Network Working Group Sheng Jiang Internet Draft Huawei Technologies Co., Ltd Intended status: Standards Track October 16, 2009 Expires: April 13, 2010 Addresses Registration Through DHCPv6 draft-jiang-dhc-addr-registration-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 April 16, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Jiang Expires April 16, 2010 [Page 1] Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009 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 extends Dynamic Host Configuration Protocol for IPv6 (DHCPv6) and Router Advertisement to enable the address registration processing from nodes to network management. Table of Contents 1. Introduction & Motivation.....................................3 2. Terminology...................................................3 3. Address Registration through DHCPv6...........................3 4. New Options...................................................5 4.1. Address Registry Request Option for Router Advertisement.5 4.2. Address Registry Request Option for DHCPv6...............6 4.3. Address Registration Acknowledgement Option..............6 5. Security Considerations.......................................7 6. IANA Considerations...........................................7 7. Acknowledgments...............................................8 8. References....................................................8 8.1. Normative References.....................................8 8.2. Informative References...................................8 Author's Addresses...............................................9 Jiang Expires April 13, 2010 [Page 2] Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009 1. Introduction & Motivation 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 extends Dynamic Host Configuration Protocol for IPv6 (DHCPv6) and Router Advertisement to propagate the address registration request from network management to nodes. A new Router Advertisement option and a new DHCPv6 option are defined. Two existing DHCPv6 options are re-used in the address registration interaction from nodes to network management. 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]. 3. Address Registration through DHCPv6 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. Jiang Expires April 13, 2010 [Page 3] Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009 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 The request of registering self-generated addresses can be carried in either DHCPv6 messages or Router Advertisement, but both need to define new options. The registration requests can use DHCPv6 protocol with the existing DHCPv6 options. The current DHCPv6 protocol 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, too. Among the mechanisms in which configuration parameters could be pushed to the end hosts and self-generated addresses sent back to a central administration, we discuss the stateful configuration mechanism based on DCHPv6 in this document. Other mechanisms may also provide similar functions, but out of scope. Jiang Expires April 13, 2010 [Page 4] Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009 4. New Options 4.1. Address Registry Request Option for Router Advertisement Address Registration Request Option (AR_REG) for Router Advertisement [RFC4861] is broadcasted by a router to request hosts to register their self-generated address(es), if there are any, to a certain DHCPv6 server. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DHCPv6 Server Address (128-bit) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Router Advertisement AR_REG Option Format Type 8-bit identifier of the RDNSS option type as assigned by the IANA: (TBA0) Length 3, 8-bit unsigned integer. The length of the option (including the Type and Length fields) is in units of 8 octets. Reserved A 48-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. DHCPv6 Server Address The IPv6 address of the DHCPv6 server that the client should register its self-generated address to. This field should be set to all 0, if do not assign a DHCPv6 server. By receiving this AR_REQ Option, the client MUST register its self- generated address(es), if there are any, by sending a DHCPv6 request message that contains IA option(s), in which each self-generated address is listed, to the DHCPv6 server indicated in the AR_REG Option. Jiang Expires April 13, 2010 [Page 5] Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009 {undecided question: is it possible here to have multiple DHCPv6 servers?} 4.2. Address Registry Request Option for DHCPv6 DHCPv6 Address Registration Request Option (AR_REG) is sent by a DHCPv6 server to request a host to register its self-generated address(es), if there are any. It is carried in DHCPv6 messages from server to the client. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_AR_REQ | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_AR_REG (TBA1). option-len 0. By receiving this AR_REQ Option, the client MUST register its self- generated address(es), if there are any, by sending a DHCPv6 request message that contains IA option(s), in which each self-generated address is listed. 4.3. Address Registration Acknowledgement Option DHCPv6 Address Registration Acknowledgement Option is sent by a DHCPv6 server in a response message for address registry message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_AR_ACK | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acceptance | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_AR_ACK (TBA2). Jiang Expires April 13, 2010 [Page 6] Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009 option-len 20, length of this option in octets (option-code and option-len are not included). Acceptance Indicates whether this IPv6 address are accepted and registered by the network management or rejected. 0, accepted; 1, rejected. Reserved A 24-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. IPv6 address The IPv6 address that this option is associated. Each Address Registration Acknowledgement Option only indicates the acceptance information of one IPv6 address. In order to acknowledge the registration request of multiple addresses, multiple AR_ACK Options are used. 5. Security Considerations 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). It 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 [SDHCP] can prevent these threats. If Secure Neighbor Discovery (SEND) protocol is used as the security mechanism for ND, all the ND options including RDNSS option are also automatically included in the signatures [RFC3971], so the RDNSS transport is integrity-protected. 6. IANA Considerations This document defines a new IPv6 Neighbor Discovery option, which must be assigned Option Type values within the option numbering space for ICMPv6 parameters: The Address Registry Request Option (TBA0) for Router Advertisement, described in Section 4.1. This document defines two new DHCPv6 [RFC3315] options, which must be assigned Option Type values within the option numbering space for DHCPv6 messages: Jiang Expires April 13, 2010 [Page 7] Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009 The DHCPv6 Address Registry Request Option (TBA1), described in Section 4.2. The DHCPv6 Address Registry Acknowledgement Option (TBA2), described in Section 4.3. 7. Acknowledgments The authors would like to thank Cao Wei, Huawei, Stig Venaas, Cisco 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. [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 and P. Nikander, "SEcure Neighbor Discovery (SEND) ", RFC 3971, March 2005. [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, March 2005. [RFC4861] T. Narten, E. Nordmark, W. Simpson and H. Soliman, "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 [SDHCP] S. Jiang, "Secure DHCPv6 Using CGAs", draft-jiang-dhc- secure-dhcpv6-02.txt (work in progress), July, 2009. Jiang Expires April 13, 2010 [Page 8] Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009 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 Jiang Expires April 13, 2010 [Page 9]