draft-ietf-dhc-dhcpv6-failover-protocol-00.txt   draft-ietf-dhc-dhcpv6-failover-protocol-01.txt 
Dynamic Host Configuration (DHC) T. Mrugalski Dynamic Host Configuration (DHC) T. Mrugalski
Internet-Draft ISC Internet-Draft ISC
Intended status: Standards Track K. Kinnear Intended status: Standards Track K. Kinnear
Expires: April 18, 2016 Cisco Expires: June 26, 2016 Cisco
October 16, 2015 December 24, 2015
DHCPv6 Failover Protocol DHCPv6 Failover Protocol
draft-ietf-dhc-dhcpv6-failover-protocol-00 draft-ietf-dhc-dhcpv6-failover-protocol-01
Abstract Abstract
DHCPv6 defined in "Dynamic Host Configuration Protocol for IPv6 DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" does not offer server redundancy. This document defines a (DHCPv6)" (RFC3315) does not offer server redundancy. This document
specific protocol implementation to provide for DHCPv6 failover, a defines a protocol implementation to provide for DHCPv6 failover, a
mechanism for running two servers on the same network with capability mechanism for running two servers on the same network with the
for either server to take over clients' leases in case of server capability for either server to take over clients' leases in case of
failure or network partition. It meets the requirements for DHCPv6 server failure or network partition. It meets the requirements for
failover detailed in "DHCPv6 Failover Requirements". DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC7031).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2016. This Internet-Draft will expire on June 26, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Failover Concepts and Mechanisms . . . . . . . . . . . . . . 7 4. Failover Concepts and Mechanisms . . . . . . . . . . . . . . 8
4.1. Required Server Configuration . . . . . . . . . . . . . . 7 4.1. Required Server Configuration . . . . . . . . . . . . . . 8
4.2. IPv6 Address and Delegable Prefix Allocation . . . . . . 8 4.2. IPv6 Address and Delegable Prefix Allocation . . . . . . 9
4.2.1. Independent Allocation . . . . . . . . . . . . . . . 8 4.2.1. Independent Allocation . . . . . . . . . . . . . . . 9
4.2.2. Proportional Allocation . . . . . . . . . . . . . . . 9 4.2.2. Proportional Allocation . . . . . . . . . . . . . . . 10
4.3. Lazy Updates . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Lazy Updates . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Maximum Client Lead Time (MCLT) . . . . . . . . . . . . . 12 4.4. Maximum Client Lead Time (MCLT) . . . . . . . . . . . . . 13
4.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . 13 4.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . 14
5. Message and Option Definitions . . . . . . . . . . . . . . . 14 5. Message and Option Definitions . . . . . . . . . . . . . . . 16
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 15 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 16
5.2. Failover Message Format . . . . . . . . . . . . . . . . . 15 5.2. Failover Message Format . . . . . . . . . . . . . . . . . 16
5.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. BNDUPD . . . . . . . . . . . . . . . . . . . . . . . 16 5.3.1. BNDUPD . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.2. BNDACK . . . . . . . . . . . . . . . . . . . . . . . 16 5.3.2. BNDACK . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.3. POOLREQ . . . . . . . . . . . . . . . . . . . . . . . 16 5.3.3. POOLREQ . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.4. POOLRESP . . . . . . . . . . . . . . . . . . . . . . 16 5.3.4. POOLRESP . . . . . . . . . . . . . . . . . . . . . . 18
5.3.5. UPDREQ . . . . . . . . . . . . . . . . . . . . . . . 16 5.3.5. UPDREQ . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.6. UPDREQALL . . . . . . . . . . . . . . . . . . . . . . 16 5.3.6. UPDREQALL . . . . . . . . . . . . . . . . . . . . . . 18
5.3.7. UPDDONE . . . . . . . . . . . . . . . . . . . . . . . 17 5.3.7. UPDDONE . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.8. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 17 5.3.8. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.9. CONNECTACK . . . . . . . . . . . . . . . . . . . . . 17 5.3.9. CONNECTACK . . . . . . . . . . . . . . . . . . . . . 19
5.3.10. DISCONNECT . . . . . . . . . . . . . . . . . . . . . 17 5.3.10. DISCONNECT . . . . . . . . . . . . . . . . . . . . . 19
5.3.11. STATE . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3.11. STATE . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.12. CONTACT . . . . . . . . . . . . . . . . . . . . . . . 17 5.3.12. CONTACT . . . . . . . . . . . . . . . . . . . . . . . 19
5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4.1. OPTION_F_BINDING_STATUS . . . . . . . . . . . . . . . 18 5.4.1. OPTION_F_BINDING_STATUS . . . . . . . . . . . . . . . 20
5.4.2. OPTION_F_DNS_REMOVAL_INFO . . . . . . . . . . . . . . 19 5.4.2. OPTION_F_CONNECT_FLAGS . . . . . . . . . . . . . . . 20
5.4.3. OPTION_F_DNS_HOST_NAME . . . . . . . . . . . . . . . 19 5.4.3. OPTION_F_DNS_REMOVAL_INFO . . . . . . . . . . . . . . 21
5.4.4. OPTION_F_DNS_ZONE_NAME . . . . . . . . . . . . . . . 20 5.4.4. OPTION_F_DNS_HOST_NAME . . . . . . . . . . . . . . . 22
5.4.5. OPTION_F_DNS_FLAGS . . . . . . . . . . . . . . . . . 21 5.4.5. OPTION_F_DNS_ZONE_NAME . . . . . . . . . . . . . . . 22
5.4.6. OPTION_F_EXPIRATION_TIME . . . . . . . . . . . . . . 21 5.4.6. OPTION_F_DNS_FLAGS . . . . . . . . . . . . . . . . . 23
5.4.7. OPTION_F_MAX_UNACKED_BNDUPD . . . . . . . . . . . . . 22 5.4.7. OPTION_F_EXPIRATION_TIME . . . . . . . . . . . . . . 24
5.4.8. OPTION_F_MCLT . . . . . . . . . . . . . . . . . . . . 23 5.4.8. OPTION_F_MAX_UNACKED_BNDUPD . . . . . . . . . . . . . 25
5.4.9. OPTION_F_PARTNER_LIFETIME . . . . . . . . . . . . . . 23 5.4.9. OPTION_F_MCLT . . . . . . . . . . . . . . . . . . . . 25
5.4.10. OPTION_F_PARTNER_LIFETIME_SENT . . . . . . . . . . . 24 5.4.10. OPTION_F_PARTNER_LIFETIME . . . . . . . . . . . . . . 26
5.4.11. OPTION_F_PARTNER_DOWN_TIME . . . . . . . . . . . . . 24 5.4.11. OPTION_F_PARTNER_LIFETIME_SENT . . . . . . . . . . . 26
5.4.12. OPTION_F_PARTNER_RAW_CLT_TIME . . . . . . . . . . . . 25 5.4.12. OPTION_F_PARTNER_DOWN_TIME . . . . . . . . . . . . . 27
5.4.13. OPTION_F_PROTOCOL_VERSION . . . . . . . . . . . . . . 25 5.4.13. OPTION_F_PARTNER_RAW_CLT_TIME . . . . . . . . . . . . 28
5.4.14. OPTION_F_RECEIVE_TIME . . . . . . . . . . . . . . . . 26 5.4.14. OPTION_F_PROTOCOL_VERSION . . . . . . . . . . . . . . 28
5.4.15. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 26 5.4.15. OPTION_F_RECEIVE_TIME . . . . . . . . . . . . . . . . 29
5.4.16. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 27 5.4.16. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 29
5.4.17. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 28 5.4.17. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 30
5.4.18. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 29 5.4.18. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 31
5.4.19. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 30 5.4.19. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 32
5.4.20. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 31 5.4.20. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 33
5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 31 5.4.21. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 34
6. Connection Management . . . . . . . . . . . . . . . . . . . . 32 5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 35
6.1. Creating Connections . . . . . . . . . . . . . . . . . . 32 6. Connection Management . . . . . . . . . . . . . . . . . . . . 36
6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 33 6.1. Creating Connections . . . . . . . . . . . . . . . . . . 36
6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 33 6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 37
6.1.3. Receiving a CONNECTACK message . . . . . . . . . . . 34 6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 37
6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 35 6.1.3. Receiving a CONNECTACK message . . . . . . . . . . . 38
6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 35 6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 39
6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 36 6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 40
6.5. Connection Maintenance Parameters . . . . . . . . . . . . 37 6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 40
6.6. Unreachability detection . . . . . . . . . . . . . . . . 37 6.5. Connection Maintenance Parameters . . . . . . . . . . . . 41
7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 38 6.6. Unreachability detection . . . . . . . . . . . . . . . . 42
7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 38 7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 42
7.2. Information model . . . . . . . . . . . . . . . . . . . . 38 7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 42
7.3. Times Required for Exchanging Binding Updates . . . . . . 42 7.2. Information model . . . . . . . . . . . . . . . . . . . . 43
7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 43 7.3. Times Required for Exchanging Binding Updates . . . . . . 46
7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 45 7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 47
7.5.1. Correcting Time Skew . . . . . . . . . . . . . . . . 45 7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 50
7.5.2. Processing Binding Updates . . . . . . . . . . . . . 46 7.5.1. Monitoring Time Skew . . . . . . . . . . . . . . . . 50
7.5.3. Accept or Reject? . . . . . . . . . . . . . . . . . . 47 7.5.2. Acknowledging Reception . . . . . . . . . . . . . . . 50
7.5.4. Accepting Updates . . . . . . . . . . . . . . . . . . 48 7.5.3. Processing Binding Updates . . . . . . . . . . . . . 51
7.6. Sending Binding Acks . . . . . . . . . . . . . . . . . . 49 7.5.4. Accept or Reject? . . . . . . . . . . . . . . . . . . 51
7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 50 7.5.5. Accepting Updates . . . . . . . . . . . . . . . . . . 53
7.8. Acknowledging Reception . . . . . . . . . . . . . . . . . 51 7.6. Sending Binding Acks . . . . . . . . . . . . . . . . . . 54
7.9. BNDUPD/BNDACK Data Flow . . . . . . . . . . . . . . . . . 51 7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 57
8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 52 7.8. BNDUPD/BNDACK Data Flow . . . . . . . . . . . . . . . . . 58
8.1. State Machine Operation . . . . . . . . . . . . . . . . . 52 8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 59
8.2. State Machine Initialization . . . . . . . . . . . . . . 55 8.1. State Machine Operation . . . . . . . . . . . . . . . . . 59
8.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 55 8.2. State Machine Initialization . . . . . . . . . . . . . . 62
8.3.1. Operation in STARTUP State . . . . . . . . . . . . . 56 8.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 62
8.3.2. Transition Out of STARTUP State . . . . . . . . . . . 56 8.3.1. Operation in STARTUP State . . . . . . . . . . . . . 63
8.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 58 8.3.2. Transition Out of STARTUP State . . . . . . . . . . . 63
8.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 58 8.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 65
8.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 59 8.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 65
8.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 59 8.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 66
8.5.1. Operation in RECOVER State . . . . . . . . . . . . . 60 8.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 66
8.5.2. Transition Out of RECOVER State . . . . . . . . . . . 60 8.5.1. Operation in RECOVER State . . . . . . . . . . . . . 67
8.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 61 8.5.2. Transition Out of RECOVER State . . . . . . . . . . . 67
8.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 62 8.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 68
8.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 62 8.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 69
8.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 62 8.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 69
8.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 62 8.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 69
8.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 63 8.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 69
8.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 63 8.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 70
8.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 63 8.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 70
8.8.2. Transition Out of NORMAL State . . . . . . . . . . . 64 8.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 70
8.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 65 8.8.2. Transition Out of NORMAL State . . . . . . . . . . . 71
8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 65 8.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 72
8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 66 8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 72
8.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 67 8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 73
8.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 68 8.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 74
8.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 68 8.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 75
8.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 69 8.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 75
8.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 70 8.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 76
8.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 70 8.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 77
8.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 70 8.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 77
8.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 71 8.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 77
8.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 71 8.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 78
9. Dynamic DNS Considerations . . . . . . . . . . . . . . . . . 71 8.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 78
9.1. Relationship between failover and dynamic DNS update . . 72 9. DNS Update Considerations . . . . . . . . . . . . . . . . . . 78
9.2. Exchanging DDNS Information . . . . . . . . . . . . . . . 73 9.1. Relationship between failover and DNS update . . . . . . 79
9.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . . 74 9.2. Exchanging DNS Update Information . . . . . . . . . . . . 80
9.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . . 75 9.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . . 82
9.5. Name Assignment with No Update of DNS . . . . . . . . . . 76 9.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . . 82
10. Security Considerations . . . . . . . . . . . . . . . . . . . 76 9.5. Name Assignment with No Update of DNS . . . . . . . . . . 83
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 83
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 79 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 86
13.1. Normative References . . . . . . . . . . . . . . . . . . 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 86
13.2. Informative References . . . . . . . . . . . . . . . . . 80 13.1. Normative References . . . . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 13.2. Informative References . . . . . . . . . . . . . . . . . 88
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88
1. Requirements Language 1. Introduction
The failover protocol provides a means for cooperating DHCP servers
to work together to provide a DHCP service with availability that is
increased beyond that which could be provided by a single DHCP server
operating alone. It is designed to protect DHCP clients against
server unreachability, including server failure and network
partition. It is possible to deploy exactly two servers that are
able to continue providing a lease for an IPv6 address [RFC3315] or
on an IPv6 prefix [RFC3633] without the DHCP client experiencing
lease expiration or a reassignment of a lease to a different IPv6
address or prefix in the event of failure by one or the other of the
two servers.
This protocol defines an active-passive mode, sometimes also called a
hot standby model. This means that during normal operation one
server is active (i.e. actively responds to clients' requests) while
the second is passive (i.e. it receives clients' requests, but
responds only to those specifically directed to it). The secondary
maintains a copy of the binding database and is ready to take over
all incoming queries in case of primary server failure.
The failover protocol is designed to provide lease stability for
leases with valid lifetimes beyond a short period. The DHCPv6
Failover protocol MUST NOT be used for leases shorter than 30
seconds.
This protocol fulfills all DHCPv6 failover requirements defined in
[RFC7031].
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Glossary 3. Glossary
This is a supplemental glossary that should be combined with This is a supplemental glossary that should be combined with
definitions in Section 3 of RFC 7031 [RFC7031]. definitions in Section 3 of RFC 7031 [RFC7031].
o Absolute Time o Absolute Time
The time in seconds since midnight January 1, 2000 UTC, modulo The time in seconds since midnight January 1, 2000 UTC, modulo
2^32). 2^32).
o Address Lease
A lease involving an IPv6 address. Typically used when it is
necessary to distinguish the lease for an IPv6 address from a
lease for a DHCP prefix. See "delegated prefix" and "prefix
lease".
o auto-partner-down o auto-partner-down
A capability where a failover server will move from A capability where a failover server will move from
COMMUNICATIONS-INTERRUPTED state to PARTNER-DOWN state COMMUNICATIONS-INTERRUPTED state to PARTNER-DOWN state
automatically, without operator intervention. automatically, without operator intervention.
o DDNS o Available (Lease or Prefix)
Dynamic DNS. Typically used as an acronym referring to dynamic A lease or delegable prefix is available if it could be allocated
update of the DNS. 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
is in the BACKUP state. Sometimes the term "available" is used
when it would be awkward to say "FREE on the primary server and
BACKUP on the secondary server".
o Binding Status
A lease can hold a variety of states (see Section 5.4.1 for a
list) and these are also referred to as the binding-status of the
lease.
o Delegable Prefix o Delegable Prefix
A prefix from which other prefixes may be delegated, as described A prefix from which other prefixes may be delegated, as described
in [RFC3633]. in [RFC3633]. A prefix which has been delegated is known as a
"delegated prefix" or a "prefix lease".
o Delegated Prefix
A prefix which has been deletegated to a DHCP client as described
in [RFC3633]. Depending on the context, a delegated prefix may
also be described as a "prefix lease", when it is necessary to
distinguish it from an "address lease".
o Failover endpoint o Failover endpoint
The failover protocol allows for there to be a unique failover The failover protocol allows for there to be a unique failover
'endpoint' for each failover relationship in which a failover 'endpoint' for each failover relationship in which a failover
server participates. The failover relationship is defined by a server participates. The failover relationship is defined by a
relationship name, and includes the failover partner IP address, relationship name, and includes the failover partner IP address,
the role this server takes with respect to that partner (primary the role this server takes with respect to that partner (primary
or secondary), and the prefixes associated with that relationship. or secondary), and the prefixes from which addresses can be leased
The failover endpoint can take actions and hold unique states. as well as prefixes from which other prefixes can be delegated
(delegable prefixes), 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. All messages exchanged between partners.
o Independent Allocation o Independent Allocation
An allocation algorithm that splits the available pool of An allocation algorithm that splits the available pool of address
resources between the primary and secondary servers that is leases between the primary and secondary servers. It is used for
particularly well suited for vast pools (i.e. when available IPv6 address allocations. See Section 4.2.1.
resources are not expected to deplete). 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
An association of a DHCPv6 client with an IPv6 address or prefix. This might refer to either an existing association or a
delegated prefix. potential association.
o MCLT o MCLT
Maximum Client Lead Time. The fundamental relationship on which Maximum Client Lead Time. The fundamental relationship on which
much of the correctness of this protocol depends is that the lease much of the correctness of this protocol depends is that the lease
expiration time known to a DHCPv6 client MUST NOT be greater by expiration time known to a DHCP client MUST NOT be greater by more
more than the MCLT beyond the partner lifetime time acknowledged than the MCLT beyond the later of the partner lifetime time
by that servers's failover partner. See Section 4.4. acknowledged by that server's failover partner or the current time
(i.e., now). See Section 4.4.
o Partner o Partner
Name of the other DHCPv6 server that participates in failover The other DHCP server that participates in a failover
relationship. When the role (primary or secondary) is not relationship. When the role (primary or secondary) is not
important, the other server is referred to as a "failover partner" important, the other server is referred to as a "failover partner"
or somtimes simply "partner". or sometimes simply "partner".
o Prefix Lease
A lease involving a prefix that is or could be delegated, as
opposed to a lease for a single IPv6 address. A prefix lease can
also be described as a "delegated prefix".
o Primary Server o Primary Server
First out of two DHCPv6 servers that participate in a failover First out of two DHCP servers that participate in a failover
relationship. When both servers are operating this server handles relationship. When both servers are operating this server handles
most of the client traffic. Its failover partner is referred to most of the client traffic. Its failover partner is referred to
as secondary server. as secondary server.
o Proportional Allocation o Proportional Allocation
An allocation algorithm that splits the available resources An allocation algorithm that splits the delegable prefixes between
between the primary and secondary servers and maintains a more or the primary and secondary servers and maintains a more or less
less fixed proportion of the available resources between both fixed proportion of the delegable prefixes between both servers.
servers. It is particularly well suited for more limited
resources. It is used for allocations of delegated prefixes. See
Section 4.2.2. Section 4.2.2.
o Resource o Renew Responsive
Any type of resource that is managed by DHCPv6. Currently there A server that is renew responsive will respond to DHCP client
are three types of such resources defined: a non-temporary IPv6 requests that are directed to it by having an OPTION_SERVERID
address, a temporary IPv6 address, and an IPv6 delegated prefix. option in the message which contains the DUID of the renew
Only the non-temporary IPv6 addresses and IPv6 delegated prefixes responsive server. See [RFC3315].
are involved in DHCPv6 failover.
o Responsive o Responsive
A server that is responsive will respond to all DHCP client
A server that is responsive will respond to DHCPv6 client
requests. requests.
o Secondary Server o Secondary Server
Second of two DHCPv6 servers that participate in a failover Second of two DHCP servers that participate in a failover
relationship. Its failover partner is referred to as the primary relationship. Its failover partner is referred to as the primary
server. When both servers are operating this server (the server. When both servers are operating this server (the
secondary) typically does not handle client traffic and acts as a secondary) typically does not handle client traffic and acts as a
backup to the primary server. backup to the primary server. It will respond, however, to RENEW
requests directed specifically to it.
o Server o Server
A DHCPv6 server that implements DHCPv6 failover. 'Server' and
A DHCP server that implements DHCPv6 failover. 'Server' and
'failover endpoint' are synonymous only if the server participates 'failover endpoint' are synonymous only if the server participates
in only one failover relationship. in only one failover relationship.
o Unresponsive o State
A server that is unresponsive will not respond to DHCPv6 client
requests.
3. Introduction 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
that a failover endpoint can move through. See Section 8 for
details of the failover endpoint states. A lease also has a
state, and this is sometimes referred to as a binding-status. See
Section 5.4.1 for a list of the states a lease can hold.
The failover protocol provides a means for cooperating DHCPv6 servers o Time Context
to work together to provide a DHCPv6 service with availability that
is increased beyond that which could be provided by a single DHCPv6
server operating alone. It is designed to protect DHCPv6 clients
against server unreachability, including server failure and network
partition. It is possible to deploy exactly two servers that are
able to continue providing a lease on an IPv6 address [RFC3315] or on
an IPv6 prefix [RFC3633] without the DHCPv6 client experiencing lease
expiration or a reassignment of a lease to a different IPv6 address
(or prefix) in the event of failure by one or the other of the two
servers.
This protocol defines an active-passive mode, sometimes also called a Each failover server has a clock and a definite idea of the
hot standby model. This means that during normal operation one current universal time. Each server's idea of the current time is
server is active (i.e. actively responds to clients' requests) while considered its time context.
the second is passive (i.e. it receives clients' requests, but does
not respond to them and only maintains a copy on the binding database
and is ready to take over incoming queries in case of primary server
failure).
The failover protocol is designed to provide lease stability for o Unresponsive
leases with lease times beyond a short period. Due in part to the
additional overhead required as well as requirements to handle time
skew between failover partners (See Section 7.1) failover is not
suitable for leases shorter than 30 seconds. The DHCPv6 Failover
protocol MUST NOT be used for leases shorter than 30 seconds.
This protocol fulfills all DHCPv6 failover requirements defined in A server that is unresponsive will not respond to DHCP client
[RFC7031]. requests.
4. Failover Concepts and Mechanisms 4. Failover Concepts and Mechanisms
4.1. Required Server Configuration 4.1. Required Server Configuration
Servers frequently have several kinds of resources 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 primary and secondary servers are configured identically with regard
to the prefixes and links involved in DHCPv6. For delegated prefixes to the prefixes and links involved in DHCP. For delegated prefixes
(involved in proportional allocation) the primary server is (involved in proportional allocation) the primary server is
responsible for allocating to the secondary server the correct responsible for allocating to the secondary server the correct
proportion of the available delegated prefixes. IPv6 addresses proportion of the available delegated prefixes. IPv6 addresses
(involved in independent allocation) are allocated to the primary and (involved in independent allocation) are allocated to the primary and
secondary servers algorithmically, and do not require an explicit secondary servers algorithmically, and do not require an explicit
message transfer to be distributed. 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 for resources Currently there are two allocation algorithms defined, one for
(IPv6 addresses or delegable prefixes). 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 DHCPv6 IPv6 In this allocation scheme, used for allocating individual DHCP IPv6
addresses, available IPv6 addresses are permanently (until server addresses, available IPv6 addresses are permanently (until server
configuration changes) split between servers. Available IPv6 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 a message exchange for each IPv6 address allocated. This require a message exchange for each server to know which IPv6
algorithm is simpler than proportional allocation since it does not addresses it has been allocated. This algorithm is simpler than
require a rebalancing mechanism. It assumes that the pool assigned proportional allocation since it does not require a rebalancing
to each server will never deplete. mechanism. It also assumes that the pool assigned to each server
will never deplete.
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 resource or its lease on an to clients. Once a client releases a lease or its lease on an IPv6
IPv6 address expires, the returned IPv6 address returns to the pool address expires, the returned IPv6 address returns to the pool for
for the server that leased it. A lease on an IPv6 address can be the server that leased it. A lease on an IPv6 address can be renewed
renewed by any responsive server. When an IPv6 address goes FREE* it by a responsive server or by a renew responsive server. When an IPv6
is owned by whichever server it is allocated to by the independent address goes PENDING-FREE Section 7.2 it is owned by whichever server
allocation algorithm. 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) are
ignored when a server processes a POOLREQ message. ignored when a server processes a POOLREQ message.
During COMMUNICATION-INTERRUPTED events, a partner MAY continue During COMMUNICATION-INTERRUPTED events, a partner MAY continue
extending existing leases when requested by clients. A healthy extending existing address leases as requested by clients. An
partner MUST NOT lease IPv6 addresses that were assigned to its operational partner MUST NOT lease IPv6 addresses that were assigned
downed partner and later released by a client unless it is in to its downed partner and later expired or were released or declined
PARTNER-DOWN state. When it is in PARTNER-DOWN state, a server by a client unless it is in PARTNER-DOWN state. When it is in
SHOULD use its own pool first and then it can start making new PARTNER-DOWN state, a server SHOULD allocate from its own pool. It
assignments from its downed partner's pool. SHOULD NOT use its partner's pool.
4.2.1.1. Independent Allocation Algorithm 4.2.1.1. Independent Allocation Algorithm
For every prefix from which IPv6 addresses can be allocated, the For each address that can be allocated, the primary server MUST
primary server MUST allocate only IPv6 addresses when the low-order allocate only IPv6 addresses when the low-order bit (i.e., bit 127)
bit (i.e., bit 15) is equal to 1, and the secondary server MUST is equal to 1, and the secondary server MUST allocate only the IPv6
allocate only the IPv6 addresses when the low-order bit (i.e., bit addresses when the low-order bit (i.e., bit 127) is equal to 0.
15) 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. Remaining available delegeable prefixes available for delegation, known as "delegable prefixes". These
are split between the primary and secondary servers in a configured delegable prefixes may be prefixes from which other prefixes can be
proportion. Note that a delegable prefix is not "owned" by a delegated or they may be prefixes which are the correct size for
particular server throughout its entire lifetime. Only a delegable delegation but are not, at present, delegated to a particular client.
prefix which is available is "owned" by a particular server -- once Remaining delegable prefixes are split between the primary and
it has been leased to a client, it is not owned by either failover secondary servers in a configured proportion. Note that a delegated
prefix (also known as a prefix lease) is not "owned" by a particular
server. Only a delegable prefix which is available is "owned" by a
particular server -- once it has been delegated (leased) to a client
it becomes a prefix lease and is not owned by either failover
partner. When it finally becomes available again, it will be owned partner. When it finally becomes available again, it will be owned
initially by the primary server, and it may or may not be allocated initially by the primary server, and it may or may not be allocated
to the secondary server by the primary server. to the secondary server by the primary server.
The flow of a delegable prefix is as follows: initially a delegable The flow of a delegable prefix is as follows: initially the delegable
prefix is owned by the primary server. It may be allocated to the prefix is part of a larger delegable prefix, all of which are
secondary server if it is available, and then it is owned by the initially owned by the primary server. A delegable prefix may be
secondary server. Either server can allocate available delegable allocated to the secondary server and then it is owned by the
prefixes which they own to clients, in which case they cease to own secondary server. Either server can allocate and delegate prefixes
them. When the client releases the delegated prefix or the lease on out of the delegable prefixes which they own. Once these prefixes
it expires, it will again become available and will be owned by the are delegated (leased) to clients, the servers cease to own them and
primary. they are owned by the clients to which they have been delegated
(leased). When the client releases the delegated prefix or the lease
on it expires, it will again become available and will then be a
delegable prefix and be owned by the primary.
Pools governed by proportional allocation are used for allocation A server delegates prefixes only from its own pool of delegable
when the server is in all states, except PARTNER-DOWN. In PARTNER- prefixes in all states except for PARTNER-DOWN. In PARTNER-DOWN
DOWN state the operational partner can allocate 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 allocation and maintenance of these address pools is elapsed). The operational partner SHOULD allocate from its own pool
important, since the goal is to maintain a more or less constant before using its partner's pool. The allocation and maintenance of
ratio of available addresses between the two servers. these pools of delegable prefixes is important, since the goal is to
maintain a more or less constant ratio of delegable prefixes between
the two servers.
The initial allocation when the servers first integrate is triggered The initial allocation of delegable prefixes from the primary to the
by the POOLREQ message from the secondary to the primary. This is secondary when the servers first integrate is triggered by the
followed (at some point) by the POOLRESP message where the primary POOLREQ message from the secondary to the primary. This is followed
tells the secondary that it received and processed the POOLREQ (at some point) by the POOLRESP message where the primary tells the
message. The primary sends the allocated delegable prefixes to the secondary that it received and processed the POOLREQ message. The
secondary via BNDUPD messages. The POOLRESP message may be sent primary sends the allocated delegable prefixes to the secondary as
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 using the BNDUPD The delegable prefixes are sent to the secondary as prefix leases
message with a state of FREE_BACKUP, which indicates the delegable using the BNDUPD message containing an OPTION_IAPREFIX with a state
prefix is now available for allocation by the secondary. Once the of FREE-BACKUP, which indicates the prefix lease is now available for
message is sent, the primary MUST NOT use these prefixes for allocation by the secondary. Once the message is sent, the primary
allocation to DHCPv6 clients. MUST NOT use these prefixes for allocation to DHCP 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 prefixes and determine if the secondary needs more database of delegable prefixes and determine if the secondary needs
delegable prefixes from any of the delegable prefixes which it more delegable prefixes from any of the delegable prefixes which it
currently owns. currently owns.
In order to support a reasonably dynamic balance of the resources 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 it
needs). 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 available prefixes for either the primary or secondary the number of possibly delegable prefixes for either the primary or
changes by more than a configured limit. The primary server SHOULD secondary changes by more than a predetermined amount. Typically
adjust the delegable prefix balance as required to ensure the this comparison would not involve actually comparing the count of
configured delegable prefix balance, excepting that the primary existing instances of delegable prefixes, but would instead involve
server SHOULD employ some threshold mechanism to such a balance determining the number prefixes that could be delegated given the
adjustment in order to minimize the overhead of maintaining this address ranges of the delegable prefixes allocated to each server.
balance. The primary server SHOULD adjust the delegable prefix balance as
required to ensure the configured delegable prefix balance, excepting
An example of a threshold approach is: do not attempt to re-balance that the primary server SHOULD employ some threshold mechanism to
the prefixes on the primary and secondary until the out of balance such a balance adjustment in order to minimize the overhead of
value exceeds a configured value. 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 with the state FREE-BACKUP.
The primary server can attempt to take an available delegable prefix The primary server can attempt to take an available delegable prefix
away from the secondary by sending a BNDUPD with the state FREE. If away from the secondary by sending a BNDUPD with the state FREE. If
the secondary accepts the BNDUPD, then the resource is now available the secondary accepts the BNDUPD, then the lease is now available to
to the primary and not available to the secondary. Of course, the the primary and not available to the secondary. Of course, the
secondary MUST reject that BNDUPD if it has already used that secondary MUST reject that BNDUPD if it has already allocated that
resource for a DHCPv6 client. lease to a DHCP client.
4.2.2.1. Re-allocating Leases 4.2.2.1. Re-allocating Leases
When in PARTNER-DOWN state there is a waiting period after which a When in PARTNER-DOWN state there is a waiting period after which a
delegated prefix can be re-allocated to another client. For delegated prefix can be re-allocated to another client. For
delegable prefixes which are available when the server enters delegable prefixes which 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 which 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), and the expiration-time. If this time the partner-lifetime (if any), the expiration-time, and the entry to
would be earlier than the current time plus the MCLT, then the time PARTNER-DOWN time plus the MCLT.
the server entered PARTNER-DOWN state plus the maximum-client-lead-
time is used.
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
BNDACK message) that its partner is aware that the first client is BNDACK message) that its partner is aware that the first client is
not using the resource. not using the lease.
This may be modeled in the following way.
An "available" delegable prefix on a server may be allocated to any Specifically, an "available" delegable prefix on a server may be
client. A prefix which was delegated (leased) to a client and which allocated to any client. A prefix which was delegated (leased) to a
expired or was released by that client would take on a new state, client and which expired or was released by that client would take on
EXPIRED or RELEASED respectively. The partner server would then be a new state, EXPIRED or RELEASED respectively. The partner server
notified that this delegated prefix was EXPIRED or RELEASED through a would then be notified that this delegated prefix was EXPIRED or
BNDUPD. When the sending server received the BNDACK for that RELEASED through a BNDUPD. When the sending server received the
delegated prefix showing it was FREE, it would move the resource from BNDACK for that delegated prefix showing it was FREE, it would move
EXPIRED or RELEASED to FREE, and it would be available for allocation the lease from EXPIRED or RELEASED to FREE, and it would be available
by the primary server to any clients. 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 to its partner. This situation would exist if sent a BNDUPD message regarding the delegated prefix to its partner.
the lease expired or was released after the transition into PARTNER- This situation would exist if the prefix lease expired or was
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 The DHCPv6 Failover Requirements document includes the requirement
that failover must not introduce significant performance impact on that failover must not introduce significant performance impact on
server response times (See Sections 7 and 5.2.2 of [RFC7031] ). In server response times (see Sections 7 and 5.2.2 of [RFC7031] ). In
order to realize this requirement a server implementing the failover order to realize this requirement a server implementing the failover
protocol must be able respond to a DHCPv6 client without waiting to protocol must be able respond to a DHCP client without waiting to
update its failover partner whenever the binding database changes. update its failover partner whenever the binding database changes.
The lazy update mechanism allows a server to allocate a new lease or The lazy update mechanism allows a server to allocate a new lease or
extend an existing lease, respond to the DHCPv6 client, and then extend an existing lease, respond to the DHCP client, and then update
update its failover partner as time permits. its 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 DHCPv6 client with a particular lease time and before updating a DHCP client with a particular valid lifetime and 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 DHCPv6 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 of the resource to the DHCPv6 client. Both of these issues the lease to the DHCP client. Both of these issues are dealt with by
are dealt with by use of the MCLT when allocating or extending leases use of the MCLT when allocating or extending leases (see
(see Section 4.4). 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 and
secondary servers. Proper use of this time interval places an upper secondary servers. Proper use of this time interval places an upper
bound on the difference allowed between the lease time provided to a bound on the difference allowed between the valid lifetime provided
DHCPv6 client by a server and the lease time known by that server's to a DHCP client by a server and the valid lifetime known by that
failover partner. server's failover partner.
The MCLT is typically much less than the lease time that a server has The MCLT is typically much less than the valid lifetime that a server
been configured to offer a client, and so some strategy must exist to has been configured to offer a client, and so some strategy must
allow a server to offer the configured lease time to a client. exist to allow a server to offer the configured valid lifetime to a
During a lazy update the updating server updates its failover partner client. During a lazy update the updating server updates its
with a partner lifetime which is longer than the lease time failover partner with a partner lifetime which is longer than the
previously given to the DHCPv6 client and which is longer than the valid lifetime previously given to the DHCP client and which is
lease time that the server has been configured to give a client. longer than the valid lifetime that the server has been configured to
This allows the server to give the configured lease time to the give a client. This allows the server to give the configured valid
client the next time the client renews its lease, since the time that lifetime to the client the next time the client renews its lease,
it will give to the client will not be longer than the MCLT beyond since the time that it will give to the client will not be longer
the partner lifetime acknowledged by its partner. than the MCLT beyond the partner lifetime acknowledged by its partner
or the current time.
The fundamental relationship on which this protocol depends is: the The fundamental relationship on which this protocol depends is: the
lease expiration time known to a DHCPv6 client MUST NOT be greater by lease expiration time known to a DHCP client MUST NOT be greater by
more than the MCLT beyond the partner lifetime acknowledged by that more than the MCLT beyond the later of the partner lifetime
server's failover partner. acknowledged by that server's failover partner and 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.
This protocol requires a DHCPv6 server to deal with several different This protocol requires a DHCP server to deal with several different
lease intervals and places specific restrictions on their 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
other server in the pair to be able to make certain assumptions in partner to be able to make certain assumptions in the absence of an
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:
desired lifetime: desired lifetime:
The desired lifetime is the lease interval that a DHCPv6 server The desired lifetime is the lease interval that a DHCP server
would like to give to a DHCPv6 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 this protocol. Typically this is the is outside of the scope of this protocol. Typically this is the
result of external configuration of a DHCPv6 server. result of external configuration of a DHCP server.
actual lifetime: actual lifetime:
The actual lifetime is the lease interval that a DHCPv6 server The actual lifetime is the lease interval that a DHCP server gives
gives out to a DHCPv6 client. It may be shorter than the desired out to a DHCP client. It may be shorter than the desired lifetime
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 tells 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 BNDACK message. partner server has most recently acknowledged in a BNDACK 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
DHCPv6 client, it determines the desired lifetime (in this case, 3 DHCP client, it determines the desired lifetime (in this case, 3
days). It then examines the acknowledged partner lifetime (which in days). It then examines the acknowledged partner lifetime (which in
this case is zero) and determines the remainder of the time left to this case is zero) and determines the remainder of the time left to
run, which is also zero. It adds the MCLT to this value. Since the run, which is also zero. It adds the MCLT to this value. Since the
actual lifetime cannot be allowed to exceed the remainder of 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 DHCPv6 client, it will Once the server has sent the REPLY to the DHCP client, it will update
update its failover partner with the lease information using a BNDUPD its failover partner with the lease information using a BNDUPD
message. However, the desired partner lifetime will be composed of message. However, the desired partner lifetime will be composed of
one half of the current actual lifetime added to the desired one half of the current actual lifetime added to the desired
lifetime. Thus, the failover partner is updated with a BNDUPD with a lifetime. Thus, the failover partner is updated with a BNDUPD with a
partner lifetime of 1/2 hour + 3 days. partner lifetime of 1/2 hour + 3 days.
When the primary server receives a BNDACK to its update of the When the primary server receives a BNDACK to its update of the
secondary server's (partner's) 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 BNDACK the acknowledged partner lifetime. A server MUST NOT send a BNDACK
in response to a BNDUPD message until it is sure that the information in response to a BNDUPD message until it is sure that the information
in the BNDUPD message has been updated in its lease database. See in the BNDUPD message has been updated in its lease database. See
Section 7.8. Thus, the primary server in this case can be sure that Section 7.5.2. Thus, the primary server in this case can be sure
the secondary server has recorded the parnter lease interval in its that the secondary server has recorded the partner lease interval in
stable storage when the primary server receives a BNDACK message from its stable storage when the primary server receives a BNDACK message
the secondary server. from the secondary server.
When the DHCPv6 client attempts to renew at T1 (approximately one When the DHCP client attempts to renew at T1 (approximately one half
half an hour from the start of the lease), the primary server again an hour from the start of the lease), the primary server again
determines the desired lifetime, which is still 3 days. It then determines the desired lifetime, which is still 3 days. It then
compares this with the original acknowledged partner lifetime (1/2 compares this with the original acknowledged partner lifetime (1/2
hour + 3 days) and adjusts for the time passed since the secondary hour + 3 days) and adjusts for the time passed since the secondary
was last updated (1/2 hour). Thus the time remaining of the was last updated (1/2 hour). Thus the time remaining of the
acknowledged partner interval is 3 days. Adding the MCLT to this acknowledged partner interval is 3 days. Adding the MCLT to this
yields 3 days plus 1 hour, which is more than the desired lifetime of yields 3 days plus 1 hour, which is more than the desired lifetime of
3 days. So the client may have its lease renewed for the desired 3 days. So the client may have its lease renewed for the desired
lifetime -- 3 days. lifetime -- 3 days.
When the primary DHCPv6 server updates the secondary DHCPv6 server When the primary DHCP server updates the secondary DHCP server after
after the DHCPv6 client's renewal REPLY is complete, it will the DHCP client's renewal REPLY is complete, it will calculate the
calculate the desired partner lifetime as the T1 fraction of the desired partner lifetime as the T1 fraction of the actual client
actual client lifetime (1/2 of 3 days this time = 1.5 days). To this lifetime (1/2 of 3 days this time = 1.5 days). To this it will add
it will add the desired client lifetime of 3 days, yielding a total the desired client lifetime of 3 days, yielding a total desired
desired partner lifetime of 4.5 days. In this way, the primary partner lifetime of 4.5 days. In this way, the primary attempts to
attempts to have the secondary always "lead" the client in its have the secondary always "lead" the client in its understanding of
understanding of the client's lifetime so as to be able to always the client's lifetime so as to be able to always offer the client the
offer the client the desired client lifetime. desired client lifetime.
Once the initial actual client lifetime of the MCLT is past, the Once the initial actual client lifetime of the MCLT is past, the
protocol operates effectively like the DHCPv6 protocol does today in protocol operates effectively like the DHCP protocol does today in
its behavior concerning lifetimes. However, the guarantee that the its behavior concerning lifetimes. However, the guarantee that the
actual client lifetime will never exceed the remaining acknowledged actual client lifetime will never exceed the remaining acknowledged
partner server partner lifetime by more than the MCLT allows full partner server partner lifetime by more than the MCLT allows full
recovery from a variety of DHCPv6 server failures. recovery from a variety of DHCP server failures.
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 protocol uses the framing format specified
in Section 5.1 of DHCPv6 Bulk Leasequery [RFC5460], but uses in Section 5.1 of DHCPv6 Bulk Leasequery [RFC5460], but uses
different message types with a different message format, described in different message types with a different message format, described in
Section 5.2. All information is sent over the connection as typical Section 5.2. The TCP connection between failover servers is made to
DHCPv6 messages that convey DHCPv6 options, following the format a specific port, the dhcp-failover port, port 647. All information
defined in Section 22.1 of [RFC3315]. is sent over the 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 DHCPv6 messages The following diagram illustrates the format of DHCP messages
exchanged between failover partners (which is compatible with the exchanged between failover partners (which is compatible with the
format described in Section 6 of [RFC3315]): format described in Section 6 of [RFC3315]):
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 DHCPv6 message type; the msg-type Identifies the DHCP message type; the
available message types are listed in available message types are listed below.
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. options Options carried in this message. These
options are all defined in the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)
Option Codes registry. A number of existing
DHCPv6 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 list contains the new message types created 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 (TBD1) is used to send the binding
lease changes to the partner. One message may contain one or more lease changes to the partner. At most one OPTION_CLIENT_DATA option
lease updates. The partner is expected to respond with a BNDACK may appear in a BNDUPD message. Note that not all data in a BNDUPD
message. is sent in an OPTION_CLIENT_DATA option. Information about delegable
prefixes not currently allocated to a particular client is sent in
BNDUPD messages but not within OPTION_CLIENT_DATA options. The
partner is expected to respond with a BNDACK message.
5.3.2. BNDACK 5.3.2. BNDACK
The binding acknowledgement message BNDACK (TBD2) is used for The binding acknowledgement message BNDACK (TBD2) 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 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 (TBD3) is used by the secondary
server to request allocation of resources (addresses or prefixes) server to request allocation of delegable prefixes from the primary
from the primary server. The primary responds with POOLRESP. server. The primary responds with POOLRESP.
5.3.4. POOLRESP 5.3.4. POOLRESP
The Pool Response POOLRESP (TBD4) message is used by the primary The Pool Response POOLRESP (TBD4) message is used by the primary
server to indicate that it has responded to the secondary's request server to indicate that it has received the secondary's servers
for resource allocation. request to ensure that delegable prefixes are balanced between 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
responded to, it only indicates reception and acceptance of the task
of ensuring 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 (TBD5) is used by one server to
request that its partner send 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
BNDACK message has been received for each of them. BNDACK message has been received for each of them.
skipping to change at page 17, line 18 skipping to change at page 19, line 16
The update done message UPDDONE (TBD7) is used by the server The update done message UPDDONE (TBD7) is used by the server
responding to an UPDREQ or UPDREQALL to indicate that all requested responding to an UPDREQ or UPDREQALL to indicate that all requested
updates have been sent by the responding server and acked by the updates have been sent by the responding server and acked by the
requesting server. 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 (TBD8) 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 data items between the transmit several important configuration attributes items between the
servers. The partner is expected to confirm by responding with servers. The partner is expected to confirm by responding with
CONNECTACK message. CONNECTACK message.
5.3.9. CONNECTACK 5.3.9. CONNECTACK
The connect acknowledgement message CONNECTACK (TBD9) is used by the The connect acknowledgement message CONNECTACK (TBD9) is used by the
secondary server to respond to a CONNECT message from the primary secondary server to respond to a CONNECT message from the primary
server. server.
5.3.10. DISCONNECT 5.3.10. DISCONNECT
skipping to change at page 18, line 14 skipping to change at page 20, line 12
established connection if other message traffic is not flowing, and established connection if other message traffic is not flowing, and
it MAY be sent at any time. See Section 6.5. it MAY be sent at any time. See Section 6.5.
5.4. Options 5.4. Options
The following new options are defined. The following new options are defined.
5.4.1. OPTION_F_BINDING_STATUS 5.4.1. OPTION_F_BINDING_STATUS
The binding-status represents an implementation independent The binding-status represents an implementation independent
representation of the status (or the state) of a resource (IPv6 representation of 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 TBD13.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 39 skipping to change at page 20, line 37
option-code OPTION_F_BINDING_STATUS (TBD13). option-code OPTION_F_BINDING_STATUS (TBD13).
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 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.4.2. OPTION_F_DNS_REMOVAL_INFO 5.4.2. OPTION_F_CONNECT_FLAGS
Flags which indicate attributes of the connecting server.
This consists of an unsigned 16 bit value in network byte order.
The code for this option is TBD14.
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_CONNECT_FLAGS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_CONNECT_FLAGS (TBD14).
option-len 2.
flags flag bits, see below:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bits (numbered from the least-significant bit in network
byte-order) are used as follows:
0-14: MBZ
Must be zero
15 (F): FIXED_PD_LENGTH
Set to 1 to indicate that all prefixes delegated from a
given delegable prefix have the same prefix length (size).
If this is not set, the prefixes delegated from one
delegable prefix may have different sizes.
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.
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
prefixes delegated will be the same size, rather that all 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
specified independent of this protocol, but must be known to both
failover partners. It might be specified in the configuration for
each delegable prefix or it might be fixed for the entire server.
5.4.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 TBD14. The code for this option is TBD15.
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_REMOVAL_INFO | option-len | | OPTION_F_DNS_REMOVAL_INFO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-options | | encapsulated-options |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_REMOVAL_INFO (TBD14). option-code OPTION_F_DNS_REMOVAL_INFO (TBD15).
option-len 4. option-len variable
sub-options Three possible sub-options: sub-options Three possible encapsulated options:
OPTION_F_DNS_HOST_NAME OPTION_F_DNS_HOST_NAME
OPTION_F_DNS_ZONE_NAME OPTION_F_DNS_ZONE_NAME
OPTION_F_DNS_FLAGS OPTION_F_DNS_FLAGS
5.4.3. OPTION_F_DNS_HOST_NAME 5.4.4. OPTION_F_DNS_HOST_NAME
Contains the host name that was entered into DNS by the failover Contains the host name that was entered into DNS by the failover
partner. partner.
This is a DNS name encoded in [RFC1035] format as specified in This is a DNS name encoded in [RFC1035] format as specified in
Section 8 of [RFC3315]. Section 8 of [RFC3315].
This is a suboption of OPTION_F_DNS_REMOVAL_INFO. The suboption code The code for this option is TBD16.
for this suboption is 1.
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_HOST_NAME | option-len | | OPTION_F_DNS_HOST_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | .
. . . .
. host-name . . host-name .
. (variable) . . (variable) .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_HOST_NAME (1). option-code OPTION_F_DNS_HOST_NAME (TBD16).
option-len 0 + length of host-name. option-len length of host-name.
host-name RFC 1035 encoded host-name. host-name RFC 1035 encoded host-name.
5.4.4. OPTION_F_DNS_ZONE_NAME 5.4.5. OPTION_F_DNS_ZONE_NAME
Contains the zone name that was entered into DNS by the failover Contains the zone name that was entered into DNS by the failover
partner. partner.
This is a DNS name encoded in [RFC1035] format as specified in This is a DNS name encoded in [RFC1035] format as specified in
Section 8 of [RFC3315]. Section 8 of [RFC3315].
This is a suboption of OPTION_F_DNS_REMOVAL_INFO. The suboption code The code for this option is TBD17.
for this suboption is 2.
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_ZONE_NAME | option-len | | OPTION_F_DNS_ZONE_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . | .
. . . .
. zone-name . . zone-name .
. (variable) . . (variable) .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_ZONE_NAME (2). option-code OPTION_F_DNS_ZONE_NAME (TBD17).
option-len 0 + length of zone-name. option-len length of zone-name.
zone-name RFC 1035 encoded zone name. zone-name RFC 1035 encoded zone name.
5.4.5. OPTION_F_DNS_FLAGS 5.4.6. OPTION_F_DNS_FLAGS
Flags which indicate what needs to be done to remove this DNS name. Flags which indicate what needs to be done to remove this DNS name.
This consists an unsigned 16 bit value in network byte order. This consists of an unsigned 16 bit value in network byte order.
This is a suboption of OPTION_F_DNS_REMOVAL_INFO. The suboption code The code for this option is TBD18.
for this suboption is 3.
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 (3). option-code OPTION_F_DNS_FLAGS (TBD18).
option-len 2. option-len 2.
flags flag bits, see below: flags flag bits, see below:
0 1 2 3 4 5 6 7 0 1
+-+-+-+-+-+-+-+-+ 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 least-significant bit in network The bits (numbered from the least-significant bit in network
byte-order) are used as follows: byte-order) are used as follows:
4 (U): USING_REQUESTED_FQDN 0-11: MBZ
Set to 1 to indicate that name used came from the Must be zero
FQDN that was received from the client. 12 (U): USING_REQUESTED_FQDN
5 (S): SYNTHESIZED_NAME Set to 1 to indicate that name used came from the
Set to 1 to indicate that the name was synthesized FQDN that was received from the client.
based on some algorithm. 13 (S): SYNTHESIZED_NAME
6 (R): REV_UPTODATE Set to 1 to indicate that the name was synthesized
Set to 1 to indicate that the reverse zone is up to date. based on some algorithm.
7 (F): FWD_UPTODATE 14 (R): REV_UPTODATE
Set to 1 to indicate that the forward zone is up to date. Set to 1 to indicate that the reverse zone is up to date.
0-3 : MBZ 15 (F): FWD_UPTODATE
Must be zero Set to 1 to indicate that the forward zone is up to date.
5.4.6. OPTION_F_EXPIRATION_TIME If both the U and S bits are unset, then the name must have been
provided from some alternative configuration, such as client
registration in some database accessible to the DHCP server.
5.4.7. OPTION_F_EXPIRATION_TIME
The greatest lifetime that this server has ever acked to its partner The greatest lifetime that this server has ever acked to its partner
in a BNDACK. This MUST be an absolute time (i.e. seconds since in a BNDACK. This MUST be an absolute time (i.e. seconds since
midnight January 1, 2000 UTC, modulo 2^32). 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 TBD15. The code for this option is TBD19.
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 (TBD15). option-code OPTION_F_EXPIRATION_TIME (TBD19).
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.4.7. OPTION_F_MAX_UNACKED_BNDUPD 5.4.8. OPTION_F_MAX_UNACKED_BNDUPD
The maximum number of BNDUPD messages that this server is prepared to The maximum number of BNDUPD messages that this server is prepared to
accept over the TCP connection without causing the TCP connection to accept over the TCP connection without causing the TCP connection to
block. 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 TBD16. The code for this option is TBD20.
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 (TBD16). option-code OPTION_F_MAX_UNACKED_BNDUPD (TBD20).
option-len 4. option-len 4.
max-unacked-bndupd Maximum number of unacked BNDUPD message max-unacked-bndupd Maximum number of unacked BNDUPD message
allowed. allowed.
5.4.8. OPTION_F_MCLT 5.4.9. OPTION_F_MCLT
The maximum-client-lead-time (MCLT) is the is the upper bound on the The maximum-client-lead-time (MCLT) is the upper bound on the
difference allowed between the lease time provided to a DHCPv6 client difference allowed between the valid lifetime provided to a DHCP
by a server and the lease time known by that server's failover client by a server and the valid lifetime known by that server's
partner. It is an interval, measured in seconds. See Section 4.4. failover partner. It is an interval, measured in seconds. See
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 TBD17. The code for this option is TBD21.
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 (TBD17). option-code OPTION_F_MCLT (TBD21).
option-len 4. option-len 4.
mclt The maximum-client-lease-time, in seconds. mclt The maximum-client-lease-time, in seconds.
5.4.9. OPTION_F_PARTNER_LIFETIME 5.4.10. OPTION_F_PARTNER_LIFETIME
The time after which the partner can consider an IPv6 address expired The time after which the partner can consider an IPv6 address expired
and is able to re-use the IPv6 address. This MUST be an absolute and is able to re-use the IPv6 address. This MUST be an absolute
time (i.e. seconds since 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 TBD18. The code for this option is TBD22.
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 (TBD18). option-code OPTION_F_PARTER_LIFETIME (TBD22).
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.4.10. OPTION_F_PARTNER_LIFETIME_SENT 5.4.11. OPTION_F_PARTNER_LIFETIME_SENT
The time that was received in an OPTION_F_PARTNER_LIFETIME The time that was received in an OPTION_F_PARTNER_LIFETIME
Section 5.4.9 option. This is an exact duplicate (echo) of the time Section 5.4.10 option. This is an exact duplicate (echo) of the time
received in the OPTION_F_PARTNER_LIFETIME option, uncorrected and received in the OPTION_F_PARTNER_LIFETIME option, uncorrected and
unadjusted in any way. This MUST be an absolute time (i.e. seconds unadjusted in any way. This MUST be an absolute time (i.e. seconds
since midnight January 1, 2000 UTC, modulo 2^32). 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 TBD19. The code for this option is TBD23.
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_SENT | option-len | |OPTION_F_PARTNER_LIFETIME_SENT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-lifetime-sent | | partner-lifetime-sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTNER_LIFETIME_SENT (TBD19). option-code OPTION_F_PARTNER_LIFETIME_SENT (TBD23).
option-len 4. option-len 4.
partner-lifetime-sent The partner-lifetime received in an 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.4.11. OPTION_F_PARTNER_DOWN_TIME 5.4.12. OPTION_F_PARTNER_DOWN_TIME
The time that the partner most recently lost commmunications with its The time that the partner most recently lost communications with its
failover partner. This MUST be an absolute time (i.e. seconds since failover partner. This MUST be an absolute time (i.e. seconds since
midnight January 1, 2000 UTC, modulo 2^32). 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 TBD20. The code for this option is TBD24.
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 (TBD20). option-code OPTION_F_PARTNER_DOWN_TIME (TBD24).
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 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.4.12. OPTION_F_PARTNER_RAW_CLT_TIME 5.4.13. OPTION_F_PARTNER_RAW_CLT_TIME
The time when the partner most recently interacted with the DHCPv6 The time when the partner most recently interacted with the DHCP
client associated with this IPv6 address. This MUST be an absolute client associated with this IPv6 address. This MUST be an absolute
time (i.e. seconds since midnight January 1, 2000 UTC, modulo 2^32). time (i.e. seconds since midnight January 1, 2000 UTC, modulo 2^32).
This time is uncorrected for clock skew, and remains in the time
context of the partner server.
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 TBD25.
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 (TBD21). option-code OPTION_F_PARTNER_RAW_CLT_TIME (TBD25).
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. This MUST
be an absolute time (i.e. seconds since be an absolute time (i.e. seconds since
midnight January 1, 2000 UTC, modulo 2^32). midnight January 1, 2000 UTC, modulo 2^32).
5.4.13. OPTION_F_PROTOCOL_VERSION 5.4.14. OPTION_F_PROTOCOL_VERSION
The protocol version allows the 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. changes and upgrades in the future. Two components are provided, to
allow for large and small changes to be represented in one 32-bit
number. The intent is that large changes would result in an
increment of the major-version, while small changes would result in
an increment of the minor-version. As subsequent updates and
extensions of this document can define changes to these values in any
way deemed appropriate no attempt is made to further define large and
small in this document.
This is an unsigned integer in network byte order. This consists of two unsigned 16-bit integers, in network byte order.
The code for this option is TBD22. The code for this option is TBD26.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol-version | | major-version | minor-version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol-version |
option-code OPTION_F_PROTOCOL_VERSION (TBD22). option-code OPTION_F_PROTOCOL_VERSION (TBD26).
option-len 4. option-len 4.
protocol-version The version of the protocol. major-version The major version of the protocol. Initially 1.
minor-version The minor version of the protocol. Initially 0.
5.4.14. OPTION_F_RECEIVE_TIME 5.4.15. OPTION_F_RECEIVE_TIME
The number of seconds (an interval) within which the server must The number of seconds (an interval) within which the server must
receive a message from its partner, or it will assume that receive a message from its partner, or it will assume that
communications from the partner is not ok. communications from the partner is 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 TBD23. The code for this option is TBD27.
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_RECEIVE_TIME | option-len | | OPTION_F_RECEIVE_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| receive-time | | receive-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_RECEIVE_TIME (TBD23). option-code OPTION_F_RECEIVE_TIME (TBD27).
option-len 4. option-len 4.
receive-time The receive-time. An interval of seconds. receive-time The receive-time. An interval of seconds.
5.4.15. OPTION_F_RECONFIGURE_DATA 5.4.16. OPTION_F_RECONFIGURE_DATA
Contains the information necessary for one failover partner to use Contains the information necessary for one failover partner to use
the reconfigure-key created on the other failover partner. the reconfigure-key created on the other failover partner.
The code for this option is TBD24. The code for this option is TBD28.
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 (TBD24). option-code OPTION_F_RECONFIGURE_DATA (TBD28).
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 (i.e. seconds
since midnight 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.4.16. OPTION_F_RELATIONSHIP_NAME 5.4.17. OPTION_F_RELATIONSHIP_NAME
A name for this failover relationshiop. A name for this failover relationship. Used to distinguish between
relationships when there are multiple failover relationships between
two failover servers.
A UTF-8 encoded text string suitable for display to an end user, A UTF-8 encoded text string suitable for display to an end user,
which MUST NOT be null-terminated. which MUST NOT be null-terminated.
The code for this option is TBD25. The code for this option is TBD29.
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 (TBD25). option-code OPTION_F_RELATIONSHIP_NAME (TBD29).
option-len 0 + 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, which MUST NOT be
null-terminated. null-terminated.
5.4.17. OPTION_F_SERVER_FLAGS 5.4.18. 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 TBD26. The code for this option is TBD30.
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 (TBD26). option-code OPTION_F_SERVER_FLAGS (TBD30).
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 |B|A|S|C| | MBZ |A|S|C|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The bits (numbered from the least-significant bit in network The bits (numbered from the least-significant bit in network
byte-order) are used as follows: byte-order) are used as follows:
4 (B): SECONDARY (BACKUP)
Indicates that the sending server is a secondary
(or backup) server.
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 most
recently received contained the STARTUP bit set. recently received contained the STARTUP bit set.
6 (S): STARTUP, 6 (S): STARTUP,
MUST be set to 1 whenever the server is in STARTUP state. MUST be set to 1 whenever the server is in STARTUP state.
7 (C): COMMUNICATED 7 (C): COMMUNICATED
Set to 1 to indicate that the sending server has Set to 1 to indicate that the sending server has
communicated with its partner. communicated with its partner.
0-3 : MBZ 0-3 : MBZ
Must be zero Must be zero
5.4.18. OPTION_F_SERVER_STATE 5.4.19. 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 TBD27. The code for this option is TBD31.
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 (TBD27). option-code OPTION_F_SERVER_STATE (TBD31).
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 Communication 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 an long period. 7 SHUTDOWN Shutting down for a long period.
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 server-flags options (see
Section 8.3. Section 8.3).
5.4.19. OPTION_F_START_TIME_OF_STATE 5.4.20. OPTION_F_START_TIME_OF_STATE
The time at which the associated state began to hold its current The time at which the associated state began to hold its current
value. When this option appears in a STATE message, the state to value. When this option appears in a STATE message, the state to
which it refers is the server endpoint state. When it appears in an which it refers is the server endpoint state. When it appears in an
IA_NA or IA_PD message, the state to which it refers is the binding- IA_NA-options, IA_TA-options, or IA_PD-options field , the state to
status value in the IA_NA or IA_PD option. This MUST be an absolute which it refers is the binding-status value in the OPTION_IA_NA,
time (i.e. seconds since midnight January 1, 2000 UTC, modulo 2^32). OPTION_IA_TA, or OPTION_IA_PD option, respectively. 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 TBD28. The code for this option is TBD32.
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 (TBD28). option-code OPTION_F_START_TIME_OF_STATE (TBD32).
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-state. 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.4.20. OPTION_F_STATE_EXPIRATION_TIME 5.4.21. OPTION_F_STATE_EXPIRATION_TIME
The state-expiration-time is the time at which the current state of The state-expiration-time is the time at which the current state of
this lease will expire. This MUST be an absolute time (i.e. seconds this lease will expire. This MUST be an absolute time (i.e. seconds
since midnight January 1, 2000 UTC, modulo 2^32). since midnight January 1, 2000 UTC, modulo 2^32).
This is an unsigned 32 bit integer in network byte order. Note that states other than ACTIVE may have a time associated with
them. In particular, EXPIRED might have a time associated with it,
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
ABANDONED state might have a time associated with it, in the event
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
client. In general, if there is an OPTION_STATE_EXPIRATION_TIME
associated with a particular state, that indicates the associated
state will expire and move to a different state at that time.
The code for this option is TBD29. This is an unsigned 32-bit integer in network byte order.
The code for this option is TBD33.
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 (TBD29). option-code OPTION_F_STATE_EXPIRATION_TIME (TBD33).
option-len 4. option-len 4.
state-expiration-time The state-expiration-time. This MUST be an state-expiration-time The state-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. Status Codes 5.5. 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.
AddressInUseByOtherClient (TBD30) AddressInUse (TBD34)
The one client on one server has leased resources that are in One client on one server has leases that are in conflict with the
conflict with the resources that this client has leased on another leases that the client has on another server. Alternatively, the
server. address could be associated with a different IA_ID on each server.
ConfigurationConflict (TBD31) ConfigurationConflict (TBD35)
The configuration implied by the information in a BNDUPD (e.g. the The configuration implied by the information in a BNDUPD (e.g. the
IPV6 address or prefix address) is in direct conflict with the IPV6 address or prefix address) is in direct conflict with the
information known to the receiving server. information known to the receiving server.
MissingBindingInformation (TBD32) MissingBindingInformation (TBD36)
There is insufficient information in a BNDUPD to effectively There is insufficient information in a BNDUPD to effectively
process it. process it.
OutdatedBindingInformation (TBD33) OutdatedBindingInformation (TBD37)
Returned when the information in a server's binding database Returned when the information in a server's binding database
conflicts with the information found in an incoming BNDUPD, and conflicts with the information found in an incoming BNDUPD, and
the server believes that the information in its binding database the server believes that the information in its binding database
more accurately reflects reality. more accurately reflects reality.
ServerShuttingDown (TBD34) ServerShuttingDown (TBD38)
Returned when the server is undergoing an operator directed or Returned when the server is undergoing an operator directed or
otherwise planned shutdown. otherwise planned shutdown.
DNSUpdateNotSupported (TBD39)
Returned when a server receives a BNDUPD with DNS update
information included, and the server doesn't support DNS update.
6. Connection Management 6. Connection Management
6.1. Creating Connections 6.1. Creating Connections
Every primary server implementing the failover protocol MUST attempt Every primary server implementing the failover protocol MUST
to connect to all of its configured partners periodically, where the periodically attempt to create a TCP connection to the dhcp-failover
period is implementation dependent and SHOULD be configurable. In port (647) of all of its configured partners, where the period is
the event that a connection has been rejected by a CONNECTACK message implementation dependent and SHOULD be configurable. In the event
with a reject-reason option contained in it or a DISCONNECT message, that a connection has been rejected by a CONNECTACK message with a
a server SHOULD reduce the frequency with which it attempts to reject-reason option contained in it or a DISCONNECT message, a
connect to that server but it MUST continue to attempt to connect server SHOULD reduce the frequency with which it attempts 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 connection attempts from the primary server. for TCP connection attempts on the dhcp-failover port (647) from a
primary server.
When a primary server attempts to connect with a secondary server, it After a primary server successfully establishes a TCP connection to a
MUST do so as described in Section 8.2 of [RFC7653]. In the language secondary server, it MUST continue the connection process as
of that section, the primary failover server operates as the described in Section 8.2 of [RFC7653]. In the language of that
"requestor" and the secondary failover server operates as the "DHCPv6 section, the primary failover server operates as the "requestor" and
server". The message that is sent over the newly established the secondary failover server operates as the "DHCP server". The
connection is a CONNECT message, instead of an ACTIVELEASEQUERY message that is sent over the newly established connection is a
message. CONNECT message, instead of an ACTIVELEASEQUERY message.
When a connection attempt is received by a secondary server, the only When a connection attempt is received by a secondary server, 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.
skipping to change at page 33, line 20 skipping to change at page 37, line 15
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. o OPTION_F_PROTOCOL_VERSION containing the protocol version.
o OPTION_F_MCLT containing the configured MCLT. o OPTION_F_MCLT containing the configured MCLT.
o OPTION_F_RECEIVE_TIME containing the the number of seconds (an o OPTION_F_RECEIVE_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 is
not ok. not ok.
o OPTION_F_UNACKED_BNDUPD containing the maximum number of BNDUPD o OPTION_F_UNACKED_BNDUPD containing the maximum number of BNDUPD
messages that this server is prepared to accept over the failover messages that this server is prepared to accept over the failover
connection without causing the connection to block. connection without causing the connection to block.
o OPTION_F_RELATIONSHIP_NAME containing name of the failover
relationship to which this connection applies. If there is no
OPTION_F_RELATIONSHIP_NAME in the CONNECT message, it indicates
that there is only a single relationship between this pair of
primary and secondary servers.
o OPTION_F_CONNECT_FLAGS containing information about certain
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 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 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 - Compare the MCLT received with the configured o OPTION_F_MCLT - Compare the MCLT received with the configured
MCLT, and if they are different the server MUST alert operational MCLT, and if they are different the server MUST alert operational
staff of this difference. Use the MCLT supplied by the primary staff of this difference. Use the MCLT supplied by the primary
skipping to change at page 34, line 5 skipping to change at page 38, line 9
secondary server. secondary server.
o OPTION_F_RECEIVE_TIME - Remember the receive-time as the o OPTION_F_RECEIVE_TIME - Remember the receive-time as the
FO_RECEIVE_TIME when implementing the Unreachability Detection FO_RECEIVE_TIME when implementing the Unreachability Detection
algorithm described in Section 6.6. algorithm described in Section 6.6.
o OPTION_F_UNACKED_BNDUPD - Ensure that the maximum amount of o OPTION_F_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_UNACKED_BNDUPD option. the value in the OPTION_F_UNACKED_BNDUPD option.
o OPTION_F_CONNECT_FLAGS - Ensure that the secondary can process
information from the primary as specified in the flags. For
example, if the secondary server cannot process prefix delegation
with variable sized prefixes delegated from the same delegable
prefix, and the primary server says that it can, the secondary
should reject the connection.
A CONNECT message SHOULD always be followed by a CONNECTACK message, A CONNECT message SHOULD always be followed by a CONNECTACK message,
either to accept the connection or to reject the connection by either to accept the connection or to reject the connection by
including an OPTION_STATUS_CODE option with an error reject. In including an OPTION_STATUS_CODE option with an error reject. In
order to reject the connection attempt, simply send a CONNECTACK order to reject the connection attempt, simply send a CONNECTACK
message with the OPTION_STATUS_CODE with the correct status. If message with the OPTION_STATUS_CODE with the correct status. If
accepting the connection attempt, then send a CONNECTACK message with accepting the connection attempt, then send a CONNECTACK message with
the following information: 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. used by the secondary server.
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.
o OPTION_F_RECEIVE_TIME containing the the number of seconds (an o OPTION_F_RECEIVE_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 is
not ok. not ok.
o OPTION_F_UNACKED_BNDUPD containing the maximum number of BNDUPD o OPTION_F_UNACKED_BNDUPD containing the maximum number of BNDUPD
messages that this server is prepared to accept over the failover messages that this server is prepared to accept over the failover
connection without causing the connection to block. connection without causing the connection to block.
o OPTION_F_CONNECT_FLAGS - Place information into this option to
describe the attributes of the secondary server that the primary
needs to know about.
After sending a CONNECTACK message to accept the primary server's After sending a CONNECTACK 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 CONNECTACK message 6.1.3. Receiving a CONNECTACK message
A server receiving a CONNECTACK message must process the information A server receiving a CONNECTACK message must process the information
in the message and decide whether or not continue to employ the in the message and decide whether or not to continue to employ the
connection. The processing is performed as follows: 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. drop the connection. If it is supported, continue processing.
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, and if they are different send a DISCONNECT message and drop
the connection. the connection.
o OPTION_F_RECEIVE_TIME - Remember the receive-time as the o OPTION_F_RECEIVE_TIME - Remember the receive-time as the
FO_RECEIVE_TIME when implementing the Unreachability Detection FO_RECEIVE_TIME when implementing the Unreachability Detection
algorithm described in Section 6.6. algorithm described in Section 6.6.
o OPTION_F_UNACKED_BNDUPD - Ensure that the maximum amount of o OPTION_F_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_UNACKED_BNDUPD option. exceeds the value in the OPTION_F_UNACKED_BNDUPD option.
o OPTION_F_CONNECT_FLAGS - Ensure that the primary can process
information from the secondary as specified in the flags. For
example, if the primary server cannot process prefix delegation
with variable sized prefixes delegated from the same delegable
prefix, and the secondary server says that it can, the primary
should drop the connection.
After receiving a CONNECTACK message that accepted the primary After receiving a CONNECTACK 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 DHCPv6 A failover endpoint is always associated with a set of DHCP prefixes
prefixes that are configured on the DHCPv6 server where the endpoint that are configured on the DHCP server where the endpoint appears. A
appears. A DHCPv6 prefix MUST NOT be associated with more than one DHCP prefix MUST NOT be associated with more than one failover
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 protocol in
terms of primary and secondary servers, not primary and secondary terms of primary and secondary servers, not primary and secondary
skipping to change at page 36, line 11 skipping to change at page 40, line 30
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 cause no problems, and not updating the
failover partner with information about a failover endpoint state failover partner with information about a failover endpoint state
change can, in many cases, cause the entire failover protocol to be change can, in many cases, cause the entire failover protocol to be
inoperative. 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 the 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 the 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 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.
skipping to change at page 37, line 16 skipping to change at page 41, line 32
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_RECEIVE_TIMER timer counts down to time connection FO_RECEIVE_TIMER timer counts down to time connection
assumed dead due to lack of packets assumed dead due to lack of messages
FO_RECEIVE_TIME 60 maximum time server will consider FO_RECEIVE_TIME 60 maximum time server will consider
connection still up with no packets connection still up with no messages
FO_CONTACT_PER_RECEIVE_TIME number of CONTACT messages to send FO_CONTACT_PER_RECEIVE_TIME number of CONTACT messages to send
4 during partner's FO_RECEIVE_TIME 4 during partner's FO_RECEIVE_TIME
period period
FO_SEND_TIMER timer counts down to time to send next FO_SEND_TIMER timer counts down to time to send next
CONTACT message CONTACT message
FO_SEND_TIME 15 maximum time to wait between sending FO_SEND_TIME 15 maximum time to wait between sending
CONTACT packets if no other traffic CONTACT messages if no other traffic
Created from partner's FO_RECEIVE_TIME Created from partner's FO_RECEIVE_TIME
divided by FO_CONTACT_PER_RECEIVE_TIME divided by FO_CONTACT_PER_RECEIVE_TIME
FO_SKEW_AVG 10 Number of time-skew values to include
in the moving average time-skew
calculatin
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 is reset to FO_SEND_TIME every time connection. The FO_SEND_TIMER for a particular connection is reset
any message is transmitted, and counts down once per second. If the to FO_SEND_TIME every time any message is transmitted on that
timer reaches zero, a CONTACT message is transmitted and timer is connection, and counts down once per second. If the timer reaches
reset to FO_SEND_TIME. The CONTACT message may be transmitted at any zero, a CONTACT message is transmitted on that connection and the
time. An implementation MAY use additional mechanisms to detect timer for that connection is reset to FO_SEND_TIME. The CONTACT
partner unreachability. message may be transmitted at any time. An implementation MAY use
additional mechanisms to detect partner unreachability.
The FO_SEND_TIME is initialized from the configured FO_RECEIVE_TIME The FO_SEND_TIME is initialized from the configured FO_RECEIVE_TIME
divided by FO_CONTACT_PER_RECEIVE_TIME. When a CONNECT or CONNECTACK divided by FO_CONTACT_PER_RECEIVE_TIME. When a CONNECT or CONNECTACK
message is received, the OPTION_F_RECEIVE_TIME option is checked, and message is received on a connection, the received
if it appears then the value in that option is used to calculate the OPTION_F_RECEIVE_TIME option is checked, and the value in that option
FO_SEND_TIME by dividing the value received by the configured is used to calculate the FO_SEND_TIME for that connection by dividing
FO_CONTACT_PER_RECEIVE_TIME. the value received by the configured FO_CONTACT_PER_RECEIVE_TIME.
Each partner MUST maintain an FO_RECEIVE_TIMER for each failover Each partner MUST maintain an FO_RECEIVE_TIMER for each failover
connection. This timer is initialized to FO_RECEIVE_TIME and counts connection. This timer is initialized to FO_RECEIVE_TIME and counts
down once per second. It is reset to FO_RECEIVE_TIME whenever a down once per second. It is reset to FO_RECEIVE_TIME whenever a
packet is received. If it ever reaches zero, the connection is message is received on that connection. If it ever reaches zero,
considered dead. In addition, the FO_RECEIVE_TIME MUST be sent to that connection is considered dead. In addition, the FO_RECEIVE_TIME
the failover partner on every CONNECT or CONNECTACK messages, in the for that connection MUST be sent to the failover partner on every
OPTION_F_RECEIVE_TIME option. CONNECT or CONNECTACK messages, in the OPTION_F_RECEIVE_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. Although a known lease state with the times received in the update. The
simple approach would be to require both partners to use synchronized failover protocol adopts the simple approach of requiring that the
time, e.g. by using the Network Time Protocol, such a service may not failover partners use some mechanism to synchronize the clocks on the
always be available. Therefore a mechanism to measure and track two servers to within an accuracy of roughly 5 seconds.
relative time differences between servers is necessary. To do so,
each message contains the time of the transmission in the time A mechanism to measure and track relative time differences between
context of the transmitter in the sent-time field of the message servers is necessary to ensure this synchronization. To do so, each
Section 5.2. The transmitting server MUST set this as close to the message contains the time of the transmission in the time context of
the transmitter in the sent-time field of the message (see
Section 5.2). The transmitting server MUST set this as close to the
actual transmission as possible. The receiving partner MUST store actual transmission as possible. The receiving partner MUST store
its own timestamp of reception as close to the actual reception as its own timestamp of reception as close to the actual reception as
possible. The received timestamp information is then compared with possible. The received timestamp information is then compared with
local timestamp. local timestamp.
To account for packet delay variation (jitter), the measured
difference is not used directly, but rather the moving average of the
last FO_SKEW_AVG packets time difference is calculated. This
averaged value is referred to as the time skew. Note that the time
skew algorithm allows cooperation between servers with completely
desynchronized clocks as well as those whose desynchronization itself
is not constant.
7.2. Information model 7.2. Information model
In most DHCPv6 servers a resource (an IPv6 address or a prefix) can In most DHCP servers a lease on an IPv6 address or a prefix can take
take on several different binding-status values, sometimes also on several different binding-status values, sometimes also called
called lease states. While no two DHCPv6 server implementations will lease states. While no two DHCP server implementations will have
have exactly the same possible binding-status values, [RFC3315] exactly the same possible binding-status values, [RFC3315] enforces
enforces some commonality among the general semantics of the binding- some commonality among the general semantics of the binding-status
status values used by various DHCPv6 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 with any actual implementation of the DHCPv6 protocol in a
DHCPv6 server, but rather that the binding-status values defined in DHCP server, but rather that the binding-status values defined in
this document should be convertable back and forth between those this document should be convertible back and forth between those
defined below and those in use by many DHCPv6 server implementations. defined below and 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 value.
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 -- indicates that a client's binding on a given lease has
expired. When the partner acks the BNDUPD of an expired lease, expired. When the partner acks the BNDUPD of an expired lease,
the server sets its internal state to FREE*. Client identification the server sets its internal state to PENDING-FREE. Client
SHOULD appear. identification SHOULD appear.
RELEASED -- indicates that a client sent in RELEASE message. When RELEASED -- indicates that a client sent a RELEASE message. When
the partner acks the BNDUPD of a released lease, the server sets the partner acks the BNDUPD of a released lease, the server sets
its internal state to FREE*. Client identification SHOULD appear. its internal state to PENDING-FREE. Client identification SHOULD
appear.
FREE* -- Once a lease is expired or released, its state becomes
FREE*. Depending on which algorithm and which pool was used to
allocate a given lease, FREE* may either mean FREE or FREE_BACKUP.
Implementations do not have to implement this FREE* state, but may
choose to switch to the destination state directly. For a clarity
of representation, this transitional FREE* state is treated as a
separate state.
FREE -- Is used when a DHCPv6 server needs to communicate that a PENDING-FREE -- Once a lease is expired or released, its state
resource is unused by any client, but it was not just released, becomes PENDING-FREE. Depending on which algorithm and which pool
expired or reset by a network administrator. When the partner was used to allocate a given lease, PENDING-FREE may either mean
acks the BNDUPD of a FREE lease, the server marks the lease as FREE or FREE-BACKUP. Implementations do not have to implement
available for assignment by the primary server. Note that on a this PENDING-FREE state, but may choose to switch to the
secondary server running in PARTNER-DOWN state, after waiting the destination state directly. For clarity of representation, this
MCLT, the resource MAY be allocated to a client by the secondary transitional PENDING-FREE state is treated as a separate state.
server. Client identification MAY appear and indicates the last
client to have used this resource as a hint.
FREE_BACKUP -- indicates that this resource can be allocated by the FREE -- Is used when a DHCP server needs to communicate that a lease
secondary server to a client at any time. Note that the primary is unused by any client, but it was not just released, expired or
reset by a network administrator. When the partner acks the
BNDUPD of a FREE lease, the server marks the lease as available
for assignment by the primary server. Note that on a secondary
server running in PARTNER-DOWN state, after waiting the MCLT, the server running in PARTNER-DOWN state, after waiting the MCLT, the
resource MAY be allocated to a client by the primary server if lease MAY be allocated to a client by the secondary server.
proportional algorithm was used. Client identification MAY appear Client identification MAY appear and indicates the last client to
and indicates the last client to have used this resource as a have used this lease as a hint.
FREE-BACKUP -- indicates that this lease can be allocated by the
secondary server to a client at any time. Note that on the
primary server running in PARTNER-DOWN state, after waiting the
MCLT, the lease MAY be allocated to a client by the primary server
if proportional algorithm was used. Client identification MAY
appear and indicates the last client to have used this lease as a
hint. hint.
ABANDONED -- indicates that a lease is considered unusable by the ABANDONED -- indicates that a lease is considered unusable by the
DHCPv6 system. The primary reason for entering such state is DHCP system. The primary reason for entering such state is
reception of DECLINE message for the lease. Client identification reception of DECLINE message for the lease. Client identification
MAY appear. MAY appear.
RESET -- indicates that this resource was made available by operator RESET -- indicates that this lease was made available by operator
command. This is a distinct state so that the reason that the command. This is a distinct state so that the reason that the
resource became FREE can be determined. Client identification MAY lease became FREE can be determined. Client identification MAY
appear. appear.
Which binding-status values are associated with a timeout is
implementation dependent. Some binding-status values such as ACTIVE
will have a timeout value in all implementations, while others such
as ABANDONDED will have a timeout value in some implementations and
not in others. In some implementations a binding-status value may be
associated with a timeout in some circumstances and not in other
circumstances. The receipt of a BNDUPD with a particular binding-
status value and an 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 1. Most states are The lease state machine is presented in Figure 1. 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 external
event triggers transition to another state. The only transitive event triggers transition to another state. The only transitive
state is FREE*. Once it is reached, the state machine immediately state is PENDING-FREE. Once it is reached, the state machine
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| |
skipping to change at page 41, line 26 skipping to change at page 45, line 26
| | | (10) | | | | (10) |
| | | V | | | | V |
| | | +---------+ | | | | +---------+ |
| | | | RESET | | | | | | RESET | |
| | | +---------+ | | | | +---------+ |
| | | | | | | | | |
| \--(4)--\ (4) /--(4)--/ | | \--(4)--\ (4) /--(4)--/ |
| | | | | | | | | |
(1) V V V (2) (1) V V V (2)
| /---------\ | | /---------\ |
| | FREE* | | | | PENDING | |
| | FREE | |
| \---------/ | | \---------/ |
| | | | | | | |
| /-(5)--/ \-(6)-\ | | /-(5)--/ \-(6)-\ |
| | | | | | | |
| V V | | V V |
| +-------+ +-----------+ | | +-------+ +-----------+ |
\----| FREE |<--(7)-->|FREE_BACKUP|-----/ \----| FREE |<--(7)-->|FREE-BACKUP|-----/
+-------+ +-----------+ +-------+ +-----------+
FREE* transition PENDING-FREE transition
Figure 1: Lease State Machine Figure 1: Lease State Machine
Transitions between states are results of the following events: Transitions between states are results of the following events:
1. Primary server allocates a lease. 1. Primary server allocates a lease.
2. Secondary server allocates a lease. 2. Secondary server allocates a lease.
3. Client sends RELEASE and the lease is released. 3. Client sends RELEASE and the lease is released.
4. Partner acknowledges state change. This transition MAY also 4. Partner acknowledges state change. This transition MAY also
occur if the server is in PARTNER-DOWN state and the MCLT has occur if the server is in PARTNER-DOWN state and the MCLT has
passed since the entry in RELEASED, EXPIRED, or RESET states. passed since the entry 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 the
proportional allocation, or independent allocation is used and proportional allocation, or independent allocation is used and
this lease belongs to primary server pool. this lease belongs to primary server pool.
6. The lease belongs to a pool that is governed by the 6. The lease belongs to a pool that is governed by the
independent allocation and the lease belongs to the secondary independent allocation and the lease belongs to the secondary
server. server.
7. Pool rebalance event occurs (POOLREQ/POOLRESP messages are 7. Pool rebalance event occurs (POOLREQ/POOLRESP messages are
exchanged). Addresses (or prefixes) belonging to the primary exchanged). Delegable prefixes belonging to the primary server
server can be assigned to the secondary server pool (transition can be assigned to the secondary server pool (transition from FREE
from FREE to FREE_BACKUP) or vice versa. to FREE-BACKUP) or vice versa.
8. The lease has expired. 8. The lease has expired.
9. DECLINE message is received or a lease is deemed unusable for 9. DECLINE message is received or a lease is deemed unusable for
other reasons. other reasons.
10. An administrative action is taken to recover an abandoned 10. An administrative action is taken to recover an abandoned
lease back to usable state. This transition MAY occur due to an lease back to usable state. This transition MAY occur due to an
implementation specific handling on ABANDONED resource. One implementation specific handling on ABANDONED lease. One possible
possible example of such use is a Neighbor Discovery or ICMPv6 example of such use is a Neighbor Discovery or ICMPv6 Echo check
Echo check if the address is still in use. if the address is still in use.
The resource 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 FREE*. Depending of what allocation algorithm is used, the becomes PENDING-FREE. Depending on what allocation algorithm is
resource that is no longer is use, returns to the primary (FREE) or used, the lease that is no longer is use, returns to the primary
secondary pool (FREE_BACKUP). The conditions for specific (FREE) or secondary pool (FREE-BACKUP). The conditions for specific
transitions are depicted in Figure 2. transitions are depicted in Figure 2.
+----------------+---------+-----------+ +----------------+---------+-----------+
| \Resource owner| | | | \ Lease owner| | |
| \----------\ | Primary | Secondary | | \----------\ | Primary | Secondary |
|Algorithm \ | | | |Algorithm \ | | |
+----------------+---------+-----------+ +----------------+---------+-----------+
| Proportional | FREE |FREE_BACKUP| | Proportional | FREE |FREE-BACKUP|
| Independent | FREE | FREE | | Independent | FREE | FREE |
+----------------+---------+-----------+ +----------------+---------+-----------+
Figure 2: FREE* State Transitions Figure 2: 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 DHCPv6 protocol [RFC3315]. those required by the base DHCP protocol [RFC3315].
expiration-time expiration-time
The greatest lifteime that this server has ever acked to its The greatest liftime that this server has ever acked to its
failover partner in a BNDACK. failover partner in a BNDACK.
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 BNDACK. this server in a BNDACK.
partner-lifetime partner-lifetime
The time that we will send (or have sent) the partner, which will The time that we will send (or have sent) the partner, which will
be the time after which the partner can consider the IPv6 address be the time after which the partner can consider the lease
expired. expired. When we receive a BNDUPD this value can be updated from
the received OPTION_F_EXPIRATION_TIME.
client-last-transaction-time client-last-transaction-time
The time when the this server most recently intereacted with the The time when the this server most recently interacted with the
client associated with this IPv6 address. client 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 IPv6 address. This time remains exactly as associated with this lease. This time remains exactly as it was
it was received by this server, and MUST NOT be adjusted to be in received by this server, and MUST NOT be adjusted to be in the
the time context of this server. 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
Each server updates its failover partner about recent changes in Each server updates its failover partner about recent changes in
lease states using the BNDUPD message. Every BNDUPD message contains lease states using the BNDUPD message. Every BNDUPD message contains
information about one or more client bindings. All information about information about either a single client binding in an
a particular client binding is contained in a single OPTION_CLIENT_DATA option, or a single prefix lease in an
OPTION_CLIENT_DATA option (see [RFC5007] Section 4.1.2.2). OPTION_IAPREFIX option.
The OPTION_CLIENT_DATA option MUST contain at least the data shown All information about a particular client binding MUST be contained
below in its client-options section: in a single OPTION_CLIENT_DATA option (see Section 4.1.2.2 of
[RFC5007]). The OPTION_CLIENT_DATA option MUST contain at least the
data 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 IPv6 address*; associated with this lease;
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 into this OPTION_CLIENT_DATA option (see
[RFC7653] Section 6.3.1); Section 6.3.1 of [RFC7653]);
o OPTION_VSS (see Section 3.4 of [RFC6607]) This option MUST NOT
appear if the information in this OPTION_CLIENT_DATA option is
associated with the global, default VPN. This option MUST appear
if the information in this OPTION_CLIENT_DATA option is associated
with a VPN other than the global, default VPN;
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]*; Section 4.1.2.4 of [RFC5007], if any exists;
o OPTION_IA_NA for an IPv6 Address or OPTION_IA_PD for an IPv6 o OPTION_IA_NA or OPTION_IA_TA for an IPv6 Address or OPTION_IA_PD
Prefix. More than one of either of these options MAY appear if for an IPv6 Prefix. More than one of either of these options MAY
there are more than one associated with this client; appear if there are more than one associated with this client;
* 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. (Note1: one client may use many IAIDs
simultaneously. Note2: IAID for IA, TA and PD are orthogonal simultaneously. Note2: IAID for IA, TA and PD are orthogonal
number spaces.)*; 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 or IA_PD-option sections: * Inside of the IA_NA-options, IA_TA-options, or IA_PD-option
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; a IPv6 prefix;
- 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;
o OPTION_F_START_TIME_OF_STATE containing the start- o OPTION_F_START_TIME_OF_STATE containing the start-
time-of-state; time-of-state;
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 client-last-
transaction-time. See [RFC5007] for this option*; transaction-time. See [RFC5007] for this option;
o OPTION_F_PARTNER_LIFETIME (absolute) containing o OPTION_F_PARTNER_LIFETIME (absolute) containing
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 the FQDN information o DHCP_O_CLIENT_FQDN containing the FQDN information
associated with this resource and client*; associated with this lease and client, if any;
Note that additonal data MAY be included beyond that listed above. Information about a prefix lease is contained in a single
The IAddr_options or IAprefix-options area are the places where OPTION_IAPREFIX option. Only a single OPTION_IAPREFIX option may
additional information should be included. appear in a BNDUPD message outside of an OPTION_CLIENT_DATA option.
In detail:
Items marked with a single asterisk (*) MUST appear only if the o OPTION_IAPREFIX for a prefix lease;
resource is associated with a client. Otherwise it MUST NOT appear.
Items marked with a double asterisk (**) MUST appear only if the * IPv6 Prefix (with length);
value in the OPTION_F_BINDING_STATUS is associated with a timeout,
otherwise it MUST NOT appear. * Inside of the IAprefix-options section:
+ OPTION_VSS (see Section 3.4 of [RFC6607]) This option MUST
NOT appear if the information in this OPTION_IAPREFIX option
is associated with the global, default VPN. This option
MUST appear if the information in this OPTION_IAPREFIX
option is associated with a VPN other than the global,
default VPN;
+ OPTION_LQ_BASE_TIME containing the absolute time that this
information was placed into this OPTIONS_IAPREFIX option
(see Section 6.3.1 of [RFC7653]);
+ OPTION_F_BINDING_STATUS containing the binding-status;
+ OPTION_F_START_TIME_OF_STATE containing the start-time-of-
state;
+ OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the
state-expiration-time*;
+ OPTION_F_PARTNER_LIFETIME (absolute) containing partner-
lifetime*;
+ OPTION_F_EXPIRATION_TIME (absolute) containing the
expiration-time*;
Items marked with a single asterisk (*) MUST appear only if the value
in the OPTION_F_BINDING_STATUS is associated with a timeout,
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 DHCPv6 client. It MUST NOT be, for last interacted with the DHCP client. It MUST NOT be, for instance,
instance, the time that the lease on an IPv6 address expired. If the time that the lease expired if there has been no interaction with
there has been no interaction with the DHCPv6 client in question (or the DHCP client in question.
there is no DHCPv6 client presently associated with this resource),
then there will be no OPTION_CLT_TIME option in the
OPTION_CLIENT_DATA option
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 Dynamic DNS. Another reason the partner may be discussion about DNS update. Another reason the partner may be
interested in keeping additional data is a 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 features queries based on Relay-ID, by link [RFC7653], some of which feature queries based on Relay-ID, by link
address and by Remote-ID. address and by Remote-ID.
7.5. Receiving Binding Updates 7.5. Receiving Binding Updates
7.5.1. Correcting Time Skew 7.5.1. Monitoring Time Skew
Unless otherwise specified, all of the times discussed below are
corrected to be in the time context of the receiving server, as
follows:
1. The sent-time from the Failover message is compared with the
current time of the receiving server as recorded when it received
the message. The difference is noted, and used to affect the
time correction by being included in the moving average of the
last FO_SKEW_AVG differences. This is called the time-
correction.
2. Any OPTION_LQ_BASE_TIME options in the BNDUPD message MUST be The sent-time from the Failover message is compared with the current
corrected with the time-correction. The result is called the time of the receiving server as recorded when it received the
corrected-base-time. message. The difference is noted, and if it is greater than 5
seconds the receiving server SHOULD drop the connection.
3. Any relative time values received in the BNDUPD MUST be added to Any time can be before, after, or essentially the same as another
or subtracted from the corrected-base-time. time. Any time which ends up being +/- 5 seconds of another time
SHOULD be considered to be representing the same time when performing
a comparison between two times.
4. Any absolute time values received in the BNDUPD MUST be corrected 7.5.2. Acknowledging Reception
with the time-correction
When all of this is done to an incoming time, that time can be Upon acceptance of a binding update, the server MUST notify its
before, after, or essentially the same as another time. Any time partner that it has processed the binding update (and updated its
which ends up being +/- 5 seconds of another time SHOULD be lease state database if necessary) by sending a BNDACK. A server
considered to be representing the same time when performing a MUST NOT send the BNDACK before its binding database is updated.
comparison between two times.
7.5.2. Processing Binding Updates 7.5.3. Processing Binding Updates
When a BNDUPD is received each OPTION_CLIENT_DATA option is processed When a BNDUPD is received it MUST contain either a single
separately, and each must be independently accepted or rejected. OPTION_CLIENT_DATA option or a single OPTION_IAPREFIX option.
When analyzing an OPTION_CLIENT_DATA option from a partner server, if When analyzing an BNDUPD message option from a partner server, if
there is insufficient information in the OPTION_CLIENT_DATA to there is insufficient information in the BNDUPD message to process
process it, then it is rejected with an OPTION_STATUS_CODE of it, then it 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 update from its partner must evaluate
the received information in each OPTION_CLIENT_DATA option to see if the received information in each OPTION_CLIENT_DATA or IAPREFIX
it is consistent with the server's already known state, and if it is option to see if it is consistent with the server's already known
not, decide which information - that previously known or that just state, and if it is not, decide which information - that previously
received - is "better". If the information in the BNDUPD is known or that just received - is "better". If the information in the
"better", the receiving server will accept the information in the BNDUPD is "better", the receiving server will accept the information
BNDUPD. If the information in the server's binding database is in the BNDUPD. If the information in the server's binding database
"better", the server will reject the information in the BNDUPD. is "better", the server will reject the information in the BNDUPD.
A server receving a BNDUPD message MUST respond to the sender of that A server receiving a BNDUPD message MUST respond to the sender of
message with a BNDACK message which contains the same transaction-id that message with a BNDACK message which contains the same
as the BNDUPD message. This BNDACK message MUST contain one or more transaction-id as the BNDUPD message. This BNDACK message MUST
OPTION_CLIENT_DATA options, each of which corresponds to one of the contain either a single OPTION_CLIENT_DATA option or a single
OPTION_CLIENT_DATA options in the BNDUPD message. OPTION_IAPREFIX option, corresponding to whatever was received in the
BNDUPD message.
Each OPTION_CLIENT_DATA in the BNDACK which is accepted SHOULD NOT An OPTION_CLIENT_DATA option or an OPTION_IAPREFIX option in the
contain an OPTION_STATUS_CODE unless a status message needs to be BNDACK which is accepted SHOULD NOT contain an OPTION_STATUS_CODE
sent to the failover partner, in which case it SHOULD include an unless a status message needs to be sent to the failover partner, in
OPTION_STATUS_CODE option with a status code indicating success and which case it SHOULD include an OPTION_STATUS_CODE option with a
whatever message is needed. status code indicating success and whatever message is needed.
To indicate rejection of the information in an OPTION_CLIENT_DATA, an To indicate rejection of the information in an OPTION_CLIENT_DATA
OPTION_STATUS_CODE SHOULD be included with a status code indicating option, or an OPTION_IAPREFIX option, an OPTION_STATUS_CODE SHOULD be
an error, in the OPTION_CLIENT_DATA option in the BNDACK message. included with a status code indicating an error in the
OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDACK
message.
7.5.3. 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 is extract the client information and resource information out option or OPTION_IAPREFIX option is extract the client information
of the OPTION_CLIENT_DATA option, and to access the resource (IPv6 (if any) and lease information out of the option, and to access the
address or prefix) information in the server's binding database. address lease or prefix lease information in the server's binding
database.
If the resource specified in the OPTION_CLIENT_DATA is not a resource If an OPTION_VSS option is specified in the OPTION_CLIENT_DATA option
associated with the failover endpoint which received the or OPTION_IAPREFIX option, if the VPN specified in the OPTION_VSS
OPTION_CLIENT_DATA option, then reject it with reject-reason option does not appear in the configuration of the receiving server,
"ConfigurationConflict". reject the entire OPTION_CLIENT_DATA option or OPTION_IAPREFIX option
with the reject-reason "ConfigurationConflict".
If the lease specified in the OPTION_CLIENT_DATA option or
OPTION_IAPREFIX option is not a lease associated with the failover
endpoint which received the OPTION_CLIENT_DATA option, then reject it
with reject-reason "ConfigurationConflict".
In general, acceptance or rejection is based around the comparison of In general, acceptance or rejection is based around the comparison of
two different time values, one from the OPTION_CLIENT_DATA and one two different time values, one from the OPTION_CLIENT_DATA option or
from receiving server's binding database associated with the resource OPTION_IAPREFIX option in the BNDUPD message, and one from the
found in the OPTION_CLIENT_DATA. The time for the OPTION_CLIENT_DATA receiving server's binding database associated with the address or
is the OPTION_CLT_TIME if one appears, and the prefix lease found in the BNDUPD message. The time for the BNDUPD
OPTION_F_START_TIME_OF_STATE if one does not. The time for the message is the OPTION_CLT_TIME if one appears, and the
resource in the server's binding database is the client-last- OPTION_F_START_TIME_OF_STATE if one does not. The time for the lease
transaction-time, if one appears, and the start-time-of-state if one in the server's binding database is the client-last-transaction-time,
does not. if one appears, and 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
OPTION_CLIENT_DATA is clearly later, then accept the information in BNDUPD message is clearly later, then accept the information in the
the OPTION_CLIENT_DATA. If the one from the server's binding OPTION_CLIENT_DATA option or OPTION_IAPREFIX option. If the one from
database is clearly later, then reject the information in the the server's binding database is clearly later, then reject the
OPTION_CLIENT_DATA. The challenge comes when they are essentially information in the BNDUPD message. The challenge comes when they are
the same (i.e., +/- 5 seconds). The table below (Figure 3) contains essentially the same (i.e., +/- 5 seconds). In this case they are
the rules for dealing with these situations. considered identical, despite the minor differences. The table below
(Figure 3) contains the rules for dealing with all of these
situations.
binding-status in received OPTION_CLIENT_DATA binding-status in received OPTION_CLIENT_DATA
binding-status or OPTION_IAPREFIX
in receiving FREE RESET binding-status in
server ACTIVE EXPIRED RELEASED FREE_BACKUP ABANDONED receiving server's FREE RESET
lease state DB ACTIVE EXPIRED RELEASED FREE-BACKUP ABANDONED
ACTIVE accept(4) time(2) time(1) time(2) accept ACTIVE accept(4) time(2) time(1) time(2) accept
EXPIRED time(1) accept accept accept accept EXPIRED time(1) accept accept accept accept
RELEASED time(1) time(1) accept accept accept RELEASED time(1) time(1) accept accept accept
FREE/FREE_BACKUP accept accept accept accept accept FREE/FREE-BACKUP accept accept accept accept accept
RESET time(3) accept accept accept accept RESET time(3) accept accept accept accept
ABANDONED reject reject reject reject accept ABANDONED reject reject reject reject accept
Figure 3: Conflict Resolution Figure 3: Conflict Resolution
time(1): If the time value in the OPTION_CLIENT_DATA is later than time(1): If the time value in the OPTION_CLIENT_DATA option or
the time value in the server's binding database, accept it, else OPTION_IAPREFIX option is later than the time value in the server's
reject it. binding database, accept it, else reject it.
time(2): If the current time is later than the receiving server's time(2): 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(3): If the OPTION_CLT_TIME value in the OPTION_CLIENT_DATA is time(3): If the OPTION_CLT_TIME value (if it appears) in the
later than the start-time-of-state in the receiving server's binding, OPTION_CLIENT_DATA is later than the start-time-of-state in the
accept it, else reject it. receiving server's binding, accept it, else reject it.
(1,2,3): If rejecting, use reject reason (1,2,3): If rejecting, use reject reason
"OutdatedBindingInformation". "OutdatedBindingInformation".
(4): If the client in an OPTION_CLIENT_DATA option and in a receiving (4): If the client in an OPTION_CLIENT_DATA option and in a receiving
server's binding differ, then if the receiving server is a secondary server's binding differ, then if the receiving server is a secondary
accept it, else reject it with a reject reason of accept it, else reject it with a reject reason of "AddressInUse".
"AddressInUseByOtherClient".
The lease update may be accepted or rejected. Rejection SHOULD NOT The lease update may be accepted or rejected. Rejection SHOULD NOT
change the flag in a lease that says that it should be transmitted to change the flag in a lease that says that it should be transmitted to
the failover partner. If this flag is set, then it should be the failover partner. If this flag is set, then it should be
transmitted, but if it is not already set, the rejection of a lease transmitted, but if it is not already set, the rejection of a lease
state update SHOULD NOT trigger an automatic update of the failover state update SHOULD NOT trigger an automatic update of the failover
partner sending the rejected update. The potential for update storms partner sending the rejected update. The potential for update storms
is too great, and in the unusual case where the servers simply can't is too great, and in the unusual case where the servers simply can't
agree, that disagreement is better than an update storm. agree, that disagreement is better than an update storm.
7.5.4. Accepting Updates 7.5.5. Accepting Updates
When the information in an OPTION_CLIENT_DATA option has been When the information in an OPTION_CLIENT_DATA option or
accepted, some of that information is stored in the receiving OPTION_IAPREFIX option has been accepted, some of that information is
server's binding database, and corresponding OPTION_CLIENT_DATA is stored in the receiving server's binding database, and corresponding
entered into a BNDACK. The information to enter into the a OPTION_CLIENT_DATA option or OPTION_IAPREFIX option is entered into
OPTION_CLIENT_DATA in the BNDACK is described in Section 7.6. a BNDACK. The information to enter into the OPTION_CLIENT_DATA
option or OPTION_IAPREFIX option in the BNDACK is described in
Section 7.6.
The information contained in the accepted OPTION_CLIENT_DATA option The information contained in an accepted OPTION_CLIENT_DATA option is
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 IA_NA or IA_PD options in the OPTION_CLIENT_DATA 3. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
option and for each of the OPTION_IADDR or OPTION_IAPREFIX option in the OPTION_CLIENT_DATA option and for each of the
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 1. OPTION_F_BINDING_STATUS is stored as the binding-status
2. OPTION_F_PARTNER_LIFETIME is stored in the expiration-time 2. OPTION_F_PARTNER_LIFETIME is stored in the expiration-time
3. OPTION_F_STATE_EXPIRATION_TIME is stored in the state- 3. OPTION_F_STATE_EXPIRATION_TIME is stored in the state-
expiration-time expiration-time
4. OPTION_F_CLT_TIME (which MUST NOT be converted with the 4. OPTION_F_CLT_TIME (which MUST NOT be converted with the
corrected-base-time, but MUST be converted with the raw value corrected-base-time, but MUST be converted with the raw value
from the OPTION_LQ_BASE_TIME) is stored in the partner-raw- from the OPTION_LQ_BASE_TIME) is stored in the partner-raw-
clt-time clt-time
skipping to change at page 49, line 25 skipping to change at page 54, line 22
clt-time clt-time
5. OPTION_F_PARTNER_RAW_CLT_TIME (which MUST NOT be corrected 5. OPTION_F_PARTNER_RAW_CLT_TIME (which MUST NOT be corrected
with the time-correction) replaces the client-last- with the time-correction) replaces the client-last-
transaction-time if it is later than the current client-last- transaction-time if it is later than the current client-last-
transaction-time. transaction-time.
6. OPTION_F_EXPIRATION_TIME replaces the partner-lifetime if it 6. 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
option is stored in the receiving server's binding database as
follows:
1. The IPv6 Prefix is used to find the prefix.
2. Inside of the IAprefix-options section:
1. OPTION_F_BINDING_STATUS is stored as the binding-status
2. OPTION_F_PARTNER_LIFETIME (if any) is stored in the
expiration-time
3. OPTION_F_STATE_EXPIRATION_TIME (if any) is stored in the
state-expiration-time
4. OPTION_F_EXPIRATION_TIME (if any) replaces the partner-
lifetime if it is later than the current partner-lifetime.
7.6. Sending Binding Acks 7.6. Sending Binding Acks
A server MUST respond to every BNDUPD message with a BNDACK message. A server MUST respond to every BNDUPD message with a BNDACK message.
The BNDACK message MUST contain an OPTION_CLIENT_DATA option The BNDACK message MUST contain an OPTION_CLIENT_DATA option if the
corresponding to every OPTION_CLIENT_DATA option in the BNDUPD BNDUPD message contained an OPTION_CLIENT_DATA option, or it MUST
message. The BNDACK message MUST have the same transaction-id as the contain an OPTION_IAPREFIX option if the BNDUPD message contained an
BNDUPD message to which it is a response. Each OPTION_CLIENT_DATA OPTION_IAPREFIX option. The BNDACK message MUST have the same
option MUST contain at least the data shown below in its client- transaction-id as the BNDUPD message to which it is a response.
options section:
Acceptance or rejection of all or a particular part of the BNDUPD
message is signaled with a OPTION_STATUS_CODE option. An
OPTION_STATUS_CODE option containing a status-code representing an
error is significant, while an OPTION_STATUS_CODE option whose
status-code contains success is considered informational but does not
affect the processing of the BNDACK message when it is received by
the server that sent the BNDUPD message.
Rejection of all or part of the information in a BNDUPD message is
signaled in a BNDACK message by use of the OPTION_STATUS_CODE 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
hierarchy, or the bottom level of the option hierarchy:
Entire BNDUPD: The OPTION_STATUS_CODE containing an error is
present in the outermost option of the BNDACK -- either the single
OPTION_CLIENT_DATA option or the single OPTION_IAPREFIX option.
An example of this sort of error might be that a VSS option was
present and specified a VPN that might not exist in the receiving
server.
Single address or prefix: The OPTION_STATUS_CODE containing an
error is present in a single IAADDR or IAPREFIX option which is
itself contained in an OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
option. An example of this sort of error might be that a
particular IPv6 address was specified in an IAADDR option that
doesn't appear in the receiving server's configuration.
Rejection present at either of these levels indicates rejection of
all of the information contained in the option (including any other
options contained in that option) where the OPTION_STATUS_CODE option
containing an error appears. The converse is not true -- an
OPTION_STATUS_CODE option containing success does not signify that
all of the contained information has been accepted.
If the BNDACK message contains an OPTION_CLIENT_DATA option, then the
OPTION_CLIENT_DATA option MUST contain at least the data 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 IPv6 address*; associated with this IPv6 address*;
o OPTION_IA_NA for an IPv6 Address or OPTION_IA_PD for an IPv6 o OPTION_VSS from the BNDUPD, if any.
Prefix. More than one of either of these options MAY appear if
there are more than one associated with this client;
* Inside of the IA_NA-options or IA_PD-option sections: 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
appear if there are more than one associated with this client;
* Inside of the IA_NA-options, IA_TA-options, or IA_PD-option
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; a 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.
If the information in the corresponding OPTION_IA_NA,
If the information in the corresponding OPTION_IA_TA, or OPTION_IA_PD option in the BNDUPD was
OPTION_CLIENT_DATA in the BNDACK was accepted, and no accepted, and no status message was required (which is
status message was required (which is the usual case), the usual case), no OPTION_STATUS_CODE option appears.
no OPTION_STATUS_CODE option appears.
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;
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;
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;
If the BNDACK message contains a top level OPTION_IAPREFIX option,
then the OPTION_IAPREFIX option MUST contain at least the data shown
below:
o IPv6 Prefix (with length);
o IAprefix-options:
* OPTION_VSS from the BNDUPD, if any.
* OPTION_STATUS_CODE containing an error code, or containing a
success code if a message is required. If the information in
the corresponding OPTION_IAPREFIX in the BNDUPD was accepted,
and no status message was required (which is the usual case),
no OPTION_STATUS_CODE option appears.
* OPTION_F_BINDING_STATUS containing the binding-status received
in the BNDACK;
* OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-
expiration-time received in the BNDACK;
* OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a
duplicate of the OPTION_F_PARTNER_LIFETIME received in the
BNDACK;
7.7. Receiving Binding Acks 7.7. Receiving Binding Acks
When a BNDACK is received each OPTION_CLIENT_DATA option is processed When a BNDACK is received the overall OPTION_CLIENT_DATA option or
separately, and each can either represent an ACK or a NAK. If a the overall OPTION_IAPREFIX option may contain an OPTION_STATUS_CODE
particular OPTION_CLIENT_DATA option does not contain an containing an error, representing an NAK of the entire BNDUPD. An
OPTION_STATUS_CODE option, or if there is an OPTION_STATUS_CODE enclosed OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD option may also
option which contains a success code, then the OPTION_CLIENT_DATA contain an OPTION_STATUS_CODE containing an error which indicates
option represents an acknowledgement (ACK) that the BNDUPD was a that everything in those options have been NAKed. Or an individual
success. IAADDR or IAPREFIX option may contain an OPTION_STATUS_CODE option
containing an error, indicating that the IAADDR or IAPREFIX option
has been NAKed. An OPTION_STATUS_CODE containing a success code has
no bearing on the ACK or NAK status of the BNDACK at any level.
Alternatively, the appearance of an OPTION_STATUS_CODE representing Receipt of a NAK (or a part of a BNDACK that is a NAK) requires no
an error in an OPTION_CLIENT_DATA option indicates a NAK of the processing other than remembering that it has been encountered.
BNDUPD represented by the OPTION_CLIENT_DATA.
The information contained in the BNDACK in an OPTION_CLIENT_DATA that The information contained in the BNDACK in an OPTION_CLIENT_DATA that
represents an ACK is stored with the appropriate client and lease, as represents an ACK is stored with the appropriate client and lease, as
follows: 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 IA_NA or IA_PD options in the OPTION_CLIENT_DATA 2. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
option and for each of the OPTION_IADDR or OPTION_IAPREFIX option in the OPTION_CLIENT_DATA option and for each of the
options: OPTION_IAADDR or OPTION_IAPREFIX options they contain:
1. OPTION_F_PARTNER_LIFETIME_SENT is stored in the acked- 1. OPTION_F_PARTNER_LIFETIME_SENT is stored in the acked-
partner-lifetime partner-lifetime
2. The time partner-lifetime is set to 0. 2. The time partner-lifetime is set to 0, to indicate that
nothing additional needs to be sent to the partner..
7.8. Acknowledging Reception Alternatively, the BNDACK may contain a top level OPTION_IAPREFIX
option, representing information concerning a single prefix lease.
If the IAprefix-options section of the OPTION_IAPREFIX option
contains an OPTION_STATUS_CODE representing an error, then it is
considered a NAK of the corresponding BNDUPD message. If the
OPTION_IAPREFIX option does not contain an OPTION_STATUS_CODE option
or if the OPTION_STATUS_CODE option contains a success status, then
the following information is stored in the lease state database, in
the section associated with the prefix lease represented by the
OPTION_IAPREFIX option.
Upon acceptance of a binding update, the server MUST notify its 1. OPTION_F_BINDING_STATUS containing the binding-status received in
partner that it updated its binding database by sending a BNDACK. A the BNDACK;
server MUST NOT send the BNDACK before its binding database is
updated.
7.9. BNDUPD/BNDACK Data Flow 2. OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-
expiration-time received in the BNDACK;
3. OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a duplicate
of the OPTION_F_PARTNER_LIFETIME received in the BNDACK;
7.8. BNDUPD/BNDACK Data Flow
The following diagram shows the relationship of the times described The following diagram shows the relationship of the times described
in Section 7.3 with the options used to transmit them. It also in Section 7.3 with the options used to transmit them. It also
relates the times on one failover partner to the other failover relates the times on 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
skipping to change at page 52, line 33 skipping to change at page 59, line 33
----------------------- BNDACK ------------------------------ ----------------------- BNDACK ------------------------------
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
STATE_EXPIRATION_TIME state-expiration-time (nothing to update) STATE_EXPIRATION_TIME state-expiration-time
------------------------------------------------------------- -------------------------------------------------------------
Figure 4: BNDUPD and BNDACK Time Handling Figure 4: BNDUPD and BNDACK 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 DHCPv6 client as well as dealing with changing request from a DHCP client as well as dealing with changing external
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 DHCPv6 client o Responsiveness -- the server is either responsive to DHCP client
requests or it is not. requests, it is renew responsive, or it is 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 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 has acked plus the MCLT (or not). partner has acked plus the MCLT (or not).
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 changes 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 following state transition diagram gives a condensed view of the
state machine. If there is a difference between the words describing state machine. If there is a difference between the words describing
a particular state and the diagram below, the words should be a particular state and the diagram below, the words should be
considered authoritative. considered authoritative.
In the diagram below, the word (responsive) or (unresponsive) appers In the diagram below, the word (responsive) (r-responsive) or
in the states, and refers to whether the server in this state is (unresponsive) appears in the states, and refers to whether the
allowed to respond to client DHCPv6 requests. server in this state is allowed to responsive, renew responsive, or
unresponsive respectively.
In the state transition diagram below, the "+" or "-" in the upper In the state transition diagram below, the "+", "-", or "*" in the
right corner of each state is a notation about whether communication upper right corner of each state is a notation about whether
is ongoing with the other server. communication is ongoing with the other server, with "+" meaning that
communications are ok, "-" meaning communications are interrupted,
and "*" meaning that communications may be 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 + +<--------------+ |
| +--+----------+-->+ (responsive) +-------External Command-->+ | +--+----------+-->+ pri: responsive +-------External Command-->+
| ^ ^ +--------+--------+ | | ^ ^ |sec: r-responsive| |
| | | +--------+--------+ |
| | | | | | | | | | | |
| Wait for Comm. OK Comm. Failed | | | Wait for Comm. OK Comm. Failed | External
| Other Other | | External | Other Other | | Command
| State: State: | | Command | State: State: Start Auto | or
| RECOVER-DONE NORMAL Start Safe Comm. OK or | RECOVER-DONE NORMAL Partner Down Comm. OK Auto
| | COMM. INT. Period Timer Other State: Safe | | COMM. INT. Timer Other State: Partner
| Comm. OK. | V All Others Period | 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 5: Failover Endpoint State Machine Figure 5: Failover Endpoint State Machine
8.2. State Machine Initialization 8.2. State Machine Initialization
skipping to change at page 55, line 20 skipping to change at page 62, line 20
o Current failover state. o Current failover state.
o Previous failover state. o Previous failover state.
o Start time of current failover state. o Start time of current failover state.
o Partner's failover state. o Partner's failover state.
o Start time of partner's failover state. o Start time of partner's failover state.
o Time most recent packet 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 packet received from partner: None until packet 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 5) because the processing during the state machine diagram (Figure 5) 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 DHCPv6 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 message and the previously
recorded failover state MUST be placed in the server-state option. recorded failover state MUST be placed in the server-state option.
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 following algorithm 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 algorithm description below. PREVIOUS-STATE is simply for
storage of a state, while CURRENT-STATE not only stores the current
state but also changes the current state of the failover endpoint to
whatever state is set into the CURRENT-STATE.
Step 1: Step 1:
If there is any record in stable storage of a previous failover state 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 for this server, set PREVIOUS-STATE to the last recorded value in
stable storage, and go to Step 2. stable storage, and go to Step 2.
If there is no record of any previous failover state in stable If there is no record of any previous failover state in stable
storage for this server, then set the PREVIOUS-STATE to RECOVER and 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 set the TIME-OF-FAILURE to 0. This will allow two servers which
already have lease information to synchronize themselves prior to already have lease information to synchronize themselves prior to
operating. operating.
In some cases, an existing server will be commissioned as a failover In some cases, an existing server will be commissioned as a failover
server and brought back into operation where its partner is not yet server and brought back into operation where its partner is not yet
available. In this case, the newly commissioned failover server will available. In this case, the newly commissioned failover server will
not operate until its partner comes online -- but it has operational not operate until its partner comes online -- but it has operational
responsibilities as a DHCPv6 server nonetheless. To properly handle responsibilities as a DHCP server nonetheless. To properly handle
this situation, a server SHOULD be configurable in such a way as to this situation, a server SHOULD be configurable in such a way as to
move directly into PARTNER-DOWN state after the startup period move directly into PARTNER-DOWN state after the startup period
expires if it has been unable to contact its partner during the expires if it has been unable to contact its partner during the
startup period. startup period.
Step 2: Step 2:
Implementations will differ in the ways that they deal with the state Implementations will differ in the ways that they deal with the state
machine for failover endpoint states. In many cases, state machine for failover endpoint states. In many cases, state
transitions will occur when communications goes from "OK" to failed, transitions will occur when communications goes from "OK" to failed,
or from failed to "OK", and some implementations will implement a or from failed to "OK", and some implementations will implement a
portion of their state machine processing based on these changes. portion of their state machine processing based on these changes.
In these cases, during startup, if the previous state is one where In these cases, during startup, if the PREVIOUS-STATE is one where
communications was "OK", then set the previous state to the state communications was "OK", then set the PREVIOUS-STATE to the state
that is the result of the communications failed state transition when that is the result of the communications failed state transition when
in that state (if such transition exists -- some states don't have a in that state (if such transition exists -- some states don't have a
communications failed state transition, since they allow both communications failed state transition, since they allow both
communications OK and failed). communications OK and failed).
Step 3: Step 3:
Start the STARTUP state timer. The time that a server remains in the Start the STARTUP state timer. The time that a server remains in the
STARTUP state (absent any communications with its partner) is STARTUP state (absent any communications with its partner) is
implementation dependent but SHOULD be short. It SHOULD be long implementation dependent but SHOULD be short. It SHOULD be long
skipping to change at page 57, line 29 skipping to change at page 64, line 35
If the server is a primary server: attempt to create a TCP connection 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 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 on the failover port and wait for the primary server to connect. See
Section 6.1. Section 6.1.
Step 5: Step 5:
Wait for "communications OK". Wait for "communications OK".
When and if communications become "OK", clear the STARTUP flag, and When and if communications become "OK", clear the STARTUP flag, and
set the current state to the PREVIOUS-STATE. set the CURRENT-STATE to the PREVIOUS-STATE.
If the partner is in PARTNER-DOWN state, and if the time at which it If the partner is in PARTNER-DOWN state, and if the time at which it
entered PARTNER-DOWN state (as received in the start-time-of-state entered PARTNER-DOWN state (as received in the start-time-of-state
option in the STATE message) is later than the last recorded time of 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 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 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 recorded time of operation of this server, then set CURRENT-STATE to
POTENTIAL-CONFLICT. POTENTIAL-CONFLICT.
Then, transition to the current state and take the "communications Then, transition to the CURRENT-STATE and take the "communications
OK" state transition based on the current state of this server and OK" state transition based on the CURRENT-STATE of this server and
the partner. the partner.
Step 6: Step 6:
If the startup time expires prior to communications becoming "OK", If the startup time expires prior to communications becoming "OK",
the server SHOULD transition to the PREVIOUS-STATE. the server SHOULD transition to the 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
skipping to change at page 58, line 24 skipping to change at page 65, line 27
is, indeed, down), or as a result of an optional auto-partner-down is, indeed, down), or as a result of an optional auto-partner-down
capability where PARTNER-DOWN state is entered automatically after a capability where PARTNER-DOWN state is entered automatically after a
server has been in COMMUNICATIONS-INTERRUPTED state for a pre- server has been in COMMUNICATIONS-INTERRUPTED state for a pre-
determined period of time. determined 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 if it
is primary or secondary. is primary or secondary.
It will allow renewal of all outstanding leases on all resources. It will allow renewal of all outstanding leases.
For those resources for which the server is using proportional For delegable prefixes it will allocate leases from its own pool, and
allocation (i.e. prefixes), it will allocate resources 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 IPv6 from the set of all available pools. Server MUST fully deplete its
addresses from the set of all available pools. 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) MUST NOT be allocated to a server (at entry to PARTNER-DOWN state) SHOULD NOT be allocated to a
new client until the MCLT beyond the entry into PARTNER-DOWN state client. If one elects to do so anyway, they MUST NOT be allocated to
a new client until the MCLT beyond the entry into PARTNER-DOWN state
has elapsed. has elapsed.
A server in PARTNER-DOWN state MUST NOT allocate a resource to a A server in PARTNER-DOWN state MUST NOT allocate a lease to a DHCP
DHCPv6 client different from that to which it was allocated at the client different from that to which it was allocated at the entrance
entrance to PARTNER-DOWN state until the MCLT beyond the maximum of to PARTNER-DOWN state until the MCLT beyond the maximum of the
the following times: client expiration time, most recently following times: client expiration time, most recently transmitted
transmitted partner-lifetime, most recently received ack of the partner-lifetime, most recently received ack of the partner-time from
partner-time from the partner, and most recently acked partner- the partner, and most recently acked partner-lifetime to the partner.
lifetime to the partner. If this time would be earlier than the If this time would be earlier than the current time plus the MCLT,
current time plus the MCLT, then the time the server entered PARTNER- then the time the server entered PARTNER-DOWN state plus the MCLT is
DOWN state plus the MCLT is used. used.
The server is not restricted by the MCLT when offering lease times The server is not restricted by the MCLT when offering valid
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 a
PARTNER-DOWN state, there is a chance of duplicate leases for the PARTNER-DOWN state, there is a chance of duplicate leases for the
same prefix to be assigned. This leads to a POTENTIAL-CONFLICT same prefix to be assigned. This leads to a POTENTIAL-CONFLICT
(unresponsive) state when they re-establish contact. The duplicate (unresponsive) state when they re-establish contact. The duplicate
lease issue can be postponed to a large extent by the server granting lease issue can be postponed to a large extent by the server granting
new leases first from its own pool. Therefore the server operating new leases first 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 pool.
skipping to change at page 62, line 46 skipping to change at page 69, line 46
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 unresponsive, but MAY A server in RECOVER-DONE state SHOULD be renew responsive, and MAY
respond to RENEW requests but MUST only change the state of resources respond to RENEW requests but MUST only change the state of lease
that appear in the RENEW request. It MUST NOT allocate any that appear in the RENEW request. It MUST NOT allocate any
additional resources when in RECOVER-DONE state. additional leases when in RECOVER-DONE state.
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, then it will
transition into NORMAL state. transition into NORMAL state.
If the partner server enters RECOVER or RECOVER-WAIT state, this
server transitions to COMMUNICATIONS-INTERRUPTED.
If the partner server enters POTENTIAL-CONFLICT state then this
server 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 bindings 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 resources state is a secondary server, then it will request delegable prefixes
(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
unresponsive 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:
Lease time calculations Valid lifetime calculations
As discussed in Section 4.4, the lease interval given to a DHCPv6 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 DHCPv6 client or the value the lease interval that it gives to a DHCP client or the value of
of the partner lifetime sent to its failover partner are the partner lifetime sent to its failover partner are
implementation dependent. implementation dependent.
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 DHCPv6 client request attempts to update the server servicing a DHCP client request attempts to update its
its partner with the new binding information. See Section 4.3. partner with the new binding information. See Section 4.3.
Reallocation of resources 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 BNDACK is received for this message, or EXPIRED. However, until a BNDACK is received for this message,
the resource cannot be allocated to another client. It cannot be the lease cannot be allocated to another client. It cannot be
allocated to the same client again if a BNDUPD was sent, otherwise allocated to the same client again if a BNDUPD was sent, otherwise
it can. See Section 4.2.2.1 for details. 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.4). 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 BNDACK message to its partner server (see Section 7.6). corresponding BNDACK message to its partner server (see 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 an external command is received by a server in NORMAL state
informing it that its partner is down, then transition into PARTNER- informing it that its partner is down, then transition into PARTNER-
DOWN state. Generally, this would be an unusual situation, where DOWN state. Generally, this would be an unusual situation, where
some external agency knew the partner server was down prior to the some external agency knew the partner server was down prior to the
failover server discovering it on its own. failover server discovering it on its own.
skipping to change at page 65, line 12 skipping to change at page 72, line 16
partner, the server should transition into COMMUNICATIONS-INTERRUPTED partner, the server should transition into COMMUNICATIONS-INTERRUPTED
state. 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 and COMMUNICATIONS-INTERRUPTED state as the network
connection between them fails and recovers, or as the partner server connection between them fails and recovers, or as the partner server
cycles between operational and non-operational. No duplicate cycles between operational and non-operational. No duplicate lease
resource allocation can occur while the servers cycle between these allocation can occur while the servers cycle between these states.
states.
When a server enters COMMUNICATIONS-INTERRUPTED state, if it has been When a server enters COMMUNICATIONS-INTERRUPTED state, if it has been
configured to support an automatic transition out of COMMUNICATIONS- configured to support an automatic transition out of COMMUNICATIONS-
INTERRUPTED state and into PARTNER-DOWN state (i.e., auto-partner- INTERRUPTED state and into PARTNER-DOWN state (i.e., auto-partner-
down has been configured), then a timer is started for the length of down has been configured), then a timer is started for the length of
the configured auto-partner-down period. the configured auto-partner-down period.
A server transitioning into the COMMUNICATIONS-INTERRUPTED state from A server transitioning into the COMMUNICATIONS-INTERRUPTED state from
the NORMAL state SHOULD raise some alarm condition to alert the NORMAL state SHOULD raise some alarm condition to alert
administrative staff to a potential problem in the DHCP subsystem. administrative staff to a potential problem in the DHCP subsystem.
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 DHCPv6 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 DHCPv6 client's current lease on a resource regardless renewal of a DHCP client's current lease regardless of whether that
of whether that lease was given out by the receiving server or not, lease was given out by the receiving server or not, although the
although the renewal period MUST NOT exceed the MCLT beyond the renewal period MUST NOT exceed the MCLT beyond the latest of: 1) the
latest of: 1) the partner lifetime already acknowledged by the other partner lifetime already acknowledged by the other server, or 2) now,
server, or 2) now, or 3) the partner lifetime received from the or 3) the partner lifetime received from the partner server.
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-client-lease-time, which would be unusual). greater than the desired-client-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.
skipping to change at page 67, line 50 skipping to change at page 74, line 50
Figure 7: Transition from NORMAL to COMMUNICATIONS-INTERRUPTED and Figure 7: Transition from NORMAL to COMMUNICATIONS-INTERRUPTED and
back 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 state that did not guarantee automatic reintegration would be a state that did not guarantee automatic reintegration would be
possible. In POTENTIAL-CONFLICT state the servers may determine that possible. In POTENTIAL-CONFLICT state the servers may determine that
the same resource has been offered and accepted by two different the same lease has been offered and accepted by two different
clients. clients.
It is a goal of this protocol to minimize the possibility that It is a goal of this protocol to minimize the possibility 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 which 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
DHCPv6 requests. DHCP requests.
8.10.2. Transition Out of POTENTIAL-CONFLICT State 8.10.2. Transition Out of POTENTIAL-CONFLICT State
If communications fails with the partner while in POTENTIAL-CONFLICT If communications fails with the partner 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
skipping to change at page 69, line 52 skipping to change at page 76, line 52
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
communications failed prior to completion of re-integration. communications failed prior to completion of re-integration.
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 DHCPv6 server that remains in service will not be able to process DHCP
client requests and there will be no DHCPv6 service available. The client requests and there will be no DHCP service available. The
RESOLUTION-INTERRUPTED state is the state that a server moves to if RESOLUTION-INTERRUPTED state is the state that a server moves to if
its partner disappears while it is in POTENTIAL-CONFLICT state. its partner disappears while it is in POTENTIAL-CONFLICT state.
When a server enters RESOLUTION-INTERRUPTED state it SHOULD raise an When a server enters RESOLUTION-INTERRUPTED state it SHOULD raise an
alarm condition to alert administrative staff of a problem in the alarm condition to alert administrative staff of a problem in the
DHCPv6 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 DHCPv6 client requests. In this state a server MUST respond to all DHCP client requests.
When allocating new resources, each server SHOULD allocate from its When allocating new leases, each server SHOULD allocate from its own
own pool (if that can be determined), where the primary SHOULD pool (if that can be determined), where the primary SHOULD allocate
allocate only FREE resources, and the secondary SHOULD allocate only only FREE leases, and the secondary SHOULD allocate only FREE-BACKUP
FREE_BACKUP resources. When responding to renewal requests, each leases. When responding to renewal requests, each server will allow
server will allow continued renewal of a DHCPv6 client's current continued renewal of a DHCP client's current lease independent of
lease independent of whether that lease was given out by the whether that lease was given out by the receiving server or not,
receiving server or not, although the renewal period MUST NOT exceed although the renewal period MUST NOT exceed the maximum client lead
the maximum client lead time (MCLT) beyond the latest of: 1) the time (MCLT) beyond the latest of: 1) the partner lifetime already
partner lifetime already acknowledged by the other server or 2) now acknowledged by the other server or 2) now or 3) partner lifetime
or 3) partner lifetime received from the partner server. 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 an external command is received by a server in RESOLUTION-
INTERRUPTED state informing it that its partner is down, it will INTERRUPTED state informing it that its partner is down, it will
transition immediately into PARTNER-DOWN state. transition immediately into PARTNER-DOWN state.
skipping to change at page 70, line 49 skipping to change at page 77, line 49
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 re-integrate with each other, the primary server
has received all of the updates from the secondary server. It makes has received all of the updates from the secondary server. It makes
a transition into CONFLICT-DONE state in order that it may be totally a transition into CONFLICT-DONE state in order that it may be totally
responsive to the client load. There is no operational difference responsive to the client load. There is no operational difference
between CONFLICT-DONE and NORMAL for primary as in both states it between CONFLICT-DONE and NORMAL for primary as in both states it
responds to all clients' requests. The distinction between CONFLICT- responds to all clients' requests. The distinction between CONFLICT-
DONE and NORMAL states will is necessary in the event that a load- DONE and NORMAL states is necessary in the event that a load-
balancing extension is ever defined. 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
DHCPv6 clients (similar to the situation in COMMUNICATIONS- DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED
INTERRUPTED state). state).
If communications fails, remain in CONFLICT-DONE state. If If communications fails, remain in CONFLICT-DONE state. If
communications becomes OK, remain in CONFLICT-DONE state until the communications becomes OK, remain in CONFLICT-DONE state until the
conditions for transition out become satisfied. conditions for transition out become satisfied.
8.12.2. Transition Out of CONFLICT-DONE State 8.12.2. Transition Out of CONFLICT-DONE State
If communications fails with the partner while in CONFLICT-DONE If communications fails with the partner while in CONFLICT-DONE
state, then the server will remain in CONFLICT-DONE state. 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. Dynamic DNS Considerations 9. DNS Update Considerations
DHCPv6 servers (and clients) can use DNS Dynamic Updates as described DHCP servers (and clients) can use DNS Updates as described in RFC
in RFC 2136 [RFC2136] to maintain DNS name-mappings as they maintain 2136 [RFC2136] to maintain DNS name-mappings as they maintain DHCP
DHCPv6 leases. Many different administrative models for DHCP-DNS 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 DHCPv6 servers and clients should follow in and guidelines that DHCP servers and clients should follow in
carrying them out, are laid out in RFC 4704 [RFC4704]. carrying them out, are laid out in RFC 4704 [RFC4704].
The nature of the failover protocol introduces some issues concerning The nature of the failover protocol introduces some issues concerning
dynamic DNS (DDNS) updates that are not part of non-failover DNS updates that are not part of non-failover environments. This
environments. This section describes these issues, and defines the section describes these issues, and defines the information which
information which failover partners should exchange in order to failover partners should exchange in order to ensure consistent
ensure consistent behavior. The presence of this section should not behavior. The presence of this section should not be interpreted as
be interpreted as requiring an implementation of the DHCPv6 failover requiring an implementation of the DHCPv6 failover protocol to also
protocol to also support DDNS updates. 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-DDNS 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 which support both protocols, not to introduce a new
requirement into the DHCPv6 failover protocol. Thus, a DHCPv6 server requirement into the DHCPv6 failover protocol. Thus, a DHCP server
which implements the failover protocol MAY also support dynamic DNS which implements the failover protocol MAY also support DNS updates,
updates, but if it does support dynamic DNS updates it SHOULD utilize but if it does support DNS updates it SHOULD utilize the techniques
the techniques described here in order to correctly distribute them described here in order to correctly distribute them between the
between the failover partners. See RFC 4704 [RFC4704] as well as RFC failover partners. See RFC 4704 [RFC4704] as well as RFC 4703
4703 [RFC4703] for information on how DHCPv6 servers deal with [RFC4703] for information on how DHCP servers deal with potential
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 DDNS protocol to update a DNS server a server which is utilizing the DNS update protocol to update a DNS
should not be a partner with a server which is not utilizing the DDNS server should not be a partner with a server which is not utilizing
protocol to update a DNS server. However, a server which is not able the DNS update protocol to update a DNS server. However, a server
to support DDNS or is not configured to support DDNS SHOULD output a which is not able to support DNS update or is not configured to
warning message when it receives BNDUPD messages which indicate that support DNS update SHOULD output a warning message when it receives
its failover partner is configured to support the DDNS protocol to BNDUPD messages which indicate that its failover partner is
update a DNS server. An implementation MAY consider this an error configured to support the DNS update protocol to update a DNS server.
and refuse to operate, or it MAY choose to operate anyway, having An implementation MAY consider this an error and refuse to accept the
warned the administrator of the problem in some way. BNDUPD by returning the status DNSUpdateNotSupported in an
OPTION_STATUS_CODE option in the BNDACK message, or it MAY choose to
operate anyway, having warned the administrator of the problem in
some way.
9.1. Relationship between failover and dynamic 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 DHCPv6 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
DHCPv6 client. An analogous set of conditions determines when a DHCP client. An analogous set of conditions determines when a
failover server should initiate a DDNS update, and when it should failover server should initiate a 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 which they obtained from one failover partner
even if they can only communicate with the other partner; allowing even if they can only communicate with the other partner; allowing
the secondary DHCPv6 server to grant new leases even if it is unable the secondary DHCP server to grant new leases even if it is unable to
to communicate with the primary server. The desired external DDNS communicate with the primary server. The desired external DNS update
behavior for DHCPv6 failover servers is similar to that described behavior for DHCPv6 failover servers is similar to that described
above for the failover protocol itself: above for the failover protocol itself:
1. Allow timely DDNS updates from the server which grants a lease to 1. Allow timely DNS updates from the server which grants a lease to
a client. Recognize that there is often a DDNS update lifecycle a client. Recognize that there is often a DNS update lifecycle
which parallels the DHCP lease lifecycle. This is likely to which 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 removal of DNS records when the leased resource is the removal of DNS records when the lease is subsequently made
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 DDNS 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 DDNS updates, where both failover 3. Avoid redundant or overlapping DNS updates, where both failover
servers are attempting to perform DDNS updates for the same servers are attempting to perform DNS updates for the same lease-
lease-client binding. client binding.
4. Avoid situations where one partner is attempting to add RRs 4. Avoid situations where one partner is attempting to add RRs
related to a lease binding while the other partner is attempting related to a lease binding while the other partner is attempting
to remove RRs related to the same lease binding. to remove RRs related to the same lease binding.
While DHCPv6 servers configured for DDNS typically perform these While DHCPv6 servers configured for DNS update typically perform
operations on both the AAAA and the PTR resource records, this is not these operations on both the AAAA and the PTR resource records, this
required. It is entirely possible that a DHCPv6 server could be is not required. It is entirely possible that a DHCPv6 server could
configured to only update the DNS with PTR records, and the DHCPv6 be configured to only update the DNS with PTR records, and the DHCPv6
clients could be responsible for updating the DNS with their own AAAA 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 DDNS Information 9.2. Exchanging DNS Update Information
In order for either server to be able to complete a DDNS update, or In order for either server to be able to complete a DNS update, or to
to remove DNS records which were added by its partner, both servers remove DNS records which were added by its partner, both servers need
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 DDNS 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 1. The FQDN that the client requested be associated with the lease.
resource. If the client doesn't request a particular FQDN and If the client doesn't request a particular FQDN and one is
one is synthesized by the failover server or if the failover synthesized by the failover server or if the failover server is
server is configured to replace a client requested FQDN with a configured to replace a client requested FQDN with a different
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 DDNS operations in progress or completed. 3. The status of and 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 resources 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 DDNS 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 DDNS The partner server receiving BNDUPD messages containing the DNS
information SHOULD compare the status information and the FQDN with update information SHOULD compare the status information and the FQDN
the current DDNS information it has associated with the lease with the current DNS update information it has associated with the
binding, and update its notion of the DDNS status accordingly. lease binding, and update its notion of the DNS update status
accordingly.
Some implementations will instead choose to send a BNDUPD without Some implementations will instead choose to send a BNDUPD without
waiting for the DDNS update to complete, and then will send a second waiting for the DNS update to complete, and then will send a second
BNDUPD once the DDNS update is complete. Other implementations will BNDUPD once the DNS update is complete. Other implementations will
delay sending the partner a BNDUPD until the DDNS update has been delay sending the partner a BNDUPD until the DNS update has been
acknowledged by the DNS server, or until some time-limit has elapsed, acknowledged by the DNS server, or until some time-limit has elapsed,
in order to avoid sending a second BNDUPD. in order to avoid sending a second BNDUPD.
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 an 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 or prefix value. The FQDN may be composed in any of several
ways, depending on server configuration and the information provided ways, depending on server configuration and the information provided
by the client in its DHCP messages. The client may supply a hostname by the client in its DHCP messages. The client may supply a hostname
which it would like the server to use in forming the FQDN, or it may which it would like the server to use in forming the FQDN, or it may
supply the entire FQDN. The server may be configured to attempt to supply the entire FQDN. The server may be configured to attempt to
use the information the client supplies, it may be configured with an use the information the client supplies, it may be configured with an
FQDN to use for the client, or it may be configured to synthesize an FQDN to 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 DDNS update at the time it sends the first BNDUPD about the lease the DNS update at the time it sends the first BNDUPD about the lease
binding, there may be cases where the FQDN in later BNDUPD messages binding, there may be cases where the FQDN in later BNDUPD messages
does not match the FQDN included in earlier messages. For example, does not match the FQDN included in earlier messages. For example,
the responsive server may be configured to handle situations where the responsive server may be configured to handle situations where
two or more DHCP client FQDNs are identical by modifying the most- two or more DHCP client FQDNs are identical by modifying the most-
specific label in the FQDNs of some of the clients in an attempt to specific label in the FQDNs of some of the clients in an attempt to
generate unique FQDNs for them (a process sometimes called generate unique FQDNs for them (a process sometimes called
"disambiguation"). Alternatively, at sites which use some or all of "disambiguation"). Alternatively, at sites which use some or all of
the information which clients supply to form the FQDN, it's possible the information which clients supply to form the FQDN, it's possible
that a client's configuration may be changed so that it begins to 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 which it originally added for the client,
and replacing them with records that refer to the client's new FQDN. and replacing them with records that refer to the client's new FQDN.
In such cases, the server SHOULD include the actual FQDN that was In such cases, the server SHOULD include the actual FQDN that was
used in subsequent DDNS options in any BNDUPD messages exchanged used in subsequent DNS update options in any BNDUPD messages
between the failover partners. This server SHOULD include relevant exchanged between the failover partners. This server SHOULD include
information in its BNDUPD messages. This information may be relevant 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. which 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 DDNS updates SHOULD A failover server which is going to perform DNS updates SHOULD
initiate the DDNS 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 DDNS server which did not grant the lease SHOULD NOT initiate a DNS update
update when it receives the BNDUPD after the lease has been granted. when it receives the BNDUPD after the lease has been granted. The
The failover protocol ensures that only one of the partners will failover protocol ensures that only one of the partners will grant a
grant a lease to any individual client, so it follows that this lease to any individual client, so it follows that this requirement
requirement will prevent both partners from initiating updates will prevent both partners from initiating updates simultaneously.
simultaneously. The server initiating the update SHOULD follow the The server initiating the update SHOULD follow the protocol in RFC
protocol in RFC 4704 [RFC4704]. The server may be configured to 4704 [RFC4704]. The server may be configured to perform a AAAA RR
perform a AAAA RR update on behalf of its clients, or not. update on behalf of its clients, or not. Ordinarily, a failover
Ordinarily, a failover server will not initiate DDNS updates when it server will not initiate DNS updates when it renews leases. In two
renews leases. In two cases, however, a failover server MAY initiate cases, however, a failover server MAY initiate a DNS update when it
a DDNS update when it renews a lease to its existing client: 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 DDNS 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. The server which updates when it next renews existing leases.
granted the lease is the server which should initiate the DDNS
update.
2. If a server is in PARTNER-DOWN state, it can conclude that its 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 DDNS 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 to PARTNER-DOWN state, it may perform this
in the background, or it MAY initiate this update upon next in the background, or it MAY initiate this update upon next
hearing from the DHCPv6 client. hearing from the DHCP client.
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
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
ensure that the DNS has information that corresponds correctly the
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 resource FREE* SHOULD initiate any The failover server which makes a lease PENDING-FREE SHOULD initiate
DDNS 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 resource FREE*" when it A server not in PARTNER-DOWN state "makes a lease PENDING-FREE" when
initiates a BNDUPD with a binding-status of FREE, FREE_BACKUP, it initiates a BNDUPD with a binding-status of FREE, FREE-BACKUP,
EXPIRED, or RELEASED. Its partner confirms this status by acking EXPIRED, or RELEASED. Its partner confirms this status by acking
that BNDUPD, and upon receipt of the BNDACK the server has "made the that BNDUPD, and upon receipt of the BNDACK the server has "made the
resource FREE*". Conversely, a server in PARTNER-DOWN state "makes a lease PENDING-FREE". Conversely, a server in PARTNER-DOWN state
resource FREE*" when it sets the binding-status to FREE, since in "makes a lease PENDING-FREE" when it sets the binding-status to FREE,
PARTNER-DOWN state no communications is required with the partner. since in PARTNER-DOWN state no communications is required with the
partner.
It is at this point that it should initiate the DDNS operations to It is at this point that it should initiate the DNS operations to
delete RRs from the DDNS. Its partner SHOULD NOT initiate DDNS delete RRs from the DNS. Its partner SHOULD NOT initiate DNS deletes
deletes for DNS records related to the lease binding as part of for DNS records related to the lease binding as part of sending the
sending the BNDACK message. The partner MAY have issued BNDUPD BNDACK message. The partner MAY have issued BNDUPD messages with a
messages with a binding-status of FREE, EXPIRED, or RELEASED binding-status of FREE, EXPIRED, or RELEASED previously, but the
previously, but the other server will have rejected these BNDUPD other server will have rejected these BNDUPD messages.
messages.
The failover protocol ensures that only one of the two partner The failover protocol ensures that only one of the two partner
servers will be able to make a resource FREE*. The server making the servers will be able to make a lease PENDING-FREE. The server making
resource FREE* may be doing so while it is in NORMAL communication the lease PENDING-FREE may be doing so while it is in NORMAL
with its partner, or it may be in PARTNER-DOWN state. If a server is communication with its partner, or it may be in PARTNER-DOWN state.
in PARTNER-DOWN state, it may be performing DDNS deletes for RRs If a server is in PARTNER-DOWN state, it may be performing DNS
which its partner added originally. This allows a single remaining deletes for RRs which its partner added originally. This allows a
partner server to assume responsibility for all of the DDNS activity single remaining partner server to assume responsibility for all of
which the two servers were undertaking. the DNS update activity which the two servers were undertaking.
Another implication of this approach is that no DDNS RR deletes will Another implication of this approach is that no 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 resource are moved into the FREE* state during that state, since no leases are moved into the PENDING-FREE state during
period. that period.
A failover server SHOULD ensure that a server failure while making a
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
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 DHCPv6 server is configured to return a name to the In some cases, a DHCP server is configured to return a name to the
DHCPv6 client but not enter that name into the DNS. This is DHCP client but not enter that name into the DNS. This is typically
typically a name that it has discovered or generated from information a name that it has discovered or generated from information it has
it has received from the client. In this case this name information received from the client. In this case this name information SHOULD
SHOULD be communicated to the failover partner, if only to ensure be communicated to the failover partner, if only to ensure that they
that they will return the same name in the event the partner becomes will return the same name in the event the partner becomes the server
the server to which the DHCPv6 client begins to interact. to 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 [RFC3315], Section 23 and [RFC3633],
Section 15 related to the server apply. Section 15 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 DHCPv6 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.
When operating in secure mode, TLS [RFC5246] is used to secure the When operating in secure mode, TLS [RFC5246] is used to secure the
connection. The recommendations in [RFC7525] SHOULD be followed when connection. The recommendations in [RFC7525] SHOULD be followed when
negotiating a TLS connection. negotiating a TLS connection.
skipping to change at page 77, line 11 skipping to change at page 84, line 25
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. document.
11. IANA Considerations 11. IANA Considerations
IANA is requested to create a new registry "DHCPv6 Failover Message
Types" in the registry maintained in http://www.iana.org/assignments/
dhcpv6-parameters, and assign the following initial value in that new
registry. These values should start at 20, in order to reduce the
chance of collisions with existing DHCPv4 Messages using the same
ports as DHCPv6 failover.
IANA is requested to assign values for the following new DHCPv6 IANA is requested to assign values for the following new DHCPv6
Message types in the registry maintained in Message types in the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters: http://www.iana.org/assignments/dhcpv6-parameters:
o BNDUPD (TBD1) o BNDUPD (TBD1)
o BNDACK (TBD2) o BNDACK (TBD2)
o POOLREQ (TBD3) o POOLREQ (TBD3)
skipping to change at page 77, line 45 skipping to change at page 85, line 18
o STATE (TBD11) o STATE (TBD11)
o CONTACT (TBD12) o CONTACT (TBD12)
IANA is requested to assign values for the following new DHCPv6 IANA is requested to assign values for the following new DHCPv6
Option codes in the registry maintained in Option codes in the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters: http://www.iana.org/assignments/dhcpv6-parameters:
OPTION_F_BINDING_STATUS (TBD13) OPTION_F_BINDING_STATUS (TBD13)
OPTION_F_DNS_REMOVAL_INFO (TBD14) OPTION_F_CONNECT_FLAGS (TBD14)
OPTION_F_FAILOVER_EXPIRE_TIME (TBD15) OPTION_F_DNS_REMOVAL_INFO (TBD15)
OPTION_F_MAX_UNACKED_BNDUPD (TBD16) OPTION_F_DNS_HOST_NAME (TBD16)
OPTION_F_MCLT (TBD17) OPTION_F_DNS_ZONE_NAME (TBD17)
OPTION_F_PARTNER_LIFETIME (TBD18)
OPTION_F_PARTNER_LIFETIME_SENT (TBD19) OPTION_F_DNS_FLAGS (TBD18)
OPTION_F_PARTNER_DOWN_TIME (TBD20) OPTION_F_EXPIRATION_TIME (TBD19)
OPTION_F_PARTNER_RAW_CLT_TIME (TBD21) OPTION_F_MAX_UNACKED_BNDUPD (TBD20)
OPTION_F_PROTOCOL_VERSION (TBD22) OPTION_F_MCLT (TBD21)
OPTION_F_RECEIVE_TIME (TBD23) OPTION_F_PARTNER_LIFETIME (TBD22)
OPTION_F_RECONFIGURE_DATA (TBD24) OPTION_F_PARTNER_LIFETIME_SENT (TBD23)
OPTION_F_RELATIONSHIP_NAME (TBD25) OPTION_F_PARTNER_DOWN_TIME (TBD24)
OPTION_F_SERVER_FLAGS (TBD26) OPTION_F_PARTNER_RAW_CLT_TIME (TBD25)
OPTION_F_SERVER_STATE (TBD27) OPTION_F_PROTOCOL_VERSION (TBD26)
OPTION_F_START_TIME_OF_STATE (TBD28) OPTION_F_RECEIVE_TIME (TBD27)
OPTION_F_STATE_EXPIRATION_TIME (TBD29) OPTION_F_RECONFIGURE_DATA (TBD28)
OPTION_F_RELATIONSHIP_NAME (TBD29)
OPTION_F_SERVER_FLAGS (TBD30)
OPTION_F_SERVER_STATE (TBD31)
OPTION_F_START_TIME_OF_STATE (TBD32)
OPTION_F_STATE_EXPIRATION_TIME (TBD33)
IANA is requested to assign values for the following new DHCPv6 IANA is requested to assign values for the following new DHCPv6
Status codes in the registry maintained in Status codes in the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters: http://www.iana.org/assignments/dhcpv6-parameters:
AddressInUseByOtherClient (TBD30) AddressInUse (TBD34)
ConfigurationConflict (TBD31) ConfigurationConflict (TBD35)
MissingBindingInformation (TBD32) MissingBindingInformation (TBD36)
OutdatedBindingInformation (TBD33) OutdatedBindingInformation (TBD37)
ServerShuttingDown (TBD34) ServerShuttingDown (TBD38)
DNSUpdateNotSupported (TBD39)
12. Acknowledgements 12. Acknowledgements
This document extensively uses concepts, definitions and other parts This document extensively uses concepts, definitions and other parts
of an effort to document failover for DHCPv4. Authors would like to of an effort to document failover for DHCPv4. Authors would like to
thank Shawn Routher, Greg Rabil, Bernie Volz and Marcin Siodelski for thank Shawn Routher, Greg Rabil, Bernie Volz and Marcin Siodelski for
their significant involvement and contributions. Authors would like their significant involvement and contributions. In particular,
to thank VithalPrasad Gaitonde, Krzysztof Gierlowski, Krzysztof Bernie Volz and Shawn Routher provided detailed and substantive
Nowicki and Michal Hoeft for their insightful comments. technical reviews of the draft. Authors would like to thank
VithalPrasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki and
This work has been partially supported by Department of Computer Michal Hoeft for their insightful comments.
Communications (a division of Gdansk University of Technology) and
the Polish Ministry of Science and Higher Education under the
European Regional Development Fund, Grant No.
POIG.01.01.02-00-045/09-00 (Future Internet Engineering Project).
13. References 13. References
13.1. Normative References 13.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
skipping to change at page 80, line 14 skipping to change at page 87, line 44
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
DOI 10.17487/RFC5460, February 2009, DOI 10.17487/RFC5460, February 2009,
<http://www.rfc-editor.org/info/rfc5460>. <http://www.rfc-editor.org/info/rfc5460>.
[RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet
Selection Options for DHCPv4 and DHCPv6", RFC 6607,
DOI 10.17487/RFC6607, April 2012,
<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, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 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>.
 End of changes. 412 change blocks. 
1060 lines changed or deleted 1426 lines changed or added

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