| 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
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.
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 (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 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.
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.
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].
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
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.
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:
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
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.
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
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.
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.
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.
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.
TBA
This document defines two new DHCPv6 message, the ADDR-REGISTRATION- CONFIRMATION message (TBA1) and ADDR-REGISTRATION-VALIDATION message (TBA2) described in Section 4.
| [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. |