draft-ietf-dhc-dhcpv6-failover-protocol-06.txt   rfc8156.txt 
Dynamic Host Configuration (DHC) T. Mrugalski Internet Engineering Task Force (IETF) T. Mrugalski
Internet-Draft ISC Request for Comments: 8156 ISC
Intended status: Standards Track K. Kinnear Category: Standards Track K. Kinnear
Expires: August 31, 2017 Cisco ISSN: 2070-1721 Cisco
February 27, 2017 June 2017
DHCPv6 Failover Protocol DHCPv6 Failover Protocol
draft-ietf-dhc-dhcpv6-failover-protocol-06
Abstract Abstract
DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" (RFC3315) does not offer server redundancy. This document (DHCPv6)" (RFC 3315) does not offer server redundancy. This document
defines a protocol implementation to provide DHCPv6 failover, a defines a protocol implementation to provide DHCPv6 failover, a
mechanism for running two servers with the capability for either mechanism for running two servers with the 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. It meets the requirements for DHCPv6 failover network partition. It meets the requirements for DHCPv6 failover
detailed in "DHCPv6 Failover Requirements" (RFC7031). detailed in "DHCPv6 Failover Requirements" (RFC 7031).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on August 31, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8156.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language ...........................................5
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Glossary ........................................................6
4. Failover Concepts and Mechanisms . . . . . . . . . . . . . . 9 4. Failover Concepts and Mechanisms ...............................10
4.1. Required Server Configuration . . . . . . . . . . . . . . 9 4.1. Required Server Configuration .............................10
4.2. IPv6 Address and Delegable Prefix Allocation . . . . . . 9 4.2. IPv6 Address and Delegable Prefix Allocation ..............10
4.2.1. Independent Allocation . . . . . . . . . . . . . . . 9 4.2.1. Independent Allocation .............................10
4.2.2. Proportional Allocation . . . . . . . . . . . . . . . 10 4.2.1.1. Independent Allocation Algorithm ..........11
4.3. Lazy Updates . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. Proportional Allocation ............................11
4.4. Maximum Client Lead Time (MCLT) . . . . . . . . . . . . . 13 4.2.2.1. Reallocating Leases .......................13
4.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . 15 4.3. Lazy Updates ..............................................14
5. Message and Option Definitions . . . . . . . . . . . . . . . 18 4.4. Maximum Client Lead Time (MCLT) ...........................14
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 18 4.4.1. MCLT Example .......................................16
5.2. Failover Message Format . . . . . . . . . . . . . . . . . 18 5. Message and Option Definitions .................................19
5.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Message Framing for TCP ...................................19
5.3.1. BNDUPD . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Failover Message Format ...................................19
5.3.2. BNDREPLY . . . . . . . . . . . . . . . . . . . . . . 20 5.3. Messages ..................................................20
5.3.3. POOLREQ . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.1. BNDUPD .............................................20
5.3.4. POOLRESP . . . . . . . . . . . . . . . . . . . . . . 20 5.3.2. BNDREPLY ...........................................20
5.3.5. UPDREQ . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.3. POOLREQ ............................................20
5.3.6. UPDREQALL . . . . . . . . . . . . . . . . . . . . . . 20 5.3.4. POOLRESP ...........................................21
5.3.7. UPDDONE . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.5. UPDREQ .............................................21
5.3.8. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.6. UPDREQALL ..........................................21
5.3.9. CONNECTREPLY . . . . . . . . . . . . . . . . . . . . 21 5.3.7. UPDDONE ............................................21
5.3.10. DISCONNECT . . . . . . . . . . . . . . . . . . . . . 21 5.3.8. CONNECT ............................................21
5.3.11. STATE . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.9. CONNECTREPLY .......................................22
5.3.12. CONTACT . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.10. DISCONNECT ........................................22
5.4. Transaction Id . . . . . . . . . . . . . . . . . . . . . 22 5.3.11. STATE .............................................22
5.5. Options . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.12. CONTACT ...........................................22
5.5.1. OPTION_F_BINDING_STATUS . . . . . . . . . . . . . . . 22 5.4. Transaction-id ............................................22
5.5.2. OPTION_F_CONNECT_FLAGS . . . . . . . . . . . . . . . 23 5.5. Options ...................................................23
5.5.3. OPTION_F_DNS_REMOVAL_INFO . . . . . . . . . . . . . . 24 5.5.1. OPTION_F_BINDING_STATUS ............................23
5.5.4. OPTION_F_DNS_HOST_NAME . . . . . . . . . . . . . . . 25 5.5.2. OPTION_F_CONNECT_FLAGS .............................24
5.5.5. OPTION_F_DNS_ZONE_NAME . . . . . . . . . . . . . . . 25 5.5.3. OPTION_F_DNS_REMOVAL_INFO ..........................25
5.5.6. OPTION_F_DNS_FLAGS . . . . . . . . . . . . . . . . . 26 5.5.3.1. OPTION_F_DNS_HOST_NAME ....................26
5.5.7. OPTION_F_EXPIRATION_TIME . . . . . . . . . . . . . . 27 5.5.3.2. OPTION_F_DNS_ZONE_NAME ....................26
5.5.8. OPTION_F_MAX_UNACKED_BNDUPD . . . . . . . . . . . . . 28 5.5.3.3. OPTION_F_DNS_FLAGS ........................27
5.5.9. OPTION_F_MCLT . . . . . . . . . . . . . . . . . . . . 28 5.5.4. OPTION_F_EXPIRATION_TIME ...........................28
5.5.10. OPTION_F_PARTNER_LIFETIME . . . . . . . . . . . . . . 29 5.5.5. OPTION_F_MAX_UNACKED_BNDUPD ........................29
5.5.11. OPTION_F_PARTNER_LIFETIME_SENT . . . . . . . . . . . 29 5.5.6. OPTION_F_MCLT ......................................29
5.5.12. OPTION_F_PARTNER_DOWN_TIME . . . . . . . . . . . . . 30 5.5.7. OPTION_F_PARTNER_LIFETIME ..........................30
5.5.13. OPTION_F_PARTNER_RAW_CLT_TIME . . . . . . . . . . . . 31 5.5.8. OPTION_F_PARTNER_LIFETIME_SENT .....................30
5.5.14. OPTION_F_PROTOCOL_VERSION . . . . . . . . . . . . . . 31 5.5.9. OPTION_F_PARTNER_DOWN_TIME .........................31
5.5.15. OPTION_F_KEEPALIVE_TIME . . . . . . . . . . . . . . . 32 5.5.10. OPTION_F_PARTNER_RAW_CLT_TIME .....................32
5.5.16. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 32 5.5.11. OPTION_F_PROTOCOL_VERSION .........................32
5.5.17. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 33 5.5.12. OPTION_F_KEEPALIVE_TIME ...........................33
5.5.18. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 34 5.5.13. OPTION_F_RECONFIGURE_DATA .........................34
5.5.19. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 35 5.5.14. OPTION_F_RELATIONSHIP_NAME ........................35
5.5.20. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 36 5.5.15. OPTION_F_SERVER_FLAGS .............................36
5.5.21. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 37 5.5.16. OPTION_F_SERVER_STATE .............................37
5.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 38 5.5.17. OPTION_F_START_TIME_OF_STATE ......................38
6. Connection Management . . . . . . . . . . . . . . . . . . . . 39 5.5.18. OPTION_F_STATE_EXPIRATION_TIME ....................38
6.1. Creating Connections . . . . . . . . . . . . . . . . . . 39 5.6. Status Codes ..............................................39
6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 40 6. Connection Management ..........................................40
6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 41 6.1. Creating Connections ......................................40
6.1.3. Receiving a CONNECTREPLY message . . . . . . . . . . 42 6.1.1. Sending a CONNECT Message ..........................41
6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 43 6.1.2. Receiving a CONNECT Message ........................42
6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 44 6.1.3. Receiving a CONNECTREPLY Message ...................43
6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 44 6.2. Endpoint Identification ...................................44
6.5. Connection Maintenance Parameters . . . . . . . . . . . . 45 6.3. Sending a STATE Message ...................................45
6.6. Unreachability detection . . . . . . . . . . . . . . . . 45 6.4. Receiving a STATE Message .................................46
7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 46 6.5. Connection Maintenance Parameters .........................46
7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 46 6.6. Unreachability Detection ..................................47
7.2. Information model . . . . . . . . . . . . . . . . . . . . 46 7. Binding Updates and Acks .......................................47
7.3. Times Required for Exchanging Binding Updates . . . . . . 50 7.1. Time Skew .................................................47
7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 51 7.2. Information Model .........................................48
7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 54 7.3. Times Required for Exchanging Binding Updates .............52
7.5.1. Monitoring Time Skew . . . . . . . . . . . . . . . . 54 7.4. Sending Binding Updates ...................................53
7.5.2. Acknowledging Reception . . . . . . . . . . . . . . . 55 7.5. Receiving Binding Updates .................................56
7.5.3. Processing Binding Updates . . . . . . . . . . . . . 55 7.5.1. Monitoring Time Skew ...............................56
7.5.4. Accept or Reject? . . . . . . . . . . . . . . . . . . 55 7.5.2. Acknowledging Reception ............................56
7.5.5. Accepting Updates . . . . . . . . . . . . . . . . . . 58 7.5.3. Processing Binding Updates .........................57
7.6. Sending Binding Replies . . . . . . . . . . . . . . . . . 59 7.5.4. Accept or Reject? ..................................57
7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 61 7.5.5. Accepting Updates ..................................59
7.8. BNDUPD/BNDREPLY Data Flow . . . . . . . . . . . . . . . . 62 7.6. Sending Binding Replies ...................................61
8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 63 7.7. Receiving Binding Acks ....................................63
8.1. State Machine Operation . . . . . . . . . . . . . . . . . 63 7.8. BNDUPD/BNDREPLY Data Flow .................................65
8.2. State Machine Initialization . . . . . . . . . . . . . . 67 8. Endpoint States ................................................66
8.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 67 8.1. State Machine Operation ...................................66
8.3.1. Operation in STARTUP State . . . . . . . . . . . . . 68 8.2. State Machine Initialization ..............................69
8.3.2. Transition Out of STARTUP State . . . . . . . . . . . 68 8.3. STARTUP State .............................................70
8.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 70 8.3.1. Operation in STARTUP State .........................70
8.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 70 8.3.2. Transition out of STARTUP State ....................70
8.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 71 8.4. PARTNER-DOWN State ........................................72
8.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 71 8.4.1. Operation in PARTNER-DOWN State ....................72
8.5.1. Operation in RECOVER State . . . . . . . . . . . . . 72 8.4.2. Transition out of PARTNER-DOWN State ...............73
8.5.2. Transition Out of RECOVER State . . . . . . . . . . . 72 8.5. RECOVER State .............................................74
8.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 73 8.5.1. Operation in RECOVER State .........................74
8.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 74 8.5.2. Transition out of RECOVER State ....................74
8.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 74 8.6. RECOVER-WAIT State ........................................76
8.6.1. Operation in RECOVER-WAIT State ....................76
8.6.2. Transition out of RECOVER-WAIT State ...............76
8.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 74 8.7. RECOVER-DONE State ........................................77
8.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 74 8.7.1. Operation in RECOVER-DONE State ....................77
8.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 75 8.7.2. Transition out of RECOVER-DONE State ...............77
8.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 75 8.8. NORMAL State ..............................................77
8.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 75 8.8.1. Operation in NORMAL State ..........................78
8.8.2. Transition Out of NORMAL State . . . . . . . . . . . 76 8.8.2. Transition out of NORMAL State .....................78
8.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 77 8.9. COMMUNICATIONS-INTERRUPTED State ..........................79
8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 77 8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State ......80
8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 78 8.9.2. Transition out of COMMUNICATIONS-INTERRUPTED
8.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 79 State ..............................................80
8.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 80 8.10. POTENTIAL-CONFLICT State .................................82
8.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 80 8.10.1. Operation in POTENTIAL-CONFLICT State .............82
8.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 81 8.10.2. Transition out of POTENTIAL-CONFLICT State ........82
8.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 82 8.11. RESOLUTION-INTERRUPTED State .............................83
8.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 82 8.11.1. Operation in RESOLUTION-INTERRUPTED State .........84
8.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 82 8.11.2. Transition out of RESOLUTION-INTERRUPTED State ....84
8.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 83 8.12. CONFLICT-DONE State ......................................84
8.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 83 8.12.1. Operation in CONFLICT-DONE State ..................85
9. DNS Update Considerations . . . . . . . . . . . . . . . . . . 83 8.12.2. Transition out of CONFLICT-DONE State .............85
9.1. Relationship between failover and DNS update . . . . . . 84 9. DNS Update Considerations ......................................85
9.2. Exchanging DNS Update Information . . . . . . . . . . . . 85 9.1. Relationship between Failover and DNS Update ..............86
9.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . . 87 9.2. Exchanging DNS Update Information .........................87
9.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . . 87 9.3. Adding RRs to the DNS .....................................89
9.5. Name Assignment with No Update of DNS . . . . . . . . . . 88 9.4. Deleting RRs from the DNS .................................90
10. Security Considerations . . . . . . . . . . . . . . . . . . . 88 9.5. Name Assignment with No Update of DNS .....................91
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 10. Security Considerations .......................................91
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91 11. IANA Considerations ...........................................92
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 12. References ....................................................94
13.1. Normative References . . . . . . . . . . . . . . . . . . 92 12.1. Normative References .....................................94
13.2. Informative References . . . . . . . . . . . . . . . . . 93 12.2. Informative References ...................................96
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 93 Acknowledgements ..................................................96
Authors' Addresses ................................................96
1. Introduction 1. Introduction
This document defines a DHCPv6 failover protocol, which is a This document defines a DHCPv6 failover protocol, which is a
mechanism for running two DHCPv6 servers [RFC3315] with the mechanism for running two DHCPv6 servers [RFC3315] with the
capability for either server to take over clients' leases in case of capability for either server to take over clients' leases in case of
server failover or network partition. For a general overview of server failover or network partition. For a general overview of
DHCPv6 failover problems, use cases, benefits, and shortcomings, see DHCPv6 failover problems, use cases, benefits, and shortcomings, see
[RFC7031]. [RFC7031].
The failover protocol provides a means for cooperating DHCP servers The failover protocol provides a means for cooperating DHCP servers
to work together to provide a service to DHCP clients with to work together to provide a service to DHCP clients with
availability that is increased beyond that which could be provided by availability that is increased beyond the availability that could be
a single DHCP server operating alone. It is designed to protect DHCP provided by a single DHCP server operating alone. It is designed to
clients against server unreachability, including server failure and protect DHCP clients against server unreachability, including server
network partition. It is possible to deploy exactly two servers that failure and network partition. It is possible to deploy exactly two
are able to continue providing a lease for an IPv6 address [RFC3315] servers that are able to continue providing a lease for an IPv6
or on an IPv6 prefix [RFC3633] without the DHCP client experiencing address [RFC3315] or on an IPv6 prefix [RFC3633] without the DHCP
lease expiration or a reassignment of a lease to a different IPv6 client experiencing lease expiration or a reassignment of a lease to
address or prefix in the event of failure by one or the other of the a different IPv6 address or prefix in the event of failure by one or
two servers. the other of the two servers.
The failover protocol defines an active-passive mode, sometimes also The failover protocol defines an active-passive mode, sometimes also
called a hot standby model. This means that during normal operation called a "hot standby" model. This means that during normal
one server is active (i.e. actively responds to clients' requests) operation one server is active (i.e., it actively responds to
while the second is passive (i.e. it receives clients' requests, but clients' requests) while the second is passive (i.e., it receives
responds only to those specifically directed to it). The secondary clients' requests but responds only to those specifically directed to
maintains a copy of the binding database and is ready to take over it). The secondary server maintains a copy of the binding database
all incoming queries in case of primary server failure. and is ready to take over all incoming queries in case the primary
server fails.
The failover protocol is designed to provide lease stability for The failover protocol is designed to provide lease stability for
leases with valid lifetimes beyond a short period. The DHCPv6 leases with valid lifetimes beyond a short period. The DHCPv6
Failover protocol MUST NOT be used for new leases shorter than 30 failover protocol MUST NOT be used for new leases shorter than
seconds. Leases reaching the end of their liftetime are not affected 30 seconds. Leases reaching the end of their lifetimes are not
by this restriction. affected by this restriction.
The failover protocol fulfills all DHCPv6 failover requirements The failover protocol fulfills all DHCPv6 failover requirements
defined in [RFC7031]. defined in [RFC7031].
2. Requirements Language 2. 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Glossary 3. Glossary
This is a supplemental glossary that should be combined with This is a supplemental glossary that should be used in combination
definitions in Section 3 of RFC 7031 [RFC7031]. with the definitions in Section 2 of RFC 7031 [RFC7031].
o Absolute Time o Absolute Time
The time in seconds since midnight January 1, 2000 UTC, modulo "Absolute time" refers to the time in seconds since midnight
2^32). January 1, 2000 UTC, modulo 2^32.
o Address Lease o Address Lease
A lease involving an IPv6 address. Typically used when it is "Address lease" refers to a lease involving an IPv6 address.
necessary to distinguish the lease for an IPv6 address from a Typically used when it is necessary to distinguish the lease for
lease for a DHCP prefix. See "delegated prefix" and "prefix an IPv6 address from a lease for a DHCP prefix. See the
lease". definitions for "delegated prefix" and "prefix lease" below.
o auto-partner-down o auto-partner-down
A capability where a failover server will move from
COMMUNICATIONS-INTERRUPTED state to PARTNER-DOWN state "auto-partner-down" refers to a capability where a failover server
automatically, without operator intervention. will move from COMMUNICATIONS-INTERRUPTED state to PARTNER-DOWN
state automatically, without operator intervention.
o Available (Lease or Prefix) o Available (Lease or Prefix)
A lease or delegable prefix is available if it could be allocated A lease or delegable prefix is available if it could be allocated
for use by a DHCP client. It is available on the main server when for use by a DHCP client. It is available on the main server when
it is in FREE state and available on the secondary server when it it is in the FREE state and available on the secondary server when
is in the FREE-BACKUP state. Sometimes the term "available" is it is in the FREE-BACKUP state. The term "available" is sometimes
used when it would be awkward to say "FREE on the primary server used when it would be awkward to say "FREE on the primary server
and FREE-BACKUP on the secondary server". and FREE-BACKUP on the secondary server".
o Binding-Status o Binding-Status
A lease can hold a variety of states (see Section 5.5.1 for a A lease can hold a variety of states (see Section 5.5.1 for a
list) and these are also referred to as the binding-status of the list); these are also referred to as the "binding-status" of the
lease. lease.
o Delegable Prefix o Delegable Prefix
A prefix from which other prefixes may be delegated, using the "Delegable prefix" refers to a prefix from which other prefixes
mechanisms described in [RFC3633]. A prefix which has been may be delegated, using the mechanisms described in [RFC3633]. A
delegated is known as a "delegated prefix" or a "prefix lease". prefix that has been delegated is known as a "delegated prefix" or
a "prefix lease".
o Delegated Prefix o Delegated Prefix
A prefix which has been deletegated to a DHCP client as described A delegated prefix is a prefix that has been delegated to a DHCP
in [RFC3633]. Depending on the context, a delegated prefix may client as described in [RFC3633]. Depending on the context, a
also be described as a "prefix lease", when it is necessary to delegated prefix may also be described as a "prefix lease" when it
distinguish it from an "address lease". is necessary to distinguish it from an "address lease".
o Failover endpoint o DHCP Prefix
The failover protocol allows for there to be a unique failover A DHCP prefix is part of the IPv6 address space configured to be
'endpoint' for each failover relationship in which a failover managed by a DHCP server.
server participates. The failover relationship is defined by a
relationship name, and includes the failover partner IP address, o Failover Endpoint
the role this server takes with respect to that partner (primary
or secondary), and the prefixes from which addresses can be leased The failover protocol permits a unique failover "endpoint" for
as well as prefixes from which other prefixes can be delegated each failover relationship in which a failover server
(delegable prefixes), associated with that relationship. The participates. The failover relationship is defined by a
failover endpoint can take actions and hold unique states. relationship name and includes
* the failover partner IP address,
* the role this server takes with respect to that partner
(primary or secondary), and
* the prefixes from which addresses can be leased, as well as
prefixes from which other prefixes can be delegated (delegable
prefixes), that are associated with that relationship.
The failover endpoint can take actions and hold unique states.
Typically, there is one failover endpoint per partner (server), Typically, there is one failover endpoint per partner (server),
although there may be more. although there may be more.
o Failover communication o Failover Communication
All messages exchanged between partners.
"Failover communication" refers to all messages exchanged between
partners.
o Independent Allocation o Independent Allocation
An allocation algorithm that splits the available pool of address "Independent allocation" refers to an allocation algorithm that
leases between the primary and secondary servers. It is used for splits the available pool of address leases between the primary
IPv6 address allocations. See Section 4.2.1. and secondary servers. It is used for IPv6 address allocations.
See Section 4.2.1.
o Lease o Lease
An association of a DHCP client with an IPv6 address or delegated A lease is an association of a DHCP client with an IPv6 address or
prefix. This might refer to either an existing association or a delegated prefix. This might refer to either an existing
potential association. association or a potential association.
o MCLT o MCLT (Maximum Client Lead Time)
Maximum Client Lead Time. The fundamental relationship on which The fundamental relationship on which much of the correctness of
much of the correctness of the failover protocol depends is that the failover protocol depends is that the lease expiration time
the lease expiration time known to a DHCP client MUST NOT be known to a DHCP client MUST NOT be greater by more than the MCLT
greater by more than the MCLT beyond the later of the partner beyond the later of the partner lifetime acknowledged by that
lifetime time acknowledged by that server's failover partner or server's failover partner or the current time (i.e., now). See
the current time (i.e., now). See Section 4.4. Section 4.4.
o Partner o Partner
The other DHCP server that participates in a failover The other DHCP server that participates in a failover relationship
relationship. When the role (primary or secondary) is not is referred to as the "partner". When the role (primary or
important, the other server is referred to as a "failover partner" secondary) is not important, the other server is referred to as a
or sometimes simply "partner". "failover partner" or sometimes simply "partner".
o Prefix Lease o Prefix Lease
A lease involving a prefix that is or could be delegated, as A prefix lease is a lease involving a prefix that is delegated or
opposed to a lease for a single IPv6 address. A prefix lease can could be delegated, as opposed to a lease for a single IPv6
also be described as a "delegated prefix". address. A prefix lease can also be described as a "delegated
prefix".
o Primary Server o Primary Server
First out of two DHCP servers that participate in a failover The primary server is the first of the two DHCP servers that
relationship. When both servers are operating this server handles participate in a failover relationship. When both servers are
most of the client traffic. Its failover partner is referred to operating, this server handles most of the client traffic. Its
as secondary server. failover partner is referred to as the "secondary server".
o Proportional Allocation o Proportional Allocation
An allocation algorithm that splits the delegable prefixes between "Proportional allocation" is an allocation algorithm that splits
the primary and secondary servers and maintains a more or less the delegable prefixes between the primary and secondary servers
fixed proportion of the delegable prefixes between both servers. and maintains a more or less fixed proportion of the delegable
Section 4.2.2. prefixes between both servers. See Section 4.2.2.
o Renew Responsive o Renew Responsive
A server that is renew responsive will respond to valid DHCP A server that is "renew responsive" will respond to valid DHCP
client requests that are directed to it by having an client messages that are directed to it by having an
OPTION_SERVERID option in the message which contains the DUID of OPTION_SERVERID option in the message that contains the DHCP
the renew responsive server. See [RFC3315]. Unique Identifier (DUID) of the renew responsive server. See
[RFC3315].
o Responsive o Responsive
A server that is responsive will respond to all valid DHCP client A server that is responsive will respond to all valid DHCP client
requests. messages.
o Secondary Server o Secondary Server
Second of two DHCP servers that participate in a failover The secondary server is the second of the two DHCP servers that
relationship. Its failover partner is referred to as the primary participate in a failover relationship. Its failover partner is
server. When both servers are operating this server (the referred to as the "primary server" (as defined above). When both
secondary) typically does not handle client traffic and acts as a servers are operating, this server (the secondary) typically does
backup to the primary server. It will respond, however, to RENEW not handle client traffic and acts as a backup to the primary
requests directed specifically to it. server. However, it will respond to RENEW requests directed
specifically to it.
o Server o Server
A DHCP server that implements DHCPv6 failover. 'Server' and "Server" refers to a DHCP server that implements DHCPv6 failover.
'failover endpoint' are synonymous only if the server participates "Server" and "failover endpoint" are synonymous only if the server
in only one failover relationship. participates in only one failover relationship.
o State o State
The term state is used in two ways in this document. A failover The term "state" is used in two ways in this document. A failover
endpoint is always in some state, and there are a series of states endpoint is always in some state, and there are a series of states
that a failover endpoint can move through. See Section 8 for that a failover endpoint can move through. See Section 8 for
details of the failover endpoint states. A lease also has a details of the failover endpoint states. A lease also has a
state, and this is sometimes referred to as a binding-status. See state, and this is sometimes referred to as a "binding-status".
Section 5.5.1 for a list of the states a lease can hold. See Section 5.5.1 for a list of the states a lease can hold.
o Time Context
Each failover server has a clock and a definite idea of the
current universal time. Each server's idea of the current time is
considered its time context.
o Unresponsive o Unresponsive
A server that is unresponsive will not respond to DHCP client A server that is unresponsive will not respond to DHCP client
requests. messages.
4. Failover Concepts and Mechanisms 4. Failover Concepts and Mechanisms
The following concepts and mechanisms are necessary to the operation The following concepts and mechanisms are necessary for the operation
of the failover protocol, and they are not currently employed by the of the failover protocol. They are not currently employed by DHCPv6
DHCPv6 protocol [RFC3315]. The failover protocol provides support [RFC3315]. The failover protocol provides support for all of these
for all of these concepts and mechanisms. concepts and mechanisms.
4.1. Required Server Configuration 4.1. Required Server Configuration
Servers frequently have several kinds of leases available on a Servers frequently have several kinds of leases 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 identically with regard the primary server and the secondary server are configured
to the prefixes and links involved in DHCP. For delegated prefixes identically with regard to the prefixes and links involved in DHCP.
(involved in proportional allocation) the primary server is For delegable prefixes (involved in proportional allocation), the
responsible for allocating to the secondary server the correct primary server is responsible for allocating to the secondary server
proportion of the available delegated prefixes. IPv6 addresses the correct proportion of the available delegable prefixes. IPv6
(involved in independent allocation) are allocated to the primary and addresses (involved in independent allocation) are allocated to the
secondary servers algorithmically, and do not require an explicit primary and secondary servers algorithmically and do not require an
message transfer to be distributed. explicit message transfer to be distributed.
4.2. IPv6 Address and Delegable Prefix Allocation 4.2. IPv6 Address and Delegable Prefix Allocation
Currently there are two allocation algorithms defined, one for Currently, there are two allocation algorithms defined: one for
address leases and one for prefix leases. address leases and one for prefix leases.
4.2.1. Independent Allocation 4.2.1. Independent Allocation
In this allocation scheme, used for allocating individual IPv6 In this allocation scheme, which is used for allocating individual
addresses, available IPv6 addresses are permanently (until server IPv6 addresses, available IPv6 addresses are permanently (until
configuration changes) split between servers. Available IPv6 server configuration changes) split between servers. Available IPv6
addresses are split between the primary and secondary servers as part addresses are split between the primary and secondary servers as part
of initial connection establishment. Once IPv6 addresses are of initial connection establishment. Once IPv6 addresses are
allocated to each server, there is no need to reassign them. The allocated to each server, there is no need to reassign them. The
IPv6 address allocation is algorithmic in nature, and does not IPv6 address allocation is algorithmic in nature and does not require
require a message exchange for each server to know which IPv6 a message exchange for each server to know which IPv6 addresses it
addresses it has been allocated. This algorithm is simpler than has been allocated. This algorithm is simpler than proportional
proportional allocation since it does not require a rebalancing allocation, since it does not require a rebalancing mechanism. It
mechanism. It also assumes that the pool assigned to each server also assumes that the pool assigned to each server will never be
will never deplete. depleted.
Once each server is assigned a pool of IPv6 addresses during initial Once each server is assigned a pool of IPv6 addresses during initial
connection establishment, it may allocate its assigned IPv6 addresses connection establishment, it may allocate its assigned IPv6 addresses
to clients. Once a client releases a lease or its lease on an IPv6 to clients. Once a client releases a lease or its lease on an IPv6
address expires, the returned IPv6 address returns to the pool for address expires, the returned IPv6 address returns to the pool for
the server that leased it. A lease on an IPv6 address can be renewed the server that leased it. A lease on an IPv6 address can be renewed
by a responsive server or by a renew responsive server. When an IPv6 by a responsive server or by a renew responsive server. When an IPv6
address goes PENDING-FREE (see Section 7.2) it is owned by whichever address goes PENDING-FREE (see Section 7.2), it is owned by whichever
server it is allocated to by the independent allocation algorithm. server it is allocated to by the independent allocation algorithm.
IPv6 addresses (which use the independent allocation approach) are IPv6 addresses, which use the independent allocation approach, will
ignored when a server processes a POOLREQ message. be ignored when a server processes a POOLREQ message.
During COMMUNICATION-INTERRUPTED events, a partner MAY continue During COMMUNICATIONS-INTERRUPTED events, a partner MAY continue
extending existing address leases as requested by clients. An extending existing address leases as requested by clients. An
operational partner MUST NOT lease IPv6 addresses that were assigned operational partner MUST NOT lease IPv6 addresses that were assigned
to its downed partner and later expired or were released or declined to its downed partner and later expired or that were released or
by a client. When it is in PARTNER-DOWN state, a server MUST declined by a client. When it is in PARTNER-DOWN state, a server
allocate new leases from its own pool. It MUST NOT use its partner's MUST allocate new leases from its own pool. It MUST NOT use its
pool to allocate new leases. partner's pool to allocate new leases.
4.2.1.1. Independent Allocation Algorithm 4.2.1.1. Independent Allocation Algorithm
For each address that can be allocated, the primary server MUST For each address that can be allocated, the primary server MUST
allocate only IPv6 addresses when the low-order bit (i.e., bit 127) allocate only IPv6 addresses when the low-order bit (i.e., bit 127)
is equal to 1, and the secondary server MUST allocate only the IPv6 is equal to 1, and the secondary server MUST allocate only the IPv6
addresses when the low-order bit (i.e., bit 127) is equal to 0. addresses when the low-order bit (i.e., bit 127) is equal to 0.
4.2.2. Proportional Allocation 4.2.2. Proportional Allocation
In this allocation scheme, each server has its own pool of prefixes In this allocation scheme, each server has its own pool of prefixes
available for delegation, known as "delegable prefixes". These available for delegation, known as "delegable prefixes". These
delegable prefixes may be prefixes from which other prefixes can be delegable prefixes may be prefixes from which other prefixes can be
delegated or they may be prefixes which are the correct size for delegated, or they may be prefixes that are the correct size for
delegation but are not, at present, delegated to a particular client. delegation but are not, at present, delegated to a particular client.
Remaining delegable prefixes are split between the primary and Remaining delegable prefixes are split between the primary and
secondary servers in a configured proportion. Note that a delegated secondary servers in a configured proportion. Note that a delegated
prefix (also known as a prefix lease) is not "owned" by a particular prefix (also known as a "prefix lease") is not "owned" by a
server. Only a delegable prefix which is available is "owned" by a particular server. Only a delegable prefix that is available is
particular server -- once it has been delegated (leased) to a client owned by a particular server -- once it has been delegated (leased)
it becomes a prefix lease and is not owned by either failover to a client, it becomes a prefix lease and is not owned by either
partner. When it finally becomes available again, it will be owned failover partner. When it finally becomes available again, it will
initially by the primary server, and it may or may not be allocated be initially owned by the primary server, and it may or may not be
to the secondary server by the primary server. allocated to the secondary server by the primary server.
The flow of a delegable prefix is as follows: initially the delegable The flow of a delegable prefix is as follows: initially, the
prefix is part of a larger delegable prefix, all of which are delegable prefix is part of a set of delegable prefixes, all of which
initially owned by the primary server. A delegable prefix may be are initially owned by the primary server. A delegable prefix may be
allocated to the secondary server and then it is owned by the allocated to the secondary server, and it is then owned by the
secondary server. Either server can allocate and delegate prefixes secondary server. Either server can allocate and delegate prefixes
out of the delegable prefixes which they own. Once these prefixes out of the delegable prefixes that they own. Once these prefixes are
are delegated (leased) to clients, the servers cease to own them and delegated (leased) to clients, the servers cease to own them, and
they are owned by the clients to which they have been delegated they are owned by the clients to which they have been delegated
(leased). When the client releases the delegated prefix or the lease (leased). When the client releases the delegated prefix or the lease
on it expires, it will again become available and will then be a on it expires, the prefix will again become available, will again be
delegable prefix and be owned by the primary. a delegable prefix, and will be owned by the primary.
A server delegates prefixes only from its own pool of delegable A server delegates prefixes only from its own pool of delegable
prefixes in all states except for PARTNER-DOWN. In PARTNER-DOWN prefixes in all states except for PARTNER-DOWN. In PARTNER-DOWN
state the operational partner can delegate prefixes from either pool state, the operational partner can delegate prefixes from either pool
(both its own, and its partner's after some time constraints have (both its own, and its partner's after some time constraints have
elapsed). The operational partner SHOULD allocate from its own pool elapsed). The operational partner SHOULD allocate from its own pool
before using its partner's pool. The allocation and maintenance of before using its partner's pool. The allocation and maintenance of
these pools of delegable prefixes is important, since the goal is to these pools of delegable prefixes are important, since the goal is to
maintain a more or less constant ratio of delegable prefixes between maintain a more or less constant ratio of delegable prefixes between
the two servers. the two servers.
Each server knows which delegable prefixes are in its own pool as Each server knows which delegable prefixes are in its own pool as
well as which are in its partner's pool, so that it can allocate well as which are in its partner's pool, so that it can allocate
delegable prefixes from its partner's pool without communication with delegable prefixes from its partner's pool without communication with
its partner if that becomes necessary. its partner if that becomes necessary.
The initial allocation of delegable prefixes from the primary to the The initial allocation of delegable prefixes from the primary to the
secondary when the servers first integrate is triggered by the secondary when the servers first integrate is triggered by the
POOLREQ message from the secondary to the primary. This is followed POOLREQ message from the secondary to the primary. This is followed
(at some point) by the POOLRESP message where the primary tells the (at some point) by the POOLRESP message, where the primary tells the
secondary that it received and processed the POOLREQ message. The secondary that it received and processed the POOLREQ message. The
primary sends the allocated delegable prefixes to the secondary as primary sends the allocated delegable prefixes to the secondary as
prefix leases via BNDUPD messages. The POOLRESP message may be sent prefix leases via BNDUPD messages. The POOLRESP message may be sent
before, during, or at the completion of the BNDUPD message exchanges before, during, or at the completion of the BNDUPD message exchanges
that were triggered by the POOLREQ message. The POOLREQ/POOLRESP that were triggered by the POOLREQ message. The POOLREQ/POOLRESP
message exchange is a trigger to the primary to perform a scan of its message exchange is a trigger to the primary to perform a scan of its
database and to ensure that the secondary has enough delegable database and to ensure that the secondary has enough delegable
prefixes (based on some configured ratio). prefixes (based on some configured ratio).
The delegable prefixes are sent to the secondary as prefix leases The delegable prefixes are sent to the secondary as prefix leases
using the BNDUPD message containing an OPTION_IAPREFIX with a state using the BNDUPD message containing an OPTION_IAPREFIX with a state
of FREE-BACKUP, which indicates the prefix lease is now available for of FREE-BACKUP, which indicates that the prefix lease is now
allocation by the secondary. Once the message is sent, the primary available for allocation by the secondary. Once the message is sent,
MUST NOT use these prefixes for allocation to DHCP clients (except the primary MUST NOT use these prefixes for allocation to DHCP
when the server is in PARTNER-DOWN state). clients (except when the server is in PARTNER-DOWN state).
The POOLREQ/POOLRESP message exchange initiated by the secondary is The POOLREQ/POOLRESP message exchange initiated by the secondary is
valid at any time both partners remain in contact, and the primary valid at any time both partners remain in contact, and the primary
server SHOULD, whenever it receives the POOLREQ message, scan its server SHOULD, whenever it receives the POOLREQ message, scan its
database of delegable prefixes and determine if the secondary needs database of delegable prefixes and determine if the secondary needs
more delegable prefixes from any of the delegable prefixes which it more delegable prefixes from any of the delegable prefixes that it
currently owns. currently owns.
In order to support a reasonably dynamic balance of the leases In order to support a reasonably dynamic balance of the leases
between the failover partners, the primary server needs to do between the failover partners, the primary server needs to do
additional work to ensure that the secondary server has as many additional work to ensure that the secondary server has as many
delegable prefixes as it needs (but that it doesn't have more than it delegable prefixes as it needs (but that it doesn't have more than
needs). it needs).
The primary server SHOULD examine the balance of delegable prefixes The primary server SHOULD examine the balance of delegable prefixes
between the primary and secondary for a particular prefix whenever between the primary and secondary for a particular prefix whenever
the number of possibly delegable prefixes for either the primary or the number of possibly delegable prefixes for either the primary or
secondary changes by more than a predetermined amount. Typically secondary changes by more than a predetermined amount. Typically,
this comparison would not involve actually comparing the count of this comparison would not involve actually comparing the count of
existing instances of delegable prefixes, but would instead involve existing instances of delegable prefixes but would instead involve
determining the number prefixes that could be delegated given the determining the number of prefixes that could be delegated given the
address ranges of the delegable prefixes allocated to each server. address ranges of the delegable prefixes allocated to each server.
The primary server SHOULD adjust the delegable prefix balance as The primary server SHOULD adjust the delegable prefix balance as
required to ensure the configured delegable prefix balance, excepting required to ensure the configured delegable prefix balance, except
that the primary server SHOULD employ some threshold mechanism to that the primary server SHOULD employ some threshold mechanism to
such a balance adjustment in order to minimize the overhead of such a balance adjustment in order to minimize the overhead of
maintaining this balance. maintaining this balance.
The primary server can, at any time, send an available delegable The primary server can, at any time, send an available delegable
prefix to the secondary using a BNDUPD with the state FREE-BACKUP. prefix to the secondary using a BNDUPD message with the state
The primary server can attempt to take an available delegable prefix FREE-BACKUP. The primary server can attempt to take an available
away from the secondary by sending a BNDUPD with the state FREE. If delegable prefix away from the secondary by sending a BNDUPD message
the secondary accepts the BNDUPD, then the lease is now available to with the state FREE. If the secondary accepts the BNDUPD message,
the primary and not available to the secondary. Of course, the then the lease is now available to the primary and not available to
secondary MUST reject that BNDUPD if it has already allocated that the secondary. Of course, the secondary MUST reject that BNDUPD
lease to a DHCP client. message if it has already allocated that lease to a DHCP client.
4.2.2.1. Re-allocating Leases 4.2.2.1. Reallocating Leases
When in PARTNER-DOWN state there is a waiting period after which a When the server is in PARTNER-DOWN state, there is a waiting period
delegated prefix can be re-allocated to another client. For after which a delegated prefix can be reallocated to another client.
delegable prefixes which are "available" when the server enters For delegable prefixes that are "available" when the server enters
PARTNER-DOWN state, the period is the MCLT from the entry into PARTNER-DOWN state, the period is the MCLT from the entry into
PARTNER-DOWN state. For delegated prefixes which are not available PARTNER-DOWN state. For delegated prefixes that are not available
when the server enters PARTNER-DOWN state, the period is the MCLT when the server enters PARTNER-DOWN state, the period is the MCLT
after the later of the following times: the acked-partner-lifetime, after the later of the following times: the acked-partner-lifetime,
the partner-lifetime (if any), the expiration-time, and the entry to the partner-lifetime (if any), the expiration-time, or the entry into
PARTNER-DOWN time plus the MCLT. PARTNER-DOWN time.
In any other state, a server cannot reallocate a delegated prefix In any other state, a server cannot reallocate a delegated prefix
from one client to another without first notifying its partner from one client to another without first notifying its partner
(through a BNDUPD message) and receiving acknowledgement (through a (through a BNDUPD message) and receiving acknowledgement (through a
BNDREPLY message) that its partner is aware that the first client is BNDREPLY message) that its partner is aware that the first client is
not using the lease. not using the lease.
Specifically, an "available" delegable prefix on a server may be Specifically, an "available" delegable prefix on a server may be
allocated to any client. A prefix which was delegated (leased) to a allocated to any client. A prefix that was delegated (leased) to a
client and which expired or was released by that client would take on client and that expired or was released by that client would take on
a new state, EXPIRED or RELEASED respectively. The partner server a new state -- EXPIRED or RELEASED, respectively. The partner server
would then be notified that this delegated prefix was EXPIRED or would then be notified that this delegated prefix was EXPIRED or
RELEASED through a BNDUPD. When the sending server received the RELEASED through a BNDUPD message. When the sending server received
BNDREPLY for that delegated prefix showing it was FREE, it would move the BNDREPLY message for that delegated prefix showing that it was
the lease from EXPIRED or RELEASED to FREE, and it would be available FREE, it would move the lease from EXPIRED or RELEASED to FREE, and
for allocation by the primary server to any clients. the prefix would be available for allocation by the primary server to
any clients.
A server MAY reallocate a delegated prefix in the EXPIRED or RELEASED A server MAY reallocate a delegated prefix in the EXPIRED or RELEASED
state to the same client with no restrictions provided it has not state to the same client with no restrictions, provided it has not
sent a BNDUPD message regarding the delegated prefix to its partner. sent a BNDUPD message regarding the delegated prefix to its partner.
This situation would exist if the prefix lease expired or was This situation would exist if the prefix lease expired or was
released after the transition into PARTNER-DOWN state, for instance. released after the transition into PARTNER-DOWN state, for instance.
4.3. Lazy Updates 4.3. Lazy Updates
The DHCPv6 Failover Requirements document includes the requirement [RFC7031] includes the requirement that failover must not introduce
that failover must not introduce significant performance impact on significant performance impact on server response times (see
server response times (see Sections 7 and 5.2.2 of [RFC7031] ). In Sections 7 and 5.2.2 of [RFC7031]). In order to realize this
order to realize this requirement a server implementing the failover requirement, a server implementing the failover protocol must be able
protocol must be able respond to a DHCP client without waiting to to respond to a DHCP client without waiting to update its failover
update its failover partner whenever the binding database changes. partner whenever the binding database changes. The "lazy update"
The lazy update mechanism allows a server to allocate a new lease or mechanism allows a server to allocate a new lease or extend an
extend an existing lease, respond to the DHCP client, and then update existing lease, respond to the DHCP client, and then update its
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 DHCP client with a particular valid lifetime and before updating a DHCP client with a particular valid lifetime but before
updating its failover partner, the failover partner will eventually updating its failover partner, the failover partner will eventually
believe that the client's lease has expired -- even though the DHCP believe that the client's lease has expired -- even though the DHCP
client still retains a valid lease on that address or prefix. It is client still retains a valid lease on that address or prefix. It is
also possible that the failover partner will have no record at all of also possible that the failover partner will have no record at all of
the lease being assigned to the DHCP client. Both of these issues the lease being assigned to the DHCP client. Both of these issues
are dealt with by use of the MCLT when allocating or extending leases are dealt with by using the MCLT when allocating or extending leases
(see Section 4.4). (see Section 4.4).
4.4. Maximum Client Lead Time (MCLT) 4.4. Maximum Client Lead Time (MCLT)
In order to handle problems introduced by lazy updates (see In order to handle problems introduced by lazy updates (see
Section 4.3), a period of time known as the "Maximum Client Lead Section 4.3), 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 server
secondary servers. Proper use of this time interval places an upper and the secondary server. Proper use of this time interval places an
bound on the difference allowed between the valid lifetime provided upper bound on the difference allowed between the valid lifetime
to a DHCP client by a server and the valid lifetime known by that provided to a DHCP client by a server and the valid lifetime known by
server's failover partner. that server's failover partner.
The MCLT is typically much less than the valid lifetime that a server The MCLT is typically much less than the valid lifetime that a server
has been configured to offer a client, and so some strategy must has been configured to offer a client, and so some strategy must
exist to allow a server to offer the configured valid lifetime to a exist to allow a server to offer the configured valid lifetime to a
client. During a lazy update the updating server updates its client. During a lazy update, the updating server updates its
failover partner with a partner lifetime which is longer than the failover partner with a partner lifetime that is longer than the
valid lifetime previously given to the DHCP client and which is valid lifetime previously given to the DHCP client and that is longer
longer than the valid lifetime that the server has been configured to than the valid lifetime that the server has been configured to give a
give a client. This allows the server to give the configured valid client. This allows the server to give the configured valid lifetime
lifetime to the client the next time the client renews its lease, to the client the next time the client renews its lease, since the
since the time that it will give to the client will not be longer time that it will give to the client will not be longer than the MCLT
than the MCLT beyond the partner lifetime acknowledged by its partner beyond the partner lifetime acknowledged by its partner or the
or the current time. current time.
The fundamental relationship on which the failover protocol depends The fundamental relationship on which the failover protocol depends
is: the lease expiration time known to a DHCP client MUST NOT be is as follows: the lease expiration time known to a DHCP client
greater by more than the MCLT beyond the later of the partner MUST NOT be greater by more than the MCLT beyond the later of the
lifetime acknowledged by that server's failover partner and the partner lifetime acknowledged by that server's failover partner or
current time. the current time.
The remainder of this section makes the above fundamental The remainder of this section makes the above fundamental
relationship more explicit. relationship more explicit.
The failover protocol requires a DHCP server to deal with several The failover protocol requires a DHCP server to deal with several
different lease intervals and places specific restrictions on their different lease intervals and places specific restrictions on their
relationships. The purpose of these restrictions is to allow the relationships. The purpose of these restrictions is to allow the
partner to be able to make certain assumptions in the absence of an partner to be able to make certain assumptions in the absence of an
ability to communicate between servers. ability to communicate between servers.
In the following explanation, all of the lifetimes are "valid" In the following explanation, all of the lifetimes are "valid"
lifetimes, in the context of [RFC3315]. lifetimes, in the context of [RFC3315].
The different times are: The different times are as follows:
desired lifetime: desired lifetime:
The desired lifetime is the lease interval that a DHCP server The desired lifetime is the lease interval that a DHCP server
would like to give to a DHCP client in the absence of any would like to give to a DHCP client in the absence of any
restrictions imposed by the failover protocol. Its determination restrictions imposed by the failover protocol. Its determination
is outside of the scope of the failover protocol. Typically this is outside of the scope of the failover protocol. Typically, this
is the result of external configuration of a DHCP server. is the result of external configuration of a DHCP server.
actual lifetime: actual lifetime:
The actual lifetime is the lease interval that a DHCP server gives The actual lifetime is the lease interval that a DHCP server gives
out to a DHCP client. It may be shorter than the desired lifetime out to a DHCP client. It may be shorter than the desired lifetime
(as explained below). (as explained below).
partner lifetime: partner lifetime:
The partner lifetime is the lease expiration interval the local The partner lifetime is the lease expiration interval the local
server tells to its partner in a BNDUPD message. server sends to its partner in a BNDUPD message.
acknowledged partner lifetime: acknowledged partner lifetime:
The acknowledged partner lifetime is the partner lifetime the The acknowledged partner lifetime is the partner lifetime the
partner server has most recently acknowledged in a BNDREPLY partner server has most recently acknowledged in a BNDREPLY
message. message.
4.4.1. MCLT example 4.4.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 and are not a recommendation for values used are arbitrarily chosen and are not a recommendation for
actual values. The MCLT in this case is 1 hour. The desired actual values. The MCLT in this case is 1 hour. The desired
lifetime is 3 days, and its renewal time is half the lifetime. lifetime is 3 days, and its renewal time is half the lifetime.
When a server makes an offer for a new lease on an IPv6 address to a When a server makes an offer for a new lease on an IPv6 address to a
DHCP client, it determines the desired lifetime (in this case, 3 DHCP client, it determines the desired lifetime (in this case,
days). It then examines the acknowledged partner lifetime (which in 3 days). It then examines the acknowledged partner lifetime (which,
this case is zero) and determines the remainder of the time left to in this case, is zero) and determines the remainder of the time left
run, which is also zero. It adds the MCLT to this value. Since the to run, which is also zero. It adds the MCLT to this value. Since
actual lifetime cannot be allowed to exceed the remainder of the the actual lifetime cannot be allowed to exceed the remainder of the
current acknowledged partner lifetime plus the MCLT, the offer made current acknowledged partner lifetime plus the MCLT, the offer made
to the client is for the remainder of the current acknowledged to the client is for the remainder of the current acknowledged
partner lifetime (i.e. zero) plus the MCLT. Thus, the actual partner lifetime (i.e., zero) plus the MCLT. Thus, the actual
lifetime is 1 hour (the MCLT). lifetime is 1 hour (the MCLT).
Once the server has sent the REPLY to the DHCP client, it will update Once the server has sent the REPLY to the DHCP client, it will update
its failover partner with the lease information using a BNDUPD its failover partner with the lease information using a BNDUPD
message. The partner lifetime will be composed of the T1 fraction message. The partner lifetime will be composed of the T1 fraction
(1/2) of the actual lifetime added to the desired lifetime. Thus, (1/2) of the actual lifetime added to the desired lifetime. Thus,
the failover partner is updated using a BNDUPD with a partner the failover partner is updated using a BNDUPD message with a partner
lifetime of 1/2 hour + 3 days. lifetime of 1/2 hour + 3 days.
When the primary server receives a BNDREPLY to its update of the When the primary server receives a BNDREPLY to its update of the
secondary server's (partner's) partner lifetime, it records that as secondary server's (partner's) partner lifetime, it records that as
the acknowledged partner lifetime. A server MUST NOT send a BNDREPLY the acknowledged partner lifetime. A server MUST NOT send a BNDREPLY
in response to a BNDUPD message until it is sure that the information message in response to a BNDUPD message until it is sure that the
in the BNDUPD message has been updated in its lease database. See information in the BNDUPD message has been updated in its lease
Section 7.5.2. Thus, the primary server in this case can be sure database. See Section 7.5.2. Thus, the primary server in this case
that the secondary server has recorded the partner lifetime in its can be sure that the secondary server has recorded the partner
stable storage when the primary server receives a BNDREPLY message lifetime in its stable storage when the primary server receives a
from the secondary server. BNDREPLY message from the secondary server.
When the DHCP client attempts to renew at T1 (approximately one half When the DHCP client attempts to renew at T1 (approximately 1/2 hour
an hour from the start of the lease), the primary server again from the start of the lease), the primary server again determines the
determines the desired lifetime, which is still 3 days. It then desired lifetime, which is still 3 days. It then compares this with
compares this with the original acknowledged partner lifetime (1/2 the original acknowledged partner lifetime (1/2 hour + 3 days) and
hour + 3 days) and adjusts for the time passed since the secondary adjusts for the time passed since the secondary was last updated
was last updated (1/2 hour). Thus the time remaining of the (1/2 hour). Thus, the remaining time for the acknowledged partner
acknowledged partner interval is 3 days. Adding the MCLT to this interval is 3 days. Adding the MCLT to this yields 3 days plus
yields 3 days plus 1 hour, which is more than the desired lifetime of 1 hour, which is more than the desired lifetime of 3 days. So, the
3 days. So the client may have its lease renewed for the desired client may have its lease renewed for the desired lifetime -- 3 days.
lifetime -- 3 days.
When the primary DHCP server updates the secondary DHCP server after When the primary DHCP server updates the secondary DHCP server after
the DHCP client's renewal REPLY is complete, it will calculate the the DHCP client's renewal REPLY is complete, it will calculate the
partner lifetime as the T1 fraction of the actual client lifetime partner lifetime as the T1 fraction of the actual client lifetime
(1/2 of 3 days this time = 1.5 days). To this it will add the (1/2 of 3 days = 1.5 days). To this it will add the desired lifetime
desired lifetime of 3 days, yielding a total partner lifetime of 4.5 of 3 days, yielding a total partner lifetime of 4.5 days. In this
days. In this way, the primary attempts to have the secondary always way, the primary attempts to have the secondary always "lead" the
"lead" the client in its understanding of the client's lifetime so as client in its understanding of the client's lifetime so as to be able
to be able to always offer the client the desired lifetime. to always offer the client the desired lifetime.
Once the initial actual client lifetime of the MCLT is past, the Once the initial actual client lifetime of the MCLT has passed, the
protocol operates effectively like the DHCP protocol does today in failover protocol operates effectively like DHCP does today in its
its behavior concerning lifetimes. However, the guarantee that the behavior concerning lifetimes. However, the guarantee that the
actual client lifetime will never exceed the remaining acknowledged actual client lifetime will never exceed the partner server's
partner server partner lifetime by more than the MCLT allows full remaining acknowledged partner lifetime by more than the MCLT allows
recovery from a variety of DHCP server failures. full recovery from a variety of DHCP server failures.
Fundamental relationship: Fundamental relationship:
lease time = floor(desired lifetime, ack-partner-lifetime + MCLT) lease time = floor( desired lifetime, acked-partner-lifetime + MCLT )
Initial conditions: MCLT = 1h, desired lifetime = 3d Initial conditions: MCLT = 1h, desired lifetime = 3d
DHCPv6 Primary Secondary DHCPv6 Primary Secondary
time Client Server Server time Client Server Server
| >-SOLICIT------> | | | >-SOLICIT------> | |
| acknowledged partner lifetime = 0 | | acknowledged partner lifetime = 0 |
| lease time = floor( 3d, 0 + 1h ) = 1h | | lease time = floor( 3d, 0 + 1h ) = 1h |
| <-----ADVERTISE-< | | | <-----ADVERTISE-< | |
| lease-time= 1h | | | lease-time = 1h | |
| >-REQUEST------> | | | >-REQUEST------> | |
t | <---------REPLY-< | | t | <---------REPLY-< | |
| lease-time= 1h | | | lease-time = 1h | |
| | >-BNDUPD------> | | | >-BNDUPD------> |
| | partner-lifetime = 1/2h + 3d | | partner-lifetime = 1/2h + 3d
| | <----BNDREPLY-< | | | <----BNDREPLY-< |
| | partner-lifetime = 1/2h + 3d | | partner-lifetime = 1/2h + 3d
1/2h passes ... ... ... |acknowledged partner lifetime = 1/2h + 3d |
t+1/2h | >-RENEW--------> | | 1/2h passes ... ... ...
| acknowledged partner lifetime = 3d | t+1/2h | >-RENEW--------> | |
| lease time = floor( 3d, 3d + 1h ) = 3d | | acknowledged partner lifetime = 3d |
| <---------REPLY-< | | | lease time = floor( 3d, 3d + 1h ) = 3d |
| lease-time=3d | | | <---------REPLY-< | |
| | >-BNDUPD-------> | | lease-time = 3d | |
| | partner-lifetime = 1.5d + 3d | | >-BNDUPD-------> |
| | <----BNDREPLY-< | | | partner-lifetime = 1.5d + 3d
| | partner-lifetime = 1.5d + 3d | | <----BNDREPLY-< |
acknowledged partner lifetime = 1.5d + 3d | | partner-lifetime = 1.5d + 3d
1.5d passes ... ... ... |acknowledged partner lifetime = 1.5d + 3d |
| | | 1.5d passes ... ... ...
t+1.5d + 1/2h | >-RENEW--------> | | | | |
| acknowledged partner lifetime = 3d | t+1.5d + 1/2h | >-RENEW--------> | |
| lease time = floor( 3d, 3d + 1h ) = 3d | | acknowledged partner lifetime = 3d |
| <---------REPLY-< | | | lease time = floor( 3d, 3d + 1h ) = 3d |
| lease-time=3d | | | <---------REPLY-< | |
| | >-BNDUPD-------> | | lease-time = 3d | |
| | partner-lifetime = 1.5d + 3d | | >-BNDUPD-------> |
| | <----BNDREPLY-< | | | partner-lifetime = 1.5d + 3d
| | partner-lifetime = 1.5d + 3d | | <----BNDREPLY-< |
| acknowledged partner lifetime = 1.5d + 3d| | | partner-lifetime = 1.5d + 3d
|acknowledged partner lifetime = 1.5d + 3d |
Figure 1: MCLT Example Figure 1: MCLT Example
5. Message and Option Definitions 5. Message and Option Definitions
5.1. Message Framing for TCP 5.1. Message Framing for TCP
Failover communication is conducted over a TCP connection established Failover communication is conducted over a TCP connection established
between the partners. The protocol uses the framing format specified between the partners. The failover protocol uses the framing format
in Section 5.1 of DHCPv6 Bulk Leasequery [RFC5460], but uses specified in Section 5.1 of "DHCPv6 Bulk Leasequery" [RFC5460] but
different message types with a different message format, described in uses different message types with a different message format, as
Section 5.2. The TCP connection between failover servers is made to described in Section 5.2 of this document. The TCP connection
a specific port, the dhcp-failover port, port 647. All information between failover servers is made to a specific port -- the
is sent over the connection as typical DHCP messages that convey DHCP dhcp-failover port, port 647. All information is sent over the
options, following the format defined in Section 22.1 of [RFC3315]. connection as typical DHCP messages that convey DHCP options,
following the format defined in Section 22.1 of [RFC3315].
5.2. Failover Message Format 5.2. Failover Message Format
All Failover messages defined below share a common format with a All failover messages defined below share a common format with a
fixed size header and a variable format area for options. All values fixed-size header and a variable format area for options. All values
in the message header and in any included options are in network byte in the message header and in any included options are in network byte
order. order.
The following diagram illustrates the format of DHCP messages The following diagram illustrates the format (which is compatible
exchanged between failover partners (which is compatible with the with the format described in Section 6 of [RFC3315]) of DHCP messages
format described in Section 6 of [RFC3315]): exchanged between failover partners:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id | | msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sent-time | | sent-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | .
. options . . options .
. (variable) . . (variable) .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type Identifies the DHCP message type; the msg-type Identifies the DHCP message type; the
available message types are listed below. available message types are listed below.
Note that since the TCP connection for
failover is made to a unique port, the
msg-type codes are allocated from a registry
distinct from the Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Message Types
registry.
transaction-id The transaction ID for this message exchange. transaction-id The transaction-id for this message exchange.
sent-time The time the message was transmitted (set sent-time The time the message was transmitted (set
as close to transmission as practical), as close to transmission as practical),
in seconds since midnight (UTC), in seconds since midnight (UTC),
January 1, 2000, modulo 2^32. Used to January 1, 2000, modulo 2^32. Used to
determine the time skew of the failover determine the time skew of the failover
partners. partners.
options Options carried in this message. These options Options carried in this message. These
options are all defined in the Dynamic Host options are all defined in the "Option Codes"
Configuration Protocol for IPv6 (DHCPv6) sub-registry of the "Dynamic Host
Option Codes registry. A number of existing Configuration Protocol for IPv6 (DHCPv6)"
DHCPv6 options are used and several more registry. A number of existing DHCPv6
are defined in this document. options are used, and several more are
defined in this document.
5.3. Messages 5.3. Messages
The following list contains the new message types created for The following sections list the new message types defined for
failover communication. failover communication.
5.3.1. BNDUPD 5.3.1. BNDUPD
The binding update message BNDUPD (TBD1) is used to send the binding The binding update message, BNDUPD (24), is used to send the binding
lease changes to the partner. At most one OPTION_CLIENT_DATA option lease changes to the partner. At most one OPTION_CLIENT_DATA option
may appear in a BNDUPD message. Note that not all data in a BNDUPD may appear in a BNDUPD message. Note that not all data in a BNDUPD
is sent in an OPTION_CLIENT_DATA option. Information about delegable message is sent in an OPTION_CLIENT_DATA option. Information about
prefixes not currently allocated to a particular client is sent in delegable prefixes not currently allocated to a particular client is
BNDUPD messages but not within OPTION_CLIENT_DATA options. The sent in BNDUPD messages but not within OPTION_CLIENT_DATA options.
partner is expected to respond with a BNDREPLY message. The partner is expected to respond with a BNDREPLY message.
5.3.2. BNDREPLY 5.3.2. BNDREPLY
The binding acknowledgement message BNDREPLY (TBD2) is used for The binding acknowledgement message, BNDREPLY (25), is used for
confirmation of the received BNDUPD message. It may contain a confirmation of the received BNDUPD message. It may contain a
positive or negative response (e.g. due to detected lease conflict). positive or negative response (e.g., due to a detected lease
conflict).
5.3.3. POOLREQ 5.3.3. POOLREQ
The Pool Request message POOLREQ (TBD3) is used by the secondary The pool request message, POOLREQ (26), is used by the secondary
server to request allocation of delegable prefixes from the primary server to request allocation of delegable prefixes from the primary
server. The primary responds with POOLRESP. server. The primary responds with a POOLRESP message.
5.3.4. POOLRESP 5.3.4. POOLRESP
The Pool Response POOLRESP (TBD4) message is used by the primary The pool response message, POOLRESP (27), is used by the primary
server to indicate that it has received the secondary's servers server to indicate that it has received the secondary server's
request to ensure that delegable prefixes are balanced between the request to ensure that delegable prefixes are balanced between the
primary and secondary servers. It does not indicate that all of the primary and secondary servers. It does not indicate that all of the
BNDUPDs that might be created from any rebalancing have been sent or BNDUPD messages that might be created from any rebalancing have been
responded to, it only indicates reception and acceptance of the task sent or responded to; it only indicates reception and acceptance of
of ensuring the balance is examined and corrected as necessary. the task of ensuring that the balance is examined and corrected as
necessary.
5.3.5. UPDREQ 5.3.5. UPDREQ
The update request message UPDREQ (TBD5) is used by one server to The update request message, UPDREQ (28), is used by one server to
request that its partner sends all binding database changes that have request that its partner send all binding database changes that have
not yet been confirmed. The partner is expected to respond with zero not yet been confirmed. The partner is expected to respond with zero
or more BNDUPD messages, followed by an UPDDONE message that signals or more BNDUPD messages, followed by an UPDDONE message that signals
that all of the BNDUPD messages have been sent and a corresponding that all of the BNDUPD messages have been sent and a corresponding
BNDREPLY message has been received for each of them. BNDREPLY message has been received for each of them.
5.3.6. UPDREQALL 5.3.6. UPDREQALL
The update request all UPDREQALL (TBD6) is used by one server to The update request all message, UPDREQALL (29), is used by one server
request that all binding database information present in the other to request that all binding database information present in the other
server be sent to the requesting server, in order to recover from a server be sent to the requesting server, in order for the requesting
total loss of its binding database by the requesting server. A server to recover from a total loss of its binding database. A
server receiving this request responds with zero or more BNDUPD server receiving this request responds with zero or more BNDUPD
messages, followed by an UPDDONE that signals that all of the BNDUPD messages, followed by an UPDDONE message that signals that all of the
messages have been sent and a corresponding BNDREPLY message has been BNDUPD messages have been sent and a corresponding BNDREPLY message
received for each of them. has been received for each of them.
5.3.7. UPDDONE 5.3.7. UPDDONE
The update done message UPDDONE (TBD7) is used by the server The update done message, UPDDONE (30), is used by the server
responding to an UPDREQ or UPDREQALL to indicate that all requested responding to an UPDREQ or UPDREQALL message to indicate that all
updates have been sent by the responding server and acked by the requested updates have been sent by the responding server and acked
requesting server. by the requesting server.
5.3.8. CONNECT 5.3.8. CONNECT
The connect message CONNECT (TBD8) is used by the primary server to The connect message, CONNECT (31), is used by the primary server to
establish a failover connection with the secondary server, and to establish a failover connection with the secondary server and to
transmit several important configuration attributes items between the transmit several important configuration attributes between the
servers. The partner is expected to confirm by responding with servers. The partner is expected to confirm by responding with a
CONNECTREPLY message. CONNECTREPLY message.
5.3.9. CONNECTREPLY 5.3.9. CONNECTREPLY
The connect acknowledgement message CONNECTREPLY (TBD9) is used by The connect acknowledgement message, CONNECTREPLY (32), is used by
the secondary server to respond to a CONNECT message from the primary the secondary server to respond to a CONNECT message from the primary
server. server.
5.3.10. DISCONNECT 5.3.10. DISCONNECT
The disconnect message DISCONNECT (TBD10) is used by either server The disconnect message, DISCONNECT (33), is used by either server
when closing a connection and shutting down. No response is required when closing a connection and shutting down. No response is required
for this message. The DISCONNECT message SHOULD contain an for this message. The DISCONNECT message SHOULD contain an
OPTION_STATUS_CODE option with an appropriate status. Often this OPTION_STATUS_CODE option with an appropriate status. Often, this
will be ServerShuttingDown. See Section 5.6. A server SHOULD will be ServerShuttingDown. See Section 5.6. A server SHOULD
include a descriptive message as to the reasons causing the include a descriptive message as to what caused the disconnect
disconnect message. message.
5.3.11. STATE 5.3.11. STATE
The state message STATE (TBD11) is used by either server to inform The state message, STATE (34), is used by either server to inform its
its partner about a change of failover state. In some cases it may partner about a change of failover state. In some cases, it may be
be used to also inform the partner about the current state, e.g. used to also inform the partner about the current state, e.g., after
after connection is established in COMMUNICATIONS-INTERRUPTED or connection is established in the COMMUNICATIONS-INTERRUPTED or
PARTNER-DOWN states. PARTNER-DOWN states.
5.3.12. CONTACT 5.3.12. CONTACT
The contact message CONTACT (TBD12) is used by either server to The contact message, CONTACT (35), is used by either server to ensure
ensure that its partner continues to see the connection as that its partner continues to see the connection as operational. It
operational. It MUST be transmitted periodically over every MUST be transmitted periodically over every established connection if
established connection if other message traffic is not flowing, and other message traffic is not flowing, and it MAY be sent at any time.
it MAY be sent at any time. See Section 6.5. See Section 6.5.
5.4. Transaction Id 5.4. Transaction-id
The initiator of a message exchange MUST set the transaction-id. The initiator of a message exchange MUST set the transaction-id (see
This means that all of the messages above except BNDREPLY, POOLRESP, Section 5.2). This means that all of the messages above except
UPDDONE, and CONNECTREPLY must set the tranasction-id. The BNDREPLY, POOLRESP, UPDDONE, and CONNECTREPLY must set the
transaction-id MUST be unique among all currently outstanding transaction-id. The transaction-id MUST be unique among all
messages sent to the failover partner. A straightforward way to currently outstanding messages sent to the failover partner. A
ensure this is to simply use an incrementing value, with one caveat. straightforward way to ensure this is to simply use an incrementing
The UPDREQ and UPDREQALL messages may be separated by a considerable value, with one caveat: The UPDREQ and UPDREQALL messages may be
time prior to the receipt of an UPDDONE message. While the usual separated by a considerable time prior to the receipt of an UPDDONE
pattern of message exchange would have the partner doing the vast message. While the usual pattern of message exchange would have the
majority of message initiation, it is remotely possible that the partner doing the vast majority of message initiation, it is remotely
partner which initiated the UPDREQ or UPDREQALL messages might also possible that the partner that initiated the UPDREQ or UPDREQALL
send enough messages to wrap the 24-bit transaction-id and duplicate messages might also send enough messages to wrap the 24-bit
the transaction-id of the outstanding UPDREQ or UPDREQALL. Thus, it transaction-id and duplicate the transaction-id of the outstanding
is important to ensure that the transaction-id of a currently UPDREQ or UPDREQALL messages. Thus, it is important to ensure that
outstanding UPDREQ or UPDREQALL is not replicated in any message the transaction-id of a currently outstanding UPDREQ or UPDREQALL
initiated prior to the receipt of the corresponding UPDDONE. message is not replicated in any message initiated prior to the
receipt of the corresponding UPDDONE message.
5.5. Options 5.5. Options
The following new options are defined. The following new options are defined.
5.5.1. OPTION_F_BINDING_STATUS 5.5.1. OPTION_F_BINDING_STATUS
The binding-status represents an implementation independent The binding-status is an implementation-independent representation of
representation of the status (or the state) of a lease on an IPv6 the status (or the state) of a lease on an IPv6 address or prefix.
address or prefix.
This is an unsigned byte. This is an unsigned byte.
The code for this option is TBD13. The code for this option is 114.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_BINDING_STATUS | option-len | | OPTION_F_BINDING_STATUS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| binding-status| | binding-status|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
option-code OPTION_F_BINDING_STATUS (TBD13). option-code OPTION_F_BINDING_STATUS (114)
option-len 1. option-len 1
binding-status The binding-status. See below. binding-status The binding-status. See below:
Value binding-status Value binding-status
----- -------------- ----- --------------
0 reserved 0 reserved
1 ACTIVE 1 ACTIVE
2 EXPIRED 2 EXPIRED
3 RELEASED 3 RELEASED
4 PENDING-FREE 4 PENDING-FREE
5 FREE 5 FREE
6 FREE-BACKUP 6 FREE-BACKUP
7 ABANDONED 7 ABANDONED
8 RESET 8 RESET
The binding-status values are discussed in Section 7.2 The binding-status values are discussed in Section 7.2.
5.5.2. OPTION_F_CONNECT_FLAGS 5.5.2. OPTION_F_CONNECT_FLAGS
Flags which indicate attributes of the connecting server. This option provides flags that indicate attributes of the connecting
server.
This consists of an unsigned 16 bit value in network byte order. This option consists of an unsigned 16-bit integer in network byte
order.
The code for this option is TBD14. The code for this option is 115.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_CONNECT_FLAGS | option-len | | OPTION_F_CONNECT_FLAGS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_CONNECT_FLAGS (TBD14). option-code OPTION_F_CONNECT_FLAGS (115)
option-len 2. option-len 2
flags flag bits, see below: flags flag bits. See below:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |F| | MBZ |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bits (numbered from the most-significant bit in network The bits (numbered from the most significant bit in network
byte-order) are used as follows: byte order) are used as follows:
0-14: MBZ 0-14: MBZ
Must be zero Must be zero.
15 (F): FIXED_PD_LENGTH 15 (F): FIXED_PD_LENGTH
Set to 1 to indicate that all prefixes delegated from a Set to 1 to indicate that all prefixes delegated from a
given delegable prefix have the same prefix length (size). given delegable prefix have the same prefix length (size).
If this is not set, the prefixes delegated from one If this is not set, the prefixes delegated from one
delegable prefix may have different sizes. delegable prefix may have different sizes.
If the FIXED_PD_LENGTH bit is not set, it indicates that prefixes of If the FIXED_PD_LENGTH bit is not set, it indicates that prefixes of
a range of sizes can be delegated from a given delegable prefix. a range of sizes can be delegated from a given delegable prefix.
Note that if the FIXED_PD_LENGTH bit is set, each delegable prefix Note that if the FIXED_PD_LENGTH bit is set, each delegable prefix
may have its own fixed size -- this flag does not imply that all may have its own fixed size -- this flag does not imply that all
prefixes delegated will be the same size, rather that all prefixes prefixes delegated will be the same size, but rather that all
delegated from the same delegable prefix will be the same size. prefixes delegated from the same delegable prefix will be the
same size.
If the FIXED_PD_LENGTH bit is set, the length used for each prefix is If the FIXED_PD_LENGTH bit is set, the length used for each prefix is
specified independent of the failover protocol, but must be known to specified independently of the failover protocol but must be known to
both failover partners. It might be specified in the configuration both failover partners. It might be specified in the configuration
for each delegable prefix or it might be fixed for the entire server. for each delegable prefix, or it might be fixed for the entire
server.
5.5.3. OPTION_F_DNS_REMOVAL_INFO 5.5.3. OPTION_F_DNS_REMOVAL_INFO
This option contains the information necessary to remove a DNS name This option contains the information necessary to remove a DNS name
that was entered by the failover partner. that was entered by the failover partner.
The code for this option is TBD15. The code for this option is 116.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_DNS_REMOVAL_INFO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encapsulated-options |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_REMOVAL_INFO (TBD15). 0 1 2 3
option-len variable 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
sub-options Three possible encapsulated options: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPTION_F_DNS_HOST_NAME | OPTION_F_DNS_REMOVAL_INFO | option-len |
OPTION_F_DNS_ZONE_NAME +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OPTION_F_DNS_FLAGS | encapsulated-options |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5.4. OPTION_F_DNS_HOST_NAME option-code OPTION_F_DNS_REMOVAL_INFO (116)
option-len variable
options Three possible encapsulated options:
OPTION_F_DNS_HOST_NAME
OPTION_F_DNS_ZONE_NAME
OPTION_F_DNS_FLAGS
Contains the host name that was entered into DNS by the failover 5.5.3.1. OPTION_F_DNS_HOST_NAME
partner.
This is a DNS name encoded in [RFC1035] format as specified in This option contains the hostname that was entered into the DNS by
Section 8 of [RFC3315]. the failover partner.
The code for this option is TBD16. This is a DNS name encoded using the format specified in [RFC1035],
as also specified in Section 8 of [RFC3315].
0 1 2 3 The code for this option is 117.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_DNS_HOST_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. .
. host-name .
. (variable) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_HOST_NAME (TBD16). 0 1 2 3
option-len length of host-name. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
host-name RFC 1035 encoded host-name. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_DNS_HOST_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. .
. host-name .
. (variable) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5.5. OPTION_F_DNS_ZONE_NAME option-code OPTION_F_DNS_HOST_NAME (117)
option-len length of host-name
host-name hostname encoded per RFC 1035
Contains the zone name that was entered into DNS by the failover 5.5.3.2. OPTION_F_DNS_ZONE_NAME
partner.
This is a DNS name encoded in [RFC1035] format as specified in This option contains the zone name that was entered into the DNS by
Section 8 of [RFC3315]. the failover partner.
The code for this option is TBD17. This is a DNS name encoded using the format specified in [RFC1035],
as also specified in Section 8 of [RFC3315].
0 1 2 3 The code for this option is 118.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_DNS_ZONE_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. .
. zone-name .
. (variable) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_ZONE_NAME (TBD17). 0 1 2 3
option-len length of zone-name. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
zone-name RFC 1035 encoded zone name. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_DNS_ZONE_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .
. .
. zone-name .
. (variable) .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_ZONE_NAME (118)
option-len length of zone-name
zone-name zone name encoded per RFC 1035
5.5.6. OPTION_F_DNS_FLAGS 5.5.3.3. OPTION_F_DNS_FLAGS
Flags which indicate what needs to be done to remove this DNS name. This option provides flags that indicate what needs to be done to
remove this DNS name.
This consists of an unsigned 16 bit value in network byte order. This option consists of an unsigned 16-bit integer in network byte
order.
The code for this option is TBD18. The code for this option is 119.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_DNS_FLAGS | option-len | | OPTION_F_DNS_FLAGS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_FLAGS (TBD18). option-code OPTION_F_DNS_FLAGS (119)
option-len 2. option-len 2
flags flag bits, see below: flags flag bits. See below:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |U|S|R|F| | MBZ |U|S|R|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bits (numbered from the most-significant bit in network The bits (numbered from the most significant bit in network
byte-order) are used as follows: byte order) are used as follows:
0-11: MBZ 0-11: MBZ
Must be zero Must be zero.
12 (U): USING_REQUESTED_FQDN 12 (U): USING_REQUESTED_FQDN
Set to 1 to indicate that name used came from the Set to 1 to indicate that the name used came from the
FQDN that was received from the client. Fully Qualified Domain Name (FQDN) that was received
from the client.
13 (S): SYNTHESIZED_NAME 13 (S): SYNTHESIZED_NAME
Set to 1 to indicate that the name was synthesized Set to 1 to indicate that the name was synthesized
based on some algorithm. based on some algorithm.
14 (R): REV_UPTODATE 14 (R): REV_UPTODATE
Set to 1 to indicate that the reverse zone is up to date. Set to 1 to indicate that the reverse zone is up to date.
15 (F): FWD_UPTODATE 15 (F): FWD_UPTODATE
Set to 1 to indicate that the forward zone is up to date. Set to 1 to indicate that the forward zone is up to date.
If both the U and S bits are unset, then the name must have been If both the U bit and the S bit are unset, then the name must have
provided from some alternative configuration, such as client been provided from some alternative configuration, such as client
registration in some database accessible to the DHCP server. registration in some database accessible to the DHCP server.
5.5.7. OPTION_F_EXPIRATION_TIME 5.5.4. OPTION_F_EXPIRATION_TIME
The greatest lifetime that this server has ever acked to its partner This option specifies the greatest lifetime that this server has ever
in a BNDREPLY for a particular lease or prefix. This MUST be an acked to its partner in a BNDREPLY message for a particular lease or
absolute time (i.e. seconds since midnight January 1, 2000 UTC, prefix. This MUST be an absolute time (i.e., seconds since midnight
modulo 2^32). January 1, 2000 UTC, modulo 2^32).
This is an unsigned 32-bit integer in network byte order. This is an unsigned 32-bit integer in network byte order.
The code for this option is TBD19. The code for this option is 120.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_EXPIRATION_TIME | option-len | | OPTION_F_EXPIRATION_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| expiration-time | | expiration-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_EXPIRATION_TIME (TBD19). option-code OPTION_F_EXPIRATION_TIME (120)
option-len 4. option-len 4
expiration-time The expiration time. This MUST be an expiration-time The expiration time. This MUST be an
absolute time (i.e. seconds since midnight absolute time (i.e., seconds since midnight
January 1, 2000 UTC, modulo 2^32). January 1, 2000 UTC, modulo 2^32).
5.5.8. OPTION_F_MAX_UNACKED_BNDUPD 5.5.5. OPTION_F_MAX_UNACKED_BNDUPD
The maximum number of BNDUPD messages that this server is prepared to This option specifies the maximum number of BNDUPD messages that this
accept over the TCP connection without causing the TCP connection to server is prepared to accept over the TCP connection without causing
block. the TCP connection to block.
This is an unsigned 32-bit integer in network byte order. This is an unsigned 32-bit integer in network byte order.
The code for this option is TBD20. The code for this option is 121.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_MAX_UNACKED_BNDUPD | option-len | | OPTION_F_MAX_UNACKED_BNDUPD | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max-unacked-bndupd | | max-unacked-bndupd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_MAX_UNACKED_BNDUPD (TBD20). option-code OPTION_F_MAX_UNACKED_BNDUPD (121)
option-len 4. option-len 4
max-unacked-bndupd Maximum number of unacked BNDUPD message max-unacked-bndupd Maximum number of unacked BNDUPD messages
allowed. allowed
5.5.9. OPTION_F_MCLT 5.5.6. OPTION_F_MCLT
The maximum-client-lead-time (MCLT) is the upper bound on the The Maximum Client Lead Time (MCLT) is the upper bound on the
difference allowed between the valid lifetime provided to a DHCP difference allowed between the valid lifetime provided to a DHCP
client by a server and the valid lifetime known by that server's client by a server and the valid lifetime known by that server's
failover partner. It is an interval, measured in seconds. See failover partner. It is an interval, measured in seconds. See
Section 4.4. Section 4.4.
This is an unsigned 32-bit integer in network byte order. This is an unsigned 32-bit integer in network byte order.
The code for this option is TBD21. The code for this option is 122.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_MCLT | option-len | | OPTION_F_MCLT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mclt | | mclt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_MCLT (TBD21). option-code OPTION_F_MCLT (122)
option-len 4. option-len 4
mclt The maximum-client-lead-time, in seconds. mclt The MCLT, in seconds
5.5.10. OPTION_F_PARTNER_LIFETIME 5.5.7. OPTION_F_PARTNER_LIFETIME
The time after which the partner can consider an IPv6 address expired This option specifies the time after which the partner can consider
and is able to re-use the IPv6 address. This MUST be an absolute an IPv6 address expired and is able to reuse the IPv6 address.
time (i.e. seconds since midnight January 1, 2000 UTC, modulo 2^32). This MUST be an absolute time (i.e., seconds since midnight
January 1, 2000 UTC, modulo 2^32).
This is an unsigned 32-bit integer in network byte order. This is an unsigned 32-bit integer in network byte order.
The code for this option is TBD22. The code for this option is 123.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_PARTNER_LIFETIME | option-len | | OPTION_F_PARTNER_LIFETIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-lifetime | | partner-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTER_LIFETIME (TBD22). option-code OPTION_F_PARTNER_LIFETIME (123)
option-len 4. option-len 4
partner-lifetime The partner-lifetime. This MUST be an partner-lifetime The partner lifetime. This MUST be an
absolute time (i.e. seconds since midnight absolute time (i.e., seconds since midnight
January 1, 2000 UTC, modulo 2^32). January 1, 2000 UTC, modulo 2^32).
5.5.11. OPTION_F_PARTNER_LIFETIME_SENT 5.5.8. OPTION_F_PARTNER_LIFETIME_SENT
The time that was received in an OPTION_F_PARTNER_LIFETIME This option indicates the time that was received in an
Section 5.5.10 option. This is an exact duplicate (echo) of the time OPTION_F_PARTNER_LIFETIME option (Section 5.5.7). This is an exact
received in the OPTION_F_PARTNER_LIFETIME option, uncorrected and duplicate (echo) of the time received in the
unadjusted in any way. This MUST be an absolute time (i.e. seconds OPTION_F_PARTNER_LIFETIME option; it is not adjusted in any way.
since midnight January 1, 2000 UTC, modulo 2^32). This MUST be an absolute time (i.e., seconds since midnight
January 1, 2000 UTC, modulo 2^32).
This is an unsigned 32-bit integer in network byte order. This is an unsigned 32-bit integer in network byte order.
The code for this option is TBD23. The code for this option is 124.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OPTION_F_PARTNER_LIFETIME_SENT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-lifetime-sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTNER_LIFETIME_SENT (TBD23). 0 1 2 3
option-len 4. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
partner-lifetime-sent The partner-lifetime received in an +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OPTION_F_PARTNER_LIFETIME_SENT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-lifetime-sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTNER_LIFETIME_SENT (124)
option-len 4
partner-lifetime-sent The partner-lifetime received in an
OPTION_F_PARTNER_LIFETIME option. OPTION_F_PARTNER_LIFETIME option.
This MUST be an absolute time This MUST be an absolute time
(i.e. seconds since midnight (i.e., seconds since midnight
January 1, 2000 UTC, modulo 2^32). January 1, 2000 UTC, modulo 2^32).
5.5.12. OPTION_F_PARTNER_DOWN_TIME 5.5.9. OPTION_F_PARTNER_DOWN_TIME
The time that the partner most recently lost communications with its This option specifies the time that the server most recently lost
failover partner. This MUST be an absolute time (i.e. seconds since communications with its failover partner. This MUST be an absolute
midnight January 1, 2000 UTC, modulo 2^32). time (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
This is an unsigned 32-bit integer in network byte order. This is an unsigned 32-bit integer in network byte order.
The code for this option is TBD24. The code for this option is 125.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_PARTNER_DOWN_TIME | option-len | | OPTION_F_PARTNER_DOWN_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-down-time | | partner-down-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTNER_DOWN_TIME (TBD24). option-code OPTION_F_PARTNER_DOWN_TIME (125)
option-len 4. option-len 4
partner-down-time Contains the partner-down-time. This MUST be an partner-down-time Contains the PARTNER-DOWN time. This MUST be
absolute time (i.e. seconds since midnight an absolute time (i.e., seconds since midnight
January 1, 2000 UTC, modulo 2^32). January 1, 2000 UTC, modulo 2^32).
5.5.13. OPTION_F_PARTNER_RAW_CLT_TIME 5.5.10. OPTION_F_PARTNER_RAW_CLT_TIME
The time when the partner most recently interacted with the DHCP This option specifies the time when the partner most recently
client associated with this IPv6 address or prefix. This MUST be an interacted with the DHCP client associated with this IPv6 address or
absolute time (i.e. seconds since midnight January 1, 2000 UTC, prefix. This MUST be an absolute time (i.e., seconds since midnight
modulo 2^32). January 1, 2000 UTC, modulo 2^32).
This is an unsigned 32-bit integer in network byte order. This is an unsigned 32-bit integer in network byte order.
The code for this option is TBD25. The code for this option is 126.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_PARTNER_RAW_CLT_TIME | option-len | | OPTION_F_PARTNER_RAW_CLT_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-raw-clt-time | | partner-raw-clt-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTNER_RAW_CLT_TIME (TBD25). option-code OPTION_F_PARTNER_RAW_CLT_TIME (126)
option-len 4. option-len 4
partner-raw-clt-time Contains the partner-raw-clt-time. This MUST partner-raw-clt-time Contains the partner-raw-clt-time.
be an absolute time (i.e. seconds since This MUST be an absolute time
midnight January 1, 2000 UTC, modulo 2^32). (i.e., seconds since midnight
January 1, 2000 UTC, modulo 2^32).
5.5.14. OPTION_F_PROTOCOL_VERSION 5.5.11. OPTION_F_PROTOCOL_VERSION
The protocol version allows one failover partner to determine the The protocol version allows one failover partner to determine the
version of the protocol being used by the other partner, to allow for version of the protocol being used by the other partner, to allow for
changes and upgrades in the future. Two components are provided, to changes and upgrades in the future. Two components are provided, to
allow for large and small changes to be represented in one 32-bit allow large and small changes to be represented in one 32-bit number.
number. The intent is that large changes would result in an The intent is that large changes would result in an increment of the
increment of the major-version, while small changes would result in value of major-version, while small changes would result in an
an increment of the minor-version. As subsequent updates and increment of the value of minor-version. As subsequent updates and
extensions of this document can define changes to these values in any extensions of this document can define changes to these values in any
way deemed appropriate no attempt is made to further define large and way deemed appropriate, no attempt is made to further define "large"
small in this document. and "small" in this document.
This consists of two unsigned 16-bit integers, in network byte order. This option consists of two unsigned 16-bit integers in network byte
order.
The code for this option is TBD26. The code for this option is 127.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_PROTOCOL_VERSION | option-len | | OPTION_F_PROTOCOL_VERSION | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| major-version | minor-version | | major-version | minor-version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PROTOCOL_VERSION (TBD26). option-code OPTION_F_PROTOCOL_VERSION (127)
option-len 4. option-len 4
major-version The major version of the protocol. Initially 1. major-version The major version of the protocol. Initially 1.
minor-version The minor version of the protocol. Initially 0. minor-version The minor version of the protocol. Initially 0.
5.5.15. OPTION_F_KEEPALIVE_TIME 5.5.12. OPTION_F_KEEPALIVE_TIME
The number of seconds (an interval) within which the server must This option specifies the number of seconds (an interval) within
receive a message from its partner, or it will assume that which the server must receive a message from its partner, or it will
communications from the partner is not ok. assume that communications from the partner are not "OK".
This is an unsigned 32-bit integer in network byte order. This is an unsigned 32-bit integer in network byte order.
The code for this option is TBD27. The code for this option is 128.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_KEEPALIVE_TIME | option-len | | OPTION_F_KEEPALIVE_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keepalive-time | | keepalive-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_KEEPALIVE_TIME (TBD27). option-code OPTION_F_KEEPALIVE_TIME (128)
option-len 4. option-len 4
receive-time The keepalive-time. An interval of seconds. receive-time The keepalive-time. An interval of seconds.
5.5.16. OPTION_F_RECONFIGURE_DATA 5.5.13. OPTION_F_RECONFIGURE_DATA
Contains the information necessary for one failover partner to use This option contains the information necessary for one failover
the reconfigure-key created on the other failover partner. partner to use the reconfigure-key created on the other failover
partner.
The code for this option is TBD28. The code for this option is 129.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_RECONFIGURE_DATA | option-len | | OPTION_F_RECONFIGURE_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reconfigure-time | | reconfigure-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | .
. . . .
. reconfigure-key . . reconfigure-key .
. (variable) . . (variable) .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_RECONFIGURE_DATA (TBD28). option-code OPTION_F_RECONFIGURE_DATA (129)
option-len 4 + length of reconfigure-key. option-len 4 + length of reconfigure-key
reconfigure-time Time at which reconfigure-key was created. reconfigure-time Time at which reconfigure-key was created.
This MUST be an absolute time (i.e. seconds This MUST be an absolute time
since midnight (i.e., seconds since midnight
January 1, 2000 UTC, modulo 2^32). January 1, 2000 UTC, modulo 2^32).
reconfigure-key The reconfigure-key. reconfigure-key The reconfigure key
5.5.17. OPTION_F_RELATIONSHIP_NAME 5.5.14. OPTION_F_RELATIONSHIP_NAME
A name for this failover relationship. Used to distinguish between This option specifies a name for this failover relationship. It is
relationships when there are multiple failover relationships between used to distinguish between relationships when there are multiple
two failover servers. failover relationships between two failover servers.
A UTF-8 encoded text string suitable for display to an end user, This is a UTF-8 encoded text string suitable for display to an end
which MUST NOT be null-terminated. user. It MUST NOT be null-terminated.
The code for this option is TBD29. The code for this option is 130.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_RELATIONSHIP_NAME | option-len | | OPTION_F_RELATIONSHIP_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | .
. . . .
. relationship-name . . relationship-name .
. (variable) . . (variable) .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_RELATIONSHIP_NAME (TBD29). option-code OPTION_F_RELATIONSHIP_NAME (130)
option-len length of relationship-name. option-len length of relationship-name
relationship-name A UTF-8 encoded text string suitable for relationship-name A UTF-8 encoded text string suitable for
display to an end user, which MUST NOT be display to an end user. MUST NOT be
null-terminated. null-terminated.
5.5.18. OPTION_F_SERVER_FLAGS 5.5.15. OPTION_F_SERVER_FLAGS
The OPTION_F_SERVER_FLAGS option specifies information associated The OPTION_F_SERVER_FLAGS option specifies information associated
with the failover endpoint sending the option. with the failover endpoint sending the option.
This is an unsigned byte. This is an unsigned byte.
The code for this option is TBD30. The code for this option is 131.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_SERVER_FLAGS | option-len | | OPTION_F_SERVER_FLAGS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-flags | | server-flags |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
option-code OPTION_F_SERVER_FLAGS (TBD30). option-code OPTION_F_SERVER_FLAGS (131)
option-len 1. option-len 1
server-flags The server flags, see below: server-flags The server flags. See below:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MBZ |A|S|C| | MBZ |A|S|C|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The bits (numbered from the most-significant bit in network The bits (numbered from the most significant bit in network
byte-order) are used as follows: byte order) are used as follows:
0-4 : MBZ 0-4: MBZ
Must be zero Must be zero.
5 (A): ACK_STARTUP 5 (A): ACK_STARTUP
Set to 1 to indicate that the OPTION_F_SERVER_FLAGS most Set to 1 to indicate that the OPTION_F_SERVER_FLAGS option
recently received contained the STARTUP bit set. that was most recently received contained the
6 (S): STARTUP, STARTUP bit set.
MUST be set to 1 whenever the server is in STARTUP state. 6 (S): STARTUP
7 (C): COMMUNICATED MUST be set to 1 whenever the server is in STARTUP state.
Set to 1 to indicate that the sending server has 7 (C): COMMUNICATED
communicated with its partner. Set to 1 to indicate that the sending server has
communicated with its partner.
5.5.19. OPTION_F_SERVER_STATE 5.5.16. OPTION_F_SERVER_STATE
The OPTION_F_SERVER_STATE option specifies the endpoint state of the The OPTION_F_SERVER_STATE option specifies the endpoint state of the
server sending the option. server sending the option.
This is an unsigned byte. This is an unsigned byte.
The code for this option is TBD31. The code for this option is 132.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_SERVER_STATE | option-len | | OPTION_F_SERVER_STATE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server-state | | server-state |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
option-code OPTION_F_SERVER_STATE (TBD31). option-code OPTION_F_SERVER_STATE (132)
option-len 1. option-len 1
server-state Failover endpoint state. server-state Failover endpoint state
Value Server State Value Server State
----- ---------------------------------------------------------- ----- -------------------------------------------------------------
0 reserved 0 reserved
1 STARTUP Startup state (1) 1 STARTUP Startup state (1)
2 NORMAL Normal state 2 NORMAL Normal state
3 COMMUNICATIONS-INTERRUPTED Communication interrupted 3 COMMUNICATIONS-INTERRUPTED Communications interrupted
4 PARTNER-DOWN Partner down 4 PARTNER-DOWN Partner down
5 POTENTIAL-CONFLICT Synchronizing 5 POTENTIAL-CONFLICT Synchronizing
6 RECOVER Recovering bindings from partner 6 RECOVER Recovering bindings from partner
7 SHUTDOWN Shutting down for a long period. 7 RECOVER-WAIT Waiting out MCLT after RECOVER
8 RECOVER-DONE Interlock state prior to NORMAL 8 RECOVER-DONE Interlock state prior to NORMAL
9 RESOLUTION-INTERRUPTED Comm. failed during resolution 9 RESOLUTION-INTERRUPTED Comm. failed during resolution
10 CONFLICT-DONE Primary resolved its conflicts 10 CONFLICT-DONE Primary resolved its conflicts
These states are discussed in detail in Section 8. These states are discussed in detail in Section 8.
(1) The STARTUP state is never sent to the partner server, it is (1) The STARTUP state is never sent to the partner server; it is
indicated by the STARTUP bit in the server-flags options (see indicated by the STARTUP bit in the OPTION_F_SERVER_FLAGS option
Section 8.3). (see Section 8.3).
5.5.20. OPTION_F_START_TIME_OF_STATE 5.5.17. OPTION_F_START_TIME_OF_STATE
The time at which the associated state began to hold its current The OPTION_F_START_TIME_OF_STATE option specifies the time at which
value. When this option appears in a STATE message, the state to the associated state began to hold its current value. When this
which it refers is the server endpoint state. When it appears in an option appears in a STATE message, the state to which it refers is
IA_NA-options, IA_TA-options, or IA_PD-options field , the state to the server endpoint state. When it appears in an IA_NA-options,
which it refers is the binding-status value in the OPTION_IA_NA, IA_TA-options, or IA_PD-options field, the state to which it refers
OPTION_IA_TA, or OPTION_IA_PD option, respectively. This MUST be an is the binding-status value in the OPTION_IA_NA, OPTION_IA_TA, or
absolute time (i.e. seconds since midnight January 1, 2000 UTC, OPTION_IA_PD option, respectively. This MUST be an absolute time
modulo 2^32). (i.e., seconds since midnight January 1, 2000 UTC, modulo 2^32).
This is an unsigned 32-bit integer in network byte order. This is an unsigned 32-bit integer in network byte order.
The code for this option is TBD32. The code for this option is 133.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_START_TIME_OF_STATE | option-len | | OPTION_F_START_TIME_OF_STATE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start-time-of-state | | start-time-of-state |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_START_TIME_OF_STATE (TBD32). option-code OPTION_F_START_TIME_OF_STATE (133)
option-len 4. option-len 4
start-time-of-state The start-time-of-state. This MUST be an start-time-of-state The start time of the current state.
absolute time (i.e. seconds since midnight This MUST be an absolute time (i.e., seconds
January 1, 2000 UTC, modulo 2^32). since midnight January 1, 2000 UTC,
modulo 2^32).
5.5.21. OPTION_F_STATE_EXPIRATION_TIME 5.5.18. OPTION_F_STATE_EXPIRATION_TIME
The state-expiration-time is the time at which the current state of The OPTION_F_STATE_EXPIRATION_TIME option specifies the time at which
this lease will expire. This MUST be an absolute time (i.e. seconds the current state of this lease will expire. This MUST be an
since midnight January 1, 2000 UTC, modulo 2^32). absolute time (i.e., seconds since midnight January 1, 2000 UTC,
modulo 2^32).
Note that states other than ACTIVE may have a time associated with Note that states other than ACTIVE may have a time associated with
them. In particular, EXPIRED might have a time associated with it, them. In particular, EXPIRED might have a time associated with it,
in the event that some sort of "grace period" existed where the lease in the event that some sort of "grace period" existed where the lease
would not be reused for a period after the lease expired. The would not be reused for a period after the lease expired. The
ABANDONED state might have a time associated with it, in the event ABANDONED state might have a time associated with it, in the event
that the servers participating in failover had a time after which an that the servers participating in failover had a time after which an
ABANDONED lease might be placed back into a pool for allocation to a ABANDONED lease might be placed back into a pool for allocation to a
client. In general, if there is an OPTION_STATE_EXPIRATION_TIME client. In general, if there is an OPTION_STATE_EXPIRATION_TIME
associated with a particular state, that indicates the associated associated with a particular state, that indicates that the
state will expire and move to a different state at that time. associated state will expire and move to a different state at
that time.
This is an unsigned 32-bit integer in network byte order. This is an unsigned 32-bit integer in network byte order.
The code for this option is TBD33. The code for this option is 134.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_STATE_EXPIRATION_TIME| option-len | | OPTION_F_STATE_EXPIRATION_TIME| option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| state-expiration-time | | state-expiration-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_STATE_EXPIRATION_TIME (TBD33). option-code OPTION_F_STATE_EXPIRATION_TIME (134)
option-len 4. option-len 4
state-expiration-time The state-expiration-time. This MUST be an state-expiration-time The time at which the current state of the
absolute time (i.e. seconds since midnight lease will expire. This MUST be an
absolute time (i.e., seconds since midnight
January 1, 2000 UTC, modulo 2^32). January 1, 2000 UTC, modulo 2^32).
5.6. Status Codes 5.6. Status Codes
The following new status codes are defined, to be used in the The following new status codes are defined to be used in the
OPTION_STATUS_CODE option. OPTION_STATUS_CODE option.
AddressInUse (TBD34) AddressInUse (16)
One client on one server has leases that are in conflict with the One client on one server has leases that are in conflict with the
leases that the client has on another server. Alternatively, the leases that the client has on another server. Alternatively, the
address could be associated with a different IAID on each server. address could be associated with a different Identity Association
Identifier (IAID) on each server.
ConfigurationConflict (TBD35) ConfigurationConflict (17)
The configuration implied by the information in a BNDUPD (e.g. the The configuration implied by the information in a BNDUPD message
IPV6 address or prefix address) is in direct conflict with the (e.g., the IPv6 address or prefix address) is in direct conflict
information known to the receiving server. with the information known to the receiving server.
MissingBindingInformation (TBD36) MissingBindingInformation (18)
There is insufficient information in a BNDUPD to effectively There is insufficient information in a BNDUPD message to
process it. effectively process it.
OutdatedBindingInformation (TBD37) OutdatedBindingInformation (19)
Returned when the information in a server's binding database The information in a server's binding database conflicts with the
conflicts with the information found in an incoming BNDUPD, and information found in an incoming BNDUPD message and the server
the server believes that the information in its binding database believes that the information in its binding database more
more accurately reflects reality. accurately reflects reality.
ServerShuttingDown (TBD38) ServerShuttingDown (20)
Returned when the server is undergoing an operator directed or The server is undergoing an operator-directed or otherwise planned
otherwise planned shutdown. shutdown.
DNSUpdateNotSupported (TBD39) DNSUpdateNotSupported (21)
Returned when a server receives a BNDUPD with DNS update A server receives a BNDUPD message with DNS update information
information included, and the server doesn't support DNS update. included and the server doesn't support DNS update.
ExcessiveTimeSkew (TBD40) ExcessiveTimeSkew (22)
Returned when a server detects that the time skew between its A server detects that the time skew between its current time and
current time and its partner's current time is greater than 5 its partner's current time is greater than 5 seconds.
seconds.
6. Connection Management 6. Connection Management
Communication between failover partners takes place over a long-lived Communication between failover partners takes place over a long-lived
TCP connection. This connection is always initiated by the primary TCP connection. This connection is always initiated by the primary
server, and if the long-lived connection is lost it is the server, and if the long-lived connection is lost it is the
responsibility of the primary server to attempt to reconnect to the responsibility of the primary server to attempt to reconnect to the
secondary server. The detailed process used by the primary server secondary server. The detailed process used by the primary server
when initiating a connection and by the secondary server when when initiating a connection and by the secondary server when
responding to a connection attempt documented in Section 6.1 is responding to a connection attempt as documented in Section 6.1 is
followed each time a connection is established, regardless of any followed each time a connection is established, regardless of any
previous connection between the failover partners. previous connection between the failover partners.
6.1. Creating Connections 6.1. Creating Connections
Every primary server implementing the failover protocol MUST Every primary server implementing the failover protocol MUST
periodically attempt to create a TCP connection to the dhcp-failover periodically attempt to create a TCP connection to the dhcp-failover
port (647) of all of its configured partners, where the period is port (647) of all of its configured partners, where the period is
implementation dependent and SHOULD be configurable. In the event implementation dependent and SHOULD be configurable. In the event
that a connection has been rejected by a CONNECTREPLY message with a that a connection has been rejected by a CONNECTREPLY message with an
reject-reason option contained in it or a DISCONNECT message, a OPTION_STATUS_CODE option contained in it or a DISCONNECT message, a
server SHOULD reduce the frequency with which it attempts to connect server SHOULD reduce the frequency with which it attempts to connect
to that server but it MUST 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 MUST listen Every secondary server implementing the failover protocol MUST listen
for TCP connection attempts on the dhcp-failover port (647) from a for TCP connection attempts on the dhcp-failover port (647) from a
primary server. primary server.
After a primary server successfully establishes a TCP connection to a After a primary server successfully establishes a TCP connection to a
secondary server, it MUST continue the connection process as secondary server, it MUST continue the connection process as
described in Section 8.2 of [RFC7653]. In the language of that described in Section 8.2 of [RFC7653]. In the language of that
section, the primary failover server operates as the "requestor" and section, the primary failover server operates as the "requestor" and
the secondary failover server operates as the "DHCP server". The the secondary failover server operates as the "DHCP server". The
message that is sent over the newly established connection is a message that is sent over the newly established connection is a
CONNECT message, instead of an ACTIVELEASEQUERY message. CONNECT message, instead of an ACTIVELEASEQUERY message.
When a connection attempt is received by a secondary server, the only When a secondary server receives a connection attempt, the only
information that the secondary server has is the IP address of the information that the secondary server has is the IP address of the
partner initiating a connection. If it has any relationships with partner initiating a connection. If it has any relationships with
the connecting server for which it is a secondary server, it should the connecting server for which it is a secondary server, it should
operate as described in Section 9.1 of [RFC7653], with the exception operate as described in Section 9.1 of [RFC7653], with the exception
that instead of waiting for an Active Leasequery message it will wait that instead of waiting for an Active Leasequery message it will wait
for a CONNECT message. Once it has received the CONNECT message, it for a CONNECT message. Once it has received the CONNECT message, it
will use the information in that message to determine which will use the information in that message to determine which
relationship this connection is to service. relationship this connection is to service.
If it has no secondary relationships with the connecting server, it If it has no secondary relationships with the connecting server, it
MUST drop the connection. MUST drop the 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 MUST listen for CONNECT messages secondary server in a relationship MUST listen for CONNECT messages
from the primary server. from the primary server.
When the CONNECT and CONNECTREPLY exchange successfully produces a When the CONNECT and CONNECTREPLY exchange successfully produces a
working failover connection, the next message sent over a new working failover connection, the next message sent over a new
connection is a STATE message. See Section 6.3. Upon the receipt of connection is a STATE message. See Section 6.3. Upon the receipt of
the STATE message, the receiver can consider communications ok. the STATE message, the receiver can consider communications "OK".
6.1.1. Sending a CONNECT message 6.1.1. Sending a CONNECT Message
The CONNECT message is sent with information about the failover The CONNECT message is sent with information about the failover
configuration on the primary server. The message MUST contain at configuration on the primary server. The message MUST contain at
least the following information in the options area: least the following information in the options area:
o OPTION_F_PROTOCOL_VERSION containing the protocol version that the o OPTION_F_PROTOCOL_VERSION containing the protocol version that the
primary server will use when sending failover messages. primary server will use when sending failover messages.
o OPTION_F_MCLT containing the configured MCLT. o OPTION_F_MCLT containing the configured MCLT.
o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an
interval) within which the server must receive a message from its interval) within which the server must receive a message from its
partner, or it will assume that communications from the partner is partner, or it will assume that communications from the partner
not ok. are not "OK".
o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of
BNDUPD messages that this server is prepared to accept over the BNDUPD messages that this server is prepared to accept over the
failover connection without causing the connection to block. This failover connection without causing the connection to block. This
is to implement application level flow control over the implements application-level flow control over the connection, so
connection, so that a flood of BNDUPD messages does not cause the that a flood of BNDUPD messages does not cause the connection to
connection to block and thereby prevent other messages from being block and thereby prevent other messages from being transmitted
transmitted over the connection and received by the failover over the connection and received by the failover partner.
partner.
o OPTION_F_RELATIONSHIP_NAME containing name of the failover o OPTION_F_RELATIONSHIP_NAME containing the name of the failover
relationship to which this connection applies. If there is no relationship to which this connection applies. If there is no
OPTION_F_RELATIONSHIP_NAME in the CONNECT message, it indicates OPTION_F_RELATIONSHIP_NAME in the CONNECT message, it indicates
that there is only a single relationship between this pair of that there is only a single relationship between this pair of
primary and secondary servers. primary and secondary servers.
o OPTION_F_CONNECT_FLAGS containing information about certain o OPTION_F_CONNECT_FLAGS containing information about certain
attributes of the connecting servers. attributes of the connecting servers.
6.1.2. Receiving a CONNECT message 6.1.2. Receiving a CONNECT Message
A server receiving a CONNECT message must process the information in A server receiving a CONNECT message must process the information in
the message and decide whether or not to accept the connection. The the message and decide whether or not to accept the connection. The
processing is performed as follows: processing is performed as follows:
o sent-time - The secondary server checks the sent-time to see if it o sent-time - The secondary server checks the sent-time to see if it
is within 5 seconds of its current time. See Section 7.1. If it is within 5 seconds of its current time. See Section 7.1. If it
is not, return ExcessiveTimeSkew in the OPTION_STATUS_CODE to is not, return ExcessiveTimeSkew in the OPTION_STATUS_CODE to
reject the CONNECT message. reject the CONNECT message.
o OPTION_F_PROTOCOL_VERSION - The secondary server decides if the o OPTION_F_PROTOCOL_VERSION - The secondary server decides if the
protocol version of the primary server is supported by the protocol version of the primary server is supported by the
secondary server. If it is not, return NotSupported in the secondary server. If it is not, return NotSupported in the
OPTION_STATUS_CODE to reject the CONNECT message. OPTION_STATUS_CODE to reject the CONNECT message.
o OPTION_F_MCLT - Use this MCLT supplied by the primary server. o OPTION_F_MCLT - Use this MCLT supplied by the primary server.
Remember this MCLT and use it until a different MCLT is supplied Remember this MCLT, and use it until a different MCLT is supplied
by some subsequent CONNECT message. by some subsequent CONNECT message.
o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the
FO_KEEPALIVE_TIME when implementing the Unreachability Detection FO_KEEPALIVE_TIME (Section 6.5) when implementing the
algorithm described in Section 6.6. Unreachability Detection algorithm described in Section 6.6.
o OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of o OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of
unacked BNDUPD messages queued to the primary server never exceeds unacked BNDUPD messages queued to the primary server never exceeds
the value in the OPTION_F_MAX_UNACKED_BNDUPD option. the value in the OPTION_F_MAX_UNACKED_BNDUPD option.
o OPTION_F_CONNECT_FLAGS - Ensure that the secondary can process o OPTION_F_CONNECT_FLAGS - Ensure that the secondary server can
information from the primary as specified in the flags. For process information from the primary server as specified in the
example, if the secondary server cannot process prefix delegation flags. For example, if the secondary server cannot process prefix
with variable sized prefixes delegated from the same delegable delegation with variable-sized prefixes delegated from the same
prefix, and the primary server says that it can, the secondary delegable prefix and the primary server says that it can, the
should reject the connection. secondary should reject the connection.
A CONNECT message SHOULD always be followed by a CONNECTREPLY A CONNECT message SHOULD always be followed by a CONNECTREPLY
message, either to accept the connection or to reject the connection message, to either (1) accept the connection or (2) reject the
by including an OPTION_STATUS_CODE option with an error reject. In connection by including an OPTION_STATUS_CODE option with a
order to reject the connection attempt, simply send a CONNECTREPLY status-code indicating the reason for the rejection. If accepting
message with the OPTION_STATUS_CODE with the correct status. If the connection attempt, then send a CONNECTREPLY message with the
accepting the connection attempt, then send a CONNECTREPLY message following information:
with the following information:
o OPTION_F_PROTOCOL_VERSION containing the protocol version being o OPTION_F_PROTOCOL_VERSION containing the protocol version being
used by the secondary server when sending failover messages. used by the secondary server when sending failover messages.
o OPTION_F_MCLT containing the MCLT currently in use on the o OPTION_F_MCLT containing the MCLT currently in use on the
secondary server. This MUST equal the MCLT that was in the secondary server. This MUST equal the MCLT that was in the
OPTION_F_MCLT option in the CONNECT. OPTION_F_MCLT option in the CONNECT message.
o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an
interval) within which the server must receive a message from its interval) within which the server must receive a message from its
partner, or it will assume that communications from the partner is partner, or it will assume that communications from the partner
not ok. are not "OK".
o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of
BNDUPD messages that this server is prepared to accept over the BNDUPD messages that this server is prepared to accept over the
failover connection without causing the connection to block. This failover connection without causing the connection to block. This
is to implement application level flow control over the implements application-level flow control over the connection, so
connection, so that a flood of BNDUPD messages does not cause the that a flood of BNDUPD messages does not cause the connection to
connection to block and thereby prevent other messages from being block and thereby prevent other messages from being transmitted
transmitted over the connection and received by the failover over the connection and received by the failover partner.
partner.
o OPTION_F_CONNECT_FLAGS - Place information into this option to o OPTION_F_CONNECT_FLAGS containing information describing the
describe the attributes of the secondary server that the primary attributes of the secondary server that the primary needs to
needs to know about. know about.
After sending a CONNECTREPLY message to accept the primary server's After sending a CONNECTREPLY message to accept the primary server's
CONNECT message, the secondary server MUST send a STATE message (see CONNECT message, the secondary server MUST send a STATE message (see
Section 6.3). Section 6.3).
6.1.3. Receiving a CONNECTREPLY message 6.1.3. Receiving a CONNECTREPLY Message
A server receiving a CONNECTREPLY message must process the A server receiving a CONNECTREPLY message must process the
information in the message and decide whether or not to continue to information in the message and decide whether or not to continue to
employ the connection. The processing is performed as follows: employ the connection. The processing is performed as follows:
o OPTION_F_PROTOCOL_VERSION - The primary server decides if the o OPTION_F_PROTOCOL_VERSION - The primary server decides if the
protocol version in use by the secondary server is supported by protocol version in use by the secondary server is supported by
the primary server. If it is not, send a DISCONNECT message and the primary server. If it is not, send a DISCONNECT message and
drop the connection. If it is supported, continue processing. It drop the connection. If it is supported, continue processing. It
is possible that the primary and secondary server will each be is possible that the primary and secondary servers will each be
sending different versions of the protocol to the other server. sending different versions of the protocol to the other server.
The extent to which this is supported will be in part defined by
as yet unknown differences in the protocols that the versions The extent to which this is supported will be defined partly by
represent, and in part by the capabilities of the two as-yet-unknown differences in the protocols that the versions
represent and partly by the capabilities of the two
implementations involved in the failover relationship. implementations involved in the failover relationship.
o OPTION_F_MCLT - Compare the MCLT received with the configured o OPTION_F_MCLT - Compare the MCLT received with the configured
MCLT, and if they are different send a DISCONNECT message and drop MCLT. If they are different, send a DISCONNECT message and drop
the connection. the connection.
o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the
FO_KEEPALIVE_TIME when implementing the Unreachability Detection FO_KEEPALIVE_TIME (Section 6.5) when implementing the
algorithm described in Section 6.6. Unreachability Detection algorithm described in Section 6.6.
o OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of o OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of
unacked BNDUPD messages queued to the secondary server never unacked BNDUPD messages queued to the secondary server never
exceeds the value in the OPTION_F_MAX_UNACKED_BNDUPD option. exceeds the value in the OPTION_F_MAX_UNACKED_BNDUPD option.
o OPTION_F_CONNECT_FLAGS - Ensure that the primary can process o OPTION_F_CONNECT_FLAGS - Ensure that the primary server can
information from the secondary as specified in the flags. For process information from the secondary server as specified in the
example, if the primary server cannot process prefix delegation flags. For example, if the primary server cannot process prefix
with variable sized prefixes delegated from the same delegable delegation with variable-sized prefixes delegated from the same
prefix, and the secondary server says that it can, the primary delegable prefix and the secondary server says that it can, the
should drop the connection. primary should drop the connection.
After receiving a CONNECTREPLY message that accepted the primary After receiving a CONNECTREPLY message that accepted the primary
server's CONNECT message, the primary server MUST send a STATE server's CONNECT message, the primary server MUST send a STATE
message (see Section 6.3). message (see Section 6.3).
6.2. Endpoint Identification 6.2. Endpoint Identification
A failover endpoint is always associated with a set of DHCP prefixes A failover endpoint is always associated with a set of DHCP prefixes
that are configured on the DHCP server where the endpoint appears. A that are configured on the DHCP server where the endpoint appears. A
DHCP prefix MUST NOT be associated with more than one failover DHCP prefix MUST NOT be associated with more than one failover
endpoint. endpoint.
The failover protocol SHOULD be configured with one failover The failover protocol SHOULD be configured with one failover
relationship between each pair of failover servers. In this case relationship between each pair of failover servers. In this case,
there is one failover endpoint for that relationship on each failover there is one failover endpoint for that relationship on each failover
partner. This failover relationship MUST have a unique name. partner. This failover relationship MUST have a unique name.
Any failover endpoint can take actions and hold unique states. Any failover endpoint can take actions and hold unique states.
This document frequently describes the behavior of the protocol in This document frequently describes the behavior of the failover
terms of primary and secondary servers, not primary and secondary protocol in terms of primary and secondary servers, not primary and
failover endpoints. However, it is important to remember that every secondary failover endpoints. However, it is important to remember
'server' described in this document is in reality a failover endpoint that every "server" described in this document is in reality a
that resides in a particular process, and that several failover end- failover endpoint that resides in a particular process and that
points may reside in the same server process. several failover endpoints may reside in the same server process.
It is not the case that there is a unique failover endpoint for each It is not the case that there is a unique failover endpoint for each
prefix that participates in a failover relationship. On one server, prefix that participates in a failover relationship. On one server,
there is (typically) one failover endpoint per partner, regardless of there is (typically) one failover endpoint per partner, regardless of
how many prefixes are managed by that combination of partner and how many prefixes are managed by that combination of partner and
role. On a particular server, any given prefix that participates in role. On a particular server, any given prefix that participates in
failover will be associated with exactly one failover endpoint. failover will be associated with exactly one failover endpoint.
When a connection is received from the partner, the unique failover When a connection is received from the partner, the unique failover
endpoint to which the message is directed is determined solely by the endpoint to which the message is directed is determined solely by the
IPv6 address of the partner, the relationship-name, and the role of IPv6 address of the partner, the relationship name, and the role of
the receiving server. the receiving server.
6.3. Sending a STATE message 6.3. Sending a STATE Message
A server MUST send a STATE message to its failover partner whenever A server MUST send a STATE message to its failover partner whenever
the state of the failover endpoint changes. Sending the occasional the state of the failover endpoint changes. Sending the occasional
duplicate STATE message will cause no problems, and not updating the duplicate STATE message will not cause any problems; note, however,
failover partner with information about a failover endpoint state that not updating the failover partner with information about a
change can, in many cases, cause the entire failover protocol to be failover endpoint state change can, in many cases, cause the entire
inoperative. failover protocol to be inoperative.
The STATE message is sent with information about the endpoint state The STATE message is sent with information about the endpoint state
of the failover relationship. The STATE message MUST contain at of the failover relationship. The STATE message MUST contain at
least the following information in the options area: least the following information in the options area:
o OPTION_F_SERVER_STATE containing the state of this failover o OPTION_F_SERVER_STATE containing the state of this failover
endpoint. endpoint.
o OPTION_F_SERVER_FLAGS containing the flag values associated with o OPTION_F_SERVER_FLAGS containing the flag values associated with
this failover endpoint. this failover endpoint.
o OPTION_F_START_TIME_OF_STATE containing the time when this became o OPTION_F_START_TIME_OF_STATE containing the time when this became
the state of this failover endpoint. the state of this failover endpoint.
o OPTION_F_PARTNER_DOWN_TIME containing time that this failover o OPTION_F_PARTNER_DOWN_TIME containing the time that this failover
endpoint went into PARTNER-DOWN state if this server is in endpoint went into PARTNER-DOWN state if this server is in
PARTNER-DOWN state. If this server isn't in PARTNER-DOWN state, PARTNER-DOWN state. If this server isn't in PARTNER-DOWN state,
do not include this option. do not include this option.
The server sending a STATE message SHOULD ensure that this The server sending a STATE message SHOULD ensure that this
information is written to stable storage prior to enqueuing it to its information is written to stable storage prior to enqueuing it to its
failover partner. failover partner.
6.4. Receiving a STATE message 6.4. Receiving a STATE Message
A server receiving a STATE message must process the information in A server receiving a STATE message must process the information in
the message and decide how to react to the information. The the message and decide how to react to the information. The
processing is performed as follows: processing is performed as follows:
o OPTION_F_SERVER_STATE - If this represents a change in state for o OPTION_F_SERVER_STATE - If this represents a change in state for
the failover partner, react according to the direction in the failover partner, react according to the instructions in
Section 8.1. If the state is not PARTNER-DOWN, clear any memory Section 8.1. If the state is not PARTNER-DOWN, clear any memory
of the partner-down-time. of the partner-down-time.
o OPTION_F_SERVER_FLAGS - Remember these flags in an appropriate o OPTION_F_SERVER_FLAGS - Remember these flags in an appropriate
data area so they can be referenced by code implementing other data area so they can be referenced later.
parts of this document.
o OPTION_F_START_TIME_OF_STATE - Remember this information in an o OPTION_F_START_TIME_OF_STATE - Remember this information in an
appropriate data area. appropriate data area so it can be referenced later.
o OPTION_F_PARTNER_DOWN_TIME - Remember this information in an o OPTION_F_PARTNER_DOWN_TIME - If the value of the
appropriate data area if the value of the OPTION_F_SERVER_STATE is OPTION_F_SERVER_STATE is PARTNER-DOWN, remember this information
PARTNER-DOWN. in an appropriate data area so it can be referenced later.
A server receiving a STATE message SHOULD ensure that this A server receiving a STATE message SHOULD ensure that this
information is written to stable storage. information is written to stable storage.
6.5. Connection Maintenance Parameters 6.5. Connection Maintenance Parameters
The following parameters and timers are used to ensure the integrity The following parameters and timers are used to ensure the integrity
of the connections between two failover servers. of the connections between two failover servers.
Parameter Default Description Parameter Default Description
------------------------------------------ ---------------------------------------------------------------------
FO_KEEPALIVE_TIMER timer counts down to time connection FO_KEEPALIVE_TIMER timer counts down to time
assumed dead due to lack of messages connection assumed dead
due to lack of messages
FO_KEEPALIVE_TIME 60 maximum time server will consider FO_KEEPALIVE_TIME 60 maximum time server will
connection still up with no messages consider connection still up
with no messages
FO_CONTACT_PER_KEEPALIVE_TIME number of CONTACT messages to send FO_CONTACT_PER_KEEPALIVE_TIME 4 number of CONTACT messages
4 during partner's FO_KEEPALIVE_TIME to send during partner's
period FO_KEEPALIVE_TIME period
FO_SEND_TIMER timer counts down to time to send next FO_SEND_TIMER timer counts down to time to send
CONTACT message next CONTACT message
FO_SEND_TIME 15 maximum time to wait between sending FO_SEND_TIME 15 maximum time to wait between
CONTACT messages if no other traffic sending CONTACT messages
Created from partner's FO_KEEPALIVE_TIME if no other traffic.
divided by FO_CONTACT_PER_KEEPALIVE_TIME Created from partner's
FO_KEEPALIVE_TIME divided by
FO_CONTACT_PER_KEEPALIVE_TIME
6.6. Unreachability detection 6.6. Unreachability Detection
Each partner MUST maintain an FO_SEND_TIMER for each failover Each partner MUST maintain an FO_SEND_TIMER for each failover
connection. The FO_SEND_TIMER for a particular connection is reset connection. The FO_SEND_TIMER for a particular connection is reset
to FO_SEND_TIME every time any message is transmitted on that to FO_SEND_TIME every time any message is transmitted on that
connection, and counts down once per second. If the timer reaches connection, and the timer counts down once per second. If the timer
zero, a CONTACT message is transmitted on that connection and the reaches zero, a CONTACT message is transmitted on that connection and
timer for that connection is reset to FO_SEND_TIME. The CONTACT the timer for that connection is reset to FO_SEND_TIME. The CONTACT
message may be transmitted at any time. An implementation MAY use message may be transmitted at any time. An implementation MAY use
additional mechanisms to detect partner unreachability. additional mechanisms to detect partner unreachability.
The FO_SEND_TIME is initialized from the configured FO_KEEPALIVE_TIME The FO_SEND_TIME is initialized from the configured FO_KEEPALIVE_TIME
divided by FO_CONTACT_PER_KEEPALIVE_TIME. When a CONNECT or divided by FO_CONTACT_PER_KEEPALIVE_TIME. When a CONNECT or
CONNECTREPLY message is received on a connection, the received CONNECTREPLY message is received on a connection, the received
OPTION_F_KEEPALIVE_TIME option is checked, and the value in that OPTION_F_KEEPALIVE_TIME option is checked, and the value in that
option is used to calculate the FO_SEND_TIME for that connection by option is used to calculate the FO_SEND_TIME for that connection by
dividing the value received by the configured dividing the value received by the configured
FO_CONTACT_PER_KEEPALIVE_TIME. FO_CONTACT_PER_KEEPALIVE_TIME.
Each partner MUST maintain an FO_KEEPALIVE_TIMER for each failover Each partner MUST maintain an FO_KEEPALIVE_TIMER for each failover
connection. This timer is initialized to FO_KEEPALIVE_TIME and connection. This timer is initialized to FO_KEEPALIVE_TIME and
counts down once per second. It is reset to FO_KEEPALIVE_TIME counts down once per second. It is reset to FO_KEEPALIVE_TIME
whenever a message is received on that connection. If it ever whenever a message is received on that connection. If it ever
reaches zero, that connection is considered dead. In addition, the reaches zero, that connection is considered dead. In addition, the
FO_KEEPALIVE_TIME for that connection MUST be sent to the failover FO_KEEPALIVE_TIME for that connection MUST be sent to the failover
partner on every CONNECT or CONNECTREPLY messages, in the partner on every CONNECT or CONNECTREPLY message in the
OPTION_F_KEEPALIVE_TIME option. OPTION_F_KEEPALIVE_TIME option.
7. Binding Updates and Acks 7. Binding Updates and Acks
7.1. Time Skew 7.1. Time Skew
Partners exchange information about known lease states. To reliably Partners exchange information about known lease states. To reliably
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. The known lease state with the times received in the update. The
failover protocol adopts the simple approach of requiring that the failover protocol adopts the simple approach of requiring that the
failover partners use some mechanism to synchronize the clocks on the failover partners use some mechanism to synchronize the clocks on the
two servers to within an accuracy of roughly 5 seconds. two servers to within an accuracy of roughly 5 seconds.
A mechanism to measure and track relative time differences between A mechanism to measure and track relative time differences between
servers is necessary to ensure this synchronization. To do so, each servers is necessary to ensure this synchronization. To do so, each
message contains the time of the transmission in the time context of message contains the time of the transmission in the sent-time field
the transmitter in the sent-time field of the message (see of the message (see Section 5.2). The transmitting server MUST set
Section 5.2). The transmitting server MUST set this as close to the this as close to the actual transmission as possible. The receiving
actual transmission as possible. The receiving partner MUST store partner MUST store its own timestamp of reception as close to the
its own timestamp of reception as close to the actual reception as actual reception as possible. The received timestamp information is
possible. The received timestamp information is then compared with then compared with the local timestamp.
local timestamp.
7.2. Information model 7.2. Information Model
In most DHCP servers a lease on an IPv6 address or a prefix can take In most DHCP servers, a lease on an IPv6 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 will have "lease states". While no two DHCP server implementations will 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.
In order to transmit binding database updates between one server and In order to transmit binding database updates between one server and
another using the failover protocol, some common binding-status another using the failover protocol, some common binding-status
values must be defined. It is not expected that these values values must be defined. It is not expected that these values
correspond with any actual implementation of the DHCPv6 protocol in a correspond to any actual implementation of DHCPv6 in a DHCP server,
DHCP server, but rather that the binding-status values defined in but rather that the binding-status values defined in this document
this document should be convertible back and forth between those should be convertible back and forth between those defined below and
defined below and those in use by many DHCP server implementations. those in use by many DHCP server implementations.
The lease binding-status values defined for the failover protocol are The lease binding-status values defined for the failover protocol are
listed below. Unless otherwise noted below, there MAY be client listed below. Unless otherwise noted below, there MAY be client
information associated with each of these binding-status value. information associated with each of these binding-status values.
ACTIVE -- The lease is assigned to a client. Client identification ACTIVE - The lease is assigned to a client. Client identification
data MUST appear. data MUST appear.
EXPIRED -- indicates that a client's binding on a given lease has EXPIRED - This value indicates that a client's binding on a given
expired. When the partner acks the BNDUPD of an expired lease, lease has expired. When the partner acks the BNDUPD message of an
the server sets its internal state to PENDING-FREE. Client expired lease, the server sets its internal state to PENDING-FREE.
identification SHOULD appear. Client identification SHOULD appear.
RELEASED -- indicates that a client sent a RELEASE message. When RELEASED - This value indicates that a client sent a RELEASE message.
the partner acks the BNDUPD of a released lease, the server sets When the partner acks the BNDUPD message of a released lease, the
its internal state to PENDING-FREE. Client identification SHOULD server sets its internal state to PENDING-FREE. Client
appear. identification SHOULD appear.
PENDING-FREE -- Once a lease is expired or released, its state PENDING-FREE - Once a lease is expired or released, its state becomes
becomes PENDING-FREE. Depending on which algorithm and which pool PENDING-FREE. Depending on which algorithm was used to allocate a
was used to allocate a given lease, PENDING-FREE may either mean given lease, PENDING-FREE may mean either FREE or FREE-BACKUP.
FREE or FREE-BACKUP. Implementations do not have to implement Implementations do not have to implement this PENDING-FREE state
this PENDING-FREE state, but may choose to switch to the but may choose to switch to the destination state directly. For
destination state directly. For clarity of representation, this clarity of representation, this transitional PENDING-FREE state is
transitional PENDING-FREE state is treated as a separate state. treated as a separate state.
FREE -- Is used when a DHCP server needs to communicate that a lease FREE - This value is used when a DHCP server needs to communicate
is unused by any client, but it was not just released, expired or that a lease is unused by any client, but it was not just
reset by a network administrator. When the partner acks the released, expired, or reset by a network administrator. When the
BNDUPD of a FREE lease, the server marks the lease as available partner acks the BNDUPD message of a FREE lease, the server marks
for assignment by the primary server. Note that on a secondary the lease as available for assignment by the primary server. Note
server running in PARTNER-DOWN state, after waiting the MCLT, the that on a secondary server running in PARTNER-DOWN state, after
lease MAY be allocated to a client by the secondary server. waiting the MCLT, the lease MAY be allocated to a client by the
Client identification MAY appear and indicates the last client to secondary server. Client identification MAY appear and indicates,
have used this lease as a hint. as a hint, the last client to have used this lease.
FREE-BACKUP -- indicates that this lease can be allocated by the FREE-BACKUP - This value indicates that this lease can be allocated
secondary server to a client at any time. Note that on the by the secondary server to a client at any time. Note that on the
primary server running in PARTNER-DOWN state, after waiting the primary server running in PARTNER-DOWN state, after waiting the
MCLT, the lease MAY be allocated to a client by the primary server MCLT, the lease MAY be allocated to a client by the primary server
if proportional algorithm was used. Client identification MAY if the proportional algorithm was used. Client identification MAY
appear and indicates the last client to have used this lease as a appear and indicates, as a hint, the last client to have used this
hint. lease.
ABANDONED -- indicates that a lease is considered unusable by the ABANDONED - This value indicates that a lease is considered unusable
DHCP system. The primary reason for entering such state is by the DHCP system. The primary reason for entering such a state
reception of DECLINE message for the lease. Client identification is the reception of a DECLINE message for the lease. Client
MAY appear. identification MAY appear.
RESET -- indicates that this lease was made available by operator RESET - This value indicates that this lease was made available by an
command. This is a distinct state so that the reason that the operator command. This is a distinct state so that the reason
lease became FREE can be determined. Client identification MAY that the lease became FREE can be determined. Client
appear. identification MAY appear.
Which binding-status values are associated with a timeout is Which binding-status values are associated with a timeout is
implementation dependent. Some binding-status values such as ACTIVE implementation dependent. Some binding-status values, such as
will have a timeout value in all implementations, while others such ACTIVE, will have a timeout value in all implementations, while
as ABANDONDED will have a timeout value in some implementations and others, such as ABANDONED, will have a timeout value in some
not in others. In some implementations a binding-status value may be implementations and not in others. In some implementations, a
associated with a timeout in some circumstances and not in other binding-status value may be associated with a timeout in some
circumstances. The receipt of a BNDUPD with a particular binding- circumstances and not in others. The receipt of a BNDUPD message
status value and an OPTION_F_STATE_EXPIRATION_TIME indicates that with a particular binding-status value and an
this particular binding-status value is associated with a timeout. OPTION_F_STATE_EXPIRATION_TIME indicates that this particular
binding-status value is associated with a timeout.
The lease state machine is presented in Figure 2. Most states are The lease state machine is presented in Figure 2. Most states are
stationary, i.e. the lease stays in a given state until external stationary, i.e., the lease stays in a given state until an external
event triggers transition to another state. The only transitive event triggers transition to another state. The only transitive
state is PENDING-FREE. Once it is reached, the state machine state is PENDING-FREE. Once it is reached, the state machine
immediately transitions to either FREE or FREE-BACKUP state. immediately transitions to either FREE or FREE-BACKUP state.
+---------+ +---------+
/------------->| ACTIVE |<--------------\ /------------->| ACTIVE |<--------------\
| +---------+ | | +---------+ |
| | | | | | | | | |
| /--(8)--/ (3) \--(9)-\ | | /--(8)--/ (3) \--(9)-\ |
| | | | | | | | | |
| V V V | | V V V |
| +-------+ +--------+ +---------+ | | +-------+ +--------+ +---------+ |
| |EXPIRED| |RELEASED| |ABANDONED| | | |EXPIRED| |RELEASED| |ABANDONED| |
| +-------+ +--------+ +---------+ | | +-------+ +--------+ +---------+ |
| | | | | | | | | |
| | | (10) | | | | (10) |
| | | V | | | | V |
| | | +---------+ | | | | +---------+ |
| | | | RESET | | | | | | RESET | |
| | | +---------+ | | | | +---------+ |
| | | | | | | | | |
| \--(4)--\ (4) /--(4)--/ | | \--(4)--\ (4) /--(4)--/ |
| | | | | | | | | |
(1) V V V (2) (1) V V V (2)
| /---------\ | | /---------\ |
| | PENDING | | | | PENDING-| |
| | FREE | | | | FREE | |
| \---------/ | | \---------/ |
| | | | | | | |
| /-(5)--/ \-(6)-\ | | /-(5)--/ \-(6)-\ |
| | | | | | | |
| V V | | V V |
| +-------+ +-----------+ | | +-------+ +-----------+ |
\----| FREE |<--(7)-->|FREE-BACKUP|-----/ \----| FREE |<--(7)-->|FREE-BACKUP|-----/
+-------+ +-----------+ +-------+ +-----------+
PENDING-FREE transition PENDING-FREE transition
Figure 2: Lease State Machine Figure 2: Lease State Machine
Transitions between states are results of the following events: Transitions between states will result from the following events:
1. Primary server allocates a lease. (1) The primary server allocates a lease.
2. Secondary server allocates a lease. (2) The secondary server allocates a lease.
3. Client sends RELEASE and the lease is released. (3) The client sends RELEASE, and the lease is released.
4. Partner acknowledges state change. This transition MAY also (4) The partner acknowledges the state change. This transition MAY
occur if the server is in PARTNER-DOWN state and the MCLT has also occur if the server is in PARTNER-DOWN state and the MCLT
passed since the entry into RELEASED, EXPIRED, or RESET states. has passed since the entry into RELEASED, EXPIRED, or RESET
states.
5. The lease belongs to a pool that is governed by the (5) The lease belongs to a pool that is governed by proportional
proportional allocation, or independent allocation is used and allocation, or independent allocation is used and this lease
this lease belongs to primary server pool. belongs to the primary server's pool.
6. The lease belongs to a pool that is governed by the (6) The lease belongs to a pool that is governed by independent
independent allocation and the lease belongs to the secondary allocation, and the lease belongs to the secondary server.
server.
7. Pool rebalance event occurs (POOLREQ/POOLRESP messages are (7) A pool rebalance event occurs (POOLREQ/POOLRESP messages are
exchanged). Delegable prefixes belonging to the primary server exchanged). Delegable prefixes belonging to the primary server
can be assigned to the secondary server pool (transition from FREE can be assigned to the secondary server's pool (transition from
to FREE-BACKUP) or vice versa. 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) A DECLINE message is received, or a lease is deemed unusable
other reasons. for other reasons.
10. An administrative action is taken to recover an abandoned (10) An administrative action is taken to restore an abandoned lease
lease back to usable state. This transition MAY occur due to an to a usable state. This transition MAY occur due to
implementation specific handling on ABANDONED lease. One possible implementation-specific handling of an ABANDONED lease. One
example of such use is a Neighbor Discovery or ICMPv6 Echo check possible example of this is a Neighbor Discovery or ICMPv6 Echo
if the address is still in use. check to see if the address is still in use.
The lease that is no longer in use (due to expiration or release), The lease that is no longer in use (due to expiration or release)
becomes PENDING-FREE. Depending on what allocation algorithm is becomes PENDING-FREE. Depending on what allocation algorithm is
used, the lease that is no longer is use, returns to the primary used, the lease that is no longer in use returns to the primary pool
(FREE) or secondary pool (FREE-BACKUP). The conditions for specific (FREE) or the secondary pool (FREE-BACKUP). The conditions for
transitions are depicted in Figure 3. specific transitions are depicted in Figure 3.
+----------------+---------+-----------+ +----------------+---------+-----------+
| \ Lease owner| | | | \ Lease owner| | |
| \----------\ | Primary | Secondary | | \----------\ | Primary | Secondary |
|Algorithm \ | | | |Algorithm \ | | |
+----------------+---------+-----------+ +----------------+---------+-----------+
| Proportional | FREE |FREE-BACKUP| | Proportional | FREE |FREE-BACKUP|
| Independent | FREE | FREE | | Independent | FREE | FREE |
+----------------+---------+-----------+ +----------------+---------+-----------+
Figure 3: PENDING-FREE State Transitions Figure 3: PENDING-FREE State Transitions
7.3. Times Required for Exchanging Binding Updates 7.3. Times Required for Exchanging Binding Updates
Each server must keep track of the following specific times beyond Each server must keep track of the following specific times beyond
those required by the base DHCP protocol [RFC3315]. those required by the base DHCP specification [RFC3315].
expiration-time expiration-time
The greatest lifetime that this server has ever acked to its The greatest lifetime that this server has ever acked to its
failover partner in a BNDREPLY. failover partner in a BNDREPLY message.
acked-partner-lifetime acked-partner-lifetime
The greatest lifetime that the failover partner has ever acked to The greatest lifetime that the failover partner has ever acked to
this server in a BNDREPLY. this server in a BNDREPLY message.
partner-lifetime partner-lifetime
The time that we will send (or have sent) the partner, which will The time value that will be sent (or that has been sent) to the
be the time after which the partner can consider the lease partner to indicate the time after which the partner can consider
expired. When we receive a BNDUPD this value can be updated from the lease expired. When a BNDUPD message is received, this value
the received OPTION_F_EXPIRATION_TIME. can be updated from the received OPTION_F_EXPIRATION_TIME.
client-last-transaction-time client-last-transaction-time
The time when this server most recently interacted with the client The time when this server most recently interacted with the client
associated with this lease. associated with this lease.
partner-raw-clt-time partner-raw-clt-time
The time when the partner most recently interacted with the client The time when the partner most recently interacted with the client
associated with this lease. This time remains exactly as it was associated with this lease. This time remains exactly as it was
received by this server, and MUST NOT be adjusted to be in the received by this server and MUST NOT be adjusted in any way.
time context of this server.
start-time-of-state start-time-of-state
The time when the binding-status of this lease was changed to its The time when the binding-status of this lease was changed to its
current value. current value.
state-expiration-time state-expiration-time
The time when the current state of this lease will expire. The time when the current state of this lease will expire.
7.4. Sending Binding Updates 7.4. Sending Binding Updates
Every BNDUPD message contains information about either a single Every BNDUPD message contains information about either (1) a single
client binding in an OPTION_CLIENT_DATA option that include IAADDR or client binding in an OPTION_CLIENT_DATA option that includes IAADDR
IAPREFIX options associated with that client, or a single prefix or IAPREFIX options associated with that client or (2) a single
lease in an OPTION_IAPREFIX option for prefixes that are currently prefix lease in an OPTION_IAPREFIX option for prefixes that are
not associated with any clients. currently not associated with any clients.
All information about a particular client binding MUST be contained All information about a particular client binding MUST be contained
in a single OPTION_CLIENT_DATA option (see Section 4.1.2.2 of in a single OPTION_CLIENT_DATA option (see Section 4.1.2.2 of
[RFC5007]). The OPTION_CLIENT_DATA option contains at least the data [RFC5007]). The OPTION_CLIENT_DATA option contains at least the data
shown below in its client-options section: shown below in its client-options section:
o OPTION_CLIENTID containing the DUID of the client most recently o OPTION_CLIENTID containing the DUID of the client most recently
associated with this lease MUST appear; associated with this lease MUST appear.
o OPTION_LQ_BASE_TIME containing the absolute time that the o OPTION_LQ_BASE_TIME containing the absolute time that the
information was placed into this OPTION_CLIENT_DATA option (see information was placed in this OPTION_CLIENT_DATA option (see
Section 6.3.1 of [RFC7653]) MUST appear; Section 6.3.1 of [RFC7653]) MUST appear.
o OPTION_VSS (see Section 3.4 of [RFC6607]) This option MUST NOT o OPTION_VSS (see Section 3.4 of [RFC6607]). This option MUST NOT
appear if the information in this OPTION_CLIENT_DATA option is appear if the information in this OPTION_CLIENT_DATA option is
associated with the global, default VPN. This option MUST appear associated with the global, default VPN. This option MUST appear
if the information in this OPTION_CLIENT_DATA option is associated if the information in this OPTION_CLIENT_DATA option is associated
with a VPN other than the global, default VPN. Support of with a VPN other than the global, default VPN. Support of
[RFC6607] is not required, and OPTION_VSS is only used if a VPN [RFC6607] is not required, and if it is not supported, then an
other than the global, default VPN is used, which requires support OPTION_VSS MUST NOT appear. If [RFC6607] is supported, then an
of [RFC6607]; OPTION_VSS MUST appear if and only if a VPN other than the global,
default VPN is used.
o OPTION_F_RECONFIGURE_DATA containing the time and reconfigure key, o OPTION_F_RECONFIGURE_DATA containing the time and reconfigure key,
if any; if any.
o OPTION_LQ_RELAY_DATA containing information described in o OPTION_LQ_RELAY_DATA containing information described in
Section 4.1.2.4 of [RFC5007], if any exists; Section 4.1.2.4 of [RFC5007], if any exists.
o OPTION_IA_NA or OPTION_IA_TA for an IPv6 Address or OPTION_IA_PD o OPTION_IA_NA or OPTION_IA_TA for an IPv6 address, or OPTION_IA_PD
for an IPv6 Prefix. More than one of either of these options MAY for an IPv6 prefix. More than one of either of these options MAY
appear if there are more than one associated with this client. At appear if more than one of them are associated with this client.
least one MUST appear; At least one of an OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
must appear.
* IAID - Identity Association used by the client, while obtaining * IAID - Identity Association used by the client, while obtaining
a given lease. (Note1: one client may use many IAIDs a given lease. Note that (1) one client may use many IAIDs
simultaneously. Note2: IAID for IA, TA and PD are orthogonal simultaneously and (2) IAIDs for OPTION_IA_NA, OPTION_IA_TA,
number spaces.); and OPTION_IA_PD are orthogonal number spaces.
* T1 time sent to client; * T1 time sent to client.
* T2 time sent to client; * T2 time sent to client.
* Inside of the IA_NA-options, IA_TA-options, or IA_PD-option * Inside of the IA_NA-options, IA_TA-options, or IA_PD-options
sections: sections:
+ OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for + OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for
a IPv6 prefix MUST appear; an IPv6 prefix MUST appear.
- IPv6 Address or IPv6 Prefix (with length); - IPv6 address or IPv6 prefix (with length).
- preferred lifetime sent to client; - Preferred lifetime sent to client.
- valid lifetime sent to client; - Valid lifetime sent to client.
- Inside of the IAaddr-options or IAprefix-options: - Inside of the IAaddr-options or IAprefix-options:
o OPTION_F_BINDING_STATUS containing the binding-status o OPTION_F_BINDING_STATUS containing the binding-status
MUST appear; MUST appear.
o OPTION_F_START_TIME_OF_STATE containing the start- o OPTION_F_START_TIME_OF_STATE containing the
time-of-state MUST appear; start-time-of-state MUST appear.
o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing
the state-expiration-time*; the state-expiration-time*.
o OPTION_CLT_TIME (relative) containing the client-last- o OPTION_CLT_TIME (relative) containing the
transaction-time. See [RFC5007] for this option; client-last-transaction-time. See [RFC5007] for a
description of this option.
o OPTION_F_PARTNER_LIFETIME (absolute) containing o OPTION_F_PARTNER_LIFETIME (absolute) containing the
partner-lifetime*; partner-lifetime*.
o OPTION_F_PARTNER_RAW_CLT_TIME (absolute) containing o OPTION_F_PARTNER_RAW_CLT_TIME (absolute) containing
the partner-raw-clt-time; the partner-raw-clt-time.
o OPTION_F_EXPIRATION_TIME (absolute) containing the o OPTION_F_EXPIRATION_TIME (absolute) containing the
expiration-time*; expiration-time*.
o DHCP_O_CLIENT_FQDN containing the FQDN information o OPTION_CLIENT_FQDN containing the FQDN information
associated with this lease and client, if any; associated with this lease and client, if any.
Information about a prefix lease is contained in a single Information about a prefix lease is contained in a single
OPTION_IAPREFIX option. Only a single OPTION_IAPREFIX option may OPTION_IAPREFIX option. Only a single OPTION_IAPREFIX option may
appear in a BNDUPD message outside of an OPTION_CLIENT_DATA option. appear in a BNDUPD message outside of an OPTION_CLIENT_DATA option.
In detail: In detail:
o OPTION_IAPREFIX for a prefix lease; o OPTION_IAPREFIX for a prefix lease.
* IPv6 Prefix (with length); * IPv6 prefix (with length).
* Inside of the IAprefix-options section: * Inside of the IAprefix-options section:
+ OPTION_VSS (see Section 3.4 of [RFC6607]) This option MUST + OPTION_VSS (see Section 3.4 of [RFC6607]). This option
NOT appear if the information in this OPTION_IAPREFIX option MUST NOT appear if the information in this OPTION_IAPREFIX
is associated with the global, default VPN. This option option is associated with the global, default VPN. This
MUST appear if the information in this OPTION_IAPREFIX option MUST appear if the information in this
option is associated with a VPN other than the global, OPTION_IAPREFIX option is associated with a VPN other than
default VPN. Support of [RFC6607] is not required, and the global, default VPN. Support of [RFC6607] is not
OPTION_VSS is only used if a VPN other than the global, required, and if it is not supported, then an OPTION_VSS
default VPN is used, which requires support of [RFC6607]; MUST NOT appear. If [RFC6607] is supported, then an
OPTION_VSS MUST appear if and only if a VPN other than the
global, default VPN is used.
+ OPTION_LQ_BASE_TIME containing the absolute time that this + OPTION_LQ_BASE_TIME containing the absolute time that this
information was placed into this OPTIONS_IAPREFIX option information was placed in this OPTIONS_IAPREFIX option (see
(see Section 6.3.1 of [RFC7653]) MUST appear; Section 6.3.1 of [RFC7653]) MUST appear.
+ OPTION_F_BINDING_STATUS containing the binding-status MUST + OPTION_F_BINDING_STATUS containing the binding-status MUST
appear; appear.
+ OPTION_F_START_TIME_OF_STATE containing the start-time-of- + OPTION_F_START_TIME_OF_STATE containing the
state MUST appear; start-time-of-state MUST appear.
+ OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the + OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the
state-expiration-time*; state-expiration-time*.
+ OPTION_F_PARTNER_LIFETIME (absolute) containing partner- + OPTION_F_PARTNER_LIFETIME (absolute) containing the
lifetime*; partner-lifetime*.
+ OPTION_F_EXPIRATION_TIME (absolute) containing the + OPTION_F_EXPIRATION_TIME (absolute) containing the
expiration-time*; expiration-time*.
Items marked with a single asterisk (*) MUST appear only if the value Items marked with a single asterisk (*) MUST appear only if the value
in the OPTION_F_BINDING_STATUS is associated with a timeout, in the OPTION_F_BINDING_STATUS is associated with a timeout;
otherwise it MUST NOT appear. See Section 7.2 for details. otherwise, it MUST NOT appear. See Section 7.2 for details.
The OPTION_CLT_TIME MUST, if it appears, be the time that the server The OPTION_CLT_TIME MUST, if it appears, be the time that the server
last interacted with the DHCP client. It MUST NOT be, for instance, last interacted with the DHCP client. It MUST NOT be, for instance,
the time that the lease expired if there has been no interaction with the time that the lease expired if there has been no interaction with
the DHCP client in question. the DHCP client in question.
A server SHOULD be prepared to clean up DNS information once the A server SHOULD be prepared to clean up DNS information once the
lease expires or is released. See Section 9 for a detailed lease expires or is released. See Section 9 for a detailed
discussion about DNS update. Another reason the partner may be discussion about DNS update. Another reason the partner may be
interested in keeping additional data is to enable better support for interested in keeping additional data is to enable better support for
Leasequery [RFC5007], Bulk Leasequery [RFC5460] or Active Leasequery Leasequery [RFC5007], Bulk Leasequery [RFC5460], or Active Leasequery
[RFC7653], some of which feature queries based on Relay-ID, by link [RFC7653], some of which feature queries based on Relay-ID, link
address and by Remote-ID. address, or Remote-ID.
7.5. Receiving Binding Updates 7.5. Receiving Binding Updates
7.5.1. Monitoring Time Skew 7.5.1. Monitoring Time Skew
The sent-time from the Failover message is compared with the current The sent-time from the failover message is compared with the current
time of the receiving server as recorded when it received the time of the receiving server as recorded when it received the
message. The difference is noted, and if it is greater than 5 message. The difference is noted, and if it is greater than
seconds the receiving server SHOULD drop the connection. A message 5 seconds the receiving server SHOULD drop the connection. A message
SHOULD be logged to signal the reason for the connection being SHOULD be logged to signal the reason for the connection being
dropped. dropped.
Any time can be before, after, or essentially the same as another Any time can be before, after, or essentially the same as another
time. Any time which ends up being +/- 5 seconds of another time time. Any time that ends up being +/- 5 seconds of another time
SHOULD be considered to be representing the same time when performing SHOULD be considered to be representing the same time when performing
a comparison between two times. a comparison between two times.
7.5.2. Acknowledging Reception 7.5.2. Acknowledging Reception
Upon acceptance of a binding update, the server MUST notify its Upon acceptance of a binding update, the server MUST notify its
partner that it has processed the binding update (and updated its partner that it has processed the binding update (and updated its
lease state database if necessary) by sending a BNDREPLY. A server lease state database if necessary) by sending a BNDREPLY message. A
MUST NOT send the BNDREPLY before its binding database is updated. server MUST NOT send the BNDREPLY message before its binding database
is updated.
7.5.3. Processing Binding Updates 7.5.3. Processing Binding Updates
When a BNDUPD is received it MUST contain either a single When a BNDUPD message is received, it MUST contain either a single
OPTION_CLIENT_DATA option or a single OPTION_IAPREFIX option. OPTION_CLIENT_DATA option or a single OPTION_IAPREFIX option.
When analyzing an BNDUPD message option from a partner server, if When analyzing a BNDUPD message from a partner server, if there is
there is insufficient information in the BNDUPD message to process insufficient information in the BNDUPD message to process it, then it
it, then it is rejected with an OPTION_STATUS_CODE of is rejected with an OPTION_STATUS_CODE of
"MissingBindingInformation". "MissingBindingInformation".
The server receiving a BNDUPD update from its partner must evaluate The server receiving a BNDUPD message from its partner must evaluate
the received information in each OPTION_CLIENT_DATA or IAPREFIX the received information in each OPTION_CLIENT_DATA or IAPREFIX
option to see if it is consistent with the server's already known option to see if it is consistent with the server's already-known
state, and if it is not, decide to accept or reject the information. state and, if it is not, decide to accept or reject the information.
Section 7.5.4 provides the details how the server makes this Section 7.5.4 provides details regarding how the server makes this
determination. determination.
A server receiving a BNDUPD message MUST respond to the sender of A server receiving a BNDUPD message MUST respond to the sender of
that message with a BNDREPLY message which contains the same that message with a BNDREPLY message that contains the same
transaction-id as the BNDUPD message. This BNDREPLY message MUST transaction-id as the BNDUPD message. This BNDREPLY message MUST
contain either a single OPTION_CLIENT_DATA option or a single contain either a single OPTION_CLIENT_DATA option or a single
OPTION_IAPREFIX option, corresponding to whatever was received in the OPTION_IAPREFIX option, corresponding to whatever was received in the
BNDUPD message. BNDUPD message.
An OPTION_CLIENT_DATA option or an OPTION_IAPREFIX option in the An OPTION_CLIENT_DATA option or an OPTION_IAPREFIX option in the
BNDREPLY which is accepted SHOULD NOT contain an OPTION_STATUS_CODE BNDREPLY message that is accepted SHOULD NOT contain an
unless a status message needs to be sent to the failover partner, in OPTION_STATUS_CODE unless a status message needs to be sent to the
which case it SHOULD include an OPTION_STATUS_CODE option with a failover partner, in which case it SHOULD include an
status code indicating success and whatever message is needed. OPTION_STATUS_CODE option with a status-code indicating success and
whatever message is needed.
To indicate rejection of the information in an OPTION_CLIENT_DATA To indicate rejection of the information in an OPTION_CLIENT_DATA
option, or an OPTION_IAPREFIX option, an OPTION_STATUS_CODE SHOULD be option or an OPTION_IAPREFIX option, an OPTION_STATUS_CODE SHOULD be
included with a status code indicating an error in the included with a status-code indicating an error in the
OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDREPLY OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDREPLY
message. message.
7.5.4. Accept or Reject? 7.5.4. Accept or Reject?
The first task in processing the information in an OPTION_CLIENT_DATA The first task in processing the information in an OPTION_CLIENT_DATA
option or OPTION_IAPREFIX option is extract the client information option or OPTION_IAPREFIX option is to extract the client information
(if any) and lease information out of the option, and to access the (if any) and lease information out of the option and to access the
address lease or prefix lease information in the server's binding address lease or prefix lease information in the server's binding
database. database.
If an OPTION_VSS option is specified in the OPTION_CLIENT_DATA option If an OPTION_VSS option is specified in the OPTION_CLIENT_DATA option
or OPTION_IAPREFIX option, if the VPN specified in the OPTION_VSS or OPTION_IAPREFIX option and the VPN specified in the OPTION_VSS
option does not appear in the configuration of the receiving server, option does not appear in the configuration of the receiving server,
reject the entire OPTION_CLIENT_DATA option or OPTION_IAPREFIX option then reject the entire OPTION_CLIENT_DATA option or OPTION_IAPREFIX
with the reject-reason "ConfigurationConflict". option by including an OPTION_STATUS_CODE option with a status-code
of "ConfigurationConflict".
If the lease specified in the OPTION_CLIENT_DATA option or If the lease specified in the OPTION_CLIENT_DATA option or
OPTION_IAPREFIX option is not a lease associated with the failover OPTION_IAPREFIX option is not a lease associated with the failover
endpoint which received the OPTION_CLIENT_DATA option, then reject it endpoint that received the OPTION_CLIENT_DATA option, then reject it
with reject-reason "ConfigurationConflict". by including an OPTION_STATUS_CODE option with a status-code of
"ConfigurationConflict".
In general, acceptance or rejection is based around the comparison of In general, acceptance or rejection is based on the comparison of two
two different time values, one from the OPTION_CLIENT_DATA option or different time values -- one from the OPTION_CLIENT_DATA option or
OPTION_IAPREFIX option in the BNDUPD message, and one from the OPTION_IAPREFIX option in the BNDUPD message, and one from the
receiving server's binding database associated with the address or receiving server's binding database associated with the address or
prefix lease found in the BNDUPD message. The time for the BNDUPD prefix lease found in the BNDUPD message. The time for the BNDUPD
message where the OPTION_F_BINDING_STATUS is ACTIVE, EXPIRED, or message where the OPTION_F_BINDING_STATUS is ACTIVE, EXPIRED, or
RELEASED is the OPTION_CLT_TIME if one appears, and the RELEASED is the OPTION_CLT_TIME if one appears, or the
OPTION_F_START_TIME_OF_STATE if one does not. For other binding- OPTION_F_START_TIME_OF_STATE if one does not. For other
status values, the time for the BNDUPD message is the later of the binding-status values, the time for the BNDUPD message is the
OPTION_CLT_TIME if one appears, and the OPTION_F_START_TIME_OF_STATE. later of (1) the OPTION_CLT_TIME if one appears or (2) the
The time for the lease in the server's binding database is the OPTION_F_START_TIME_OF_STATE. The time for the lease in the server's
client-last-transaction-time, if one appears, and the start-time-of- binding database is the client-last-transaction-time if one appears,
state if one does not. or the start-time-of-state if one does not.
The basic approach is to compare these times, and if the one from the The basic approach is to compare these times, and if the one from the
BNDUPD message is clearly later, then accept the information in the BNDUPD message is clearly later, then accept the information in the
OPTION_CLIENT_DATA option or OPTION_IAPREFIX option. If the one from OPTION_CLIENT_DATA option or OPTION_IAPREFIX option. If the one from
the server's binding database is clearly later, then reject the the server's binding database is clearly later, then reject the
information in the BNDUPD message. The challenge comes when they are information in the BNDUPD message. The challenge comes when they are
essentially the same (i.e., +/- 5 seconds). In this case they are essentially the same (i.e., +/- 5 seconds). In this case, they are
considered identical, despite the minor differences. The table below considered identical, despite the minor differences. Figure 4 shows
(Figure 4) contains the rules for dealing with all of these a table containing the rules for dealing with all of these
situations. situations.
binding-status in received OPTION_CLIENT_DATA binding-status in received OPTION_CLIENT_DATA
or OPTION_IAPREFIX or OPTION_IAPREFIX
binding-status in binding-status in
receiving server's FREE RESET receiving server's FREE RESET
lease state DB ACTIVE EXPIRED RELEASED FREE-BACKUP ABANDONED lease state DB ACTIVE EXPIRED RELEASED FREE-BACKUP ABANDONED
---------------------------------------------------------------------
ACTIVE accept(3) time(1) accept time(1) accept ACTIVE accept(3) time(1) accept time(1) accept
EXPIRED accept accept accept accept accept EXPIRED accept accept accept accept accept
RELEASED accept accept accept accept accept RELEASED accept accept accept accept accept
FREE/FREE-BACKUP accept accept accept accept accept FREE/FREE-BACKUP accept accept accept accept accept
RESET time(2) accept accept accept accept RESET time(2) accept accept accept accept
ABANDONED accept accept accept accept accept ABANDONED accept accept accept accept accept
Figure 4: Conflict Resolution Figure 4: Conflict Resolution
accept: If the time value in the OPTION_CLIENT_DATA option or accept: If the time value in the OPTION_CLIENT_DATA option or
OPTION_IAPREFIX option is later than the time value in the server's OPTION_IAPREFIX option is later than the time value in the
binding database, accept it, else reject it. server's binding database, accept it, else reject it.
time(1): If the current time is later than the receiving server's time(1): If the current time is later than the receiving server's
state-expiration-time, accept it, else reject it. state-expiration-time, accept it, else reject it.
time(2): If the OPTION_CLT_TIME value (if it appears) in the time(2): If the OPTION_CLT_TIME value (if it appears) in the
OPTION_CLIENT_DATA is later than the start-time-of-state in the OPTION_CLIENT_DATA is later than the start-time-of-state in the
receiving server's binding, accept it, else reject it. receiving server's binding, accept it, else reject it.
accept,time(1),time(2): If rejecting, use reject reason accept,time(1),time(2): If rejecting, use a status-code of
"OutdatedBindingInformation". "OutdatedBindingInformation".
accept(3): If the client in an OPTION_CLIENT_DATA option and in a accept(3): If the clients in an OPTION_CLIENT_DATA option and in a
receiving server's binding differ, then if time(2) or the receiving receiving server's binding differ, then if time(2) or the
server is a secondary accept it, else reject it with a reject reason receiving server is a secondary accept it, else reject it with a
of "AddressInUse". If the clients match, accept the update. status-code of "AddressInUse". If the clients match, accept the
update.
The lease update may be accepted or rejected. If a lease is rejected The lease update may be accepted or rejected. If a lease is rejected
with "OutdatedBindingInformation", then the flag in the lease that with "OutdatedBindingInformation", then the flag in the lease that
indicates the partner should be updated about the information in this indicates that the partner should be updated with the information in
lease SHOULD be set, otherwise it SHOULD NOT be changed. If this this lease SHOULD be set; otherwise, it SHOULD NOT be changed. If
flag was previously not set, then an update MAY be transmitted this flag was previously not set, then an update MAY be transmitted
immediately to the partner (though the BNDREPLY to this BNDUPD SHOULD immediately to the partner (though the BNDREPLY to this BNDUPD
be sent first). If this flag was previously set an update SHOULD NOT message SHOULD be sent first). If this flag was previously set, an
be transmitted immediately to the partner. In this case, an update update SHOULD NOT be transmitted immediately to the partner. In this
will be sent during the next periodic scan, but not immediately, thus case, an update will be sent during the next periodic scan, but not
preventing a possible update storm should the servers be unable to immediately, thus preventing a possible update storm should the
agree. Ultimately, the server with the most recent binding servers be unable to agree. Ultimately, the server with the most
information should have its update accepted by its partner. recent binding information should have its update accepted by its
partner.
7.5.5. Accepting Updates 7.5.5. Accepting Updates
When the information in an OPTION_CLIENT_DATA option or When the information in an OPTION_CLIENT_DATA option or
OPTION_IAPREFIX option has been accepted, some of that information is OPTION_IAPREFIX option has been accepted, some of that information is
stored in the receiving server's binding database, and corresponding stored in the receiving server's binding database, and a
a OPTION_CLIENT_DATA option or OPTION_IAPREFIX option is entered into corresponding OPTION_CLIENT_DATA option or OPTION_IAPREFIX option is
a BNDREPLY. The information to enter into the OPTION_CLIENT_DATA entered into a BNDREPLY message. The information to enter into the
option or OPTION_IAPREFIX option in the BNDREPLY is described in OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDREPLY
Section 7.6. message is described in Section 7.6.
The information contained in an accepted OPTION_CLIENT_DATA option is The information contained in an accepted OPTION_CLIENT_DATA option is
stored in the receiving server's binding database as follows: stored in the receiving server's binding database as follows:
1. The OPTION_CLIENTID is used to find the client. 1. The OPTION_CLIENTID is used to find the client.
2. The other data contained in the top level of the 2. The other data contained in the top level of the
OPTION_CLIENT_DATA option is stored with the client as OPTION_CLIENT_DATA option is stored with the client as
appropriate. appropriate.
3. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD 3. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
option in the OPTION_CLIENT_DATA option and for each of the options in the OPTION_CLIENT_DATA option and for each of the
OPTION_IAADDR or OPTION_IAPREFIX options in the IA_* options: OPTION_IAADDR or OPTION_IAPREFIX options in the IA_* options:
1. OPTION_F_BINDING_STATUS is stored as the binding-status a. OPTION_F_BINDING_STATUS is stored as the binding-status.
2. OPTION_F_PARTNER_LIFETIME is stored in the expiration-time b. OPTION_F_PARTNER_LIFETIME is stored in the expiration-time.
3. OPTION_F_STATE_EXPIRATION_TIME is stored in the state- c. OPTION_F_STATE_EXPIRATION_TIME is stored in the
expiration-time state-expiration-time.
4. OPTION_F_CLT_TIME (which MUST NOT be converted with the d. OPTION_CLT_TIME [RFC5007] is stored in the
corrected-base-time, but MUST be converted with the raw value partner-raw-clt-time.
from the OPTION_LQ_BASE_TIME) is stored in the partner-raw-
clt-time
5. OPTION_F_PARTNER_RAW_CLT_TIME (which MUST NOT be corrected e. OPTION_F_PARTNER_RAW_CLT_TIME replaces the
with the time-correction) replaces the client-last- client-last-transaction-time if it is later than the current
transaction-time if it is later than the current client-last- client-last-transaction-time.
transaction-time.
6. OPTION_F_EXPIRATION_TIME replaces the partner-lifetime if it f. OPTION_F_EXPIRATION_TIME replaces the partner-lifetime if it
is later than the current partner-lifetime. is later than the current partner-lifetime.
The information contained in an accepted top level OPTION_IAPREFIX The information contained in an accepted single OPTION_IAPREFIX
option is stored in the receiving server's binding database as option that is not contained in an OPTION_CLIENT_DATA option is
follows: stored in the receiving server's binding database as follows:
1. The IPv6 Prefix is used to find the prefix. 1. The IPv6 prefix is used to find the prefix.
2. Inside of the IAprefix-options section: 2. Inside of the IAprefix-options section:
1. OPTION_F_BINDING_STATUS is stored as the binding-status a. OPTION_F_BINDING_STATUS is stored as the binding-status.
2. OPTION_F_PARTNER_LIFETIME (if any) is stored in the b. OPTION_F_PARTNER_LIFETIME (if any) is stored in the
expiration-time expiration-time.
3. OPTION_F_STATE_EXPIRATION_TIME (if any) is stored in the c. OPTION_F_STATE_EXPIRATION_TIME (if any) is stored in the
state-expiration-time state-expiration-time.
4. OPTION_F_EXPIRATION_TIME (if any) replaces the partner- d. OPTION_F_EXPIRATION_TIME (if any) replaces the
lifetime if it is later than the current partner-lifetime. partner-lifetime if it is later than the current
partner-lifetime.
7.6. Sending Binding Replies 7.6. Sending Binding Replies
A server MUST respond to every BNDUPD message with a BNDREPLY A server MUST respond to every BNDUPD message with a BNDREPLY
message. The BNDREPLY message MUST contain an OPTION_CLIENT_DATA message. The BNDREPLY message MUST contain an OPTION_CLIENT_DATA
option if the BNDUPD message contained an OPTION_CLIENT_DATA option, option if the BNDUPD message contained an OPTION_CLIENT_DATA option,
or it MUST contain an OPTION_IAPREFIX option if the BNDUPD message or it MUST contain an OPTION_IAPREFIX option if the BNDUPD message
contained an OPTION_IAPREFIX option. The BNDREPLY message MUST have contained an OPTION_IAPREFIX option. The BNDREPLY message MUST have
the same transaction-id as the BNDUPD message to which it is a the same transaction-id as the BNDUPD message to which it is a
response. response.
Acceptance or rejection of all or a particular part of the BNDUPD Acceptance or rejection of all of or a particular part of the BNDUPD
message is signaled with a OPTION_STATUS_CODE option. An message is signaled with an OPTION_STATUS_CODE option. An
OPTION_STATUS_CODE option containing a status-code representing an OPTION_STATUS_CODE option containing a status-code representing an
error is significant, while an OPTION_STATUS_CODE option whose error is significant, while an OPTION_STATUS_CODE option whose
status-code contains success is considered informational but does not status-code contains success is considered informational but does not
affect the processing of the BNDREPLY message when it is received by affect the processing of the BNDREPLY message when it is received by
the server that sent the BNDUPD message. the server that sent the BNDUPD message.
Rejection of all or part of the information in a BNDUPD message is Rejection of all of or part of the information in a BNDUPD message is
signaled in a BNDREPLY message by use of the OPTION_STATUS_CODE signaled in a BNDREPLY message by using the OPTION_STATUS_CODE
message with an error in the status-code field. This rejection can message with an error in the status-code field. This rejection can
take place at either of two levels -- the top level of the option take place at either of two levels -- the top level of the option
hierarchy, or the bottom level of the option hierarchy: hierarchy or the bottom level of the option hierarchy:
Entire BNDUPD: The OPTION_STATUS_CODE containing an error is 1. Entire BNDUPD: The OPTION_STATUS_CODE containing an error is
present in the outermost option of the BNDREPLY -- either the present in the outermost option of the BNDREPLY message -- either
single OPTION_CLIENT_DATA option or the single OPTION_IAPREFIX the single OPTION_CLIENT_DATA option or the single
option. An example of this sort of error might be that a VSS OPTION_IAPREFIX option. An example of this sort of error might
option was present and specified a VPN that might not exist in the be that an OPTION_VSS option was present and specified a VPN that
receiving server. might not exist in the receiving server.
Single address or prefix: The OPTION_STATUS_CODE containing an 2. Single address or prefix: The OPTION_STATUS_CODE containing an
error is present in a single IAADDR or IAPREFIX option which is error is present in a single IAADDR or IAPREFIX option that is
itself contained in an OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD itself contained in an OPTION_IA_NA, OPTION_IA_TA, or
option. An example of this sort of error might be that a OPTION_IA_PD option. An example of this sort of error might be
particular IPv6 address was specified in an IAADDR option that that a particular IPv6 address was specified in an IAADDR option
doesn't appear in the receiving server's configuration. that doesn't appear in the receiving server's configuration.
Rejection present at either of these levels indicates rejection of Rejection occurring at either of these levels indicates rejection of
all of the information contained in the option (including any other all of the information contained in the option (including any other
options contained in that option) where the OPTION_STATUS_CODE option options contained in that option) where the OPTION_STATUS_CODE option
containing an error appears. The converse is not true -- an containing an error appears. The converse is not true -- an
OPTION_STATUS_CODE option containing success does not signify that OPTION_STATUS_CODE option containing success does not signify that
all of the contained information has been accepted. all of the contained information has been accepted.
If the BNDREPLY message contains an OPTION_CLIENT_DATA option, then If the BNDREPLY message contains an OPTION_CLIENT_DATA option, then
the OPTION_CLIENT_DATA option MUST contain at least the data shown the OPTION_CLIENT_DATA option MUST contain at least the data shown
below in its client-options section: below in its client-options section:
o OPTION_CLIENTID containing the DUID of the client most recently o OPTION_CLIENTID containing the DUID of the client most recently
associated with this IPv6 address*; associated with this IPv6 address.
o OPTION_VSS from the BNDUPD, if any. o OPTION_VSS from the BNDUPD message, if any.
o OPTION_IA_NA or OPTION_IA_TA for an IPv6 Address or OPTION_IA_PD o OPTION_IA_NA or OPTION_IA_TA for an IPv6 address or OPTION_IA_PD
for an IPv6 Prefix. More than one of either of these options MAY for an IPv6 prefix. More than one of either of these options MAY
appear if there are more than one associated with this client; appear if there are more than one of them associated with this
client.
* Inside of the IA_NA-options, IA_TA-options, or IA_PD-option * Inside of the IA_NA-options, IA_TA-options, or IA_PD-options
sections: sections:
+ OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for + OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for
a IPv6 prefix; an IPv6 prefix.
- IPv6 Address or IPv6 Prefix (with length); - IPv6 address or IPv6 prefix (with length).
- Inside of the IAaddr-options or IAprefix-options: - Inside of the IAaddr-options or IAprefix-options:
o OPTION_STATUS_CODE containing an error code, or o OPTION_STATUS_CODE containing an error code, or
containing a success code if a message is required. containing a success code if a message is required.
An OPTION_STATUS_CODE option SHOULD NOT appear with a An OPTION_STATUS_CODE option SHOULD NOT appear with a
success code unless a message associated with the success code unless a message associated with the
success code needs to be included. The lack of an success code needs to be included. The lack of an
OPTION_STATUS_CODE option is an indication of success. OPTION_STATUS_CODE option is an indication of success.
o OPTION_F_BINDING_STATUS containing the binding-status o OPTION_F_BINDING_STATUS containing the binding-status
received in the BNDUPD; received in the BNDUPD message.
o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing
the state-expiration-time received in the BNDUPD; the state-expiration-time received in the BNDUPD
message.
o OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a o OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a
duplicate of the OPTION_F_PARTNER_LIFETIME received in duplicate of the OPTION_F_PARTNER_LIFETIME received in
the BNDUPD; the BNDUPD message.
If the BNDREPLY message contains a top level OPTION_IAPREFIX option, If the BNDREPLY message contains a single OPTION_IAPREFIX option not
then the OPTION_IAPREFIX option MUST contain at least the data shown contained in an OPTION_CLIENT_DATA option, then the OPTION_IAPREFIX
below: option MUST contain at least the data shown below:
o IPv6 Prefix (with length); o IPv6 prefix (with length).
o IAprefix-options: o IAprefix-options:
* OPTION_VSS from the BNDUPD, if any. * OPTION_VSS from the BNDUPD message, if any.
* OPTION_STATUS_CODE containing an error code, or containing a * OPTION_STATUS_CODE containing an error code, or containing a
success code if a message is required. If the information in success code if a message is required. If the information in
the corresponding OPTION_IAPREFIX in the BNDUPD was accepted, the corresponding OPTION_IAPREFIX in the BNDUPD message was
and no status message was required (which is the usual case), accepted and no status message was required (which is the usual
no OPTION_STATUS_CODE option appears. case), no OPTION_STATUS_CODE option appears.
* OPTION_F_BINDING_STATUS containing the binding-status received * OPTION_F_BINDING_STATUS containing the binding-status received
in the BNDREPLY; in the BNDREPLY message.
* OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state- * OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the
expiration-time received in the BNDREPLY; state-expiration-time received in the BNDREPLY message.
* OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a * OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a
duplicate of the OPTION_F_PARTNER_LIFETIME received in the duplicate of the OPTION_F_PARTNER_LIFETIME received in the
BNDREPLY; BNDREPLY message.
7.7. Receiving Binding Acks 7.7. Receiving Binding Acks
When a BNDREPLY is received the overall OPTION_CLIENT_DATA option or When a BNDREPLY message is received, the overall OPTION_CLIENT_DATA
the overall OPTION_IAPREFIX option may contain an OPTION_STATUS_CODE option or the overall OPTION_IAPREFIX option may contain an
containing an error, representing a rejection of the entire BNDUPD. OPTION_STATUS_CODE containing an error that represents a rejection of
An enclosed OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD option may the entire BNDUPD message. An enclosed OPTION_IA_NA, OPTION_IA_TA,
also contain an OPTION_STATUS_CODE containing an error which or OPTION_IA_PD option may also contain an OPTION_STATUS_CODE
indicates that everything in containing option has been rejected. Or containing an error that indicates that everything in the containing
an individual IAADDR or IAPREFIX option may contain an option has been rejected. Alternatively, an individual IAADDR or
OPTION_STATUS_CODE option containing an error, indicating that the IAPREFIX option may contain an OPTION_STATUS_CODE option containing
IAADDR or IAPREFIX option has been rejected. An OPTION_STATUS_CODE an error that indicates that the IAADDR or IAPREFIX option has been
containing a success code has no bearing on the acceptance status of rejected. An OPTION_STATUS_CODE containing a success code has no
the BNDREPLY at any level. bearing on the acceptance status of the BNDREPLY message at any
level.
Receipt of a rejection (or a part of a BNDREPLY that has been Receipt of a rejection (or a part of a BNDREPLY message that has been
rejected) requires no processing other than remembering that it has rejected) requires no processing, other than remembering that it has
been encountered. been encountered.
The information contained in the BNDREPLY in an OPTION_CLIENT_DATA The information contained in the BNDREPLY message in an
that represents an acceptance is stored with the appropriate client OPTION_CLIENT_DATA that represents an acceptance is stored with the
and lease, as follows: appropriate client and lease, as follows:
1. The OPTION_CLIENTID is used to find the client. 1. The OPTION_CLIENTID is used to find the client.
2. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD 2. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
option in the OPTION_CLIENT_DATA option and for each of the options in the OPTION_CLIENT_DATA option and for each of the
OPTION_IAADDR or OPTION_IAPREFIX options they contain: OPTION_IAADDR or OPTION_IAPREFIX options they contain:
1. OPTION_F_PARTNER_LIFETIME_SENT is stored in the acked- a. OPTION_F_PARTNER_LIFETIME_SENT is stored in the
partner-lifetime acked-partner-lifetime.
2. The time partner-lifetime is set to 0, to indicate that b. The partner-lifetime is set to 0 to indicate that no more
nothing additional needs to be sent to the partner. information needs to be sent to the partner.
Alternatively, the BNDREPLY may contain a top level OPTION_IAPREFIX Alternatively, the BNDREPLY message may contain a single
option, representing information concerning a single prefix lease. OPTION_IAPREFIX option not contained in an OPTION_CLIENT_DATA option,
If the IAprefix-options section of the OPTION_IAPREFIX option representing information concerning a single prefix lease. If the
contains an OPTION_STATUS_CODE representing an error, then it is IAprefix-options section of the OPTION_IAPREFIX option contains an
considered a rejection of the corresponding BNDUPD message. If the OPTION_STATUS_CODE representing an error, then it is considered a
rejection of the corresponding BNDUPD message. If the
OPTION_IAPREFIX option does not contain an OPTION_STATUS_CODE option OPTION_IAPREFIX option does not contain an OPTION_STATUS_CODE option
or if the OPTION_STATUS_CODE option contains a success status, then or if the OPTION_STATUS_CODE option contains a success status, then
the three items in the following list are stored in the lease state the three items in the following list are stored in the lease state
database, in the section associated with the prefix lease represented database, in the section associated with the prefix lease represented
by the OPTION_IAPREFIX option. by the OPTION_IAPREFIX option.
1. OPTION_F_BINDING_STATUS containing the binding-status received in 1. OPTION_F_BINDING_STATUS containing the binding-status received in
the BNDREPLY; the BNDREPLY message.
2. OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state- 2. OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the
expiration-time received in the BNDREPLY; state-expiration-time received in the BNDREPLY message.
3. OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a duplicate 3. OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a duplicate
of the OPTION_F_PARTNER_LIFETIME received in the BNDREPLY; of the OPTION_F_PARTNER_LIFETIME received in the BNDREPLY
message.
7.8. BNDUPD/BNDREPLY Data Flow 7.8. BNDUPD/BNDREPLY Data Flow
The following diagram shows the relationship of the times described Figure 5 shows the relationship of the times described in Section 7.3
in Section 7.3 with the options used to transmit them. It also to the options used to transmit them. It also relates the times on
relates the times on one failover partner to the other failover one failover partner to the other failover partner.
partner.
----------------------- BNDUPD ------------------------------ ----------------------- BNDUPD ---------------------------------
Source on OPTION_F in Storage on Source on OPTION_F in Storage on
Sending Server -> BNDUPD message -> Receiving Server Sending Server -> BNDUPD message -> Receiving Server
[ always update ] [always update]
partner-lifetime PARTNER_LIFETIME expiration-time partner-lifetime PARTNER_LIFETIME expiration-time
client-last-transaction-time CLT_TIME (uncorrected) client-last-transaction-time CLT_TIME partner-raw-clt-time
partner-raw-clt-time
start-time-of-state START_TIME_OF_STATE start-time-of-state start-time-of-state START_TIME_OF_STATE start-time-of-state
state-expiration-time STATE_EXPIRATION_TIME state-expiration-time state-expiration-time STATE_EXPIRATION_TIME state-expiration-time
[update only if received > current] [update only if received > current]
expiration-time EXPIRATION_TIME partner-lifetime expiration-time EXPIRATION_TIME partner-lifetime
partner-raw-clt-time PARTNER_RAW_CLT_TIME partner-raw-clt-time PARTNER_RAW_CLT_TIME
client-last-transaction-time client-last-transaction-time
----------------------- BNDREPLY ------------------------------ ----------------------- BNDREPLY -------------------------------
Storage on OPTION_F in Storage on Storage on OPTION_F in Storage on
Receiving Server <- BNDUPD message <- Sending Server Receiving Server <- BNDUPD message <- Sending Server
[ always update ] [always update]
acked-partner-lifetime PARTNER_LIFETIME_SENT duplicate of received acked-partner-lifetime PARTNER_LIFETIME_SENT duplicate of received
PARTNER_LIFETIME PARTNER_LIFETIME
(nothing to update) STATE_EXPIRATION_TIME state-expiration-time (nothing to update) STATE_EXPIRATION_TIME state-expiration-time
------------------------------------------------------------- ----------------------------------------------------------------
Figure 5: BNDUPD and BNDREPLY Time Handling Figure 5: BNDUPD and BNDREPLY Time Handling
8. Endpoint States 8. Endpoint States
8.1. State Machine Operation 8.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 DHCP client as well as dealing with changing external request from a DHCP client as well as dealing with changing external
conditions (e.g., loss of connection to a failover partner). conditions (e.g., loss of connection to a failover partner).
The failover state in which a server is running controls the The failover state in which a server is running controls the
following behaviors: following behaviors:
o Responsiveness -- the server is either responsive to DHCP client o Responsiveness - the server is either responsive to DHCP client
requests, it is renew responsive, or it is unresponsive. requests, renew responsive, or unresponsive.
o Allocation Pool -- which pool of addresses (or prefixes) can be o Allocation Pool - which pool of addresses (or prefixes) can be
used for advertisement on receipt of a SOLICIT or allocation on used for advertisement on receipt of a SOLICIT or allocation on
receipt of a REQUEST, RENEW or REBIND message. receipt of a REQUEST, RENEW, or REBIND message.
o MCLT -- ensure that valid lifetimes are not beyond what the o MCLT - ensure that valid lifetimes are not beyond what the partner
partner has acked plus the MCLT (or not). has acked plus the MCLT (unless the failover state doesn't require
this restriction).
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).
Whenever any of the above state variables change state, the state Whenever any of the above state variables change state, the state
machine is invoked, which may then trigger a change in the current machine is invoked, which may then trigger a change in the current
failover state. Thus, whenever the communications status changes, failover state. Thus, whenever the communications status changes,
the state machine processing is invoked. This may or may not result the state machine processing is invoked. This may or may not result
in a change in the current failover state. 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 state transition diagram below (Figure 6) gives a condensed view
state machine. If there is a difference between the words describing of the state machine. If there are any differences between text
a particular state and the diagram below, the words should be describing a particular state and the information shown in Figure 6,
considered authoritative. the text should be considered authoritative.
In the diagram below, the word (responsive) (r-responsive) or
(unresponsive) appears in the states, and refers to whether the
server in this state is allowed to responsive, renew responsive, or
unresponsive respectively.
In the state transition diagram below, the "+", "-", or "*" in the In Figure 6, the terms "responsive", "r-responsive", and
upper right corner of each state is a notation about whether "unresponsive" appear in the states and refer to whether the server
communication is ongoing with the other server, with "+" meaning that in the indicated state is allowed to be responsive, renew responsive,
communications are ok, "-" meaning communications are interrupted, or unresponsive, respectively. The "+", "-", or "*" in the upper
and "*" meaning that communications may be ok or interrupted. right corner of each state is a notation about whether communication
is ongoing with the other server, with "+" meaning that
communications are "OK", "-" meaning that communications are
interrupted, and "*" meaning that communications may be either "OK"
or interrupted.
+---------------+ V +--------------+ +---------------+ V +--------------+
| RECOVER * | | | STARTUP - | | RECOVER * | | | STARTUP - |
|(unresponsive) | +->+(unresponsive)| |(unresponsive) | +->+(unresponsive)|
+------+--------+ +--------------+ +------+--------+ +--------------+
+-Comm. OK +-----------------+ +-Comm. OK +-----------------+
| Other State: | PARTNER DOWN - +<---------------------+ | Other State: | PARTNER-DOWN - +<---------------------+
| RESOLUTION-INTER. | (responsive) | ^ | RESOLUTION-INTER. | (responsive) | ^
All POTENTIAL- +----+------------+ | All POTENTIAL- +----+------------+ |
Others CONFLICT------------ | --------+ | Others CONFLICT------------ | --------+ |
| CONFLICT-DONE Comm. OK | +--------------+ | | CONFLICT-DONE Comm. OK | +--------------+ |
UPDREQ or Other State: | +--+ RESOLUTION - | | UPDREQ or Other State: | +--+ RESOLUTION - | |
UPDREQALL | | | | | INTERRUPTED | | UPDREQALL | | | | | INTERRUPTED | |
Rcv UPDDONE RECOVER All | | | (responsive) | | Rcv UPDDONE RECOVER All | | | (responsive) | |
| +---------------+ | Others | | +------+-----+-+ | | +---------------+ | Others | | +------+-----+-+ |
+->+RECOVER-WAIT * | RECOVER | | | ^ | | +->+RECOVER-WAIT * | RECOVER- | | | ^ | |
|(unresponsive) | WAIT or | | Comm. | Ext. | |(unresponsive) | WAIT or | | Comm. | Ext. |
+-----------+---+ DONE | | OK Comm. Cmd---->+ +-----------+---+ DONE | | OK Comm. Cmd---->+
Comm.---+ Wait MCLT | V V V Failed | Comm.---+ Wait MCLT | V V V Failed |
Changed | V +---+ +---+-----+--+-+ | | Changed | V +---+ +---+-----+--+-+ | |
| +---+----------++ | | POTENTIAL + +-------+ | | +---+----------++ | | POTENTIAL + +-------+ |
| |RECOVER-DONE * | Wait | CONFLICT +------+ | | |RECOVER-DONE * | Wait | CONFLICT +------+ |
+->+(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 + +<--------------+ |
| +--+----------+-->+ pri: responsive +-------External Command-->+ | +--+----------+-->+ pri: responsive +-------External Command-->+
| ^ ^ |sec: r-responsive| | | ^ ^ |sec: r-responsive| | |
| | | +--------+--------+ | | | | +--------+--------+ | |
| | | | | | | | | | | |
| Wait for Comm. OK Comm. Failed | External | Wait for Comm. OK Comm. Failed | External
| Other Other | | Command | Other Other | | Command
| State: State: Start Auto | or | State: State: Start Auto | or
| RECOVER-DONE NORMAL Partner Down Comm. OK Auto | RECOVER-DONE NORMAL Partner Down Comm. OK Auto
| | COMM. INT. Timer Other State: Partner | | COMM.-INT. Timer Other State: Partner
| Comm. OK. | V All Others Down | Comm. OK | V All Others Down
| Other State: | +---------+--------+ | expiration | Other State: | +---------+--------+ | expiration
| RECOVER +--+ COMMUNICATIONS - +----+ | | RECOVER +--+ COMMUNICATIONS - +----+ |
| +-------------+ INTERRUPTED | | | +-------------+ INTERRUPTED | |
RECOVER | (responsive) +------------------------->+ RECOVER | (responsive) +------------------------->+
RECOVER-WAIT--------->+------------------+ RECOVER-WAIT--------->+------------------+
Figure 6: Failover Endpoint State Machine Figure 6: Failover Endpoint State Machine
8.2. State Machine Initialization 8.2. State Machine Initialization
skipping to change at page 67, line 27 skipping to change at page 69, line 27
o Start time of partner's failover state. o Start time of partner's failover state.
o Time most recent message received from partner. o Time most recent message received from partner.
The state machine is initialized by reading these data items from The state machine is initialized by reading these data items from
stable storage and restoring their values from the information saved. stable storage and restoring their values from the information saved.
If there is no information in stable storage concerning these items, If there is no information in stable storage concerning these items,
then they should be initialized as follows: then they should be initialized as follows:
o Current failover state: Primary: PARTNER-DOWN, Secondary: RECOVER o Current failover state: Primary: PARTNER-DOWN, Secondary: RECOVER.
o Previous failover state: None. o Previous failover state: None.
o Start time of current failover state: Current time. o Start time of current failover state: Current time.
o Partner's failover state: None until reception of STATE message. o Partner's failover state: None until reception of STATE message.
o Start time of partner's failover state: None until reception of o Start time of partner's failover state: None until reception of
STATE message. STATE message.
o Time most recent message received from partner: None until message o Time most recent message received from partner: None until message
received. received.
8.3. STARTUP State 8.3. STARTUP State
The STARTUP state affords an opportunity for a server to probe its The STARTUP state affords an opportunity for a server to probe its
partner server, before starting to service DHCP clients. When in the partner server before starting to service DHCP clients. When in the
STARTUP state, a server attempts to learn its partner's state and STARTUP state, a server attempts to learn its partner's state and
determine (using that information if it is available) what state it determine (using that information if it is available) what state it
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 6) because the processing during the state machine diagram (Figure 6) 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.
8.3.1. Operation in STARTUP State 8.3.1. Operation in STARTUP State
The server MUST NOT be responsive to DHCP clients in STARTUP state. The server MUST NOT be responsive to DHCP 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 OPTION_F_SERVER_FLAGS
recorded failover state MUST be placed in the server-state option. option and the previously recorded failover state MUST be placed in
the OPTION_F_SERVER_STATE option, each of which is included in the
STATE message.
8.3.2. Transition Out of STARTUP State 8.3.2. Transition out of STARTUP State
The following algorithm is followed every time the server initializes The algorithm below is followed every time the server initializes
itself, and enters STARTUP state. itself and enters STARTUP state.
The variables PREVIOUS-STATE and CURRENT-STATE are defined for use in The variables PREVIOUS-STATE and CURRENT-STATE are defined for use in
the algorithm description below. PREVIOUS-STATE is simply for the algorithm description below. PREVIOUS-STATE is simply for
storage of a state, while CURRENT-STATE not only stores the current storage of a state, while CURRENT-STATE not only stores the current
state but also changes the current state of the failover endpoint to state but also changes the current state of the failover endpoint to
whatever state is set into the CURRENT-STATE. whatever state is set in CURRENT-STATE.
Step 1:
If there is any record in stable storage of a previous failover state
for this server, set PREVIOUS-STATE to the last recorded value in
stable storage, and go to Step 2.
If there is no record of any previous failover state in stable
storage for this server, then set the PREVIOUS-STATE to RECOVER and
set the TIME-OF-FAILURE to 0. This will allow two servers which
already have lease information to synchronize themselves prior to
operating.
In some cases, an existing server will be commissioned as a failover
server and brought back into operation where its partner is not yet
available. In this case, the newly commissioned failover server will
not operate until its partner comes online -- but it has operational
responsibilities as a DHCP server nonetheless. To properly handle
this situation, a server SHOULD be configurable in such a way as to
move directly into PARTNER-DOWN state after the startup period
expires if it has been unable to contact its partner during the
startup period.
Step 2:
Implementations will differ in the ways that they deal with the state
machine for failover endpoint states. In many cases, state
transitions will occur when communications goes from "OK" to failed,
or from failed to "OK", and some implementations will implement a
portion of their state machine processing based on these changes.
In these cases, during startup, if the PREVIOUS-STATE is one where Step 1: If there is any record of a previous failover state in stable
communications was "OK", then set the PREVIOUS-STATE to the state storage for this server, then set the PREVIOUS-STATE to the
that is the result of the communications failed state transition when last recorded value in stable storage and the TIME-OF-FAILURE
in that state (if such transition exists -- some states don't have a to the time the server failed or a time beyond which the
communication failed state transition, since they allow both server could not have been operating, and go to Step 2.
communications OK and failed).
Step 3: If there is no record of any previous failover state in
stable storage for this server, then set the PREVIOUS-STATE
to RECOVER, and set the TIME-OF-FAILURE to 0. This will
allow two servers that already have lease information to
synchronize themselves prior to operating.
Start the STARTUP state timer. The time that a server remains in the In some cases, an existing server will be commissioned as a
STARTUP state (absent any communications with its partner) is failover server and brought back into operation when its
implementation dependent but SHOULD be short. It SHOULD be long partner is not yet available. In this case, the newly
enough for a TCP connection to be created to a heavily loaded partner commissioned failover server will not operate until its
across a slow network. partner comes online -- but it has operational
responsibilities as a DHCP server nonetheless. To properly
handle this situation, a server SHOULD be configurable in
such a way as to move directly into PARTNER-DOWN state after
the startup period expires if it has been unable to contact
its partner during the startup period.
Step 4: Step 2: Implementations will differ in the ways that they deal with
the state machine for failover endpoint states. In many
cases, state transitions will occur when communications go
from "OK" to failed or from failed to "OK", and some
implementations will implement a portion of their state
machine processing based on these changes.
If the server is a primary server: attempt to create a TCP connection In these cases, during startup, if the PREVIOUS-STATE is one
to the failover partner. If the server is a secondary server, listen where communications were "OK", then set the PREVIOUS-STATE
on the failover port and wait for the primary server to connect. See to the state that is the result of the communication failed
Section 6.1. state transition when in that state (if such a transition
exists -- some states don't have a communication failed state
transition, since they allow both "communications OK" and
"failed").
Step 5: Step 3: Start the STARTUP state timer. The time that a server
remains in the STARTUP state (absent any communications with
its partner) is implementation dependent but SHOULD be short.
It SHOULD be long enough for a TCP connection to a heavily
loaded partner to be created across a slow network.
Wait for "communications OK". Step 4: If the server is a primary server, attempt to create a TCP
connection to the failover partner. If the server is a
secondary server, listen on the failover port and wait for
the primary server to connect. See Section 6.1.
When and if communications become "OK", clear the STARTUP flag, and Step 5: Wait for "communications OK".
set the CURRENT-STATE to the PREVIOUS-STATE.
If the partner is in PARTNER-DOWN state, and if the time at which it When and if communications become "OK", clear the STARTUP
entered PARTNER-DOWN state (as received in the start-time-of-state flag, and set the CURRENT-STATE to the PREVIOUS-STATE.
option in the STATE message) is later than the last recorded time of
operation of this server, then set CURRENT-STATE to RECOVER. If the
time at which it entered PARTNER-DOWN state is earlier than the last
recorded time of operation of this server, then set CURRENT-STATE to
POTENTIAL-CONFLICT.
Then, transition to the CURRENT-STATE and take the "communications If the partner is in PARTNER-DOWN state and if the time at
OK" state transition based on the CURRENT-STATE of this server and which it entered PARTNER-DOWN state (as received in the
the partner. OPTION_F_START_TIME_OF_STATE option in the STATE message) is
later than the last recorded time of operation of this
server, then set CURRENT-STATE to RECOVER. If the time at
which it entered PARTNER-DOWN state is earlier than the last
recorded time of operation of this server, then set
CURRENT-STATE to POTENTIAL-CONFLICT.
Step 6: Then, transition to the CURRENT-STATE and take the
"communications OK" state transition based on the
CURRENT-STATE of this server and the partner.
If the startup time expires prior to communications becoming "OK", Step 6: If the startup time expires prior to communications becoming
the server SHOULD transition to the PREVIOUS-STATE. "OK", the server SHOULD transition to PREVIOUS-STATE.
8.4. PARTNER-DOWN State 8.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 as a result of either
intervention (when an operator determines that the server's partner (1) operator intervention (when an operator determines that the
is, indeed, down), or as a result of an optional auto-partner-down server's partner is, indeed, down) or (2) an optional
capability where PARTNER-DOWN state is entered automatically after a auto-partner-down capability where PARTNER-DOWN state is entered
server has been in COMMUNICATIONS-INTERRUPTED state for a pre- automatically after a server has been in COMMUNICATIONS-INTERRUPTED
determined period of time. state for a predetermined period of time.
8.4.1. Operation in PARTNER-DOWN State 8.4.1. Operation in PARTNER-DOWN State
The server MUST be responsive in PARTNER-DOWN state, regardless if it The server MUST be responsive in PARTNER-DOWN state, regardless of
is primary or secondary. whether it is primary or secondary.
It will allow renewal of all outstanding leases. It will allow renewal of all outstanding leases.
For delegable prefixes it will allocate leases from its own pool, and For delegable prefixes, the server will allocate leases from its own
after a fixed period of time (the MCLT interval) has elapsed from pool, and after a fixed period of time (the MCLT interval) has
entry into PARTNER-DOWN state, it may allocate delegable prefixes elapsed from entry into PARTNER-DOWN state, it may allocate delegable
from the set of all available pools. Server MUST fully deplete its prefixes from the set of all available pools. The server MUST fully
own pool, before starting allocations from its downed partner's pool. deplete its own pool before starting allocations from its downed
partner's pool.
IPv6 addresses available for independent allocation by the other IPv6 addresses available for independent allocation by the other
server (at entry to PARTNER-DOWN state) SHOULD NOT be allocated to a server (upon entering PARTNER-DOWN state) SHOULD NOT be allocated to
client. If one elects to do so anyway, they MUST NOT be allocated to a client. If one elects to do so anyway, they MUST NOT be allocated
a new client until the MCLT beyond the entry into PARTNER-DOWN state to a new client until the MCLT beyond the entry into PARTNER-DOWN
has elapsed. state has elapsed.
A server in PARTNER-DOWN state MUST NOT allocate a lease to a DHCP A server in PARTNER-DOWN state MUST NOT allocate a lease to a DHCP
client different from that to which it was allocated at the entrance client different from the client to which it was allocated at the
to PARTNER-DOWN state until the MCLT beyond the maximum of the time of entry into PARTNER-DOWN state until the MCLT beyond the
following times: client expiration time, most recently transmitted maximum of the following times: client expiration time, most recently
partner-lifetime, most recently received ack of the partner-time from transmitted partner-lifetime, most recently received ack of the
the partner, and most recently acked partner-lifetime to the partner. partner-time from the partner, and most recently acked
If this time would be earlier than the current time plus the MCLT, partner-lifetime to the partner. If this time would be earlier than
then the time the server entered PARTNER-DOWN state plus the MCLT is the current time plus the MCLT, then the time the server entered
used. PARTNER-DOWN state plus the MCLT is used.
The server is not restricted by the MCLT when offering valid The server is not restricted by the MCLT when offering valid
lifetimes while in PARTNER-DOWN state. lifetimes 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
PARTNER-DOWN state, there is a chance of duplicate leases for the PARTNER-DOWN state, there is a chance that duplicate leases for the
same prefix to be assigned. This leads to a POTENTIAL-CONFLICT same prefix could be assigned. This leads to a POTENTIAL-CONFLICT
(unresponsive) state when they re-establish contact. The duplicate (unresponsive) state when the servers reestablish contact. This
lease issue can be postponed to a large extent by the server granting issue of duplicate leases can be prevented as long as the server
new leases first from its own pool. Therefore the server operating grants new leases from its own pool; therefore, the server operating
in PARTNER-DOWN state MUST use its own pool first for new leases in PARTNER-DOWN state MUST use its own pool first for new leases
before assigning any leases from its downed partner pool. before assigning any leases from its downed partner's pool.
8.4.2. Transition Out of PARTNER-DOWN State 8.4.2. Transition out of PARTNER-DOWN State
When a server in PARTNER-DOWN state succeeds in establishing a When a server in PARTNER-DOWN state succeeds in establishing a
connection to its partner, its actions are conditional on the state connection to its partner, its actions are conditional on the state
and flags received in the STATE message from the other server as part and flags received in the STATE message from the other server as part
of 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 OPTION_F_SERVER_FLAGS option of a
STATE message, a server in PARTNER-DOWN state MUST NOT take any state received STATE message, a server in PARTNER-DOWN state MUST NOT take
transitions based on reestablishing communications. If a server is any state transitions based on reestablishing communications. If a
in PARTNER-DOWN state, it ignores all STATE messages from its partner server is in PARTNER-DOWN state, it ignores all STATE messages from
that have the STARTUP bit set in the server-flags option of the STATE its partner that have the STARTUP bit set in the
message. OPTION_F_SERVER_FLAGS option 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 OPTION_F_SERVER_FLAGS option of
message received from its partner, then a server in PARTNER-DOWN a STATE message received from its partner, then a server in
state takes the following actions based on the state of the partner PARTNER-DOWN state takes the following actions, based on the state of
as received in a STATE message (either immediately after establishing the partner as received in a STATE message (either immediately after
communications or at any time later when a new state is received) establishing communications or at any time later when a new state is
received):
o If the partner is in: [ NORMAL, COMMUNICATIONS-INTERRUPTED, o If the partner is in NORMAL, COMMUNICATIONS-INTERRUPTED,
PARTNER-DOWN, POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or PARTNER-DOWN, POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or
CONFLICT-DONE ] state, then transition to POTENTIAL-CONFLICT state CONFLICT-DONE state, then transition to POTENTIAL-CONFLICT state.
o If the partner is in: [ RECOVER, RECOVER-WAIT ] state stay in o If the partner is in RECOVER or RECOVER-WAIT state, then stay in
PARTNER-DOWN state PARTNER-DOWN state.
o If the partner is in: [ RECOVER-DONE ] state transition into o If the partner is in RECOVER-DONE state, then transition to
NORMAL state NORMAL state.
8.5. RECOVER State 8.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 reintegrating 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.
8.5.1. Operation in RECOVER State 8.5.1. Operation in RECOVER State
The server MUST NOT be responsive in RECOVER state. The server MUST NOT be responsive in RECOVER state.
A server in RECOVER state will attempt to reestablish communications A server in RECOVER state will attempt to reestablish communications
with the other server. with the other server.
8.5.2. Transition Out of RECOVER State 8.5.2. Transition out of RECOVER State
If the other server is in POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, If the other server is in POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED,
or CONFLICT-DONE state when communications are reestablished, then or CONFLICT-DONE state when communications are reestablished, then
the server in RECOVER state will move to POTENTIAL-CONFLICT state the server in RECOVER state will move itself to POTENTIAL-CONFLICT
itself. state.
If the other server is in any other state, then the server in RECOVER If the other server is in any other state, then the server in RECOVER
state will request an update of missing binding information by state will request an update of missing binding information by
sending an UPDREQ message. If the server has determined that it has sending an UPDREQ message. If the server has determined that it has
lost its stable storage because it has no record of ever having lost its stable storage because it has no record of ever having
talked to its partner, while its partner does have a record of talked to its partner even though its partner does have a record of
communicating with it, it MUST send an UPDREQALL message, otherwise communicating with it, it MUST send an UPDREQALL message; otherwise,
it MUST send an UPDREQ message. it MUST send an UPDREQ message.
It will wait for an UPDDONE message, and upon receipt of that message It will wait for an UPDDONE message, and upon receipt of that message
it will transition to RECOVER-WAIT state. it will transition to RECOVER-WAIT state.
If communication fails during the reception of the results of the If communication fails during the reception of the results of the
UPDREQ or UPDREQALL message, the server will remain in RECOVER state, UPDREQ or UPDREQALL message, the server will remain in RECOVER state
and will re-issue the UPDREQ or UPDREQALL when communications are re- and will reissue the UPDREQ or UPDREQALL message when communications
established. are reestablished.
If an UPDDONE message isn't received within an implementation If an UPDDONE message isn't received within an implementation-
dependent amount of time, and no BNDUPD messages are being received, dependent amount of time and no BNDUPD messages are being received,
the connection SHOULD be dropped. the connection SHOULD be dropped.
A B A B
Server Server Server Server
| | | |
RECOVER PARTNER-DOWN RECOVER PARTNER-DOWN
| | | |
| >--UPDREQ--------------------> | | >--UPDREQ--------------------> |
| | | |
skipping to change at page 73, line 40 skipping to change at page 75, line 49
RECOVER-DONE | RECOVER-DONE |
| | | |
| >--STATE-(RECOVER-DONE)------> | | >--STATE-(RECOVER-DONE)------> |
| NORMAL | NORMAL
| <-------------(NORMAL)-STATE--< | | <-------------(NORMAL)-STATE--< |
NORMAL | NORMAL |
| >---- State-(NORMAL)---------------> | | >---- State-(NORMAL)---------------> |
| | | |
| | | |
Figure 7: Transition out of RECOVER state Figure 7: Transition out of RECOVER State
If at any time while a server is in RECOVER state communication If at any time while a server is in RECOVER state communication
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.
8.6. RECOVER-WAIT State 8.6. RECOVER-WAIT State
This state indicates that the server has sent 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 message and has received the UPDDONE message indicating that it has
all outstanding binding update information. In the RECOVER-WAIT received all outstanding binding update information. In the
state the server will wait for the MCLT in order to ensure that any RECOVER-WAIT state, the server will wait for the MCLT in order to
processing that this server might have done prior to losing its ensure that any processing that this server might have done prior to
stable storage will not cause future difficulties. losing its stable storage will not cause future difficulties.
8.6.1. Operation in RECOVER-WAIT State 8.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.
8.6.2. Transition Out of RECOVER-WAIT State 8.6.2. Transition out of RECOVER-WAIT State
Upon entry to RECOVER-WAIT state the server MUST start a timer whose Upon entry into RECOVER-WAIT state, the server MUST start a timer
expiration is set to a time equal to the time the server went down whose expiration is set to a time equal to the time the server went
(if known) or the time the server started (if the down-time is down (the TIME-OF-FAILURE from Section 8.3.2), if known, or the time
unknown) plus the maximum-client-lead-time. When this timer expires, the server started (if the TIME-OF-FAILURE is unknown), plus the
the server will transition into RECOVER-DONE state. MCLT. When this timer expires, the server will transition into
RECOVER-DONE state.
This is to allow any IPv6 addresses or prefixes that were allocated This allows any IPv6 addresses or prefixes that were allocated by
by this server prior to loss of its client binding information in this server prior to the loss of its client binding information in
stable storage to contact the other server or to time out. stable storage to contact the other server or to time out.
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 and the server MAY transition immediately to wait in this state, and the server MAY transition immediately to
RECOVER_DONE state. However, to determine if this server has run RECOVER-DONE state. However, 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 communication fails while a server is in RECOVER-WAIT state, it If communication 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 if 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 this are interrupted, but in this case there is no reason to inhibit this
transition. transition.
8.7. RECOVER-DONE State 8.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.
8.7.1. Operation in RECOVER-DONE State 8.7.1. Operation in RECOVER-DONE State
A server in RECOVER-DONE state SHOULD be renew responsive, and MAY A server in RECOVER-DONE state SHOULD be renew responsive and MAY
respond to RENEW requests but MUST only change the state of a lease respond to RENEW requests but MUST only change the state of a lease
that appears in the RENEW request. It MUST NOT allocate any that appears in the RENEW request. It MUST NOT allocate any
additional leases when in RECOVER-DONE state and should only respond additional leases when in RECOVER-DONE state and should only respond
only to RENEW requests where it already has a record of the lease. to RENEW requests where it already has a record of the lease.
8.7.2. Transition Out of RECOVER-DONE State 8.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, it will transition
transition into NORMAL state. into NORMAL state.
If the partner server enters RECOVER or RECOVER-WAIT state, this If the partner server enters RECOVER or RECOVER-WAIT state, this
server transitions to COMMUNICATIONS-INTERRUPTED. server transitions to COMMUNICATIONS-INTERRUPTED.
If the partner server enters POTENTIAL-CONFLICT state then this If the partner server enters POTENTIAL-CONFLICT state, this server
server enters POTENTIAL-CONFLICT state as well. enters POTENTIAL-CONFLICT state as well.
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.
8.8. NORMAL State 8.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
with the other server, and any required resynchronization has been with the other server and any required resynchronization has been
performed. While some binding database synchronization is performed performed. While some binding database synchronization is performed
in NORMAL state, potential conflicts are resolved prior to entry into in NORMAL state, potential conflicts are resolved prior to entry into
NORMAL state as is binding database data loss. NORMAL state, as is binding database data loss.
When entering NORMAL state, a server will send to the other server When entering NORMAL state, a server will send to the other server
all currently unacknowledged binding updates as BNDUPD messages. all currently unacknowledged binding updates as BNDUPD messages.
When the above process is complete, if the server entering NORMAL When the above process is complete, if the server entering NORMAL
state is a secondary server, then it will request delegable prefixes state is a secondary server, then it will request delegable prefixes
for allocation using the POOLREQ message. for allocation using the POOLREQ message.
8.8.1. Operation in NORMAL State 8.8.1. Operation in NORMAL State
The primary server is responsive in NORMAL state. The secondary is The primary server is responsive in NORMAL state. The secondary is
renew responsive in NORMAL state. renew responsive 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:
Valid lifetime calculations Valid lifetime calculations
As discussed in Section 4.4, the lease interval given to a DHCP As discussed in Section 4.4, 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 acknowledged partner lifetime received from the failover recently acknowledged partner lifetime received 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
skipping to change at page 76, line 15 skipping to change at page 78, line 34
Lazy update of partner server Lazy update of partner server
After sending a REPLY that includes a lease update to a client, After sending a REPLY that includes a lease update to a client,
the 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. See Section 4.3. partner with the new binding information. See Section 4.3.
Reallocation of leases between clients Reallocation of leases 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 BNDREPLY is received for this or EXPIRED. However, until a BNDREPLY is received for this
message, the lease cannot be allocated to another client. It message, the lease cannot be allocated to another client. It
cannot be allocated to the same client again if a BNDUPD was sent, cannot be allocated to the same client again if a BNDUPD message
otherwise it can. See Section 4.2.2.1 for details. was sent; otherwise, it can. See Section 4.2.2.1 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 (see Section 7.5.5). It records partner server in BNDUPD messages (see Section 7.5.5). It records
these in its binding database in stable storage and then sends a these in its binding database in stable storage and then sends a
corresponding BNDREPLY message to its partner server (see corresponding BNDREPLY message to its partner server (see
Section 7.6). Section 7.6).
8.8.2. Transition Out of NORMAL State 8.8.2. Transition out of NORMAL State
If an external command is received by a server in NORMAL state If a server in NORMAL state receives an external command informing it
informing it that its partner is down, then transition into PARTNER- that its partner is down, it will transition immediately into
DOWN state. Generally, this would be an unusual situation, where PARTNER-DOWN state. Generally, this would be an unusual situation,
some external agency knew the partner server was down prior to the where some external agency knew the partner server was down prior to
failover server discovering it on its own. the failover server discovering it on its own.
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 occur if the partner server was capable of maintaining the TCP
connection between the server and also capable of sending a CONTACT connection between the server and also capable of sending a CONTACT
message periodically, but was (for some reason) incapable of message periodically but was (for some reason) incapable of
processing BNDUPD messages. processing BNDUPD messages.
If the communications is determined to not be "ok" (as defined in If it is determined that communications are not "OK" (as defined in
Section 6.6), then transition into COMMUNICATIONS-INTERRUPTED state. Section 6.6), then the server should 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 COMMUNICATIONS-INTERRUPTED state and take the appropriate state
transition from there. For example, it would be expected for the transition from there. For example, it would be expected that the
partner to transition from POTENTIAL-CONFLICT into NORMAL state, but partner would transition from POTENTIAL-CONFLICT state into NORMAL
not for the partner to transition from NORMAL into POTENTIAL-CONFLICT state but not that the partner would transition from NORMAL state
state. 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, then the server should transition into
state. COMMUNICATIONS-INTERRUPTED state.
8.9. COMMUNICATIONS-INTERRUPTED State 8.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 state and COMMUNICATIONS-INTERRUPTED state as the
connection between them fails and recovers, or as the partner server network connection between them fails and recovers, or as the partner
cycles between operational and non-operational. No duplicate lease server cycles between operational and non-operational. No allocation
allocation can occur while the servers cycle between these states. of duplicate leases can occur while the servers cycle between these
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
INTERRUPTED state and into PARTNER-DOWN state (i.e., auto-partner- COMMUNICATIONS-INTERRUPTED state and into PARTNER-DOWN state (i.e.,
down has been configured), then a timer is started for the length of auto-partner-down has been configured), then a timer is started for
the configured auto-partner-down period. the 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 an alarm condition to alert
administrative staff to a potential problem in the DHCP subsystem. administrative staff to a potential problem in the DHCP subsystem.
8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State 8.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 delegable prefixes, and the where the primary MUST allocate only FREE delegable prefixes and the
secondary MUST allocate only FREE-BACKUP delegable prefixes, and each secondary MUST allocate only FREE-BACKUP delegable prefixes, and each
server allocates from its own independent IPv6 address ranges. When server allocates from its own independent IPv6 address ranges. When
responding to RENEW messages, each server will allow continued responding to RENEW messages, each server will allow continued
renewal of a DHCP client's current lease regardless of whether that renewal of a DHCP client's current lease, regardless of whether that
lease was given out by the receiving server or not, although the lease was given out by the receiving server or not, although the
renewal period MUST NOT exceed the MCLT beyond the latest of: 1) the renewal period MUST NOT exceed the MCLT beyond the later of (1) the
partner lifetime already acknowledged by the other server, or 2) now, partner lifetime already acknowledged by the other server or (2) now.
or 3) the partner 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 partner lifetime will not be updated despite state, the acknowledged partner lifetime will not be updated, despite
continued RENEW message processing. This is likely to eventually continued RENEW message processing. This is likely to eventually
cause the actual lifetimes to converge to the MCLT (unless this is cause the actual lifetimes to converge to the MCLT (unless this is
greater than the desired lease time, which would be unusual). greater than the desired lease time, which would be unusual).
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.
8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State 8.9.2. Transition out of COMMUNICATIONS-INTERRUPTED State
If the auto-partner-down timer expires while a server is in the If the auto-partner-down timer expires while a server is in
COMMUNICATIONS-INTERRUPTED state, it will transition immediately into COMMUNICATIONS-INTERRUPTED state, it will transition immediately into
PARTNER-DOWN state. PARTNER-DOWN state.
If an external command is received by a server in COMMUNICATIONS- If a server in COMMUNICATIONS-INTERRUPTED state receives an external
INTERRUPTED state informing it that its partner is down, it will command informing it that its partner is down, it will transition
transition immediately into PARTNER-DOWN state. immediately into PARTNER-DOWN state.
If communications is restored with the other server, then the server If communications with the other server are restored, then the server
in COMMUNICATIONS-INTERRUPTED state will transition into another in COMMUNICATIONS-INTERRUPTED state will transition into another
state based on the state of the partner: state based on the state of the partner:
o NORMAL or COMMUNICATIONS-INTERRUPTED: Transition into the NORMAL o NORMAL or COMMUNICATIONS-INTERRUPTED: Transition into
state. NORMAL state.
o RECOVER: Stay in COMMUNICATIONS-INTERRUPTED state. o RECOVER: Stay in COMMUNICATIONS-INTERRUPTED state.
o RECOVER-DONE: Transition into NORMAL state. o RECOVER-DONE: Transition into NORMAL state.
o PARTNER-DOWN, POTENTIAL-CONFLICT, CONFLICT-DONE, or RESOLUTION- o PARTNER-DOWN, POTENTIAL-CONFLICT, CONFLICT-DONE, or
INTERRUPTED: Transition into POTENTIAL-CONFLICT state. RESOLUTION-INTERRUPTED: Transition into POTENTIAL-CONFLICT state.
The following figure illustrates the transition from NORMAL to Figure 8 illustrates the transition from NORMAL state to
COMMUNICATIONS-INTERRUPTED state and then back to NORMAL state again. COMMUNICATIONS-INTERRUPTED state and then back to NORMAL state again.
Primary Secondary Primary Secondary
Server Server Server Server
NORMAL NORMAL NORMAL NORMAL
| >--CONTACT-------------------> | | >--CONTACT-------------------> |
| <--------------------CONTACT--< | | <--------------------CONTACT--< |
| [TCP connection broken] | | [TCP connection broken] |
COMMUNICATIONS : COMMUNICATIONS COMMUNICATIONS- : COMMUNICATIONS-
INTERRUPTED : INTERRUPTED INTERRUPTED : INTERRUPTED
| [attempt new TCP connection] | | [attempt new TCP connection] |
| [connection succeeds] | | [connection succeeds] |
| | | |
| >--CONNECT-------------------> | | >--CONNECT-------------------> |
| <---------------CONNECTREPLY--< | | <---------------CONNECTREPLY--< |
| NORMAL | >--STATE---------------------> |
| <-------------------STATE-----< | | NORMAL
NORMAL | | <-------------------STATE-----< |
| >--STATE---------------------> | NORMAL |
| | |
| >--BNDUPD--------------------> | | >--BNDUPD--------------------> |
| <-------------------BNDREPLY--< | | <-------------------BNDREPLY--< |
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
| >------BNDREPLY--------------> | | >------BNDREPLY--------------> |
... ... ... ...
| | | |
| <--------------------POOLREQ--< | | <--------------------POOLREQ--< |
| >--POOLRESP------------------> | | >--POOLRESP------------------> |
| | | |
| >--BNDUPD-(#1)---------------> | | >--BNDUPD-(#1)---------------> |
| <-------------------BNDREPLY--< | | <-------------------BNDREPLY--< |
| | | |
| >--BNDUPD-(#2)---------------> | | >--BNDUPD-(#2)---------------> |
| <-------------------BNDREPLY--< | | <-------------------BNDREPLY--< |
| | | |
Figure 8: Transition from NORMAL to COMMUNICATIONS-INTERRUPTED and Figure 8: Transition from NORMAL State
back to COMMUNICATIONS-INTERRUPTED State and Back
8.10. POTENTIAL-CONFLICT State 8.10. POTENTIAL-CONFLICT State
This state indicates that the two servers are attempting to This state indicates that the two servers are attempting to
reintegrate with each other, but at least one of them was running in reintegrate with each other but at least one of them was running in a
a state that did not guarantee automatic reintegration would be state that did not guarantee that automatic reintegration would be
possible. In POTENTIAL-CONFLICT state the servers may determine that possible. In POTENTIAL-CONFLICT state, the servers may determine
the same lease has been offered and accepted by two different that the same lease has been offered and accepted by two different
clients. clients.
It is a goal of the failover protocol to minimize the possibility A goal of the failover protocol is to minimize the possibility that
that POTENTIAL-CONFLICT state is ever entered. POTENTIAL-CONFLICT state is ever entered.
When a primary server enters POTENTIAL-CONFLICT state it should When a primary server enters POTENTIAL-CONFLICT state, it should
request that the secondary send it all updates which the primary request that the secondary send it all updates that the primary
server has not yet acknowledged by sending an UPDREQ message to the server has not yet acknowledged by sending an UPDREQ message to the
secondary server. secondary server.
A secondary server entering POTENTIAL-CONFLICT state will wait for A secondary server entering POTENTIAL-CONFLICT state will wait for
the primary to send it an UPDREQ message. the primary to send it an UPDREQ message.
8.10.1. Operation in POTENTIAL-CONFLICT State 8.10.1. Operation in POTENTIAL-CONFLICT State
Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming
DHCP requests. DHCP requests.
8.10.2. Transition Out of POTENTIAL-CONFLICT State 8.10.2. Transition out of POTENTIAL-CONFLICT State
If communication fails with the partner while in POTENTIAL-CONFLICT If communication with the partner fails while in POTENTIAL-CONFLICT
state, then the server will transition to RESOLUTION-INTERRUPTED state, then the server will transition to RESOLUTION-INTERRUPTED
state. state.
Whenever either server receives an UPDDONE message from its partner Whenever either server receives an UPDDONE message from its partner
while in POTENTIAL-CONFLICT state, it MUST transition to a new state. while in POTENTIAL-CONFLICT state, it MUST transition to a new state.
The primary MUST transition to CONFLICT-DONE state, and the secondary The primary MUST transition to CONFLICT-DONE state, and the secondary
MUST transition to NORMAL state. This will cause the primary server MUST transition to NORMAL state. This will cause the primary server
to leave POTENTIAL-CONFLICT state prior to the secondary, since the to leave POTENTIAL-CONFLICT state prior to the secondary, since the
primary sends an UPDREQ message and receives an UPDDONE before the primary sends an UPDREQ message and receives an UPDDONE message
secondary sends an UPDREQ message and receives its UPDDONE message. before the secondary sends an UPDREQ message and receives its UPDDONE
message.
When a secondary server receives an indication that the primary When a secondary server receives an indication that the primary
server has made a transition from POTENTIAL-CONFLICT to CONFLICT-DONE server has made a transition from POTENTIAL-CONFLICT to CONFLICT-DONE
state, it SHOULD send an UPDREQ message to the primary server. state, it SHOULD send an UPDREQ message to the primary server.
Primary Secondary Primary Secondary
Server Server Server Server
| | | |
POTENTIAL-CONFLICT POTENTIAL-CONFLICT POTENTIAL-CONFLICT POTENTIAL-CONFLICT
| | | |
| >--UPDREQ--------------------> | | >--UPDREQ--------------------> |
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
| >--BNDREPLY------------------> | | >--BNDREPLY------------------> |
... ... ... ...
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
| >--BNDREPLY------------------> | | >--BNDREPLY------------------> |
| | | |
| <--------------------UPDDONE--< | | <--------------------UPDDONE--< |
CONFLICT-DONE | CONFLICT-DONE |
| >--STATE--(CONFLICT-DONE)----> | | >--STATE--(CONFLICT-DONE)----> |
| <---------------------UPDREQ--< | | <---------------------UPDREQ--< |
| | | |
| >--BNDUPD--------------------> | | >--BNDUPD--------------------> |
| <-------------------BNDREPLY--< | | <-------------------BNDREPLY--< |
... ... ... ...
| >--BNDUPD--------------------> | | >--BNDUPD--------------------> |
| <-------------------BNDREPLY--< | | <-------------------BNDREPLY--< |
| | | |
| >--UPDDONE-------------------> | | >--UPDDONE-------------------> |
| NORMAL | NORMAL
| <------------STATE--(NORMAL)--< | | <------------STATE--(NORMAL)--< |
NORMAL | NORMAL |
| >--STATE--(NORMAL)-----------> | | >--STATE--(NORMAL)-----------> |
| | | |
| <--------------------POOLREQ--< | | <--------------------POOLREQ--< |
| >------POOLRESP--------------> | | >------POOLRESP--------------> |
| | | |
Figure 9: Transition out of POTENTIAL-CONFLICT Figure 9: Transition out of POTENTIAL-CONFLICT State
8.11. RESOLUTION-INTERRUPTED State 8.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
communication failed prior to completion of re-integration. communication failed prior to completion of reintegration.
The RESOLUTION-INTERRUPTED state exists because servers are not The RESOLUTION-INTERRUPTED state exists because servers are not
responsive in POTENTIAL-CONFLICT state, and if one server drops out responsive in POTENTIAL-CONFLICT state, and if one server drops out
of service while both servers are in POTENTIAL-CONFLICT state, the of service while both servers are in POTENTIAL-CONFLICT state, the
server that remains in service will not be able to process DHCP server that remains in service will not be able to process DHCP
client requests and there will be no DHCP server available to process client requests and there will be no DHCP server available to process
client requests. The RESOLUTION-INTERRUPTED state is the state that client requests. The RESOLUTION-INTERRUPTED state is the state that
a server moves to if its partner disappears while it is in POTENTIAL- a server moves to if its partner disappears while it is in
CONFLICT state. 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.
8.11.1. Operation in RESOLUTION-INTERRUPTED State 8.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 leases, each server SHOULD allocate from its own When allocating new leases, each server SHOULD allocate from its own
pool (if that can be determined), where the primary SHOULD allocate pool (if that can be determined), where the primary SHOULD allocate
only FREE leases, and the secondary SHOULD allocate only FREE-BACKUP only FREE leases and the secondary SHOULD allocate only FREE-BACKUP
leases. When responding to renewal requests, each server will allow leases. When responding to renewal requests, each server will allow
continued renewal of a DHCP client's current lease independent of continued renewal of a DHCP client's current lease, independent of
whether that lease was given out by the receiving server or not, whether that lease was given out by the receiving server or not,
although the renewal period MUST NOT exceed the maximum client lead although the renewal period MUST NOT exceed the MCLT beyond the
time (MCLT) beyond the latest of: 1) the partner lifetime already later of (1) the partner lifetime already acknowledged by the other
acknowledged by the other server or 2) now or 3) partner lifetime server or (2) now.
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 partner lifetime will not be updated in any state, the acknowledged partner lifetime will not be updated in any
new bindings. new bindings.
8.11.2. Transition Out of RESOLUTION-INTERRUPTED State 8.11.2. Transition out of RESOLUTION-INTERRUPTED State
If an external command is received by a server in RESOLUTION- If a server in RESOLUTION-INTERRUPTED state receives an external
INTERRUPTED state informing it that its partner is down, it will command informing it that its partner is down, it will transition
transition immediately into PARTNER-DOWN state. immediately into PARTNER-DOWN state.
If communications is restored with the other server, then the server If communications with the other server are restored, then the server
in RESOLUTION-INTERRUPTED state will transition into POTENTIAL- in RESOLUTION-INTERRUPTED state will transition into
CONFLICT state. POTENTIAL-CONFLICT state.
8.12. CONFLICT-DONE State 8.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 reintegrate with each other, the primary server has
has received all of the updates from the secondary server. It makes received all of the updates from the secondary server. It makes a
a transition into CONFLICT-DONE state in order that it may be totally transition into CONFLICT-DONE state so that it can 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 the primary server, as in both
responds to all clients' requests. The distinction between CONFLICT- states it responds to all clients' requests. The distinction between
DONE and NORMAL states is necessary in the event that a load- CONFLICT-DONE and NORMAL states is necessary in the event that a
balancing extension is ever defined. load-balancing extension is ever defined.
8.12.1. Operation in CONFLICT-DONE State 8.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 communication fails, remain in CONFLICT-DONE state. If If communication fails, remain in CONFLICT-DONE state. If
communications becomes OK, remain in CONFLICT-DONE state until the communication becomes "OK", remain in CONFLICT-DONE state until the
conditions for transition out become satisfied. conditions for transition out of CONFLICT-DONE state are satisfied.
8.12.2. Transition Out of CONFLICT-DONE State 8.12.2. Transition out of CONFLICT-DONE State
If communication fails with the partner while in CONFLICT-DONE state, If communication with the partner fails while in CONFLICT-DONE state,
then the server will remain in CONFLICT-DONE state. then the server will remain in CONFLICT-DONE state.
When a primary server determines that the secondary server has made a When a primary server determines that the secondary server has made a
transition into NORMAL state, the primary server will also transition transition into NORMAL state, the primary server will also transition
into NORMAL state. into NORMAL state.
9. DNS Update Considerations 9. DNS Update Considerations
DHCP servers (and clients) can use DNS Updates as described in RFC DHCP servers (and clients) can use "DNS update" as described in
2136 [RFC2136] to maintain DNS name-mappings as they maintain DHCP RFC 2136 [RFC2136] to maintain DNS name mappings as they maintain
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
DNS updates that are not part of non-failover environments. This DNS updates that are not part of non-failover environments. This
section describes these issues, and defines the information which section describes these issues and defines the information that
failover partners should exchange in order to ensure consistent failover partners should exchange in order to ensure consistent
behavior. The presence of this section should not be interpreted as behavior. The presence of this section should not be interpreted as
requiring an implementation of the DHCPv6 failover protocol to also a requirement that an implementation of the DHCPv6 failover protocol
support DNS updates. also support DNS 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 DNS update protocols intersect for the benefit of failover and DHCP DNS update protocols intersect for the benefit of
implementations which support both protocols, not to introduce a new implementations that support both protocols, not to introduce a new
requirement into the DHCPv6 failover protocol. Thus, a DHCP server requirement into the DHCPv6 failover protocol. Thus, a DHCP server
which implements the failover protocol MAY also support DNS updates, that implements the failover protocol MAY also support DNS updates,
but if it does support DNS updates it SHOULD utilize the techniques but if it does support DNS updates it SHOULD utilize the techniques
described here in order to correctly distribute them between the described here in order to correctly distribute them between the
failover partners. See RFC 4704 [RFC4704] as well as RFC 4703 failover partners. See RFC 4704 [RFC4704] as well as RFC 4703
[RFC4703] for information on how DHCP servers deal with potential [RFC4703] for information on how DHCP servers deal with potential
conflicts when updating DNS even without failover. conflicts when updating DNS even without failover.
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 DNS update protocol to update a DNS a server that is utilizing the DNS update protocol to update a DNS
server should not be a partner with a server which is not utilizing server should not be a partner with a server that is not utilizing
the DNS update protocol to update a DNS server. However, a server the DNS update protocol to update a DNS server. However, a server
which is not able to support DNS update or is not configured to that is not able to support DNS update or is not configured to
support DNS update SHOULD output a warning message when it receives support DNS update SHOULD output a warning message when it receives
BNDUPD messages which indicate that its failover partner is BNDUPD messages that indicate that its failover partner is configured
configured to support the DNS update protocol to update a DNS server. to support the DNS update protocol to update a DNS server. An
An implementation MAY consider this an error and refuse to accept the implementation MAY consider this an error and refuse to accept the
BNDUPD by returning the status DNSUpdateNotSupported in an BNDUPD message by returning the status DNSUpdateNotSupported in an
OPTION_STATUS_CODE option in the BNDREPLY message, or it MAY choose OPTION_STATUS_CODE option in the BNDREPLY message, or it MAY choose
to operate anyway, having warned the administrator of the problem in to operate anyway, having warned the administrator of the problem in
some way. some way.
9.1. Relationship between failover and DNS update 9.1. Relationship between Failover and 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 DNS update, and when it should failover server should initiate a DNS 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 that 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, and
the secondary DHCP server to grant new leases even if it is unable to allowing the secondary DHCP server to grant new leases even if it is
communicate with the primary server. The desired external DNS update unable to communicate with the primary server. The desired external
behavior for DHCPv6 failover servers is similar to that described DNS update behavior for DHCPv6 failover servers is similar to that
above for the failover protocol itself: described above for the failover protocol itself:
1. Allow timely DNS updates from the server which grants a lease to 1. Allow timely DNS updates from the server that grants a lease to a
a client. Recognize that there is often a DNS update lifecycle client. Recognize that there is often a DNS update "lifecycle"
which parallels the DHCP lease lifecycle. This is likely to that parallels the DHCP lease lifecycle. This is likely to
include the addition of records when the lease is granted, and include the addition of records when the lease is granted and the
the removal of DNS records when the lease is subsequently made removal of DNS records when the lease is subsequently made
available for allocation to a different client. available for allocation to a different client.
2. Communicate enough information between the two failover servers 2. Communicate enough information between the two failover servers
to allow one to complete the DNS update 'lifecycle' even if the to allow one to complete the DNS update lifecycle even if the
other server originally granted the lease. other server originally granted the lease.
3. Avoid redundant or overlapping DNS updates, where both failover 3. Avoid redundant or overlapping DNS updates where both failover
servers are attempting to perform DNS updates for the same lease- servers are attempting to perform DNS updates for the same
client binding. lease-client binding.
4. Avoid situations where one partner is attempting to add RRs 4. Avoid situations where one partner is attempting to add resource
related to a lease binding while the other partner is attempting records (RRs) related to a lease binding while the other partner
to remove RRs related to the same lease binding. is attempting to remove RRs related to the same lease binding.
While DHCPv6 servers configured for DNS update typically perform While DHCPv6 servers configured for DNS update typically perform
these operations on both the AAAA and the PTR resource records, this these operations on both the AAAA and the PTR RRs, this is not
is not required. It is entirely possible that a DHCPv6 server could required. It is entirely possible that a DHCPv6 server could be
be configured to only update the DNS with PTR records, and the DHCPv6 configured to only update the DNS with PTR records, and the DHCPv6
clients could be responsible for updating the DNS with their own AAAA clients could be responsible for updating the DNS with their own AAAA
records. In this case, the discussions here would apply only to the records. In this case, the discussions here would apply only to the
PTR records. PTR records.
9.2. Exchanging DNS Update Information 9.2. Exchanging DNS Update Information
In order for either server to be able to complete a DNS update, or to In order for either server to be able to complete a DNS update or to
remove DNS records which were added by its partner, both servers need remove DNS records that were added by its partner, both servers need
to know the FQDN associated with the lease-client binding. In to know the FQDN associated with the lease-client binding. In
addition, to properly handle DNS updates, additional information is addition, to properly handle DNS updates, additional information is
required. All of the following information needs to be transmitted required. All of the following information needs to be transmitted
between the failover partners: between the failover partners:
1. The FQDN that the client requested be associated with the lease. 1. The FQDN that the client requested be associated with the lease.
If the client doesn't request a particular FQDN and one is If the client doesn't request a particular FQDN and one is
synthesized by the failover server or if the failover server is synthesized by the failover server or if the failover server is
configured to replace a client requested FQDN with a different configured to replace a client-requested FQDN with a different
FQDN, then the server generated value would be used. FQDN, then the server-generated value would be used.
2. The FQDN that was actually placed in the DNS for this lease. It 2. The FQDN that was actually placed in the DNS for this lease. It
may differ from the client requested FQDN due to some form of may differ from the client-requested FQDN due to some form of
disambiguation or other DHCP server configuration (as described disambiguation or other DHCP server configuration (as described
above). above).
3. The status of and DNS update operations in progress or completed. 3. The status of any DNS update operations in progress or completed.
4. Information sufficient to allow the failover partner to remove 4. Information sufficient to allow the failover partner to remove
the FQDN from the DNS should that become necessary. the FQDN from the DNS, should that become necessary.
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 leases allocated to clients. the DNS up to date with the leases 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 DNS update related to the lease. no change in the status of any DNS update related to the lease.
The partner server receiving BNDUPD messages containing the DNS The partner server receiving BNDUPD messages containing the DNS
update information SHOULD compare the status information and the FQDN update information SHOULD compare the status information and the FQDN
with the current DNS update information it has associated with the with the current DNS update information it has associated with the
lease binding, and update its notion of the DNS update status lease binding and update its notion of the DNS update status
accordingly. accordingly.
Some implementations will instead choose to send a BNDUPD without Some implementations will instead choose to send a BNDUPD message
waiting for the DNS update to complete, and then will send a second without waiting for the DNS update to complete and then will send a
BNDUPD once the DNS update is complete. Other implementations will second BNDUPD message once the DNS update is complete. Other
delay sending the partner a BNDUPD until the DNS update has been implementations will delay sending the partner a BNDUPD message until
acknowledged by the DNS server, or until some time-limit has elapsed, the DNS update has been acknowledged by the DNS server, or until some
in order to avoid sending a second BNDUPD. time limit has elapsed, in order to avoid sending a second BNDUPD
message.
The FQDN option contains the FQDN that will be associated with the The FQDN option contains the FQDN that will be associated with the
AAAA RR (if the server is performing an AAAA RR update for the AAAA RR (if the server is performing a AAAA RR update for the
client). The PTR RR can be generated automatically from the IPv6 client). The PTR RR can be generated automatically from the IPv6
address or prefix value. The FQDN may be composed in any of several address value. The FQDN may be composed in any of several ways,
ways, depending on server configuration and the information provided depending on server configuration and the information provided by the
by the client in its DHCP messages. The client may supply a hostname client in its DHCP messages. The client may supply a hostname that
which it would like the server to use in forming the FQDN, or it may it would like the server to use in forming the FQDN, or it may supply
supply the entire FQDN. The server may be configured to attempt to the entire FQDN. The server may be configured to attempt to use the
use the information the client supplies, it may be configured with an information the client supplies, it may be configured with an FQDN to
FQDN to use for the client, or it may be configured to synthesize an use for the client, or it may be configured to synthesize an FQDN.
FQDN.
Since the server interacting with the client may not have completed Since the server interacting with the client may not have completed
the DNS update at the time it sends the first BNDUPD about the lease the DNS update at the time it sends the first BNDUPD message about
binding, there may be cases where the FQDN in later BNDUPD messages the lease binding, there may be cases where the FQDN in later BNDUPD
does not match the FQDN included in earlier messages. For example, messages does not match the FQDN included in earlier messages. For
the responsive server may be configured to handle situations where example, the responsive server may be configured to handle situations
two or more DHCP client FQDNs are identical by modifying the most- where two or more DHCP client FQDNs are identical by modifying the
specific label in the FQDNs of some of the clients in an attempt to most-specific label in the FQDNs of some of the clients in an attempt
generate unique FQDNs for them (a process sometimes called to generate unique FQDNs for them (a process sometimes called
"disambiguation"). Alternatively, at sites which use some or all of "disambiguation"). Alternatively, at sites that use some or all of
the information which clients supply to form the FQDN, it's possible the information that clients supply to form the FQDN, it's possible
that a client's configuration may be changed so that it begins to that a client's configuration may be changed so that it begins to
supply new data. The server interacting with the client may react by supply new data. The server interacting with the client may react by
removing the DNS records which it originally added for the client, removing the DNS records that it originally added for the client and
and replacing them with records that refer to the client's new FQDN. replacing them with records that refer to the client's new FQDN. In
In such cases, the server SHOULD include the actual FQDN that was such cases, the server SHOULD include the actual FQDN that was used
used in subsequent DNS update options in any BNDUPD messages in subsequent DNS update options in any BNDUPD messages exchanged
exchanged between the failover partners. This server SHOULD include between the failover partners. This server SHOULD include relevant
relevant information in its BNDUPD messages. This information may be information in its BNDUPD messages. This information may be
necessary in order to allow the non-responsive partner to detect necessary in order to allow the non-responsive partner to detect
client configuration changes that change the hostname or FQDN data client configuration changes that change the hostname or FQDN data
which the client includes in its DHCPv6 requests. that the client includes in its DHCPv6 requests.
9.3. Adding RRs to the DNS 9.3. Adding RRs to the DNS
A failover server which is going to perform DNS updates SHOULD A failover server that is going to perform DNS updates SHOULD
initiate the DNS update when it grants a new lease to a client. The initiate the DNS update when it grants a new lease to a client. The
server which did not grant the lease SHOULD NOT initiate a DNS update server that did not grant the lease SHOULD NOT initiate a DNS update
when it receives the BNDUPD after the lease has been granted. The when it receives the BNDUPD message after the lease has been granted.
failover protocol ensures that only one of the partners will grant a The failover protocol ensures that only one of the partners will
lease to any individual client, so it follows that this requirement grant a lease to any individual client, so it follows that this
will prevent both partners from initiating updates simultaneously. requirement will prevent both partners from initiating updates
The server initiating the update SHOULD follow the protocol in RFC simultaneously. The server initiating the update SHOULD follow the
4704 [RFC4704]. The server may be configured to perform a AAAA RR protocol in RFC 4704 [RFC4704]. The server may be configured to
update on behalf of its clients, or not. Ordinarily, a failover perform a AAAA RR update on behalf of its clients, or not.
server will not initiate DNS updates when it renews leases. In two Ordinarily, a failover server will not initiate DNS updates when it
cases, however, a failover server MAY initiate a DNS update when it renews leases. In two cases, however, a failover server MAY initiate
renews a lease to its existing client: a DNS update when it renews a lease to its existing client:
1. When the lease was granted before the server was configured to 1. When the lease was granted before the server was configured to
perform DNS updates, the server MAY be configured to perform perform DNS updates, the server MAY be configured to perform
updates when it next renews existing leases. updates when it next renews existing leases.
2. If a server is in PARTNER-DOWN state, it can conclude that its 2. If a server is in PARTNER-DOWN state, it can conclude that its
partner is no longer attempting to perform an update for the 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 DNS update. It MAY initiate this update server MAY initiate a DNS update. It may initiate this update
immediately upon entry to PARTNER-DOWN state, it may perform this immediately upon entry into PARTNER-DOWN state, it may perform
in the background, or it MAY initiate this update upon next this in the background, or it may initiate this update upon next
hearing from the DHCP client. hearing from the DHCP client.
Note that, regardless of the use of failover, there is a use case for Note that, regardless of the use of failover, there is a use case for
updating the DNS on every lease renewal. If there is a concern that updating the DNS on every lease renewal. If there is a concern that
the information in the DNS does not match the information in the DHCP the information in the DNS does not match the information in the DHCP
server, updating the DNS on lease renewal is one way to gradually server, updating the DNS on lease renewal is one way to gradually
ensure that the DNS has information that corresponds correctly the ensure that the DNS has information that corresponds correctly to the
information in the DHCP server. information in the DHCP server.
9.4. Deleting RRs from the DNS 9.4. Deleting RRs from the DNS
The failover server which makes a lease PENDING-FREE SHOULD initiate The failover server that makes a lease PENDING-FREE SHOULD initiate
any DNS deletes, if it has recorded that DNS records were added on any DNS 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 lease PENDING-FREE" when A server not in PARTNER-DOWN state "makes a lease PENDING-FREE" when
it initiates a BNDUPD with a binding-status of FREE, FREE-BACKUP, it initiates a BNDUPD message with a binding-status of FREE,
EXPIRED, or RELEASED. Its partner confirms this status by acking FREE-BACKUP, EXPIRED, or RELEASED. Its partner confirms this status
that BNDUPD, and upon receipt of the BNDREPLY the server has "made by acking that BNDUPD message, and upon receipt of the BNDREPLY
the lease PENDING-FREE". Conversely, a server in PARTNER-DOWN state message the server has "made the lease PENDING-FREE". Conversely, a
"makes a lease PENDING-FREE" when it sets the binding-status to FREE, server in PARTNER-DOWN state "makes a lease PENDING-FREE" when it
since in PARTNER-DOWN state no communications is required with the sets the binding-status to FREE, since in PARTNER-DOWN state no
partner. communications with the partner are required.
It is at this point that it should initiate the DNS operations to It is at this point that it should initiate the DNS operations to
delete RRs from the DNS. Its partner SHOULD NOT initiate DNS deletes delete RRs from the DNS. Its partner SHOULD NOT initiate DNS deletes
for DNS records related to the lease binding as part of sending the for DNS records related to the lease binding as part of sending the
BNDREPLY message. The partner MAY have issued BNDUPD messages with a BNDREPLY message. The partner MAY have issued BNDUPD messages with a
binding-status of FREE, EXPIRED, or RELEASED previously, but the binding-status of FREE, EXPIRED, or RELEASED previously, but the
other server will have rejected these BNDUPD messages. other server will have rejected these BNDUPD 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 lease PENDING-FREE. The server making servers will be able to make a lease PENDING-FREE. The server making
the lease PENDING-FREE may be doing so while it is in NORMAL the lease PENDING-FREE may be doing so while it is communicating in
communication with its partner, or it may be in PARTNER-DOWN state. NORMAL state with its partner, or it may be in PARTNER-DOWN state.
If a server is in PARTNER-DOWN state, it may be performing DNS If a server is in PARTNER-DOWN state, it may be performing DNS
deletes for RRs which its partner added originally. This allows a deletes for RRs that its partner added originally. This allows a
single remaining partner server to assume responsibility for all of single remaining partner server to assume responsibility for all of
the DNS update activity which the two servers were undertaking. the DNS update activity that the two servers were undertaking.
Another implication of this approach is that no DNS RR deletes will Another implication of this approach is that no DNS RR deletes will
be performed while either server is in COMMUNICATIONS-INTERRUPTED be performed while either server is in COMMUNICATIONS-INTERRUPTED
state, since no leases are moved into the PENDING-FREE state during state, since no leases are moved into the PENDING-FREE state during
that period. that period.
A failover server SHOULD ensure that a server failure while making a A failover server SHOULD ensure that a server failure while making a
lease PENDING-FREE and initiating a DNS delete does not somehow leave lease PENDING-FREE and initiating a DNS delete does not somehow leave
the lease with a RR in the DNS with nothing recorded in the lease the lease with an RR in the DNS with nothing recorded in the lease
state database to trigger a DNS delete. state database to trigger a DNS delete.
9.5. Name Assignment with No Update of DNS 9.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
DHCP client but not enter that name into the DNS. This is typically DHCP client but not enter that name into the DNS. This is typically
a name that it has discovered or generated from information it has a name that it has discovered or generated from information it has
received from the client. In this case this name information SHOULD received from the client. In this case, this name information SHOULD
be communicated to the failover partner, if only to ensure that they be communicated to the failover partner, if only to ensure that they
will return the same name in the event the partner becomes the server will return the same name in the event the partner becomes the server
to which the DHCP client begins to interact. with which the DHCP client begins to interact.
10. Security Considerations 10. 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 Section 23 of [RFC3315] and Section 15
Section 15 related to the server apply. of [RFC3633] related to the server apply.
The use of TCP introduces some additional concerns. Attacks that The use of TCP introduces some additional concerns. Attacks that
attempt to exhaust the DHCP server's available TCP connection attempt to exhaust the DHCP server's available TCP connection
resources can compromise the ability of legitimate partners to resources can compromise the ability of legitimate partners to
receive service. Malicious requestors who succeed in establishing receive service. Malicious requestors who succeed in establishing
connections but who then send invalid messages, partial messages, or connections but who then send invalid messages, partial messages, or
no messages at all can also exhaust a server's pool of available no messages at all can also exhaust a server's pool of available
connections. connections.
DHCPv6 failover can operate in secure or insecure mode. Secure mode DHCPv6 failover can operate in secure or insecure mode. Secure mode
(using TLS) would be indicated when the TCP connection between (using Transport Layer Security (TLS) [RFC5246]) would be indicated
failover partners is open to external monitoring or interception. when the TCP connection between failover partners is open to external
Insecure mode should only be used when the TCP connection between monitoring or interception. Insecure mode should only be used when
failover partners remains within a set of protected systems. Details the TCP connection between failover partners remains within a set of
of such protections are beyond the scope of this document. Failover protected systems. Details of such protections are beyond the scope
servers MUST use the approach documented in Section 9.1 of [RFC7653] of this document. Failover servers MUST use the approach documented
to decide to use or not to use TLS when connecting with the failover in Section 9.1 of [RFC7653] to decide whether or not to use TLS when
partner. connecting with the failover partner.
The threats created by using failover directly mirror those from The threats created by using failover directly mirror those from
using DHCPv6 itself: information leakage through monitoring, and using DHCPv6 itself: information leakage through monitoring, and
disruption of address assignment and configuration. Monitoring the disruption of address assignment and configuration. Monitoring the
failover TCP connection provides no additional data beyond that failover TCP connection provides no additional data beyond that
available from monitoring the interactions between DHCPv6 clients and available from monitoring the interactions between DHCPv6 clients and
the DHCPv6 server. Likewise, manipulating the data flow between the DHCPv6 server. Likewise, manipulating the data flow between
failover servers provides no additional opportunities to disrupt failover servers provides no additional opportunities to disrupt
address assignment and configuration beyond that provided by acting address assignment and configuration beyond that provided by acting
as a counterfeit DHCP server. Protection from both threats is easier as a counterfeit DHCP server. Protection from both threats is easier
than with basic DHCPv6, as only a single TCP connection needs to be than with basic DHCPv6, as only a single TCP connection needs to be
protected. Either use secure mode to protect that TCP connection or protected. Either use secure mode to protect that TCP connection or
ensure that it can only exist with a set of protected systems. ensure that it can only exist with a set of protected systems.
When operating in secure mode, TLS [RFC5246] is used to secure the When operating in secure mode, TLS is used to secure the connection.
connection. The recommendations in [RFC7525] SHOULD be followed when The recommendations in [RFC7525] SHOULD be followed when negotiating
negotiating a TLS connection. a TLS connection.
Servers SHOULD offer configuration parameters to limit the sources of Servers SHOULD offer configuration parameters to limit the sources of
incoming connections through validation and use of the digital incoming connections through validation and use of the digital
certificates presented to create a TLS connection. They SHOULD also certificates presented to create a TLS connection. They SHOULD also
limit the number of accepted connections and limit the period of time limit the number of accepted connections and limit the period of time
during which an idle connection will be left open. during which an idle connection will be left open.
Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to
attempt to secure transmission of the messages described in this attempt to secure transmission of the messages described in this
document. If authentication is desired, secure mode using TLS SHOULD document. If authentication is desired, secure mode using TLS SHOULD
be employed as described in Sections 8.2 and 9.1 of [RFC7653]. be employed as described in Sections 8.2 and 9.1 of [RFC7653].
11. IANA Considerations 11. IANA Considerations
IANA is requested to assign values for the following new DHCPv6 IANA has assigned values for the following new DHCPv6 message types
Message types in the registry maintained in in the registry maintained at <http://www.iana.org/assignments/
http://www.iana.org/assignments/dhcpv6-parameters: dhcpv6-parameters>:
o BNDUPD (TBD1)
o BNDREPLY (TBD2)
o POOLREQ (TBD3)
o POOLRESP (TBD4) o BNDUPD (24)
o UPDREQ (TBD5) o BNDREPLY (25)
o UPDREQALL (TBD6) o POOLREQ (26)
o UPDDONE (TBD7) o POOLRESP (27)
o CONNECT (TBD8) o UPDREQ (28)
o CONNECTREPLY (TBD9) o UPDREQALL (29)
o DISCONNECT (TBD10) o UPDDONE (30)
o STATE (TBD11) o CONNECT (31)
o CONTACT (TBD12) o CONNECTREPLY (32)
IANA is requested to assign values for the following new DHCPv6 o DISCONNECT (33)
Option codes in the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters:
OPTION_F_BINDING_STATUS (TBD13) o STATE (34)
OPTION_F_CONNECT_FLAGS (TBD14) o CONTACT (35)
IANA has assigned values for the following new DHCPv6 option codes in
the registry maintained at <http://www.iana.org/assignments/
dhcpv6-parameters>:
OPTION_F_DNS_REMOVAL_INFO (TBD15) o OPTION_F_BINDING_STATUS (114)
OPTION_F_DNS_HOST_NAME (TBD16) o OPTION_F_CONNECT_FLAGS (115)
OPTION_F_DNS_ZONE_NAME (TBD17) o OPTION_F_DNS_REMOVAL_INFO (116)
OPTION_F_DNS_FLAGS (TBD18) o OPTION_F_DNS_HOST_NAME (117)
OPTION_F_EXPIRATION_TIME (TBD19) o OPTION_F_DNS_ZONE_NAME (118)
OPTION_F_MAX_UNACKED_BNDUPD (TBD20) o OPTION_F_DNS_FLAGS (119)
OPTION_F_MCLT (TBD21) o OPTION_F_EXPIRATION_TIME (120)
OPTION_F_PARTNER_LIFETIME (TBD22) o OPTION_F_MAX_UNACKED_BNDUPD (121)
OPTION_F_PARTNER_LIFETIME_SENT (TBD23)
OPTION_F_PARTNER_DOWN_TIME (TBD24) o OPTION_F_MCLT (122)
OPTION_F_PARTNER_RAW_CLT_TIME (TBD25) o OPTION_F_PARTNER_LIFETIME (123)
OPTION_F_PROTOCOL_VERSION (TBD26) o OPTION_F_PARTNER_LIFETIME_SENT (124)
OPTION_F_KEEPALIVE_TIME (TBD27) o OPTION_F_PARTNER_DOWN_TIME (125)
OPTION_F_RECONFIGURE_DATA (TBD28) o OPTION_F_PARTNER_RAW_CLT_TIME (126)
OPTION_F_RELATIONSHIP_NAME (TBD29) o OPTION_F_PROTOCOL_VERSION (127)
OPTION_F_SERVER_FLAGS (TBD30) o OPTION_F_KEEPALIVE_TIME (128)
OPTION_F_SERVER_STATE (TBD31) o OPTION_F_RECONFIGURE_DATA (129)
OPTION_F_START_TIME_OF_STATE (TBD32) o OPTION_F_RELATIONSHIP_NAME (130)
OPTION_F_STATE_EXPIRATION_TIME (TBD33) o OPTION_F_SERVER_FLAGS (131)
IANA is requested to assign values for the following new DHCPv6 o OPTION_F_SERVER_STATE (132)
Status codes in the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters:
AddressInUse (TBD34) o OPTION_F_START_TIME_OF_STATE (133)
ConfigurationConflict (TBD35) o OPTION_F_STATE_EXPIRATION_TIME (134)
IANA has assigned values for the following new DHCPv6 status codes in
the registry maintained at <http://www.iana.org/assignments/
dhcpv6-parameters>:
MissingBindingInformation (TBD36) o AddressInUse (16)
OutdatedBindingInformation (TBD37) o ConfigurationConflict (17)
ServerShuttingDown (TBD38) o MissingBindingInformation (18)
DNSUpdateNotSupported (TBD39) o OutdatedBindingInformation (19)
ExcessiveTimeSkew (TBD40) o ServerShuttingDown (20)
12. Acknowledgements o DNSUpdateNotSupported (21)
This document extensively uses concepts, definitions and other parts o ExcessiveTimeSkew (22)
of an effort to document failover for DHCPv4. Authors would like to
thank Shawn Routhier, Greg Rabil, Bernie Volz and Marcin Siodelski
for their significant involvement and contributions. In particular,
Bernie Volz and Shawn Routhier provided detailed and substantive
technical reviews of the draft. Authors would like to thank
VithalPrasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki and
Michal Hoeft for their insightful comments.
13. References 12. References
13.1. Normative References 12.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., 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, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>. <http://www.rfc-editor.org/info/rfc2136>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315,
2003, <http://www.rfc-editor.org/info/rfc3315>. July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003, DOI 10.17487/RFC3633, December 2003,
<http://www.rfc-editor.org/info/rfc3633>. <http://www.rfc-editor.org/info/rfc3633>.
[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, Configuration Protocol (DHCP) Clients", RFC 4703,
DOI 10.17487/RFC4703, October 2006, DOI 10.17487/RFC4703, October 2006,
skipping to change at page 93, line 22 skipping to change at page 95, line 37
<http://www.rfc-editor.org/info/rfc5460>. <http://www.rfc-editor.org/info/rfc5460>.
[RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet [RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet
Selection Options for DHCPv4 and DHCPv6", RFC 6607, Selection Options for DHCPv4 and DHCPv6", RFC 6607,
DOI 10.17487/RFC6607, April 2012, DOI 10.17487/RFC6607, April 2012,
<http://www.rfc-editor.org/info/rfc6607>. <http://www.rfc-editor.org/info/rfc6607>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
2015, <http://www.rfc-editor.org/info/rfc7525>. May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
October 2015, <http://www.rfc-editor.org/info/rfc7653>. October 2015, <http://www.rfc-editor.org/info/rfc7653>.
13.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<http://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References
[RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover [RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
Requirements", RFC 7031, DOI 10.17487/RFC7031, September Requirements", RFC 7031, DOI 10.17487/RFC7031,
2013, <http://www.rfc-editor.org/info/rfc7031>. September 2013, <http://www.rfc-editor.org/info/rfc7031>.
Acknowledgements
This document extensively uses concepts, definitions, and other parts
of an effort to document failover for DHCPv4. The authors would like
to thank Shawn Routhier, Greg Rabil, Bernie Volz, and Marcin
Siodelski for their significant involvement and contributions. In
particular, Bernie Volz and Shawn Routhier provided detailed and
substantive technical reviews of the document. The RFC Editor also
caught several important technical issues. The authors would like to
thank Vithalprasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki,
and Michal Hoeft for their insightful comments.
Authors' Addresses Authors' Addresses
Tomasz Mrugalski Tomek Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, California 94063
USA United States of America
Phone: +1 650 423 1345
Email: tomasz.mrugalski@gmail.com Email: tomasz.mrugalski@gmail.com
Kim Kinnear Kim Kinnear
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 200 Beaver Brook Road
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
USA United States of America
Phone: +1 (978) 936-0000 Phone: +1 978 936 0000
Email: kkinnear@cisco.com Email: kkinnear@cisco.com
 End of changes. 662 change blocks. 
2006 lines changed or deleted 2052 lines changed or added

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