Network Working Group Sheng Jiang Internet Draft Huawei Technologies Co., Ltd Intended status: Standards Track G. Chen Expires: August 27, 2010 China Mobile March 1, 2010 Requirements for Addresses Registration draft-jiang-6man-addr-registration-req-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 August 27, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Jiang & Chen Expires August 27, 2010 [Page 1] Internet-Draftdraft-jiang-6man-addr-registration-req-00.txt March 2010 Abstract In the IPv6 address allocation scenarios, node self-generated addresses are notionally conflicted with the network managed address architecture. These addresses need to be registered in the networking management plate for the purposes of central address administration. This document discusses the requirements of address registration and analyzes the possible solutions. Table of Contents 1. Introduction & Requirements..................................3 2. Terminology..................................................3 3. Potential Solutions..........................................4 3.1. Generic Address Registration Procedure..................4 3.2. Propagating the Registration Request....................4 3.3. Address Registration Server and Protocol................5 3.3.1. Using DHCPv6 and DHCPv6 server.....................5 3.3.2. Defining a new address Registration Protocol.......5 4. Security Considerations......................................6 5. IANA Considerations..........................................6 6. Change Log [RFC Editor please remove]........................6 7. Acknowledgments..............................................6 8. References...................................................6 8.1. Normative References....................................6 8.2. Informative References..................................7 Author's Addresses..............................................8 Jiang & Chen Expires August 27, 2010 [Page 2] Internet-Draftdraft-jiang-6man-addr-registration-req-00.txt March 2010 1. Introduction & Requirements In the IPv6 address allocation scenarios, node self-generated addresses, such as addresses in IPv6 Stateless Address Configuration [RFC4862, RFC4941] scenario and Cryptographically Generated Addresses (CGA, [RFC3972]), is notionally conflicted with the network managed address architecture, such as DHCPv6-managed network or network with Access Control List, in which addresses are assigned and managed by the network management plate. The current IPv4 address allocation mode in DHCPv4-managed network is that the DHCPv4 server assigns addresses. Many operators of enterprise networks and similarly tightly administered networks have expressed the desire to hold on to this model when moving to IPv6, because they don't want to have hosts end up with essentially random IPv6 addresses. However, the notion that a server assigns an address is for the most part incompatible with IPv6 stateless configuration. A useful way to give network administrators most of what they want, while at the same time retaining compatibility with normal stateless configuration would be: if the self-generated IPv6 addresses are used, they may need to be registered in and granted by the networking management plate. The node may be required to perform this registration since only granted IPv6 addresses are allowed to be used to access the network. This document discusses the requirements of address registration and analyzes the possible solutions. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) and Router Advertisement may be extended to propagate the address registration request from network management to nodes. A DHCPv6 server may play the address registration server with newly defined DHCPv6 options. However, this may conflict with the original DHCP notion. A new set of protocol may have to be defined for the address registration purpose. 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 [RFC2119]. Jiang & Chen Expires August 27, 2010 [Page 3] Internet-Draftdraft-jiang-6man-addr-registration-req-00.txt March 2010 3. Potential Solutions 3.1. Generic Address Registration Procedure By current default, the nodes with self-generated addresses do not register their addresses to any network devices. However, this may result that the network may reject the access request from these devices. As showed in below Figure 1, in the generic address registration procedure, the network management plate should firstly propagate the request of registering self-generated addresses. By received such requests, a node using the self-generated address should send an address registration message to the network management. The network management should check whether the requested address is accepted, for example, performing a Duplicated Address Detect or checking the address does not use the Reserved IPv6 Interface Identifiers [RFC5453]. If the requested address is accepted by the network management, it is registered in the address manage database, which may be used by other network functions, such as DNS or ACL. An acknowledgement is sent to the node, granting the usage of this address. If the requested address is not accepted by the network management, a rejected acknowledgement is sent to the node to indicate that it must generate a new address. +--------------------+ +---------+ | Network Management | | Node | +--------------------+ +---------+ | | | Request Node to register addr | |----------------------------------------->| | | |Send self-generation addr for registration| |<-----------------------------------------| register | | the addr |Reply granting or rejected acknowledgment | |----------------------------------------->| Figure 1: address registration procedure 3.2. Propagating the Registration Request In order to indicate or force the nodes with self-generated addresses to register their addresses and the appointed address registration server, a new request option needs to be defined. Jiang & Chen Expires August 27, 2010 [Page 4] Internet-Draftdraft-jiang-6man-addr-registration-req-00.txt March 2010 There are more than one mechanisms in which configuration parameters could be pushed to the end hosts. The address registration request option can be carried in Router Advertisement. In the DHCPv6 managed network, it can also be carried in DHCPv6 messages. By receiving attendant of the address registration request option, a node MUST register its self-generated addresses, if there are any, to the appointed registration server. The option may be defined to include the default/enforced address registration server. 3.3. Address Registration Server and Protocol In order to manage the address, an address registration server is needed with the support a set of address registration protocol. The server should hold all registered addresses. It also needs to check whether the addresses meet the network address management policy, also performing a Duplicated Address Detect or checking the address does not use the Reserved IPv6 Interface Identifiers [RFC5453], etc. Its address data may be used by other network functions, such as DNS or ACL. A set of address registration protocol need to at least support a basic information exchange: the node sends its address to the server and an acknowledgement is sent to the node. 3.3.1. Using DHCPv6 and DHCPv6 server The current DHCPv6 protocol can be reused as the address registration protocol while a DHCPv6 serve plays as address registration server. The current DHCPv6 specification allows for a host to communicate a set of "preferred" addresses to the server by listing these addresses in IA options [RFC3315]. In order to response to registration requests, an acknowledgement DHCPv6 option should be defined. It is used to indicate whether the registration of an IPv6 address is accepted. 3.3.2. Defining a new address Registration Protocol However, the address registration procedure using DHC protocol may conflict with the initial notional of DHC protocol. The DHC protocol was originally designed to push configuration information from the network management side to the hosts while the address registration procedure is collecting information from hosts to the network management side. Jiang & Chen Expires August 27, 2010 [Page 5] Internet-Draftdraft-jiang-6man-addr-registration-req-00.txt March 2010 A new set of address registration protocol may be defined. [Author notes for IETF discussion:] Any other existing protocol may be used for address registration purposes? 4. Security Considerations An attacker may use a faked address registration request option to indicate hosts reports their address to a malicious server and collect the user information. These attacks may be prevented by using secure protocols, in Neighbor Discovery protocol case, Secure Neighbor Discovery (SEND, [RFC3971]); in DHCP case, Secure DHCP [I- D.jiang-dhc-secure-dhcpv6]; or other additional security mechanisms. An attacker could generate IPv6 address registration requests in order to exhaust the server resources (or to impact on any other operation that depend on the registration of the address). In the use case of DHCPv6, the address registration procedure is as vulnerable as all other mechanisms based on DHCPv6 to DOS attacks to the server. Proper use of DHCPv6 autoconfiguration facilities [RFC3315], such as AUTH option or Secure DHCP [I-D.jiang-dhc-secure- dhcpv6] can prevent these threats. 5. IANA Considerations There is no IANA considerations. 6. Change Log [RFC Editor please remove] draft-jiang-6man-addr-registration-req-00, original version, 2010-03- 01 7. Acknowledgments The authors would like to thank Cao Wei, Huawei for been involved in the early requirement identification and early discussion. 8. References 8.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, March 1997. Jiang & Chen Expires August 27, 2010 [Page 6] Internet-Draftdraft-jiang-6man-addr-registration-req-00.txt March 2010 [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carne, "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. [RFC4861] T. Narten, et al., "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] S. Thomson, T. Narten and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC4862, September 2007. [RFC4941] T. Narten, R. Draves and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC5453] S. Krishnan, "Reserved IPv6 Interface Identifiers", RFC 4543, February 2009. 8.2. Informative References [I-D.jiang-dhc-secure-dhcpv6] S. Jiang and S. Shen "Secure DHCPv6 Using CGAs", draft- jiang-dhc-secure-dhcpv6-03.txt (work in progress), February, 2010. Jiang & Chen Expires August 27, 2010 [Page 7] Internet-Draftdraft-jiang-6man-addr-registration-req-00.txt March 2010 Author's Addresses Sheng Jiang Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 P.R. China Phone: 86-10-82836774 Email: shengjiang@huawei.com Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Phone: +86-13910710674 Email: phdgang@gmail.com Jiang & Chen Expires August 27, 2010 [Page 8]