draft-ietf-dhc-dhcpv6-failover-protocol-04.txt   draft-ietf-dhc-dhcpv6-failover-protocol-05.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: July 24, 2017 Cisco Expires: August 6, 2017 Cisco
January 20, 2017 February 2, 2017
DHCPv6 Failover Protocol DHCPv6 Failover Protocol
draft-ietf-dhc-dhcpv6-failover-protocol-04 draft-ietf-dhc-dhcpv6-failover-protocol-05
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 with the capability for either mechanism for running two servers with the capability for either
server to take over clients' leases in case of server failure or server to take over clients' leases in case of server failure or
network partition. It meets the requirements for DHCPv6 failover network partition. It meets the requirements for DHCPv6 failover
detailed in "DHCPv6 Failover Requirements" (RFC7031). detailed in "DHCPv6 Failover Requirements" (RFC7031).
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 July 24, 2017. This Internet-Draft will expire on August 6, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 9
4.1. Required Server Configuration . . . . . . . . . . . . . . 8 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.2. Proportional Allocation . . . . . . . . . . . . . . . 10 4.2.2. Proportional Allocation . . . . . . . . . . . . . . . 10
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) . . . . . . . . . . . . . 13
4.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . 14 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
5.3.6. UPDREQALL . . . . . . . . . . . . . . . . . . . . . . 20 5.3.6. UPDREQALL . . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 3, line 16 skipping to change at page 3, line 16
5.5.16. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 32 5.5.16. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 32
5.5.17. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 33 5.5.17. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 33
5.5.18. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 34 5.5.18. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 34
5.5.19. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 35 5.5.19. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 35
5.5.20. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 36 5.5.20. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 36
5.5.21. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 37 5.5.21. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 37
5.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 38 5.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 38
6. Connection Management . . . . . . . . . . . . . . . . . . . . 39 6. Connection Management . . . . . . . . . . . . . . . . . . . . 39
6.1. Creating Connections . . . . . . . . . . . . . . . . . . 39 6.1. Creating Connections . . . . . . . . . . . . . . . . . . 39
6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 40 6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 40
6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 40 6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 41
6.1.3. Receiving a CONNECTREPLY message . . . . . . . . . . 42 6.1.3. Receiving a CONNECTREPLY message . . . . . . . . . . 42
6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 42 6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 43
6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 43 6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 44
6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 44 6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 44
6.5. Connection Maintenance Parameters . . . . . . . . . . . . 44 6.5. Connection Maintenance Parameters . . . . . . . . . . . . 45
6.6. Unreachability detection . . . . . . . . . . . . . . . . 45 6.6. Unreachability detection . . . . . . . . . . . . . . . . 45
7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 46 7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 46
7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 46 7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 46
7.2. Information model . . . . . . . . . . . . . . . . . . . . 46 7.2. Information model . . . . . . . . . . . . . . . . . . . . 46
7.3. Times Required for Exchanging Binding Updates . . . . . . 50 7.3. Times Required for Exchanging Binding Updates . . . . . . 50
7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 51 7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 51
7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 54 7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 54
7.5.1. Monitoring Time Skew . . . . . . . . . . . . . . . . 54 7.5.1. Monitoring Time Skew . . . . . . . . . . . . . . . . 54
7.5.2. Acknowledging Reception . . . . . . . . . . . . . . . 54 7.5.2. Acknowledging Reception . . . . . . . . . . . . . . . 55
7.5.3. Processing Binding Updates . . . . . . . . . . . . . 54 7.5.3. Processing Binding Updates . . . . . . . . . . . . . 55
7.5.4. Accept or Reject? . . . . . . . . . . . . . . . . . . 55 7.5.4. Accept or Reject? . . . . . . . . . . . . . . . . . . 55
7.5.5. Accepting Updates . . . . . . . . . . . . . . . . . . 57 7.5.5. Accepting Updates . . . . . . . . . . . . . . . . . . 58
7.6. Sending Binding Replies . . . . . . . . . . . . . . . . . 58 7.6. Sending Binding Replies . . . . . . . . . . . . . . . . . 59
7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 60 7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 61
7.8. BNDUPD/BNDREPLY Data Flow . . . . . . . . . . . . . . . . 61 7.8. BNDUPD/BNDREPLY Data Flow . . . . . . . . . . . . . . . . 62
8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 62 8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 63
8.1. State Machine Operation . . . . . . . . . . . . . . . . . 62 8.1. State Machine Operation . . . . . . . . . . . . . . . . . 63
8.2. State Machine Initialization . . . . . . . . . . . . . . 66 8.2. State Machine Initialization . . . . . . . . . . . . . . 67
8.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 66 8.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 67
8.3.1. Operation in STARTUP State . . . . . . . . . . . . . 67 8.3.1. Operation in STARTUP State . . . . . . . . . . . . . 68
8.3.2. Transition Out of STARTUP State . . . . . . . . . . . 67 8.3.2. Transition Out of STARTUP State . . . . . . . . . . . 68
8.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 69 8.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 70
8.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 69 8.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 70
8.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 70 8.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 71
8.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 70 8.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 71
8.5.1. Operation in RECOVER State . . . . . . . . . . . . . 71 8.5.1. Operation in RECOVER State . . . . . . . . . . . . . 72
8.5.2. Transition Out of RECOVER State . . . . . . . . . . . 71 8.5.2. Transition Out of RECOVER State . . . . . . . . . . . 72
8.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 72 8.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 73
8.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 73 8.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 74
8.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 73 8.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 74
8.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 73 8.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 74
8.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 73 8.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 74
8.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 74 8.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 75
8.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 74 8.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 75
8.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 74 8.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 75
8.8.2. Transition Out of NORMAL State . . . . . . . . . . . 75 8.8.2. Transition Out of NORMAL State . . . . . . . . . . . 76
8.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 76 8.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 77
8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 76 8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 77
8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 77 8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 78
8.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 78 8.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 79
8.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 79 8.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 80
8.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 79 8.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 80
8.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 80 8.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 81
8.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 81 8.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 82
8.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 81 8.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 82
8.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 81 8.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 82
8.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 82 8.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 83
8.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 82 8.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 83
9. DNS Update Considerations . . . . . . . . . . . . . . . . . . 82 9. DNS Update Considerations . . . . . . . . . . . . . . . . . . 83
9.1. Relationship between failover and DNS update . . . . . . 83 9.1. Relationship between failover and DNS update . . . . . . 84
9.2. Exchanging DNS Update Information . . . . . . . . . . . . 84 9.2. Exchanging DNS Update Information . . . . . . . . . . . . 85
9.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . . 86 9.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . . 87
9.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . . 86 9.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . . 87
9.5. Name Assignment with No Update of DNS . . . . . . . . . . 87 9.5. Name Assignment with No Update of DNS . . . . . . . . . . 88
10. Security Considerations . . . . . . . . . . . . . . . . . . . 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 88
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 92
13.1. Normative References . . . . . . . . . . . . . . . . . . 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 92
13.2. Informative References . . . . . . . . . . . . . . . . . 92 13.2. Informative References . . . . . . . . . . . . . . . . . 93
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 93
1. Introduction 1. Introduction
This document defines a DHCPv6 failover protocol, which is a
mechanism for running two DHCPv6 servers [RFC3315] with the
capability for either server to take over clients' leases in case of
server failover or network partition. For a general overview of
DHCPv6 failover problems, use cases, benefits, and shortcomings, see
[RFC7031].
The failover protocol provides a means for cooperating DHCP servers The failover protocol provides a means for cooperating DHCP servers
to work together to provide a DHCP service with availability that is to work together to provide a service to DHCP clients with
increased beyond that which could be provided by a single DHCP server availability that is increased beyond that which could be provided by
operating alone. It is designed to protect DHCP clients against a single DHCP server operating alone. It is designed to protect DHCP
server unreachability, including server failure and network clients against server unreachability, including server failure and
partition. It is possible to deploy exactly two servers that are network partition. It is possible to deploy exactly two servers that
able to continue providing a lease for an IPv6 address [RFC3315] or are able to continue providing a lease for an IPv6 address [RFC3315]
on an IPv6 prefix [RFC3633] without the DHCP client experiencing or on an IPv6 prefix [RFC3633] without the DHCP client experiencing
lease expiration or a reassignment of a lease to a different IPv6 lease expiration or a reassignment of a lease to a different IPv6
address or prefix in the event of failure by one or the other of the address or prefix in the event of failure by one or the other of the
two servers. two servers.
This protocol defines an active-passive mode, sometimes also called a The failover protocol defines an active-passive mode, sometimes also
hot standby model. This means that during normal operation one called a hot standby model. This means that during normal operation
server is active (i.e. actively responds to clients' requests) while one server is active (i.e. actively responds to clients' requests)
the second is passive (i.e. it receives clients' requests, but while 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 new leases shorter than 30 Failover protocol MUST NOT be used for new leases shorter than 30
seconds. Leases reaching the end of their liftetime are not affected seconds. Leases reaching the end of their liftetime are not affected
by this restriction. by this restriction.
This protocol fulfills all DHCPv6 failover requirements defined in The failover protocol fulfills all DHCPv6 failover requirements
[RFC7031]. defined in [RFC7031].
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "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].
3. Glossary 3. Glossary
This is a supplemental glossary that should be combined with This is a supplemental glossary that should be combined with
skipping to change at page 7, line 14 skipping to change at page 7, line 21
o Lease o Lease
An association of a DHCP client with an IPv6 address or delegated An association of a DHCP client with an IPv6 address or delegated
prefix. This might refer to either an existing association or a prefix. This might refer to either an existing association or a
potential association. potential association.
o MCLT o MCLT
Maximum Client Lead Time. The fundamental relationship on which Maximum Client Lead Time. The fundamental relationship on which
much of the correctness of this protocol depends is that the lease much of the correctness of the failover protocol depends is that
expiration time known to a DHCP client MUST NOT be greater by more the lease expiration time known to a DHCP client MUST NOT be
than the MCLT beyond the later of the partner lifetime time greater by more than the MCLT beyond the later of the partner
acknowledged by that server's failover partner or the current time lifetime time acknowledged by that server's failover partner or
(i.e., now). See Section 4.4. the current time (i.e., now). See Section 4.4.
o Partner o Partner
The other DHCP server that participates in a failover The other DHCP server that participates in a failover
relationship. When the role (primary or secondary) is not relationship. When the role (primary or secondary) is not
important, the other server is referred to as a "failover partner" important, the other server is referred to as a "failover partner"
or sometimes simply "partner". or sometimes simply "partner".
o Prefix Lease o Prefix Lease
skipping to change at page 8, line 41 skipping to change at page 9, line 4
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.5.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
requests. requests.
4. Failover Concepts and Mechanisms 4. Failover Concepts and Mechanisms
The following concepts and mechanisms are necessary to the operation
of the failover protocol, and they are not currently employed by the
DHCPv6 protocol [RFC3315]. The failover protocol provides support
for all of these concepts and mechanisms.
4.1. Required Server Configuration 4.1. Required Server Configuration
Servers frequently have several kinds of leases available on a Servers frequently have several kinds of leases available on a
particular network segment. The failover protocol assumes that both particular network segment. The failover protocol assumes that both
primary and secondary servers are configured identically with regard primary and secondary servers are configured identically with regard
to the prefixes and links involved in DHCP. For delegated prefixes to the prefixes and links involved in DHCP. For delegated prefixes
(involved in proportional allocation) the primary server is (involved in proportional allocation) the primary server is
responsible for allocating to the secondary server the correct responsible for allocating to the secondary server the correct
proportion of the available delegated prefixes. IPv6 addresses proportion of the available delegated prefixes. IPv6 addresses
(involved in independent allocation) are allocated to the primary and (involved in independent allocation) are allocated to the primary and
skipping to change at page 14, line 5 skipping to change at page 14, line 15
client. During a lazy update the updating server updates its client. During a lazy update the updating server updates its
failover partner with a partner lifetime which is longer than the failover partner with a partner lifetime which is longer than the
valid lifetime previously given to the DHCP client and which is valid lifetime previously given to the DHCP client and which is
longer than the valid lifetime that the server has been configured to longer than the valid lifetime that the server has been configured to
give a client. This allows the server to give the configured valid give a client. This allows the server to give the configured valid
lifetime to the client the next time the client renews its lease, lifetime to the client the next time the client renews its lease,
since the time that it will give to the client will not be longer since the time that it will give to the client will not be longer
than the MCLT beyond the partner lifetime acknowledged by its partner than the MCLT beyond the partner lifetime acknowledged by its partner
or the current time. or the current time.
The fundamental relationship on which this protocol depends is: the The fundamental relationship on which the failover protocol depends
lease expiration time known to a DHCP client MUST NOT be greater by is: the lease expiration time known to a DHCP client MUST NOT be
more than the MCLT beyond the later of the partner lifetime greater by more than the MCLT beyond the later of the partner
acknowledged by that server's failover partner and the current time. lifetime acknowledged by that server's failover partner and the
current time.
The remainder of this section makes the above fundamental The remainder of this section makes the above fundamental
relationship more explicit. relationship more explicit.
This protocol requires a DHCP server to deal with several different The failover protocol requires a DHCP server to deal with several
lease intervals and places specific restrictions on their different lease intervals and places specific restrictions on their
relationships. The purpose of these restrictions is to allow the relationships. The purpose of these restrictions is to allow the
partner to be able to make certain assumptions in the absence of an partner to be able to make certain assumptions in the absence of an
ability to communicate between servers. ability to communicate between servers.
In the following explanation, all of the lifetimes are "valid" In the following explanation, all of the lifetimes are "valid"
lifetimes, in the context of [RFC3315]. lifetimes, in the context of [RFC3315].
The different times are: The different times are:
desired lifetime: desired lifetime:
The desired lifetime is the lease interval that a DHCP server The desired lifetime is the lease interval that a DHCP server
would like to give to a DHCP client in the absence of any would like to give to a DHCP client in the absence of any
restrictions imposed by the failover protocol. Its determination restrictions imposed by the failover protocol. Its determination
is outside of the scope of this protocol. Typically this is the is outside of the scope of the failover protocol. Typically this
result of external configuration of a DHCP server. is the result of external configuration of a DHCP server.
actual lifetime: actual lifetime:
The actual lifetime is the lease interval that a DHCP server gives The actual lifetime is the lease interval that a DHCP server gives
out to a DHCP client. It may be shorter than the desired lifetime out to a DHCP client. It may be shorter than the desired lifetime
(as explained below). (as explained below).
partner lifetime: partner lifetime:
The partner lifetime is the lease expiration interval the local The partner lifetime is the lease expiration interval the local
server tells to its partner in a BNDUPD message. server tells to its partner in a BNDUPD message.
skipping to change at page 24, line 30 skipping to change at page 24, line 30
delegable prefix may have different sizes. delegable prefix may have different sizes.
If the FIXED_PD_LENGTH bit is not set, it indicates that prefixes of If the FIXED_PD_LENGTH bit is not set, it indicates that prefixes of
a range of sizes can be delegated from a given delegable prefix. a range of sizes can be delegated from a given delegable prefix.
Note that if the FIXED_PD_LENGTH bit is set, each delegable prefix Note that if the FIXED_PD_LENGTH bit is set, each delegable prefix
may have its own fixed size -- this flag does not imply that all may have its own fixed size -- this flag does not imply that all
prefixes delegated will be the same size, rather that all prefixes prefixes delegated will be the same size, 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 the failover protocol, but must be known to
failover partners. It might be specified in the configuration for both failover partners. It might be specified in the configuration
each delegable prefix or it might be fixed for the entire server. for each delegable prefix or it might be fixed for the entire server.
5.5.3. OPTION_F_DNS_REMOVAL_INFO 5.5.3. OPTION_F_DNS_REMOVAL_INFO
This option contains the information necessary to remove a DNS name This option contains the information necessary to remove a DNS name
that was entered by the failover partner. that was entered by the failover partner.
The code for this option is TBD15. The code for this option is 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
skipping to change at page 39, line 10 skipping to change at page 39, line 10
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) ExcessiveTimeSkew (TBD40)
Returned when a server detects that the time skew between its Returned when a server detects that the time skew between its
current time and its partner's current time is greater than 5 current time and its partner's current time is greater than 5
seconds. seconds.
6. Connection Management 6. Connection Management
Communication between failover partners takes place over a long-lived
TCP connection. This connection is always initiated by the primary
server, and if the long-lived connection is lost it is the
responsibility of the primary server to attempt to reconnect to the
secondary server. The detailed process used by the primary server
when initiating a connection and by the secondary server when
responding to a connection attempt documented in Section 6.1 is
followed each time a connection is established, regardless of any
previous connection between the failover partners.
6.1. Creating Connections 6.1. Creating Connections
Every primary server implementing the failover protocol MUST Every primary server implementing the failover protocol MUST
periodically attempt to create a TCP connection to the dhcp-failover periodically attempt to create a TCP connection to the dhcp-failover
port (647) of all of its configured partners, where the period is port (647) of all of its configured partners, where the period is
implementation dependent and SHOULD be configurable. In the event implementation dependent and SHOULD be configurable. In the event
that a connection has been rejected by a CONNECTREPLY message with a that a connection has been rejected by a CONNECTREPLY message with 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
skipping to change at page 40, line 16 skipping to change at page 40, line 26
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 that the
primary server will use when sending failover messages.
o OPTION_F_MCLT containing the configured MCLT. o OPTION_F_MCLT containing the configured MCLT.
o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an
interval) within which the server must receive a message from its interval) within which the server must receive a message from its
partner, or it will assume that communications from the partner is partner, or it will assume that communications from the partner 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
skipping to change at page 41, line 33 skipping to change at page 41, line 49
A CONNECT message SHOULD always be followed by a CONNECTREPLY A CONNECT message SHOULD always be followed by a CONNECTREPLY
message, either to accept the connection or to reject the connection message, either to accept the connection or to reject the connection
by 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 CONNECTREPLY 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 CONNECTREPLY message accepting the connection attempt, then send a CONNECTREPLY message
with 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 when sending failover messages.
o OPTION_F_MCLT containing the MCLT currently in use on the o OPTION_F_MCLT containing the MCLT currently in use on the
secondary server. This MUST equal the MCLT that was in the secondary server. This MUST equal the MCLT that was in the
OPTION_F_MCLT option in the CONNECT. OPTION_F_MCLT option in the CONNECT.
o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an
interval) within which the server must receive a message from its interval) within which the server must receive a message from its
partner, or it will assume that communications from the partner is partner, or it will assume that communications from the partner is
not ok. not ok.
skipping to change at page 42, line 18 skipping to change at page 42, line 35
6.1.3. Receiving a CONNECTREPLY message 6.1.3. Receiving a CONNECTREPLY message
A server receiving a CONNECTREPLY message must process the A server receiving a CONNECTREPLY message must process the
information in the message and decide whether or not to continue to information in the message and decide whether or not to continue to
employ the connection. The processing is performed as follows: employ the connection. The processing is performed as follows:
o OPTION_F_PROTOCOL_VERSION - The primary server decides if the o OPTION_F_PROTOCOL_VERSION - The primary server decides if the
protocol version in use by the secondary server is supported by protocol version in use by the secondary server is supported by
the primary server. If it is not, send a DISCONNECT message and the primary server. If it is not, send a DISCONNECT message and
drop the connection. If it is supported, continue processing. drop the connection. If it is supported, continue processing. It
is possible that the primary and secondary server will each be
sending different versions of the protocol to the other server.
The extent to which this is supported will be in part defined by
as yet unknown differences in the protocols that the versions
represent, and in part by the capabilities of the two
implementations involved in the failover relationship.
o OPTION_F_MCLT - Compare the MCLT received with the configured o OPTION_F_MCLT - Compare the MCLT received with the configured
MCLT, and if they are different send a DISCONNECT message and drop MCLT, and if they are different send a DISCONNECT message and drop
the connection. the connection.
o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the
FO_KEEPALIVE_TIME when implementing the Unreachability Detection FO_KEEPALIVE_TIME 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
skipping to change at page 79, line 5 skipping to change at page 80, line 5
8.10. POTENTIAL-CONFLICT State 8.10. POTENTIAL-CONFLICT State
This state indicates that the two servers are attempting to This state indicates that the two servers are attempting to
reintegrate with each other, but at least one of them was running in reintegrate with each other, but at least one of them was running in
a state that did not guarantee automatic reintegration would be a state that did not guarantee automatic reintegration would be
possible. In POTENTIAL-CONFLICT state the servers may determine that possible. In POTENTIAL-CONFLICT state the servers may determine that
the same lease has been offered and accepted by two different the same lease has been offered and accepted by two different
clients. clients.
It is a goal of this protocol to minimize the possibility that It is a goal of the failover protocol to minimize the possibility
POTENTIAL-CONFLICT state is ever entered. that POTENTIAL-CONFLICT state is ever entered.
When a primary server enters POTENTIAL-CONFLICT state it should When a primary server enters POTENTIAL-CONFLICT state it should
request that the secondary send it all updates which the primary request that the secondary send it all updates which the primary
server has not yet acknowledged by sending an UPDREQ message to the server has not yet acknowledged by sending an UPDREQ message to the
secondary server. secondary server.
A secondary server entering POTENTIAL-CONFLICT state will wait for A secondary server entering POTENTIAL-CONFLICT state will wait for
the primary to send it an UPDREQ message. the primary to send it an UPDREQ message.
8.10.1. Operation in POTENTIAL-CONFLICT State 8.10.1. Operation in POTENTIAL-CONFLICT State
skipping to change at page 81, line 4 skipping to change at page 82, line 4
8.11. RESOLUTION-INTERRUPTED State 8.11. RESOLUTION-INTERRUPTED State
This state indicates that the two servers were attempting to This state indicates that the two servers were attempting to
reintegrate with each other in POTENTIAL-CONFLICT state, but reintegrate with each other in POTENTIAL-CONFLICT state, but
communication failed prior to completion of re-integration. communication failed prior to completion of 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 server available to process
RESOLUTION-INTERRUPTED state is the state that a server moves to if client requests. The RESOLUTION-INTERRUPTED state is the state that
its partner disappears while it is in POTENTIAL-CONFLICT state. a server moves to if its partner disappears while it is in POTENTIAL-
CONFLICT state.
When a server enters RESOLUTION-INTERRUPTED state it SHOULD raise an When a server enters RESOLUTION-INTERRUPTED state it SHOULD raise an
alarm condition to alert administrative staff of a problem in the alarm condition to alert administrative staff of a problem in the
DHCP subsystem. DHCP subsystem.
8.11.1. Operation in RESOLUTION-INTERRUPTED State 8.11.1. Operation in RESOLUTION-INTERRUPTED State
In this state a server MUST respond to all DHCP client requests. In this state a server MUST respond to all DHCP client requests.
When allocating new leases, each server SHOULD allocate from its own When allocating new leases, each server SHOULD allocate from its own
pool (if that can be determined), where the primary SHOULD allocate pool (if that can be determined), where the primary SHOULD allocate
skipping to change at page 88, line 9 skipping to change at page 89, line 9
Section 15 related to the server apply. Section 15 related to the server apply.
The use of TCP introduces some additional concerns. Attacks that The use of TCP introduces some additional concerns. Attacks that
attempt to exhaust the DHCP server's available TCP connection attempt to exhaust the DHCP server's available TCP connection
resources can compromise the ability of legitimate partners to resources can compromise the ability of legitimate partners to
receive service. Malicious requestors who succeed in establishing receive service. Malicious requestors who succeed in establishing
connections but who then send invalid messages, partial messages, or connections but who then send invalid messages, partial messages, or
no messages at all can also exhaust a server's pool of available no messages at all can also exhaust a server's pool of available
connections. connections.
DHCPv6 failover can operate in secure or insecure mode. Secure mode
(using TLS) would be indicated when the TCP connection between
failover partners is open to external monitoring or interception.
Insecure mode should only be used when the TCP connection between
failover partners remains within set of protected systems. Details
of such protections are beyond the scope of this document. Failover
servers MUST use the approach documented in Section 9.1 of [RFC7653]
to decide to use or not to use TLS when connecting with the failover
partner.
The threats created by using failover directly mirror those from
using DHCPv6 itself: information leakage through monitoring, and
disruption of address assignment and configuration. Monitoring the
failover TCP connection provides no additional data beyond that
available from monitoring the interactions between DHCPv6 clients and
the DHCPv6 server. Likewise, manipulating the data flow between
failover servers provides no additional opportunities to disrupt
address assignment and configuration beyond that provided by acting
as a counterfeit DHCP server. Protection from both threats is easier
than with basic DHCPv6, as only a single TCP connection needs to be
protected. Either use secure mode to protect that TCP connection or
ensure that it can only exist with a set of protected systems.
When operating in secure mode, TLS [RFC5246] is used to secure the When operating in secure mode, TLS [RFC5246] is used to secure the
connection. The recommendations in [RFC7525] SHOULD be followed when connection. The recommendations in [RFC7525] SHOULD be followed when
negotiating a TLS connection. negotiating a TLS connection.
Servers SHOULD offer configuration parameters to limit the sources of Servers SHOULD offer configuration parameters to limit the sources of
incoming connections through validation and use of the digital incoming connections through validation and use of the digital
certificates presented to create a TLS connection. They SHOULD also certificates presented to create a TLS connection. They SHOULD also
limit the number of accepted connections and limit the period of time limit the number of accepted connections and limit the period of time
during which an idle connection will be left open. during which an idle connection will be left open.
Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to
attempt to secure transmission of the messages described in this attempt to secure transmission of the messages described in this
document. document. If authentication is desired, secure mode using TLS SHOULD
be employed as described in Sections 8.2 and 9.1 of [RFC7653].
11. IANA Considerations 11. IANA Considerations
IANA is requested to assign values for the following new DHCPv6 IANA 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 BNDREPLY (TBD2) o BNDREPLY (TBD2)
 End of changes. 30 change blocks. 
102 lines changed or deleted 156 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/