| DHC Working Group | X. Que |
| Internet-Draft | W. Wang |
| Intended status: Standards Track | L. Zhang |
| Expires: October 17, 2015 | L. Sun |
| BUPT University | |
| April 15, 2015 |
DNS Delete-Confirm Mechanism with Multi-DHCP-Servers
draft-que-dhc-dns-multi-dhcp-servers-01
[I-D.ietf-dhc-addr-registration] specifies how a host register its self-generated addresses in DNS through DHCPv6 server. [RFC3315] allows multiple DHCPv6 servers working in an administrative domain. There exists a scenario that the client may register its addresses in multiple servers for some reasons such as higher availability and etc. This document defines a mechanism to ensure the multiple servers could work properly during 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 October 17, 2015.
Copyright (c) 2015 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.
[I-D.ietf-dhc-addr-registration] describes a mechanism to register self-generated and statically configured addresses in DNS through a DHCPv6 server. The client will send a DNS registration request to the DHCPv6 server after successfully assigning a self-generated IPv6 address on one of its interfaces. The DHCPv6 server then registers the client's IPv6 address to FQDN binding towards a configured DNS server, with a valid-lifetime. The client must extend the registration before it expires. If the DHCPv6 server does not receive such a refresh after the valid-lifetime has passed, it SHOULD remove the IPv6-address-to-FQDN bindings in DNS.
Multiple DHCPv6 servers working in an administrative domain is encouraged since it could bring higher availability, load balancing ability and other benefits. However in the context of Multiple servers within a single network, problems may arise when performing DNS update. This document specifies a mechanism to ensure servers could coordinate with each other and update DNS correctly.
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].
[I-D.ietf-dhc-addr-registration] describes a mechanism to register self-generated and statically configured addresses in DNS through a DHCPv6 server. When there are multiple address registration DHCPv6 servers within an administration domain, the client can send DNS registration request to multiple servers, and the servers can work correctly in registering DNS. When the client wants to extend its registered DNS entry, it will send an extension request to the registration servers. However, when one of the registration servers which received the initial registration request does not receive the extension request, it will remove the client's IPv6-address-to-FQDN bindings in DNS once its original valid-lifetime has passed, without verifying with the client.
After the servers update DNS correctly, the client SHOULD extends this by sending a new ADDR-REGISTRATION-REQUEST 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 the entry should be removed. The ADDR-REGISTRATION-VALIDATION message MUST be sent back to the server to indicate whether the server should remove the address registration entry or not.
+----+ +-----------+ +---------------+
|Host| |Edge router| |Addr-Reg Server|
+----+ +-----------+ +---------------+
| SLAAC | |
|<------------>| |
| | |
| | ADDR-REGISTRATION-CONFIRMATION |
|<----------------------------------------------|
| | |Register
| | |address
| | ADDR-REGISTRATION-VALIDATION |in DNS
|---------------------------------------------->|
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) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 sent 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) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
TBD
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. |