DHC Working Group S. Jiang Internet-Draft Huawei Technologies Co., Ltd Intended status: Standards Track G. Chen Expires: August 29, 2013 China Mobile S. Krishnan Ericsson February 25, 2013 A Generic IPv6 Addresses Registration Solution Using DHCPv6 draft-ietf-dhc-addr-registration-02 Abstract In networks that are centrally managed, self-generated addresses cause traceability issues due to their decentralized nature. To minimize the issues due to lack of traceability, these self-generated addresses can be registered with the network for allowing centralized address administration. This document defines a generic address registration solution using DHCPv6, using a new ND option and a new DHCPv6 option in order to communicate the use of self-generated addresses. A new Addr-registration-request message type is defined for initiate the address registration request, among with two new Status codes to indicate registration errors on the server side. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 29, 2013. Copyright Notice Copyright (c) 2013 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 Jiang, et al. Expires August 29, 2013 [Page 1] Internet-Draft IPv6 Address Registration February 2013 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Generic Address Registration Solution . . . . . . . 3 4. Propagating the Address Registration Solicitation . . . . . . . 4 4.1. ND Address Registration Solicitation Option . . . . . . . . 5 4.2. DHCPv6 Address Registration Solicitation Option . . . . . . 5 5. DHCPv6 Addr-registration-request Message . . . . . . . . . . . 6 6. DHCPv6 Address Registration Procedure . . . . . . . . . . . . . 6 6.1. DHCPv6 Address Registration Request . . . . . . . . . . . . 6 6.2. DHCPv6 Address Registration Acknowledge . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Jiang, et al. Expires August 29, 2013 [Page 2] Internet-Draft IPv6 Address Registration February 2013 1. Introduction In several common network scenarios, IPv6 addresses are self- generated by the end-hosts using some information propogated to them by the network (i.e. the network prefix). Examples of self-generated addresses include those created using IPv6 Stateless Address Configuration [RFC4862] , temporary addresses [RFC4941] and Cryptographically Generated Addresses (CGA) [RFC3972] etc. These addresses are potentially incompatible with networks with a centrally managed address architecture such as DHCPv6 [RFC3315] as they lack traceability and stability. Many operators of enterprise networks and similarly tightly administered networks have expressed the desire to be at least aware of the hosts' self-generated addresses when migrating to IPv6. One potential way to provide network administrators with most of their needs while retaining compatibility with normal stateless configuration would be to register the self-generated addresses with the systems in place to centrally administer the addresses. The edge router that observes hosts' addresses through the Neighbor Discovery protocol is the most suitable devices to register these addresses. This document introduces a new IPv6 Neighbor Discovery option and a new DHCPv6 option to solicite edge routers to register addresses. The DHCPv6 protocol is used to perform the address registration procedure while the address registration server role may be performed by a DHCPv6 server or a stand-alone server, which is also considered as a DHCPv6 server from the DHCPv6 protocol perspective. A new Addr- registration-request DHCPv6 message type is defined to initiate the address registration request, and two new Status codes is defined to indicate registration errors on the server side. 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]. 3. Overview of Generic Address Registration Solution In the generic address registration solution, the network management system solicits the edge routers to register addresses, by sending solicitation messages from either upstream router (step 1a in Figure 1) or DHCPv6 server (step 1b in Figure 1). Jiang, et al. Expires August 29, 2013 [Page 3] Internet-Draft IPv6 Address Registration February 2013 After receiving such solicitations, an edge router implementing this specification SHOULD send an Addr-registration-request message to the address registration server (step 2 in Figure 1, defined in Section 5 of this document). The address registration server may be acted by a DHCPv6 server. By received the address registration request, the address registration server records the requested address in the address registration database, which MAY be used by other network functions, such as DNS or ACL, etc. An acknowledgement MAY be sent back to the edge router (step 3 in Figure 1). +----+ +-----------+ +---------------+ +---------------+ |Host| |Edge router| |Upstream Router| |Addr-Reg Server| +----+ +-----------+ +---------------+ +---------------+ | ND | | | |<--------->| | | | | | |Addr Register Solicitation(1a) | |<------------------| | | | | Addr Register Solicitation(1b) | |<-------------------------------------| | | | Addr-registration-request(2) | |------------------------------------->| | |Register | Acknowledgment addr registration(3) |address |<-------------------------------------| Figure 1: Address Registration Procedure 4. Propagating the Address Registration Solicitation In order to notify the edge routers the availabilityof the address registration service, new solicitation options are needed. There is more than one mechanism by which configuration parameters could be pushed to the edge routers. The address registration solicitation option can be carried in Router Advertisement (RA) message, which is broadcasted by upstream routers. In the DHCPv6 managed network, it can also be carried in DHCPv6 messages. This document defines a new ND option and a new DHCPv6 option for this purpose. Since the address registration process is through the standard DHCPv6 client/ server communication - send packets to ff02::1:2, the All_DHCP_Relay_Agents_and_Servers multicast address, these solicitation options do not contain the IP address of address registration server. After receving a message containing an address registration solicitation option, an edge router implementing this specification Jiang, et al. Expires August 29, 2013 [Page 4] Internet-Draft IPv6 Address Registration February 2013 SHOULD register addresses to the address registration server. 4.1. ND Address Registration Solicitation Option The ND Address Registration Solicitation Option allows an upstream router to propagate the solicitation for edge routers to register addresses. The format of the ND Address Registration Solicitation Option is described as follows: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA1 Length 1 (in units of 8 octets, Type and Length themselves are included). Reserved Padding bits. For future use also. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. ND Address Registration Solicitation Option 4.2. DHCPv6 Address Registration Solicitation Option The DHCPv6 Address Registration Solicitation Option allows a DHCPv6 server to propagate the solicitation for edge routers to register addresses. This option MAY be propagated together with DHCPv6 Prefix Delegation Option, [RFC3633]. The format of the DHCPv6 Address Registration Solicitation Option is described as follows: 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_ADDR_REG_SOLICITATION | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_ADDR_REG_SOLICITATION (TBA2). option-len 0, Length of this option in octets (not including option-code and option-len). DHCPv6 Addr Registration Solicitation Option Jiang, et al. Expires August 29, 2013 [Page 5] Internet-Draft IPv6 Address Registration February 2013 5. DHCPv6 Addr-registration-request Message A DHCPv6 client (the edge router) sends an Addr-registration-request message to a server to request addresses to be registered. The format of the Addr-registration-request message is described as follows, compliant with Section 6 in [RFC3315]: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | transaction-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . options . . (variable) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type Identifies the DHCPv6 message type; (TBA3). transaction-id The transaction ID for this message exchange. options Options carried in this message. DHCPv6 Addr-Registration-Request message This Addr-registration-request message MUST NOT contain server- identifier option and SHOULD only contain IA_NA option(s) and Client Identifier option. Clients MUST discard any received Addr-registration-request messages. Servers MUST discard any Addr-Registration-Request messages that do not include a Client Identifier option or that do include a Server Identifier option. 6. DHCPv6 Address Registration Procedure The DHCPv6 protocol is reused as the address registration protocol while a DHCPv6 server can play the role of an address registration server. The IA_NA DHCPv6 option [RFC3315] is reused in order to fulfill the address registration interactions. 6.1. DHCPv6 Address Registration Request The edge router sends a DHCPv6 Addr-registration-request message to the address registration server to ff02::1:2, the All_DHCP_Relay_Agents_and_Servers multicast address. Jiang, et al. Expires August 29, 2013 [Page 6] Internet-Draft IPv6 Address Registration February 2013 The edge router MUST include a Client Identifier option in the Addr- registration-request message to identify itself to the server. The DHCPv6 Addr-registration-request message SHOULD contain at least one IA_NA option. The IA_NA option SHOULD contain at least one IA Address option. After receiving this Addr-Registration-Request message, the address registration server MUST register the requested address(es) in its address registration database, which may further be used by other network functions, such as DNS, network access control lists, etc. If the DHCPv6 server does not support address registration function, a Reply message with includes a Status Code option with the value the RegistrationNotSupported (TBA4) MAY be sent back to the initiated client. 6.2. DHCPv6 Address Registration Acknowledge After all the addresses have been processed, the address registration server MAY send a Reply message as the response to registration requests. The server generates a Reply message and includes a Status Code option with value Success, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. For each IA in the Release message for which the server does no register, the server adds an IA option using the IAID from the Addr- registration-request message, and includes a Status Code option with the value RegistrationDenied (TBA5) in the IA option. No other options are included in the IA option. 7. Security Considerations An attacker may register large number of fake addresses with the network in order to overwhelm the address registration server. These attacks may be prevented generic DHCPv6 protection by using the AUTH option [RFC3315] or Secure DHCPv6 [I-D.ietf-dhc-secure-dhcpv6]. 8. IANA Considerations This document defines a new IPv6 Neighbor Discovery option, the Address Registration Solicitation Option (TBA1) described in Section 4.1, that requires an allocation out of the registry defined at http://www.iana.org/assignments/icmpv6-parameters This document defines a new DHCPv6 option, the OPTION_ADDR_REG_SOLICITATION (TBA2) described in Section 4.2, that requires an allocation out of the registry defined at Jiang, et al. Expires August 29, 2013 [Page 7] Internet-Draft IPv6 Address Registration February 2013 http://www.iana.org/assignments/dhcpv6-parameters/ This document defines a new DHCPv6 message, the Addr-registration- request message (TBA3) described in Section 5, that requires an allocation out of the registry defined at http://www.iana.org/assignments/dhcpv6-parameters/ This document defines two new DHCPv6 Status code, the RegistrationNotSupported (TBA4) and RegistrationDenied (TBA5) described in Section 6, that requires an allocation out of the registry defined at http://www.iana.org/assignments/dhcpv6-parameters/ 9. Acknowledgements The authors would like to thank Ralph Droms, Ted Lemon, Bernie Volz, Sten Carlsen, Erik Kline, Lorenzo Colitti, Joel Jaeggli, Sten Carlsen, Mark Smith and other members of dhc and v6ops working groups for their valuable comments. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. Jiang, et al. Expires August 29, 2013 [Page 8] Internet-Draft IPv6 Address Registration February 2013 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. 10.2. Informative References [I-D.ietf-dhc-secure-dhcpv6] Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", draft-ietf-dhc-secure-dhcpv6-07 (work in progress), September 2012. Authors' Addresses Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China Email: jiangsheng@huawei.com Gang Chen China Mobile 53A, Xibianmennei Ave., Xuanwu District, Beijing P.R. China Phone: 86-13910710674 Email: phdgang@gmail.com Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 x42871 Email: suresh.krishnan@ericsson.com Jiang, et al. Expires August 29, 2013 [Page 9]