draft-ietf-dhc-dhcpv6-failover-protocol-01.txt   draft-ietf-dhc-dhcpv6-failover-protocol-02.txt 
Dynamic Host Configuration (DHC) T. Mrugalski Dynamic Host Configuration (DHC) T. Mrugalski
Internet-Draft ISC Internet-Draft ISC
Intended status: Standards Track K. Kinnear Intended status: Standards Track K. Kinnear
Expires: June 26, 2016 Cisco Expires: January 1, 2017 Cisco
December 24, 2015 June 30, 2016
DHCPv6 Failover Protocol DHCPv6 Failover Protocol
draft-ietf-dhc-dhcpv6-failover-protocol-01 draft-ietf-dhc-dhcpv6-failover-protocol-02
Abstract Abstract
DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" (RFC3315) does not offer server redundancy. This document (DHCPv6)" (RFC3315) does not offer server redundancy. This document
defines a protocol implementation to provide for DHCPv6 failover, a defines a protocol implementation to provide DHCPv6 failover, a
mechanism for running two servers on the same network with the mechanism for running two servers on the same network with the
capability for either server to take over clients' leases in case of capability for either server to take over clients' leases in case of
server failure or network partition. It meets the requirements for server failure or network partition. It meets the requirements for
DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC7031). 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 June 26, 2016. This Internet-Draft will expire on January 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
4.2.1. Independent Allocation . . . . . . . . . . . . . . . 9 4.2.1. Independent Allocation . . . . . . . . . . . . . . . 9
4.2.2. Proportional Allocation . . . . . . . . . . . . . . . 10 4.2.2. Proportional Allocation . . . . . . . . . . . . . . . 10
4.3. Lazy Updates . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Lazy Updates . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Maximum Client Lead Time (MCLT) . . . . . . . . . . . . . 13 4.4. Maximum Client Lead Time (MCLT) . . . . . . . . . . . . . 13
4.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . 14 4.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . 14
5. Message and Option Definitions . . . . . . . . . . . . . . . 16 5. Message and Option Definitions . . . . . . . . . . . . . . . 16
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 16 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 16
5.2. Failover Message Format . . . . . . . . . . . . . . . . . 16 5.2. Failover Message Format . . . . . . . . . . . . . . . . . 16
5.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. BNDUPD . . . . . . . . . . . . . . . . . . . . . . . 17 5.3.1. BNDUPD . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.2. BNDACK . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.2. BNDREPLY . . . . . . . . . . . . . . . . . . . . . . 18
5.3.3. POOLREQ . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.3. POOLREQ . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.4. POOLRESP . . . . . . . . . . . . . . . . . . . . . . 18 5.3.4. POOLRESP . . . . . . . . . . . . . . . . . . . . . . 18
5.3.5. UPDREQ . . . . . . . . . . . . . . . . . . . . . . . 18 5.3.5. UPDREQ . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.6. UPDREQALL . . . . . . . . . . . . . . . . . . . . . . 18 5.3.6. UPDREQALL . . . . . . . . . . . . . . . . . . . . . . 18
5.3.7. UPDDONE . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.7. UPDDONE . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.8. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.8. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.9. CONNECTACK . . . . . . . . . . . . . . . . . . . . . 19 5.3.9. CONNECTREPLY . . . . . . . . . . . . . . . . . . . . 19
5.3.10. DISCONNECT . . . . . . . . . . . . . . . . . . . . . 19 5.3.10. DISCONNECT . . . . . . . . . . . . . . . . . . . . . 19
5.3.11. STATE . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.11. STATE . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.12. CONTACT . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.12. CONTACT . . . . . . . . . . . . . . . . . . . . . . . 19
5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.4. Transaction Id . . . . . . . . . . . . . . . . . . . . . 20
5.4.1. OPTION_F_BINDING_STATUS . . . . . . . . . . . . . . . 20 5.5. Options . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4.2. OPTION_F_CONNECT_FLAGS . . . . . . . . . . . . . . . 20 5.5.1. OPTION_F_BINDING_STATUS . . . . . . . . . . . . . . . 20
5.4.3. OPTION_F_DNS_REMOVAL_INFO . . . . . . . . . . . . . . 21 5.5.2. OPTION_F_CONNECT_FLAGS . . . . . . . . . . . . . . . 21
5.4.4. OPTION_F_DNS_HOST_NAME . . . . . . . . . . . . . . . 22 5.5.3. OPTION_F_DNS_REMOVAL_INFO . . . . . . . . . . . . . . 22
5.4.5. OPTION_F_DNS_ZONE_NAME . . . . . . . . . . . . . . . 22 5.5.4. OPTION_F_DNS_HOST_NAME . . . . . . . . . . . . . . . 23
5.4.6. OPTION_F_DNS_FLAGS . . . . . . . . . . . . . . . . . 23 5.5.5. OPTION_F_DNS_ZONE_NAME . . . . . . . . . . . . . . . 23
5.4.7. OPTION_F_EXPIRATION_TIME . . . . . . . . . . . . . . 24 5.5.6. OPTION_F_DNS_FLAGS . . . . . . . . . . . . . . . . . 24
5.4.8. OPTION_F_MAX_UNACKED_BNDUPD . . . . . . . . . . . . . 25 5.5.7. OPTION_F_EXPIRATION_TIME . . . . . . . . . . . . . . 25
5.4.9. OPTION_F_MCLT . . . . . . . . . . . . . . . . . . . . 25 5.5.8. OPTION_F_MAX_UNACKED_BNDUPD . . . . . . . . . . . . . 26
5.4.10. OPTION_F_PARTNER_LIFETIME . . . . . . . . . . . . . . 26 5.5.9. OPTION_F_MCLT . . . . . . . . . . . . . . . . . . . . 26
5.4.11. OPTION_F_PARTNER_LIFETIME_SENT . . . . . . . . . . . 26 5.5.10. OPTION_F_PARTNER_LIFETIME . . . . . . . . . . . . . . 27
5.4.12. OPTION_F_PARTNER_DOWN_TIME . . . . . . . . . . . . . 27 5.5.11. OPTION_F_PARTNER_LIFETIME_SENT . . . . . . . . . . . 27
5.4.13. OPTION_F_PARTNER_RAW_CLT_TIME . . . . . . . . . . . . 28 5.5.12. OPTION_F_PARTNER_DOWN_TIME . . . . . . . . . . . . . 28
5.4.14. OPTION_F_PROTOCOL_VERSION . . . . . . . . . . . . . . 28 5.5.13. OPTION_F_PARTNER_RAW_CLT_TIME . . . . . . . . . . . . 29
5.4.15. OPTION_F_RECEIVE_TIME . . . . . . . . . . . . . . . . 29 5.5.14. OPTION_F_PROTOCOL_VERSION . . . . . . . . . . . . . . 29
5.4.16. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 29 5.5.15. OPTION_F_KEEPALIVE_TIME . . . . . . . . . . . . . . . 30
5.4.17. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 30 5.5.16. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 30
5.4.18. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 31 5.5.17. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 31
5.4.19. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 32 5.5.18. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 32
5.4.20. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 33 5.5.19. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 33
5.4.21. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 34 5.5.20. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 34
5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 35 5.5.21. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 35
6. Connection Management . . . . . . . . . . . . . . . . . . . . 36 5.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 36
6.1. Creating Connections . . . . . . . . . . . . . . . . . . 36 6. Connection Management . . . . . . . . . . . . . . . . . . . . 37
6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 37 6.1. Creating Connections . . . . . . . . . . . . . . . . . . 37
6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 37 6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 38
6.1.3. Receiving a CONNECTACK message . . . . . . . . . . . 38 6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 38
6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 39 6.1.3. Receiving a CONNECTREPLY message . . . . . . . . . . 39
6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 40 6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 40
6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 40 6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 41
6.5. Connection Maintenance Parameters . . . . . . . . . . . . 41 6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 41
6.6. Unreachability detection . . . . . . . . . . . . . . . . 42 6.5. Connection Maintenance Parameters . . . . . . . . . . . . 42
7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 42 6.6. Unreachability detection . . . . . . . . . . . . . . . . 43
7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 42 7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 43
7.2. Information model . . . . . . . . . . . . . . . . . . . . 43 7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3. Times Required for Exchanging Binding Updates . . . . . . 46 7.2. Information model . . . . . . . . . . . . . . . . . . . . 44
7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 47 7.3. Times Required for Exchanging Binding Updates . . . . . . 47
7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 50 7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 48
7.5.1. Monitoring Time Skew . . . . . . . . . . . . . . . . 50 7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 51
7.5.2. Acknowledging Reception . . . . . . . . . . . . . . . 50 7.5.1. Monitoring Time Skew . . . . . . . . . . . . . . . . 51
7.5.3. Processing Binding Updates . . . . . . . . . . . . . 51 7.5.2. Acknowledging Reception . . . . . . . . . . . . . . . 52
7.5.4. Accept or Reject? . . . . . . . . . . . . . . . . . . 51 7.5.3. Processing Binding Updates . . . . . . . . . . . . . 52
7.5.5. Accepting Updates . . . . . . . . . . . . . . . . . . 53 7.5.4. Accept or Reject? . . . . . . . . . . . . . . . . . . 53
7.6. Sending Binding Acks . . . . . . . . . . . . . . . . . . 54 7.5.5. Accepting Updates . . . . . . . . . . . . . . . . . . 55
7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 57 7.6. Sending Binding Replies . . . . . . . . . . . . . . . . . 56
7.8. BNDUPD/BNDACK Data Flow . . . . . . . . . . . . . . . . . 58 7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 58
8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 59 7.8. BNDUPD/BNDREPLY Data Flow . . . . . . . . . . . . . . . . 59
8.1. State Machine Operation . . . . . . . . . . . . . . . . . 59 8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 60
8.2. State Machine Initialization . . . . . . . . . . . . . . 62 8.1. State Machine Operation . . . . . . . . . . . . . . . . . 60
8.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 62 8.2. State Machine Initialization . . . . . . . . . . . . . . 64
8.3.1. Operation in STARTUP State . . . . . . . . . . . . . 63 8.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 64
8.3.2. Transition Out of STARTUP State . . . . . . . . . . . 63 8.3.1. Operation in STARTUP State . . . . . . . . . . . . . 65
8.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 65 8.3.2. Transition Out of STARTUP State . . . . . . . . . . . 65
8.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 65 8.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 67
8.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 66 8.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 67
8.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 66 8.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 68
8.5.1. Operation in RECOVER State . . . . . . . . . . . . . 67 8.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 68
8.5.2. Transition Out of RECOVER State . . . . . . . . . . . 67 8.5.1. Operation in RECOVER State . . . . . . . . . . . . . 69
8.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 68 8.5.2. Transition Out of RECOVER State . . . . . . . . . . . 69
8.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 69 8.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 70
8.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 69 8.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 71
8.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 69 8.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 71
8.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 69
8.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 70 8.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 71
8.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 70 8.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 71
8.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 70 8.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 72
8.8.2. Transition Out of NORMAL State . . . . . . . . . . . 71 8.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 72
8.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 72 8.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 72
8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 72 8.8.2. Transition Out of NORMAL State . . . . . . . . . . . 73
8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 73 8.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 74
8.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 74 8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 74
8.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 75 8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 75
8.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 75 8.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 76
8.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 76 8.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 77
8.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 77 8.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 77
8.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 77 8.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 78
8.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 77 8.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 79
8.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 78 8.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 79
8.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 78 8.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 79
9. DNS Update Considerations . . . . . . . . . . . . . . . . . . 78 8.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 80
9.1. Relationship between failover and DNS update . . . . . . 79 8.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 80
9.2. Exchanging DNS Update Information . . . . . . . . . . . . 80 9. DNS Update Considerations . . . . . . . . . . . . . . . . . . 80
9.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . . 82 9.1. Relationship between failover and DNS update . . . . . . 81
9.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . . 82 9.2. Exchanging DNS Update Information . . . . . . . . . . . . 82
9.5. Name Assignment with No Update of DNS . . . . . . . . . . 83 9.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . . 84
10. Security Considerations . . . . . . . . . . . . . . . . . . . 83 9.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . . 84
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 9.5. Name Assignment with No Update of DNS . . . . . . . . . . 85
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 85
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
13.1. Normative References . . . . . . . . . . . . . . . . . . 86 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 88
13.2. Informative References . . . . . . . . . . . . . . . . . 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 88
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88 13.1. Normative References . . . . . . . . . . . . . . . . . . 88
13.2. Informative References . . . . . . . . . . . . . . . . . 90
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction 1. Introduction
The failover protocol provides a means for cooperating DHCP servers The failover protocol provides a means for cooperating DHCP servers
to work together to provide a DHCP service with availability that is to work together to provide a DHCP service with availability that is
increased beyond that which could be provided by a single DHCP server increased beyond that which could be provided by a single DHCP server
operating alone. It is designed to protect DHCP clients against operating alone. It is designed to protect DHCP clients against
server unreachability, including server failure and network server unreachability, including server failure and network
partition. It is possible to deploy exactly two servers that are partition. It is possible to deploy exactly two servers that are
able to continue providing a lease for an IPv6 address [RFC3315] or able to continue providing a lease for an IPv6 address [RFC3315] or
skipping to change at page 5, line 51 skipping to change at page 6, line 4
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 Available (Lease or Prefix) o Available (Lease or Prefix)
A lease or delegable prefix is available if it could be allocated A lease or delegable prefix is available if it could be allocated
for use by a DHCP client. It is available on the main server when for use by a DHCP client. It is available on the main server when
it is in FREE state and available on the secondary server when it it is in FREE state and available on the secondary server when it
is in the BACKUP state. Sometimes the term "available" is used is in the FREE-BACKUP state. Sometimes the term "available" is
when it would be awkward to say "FREE on the primary server and used when it would be awkward to say "FREE on the primary server
BACKUP on the secondary server". and FREE-BACKUP on the secondary server".
o Binding Status o Binding-Status
A lease can hold a variety of states (see Section 5.4.1 for a A lease can hold a variety of states (see Section 5.5.1 for a
list) and these are also referred to as the binding-status of the list) and these are also referred to as the binding-status of the
lease. lease.
o Delegable Prefix o Delegable Prefix
A prefix from which other prefixes may be delegated, as described A prefix from which other prefixes may be delegated, as described
in [RFC3633]. A prefix which has been delegated is known as a in [RFC3633]. A prefix which has been delegated is known as a
"delegated prefix" or a "prefix lease". "delegated prefix" or a "prefix lease".
o Delegated Prefix o Delegated Prefix
skipping to change at page 8, line 29 skipping to change at page 8, line 29
'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 State o State
The term state is used in two ways in this document. A failover The term state is used in two ways in this document. A failover
endpoint is always in some state, and there are a series of states endpoint is always in some state, and there are a series of states
that a failover endpoint can move through. See Section 8 for that a failover endpoint can move through. See Section 8 for
details of the failover endpoint states. A lease also has a details of the failover endpoint states. A lease also has a
state, and this is sometimes referred to as a binding-status. See state, and this is sometimes referred to as a binding-status. See
Section 5.4.1 for a list of the states a lease can hold. Section 5.5.1 for a list of the states a lease can hold.
o Time Context o Time Context
Each failover server has a clock and a definite idea of the Each failover server has a clock and a definite idea of the
current universal time. Each server's idea of the current time is current universal time. Each server's idea of the current time is
considered its time context. considered its time context.
o Unresponsive o Unresponsive
A server that is unresponsive will not respond to DHCP client A server that is unresponsive will not respond to DHCP client
skipping to change at page 9, line 16 skipping to change at page 9, line 16
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, one for Currently there are two allocation algorithms defined, one for
address leases and one for prefix leases. address leases and one for prefix leases.
4.2.1. Independent Allocation 4.2.1. Independent Allocation
In this allocation scheme, used for allocating individual DHCP IPv6 In this allocation scheme, used for allocating individual 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 server to know which IPv6 require a message exchange for each server to know which IPv6
addresses it has been allocated. This algorithm is simpler than addresses it has been allocated. This algorithm is simpler than
proportional allocation since it does not require a rebalancing proportional allocation since it does not require a rebalancing
mechanism. It also assumes that the pool assigned to each server mechanism. It also assumes that the pool assigned to each server
will never deplete. 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 lease or its lease on an IPv6 to clients. Once a client releases a lease or its lease on an IPv6
address expires, the returned IPv6 address returns to the pool for address expires, the returned IPv6 address returns to the pool for
the server that leased it. A lease on an IPv6 address can be renewed the server that leased it. A lease on an IPv6 address can be renewed
by a responsive server or by a renew responsive server. When an IPv6 by a responsive server or by a renew responsive server. When an IPv6
address goes PENDING-FREE Section 7.2 it is owned by whichever server address goes PENDING-FREE (see Section 7.2) it is owned by whichever
it is allocated to by the independent allocation algorithm. server it is allocated to by the independent allocation algorithm.
IPv6 addresses (which use the independent allocation approach) are IPv6 addresses (which use the independent allocation approach) 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 address leases as requested by clients. An extending existing address leases as requested by clients. An
operational partner MUST NOT lease IPv6 addresses that were assigned operational partner MUST NOT lease IPv6 addresses that were assigned
to its downed partner and later expired or were released or declined to its downed partner and later expired or were released or declined
by a client unless it is in PARTNER-DOWN state. When it is in by a client. When it is in PARTNER-DOWN state, a server MUST
PARTNER-DOWN state, a server SHOULD allocate from its own pool. It allocate new leases from its own pool. It MUST NOT use its partner's
SHOULD NOT use its partner's pool. pool to allocate new leases.
4.2.1.1. Independent Allocation Algorithm 4.2.1.1. Independent Allocation Algorithm
For each address that can be allocated, the primary server MUST For each address that can be allocated, the primary server MUST
allocate only IPv6 addresses when the low-order bit (i.e., bit 127) allocate only IPv6 addresses when the low-order bit (i.e., bit 127)
is equal to 1, and the secondary server MUST allocate only the IPv6 is equal to 1, and the secondary server MUST allocate only the IPv6
addresses when the low-order bit (i.e., bit 127) is equal to 0. addresses when the low-order bit (i.e., bit 127) is equal to 0.
4.2.2. Proportional Allocation 4.2.2. Proportional Allocation
skipping to change at page 12, line 25 skipping to change at page 12, line 25
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), the expiration-time, and the entry to the partner-lifetime (if any), the expiration-time, and the entry to
PARTNER-DOWN time plus the MCLT. PARTNER-DOWN time plus the MCLT.
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 BNDREPLY message) that its partner is aware that the first client is
not using the lease. not using the lease.
Specifically, an "available" delegable prefix on a server may be Specifically, an "available" delegable prefix on a server may be
allocated to any client. A prefix which was delegated (leased) to a allocated to any client. A prefix which was delegated (leased) to a
client and which expired or was released by that client would take on client and which expired or was released by that client would take on
a new state, EXPIRED or RELEASED respectively. The partner server a new state, EXPIRED or RELEASED respectively. The partner server
would then be notified that this delegated prefix was EXPIRED or would then be notified that this delegated prefix was EXPIRED or
RELEASED through a BNDUPD. When the sending server received the RELEASED through a BNDUPD. When the sending server received the
BNDACK for that delegated prefix showing it was FREE, it would move BNDREPLY for that delegated prefix showing it was FREE, it would move
the lease from EXPIRED or RELEASED to FREE, and it would be available the lease from EXPIRED or RELEASED to FREE, and it would be available
for allocation 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 regarding the delegated prefix to its partner. sent a BNDUPD message regarding the delegated prefix to its partner.
This situation would exist if the prefix lease expired or was This situation would exist if the prefix lease expired or was
released after the transition into PARTNER-DOWN state, for instance. released after the transition into PARTNER-DOWN state, for instance.
4.3. Lazy Updates 4.3. Lazy Updates
skipping to change at page 13, line 17 skipping to change at page 13, line 17
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 DHCP client with a particular valid lifetime 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 DHCP believe that the client's lease has expired -- even though the DHCP
client still retains a valid lease on that address or prefix. It is client still retains a valid lease on that address or prefix. It is
also possible that the failover partner will have no record at all of also possible that the failover partner will have no record at all of
the lease to the DHCP client. Both of these issues are dealt with by the lease being assigned to the DHCP client. Both of these issues
use of the MCLT when allocating or extending leases (see are dealt with by use of the MCLT when allocating or extending leases
Section 4.4). (see Section 4.4).
4.4. Maximum Client Lead Time (MCLT) 4.4. Maximum Client Lead Time (MCLT)
In order to handle problems introduced by lazy updates (see In order to handle problems introduced by lazy updates (see
Section 4.3), a period of time known as the "Maximum Client Lead Section 4.3), a period of time known as the "Maximum Client Lead
Time" (MCLT) is defined and must be known to both the primary and Time" (MCLT) is defined and must be known to both the primary 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 valid lifetime provided bound on the difference allowed between the valid lifetime provided
to a DHCP client by a server and the valid lifetime known by that to a DHCP client by a server and the valid lifetime known by that
server's failover partner. server's failover partner.
skipping to change at page 14, line 34 skipping to change at page 14, line 34
The actual lifetime is the lease interval that a DHCP server gives The actual lifetime is the lease interval that a DHCP server gives
out to a DHCP client. It may be shorter than the desired lifetime out to a DHCP client. It may be shorter than the desired lifetime
(as explained below). (as explained below).
partner lifetime: partner lifetime:
The partner lifetime is the lease expiration interval the local The partner lifetime is the lease expiration interval the local
server tells to its partner in a BNDUPD message. server 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 BNDREPLY
message.
4.4.1. MCLT example 4.4.1. MCLT example
The following example demonstrates the MCLT concept in practice. The The following example demonstrates the MCLT concept in practice. The
values used are arbitrarily chosen and are not a recommendation for values used are arbitrarily chosen and are not a recommendation for
actual values. The MCLT in this case is 1 hour. The desired actual values. The MCLT in this case is 1 hour. The desired
lifetime is 3 days, and its renewal time is half the lifetime. lifetime is 3 days, and its renewal time is half the lifetime.
When a server makes an offer for a new lease on an IPv6 address to a When a server makes an offer for a new lease on an IPv6 address to a
DHCP client, it determines the desired lifetime (in this case, 3 DHCP client, it determines the desired lifetime (in this case, 3
skipping to change at page 15, line 12 skipping to change at page 15, line 14
partner lifetime (i.e. zero) plus the MCLT. Thus, the actual partner lifetime (i.e. zero) plus the MCLT. Thus, the actual
lifetime is 1 hour (the MCLT). lifetime is 1 hour (the MCLT).
Once the server has sent the REPLY to the DHCP client, it will update Once the server has sent the REPLY to the DHCP client, it will update
its failover partner with the lease information using a BNDUPD its failover partner with the lease information using a BNDUPD
message. 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 BNDREPLY to its update of the
secondary server's (partner's) partner lifetime, it records that as secondary server's (partner's) partner lifetime, it records that as
the acknowledged partner lifetime. A server MUST NOT send a BNDACK the acknowledged partner lifetime. A server MUST NOT send a BNDREPLY
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.5.2. Thus, the primary server in this case can be sure Section 7.5.2. Thus, the primary server in this case can be sure
that the secondary server has recorded the partner lease interval in that the secondary server has recorded the partner lease interval in
its stable storage when the primary server receives a BNDACK message its stable storage when the primary server receives a BNDREPLY
from the secondary server. message from the secondary server.
When the DHCP client attempts to renew at T1 (approximately one half When the DHCP client attempts to renew at T1 (approximately one 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
skipping to change at page 18, line 7 skipping to change at page 18, line 7
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. At most one OPTION_CLIENT_DATA option lease changes to the partner. At most one OPTION_CLIENT_DATA option
may appear in a BNDUPD message. Note that not all data in a BNDUPD may appear in a BNDUPD message. Note that not all data in a BNDUPD
is sent in an OPTION_CLIENT_DATA option. Information about delegable is sent in an OPTION_CLIENT_DATA option. Information about delegable
prefixes not currently allocated to a particular client is sent in prefixes not currently allocated to a particular client is sent in
BNDUPD messages but not within OPTION_CLIENT_DATA options. The BNDUPD messages but not within OPTION_CLIENT_DATA options. The
partner is expected to respond with a BNDACK message. partner is expected to respond with a BNDREPLY message.
5.3.2. BNDACK 5.3.2. BNDREPLY
The binding acknowledgement message BNDACK (TBD2) is used for The binding acknowledgement message BNDREPLY (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 delegable prefixes from the primary server to request allocation of delegable prefixes from the primary
server. The primary responds with POOLRESP. server. The primary responds with POOLRESP.
5.3.4. POOLRESP 5.3.4. POOLRESP
skipping to change at page 18, line 38 skipping to change at page 18, line 38
responded to, it only indicates reception and acceptance of the task responded to, it only indicates reception and acceptance of the task
of ensuring the balance is examined and corrected as necessary. 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. BNDREPLY message has been received for each of them.
5.3.6. UPDREQALL 5.3.6. UPDREQALL
The update request all UPDREQALL (TBD6) is used by one server to The update request all UPDREQALL (TBD6) is used by one server to
request that all binding database information present in the other request that all binding database information present in the other
server be sent to the requesting server, in order to recover from a server be sent to the requesting server, in order to recover from a
total loss of its binding database by the requesting server. A total loss of its binding database by the requesting server. A
server receiving this request responds with zero or more BNDUPD server receiving this request responds with zero or more BNDUPD
messages, followed by an UPDDONE that signals that all of the BNDUPD messages, followed by an UPDDONE that signals that all of the BNDUPD
messages have been sent and a corresponding BNDACK message has been messages have been sent and a corresponding BNDREPLY message has been
received for each of them. received for each of them.
5.3.7. UPDDONE 5.3.7. UPDDONE
The update done message UPDDONE (TBD7) is used by the server The update done message UPDDONE (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 attributes 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. CONNECTREPLY message.
5.3.9. CONNECTACK 5.3.9. CONNECTREPLY
The connect acknowledgement message CONNECTACK (TBD9) is used by the The connect acknowledgement message CONNECTREPLY (TBD9) is used by
secondary server to respond to a CONNECT message from the primary the secondary server to respond to a CONNECT message from the primary
server. server.
5.3.10. DISCONNECT 5.3.10. DISCONNECT
The disconnect message DISCONNECT (TBD10) is used by either server The disconnect message DISCONNECT (TBD10) is used by either server
when closing a connection and shutting down. No response is required when closing a connection and shutting down. No response is required
for this message. The DISCONNECT message SHOULD contain an for this message. The DISCONNECT message SHOULD contain an
OPTION_STATUS_CODE option with an appropriate status. Often this OPTION_STATUS_CODE option with an appropriate status. Often this
will be ServerShuttingDown. See Section 5.5. A server SHOULD will be ServerShuttingDown. See Section 5.6. A server SHOULD
include a descriptive message as to the reasons causing the include a descriptive message as to the reasons causing the
disconnect message. disconnect message.
5.3.11. STATE 5.3.11. STATE
The state message STATE (TBD11) is used by either server to inform The state message STATE (TBD11) is used by either server to inform
its partner about a change of failover state. In some cases it may its partner about a change of failover state. In some cases it may
be used to also inform the partner about the current state, e.g. be used to also inform the partner about the current state, e.g.
after connection is established in COMMUNICATIONS-INTERRUPTED or after connection is established in COMMUNICATIONS-INTERRUPTED or
PARTNER-DOWN states. PARTNER-DOWN states.
5.3.12. CONTACT 5.3.12. CONTACT
The contact message CONTACT (TBD12) is used by either server to The contact message CONTACT (TBD12) is used by either server to
ensure that its partner continues to see the connection as ensure that its partner continues to see the connection as
operational. It MUST be transmitted periodically over every operational. It MUST be transmitted periodically over every
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. Transaction Id
The initiator of a message exchange MUST set the transaction-id.
This means that all of the messages above except BNDREPLY, POOLRESP,
UPDDONE, and CONNECTREPLY must set the tranasction-id. The
transaction-id MUST be unique among all currently outstanding
messages sent to the failover partner. A straightforward way to
ensure this is to simply use an incrementing value, with one caveat.
The UPDREQ and UPDREQALL messages may be separated by a considerable
time prior to the receipt of an UPDDONE message. While the usual
pattern of message exchange would have the partner doing the vast
majority of message initiation, it is remotely possible that the
partner which initiated the UPDREQ or UPDREQALL messages might also
send enough messages to wrap the 24-bit transaction-id and duplicate
the transaction-id of the outstanding UPDREQ or UPDREQALL. Thus, it
is important to ensure that the transaction-id of a currently
outstanding UPDREQ or UPDREQALL is not replicated in any message
initiated prior to the receipt of the corresponding UPDDONE.
5.5. Options
The following new options are defined. The following new options are defined.
5.4.1. OPTION_F_BINDING_STATUS 5.5.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 lease on an 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| binding-status| | binding-status|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
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 PENDING-FREE 4 PENDING-FREE
5 FREE 5 FREE
6 FREE-BACKUP 6 FREE-BACKUP
7 ABANDONED 7 ABANDONED
8 RESET 8 RESET
The binding-status values are discussed in Section 7.2 The binding-status values are discussed in Section 7.2
5.4.2. OPTION_F_CONNECT_FLAGS 5.5.2. OPTION_F_CONNECT_FLAGS
Flags which indicate attributes of the connecting server. Flags which indicate attributes of the connecting server.
This consists of an unsigned 16 bit value in network byte order. This consists of an unsigned 16 bit value in network byte order.
The code for this option is TBD14. The code for this option is TBD14.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 46 skipping to change at page 22, line 34
Note that if the FIXED_PD_LENGTH bit is set, each delegable prefix Note that if the FIXED_PD_LENGTH bit is set, each delegable prefix
may have its own fixed size -- this flag does not imply that all may have its own fixed size -- this flag does not imply that all
prefixes delegated will be the same size, rather that all prefixes prefixes delegated will be the same size, rather that all prefixes
delegated from the same delegable prefix will be the same size. delegated from the same delegable prefix will be the same size.
If the FIXED_PD_LENGTH bit is set, the length used for each prefix is If the FIXED_PD_LENGTH bit is set, the length used for each prefix is
specified independent of this protocol, but must be known to both specified independent of this protocol, but must be known to both
failover partners. It might be specified in the configuration for failover partners. It might be specified in the configuration for
each delegable prefix or it might be fixed for the entire server. each delegable prefix or it might be fixed for the entire server.
5.4.3. OPTION_F_DNS_REMOVAL_INFO 5.5.3. OPTION_F_DNS_REMOVAL_INFO
This option contains the information necessary to remove a DNS name This option contains the information necessary to remove a DNS name
that was entered by the failover partner. that was entered by the failover partner.
The code for this option is TBD15. The code for this option is 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 |
skipping to change at page 22, line 21 skipping to change at page 23, line 21
| (variable) | | (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_REMOVAL_INFO (TBD15). option-code OPTION_F_DNS_REMOVAL_INFO (TBD15).
option-len variable option-len variable
sub-options Three possible encapsulated 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.4. OPTION_F_DNS_HOST_NAME 5.5.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].
The code for this option is TBD16. The code for this option is TBD16.
0 1 2 3 0 1 2 3
skipping to change at page 22, line 47 skipping to change at page 23, line 47
. . . .
. host-name . . host-name .
. (variable) . . (variable) .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_HOST_NAME (TBD16). option-code OPTION_F_DNS_HOST_NAME (TBD16).
option-len 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.5. OPTION_F_DNS_ZONE_NAME 5.5.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].
The code for this option is TBD17. The code for this option is TBD17.
0 1 2 3 0 1 2 3
skipping to change at page 23, line 26 skipping to change at page 24, line 26
. . . .
. zone-name . . zone-name .
. (variable) . . (variable) .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_DNS_ZONE_NAME (TBD17). option-code OPTION_F_DNS_ZONE_NAME (TBD17).
option-len 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.6. OPTION_F_DNS_FLAGS 5.5.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 of an unsigned 16 bit value in network byte order. This consists of an unsigned 16 bit value in network byte order.
The code for this option is TBD18. The code for this option is TBD18.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 31 skipping to change at page 25, line 31
based on some algorithm. based on some algorithm.
14 (R): REV_UPTODATE 14 (R): REV_UPTODATE
Set to 1 to indicate that the reverse zone is up to date. Set to 1 to indicate that the reverse zone is up to date.
15 (F): FWD_UPTODATE 15 (F): FWD_UPTODATE
Set to 1 to indicate that the forward zone is up to date. Set to 1 to indicate that the forward zone is up to date.
If both the U and S bits are unset, then the name must have been If both the U and S bits are unset, then the name must have been
provided from some alternative configuration, such as client provided from some alternative configuration, such as client
registration in some database accessible to the DHCP server. registration in some database accessible to the DHCP server.
5.4.7. OPTION_F_EXPIRATION_TIME 5.5.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 BNDREPLY for a particular lease or prefix. This MUST be an
midnight January 1, 2000 UTC, modulo 2^32). 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 TBD19. 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 (TBD19). 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.8. OPTION_F_MAX_UNACKED_BNDUPD 5.5.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 TBD20. The code for this option is TBD20.
0 1 2 3 0 1 2 3
skipping to change at page 25, line 42 skipping to change at page 26, line 42
| OPTION_F_MAX_UNACKED_BNDUPD | option-len | | OPTION_F_MAX_UNACKED_BNDUPD | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max-unacked-bndupd | | max-unacked-bndupd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_MAX_UNACKED_BNDUPD (TBD20). option-code OPTION_F_MAX_UNACKED_BNDUPD (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.9. OPTION_F_MCLT 5.5.9. OPTION_F_MCLT
The maximum-client-lead-time (MCLT) is the upper bound on the The maximum-client-lead-time (MCLT) is the upper bound on the
difference allowed between the valid lifetime provided to a DHCP difference allowed between the valid lifetime provided to a DHCP
client by a server and the valid lifetime known by that server's client by a server and the valid lifetime known by that server's
failover partner. It is an interval, measured in seconds. See failover partner. It is an interval, measured in seconds. See
Section 4.4. Section 4.4.
This is an unsigned 32-bit integer in network byte order. This is an unsigned 32-bit integer in network byte order.
The code for this option is TBD21. The code for this option is TBD21.
skipping to change at page 26, line 19 skipping to change at page 27, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_MCLT | option-len | | OPTION_F_MCLT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mclt | | mclt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_MCLT (TBD21). 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.10. OPTION_F_PARTNER_LIFETIME 5.5.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 TBD22. The code for this option is TBD22.
0 1 2 3 0 1 2 3
skipping to change at page 26, line 43 skipping to change at page 27, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-lifetime | | partner-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTER_LIFETIME (TBD22). 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.11. OPTION_F_PARTNER_LIFETIME_SENT 5.5.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.10 option. This is an exact duplicate (echo) of the time Section 5.5.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 TBD23. 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
skipping to change at page 27, line 25 skipping to change at page 28, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTNER_LIFETIME_SENT (TBD23). 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.12. OPTION_F_PARTNER_DOWN_TIME 5.5.12. OPTION_F_PARTNER_DOWN_TIME
The time that the partner most recently lost communications 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 TBD24. The code for this option is TBD24.
0 1 2 3 0 1 2 3
skipping to change at page 28, line 5 skipping to change at page 29, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partner-down-time | | partner-down-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_PARTNER_DOWN_TIME (TBD24). 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.13. OPTION_F_PARTNER_RAW_CLT_TIME 5.5.13. OPTION_F_PARTNER_RAW_CLT_TIME
The time when the partner most recently interacted with the DHCP 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 or prefix. This MUST be an
time (i.e. seconds since midnight January 1, 2000 UTC, modulo 2^32). 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 TBD25. 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 (TBD25). 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.14. OPTION_F_PROTOCOL_VERSION 5.5.14. OPTION_F_PROTOCOL_VERSION
The protocol version allows one failover partner to determine the The protocol version allows one failover partner to determine the
version of the protocol being used by the other partner, to allow for version of the protocol being used by the other partner, to allow for
changes and upgrades in the future. Two components are provided, to changes and upgrades in the future. Two components are provided, to
allow for large and small changes to be represented in one 32-bit allow for large and small changes to be represented in one 32-bit
number. The intent is that large changes would result in an number. The intent is that large changes would result in an
increment of the major-version, while small changes would result in increment of the major-version, while small changes would result in
an increment of the minor-version. As subsequent updates and an increment of the minor-version. As subsequent updates and
extensions of this document can define changes to these values in any extensions of this document can define changes to these values in any
way deemed appropriate no attempt is made to further define large and way deemed appropriate no attempt is made to further define large and
skipping to change at page 29, line 12 skipping to change at page 30, line 12
The code for this option is TBD26. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| major-version | minor-version | | major-version | minor-version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol-version |
option-code OPTION_F_PROTOCOL_VERSION (TBD26). option-code OPTION_F_PROTOCOL_VERSION (TBD26).
option-len 4. option-len 4.
major-version The major version of the protocol. Initially 1. major-version The major version of the protocol. Initially 1.
minor-version The minor version of the protocol. Initially 0. minor-version The minor version of the protocol. Initially 0.
5.4.15. OPTION_F_RECEIVE_TIME 5.5.15. OPTION_F_KEEPALIVE_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 TBD27. 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_KEEPALIVE_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| receive-time | | keepalive-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_RECEIVE_TIME (TBD27). option-code OPTION_F_KEEPALIVE_TIME (TBD27).
option-len 4. option-len 4.
receive-time The receive-time. An interval of seconds. receive-time The keepalive-time. An interval of seconds.
5.4.16. OPTION_F_RECONFIGURE_DATA 5.5.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 TBD28. 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 |
skipping to change at page 30, line 27 skipping to change at page 31, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_RECONFIGURE_DATA (TBD28). 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.17. OPTION_F_RELATIONSHIP_NAME 5.5.17. OPTION_F_RELATIONSHIP_NAME
A name for this failover relationship. Used to distinguish between A name for this failover relationship. Used to distinguish between
relationships when there are multiple failover relationships between relationships when there are multiple failover relationships between
two failover servers. 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 TBD29. The code for this option is TBD29.
skipping to change at page 31, line 23 skipping to change at page 32, line 23
. (variable) . . (variable) .
. | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_RELATIONSHIP_NAME (TBD29). option-code OPTION_F_RELATIONSHIP_NAME (TBD29).
option-len length of relationship-name. option-len length of relationship-name.
relationship-name A UTF-8 encoded text string suitable for relationship-name A UTF-8 encoded text string suitable for
display to an end user, which MUST NOT be display to an end user, which MUST NOT be
null-terminated. null-terminated.
5.4.18. OPTION_F_SERVER_FLAGS 5.5.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 TBD30. 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
skipping to change at page 32, line 24 skipping to change at page 33, line 24
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.19. OPTION_F_SERVER_STATE 5.5.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 TBD31. 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
skipping to change at page 33, line 25 skipping to change at page 34, line 25
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.20. OPTION_F_START_TIME_OF_STATE 5.5.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-options, IA_TA-options, or IA_PD-options field , the state to IA_NA-options, IA_TA-options, or IA_PD-options field , the state to
which it refers is the binding-status value in the OPTION_IA_NA, which it refers is the binding-status value in the OPTION_IA_NA,
OPTION_IA_TA, or OPTION_IA_PD option, respectively. This MUST be an OPTION_IA_TA, or OPTION_IA_PD option, respectively. This MUST be an
absolute time (i.e. seconds since midnight January 1, 2000 UTC, absolute time (i.e. seconds since midnight January 1, 2000 UTC,
modulo 2^32). modulo 2^32).
skipping to change at page 34, line 19 skipping to change at page 35, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start-time-of-state | | start-time-of-state |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_START_TIME_OF_STATE (TBD32). option-code OPTION_F_START_TIME_OF_STATE (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.21. OPTION_F_STATE_EXPIRATION_TIME 5.5.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).
Note that states other than ACTIVE may have a time associated with Note that states other than ACTIVE may have a time associated with
them. In particular, EXPIRED might have a time associated with it, them. In particular, EXPIRED might have a time associated with it,
in the event that some sort of "grace period" existed where the lease in the event that some sort of "grace period" existed where the lease
would not be reused for a period after the lease expired. The would not be reused for a period after the lease expired. The
ABANDONED state might have a time associated with it, in the event ABANDONED state might have a time associated with it, in the event
skipping to change at page 35, line 19 skipping to change at page 36, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| state-expiration-time | | state-expiration-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_STATE_EXPIRATION_TIME (TBD33). 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.6. Status Codes
The following new status codes are defined, to be used in the The following new status codes are defined, to be used in the
OPTION_STATUS_CODE option. OPTION_STATUS_CODE option.
AddressInUse (TBD34) AddressInUse (TBD34)
One client on one server has leases that are in conflict with the One client on one server has leases that are in conflict with the
leases that the client has on another server. Alternatively, the leases that the client has on another server. Alternatively, the
address could be associated with a different IA_ID on each server. address could be associated with a different IAID on each server.
ConfigurationConflict (TBD35) 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 (TBD36) MissingBindingInformation (TBD36)
There is insufficient information in a BNDUPD to effectively There is insufficient information in a BNDUPD to effectively
process it. process it.
skipping to change at page 36, line 13 skipping to change at page 37, line 13
information included, and the server doesn't support 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 Every primary server implementing the failover protocol MUST
periodically attempt to create a TCP connection to the dhcp-failover periodically attempt to create a TCP connection to the dhcp-failover
port (647) of all of its configured partners, where the period is port (647) of all of its configured partners, where the period is
implementation dependent and SHOULD be configurable. In the event implementation dependent and SHOULD be configurable. In the event
that a connection has been rejected by a CONNECTACK message with a that a connection has been rejected by a CONNECTREPLY message with a
reject-reason option contained in it or a DISCONNECT message, a reject-reason option contained in it or a DISCONNECT message, a
server SHOULD reduce the frequency with which it attempts to connect server SHOULD reduce the frequency with which it attempts to connect
to that server but it MUST continue to attempt to connect to that server but it MUST continue to attempt to connect
periodically. periodically.
Every secondary server implementing the failover protocol MUST listen Every secondary server implementing the failover protocol MUST listen
for TCP connection attempts on the dhcp-failover port (647) from a for TCP connection attempts on the dhcp-failover port (647) from a
primary server. primary server.
After a primary server successfully establishes a TCP connection to a After a primary server successfully establishes a TCP connection to a
skipping to change at page 36, line 49 skipping to change at page 37, line 49
relationship this connection is to service. relationship this connection is to service.
If it has no secondary relationships with the connecting server, it If it has no secondary relationships with the connecting server, it
MUST drop the connection. MUST drop the connection.
To summarize -- a primary server MUST use a connection that it has To summarize -- a primary server MUST use a connection that it has
initiated in order to send a CONNECT message. Every server that is a initiated in order to send a CONNECT message. Every server that is a
secondary server in a relationship MUST listen for CONNECT messages secondary server in a relationship MUST listen for CONNECT messages
from the primary server. from the primary server.
When the CONNECT and CONNECTACK exchange successfully produces a When the CONNECT and CONNECTREPLY exchange successfully produces a
working failover connection, the next message sent over a new working failover connection, the next message sent over a new
connection is a STATE message. See Section 6.3. Upon the receipt of connection is a STATE message. See Section 6.3. Upon the receipt of
the STATE message, the receiver can consider communications ok. the STATE message, the receiver can consider communications ok.
6.1.1. Sending a CONNECT message 6.1.1. Sending a CONNECT message
The CONNECT message is sent with information about the failover The CONNECT message is sent with information about the failover
configuration on the primary server. The message MUST contain at configuration on the primary server. The message MUST contain at
least the following information in the options area: least the following information in the options area:
o OPTION_F_PROTOCOL_VERSION containing the protocol version. 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 number of seconds (an o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an
interval) within which the server must receive a message from its interval) within which the server must receive a message from its
partner, or it will assume that communications from the partner is partner, or it will assume that communications from the partner 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 o OPTION_F_RELATIONSHIP_NAME containing name of the failover
relationship to which this connection applies. If there is no relationship to which this connection applies. If there is no
skipping to change at page 37, line 44 skipping to change at page 38, line 44
A server receiving a CONNECT message must process the information in A server receiving a CONNECT message must process the information in
the message and decide whether or not to accept the connection. The the message and decide whether or not to accept the connection. The
processing is performed as follows: processing is performed as follows:
o 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 - Use this MCLT supplied by the primary server.
MCLT, and if they are different the server MUST alert operational Remember this MCLT and use it until a different MCLT is supplied
staff of this difference. Use the MCLT supplied by the primary by some subsequent CONNECT message.
server until something explicitly alters the MCLT defined on the
secondary server.
o OPTION_F_RECEIVE_TIME - Remember the receive-time as the o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the
FO_RECEIVE_TIME when implementing the Unreachability Detection FO_KEEPALIVE_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 o OPTION_F_CONNECT_FLAGS - Ensure that the secondary can process
information from the primary as specified in the flags. For information from the primary as specified in the flags. For
example, if the secondary server cannot process prefix delegation example, if the secondary server cannot process prefix delegation
with variable sized prefixes delegated from the same delegable with variable sized prefixes delegated from the same delegable
prefix, and the primary server says that it can, the secondary prefix, and the primary server says that it can, the secondary
should reject the connection. should reject the connection.
A CONNECT message SHOULD always be followed by a CONNECTACK message, A CONNECT message SHOULD always be followed by a CONNECTREPLY
either to accept the connection or to reject the connection by message, either to accept the connection or to reject the connection
including an OPTION_STATUS_CODE option with an error reject. In by 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 CONNECTREPLY
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 CONNECTREPLY message
the following information: with the following information:
o OPTION_F_PROTOCOL_VERSION containing the protocol version being o OPTION_F_PROTOCOL_VERSION containing the protocol version being
used by the secondary server. 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 number of seconds (an o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an
interval) within which the server must receive a message from its interval) within which the server must receive a message from its
partner, or it will assume that communications from the partner is partner, or it will assume that communications from the partner 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 o OPTION_F_CONNECT_FLAGS - Place information into this option to
describe the attributes of the secondary server that the primary describe the attributes of the secondary server that the primary
needs to know about. needs to know about.
After sending a CONNECTACK message to accept the primary server's After sending a CONNECTREPLY message to accept the primary server's
CONNECT message, the secondary server MUST send a STATE message (see CONNECT message, the secondary server MUST send a STATE message (see
Section 6.3). Section 6.3).
6.1.3. Receiving a CONNECTACK message 6.1.3. Receiving a CONNECTREPLY message
A server receiving a CONNECTACK message must process the information A server receiving a CONNECTREPLY message must process the
in the message and decide whether or not to continue to employ the information in the message and decide whether or not to continue to
connection. The processing is performed as follows: employ the connection. The processing is performed as follows:
o OPTION_F_PROTOCOL_VERSION - The primary server decides if the o OPTION_F_PROTOCOL_VERSION - The primary server decides if the
protocol version in use by the secondary server is supported by protocol version in use by the secondary server is supported by
the primary server. If it is not, send a DISCONNECT message and the primary server. If it is not, send a DISCONNECT message and
drop the connection. If it is supported, continue processing. 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_KEEPALIVE_TIME - Remember the keepalive-time as the
FO_RECEIVE_TIME when implementing the Unreachability Detection FO_KEEPALIVE_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 o OPTION_F_CONNECT_FLAGS - Ensure that the primary can process
information from the secondary as specified in the flags. For information from the secondary as specified in the flags. For
example, if the primary server cannot process prefix delegation example, if the primary server cannot process prefix delegation
with variable sized prefixes delegated from the same delegable with variable sized prefixes delegated from the same delegable
prefix, and the secondary server says that it can, the primary prefix, and the secondary server says that it can, the primary
should drop the connection. should drop the connection.
After receiving a CONNECTACK message that accepted the primary After receiving a CONNECTREPLY message that accepted the primary
server's CONNECT message, the primary server MUST send a STATE server's CONNECT message, the primary server MUST send a STATE
message (see Section 6.3). message (see Section 6.3).
6.2. Endpoint Identification 6.2. Endpoint Identification
A failover endpoint is always associated with a set of DHCP prefixes A failover endpoint is always associated with a set of DHCP prefixes
that are configured on the DHCP server where the endpoint appears. A that are configured on the DHCP server where the endpoint appears. A
DHCP prefix MUST NOT be associated with more than one failover DHCP prefix MUST NOT be associated with more than one failover
endpoint. endpoint.
skipping to change at page 41, line 31 skipping to change at page 42, line 31
A server receiving a STATE message SHOULD ensure that this A server receiving a STATE message SHOULD ensure that this
information is written to stable storage. information is written to stable storage.
6.5. Connection Maintenance Parameters 6.5. Connection Maintenance Parameters
The following parameters and timers are used to ensure the integrity The following parameters and timers are used to ensure the integrity
of the connections between two failover servers. of the connections between two failover servers.
Parameter Default Description Parameter Default Description
------------------------------------------ ------------------------------------------
FO_RECEIVE_TIMER timer counts down to time connection FO_KEEPALIVE_TIMER timer counts down to time connection
assumed dead due to lack of messages assumed dead due to lack of messages
FO_RECEIVE_TIME 60 maximum time server will consider FO_KEEPALIVE_TIME 60 maximum time server will consider
connection still up with no messages connection still up with no messages
FO_CONTACT_PER_RECEIVE_TIME number of CONTACT messages to send FO_CONTACT_PER_KEEPALIVE_TIME number of CONTACT messages to send
4 during partner's FO_RECEIVE_TIME 4 during partner's FO_KEEPALIVE_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 messages if no other traffic CONTACT messages if no other traffic
Created from partner's FO_RECEIVE_TIME Created from partner's FO_KEEPALIVE_TIME
divided by FO_CONTACT_PER_RECEIVE_TIME divided by FO_CONTACT_PER_KEEPALIVE_TIME
6.6. Unreachability detection 6.6. Unreachability detection
Each partner MUST maintain an FO_SEND_TIMER for each failover Each partner MUST maintain an FO_SEND_TIMER for each failover
connection. The FO_SEND_TIMER for a particular connection is reset connection. The FO_SEND_TIMER for a particular connection is reset
to FO_SEND_TIME every time any message is transmitted on that to FO_SEND_TIME every time any message is transmitted on that
connection, and counts down once per second. If the timer reaches connection, and counts down once per second. If the timer reaches
zero, a CONTACT message is transmitted on that connection and the zero, a CONTACT message is transmitted on that connection and the
timer for that connection is reset to FO_SEND_TIME. The CONTACT timer for that connection is reset to FO_SEND_TIME. The CONTACT
message may be transmitted at any time. An implementation MAY use message may be transmitted at any time. An implementation MAY use
additional mechanisms to detect partner unreachability. additional mechanisms to detect partner unreachability.
The FO_SEND_TIME is initialized from the configured FO_RECEIVE_TIME The FO_SEND_TIME is initialized from the configured FO_KEEPALIVE_TIME
divided by FO_CONTACT_PER_RECEIVE_TIME. When a CONNECT or CONNECTACK divided by FO_CONTACT_PER_KEEPALIVE_TIME. When a CONNECT or
message is received on a connection, the received CONNECTREPLY message is received on a connection, the received
OPTION_F_RECEIVE_TIME option is checked, and the value in that option OPTION_F_KEEPALIVE_TIME option is checked, and the value in that
is used to calculate the FO_SEND_TIME for that connection by dividing option is used to calculate the FO_SEND_TIME for that connection by
the value received by the configured FO_CONTACT_PER_RECEIVE_TIME. dividing the value received by the configured
FO_CONTACT_PER_KEEPALIVE_TIME.
Each partner MUST maintain an FO_RECEIVE_TIMER for each failover Each partner MUST maintain an FO_KEEPALIVE_TIMER for each failover
connection. This timer is initialized to FO_RECEIVE_TIME and counts connection. This timer is initialized to FO_KEEPALIVE_TIME and
down once per second. It is reset to FO_RECEIVE_TIME whenever a counts down once per second. It is reset to FO_KEEPALIVE_TIME
message is received on that connection. If it ever reaches zero, whenever a message is received on that connection. If it ever
that connection is considered dead. In addition, the FO_RECEIVE_TIME reaches zero, that connection is considered dead. In addition, the
for that connection MUST be sent to the failover partner on every FO_KEEPALIVE_TIME for that connection MUST be sent to the failover
CONNECT or CONNECTACK messages, in the OPTION_F_RECEIVE_TIME option. partner on every CONNECT or CONNECTREPLY messages, in the
OPTION_F_KEEPALIVE_TIME option.
7. Binding Updates and Acks 7. Binding Updates and Acks
7.1. Time Skew 7.1. Time Skew
Partners exchange information about known lease states. To reliably Partners exchange information about known lease states. To reliably
compare a known lease state with an update received from a partner, compare a known lease state with an update received from a partner,
servers must be able to reliably compare the times stored in the servers must be able to reliably compare the times stored in the
known lease state with the times received in the update. The known lease state with the times received in the update. The
failover protocol adopts the simple approach of requiring that the failover protocol adopts the simple approach of requiring that the
skipping to change at page 47, line 4 skipping to change at page 48, line 4
+----------------+---------+-----------+ +----------------+---------+-----------+
Figure 2: PENDING-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 DHCP protocol [RFC3315]. those required by the base DHCP protocol [RFC3315].
expiration-time expiration-time
The greatest liftime that this server has ever acked to its The greatest lifetime that this server has ever acked to its
failover partner in a BNDACK. failover partner in a BNDREPLY.
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 BNDREPLY.
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 lease be the time after which the partner can consider the lease
expired. When we receive a BNDUPD this value can be updated from expired. When we receive a BNDUPD this value can be updated from
the received OPTION_F_EXPIRATION_TIME. the received OPTION_F_EXPIRATION_TIME.
client-last-transaction-time client-last-transaction-time
The time when the this server most recently interacted with the The time when this server most recently interacted with the client
client associated with this lease. associated with this lease.
partner-raw-clt-time partner-raw-clt-time
The time when the partner most recently interacted with the client The time when the partner most recently interacted with the client
associated with this lease. This time remains exactly as it was associated with this lease. This time remains exactly as it was
received by this server, and MUST NOT be adjusted to be in the received by this server, and MUST NOT be adjusted to be in 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 Every BNDUPD message contains information about either a single
lease states using the BNDUPD message. Every BNDUPD message contains client binding in an OPTION_CLIENT_DATA option that include IAADDR or
information about either a single client binding in an IAPREFIX options associated with that client, or a single prefix
OPTION_CLIENT_DATA option, or a single prefix lease in an lease in an OPTION_IAPREFIX option for prefixes that are currently
OPTION_IAPREFIX option. not associated with any clients.
All information about a particular client binding MUST be contained All information about a particular client binding MUST be contained
in a single OPTION_CLIENT_DATA option (see Section 4.1.2.2 of in a single OPTION_CLIENT_DATA option (see Section 4.1.2.2 of
[RFC5007]). The OPTION_CLIENT_DATA option MUST contain at least the [RFC5007]). The OPTION_CLIENT_DATA option contains at least the data
data shown below in its client-options section: shown below in its client-options section:
o OPTION_CLIENTID containing the DUID of the client most recently o OPTION_CLIENTID containing the DUID of the client most recently
associated with this lease; associated with this lease MUST appear;
o OPTION_LQ_BASE_TIME containing the absolute time that the o OPTION_LQ_BASE_TIME containing the absolute time that the
information was placed into this OPTION_CLIENT_DATA option (see information was placed into this OPTION_CLIENT_DATA option (see
Section 6.3.1 of [RFC7653]); Section 6.3.1 of [RFC7653]) MUST appear;
o OPTION_VSS (see Section 3.4 of [RFC6607]) This option MUST NOT o OPTION_VSS (see Section 3.4 of [RFC6607]) This option MUST NOT
appear if the information in this OPTION_CLIENT_DATA option is appear if the information in this OPTION_CLIENT_DATA option is
associated with the global, default VPN. This option MUST appear associated with the global, default VPN. This option MUST appear
if the information in this OPTION_CLIENT_DATA option is associated if the information in this OPTION_CLIENT_DATA option is associated
with a VPN other than the global, default VPN; with a VPN other than the global, default VPN. Support of
[RFC6607] is not required, and OPTION_VSS is only used if a VPN
other than the global, default VPN is used, which requires support
of [RFC6607];
o OPTION_F_RECONFIGURE_DATA containing the time and reconfigure key, o OPTION_F_RECONFIGURE_DATA containing the time and reconfigure key,
if any; if any;
o OPTION_LQ_RELAY_DATA containing information described in o OPTION_LQ_RELAY_DATA containing information described in
Section 4.1.2.4 of [RFC5007], if any exists; Section 4.1.2.4 of [RFC5007], if any exists;
o OPTION_IA_NA or OPTION_IA_TA for an IPv6 Address or OPTION_IA_PD o OPTION_IA_NA or OPTION_IA_TA for an IPv6 Address or OPTION_IA_PD
for an IPv6 Prefix. More than one of either of these options MAY for an IPv6 Prefix. More than one of either of these options MAY
appear if there are more than one associated with this client; appear if there are more than one associated with this client. At
least one MUST appear;
* IAID - Identity Association used by the client, while obtaining * IAID - Identity Association used by the client, while obtaining
a given lease. (Note1: one client may use many IAIDs a given lease. (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, IA_TA-options, or IA_PD-option * Inside of the IA_NA-options, IA_TA-options, or IA_PD-option
sections: sections:
+ OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for + OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for
a IPv6 prefix; a IPv6 prefix MUST appear;
- IPv6 Address or IPv6 Prefix (with length); - IPv6 Address or IPv6 Prefix (with length);
- preferred lifetime sent to client; - preferred lifetime sent to client;
- valid lifetime sent to client; - valid lifetime sent to client;
- Inside of the IAaddr-options or IAprefix-options: - Inside of the IAaddr-options or IAprefix-options:
o OPTION_F_BINDING_STATUS containing the binding-status; o OPTION_F_BINDING_STATUS containing the binding-status
MUST appear;
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 MUST appear;
o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing
the state-expiration-time*; the state-expiration-time*;
o OPTION_CLT_TIME (relative) containing the client-last- o OPTION_CLT_TIME (relative) containing the 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*;
skipping to change at page 49, line 39 skipping to change at page 50, line 45
* IPv6 Prefix (with length); * IPv6 Prefix (with length);
* Inside of the IAprefix-options section: * Inside of the IAprefix-options section:
+ OPTION_VSS (see Section 3.4 of [RFC6607]) This option MUST + OPTION_VSS (see Section 3.4 of [RFC6607]) This option MUST
NOT appear if the information in this OPTION_IAPREFIX option NOT appear if the information in this OPTION_IAPREFIX option
is associated with the global, default VPN. This option is associated with the global, default VPN. This option
MUST appear if the information in this OPTION_IAPREFIX MUST appear if the information in this OPTION_IAPREFIX
option is associated with a VPN other than the global, option is associated with a VPN other than the global,
default VPN; default VPN. Support of [RFC6607] is not required, and
OPTION_VSS is only used if a VPN other than the global,
default VPN is used, which requires support of [RFC6607];
+ OPTION_LQ_BASE_TIME containing the absolute time that this + OPTION_LQ_BASE_TIME containing the absolute time that this
information was placed into this OPTIONS_IAPREFIX option information was placed into this OPTIONS_IAPREFIX option
(see Section 6.3.1 of [RFC7653]); (see Section 6.3.1 of [RFC7653]) MUST appear;
+ OPTION_F_BINDING_STATUS containing the binding-status; + OPTION_F_BINDING_STATUS containing the binding-status MUST
appear;
+ OPTION_F_START_TIME_OF_STATE containing the start-time-of- + OPTION_F_START_TIME_OF_STATE containing the start-time-of-
state; state MUST appear;
+ OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the + OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the
state-expiration-time*; state-expiration-time*;
+ OPTION_F_PARTNER_LIFETIME (absolute) containing partner- + OPTION_F_PARTNER_LIFETIME (absolute) containing partner-
lifetime*; lifetime*;
+ OPTION_F_EXPIRATION_TIME (absolute) containing the + OPTION_F_EXPIRATION_TIME (absolute) containing the
expiration-time*; expiration-time*;
skipping to change at page 50, line 46 skipping to change at page 52, line 9
Any time can be before, after, or essentially the same as another Any time can be before, after, or essentially the same as another
time. Any time which ends up being +/- 5 seconds of another time time. Any time which ends up being +/- 5 seconds of another time
SHOULD be considered to be representing the same time when performing SHOULD be considered to be representing the same time when performing
a comparison between two times. a comparison between two times.
7.5.2. Acknowledging Reception 7.5.2. Acknowledging Reception
Upon acceptance of a binding update, the server MUST notify its Upon acceptance of a binding update, the server MUST notify its
partner that it has processed the binding update (and updated its partner that it has processed the binding update (and updated its
lease state database if necessary) by sending a BNDACK. A server lease state database if necessary) by sending a BNDREPLY. A server
MUST NOT send the BNDACK before its binding database is updated. MUST NOT send the BNDREPLY before its binding database is updated.
7.5.3. Processing Binding Updates 7.5.3. Processing Binding Updates
When a BNDUPD is received it MUST contain either a single When a BNDUPD is received it MUST contain either a single
OPTION_CLIENT_DATA option or a single OPTION_IAPREFIX option. OPTION_CLIENT_DATA option or a single OPTION_IAPREFIX option.
When analyzing an BNDUPD message option from a partner server, if When analyzing an BNDUPD message option from a partner server, if
there is insufficient information in the BNDUPD message to process there is insufficient information in the BNDUPD message to 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".
skipping to change at page 51, line 25 skipping to change at page 52, line 32
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 or IAPREFIX the received information in each OPTION_CLIENT_DATA or IAPREFIX
option to see if it is consistent with the server's already known option to see if it is consistent with the server's already known
state, and if it is not, decide which information - that previously state, and if it is not, decide which information - that previously
known or that just received - is "better". If the information in the known or that just received - is "better". If the information in the
BNDUPD is "better", the receiving server will accept the information BNDUPD is "better", the receiving server will accept the information
in the BNDUPD. If the information in the server's binding database in the BNDUPD. If the information in the server's binding database
is "better", the server will reject the information in the BNDUPD. is "better", the server will reject the information in the BNDUPD.
A server receiving a BNDUPD message MUST respond to the sender of A server receiving a BNDUPD message MUST respond to the sender of
that message with a BNDACK message which contains the same that message with a BNDREPLY message which contains the same
transaction-id as the BNDUPD message. This BNDACK message MUST transaction-id as the BNDUPD message. This BNDREPLY message MUST
contain either a single OPTION_CLIENT_DATA option or a single contain either a single OPTION_CLIENT_DATA option or a single
OPTION_IAPREFIX option, corresponding to whatever was received in the OPTION_IAPREFIX option, corresponding to whatever was received in the
BNDUPD message. BNDUPD message.
An OPTION_CLIENT_DATA option or an OPTION_IAPREFIX option in the An OPTION_CLIENT_DATA option or an OPTION_IAPREFIX option in the
BNDACK which is accepted SHOULD NOT contain an OPTION_STATUS_CODE BNDREPLY which is accepted SHOULD NOT contain an OPTION_STATUS_CODE
unless a status message needs to be sent to the failover partner, in unless a status message needs to be sent to the failover partner, in
which case it SHOULD include an OPTION_STATUS_CODE option with a which case it SHOULD include an OPTION_STATUS_CODE option with a
status code indicating success and whatever message is needed. status code indicating success and whatever message is needed.
To indicate rejection of the information in an OPTION_CLIENT_DATA To indicate rejection of the information in an OPTION_CLIENT_DATA
option, or an OPTION_IAPREFIX option, an OPTION_STATUS_CODE SHOULD be option, or an OPTION_IAPREFIX option, an OPTION_STATUS_CODE SHOULD be
included with a status code indicating an error in the included with a status code indicating an error in the
OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDACK OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDREPLY
message. message.
7.5.4. Accept or Reject? 7.5.4. Accept or Reject?
The first task in processing the information in an OPTION_CLIENT_DATA The first task in processing the information in an OPTION_CLIENT_DATA
option or OPTION_IAPREFIX option is extract the client information option or OPTION_IAPREFIX option is extract the client information
(if any) and lease information out of the option, and to access the (if any) and lease information out of the option, and to access the
address lease or prefix lease information in the server's binding address lease or prefix lease information in the server's binding
database. database.
skipping to change at page 52, line 18 skipping to change at page 53, line 29
If the lease specified in the OPTION_CLIENT_DATA option or If the lease specified in the OPTION_CLIENT_DATA option or
OPTION_IAPREFIX option is not a lease associated with the failover OPTION_IAPREFIX option is not a lease associated with the failover
endpoint which received the OPTION_CLIENT_DATA option, then reject it endpoint which received the OPTION_CLIENT_DATA option, then reject it
with reject-reason "ConfigurationConflict". 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 option or two different time values, one from the OPTION_CLIENT_DATA option or
OPTION_IAPREFIX option in the BNDUPD message, and one from the OPTION_IAPREFIX option in the BNDUPD message, and one from the
receiving server's binding database associated with the address or receiving server's binding database associated with the address or
prefix lease found in the BNDUPD message. The time for the BNDUPD prefix lease found in the BNDUPD message. The time for the BNDUPD
message is the OPTION_CLT_TIME if one appears, and the message where the OPTION_F_BINDING_STATUS is ACTIVE, EXPIRED, or
OPTION_F_START_TIME_OF_STATE if one does not. The time for the lease RELEASED is the OPTION_CLT_TIME if one appears, and the
in the server's binding database is the client-last-transaction-time, OPTION_F_START_TIME_OF_STATE if one does not. For other binding-
if one appears, and the start-time-of-state if one does not. status values, the time for the BNDUPD message is the later of the
OPTION_CLT_TIME if one appears, and the OPTION_F_START_TIME_OF_STATE.
The time for the lease in the server's binding database is the
client-last-transaction-time, 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
BNDUPD message is clearly later, then accept the information in the BNDUPD message is clearly later, then accept the information in the
OPTION_CLIENT_DATA option or OPTION_IAPREFIX option. If the one from OPTION_CLIENT_DATA option or OPTION_IAPREFIX option. If the one from
the server's binding database is clearly later, then reject the the server's binding database is clearly later, then reject the
information in the BNDUPD message. The challenge comes when they are information in the BNDUPD message. The challenge comes when they are
essentially the same (i.e., +/- 5 seconds). In this case they are essentially the same (i.e., +/- 5 seconds). In this case they are
considered identical, despite the minor differences. The table below considered identical, despite the minor differences. The table below
(Figure 3) contains the rules for dealing with all of these (Figure 3) contains the rules for dealing with all of these
situations. situations.
binding-status in received OPTION_CLIENT_DATA binding-status in received OPTION_CLIENT_DATA
or OPTION_IAPREFIX or OPTION_IAPREFIX
binding-status in binding-status in
receiving server's FREE RESET receiving server's FREE RESET
lease state DB ACTIVE EXPIRED RELEASED FREE-BACKUP ABANDONED lease state DB ACTIVE EXPIRED RELEASED FREE-BACKUP ABANDONED
ACTIVE accept(4) time(2) time(1) time(2) accept ACTIVE accept(3) time(1) accept time(1) accept
EXPIRED time(1) accept accept accept accept EXPIRED accept accept accept accept accept
RELEASED time(1) time(1) accept accept accept RELEASED accept accept accept accept accept
FREE/FREE-BACKUP accept accept accept accept accept FREE/FREE-BACKUP accept accept accept accept accept
RESET time(3) accept accept accept accept RESET time(2) accept accept accept accept
ABANDONED reject reject reject reject accept ABANDONED accept accept accept accept accept
Figure 3: Conflict Resolution Figure 3: Conflict Resolution
time(1): If the time value in the OPTION_CLIENT_DATA option or accept: If the time value in the OPTION_CLIENT_DATA option or
OPTION_IAPREFIX option is later than the time value in the server's OPTION_IAPREFIX option is later than the time value in the server's
binding database, accept it, else reject it. binding database, accept it, else reject it.
time(2): If the current time is later than the receiving server's time(1): If the current time is later than the receiving server's
state-expiration-time, accept it, else reject it. state-expiration-time, accept it, else reject it.
time(3): If the OPTION_CLT_TIME value (if it appears) in the time(2): If the OPTION_CLT_TIME value (if it appears) in the
OPTION_CLIENT_DATA is later than the start-time-of-state in the OPTION_CLIENT_DATA is later than the start-time-of-state in the
receiving server's binding, accept it, else reject it. receiving server's binding, accept it, else reject it.
(1,2,3): If rejecting, use reject reason accept,time(1),time(2): If rejecting, use reject reason
"OutdatedBindingInformation". "OutdatedBindingInformation".
(4): If the client in an OPTION_CLIENT_DATA option and in a receiving accept(3): If the client in an OPTION_CLIENT_DATA option and in a
server's binding differ, then if the receiving server is a secondary receiving server's binding differ, then if time(2) or the receiving
accept it, else reject it with a reject reason of "AddressInUse". server is a secondary accept it, else reject it with a reject reason
of "AddressInUse". If the clients match, accept the update.
The lease update may be accepted or rejected. Rejection SHOULD NOT The lease update may be accepted or rejected. If a lease is rejected
change the flag in a lease that says that it should be transmitted to with "OutdatedBindingInformation", then the flag in the lease that
the failover partner. If this flag is set, then it should be indicates the partner should be updated about the information in this
transmitted, but if it is not already set, the rejection of a lease lease SHOULD be set, otherwise it SHOULD NOT be changed. If this
state update SHOULD NOT trigger an automatic update of the failover flag was previously not set, then an update MAY be transmitted
partner sending the rejected update. The potential for update storms immediately to the partner (though the BNDREPLY to this BNDUPD SHOULD
is too great, and in the unusual case where the servers simply can't be sent first). If this flag was previously set an update SHOULD NOT
agree, that disagreement is better than an update storm. be transmitted immediately to the partner. In this case, an update
will be sent during the next periodic scan, but not immediately, thus
preventing a possible update storm should the servers be unable to
agree. Ultimately, the server with the most recent binding
information should have its update accepted by its partner.
7.5.5. Accepting Updates 7.5.5. Accepting Updates
When the information in an OPTION_CLIENT_DATA option or When the information in an OPTION_CLIENT_DATA option or
OPTION_IAPREFIX option has been accepted, some of that information is OPTION_IAPREFIX option has been accepted, some of that information is
stored in the receiving server's binding database, and corresponding stored in the receiving server's binding database, and corresponding
a OPTION_CLIENT_DATA option or OPTION_IAPREFIX option is entered into a OPTION_CLIENT_DATA option or OPTION_IAPREFIX option is entered into
a BNDACK. The information to enter into the OPTION_CLIENT_DATA a BNDREPLY. The information to enter into the OPTION_CLIENT_DATA
option or OPTION_IAPREFIX option in the BNDACK is described in option or OPTION_IAPREFIX option in the BNDREPLY is described in
Section 7.6. Section 7.6.
The information contained in an accepted OPTION_CLIENT_DATA option is The information contained in an accepted OPTION_CLIENT_DATA option is
stored in the receiving server's binding database as follows: stored in the receiving server's binding database as follows:
1. The OPTION_CLIENTID is used to find the client. 1. The OPTION_CLIENTID is used to find the client.
2. The other data contained in the top level of the 2. The other data contained in the top level of the
OPTION_CLIENT_DATA option is stored with the client as OPTION_CLIENT_DATA option is stored with the client as
appropriate. appropriate.
skipping to change at page 54, line 41 skipping to change at page 56, line 18
2. OPTION_F_PARTNER_LIFETIME (if any) is stored in the 2. OPTION_F_PARTNER_LIFETIME (if any) is stored in the
expiration-time expiration-time
3. OPTION_F_STATE_EXPIRATION_TIME (if any) is stored in the 3. OPTION_F_STATE_EXPIRATION_TIME (if any) is stored in the
state-expiration-time state-expiration-time
4. OPTION_F_EXPIRATION_TIME (if any) replaces the partner- 4. OPTION_F_EXPIRATION_TIME (if any) replaces the partner-
lifetime if it is later than the current partner-lifetime. lifetime if it is later than the current partner-lifetime.
7.6. Sending Binding Acks 7.6. Sending Binding Replies
A server MUST respond to every BNDUPD message with a BNDACK message. A server MUST respond to every BNDUPD message with a BNDREPLY
The BNDACK message MUST contain an OPTION_CLIENT_DATA option if the message. The BNDREPLY message MUST contain an OPTION_CLIENT_DATA
BNDUPD message contained an OPTION_CLIENT_DATA option, or it MUST option if the BNDUPD message contained an OPTION_CLIENT_DATA option,
contain an OPTION_IAPREFIX option if the BNDUPD message contained an or it MUST contain an OPTION_IAPREFIX option if the BNDUPD message
OPTION_IAPREFIX option. The BNDACK message MUST have the same contained an OPTION_IAPREFIX option. The BNDREPLY message MUST have
transaction-id as the BNDUPD message to which it is a response. the same transaction-id as the BNDUPD message to which it is a
response.
Acceptance or rejection of all or a particular part of the BNDUPD Acceptance or rejection of all or a particular part of the BNDUPD
message is signaled with a OPTION_STATUS_CODE option. An message is signaled with a OPTION_STATUS_CODE option. An
OPTION_STATUS_CODE option containing a status-code representing an OPTION_STATUS_CODE option containing a status-code representing an
error is significant, while an OPTION_STATUS_CODE option whose error is significant, while an OPTION_STATUS_CODE option whose
status-code contains success is considered informational but does not status-code contains success is considered informational but does not
affect the processing of the BNDACK message when it is received by affect the processing of the BNDREPLY message when it is received by
the server that sent the BNDUPD message. the server that sent the BNDUPD message.
Rejection of all or part of the information in a BNDUPD message is Rejection of all or part of the information in a BNDUPD message is
signaled in a BNDACK message by use of the OPTION_STATUS_CODE message signaled in a BNDREPLY message by use of the OPTION_STATUS_CODE
with an error in the status-code field. This rejection can take message with an error in the status-code field. This rejection can
place at either of two levels -- the top level of the option take place at either of two levels -- the top level of the option
hierarchy, or the bottom level of the option hierarchy: hierarchy, or the bottom level of the option hierarchy:
Entire BNDUPD: The OPTION_STATUS_CODE containing an error is Entire BNDUPD: The OPTION_STATUS_CODE containing an error is
present in the outermost option of the BNDACK -- either the single present in the outermost option of the BNDREPLY -- either the
OPTION_CLIENT_DATA option or the single OPTION_IAPREFIX option. single OPTION_CLIENT_DATA option or the single OPTION_IAPREFIX
An example of this sort of error might be that a VSS option was option. An example of this sort of error might be that a VSS
present and specified a VPN that might not exist in the receiving option was present and specified a VPN that might not exist in the
server. receiving server.
Single address or prefix: The OPTION_STATUS_CODE containing an Single address or prefix: The OPTION_STATUS_CODE containing an
error is present in a single IAADDR or IAPREFIX option which is error is present in a single IAADDR or IAPREFIX option which is
itself contained in an OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD itself contained in an OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
option. An example of this sort of error might be that a option. An example of this sort of error might be that a
particular IPv6 address was specified in an IAADDR option that particular IPv6 address was specified in an IAADDR option that
doesn't appear in the receiving server's configuration. doesn't appear in the receiving server's configuration.
Rejection present at either of these levels indicates rejection of Rejection present at either of these levels indicates rejection of
all of the information contained in the option (including any other all of the information contained in the option (including any other
options contained in that option) where the OPTION_STATUS_CODE option options contained in that option) where the OPTION_STATUS_CODE option
containing an error appears. The converse is not true -- an containing an error appears. The converse is not true -- an
OPTION_STATUS_CODE option containing success does not signify that OPTION_STATUS_CODE option containing success does not signify that
all of the contained information has been accepted. all of the contained information has been accepted.
If the BNDACK message contains an OPTION_CLIENT_DATA option, then the If the BNDREPLY message contains an OPTION_CLIENT_DATA option, then
OPTION_CLIENT_DATA option MUST contain at least the data shown below the OPTION_CLIENT_DATA option MUST contain at least the data shown
in its client-options section: below in its client-options section:
o OPTION_CLIENTID containing the DUID of the client most recently o OPTION_CLIENTID containing the DUID of the client most recently
associated with this IPv6 address*; associated with this IPv6 address*;
o OPTION_VSS from the BNDUPD, if any. o OPTION_VSS from the BNDUPD, if any.
o OPTION_IA_NA or OPTION_IA_TA for an IPv6 Address or OPTION_IA_PD o OPTION_IA_NA or OPTION_IA_TA for an IPv6 Address or OPTION_IA_PD
for an IPv6 Prefix. More than one of either of these options MAY for an IPv6 Prefix. More than one of either of these options MAY
appear if there are more than one associated with this client; appear if there are more than one associated with this client;
skipping to change at page 56, line 14 skipping to change at page 57, line 39
+ 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, An OPTION_STATUS_CODE option SHOULD NOT appear with a
OPTION_IA_TA, or OPTION_IA_PD option in the BNDUPD was success code unless a message associated with the
accepted, and no status message was required (which is success code needs to be included. The lack of an
the usual case), no OPTION_STATUS_CODE option appears. OPTION_STATUS_CODE option is an indication of success.
o OPTION_F_BINDING_STATUS containing the binding-status o OPTION_F_BINDING_STATUS containing the binding-status
received in the BNDUPD; received in the BNDUPD;
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, If the BNDREPLY message contains a top level OPTION_IAPREFIX option,
then the OPTION_IAPREFIX option MUST contain at least the data shown then the OPTION_IAPREFIX option MUST contain at least the data shown
below: below:
o IPv6 Prefix (with length); o IPv6 Prefix (with length);
o IAprefix-options: o IAprefix-options:
* OPTION_VSS from the BNDUPD, if any. * OPTION_VSS from the BNDUPD, if any.
* OPTION_STATUS_CODE containing an error code, or containing a * OPTION_STATUS_CODE containing an error code, or containing a
success code if a message is required. If the information in success code if a message is required. If the information in
the corresponding OPTION_IAPREFIX in the BNDUPD was accepted, the corresponding OPTION_IAPREFIX in the BNDUPD was accepted,
and no status message was required (which is the usual case), and no status message was required (which is the usual case),
no OPTION_STATUS_CODE option appears. no OPTION_STATUS_CODE option appears.
* OPTION_F_BINDING_STATUS containing the binding-status received * OPTION_F_BINDING_STATUS containing the binding-status received
in the BNDACK; in the BNDREPLY;
* OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state- * OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-
expiration-time received in the BNDACK; expiration-time received in the BNDREPLY;
* OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a * OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a
duplicate of the OPTION_F_PARTNER_LIFETIME received in the duplicate of the OPTION_F_PARTNER_LIFETIME received in the
BNDACK; BNDREPLY;
7.7. Receiving Binding Acks 7.7. Receiving Binding Acks
When a BNDACK is received the overall OPTION_CLIENT_DATA option or When a BNDREPLY is received the overall OPTION_CLIENT_DATA option or
the overall OPTION_IAPREFIX option may contain an OPTION_STATUS_CODE the overall OPTION_IAPREFIX option may contain an OPTION_STATUS_CODE
containing an error, representing an NAK of the entire BNDUPD. An containing an error, representing a rejection of the entire BNDUPD.
enclosed OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD option may also An enclosed OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD option may
contain an OPTION_STATUS_CODE containing an error which indicates also contain an OPTION_STATUS_CODE containing an error which
that everything in those options have been NAKed. Or an individual indicates that everything in containing option has been rejected. Or
IAADDR or IAPREFIX option may contain an OPTION_STATUS_CODE option an individual IAADDR or IAPREFIX option may contain an
containing an error, indicating that the IAADDR or IAPREFIX option OPTION_STATUS_CODE option containing an error, indicating that the
has been NAKed. An OPTION_STATUS_CODE containing a success code has IAADDR or IAPREFIX option has been rejected. An OPTION_STATUS_CODE
no bearing on the ACK or NAK status of the BNDACK at any level. containing a success code has no bearing on the acceptance status of
the BNDREPLY at any level.
Receipt of a NAK (or a part of a BNDACK that is a NAK) requires no Receipt of a rejection (or a part of a BNDREPLY that has been
processing other than remembering that it has been encountered. rejected) requires no processing other than remembering that it has
been encountered.
The information contained in the BNDACK in an OPTION_CLIENT_DATA that The information contained in the BNDREPLY in an OPTION_CLIENT_DATA
represents an ACK is stored with the appropriate client and lease, as that represents an acceptance is stored with the appropriate client
follows: and lease, as follows:
1. The OPTION_CLIENTID is used to find the client. 1. The OPTION_CLIENTID is used to find the client.
2. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD 2. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
option in the OPTION_CLIENT_DATA option and for each of the option in the OPTION_CLIENT_DATA option and for each of the
OPTION_IAADDR or OPTION_IAPREFIX options they contain: OPTION_IAADDR or OPTION_IAPREFIX options they contain:
1. OPTION_F_PARTNER_LIFETIME_SENT is stored in the acked- 1. OPTION_F_PARTNER_LIFETIME_SENT is stored in the acked-
partner-lifetime partner-lifetime
2. The time partner-lifetime is set to 0, to indicate that 2. The time partner-lifetime is set to 0, to indicate that
nothing additional needs to be sent to the partner.. nothing additional needs to be sent to the partner.
Alternatively, the BNDACK may contain a top level OPTION_IAPREFIX Alternatively, the BNDREPLY may contain a top level OPTION_IAPREFIX
option, representing information concerning a single prefix lease. option, representing information concerning a single prefix lease.
If the IAprefix-options section of the OPTION_IAPREFIX option If the IAprefix-options section of the OPTION_IAPREFIX option
contains an OPTION_STATUS_CODE representing an error, then it is contains an OPTION_STATUS_CODE representing an error, then it is
considered a NAK of the corresponding BNDUPD message. If the considered a rejection of the corresponding BNDUPD message. If the
OPTION_IAPREFIX option does not contain an OPTION_STATUS_CODE option OPTION_IAPREFIX option does not contain an OPTION_STATUS_CODE option
or if the OPTION_STATUS_CODE option contains a success status, then or if the OPTION_STATUS_CODE option contains a success status, then
the following information is stored in the lease state database, in the three items in the following list are stored in the lease state
the section associated with the prefix lease represented by the database, in the section associated with the prefix lease represented
OPTION_IAPREFIX option. by the OPTION_IAPREFIX option.
1. OPTION_F_BINDING_STATUS containing the binding-status received in 1. OPTION_F_BINDING_STATUS containing the binding-status received in
the BNDACK; the BNDREPLY;
2. OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state- 2. OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state-
expiration-time received in the BNDACK; expiration-time received in the BNDREPLY;
3. OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a duplicate 3. OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a duplicate
of the OPTION_F_PARTNER_LIFETIME received in the BNDACK; of the OPTION_F_PARTNER_LIFETIME received in the BNDREPLY;
7.8. BNDUPD/BNDACK Data Flow 7.8. BNDUPD/BNDREPLY 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 59, line 24 skipping to change at page 60, line 25
partner-raw-clt-time partner-raw-clt-time
start-time-of-state START_TIME_OF_STATE start-time-of-state start-time-of-state START_TIME_OF_STATE start-time-of-state
state-expiration-time STATE_EXPIRATION_TIME state-expiration-time state-expiration-time STATE_EXPIRATION_TIME state-expiration-time
[update only if received > current] [update only if received > current]
expiration-time EXPIRATION_TIME partner-lifetime expiration-time EXPIRATION_TIME partner-lifetime
partner-raw-clt-time PARTNER_RAW_CLT_TIME partner-raw-clt-time PARTNER_RAW_CLT_TIME
client-last-transaction-time client-last-transaction-time
----------------------- BNDACK ------------------------------ ----------------------- BNDREPLY ------------------------------
Storage on OPTION_F in Storage on Storage on OPTION_F in Storage on
Receiving Server <- BNDUPD message <- Sending Server Receiving Server <- BNDUPD message <- Sending Server
[ always update ] [ always update ]
acked-partner-lifetime PARTNER_LIFETIME_SENT duplicate of received acked-partner-lifetime PARTNER_LIFETIME_SENT duplicate of received
PARTNER_LIFETIME PARTNER_LIFETIME
(nothing to update) STATE_EXPIRATION_TIME state-expiration-time (nothing to update) STATE_EXPIRATION_TIME state-expiration-time
------------------------------------------------------------- -------------------------------------------------------------
Figure 4: BNDUPD and BNDACK Time Handling Figure 4: BNDUPD and BNDREPLY Time Handling
8. Endpoint States 8. Endpoint States
8.1. State Machine Operation 8.1. State Machine Operation
Each server (or, more accurately, failover endpoint) can take on a Each server (or, more accurately, failover endpoint) can take on a
variety of failover states. These states play a crucial role in variety of failover states. These states play a crucial role in
determining the actions that a server will perform when processing a determining the actions that a server will perform when processing a
request from a DHCP client as well as dealing with changing external request from a DHCP client as well as dealing with changing external
conditions (e.g., loss of connection to a failover partner). conditions (e.g., loss of connection to a failover partner).
skipping to change at page 64, line 12 skipping to change at page 66, line 12
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 communication 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
enough for a TCP connection to be created to a heavily loaded partner enough for a TCP connection to be created to a heavily loaded partner
across a slow network. across a slow network.
skipping to change at page 67, line 30 skipping to change at page 69, line 30
state will request an update of missing binding information by state will request an update of missing binding information by
sending an UPDREQ message. If the server has determined that it has sending an UPDREQ message. If the server has determined that it has
lost its stable storage because it has no record of ever having lost its stable storage because it has no record of ever having
talked to its partner, while its partner does have a record of talked to its partner, while its partner does have a record of
communicating with it, it MUST send an UPDREQALL message, otherwise communicating with it, it MUST send an UPDREQALL message, otherwise
it MUST send an UPDREQ message. it MUST send an UPDREQ message.
It will wait for an UPDDONE message, and upon receipt of that message It will wait for an UPDDONE message, and upon receipt of that message
it will transition to RECOVER-WAIT state. it will transition to RECOVER-WAIT state.
If communications fails during the reception of the results of the If communication fails during the reception of the results of the
UPDREQ or UPDREQALL message, the server will remain in RECOVER state, UPDREQ or UPDREQALL message, the server will remain in RECOVER state,
and will re-issue the UPDREQ or UPDREQALL when communications are re- and will re-issue the UPDREQ or UPDREQALL when communications are re-
established. established.
If an UPDDONE message isn't received within an implementation If an UPDDONE message isn't received within an implementation
dependent amount of time, and no BNDUPD messages are being received, dependent amount of time, and no BNDUPD messages are being received,
the connection SHOULD be dropped. the connection SHOULD be dropped.
A B A B
Server Server Server Server
| | | |
RECOVER PARTNER-DOWN RECOVER PARTNER-DOWN
| | | |
| >--UPDREQ--------------------> | | >--UPDREQ--------------------> |
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
| >--BNDACK--------------------> | | >--BNDREPLY------------------> |
... ... ... ...
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
| >--BNDACK--------------------> | | >--BNDREPLY------------------> |
| | | |
| <--------------------UPDDONE--< | | <--------------------UPDDONE--< |
| | | |
RECOVER-WAIT | RECOVER-WAIT |
| | | |
| >--STATE-(RECOVER-WAIT)------> | | >--STATE-(RECOVER-WAIT)------> |
| | | |
| | | |
Wait MCLT from last known | Wait MCLT from last known |
time of failover operation | time of failover operation |
skipping to change at page 68, line 42 skipping to change at page 70, line 42
| >--STATE-(RECOVER-DONE)------> | | >--STATE-(RECOVER-DONE)------> |
| NORMAL | NORMAL
| <-------------(NORMAL)-STATE--< | | <-------------(NORMAL)-STATE--< |
NORMAL | NORMAL |
| >---- State-(NORMAL)---------------> | | >---- State-(NORMAL)---------------> |
| | | |
| | | |
Figure 6: Transition out of RECOVER state Figure 6: Transition out of RECOVER state
If at any time while a server is in RECOVER state communications If at any time while a server is in RECOVER state communication
fails, the server will stay in RECOVER state. When communications fails, the server will stay in RECOVER state. When communications
are restored, it will restart the process of transitioning out of are restored, it will restart the process of transitioning out of
RECOVER state. RECOVER state.
8.6. RECOVER-WAIT State 8.6. RECOVER-WAIT State
This state indicates that the server has sent an UPDREQ or UPDREQALL This state indicates that the server has sent an UPDREQ or UPDREQALL
and has received the UPDDONE message indicating that it has received and has received the UPDDONE message indicating that it has received
all outstanding binding update information. In the RECOVER-WAIT all outstanding binding update information. In the RECOVER-WAIT
state the server will wait for the MCLT in order to ensure that any state the server will wait for the MCLT in order to ensure that any
skipping to change at page 69, line 19 skipping to change at page 71, line 19
The server MUST NOT be responsive in RECOVER-WAIT state. The server MUST NOT be responsive in RECOVER-WAIT state.
8.6.2. Transition Out of RECOVER-WAIT State 8.6.2. Transition Out of RECOVER-WAIT State
Upon entry to RECOVER-WAIT state the server MUST start a timer whose Upon entry to RECOVER-WAIT state the server MUST start a timer whose
expiration is set to a time equal to the time the server went down expiration is set to a time equal to the time the server went down
(if known) or the time the server started (if the down-time is (if known) or the time the server started (if the down-time is
unknown) plus the maximum-client-lead-time. When this timer expires, unknown) plus the maximum-client-lead-time. When this timer expires,
the server will transition into RECOVER-DONE state. the server will transition into RECOVER-DONE state.
This is to allow any IPv6 addresses that were allocated by this This is to allow any IPv6 addresses or prefixes that were allocated
server prior to loss of its client binding information in stable by this server prior to loss of its client binding information in
storage to contact the other server or to time out. stable storage to contact the other server or to time out.
If the server has never before run failover, then there is no need to If the server has never before run failover, then there is no need to
wait in this state and the server MAY transition immediately to wait in this state and the server MAY transition immediately to
RECOVER_DONE state. However, to determine if this server has run RECOVER_DONE state. However, to determine if this server has run
failover it is vital that the information provided by the partner be failover it is vital that the information provided by the partner be
utilized, since the stable storage of this server may have been lost. utilized, since the stable storage of this server may have been lost.
If communications fails while a server is in RECOVER-WAIT state, it If communication fails while a server is in RECOVER-WAIT state, it
has no effect on the operation of this state. The server SHOULD has no effect on the operation of this state. The server SHOULD
continue to operate its timer, and if the timer expires during the continue to operate its timer, and if the timer expires during the
period where communications with the other server have failed, then period where communications with the other server have failed, then
the server SHOULD transition to RECOVER-DONE state. This is rare -- the server SHOULD transition to RECOVER-DONE state. This is rare --
failover state transitions are not usually made while communications failover state transitions are not usually made while communications
are interrupted, but in this case there is no reason to inhibit this are interrupted, but in this case there is no reason to inhibit this
transition. transition.
8.7. RECOVER-DONE State 8.7. RECOVER-DONE State
This state exists to allow an interlocked transition for one server This state exists to allow an interlocked transition for one server
from RECOVER state and another server from PARTNER-DOWN or from RECOVER state and another server from PARTNER-DOWN or
COMMUNICATIONS-INTERRUPTED state into NORMAL state. COMMUNICATIONS-INTERRUPTED state into NORMAL state.
8.7.1. Operation in RECOVER-DONE State 8.7.1. Operation in RECOVER-DONE State
A server in RECOVER-DONE state SHOULD be renew responsive, and MAY A server in RECOVER-DONE state SHOULD be renew responsive, and MAY
respond to RENEW requests but MUST only change the state of lease respond to RENEW requests but MUST only change the state of a lease
that appear in the RENEW request. It MUST NOT allocate any that appears in the RENEW request. It MUST NOT allocate any
additional leases when in RECOVER-DONE state. additional leases when in RECOVER-DONE state and should only respond
only to RENEW requests where it already has a record of the lease.
8.7.2. Transition Out of RECOVER-DONE State 8.7.2. Transition Out of RECOVER-DONE State
When a server in RECOVER-DONE state determines that its partner When a server in RECOVER-DONE state determines that its partner
server has entered NORMAL or RECOVER-DONE state, then it will server has entered NORMAL or RECOVER-DONE state, then it will
transition into NORMAL state. transition into NORMAL state.
If the partner server enters RECOVER or RECOVER-WAIT state, this If the partner server enters RECOVER or RECOVER-WAIT state, this
server transitions to COMMUNICATIONS-INTERRUPTED. server transitions to COMMUNICATIONS-INTERRUPTED.
skipping to change at page 71, line 13 skipping to change at page 73, line 13
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 DHCP client request attempts to update its the server servicing a DHCP client request attempts to update its
partner with the new binding information. See Section 4.3. partner with the new binding information. See Section 4.3.
Reallocation of leases between clients Reallocation of leases between clients
Whenever a client binding is released or expires, a BNDUPD message Whenever a client binding is released or expires, a BNDUPD message
must be sent to the partner, setting the binding state to RELEASED must be sent to the partner, setting the binding state to RELEASED
or EXPIRED. However, until a BNDACK is received for this message, or EXPIRED. However, until a BNDREPLY is received for this
the lease cannot be allocated to another client. It cannot be message, the lease cannot be allocated to another client. It
allocated to the same client again if a BNDUPD was sent, otherwise cannot be allocated to the same client again if a BNDUPD was sent,
it can. See Section 4.2.2.1 for details. otherwise it can. See Section 4.2.2.1 for details.
In NORMAL state, each server receives binding updates from its In NORMAL state, each server receives binding updates from its
partner server in BNDUPD messages (see Section 7.5.5). It records partner server in BNDUPD messages (see Section 7.5.5). It records
these in its binding database in stable storage and then sends a these in its binding database in stable storage and then sends a
corresponding BNDACK message to its partner server (see Section 7.6). corresponding BNDREPLY 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.
If a server in NORMAL state fails to receive acks to messages sent to If a server in NORMAL state fails to receive acks to messages sent to
skipping to change at page 74, line 18 skipping to change at page 76, line 18
NORMAL NORMAL NORMAL NORMAL
| >--CONTACT-------------------> | | >--CONTACT-------------------> |
| <--------------------CONTACT--< | | <--------------------CONTACT--< |
| [TCP connection broken] | | [TCP connection broken] |
COMMUNICATIONS : COMMUNICATIONS COMMUNICATIONS : COMMUNICATIONS
INTERRUPTED : INTERRUPTED INTERRUPTED : INTERRUPTED
| [attempt new TCP connection] | | [attempt new TCP connection] |
| [connection succeeds] | | [connection succeeds] |
| | | |
| >--CONNECT-------------------> | | >--CONNECT-------------------> |
| <-----------------CONNECTACK--< | | <---------------CONNECTREPLY--< |
| NORMAL | NORMAL
| <-------------------STATE-----< | | <-------------------STATE-----< |
NORMAL | NORMAL |
| >--STATE---------------------> | | >--STATE---------------------> |
| |
| >--BNDUPD--------------------> | | >--BNDUPD--------------------> |
| <---------------------BNDACK--< | | <-------------------BNDREPLY--< |
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
| >------BNDACK----------------> | | >------BNDREPLY--------------> |
... ... ... ...
| | | |
| <--------------------POOLREQ--< | | <--------------------POOLREQ--< |
| >--POOLRESP------------------> | | >--POOLRESP------------------> |
| | | |
| >--BNDUPD-(#1)---------------> | | >--BNDUPD-(#1)---------------> |
| <---------------------BNDACK--< | | <-------------------BNDREPLY--< |
| | | |
| >--BNDUPD-(#2)---------------> | | >--BNDUPD-(#2)---------------> |
| <---------------------BNDACK--< | | <-------------------BNDREPLY--< |
| | | |
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
skipping to change at page 75, line 23 skipping to change at page 77, line 23
A secondary server entering POTENTIAL-CONFLICT state will wait for A secondary server entering POTENTIAL-CONFLICT state will wait for
the primary to send it an UPDREQ message. the primary to send it an UPDREQ message.
8.10.1. Operation in POTENTIAL-CONFLICT State 8.10.1. Operation in POTENTIAL-CONFLICT State
Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming
DHCP requests. DHCP requests.
8.10.2. Transition Out of POTENTIAL-CONFLICT State 8.10.2. Transition Out of POTENTIAL-CONFLICT State
If communications fails with the partner while in POTENTIAL-CONFLICT If communication 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
MUST transition to NORMAL state. This will cause the primary server MUST transition to NORMAL state. This will cause the primary server
to leave POTENTIAL-CONFLICT state prior to the secondary, since the to leave POTENTIAL-CONFLICT state prior to the secondary, since the
primary sends an UPDREQ message and receives an UPDDONE before the primary sends an UPDREQ message and receives an UPDDONE before the
secondary sends an UPDREQ message and receives its UPDDONE message. secondary sends an UPDREQ message and receives its UPDDONE message.
skipping to change at page 76, line 14 skipping to change at page 78, line 14
Primary Secondary Primary Secondary
Server Server Server Server
| | | |
POTENTIAL-CONFLICT POTENTIAL-CONFLICT POTENTIAL-CONFLICT POTENTIAL-CONFLICT
| | | |
| >--UPDREQ--------------------> | | >--UPDREQ--------------------> |
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
| >--BNDACK--------------------> | | >--BNDREPLY------------------> |
... ... ... ...
| | | |
| <---------------------BNDUPD--< | | <---------------------BNDUPD--< |
| >--BNDACK--------------------> | | >--BNDREPLY------------------> |
| | | |
| <--------------------UPDDONE--< | | <--------------------UPDDONE--< |
CONFLICT-DONE | CONFLICT-DONE |
| >--STATE--(CONFLICT-DONE)----> | | >--STATE--(CONFLICT-DONE)----> |
| <---------------------UPDREQ--< | | <---------------------UPDREQ--< |
| | | |
| >--BNDUPD--------------------> | | >--BNDUPD--------------------> |
| <---------------------BNDACK--< | | <-------------------BNDREPLY--< |
... ... ... ...
| >--BNDUPD--------------------> | | >--BNDUPD--------------------> |
| <---------------------BNDACK--< | | <-------------------BNDREPLY--< |
| | | |
| >--UPDDONE-------------------> | | >--UPDDONE-------------------> |
| NORMAL | NORMAL
| <------------STATE--(NORMAL)--< | | <------------STATE--(NORMAL)--< |
NORMAL | NORMAL |
| >--STATE--(NORMAL)-----------> | | >--STATE--(NORMAL)-----------> |
| | | |
| <--------------------POOLREQ--< | | <--------------------POOLREQ--< |
| >------POOLRESP--------------> | | >------POOLRESP--------------> |
| | | |
Figure 8: Transition out of POTENTIAL-CONFLICT Figure 8: Transition out of POTENTIAL-CONFLICT
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. communication 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 DHCP server that remains in service will not be able to process DHCP
client requests and there will be no DHCP 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
skipping to change at page 78, line 11 skipping to change at page 80, line 11
responds to all clients' requests. The distinction between CONFLICT- responds to all clients' requests. The distinction between CONFLICT-
DONE and NORMAL states 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
DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED
state). state).
If communications fails, remain in CONFLICT-DONE state. If If communication 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 communication fails with the partner while in CONFLICT-DONE state,
state, then the server will remain in CONFLICT-DONE state. then the server will remain in CONFLICT-DONE state.
When a primary server determines that the secondary server has made a When a primary server determines that the secondary server has made a
transition into NORMAL state, the primary server will also transition transition into NORMAL state, the primary server will also transition
into NORMAL state. into NORMAL state.
9. DNS Update Considerations 9. DNS Update Considerations
DHCP servers (and clients) can use DNS Updates as described in RFC DHCP servers (and clients) can use DNS Updates as described in RFC
2136 [RFC2136] to maintain DNS name-mappings as they maintain DHCP 2136 [RFC2136] to maintain DNS name-mappings as they maintain DHCP
leases. Many different administrative models for DHCP-DNS leases. Many different administrative models for DHCP-DNS
skipping to change at page 79, line 15 skipping to change at page 81, line 15
From the standpoint of the failover protocol, there is no reason why From the standpoint of the failover protocol, there is no reason why
a server which is utilizing the DNS update protocol to update a DNS a server which is utilizing the DNS update protocol to update a DNS
server should not be a partner with a server which is not utilizing server should not be a partner with a server which is not utilizing
the DNS update protocol to update a DNS server. However, a server the DNS update protocol to update a DNS server. However, a server
which is not able to support DNS update or is not configured to which is not able to support DNS update or is not configured to
support DNS update SHOULD output a warning message when it receives support DNS update SHOULD output a warning message when it receives
BNDUPD messages which indicate that its failover partner is BNDUPD messages which indicate that its failover partner is
configured to support the DNS update protocol to update a DNS server. configured to support the DNS update protocol to update a DNS server.
An implementation MAY consider this an error and refuse to accept the An implementation MAY consider this an error and refuse to accept the
BNDUPD by returning the status DNSUpdateNotSupported in an BNDUPD by returning the status DNSUpdateNotSupported in an
OPTION_STATUS_CODE option in the BNDACK message, or it MAY choose to OPTION_STATUS_CODE option in the BNDREPLY message, or it MAY choose
operate anyway, having warned the administrator of the problem in to operate anyway, having warned the administrator of the problem in
some way. some way.
9.1. Relationship between failover and DNS update 9.1. Relationship between failover and DNS update
The failover protocol describes the conditions under which each The failover protocol describes the conditions under which each
failover server may renew a lease to its current DHCP client, and failover server may renew a lease to its current DHCP client, and
describes the conditions under which it may grant a lease to a new describes the conditions under which it may grant a lease to a new
DHCP client. An analogous set of conditions determines when a DHCP client. An analogous set of conditions determines when a
failover server should initiate a DNS update, and when it should failover server should initiate a DNS update, and when it should
attempt to remove records from the DNS. The failover protocol's attempt to remove records from the DNS. The failover protocol's
skipping to change at page 82, line 50 skipping to change at page 84, line 50
9.4. Deleting RRs from the DNS 9.4. Deleting RRs from the DNS
The failover server which makes a lease PENDING-FREE SHOULD initiate The failover server which makes a lease PENDING-FREE SHOULD initiate
any DNS deletes, if it has recorded that DNS records were added on any DNS deletes, if it has recorded that DNS records were added on
behalf of the client. behalf of the client.
A server not in PARTNER-DOWN state "makes a lease PENDING-FREE" when A server not in PARTNER-DOWN state "makes a lease PENDING-FREE" when
it initiates a BNDUPD with a binding-status of FREE, FREE-BACKUP, it initiates a BNDUPD 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 BNDREPLY the server has "made
lease PENDING-FREE". Conversely, a server in PARTNER-DOWN state the lease PENDING-FREE". Conversely, a server in PARTNER-DOWN state
"makes a lease PENDING-FREE" when it sets the binding-status to FREE, "makes a lease PENDING-FREE" when it sets the binding-status to FREE,
since in PARTNER-DOWN state no communications is required with the since in PARTNER-DOWN state no communications is required with the
partner. partner.
It is at this point that it should initiate the DNS operations to It is at this point that it should initiate the DNS operations to
delete RRs from the DNS. Its partner SHOULD NOT initiate DNS deletes delete RRs from the DNS. Its partner SHOULD NOT initiate DNS deletes
for DNS records related to the lease binding as part of sending the for DNS records related to the lease binding as part of sending the
BNDACK message. The partner MAY have issued BNDUPD messages with a BNDREPLY message. The partner MAY have issued BNDUPD messages with a
binding-status of FREE, EXPIRED, or RELEASED previously, but the binding-status of FREE, EXPIRED, or RELEASED previously, but the
other server will have rejected these BNDUPD messages. other server will have rejected these BNDUPD messages.
The failover protocol ensures that only one of the two partner The failover protocol ensures that only one of the two partner
servers will be able to make a lease PENDING-FREE. The server making servers will be able to make a lease PENDING-FREE. The server making
the lease PENDING-FREE may be doing so while it is in NORMAL the lease PENDING-FREE may be doing so while it is in NORMAL
communication with its partner, or it may be in PARTNER-DOWN state. communication with its partner, or it may be in PARTNER-DOWN state.
If a server is in PARTNER-DOWN state, it may be performing DNS If a server is in PARTNER-DOWN state, it may be performing DNS
deletes for RRs which its partner added originally. This allows a deletes for RRs which its partner added originally. This allows a
single remaining partner server to assume responsibility for all of single remaining partner server to assume responsibility for all of
skipping to change at page 84, line 25 skipping to change at page 86, 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 BNDREPLY (TBD2)
o POOLREQ (TBD3) o POOLREQ (TBD3)
o POOLRESP (TBD4) o POOLRESP (TBD4)
o UPDREQ (TBD5) o UPDREQ (TBD5)
o UPDREQALL (TBD6) o UPDREQALL (TBD6)
o UPDDONE (TBD7) o UPDDONE (TBD7)
o CONNECT (TBD8) o CONNECT (TBD8)
o CONNECTACK (TBD9)
o CONNECTREPLY (TBD9)
o DISCONNECT (TBD10) o DISCONNECT (TBD10)
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_CONNECT_FLAGS (TBD14) OPTION_F_CONNECT_FLAGS (TBD14)
OPTION_F_DNS_REMOVAL_INFO (TBD15) OPTION_F_DNS_REMOVAL_INFO (TBD15)
skipping to change at page 85, line 44 skipping to change at page 87, line 36
OPTION_F_PARTNER_LIFETIME (TBD22) OPTION_F_PARTNER_LIFETIME (TBD22)
OPTION_F_PARTNER_LIFETIME_SENT (TBD23) OPTION_F_PARTNER_LIFETIME_SENT (TBD23)
OPTION_F_PARTNER_DOWN_TIME (TBD24) OPTION_F_PARTNER_DOWN_TIME (TBD24)
OPTION_F_PARTNER_RAW_CLT_TIME (TBD25) OPTION_F_PARTNER_RAW_CLT_TIME (TBD25)
OPTION_F_PROTOCOL_VERSION (TBD26) OPTION_F_PROTOCOL_VERSION (TBD26)
OPTION_F_RECEIVE_TIME (TBD27) OPTION_F_KEEPALIVE_TIME (TBD27)
OPTION_F_RECONFIGURE_DATA (TBD28) OPTION_F_RECONFIGURE_DATA (TBD28)
OPTION_F_RELATIONSHIP_NAME (TBD29) OPTION_F_RELATIONSHIP_NAME (TBD29)
OPTION_F_SERVER_FLAGS (TBD30) OPTION_F_SERVER_FLAGS (TBD30)
OPTION_F_SERVER_STATE (TBD31) OPTION_F_SERVER_STATE (TBD31)
OPTION_F_START_TIME_OF_STATE (TBD32) OPTION_F_START_TIME_OF_STATE (TBD32)
OPTION_F_STATE_EXPIRATION_TIME (TBD33) 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:
 End of changes. 172 change blocks. 
375 lines changed or deleted 414 lines changed or added

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