draft-ietf-dhc-dhcpv6-failover-design-03.txt   draft-ietf-dhc-dhcpv6-failover-design-04.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: January 16, 2014 Cisco Expires: March 17, 2014 Cisco
July 15, 2013 September 13, 2013
DHCPv6 Failover Design DHCPv6 Failover Design
draft-ietf-dhc-dhcpv6-failover-design-03 draft-ietf-dhc-dhcpv6-failover-design-04
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 a 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
specified in [I-D.ietf-dhc-dhcpv6-failover-requirements]. A protocol specified in [I-D.ietf-dhc-dhcpv6-failover-requirements]. A protocol
specification document is planned to follow this document. specification document is planned to follow this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 16, 2014. This Internet-Draft will expire on March 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Design Requirements . . . . . . . . . . . . . . . . . . . 6 3.1. Design 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 . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Failover State Machine Overview . . . . . . . . . . . . . 8 4.1. Failover State Machine Overview . . . . . . . . . . . . . 8
4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Connection Management . . . . . . . . . . . . . . . . . . . . 11 5. Connection Management . . . . . . . . . . . . . . . . . . . . 12
5.1. Creating Connections . . . . . . . . . . . . . . . . . . 11 5.1. Creating Connections . . . . . . . . . . . . . . . . . . 12
5.2. Endpoint Identification . . . . . . . . . . . . . . . . . 13 5.2. Endpoint Identification . . . . . . . . . . . . . . . . . 13
6. Resource Allocation . . . . . . . . . . . . . . . . . . . . . 13 6. Resource Allocation . . . . . . . . . . . . . . . . . . . . . 14
6.1. Proportional Allocation . . . . . . . . . . . . . . . . . 14 6.1. Proportional Allocation . . . . . . . . . . . . . . . . . 14
6.2. Independent Allocation . . . . . . . . . . . . . . . . . 16 6.2. Independent Allocation . . . . . . . . . . . . . . . . . 17
6.3. Choosing Allocation Algorithm . . . . . . . . . . . . . . 17 6.3. Choosing Allocation Algorithm . . . . . . . . . . . . . . 17
7. Information model . . . . . . . . . . . . . . . . . . . . . . 18 7. Information model . . . . . . . . . . . . . . . . . . . . . . 18
8. Failover Mechanisms . . . . . . . . . . . . . . . . . . . . . 22 8. Failover Mechanisms . . . . . . . . . . . . . . . . . . . . . 23
8.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. Time expression . . . . . . . . . . . . . . . . . . . . . 23 8.2. Lazy updates . . . . . . . . . . . . . . . . . . . . . . 23
8.3. Lazy updates . . . . . . . . . . . . . . . . . . . . . . 23 8.3. MCLT concept . . . . . . . . . . . . . . . . . . . . . . 24
8.4. MCLT concept . . . . . . . . . . . . . . . . . . . . . . 23 8.3.1. MCLT example . . . . . . . . . . . . . . . . . . . . 25
8.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . 25 8.4. Unreachability detection . . . . . . . . . . . . . . . . 26
8.5. Unreachability detection . . . . . . . . . . . . . . . . 26 8.5. Re-allocating Leases . . . . . . . . . . . . . . . . . . 27
8.6. Re-allocating Leases . . . . . . . . . . . . . . . . . . 26 8.6. Sending Binding Update . . . . . . . . . . . . . . . . . 28
8.7. Sending Binding Update . . . . . . . . . . . . . . . . . 27 8.7. Receiving Binding Update . . . . . . . . . . . . . . . . 29
8.8. Receiving Binding Update . . . . . . . . . . . . . . . . 29 8.8. Conflict Resolution . . . . . . . . . . . . . . . . . . . 30
8.9. Conflict Resolution . . . . . . . . . . . . . . . . . . . 30 8.9. Acknowledging Reception . . . . . . . . . . . . . . . . . 32
8.10. Acknowledging Reception . . . . . . . . . . . . . . . . . 32
9. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 32 9. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. State Machine Operation . . . . . . . . . . . . . . . . . 32 9.1. State Machine Operation . . . . . . . . . . . . . . . . . 32
9.2. State Machine Initialization . . . . . . . . . . . . . . 35 9.2. State Machine Initialization . . . . . . . . . . . . . . 35
9.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 35 9.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 35
9.3.1. Operation in STARTUP State . . . . . . . . . . . . . 36 9.3.1. Operation in STARTUP State . . . . . . . . . . . . . 36
9.3.2. Transition Out of STARTUP State . . . . . . . . . . . 36 9.3.2. Transition Out of STARTUP State . . . . . . . . . . . 36
9.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 38 9.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 38
9.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 38 9.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 38
9.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 39 9.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 39
9.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 40 9.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 39
9.5.1. Operation in RECOVER State . . . . . . . . . . . . . 40 9.5.1. Operation in RECOVER State . . . . . . . . . . . . . 39
9.5.2. Transition Out of RECOVER State . . . . . . . . . . . 40 9.5.2. Transition Out of RECOVER State . . . . . . . . . . . 40
9.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 41 9.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 41
9.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 41 9.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 41
9.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 42 9.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 41
9.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 42 9.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 42
9.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 42 9.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 42
9.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 42 9.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 42
9.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 43 9.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 43
9.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 43 9.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 43
9.8.2. Transition Out of NORMAL State . . . . . . . . . . . 44 9.8.2. Transition Out of NORMAL State . . . . . . . . . . . 44
9.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 44 9.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 44
9.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 45 9.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 45
9.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 45 9.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 45
9.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 47 9.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 47
9.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 47 9.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 47
9.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 47 9.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 47
9.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 49 9.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 48
9.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 49 9.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 49
9.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 49 9.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 49
9.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 49 9.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 49
9.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 50 9.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 49
9.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 50 9.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 50
10. Proposed extensions . . . . . . . . . . . . . . . . . . . . . 50 10. Proposed extensions . . . . . . . . . . . . . . . . . . . . . 50
10.1. Active-active mode . . . . . . . . . . . . . . . . . . . 50 10.1. Active-active mode . . . . . . . . . . . . . . . . . . . 50
11. Dynamic DNS Considerations . . . . . . . . . . . . . . . . . 51 11. Dynamic DNS Considerations . . . . . . . . . . . . . . . . . 50
11.1. Relationship between failover and dynamic DNS update . . 51 11.1. Relationship between failover and dynamic DNS update . . 51
11.2. Exchanging DDNS Information . . . . . . . . . . . . . . 52 11.2. Exchanging DDNS Information . . . . . . . . . . . . . . 52
11.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . 54 11.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . 54
11.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . 55 11.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . 54
11.5. Name Assignment with No Update of DNS . . . . . . . . . 55 11.5. Name Assignment with No Update of DNS . . . . . . . . . 55
12. Reservations and failover . . . . . . . . . . . . . . . . . . 56 12. Reservations and failover . . . . . . . . . . . . . . . . . . 55
13. Security Considerations . . . . . . . . . . . . . . . . . . . 57 13. Security Considerations . . . . . . . . . . . . . . . . . . . 57
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
16.1. Normative References . . . . . . . . . . . . . . . . . . 58 16.1. Normative References . . . . . . . . . . . . . . . . . . 58
16.2. Informative References . . . . . . . . . . . . . . . . . 58 16.2. Informative References . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
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].
skipping to change at page 4, line 4 skipping to change at page 4, line 6
16.2. Informative References . . . . . . . . . . . . . . . . . 58 16.2. Informative References . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
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
definitions in Section 3 of definitions in Section 3 of
[I-D.ietf-dhc-dhcpv6-failover-requirements]. [I-D.ietf-dhc-dhcpv6-failover-requirements].
o auto-partner-down - a capability where a failover server will move o auto-partner-down - a capability where a failover server will move
from COMMUNICATIONS-INTERRUPTED state to PARTNER-DOWN state from COMMUNICATIONS-INTERRUPTED state to PARTNER-DOWN state
automatically, without operator intervention. automatically, without operator intervention.
o DDNS - Dynamic DNS. Typically used as an acronym referring to
dynamic update of the DNS.
o Failover endpoint - The failover protocol allows for there to be a o Failover endpoint - The failover protocol allows for there to be a
unique failover 'endpoint' for each failover relationship in which unique failover 'endpoint' for each failover relationship in which
a failover server participates. The failover relationship is a failover server participates. The failover relationship is
defined by a relationship name, and includes the failover partner defined by a relationship name, and includes the failover partner
IP address, the role this server takes with respect to that IP address, the role this server takes with respect to that
partner (primary or secondary), and the prefixes associated with partner (primary or secondary), and the prefixes associated with
that relationship. Note that a single prefix can only be that relationship. Note that a single prefix can only be
associated with a single failover relationship. This failover associated with a single failover relationship. This failover
endpoint can take actions and hold unique states. Typically, endpoint can take actions and hold unique states. Typically,
there is one failover endpoint per partner (server), although there is one failover endpoint per partner (server), although
skipping to change at page 4, line 36 skipping to change at page 4, line 42
unless to do so would be confusing. unless to do so would be confusing.
o Failover communication - all messages exchanged between partners. o Failover communication - all messages exchanged between partners.
o Independent Allocation - an allocation algorithm that splits the o Independent Allocation - an allocation algorithm that splits the
available pool of resources between the primary and secondary 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 Lease - an association of a DHCPv6 client with an IPv6 address or
delegated prefix.
o Partner - name of the other DHCPv6 server that participates in o Partner - name of the other DHCPv6 server that participates in
failover relationship. When the role (primary or secondary) is failover relationship. When the role (primary or secondary) is
not important, the other server is referred to as a "failover not important, the other server is referred to as a "failover
partner" or simply partner. partner" or simply partner.
o Primary Server - First out of two DHCPv6 servers that participate o Primary Server - First out of two DHCPv6 servers that participate
in a failover relationship. In active-passive mode this is the in a failover relationship. In active-passive mode this is the
server that handles most of the client traffic. Its failover server that handles most of the client traffic. Its failover
partner is referred to as secondary server. partner is referred to as secondary server.
o Proportional Allocation - an allocation algorithm that splits the o Proportional Allocation - an allocation algorithm that splits the
available resources (addresses or prefixes) between the primary available resources between the primary and secondary servers and
and secondary servers and maintains proportions between available maintains proportions between available resources on both. It is
resources on both. It is particularly well suited for more particularly well suited for more limited resources. See
limited resources. See Section 6.1 for details. Section 6.1 for details.
o Resource - Any type of resource that is managed by DHCPv6. o Resource - Any type of resource that is managed by DHCPv6.
Currently there are two types of such resources defined: a non- Currently there are three types of such resources defined: a non-
temporary IPv6 address and an IPv6 prefix. Due to the nature of temporary IPv6 address, a temporary IPv6 address, and an IPv6
temporary addresses, they are not covered by the failover prefix. 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 - Second of out two DHCPv6 servers that o Secondary Server - Second of two DHCPv6 servers that participate
participate in a failover relationship. Its failover partner is in a failover relationship. Its failover partner is referred to
referred to as primary server. In active-passive mode this server as the primary server. In active-passive mode this server (the
typically does not handle client traffic and acts as a backup. secondary) 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
The failover protocol design provides a means for cooperating DHCPv6 The failover protocol design provides a means for cooperating DHCPv6
servers to work together to provide a DHCPv6 service with servers to work together to provide a DHCPv6 service with
availability that is increased beyond that which could be provided by availability that is increased beyond that which could be provided by
a single DHCPv6 server operating alone. It is designed to protect a single DHCPv6 server operating alone. It is designed to protect
DHCPv6 clients against server unreachability, including server DHCPv6 clients against server unreachability, including server
failure and network partition. It is possible to deploy exactly two failure and network partition. It is possible to deploy exactly two
servers that are able to continue providing a lease on an IPv6 servers that are able to continue providing a lease on an IPv6
address [RFC3315] or on an IPv6 prefix [RFC3633] without the DHCPv6 address [RFC3315] or on an IPv6 prefix [RFC3633] without the DHCPv6
client experiencing lease expiration or a reassignment of a lease to client experiencing lease expiration or a reassignment of a lease to
a different IPv6 address in the event of failure by one or the other a different IPv6 address (or prefix) in the event of failure by one
of the two servers. or the other of the two servers.
This protocol defines active-passive mode, sometimes also called a This protocol defines active-passive mode, sometimes also called a
hot standby model. This means that during normal operation one hot standby model. This means that during normal operation one
server is active (i.e. actively responds to clients' requests) while server is active (i.e. actively responds to clients' requests) while
the second is passive (i.e. it does receive clients' requests, but the second is passive (i.e. it does receive clients' requests, but
does not respond to them and only maintains a copy of lease database does not respond to them and only maintains a copy of lease database
and is ready to take over incoming queries in case of primary server and is ready to take over incoming queries in case of primary server
failure). Active-active mode (i.e. both servers actively handling failure). Active-active mode (i.e. both servers actively handling
clients' requests) is currently not supported for the sake of clients' requests) is currently not supported for the sake of
simplicity. Such a mode is likely to be defined as an exension at a simplicity. Such a mode is likely to be defined as an extension at a
later time and will probably be based on later time and will probably be based on
[I-D.ietf-dhc-dhcpv6-load-balancing]. [I-D.ietf-dhc-dhcpv6-load-balancing].
The failover protocol is designed to provide lease stability for The failover protocol is designed to provide lease stability for
leases with lease times beyond a short period. Due in part to the leases with lease times beyond a short period. Due in part to the
additional overhead required as well as requirements to handle time additional overhead required as well as requirements to handle time
skew between failover partners (See Section 8.1), failover is not skew between failover partners (See Section 8.1), failover is not
suitable for leases shorter than 30 seconds. The DHCPv6 Failover suitable for leases shorter than 30 seconds. The DHCPv6 Failover
protocol MUST NOT be used for leases shorter than 30 seconds. protocol MUST NOT be used for leases shorter than 30 seconds.
This design attempts to fulfill all DHCPv6 failover requirements This design attempts to fulfill all DHCPv6 failover requirements
defined in [I-D.ietf-dhc-dhcpv6-failover-requirements]. defined in [I-D.ietf-dhc-dhcpv6-failover-requirements].
3.1. Design Requirements 3.1. Design Requirements
The following requirements are not related to failover mechanism in The following requirements are not related to failover the mechanism
general, but rather to this particular design. in general, but rather to this particular design.
1. Minimize Asymmetry - while there are two distinct roles in 1. Minimize Asymmetry - while there are two distinct roles in
failover (primary and secondary server), the differences between failover (primary and secondary server), the differences between
those two roles should be as small as possible. This will yield those two roles should be as small as possible. This will yield
a simpler design as well as a simpler implementation of that a simpler design as well as a simpler implementation of that
design. design.
3.2. Features out of Scope: Load Balancing 3.2. Features out of Scope: Load Balancing
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 the
that each server must be able to handle whole traffic. Therefore in conclusion that each server must be able to handle all of the
properly provisioned setup, load balancing is not needed. traffic. Therefore in properly provisioned setup, load balancing is
not needed.
It is likely that active-active mode that is essentially a load It is likely that active-active mode that is essentially a load
balancing will be defined as an extension in the near future. 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,
following format defined in Section 22.1 of [RFC3315]. following the format defined in Section 22.1 of [RFC3315].
After initialization, the primary server establishes a TCP connection After initialization, the primary server establishes a TCP connection
with its partner. The primary server sends a CONNECT message with with its partner. The primary server sends a CONNECT message with
initial parameters. Secondary server responds with CONNECTACK. initial parameters. Secondary server responds with CONNECTACK.
If the primary server cannot immediately establish a connection with If the primary server cannot immediately establish a connection with
its partner, it will continue to attempt to establish a connection. its partner, it will continue to attempt to establish a connection.
See Section 5.1 for details. See Section 5.1 for details.
Depending on the failover state of each partner, they MUST initiate Depending on the failover state of each partner, they MUST initiate
one of the binding update procedures. Each server MAY send an UPDREQ one of the binding update procedures. Each server MAY send an UPDREQ
message to request its partner to send all updates that have not been message to request its partner to send all updates that have not been
sent yet (this case applies when the partner has an existing database sent yet (this case applies when the partner has an existing database
and wants to update it). Alternatively, a server MAY choose to send and wants to update it). Alternatively, a server MAY choose to send
an UPDREQALL message to request a full lease database transmission an UPDREQALL message to request a full lease database transmission
including all leases (this case applies in case of booting up new including all leases (this case applies in case of booting up a new
server after installation, corruption or complete loss of database, server after installation, corruption or complete loss of database,
or other catastrophic failure). or other catastrophic failure).
Servers exchange lease information by using BNDUPD messages. Servers exchange lease information by using BNDUPD messages.
Depending on the local and remote state of a lease, a server may Depending on the local and remote state of a lease, a server may
either accept or reject the update. Reception of lease update either accept or reject the update. Reception of lease update
information is confirmed by responding with a BNDACK message with information is confirmed by responding with a BNDACK message with
appropriate status. The majority of the messages sent over a appropriate status. The majority of the messages sent over a
failover TCP connection consists of BNDUPD and BNDACK messages. failover TCP connection consists of BNDUPD and BNDACK messages.
A subset of available resources (addresses or prefixes) is reserved A subset of available resources (addresses or prefixes) is reserved
for secondary server use. This is required for handling a case where for secondary server use. This is required for handling a case where
both servers are able to communicate with clients, but unable to both servers are able to communicate with clients, but unable to
communicate with each other. After the initial connection is communicate with each other. After the initial connection is
established, the secondary server requests a pool of available established, the secondary server requests a pool of available
addresses by sending a POOLREQ message. The primary server assigns addresses or prefixes by sending a POOLREQ message. The primary
addresses to the secondary by sending a series of BNDUPD messages. server assigns addresses or prefixes to the secondary by sending a
When this process is complete, the primary server sends a POOLRESP series of BNDUPD messages. When this process is complete, the
message to the secondary server. The secondary server may initiate primary server sends a POOLRESP message to the secondary server. The
such pool request at any time when in communication with primary secondary server may initiate such pool request at any time when in
server. communication with primary server.
Failover servers use a lazy update mechanism to update their failover Failover servers use a lazy update mechanism to update their failover
partner about changes to their lease state database. After a server partner about changes to their lease state database. After a server
performs any modifications to its lease state database (assign a new performs any modifications to its lease state database (assign a new
lease, extend, release or expire existing lease), it sends its lease, extend, release or expire existing lease), it sends its
response to the client's request first (performing the "regular" 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 a lazy update mechanism is when the server
server crashes after sending a response to client, but before sending crashes after sending a response to client, but before sending the
the lazy update to its partner (or when communication between lazy update to its partner (or when communication between partners is
partners is interrupted). To solve this problem, the concept known interrupted). To solve this problem, the concept known as the
as the Maximum Client Lead Time (initially designed for DHCPv4 Maximum Client Lead Time (initially designed for DHCPv4 failover) is
failover) is used. The MCLT is the maximum amount of time that one used. The MCLT is the maximum amount of time that one server can
server can extend a lease for a client's binding beyond the time extend a lease for a client's binding beyond the time known by its
known by its failover partner. See Section 8.4 for detailed failover partner. See Section 8.3 for a detailed description how the
desciption how the MCLT affects assigned lease times. MCLT affects assigned lifetimes.
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.4 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 State Machine 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 a 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. Depending on
a server may be either responsive (responds to clients' queries) or its current state a server may be either responsive (responds to
unresponsive (clients' queries are ignored). clients' queries) or unresponsive (clients' queries are ignored).
A server starts its operation in short-lived STARTUP state. A server A server starts its operation in the short-lived STARTUP state. A
determines its partner reachability and state and sets its own state server determines its partner reachability and state and sets its own
based on that determination. It typically returns back to the state state based on that determination. It typically returns back to the
it was in before shutdown, though the details can be complicated. state it was in before shutdown, though the details can be
See Section 9.3.2. complicated. See Section 9.3.2.
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 is unresponsive. clients' requests. The secondary server is unresponsive.
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
cautious as it can't distingush if its partner is down or just cautious as it can't distinguish if its partner is down or just
communication between servers is interrupted. Since communication communication between servers is interrupted. Since communication
between partners is not possible, a server must act on the assumtion between partners is not possible, a server must act on the assumption
that its partner is up. A failover server must follow a defined that its partner is up. A failover server must follow a defined
procedure, in particular, it MUST NOT extend any lease more than the procedure, in particular, it MUST NOT extend any lease more than the
MCLT beyond its partner's knowledge of the lease expiration time. MCLT beyond its partner's knowledge of the lease expiration time.
This imposes an additional burden on the server, in that clients will This imposes an additional burden on the server, in that clients will
return to the server for lease renewals more frequently than they return to the server for lease renewals more frequently than they
would otherwise. Therefore it is not recommended to operate for would otherwise. Therefore it is not recommended to operate for
prolonged periods in this state. Once communication is prolonged periods in this state. Once communication is
reestablished, a server may go into NORMAL, POTENTIAL-CONFLICT or reestablished, a server may go into NORMAL, POTENTIAL-CONFLICT or
PARTNER-DOWN state. It may also stay in COMMUNICATIONS-INTERRUPTED PARTNER-DOWN state. It may also stay in COMMUNICATIONS-INTERRUPTED
state if certain conditions are met. state if certain conditions are met.
Once a server is switched into PARTNER-DOWN (when auto-partner-down Once a server is switched into PARTNER-DOWN (when auto-partner-down
is used or as a result of administrative action), it can extend is used or as a result of administrative action), it can extend
leases, regardless of the original server that initially granted the leases, regardless of the original server that initially granted the
lease. In that state server handles leases from its own pool, but lease. In that state server handles leases from its own pool, but
once its own pool is depleted is also able to serve pool from its once its own pool is depleted is also able to serve pool from its
downed partner. MCLT restrictions no longer apply. Operation in downed partner. Some MCLT restrictions no longer apply, but the MCLT
this mode is less demanding for the server that remains operational, still affects whether or not a particular lease can be given to a
than in COMMUNICATIONS-INTERRUPTED state, but PARTNER-DOWN does not different client. See Section 9.4.1 for details. Operation in this
offer any kind of redundancy. Even when in PARTNER-DOWN state, a mode is less demanding for the server that remains operational, than
failover server continues to attempt to connect with its failover in COMMUNICATIONS-INTERRUPTED state, but PARTNER-DOWN does not offer
partner. any kind of redundancy. Even when in PARTNER-DOWN state, a failover
server continues to attempt to connect with its failover partner.
A server switches into RECOVER state when any of a variety of A server switches into RECOVER state when any of a variety of
conditions are encountered: conditions are encountered:
o When a backup server contacts its failover partner for the first o When a backup server contacts its failover partner for the first
time. time.
o When either server discovers that its failover partner has o When either server discovers that its failover partner has
contacted it before but it has no local record of this contact. contacted it before but it has no local record of this contact.
If the record of previous contact is held in the lease-state If the record of previous contact is held in the lease-state
skipping to change at page 10, line 46 skipping to change at page 10, line 51
o BNDACK - The binding acknowledgement is used for confirmation of o BNDACK - The binding acknowledgement is used for confirmation of
the received BNDUPD message. It may contain a positive or the received BNDUPD message. It may contain a positive or
negative response (e.g. due to detected lease conflict). negative response (e.g. due to detected lease conflict).
o POOLREQ - The Pool Request message is used by one server o POOLREQ - The Pool Request message is used by one server
(typically secondary) to request allocation of resources (typically secondary) to request allocation of resources
(addresses or prefixes) from its partner. The partner responds (addresses or prefixes) from its partner. The partner responds
with POOLRESP. with POOLRESP.
o POOLRESP - The Pool Response message is used by one server o POOLRESP - The Pool Response message is used by one server
(typically primary) to repond to its partner's request for (typically primary) to indicate that it has responded to its
resources allocation. One POOLRESP message may contain more than partner's request for resources allocation.
one pool.
o UPDREQ - The update request message is used by one server to o UPDREQ - The update request message is used by one server to
request that its partner send all binding database changes that request that its partner send all binding database changes that
has not been sent and confirmed already. Requested partner is have not been sent and confirmed already. Requested partner is
expected to respond with zero or more BNDUPD messages, followed by expected to respond with zero or more BNDUPD messages, followed by
UPDDONE that signals end of updates. UPDDONE that signals end of updates.
o UPDREQALL - The update request all is used by one server to o UPDREQALL - The update request all is used by one server to
request that all binding database information be sent in order to request that all binding database information be sent in order to
recover from a total loss of its binding database by the recover from a total loss of its binding database by the
requesting server. Requested server responds with zero or more requesting server. Requested server responds with zero or more
BNDUPD messages, followed by UPDDONE that signal end of updates. BNDUPD messages, followed by UPDDONE that signal end of updates.
o UPDDONE - The update done message is used by the responding server o UPDDONE - The update done message is used by the server responding
to indicate that all requested updates have been sent by the to an UPDREQ or UPDREQALL to indicate that all requested updates
responding server and acked by the requesting server. have been sent by the responding server and acked by the
requesting server.
o CONNECT - The connect message is used by the primary server to o CONNECT - The connect message is used by the primary server to
establish a high level connection with the other server, and to establish a high level connection with the other server, and to
transmit several important configuration data items between the transmit several important configuration data items between the
servers. The partner is expected to confirm by responding with servers. The partner is expected to confirm by responding with
CONNECTACK message. CONNECTACK message.
o CONNECTACK - The connect acknowledgement message is used by the o CONNECTACK - The connect acknowledgement message is used by the
secondary server to respond to a CONNECT message from the primary secondary server to respond to a CONNECT message from the primary
server. server.
skipping to change at page 11, line 38 skipping to change at page 11, line 43
closing a connection and shutting down. No response is required closing a connection and shutting down. No response is required
for this message. for this message.
o STATE - The state message is used by either server to inform its o STATE - The state message is used by either server to inform its
partner about a change of failover state. In some cases it may be partner about a change of failover state. In some cases it may be
used to also inform the partner about current state, e.g. after used to also inform the partner about current state, e.g. after
connection is established in COMMUNICATIONS-INTERRUPTED or connection is established in COMMUNICATIONS-INTERRUPTED or
PARTNER-DOWN states. PARTNER-DOWN states.
o CONTACT - The contact message is used by either server to ensure o CONTACT - The contact message is used by either server to ensure
that the other server continues to see the connection as opera- that the other server continues to see the connection as
tional. It MUST be transmitted periodically over every esta- operational. It MUST be transmitted periodically over every
blished connection if other message traffic is not flowing, and it established connection if other message traffic is not flowing,
MAY be sent at any time. and it MAY be sent at any time.
5. Connection Management 5. Connection Management
5.1. Creating Connections 5.1. Creating Connections
Every primary server implementing the failover protocol SHOULD Every primary server implementing the failover protocol MUST attempt
attempt to connect to all of its partners periodically, where the to connect to all of its partners periodically, where the period is
period is implementation dependent and SHOULD be configurable. In implementation dependent and SHOULD be configurable. In the event
the event that a connection has been rejected by a CONNECTACK message that a connection has been rejected by a CONNECTACK message with a
with a reject-reason option contained in it or a DISCONNECT message, reject-reason option contained in it or a DISCONNECT message, a
a server SHOULD reduce the frequency with which it attempts to server SHOULD reduce the frequency with which it attempts to connect
connect to that server but it SHOULD continue to attempt to connect to that server but it MUST continue to attempt to connect
periodically. periodically.
Every secondary server implementing the failover protocol SHOULD Every secondary server implementing the failover protocol MUST listen
listen for connection attempts from the primary server. for connection attempts from the primary server.
When a connection attempt succeeds, the primary server which has When a connection attempt succeeds, the primary server which has
initiated the connection attempt MUST send a CONNECT message down the initiated the connection attempt MUST send a CONNECT message down the
connection. connection.
When a connection attempt is received, the only information that the When a connection attempt is received, the only information that the
receiving server has is the IP address of the partner initiating a receiving server has is the IP address of the partner initiating a
connection. If it has any relationships with the connecting server connection. If it has any relationships with the connecting server
for which it is a seconary server, it should just await the CONNECT for which it is a secondary server, it should just await the CONNECT
message to determine which relationship this connection is to serve. message to determine which relationship this connection is to serve.
If it has no secondary relationships with the connecting server, it If it has no secondary relationships with the connecting server, it
SHOULD drop the connection. The goal is to limit the resources MUST drop the connection. The goal is to limit the resources
expended dealing with attempts to create a spurious failover expended dealing with attempts to create a spurious failover
connection. connection.
To summarize -- a primary server MUST use a connection that it has To summarize -- a primary server MUST use a connection that it has
initiated in order to send a CONNECT message. Every server that is a initiated in order to send a CONNECT message. Every server that is a
secondary server in a relationship simply listens for connection secondary server in a relationship simply listens for connection
attempts from the primary server. attempts from the primary server.
Once a connection is established, the primary server MUST send a Once a connection is established, the primary server MUST send a
CONNECT message across the connection. A secondary server MUST wait CONNECT message across the connection. A secondary server MUST wait
skipping to change at page 14, line 18 skipping to change at page 14, line 29
primary and secondary servers in a configured proportion. primary and secondary servers in a configured proportion.
Released resources are always returned to the primary server. Released resources are always returned to the primary server.
Primary and secondary servers may initiate a rebalancing Primary and secondary servers may initiate a rebalancing
procedure when disparity between resources available to each procedure when disparity between resources available to each
server reaches a preconfigured threshold. Only resources that server reaches a preconfigured threshold. Only resources that
are not leased to any clients are "owned" by one of the servers. are not leased to any clients are "owned" by one of the servers.
This algorithm is particularly well suited for scenarios where This algorithm is particularly well suited for scenarios where
amount of available resources is limited, as may be the case with amount of available resources is limited, as may be the case with
prefix delegation. See Section 6.1 for details. prefix delegation. See Section 6.1 for details.
2. Independent Allocation - This allocation algorithm assumes that 2. Independent Allocation - This allocation algorithm also assumes
available resources are split between primary and secondary that available resources are split between primary and secondary
servers as well. In this case, however, resources are assigned servers. In this case, however, resources are assigned to a
to a specific server for all time, regardless if they are specific server for all time, regardless if they are available or
available or currently used. This algorithm is much simpler than currently used. This algorithm is much simpler than proportional
proportional allocation, because resource imbalance doesn't have allocation, because resource imbalance doesn't have to be checked
to be checked and there is no rebalancing for independent and there is no rebalancing for independent allocation. This
allocation. This algorithm is particularly well suited for algorithm is particularly well suited for scenarios where the
scenarios where the there is an abundance of available resources there is an abundance of available resources which is typically
which is typically the case for DHCPv6 address allocation. See the case for DHCPv6 address allocation. See Section 6.2 for
Section 6.2 for details. details.
6.1. Proportional Allocation 6.1. Proportional Allocation
In this allocation scheme, each server has its own pool of available In this allocation scheme, each server has its own pool of available
resources. Remaining available resources are split between the resources. Remaining available resources are split between the
primary and secondary servers in a configured proportion. Note that primary and secondary servers in a configured proportion. Note that
a resource is not "owned" by a particular server throughout its a resource is not "owned" by a particular server throughout its
entire lifetime. Only a resource which is available is "owned" by a entire lifetime. Only a resource which is available is "owned" by a
particular server -- once it has been leased to a client, it is not particular server -- once it has been leased to a client, it is not
owned by either failover partner. When it finally becomes available owned by either failover partner. When it finally becomes available
skipping to change at page 15, line 14 skipping to change at page 15, line 25
general, that server will have had to replenish its pool of available general, that server will have had to replenish its pool of available
resources well in advance of any likely lease expirations. Thus, resources well in advance of any likely lease expirations. Thus,
having a particular resource cycle back to the secondary might well having a particular resource cycle back to the secondary might well
put the secondary more out of balance with respect to the primary put the secondary more out of balance with respect to the primary
instead of enhancing the balance of available addresses or prefixes instead of enhancing the balance of available addresses or prefixes
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 after some time constraints have elapsed).
address pools is an area of some sensitivity, since the goal is to This allocation and maintenance of these address pools is an area of
maintain a more or less constant ratio of available addresses between some sensitivity, since the goal is to maintain a more or less
the two servers. constant ratio of available addresses between the two servers.
The initial allocation when the servers first integrate is triggered The initial allocation when the servers first integrate is triggered
by the POOLREQ message from the secondary to the primary. This is by the POOLREQ message from the secondary to the primary. This is
followed by the POOLRESP message where the primary tells the followed (at some point) by the POOLRESP message where the primary
secondary how many resources it allocated to the secondary. Then, tells the secondary that it received and processed the POOLREQ
the primary sends the allocated resources to the secondary via BNDUPD message. The primary sends the allocated resources to the secondary
messages. The POOLREQ/POOLRESP message is a trigger to the primary via BNDUPD messages. The POOLRESP message may be sent before,
to perform a scan of its database and to ensure that the secondary during, or at the completion of the BNDUPD message exchanges that
has enough resources (based on some configured ratio). were triggered by the POOLREQ message. The POOLREQ/POOLRESP message
exchange 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).
The primary server SHOULD examine some or all of its database from The primary server SHOULD examine some or all of its database from
time to time to determine if resources should be shifted between the time to time to determine if resources should be shifted between the
primary and secondary (in either direction). The POOLREQ/POOLRESP primary and secondary (in either direction). The POOLREQ/POOLRESP
message exchange allows the secondary server to explicitly request message exchange allows the secondary server to explicitly request
that the primary server examine the entirety of its database to that the primary server examine the entirety of its database to
ensure that the secondary has the approprite resources available. ensure that the secondary has the appropriate resources available.
Servers frequently have several kinds of resources available on a Servers frequently have several kinds of resources available on a
particular network segment. The failover protocol assumes that both particular network segment. The failover protocol assumes that both
primary and secondary servers are configured in such a way that each primary and secondary servers are configured in such a way that each
knows the type and number of resources on every network segment knows the type and number of resources on every network segment
participating in the failover protocol. The primary server is participating in the failover protocol. The primary server is
responsible for allocating the secondary server the correct responsible for allocating the secondary server the correct
proportion of available resources of each kind, and the secondary proportion of available resources of each kind.
server MUST be 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 The resources are delegated to the secondary using the BNDUPD message
with a state of FREE_BACKUP, which indicates the resource is now with a state of FREE_BACKUP, which indicates the resource is now
available for allocation by the secondary. Once the message is sent, available for allocation by the secondary. Once the message is sent,
the primary MUST NOT use these resources for allocation to DHCPv6 the primary MUST NOT use these resources for allocation to DHCPv6
clients. clients.
Available resources can be delegated back to the primary server in Available resources can be delegated back to the primary server in
certain cases. BNDUPD will contain state FREE for leases that were certain cases. BNDUPD will contain state FREE for leases that were
previously in FREE_BACKUP state. previously in FREE_BACKUP state.
skipping to change at page 16, line 34 skipping to change at page 16, line 43
adjust the available resource balance as required to ensure the adjust the available resource balance as required to ensure the
configured resource balance, excepting that the primary server SHOULD configured resource balance, excepting that the primary server SHOULD
employ some threshold mechanism to such a balance adjustment in order employ some threshold mechanism to such a balance adjustment in order
to minimize the overhead of maintaining this balance. to minimize the overhead of maintaining this balance.
An example of a threshold approach is: do not attempt to re-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 the prefixes on the primary and secondary until the out of balance
value exceeds a configured value. value exceeds a configured value.
The primary server can, at any time, send an available resource to The primary server can, at any time, send an available resource to
the secondary using a BNDUPD with the state BACKUP. The primary the secondary using a BNDUPD with the state FREE_BACKUP. The primary
server can attempt to take an available resource away from the server can attempt to take an available resource away from the
secondary by sending a BNDUPD with the state FREE. If the secondary secondary by sending a BNDUPD with the state FREE. If the secondary
accepts the BNDUPD, then the resource is now available to the primary accepts the BNDUPD, then the resource is now available to the primary
and not available to the secondary. Of course, the secondary MUST and not available to the secondary. Of course, the secondary MUST
reject that BNDUPD if it has already used that resource for a DHCP reject that BNDUPD if it has already used that resource for a DHCP
client. client.
6.2. Independent Allocation 6.2. Independent Allocation
In this allocation scheme, available resources are permanently (until In this allocation scheme, available resources are permanently (until
server configuration changes) split between servers. Available server configuration changes) split between servers. Available
resources are split between the primary and secondary servers as part resources are split between the primary and secondary servers as part
of initial connection establishment. Once resources are allocated to of initial connection establishment. Once resources are allocated to
each server, there is no need to reassign them. The resource each server, there is no need to reassign them. The resource
allocation is algorithmic in nature, and does not require a message allocation is algorithmic in nature, and does not require a message
exchange for each resources allocated. This algorithm is simpler exchange for each resource allocated. This algorithm is simpler than
than proportional allocation since it requires similar initial proportional allocation since it does not require a rebalancing
communication, but does not require a rebalancing mechanism. It mechanism. It assumes that the pool assigned to each server will
assumes that the pool assigned to each server will never deplete. never deplete. That is often a reasonable assumption for IPv6
That is often a reasonable assumption for IPv6 addresses (e.g. addresses (e.g. servers are often assigned a /64 pool that contains
servers are often assigned a /64 pool that contains many more many more addresses than existing electronic devices on Earth). This
addresses than existing electronic devices on Earth). This
allocation mechanism SHOULD be used for IPv6 addresses, unless the allocation mechanism SHOULD be used for IPv6 addresses, unless the
configured address pool is small or is otherwise administratively configured address pool is small or is otherwise administratively
limited. 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 releases a resource or its lease is expired, clients. Once a client releases a resource or its lease is expired,
the returned resource returns to pool for the server that leased it. the returned resource returns to the pool for the server that leased
Resources never changes servers. it. Resources never changes servers.
Resources using the independent allocation approach are ignored when Resources using the independent allocation approach are ignored when
a server processes a POOLREQ message. a server processes a POOLREQ message.
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. Server SHOULD use its own pool first before starting new state. When it is in PARTNER-DOWN state, a server SHOULD use its own
assignements from its downed partner's pool. As the assumption is pool first and then it MAY start making new assignments from its
that independent allocation should be used only when available downed partner's pool. As the assumption is that independent
resources are vast and not expected to be fully used at any given allocation should be used only when available resources are vast and
time, it is very unlikely that the server will ever need to use its not expected to be fully used at any given time, it is very unlikely
downed partner pools. This makes a recovery even after prolonged that the server will ever need to use its downed partner pools. This
down-time much easier. makes a recovery even after prolonged down-time much easier.
6.3. Choosing Allocation Algorithm 6.3. Choosing Allocation Algorithm
All implementations MUST support proportional allocation algorithm All implementations SHOULD support both the proportional allocation
and SHOULD support independent allocation. If the implementation algorithm and the independent allocation algorithm. The specific
implements both and lets the user choose between them, the default requirements for support (i.e., which algorithm(s) MUST be
algorithm used SHOULD be proportional allocation algorithm. supported), and the assignment of a specific algorithm to a specific
allocation domain, would be documented in any protocol specifications
that follow from this document.
Proportional allocation mechanism is more flexible as it can The proportional allocation mechanism is more flexible as it can
dynamically rebalance available resources between servers. That dynamically rebalance available resources between servers. That
balance includes additional burden for the servers and generates more balance creates an additional burden for the servers and generates
traffic between servers. Proportional algorithm can be considered more traffic between servers. The proportional algorithm can be
more efficient at managing available resources, compared to considered more efficient at managing available resources, compared
idenpendent. That is important aspect when working in a network that to the independent algorithm. That is an important aspect when
is nearing address and/or prefix depletion. working in a network that is nearing address and/or prefix depletion.
Independent allocation can be used when the number of available Independent allocation can be used when the number of available
resources are large and there is no realistic danger of running out resources are large and there is no realistic danger of running out
of resources. Use of the independent allocation makes communication of resources. Use of the independent allocation makes communication
between partners simpler. It also makes recovery easier and between partners simpler. It also makes recovery easier and
potential conflict less likely to appear. potential conflict less likely to appear.
Typically independent allocation is used for IPv6 addresses, because Typically independent allocation is used for IPv6 addresses, because
even for /64 pools a server will never run out of addresses to 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 assign, so there is no need to rebalance. For the prefix delegation
mechanism, available resources are typically much smaller, so there mechanism, available resources are typically much smaller, so there
is a danger of running out of prefixes. Therefore typically is a danger of running out of prefixes. Therefore typically
proportional allocation will be used for prefix delegations. proportional allocation will be used for prefix delegations.
Independent allocation still may be used, but the implication must be Independent allocation still may be used, but the implication must be
well understood. For example in a network that delegates /64 well understood. For example in a network that delegates /64
prefixes out out /48 prefix (so there can be up to 65536 prefixes prefixes out of a /48 prefix (so there can be up to 65536 prefixes
delegated) and a 1000 requesting routers, it is safe to use delegated) and a 1000 requesting routers, it is safe to use
independent allocation. independent allocation.
It should be stressed out that independent allocation algorithm It should be stressed that the independent allocation algorithm
SHOULD NOT be used when number of resources is limited and there is a SHOULD NOT be used when the number of resources is limited and there
realistic danger of depleting resources. If this recommendation is is a realistic danger of depleting resources. If this recommendation
violated, it may lead to a case, when one server denies clients due 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 to pool depletion despite the fact that the other partner still has
many resources available. many resources available.
With independent allocation it is very unlikely to remaining healthy With independent allocation it is very unlikely for a remaining
server to allocate resources from its unavailable partner's pool. healthy server to allocate resources from its unavailable partner's
That makes recovery easier and any potential conflicts are less pool. That makes recovery easier and any potential conflicts are
likely to appear. less likely to appear.
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 server implementations probably have lease states. While no two DHCP server implementations probably have
exactly the same possible binding-status values, [RFC3315] enforces exactly the same possible binding-status values, [RFC3315] enforces
some commonality among the general semantics of the binding-status some commonality among the general semantics of the binding-status
values used by various DHCP server implementations. values used by various DHCP server implementations.
skipping to change at page 19, line 36 skipping to change at page 19, line 44
of representation, this transitional FREE* state is treated as a of representation, this transitional FREE* state is treated as a
separate state. separate state.
FREE -- Is used when a DHCP server needs to communicate that a FREE -- Is used when a DHCP server needs to communicate that a
resource is unused by any client, but it was not just released, resource is unused by any client, but it was not just released,
expired or reset by a network administrator. When the partner expired or reset by a network administrator. When the partner
acks the BNDUPD of a FREE lease, the server marks the lease as acks the BNDUPD of a FREE lease, the server marks the lease as
available for assignment by the primary server. Note that on a available for assignment by the primary server. Note that on a
secondary server running in PARTNER-DOWN state, after waiting the secondary server running in PARTNER-DOWN state, after waiting the
MCLT, the resource MAY be allocated to a client by the secondary MCLT, the resource MAY be allocated to a client by the secondary
server if proportional algorithm is used. Client identification server. Client identification MAY appear and indicates the last
MAY appear. client to have used this resource as a hint.
FREE_BACKUP -- indicates that this resource can be allocated by the FREE_BACKUP -- indicates that this resource can be allocated by the
secondary server to a client at any time. Note that the primary secondary server to a client at any time. Note that the primary
server running in PARTNER-DOWN state, after waiting the MCLT, the server running in PARTNER-DOWN state, after waiting the MCLT, the
resource MAY be allocated to a client by the primary server if resource MAY be allocated to a client by the primary server if
proportional algorithm was used. Client identification MAY proportional algorithm was used. Client identification MAY appear
appear. and indicates the last client to have used this resource as a
hint.
ABANDONED -- indicates that a lease is considered unusable by the ABANDONED -- indicates that a lease is considered unusable by the
DHCP system. The primary reason for entering such state is DHCP system. The primary reason for entering such state is
reception of DECLINE message for said lease. Client reception of DECLINE message for said lease. Client
identification MUST NOT appear. identification MAY appear.
RESET -- indicates that this resource was previously abandoned, but RESET -- indicates that this resource was made available by operator
was made available by operator command. This is a distinct state command. This is a distinct state so that the reason that the
so that the reason that the resource became FREE can be resource became FREE can be determined. Client identification MAY
determined. Client identification MAY appear. appear.
The lease state machine has been presented in Figure 1. Most states The lease state machine has been presented in Figure 1. Most states
are stationary, i.e. the lease stays in a given state until exernal are stationary, i.e. the lease stays in a given state until external
event triggers transition to another state. The only transitive event triggers transition to another state. The only transitive
state is FREE*. One it is reached, the the state machine immediately state is FREE*. Once it is reached, the state machine immediately
transitions to either FREE or FREE_BACKUP state. transitions to either FREE or FREE_BACKUP state.
+---------+ +---------+
/------------->| ACTIVE |<--------------\ /------------->| ACTIVE |<--------------\
| +---------+ | | +---------+ |
| | | | | | | | | |
| /--(8)--/ (3) \--(9)-\ | | /--(8)--/ (3) \--(9)-\ |
| | | | | | | | | |
| V V V | | V V V |
| +-------+ +--------+ +---------+ | | +-------+ +--------+ +---------+ |
skipping to change at page 21, line 34 skipping to change at page 21, line 48
from FREE to FREE_BACKUP) or vice versa. from FREE to FREE_BACKUP) or vice versa.
8. The lease has expired. 8. The lease has 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 a Neighbor Discovery or ICMP Echo possible example of such use is a Neighbor Discovery or ICMPv6
check if the address is still in use. Echo 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| | | | \Resource 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
In case of servers operating in active-passive mode, while a majority In case of servers operating in active-passive mode, while a majority
of the resources are owned by the primary server, the secondary of the resources are owned by the primary server, the secondary
server will need a portion of the resources to serve new clients server will need a portion of the resources to serve new clients
while operating in COMMUNICATION-INTERRUPTED state and also in while operating in COMMUNICATION-INTERRUPTED state and also in
PARTNER-DOWN state before it can take over the entire address pool PARTNER-DOWN state before it can take over the entire address pool
(after the expiry of MCLT). (after the expiry of MCLT).
The secondary server connot simply take over the entire resource pool The secondary server cannot simply take over the entire resource pool
immediately, since we have to handle the case where both servers are immediately, since it could also be that both servers are able to
able to communicate with DHCP clients, but unable to communicate with communicate with DHCP clients, but unable to communicate with each
each other. other.
The size of the resource pool allocated to the secondary is specified The size of the resource pool allocated to the secondary is specified
as a percentage of the currently available resources. Thus, as the as a percentage of the currently available resources. Thus, as the
number of available resources changes on the primary server, the number of available resources changes on the primary server, the
number of resources available to the secondary server MUST also number of resources available to the secondary server MUST also
change, although the frequency of the changes made to the secondary change, although the frequency of the changes made to the secondary
server's pool of address resources SHOULD be low enough to not use server's pool of address resources SHOULD be low enough to not use
significant processing power or network bandwidth. significant processing power or network bandwidth.
The required size of this private pool allocated to the secondary The required size of this private pool allocated to the secondary
skipping to change at page 22, line 52 skipping to change at page 23, line 26
compare a known lease state with an update received from a partner, compare a known lease state with an update received from a partner,
servers must be able to reliably compare the times stored in the servers must be able to reliably compare the times stored in the
known lease state with the times received in the update. Although a known lease state with the times received in the update. Although a
simple approach would be to require both partners to use synchronized simple approach would be to require both partners to use synchronized
time, e.g. by using NTP, such a service may not always be available time, e.g. by using NTP, such a service may not always be available
in some scenarios that failover expects to cover. Therefore a in some scenarios that failover expects to cover. Therefore a
mechanism to measure and track relative time differences between mechanism to measure and track relative time differences between
servers is necessary. To do so, each message MUST contain servers is necessary. To do so, each message MUST contain
information about the time of the transmission in the time context of information about the time of the transmission in the time context of
the transmitter. The transmitting server MUST set this as close to the transmitter. The transmitting server MUST set this as close to
the actual transmission as possible. The receiving partner MUST the actual transmission as possible. Transmission here is when data
store its own timestamp of reception as close to the actual reception is added to the send queue of the socket (or the equivalent), as the
as possible. The received timestamp information is then compared application may not know about the time of the actual transmission of
with local timestamp. the "wire". The receiving partner MUST store its own timestamp of
reception as close to the actual reception as possible. The received
timestamp information is then compared with local timestamp.
To account for packet delay variation (jitter), the measured To account for packet delay variation (jitter), the measured
difference is not used directly, but rather the moving average of difference is not used directly, but rather the moving average of
last TIME_SKEW_PKTS_AVG packets time difference is calculated. This last TIME_SKEW_PKTS_AVG packets time difference is calculated. This
averaged value is referred to as the time skew. Note that the time averaged value is referred to as the time skew. Note that the time
skew algorithm allows cooperation between clients with completely skew algorithm allows cooperation between servers with completely
desynchronized clocks as well as those whose desynchronization itself desynchronized clocks as well as those whose desynchronization itself
is not constant. is not constant.
8.2. Time expression 8.2. Lazy updates
Timestamps are expressed as number of seconds since midnight (UTC),
January 1, 2000, modulo 2^32. Note: that is the same approach as
used in creation of DUID-LLT (see Section 9.2 of [RFC3315]).
Time differences are expressed in seconds and are signed.
8.3. Lazy updates
Lazy update refers to the requirement placed on a server implementing Lazy update refers to the requirement placed on a server implementing
a failover protocol to update its failover partner whenever the a failover protocol to update its failover partner whenever the
binding database changes. A failover protocol which didn't support binding database changes. A failover protocol which didn't support
lazy update would require the failover partner update to complete lazy update would require the failover partner update to complete
before a DHCPv6 server could respond to a DHCPv6 client request. before a DHCPv6 server could respond to a DHCPv6 client request.
Such approach is often referred to as 'lockstep' and is the opposite Such approach is often referred to as 'lockstep' and is the opposite
of lazy updates. The lazy update mechanism allows a server to of lazy updates. The lazy update mechanism allows a server to
allocate a new or extend an existing lease and then update its allocate a new or extend an existing lease and then update its
failover partner as time permits. failover partner as time permits.
Although the lazy update mechanism does not introduce additional Although the lazy update mechanism does not introduce additional
delays in server response times, it introduces other difficulties. delays in server response times, it introduces other difficulties.
The key problem with lazy update is that when a server fails after The key problem with lazy update is that when a server fails after
updating a client with a particular lease time and before updating updating a client with a particular lease time and before updating
its partner, the partner will believe that a lease has expired even its partner, the partner will believe that a lease has expired even
though the client still retains a valid lease on that address or though the client still retains a valid lease on that address or
prefix. prefix. It is also possible that the partner will have no record at
all of the lease of the resource to the client.
8.3. MCLT concept
8.4. MCLT concept
In order to handle problem introduced by lazy updates (see In order to handle problem introduced by lazy updates (see
Section 8.3), a period of time known as the "Maximum Client Lead Section 8.2), a period of time known as the "Maximum Client Lead
Time" (MCLT) is defined and must be known to both the primary and Time" (MCLT) is defined and must be known to both the primary and
secondary servers. Proper use of this time interval places an upper secondary servers. Proper use of this time interval places an upper
bound on the difference allowed between the lease time provided to a bound on the difference allowed between the lease time provided to a
DHCPv6 client by a server and the lease time known by that server's DHCPv6 client by a server and the lease time known by that server's
failover partner. failover partner.
The MCLT is typically much less than the lease time that a server has The MCLT is typically much less than the lease time that a server has
been configured to offer a client, and so some strategy must exist to been configured to offer a client, and so some strategy must exist to
allow a server to offer the configured lease time to a client. allow a server to offer the configured lease time to a client.
During a lazy update the updating server typically updates its During a lazy update the updating server typically updates its
skipping to change at page 25, line 15 skipping to change at page 25, line 26
potential valid lifetime: potential valid lifetime:
The potential valid lifetime is the potential lease expiration The potential valid lifetime is the potential lease expiration
interval the local server tells to its partner in a BNDUPD interval the local server tells to its partner in a BNDUPD
message. message.
acknowledged potential valid lifetime: acknowledged potential valid lifetime:
The acknowledged potential valid lifetime is the potential lease The acknowledged potential valid lifetime is the potential lease
interval the partner server has most recently acknowledged in a interval the partner server has most recently acknowledged in a
BNDACK message. BNDACK message.
8.4.1. MCLT example 8.3.1. MCLT example
The following example demonstrates the MCLT concept in practice. The The following example demonstrates the MCLT concept in practice. The
values used are arbitrarily chosen are and not a recommendation for values used are arbitrarily chosen are and not a recommendation for
actual values. The MCLT in this case is 1 hour. The desired valid actual values. The MCLT in this case is 1 hour. The desired valid
lifetime is 3 days, and its renewal time is half the valid lifetime. lifetime is 3 days, and its renewal time is half the valid lifetime.
When a server makes an offer for a new lease on an IP address to a When a server makes an offer for a new lease on an IP address to a
DHCPv6 client, it determines the desired valid lifetime (in this DHCPv6 client, it determines the desired valid lifetime (in this
case, 3 days). It then examines the acknowledged potential valid case, 3 days). It then examines the acknowledged potential valid
lifetime (which in this case is zero) and determines the remainder of lifetime (which in this case is zero) and determines the remainder of
the time left to run, which is also zero. It adds the MCLT to this the time left to run, which is also zero. It adds the MCLT to this
value. Since the actual valid lifetime cannot be allowed to exceed value. Since the actual valid lifetime cannot be allowed to exceed
the remainder of the current acknowledged potential valid lifetime the remainder of the current acknowledged potential valid lifetime
plus the MCLT, the offer made to the client is for the remainder of plus the MCLT, the offer made to the client is for the remainder of
the current acknowledged potential valid lifetime (i.e. zero) plus the current acknowledged potential valid lifetime (i.e. zero) plus
the MCLT. Thus, the actual valid lifetime is 1 hour. the MCLT. Thus, the actual valid lifetime is 1 hour (the MCLT).
Once the server has sent the REPLY to the DHCPv6 client, it will Once the server has sent the REPLY to the DHCPv6 client, it will
update its failover partner with the lease information. However, the update its failover partner with the lease information. However, the
desired potential valid lifetime will be composed of one half of the desired potential valid lifetime will be composed of one half of the
current actual valid lifetime added to the desired valid lifetime. current actual valid lifetime added to the desired valid lifetime.
Thus, the failover partner is updated with a BNDUPD with a potential Thus, the failover partner is updated with a BNDUPD with a potential
valid lifetime of 3 days + 1/2 hour. valid lifetime of 1/2 hour + 3 days.
When the primary server receives a BNDACK to its update of the When the primary server receives a BNDACK to its update of the
secondary server's (partner's) potential valid lifetime, it records secondary server's (partner's) potential valid lifetime, it records
that as the acknowledged potential valid lifetime. A server MUST NOT that as the acknowledged potential valid lifetime. A server MUST NOT
send a BNDACK in response to a BNDUPD message until it is sure that send a BNDACK in response to a BNDUPD message until it is sure that
the information in the BNDUPD message has been updated in its lease the information in the BNDUPD message has been updated in its lease
database. Thus, the primary server in this case can be sure that the database. See Section 8.9. Thus, the primary server in this case
secondary server has recorded the potential lease interval in its can be sure that the secondary server has recorded the potential
stable storage when the primary server receives a BNDACK message from lease interval in its stable storage when the primary server receives
the secondary server. a BNDACK message from the secondary server.
When the DHCPv6 client attempts to renew at T1 (approximately one When the DHCPv6 client attempts to renew at T1 (approximately one
half an hour from the start of the lease), the primary server again half an hour from the start of the lease), the primary server again
determines the desired valid lifetime, which is still 3 days. It determines the desired valid lifetime, which is still 3 days. It
then compares this with the original acknowledged potential valid then compares this with the original acknowledged potential valid
lifetime (3 days + 1/2 hour) and adjusts for the time passed since lifetime (1/2 hour + 3 days) and adjusts for the time passed since
the secondary was last updated (1/2 hour). Thus the time remaining the secondary was last updated (1/2 hour). Thus the time remaining
of the acknowledged potential valid interval is 3 days. Adding the of the acknowledged potential valid interval is 3 days. Adding the
MCLT to this yields 3 days plus 1 hour, which is more than the MCLT to this yields 3 days plus 1 hour, which is more than the
desired valid lifetime of 3 days. So the client is renewed for the desired valid lifetime of 3 days. So the client is renewed for the
desired valid lifetime -- 3 days. desired valid lifetime -- 3 days.
When the primary DHCPv6 server updates the secondary DHCPv6 server When the primary DHCPv6 server updates the secondary DHCPv6 server
after the DHCPv6 client's renewal REPLY is complete, it will after the DHCPv6 client's renewal REPLY is complete, it will
calculate the desired potential valid lifetime as the T1 fraction of calculate the desired potential valid lifetime as the T1 fraction of
the actual client valid lifetime (1/2 of 3 days this time = 1.5 the actual client valid lifetime (1/2 of 3 days this time = 1.5
skipping to change at page 26, line 30 skipping to change at page 26, line 41
to be able to always offer the client the desired client valid to be able to always offer the client the desired client valid
lifetime. lifetime.
Once the initial actual client valid lifetime of the MCLT is past, Once the initial actual client valid lifetime of the MCLT is past,
the protocol operates effectively like the DHCPv6 protocol does today the protocol operates effectively like the DHCPv6 protocol does today
in its behavior concerning valid lifetimes. However, the guarantee in its behavior concerning valid lifetimes. However, the guarantee
that the actual client valid lifetime will never exceed the remaining that the actual client valid lifetime will never exceed the remaining
acknowledged partner server potential valid lifetime by more than the acknowledged partner server potential valid lifetime by more than the
MCLT allows full recovery from a variety of failures. MCLT allows full recovery from a variety of failures.
8.5. Unreachability detection 8.4. Unreachability detection
Each partner MUST maintain a FO_SEND timer for each failover Each partner MUST maintain a FO_SEND timer for each failover
connection. The FO_SEND timer is reset every time any message is connection. The FO_SEND timer is reset every time any message is
transmitted. If the timer reaches the FO_SEND_MAX value, a CONTACT transmitted. If the timer reaches the FO_SEND_MAX value, a CONTACT
message is transmitted and timer is reset. The CONTACT message may message is transmitted and timer is reset. The CONTACT message may
be transmitted at any time. Implementation MAY use additional be transmitted at any time. An implementation MAY use additional
mechanisms to detect partner unreachability. mechanisms to detect partner unreachability.
Implementors are advised to keep in mind that the timer based CONTACT Implementers are advised to keep in mind that the timer based CONTACT
message mechanism is not perfect and may not detect some failures. message mechanism is not perfect and may not detect some failures.
In particular, if the partner is using one interface to reach clients In particular, if the partner is using one interface to reach clients
("downlink") and another to reach its partner ("uplink"), it is ("downlink") and another to reach its partner ("uplink"), it is
possible that communication with the clients will break, yet the possible that communication with the clients will break, yet the
mechanism will still claim full reachability. For that reason it is mechanism will still claim full reachability. For that reason it is
beneficial to share the same interface for client traffic and beneficial to share the same interface for client traffic and
communication with the failover partner. That approach may have communication with the failover partner. That approach may have
drawbacks in some network topologies. drawbacks in some network topologies.
8.6. Re-allocating Leases 8.5. Re-allocating Leases
When in PARTNER-DOWN state there is a waiting period after which a When in PARTNER-DOWN state there is a waiting period after which a
resource can be re-allocated to another client. For resources which resource can be re-allocated to another client. For resources which
are available when the server enters PARTNER-DOWN state, the period are available when the server enters PARTNER-DOWN state, the period
is the MCLT from the entry into PARTNER-DOWN state. For resources is the MCLT from the entry into PARTNER-DOWN state. For resources
which are not available when the server enters PARTNER-DOWN state, which are not available when the server enters PARTNER-DOWN state,
the period is the MCLT after the later of the following times: the the period is the MCLT after the later of the following times: the
potential valid lifetime, the most recently transmitted potential potential valid lifetime, the most recently transmitted potential
valid lifetime, the most recently received acknowledged potential valid lifetime, the most recently received acknowledged potential
valid lifetime, and the most recently transmitted acknowledged valid lifetime, and the most recently transmitted acknowledged
potential valid lifetime. If this time would be earlier than the potential valid lifetime. If this time would be earlier than the
current time plus the MCLT, then the time the server entered PARTNER- current time plus the MCLT, then the time the server entered PARTNER-
DOWN state plus the maximum-client-lead-time is used. DOWN state plus the maximum-client-lead-time is used.
In any other state, a server cannot reallocate a resource from one In any other state, a server cannot reallocate a resource from one
client to another without first notifying its partner (through a client to another without first notifying its partner (through a
BNDUPD message) and receiving acknowledgement (through a BNDACK mes- BNDUPD message) and receiving acknowledgement (through a BNDACK
sage) that its partner is aware that that first client is not using message) that its partner is aware that that first client is not
the resource. using the resource.
This could be modeled in the following way. Though this specific This could be modeled in the following way. Though this specific
implementation is in no way required, it may serve to better illus- implementation is in no way required, it may serve to better
trate the concept. illustrate the concept.
An "available" resource on a server may be allocated to any client. 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 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 by that client would take on a new state, EXPIRED or
RELEASED respectively. The partner server would then be notified RELEASED respectively. The partner server would then be notified
that this resource was EXPIRED or RELEASED through a BNDUPD. When that this resource was EXPIRED or RELEASED through a BNDUPD. When
the sending server received the BNDACK for that resource showing it the sending server received the BNDACK for that resource showing it
was FREE, it would move the resource from EXPIRED or RELEASED to was FREE, it would move the resource from EXPIRED or RELEASED to
FREE, and it would be available for allocation by the primary server FREE, and it would be available for allocation by the primary server
to any clients. to any clients.
A server MAY reallocate a resource in the EXPIRED or RELEASED state 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 to the same client with no restrictions provided it has not sent a
BNDUPD message to its partner. This situation would exist if the BNDUPD message to its partner. This situation would exist if the
lease expired or was released after the transition into PARTNER-DOWN lease expired or was released after the transition into PARTNER-DOWN
state, for instance. state, for instance.
8.7. Sending Binding Update 8.6. 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. Servers MAY generate
MAY generate BNDUPD messages with multiple binding update messages with multiple binding update transactions in them, and their
transactions, every server MUST be able to process a BNDUPD message partner servers MAY process these messages. Before multiple binding
which contains multiple binding update transactions and generate the update transactions are to be sent and processed over a failover
corresponding BNDACK messages with status for multiple binding update connection, their use MUST be negotiated during the CONNECT and
transactions. CONNECTACK connection establishment processing.
Each server updates its failover partner about recent changes in Each server updates its failover partner about recent changes in
lease states. Each update MUST include at least the following lease states. Each update MUST include at least the following
information: information:
1. resource type - non-temporary address or a prefix. Resource 1. resource type - non-temporary address or a prefix. Resource
type can be indicated by the container that conveys the actual type can be indicated by the container that conveys the actual
resource (e.g. an IA_NA option indicates non-temporary IPv6 resource (e.g. an IA_NA option indicates non-temporary IPv6
address); address);
2. resource information - the actual address or prefix. That is 2. resource information - the actual address or prefix. That is
conveyed using the appropriate option, e.g. an IAADDR for an conveyed using the appropriate option, e.g. an IAADDR for an
address or an IAPREFIX for a prefix; address or an IAPREFIX for a prefix;
3. valid life time requested by client*; 3. valid life time sent to client*;
4. valid life time sent to client*;
5. IAID - Identity Association used by the client, while obtaining 4. IAID - Identity Association used by the client, while obtaining
a given lease. (Note1: one client may use many IAIDs a given lease. (Note1: one client may use many IAIDs
simulatenously. Note2: IAID for IA, TA and PD are orthogonal simultaneously. Note2: IAID for IA, TA and PD are orthogonal
number spaces.)*; number spaces.)*;
6. Next Expected Client Transmission - time interval since Client 5. Next Expected Client Transmission (renewal time) - time interval
Last Transmission Time, when a response from a client is since Client Last Transmission Time, when a response from a
expected*; client is expected*;
7. potential valid life time - a lifetime that the server is 6. potential valid life time - a lifetime that the server is
willing to set if there were no MCLT/failover restrictions willing to set if there were no MCLT/failover restrictions
imposed*; imposed*;
8. preferred life time sent to client - the actual value sent back 7. preferred life time sent to client - the actual value sent back
to the client*; to the client*;
9. CLTT - Client Last Transaction Time, a timestamp of the last 8. CLTT - Client Last Transaction Time, a timestamp of the last
received transmission from a client*; received transmission from a client*;
10. Client DUID*. 9. Client DUID*.
10. Resource state.
11. start time of state (especially for non-client updates).
Items marked with asterisk MUST appear only if the lease is/was Items marked with asterisk MUST appear only if the lease is/was
associated with a client. Otherwise it MUST NOT appear, e.g. for associated with a client. Otherwise it MUST NOT appear.
updates from FREE to FREE_BACKUP state. Server MUST reject updates
that does not include any of the aforementioned information.
The BNDUPD message MAY contain additional information related to the The BNDUPD message MAY contain additional information related to the
updated lease. The additional information MAY include, but is not updated lease. The additional information MAY include, but is not
limited to: limited to:
1. assigned FQDN name, defined in [RFC4704]; 1. assigned FQDN name, defined in [RFC4704];
2. Options Requested by the client, i.e. content of the ORO; 2. Options Requested by the client, i.e. content of the ORO;
3. Remote-ID, defined in [RFC4649]; 3. Relay Data option from DHCPv6 Leasequery, see [RFC5007]
Section 4.1.2.4
4. Relay-ID, defined in [RFC5460], section 5.4.1;
5. Link-layer address [RFC6939];
6. Any other options the updating partner deems useful. 4. Any other options the updating partner deems useful.
Receiving partner MAY store received additional information, but it The receiving partner MAY store any additional information received,
MAY choose to ignore them as well. Some information may be useful, but it MAY choose to ignore it as well. Some information may be
so it is a good idea to keep or update it. One reason is FQDN useful, so it is a good idea to keep or update it. One reason is
information. A server SHOULD be prepared to clean up DNS information FQDN information. A server SHOULD be prepared to clean up DNS
once the lease expires or is released. See Section Section 11 for information once the lease expires or is released. See Section 11
detailed discussion about Dynamic DNS. Another reason the partner for a detailed discussion about Dynamic DNS. Another reason the
may be interested in keeping additional data is a better support for partner may be interested in keeping additional data is a better
leasequery [RFC5007] or bulk leasequery [RFC5460], which features support for leasequery [RFC5007] or bulk leasequery [RFC5460], which
queries based on Relay-ID, by link address and by Remote-ID. features queries based on Relay-ID, by link address and by Remote-ID.
8.8. Receiving Binding Update 8.7. Receiving Binding Update
When a server receives a BNDUPD message, it needs to decide how to When a server receives a BNDUPD message, it needs to decide how to
process the binding update transaction it contains and whether that process the binding update transaction it contains and whether that
transaction represents a conflict of any sort. The conflict transaction represents a conflict of any sort. The conflict
resolution process MUST be used on the receipt of every BNDUPD resolution process MUST be used on the receipt of every BNDUPD
message, not just those that are received while in POTENTIAL-CONFLICT message, not just those that are received while in POTENTIAL-CONFLICT
state, in order to increase the robustness of the protocol. state, in order to increase the robustness of the protocol.
There are three sorts of conflicts: There are three sorts of conflicts:
1. Two clients, one resource - This is the duplicate resource 1. Two clients, one resource - This is the duplicate resource
allocation conflict. There two different clients each allocated allocation conflict. There two different clients each allocated
the same resource. See Section 8.9. the same resource. See Section 8.8.
2. Two resources, one client conflict - This conflict exists when a 2. Two resources, one client conflict - This conflict exists when a
client on one server is associated with a one resource, and on client on one server is associated with a one resource, and on
the other server with a different resource in the same or related the other server with a different resource in the same or related
subnet. This does not refer to the case where a single client prefix. This does not refer to the case where a single client
has resources in multiple different subnets or administrative has resources in multiple different prefixes or administrative
domains (i.e. a mobile client that changed its location), but domains (i.e. a mobile client that changed its location), but
rather the case where on the same subnet the client has a lease rather the case where on the same prefix the client has a lease
on one IP address in one server and on a different IP address on on one IP address in one server and on a different IP address on
the other server. the other server.
This conflict may or may not be a problem for a given DHCP server This conflict may or may not be a problem for a given DHCP server
implementation and policy. If implementations and policies implementation and policy. If implementations and policies
allow, both resources can be assigned to a given client. In the allow, both resources can be assigned to a given client. In the
event that a DHCP server requires that a DHCP client have only event that a DHCP server requires that a DHCP client have only
one outstanding lease of a given type, the conflict MUST be one outstanding lease of a given type, the conflict MUST be
resolved by accepting the lease which has the latest CLTT. resolved by accepting the lease which has the latest CLTT.
It should be further clarified that DHCPv6 protocol makes It should be further clarified that DHCPv6 protocol makes
assignments based on (client DUID, resource type, iaid) triplet. assignments based on a (client DUID, resource type, IAID)
The possibility of using different IAIDs was omitted in this triplet. The possibility of using different IAIDs was omitted in
paragraph for clarity. If one client is assigned multiple this paragraph for clarity. If one client is assigned multiple
resources of the same type, but with different IAIDs, there is no resources of the same type, but with different IAIDs, there is no
conflict. Also, iaid values for different resource types are conflict. Also, IAID values for different resource types are
orthogonal, i.e. IA_NA with iaid=1 is different than IA_PD with orthogonal, i.e. an IA_NA with IAID=1 is different than an IA_PD
iaid=1 and there is no conflict. with IAID=1 and there is no conflict.
3. binding-status conflict - This is normal conflict, where one 3. binding-status conflict - This is normal conflict, where one
server is updating the other with newer information. See server is updating the other with newer information. See
Section 8.9 for details of how to resolve these conflicts. Section 8.8 for details of how to resolve these conflicts.
8.9. Conflict Resolution 4. configuration conflict -- This kind of conflict stems from a
differing configuration on one server than on the other server.
It may be transient (last until both servers can process a new
configuration) or it may be chronic. It cannot be resolved by
communications over the failover connection, but must be resolved
(if it is not transient) by administrator action to resolve the
conflicts.
8.8. Conflict Resolution
The server receiving a lease update from its partner must evaluate The server receiving a lease update from its partner must evaluate
the received lease information to see if it is consistent with the received lease information to see if it is consistent with
already known state and decide which information - the previously already known state and decide which information - the previously
known or that just received - is "better". The server should take known or that just received - is "better". The server should take
into consideration the following aspects: if the lease is already into consideration the following aspects: if the lease is already
assigned to a specific client, who had contact with client recently, assigned to a specific client, who had contact with client recently,
start time of the lease, etc. start time of the lease, etc.
When analyzing a BNDUPD message from a partner server, if there is When analyzing a BNDUPD message from a partner server, if there is
skipping to change at page 31, line 14 skipping to change at page 31, line 19
Every BNDUPD message SHOULD contain a client-last-transaction-time Every BNDUPD message SHOULD contain a client-last-transaction-time
option, which MUST, if it appears, be the time that the server last option, which MUST, if it appears, be the time that the server last
interacted with the DHCP client. It MUST NOT be, for instance, the interacted with the DHCP client. It MUST NOT be, for instance, the
time that the lease on an IP address expired. If there has been no time that the lease on an IP address expired. If there has been no
interaction with the DHCP client in question (or there is no DHCP interaction with the DHCP client in question (or there is no DHCP
client presently associated with this resource), then there will be client presently associated with this resource), then there will be
no client-last-transaction-time option in the BNDUPD message. no client-last-transaction-time option in the BNDUPD message.
The list in Figure 3 presents the conflict resolution outcome. To The list in Figure 3 presents the conflict resolution outcome. To
"accept" BNDUPD means to update the server's bindings database with "accept" a BNDUPD means to update the server's bindings database with
the information contained in the BNDUDP and once the update is the information contained in the BNDUDP and once the update is
complete, send a BNDACK message corresponding to the BNDUPD message. complete, send a BNDACK message corresponding to the BNDUPD message.
To "reject" a BNDUPD means to lease the server's binding database To "reject" a BNDUPD means to leave the server's binding database
unchangeg and to respond to the BNDUPD with BNDACK with a rejest- unchanged and to respond to the BNDUPD with BNDACK with a reject-
reason option included. reason option included.
When interpreting the information in the following table (Figure 3), When interpreting the information in the following table (Figure 3),
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.
skipping to change at page 32, line 28 skipping to change at page 32, line 31
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.
8.10. Acknowledging Reception 8.9. Acknowledging Reception
Upon acceptance of a binding lease, server must notify its partner Upon acceptance of a binding lease, the server MUST notify its
that it updated its database. Server SHOULD NOT send BNDACK before partner that it updated its database. A server MUST NOT send the
its database is updated. BNDACK MUST contain at lease minimum set of BNDACK before its database is updated. A BNDACK MUST contain at
information required to unabiguously identify BNDUDP. lease the minimum set of information required to unambiguously
identify the BNDUPD that triggered the BNDACK.
9. Endpoint States 9. Endpoint States
9.1. State Machine Operation 9.1. State Machine Operation
Each server (or, more accurately, failover endpoint) can take on a Each server (or, more accurately, failover endpoint) can take on a
variety of failover states. These states play a crucial role in variety of failover states. These states play a crucial role in
determining the actions that a server will perform when processing a determining the actions that a server will perform when processing a
request from a DHCPv6 client as well as dealing with changing request from a DHCPv6 client as well as dealing with changing
external conditions (e.g., loss of connection to a failover partner). external conditions (e.g., loss of connection to a failover partner).
skipping to change at page 33, line 21 skipping to change at page 33, line 24
A server will transition from one failover state to another based on A server will transition from one failover state to another based on
the specific values held by the following state variables: the specific values held by the following state variables:
o Current failover state. o Current failover state.
o Communications status (OK or not OK). o Communications status (OK or not OK).
o Partner's failover state (if known). o Partner's failover state (if known).
Several events can cause the transition from one failover state to Whenever any of the above state variables changes state, the state
another. machine is invoked, which may then trigger a change in the current
failover state. Thus, whenever the communications status changes,
o Change in communications status (OK or not OK); the state machine processing is invoked. This may or may not result
in a change in the current failover state.
o Change in partner's failover state;
o Explicit administrative action;
o Receipt of particular messages;
o Expiration of timers.
Whenever either of the last two of the above state variables changes
state, the state machine is invoked, which may then trigger a change
in the current failove state. Thus, whenever the communications
status changes, the state machine processing is invoked. This may or
may not result in a change in the current failover state.
Whenever a server transitions to a new failover state, the new state Whenever a server transitions to a new failover state, the new state
MUST be communicated to its failover partner in a STATE message if MUST be communicated to its failover partner in a STATE message if
the communications status is OK. In addition, whenever a server the communications status is OK. In addition, whenever a server
makes a transition into a new state, it MUST record the new state, makes a transition into a new state, it MUST record the new state,
its current understanding of its partner's state, and the time at its current understanding of its partner's state, and the time at
which it entered the new state in stable storage. which it entered the new state in stable storage.
The following state transition diagram gives a condensed view of the The following state transition diagram gives a condensed view of the
state machine. If there is a difference between the words describing state machine. If there is a difference between the words describing
skipping to change at page 34, line 40 skipping to change at page 34, line 36
+->+(unresponsive) | for |(unresponsive)| Primary | +->+(unresponsive) | for |(unresponsive)| Primary |
+------+--------+ Other +>+----+--------++ resolve Comm. | +------+--------+ Other +>+----+--------++ resolve Comm. |
Comm. OK State: | | ^ conflict Changed| Comm. OK State: | | ^ conflict Changed|
+---Other State:-+ RECOVER | Secondary | V V | | +---Other State:-+ RECOVER | Secondary | V V | |
| | | DONE | resolve | ++----------+---++ | | | | DONE | resolve | ++----------+---++ |
| All Others: POTENT. | | conflict | |CONFLICT-DONE-|+| | | All Others: POTENT. | | conflict | |CONFLICT-DONE-|+| |
| Wait for CONFLICT--|-----+ | | | (responsive) | | | Wait for CONFLICT--|-----+ | | | (responsive) | |
| Other State: V V | +------+---------+ | | Other State: V V | +------+---------+ |
| NORMAL or RECOVER ++------------+---+ | Other State: NORMAL | | NORMAL or RECOVER ++------------+---+ | Other State: NORMAL |
| | DONE | NORMAL + +<--------------+ | | | DONE | NORMAL + +<--------------+ |
| +--+----------+-->+ (balanced) +-------External Command-->+ | +--+----------+-->+ (responsive) +-------External Command-->+
| ^ ^ +--------+--------+ | | ^ ^ +--------+--------+ |
| | | | | | | | | | | |
| Wait for Comm. OK Comm. Failed | | | Wait for Comm. OK Comm. Failed | |
| Other Other | | External | Other Other | | External
| State: State: | | Command | State: State: | | Command
| RECOVER-DONE NORMAL Start Safe Comm. OK or | RECOVER-DONE NORMAL Start Safe Comm. OK or
| | COMM. INT. Period Timer Other State: Safe | | COMM. INT. Period Timer Other State: Safe
| Comm. OK. | V All Others Period | Comm. OK. | V All Others Period
| Other State: | +---------+--------+ | expiration | Other State: | +---------+--------+ | expiration
| RECOVER +--+ COMMUNICATIONS - +----+ | | RECOVER +--+ COMMUNICATIONS - +----+ |
skipping to change at page 36, line 13 skipping to change at page 36, line 13
should enter. should enter.
The STARTUP state is not shown with any specific state transitions in The STARTUP state is not shown with any specific state transitions in
the state machine diagram (Figure 4) because the processing during the state machine diagram (Figure 4) because the processing during
the STARTUP state can cause the server to transition to any of the the STARTUP state can cause the server to transition to any of the
other states, so that specific state transition arcs would only other states, so that specific state transition arcs would only
obscure other information. obscure other information.
9.3.1. Operation in STARTUP State 9.3.1. Operation in STARTUP State
The server MUST NOT be responsive in STARTUP state. The server MUST NOT be responsive to DHCPv6 clients in STARTUP state.
Whenever a STATE message is sent to the partner while in STARTUP Whenever a STATE message is sent to the partner while in STARTUP
state the STARTUP flag MUST be set in the message and the previously state the STARTUP flag MUST be set in the message and the previously
recorded failover state MUST be placed in the server-state option. recorded failover state MUST be placed in the server-state option.
9.3.2. Transition Out of STARTUP State 9.3.2. Transition Out of STARTUP State
The following algorithm is followed every time the server initializes The following algorithm is followed every time the server initializes
itself, and enters STARTUP state. itself, and enters STARTUP state.
skipping to change at page 36, line 50 skipping to change at page 36, line 50
responsibilities as a DHCP server nonetheless. To properly handle responsibilities as a DHCP server nonetheless. To properly handle
this situation, a server SHOULD be configurable in such a way as to this situation, a server SHOULD be configurable in such a way as to
move directly into PARTNER-DOWN state after the startup period move directly into PARTNER-DOWN state after the startup period
expires if it has been unable to contact its partner during the expires if it has been unable to contact its partner during the
startup period. startup period.
Step 2: Step 2:
Implementations will differ in the ways that they deal with the state Implementations will differ in the ways that they deal with the state
machine for failover endpoint states. In many cases, state machine for failover endpoint states. In many cases, state
transitions will occur when communications goes from "OK" to failoed, transitions will occur when communications goes from "OK" to failed,
or from failed to "OK", and some implementations will implement a or from failed to "OK", and some implementations will implement a
portion of their state machine processing based on these changes. portion of their state machine processing based on these changes.
In these cases, during startup, if the previous state is one where In these cases, during startup, if the previous state is one where
communications was "OK", then set the previous state to the state communications was "OK", then set the previous state to the state
that is the result of the communications failed state transition when that is the result of the communications failed state transition when
in that state (if such transition exists -- some states don't have a in that state (if such transition exists -- some states don't have a
communications failed state transition, since they allow both communications failed state transition, since they allow both
communications OK and failed). communications OK and failed).
skipping to change at page 38, line 14 skipping to change at page 38, line 14
9.4. PARTNER-DOWN State 9.4. PARTNER-DOWN State
PARTNER-DOWN state is a state either server can enter. When in this PARTNER-DOWN state is a state either server can enter. When in this
state, the server assumes that it is the only server operating and state, the server assumes that it is the only server operating and
serving the client base. If one server is in PARTNER-DOWN state, the serving the client base. If one server is in PARTNER-DOWN state, the
other server MUST NOT be operating. other server MUST NOT be operating.
A server can enter PARTNER-DOWN state either as a result of operator A server can enter PARTNER-DOWN state either as a result of operator
intervention (when an operator determines that the server's partner intervention (when an operator determines that the server's partner
is, indeed, down), or as a result of the auto-partner-down capability is, indeed, down), or as a result of an optional auto-partner-down
where PARTNER-DOWN state is entered automatically after a server has capability where PARTNER-DOWN state is entered automatically after a
been in COMMUNICATIONS-INTERRUPTED state for a pre-determined period server has been in COMMUNICATIONS-INTERRUPTED state for a pre-
of time. determined period of time.
9.4.1. Operation in PARTNER-DOWN State 9.4.1. Operation in PARTNER-DOWN State
The server MUST be responsive in PARTNER-DOWN state, regardess if it The server MUST be responsive in PARTNER-DOWN state, regardless if it
is primary or secondary. is primary or secondary.
It will allow renewal of all outstanding leases on addresses or It will allow renewal of all outstanding leases on resources. For
prefixes. For those resources for which the server is using those resources for which the server is using proportional
proportional allocation, it will allocate resources from its own allocation, it will allocate resources from its own pool, and after a
pool, and after a fixed period of time (the MCLT interval) has fixed period of time (the MCLT interval) has elapsed from entry into
elapsed from entry into PARTNER-DOWN state, it may allocate IP PARTNER-DOWN state, it may allocate IP addresses from the set of all
addresses from the set of all available pools. Server SHOULD fully available pools. Server SHOULD fully deplete its own pool, before
deplete its own pool, before starting allocations from its downed starting allocations from its downed partner's pool.
partner.
Any resource tagged as available for allocation by the other server Any resource tagged as available for allocation by the other server
(at entry to PARTNER-DOWN state) MUST NOT be allocated to a new (at entry to PARTNER-DOWN state) MUST NOT be allocated to a new
client until the MCLT beyond the entry into PARTNER-DOWN state has client until the MCLT beyond the entry into PARTNER-DOWN state has
elapsed. elapsed.
A server in PARTNER-DOWN state MUST NOT allocate a resource to a DHCP A server in PARTNER-DOWN state MUST NOT allocate a resource to a DHCP
client different from that to which it was allocated at the entrance client different from that to which it was allocated at the entrance
to PARTNER-DOWN state until the MCLT beyond the maximum of the to PARTNER-DOWN state until the MCLT beyond the maximum of the
following times: client expiration time, most recently transmitted following times: client expiration time, most recently transmitted
potential-expiration-time, most recently received ack of potential- potential-expiration-time, most recently received ack of potential-
expiration-time from the partner, and most recently acked potential- expiration-time from the partner, and most recently acked potential-
expiration-time to the partner. If this time would be earlier than expiration-time to the partner. If this time would be earlier than
the current time plus the maximum-client-lead-time, then the time the the current time plus the maximum-client-lead-time, then the time the
server entered PARTNER-DOWN state plus the maximum-client-lead-time server entered PARTNER-DOWN state plus the maximum-client-lead-time
is used. is used.
The server is not restricted by the MCLT when offering lease times The server is not restricted by the MCLT when offering lease times
while in PARTNER-DOWN state. while in PARTNER-DOWN state.
In the unlikely case, when there are two servers operating in a In the unlikely case when there are two servers operating in a
PARTNER-DOWN state, there is a chance of duplicate leases assigned. PARTNER-DOWN state, there is a chance of duplicate leases assigned.
This leads to a POTENTIAL-CONFLICT (unresponsive) state when they re- This leads to a POTENTIAL-CONFLICT (unresponsive) state when they re-
establish contact. The duplicate lease issue can be postponed to a establish contact. The duplicate lease issue can be postponed to a
large extent by the server granting new leases first from its own large extent by the server granting new leases first from its own
pool. Therefore the server operating in PARTNER-DOWN state MUST use pool. Therefore the server operating in PARTNER-DOWN state MUST use
its own pool first for new leases before assigning any leases from its own pool first for new leases before assigning any leases from
its downed partner pool. its downed partner pool.
9.4.2. Transition Out of PARTNER-DOWN State 9.4.2. Transition Out of PARTNER-DOWN State
When a server in PARTNER-DOWN state succeeds in establishing a con- When a server in PARTNER-DOWN state succeeds in establishing a
nection to its partner, its actions are conditional on the state and connection to its partner, its actions are conditional on the state
flags received in the STATE message from the other server as part of and flags received in the STATE message from the other server as part
the process of establishing the connection. of the process of establishing the connection.
If the STARTUP bit is set in the server-flags option of a received If the STARTUP bit is set in the server-flags option of a received
STATE message, a server in PARTNER-DOWN state MUST NOT take any state STATE message, a server in PARTNER-DOWN state MUST NOT take any state
transitions based on reestablishing communications. Essentially, if transitions based on reestablishing communications. Essentially, if
a server is in PARTNER-DOWN state, it ignores all STATE messages from a server is in PARTNER-DOWN state, it ignores all STATE messages from
its partner that have the STARTUP bit set in the server-flags option its partner that have the STARTUP bit set in the server-flags option
of the STATE message. of the STATE message.
If the STARTUP bit is not set in the server-flags option of a STATE If the STARTUP bit is not set in the server-flags option of a STATE
message received from its partner, then a server in PARTNER-DOWN message received from its partner, then a server in PARTNER-DOWN
state takes the following actions based on the state of the partner state takes the following actions based on the state of the partner
as received in a STATE message (either immediately after establishing as received in a STATE message (either immediately after establishing
communications or at any time later when a new state is received) communications or at any time later when a new state is received)
If the partner is in: o If the partner is in: [ NORMAL, COMMUNICATIONS-INTERRUPTED,
PARTNER-DOWN, POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or
NORMAL, COMMUNICATIONS-INTERRUPTED, PARTNER-DOWN, POTENTIAL-CONFLICT, CONFLICT-DONE ] state, then transition to POTENTIAL-CONFLICT state
RESOLUTION-INTERRUPTED, or CONFLICT-DONE state
transition to POTENTIAL-CONFLICT state
If the partner is in:
RECOVER, RECOVER-WAIT state
stay in PARTNER-DOWN state
If the partner is in:
RECOVER-DONE state o If the partner is in: [ RECOVER, RECOVER-WAIT ] state stay in
PARTNER-DOWN state
transition into NORMAL state o If the partner is in: [ RECOVER-DONE ] state transition into
NORMAL state
9.5. RECOVER State 9.5. RECOVER State
This state indicates that the server has no information in its stable This state indicates that the server has no information in its stable
storage or that it is re-integrating with a server in PARTNER-DOWN storage or that it is re-integrating with a server in PARTNER-DOWN
state after it has been down. A server in this state MUST attempt to state after it has been down. A server in this state MUST attempt to
refresh its stable storage from the other server. refresh its stable storage from the other server.
9.5.1. Operation in RECOVER State 9.5.1. Operation in RECOVER State
skipping to change at page 41, line 34 skipping to change at page 41, line 23
| >--STATE-(RECOVER-DONE)------> | | >--STATE-(RECOVER-DONE)------> |
| NORMAL | NORMAL
| <-------------(NORMAL)-STATE--< | | <-------------(NORMAL)-STATE--< |
NORMAL | NORMAL |
| >---- State-(NORMAL)---------------> | | >---- State-(NORMAL)---------------> |
| | | |
| | | |
Figure 5: Transition out of RECOVER state Figure 5: Transition out of RECOVER state
If, at any time while a server is in RECOVER state communications If at any time while a server is in RECOVER state communications
fails, the server will stay in RECOVER state. When communications fails, the server will stay in RECOVER state. When communications
are restored, it will restart the process of transitioning out of are restored, it will restart the process of transitioning out of
RECOVER state. RECOVER state.
9.6. RECOVER-WAIT State 9.6. RECOVER-WAIT State
This state indicates that the server has done an UPDREQ or UPDREQALL This state indicates that the server has sent an UPDREQ or UPDREQALL
and has received the UPDDONE message indicating that it has received and has received the UPDDONE message indicating that it has received
all outstanding binding update information. In the RECOVER-WAIT all outstanding binding update information. In the RECOVER-WAIT
state the server will wait for the MCLT in order to ensure that any state the server will wait for the MCLT in order to ensure that any
processing that this server might have done prior to losing its processing that this server might have done prior to losing its
stable storage will not cause future difficulties. stable storage will not cause future difficulties.
9.6.1. Operation in RECOVER-WAIT State 9.6.1. Operation in RECOVER-WAIT State
The server MUST NOT be responsive in RECOVER-WAIT state. The server MUST NOT be responsive in RECOVER-WAIT state.
skipping to change at page 42, line 31 skipping to change at page 42, line 19
be skipped, and the server MAY transition immediately to RECOVER-DONE be skipped, and the server MAY transition immediately to RECOVER-DONE
state. state.
If the server has never before run failover, then there is no need to If the server has never before run failover, then there is no need to
wait in this state -- but, again, to determine if this server has run wait in this state -- but, again, to determine if this server has run
failover it is vital that the information provided by the partner be failover it is vital that the information provided by the partner be
utilized, since the stable storage of this server may have been lost. utilized, since the stable storage of this server may have been lost.
If communications fails while a server is in RECOVER-WAIT state, it If communications fails while a server is in RECOVER-WAIT state, it
has no effect on the operation of this state. The server SHOULD has no effect on the operation of this state. The server SHOULD
continue to operate its timer, and the timer expires during the continue to operate its timer, and if the timer expires during the
period where communications with the other server have failed, then period where communications with the other server have failed, then
the server SHOULD transition to RECOVER-DONE state. This is rare -- the server SHOULD transition to RECOVER-DONE state. This is rare --
failover state transitions are not usually made while communications failover state transitions are not usually made while communications
are interrupted, but in this case there is no reason to inhibit the are interrupted, but in this case there is no reason to inhibit the
timer. timer.
9.7. RECOVER-DONE State 9.7. RECOVER-DONE State
This state exists to allow an interlocked transition for one server This state exists to allow an interlocked transition for one server
from RECOVER state and another server from PARTNER-DOWN or from RECOVER state and another server from PARTNER-DOWN or
COMMUNICATIONS-INTERRUPTED state into NORMAL state. COMMUNICATIONS-INTERRUPTED state into NORMAL state.
9.7.1. Operation in RECOVER-DONE State 9.7.1. Operation in RECOVER-DONE State
A server in RECOVER-DONE state MUST respond only to RENEW, REBIND, A server in RECOVER-DONE state SHOULD be unresponsive, but MAY
CONFIRM and INFORMATION-REQUEST client messages. respond to RENEW requests but MUST only change the state of resources
that appear in the RENEW request. It MUST NOT allocate any
additional resources when in RECOVER-DONE state.
9.7.2. Transition Out of RECOVER-DONE State 9.7.2. Transition Out of RECOVER-DONE State
When a server in RECOVER-DONE state determines that its partner When a server in RECOVER-DONE state determines that its partner
server has entered NORMAL or RECOVER-DONE state, then it will server has entered NORMAL or RECOVER-DONE state, then it will
transition into NORMAL state. transition into NORMAL state.
If communication fails while in RECOVER-DONE state, a server will If communication fails while in RECOVER-DONE state, a server will
stay in RECOVER-DONE state. stay in RECOVER-DONE state.
9.8. NORMAL State 9.8. NORMAL State
NORMAL state is the state used by a server when it is communicating NORMAL state is the state used by a server when it is communicating
skipping to change at page 43, line 35 skipping to change at page 43, line 29
9.8.1. Operation in NORMAL State 9.8.1. Operation in NORMAL State
Primary server is responsive in NORMAL state. Secondary is Primary server is responsive in NORMAL state. Secondary is
unresponsive in NORMAL state. unresponsive in NORMAL state.
When in NORMAL state a primary server will operate in the following When in NORMAL state a primary server will operate in the following
manner: manner:
Lease time calculations Lease time calculations
As discussed in Section 8.4, the lease interval given to a DHCP As discussed in Section 8.3, the lease interval given to a DHCP
client can never be more than the MCLT greater than the most client can never be more than the MCLT greater than the most
recently received potential-expiration-time from the failover recently received potential-expiration-time from the failover
partner or the current time, whichever is later. partner or the current time, whichever is later.
As long as a server adheres to this constraint, the specifics of As long as a server adheres to this constraint, the specifics of
the lease interval that it gives to a DHCP client or the value of the lease interval that it gives to a DHCP client or the value of
the potential-expiration-time sent to its failover partner are the potential-expiration-time sent to its failover partner are
implementation dependent. implementation dependent.
Lazy update of partner server Lazy update of partner server
After sending an REPLY that includes lease update to a client, the After sending a REPLY that includes a lease update to a client,
server servicing a DHCP client request attempts to update its the server servicing a DHCP client request attempts to update its
partner with the new binding information. Server transmits both partner with the new binding information.
desired valid lifetime and actual valid lifetime.
Reallocation of resources between clients Reallocation of resources between clients
Whenever a client binding is released or expires, a BNDUPD message Whenever a client binding is released or expires, a BNDUPD message
must be sent to the partner, setting the binding state to RELEASED must be sent to the partner, setting the binding state to RELEASED
or EXPIRED. However, until a BNDACK is received for this message, or EXPIRED. However, until a BNDACK is received for this message,
the resource cannot be allocated to another client. It cannot be the resource cannot be allocated to another client. It cannot be
allocated to the same client again if a BNDUPD was sent, otherwise allocated to the same client again if a BNDUPD was sent, otherwise
it can. See Section 8.6 for details. it can. See Section 8.5 for details.
In NORMAL state, each server receives binding updates from its In NORMAL state, each server receives binding updates from its
partner server in BNDUPD messages. It records these in its client partner server in BNDUPD messages. It records these in its client
binding database in stable storage and then sends a corresponding binding database in stable storage and then sends a corresponding
BNDACK message to its partner server. BNDACK message to its partner server.
9.8.2. Transition Out of NORMAL State 9.8.2. Transition Out of NORMAL State
If an external command is received by a server in NORMAL state If an external command is received by a server in NORMAL state
informing it that its partner is down, then transition into PARTNER- informing it that its partner is down, then transition into PARTNER-
DOWN state. Generally, this would be an unusual situation, where DOWN state. Generally, this would be an unusual situation, where
some external agency knew the partner server was down. Using the some external agency knew the partner server was down prior to the
command in this case would be appropriate if the polling interval and failover server discovering it on its own.
timeout were long.
If a server in NORMAL state fails to receive acks to messages sent to If a server in NORMAL state fails to receive acks to messages sent to
its partner for an implementation dependent period of time, it MAY its partner for an implementation dependent period of time, it MAY
move into COMMUNICATIONS-INTERRUPTED state. This situation might move into COMMUNICATIONS-INTERRUPTED state. This situation might
occur if the partner server was capable of maintaining the TCP con- occur if the partner server was capable of maintaining the TCP
nection between the server and also capable of sending a CONTACT mes- connection between the server and also capable of sending a CONTACT
sage periodically, but was (for some reason) incapable of pro- message periodically, but was (for some reason) incapable of
cessing BNDUPD messages. processing BNDUPD messages.
If the communications is determined to not be "ok" (as defined in If the communications is determined to not be "ok" (as defined in
Section 8.5), then transition into COMMUNICATIONS-INTERRUPTED state. Section 8.4), then transition into COMMUNICATIONS-INTERRUPTED state.
If a server in NORMAL state receives any messages from its partner If a server in NORMAL state receives any messages from its partner
where the partner has changed state from that expected by the server where the partner has changed state from that expected by the server
in NORMAL state, then the server should transition into in NORMAL state, then the server should transition into
COMMUNICATIONS-INTERRUPTED state and take the appropriate state tran- COMMUNICATIONS-INTERRUPTED state and take the appropriate state
sition from there. For example, it would be expected for the partner transition from there. For example, it would be expected for the
to transition from POTENTIAL-CONFLICT into NORMAL state, but not for partner to transition from POTENTIAL-CONFLICT into NORMAL state, but
the partner to transition from NORMAL into POTENTIAL-CONFLICT state. not for the partner to transition from NORMAL into POTENTIAL-CONFLICT
state.
If a server in NORMAL state receives a DISCONNECT message from its If a server in NORMAL state receives a DISCONNECT message from its
partner, the server should transition into COMMUNICATIONS-INTERRUPTED partner, the server should transition into COMMUNICATIONS-INTERRUPTED
state. state.
9.9. COMMUNICATIONS-INTERRUPTED State 9.9. COMMUNICATIONS-INTERRUPTED State
A server goes into COMMUNICATIONS-INTERRUPTED state whenever it is A server goes into COMMUNICATIONS-INTERRUPTED state whenever it is
unable to communicate with its partner. Primary and secondary unable to communicate with its partner. Primary and secondary
servers cycle automatically (without administrative intervention) servers cycle automatically (without administrative intervention)
between NORMAL and COMMUNICATIONS-INTERRUPTED state as the network between NORMAL and COMMUNICATIONS-INTERRUPTED state as the network
connection between them fails and recovers, or as the partner server connection between them fails and recovers, or as the partner server
cycles between operational and non-operational. No duplicate cycles between operational and non-operational. No duplicate
resource allocation can occur while the servers cycle between these resource allocation can occur while the servers cycle between these
states. states.
When a server enters COMMUNICATIONS-INTERRUPTED state, if it has been When a server enters COMMUNICATIONS-INTERRUPTED state, if it has been
configured to support an automatic transition out of COMMUNICATIONS- configured to support an automatic transition out of COMMUNICATIONS-
INTERRUPTED state and into PARTNER-DOWN state (i.e., a "safe period" INTERRUPTED state and into PARTNER-DOWN state (i.e., a auto-partner-
has been configured, see section TODO), then a timer MUST be started down has been configured), then a timer MUST be started for the
for the length of the configured safe period. length of the configured auto-partner-down period.
A server transitioning into the COMMUNICATIONS-INTERRUPTED state from A server transitioning into the COMMUNICATIONS-INTERRUPTED state from
the NORMAL state SHOULD raise some alarm condition to alert the NORMAL state SHOULD raise some alarm condition to alert
administrative staff to a potential problem in the DHCP subsystem. administrative staff to a potential problem in the DHCP subsystem.
9.9.1. Operation in COMMUNICATIONS-INTERRUPTED State 9.9.1. Operation in COMMUNICATIONS-INTERRUPTED State
In this state a server MUST respond to all DHCP client requests. In this state a server MUST respond to all DHCP client requests.
When allocating new leases, each server allocates from its own pool, When allocating new leases, each server allocates from its own pool,
where the primary MUST allocate only FREE resources (addresses or where the primary MUST allocate only FREE resources, and the
prefixes), and the secondary MUST allocate only FREE_BACKUP resources secondary MUST allocate only FREE_BACKUP resources. When responding
(addresses or prefixes). When responding to RENEW messages, each to RENEW messages, each server will allow continued renewal of a DHCP
server will allow continued renewal of a DHCP client's current lease client's current lease on a resource irrespective of whether that
on an IP address or prefix irrespective of whether that lease was lease was given out by the receiving server or not, although the
given out by the receiving server or not, although the renewal period renewal period MUST NOT exceed the maximum client lead time (MCLT)
MUST NOT exceed the maximum client lead time (MCLT) beyond the latest beyond the latest of: 1) the potential valid lifetime already
of: 1) the potential valid lifetime already acknowledged by the other acknowledged by the other server, or 2) now, or 3) the potential
server, or 2) the actual valid lifetime sent to the DHCPv6 client, or valid lifetime received from the partner server.
3) the potential valid lifetime received from the partner server.
However, since the server cannot communicate with its partner in this However, since the server cannot communicate with its partner in this
state, the acknowledged potential valid lifetime will not be updated state, the acknowledged potential valid lifetime will not be updated
in any new bindings. This is likely to eventually cause the actual in any new bindings. This is likely to eventually cause the actual
valid lifetimes to be the current time plus the MCLT (unless this is valid lifetimes to converge to the MCLT (unless this is greater than
greater than the desired-client-lease-time). the desired-client-lease-time).
The server should continue to try to establish a connection with its The server should continue to try to establish a connection with its
partner. partner.
9.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State 9.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State
If the safe period timer expires while a server is in the If the safe period timer expires while a server is in the
COMMUNICATIONS-INTERRUPTED state, it will transition immediately into COMMUNICATIONS-INTERRUPTED state, it will transition immediately into
PARTNER-DOWN state. PARTNER-DOWN state.
skipping to change at page 47, line 4 skipping to change at page 46, line 45
| >--STATE---------------------> | | >--STATE---------------------> |
| |
| >--BNDUPD--------------------> | | >--BNDUPD--------------------> |
| <---------------------BNDACK--< | | <---------------------BNDACK--< |
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
| >------BNDACK----------------> | | >------BNDACK----------------> |
... ... ... ...
| | | |
| <--------------------POOLREQ--< | | <--------------------POOLREQ--< |
| >--POOLRESP-(2)--------------> | | >--POOLRESP------------------> |
| | | |
| >--BNDUPD-(#1)---------------> | | >--BNDUPD-(#1)---------------> |
| <---------------------BNDACK--< | | <---------------------BNDACK--< |
| | | |
| <--------------------POOLREQ--< |
| >--POOLRESP-(0)--------------> |
| |
| >--BNDUPD-(#2)---------------> | | >--BNDUPD-(#2)---------------> |
| <---------------------BNDACK--< | | <---------------------BNDACK--< |
| | | |
Figure 6: Transition from NORMAL to COMMUNICATIONS-INTERRUPTED and Figure 6: Transition from NORMAL to COMMUNICATIONS-INTERRUPTED and
back (example with 2 addresses allocated to secondary) back (example with 2 addresses allocated to secondary)
9.10. POTENTIAL-CONFLICT State 9.10. POTENTIAL-CONFLICT State
This state indicates that the two servers are attempting to This state indicates that the two servers are attempting to
skipping to change at page 48, line 48 skipping to change at page 48, line 34
| >--BNDUPD--------------------> | | >--BNDUPD--------------------> |
| <---------------------BNDACK--< | | <---------------------BNDACK--< |
| | | |
| >--UPDDONE-------------------> | | >--UPDDONE-------------------> |
| NORMAL | NORMAL
| <------------STATE--(NORMAL)--< | | <------------STATE--(NORMAL)--< |
NORMAL | NORMAL |
| >--STATE--(NORMAL)-----------> | | >--STATE--(NORMAL)-----------> |
| | | |
| <--------------------POOLREQ--< | | <--------------------POOLREQ--< |
| >------POOLRESP-(n)----------> | | >------POOLRESP--------------> |
| addresses | | |
Figure 7: Transition out of POTENTIAL-CONFLICT Figure 7: Transition out of POTENTIAL-CONFLICT
9.11. RESOLUTION-INTERRUPTED State 9.11. RESOLUTION-INTERRUPTED State
This state indicates that the two servers were attempting to This state indicates that the two servers were attempting to
reintegrate with each other in POTENTIAL-CONFLICT state, but reintegrate with each other in POTENTIAL-CONFLICT state, but
communications failed prior to completion of re-integration. communications failed prior to completion of re-integration.
If the servers remained in POTENTIAL-CONFLICT while communications The RESOLUTION-INTERRUPTED state exists because servers are not
was interrupted, neither server would be responsive to DHCP client responsive in POTENTIAL-CONFLICT state, and if one server drops out
requests, and if one server had crashed, then there might be no of service while both servers are in POTENTIAL-CONFLICT state, the
server able to process DHCP requests. server that remains in service will not be able to process DHCP
client requests and there will be no DHCP service available. The
RESOLUTION-INTERRUPTED state is the state that a server moves to if
its partner disappears while it is in POTENTIAL-CONFLICT state.
When a server enters RESOLUTION-INTERRUPTED state it SHOULD raise an When a server enters RESOLUTION-INTERRUPTED state it SHOULD raise an
alarm condition to alert administrative staff of a problem in the alarm condition to alert administrative staff of a problem in the
DHCP subsystem. DHCP subsystem.
9.11.1. Operation in RESOLUTION-INTERRUPTED State 9.11.1. Operation in RESOLUTION-INTERRUPTED State
In this state a server MUST respond to all DHCP client requests. In this state a server MUST respond to all DHCP client requests.
When allocating new resources (addresses or prefixes), each server When allocating new resources, each server SHOULD allocate from its
SHOULD allocate from its own pool (if that can be determined), where own pool (if that can be determined), where the primary SHOULD
the primary SHOULD allocate only FREE resources, and the secondary allocate only FREE resources, and the secondary SHOULD allocate only
SHOULD allocate only BACKUP resources. When responding to renewal FREE_BACKUP resources. When responding to renewal requests, each
requests, each server will allow continued renewal of a DHCP client's server will allow continued renewal of a DHCP client's current lease
current lease independent of whether that lease was given out by the independent of whether that lease was given out by the receiving
receiving server or not, although the renewal period MUST NOT exceed server or not, although the renewal period MUST NOT exceed the
the maximum client lead time (MCLT) beyond the latest of: 1) the maximum client lead time (MCLT) beyond the latest of: 1) the
potential valid lifetime already acknowledged by the other server or potential valid lifetime already acknowledged by the other server or
2) the lease-expiration-time or 3) potential valid lifetime received 2) now or 3) potential valid lifetime received from the partner
from the partner server. server.
However, since the server cannot communicate with its partner in this However, since the server cannot communicate with its partner in this
state, the acknowledged potential valid lifetime will not be updated state, the acknowledged potential valid lifetime will not be updated
in any new bindings. in any new bindings.
9.11.2. Transition Out of RESOLUTION-INTERRUPTED State 9.11.2. Transition Out of RESOLUTION-INTERRUPTED State
If an external command is received by a server in RESOLUTION- If an external command is received by a server in RESOLUTION-
INTERRUPTED state informing it that its partner is down, it will INTERRUPTED state informing it that its partner is down, it will
transition immediately into PARTNER-DOWN state. transition immediately into PARTNER-DOWN state.
If communications is restored with the other server, then the server If communications is restored with the other server, then the server
in RESOLUTION-INTERRUPTED state will transition into POTENTIAL- in RESOLUTION-INTERRUPTED state will transition into POTENTIAL-
CONFLICT state. CONFLICT state.
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 makes
transition into CONFLICT-DONE state in order that it may be totally a transition into CONFLICT-DONE state in order that it may be totally
responsive to the client load. There is no operational difference responsive to the client load. There is no operational difference
between CONFLICT-DONE and NORMAL for primary as in both states it between CONFLICT-DONE and NORMAL for primary as in both states it
responds to all clients' requests. The distinction between CONFLICT- responds to all clients' requests. The distinction between CONFLICT-
DONE and NORMAL states will be more apparent when load balancing DONE and NORMAL states will be more apparent when load balancing
extension will be defined. extension will be defined.
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.
9.12.2. Transition Out of CONFLICT-DONE State 9.12.2. Transition Out of CONFLICT-DONE State
skipping to change at page 50, line 42 skipping to change at page 50, line 32
The following section discusses possible extensions to the proposed The following section discusses possible extensions to the proposed
failover mechanism. Listed extensions must be sufficiently simple to failover mechanism. Listed extensions must be sufficiently simple to
not further complicate failover protocol. Any proposals that are not further complicate failover protocol. Any proposals that are
considered complex will be defined as stand-alone extensions in considered complex will be defined as stand-alone extensions in
separate documents. separate documents.
10.1. Active-active mode 10.1. Active-active mode
A very simple way to achieve active-active mode is to remove the A very simple way to achieve active-active mode is to remove the
restriction that seconary server MUST NOT respond to SOLICIT and restriction that secondary server MUST NOT respond to SOLICIT and
REQUEST messages. Instead it could respond, but MUST have lower REQUEST messages. Instead it could respond, but MUST have lower
preference than primary server. Clients discovering available preference than primary server. Clients discovering available
servers will receive ADVERTISE messages from both servers, but are servers will receive ADVERTISE messages from both servers, but are
expected to select the primary server as it has higher preference expected to select the primary server as it has higher preference
value configured. The following REQUEST message will be directed to value configured. The following REQUEST message will be directed to
primary server. primary server.
Discussion: Do DHCPv6 clients actually do this? DHCPv4 clients were
rumored to wait for a "while" to accept the best offer, but to a
first approximation, they all take the first offer they receive that
is even acceptable.
The benefit of this approach, compared to the "basic" active--passive The benefit of this approach, compared to the "basic" active--passive
solution is that there is no delay between primary failure and the solution is that there is no delay between primary failure and the
moment when secondary starts serving requests. moment when secondary starts serving requests.
11. Dynamic DNS Considerations 11. Dynamic DNS Considerations
DHCP servers (and clients) can use DNS Dynamic Updates as described DHCP servers (and clients) can use DNS Dynamic Updates as described
in RFC 2136 [RFC2136] to maintain DNS name-mappings as they maintain in RFC 2136 [RFC2136] to maintain DNS name-mappings as they maintain
DHCP leases. Many different administrative models for DHCP-DNS DHCP leases. Many different administrative models for DHCP-DNS
integration are possible. Descriptions of several of these models, integration are possible. Descriptions of several of these models,
and guidelines that DHCP servers and clients should follow in and guidelines that DHCP servers and clients should follow in
carrying them out, are laid out in RFC 4704 [RFC4704]. carrying them out, are laid out in RFC 4704 [RFC4704].
The nature of the failover protocol introduces some issues concerning The nature of the failover protocol introduces some issues concerning
dynamic DNS updates that are not part of non-failover environments. dynamic DNS (DDNS) updates that are not part of non-failover
This section describes these issues, and defines the information environments. This section describes these issues, and defines the
which failover partners should exchange in order to ensure consistent information which failover partners should exchange in order to
behavior. The presence of this section should not be interpreted as ensure consistent behavior. The presence of this section should not
requiring an implementation of the DHCPv6 failover protocol to also be interpreted as requiring an implementation of the DHCPv6 failover
support DDNS updates. protocol to also support DDNS updates.
The purpose of this discussion is to clarify the areas where the The purpose of this discussion is to clarify the areas where the
failover and DHCP-DDNS protocols intersect for the benefit of failover and DHCP-DDNS protocols intersect for the benefit of
implementations which support both protocols, not to introduce a new implementations which support both protocols, not to introduce a new
requirement into the DHCPv6 failover protocol. Thus, a DHCPv6 server requirement into the DHCPv6 failover protocol. Thus, a DHCPv6 server
which implements the failover protocol MAY also support dynamic DNS which implements the failover protocol MAY also support dynamic DNS
updates, but if it does support dynamic DNS updates it SHOULD utilize updates, but if it does support dynamic DNS updates it SHOULD utilize
the techniques described here in order to correctly distribute them the techniques described here in order to correctly distribute them
between the failover partners. See RFC 4704 [RFC4704] as well as RFC between the failover partners. See RFC 4704 [RFC4704] as well as RFC
4703 [RFC4703] for information on how DHCPv6 servers deal with 4703 [RFC4703] for information on how DHCPv6 servers deal with
skipping to change at page 51, line 48 skipping to change at page 51, line 33
From the standpoint of the failover protocol, there is no reason why 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 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 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 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 to support DDNS or is not configured to support DDNS SHOULD output a
warning message when it receives BNDUPD messages which indicate that warning message when it receives BNDUPD messages which indicate that
its failover partner is configured to support the DDNS protocol to its failover partner is configured to support the DDNS protocol to
update a DNS server. An implementation MAY consider this an error update a DNS server. An implementation MAY consider this an error
and refuse to operate, or it MAY choose to operate anyway, having and refuse to operate, or it MAY choose to operate anyway, having
warned the user of the problem in some way. warned the administrator of the problem in some way.
11.1. Relationship between failover and dynamic DNS update 11.1. Relationship between failover and dynamic DNS update
The failover protocol describes the conditions under which each The failover protocol describes the conditions under which each
failover server may renew a lease to its current DHCP client, and 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 describes the conditions under which it may grant a lease to a new
DHCP client. An analogous set of conditions determines when a DHCP client. An analogous set of conditions determines when a
failover server should initiate a DDNS update, and when it should failover server should initiate a DDNS update, and when it should
attempt to remove records from the DNS. The failover protocol's attempt to remove records from the DNS. The failover protocol's
conditions are based on the desired external behavior: avoiding conditions are based on the desired external behavior: avoiding
duplicate address and prefix assignments; allowing clients to duplicate address and prefix assignments; allowing clients to
continue using leases which they obtained from one failover partner continue using leases which they obtained from one failover partner
even if they can only communicate with the other partner; allowing even if they can only communicate with the other partner; allowing
skipping to change at page 53, line 33 skipping to change at page 53, line 18
These data items are the minimum necessary set to reliably allow two These data items are the minimum necessary set to reliably allow two
failover partners to successfully share the responsibility to keep failover partners to successfully share the responsibility to keep
the DNS up to date with the resources allocated to clients. the DNS up to date with the resources allocated to clients.
This information would typically be included in BNDUPD messages sent This information would typically be included in BNDUPD messages sent
from one failover partner to the other. Failover servers MAY choose from one failover partner to the other. Failover servers MAY choose
not to include this information in BNDUPD messages if there has been 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. no change in the status of any DDNS update related to the lease.
The partner server receiving BNDUPD messages containing the DDNS The partner server receiving BNDUPD messages containing the DDNS
information SHOULD compare the status informatin and the FQDN with information SHOULD compare the status information and the FQDN with
the current DDNS information it has associated with the lease the current DDNS information it has associated with the lease
binding, and update its notion of the DDNS status accordingly. binding, and update its notion of the DDNS status accordingly.
Some implementations will instead choose to send a BNDUPD without Some implementations will instead choose to send a BNDUPD without
waiting for the DDNS update to complete, and then will send a second waiting for the DDNS update to complete, and then will send a second
BNDUPD once the DDNS update is complete. Other implementations will BNDUPD once the DDNS update is complete. Other implementations will
delay sending the partner a BNDUPD until the DDNS update has been delay sending the partner a BNDUPD until the DDNS update has been
acknowledged by the DNS server, or until some time-limit has elapsed, acknowledged by the DNS server, or until some time-limit has elapsed,
in order to avoid sending a second BNDUPD. in order to avoid sending a second BNDUPD.
skipping to change at page 55, line 16 skipping to change at page 54, line 47
partner is no longer attempting to perform an update for the partner is no longer attempting to perform an update for the
existing client. If the remaining server has not recorded that existing client. If the remaining server has not recorded that
an update for the binding has been successfully completed, the an update for the binding has been successfully completed, the
server MAY initiate a DDNS update. It MAY initiate this update server MAY initiate a DDNS update. It MAY initiate this update
immediately upon entry to PARTNER-DOWN state, it may perform this immediately upon entry to PARTNER-DOWN state, it may perform this
in the background, or it MAY initiate this update upon next in the background, or it MAY initiate this update upon next
hearing from the DHCP client. hearing from the DHCP client.
11.4. Deleting RRs from the DNS 11.4. Deleting RRs from the DNS
The failover server which makes a resource FREE SHOULD initiate any The failover server which makes a resource FREE* SHOULD initiate any
DDNS deletes, if it has recorded that DNS records were added on DDNS deletes, if it has recorded that DNS records were added on
behalf of the client. behalf of the client.
A server not in PARTNER-DOWN state "makes a resource FREE" when it A server not in PARTNER-DOWN state "makes a resource FREE" when it
initiates a BNDUPD with a binding-status of FREE, FREE_BACKUP, initiates a BNDUPD with a binding-status of FREE, FREE_BACKUP,
EXPIRED, or RELEASED. Its partner confirms this status by acking EXPIRED, or RELEASED. Its partner confirms this status by acking
that BNDUPD, and upon receipt of the BNDACK the server has "made the 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". Conversely, a server in PARTNER-DOWN state "makes a
resource FREE" when it sets the binding-status to FREE, since in resource FREE" when it sets the binding-status to FREE, since in
PARTNER-DOWN state no communications is required with the partner. PARTNER-DOWN state no communications is required with the partner.
It is at this point that it should initiate the DDNS operations to It is at this point that it should initiate the DDNS operations to
delete RRs from the DDNS. Its partner SHOULD NOT initiate DDNS delete RRs from the DDNS. Its partner SHOULD NOT initiate DDNS
deletes for DNS records related to the lease binding as part of deletes for DNS records related to the lease binding as part of
sending the BNDACK message. The partner MAY have issued BNDUPD sending the BNDACK message. The partner MAY have issued BNDUPD
messages with a binding-status of FREE, EXPIRED, or RELEASED messages with a binding-status of FREE, EXPIRED, or RELEASED
previously, but the other server will have rejected these BNDUPD previously, but the other server will have rejected these BNDUPD
messages. messages.
The failover protocol ensures that only one of the two partner The failover protocol ensures that only one of the two partner
servers will be able to make a resource FREE. The server making the 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 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 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 in PARTNER-DOWN state, it may be performing DDNS deletes for RRs
which its partner added originally. This allows a single remaining which its partner added originally. This allows a single remaining
partner server to assume responsibility for all of the DDNS activity partner server to assume responsibility for all of the DDNS activity
which the two servers were undertaking. which the two servers were undertaking.
Another implication of this approach is that no DDNS RR deletes will Another implication of this approach is that no DDNS RR deletes will
be performed while either server is in COMMUNICATIONS-INTERRUPTED be performed while either server is in COMMUNICATIONS-INTERRUPTED
state, since no resource are moved into the FREE state during that state, since no resource are moved into the FREE* state during that
period. period.
11.5. Name Assignment with No Update of DNS 11.5. Name Assignment with No Update of DNS
In some cases, a DHCP server is configured to return a name to the 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 DHCPv6 client but not enter that name into the DNS. This is
typically a name that it has discovered or generated from information typically a name that it has discovered or generated from information
it has received from the client. In this case this name information it has received from the client. In this case this name information
SHOULD be communicated to the failover partner, if only to ensure SHOULD be communicated to the failover partner, if only to ensure
that they will return the same name in the event the partner becomes that they will return the same name in the event the partner becomes
the server to which the DHCPv6 client begins to interact. the server to which the DHCPv6 client begins to interact.
12. Reservations and failover 12. Reservations and failover
Some DHCP servers support a capability to offer specific Some DHCP servers support a capability to offer specific
preconfigured resources to DHCP clients. These are real DHCP preconfigured resources to DHCP clients. These are real DHCP
clients, they do the entire DHCP protocol, but these servers always clients, they do the entire DHCP protocol, but these servers always
offer the client a specific pre-configured resource, one they offer offer the client a specific pre-configured resource, and they offer
that resource to no other clients. Such a capability has several that resource to no other clients. Such a capability has several
names, but it is sometimes called a "reservation", in that the names, but it is sometimes called a "reservation", in that the
resource is reserved for a particular DHCP client. resource is reserved for a particular DHCP client.
In a situation where there are two DHCP servers serving the same In a situation where there are two DHCP servers serving the same
subnet without using failover, the two DHCP server's need to have prefix without using failover, the two DHCP server's need to have
disjoint resource pools, but identical reservations for the DHCP disjoint resource pools, but identical reservations for the DHCP
clients. clients.
In a failover context, both servers need to be configured with the In a failover context, both servers need to be configured with the
proper reservations in an identical manner, but if we stop there proper reservations in an identical manner, but if we stop there
problems can occur around the edge conditions where reservations are problems can occur around the edge conditions where reservations are
made for resource that has already been leased to a different client. made for resource that has already been leased to a different client.
Different servers handle this conflict in different ways, but the Different servers handle this conflict in different ways, but the
goal of the failover protocol is to allow correct operation with any goal of the failover protocol is to allow correct operation with any
server's approach to the normal processing of the DHCP protocol. server's approach to the normal processing of the DHCP protocol.
The general solution with regards to reservations is as follows. The general solution with regards to reservations is as follows.
Whenever a reserved resource becomes FREE (i.e., when first Whenever a reserved resource becomes FREE (i.e., when first
configured or whenever a client frees it or it expires or is reset), configured or whenever a client frees it or it expires or is reset),
the primary server MUST show that resource as FREE (and thus the primary server MUST show that resource as FREE (and thus
available for its own allocation) and it MUST send it to the 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 secondary server in a BNDUPD with a flag set showing that it is
reserved and with a status of BACKUP. reserved and with a status of FREE_BACKUP.
Note that this implies that a reserved resource goes through the Note that this implies that a reserved resource goes through the
normal state changes from FREE to ACTIVE (and possibly back to FREE). normal state changes from FREE to ACTIVE (and possibly back to FREE).
The failover protocol supports this approach to reservations, i.e., The failover protocol supports this approach to reservations, i.e.,
where the resource undergoes the normal state changes of any where the resource undergoes the normal state changes of any
resource, but it can only be offered to the client for which it is resource, but it can only be offered to the client for which it is
reserved. reserved.
From the above, it follows that a reservation soley on the secondary From the above, it follows that a reservation solely on the secondary
will not necessarily allow the secondary to offer that address to will not necessarily allow the secondary to offer that address to
client to whom it is reserved. The reservation must also appear on 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 the primary as well for the secondary to be able to offer the
resource to the client to which is is reserved. resource to the client to which it is reserved.
When the reservation on a resource is cancelled, if the resource is When the reservation on a resource is cancelled, if the resource is
currently FREE and the server is the primary, or BACKUP and the currently FREE and the server is the primary, or FREE_BACKUP and the
server is the secondary, the server MUST send a BNDUPD to the other server is the secondary, the server MUST send a BNDUPD to the other
server with the binding-status FREE and an indication that the server with the binding-status FREE and an indication that the
resource is no longer reserved. resource is no longer reserved.
13. Security Considerations 13. Security Considerations
DHCPv6 failover is an extension of a standard DHCPv6 protocol, so all DHCPv6 failover is an extension of a standard DHCPv6 protocol, so all
security considerations from [RFC3315], Section 23 and [RFC3633], security considerations from [RFC3315], Section 23 and [RFC3633],
Section 15 related to the server apply. Section 15 related to the server apply.
As traffic exchange between clients and server is not encrypted, an As traffic exchange between clients and server is not encrypted, an
attacker than penetrated the network and is able to intercept attacker that penetrated the network and is able to intercept
traffic, will not gain any additional information by also sniffing traffic, will not gain any additional information by also sniffing
communication between partners. communication between partners.
An attacker that is able to impersonate one partner can efficiently An attacker that is able to impersonate one partner can efficiently
perform a denial of service attack on the remaining uncompromised perform a denial of service attack on the remaining uncompromised
server. Several techniques may be used: pretending that conflict server. Several techniques may be used: pretending that conflict
resolution is required, requesting rebalance, claming that a valid resolution is required, requesting rebalance, claiming that a valid
lease was released or declined etc. For that reason the lease was released or declined etc. For that reason the
communication between servers SHOULD support failover connections communication between servers SHOULD support failover connections
over TLS, as explained in Section Section 5.1. Such secure over TLS, as explained in Section 5.1. Such secure connections
connection SHOULD be optional and configurable by the administrator. SHOULD be optional and configurable by the administrator.
A server MUST NOT operate in PARTNER-DOWN if its partner is up. A server MUST NOT operate in PARTNER-DOWN if its partner is up.
Network administrator is expected to switch remaining active server Network administrators are expected to switch the remaining active
to PARTNER-DOWN state only if he or she is sure that the other server server to PARTNER-DOWN state only if they is sure that its partner
is indeed down. Failing to obey this requirement will result in both server is indeed down. Failing to obey this requirement will result
servers likely assigning duplicate leases to different clients. in both servers likely assigning duplicate leases to different
Implementors should take that into consideration if they decide to clients. Implementers should take that into consideration if they
implement timer-based transition to PARTNER-DOWN state. decide to implement the auto-partner-down timer-based transition to
PARTNER-DOWN state.
Running a network protected by DHCPv6 failover requires more Running a network protected by DHCPv6 failover requires more
resources than running without it. In particular some of the resources than running without it. In particular some of the
resources are allocated to the secondary server and they are not resources are allocated to the secondary server and they are not
usable in a normal (i.e. non failures) operation. While limiting usable in a normal (i.e. non failures) operation immediately, though
this pool may be preferable from resource utilisation perspective, it over time they will be rebalanced and end up on the server that needs
must be reasonably large pool, so the secondary may take over once them. While limiting this pool may be preferable from resource
primary becomes unavailable. utilization perspective, it must be a reasonably large pool, so the
secondary may take over once the primary becomes unavailable.
TODO: Security considerations section contains loose notes and will
be transformed into consistent text once the core design solidifies.
14. IANA Considerations 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.
15. 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, Bernie Volz and Marcin Siodelski for their
involvement and contributions. Authors would like to thank Marcin significant involvement and contributions. Authors would like to
Siodelski for his thorough review and VithalPrasad Gaitonde for his thank VithalPrasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki
insightful comments. and Michal Hoeft for their 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).
16. References 16. References
16.1. Normative References 16.1. Normative References
skipping to change at page 58, line 48 skipping to change at page 58, line 37
[RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified [RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified
Domain Name (FQDN) Conflicts among Dynamic Host Domain Name (FQDN) Conflicts among Dynamic Host
Configuration Protocol (DHCP) Clients", RFC 4703, October Configuration Protocol (DHCP) Clients", RFC 4703, October
2006. 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.
[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
Address Option in DHCPv6", RFC 6939, May 2013. "DHCPv6 Leasequery", RFC 5007, September 2007.
16.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", draft-ietf-dhc-dhcpv6-failover- Requirements", draft-ietf-dhc-dhcpv6-failover-
requirements-06 (work in progress), July 2013. requirements-07 (work in progress), July 2013.
[I-D.ietf-dhc-dhcpv6-load-balancing] [I-D.ietf-dhc-dhcpv6-load-balancing]
Kostur, A., "DHC Load Balancing Algorithm for DHCPv6", Kostur, A., "DHC Load Balancing Algorithm for DHCPv6",
draft-ietf-dhc-dhcpv6-load-balancing-00 (work in draft-ietf-dhc-dhcpv6-load-balancing-00 (work in
progress), December 2012. progress), December 2012.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, April 1997.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August
2006.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
2009. 2009.
[dhcpv4-failover] [dhcpv4-failover]
Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S.,
Rabil, G., Dooley, M., and A. Kapur, "DHCP Failover Rabil, G., Dooley, M., and A. Kapur, "DHCP Failover
Protocol", draft-ietf-dhc-failover-12 (work in progress), Protocol", draft-ietf-dhc-failover-12 (work in progress),
March 2003. March 2003.
Authors' Addresses Authors' Addresses
 End of changes. 179 change blocks. 
462 lines changed or deleted 443 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/