Internet DRAFT - draft-que-dhc-dns-multi-dhcp-servers
draft-que-dhc-dns-multi-dhcp-servers
DHC Working Group X. Que
Internet-Draft W. Wang
Intended status: Standards Track L. Zhang
Expires: October 16, 2015 L. Sun
BUPT University
April 14, 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 16, 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
Que, et al. Expires October 16, 2015 [Page 1]
Internet-Draft DNS Delete CONFIRMATION April 2015
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 . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3
5. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 4
5.1. DHCPv6 ADDR-REGISTRATION-CONFIRMATION Message . . . . . . 4
5.2. DHCPv6 ADDR-REGISTRATION-VALIDATION Message . . . . . . . 5
6. DHCPv6 Address Registration Confirmation Procedure . . . . . 5
6.1. DHCPv6 Address Registration Confirmation Request . . . . 6
6.2. Registration Expiry and Refresh . . . . . . . . . . . . . 6
7. Security Considerations (TBD) . . . . . . . . . . . . . . . . 6
8. IANA Considerations (TBD) . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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.
Que, et al. Expires October 16, 2015 [Page 2]
Internet-Draft DNS Delete CONFIRMATION April 2015
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.
Que, et al. Expires October 16, 2015 [Page 3]
Internet-Draft DNS Delete CONFIRMATION April 2015
+----+ +-----------+ +---------------+
|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.
Que, et al. Expires October 16, 2015 [Page 4]
Internet-Draft DNS Delete CONFIRMATION April 2015
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.
Que, et al. Expires October 16, 2015 [Page 5]
Internet-Draft DNS Delete CONFIRMATION April 2015
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.
Que, et al. Expires October 16, 2015 [Page 6]
Internet-Draft DNS Delete CONFIRMATION April 2015
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
Que, et al. Expires October 16, 2015 [Page 7]
