draft-ietf-dhc-dhcpv6-failover-design-01.txt   draft-ietf-dhc-dhcpv6-failover-design-02.txt 
Dynamic Host Configuration (DHC) T. Mrugalski Dynamic Host Configuration (DHC) T. Mrugalski
Internet-Draft ISC Internet-Draft ISC
Intended status: Standards Track K. Kinnear Intended status: Standards Track K. Kinnear
Expires: March 11, 2013 Cisco Expires: April 25, 2013 Cisco
September 7, 2012 October 22, 2012
DHCPv6 Failover Design DHCPv6 Failover Design
draft-ietf-dhc-dhcpv6-failover-design-01 draft-ietf-dhc-dhcpv6-failover-design-02
Abstract Abstract
DHCPv6 defined in [RFC3315] does not offer server redundancy. This DHCPv6 defined in [RFC3315] does not offer server redundancy. This
document defines a design for DHCPv6 failover, a mechanism for document defines a design for DHCPv6 failover, a mechanism for
running two servers on the same network with capability for either running two servers on the same network with capability for either
server to take over clients' leases in case of server failure or server to take over clients' leases in case of server failure or
network partition. This is a DHCPv6 Failover design document, it is network partition. This is a DHCPv6 Failover design document, it is
not protocol specification document. It is a second document in a not protocol specification document. It is a second document in a
planned series of three documents. DHCPv6 failover requirements are planned series of three documents. DHCPv6 failover requirements are
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 11, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Additional Requirements . . . . . . . . . . . . . . . . . 6 3.1. Additional Requirements . . . . . . . . . . . . . . . . . 6
3.2. Features out of Scope: Load Balancing . . . . . . . . . . 6 3.2. Features out of Scope: Load Balancing . . . . . . . . . . 6
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Failover Machine State Overview . . . . . . . . . . . . . 8 4.1. Failover State Machine Overview . . . . . . . . . . . . . 8
4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Connection Management . . . . . . . . . . . . . . . . . . . . 11 5. Connection Management . . . . . . . . . . . . . . . . . . . . 11
5.1. Creating Connections . . . . . . . . . . . . . . . . . . . 11 5.1. Creating Connections . . . . . . . . . . . . . . . . . . . 11
5.2. Endpoint Identification . . . . . . . . . . . . . . . . . 12 5.2. Endpoint Identification . . . . . . . . . . . . . . . . . 12
6. Resource Allocation . . . . . . . . . . . . . . . . . . . . . 13 6. Resource Allocation . . . . . . . . . . . . . . . . . . . . . 13
6.1. Proportional Allocation . . . . . . . . . . . . . . . . . 13 6.1. Proportional Allocation . . . . . . . . . . . . . . . . . 14
6.2. Independent Allocation . . . . . . . . . . . . . . . . . . 14 6.2. Independent Allocation . . . . . . . . . . . . . . . . . . 16
6.3. Determining Allocation Approach . . . . . . . . . . . . . 15 6.3. Choosing Allocation Algorithm . . . . . . . . . . . . . . 16
6.3.1. IPv6 Addresses . . . . . . . . . . . . . . . . . . . . 15 7. Information model . . . . . . . . . . . . . . . . . . . . . . 17
6.3.2. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 15 8. Failover Mechanisms . . . . . . . . . . . . . . . . . . . . . 21
7. Information model . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Failover Mechanisms . . . . . . . . . . . . . . . . . . . . . 19 8.2. Time expression . . . . . . . . . . . . . . . . . . . . . 22
8.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 19 8.3. Lazy updates . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. Time expression . . . . . . . . . . . . . . . . . . . . . 19 8.4. MCLT concept . . . . . . . . . . . . . . . . . . . . . . . 22
8.3. Lazy updates . . . . . . . . . . . . . . . . . . . . . . . 19 8.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . . 24
8.4. MCLT concept . . . . . . . . . . . . . . . . . . . . . . . 20 8.5. Unreachability detection . . . . . . . . . . . . . . . . . 25
8.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . . 21 8.6. Re-allocating Leases . . . . . . . . . . . . . . . . . . . 25
8.5. Unreachability detection . . . . . . . . . . . . . . . . . 22 8.7. Sending Binding Update . . . . . . . . . . . . . . . . . . 26
8.6. Re-allocating Leases . . . . . . . . . . . . . . . . . . . 23 8.8. Receiving Binding Update . . . . . . . . . . . . . . . . . 28
8.7. Sending Binding Update . . . . . . . . . . . . . . . . . . 23 8.9. Conflict Resolution . . . . . . . . . . . . . . . . . . . 28
8.8. Receiving Binding Update . . . . . . . . . . . . . . . . . 24 8.10. Acknowledging Reception . . . . . . . . . . . . . . . . . 30
8.9. Conflict Resolution . . . . . . . . . . . . . . . . . . . 25 9. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 30
8.10. Acknowledging Reception . . . . . . . . . . . . . . . . . 27 9.1. State Machine Operation . . . . . . . . . . . . . . . . . 30
9. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 27 9.2. State Machine Initialization . . . . . . . . . . . . . . . 33
9.1. State Machine Operation . . . . . . . . . . . . . . . . . 27 9.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 33
9.2. State Machine Initialization . . . . . . . . . . . . . . . 30 9.3.1. Operation in STARTUP State . . . . . . . . . . . . . . 34
9.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 30 9.3.2. Transition Out of STARTUP State . . . . . . . . . . . 34
9.3.1. Operation in STARTUP State . . . . . . . . . . . . . . 31 9.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . . 35
9.3.2. Transition Out of STARTUP State . . . . . . . . . . . 31 9.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 35
9.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . . 32 9.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . . 36
9.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 32 9.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 37
9.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . . 33 9.5.1. Operation in RECOVER State . . . . . . . . . . . . . . 37
9.5.2. Transition Out of RECOVER State . . . . . . . . . . . 37
9.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 34 9.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . . 39
9.5.1. Operation in RECOVER State . . . . . . . . . . . . . . 34 9.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 40
9.5.2. Transition Out of RECOVER State . . . . . . . . . . . 34 9.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . . 40
9.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . . 36 9.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . . 40
9.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 37 9.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 41
9.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . . 37 9.7.2. Transition Out of RECOVER-DONE State . . . . . . . . . 41
9.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . . 37 9.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . . 41
9.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 38 9.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 41
9.7.2. Transition Out of RECOVER-DONE State . . . . . . . . . 38 9.8.2. Transition Out of NORMAL State . . . . . . . . . . . . 42
9.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . . 38 9.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . . 43
9.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 38 9.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 43
9.8.2. Transition Out of NORMAL State . . . . . . . . . . . . 39 9.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . . 44
9.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . . 40 9.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . . 45
9.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 40 9.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . . 46
9.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . . 41 9.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . . 46
9.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . . 42 9.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . . 47
9.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . . 43 9.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . . 48
9.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . . 43 9.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . . 48
9.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . . 44 9.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 48
9.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . . 45 9.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . . 48
9.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . . 45 9.12.2. Transition Out of CONFLICT-DONE State . . . . . . . . 49
9.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 45 10. Proposed extensions . . . . . . . . . . . . . . . . . . . . . 49
9.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . . 46 10.1. Active-active mode . . . . . . . . . . . . . . . . . . . . 49
9.12.2. Transition Out of CONFLICT-DONE State . . . . . . . . 46 11. Dynamic DNS Considerations . . . . . . . . . . . . . . . . . . 50
10. Proposed extensions . . . . . . . . . . . . . . . . . . . . . 46 11.1. Relationship between failover and dynamic DNS update . . . 50
10.1. Active-active mode . . . . . . . . . . . . . . . . . . . . 46 11.2. Exchanging DDNS Information . . . . . . . . . . . . . . . 51
11. Dynamic DNS Considerations . . . . . . . . . . . . . . . . . . 47 11.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . . 53
12. Reservations and failover . . . . . . . . . . . . . . . . . . 47 11.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . . 54
13. Protocol entities . . . . . . . . . . . . . . . . . . . . . . 47 11.5. Name Assignment with No Update of DNS . . . . . . . . . . 54
13.1. Failover Protocol . . . . . . . . . . . . . . . . . . . . 47 12. Reservations and failover . . . . . . . . . . . . . . . . . . 55
13.2. Protocol constants . . . . . . . . . . . . . . . . . . . . 47 13. Security Considerations . . . . . . . . . . . . . . . . . . . 56
14. Open questions . . . . . . . . . . . . . . . . . . . . . . . . 48 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
15. Security Considerations . . . . . . . . . . . . . . . . . . . 48 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 16.1. Normative References . . . . . . . . . . . . . . . . . . . 57
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 16.2. Informative References . . . . . . . . . . . . . . . . . . 57
18.1. Normative References . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
18.2. Informative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
1. Requirements Language 1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Glossary 2. Glossary
This is a supplemental glossary that should be combined with This is a supplemental glossary that should be combined with
skipping to change at page 4, line 41 skipping to change at page 4, line 41
unless to do so would be confusing. unless to do so would be confusing.
o Failover transmission - all messages exchanged between partners. o Failover transmission - all messages exchanged between partners.
o Independent Allocation - a prefix allocation algorithm to split o Independent Allocation - a prefix allocation algorithm to split
the available pool of resources between the primary and secondary the available pool of resources between the primary and secondary
servers that is particularly well suited for vast pools (i.e. when servers that is particularly well suited for vast pools (i.e. when
available resources are not expected to deplete). See Section 6.2 available resources are not expected to deplete). See Section 6.2
for details. for details.
o Primary Server o Partner - name of the other DHCPv6 server that participates in
failover relationship. When the role (primary or secondary) is
not important, the other server is referred to as a "failover
partner" or simply partner.
o Proportional Allocation - a prefix allocation algorithm to split o Primary Server - First out of two DHCPv6 servers that participate
the available free leases between the primary and secondary in a failover relationship. In active-passive mode this is the
servers that is particularly well suited for more limited server that handles most of the client traffic. Its failover
resources. See Section 6.1 for details. partner is referred to as secondary server.
o Proportional Allocation - a prefix allocation algorithm that
splits the available resources (addresses or prefixes) between the
primary and secondary servers that is particularly well suited for
more limited resources. See Section 6.1 for details.
o Resource - Any type of resource that is assignable using DHCPv6. o Resource - Any type of resource that is assignable using DHCPv6.
Currently there are two types of such resources defined: a non- Currently there are two types of such resources defined: a non-
temporary IPv6 address and an IPv6 prefix. Due to the nature of temporary IPv6 address and an IPv6 prefix. Due to the nature of
temporary addresses, they are not covered by the failover temporary addresses, they are not covered by the failover
mechanism. Other resource types may be defined in the future. mechanism. Other resource types may be defined in the future.
o Responsive - A server that is responsive, will respond to DHCPv6 o Responsive - A server that is responsive, will respond to DHCPv6
client requests. client requests.
o Secondary Server o Secondary Server - Second of out two DHCPv6 servers that
participate in a failover relationship. Its failover partner is
referred to as primary server. In active-passive mode this server
typically does not handle client traffic and acts as a backup.
o Server - A DHCPv6 server that implements DHCPv6 failover. o Server - A DHCPv6 server that implements DHCPv6 failover.
'Server' and 'failover endpoint' are synonymous only if the server 'Server' and 'failover endpoint' are synonymous only if the server
participates in only one failover relationship. participates in only one failover relationship.
o Unresponsive - A server that is unresponsive will not respond to o Unresponsive - A server that is unresponsive will not respond to
DHCPv6 client requests. DHCPv6 client requests.
3. Introduction 3. Introduction
skipping to change at page 6, line 28 skipping to change at page 6, line 39
While it is tempting to extend DHCPv6 failover mechanism to also While it is tempting to extend DHCPv6 failover mechanism to also
offer load balancing, as DHCPv4 failover did, this design does not do offer load balancing, as DHCPv4 failover did, this design does not do
that. Here is the reasoning for this decision. In general case (not that. Here is the reasoning for this decision. In general case (not
related to failover) load balancing solutions are used when each related to failover) load balancing solutions are used when each
server is not able to handle total incoming traffic. However, by the server is not able to handle total incoming traffic. However, by the
very definition, DHCPv6 failover is supposed to assume service very definition, DHCPv6 failover is supposed to assume service
availability despite failure of one server. That leads to conclusion availability despite failure of one server. That leads to conclusion
that each server must be able to handle whole traffic. Therefore in that each server must be able to handle whole traffic. Therefore in
properly provisioned setup, load balancing is not needed. properly provisioned setup, load balancing is not needed.
It is likely that active-active mode that is essentially a load
balancing will be defined as an extension in the near future.
4. Protocol Overview 4. Protocol Overview
The DHCPv6 Failover Protocol is defined as a communication between The DHCPv6 Failover Protocol is defined as a communication between
failover partners with all associated algorithms and mechanisms. failover partners with all associated algorithms and mechanisms.
Failover communication is conducted over a TCP connection established Failover communication is conducted over a TCP connection established
between the partners. The protocol reuses the framing format between the partners. The protocol reuses the framing format
specified in Section 5.1 of DHCPv6 Bulk Leasequery [RFC5460], but specified in Section 5.1 of DHCPv6 Bulk Leasequery [RFC5460], but
uses different message types. New failover-specific message types uses different message types. New failover-specific message types
are listed in Section 4.2. All information is sent over the are listed in Section 4.2. All information is sent over the
connection as typical DHCPv6 messages that convey DHCPv6 options, connection as typical DHCPv6 messages that convey DHCPv6 options,
skipping to change at page 7, line 39 skipping to change at page 8, line 6
its response to the client's request first (performing the "regular" its response to the client's request first (performing the "regular"
DHCPv6 operation) and then informs its failover partner using a DHCPv6 operation) and then informs its failover partner using a
BNDUPD message. This BNDUPD message SHOULD be sent soon after the BNDUPD message. This BNDUPD message SHOULD be sent soon after the
response is sent to the DHCPv6 client, but there is no specific response is sent to the DHCPv6 client, but there is no specific
requirement of a minimum time in which to do so. requirement of a minimum time in which to do so.
The major problem with lazy update mechanism is the case when the The major problem with lazy update mechanism is the case when the
server crashes after sending a response to client, but before sending server crashes after sending a response to client, but before sending
the lazy update to its partner (or when communication between the lazy update to its partner (or when communication between
partners is interrupted). To solve this problem, the concept known partners is interrupted). To solve this problem, the concept known
as the Maximum Client Lead Time (MCLT) (initially designed for DHCPv4 as the Maximum Client Lead Time (initially designed for DHCPv4
failover) is used. The MCLT is the maximum amount of time that one failover) is used. The MCLT is the maximum amount of time that one
server can extend a lease for a client's binding beyond the time server can extend a lease for a client's binding beyond the time
known by its failover partner. See Section 8.4 for detailed known by its failover partner. See Section 8.4 for detailed
desciption how the MCLT affects assigned lease times. desciption how the MCLT affects assigned lease times.
Servers verify each others availability by periodically exchanging Servers verify each others availability by periodically exchanging
CONTACT messages. See Section 8.5 for discussion about detecting a CONTACT messages. See Section 8.5 for discussion about detecting a
partner's unreachability. partner's unreachability.
A server that is being shut down transmits a DISCONNECT message, A server that is being shut down transmits a DISCONNECT message,
closes the connection with its failover partner and stops operation. closes the connection with its failover partner and stops operation.
A Server SHOULD transmit any pending lease updates before A Server SHOULD transmit any pending lease updates before
transmitting DISCONNECT message. transmitting DISCONNECT message.
4.1. Failover Machine State Overview 4.1. Failover State Machine Overview
The following section provides a simplified description of all The following section provides a simplified description of all
states. For the sake of clarity and simplicity, it omits important states. For the sake of clarity and simplicity, it omits important
details. For complete description, see Section 9. In case of a details. For complete description, see Section 9. In case of a
disagreement between the simplified and complete description, please disagreement between the simplified and complete description, please
follow Section 9. follow Section 9.
Each server MUST be in one of the well defines states. In each state Each server MUST be in one of the well defines states. In each state
a server may be either responsive (responds to clients' queries) or a server may be either responsive (responds to clients' queries) or
unresponsive (clients' queries are ignored). unresponsive (clients' queries are ignored).
A server starts its operation in short-lived STARTUP state. A server A server starts its operation in short-lived STARTUP state. A server
determines its partner reachibility and state and sets its own state determines its partner reachability and state and sets its own state
based on that determination. It frequently returns back to the state based on that determination. It frequently returns back to the state
it was in before shutdown. it was in before shutdown.
During typical operation when servers maintain communication, both During typical operation when servers maintain communication, both
are in NORMAL state. In that state only the primary responds to are in NORMAL state. In that state only the primary responds to
clients' requests. A secondary server in unresponsive to DHCPv6 clients' requests. A secondary server in unresponsive to DHCPv6
clients. clients.
If a server discovers that its partner is no longer reachable, it If a server discovers that its partner is no longer reachable, it
goes to COMMUNICATIONS-INTERRUPTED state. A server must be extra goes to COMMUNICATIONS-INTERRUPTED state. A server must be extra
skipping to change at page 14, line 25 skipping to change at page 14, line 42
between them. between them.
Pools governed by proportional allocation are used for allocation Pools governed by proportional allocation are used for allocation
when the server is in all states, except PARTNER-DOWN. In PARTNER- when the server is in all states, except PARTNER-DOWN. In PARTNER-
DOWN state the healthy partner can allocate from either pool (both DOWN state the healthy partner can allocate from either pool (both
its own and its partner's). This allocation and maintenance of these its own and its partner's). This allocation and maintenance of these
address pools is an area of some sensitivity, since the goal is to address pools is an area of some sensitivity, since the goal is to
maintain a more or less constant ratio of available addresses between maintain a more or less constant ratio of available addresses between
the two servers. the two servers.
TODO: Reuse rest of the description from section 5.4 from The initial allocation when the servers first integrate is triggered
[dhcpv4-failover] here. by the POOLREQ message from the secondary to the primary. This is
followed by the POOLRESP message where the primary tells the
secondary how many resources it allocated to the secondary. Then,
the primary sends the allocated resources to the secondary via BNDUPD
messages. The POOLREQ/POOLRESP message is a trigger to the primary
to perform a scan of its database and to ensure that the secondary
has enough resources (based on some configured ratio).
Servers frequently have several kinds of resources available on a
particular network segment. The failover protocol assumes that both
primary and secondary servers are configured in such a way that each
knows the type and number of resources on every network segment
participating in the failover protocol. The primary server is
responsible for allocating the secondary server the correct
proportion of available resources of each kind, and the secondary
server is responsible for being configured in such a way that it can
tell the kind of every resource based solely on the IP or prefix
address itself.
The resources are delegated to the secondary using the BNDUPD message
with a state of FREE_BACKUP, which indicates the resource is now
available for allocation by the secondary. Once the message is sent,
the primary MUST NOT use these resources for allocation to DHCPv6
clients.
Available resources can be delegated back to the primary server in
certain cases. BNDUPD will contain state FREE for leases that were
previously in FREE_BACKUP state.
The POOLREQ/POOLRESP message exchange initiated by the secondary is
valid at any time, and the primary server SHOULD, whenever it
receives the POOLREQ message, scan its database of prefixes and
determine if the secondary needs more resources from any of the
prefixes.
In order to support a reasonably dynamic balance of the resources
between the failover partners, the primary server needs to do
additional work to ensure that the secondary server has as many
resources as it needs (but that it doesn't have more than it needs).
The primary server SHOULD examine the balance of available resources
between the primary and secondary for a particular prefix whenever
the number of available resources for either the primary or secondary
changes by more than a configured limit. The primary server SHOULD
adjust the available resource balance as required to ensure the
configured resource balance, excepting that the primary server SHOULD
employ some threshold mechanism to such a balance adjustment in order
to minimize the overhead of maintaining this balance.
An example of a threshold approach is: do not attempt to re-balance
the prefixes on the primary and secondary until the out of balance
value exceeds a configured value.
The primary server can, at any time, send an available resource to
the secondary using a BNDUPD with the state BACKUP. The primary
server can attempt to take an available resource away from the
secondary by sending a BNDUPD with the state FREE. If the secondary
accepts the BNDUPD, then it is now available to the PRIMARY and not
available to the secondary. Of course, the secondary MUST reject
that BNDUPD if it has already used that resource for a DHCP client.
6.2. Independent Allocation 6.2. Independent Allocation
In this allocation scheme, available resources are split between In this allocation scheme, available resources are permanently (until
servers. Available resources are split between the primary and server configuration changes) split between servers. Available
secondary servers as part of initial connection establishment. Once resources are split between the primary and secondary servers as part
resources are allocated to each server, there is no need to reassign of initial connection establishment. Once resources are allocated to
them. This algorithm is simpler than proportional allocation since each server, there is no need to reassign them. This algorithm is
it requires similar initial communication and does not require a simpler than proportional allocation since it requires similar
rebalancing mechanism, but it assumes that the pool assigned to each initial communication, but does not require a rebalancing mechanism.
server will never deplete. That is often a reasonable assumption for It assumes that the pool assigned to each server will never deplete.
IPv6 addresses (e.g. servers are often assigned a /64 pool that That is often a reasonable assumption for IPv6 addresses (e.g.
contains many more addresses than existing electronic devices on servers are often assigned a /64 pool that contains many more
Earth). This allocation mechanism SHOULD be used for IPv6 addresses, addresses than existing electronic devices on Earth). This
unless the configured address pool is small or is otherwise allocation mechanism SHOULD be used for IPv6 addresses, unless the
administratively limited. configured address pool is small or is otherwise administratively
limited.
Once each server is assigned a resource pool during initial Once each server is assigned a resource pool during initial
connection establishment, it may allocate assigned resources to connection establishment, it may allocate assigned resources to
clients. Once a client release a resource or its lease is expired, clients. Once a client release a resource or its lease is expired,
the returned resource returns to pool for the same server. Resources the returned resource returns to pool for the server that leased it.
never changes servers. Resources never changes servers.
During COMMUNICATION-INTERRUPTED events, a partner MAY continue During COMMUNICATION-INTERRUPTED events, a partner MAY continue
extending existing leases when requested by clients. A healthy extending existing leases when requested by clients. A healthy
partner MUST NOT lease resources that were assigned to its downed partner MUST NOT lease resources that were assigned to its downed
partner and later released by a client unless it is in PARTNER-DOWN partner and later released by a client unless it is in PARTNER-DOWN
state. state. Server SHOULD use its own pool first before starting new
assignements from its downed partner's pool. As the assumption is
that independent allocation should be used only when available
resources are vast and not expected to be fully used at any given
time, it is very unlikely that the server will ever need to use its
downed partner pools.
6.3. Determining Allocation Approach 6.3. Choosing Allocation Algorithm
6.3.1. IPv6 Addresses All implementations MUST support proportional allocation algorithm
and SHOULD support independent allocation. If the implementation
implement both and let the user configure it, the default algorithm
used SHOULD be proportional allocation algorithm.
6.3.2. IPv6 Prefixes Proportional allocation mechanism is more flexible as it can
dynamically rebalance available resources between servers. That
balance includes additional burden for the servers and generates more
traffic between servers. Proportional algorithm can be considered as
managing available resources more efficiently than idenpendent. That
is important aspect when working in a network that is nearing address
and/or prefix depletion.
Independent allocation can be used when the number of available
resources are large and there is no realistic danger of running out
of resources. Use of the independent allocation makes communication
between partners simpler.
Typically indepentent allocation is used for IPv6 addresses, because
even for /64 pools a server will never run out of addresses to
assign, so there is no need to rebalance. For the prefix delegation
mechanism, available resources are much smaller, so there is a danger
of running out of addresses. Therefore typically proportional
allocation will be used for prefix delegations. Independent
allocation may be used, but the implication must be well understood.
For example in a network that delegates /64 prefixes out out /48
prefix (so there can be up to 65536 prefixes delegated) and a 1000
requesting routers, it is safe to use independent allocation.
It should be stressed out that independent allocation algorithm
SHOULD NOT be used when number of resources is limited and there is a
realistic danger of depleting resources. If this recommendation is
violated, it may lead to a case, when one server denies clients due
to pool depletion despite the fact the the other partner still have
many resources available.
7. Information model 7. Information model
In most DHCP servers a resource (an IP address or a prefix) can take In most DHCP servers a resource (an IP address or a prefix) can take
on several different binding-status values, sometimes also called on several different binding-status values, sometimes also called
lease states. While no two DHCP servers probably have exactly the lease states. While no two DHCP servers probably have exactly the
same possible binding-status values, the DHCP RFC enforces some same possible binding-status values, the DHCP RFC enforces some
commonality among the general semantics of the binding-status values commonality among the general semantics of the binding-status values
used by various DHCP server implementations. used by various DHCP server implementations.
skipping to change at page 18, line 6 skipping to change at page 20, line 14
4. Partner acknowledges state change. This transition MAY also 4. Partner acknowledges state change. This transition MAY also
occur if the server is in PARTNER-DOWN state and the MCLT has occur if the server is in PARTNER-DOWN state and the MCLT has
passed since the entry in RELEASED, EXPIRED, or RESET states. passed since the entry in RELEASED, EXPIRED, or RESET states.
5. The lease belongs to a pool that is governed by the 5. The lease belongs to a pool that is governed by the
proportional allocation, or independent allocation is used and proportional allocation, or independent allocation is used and
this lease belongs to primary server. this lease belongs to primary server.
6. The lease belongs to a pool that is governed by the 6. The lease belongs to a pool that is governed by the
independent allocation is used and the lease belongs to the independent allocation and the lease belongs to the secondary
secondary server. server.
7. Pool rebalance event occurs (POOLREQ/POOLRSP messages are 7. Pool rebalance event occurs (POOLREQ/POOLRSP messages are
exchanged). Addresses (or prefixes) belonging to the primary exchanged). Addresses (or prefixes) belonging to the primary
server can be assigned to the secondary server pool (transition server can be assigned to the secondary server pool (transition
from FREE to FREE_BACKUP) or vice versa. from FREE to FREE_BACKUP) or vice versa.
8. The lease is expired. 8. The lease is expired.
9. DECLINE message is received or a lease is deemed unusable for 9. DECLINE message is received or a lease is deemed unusable for
other reasons. other reasons.
10. An administrative action is taken to recover an abandoned 10. An administrative action is taken to recover an abandoned
lease back to usable state. This transition MAY occur due to an lease back to usable state. This transition MAY occur due to an
implementation specific handling on ABANDONED resource. One implementation specific handling on ABANDONED resource. One
possible example of such use is an Neighbor Discovery or ICMP Echo possible example of such use is a Neighbor Discovery or ICMP Echo
check if the address is still in use. check if the address is still in use.
The resource that is no longer in use (due to expiration or release), The resource that is no longer in use (due to expiration or release),
becomes FREE*. Depending of what allocation algorithm is used, the becomes FREE*. Depending of what allocation algorithm is used, the
resource that is no longer is use, returns to primary (FREE) or resource that is no longer is use, returns to primary (FREE) or
secondary pool (FREE_BACKUP). The conditions for specific secondary pool (FREE_BACKUP). The conditions for specific
transitions are depicted in Figure 2. transitions are depicted in Figure 2.
+---------------+---------+-----------+ +---------------+---------+-----------+
| \ Pool owner| | | | \ Pool owner| | |
| \-------\ | Primary | Secondary | | \-------\ | Primary | Secondary |
|Algorithm \ | | | |Algorithm \ | | |
+---------------+---------+-----------+ +---------------+---------+-----------+
| Proportional | FREE | FREE | | Proportional | FREE | FREE |
| Independent | FREE |FREE_BACKUP| | Independent | FREE |FREE_BACKUP|
+---------------+---------+-----------+ +---------------+---------+-----------+
Figure 2: FREE* State Transitions Figure 2: FREE* State Transitions
TODO: In case of Active-Passive model, while a majority of the In case of servers operating in active-passive mode, while a majority
addresses are owned by the primary server, the secondary server will of the resources are owned by the primary server, the secondary
need a portion of the addresses to serve new clients while operating server will need a portion of the resources to serve new clients
in communication-interrupted state and also in partner down state while operating in COMMUNICATION-INTERRUPTED state and also in
before it can take over the entire address pool (expiry of MCLT). PARTNER-DOWN state before it can take over the entire address pool
The concept of a percentage of pool reserved for secondary should be (after the expiry of MCLT).
described here.
The secondary server connot simply take over the entire resource pool
immediately, since we have to handle the case where both servers are
able to communicate with DHCP clients, but unable to communicate with
each other.
The size of the resource pool allocated to the secondary is specified
as a percentage of the currently available resources. Thus, as the
number of available resources changes on the primary server, the
number of resources available to the secondary server MUST also
change, although the frequency of the changes made to the secondary
server's pool of address resources SHOULD be low enough to not use
significant processing power or network bandwidth.
The required size of this private pool allocated to the secondary
server is based only on the arrival rate of new DHCP clients and the
length of expected downtime of the primary server, and is not
directly influenced by the total number of DHCP clients supported by
the server pair.
8. Failover Mechanisms 8. Failover Mechanisms
This section lays out an overview of the communication between This section lays out an overview of the communication between
partners and other mechanisms required for failover operation. As partners and other mechanisms required for failover operation. As
this is a design document, not a protocol specification, high level this is a design document, not a protocol specification, high level
ideas are presented without implementation specific details (e.g. on- ideas are presented without implementation specific details (e.g. on-
wire protocol formats). Specific protocol details are out of the wire protocol formats). Specific protocol details are out of the
scope of this document, and may be specified in a separate draft. scope of this document, and may be specified in a separate draft.
skipping to change at page 23, line 8 skipping to change at page 25, line 35
8.5. Unreachability detection 8.5. Unreachability detection
Each partner maintains an FO_SEND timer for each partner connection. Each partner maintains an FO_SEND timer for each partner connection.
The FO_SEND timer is reset every time any message is transmitted. If The FO_SEND timer is reset every time any message is transmitted. If
the timer reaches the FO_SEND_MAX value, a CONTACT message is the timer reaches the FO_SEND_MAX value, a CONTACT message is
transmitted and timer is reset. The CONTACT message may be transmitted and timer is reset. The CONTACT message may be
transmitted at any time. transmitted at any time.
8.6. Re-allocating Leases 8.6. Re-allocating Leases
TODO: Describe controlled re-allocation of released/expired leases to When in PARTNER-DOWN state there is a waiting period after which a
different clients. resource can be re-allocated to another client. For resources which
are available when the server enters PARTNER-DOWN state, the period
is the MCLT from entry into PARTNER-DOWN state. For resources which
are not available when the server enters PARTNER-DOWN state, the
period is the MCLT after the later of the following times: the
potential valid lifetime, the most recently transmitted potential
valid lifetime, the most recently received acknowledged potential
valid lifetime, and the most recently transmitted acknowledged
potential valid lifetime. If this time would be earlier than the
current time plus the MCLT, then the time the server entered PARTNER-
DOWN state plus the maximum-client-lead-time is used.
In any other state, a server cannot reallocate a resource from one
client to another without first notifying its partner (through a
BNDUPD message) and receiving acknowledgement (through a BNDACK mes-
sage) that its partner is aware that that first client is not using
the resource.
This could be modeled in the following way. Though this specific
implementation is in no way required, it may serve to better illus-
trate the concept.
An "available" resource on a server may be allocated to any client.
A resource which was leased to a client and which expired or was
released by that client would take on a new state, EXPIRED or
RELEASED respectively. The partner server would then be notified
that this resource was EXPIRED or RELEASED through a BNDUPD. When
the sending server received the BNDACK for that resource showing it
was FREE, it would move the resource from EXPIRED or RELEASED to
FREE, and it would be available for allocation by the primary server
to any clients.
A server MAY reallocate a resource in the EXPIRED or RELEASED state
to the same client with no restrictions provided it has not sent a
BNDUPD message to its partner. This situation would exist if the
lease expired or was released after the transition into PARTNER- DOWN
state, for instance.
8.7. Sending Binding Update 8.7. Sending Binding Update
This and the following section is written as though every BNDUPD This and the following section is written as though every BNDUPD
message contains only a single binding update transaction in order to message contains only a single binding update transaction in order to
reduce the complexity of the discussion. Note that while a server reduce the complexity of the discussion. Note that while a server
MAY generate BNDUPD messages with multiple binding update MAY generate BNDUPD messages with multiple binding update
transactions, every server MUST be able to process a BNDUPD message transactions, every server MUST be able to process a BNDUPD message
which contains multiple binding update transactions and generate the which contains multiple binding update transactions and generate the
corresponding BNDACK messages with status for multiple binding update corresponding BNDACK messages with status for multiple binding update
skipping to change at page 26, line 21 skipping to change at page 29, line 37
for those rules that are listed with "time" -- if a BNDUPD doesn't for those rules that are listed with "time" -- if a BNDUPD doesn't
have a client-last-transaction-time value, then it MUST NOT be have a client-last-transaction-time value, then it MUST NOT be
considered later than the client-last-transaction-time in the considered later than the client-last-transaction-time in the
receiving server's binding. If the BNDUPD contains a client-last- receiving server's binding. If the BNDUPD contains a client-last-
transaction-time value and the receiving server's binding does not, transaction-time value and the receiving server's binding does not,
then the client-last-transaction-time value in the BNDUPD MUST be then the client-last-transaction-time value in the BNDUPD MUST be
considered later than the server's. considered later than the server's.
binding-status in received BNDUPD. binding-status in received BNDUPD.
binding-status binding-status
in receiving FREE RESET in receiving FREE RESET
server ACTIVE EXPIRED RELEASED FREE_BACKUP ABANDONED server ACTIVE EXPIRED RELEASED FREE_BACKUP ABANDONED
ACTIVE accept(5) time(2) time(1) time(2) accept ACTIVE accept(5) time(2) time(1) time(2) accept
EXPIRED time(1) accept accept accept accept EXPIRED time(1) accept accept accept accept
RELEASED time(1) time(1) accept accept accept RELEASED time(1) time(1) accept accept accept
FREE/BACKUP accept accept accept accept accept FREE/FREE_BACKUP accept accept accept accept accept
RESET time(3) accept accept accept accept RESET time(3) accept accept accept accept
ABANDONED reject(4) reject(4) reject(4) reject(4) accept ABANDONED reject(4) reject(4) reject(4) reject(4) accept
Figure 3: Conflict Resolution Figure 3: Conflict Resolution
time(1): If the client-last-transaction-time in the BNDUPD is later time(1): If the client-last-transaction-time in the BNDUPD is later
than the client-last-transaction-time in the receiving server's than the client-last-transaction-time in the receiving server's
binding, accept it, else reject it. binding, accept it, else reject it.
time(2): If the current time is later than the receiving servers' time(2): If the current time is later than the receiving servers'
lease-expiration-time, accept it, else reject it. lease-expiration-time, accept it, else reject it.
time(3): If the client-last-transaction-time in the BNDUPD is later time(3): If the client-last-transaction-time in the BNDUPD is later
than the start-time-of-state in the receiving server's binding, than the start-time-of-state in the receiving server's binding,
accept it, else reject it. accept it, else reject it.
(1,2,3): If rejecting, use reject reason 15: "Outdated binding (1,2,3): If rejecting, use reject reason "Outdated binding
information". information".
(4): Use reject reason 16: "Less critical binding information". (4): Use reject reason "Less critical binding information".
(5): If the clients in a BNDUPD message and in a receiving server's (5): If the clients in a BNDUPD message and in a receiving server's
binding differ, then if the receiving server is a secondary accept binding differ, then if the receiving server is a secondary accept
it, else reject it with a reject reason of 2: "Fatal conflict exists: it, else reject it with a reject reason of "Fatal conflict exists:
address in use by other client". address in use by other client".
The lease update may be accepted or rejected. Rejection SHOULD NOT The lease update may be accepted or rejected. Rejection SHOULD NOT
change the flag in a lease that says that it should be transmitted to change the flag in a lease that says that it should be transmitted to
the failover partner. If this flag is set, then it should be the failover partner. If this flag is set, then it should be
transmitted, but if it is not already set, the rejection of a lease transmitted, but if it is not already set, the rejection of a lease
state update SHOULD NOT trigger an automatic update of the failover state update SHOULD NOT trigger an automatic update of the failover
partner sending the rejected update. The potential for update storms partner sending the rejected update. The potential for update storms
is too great, and in the unusual case where the servers simply can't is too great, and in the unusual case where the servers simply can't
agree, that disagreement is better than an update storm. agree, that disagreement is better than an update storm.
skipping to change at page 45, line 48 skipping to change at page 48, line 48
9.12. CONFLICT-DONE State 9.12. CONFLICT-DONE State
This state indicates that during the process where the two servers This state indicates that during the process where the two servers
are attempting to re-integrate with each other, the primary server are attempting to re-integrate with each other, the primary server
has received all of the updates from the secondary server. It make a has received all of the updates from the secondary server. It make a
transition into CONFLICT-DONE state in order that it may be totally transition into CONFLICT-DONE state in order that it may be totally
responsive to the client load, as opposed to NORMAL state where it responsive to the client load, as opposed to NORMAL state where it
would be in a "balanced" responsive state, running the load balancing would be in a "balanced" responsive state, running the load balancing
algorithm. algorithm.
TODO: We do not support load balancing, so CONFLICT-DONE is actually
equal to NORMAL. Need to remove CONFLICT-DONE and replace all its
references to NORMAL.
9.12.1. Operation in CONFLICT-DONE State 9.12.1. Operation in CONFLICT-DONE State
A primary server in CONFLICT-DONE state is fully responsive to all A primary server in CONFLICT-DONE state is fully responsive to all
DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED
state). state).
If communications fails, remain in CONFLICT-DONE state. If If communications fails, remain in CONFLICT-DONE state. If
communications becomes OK, remain in CONFLICT-DONE state until the communications becomes OK, remain in CONFLICT-DONE state until the
conditions for transition out become satisfied. conditions for transition out become satisfied.
skipping to change at page 47, line 16 skipping to change at page 50, line 9
equal value could theoretically work as a crude attempt to provide equal value could theoretically work as a crude attempt to provide
load balancing. It wouldn't do much good on its own, as one (faster) load balancing. It wouldn't do much good on its own, as one (faster)
server could be chosen more frequently (assuming that with equal server could be chosen more frequently (assuming that with equal
preference sets clients will pick first responding server, which is preference sets clients will pick first responding server, which is
not mandated by DHCPv6). We could design a simple mechanism of not mandated by DHCPv6). We could design a simple mechanism of
dynamically updating preference depending on usage of available dynamically updating preference depending on usage of available
resources. This concept hasn't been investigated in detail yet. resources. This concept hasn't been investigated in detail yet.
11. Dynamic DNS Considerations 11. Dynamic DNS Considerations
TODO: Describe DNS Update [RFC2136] challenges in failover DHCP servers (and clients) can use DNS Dynamic Updates as described
environment. It is nicely described in Section 5.12 of in RFC 2136 [RFC2136] to maintain DNS name-mappings as they maintain
[dhcpv4-failover]. DHCP leases. Many different administrative models for DHCP-DNS
integration are possible. Descriptions of several of these models,
and guidelines that DHCP servers and clients should follow in
carrying them out, are laid out in RFC 4704 [RFC4704].
12. Reservations and failover The nature of the failover protocol introduces some issues concerning
dynamic DNS updates that are not part of non-failover environments.
This section describes these issues, and defines the information
which failover partners should exchange in order to ensure consistent
behavior. The presence of this section should not be interpreted as
requiring an implementation of the DHCPv6 failover protocol to also
support DDNS updates.
TODO: Describe how lease reservation works with failover. See The purpose of this discussion is to clarify the areas where the
Section 5.13 in [dhcpv4-failover]. failover and DHCP-DDNS protocols intersect for the benefit of
implementations which support both protocols, not to introduce a new
requirement into the DHCPv6 failover protocol. Thus, a DHCPv6 server
which implements the failover protocol MAY also support dynamic DNS
updates, but if it does support dynamic DNS updates it SHOULD utilize
the techniques described here in order to correctly distribute them
between the failover partners. See RFC 4704 [RFC4704] as well as RFC
4703 [RFC4703] for information on how DHCPv6 servers deal with
potential conflicts when updating DNS even without failover.
13. Protocol entities From the standpoint of the failover protocol, there is no reason why
a server which is utilizing the DDNS protocol to update a DNS server
should not be a partner with a server which is not utilizing the DDNS
protocol to update a DNS server. However, a server which is not able
to support DDNS or is not configured to support DDNS SHOULD output a
warning message when it receives BNDUPD messages which indicate that
its failover partner is configured to support the DDNS protocol to
update a DNS server. An implementation MAY consider this an error
and refuse to operate, or it MAY choose to operate anyway, having
warned the user of the problem in some way.
Discussion: It is unclear if following sections belong to design or 11.1. Relationship between failover and dynamic DNS update
protocol draft. It is currently kept here as a scratchbook with list
of things that will have to be defined eventually. Whether or not it
will stay in this document or will be moved to the protocol spec
document is TBD.
13.1. Failover Protocol The failover protocol describes the conditions under which each
failover server may renew a lease to its current DHCP client, and
describes the conditions under which it may grant a lease to a new
DHCP client. An analogous set of conditions determines when a
failover server should initiate a DDNS update, and when it should
attempt to remove records from the DNS. The failover protocol's
conditions are based on the desired external behavior: avoiding
duplicate address and prefix assignments; allowing clients to
continue using leases which they obtained from one failover partner
even if they can only communicate with the other partner; allowing
the secondary DHCP server to grant new leases even if it is unable to
communicate with the primary server. The desired external DDNS
behavior for DHCP failover servers is similar to that described above
for the failover protocol itself:
This section enumerates list of options that will be defined in 1. Allow timely DDNS updates from the server which grants a lease to
failover protocol specification. Rough description of purpose and a client. Recognize that there is often a DDNS update lifecycle
content for each option is specified. Exact on wire format will be which parallels the DHCP lease lifecycle. This is likely to
defined in protocol specification. include the addition of records when the lease is granted, and
the removal of DNS records when the leased resource is
subsequently made available for allocation to a different client.
1. OPTION_FO_TIMESTAMP - convey information about timestamp. It is 2. Communicate enough information between the two failover servers
used by time skew measurement algorithm (see Section 8.1). to allow one to complete the DDNS update 'lifecycle' even if the
other server originally granted the lease.
13.2. Protocol constants 3. Avoid redundant or overlapping DDNS updates, where both failover
servers are attempting to perform DDNS updates for the same
lease-client binding.
This section enumerates various constants that have to be defined in 4. Avoid situations where one partner is attempting to add RRs
actual protocol specification. related to a lease binding while the other partner is attempting
to remove RRs related to the same lease binding.
1. TIME_SKEW_PKTS_AVG - number of packets that are used to calculate While DHCP servers configured for DDNS typically perform these
average time skew between partners. See (see Section 8.1). operations on both the AAAA and the PTR resource records, this is not
required. It is entirely possible that a DHCP server could be
configured to only update the DNS with PTR records, and the DHCPv6
clients could be responsible for updating the DNS with their own AAAA
records. In this case, the discussions here would apply only to the
PTR records.
14. Open questions 11.2. Exchanging DDNS Information
This is scratchbook. This section will be removed once questions are In order for either server to be able to complete a DDNS update, or
answered. to remove DNS records which were added by its partner, both servers
need to know the FQDN associated with the lease-client binding. In
addition, to properly handle DDNS updates, additional information is
required. All of the following information needs to be transmitted
between the failover partners:
Q: Do we want to support temporary addresses? I think not. They are 1. The FQDN that the client requested be associated with the
short-lived by definition, so clients should not mind getting new resource. If the client doesn't request a particular FQDN and
temporary addresses. one is synthesized by the failover server or if the failover
server is configured to replace a client requested FQDN with a
different FQDN, then the server generated value would be used.
Q: Do we want to support CGA-registered addresses? There is 2. The FQDN that was actually placed in the DNS for this lease. It
currently work in DHC WG about this, but I haven't looked at it yet. may differ from the client requested FQDN due to some form of
If that is complicated, we may not define it here, but rather as an disambiguation or other DHCP server configuration (as described
extension. [If it moves forward, we need to support it.] above).
15. Security Considerations 3. The status of and DDNS operations in progress or completed.
TODO: Security considerations section will contain loose notes and 4. Information sufficient to allow the failover partner to remove
will be transformed into consistent text once the core design the FQDN from the DNS should that become necessary.
solidifies.
16. IANA Considerations These data items are the minimum necessary set to reliably allow two
failover partners to successfully share the responsibility to keep
the DNS up to date with the resources allocated to clients.
This information would typically be included in BNDUPD messages sent
from one failover partner to the other. Failover servers MAY choose
not to include this information in BNDUPD messages if there has been
no change in the status of any DDNS update related to the lease.
The partner server receiving BNDUPD messages containing the DDNS
information SHOULD compare the status informatin and the FQDN with
the current DDNS information it has associated with the lease
binding, and update its notion of the DDNS status accordingly.
Some implementations will instead choose to send a BNDUPD without
waiting for the DDNS update to complete, and then will send a second
BNDUPD once the DDNS update is complete. Other implementations will
delay sending the partner a BNDUPD until the DDNS update has been
acknowledged by the DNS server, or until some time-limit has elapsed,
in order to avoid sending a second BNDUPD.
The FQDN option contains the FQDN that will be associated with the
AAAA RR (if the server is performing an AAAA RR update for the
client). The PTR RR can be generated automatically from the IP
address or prefix value. The FQDN may be composed in any of several
ways, depending on server configuration and the information provided
by the client in its DHCP messages. The client may supply a hostname
which it would like the server to use in forming the FQDN, or it may
supply the entire FQDN. The server may be configured to attempt to
use the information the client supplies, it may be configured with an
FQDN to use for the client, or it may be configured to synthesize an
FQDN.
Since the server interacting with the client may not have completed
the DDNS update at the time it sends the first BNDUPD about the lease
binding, there may be cases where the FQDN in later BNDUPD messages
does not match the FQDN included in earlier messages. For example,
the responsive server may be configured to handle situations where
two or more DHCP client FQDNs are identical by modifying the most-
specific label in the FQDNs of some of the clients in an attempt to
generate unique FQDNs for them (a process sometimes called
"disambiguation"). Alternatively, at sites which use some or all of
the information which clients supply to form the FQDN, it's possible
that a client's configuration may be changed so that it begins to
supply new data. The server interacting with the client may react by
removing the DNS records which it originally added for the client,
and replacing them with records that refer to the client's new FQDN.
In such cases, the server SHOULD include the actual FQDN that was
used in subsequent DDNS options in any BNDUPD messages exchanged
between the failover partners. This server SHOULD include relevant
information in its BNDUPD messages. This information may be
necessary in order to allow the non-responsive partner to detect
client configuration changes that change the hostname or FQDN data
which the client includes in its DHCP requests.
11.3. Adding RRs to the DNS
A failover server which is going to perform DDNS updates SHOULD
initiate the DDNS update when it grants a new lease to a client. The
server which did not grant the lease SHOULD NOT initiate a DDNS
update when it receives the BNDUPD after the lease has been granted.
The failover protocol ensures that only one of the partners will
grant a lease to any individual client, so it follows that this
requirement will prevent both partners from initiating updates
simultaneously. The server initiating the update SHOULD follow the
protocol in RFC 4704 [RFC4704]. The server may be configured to
perform a AAAA RR update on behalf of its clients, or not.
Ordinarily, a failover server will not initiate DDNS updates when it
renews leases. In two cases, however, a failover server MAY initiate
a DDNS update when it renews a lease to its existing client:
1. When the lease was granted before the server was configured to
perform DDNS updates, the server MAY be configured to perform
updates when it next renews existing leases. The server which
granted the lease is the server which should initiate the DDNS
update.
2. If a server is in PARTNER-DOWN state, it can conclude that its
partner is no longer attempting to perform an update for the
existing client. If the remaining server has not recorded that
an update for the binding has been successfully completed, the
server MAY initiate a DDNS update. It MAY initiate this update
immediately upon entry to PARTNER-DOWN state, it may perform this
in the background, or it MAY initiate this update upon next
hearing from the DHCP client.
11.4. Deleting RRs from the DNS
The failover server which makes a resource FREE SHOULD initiate any
DDNS deletes, if it has recorded that DNS records were added on
behalf of the client.
A server not in PARTNER-DOWN state "makes a resource FREE" when it
initiates a BNDUPD with a binding-status of FREE, FREE_BACKUP,
EXPIRED, or RELEASED. Its partner confirms this status by acking
that BNDUPD, and upon receipt of the BNDACK the server has "made the
resource FREE". Conversely, a server in PARTNER-DOWN state "makes a
resource FREE" when it sets the binding-status to FREE, since in
PARTNER-DOWN state no communications is required with the partner.
It is at this point that it should initiate the DDNS operations to
delete RRs from the DDNS. Its partner SHOULD NOT initiate DDNS
deletes for DNS records related to the lease binding as part of
sending the BNDACK message. The partner MAY have issued BNDUPD
messages with a binding-status of FREE, EXPIRED, or RELEASED
previously, but the other server will have rejected these BNDUPD
messages.
The failover protocol ensures that only one of the two partner
servers will be able to make a resource FREE. The server making the
resource FREE may be doing so while it is in NORMAL communication
with its partner, or it may be in PARTNER-DOWN state. If a server is
in PARTNER-DOWN state, it may be performing DDNS deletes for RRs
which its partner added originally. This allows a single remaining
partner server to assume responsibility for all of the DDNS activity
which the two servers were undertaking.
Another implication of this approach is that no DDNS RR deletes will
be performed while either server is in COMMUNICATIONS-INTERRUPTED
state, since no resource are moved into the FREE state during that
period.
11.5. Name Assignment with No Update of DNS
In some cases, a DHCP server is configured to return a name to the
DHCPv6 client but not enter that name into the DNS. This is
typically a name that it has discovered or generated from information
it has received from the client. In this case this name information
SHOULD be communicated to the failover partner, if only to ensure
that they will return the same name in the event the partner becomes
the server to which the DHCPv6 client begins to interact.
12. Reservations and failover
Some DHCP servers support a capability to offer specific
preconfigured resources to DHCP clients. These are real DHCP
clients, they do the entire DHCP protocol, but these servers always
offer the client a specific pre-configured resource, one they offer
that resource to no other clients. Such a capability has several
names, but it is sometimes called a "reservation", in that the
resource is reserved for a particular DHCP client.
In a situation where there are two DHCP servers serving the same
subnet without using failover, the two DHCP server's need to have
disjoint resource pools, but identical reservations for the DHCP
clients.
In a failover context, both servers need to be configured with the
proper reservations in an identical manner, but if we stop there
problems can occur around the edge conditions where reservations are
made for resource that has already been leased to a different client.
Different servers handle this conflict in different ways, but the
goal of the failover protocol is to allow correct operation with any
server's approach to the normal processing of the DHCP protocol.
The general solution with regards to reservations is as follows.
Whenever a reserved resource becomes FREE (i.e., when first
configured or whenever a client frees it or it expires or is reset),
the primary server MUST show that resource as FREE (and thus
available for its own allocation) and it MUST send it to the
secondary server in a BNDUPD with a flag set showing that it is
reserved and with a status of BACKUP.
Note that this implies that a reserved resource goes through the
normal state changes from FREE to ACTIVE (and possibly back to FREE).
The failover protocol supports this approach to reservations, i.e.,
where the resource undergoes the normal state changes of any
resource, but it can only be offered to the client for which it is
reserved.
From the above, it follows that a reservation soley on the secondary
will not necessarily allow the secondary to offer that address to
client to whom it is reserved. The reservation must also appear on
the primary as well for the secondary to be able to offer the
resource to the client to which is is reserved.
When the reservation on a resource is cancelled, if the resource is
currently FREE and the server is the primary, or BACKUP and the
server is the secondary, the server MUST send a BNDUPD to the other
server with the binding-status FREE and an indication that the
resource is no longer reserved.
13. Security Considerations
DHCPv6 failover is an extension of a standard DHCPv6 protocol, so all
security considerations from [RFC3315], Section 23 and [RFC3633],
Section 15 related to the server apply.
As traffic exchange between clients and server is not encrypted, an
attacker than penetrated the network and is able to intercept
traffic, will not gain anything by also sniffing communication
between partners.
An attacker that can impersonate one partner can efficiently perform
a denial of service attack on the remaining uncompromised server.
Several techniques may be used: pretending that conflict resolution
is required, requesting rebalance, claming that a valid lease was
released or declined etc. For that reason the communication between
servers SHOULD support failover connections over TLS, as explained in
Section Section 5.1. Such secure connection SHOULD be optional and
configurable by the administrator.
TODO: Security considerations section contains loose notes and will
be transformed into consistent text once the core design solidifies.
14. IANA Considerations
IANA is not requested to perform any actions at this time. IANA is not requested to perform any actions at this time.
17. Acknowledgements 15. Acknowledgements
This document extensively uses concepts, definitions and other parts This document extensively uses concepts, definitions and other parts
of [dhcpv4-failover] document. Authors would like to thank Shawn of [dhcpv4-failover] document. Authors would like to thank Shawn
Routher, Greg Rabil, and Bernie Volz for their significant Routher, Greg Rabil, and Bernie Volz for their significant
involvement and contributions. Authors would like to thank involvement and contributions. Authors would like to thank
VithalPrasad Gaitonde for his insightful comments. VithalPrasad Gaitonde for his insightful comments.
This work has been partially supported by Department of Computer This work has been partially supported by Department of Computer
Communications (a division of Gdansk University of Technology) and Communications (a division of Gdansk University of Technology) and
the Polish Ministry of Science and Higher Education under the the Polish Ministry of Science and Higher Education under the
European Regional Development Fund, Grant No. POIG.01.01.02-00-045/ European Regional Development Fund, Grant No. POIG.01.01.02-00-045/
09-00 (Future Internet Engineering Project). 09-00 (Future Internet Engineering Project).
18. References 16. References
18.1. Normative References
16.1. Normative References
[I-D.ietf-dhc-dhcpv6-client-link-layer-addr-opt] [I-D.ietf-dhc-dhcpv6-client-link-layer-addr-opt]
Halwasia, G., Systems, C., and W. Dec, "Client Link-layer Halwasia, G., Systems, C., and W. Dec, "Client Link-layer
Address Option in DHCPv6", Address Option in DHCPv6",
draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01 (work draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-03 (work
in progress), August 2012. in progress), October 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified
Domain Name (FQDN) Conflicts among Dynamic Host
Configuration Protocol (DHCP) Clients", RFC 4703,
October 2006.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006. Option", RFC 4704, October 2006.
18.2. Informative References 16.2. Informative References
[I-D.ietf-dhc-dhcpv6-failover-requirements] [I-D.ietf-dhc-dhcpv6-failover-requirements]
Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
Requirements", Requirements",
draft-ietf-dhc-dhcpv6-failover-requirements-01 (work in draft-ietf-dhc-dhcpv6-failover-requirements-02 (work in
progress), July 2012. progress), September 2012.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649, (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
August 2006. August 2006.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007. "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
February 2009. February 2009.
 End of changes. 54 change blocks. 
181 lines changed or deleted 601 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/