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

Abstract

[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.

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 October 17, 2015.

Copyright Notice

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.


Table of Contents

1. Introduction

[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.

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].

3. Problem Statement

[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.

4. Solution Overview

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

5. 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.

5.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:

      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

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.

5.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 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

msg-type
Identifies the message type.
transaction-id
The transaction ID for this message exchange.
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.

6. 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.

6.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.

6.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.

7. Security Considerations (TBD)

TBD

8. IANA Considerations (TBD)

This document defines two new DHCPv6 message, the ADDR-REGISTRATION-CONFIRMATION message (TBA1) and ADDR-REGISTRATION-VALIDATION message (TBA2) described in Section 4.

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

9.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
Lanshan Zhang BUPT University Beijing University of Posts and Telecommunications (BUPT) Beijing, 100876 P.R. China Phone: +86-13146885878 EMail: zls326@sina.com
Linhui Sun BUPT University Beijing University of Posts and Telecommunications (BUPT) Beijing, 100876 P.R. China Phone: +86-13870912585 EMail: sunlinhui@bupt.edu.cn