draft-ietf-dhc-dhcpv6-failover-protocol-02.txt   draft-ietf-dhc-dhcpv6-failover-protocol-03.txt 
Dynamic Host Configuration (DHC) T. Mrugalski Dynamic Host Configuration (DHC) T. Mrugalski
Internet-Draft ISC Internet-Draft ISC
Intended status: Standards Track K. Kinnear Intended status: Standards Track K. Kinnear
Expires: January 1, 2017 Cisco Expires: April 16, 2017 Cisco
June 30, 2016 October 13, 2016
DHCPv6 Failover Protocol DHCPv6 Failover Protocol
draft-ietf-dhc-dhcpv6-failover-protocol-02 draft-ietf-dhc-dhcpv6-failover-protocol-03
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 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 with the capability for either
capability for either server to take over clients' leases in case of server to take over clients' leases in case of server failure or
server failure or network partition. It meets the requirements for network partition. It meets the requirements for DHCPv6 failover
DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC7031). 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 January 1, 2017. This Internet-Draft will expire on April 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Failover Concepts and Mechanisms . . . . . . . . . . . . . . 8 4. Failover Concepts and Mechanisms . . . . . . . . . . . . . . 8
4.1. Required Server Configuration . . . . . . . . . . . . . . 8 4.1. Required Server Configuration . . . . . . . . . . . . . . 8
4.2. IPv6 Address and Delegable Prefix Allocation . . . . . . 9 4.2. IPv6 Address and Delegable Prefix Allocation . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . 13
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. BNDREPLY . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
5.5.17. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 31 5.5.17. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 31
5.5.18. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 32 5.5.18. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 32
5.5.19. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 33 5.5.19. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 33
5.5.20. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 34 5.5.20. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 34
5.5.21. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 35 5.5.21. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 35
5.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 36 5.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 36
6. Connection Management . . . . . . . . . . . . . . . . . . . . 37 6. Connection Management . . . . . . . . . . . . . . . . . . . . 37
6.1. Creating Connections . . . . . . . . . . . . . . . . . . 37 6.1. Creating Connections . . . . . . . . . . . . . . . . . . 37
6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 38 6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 38
6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 38 6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 38
6.1.3. Receiving a CONNECTREPLY message . . . . . . . . . . 39 6.1.3. Receiving a CONNECTREPLY message . . . . . . . . . . 40
6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 40 6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 40
6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 41 6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 41
6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 41 6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 42
6.5. Connection Maintenance Parameters . . . . . . . . . . . . 42 6.5. Connection Maintenance Parameters . . . . . . . . . . . . 42
6.6. Unreachability detection . . . . . . . . . . . . . . . . 43 6.6. Unreachability detection . . . . . . . . . . . . . . . . 43
7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 43 7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 44
7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 43 7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 44
7.2. Information model . . . . . . . . . . . . . . . . . . . . 44 7.2. Information model . . . . . . . . . . . . . . . . . . . . 44
7.3. Times Required for Exchanging Binding Updates . . . . . . 47 7.3. Times Required for Exchanging Binding Updates . . . . . . 48
7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 48 7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 49
7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 51 7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 52
7.5.1. Monitoring Time Skew . . . . . . . . . . . . . . . . 51 7.5.1. Monitoring Time Skew . . . . . . . . . . . . . . . . 52
7.5.2. Acknowledging Reception . . . . . . . . . . . . . . . 52 7.5.2. Acknowledging Reception . . . . . . . . . . . . . . . 52
7.5.3. Processing Binding Updates . . . . . . . . . . . . . 52 7.5.3. Processing Binding Updates . . . . . . . . . . . . . 52
7.5.4. Accept or Reject? . . . . . . . . . . . . . . . . . . 53 7.5.4. Accept or Reject? . . . . . . . . . . . . . . . . . . 53
7.5.5. Accepting Updates . . . . . . . . . . . . . . . . . . 55 7.5.5. Accepting Updates . . . . . . . . . . . . . . . . . . 55
7.6. Sending Binding Replies . . . . . . . . . . . . . . . . . 56 7.6. Sending Binding Replies . . . . . . . . . . . . . . . . . 56
7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 58 7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 58
7.8. BNDUPD/BNDREPLY Data Flow . . . . . . . . . . . . . . . . 59 7.8. BNDUPD/BNDREPLY Data Flow . . . . . . . . . . . . . . . . 59
8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 60 8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 60
8.1. State Machine Operation . . . . . . . . . . . . . . . . . 60 8.1. State Machine Operation . . . . . . . . . . . . . . . . . 60
8.2. State Machine Initialization . . . . . . . . . . . . . . 64 8.2. State Machine Initialization . . . . . . . . . . . . . . 64
skipping to change at page 5, line 12 skipping to change at page 5, line 12
This protocol defines an active-passive mode, sometimes also called a This protocol defines an active-passive mode, sometimes also called a
hot standby model. This means that during normal operation one hot standby model. This means that during normal operation one
server is active (i.e. actively responds to clients' requests) while server is active (i.e. actively responds to clients' requests) while
the second is passive (i.e. it receives clients' requests, but the second is passive (i.e. it receives clients' requests, but
responds only to those specifically directed to it). The secondary responds only to those specifically directed to it). The secondary
maintains a copy of the binding database and is ready to take over maintains a copy of the binding database and is ready to take over
all incoming queries in case of primary server failure. all incoming queries in case of primary server failure.
The failover protocol is designed to provide lease stability for The failover protocol is designed to provide lease stability for
leases with valid lifetimes beyond a short period. The DHCPv6 leases with valid lifetimes beyond a short period. The DHCPv6
Failover protocol MUST NOT be used for leases shorter than 30 Failover protocol MUST NOT be used for new leases shorter than 30
seconds. seconds. Leases reaching the end of their liftetime are not affected
by this restriction.
This protocol fulfills all DHCPv6 failover requirements defined in This protocol fulfills all DHCPv6 failover requirements defined in
[RFC7031]. [RFC7031].
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 6, line 16 skipping to change at page 6, line 17
and FREE-BACKUP on the secondary server". and FREE-BACKUP on the secondary server".
o Binding-Status o Binding-Status
A lease can hold a variety of states (see Section 5.5.1 for a A lease can hold a variety of states (see Section 5.5.1 for a
list) and these are also referred to as the binding-status of the list) 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, using the
in [RFC3633]. A prefix which has been delegated is known as a mechanisms described in [RFC3633]. A prefix which has been
"delegated prefix" or a "prefix lease". delegated is known as a "delegated prefix" or a "prefix lease".
o Delegated Prefix o Delegated Prefix
A prefix which has been deletegated to a DHCP client as described A prefix which has been deletegated to a DHCP client as described
in [RFC3633]. Depending on the context, a delegated prefix may in [RFC3633]. Depending on the context, a delegated prefix may
also be described as a "prefix lease", when it is necessary to also be described as a "prefix lease", when it is necessary to
distinguish it from an "address lease". distinguish it from an "address lease".
o Failover endpoint o Failover endpoint
skipping to change at page 7, line 46 skipping to change at page 7, line 49
o Proportional Allocation o Proportional Allocation
An allocation algorithm that splits the delegable prefixes between An allocation algorithm that splits the delegable prefixes between
the primary and secondary servers and maintains a more or less the primary and secondary servers and maintains a more or less
fixed proportion of the delegable prefixes between both servers. fixed proportion of the delegable prefixes between both servers.
Section 4.2.2. Section 4.2.2.
o Renew Responsive o Renew Responsive
A server that is renew responsive will respond to DHCP client A server that is renew responsive will respond to valid DHCP
requests that are directed to it by having an OPTION_SERVERID client requests that are directed to it by having an
option in the message which contains the DUID of the renew OPTION_SERVERID option in the message which contains the DUID of
responsive server. See [RFC3315]. the renew responsive server. See [RFC3315].
o Responsive o Responsive
A server that is responsive will respond to all DHCP client
A server that is responsive will respond to all valid DHCP client
requests. requests.
o Secondary Server o Secondary Server
Second of two DHCP servers that participate in a failover Second of two DHCP servers that participate in a failover
relationship. Its failover partner is referred to as the primary relationship. Its failover partner is referred to as the primary
server. When both servers are operating this server (the server. When both servers are operating this server (the
secondary) typically does not handle client traffic and acts as a secondary) typically does not handle client traffic and acts as a
backup to the primary server. It will respond, however, to RENEW backup to the primary server. It will respond, however, to RENEW
requests directed specifically to it. requests directed specifically to it.
skipping to change at page 10, line 51 skipping to change at page 10, line 51
A server delegates prefixes only from its own pool of delegable A server delegates prefixes only from its own pool of delegable
prefixes in all states except for PARTNER-DOWN. In PARTNER-DOWN prefixes in all states except for PARTNER-DOWN. In PARTNER-DOWN
state the operational partner can delegate prefixes from either pool state the operational partner can delegate prefixes from either pool
(both its own, and its partner's after some time constraints have (both its own, and its partner's after some time constraints have
elapsed). The operational partner SHOULD allocate from its own pool elapsed). The operational partner SHOULD allocate from its own pool
before using its partner's pool. The allocation and maintenance of before using its partner's pool. The allocation and maintenance of
these pools of delegable prefixes is important, since the goal is to these pools of delegable prefixes is important, since the goal is to
maintain a more or less constant ratio of delegable prefixes between maintain a more or less constant ratio of delegable prefixes between
the two servers. the two servers.
Each server knows which delegable prefixes are in its own pool as
well as which are in its partner's pool, so that it can allocate
delegable prefixes from its partner's pool without communication with
its partner if that becomes necessary.
The initial allocation of delegable prefixes from the primary to the The initial allocation of delegable prefixes from the primary to the
secondary when the servers first integrate is triggered by the secondary when the servers first integrate is triggered by the
POOLREQ message from the secondary to the primary. This is followed POOLREQ message from the secondary to the primary. This is followed
(at some point) by the POOLRESP message where the primary tells the (at some point) by the POOLRESP message where the primary tells the
secondary that it received and processed the POOLREQ message. The secondary that it received and processed the POOLREQ message. The
primary sends the allocated delegable prefixes to the secondary as primary sends the allocated delegable prefixes to the secondary as
prefix leases via BNDUPD messages. The POOLRESP message may be sent prefix leases via BNDUPD messages. The POOLRESP message may be sent
before, during, or at the completion of the BNDUPD message exchanges before, during, or at the completion of the BNDUPD message exchanges
that were triggered by the POOLREQ message. The POOLREQ/POOLRESP that were triggered by the POOLREQ message. The POOLREQ/POOLRESP
message exchange is a trigger to the primary to perform a scan of its message exchange is a trigger to the primary to perform a scan of its
skipping to change at page 15, line 9 skipping to change at page 15, line 18
this case is zero) and determines the remainder of the time left to this case is zero) and determines the remainder of the time left to
run, which is also zero. It adds the MCLT to this value. Since the run, which is also zero. It adds the MCLT to this value. Since the
actual lifetime cannot be allowed to exceed the remainder of the actual lifetime cannot be allowed to exceed the remainder of the
current acknowledged partner lifetime plus the MCLT, the offer made current acknowledged partner lifetime plus the MCLT, the offer made
to the client is for the remainder of the current acknowledged to the client is for the remainder of the current acknowledged
partner lifetime (i.e. zero) plus the MCLT. Thus, the actual partner lifetime (i.e. zero) plus the MCLT. Thus, the actual
lifetime is 1 hour (the MCLT). lifetime is 1 hour (the MCLT).
Once the server has sent the REPLY to the 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. The partner lifetime will be composed of the T1 fraction
one half of the current actual lifetime added to the desired (1/2) of the actual lifetime added to the desired lifetime. Thus,
lifetime. Thus, the failover partner is updated with a BNDUPD with a the failover partner is updated using a BNDUPD with a partner
partner lifetime of 1/2 hour + 3 days. lifetime of 1/2 hour + 3 days.
When the primary server receives a BNDREPLY to its update of the When the primary server receives a BNDREPLY to its update of the
secondary server's (partner's) partner lifetime, it records that as secondary server's (partner's) partner lifetime, it records that as
the acknowledged partner lifetime. A server MUST NOT send a BNDREPLY the acknowledged partner lifetime. A server MUST NOT send a BNDREPLY
in response to a BNDUPD message until it is sure that the information 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 lifetime in its
its stable storage when the primary server receives a BNDREPLY stable storage when the primary server receives a BNDREPLY message
message from the secondary server. 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
lifetime -- 3 days. lifetime -- 3 days.
When the primary DHCP server updates the secondary DHCP server after When the primary DHCP server updates the secondary DHCP server after
the DHCP client's renewal REPLY is complete, it will calculate the the DHCP client's renewal REPLY is complete, it will calculate the
desired partner lifetime as the T1 fraction of the actual client partner lifetime as the T1 fraction of the actual client lifetime
lifetime (1/2 of 3 days this time = 1.5 days). To this it will add (1/2 of 3 days this time = 1.5 days). To this it will add the
the desired client lifetime of 3 days, yielding a total desired desired lifetime of 3 days, yielding a total partner lifetime of 4.5
partner lifetime of 4.5 days. In this way, the primary attempts to days. In this way, the primary attempts to have the secondary always
have the secondary always "lead" the client in its understanding of "lead" the client in its understanding of the client's lifetime so as
the client's lifetime so as to be able to always offer the client the to be able to always offer the client the desired lifetime.
desired client lifetime.
Once the initial actual client lifetime of the MCLT is past, the Once the initial actual client lifetime of the MCLT is past, the
protocol operates effectively like the DHCP protocol does today in protocol operates effectively like the DHCP protocol does today in
its behavior concerning lifetimes. However, the guarantee that the its behavior concerning lifetimes. However, the guarantee that the
actual client lifetime will never exceed the remaining acknowledged actual client lifetime will never exceed the remaining acknowledged
partner server partner lifetime by more than the MCLT allows full partner server partner lifetime by more than the MCLT allows full
recovery from a variety of DHCP server failures. recovery from a variety of DHCP server failures.
5. Message and Option Definitions 5. Message and Option Definitions
skipping to change at page 18, line 34 skipping to change at page 18, line 34
server to indicate that it has received the secondary's servers server to indicate that it has received the secondary's servers
request to ensure that delegable prefixes are balanced between the request to ensure that delegable prefixes are balanced between the
primary and secondary servers. It does not indicate that all of the primary and secondary servers. It does not indicate that all of the
BNDUPDs that might be created from any rebalancing have been sent or BNDUPDs that might be created from any rebalancing have been sent or
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 sends all binding database changes that have
not yet been confirmed. The partner is expected to respond with zero not yet been confirmed. The partner is expected to respond with zero
or more BNDUPD messages, followed by an UPDDONE message that signals or more BNDUPD messages, followed by an UPDDONE message that signals
that all of the BNDUPD messages have been sent and a corresponding that all of the BNDUPD messages have been sent and a corresponding
BNDREPLY message has been received for each of them. BNDREPLY message has been received for each of them.
5.3.6. UPDREQALL 5.3.6. UPDREQALL
The update request all UPDREQALL (TBD6) is used by one server to The update request all 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
skipping to change at page 27, line 17 skipping to change at page 27, line 17
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_F_MCLT | option-len | | OPTION_F_MCLT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mclt | | mclt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_F_MCLT (TBD21). option-code OPTION_F_MCLT (TBD21).
option-len 4. option-len 4.
mclt The maximum-client-lease-time, in seconds. mclt The maximum-client-lead-time, in seconds.
5.5.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.
skipping to change at page 37, line 5 skipping to change at page 36, line 52
more accurately reflects reality. more accurately reflects reality.
ServerShuttingDown (TBD38) ServerShuttingDown (TBD38)
Returned when the server is undergoing an operator directed or Returned when the server is undergoing an operator directed or
otherwise planned shutdown. otherwise planned shutdown.
DNSUpdateNotSupported (TBD39) DNSUpdateNotSupported (TBD39)
Returned when a server receives a BNDUPD with DNS update Returned when a server receives a BNDUPD with DNS update
information included, and the server doesn't support DNS update. information included, and the server doesn't support DNS update.
ExcessiveTimeSkew (TBD40)
Returned when a server detects that the time skew between its
current time and its partner's current time is greater than 5
seconds.
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 CONNECTREPLY 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
skipping to change at page 38, line 39 skipping to change at page 38, line 44
o OPTION_F_CONNECT_FLAGS containing information about certain o OPTION_F_CONNECT_FLAGS containing information about certain
attributes of the connecting servers. attributes of the connecting servers.
6.1.2. Receiving a CONNECT message 6.1.2. Receiving a CONNECT message
A server receiving a CONNECT message must process the information in A server receiving a CONNECT message must process the information in
the message and decide whether or not to accept the connection. The the message and decide whether or not to accept the connection. The
processing is performed as follows: processing is performed as follows:
o sent-time - The secondary server checks the sent-time to see if it
is within 5 seconds of its current time. See Section 7.1. If it
is not, return ExcessiveTimeSkew in the OPTION_STATUS_CODE to
reject the CONNECT message.
o OPTION_F_PROTOCOL_VERSION - The secondary server decides if the o OPTION_F_PROTOCOL_VERSION - The secondary server decides if the
protocol version of the primary server is supported by the protocol version of the primary server is supported by the
secondary server. If it is not, return NotSupported in the secondary server. If it is not, return NotSupported in the
OPTION_STATUS_CODE to reject the CONNECT message. OPTION_STATUS_CODE to reject the CONNECT message.
o OPTION_F_MCLT - Use this MCLT supplied by the primary server. o OPTION_F_MCLT - Use this MCLT supplied by the primary server.
Remember this MCLT and use it until a different MCLT is supplied Remember this MCLT and use it until a different MCLT is supplied
by some subsequent CONNECT message. by some subsequent CONNECT message.
o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the
skipping to change at page 51, line 44 skipping to change at page 52, line 12
[RFC7653], some of which feature queries based on Relay-ID, by link [RFC7653], some of which feature queries based on Relay-ID, by link
address and by Remote-ID. address and by Remote-ID.
7.5. Receiving Binding Updates 7.5. Receiving Binding Updates
7.5.1. Monitoring Time Skew 7.5.1. Monitoring Time Skew
The sent-time from the Failover message is compared with the current The sent-time from the Failover message is compared with the current
time of the receiving server as recorded when it received the time of the receiving server as recorded when it received the
message. The difference is noted, and if it is greater than 5 message. The difference is noted, and if it is greater than 5
seconds the receiving server SHOULD drop the connection. seconds the receiving server SHOULD drop the connection. A message
SHOULD be logged to signal the reason for the connection being
dropped.
Any time can be before, after, or essentially the same as another Any time can be before, after, or essentially the same as another
time. Any time which ends up being +/- 5 seconds of another time time. Any time 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
skipping to change at page 52, line 25 skipping to change at page 52, line 41
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".
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 to accept or reject the information.
known or that just received - is "better". If the information in the Section 7.5.4 provides the details how the server makes this
BNDUPD is "better", the receiving server will accept the information determination.
in the BNDUPD. If the information in the server's binding database
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 BNDREPLY message which contains the same that message with a BNDREPLY message which contains the same
transaction-id as the BNDUPD message. This BNDREPLY message MUST transaction-id as the BNDUPD message. This BNDREPLY message MUST
contain either a single OPTION_CLIENT_DATA option or a single contain either a single OPTION_CLIENT_DATA option or a single
OPTION_IAPREFIX option, corresponding to whatever was received in the OPTION_IAPREFIX option, corresponding to whatever was received in the
BNDUPD message. BNDUPD message.
An OPTION_CLIENT_DATA option or an OPTION_IAPREFIX option in the An OPTION_CLIENT_DATA option or an OPTION_IAPREFIX option in the
BNDREPLY which is accepted SHOULD NOT contain an OPTION_STATUS_CODE BNDREPLY which is accepted SHOULD NOT contain an OPTION_STATUS_CODE
skipping to change at page 74, line 47 skipping to change at page 74, line 47
renewal of a DHCP client's current lease regardless of whether that renewal of a DHCP client's current lease regardless of whether that
lease was given out by the receiving server or not, although the lease was given out by the receiving server or not, although the
renewal period MUST NOT exceed the MCLT beyond the latest of: 1) the renewal period MUST NOT exceed the MCLT beyond the latest of: 1) the
partner lifetime already acknowledged by the other server, or 2) now, partner lifetime already acknowledged by the other server, or 2) now,
or 3) the partner lifetime received from the partner server. or 3) the partner lifetime received from the partner server.
However, since the server cannot communicate with its partner in this However, since the server cannot communicate with its partner in this
state, the acknowledged partner lifetime will not be updated despite state, the acknowledged partner lifetime will not be updated despite
continued RENEW message processing. This is likely to eventually continued RENEW message processing. This is likely to eventually
cause the actual lifetimes to converge to the MCLT (unless this is cause the actual lifetimes to converge to the MCLT (unless this is
greater than the desired-client-lease-time, which would be unusual). greater than the desired lease time, which would be unusual).
The server should continue to try to establish a connection with its The server should continue to try to establish a connection with its
partner. partner.
8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State 8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State
If the auto-partner-down timer expires while a server is in the If the auto-partner-down timer expires while a server is in the
COMMUNICATIONS-INTERRUPTED state, it will transition immediately into COMMUNICATIONS-INTERRUPTED state, it will transition immediately into
PARTNER-DOWN state. PARTNER-DOWN state.
skipping to change at page 88, line 21 skipping to change at page 88, line 21
ConfigurationConflict (TBD35) ConfigurationConflict (TBD35)
MissingBindingInformation (TBD36) MissingBindingInformation (TBD36)
OutdatedBindingInformation (TBD37) OutdatedBindingInformation (TBD37)
ServerShuttingDown (TBD38) ServerShuttingDown (TBD38)
DNSUpdateNotSupported (TBD39) DNSUpdateNotSupported (TBD39)
ExcessiveTimeSkew (TBD40)
12. Acknowledgements 12. Acknowledgements
This document extensively uses concepts, definitions and other parts This document extensively uses concepts, definitions and other parts
of an effort to document failover for DHCPv4. Authors would like to of an effort to document failover for DHCPv4. Authors would like to
thank Shawn Routher, Greg Rabil, Bernie Volz and Marcin Siodelski for thank Shawn Routher, Greg Rabil, Bernie Volz and Marcin Siodelski for
their significant involvement and contributions. In particular, their significant involvement and contributions. In particular,
Bernie Volz and Shawn Routher provided detailed and substantive Bernie Volz and Shawn Routher provided detailed and substantive
technical reviews of the draft. Authors would like to thank technical reviews of the draft. Authors would like to thank
VithalPrasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki and VithalPrasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki and
Michal Hoeft for their insightful comments. Michal Hoeft for their insightful comments.
 End of changes. 25 change blocks. 
50 lines changed or deleted 68 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/