rfc8156-kek.txt   rfc8156.txt 
Internet Engineering Task Force (IETF) T. Mrugalski Internet Engineering Task Force (IETF) T. Mrugalski
Request for Comments: 8156 ISC Request for Comments: 8156 ISC
Category: Standards Track K. Kinnear Category: Standards Track K. Kinnear
ISSN: 2070-1721 Cisco ISSN: 2070-1721 Cisco
April 2017 May 2017
DHCPv6 Failover Protocol DHCPv6 Failover Protocol
Abstract Abstract
DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" (RFC 3315) does not offer server redundancy. This document (DHCPv6)" (RFC 3315) does not offer server redundancy. This document
defines a protocol implementation to provide DHCPv6 failover, a defines a protocol implementation to provide DHCPv6 failover, a
mechanism for running two servers with the capability for either mechanism for running two servers with the capability for either
server to take over clients' leases in case of server failure or server to take over clients' leases in case of server failure or
skipping to change at page 2, line 14 skipping to change at page 2, line 14
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 . . . . . . . . . . . . . . 9 4. Failover Concepts and Mechanisms . . . . . . . . . . . . . . 9
4.1. Required Server Configuration . . . . . . . . . . . . . . 9 4.1. Required Server Configuration . . . . . . . . . . . . . . 9
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.1.1. Independent Allocation Algorithm . . . . . . . . 10
4.2.2. Proportional Allocation . . . . . . . . . . . . . . . 10 4.2.2. Proportional Allocation . . . . . . . . . . . . . . . 10
4.2.2.1. Reallocating Leases . . . . . . . . . . . . . . . 12
4.3. Lazy Updates . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Lazy Updates . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Maximum Client Lead Time (MCLT) . . . . . . . . . . . . . 13 4.4. Maximum Client Lead Time (MCLT) . . . . . . . . . . . . . 14
4.4.1. MCLT Example . . . . . . . . . . . . . . . . . . . . 15 4.4.1. MCLT Example . . . . . . . . . . . . . . . . . . . . 15
5. Message and Option Definitions . . . . . . . . . . . . . . . 18 5. Message and Option Definitions . . . . . . . . . . . . . . . 18
5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 18 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 18
5.2. Failover Message Format . . . . . . . . . . . . . . . . . 18 5.2. Failover Message Format . . . . . . . . . . . . . . . . . 18
5.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.1. BNDUPD . . . . . . . . . . . . . . . . . . . . . . . 19 5.3.1. BNDUPD . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.2. BNDREPLY . . . . . . . . . . . . . . . . . . . . . . 20 5.3.2. BNDREPLY . . . . . . . . . . . . . . . . . . . . . . 20
5.3.3. POOLREQ . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.3. POOLREQ . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.4. POOLRESP . . . . . . . . . . . . . . . . . . . . . . 20 5.3.4. POOLRESP . . . . . . . . . . . . . . . . . . . . . . 20
5.3.5. UPDREQ . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.5. UPDREQ . . . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 2, line 39 skipping to change at page 2, line 41
5.3.8. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.8. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 21
5.3.9. CONNECTREPLY . . . . . . . . . . . . . . . . . . . . 21 5.3.9. CONNECTREPLY . . . . . . . . . . . . . . . . . . . . 21
5.3.10. DISCONNECT . . . . . . . . . . . . . . . . . . . . . 21 5.3.10. DISCONNECT . . . . . . . . . . . . . . . . . . . . . 21
5.3.11. STATE . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.11. STATE . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3.12. CONTACT . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.12. CONTACT . . . . . . . . . . . . . . . . . . . . . . . 21
5.4. Transaction-id . . . . . . . . . . . . . . . . . . . . . 22 5.4. Transaction-id . . . . . . . . . . . . . . . . . . . . . 22
5.5. Options . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.5. Options . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5.1. OPTION_F_BINDING_STATUS . . . . . . . . . . . . . . . 22 5.5.1. OPTION_F_BINDING_STATUS . . . . . . . . . . . . . . . 22
5.5.2. OPTION_F_CONNECT_FLAGS . . . . . . . . . . . . . . . 23 5.5.2. OPTION_F_CONNECT_FLAGS . . . . . . . . . . . . . . . 23
5.5.3. OPTION_F_DNS_REMOVAL_INFO . . . . . . . . . . . . . . 24 5.5.3. OPTION_F_DNS_REMOVAL_INFO . . . . . . . . . . . . . . 24
5.5.3.1. OPTION_F_DNS_HOST_NAME . . . . . . . . . . . . . 25
5.5.3.2. OPTION_F_DNS_ZONE_NAME . . . . . . . . . . . . . 25
5.5.3.3. OPTION_F_DNS_FLAGS . . . . . . . . . . . . . . . 26
5.5.4. OPTION_F_EXPIRATION_TIME . . . . . . . . . . . . . . 27 5.5.4. OPTION_F_EXPIRATION_TIME . . . . . . . . . . . . . . 27
5.5.5. OPTION_F_MAX_UNACKED_BNDUPD . . . . . . . . . . . . . 28 5.5.5. OPTION_F_MAX_UNACKED_BNDUPD . . . . . . . . . . . . . 28
5.5.6. OPTION_F_MCLT . . . . . . . . . . . . . . . . . . . . 28 5.5.6. OPTION_F_MCLT . . . . . . . . . . . . . . . . . . . . 28
5.5.7. OPTION_F_PARTNER_LIFETIME . . . . . . . . . . . . . . 29 5.5.7. OPTION_F_PARTNER_LIFETIME . . . . . . . . . . . . . . 29
5.5.8. OPTION_F_PARTNER_LIFETIME_SENT . . . . . . . . . . . 29 5.5.8. OPTION_F_PARTNER_LIFETIME_SENT . . . . . . . . . . . 29
5.5.9. OPTION_F_PARTNER_DOWN_TIME . . . . . . . . . . . . . 30 5.5.9. OPTION_F_PARTNER_DOWN_TIME . . . . . . . . . . . . . 30
5.5.10. OPTION_F_PARTNER_RAW_CLT_TIME . . . . . . . . . . . . 30 5.5.10. OPTION_F_PARTNER_RAW_CLT_TIME . . . . . . . . . . . . 30
5.5.11. OPTION_F_PROTOCOL_VERSION . . . . . . . . . . . . . . 31 5.5.11. OPTION_F_PROTOCOL_VERSION . . . . . . . . . . . . . . 31
5.5.12. OPTION_F_KEEPALIVE_TIME . . . . . . . . . . . . . . . 32 5.5.12. OPTION_F_KEEPALIVE_TIME . . . . . . . . . . . . . . . 32
5.5.13. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 32 5.5.13. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 32
skipping to change at page 16, line 8 skipping to change at page 16, line 21
the original acknowledged partner lifetime (1/2 hour + 3 days) and the original acknowledged partner lifetime (1/2 hour + 3 days) and
adjusts for the time passed since the secondary was last updated adjusts for the time passed since the secondary was last updated
(1/2 hour). Thus, the remaining time for the acknowledged partner (1/2 hour). Thus, the remaining time for the acknowledged partner
interval is 3 days. Adding the MCLT to this yields 3 days plus interval is 3 days. Adding the MCLT to this yields 3 days plus
1 hour, which is more than the desired lifetime of 3 days. So, the 1 hour, which is more than the desired lifetime of 3 days. So, the
client may have its lease renewed for the desired lifetime -- 3 days. client may have its lease renewed for the desired lifetime -- 3 days.
When the primary DHCP server updates the secondary DHCP server after When the primary DHCP server updates the secondary DHCP server after
the DHCP client's renewal REPLY is complete, it will calculate the the DHCP client's renewal REPLY is complete, it will calculate the
partner lifetime as the T1 fraction of the actual client lifetime partner lifetime as the T1 fraction of the actual client lifetime
(1/2 of 3 days this time = 1.5 days). To this it will add the (1/2 of 3 days = 1.5 days). To this it will add the desired lifetime
desired lifetime of 3 days, yielding a total partner lifetime of of 3 days, yielding a total partner lifetime of 4.5 days. In this
4.5 days. In this way, the primary attempts to have the secondary way, the primary attempts to have the secondary always "lead" the
always "lead" the client in its understanding of the client's client in its understanding of the client's lifetime so as to be able
lifetime so as to be able to always offer the client the desired to always offer the client the desired lifetime.
lifetime.
Once the initial actual client lifetime of the MCLT has passed, the Once the initial actual client lifetime of the MCLT has passed, the
failover protocol operates effectively like DHCP does today in its failover protocol operates effectively like DHCP does today in its
behavior concerning lifetimes. However, the guarantee that the behavior concerning lifetimes. However, the guarantee that the
actual client lifetime will never exceed the partner server's actual client lifetime will never exceed the partner server's
remaining acknowledged partner lifetime by more than the MCLT allows remaining acknowledged partner lifetime by more than the MCLT allows
full recovery from a variety of DHCP server failures. full recovery from a variety of DHCP server failures.
Fundamental relationship: Fundamental relationship:
lease time = floor( desired lifetime, acked-partner-lifetime + MCLT ) lease time = floor( desired lifetime, acked-partner-lifetime + MCLT )
skipping to change at page 58, line 28 skipping to change at page 58, line 28
1. The OPTION_CLIENTID is used to find the client. 1. The OPTION_CLIENTID is used to find the client.
2. The other data contained in the top level of the 2. The other data contained in the top level of the
OPTION_CLIENT_DATA option is stored with the client as OPTION_CLIENT_DATA option is stored with the client as
appropriate. appropriate.
3. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD 3. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
options in the OPTION_CLIENT_DATA option and for each of the options in the OPTION_CLIENT_DATA option and for each of the
OPTION_IAADDR or OPTION_IAPREFIX options in the IA_* options: OPTION_IAADDR or OPTION_IAPREFIX options in the IA_* options:
1. OPTION_F_BINDING_STATUS is stored as the binding-status. a. OPTION_F_BINDING_STATUS is stored as the binding-status.
2. OPTION_F_PARTNER_LIFETIME is stored in the expiration-time. b. OPTION_F_PARTNER_LIFETIME is stored in the expiration-time.
3. OPTION_F_STATE_EXPIRATION_TIME is stored in the c. OPTION_F_STATE_EXPIRATION_TIME is stored in the
state-expiration-time. state-expiration-time.
4. OPTION_CLT_TIME [RFC5007] is stored in the d. OPTION_CLT_TIME [RFC5007] is stored in the
partner-raw-clt-time. partner-raw-clt-time.
5. OPTION_F_PARTNER_RAW_CLT_TIME replaces the e. OPTION_F_PARTNER_RAW_CLT_TIME replaces the
client-last-transaction-time if it is later than the current client-last-transaction-time if it is later than the current
client-last-transaction-time. client-last-transaction-time.
6. OPTION_F_EXPIRATION_TIME replaces the partner-lifetime if it f. OPTION_F_EXPIRATION_TIME replaces the partner-lifetime if it
is later than the current partner-lifetime. is later than the current partner-lifetime.
The information contained in an accepted single OPTION_IAPREFIX The information contained in an accepted single OPTION_IAPREFIX
option that is not contained in an OPTION_CLIENT_DATA option is option that is not contained in an 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 IPv6 prefix is used to find the prefix. 1. The IPv6 prefix is used to find the prefix.
2. Inside of the IAprefix-options section: 2. Inside of the IAprefix-options section:
1. OPTION_F_BINDING_STATUS is stored as the binding-status. a. OPTION_F_BINDING_STATUS is stored as the binding-status.
2. OPTION_F_PARTNER_LIFETIME (if any) is stored in the b. OPTION_F_PARTNER_LIFETIME (if any) is stored in the
expiration-time. expiration-time.
3. OPTION_F_STATE_EXPIRATION_TIME (if any) is stored in the c. OPTION_F_STATE_EXPIRATION_TIME (if any) is stored in the
state-expiration-time. state-expiration-time.
4. OPTION_F_EXPIRATION_TIME (if any) replaces the d. OPTION_F_EXPIRATION_TIME (if any) replaces the
partner-lifetime if it is later than the current partner-lifetime if it is later than the current
partner-lifetime. partner-lifetime.
7.6. Sending Binding Replies 7.6. Sending Binding Replies
A server MUST respond to every BNDUPD message with a BNDREPLY A server MUST respond to every BNDUPD message with a BNDREPLY
message. The BNDREPLY message MUST contain an OPTION_CLIENT_DATA message. The BNDREPLY message MUST contain an OPTION_CLIENT_DATA
option if the BNDUPD message contained an OPTION_CLIENT_DATA option, option if the BNDUPD message contained an OPTION_CLIENT_DATA option,
or it MUST contain an OPTION_IAPREFIX option if the BNDUPD message or it MUST contain an OPTION_IAPREFIX option if the BNDUPD message
contained an OPTION_IAPREFIX option. The BNDREPLY message MUST have contained an OPTION_IAPREFIX option. The BNDREPLY message MUST have
skipping to change at page 62, line 15 skipping to change at page 62, line 15
The information contained in the BNDREPLY message in an The information contained in the BNDREPLY message in an
OPTION_CLIENT_DATA that represents an acceptance is stored with the OPTION_CLIENT_DATA that represents an acceptance is stored with the
appropriate client and lease, as follows: appropriate client and lease, as follows:
1. The OPTION_CLIENTID is used to find the client. 1. The OPTION_CLIENTID is used to find the client.
2. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD 2. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD
options in the OPTION_CLIENT_DATA option and for each of the options in the OPTION_CLIENT_DATA option and for each of the
OPTION_IAADDR or OPTION_IAPREFIX options they contain: OPTION_IAADDR or OPTION_IAPREFIX options they contain:
1. OPTION_F_PARTNER_LIFETIME_SENT is stored in the a. OPTION_F_PARTNER_LIFETIME_SENT is stored in the
acked-partner-lifetime. acked-partner-lifetime.
2. The partner-lifetime is set to 0 to indicate that no more b. The partner-lifetime is set to 0 to indicate that no more
information needs to be sent to the partner. information needs to be sent to the partner.
Alternatively, the BNDREPLY message may contain a single Alternatively, the BNDREPLY message may contain a single
OPTION_IAPREFIX option not contained in an OPTION_CLIENT_DATA option, OPTION_IAPREFIX option not contained in an OPTION_CLIENT_DATA option,
representing information concerning a single prefix lease. If the representing information concerning a single prefix lease. If the
IAprefix-options section of the OPTION_IAPREFIX option contains an IAprefix-options section of the OPTION_IAPREFIX option contains an
OPTION_STATUS_CODE representing an error, then it is considered a OPTION_STATUS_CODE representing an error, then it is considered a
rejection of the corresponding BNDUPD message. If the 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
 End of changes. 18 change blocks. 
20 lines changed or deleted 24 lines changed or added

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