DHC Working Group X. Que Internet-Draft W. Wang Intended status: Standards Track L. Zhang Expires: March 19, 2015 BUPT University L. Li Tsinghua University September 15, 2014 DNS Delete-Confirm Mechanism With Multi-DHCP-Servers draft-que-dhc-dns-multi-dhcp-servers-00 Abstract Registering Self-generated IPv6 Addresses in DNS using DHCPv6 describes a mechanism to register self-generated and statically configured addresses in DNS through a DHCPv6 server. If there are multiple DHCPv6 servers within an administration domain, when the client extends the configuration, the coordination of multiple servers will be an important problem. This document defines a mechanism to ensure that the servers can work correctly in updating DNS. 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 March 19, 2015. Copyright Notice Copyright (c) 2014 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 Que, et al. Expires March 19, 2015 [Page 1] Internet-Draft DNS Delete CONFIRMATION September 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 3 4.1. DHCPv6 ADDR-REGISTRATION-CONFIRMATION Message . . . . . . 3 4.2. DHCPv6 ADDR-REGISTRATION-VALIDATION Message . . . . . . . 4 5. DHCPv6 Address Registration Confirmation Procedure . . . . . 5 5.1. DHCPv6 Address Registration Confirmation Request . . . . 5 5.2. Registration Expiry and Refresh . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction In network that are centrally managed, self-generated and statically configured addresses can be registered through a DHCPv6 server. When there are multiple DHCPv6 servers within an administration domain, the servers can work correctly in updating DNS (either adding or removing the entries). If there are two address registration servers and both receive the initial registration and (correctly) update DNS, when the client extends this but one of the servers does not receive this extension. Then, the server that missed the extension removes the entry prematurely (i.e., when it expired originally). This document defines a mechanism to ensure that the servers can coordinate with each other and update DNS correctly. Two new DHCPv6 message type is defined to confirm the address registration information. 2. Requirements Language 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]. Que, et al. Expires March 19, 2015 [Page 2] Internet-Draft DNS Delete CONFIRMATION September 2014 3. Solution Overview After the servers update DNS correctly, the client SHOULD extends this by sending a new ADDR-REGISTRATION-CONFIRMATION message to a DHCPv6 address registration server. After receiving the refresh message, the DHCPv6 address registration server update the address registration entry. Before the servers that missed the extension remove the entry prematurely (i.e., when it expired originally), the server MUST send an ADDR-REGISTRATION-CONFIRMATION message to the client to confirm whether or not remove the entry. The ADDR- REGISTRATION-VALIDATION message MUST be sent back to the server to indicate whether or not the server remove the address registration entry. +----+ +-----------+ +---------------+ |Host| |Edge router| |Addr-Reg Server| +----+ +-----------+ +---------------+ | SLAAC | | |<------------>| | | | | | | ADDR-REGISTRATION-CONFIRMATION | |<----------------------------------------------| | | |Register | | |address | | ADDR-REGISTRATION-VALIDATION |in DNS |---------------------------------------------->| Figure 1: Address Registration Confirmation Procedure 4. New DHCPv6 Messages Two new DHCPv6 messages between the client and the server: DHCPv6 ADDR-REGISTRATION-CONFIRMATION Message and DHCPv6 ADDR-REGISTRATION- VALIDATION Message are defined.This section describes the structures of these messages. 4.1. DHCPv6 ADDR-REGISTRATION-CONFIRMATION Message Before the servers that missed the extension remove the entry prematurely, the DHCPv6 server sends an ADDR-REGISTRATION- CONFIRMATION message to a client to whether or not remove the entry. The format of the ADDR-REGISTRATION-REQUEST message is described as follows: Que, et al. Expires March 19, 2015 [Page 3] Internet-Draft DNS Delete CONFIRMATION September 2014 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) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The format of ADDR-REGISTRATION-CONFIRMATION Message msg-type Identifies the message type. transaction-id The transaction ID for this message exchange. options Options carried in this message. The ADDR-REGISTRATION-CONFIRMATION message MUST contain server identifier option and MUST contain the IA_NA option and the DHCPv6 FQDN option [RFC4704]. The IA_NA option MUST contain the IPv6 address of the server. When the client receives the ADDR- REGISTRATION-CONFIRMATION message. 4.2. DHCPv6 ADDR-REGISTRATION-VALIDATION Message When received the ADDR-REGISTRATION-CONFIRMATION message from the server, the client determines whether to remove the entry and sents ADDR-REGISTRATION-VALIDATION message to the server. The format of the ADDR-REGISTRATION-VALIDATION message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | transaction-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . options . . (variable) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The format of ADDR-REGISTRATION-VALIDATION Message msg-type Identifies the message type. transaction-id The transaction ID for this message exchange. Que, et al. Expires March 19, 2015 [Page 4] Internet-Draft DNS Delete CONFIRMATION September 2014 options Options carried in this message. If the binding entry is valid, ADDR-REGISTRATION-VALIDATION MUST contain the IA_NA option and the DHCPv6 FQDN option [RFC4704]. The IA_NA option MUST contain at least one IA Address option. The valid- lifetime field of the IA Address option MUST be set to the period for which the client would like to register the binding in DNS. If the binding entry is invalid, the client MUST NOT put any option in the ADDR-REGISTRATION-VALIDATION message. 5. DHCPv6 Address Registration Confirmation Procedure If there are multiple DHCPv6 servers within an administration domain, when the client extends the configuration, one of the server MAY miss the extension and remove the binding entry by mistake. Before the server removes the binding entry, the server MUST send ADDR- REGISTRATION-CONFIRMATION to confirm whether or not to remove the binding entry. 5.1. DHCPv6 Address Registration Confirmation Request For every successful binding registration, the address registration server MUST record the IPv6-address-to-FQDN bindings and associated valid-lifetimes in its storage. The address registration client MUST refresh the registration before it expires (i.e. before the valid-lifetime of the IA address elapses) by sending a new ADDR-REGISTRATION-REQUEST to the address registration server. If the address registration server does not receive such a refresh and the valid-lifetime will pass, the address registration server sends ADDR-REGISTRATION-CONFIRMATION to the client. If the binding entry is valid, ADDR-REGISTRATION-VALIDATION MUST contain the IA_NA option and the DHCPv6 FQDN option. If the binding entry is invalid, the client MUST NOT put any option in the ADDR- REGISTRATION-VALIDATION message. 5.2. Registration Expiry and Refresh When the server receives the ADDR-REGISTRATION-VALIDATION message, if the option is null, then remove the IPv6-address-to-FQDN binding entry in DNS, also the local record. But if the option contain the IA_NA option and the FQDN option, the server MUST refresh the registration. Que, et al. Expires March 19, 2015 [Page 5] Internet-Draft DNS Delete CONFIRMATION September 2014 6. Security Considerations TBA 7. IANA Considerations This document defines two new DHCPv6 message, the ADDR-REGISTRATION- CONFIRMATION message (TBA1) and ADDR-REGISTRATION-VALIDATION message (TBA2) described in Section 4. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [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. Authors' Addresses Xirong Que BUPT University Beijing University of Posts and Telecommunications (BUPT) Beijing 100876 P.R.China Phone: +86-10-6228-3411 Email: rongqx@bupt.edu.cn Wenhong Wang BUPT University Beijing University of Posts and Telecommunications (BUPT) Beijing 100876 P.R.China Email: wangwh@bupt.edu.cn Que, et al. Expires March 19, 2015 [Page 6] Internet-Draft DNS Delete CONFIRMATION September 2014 Lanshan Zhang BUPT University Beijing University of Posts and Telecommunications (BUPT) Beijing 100876 P.R.China Phone: +86-13146885878 Email: zls326@sina.com Lishan Li Tsinghua University Beijing 100084 P.R.China Phone: +86-15201441862 Email: lilishan9248@126.com Que, et al. Expires March 19, 2015 [Page 7]