idnits 2.17.1 draft-ietf-dhc-dhcpv6-failover-protocol-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 992 has weird spacing: '... Value bind...' == Line 1943 has weird spacing: '...R timer count...' == Line 1953 has weird spacing: '... timer count...' == Line 2474 has weird spacing: '... accept acc...' == Line 2475 has weird spacing: '... accept acc...' == (3 more instances...) -- The document date (February 27, 2017) is 2614 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration (DHC) T. Mrugalski 3 Internet-Draft ISC 4 Intended status: Standards Track K. Kinnear 5 Expires: August 31, 2017 Cisco 6 February 27, 2017 8 DHCPv6 Failover Protocol 9 draft-ietf-dhc-dhcpv6-failover-protocol-06 11 Abstract 13 DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 14 (DHCPv6)" (RFC3315) does not offer server redundancy. This document 15 defines a protocol implementation to provide DHCPv6 failover, a 16 mechanism for running two servers with the capability for either 17 server to take over clients' leases in case of server failure or 18 network partition. It meets the requirements for DHCPv6 failover 19 detailed in "DHCPv6 Failover Requirements" (RFC7031). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 31, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 57 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Failover Concepts and Mechanisms . . . . . . . . . . . . . . 9 59 4.1. Required Server Configuration . . . . . . . . . . . . . . 9 60 4.2. IPv6 Address and Delegable Prefix Allocation . . . . . . 9 61 4.2.1. Independent Allocation . . . . . . . . . . . . . . . 9 62 4.2.2. Proportional Allocation . . . . . . . . . . . . . . . 10 63 4.3. Lazy Updates . . . . . . . . . . . . . . . . . . . . . . 13 64 4.4. Maximum Client Lead Time (MCLT) . . . . . . . . . . . . . 13 65 4.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . 15 66 5. Message and Option Definitions . . . . . . . . . . . . . . . 18 67 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 18 68 5.2. Failover Message Format . . . . . . . . . . . . . . . . . 18 69 5.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 19 70 5.3.1. BNDUPD . . . . . . . . . . . . . . . . . . . . . . . 19 71 5.3.2. BNDREPLY . . . . . . . . . . . . . . . . . . . . . . 20 72 5.3.3. POOLREQ . . . . . . . . . . . . . . . . . . . . . . . 20 73 5.3.4. POOLRESP . . . . . . . . . . . . . . . . . . . . . . 20 74 5.3.5. UPDREQ . . . . . . . . . . . . . . . . . . . . . . . 20 75 5.3.6. UPDREQALL . . . . . . . . . . . . . . . . . . . . . . 20 76 5.3.7. UPDDONE . . . . . . . . . . . . . . . . . . . . . . . 21 77 5.3.8. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 21 78 5.3.9. CONNECTREPLY . . . . . . . . . . . . . . . . . . . . 21 79 5.3.10. DISCONNECT . . . . . . . . . . . . . . . . . . . . . 21 80 5.3.11. STATE . . . . . . . . . . . . . . . . . . . . . . . . 21 81 5.3.12. CONTACT . . . . . . . . . . . . . . . . . . . . . . . 21 82 5.4. Transaction Id . . . . . . . . . . . . . . . . . . . . . 22 83 5.5. Options . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 5.5.1. OPTION_F_BINDING_STATUS . . . . . . . . . . . . . . . 22 85 5.5.2. OPTION_F_CONNECT_FLAGS . . . . . . . . . . . . . . . 23 86 5.5.3. OPTION_F_DNS_REMOVAL_INFO . . . . . . . . . . . . . . 24 87 5.5.4. OPTION_F_DNS_HOST_NAME . . . . . . . . . . . . . . . 25 88 5.5.5. OPTION_F_DNS_ZONE_NAME . . . . . . . . . . . . . . . 25 89 5.5.6. OPTION_F_DNS_FLAGS . . . . . . . . . . . . . . . . . 26 90 5.5.7. OPTION_F_EXPIRATION_TIME . . . . . . . . . . . . . . 27 91 5.5.8. OPTION_F_MAX_UNACKED_BNDUPD . . . . . . . . . . . . . 28 92 5.5.9. OPTION_F_MCLT . . . . . . . . . . . . . . . . . . . . 28 93 5.5.10. OPTION_F_PARTNER_LIFETIME . . . . . . . . . . . . . . 29 94 5.5.11. OPTION_F_PARTNER_LIFETIME_SENT . . . . . . . . . . . 29 95 5.5.12. OPTION_F_PARTNER_DOWN_TIME . . . . . . . . . . . . . 30 96 5.5.13. OPTION_F_PARTNER_RAW_CLT_TIME . . . . . . . . . . . . 31 97 5.5.14. OPTION_F_PROTOCOL_VERSION . . . . . . . . . . . . . . 31 98 5.5.15. OPTION_F_KEEPALIVE_TIME . . . . . . . . . . . . . . . 32 99 5.5.16. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 32 100 5.5.17. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 33 101 5.5.18. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 34 102 5.5.19. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 35 103 5.5.20. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 36 104 5.5.21. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 37 105 5.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 38 106 6. Connection Management . . . . . . . . . . . . . . . . . . . . 39 107 6.1. Creating Connections . . . . . . . . . . . . . . . . . . 39 108 6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 40 109 6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 41 110 6.1.3. Receiving a CONNECTREPLY message . . . . . . . . . . 42 111 6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 43 112 6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 44 113 6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 44 114 6.5. Connection Maintenance Parameters . . . . . . . . . . . . 45 115 6.6. Unreachability detection . . . . . . . . . . . . . . . . 45 116 7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 46 117 7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 46 118 7.2. Information model . . . . . . . . . . . . . . . . . . . . 46 119 7.3. Times Required for Exchanging Binding Updates . . . . . . 50 120 7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 51 121 7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 54 122 7.5.1. Monitoring Time Skew . . . . . . . . . . . . . . . . 54 123 7.5.2. Acknowledging Reception . . . . . . . . . . . . . . . 55 124 7.5.3. Processing Binding Updates . . . . . . . . . . . . . 55 125 7.5.4. Accept or Reject? . . . . . . . . . . . . . . . . . . 55 126 7.5.5. Accepting Updates . . . . . . . . . . . . . . . . . . 58 127 7.6. Sending Binding Replies . . . . . . . . . . . . . . . . . 59 128 7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 61 129 7.8. BNDUPD/BNDREPLY Data Flow . . . . . . . . . . . . . . . . 62 130 8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 63 131 8.1. State Machine Operation . . . . . . . . . . . . . . . . . 63 132 8.2. State Machine Initialization . . . . . . . . . . . . . . 67 133 8.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 67 134 8.3.1. Operation in STARTUP State . . . . . . . . . . . . . 68 135 8.3.2. Transition Out of STARTUP State . . . . . . . . . . . 68 136 8.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 70 137 8.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 70 138 8.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 71 139 8.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 71 140 8.5.1. Operation in RECOVER State . . . . . . . . . . . . . 72 141 8.5.2. Transition Out of RECOVER State . . . . . . . . . . . 72 142 8.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 73 143 8.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 74 144 8.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 74 146 8.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 74 147 8.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 74 148 8.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 75 149 8.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 75 150 8.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 75 151 8.8.2. Transition Out of NORMAL State . . . . . . . . . . . 76 152 8.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 77 153 8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 77 154 8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 78 155 8.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 79 156 8.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 80 157 8.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 80 158 8.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 81 159 8.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 82 160 8.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 82 161 8.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 82 162 8.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 83 163 8.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 83 164 9. DNS Update Considerations . . . . . . . . . . . . . . . . . . 83 165 9.1. Relationship between failover and DNS update . . . . . . 84 166 9.2. Exchanging DNS Update Information . . . . . . . . . . . . 85 167 9.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . . 87 168 9.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . . 87 169 9.5. Name Assignment with No Update of DNS . . . . . . . . . . 88 170 10. Security Considerations . . . . . . . . . . . . . . . . . . . 88 171 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 172 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91 173 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 174 13.1. Normative References . . . . . . . . . . . . . . . . . . 92 175 13.2. Informative References . . . . . . . . . . . . . . . . . 93 176 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 93 178 1. Introduction 180 This document defines a DHCPv6 failover protocol, which is a 181 mechanism for running two DHCPv6 servers [RFC3315] with the 182 capability for either server to take over clients' leases in case of 183 server failover or network partition. For a general overview of 184 DHCPv6 failover problems, use cases, benefits, and shortcomings, see 185 [RFC7031]. 187 The failover protocol provides a means for cooperating DHCP servers 188 to work together to provide a service to DHCP clients with 189 availability that is increased beyond that which could be provided by 190 a single DHCP server operating alone. It is designed to protect DHCP 191 clients against server unreachability, including server failure and 192 network partition. It is possible to deploy exactly two servers that 193 are able to continue providing a lease for an IPv6 address [RFC3315] 194 or on an IPv6 prefix [RFC3633] without the DHCP client experiencing 195 lease expiration or a reassignment of a lease to a different IPv6 196 address or prefix in the event of failure by one or the other of the 197 two servers. 199 The failover protocol defines an active-passive mode, sometimes also 200 called a hot standby model. This means that during normal operation 201 one server is active (i.e. actively responds to clients' requests) 202 while the second is passive (i.e. it receives clients' requests, but 203 responds only to those specifically directed to it). The secondary 204 maintains a copy of the binding database and is ready to take over 205 all incoming queries in case of primary server failure. 207 The failover protocol is designed to provide lease stability for 208 leases with valid lifetimes beyond a short period. The DHCPv6 209 Failover protocol MUST NOT be used for new leases shorter than 30 210 seconds. Leases reaching the end of their liftetime are not affected 211 by this restriction. 213 The failover protocol fulfills all DHCPv6 failover requirements 214 defined in [RFC7031]. 216 2. Requirements Language 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in RFC 2119 [RFC2119]. 222 3. Glossary 224 This is a supplemental glossary that should be combined with 225 definitions in Section 3 of RFC 7031 [RFC7031]. 227 o Absolute Time 229 The time in seconds since midnight January 1, 2000 UTC, modulo 230 2^32). 232 o Address Lease 234 A lease involving an IPv6 address. Typically used when it is 235 necessary to distinguish the lease for an IPv6 address from a 236 lease for a DHCP prefix. See "delegated prefix" and "prefix 237 lease". 239 o auto-partner-down 240 A capability where a failover server will move from 241 COMMUNICATIONS-INTERRUPTED state to PARTNER-DOWN state 242 automatically, without operator intervention. 244 o Available (Lease or Prefix) 246 A lease or delegable prefix is available if it could be allocated 247 for use by a DHCP client. It is available on the main server when 248 it is in FREE state and available on the secondary server when it 249 is in the FREE-BACKUP state. Sometimes the term "available" is 250 used when it would be awkward to say "FREE on the primary server 251 and FREE-BACKUP on the secondary server". 253 o Binding-Status 255 A lease can hold a variety of states (see Section 5.5.1 for a 256 list) and these are also referred to as the binding-status of the 257 lease. 259 o Delegable Prefix 261 A prefix from which other prefixes may be delegated, using the 262 mechanisms described in [RFC3633]. A prefix which has been 263 delegated is known as a "delegated prefix" or a "prefix lease". 265 o Delegated Prefix 267 A prefix which has been deletegated to a DHCP client as described 268 in [RFC3633]. Depending on the context, a delegated prefix may 269 also be described as a "prefix lease", when it is necessary to 270 distinguish it from an "address lease". 272 o Failover endpoint 274 The failover protocol allows for there to be a unique failover 275 'endpoint' for each failover relationship in which a failover 276 server participates. The failover relationship is defined by a 277 relationship name, and includes the failover partner IP address, 278 the role this server takes with respect to that partner (primary 279 or secondary), and the prefixes from which addresses can be leased 280 as well as prefixes from which other prefixes can be delegated 281 (delegable prefixes), associated with that relationship. The 282 failover endpoint can take actions and hold unique states. 283 Typically, there is one failover endpoint per partner (server), 284 although there may be more. 286 o Failover communication 287 All messages exchanged between partners. 289 o Independent Allocation 291 An allocation algorithm that splits the available pool of address 292 leases between the primary and secondary servers. It is used for 293 IPv6 address allocations. See Section 4.2.1. 295 o Lease 297 An association of a DHCP client with an IPv6 address or delegated 298 prefix. This might refer to either an existing association or a 299 potential association. 301 o MCLT 303 Maximum Client Lead Time. The fundamental relationship on which 304 much of the correctness of the failover protocol depends is that 305 the lease expiration time known to a DHCP client MUST NOT be 306 greater by more than the MCLT beyond the later of the partner 307 lifetime time acknowledged by that server's failover partner or 308 the current time (i.e., now). See Section 4.4. 310 o Partner 312 The other DHCP server that participates in a failover 313 relationship. When the role (primary or secondary) is not 314 important, the other server is referred to as a "failover partner" 315 or sometimes simply "partner". 317 o Prefix Lease 319 A lease involving a prefix that is or could be delegated, as 320 opposed to a lease for a single IPv6 address. A prefix lease can 321 also be described as a "delegated prefix". 323 o Primary Server 325 First out of two DHCP servers that participate in a failover 326 relationship. When both servers are operating this server handles 327 most of the client traffic. Its failover partner is referred to 328 as secondary server. 330 o Proportional Allocation 332 An allocation algorithm that splits the delegable prefixes between 333 the primary and secondary servers and maintains a more or less 334 fixed proportion of the delegable prefixes between both servers. 335 Section 4.2.2. 337 o Renew Responsive 339 A server that is renew responsive will respond to valid DHCP 340 client requests that are directed to it by having an 341 OPTION_SERVERID option in the message which contains the DUID of 342 the renew responsive server. See [RFC3315]. 344 o Responsive 346 A server that is responsive will respond to all valid DHCP client 347 requests. 349 o Secondary Server 351 Second of two DHCP servers that participate in a failover 352 relationship. Its failover partner is referred to as the primary 353 server. When both servers are operating this server (the 354 secondary) typically does not handle client traffic and acts as a 355 backup to the primary server. It will respond, however, to RENEW 356 requests directed specifically to it. 358 o Server 360 A DHCP server that implements DHCPv6 failover. 'Server' and 361 'failover endpoint' are synonymous only if the server participates 362 in only one failover relationship. 364 o State 366 The term state is used in two ways in this document. A failover 367 endpoint is always in some state, and there are a series of states 368 that a failover endpoint can move through. See Section 8 for 369 details of the failover endpoint states. A lease also has a 370 state, and this is sometimes referred to as a binding-status. See 371 Section 5.5.1 for a list of the states a lease can hold. 373 o Time Context 375 Each failover server has a clock and a definite idea of the 376 current universal time. Each server's idea of the current time is 377 considered its time context. 379 o Unresponsive 380 A server that is unresponsive will not respond to DHCP client 381 requests. 383 4. Failover Concepts and Mechanisms 385 The following concepts and mechanisms are necessary to the operation 386 of the failover protocol, and they are not currently employed by the 387 DHCPv6 protocol [RFC3315]. The failover protocol provides support 388 for all of these concepts and mechanisms. 390 4.1. Required Server Configuration 392 Servers frequently have several kinds of leases available on a 393 particular network segment. The failover protocol assumes that both 394 primary and secondary servers are configured identically with regard 395 to the prefixes and links involved in DHCP. For delegated prefixes 396 (involved in proportional allocation) the primary server is 397 responsible for allocating to the secondary server the correct 398 proportion of the available delegated prefixes. IPv6 addresses 399 (involved in independent allocation) are allocated to the primary and 400 secondary servers algorithmically, and do not require an explicit 401 message transfer to be distributed. 403 4.2. IPv6 Address and Delegable Prefix Allocation 405 Currently there are two allocation algorithms defined, one for 406 address leases and one for prefix leases. 408 4.2.1. Independent Allocation 410 In this allocation scheme, used for allocating individual IPv6 411 addresses, available IPv6 addresses are permanently (until server 412 configuration changes) split between servers. Available IPv6 413 addresses are split between the primary and secondary servers as part 414 of initial connection establishment. Once IPv6 addresses are 415 allocated to each server, there is no need to reassign them. The 416 IPv6 address allocation is algorithmic in nature, and does not 417 require a message exchange for each server to know which IPv6 418 addresses it has been allocated. This algorithm is simpler than 419 proportional allocation since it does not require a rebalancing 420 mechanism. It also assumes that the pool assigned to each server 421 will never deplete. 423 Once each server is assigned a pool of IPv6 addresses during initial 424 connection establishment, it may allocate its assigned IPv6 addresses 425 to clients. Once a client releases a lease or its lease on an IPv6 426 address expires, the returned IPv6 address returns to the pool for 427 the server that leased it. A lease on an IPv6 address can be renewed 428 by a responsive server or by a renew responsive server. When an IPv6 429 address goes PENDING-FREE (see Section 7.2) it is owned by whichever 430 server it is allocated to by the independent allocation algorithm. 432 IPv6 addresses (which use the independent allocation approach) are 433 ignored when a server processes a POOLREQ message. 435 During COMMUNICATION-INTERRUPTED events, a partner MAY continue 436 extending existing address leases as requested by clients. An 437 operational partner MUST NOT lease IPv6 addresses that were assigned 438 to its downed partner and later expired or were released or declined 439 by a client. When it is in PARTNER-DOWN state, a server MUST 440 allocate new leases from its own pool. It MUST NOT use its partner's 441 pool to allocate new leases. 443 4.2.1.1. Independent Allocation Algorithm 445 For each address that can be allocated, the primary server MUST 446 allocate only IPv6 addresses when the low-order bit (i.e., bit 127) 447 is equal to 1, and the secondary server MUST allocate only the IPv6 448 addresses when the low-order bit (i.e., bit 127) is equal to 0. 450 4.2.2. Proportional Allocation 452 In this allocation scheme, each server has its own pool of prefixes 453 available for delegation, known as "delegable prefixes". These 454 delegable prefixes may be prefixes from which other prefixes can be 455 delegated or they may be prefixes which are the correct size for 456 delegation but are not, at present, delegated to a particular client. 457 Remaining delegable prefixes are split between the primary and 458 secondary servers in a configured proportion. Note that a delegated 459 prefix (also known as a prefix lease) is not "owned" by a particular 460 server. Only a delegable prefix which is available is "owned" by a 461 particular server -- once it has been delegated (leased) to a client 462 it becomes a prefix lease and is not owned by either failover 463 partner. When it finally becomes available again, it will be owned 464 initially by the primary server, and it may or may not be allocated 465 to the secondary server by the primary server. 467 The flow of a delegable prefix is as follows: initially the delegable 468 prefix is part of a larger delegable prefix, all of which are 469 initially owned by the primary server. A delegable prefix may be 470 allocated to the secondary server and then it is owned by the 471 secondary server. Either server can allocate and delegate prefixes 472 out of the delegable prefixes which they own. Once these prefixes 473 are delegated (leased) to clients, the servers cease to own them and 474 they are owned by the clients to which they have been delegated 475 (leased). When the client releases the delegated prefix or the lease 476 on it expires, it will again become available and will then be a 477 delegable prefix and be owned by the primary. 479 A server delegates prefixes only from its own pool of delegable 480 prefixes in all states except for PARTNER-DOWN. In PARTNER-DOWN 481 state the operational partner can delegate prefixes from either pool 482 (both its own, and its partner's after some time constraints have 483 elapsed). The operational partner SHOULD allocate from its own pool 484 before using its partner's pool. The allocation and maintenance of 485 these pools of delegable prefixes is important, since the goal is to 486 maintain a more or less constant ratio of delegable prefixes between 487 the two servers. 489 Each server knows which delegable prefixes are in its own pool as 490 well as which are in its partner's pool, so that it can allocate 491 delegable prefixes from its partner's pool without communication with 492 its partner if that becomes necessary. 494 The initial allocation of delegable prefixes from the primary to the 495 secondary when the servers first integrate is triggered by the 496 POOLREQ message from the secondary to the primary. This is followed 497 (at some point) by the POOLRESP message where the primary tells the 498 secondary that it received and processed the POOLREQ message. The 499 primary sends the allocated delegable prefixes to the secondary as 500 prefix leases via BNDUPD messages. The POOLRESP message may be sent 501 before, during, or at the completion of the BNDUPD message exchanges 502 that were triggered by the POOLREQ message. The POOLREQ/POOLRESP 503 message exchange is a trigger to the primary to perform a scan of its 504 database and to ensure that the secondary has enough delegable 505 prefixes (based on some configured ratio). 507 The delegable prefixes are sent to the secondary as prefix leases 508 using the BNDUPD message containing an OPTION_IAPREFIX with a state 509 of FREE-BACKUP, which indicates the prefix lease is now available for 510 allocation by the secondary. Once the message is sent, the primary 511 MUST NOT use these prefixes for allocation to DHCP clients (except 512 when the server is in PARTNER-DOWN state). 514 The POOLREQ/POOLRESP message exchange initiated by the secondary is 515 valid at any time both partners remain in contact, and the primary 516 server SHOULD, whenever it receives the POOLREQ message, scan its 517 database of delegable prefixes and determine if the secondary needs 518 more delegable prefixes from any of the delegable prefixes which it 519 currently owns. 521 In order to support a reasonably dynamic balance of the leases 522 between the failover partners, the primary server needs to do 523 additional work to ensure that the secondary server has as many 524 delegable prefixes as it needs (but that it doesn't have more than it 525 needs). 527 The primary server SHOULD examine the balance of delegable prefixes 528 between the primary and secondary for a particular prefix whenever 529 the number of possibly delegable prefixes for either the primary or 530 secondary changes by more than a predetermined amount. Typically 531 this comparison would not involve actually comparing the count of 532 existing instances of delegable prefixes, but would instead involve 533 determining the number prefixes that could be delegated given the 534 address ranges of the delegable prefixes allocated to each server. 535 The primary server SHOULD adjust the delegable prefix balance as 536 required to ensure the configured delegable prefix balance, excepting 537 that the primary server SHOULD employ some threshold mechanism to 538 such a balance adjustment in order to minimize the overhead of 539 maintaining this balance. 541 The primary server can, at any time, send an available delegable 542 prefix to the secondary using a BNDUPD with the state FREE-BACKUP. 543 The primary server can attempt to take an available delegable prefix 544 away from the secondary by sending a BNDUPD with the state FREE. If 545 the secondary accepts the BNDUPD, then the lease is now available to 546 the primary and not available to the secondary. Of course, the 547 secondary MUST reject that BNDUPD if it has already allocated that 548 lease to a DHCP client. 550 4.2.2.1. Re-allocating Leases 552 When in PARTNER-DOWN state there is a waiting period after which a 553 delegated prefix can be re-allocated to another client. For 554 delegable prefixes which are "available" when the server enters 555 PARTNER-DOWN state, the period is the MCLT from the entry into 556 PARTNER-DOWN state. For delegated prefixes which are not available 557 when the server enters PARTNER-DOWN state, the period is the MCLT 558 after the later of the following times: the acked-partner-lifetime, 559 the partner-lifetime (if any), the expiration-time, and the entry to 560 PARTNER-DOWN time plus the MCLT. 562 In any other state, a server cannot reallocate a delegated prefix 563 from one client to another without first notifying its partner 564 (through a BNDUPD message) and receiving acknowledgement (through a 565 BNDREPLY message) that its partner is aware that the first client is 566 not using the lease. 568 Specifically, an "available" delegable prefix on a server may be 569 allocated to any client. A prefix which was delegated (leased) to a 570 client and which expired or was released by that client would take on 571 a new state, EXPIRED or RELEASED respectively. The partner server 572 would then be notified that this delegated prefix was EXPIRED or 573 RELEASED through a BNDUPD. When the sending server received the 574 BNDREPLY for that delegated prefix showing it was FREE, it would move 575 the lease from EXPIRED or RELEASED to FREE, and it would be available 576 for allocation by the primary server to any clients. 578 A server MAY reallocate a delegated prefix in the EXPIRED or RELEASED 579 state to the same client with no restrictions provided it has not 580 sent a BNDUPD message regarding the delegated prefix to its partner. 581 This situation would exist if the prefix lease expired or was 582 released after the transition into PARTNER-DOWN state, for instance. 584 4.3. Lazy Updates 586 The DHCPv6 Failover Requirements document includes the requirement 587 that failover must not introduce significant performance impact on 588 server response times (see Sections 7 and 5.2.2 of [RFC7031] ). In 589 order to realize this requirement a server implementing the failover 590 protocol must be able respond to a DHCP client without waiting to 591 update its failover partner whenever the binding database changes. 592 The lazy update mechanism allows a server to allocate a new lease or 593 extend an existing lease, respond to the DHCP client, and then update 594 its failover partner as time permits. 596 Although the lazy update mechanism does not introduce additional 597 delays in server response times, it introduces other difficulties. 598 The key problem with lazy update is that when a server fails after 599 updating a DHCP client with a particular valid lifetime and before 600 updating its failover partner, the failover partner will eventually 601 believe that the client's lease has expired -- even though the DHCP 602 client still retains a valid lease on that address or prefix. It is 603 also possible that the failover partner will have no record at all of 604 the lease being assigned to the DHCP client. Both of these issues 605 are dealt with by use of the MCLT when allocating or extending leases 606 (see Section 4.4). 608 4.4. Maximum Client Lead Time (MCLT) 610 In order to handle problems introduced by lazy updates (see 611 Section 4.3), a period of time known as the "Maximum Client Lead 612 Time" (MCLT) is defined and must be known to both the primary and 613 secondary servers. Proper use of this time interval places an upper 614 bound on the difference allowed between the valid lifetime provided 615 to a DHCP client by a server and the valid lifetime known by that 616 server's failover partner. 618 The MCLT is typically much less than the valid lifetime that a server 619 has been configured to offer a client, and so some strategy must 620 exist to allow a server to offer the configured valid lifetime to a 621 client. During a lazy update the updating server updates its 622 failover partner with a partner lifetime which is longer than the 623 valid lifetime previously given to the DHCP client and which is 624 longer than the valid lifetime that the server has been configured to 625 give a client. This allows the server to give the configured valid 626 lifetime to the client the next time the client renews its lease, 627 since the time that it will give to the client will not be longer 628 than the MCLT beyond the partner lifetime acknowledged by its partner 629 or the current time. 631 The fundamental relationship on which the failover protocol depends 632 is: the lease expiration time known to a DHCP client MUST NOT be 633 greater by more than the MCLT beyond the later of the partner 634 lifetime acknowledged by that server's failover partner and the 635 current time. 637 The remainder of this section makes the above fundamental 638 relationship more explicit. 640 The failover protocol requires a DHCP server to deal with several 641 different lease intervals and places specific restrictions on their 642 relationships. The purpose of these restrictions is to allow the 643 partner to be able to make certain assumptions in the absence of an 644 ability to communicate between servers. 646 In the following explanation, all of the lifetimes are "valid" 647 lifetimes, in the context of [RFC3315]. 649 The different times are: 651 desired lifetime: 652 The desired lifetime is the lease interval that a DHCP server 653 would like to give to a DHCP client in the absence of any 654 restrictions imposed by the failover protocol. Its determination 655 is outside of the scope of the failover protocol. Typically this 656 is the result of external configuration of a DHCP server. 658 actual lifetime: 659 The actual lifetime is the lease interval that a DHCP server gives 660 out to a DHCP client. It may be shorter than the desired lifetime 661 (as explained below). 663 partner lifetime: 664 The partner lifetime is the lease expiration interval the local 665 server tells to its partner in a BNDUPD message. 667 acknowledged partner lifetime: 669 The acknowledged partner lifetime is the partner lifetime the 670 partner server has most recently acknowledged in a BNDREPLY 671 message. 673 4.4.1. MCLT example 675 The following example demonstrates the MCLT concept in practice. The 676 values used are arbitrarily chosen and are not a recommendation for 677 actual values. The MCLT in this case is 1 hour. The desired 678 lifetime is 3 days, and its renewal time is half the lifetime. 680 When a server makes an offer for a new lease on an IPv6 address to a 681 DHCP client, it determines the desired lifetime (in this case, 3 682 days). It then examines the acknowledged partner lifetime (which in 683 this case is zero) and determines the remainder of the time left to 684 run, which is also zero. It adds the MCLT to this value. Since the 685 actual lifetime cannot be allowed to exceed the remainder of the 686 current acknowledged partner lifetime plus the MCLT, the offer made 687 to the client is for the remainder of the current acknowledged 688 partner lifetime (i.e. zero) plus the MCLT. Thus, the actual 689 lifetime is 1 hour (the MCLT). 691 Once the server has sent the REPLY to the DHCP client, it will update 692 its failover partner with the lease information using a BNDUPD 693 message. The partner lifetime will be composed of the T1 fraction 694 (1/2) of the actual lifetime added to the desired lifetime. Thus, 695 the failover partner is updated using a BNDUPD with a partner 696 lifetime of 1/2 hour + 3 days. 698 When the primary server receives a BNDREPLY to its update of the 699 secondary server's (partner's) partner lifetime, it records that as 700 the acknowledged partner lifetime. A server MUST NOT send a BNDREPLY 701 in response to a BNDUPD message until it is sure that the information 702 in the BNDUPD message has been updated in its lease database. See 703 Section 7.5.2. Thus, the primary server in this case can be sure 704 that the secondary server has recorded the partner lifetime in its 705 stable storage when the primary server receives a BNDREPLY message 706 from the secondary server. 708 When the DHCP client attempts to renew at T1 (approximately one half 709 an hour from the start of the lease), the primary server again 710 determines the desired lifetime, which is still 3 days. It then 711 compares this with the original acknowledged partner lifetime (1/2 712 hour + 3 days) and adjusts for the time passed since the secondary 713 was last updated (1/2 hour). Thus the time remaining of the 714 acknowledged partner interval is 3 days. Adding the MCLT to this 715 yields 3 days plus 1 hour, which is more than the desired lifetime of 716 3 days. So the client may have its lease renewed for the desired 717 lifetime -- 3 days. 719 When the primary DHCP server updates the secondary DHCP server after 720 the DHCP client's renewal REPLY is complete, it will calculate the 721 partner lifetime as the T1 fraction of the actual client lifetime 722 (1/2 of 3 days this time = 1.5 days). To this it will add the 723 desired lifetime of 3 days, yielding a total partner lifetime of 4.5 724 days. In this way, the primary attempts to have the secondary always 725 "lead" the client in its understanding of the client's lifetime so as 726 to be able to always offer the client the desired lifetime. 728 Once the initial actual client lifetime of the MCLT is past, the 729 protocol operates effectively like the DHCP protocol does today in 730 its behavior concerning lifetimes. However, the guarantee that the 731 actual client lifetime will never exceed the remaining acknowledged 732 partner server partner lifetime by more than the MCLT allows full 733 recovery from a variety of DHCP server failures. 735 Fundamental relationship: 736 lease time = floor(desired lifetime, ack-partner-lifetime + MCLT) 738 Initial conditions: MCLT = 1h, desired lifetime = 3d 740 DHCPv6 Primary Secondary 741 time Client Server Server 743 | >-SOLICIT------> | | 744 | acknowledged partner lifetime = 0 | 745 | lease time = floor( 3d, 0 + 1h ) = 1h | 746 | <-----ADVERTISE-< | | 747 | lease-time= 1h | | 748 | >-REQUEST------> | | 749 t | <---------REPLY-< | | 750 | lease-time= 1h | | 751 | | >-BNDUPD------> | 752 | | partner-lifetime = 1/2h + 3d 753 | | <----BNDREPLY-< | 754 | | partner-lifetime = 1/2h + 3d 755 1/2h passes ... ... ... 756 t+1/2h | >-RENEW--------> | | 757 | acknowledged partner lifetime = 3d | 758 | lease time = floor( 3d, 3d + 1h ) = 3d | 759 | <---------REPLY-< | | 760 | lease-time=3d | | 761 | | >-BNDUPD-------> | 762 | | partner-lifetime = 1.5d + 3d 763 | | <----BNDREPLY-< | 764 | | partner-lifetime = 1.5d + 3d 765 acknowledged partner lifetime = 1.5d + 3d 766 1.5d passes ... ... ... 767 | | | 768 t+1.5d + 1/2h | >-RENEW--------> | | 769 | acknowledged partner lifetime = 3d | 770 | lease time = floor( 3d, 3d + 1h ) = 3d | 771 | <---------REPLY-< | | 772 | lease-time=3d | | 773 | | >-BNDUPD-------> | 774 | | partner-lifetime = 1.5d + 3d 775 | | <----BNDREPLY-< | 776 | | partner-lifetime = 1.5d + 3d 777 | acknowledged partner lifetime = 1.5d + 3d| 779 Figure 1: MCLT Example 781 5. Message and Option Definitions 783 5.1. Message Framing for TCP 785 Failover communication is conducted over a TCP connection established 786 between the partners. The protocol uses the framing format specified 787 in Section 5.1 of DHCPv6 Bulk Leasequery [RFC5460], but uses 788 different message types with a different message format, described in 789 Section 5.2. The TCP connection between failover servers is made to 790 a specific port, the dhcp-failover port, port 647. All information 791 is sent over the connection as typical DHCP messages that convey DHCP 792 options, following the format defined in Section 22.1 of [RFC3315]. 794 5.2. Failover Message Format 796 All Failover messages defined below share a common format with a 797 fixed size header and a variable format area for options. All values 798 in the message header and in any included options are in network byte 799 order. 801 The following diagram illustrates the format of DHCP messages 802 exchanged between failover partners (which is compatible with the 803 format described in Section 6 of [RFC3315]): 805 0 1 2 3 806 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 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | msg-type | transaction-id | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | sent-time | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | . 813 . options . 814 . (variable) . 815 . | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 msg-type Identifies the DHCP message type; the 819 available message types are listed below. 820 Note that since the TCP connection for 821 failover is made to a unique port, the 822 msg-type codes are allocated from a registry 823 distinct from the Dynamic Host Configuration 824 Protocol for IPv6 (DHCPv6) Message Types 825 registry. 827 transaction-id The transaction ID for this message exchange. 829 sent-time The time the message was transmitted (set 830 as close to transmission as practical), 831 in seconds since midnight (UTC), 832 January 1, 2000, modulo 2^32. Used to 833 determine the time skew of the failover 834 partners. 836 options Options carried in this message. These 837 options are all defined in the Dynamic Host 838 Configuration Protocol for IPv6 (DHCPv6) 839 Option Codes registry. A number of existing 840 DHCPv6 options are used and several more 841 are defined in this document. 843 5.3. Messages 845 The following list contains the new message types created for 846 failover communication. 848 5.3.1. BNDUPD 850 The binding update message BNDUPD (TBD1) is used to send the binding 851 lease changes to the partner. At most one OPTION_CLIENT_DATA option 852 may appear in a BNDUPD message. Note that not all data in a BNDUPD 853 is sent in an OPTION_CLIENT_DATA option. Information about delegable 854 prefixes not currently allocated to a particular client is sent in 855 BNDUPD messages but not within OPTION_CLIENT_DATA options. The 856 partner is expected to respond with a BNDREPLY message. 858 5.3.2. BNDREPLY 860 The binding acknowledgement message BNDREPLY (TBD2) is used for 861 confirmation of the received BNDUPD message. It may contain a 862 positive or negative response (e.g. due to detected lease conflict). 864 5.3.3. POOLREQ 866 The Pool Request message POOLREQ (TBD3) is used by the secondary 867 server to request allocation of delegable prefixes from the primary 868 server. The primary responds with POOLRESP. 870 5.3.4. POOLRESP 872 The Pool Response POOLRESP (TBD4) message is used by the primary 873 server to indicate that it has received the secondary's servers 874 request to ensure that delegable prefixes are balanced between the 875 primary and secondary servers. It does not indicate that all of the 876 BNDUPDs that might be created from any rebalancing have been sent or 877 responded to, it only indicates reception and acceptance of the task 878 of ensuring the balance is examined and corrected as necessary. 880 5.3.5. UPDREQ 882 The update request message UPDREQ (TBD5) is used by one server to 883 request that its partner sends all binding database changes that have 884 not yet been confirmed. The partner is expected to respond with zero 885 or more BNDUPD messages, followed by an UPDDONE message that signals 886 that all of the BNDUPD messages have been sent and a corresponding 887 BNDREPLY message has been received for each of them. 889 5.3.6. UPDREQALL 891 The update request all UPDREQALL (TBD6) is used by one server to 892 request that all binding database information present in the other 893 server be sent to the requesting server, in order to recover from a 894 total loss of its binding database by the requesting server. A 895 server receiving this request responds with zero or more BNDUPD 896 messages, followed by an UPDDONE that signals that all of the BNDUPD 897 messages have been sent and a corresponding BNDREPLY message has been 898 received for each of them. 900 5.3.7. UPDDONE 902 The update done message UPDDONE (TBD7) is used by the server 903 responding to an UPDREQ or UPDREQALL to indicate that all requested 904 updates have been sent by the responding server and acked by the 905 requesting server. 907 5.3.8. CONNECT 909 The connect message CONNECT (TBD8) is used by the primary server to 910 establish a failover connection with the secondary server, and to 911 transmit several important configuration attributes items between the 912 servers. The partner is expected to confirm by responding with 913 CONNECTREPLY message. 915 5.3.9. CONNECTREPLY 917 The connect acknowledgement message CONNECTREPLY (TBD9) is used by 918 the secondary server to respond to a CONNECT message from the primary 919 server. 921 5.3.10. DISCONNECT 923 The disconnect message DISCONNECT (TBD10) is used by either server 924 when closing a connection and shutting down. No response is required 925 for this message. The DISCONNECT message SHOULD contain an 926 OPTION_STATUS_CODE option with an appropriate status. Often this 927 will be ServerShuttingDown. See Section 5.6. A server SHOULD 928 include a descriptive message as to the reasons causing the 929 disconnect message. 931 5.3.11. STATE 933 The state message STATE (TBD11) is used by either server to inform 934 its partner about a change of failover state. In some cases it may 935 be used to also inform the partner about the current state, e.g. 936 after connection is established in COMMUNICATIONS-INTERRUPTED or 937 PARTNER-DOWN states. 939 5.3.12. CONTACT 941 The contact message CONTACT (TBD12) is used by either server to 942 ensure that its partner continues to see the connection as 943 operational. It MUST be transmitted periodically over every 944 established connection if other message traffic is not flowing, and 945 it MAY be sent at any time. See Section 6.5. 947 5.4. Transaction Id 949 The initiator of a message exchange MUST set the transaction-id. 950 This means that all of the messages above except BNDREPLY, POOLRESP, 951 UPDDONE, and CONNECTREPLY must set the tranasction-id. The 952 transaction-id MUST be unique among all currently outstanding 953 messages sent to the failover partner. A straightforward way to 954 ensure this is to simply use an incrementing value, with one caveat. 955 The UPDREQ and UPDREQALL messages may be separated by a considerable 956 time prior to the receipt of an UPDDONE message. While the usual 957 pattern of message exchange would have the partner doing the vast 958 majority of message initiation, it is remotely possible that the 959 partner which initiated the UPDREQ or UPDREQALL messages might also 960 send enough messages to wrap the 24-bit transaction-id and duplicate 961 the transaction-id of the outstanding UPDREQ or UPDREQALL. Thus, it 962 is important to ensure that the transaction-id of a currently 963 outstanding UPDREQ or UPDREQALL is not replicated in any message 964 initiated prior to the receipt of the corresponding UPDDONE. 966 5.5. Options 968 The following new options are defined. 970 5.5.1. OPTION_F_BINDING_STATUS 972 The binding-status represents an implementation independent 973 representation of the status (or the state) of a lease on an IPv6 974 address or prefix. 976 This is an unsigned byte. 978 The code for this option is TBD13. 980 0 1 2 3 981 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 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | OPTION_F_BINDING_STATUS | option-len | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | binding-status| 986 +-+-+-+-+-+-+-+-+ 988 option-code OPTION_F_BINDING_STATUS (TBD13). 989 option-len 1. 990 binding-status The binding-status. See below. 992 Value binding-status 993 ----- -------------- 994 0 reserved 995 1 ACTIVE 996 2 EXPIRED 997 3 RELEASED 998 4 PENDING-FREE 999 5 FREE 1000 6 FREE-BACKUP 1001 7 ABANDONED 1002 8 RESET 1004 The binding-status values are discussed in Section 7.2 1006 5.5.2. OPTION_F_CONNECT_FLAGS 1008 Flags which indicate attributes of the connecting server. 1010 This consists of an unsigned 16 bit value in network byte order. 1012 The code for this option is TBD14. 1014 0 1 2 3 1015 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 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | OPTION_F_CONNECT_FLAGS | option-len | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | flags | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 option-code OPTION_F_CONNECT_FLAGS (TBD14). 1023 option-len 2. 1024 flags flag bits, see below: 1026 0 1 1027 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | MBZ |F| 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 The bits (numbered from the most-significant bit in network 1033 byte-order) are used as follows: 1035 0-14: MBZ 1036 Must be zero 1037 15 (F): FIXED_PD_LENGTH 1038 Set to 1 to indicate that all prefixes delegated from a 1039 given delegable prefix have the same prefix length (size). 1040 If this is not set, the prefixes delegated from one 1041 delegable prefix may have different sizes. 1043 If the FIXED_PD_LENGTH bit is not set, it indicates that prefixes of 1044 a range of sizes can be delegated from a given delegable prefix. 1045 Note that if the FIXED_PD_LENGTH bit is set, each delegable prefix 1046 may have its own fixed size -- this flag does not imply that all 1047 prefixes delegated will be the same size, rather that all prefixes 1048 delegated from the same delegable prefix will be the same size. 1050 If the FIXED_PD_LENGTH bit is set, the length used for each prefix is 1051 specified independent of the failover protocol, but must be known to 1052 both failover partners. It might be specified in the configuration 1053 for each delegable prefix or it might be fixed for the entire server. 1055 5.5.3. OPTION_F_DNS_REMOVAL_INFO 1057 This option contains the information necessary to remove a DNS name 1058 that was entered by the failover partner. 1060 The code for this option is TBD15. 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | OPTION_F_DNS_REMOVAL_INFO | option-len | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | encapsulated-options | 1068 | (variable) | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 option-code OPTION_F_DNS_REMOVAL_INFO (TBD15). 1072 option-len variable 1073 sub-options Three possible encapsulated options: 1074 OPTION_F_DNS_HOST_NAME 1075 OPTION_F_DNS_ZONE_NAME 1076 OPTION_F_DNS_FLAGS 1078 5.5.4. OPTION_F_DNS_HOST_NAME 1080 Contains the host name that was entered into DNS by the failover 1081 partner. 1083 This is a DNS name encoded in [RFC1035] format as specified in 1084 Section 8 of [RFC3315]. 1086 The code for this option is TBD16. 1088 0 1 2 3 1089 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 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | OPTION_F_DNS_HOST_NAME | option-len | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | . 1094 . . 1095 . host-name . 1096 . (variable) . 1097 . | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 option-code OPTION_F_DNS_HOST_NAME (TBD16). 1101 option-len length of host-name. 1102 host-name RFC 1035 encoded host-name. 1104 5.5.5. OPTION_F_DNS_ZONE_NAME 1106 Contains the zone name that was entered into DNS by the failover 1107 partner. 1109 This is a DNS name encoded in [RFC1035] format as specified in 1110 Section 8 of [RFC3315]. 1112 The code for this option is TBD17. 1114 0 1 2 3 1115 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 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | OPTION_F_DNS_ZONE_NAME | option-len | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | . 1120 . . 1121 . zone-name . 1122 . (variable) . 1123 . | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 option-code OPTION_F_DNS_ZONE_NAME (TBD17). 1127 option-len length of zone-name. 1128 zone-name RFC 1035 encoded zone name. 1130 5.5.6. OPTION_F_DNS_FLAGS 1132 Flags which indicate what needs to be done to remove this DNS name. 1134 This consists of an unsigned 16 bit value in network byte order. 1136 The code for this option is TBD18. 1138 0 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | OPTION_F_DNS_FLAGS | option-len | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | flags | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 option-code OPTION_F_DNS_FLAGS (TBD18). 1147 option-len 2. 1148 flags flag bits, see below: 1150 0 1 1151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | MBZ |U|S|R|F| 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 The bits (numbered from the most-significant bit in network 1157 byte-order) are used as follows: 1159 0-11: MBZ 1160 Must be zero 1161 12 (U): USING_REQUESTED_FQDN 1162 Set to 1 to indicate that name used came from the 1163 FQDN that was received from the client. 1164 13 (S): SYNTHESIZED_NAME 1165 Set to 1 to indicate that the name was synthesized 1166 based on some algorithm. 1167 14 (R): REV_UPTODATE 1168 Set to 1 to indicate that the reverse zone is up to date. 1169 15 (F): FWD_UPTODATE 1170 Set to 1 to indicate that the forward zone is up to date. 1172 If both the U and S bits are unset, then the name must have been 1173 provided from some alternative configuration, such as client 1174 registration in some database accessible to the DHCP server. 1176 5.5.7. OPTION_F_EXPIRATION_TIME 1178 The greatest lifetime that this server has ever acked to its partner 1179 in a BNDREPLY for a particular lease or prefix. This MUST be an 1180 absolute time (i.e. seconds since midnight January 1, 2000 UTC, 1181 modulo 2^32). 1183 This is an unsigned 32-bit integer in network byte order. 1185 The code for this option is TBD19. 1187 0 1 2 3 1188 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 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | OPTION_F_EXPIRATION_TIME | option-len | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | expiration-time | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 option-code OPTION_F_EXPIRATION_TIME (TBD19). 1196 option-len 4. 1197 expiration-time The expiration time. This MUST be an 1198 absolute time (i.e. seconds since midnight 1199 January 1, 2000 UTC, modulo 2^32). 1201 5.5.8. OPTION_F_MAX_UNACKED_BNDUPD 1203 The maximum number of BNDUPD messages that this server is prepared to 1204 accept over the TCP connection without causing the TCP connection to 1205 block. 1207 This is an unsigned 32-bit integer in network byte order. 1209 The code for this option is TBD20. 1211 0 1 2 3 1212 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 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | OPTION_F_MAX_UNACKED_BNDUPD | option-len | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | max-unacked-bndupd | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 option-code OPTION_F_MAX_UNACKED_BNDUPD (TBD20). 1220 option-len 4. 1221 max-unacked-bndupd Maximum number of unacked BNDUPD message 1222 allowed. 1224 5.5.9. OPTION_F_MCLT 1226 The maximum-client-lead-time (MCLT) is the upper bound on the 1227 difference allowed between the valid lifetime provided to a DHCP 1228 client by a server and the valid lifetime known by that server's 1229 failover partner. It is an interval, measured in seconds. See 1230 Section 4.4. 1232 This is an unsigned 32-bit integer in network byte order. 1234 The code for this option is TBD21. 1236 0 1 2 3 1237 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 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 | OPTION_F_MCLT | option-len | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | mclt | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 option-code OPTION_F_MCLT (TBD21). 1245 option-len 4. 1246 mclt The maximum-client-lead-time, in seconds. 1248 5.5.10. OPTION_F_PARTNER_LIFETIME 1250 The time after which the partner can consider an IPv6 address expired 1251 and is able to re-use the IPv6 address. This MUST be an absolute 1252 time (i.e. seconds since midnight January 1, 2000 UTC, modulo 2^32). 1254 This is an unsigned 32-bit integer in network byte order. 1256 The code for this option is TBD22. 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | OPTION_F_PARTNER_LIFETIME | option-len | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | partner-lifetime | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 option-code OPTION_F_PARTER_LIFETIME (TBD22). 1267 option-len 4. 1268 partner-lifetime The partner-lifetime. This MUST be an 1269 absolute time (i.e. seconds since midnight 1270 January 1, 2000 UTC, modulo 2^32). 1272 5.5.11. OPTION_F_PARTNER_LIFETIME_SENT 1274 The time that was received in an OPTION_F_PARTNER_LIFETIME 1275 Section 5.5.10 option. This is an exact duplicate (echo) of the time 1276 received in the OPTION_F_PARTNER_LIFETIME option, uncorrected and 1277 unadjusted in any way. This MUST be an absolute time (i.e. seconds 1278 since midnight January 1, 2000 UTC, modulo 2^32). 1280 This is an unsigned 32-bit integer in network byte order. 1282 The code for this option is TBD23. 1284 0 1 2 3 1285 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 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 |OPTION_F_PARTNER_LIFETIME_SENT | option-len | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | partner-lifetime-sent | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 option-code OPTION_F_PARTNER_LIFETIME_SENT (TBD23). 1293 option-len 4. 1294 partner-lifetime-sent The partner-lifetime received in an 1295 OPTION_F_PARTNER_LIFETIME option. 1296 This MUST be an absolute time 1297 (i.e. seconds since midnight 1298 January 1, 2000 UTC, modulo 2^32). 1300 5.5.12. OPTION_F_PARTNER_DOWN_TIME 1302 The time that the partner most recently lost communications with its 1303 failover partner. This MUST be an absolute time (i.e. seconds since 1304 midnight January 1, 2000 UTC, modulo 2^32). 1306 This is an unsigned 32-bit integer in network byte order. 1308 The code for this option is TBD24. 1310 0 1 2 3 1311 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 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | OPTION_F_PARTNER_DOWN_TIME | option-len | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | partner-down-time | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 option-code OPTION_F_PARTNER_DOWN_TIME (TBD24). 1319 option-len 4. 1320 partner-down-time Contains the partner-down-time. This MUST be an 1321 absolute time (i.e. seconds since midnight 1322 January 1, 2000 UTC, modulo 2^32). 1324 5.5.13. OPTION_F_PARTNER_RAW_CLT_TIME 1326 The time when the partner most recently interacted with the DHCP 1327 client associated with this IPv6 address or prefix. This MUST be an 1328 absolute time (i.e. seconds since midnight January 1, 2000 UTC, 1329 modulo 2^32). 1331 This is an unsigned 32-bit integer in network byte order. 1333 The code for this option is TBD25. 1335 0 1 2 3 1336 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 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | OPTION_F_PARTNER_RAW_CLT_TIME | option-len | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | partner-raw-clt-time | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 option-code OPTION_F_PARTNER_RAW_CLT_TIME (TBD25). 1344 option-len 4. 1345 partner-raw-clt-time Contains the partner-raw-clt-time. This MUST 1346 be an absolute time (i.e. seconds since 1347 midnight January 1, 2000 UTC, modulo 2^32). 1349 5.5.14. OPTION_F_PROTOCOL_VERSION 1351 The protocol version allows one failover partner to determine the 1352 version of the protocol being used by the other partner, to allow for 1353 changes and upgrades in the future. Two components are provided, to 1354 allow for large and small changes to be represented in one 32-bit 1355 number. The intent is that large changes would result in an 1356 increment of the major-version, while small changes would result in 1357 an increment of the minor-version. As subsequent updates and 1358 extensions of this document can define changes to these values in any 1359 way deemed appropriate no attempt is made to further define large and 1360 small in this document. 1362 This consists of two unsigned 16-bit integers, in network byte order. 1364 The code for this option is TBD26. 1366 0 1 2 3 1367 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 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | OPTION_F_PROTOCOL_VERSION | option-len | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | major-version | minor-version | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 option-code OPTION_F_PROTOCOL_VERSION (TBD26). 1375 option-len 4. 1376 major-version The major version of the protocol. Initially 1. 1377 minor-version The minor version of the protocol. Initially 0. 1379 5.5.15. OPTION_F_KEEPALIVE_TIME 1381 The number of seconds (an interval) within which the server must 1382 receive a message from its partner, or it will assume that 1383 communications from the partner is not ok. 1385 This is an unsigned 32-bit integer in network byte order. 1387 The code for this option is TBD27. 1389 0 1 2 3 1390 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 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | OPTION_F_KEEPALIVE_TIME | option-len | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | keepalive-time | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 option-code OPTION_F_KEEPALIVE_TIME (TBD27). 1398 option-len 4. 1399 receive-time The keepalive-time. An interval of seconds. 1401 5.5.16. OPTION_F_RECONFIGURE_DATA 1403 Contains the information necessary for one failover partner to use 1404 the reconfigure-key created on the other failover partner. 1406 The code for this option is TBD28. 1408 0 1 2 3 1409 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 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | OPTION_F_RECONFIGURE_DATA | option-len | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | reconfigure-time | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | . 1416 . . 1417 . reconfigure-key . 1418 . (variable) . 1419 . | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 option-code OPTION_F_RECONFIGURE_DATA (TBD28). 1423 option-len 4 + length of reconfigure-key. 1424 reconfigure-time Time at which reconfigure-key was created. 1425 This MUST be an absolute time (i.e. seconds 1426 since midnight 1427 January 1, 2000 UTC, modulo 2^32). 1428 reconfigure-key The reconfigure-key. 1430 5.5.17. OPTION_F_RELATIONSHIP_NAME 1432 A name for this failover relationship. Used to distinguish between 1433 relationships when there are multiple failover relationships between 1434 two failover servers. 1436 A UTF-8 encoded text string suitable for display to an end user, 1437 which MUST NOT be null-terminated. 1439 The code for this option is TBD29. 1441 0 1 2 3 1442 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 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | OPTION_F_RELATIONSHIP_NAME | option-len | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | . 1447 . . 1448 . relationship-name . 1449 . (variable) . 1450 . | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 option-code OPTION_F_RELATIONSHIP_NAME (TBD29). 1454 option-len length of relationship-name. 1455 relationship-name A UTF-8 encoded text string suitable for 1456 display to an end user, which MUST NOT be 1457 null-terminated. 1459 5.5.18. OPTION_F_SERVER_FLAGS 1461 The OPTION_F_SERVER_FLAGS option specifies information associated 1462 with the failover endpoint sending the option. 1464 This is an unsigned byte. 1466 The code for this option is TBD30. 1468 0 1 2 3 1469 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 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | OPTION_F_SERVER_FLAGS | option-len | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | server-flags | 1474 +-+-+-+-+-+-+-+-+ 1476 option-code OPTION_F_SERVER_FLAGS (TBD30). 1477 option-len 1. 1478 server-flags The server flags, see below: 1480 0 1 2 3 4 5 6 7 1481 +-+-+-+-+-+-+-+-+ 1482 | MBZ |A|S|C| 1483 +-+-+-+-+-+-+-+-+ 1485 The bits (numbered from the most-significant bit in network 1486 byte-order) are used as follows: 1488 0-4 : MBZ 1489 Must be zero 1490 5 (A): ACK_STARTUP 1491 Set to 1 to indicate that the OPTION_F_SERVER_FLAGS most 1492 recently received contained the STARTUP bit set. 1493 6 (S): STARTUP, 1494 MUST be set to 1 whenever the server is in STARTUP state. 1495 7 (C): COMMUNICATED 1496 Set to 1 to indicate that the sending server has 1497 communicated with its partner. 1499 5.5.19. OPTION_F_SERVER_STATE 1501 The OPTION_F_SERVER_STATE option specifies the endpoint state of the 1502 server sending the option. 1504 This is an unsigned byte. 1506 The code for this option is TBD31. 1508 0 1 2 3 1509 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 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | OPTION_F_SERVER_STATE | option-len | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | server-state | 1514 +-+-+-+-+-+-+-+-+ 1516 option-code OPTION_F_SERVER_STATE (TBD31). 1517 option-len 1. 1518 server-state Failover endpoint state. 1520 Value Server State 1521 ----- ---------------------------------------------------------- 1522 0 reserved 1523 1 STARTUP Startup state (1) 1524 2 NORMAL Normal state 1525 3 COMMUNICATIONS-INTERRUPTED Communication interrupted 1526 4 PARTNER-DOWN Partner down 1527 5 POTENTIAL-CONFLICT Synchronizing 1528 6 RECOVER Recovering bindings from partner 1529 7 SHUTDOWN Shutting down for a long period. 1530 8 RECOVER-DONE Interlock state prior to NORMAL 1531 9 RESOLUTION-INTERRUPTED Comm. failed during resolution 1532 10 CONFLICT-DONE Primary resolved its conflicts 1534 These states are discussed in detail in Section 8. 1536 (1) The STARTUP state is never sent to the partner server, it is 1537 indicated by the STARTUP bit in the server-flags options (see 1538 Section 8.3). 1540 5.5.20. OPTION_F_START_TIME_OF_STATE 1542 The time at which the associated state began to hold its current 1543 value. When this option appears in a STATE message, the state to 1544 which it refers is the server endpoint state. When it appears in an 1545 IA_NA-options, IA_TA-options, or IA_PD-options field , the state to 1546 which it refers is the binding-status value in the OPTION_IA_NA, 1547 OPTION_IA_TA, or OPTION_IA_PD option, respectively. This MUST be an 1548 absolute time (i.e. seconds since midnight January 1, 2000 UTC, 1549 modulo 2^32). 1551 This is an unsigned 32-bit integer in network byte order. 1553 The code for this option is TBD32. 1555 0 1 2 3 1556 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 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | OPTION_F_START_TIME_OF_STATE | option-len | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | start-time-of-state | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 option-code OPTION_F_START_TIME_OF_STATE (TBD32). 1564 option-len 4. 1565 start-time-of-state The start-time-of-state. This MUST be an 1566 absolute time (i.e. seconds since midnight 1567 January 1, 2000 UTC, modulo 2^32). 1569 5.5.21. OPTION_F_STATE_EXPIRATION_TIME 1571 The state-expiration-time is the time at which the current state of 1572 this lease will expire. This MUST be an absolute time (i.e. seconds 1573 since midnight January 1, 2000 UTC, modulo 2^32). 1575 Note that states other than ACTIVE may have a time associated with 1576 them. In particular, EXPIRED might have a time associated with it, 1577 in the event that some sort of "grace period" existed where the lease 1578 would not be reused for a period after the lease expired. The 1579 ABANDONED state might have a time associated with it, in the event 1580 that the servers participating in failover had a time after which an 1581 ABANDONED lease might be placed back into a pool for allocation to a 1582 client. In general, if there is an OPTION_STATE_EXPIRATION_TIME 1583 associated with a particular state, that indicates the associated 1584 state will expire and move to a different state at that time. 1586 This is an unsigned 32-bit integer in network byte order. 1588 The code for this option is TBD33. 1590 0 1 2 3 1591 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 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | OPTION_F_STATE_EXPIRATION_TIME| option-len | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | state-expiration-time | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 option-code OPTION_F_STATE_EXPIRATION_TIME (TBD33). 1599 option-len 4. 1600 state-expiration-time The state-expiration-time. This MUST be an 1601 absolute time (i.e. seconds since midnight 1602 January 1, 2000 UTC, modulo 2^32). 1604 5.6. Status Codes 1606 The following new status codes are defined, to be used in the 1607 OPTION_STATUS_CODE option. 1609 AddressInUse (TBD34) 1610 One client on one server has leases that are in conflict with the 1611 leases that the client has on another server. Alternatively, the 1612 address could be associated with a different IAID on each server. 1614 ConfigurationConflict (TBD35) 1615 The configuration implied by the information in a BNDUPD (e.g. the 1616 IPV6 address or prefix address) is in direct conflict with the 1617 information known to the receiving server. 1619 MissingBindingInformation (TBD36) 1620 There is insufficient information in a BNDUPD to effectively 1621 process it. 1623 OutdatedBindingInformation (TBD37) 1624 Returned when the information in a server's binding database 1625 conflicts with the information found in an incoming BNDUPD, and 1626 the server believes that the information in its binding database 1627 more accurately reflects reality. 1629 ServerShuttingDown (TBD38) 1630 Returned when the server is undergoing an operator directed or 1631 otherwise planned shutdown. 1633 DNSUpdateNotSupported (TBD39) 1634 Returned when a server receives a BNDUPD with DNS update 1635 information included, and the server doesn't support DNS update. 1637 ExcessiveTimeSkew (TBD40) 1638 Returned when a server detects that the time skew between its 1639 current time and its partner's current time is greater than 5 1640 seconds. 1642 6. Connection Management 1644 Communication between failover partners takes place over a long-lived 1645 TCP connection. This connection is always initiated by the primary 1646 server, and if the long-lived connection is lost it is the 1647 responsibility of the primary server to attempt to reconnect to the 1648 secondary server. The detailed process used by the primary server 1649 when initiating a connection and by the secondary server when 1650 responding to a connection attempt documented in Section 6.1 is 1651 followed each time a connection is established, regardless of any 1652 previous connection between the failover partners. 1654 6.1. Creating Connections 1656 Every primary server implementing the failover protocol MUST 1657 periodically attempt to create a TCP connection to the dhcp-failover 1658 port (647) of all of its configured partners, where the period is 1659 implementation dependent and SHOULD be configurable. In the event 1660 that a connection has been rejected by a CONNECTREPLY message with a 1661 reject-reason option contained in it or a DISCONNECT message, a 1662 server SHOULD reduce the frequency with which it attempts to connect 1663 to that server but it MUST continue to attempt to connect 1664 periodically. 1666 Every secondary server implementing the failover protocol MUST listen 1667 for TCP connection attempts on the dhcp-failover port (647) from a 1668 primary server. 1670 After a primary server successfully establishes a TCP connection to a 1671 secondary server, it MUST continue the connection process as 1672 described in Section 8.2 of [RFC7653]. In the language of that 1673 section, the primary failover server operates as the "requestor" and 1674 the secondary failover server operates as the "DHCP server". The 1675 message that is sent over the newly established connection is a 1676 CONNECT message, instead of an ACTIVELEASEQUERY message. 1678 When a connection attempt is received by a secondary server, the only 1679 information that the secondary server has is the IP address of the 1680 partner initiating a connection. If it has any relationships with 1681 the connecting server for which it is a secondary server, it should 1682 operate as described in Section 9.1 of [RFC7653], with the exception 1683 that instead of waiting for an Active Leasequery message it will wait 1684 for a CONNECT message. Once it has received the CONNECT message, it 1685 will use the information in that message to determine which 1686 relationship this connection is to service. 1688 If it has no secondary relationships with the connecting server, it 1689 MUST drop the connection. 1691 To summarize -- a primary server MUST use a connection that it has 1692 initiated in order to send a CONNECT message. Every server that is a 1693 secondary server in a relationship MUST listen for CONNECT messages 1694 from the primary server. 1696 When the CONNECT and CONNECTREPLY exchange successfully produces a 1697 working failover connection, the next message sent over a new 1698 connection is a STATE message. See Section 6.3. Upon the receipt of 1699 the STATE message, the receiver can consider communications ok. 1701 6.1.1. Sending a CONNECT message 1703 The CONNECT message is sent with information about the failover 1704 configuration on the primary server. The message MUST contain at 1705 least the following information in the options area: 1707 o OPTION_F_PROTOCOL_VERSION containing the protocol version that the 1708 primary server will use when sending failover messages. 1710 o OPTION_F_MCLT containing the configured MCLT. 1712 o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an 1713 interval) within which the server must receive a message from its 1714 partner, or it will assume that communications from the partner is 1715 not ok. 1717 o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of 1718 BNDUPD messages that this server is prepared to accept over the 1719 failover connection without causing the connection to block. This 1720 is to implement application level flow control over the 1721 connection, so that a flood of BNDUPD messages does not cause the 1722 connection to block and thereby prevent other messages from being 1723 transmitted over the connection and received by the failover 1724 partner. 1726 o OPTION_F_RELATIONSHIP_NAME containing name of the failover 1727 relationship to which this connection applies. If there is no 1728 OPTION_F_RELATIONSHIP_NAME in the CONNECT message, it indicates 1729 that there is only a single relationship between this pair of 1730 primary and secondary servers. 1732 o OPTION_F_CONNECT_FLAGS containing information about certain 1733 attributes of the connecting servers. 1735 6.1.2. Receiving a CONNECT message 1737 A server receiving a CONNECT message must process the information in 1738 the message and decide whether or not to accept the connection. The 1739 processing is performed as follows: 1741 o sent-time - The secondary server checks the sent-time to see if it 1742 is within 5 seconds of its current time. See Section 7.1. If it 1743 is not, return ExcessiveTimeSkew in the OPTION_STATUS_CODE to 1744 reject the CONNECT message. 1746 o OPTION_F_PROTOCOL_VERSION - The secondary server decides if the 1747 protocol version of the primary server is supported by the 1748 secondary server. If it is not, return NotSupported in the 1749 OPTION_STATUS_CODE to reject the CONNECT message. 1751 o OPTION_F_MCLT - Use this MCLT supplied by the primary server. 1752 Remember this MCLT and use it until a different MCLT is supplied 1753 by some subsequent CONNECT message. 1755 o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the 1756 FO_KEEPALIVE_TIME when implementing the Unreachability Detection 1757 algorithm described in Section 6.6. 1759 o OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of 1760 unacked BNDUPD messages queued to the primary server never exceeds 1761 the value in the OPTION_F_MAX_UNACKED_BNDUPD option. 1763 o OPTION_F_CONNECT_FLAGS - Ensure that the secondary can process 1764 information from the primary as specified in the flags. For 1765 example, if the secondary server cannot process prefix delegation 1766 with variable sized prefixes delegated from the same delegable 1767 prefix, and the primary server says that it can, the secondary 1768 should reject the connection. 1770 A CONNECT message SHOULD always be followed by a CONNECTREPLY 1771 message, either to accept the connection or to reject the connection 1772 by including an OPTION_STATUS_CODE option with an error reject. In 1773 order to reject the connection attempt, simply send a CONNECTREPLY 1774 message with the OPTION_STATUS_CODE with the correct status. If 1775 accepting the connection attempt, then send a CONNECTREPLY message 1776 with the following information: 1778 o OPTION_F_PROTOCOL_VERSION containing the protocol version being 1779 used by the secondary server when sending failover messages. 1781 o OPTION_F_MCLT containing the MCLT currently in use on the 1782 secondary server. This MUST equal the MCLT that was in the 1783 OPTION_F_MCLT option in the CONNECT. 1785 o OPTION_F_KEEPALIVE_TIME containing the number of seconds (an 1786 interval) within which the server must receive a message from its 1787 partner, or it will assume that communications from the partner is 1788 not ok. 1790 o OPTION_F_MAX_UNACKED_BNDUPD containing the maximum number of 1791 BNDUPD messages that this server is prepared to accept over the 1792 failover connection without causing the connection to block. This 1793 is to implement application level flow control over the 1794 connection, so that a flood of BNDUPD messages does not cause the 1795 connection to block and thereby prevent other messages from being 1796 transmitted over the connection and received by the failover 1797 partner. 1799 o OPTION_F_CONNECT_FLAGS - Place information into this option to 1800 describe the attributes of the secondary server that the primary 1801 needs to know about. 1803 After sending a CONNECTREPLY message to accept the primary server's 1804 CONNECT message, the secondary server MUST send a STATE message (see 1805 Section 6.3). 1807 6.1.3. Receiving a CONNECTREPLY message 1809 A server receiving a CONNECTREPLY message must process the 1810 information in the message and decide whether or not to continue to 1811 employ the connection. The processing is performed as follows: 1813 o OPTION_F_PROTOCOL_VERSION - The primary server decides if the 1814 protocol version in use by the secondary server is supported by 1815 the primary server. If it is not, send a DISCONNECT message and 1816 drop the connection. If it is supported, continue processing. It 1817 is possible that the primary and secondary server will each be 1818 sending different versions of the protocol to the other server. 1819 The extent to which this is supported will be in part defined by 1820 as yet unknown differences in the protocols that the versions 1821 represent, and in part by the capabilities of the two 1822 implementations involved in the failover relationship. 1824 o OPTION_F_MCLT - Compare the MCLT received with the configured 1825 MCLT, and if they are different send a DISCONNECT message and drop 1826 the connection. 1828 o OPTION_F_KEEPALIVE_TIME - Remember the keepalive-time as the 1829 FO_KEEPALIVE_TIME when implementing the Unreachability Detection 1830 algorithm described in Section 6.6. 1832 o OPTION_F_MAX_UNACKED_BNDUPD - Ensure that the maximum amount of 1833 unacked BNDUPD messages queued to the secondary server never 1834 exceeds the value in the OPTION_F_MAX_UNACKED_BNDUPD option. 1836 o OPTION_F_CONNECT_FLAGS - Ensure that the primary can process 1837 information from the secondary as specified in the flags. For 1838 example, if the primary server cannot process prefix delegation 1839 with variable sized prefixes delegated from the same delegable 1840 prefix, and the secondary server says that it can, the primary 1841 should drop the connection. 1843 After receiving a CONNECTREPLY message that accepted the primary 1844 server's CONNECT message, the primary server MUST send a STATE 1845 message (see Section 6.3). 1847 6.2. Endpoint Identification 1849 A failover endpoint is always associated with a set of DHCP prefixes 1850 that are configured on the DHCP server where the endpoint appears. A 1851 DHCP prefix MUST NOT be associated with more than one failover 1852 endpoint. 1854 The failover protocol SHOULD be configured with one failover 1855 relationship between each pair of failover servers. In this case 1856 there is one failover endpoint for that relationship on each failover 1857 partner. This failover relationship MUST have a unique name. 1859 Any failover endpoint can take actions and hold unique states. 1861 This document frequently describes the behavior of the protocol in 1862 terms of primary and secondary servers, not primary and secondary 1863 failover endpoints. However, it is important to remember that every 1864 'server' described in this document is in reality a failover endpoint 1865 that resides in a particular process, and that several failover end- 1866 points may reside in the same server process. 1868 It is not the case that there is a unique failover endpoint for each 1869 prefix that participates in a failover relationship. On one server, 1870 there is (typically) one failover endpoint per partner, regardless of 1871 how many prefixes are managed by that combination of partner and 1872 role. On a particular server, any given prefix that participates in 1873 failover will be associated with exactly one failover endpoint. 1875 When a connection is received from the partner, the unique failover 1876 endpoint to which the message is directed is determined solely by the 1877 IPv6 address of the partner, the relationship-name, and the role of 1878 the receiving server. 1880 6.3. Sending a STATE message 1882 A server MUST send a STATE message to its failover partner whenever 1883 the state of the failover endpoint changes. Sending the occasional 1884 duplicate STATE message will cause no problems, and not updating the 1885 failover partner with information about a failover endpoint state 1886 change can, in many cases, cause the entire failover protocol to be 1887 inoperative. 1889 The STATE message is sent with information about the endpoint state 1890 of the failover relationship. The STATE message MUST contain at 1891 least the following information in the options area: 1893 o OPTION_F_SERVER_STATE containing the state of this failover 1894 endpoint. 1896 o OPTION_F_SERVER_FLAGS containing the flag values associated with 1897 this failover endpoint. 1899 o OPTION_F_START_TIME_OF_STATE containing the time when this became 1900 the state of this failover endpoint. 1902 o OPTION_F_PARTNER_DOWN_TIME containing time that this failover 1903 endpoint went into PARTNER-DOWN state if this server is in 1904 PARTNER-DOWN state. If this server isn't in PARTNER-DOWN state, 1905 do not include this option. 1907 The server sending a STATE message SHOULD ensure that this 1908 information is written to stable storage prior to enqueuing it to its 1909 failover partner. 1911 6.4. Receiving a STATE message 1913 A server receiving a STATE message must process the information in 1914 the message and decide how to react to the information. The 1915 processing is performed as follows: 1917 o OPTION_F_SERVER_STATE - If this represents a change in state for 1918 the failover partner, react according to the direction in 1919 Section 8.1. If the state is not PARTNER-DOWN, clear any memory 1920 of the partner-down-time. 1922 o OPTION_F_SERVER_FLAGS - Remember these flags in an appropriate 1923 data area so they can be referenced by code implementing other 1924 parts of this document. 1926 o OPTION_F_START_TIME_OF_STATE - Remember this information in an 1927 appropriate data area. 1929 o OPTION_F_PARTNER_DOWN_TIME - Remember this information in an 1930 appropriate data area if the value of the OPTION_F_SERVER_STATE is 1931 PARTNER-DOWN. 1933 A server receiving a STATE message SHOULD ensure that this 1934 information is written to stable storage. 1936 6.5. Connection Maintenance Parameters 1938 The following parameters and timers are used to ensure the integrity 1939 of the connections between two failover servers. 1941 Parameter Default Description 1942 ------------------------------------------ 1943 FO_KEEPALIVE_TIMER timer counts down to time connection 1944 assumed dead due to lack of messages 1946 FO_KEEPALIVE_TIME 60 maximum time server will consider 1947 connection still up with no messages 1949 FO_CONTACT_PER_KEEPALIVE_TIME number of CONTACT messages to send 1950 4 during partner's FO_KEEPALIVE_TIME 1951 period 1953 FO_SEND_TIMER timer counts down to time to send next 1954 CONTACT message 1956 FO_SEND_TIME 15 maximum time to wait between sending 1957 CONTACT messages if no other traffic 1958 Created from partner's FO_KEEPALIVE_TIME 1959 divided by FO_CONTACT_PER_KEEPALIVE_TIME 1961 6.6. Unreachability detection 1963 Each partner MUST maintain an FO_SEND_TIMER for each failover 1964 connection. The FO_SEND_TIMER for a particular connection is reset 1965 to FO_SEND_TIME every time any message is transmitted on that 1966 connection, and counts down once per second. If the timer reaches 1967 zero, a CONTACT message is transmitted on that connection and the 1968 timer for that connection is reset to FO_SEND_TIME. The CONTACT 1969 message may be transmitted at any time. An implementation MAY use 1970 additional mechanisms to detect partner unreachability. 1972 The FO_SEND_TIME is initialized from the configured FO_KEEPALIVE_TIME 1973 divided by FO_CONTACT_PER_KEEPALIVE_TIME. When a CONNECT or 1974 CONNECTREPLY message is received on a connection, the received 1975 OPTION_F_KEEPALIVE_TIME option is checked, and the value in that 1976 option is used to calculate the FO_SEND_TIME for that connection by 1977 dividing the value received by the configured 1978 FO_CONTACT_PER_KEEPALIVE_TIME. 1980 Each partner MUST maintain an FO_KEEPALIVE_TIMER for each failover 1981 connection. This timer is initialized to FO_KEEPALIVE_TIME and 1982 counts down once per second. It is reset to FO_KEEPALIVE_TIME 1983 whenever a message is received on that connection. If it ever 1984 reaches zero, that connection is considered dead. In addition, the 1985 FO_KEEPALIVE_TIME for that connection MUST be sent to the failover 1986 partner on every CONNECT or CONNECTREPLY messages, in the 1987 OPTION_F_KEEPALIVE_TIME option. 1989 7. Binding Updates and Acks 1991 7.1. Time Skew 1993 Partners exchange information about known lease states. To reliably 1994 compare a known lease state with an update received from a partner, 1995 servers must be able to reliably compare the times stored in the 1996 known lease state with the times received in the update. The 1997 failover protocol adopts the simple approach of requiring that the 1998 failover partners use some mechanism to synchronize the clocks on the 1999 two servers to within an accuracy of roughly 5 seconds. 2001 A mechanism to measure and track relative time differences between 2002 servers is necessary to ensure this synchronization. To do so, each 2003 message contains the time of the transmission in the time context of 2004 the transmitter in the sent-time field of the message (see 2005 Section 5.2). The transmitting server MUST set this as close to the 2006 actual transmission as possible. The receiving partner MUST store 2007 its own timestamp of reception as close to the actual reception as 2008 possible. The received timestamp information is then compared with 2009 local timestamp. 2011 7.2. Information model 2013 In most DHCP servers a lease on an IPv6 address or a prefix can take 2014 on several different binding-status values, sometimes also called 2015 lease states. While no two DHCP server implementations will have 2016 exactly the same possible binding-status values, [RFC3315] enforces 2017 some commonality among the general semantics of the binding-status 2018 values used by various DHCP server implementations. 2020 In order to transmit binding database updates between one server and 2021 another using the failover protocol, some common binding-status 2022 values must be defined. It is not expected that these values 2023 correspond with any actual implementation of the DHCPv6 protocol in a 2024 DHCP server, but rather that the binding-status values defined in 2025 this document should be convertible back and forth between those 2026 defined below and those in use by many DHCP server implementations. 2028 The lease binding-status values defined for the failover protocol are 2029 listed below. Unless otherwise noted below, there MAY be client 2030 information associated with each of these binding-status value. 2032 ACTIVE -- The lease is assigned to a client. Client identification 2033 data MUST appear. 2035 EXPIRED -- indicates that a client's binding on a given lease has 2036 expired. When the partner acks the BNDUPD of an expired lease, 2037 the server sets its internal state to PENDING-FREE. Client 2038 identification SHOULD appear. 2040 RELEASED -- indicates that a client sent a RELEASE message. When 2041 the partner acks the BNDUPD of a released lease, the server sets 2042 its internal state to PENDING-FREE. Client identification SHOULD 2043 appear. 2045 PENDING-FREE -- Once a lease is expired or released, its state 2046 becomes PENDING-FREE. Depending on which algorithm and which pool 2047 was used to allocate a given lease, PENDING-FREE may either mean 2048 FREE or FREE-BACKUP. Implementations do not have to implement 2049 this PENDING-FREE state, but may choose to switch to the 2050 destination state directly. For clarity of representation, this 2051 transitional PENDING-FREE state is treated as a separate state. 2053 FREE -- Is used when a DHCP server needs to communicate that a lease 2054 is unused by any client, but it was not just released, expired or 2055 reset by a network administrator. When the partner acks the 2056 BNDUPD of a FREE lease, the server marks the lease as available 2057 for assignment by the primary server. Note that on a secondary 2058 server running in PARTNER-DOWN state, after waiting the MCLT, the 2059 lease MAY be allocated to a client by the secondary server. 2060 Client identification MAY appear and indicates the last client to 2061 have used this lease as a hint. 2063 FREE-BACKUP -- indicates that this lease can be allocated by the 2064 secondary server to a client at any time. Note that on the 2065 primary server running in PARTNER-DOWN state, after waiting the 2066 MCLT, the lease MAY be allocated to a client by the primary server 2067 if proportional algorithm was used. Client identification MAY 2068 appear and indicates the last client to have used this lease as a 2069 hint. 2071 ABANDONED -- indicates that a lease is considered unusable by the 2072 DHCP system. The primary reason for entering such state is 2073 reception of DECLINE message for the lease. Client identification 2074 MAY appear. 2076 RESET -- indicates that this lease was made available by operator 2077 command. This is a distinct state so that the reason that the 2078 lease became FREE can be determined. Client identification MAY 2079 appear. 2081 Which binding-status values are associated with a timeout is 2082 implementation dependent. Some binding-status values such as ACTIVE 2083 will have a timeout value in all implementations, while others such 2084 as ABANDONDED will have a timeout value in some implementations and 2085 not in others. In some implementations a binding-status value may be 2086 associated with a timeout in some circumstances and not in other 2087 circumstances. The receipt of a BNDUPD with a particular binding- 2088 status value and an OPTION_F_STATE_EXPIRATION_TIME indicates that 2089 this particular binding-status value is associated with a timeout. 2091 The lease state machine is presented in Figure 2. Most states are 2092 stationary, i.e. the lease stays in a given state until external 2093 event triggers transition to another state. The only transitive 2094 state is PENDING-FREE. Once it is reached, the state machine 2095 immediately transitions to either FREE or FREE-BACKUP state. 2097 +---------+ 2098 /------------->| ACTIVE |<--------------\ 2099 | +---------+ | 2100 | | | | | 2101 | /--(8)--/ (3) \--(9)-\ | 2102 | | | | | 2103 | V V V | 2104 | +-------+ +--------+ +---------+ | 2105 | |EXPIRED| |RELEASED| |ABANDONED| | 2106 | +-------+ +--------+ +---------+ | 2107 | | | | | 2108 | | | (10) | 2109 | | | V | 2110 | | | +---------+ | 2111 | | | | RESET | | 2112 | | | +---------+ | 2113 | | | | | 2114 | \--(4)--\ (4) /--(4)--/ | 2115 | | | | | 2116 (1) V V V (2) 2117 | /---------\ | 2118 | | PENDING | | 2119 | | FREE | | 2120 | \---------/ | 2121 | | | | 2122 | /-(5)--/ \-(6)-\ | 2123 | | | | 2124 | V V | 2125 | +-------+ +-----------+ | 2126 \----| FREE |<--(7)-->|FREE-BACKUP|-----/ 2127 +-------+ +-----------+ 2129 PENDING-FREE transition 2131 Figure 2: Lease State Machine 2133 Transitions between states are results of the following events: 2135 1. Primary server allocates a lease. 2137 2. Secondary server allocates a lease. 2139 3. Client sends RELEASE and the lease is released. 2141 4. Partner acknowledges state change. This transition MAY also 2142 occur if the server is in PARTNER-DOWN state and the MCLT has 2143 passed since the entry into RELEASED, EXPIRED, or RESET states. 2145 5. The lease belongs to a pool that is governed by the 2146 proportional allocation, or independent allocation is used and 2147 this lease belongs to primary server pool. 2149 6. The lease belongs to a pool that is governed by the 2150 independent allocation and the lease belongs to the secondary 2151 server. 2153 7. Pool rebalance event occurs (POOLREQ/POOLRESP messages are 2154 exchanged). Delegable prefixes belonging to the primary server 2155 can be assigned to the secondary server pool (transition from FREE 2156 to FREE-BACKUP) or vice versa. 2158 8. The lease has expired. 2160 9. DECLINE message is received or a lease is deemed unusable for 2161 other reasons. 2163 10. An administrative action is taken to recover an abandoned 2164 lease back to usable state. This transition MAY occur due to an 2165 implementation specific handling on ABANDONED lease. One possible 2166 example of such use is a Neighbor Discovery or ICMPv6 Echo check 2167 if the address is still in use. 2169 The lease that is no longer in use (due to expiration or release), 2170 becomes PENDING-FREE. Depending on what allocation algorithm is 2171 used, the lease that is no longer is use, returns to the primary 2172 (FREE) or secondary pool (FREE-BACKUP). The conditions for specific 2173 transitions are depicted in Figure 3. 2175 +----------------+---------+-----------+ 2176 | \ Lease owner| | | 2177 | \----------\ | Primary | Secondary | 2178 |Algorithm \ | | | 2179 +----------------+---------+-----------+ 2180 | Proportional | FREE |FREE-BACKUP| 2181 | Independent | FREE | FREE | 2182 +----------------+---------+-----------+ 2184 Figure 3: PENDING-FREE State Transitions 2186 7.3. Times Required for Exchanging Binding Updates 2188 Each server must keep track of the following specific times beyond 2189 those required by the base DHCP protocol [RFC3315]. 2191 expiration-time 2192 The greatest lifetime that this server has ever acked to its 2193 failover partner in a BNDREPLY. 2195 acked-partner-lifetime 2196 The greatest lifetime that the failover partner has ever acked to 2197 this server in a BNDREPLY. 2199 partner-lifetime 2200 The time that we will send (or have sent) the partner, which will 2201 be the time after which the partner can consider the lease 2202 expired. When we receive a BNDUPD this value can be updated from 2203 the received OPTION_F_EXPIRATION_TIME. 2205 client-last-transaction-time 2206 The time when this server most recently interacted with the client 2207 associated with this lease. 2209 partner-raw-clt-time 2210 The time when the partner most recently interacted with the client 2211 associated with this lease. This time remains exactly as it was 2212 received by this server, and MUST NOT be adjusted to be in the 2213 time context of this server. 2215 start-time-of-state 2216 The time when the binding-status of this lease was changed to its 2217 current value. 2219 state-expiration-time 2220 The time when the current state of this lease will expire. 2222 7.4. Sending Binding Updates 2224 Every BNDUPD message contains information about either a single 2225 client binding in an OPTION_CLIENT_DATA option that include IAADDR or 2226 IAPREFIX options associated with that client, or a single prefix 2227 lease in an OPTION_IAPREFIX option for prefixes that are currently 2228 not associated with any clients. 2230 All information about a particular client binding MUST be contained 2231 in a single OPTION_CLIENT_DATA option (see Section 4.1.2.2 of 2232 [RFC5007]). The OPTION_CLIENT_DATA option contains at least the data 2233 shown below in its client-options section: 2235 o OPTION_CLIENTID containing the DUID of the client most recently 2236 associated with this lease MUST appear; 2238 o OPTION_LQ_BASE_TIME containing the absolute time that the 2239 information was placed into this OPTION_CLIENT_DATA option (see 2240 Section 6.3.1 of [RFC7653]) MUST appear; 2242 o OPTION_VSS (see Section 3.4 of [RFC6607]) This option MUST NOT 2243 appear if the information in this OPTION_CLIENT_DATA option is 2244 associated with the global, default VPN. This option MUST appear 2245 if the information in this OPTION_CLIENT_DATA option is associated 2246 with a VPN other than the global, default VPN. Support of 2247 [RFC6607] is not required, and OPTION_VSS is only used if a VPN 2248 other than the global, default VPN is used, which requires support 2249 of [RFC6607]; 2251 o OPTION_F_RECONFIGURE_DATA containing the time and reconfigure key, 2252 if any; 2254 o OPTION_LQ_RELAY_DATA containing information described in 2255 Section 4.1.2.4 of [RFC5007], if any exists; 2257 o OPTION_IA_NA or OPTION_IA_TA for an IPv6 Address or OPTION_IA_PD 2258 for an IPv6 Prefix. More than one of either of these options MAY 2259 appear if there are more than one associated with this client. At 2260 least one MUST appear; 2262 * IAID - Identity Association used by the client, while obtaining 2263 a given lease. (Note1: one client may use many IAIDs 2264 simultaneously. Note2: IAID for IA, TA and PD are orthogonal 2265 number spaces.); 2267 * T1 time sent to client; 2269 * T2 time sent to client; 2271 * Inside of the IA_NA-options, IA_TA-options, or IA_PD-option 2272 sections: 2274 + OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for 2275 a IPv6 prefix MUST appear; 2277 - IPv6 Address or IPv6 Prefix (with length); 2279 - preferred lifetime sent to client; 2281 - valid lifetime sent to client; 2283 - Inside of the IAaddr-options or IAprefix-options: 2285 o OPTION_F_BINDING_STATUS containing the binding-status 2286 MUST appear; 2288 o OPTION_F_START_TIME_OF_STATE containing the start- 2289 time-of-state MUST appear; 2291 o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing 2292 the state-expiration-time*; 2294 o OPTION_CLT_TIME (relative) containing the client-last- 2295 transaction-time. See [RFC5007] for this option; 2297 o OPTION_F_PARTNER_LIFETIME (absolute) containing 2298 partner-lifetime*; 2300 o OPTION_F_PARTNER_RAW_CLT_TIME (absolute) containing 2301 the partner-raw-clt-time; 2303 o OPTION_F_EXPIRATION_TIME (absolute) containing the 2304 expiration-time*; 2306 o DHCP_O_CLIENT_FQDN containing the FQDN information 2307 associated with this lease and client, if any; 2309 Information about a prefix lease is contained in a single 2310 OPTION_IAPREFIX option. Only a single OPTION_IAPREFIX option may 2311 appear in a BNDUPD message outside of an OPTION_CLIENT_DATA option. 2312 In detail: 2314 o OPTION_IAPREFIX for a prefix lease; 2316 * IPv6 Prefix (with length); 2318 * Inside of the IAprefix-options section: 2320 + OPTION_VSS (see Section 3.4 of [RFC6607]) This option MUST 2321 NOT appear if the information in this OPTION_IAPREFIX option 2322 is associated with the global, default VPN. This option 2323 MUST appear if the information in this OPTION_IAPREFIX 2324 option is associated with a VPN other than the global, 2325 default VPN. Support of [RFC6607] is not required, and 2326 OPTION_VSS is only used if a VPN other than the global, 2327 default VPN is used, which requires support of [RFC6607]; 2329 + OPTION_LQ_BASE_TIME containing the absolute time that this 2330 information was placed into this OPTIONS_IAPREFIX option 2331 (see Section 6.3.1 of [RFC7653]) MUST appear; 2333 + OPTION_F_BINDING_STATUS containing the binding-status MUST 2334 appear; 2336 + OPTION_F_START_TIME_OF_STATE containing the start-time-of- 2337 state MUST appear; 2339 + OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the 2340 state-expiration-time*; 2342 + OPTION_F_PARTNER_LIFETIME (absolute) containing partner- 2343 lifetime*; 2345 + OPTION_F_EXPIRATION_TIME (absolute) containing the 2346 expiration-time*; 2348 Items marked with a single asterisk (*) MUST appear only if the value 2349 in the OPTION_F_BINDING_STATUS is associated with a timeout, 2350 otherwise it MUST NOT appear. See Section 7.2 for details. 2352 The OPTION_CLT_TIME MUST, if it appears, be the time that the server 2353 last interacted with the DHCP client. It MUST NOT be, for instance, 2354 the time that the lease expired if there has been no interaction with 2355 the DHCP client in question. 2357 A server SHOULD be prepared to clean up DNS information once the 2358 lease expires or is released. See Section 9 for a detailed 2359 discussion about DNS update. Another reason the partner may be 2360 interested in keeping additional data is to enable better support for 2361 Leasequery [RFC5007], Bulk Leasequery [RFC5460] or Active Leasequery 2362 [RFC7653], some of which feature queries based on Relay-ID, by link 2363 address and by Remote-ID. 2365 7.5. Receiving Binding Updates 2367 7.5.1. Monitoring Time Skew 2369 The sent-time from the Failover message is compared with the current 2370 time of the receiving server as recorded when it received the 2371 message. The difference is noted, and if it is greater than 5 2372 seconds the receiving server SHOULD drop the connection. A message 2373 SHOULD be logged to signal the reason for the connection being 2374 dropped. 2376 Any time can be before, after, or essentially the same as another 2377 time. Any time which ends up being +/- 5 seconds of another time 2378 SHOULD be considered to be representing the same time when performing 2379 a comparison between two times. 2381 7.5.2. Acknowledging Reception 2383 Upon acceptance of a binding update, the server MUST notify its 2384 partner that it has processed the binding update (and updated its 2385 lease state database if necessary) by sending a BNDREPLY. A server 2386 MUST NOT send the BNDREPLY before its binding database is updated. 2388 7.5.3. Processing Binding Updates 2390 When a BNDUPD is received it MUST contain either a single 2391 OPTION_CLIENT_DATA option or a single OPTION_IAPREFIX option. 2393 When analyzing an BNDUPD message option from a partner server, if 2394 there is insufficient information in the BNDUPD message to process 2395 it, then it is rejected with an OPTION_STATUS_CODE of 2396 "MissingBindingInformation". 2398 The server receiving a BNDUPD update from its partner must evaluate 2399 the received information in each OPTION_CLIENT_DATA or IAPREFIX 2400 option to see if it is consistent with the server's already known 2401 state, and if it is not, decide to accept or reject the information. 2402 Section 7.5.4 provides the details how the server makes this 2403 determination. 2405 A server receiving a BNDUPD message MUST respond to the sender of 2406 that message with a BNDREPLY message which contains the same 2407 transaction-id as the BNDUPD message. This BNDREPLY message MUST 2408 contain either a single OPTION_CLIENT_DATA option or a single 2409 OPTION_IAPREFIX option, corresponding to whatever was received in the 2410 BNDUPD message. 2412 An OPTION_CLIENT_DATA option or an OPTION_IAPREFIX option in the 2413 BNDREPLY which is accepted SHOULD NOT contain an OPTION_STATUS_CODE 2414 unless a status message needs to be sent to the failover partner, in 2415 which case it SHOULD include an OPTION_STATUS_CODE option with a 2416 status code indicating success and whatever message is needed. 2418 To indicate rejection of the information in an OPTION_CLIENT_DATA 2419 option, or an OPTION_IAPREFIX option, an OPTION_STATUS_CODE SHOULD be 2420 included with a status code indicating an error in the 2421 OPTION_CLIENT_DATA option or OPTION_IAPREFIX option in the BNDREPLY 2422 message. 2424 7.5.4. Accept or Reject? 2426 The first task in processing the information in an OPTION_CLIENT_DATA 2427 option or OPTION_IAPREFIX option is extract the client information 2428 (if any) and lease information out of the option, and to access the 2429 address lease or prefix lease information in the server's binding 2430 database. 2432 If an OPTION_VSS option is specified in the OPTION_CLIENT_DATA option 2433 or OPTION_IAPREFIX option, if the VPN specified in the OPTION_VSS 2434 option does not appear in the configuration of the receiving server, 2435 reject the entire OPTION_CLIENT_DATA option or OPTION_IAPREFIX option 2436 with the reject-reason "ConfigurationConflict". 2438 If the lease specified in the OPTION_CLIENT_DATA option or 2439 OPTION_IAPREFIX option is not a lease associated with the failover 2440 endpoint which received the OPTION_CLIENT_DATA option, then reject it 2441 with reject-reason "ConfigurationConflict". 2443 In general, acceptance or rejection is based around the comparison of 2444 two different time values, one from the OPTION_CLIENT_DATA option or 2445 OPTION_IAPREFIX option in the BNDUPD message, and one from the 2446 receiving server's binding database associated with the address or 2447 prefix lease found in the BNDUPD message. The time for the BNDUPD 2448 message where the OPTION_F_BINDING_STATUS is ACTIVE, EXPIRED, or 2449 RELEASED is the OPTION_CLT_TIME if one appears, and the 2450 OPTION_F_START_TIME_OF_STATE if one does not. For other binding- 2451 status values, the time for the BNDUPD message is the later of the 2452 OPTION_CLT_TIME if one appears, and the OPTION_F_START_TIME_OF_STATE. 2453 The time for the lease in the server's binding database is the 2454 client-last-transaction-time, if one appears, and the start-time-of- 2455 state if one does not. 2457 The basic approach is to compare these times, and if the one from the 2458 BNDUPD message is clearly later, then accept the information in the 2459 OPTION_CLIENT_DATA option or OPTION_IAPREFIX option. If the one from 2460 the server's binding database is clearly later, then reject the 2461 information in the BNDUPD message. The challenge comes when they are 2462 essentially the same (i.e., +/- 5 seconds). In this case they are 2463 considered identical, despite the minor differences. The table below 2464 (Figure 4) contains the rules for dealing with all of these 2465 situations. 2467 binding-status in received OPTION_CLIENT_DATA 2468 or OPTION_IAPREFIX 2469 binding-status in 2470 receiving server's FREE RESET 2471 lease state DB ACTIVE EXPIRED RELEASED FREE-BACKUP ABANDONED 2473 ACTIVE accept(3) time(1) accept time(1) accept 2474 EXPIRED accept accept accept accept accept 2475 RELEASED accept accept accept accept accept 2476 FREE/FREE-BACKUP accept accept accept accept accept 2477 RESET time(2) accept accept accept accept 2478 ABANDONED accept accept accept accept accept 2480 Figure 4: Conflict Resolution 2482 accept: If the time value in the OPTION_CLIENT_DATA option or 2483 OPTION_IAPREFIX option is later than the time value in the server's 2484 binding database, accept it, else reject it. 2486 time(1): If the current time is later than the receiving server's 2487 state-expiration-time, accept it, else reject it. 2489 time(2): If the OPTION_CLT_TIME value (if it appears) in the 2490 OPTION_CLIENT_DATA is later than the start-time-of-state in the 2491 receiving server's binding, accept it, else reject it. 2493 accept,time(1),time(2): If rejecting, use reject reason 2494 "OutdatedBindingInformation". 2496 accept(3): If the client in an OPTION_CLIENT_DATA option and in a 2497 receiving server's binding differ, then if time(2) or the receiving 2498 server is a secondary accept it, else reject it with a reject reason 2499 of "AddressInUse". If the clients match, accept the update. 2501 The lease update may be accepted or rejected. If a lease is rejected 2502 with "OutdatedBindingInformation", then the flag in the lease that 2503 indicates the partner should be updated about the information in this 2504 lease SHOULD be set, otherwise it SHOULD NOT be changed. If this 2505 flag was previously not set, then an update MAY be transmitted 2506 immediately to the partner (though the BNDREPLY to this BNDUPD SHOULD 2507 be sent first). If this flag was previously set an update SHOULD NOT 2508 be transmitted immediately to the partner. In this case, an update 2509 will be sent during the next periodic scan, but not immediately, thus 2510 preventing a possible update storm should the servers be unable to 2511 agree. Ultimately, the server with the most recent binding 2512 information should have its update accepted by its partner. 2514 7.5.5. Accepting Updates 2516 When the information in an OPTION_CLIENT_DATA option or 2517 OPTION_IAPREFIX option has been accepted, some of that information is 2518 stored in the receiving server's binding database, and corresponding 2519 a OPTION_CLIENT_DATA option or OPTION_IAPREFIX option is entered into 2520 a BNDREPLY. The information to enter into the OPTION_CLIENT_DATA 2521 option or OPTION_IAPREFIX option in the BNDREPLY is described in 2522 Section 7.6. 2524 The information contained in an accepted OPTION_CLIENT_DATA option is 2525 stored in the receiving server's binding database as follows: 2527 1. The OPTION_CLIENTID is used to find the client. 2529 2. The other data contained in the top level of the 2530 OPTION_CLIENT_DATA option is stored with the client as 2531 appropriate. 2533 3. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD 2534 option in the OPTION_CLIENT_DATA option and for each of the 2535 OPTION_IAADDR or OPTION_IAPREFIX options in the IA_* options: 2537 1. OPTION_F_BINDING_STATUS is stored as the binding-status 2539 2. OPTION_F_PARTNER_LIFETIME is stored in the expiration-time 2541 3. OPTION_F_STATE_EXPIRATION_TIME is stored in the state- 2542 expiration-time 2544 4. OPTION_F_CLT_TIME (which MUST NOT be converted with the 2545 corrected-base-time, but MUST be converted with the raw value 2546 from the OPTION_LQ_BASE_TIME) is stored in the partner-raw- 2547 clt-time 2549 5. OPTION_F_PARTNER_RAW_CLT_TIME (which MUST NOT be corrected 2550 with the time-correction) replaces the client-last- 2551 transaction-time if it is later than the current client-last- 2552 transaction-time. 2554 6. OPTION_F_EXPIRATION_TIME replaces the partner-lifetime if it 2555 is later than the current partner-lifetime. 2557 The information contained in an accepted top level OPTION_IAPREFIX 2558 option is stored in the receiving server's binding database as 2559 follows: 2561 1. The IPv6 Prefix is used to find the prefix. 2563 2. Inside of the IAprefix-options section: 2565 1. OPTION_F_BINDING_STATUS is stored as the binding-status 2567 2. OPTION_F_PARTNER_LIFETIME (if any) is stored in the 2568 expiration-time 2570 3. OPTION_F_STATE_EXPIRATION_TIME (if any) is stored in the 2571 state-expiration-time 2573 4. OPTION_F_EXPIRATION_TIME (if any) replaces the partner- 2574 lifetime if it is later than the current partner-lifetime. 2576 7.6. Sending Binding Replies 2578 A server MUST respond to every BNDUPD message with a BNDREPLY 2579 message. The BNDREPLY message MUST contain an OPTION_CLIENT_DATA 2580 option if the BNDUPD message contained an OPTION_CLIENT_DATA option, 2581 or it MUST contain an OPTION_IAPREFIX option if the BNDUPD message 2582 contained an OPTION_IAPREFIX option. The BNDREPLY message MUST have 2583 the same transaction-id as the BNDUPD message to which it is a 2584 response. 2586 Acceptance or rejection of all or a particular part of the BNDUPD 2587 message is signaled with a OPTION_STATUS_CODE option. An 2588 OPTION_STATUS_CODE option containing a status-code representing an 2589 error is significant, while an OPTION_STATUS_CODE option whose 2590 status-code contains success is considered informational but does not 2591 affect the processing of the BNDREPLY message when it is received by 2592 the server that sent the BNDUPD message. 2594 Rejection of all or part of the information in a BNDUPD message is 2595 signaled in a BNDREPLY message by use of the OPTION_STATUS_CODE 2596 message with an error in the status-code field. This rejection can 2597 take place at either of two levels -- the top level of the option 2598 hierarchy, or the bottom level of the option hierarchy: 2600 Entire BNDUPD: The OPTION_STATUS_CODE containing an error is 2601 present in the outermost option of the BNDREPLY -- either the 2602 single OPTION_CLIENT_DATA option or the single OPTION_IAPREFIX 2603 option. An example of this sort of error might be that a VSS 2604 option was present and specified a VPN that might not exist in the 2605 receiving server. 2607 Single address or prefix: The OPTION_STATUS_CODE containing an 2608 error is present in a single IAADDR or IAPREFIX option which is 2609 itself contained in an OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD 2610 option. An example of this sort of error might be that a 2611 particular IPv6 address was specified in an IAADDR option that 2612 doesn't appear in the receiving server's configuration. 2614 Rejection present at either of these levels indicates rejection of 2615 all of the information contained in the option (including any other 2616 options contained in that option) where the OPTION_STATUS_CODE option 2617 containing an error appears. The converse is not true -- an 2618 OPTION_STATUS_CODE option containing success does not signify that 2619 all of the contained information has been accepted. 2621 If the BNDREPLY message contains an OPTION_CLIENT_DATA option, then 2622 the OPTION_CLIENT_DATA option MUST contain at least the data shown 2623 below in its client-options section: 2625 o OPTION_CLIENTID containing the DUID of the client most recently 2626 associated with this IPv6 address*; 2628 o OPTION_VSS from the BNDUPD, if any. 2630 o OPTION_IA_NA or OPTION_IA_TA for an IPv6 Address or OPTION_IA_PD 2631 for an IPv6 Prefix. More than one of either of these options MAY 2632 appear if there are more than one associated with this client; 2634 * Inside of the IA_NA-options, IA_TA-options, or IA_PD-option 2635 sections: 2637 + OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for 2638 a IPv6 prefix; 2640 - IPv6 Address or IPv6 Prefix (with length); 2642 - Inside of the IAaddr-options or IAprefix-options: 2644 o OPTION_STATUS_CODE containing an error code, or 2645 containing a success code if a message is required. 2646 An OPTION_STATUS_CODE option SHOULD NOT appear with a 2647 success code unless a message associated with the 2648 success code needs to be included. The lack of an 2649 OPTION_STATUS_CODE option is an indication of success. 2651 o OPTION_F_BINDING_STATUS containing the binding-status 2652 received in the BNDUPD; 2654 o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing 2655 the state-expiration-time received in the BNDUPD; 2657 o OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a 2658 duplicate of the OPTION_F_PARTNER_LIFETIME received in 2659 the BNDUPD; 2661 If the BNDREPLY message contains a top level OPTION_IAPREFIX option, 2662 then the OPTION_IAPREFIX option MUST contain at least the data shown 2663 below: 2665 o IPv6 Prefix (with length); 2667 o IAprefix-options: 2669 * OPTION_VSS from the BNDUPD, if any. 2671 * OPTION_STATUS_CODE containing an error code, or containing a 2672 success code if a message is required. If the information in 2673 the corresponding OPTION_IAPREFIX in the BNDUPD was accepted, 2674 and no status message was required (which is the usual case), 2675 no OPTION_STATUS_CODE option appears. 2677 * OPTION_F_BINDING_STATUS containing the binding-status received 2678 in the BNDREPLY; 2680 * OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state- 2681 expiration-time received in the BNDREPLY; 2683 * OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a 2684 duplicate of the OPTION_F_PARTNER_LIFETIME received in the 2685 BNDREPLY; 2687 7.7. Receiving Binding Acks 2689 When a BNDREPLY is received the overall OPTION_CLIENT_DATA option or 2690 the overall OPTION_IAPREFIX option may contain an OPTION_STATUS_CODE 2691 containing an error, representing a rejection of the entire BNDUPD. 2692 An enclosed OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD option may 2693 also contain an OPTION_STATUS_CODE containing an error which 2694 indicates that everything in containing option has been rejected. Or 2695 an individual IAADDR or IAPREFIX option may contain an 2696 OPTION_STATUS_CODE option containing an error, indicating that the 2697 IAADDR or IAPREFIX option has been rejected. An OPTION_STATUS_CODE 2698 containing a success code has no bearing on the acceptance status of 2699 the BNDREPLY at any level. 2701 Receipt of a rejection (or a part of a BNDREPLY that has been 2702 rejected) requires no processing other than remembering that it has 2703 been encountered. 2705 The information contained in the BNDREPLY in an OPTION_CLIENT_DATA 2706 that represents an acceptance is stored with the appropriate client 2707 and lease, as follows: 2709 1. The OPTION_CLIENTID is used to find the client. 2711 2. For each of the OPTION_IA_NA, OPTION_IA_TA, or OPTION_IA_PD 2712 option in the OPTION_CLIENT_DATA option and for each of the 2713 OPTION_IAADDR or OPTION_IAPREFIX options they contain: 2715 1. OPTION_F_PARTNER_LIFETIME_SENT is stored in the acked- 2716 partner-lifetime 2718 2. The time partner-lifetime is set to 0, to indicate that 2719 nothing additional needs to be sent to the partner. 2721 Alternatively, the BNDREPLY may contain a top level OPTION_IAPREFIX 2722 option, representing information concerning a single prefix lease. 2723 If the IAprefix-options section of the OPTION_IAPREFIX option 2724 contains an OPTION_STATUS_CODE representing an error, then it is 2725 considered a rejection of the corresponding BNDUPD message. If the 2726 OPTION_IAPREFIX option does not contain an OPTION_STATUS_CODE option 2727 or if the OPTION_STATUS_CODE option contains a success status, then 2728 the three items in the following list are stored in the lease state 2729 database, in the section associated with the prefix lease represented 2730 by the OPTION_IAPREFIX option. 2732 1. OPTION_F_BINDING_STATUS containing the binding-status received in 2733 the BNDREPLY; 2735 2. OPTION_F_STATE_EXPIRATION_TIME (absolute) containing the state- 2736 expiration-time received in the BNDREPLY; 2738 3. OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a duplicate 2739 of the OPTION_F_PARTNER_LIFETIME received in the BNDREPLY; 2741 7.8. BNDUPD/BNDREPLY Data Flow 2743 The following diagram shows the relationship of the times described 2744 in Section 7.3 with the options used to transmit them. It also 2745 relates the times on one failover partner to the other failover 2746 partner. 2748 ----------------------- BNDUPD ------------------------------ 2750 Source on OPTION_F in Storage on 2751 Sending Server -> BNDUPD message -> Receiving Server 2753 [ always update ] 2755 partner-lifetime PARTNER_LIFETIME expiration-time 2757 client-last-transaction-time CLT_TIME (uncorrected) 2758 partner-raw-clt-time 2759 start-time-of-state START_TIME_OF_STATE start-time-of-state 2760 state-expiration-time STATE_EXPIRATION_TIME state-expiration-time 2762 [update only if received > current] 2764 expiration-time EXPIRATION_TIME partner-lifetime 2765 partner-raw-clt-time PARTNER_RAW_CLT_TIME 2766 client-last-transaction-time 2768 ----------------------- BNDREPLY ------------------------------ 2770 Storage on OPTION_F in Storage on 2771 Receiving Server <- BNDUPD message <- Sending Server 2773 [ always update ] 2775 acked-partner-lifetime PARTNER_LIFETIME_SENT duplicate of received 2776 PARTNER_LIFETIME 2777 (nothing to update) STATE_EXPIRATION_TIME state-expiration-time 2779 ------------------------------------------------------------- 2781 Figure 5: BNDUPD and BNDREPLY Time Handling 2783 8. Endpoint States 2785 8.1. State Machine Operation 2787 Each server (or, more accurately, failover endpoint) can take on a 2788 variety of failover states. These states play a crucial role in 2789 determining the actions that a server will perform when processing a 2790 request from a DHCP client as well as dealing with changing external 2791 conditions (e.g., loss of connection to a failover partner). 2793 The failover state in which a server is running controls the 2794 following behaviors: 2796 o Responsiveness -- the server is either responsive to DHCP client 2797 requests, it is renew responsive, or it is unresponsive. 2799 o Allocation Pool -- which pool of addresses (or prefixes) can be 2800 used for advertisement on receipt of a SOLICIT or allocation on 2801 receipt of a REQUEST, RENEW or REBIND message. 2803 o MCLT -- ensure that valid lifetimes are not beyond what the 2804 partner has acked plus the MCLT (or not). 2806 A server will transition from one failover state to another based on 2807 the specific values held by the following state variables: 2809 o Current failover state. 2811 o Communications status (OK or not OK). 2813 o Partner's failover state (if known). 2815 Whenever any of the above state variables change state, the state 2816 machine is invoked, which may then trigger a change in the current 2817 failover state. Thus, whenever the communications status changes, 2818 the state machine processing is invoked. This may or may not result 2819 in a change in the current failover state. 2821 Whenever a server transitions to a new failover state, the new state 2822 MUST be communicated to its failover partner in a STATE message if 2823 the communications status is OK. In addition, whenever a server 2824 makes a transition into a new state, it MUST record the new state, 2825 its current understanding of its partner's state, and the time at 2826 which it entered the new state in stable storage. 2828 The following state transition diagram gives a condensed view of the 2829 state machine. If there is a difference between the words describing 2830 a particular state and the diagram below, the words should be 2831 considered authoritative. 2833 In the diagram below, the word (responsive) (r-responsive) or 2834 (unresponsive) appears in the states, and refers to whether the 2835 server in this state is allowed to responsive, renew responsive, or 2836 unresponsive respectively. 2838 In the state transition diagram below, the "+", "-", or "*" in the 2839 upper right corner of each state is a notation about whether 2840 communication is ongoing with the other server, with "+" meaning that 2841 communications are ok, "-" meaning communications are interrupted, 2842 and "*" meaning that communications may be ok or interrupted. 2844 +---------------+ V +--------------+ 2845 | RECOVER * | | | STARTUP - | 2846 |(unresponsive) | +->+(unresponsive)| 2847 +------+--------+ +--------------+ 2848 +-Comm. OK +-----------------+ 2849 | Other State: | PARTNER DOWN - +<---------------------+ 2850 | RESOLUTION-INTER. | (responsive) | ^ 2851 All POTENTIAL- +----+------------+ | 2852 Others CONFLICT------------ | --------+ | 2853 | CONFLICT-DONE Comm. OK | +--------------+ | 2854 UPDREQ or Other State: | +--+ RESOLUTION - | | 2855 UPDREQALL | | | | | INTERRUPTED | | 2856 Rcv UPDDONE RECOVER All | | | (responsive) | | 2857 | +---------------+ | Others | | +------+-----+-+ | 2858 +->+RECOVER-WAIT * | RECOVER | | | ^ | | 2859 |(unresponsive) | WAIT or | | Comm. | Ext. | 2860 +-----------+---+ DONE | | OK Comm. Cmd---->+ 2861 Comm.---+ Wait MCLT | V V V Failed | 2862 Changed | V +---+ +---+-----+--+-+ | | 2863 | +---+----------++ | | POTENTIAL + +-------+ | 2864 | |RECOVER-DONE * | Wait | CONFLICT +------+ | 2865 +->+(unresponsive) | for |(unresponsive)| Primary | 2866 +------+--------+ Other +>+----+--------++ resolve Comm. | 2867 Comm. OK State: | | ^ conflict Changed| 2868 +---Other State:-+ RECOVER | Secondary | V V | | 2869 | | | DONE | resolve | +----+-------+--++ | 2870 | All Others: POTENT. | | conflict | |CONFLICT-DONE * | 2871 | Wait for CONFLICT--|-----+ | | | (responsive) | | 2872 | Other State: V V | +-------+--------+ | 2873 | NORMAL or RECOVER ++------------+---+ | Other State: NORMAL | 2874 | | DONE | NORMAL + +<--------------+ | 2875 | +--+----------+-->+ pri: responsive +-------External Command-->+ 2876 | ^ ^ |sec: r-responsive| | 2877 | | | +--------+--------+ | 2878 | | | | | | 2879 | Wait for Comm. OK Comm. Failed | External 2880 | Other Other | | Command 2881 | State: State: Start Auto | or 2882 | RECOVER-DONE NORMAL Partner Down Comm. OK Auto 2883 | | COMM. INT. Timer Other State: Partner 2884 | Comm. OK. | V All Others Down 2885 | Other State: | +---------+--------+ | expiration 2886 | RECOVER +--+ COMMUNICATIONS - +----+ | 2887 | +-------------+ INTERRUPTED | | 2888 RECOVER | (responsive) +------------------------->+ 2889 RECOVER-WAIT--------->+------------------+ 2891 Figure 6: Failover Endpoint State Machine 2893 8.2. State Machine Initialization 2895 The state machine is characterized by storage (in stable storage) of 2896 at least the following information: 2898 o Current failover state. 2900 o Previous failover state. 2902 o Start time of current failover state. 2904 o Partner's failover state. 2906 o Start time of partner's failover state. 2908 o Time most recent message received from partner. 2910 The state machine is initialized by reading these data items from 2911 stable storage and restoring their values from the information saved. 2912 If there is no information in stable storage concerning these items, 2913 then they should be initialized as follows: 2915 o Current failover state: Primary: PARTNER-DOWN, Secondary: RECOVER 2917 o Previous failover state: None. 2919 o Start time of current failover state: Current time. 2921 o Partner's failover state: None until reception of STATE message. 2923 o Start time of partner's failover state: None until reception of 2924 STATE message. 2926 o Time most recent message received from partner: None until message 2927 received. 2929 8.3. STARTUP State 2931 The STARTUP state affords an opportunity for a server to probe its 2932 partner server, before starting to service DHCP clients. When in the 2933 STARTUP state, a server attempts to learn its partner's state and 2934 determine (using that information if it is available) what state it 2935 should enter. 2937 The STARTUP state is not shown with any specific state transitions in 2938 the state machine diagram (Figure 6) because the processing during 2939 the STARTUP state can cause the server to transition to any of the 2940 other states, so that specific state transition arcs would only 2941 obscure other information. 2943 8.3.1. Operation in STARTUP State 2945 The server MUST NOT be responsive to DHCP clients in STARTUP state. 2947 Whenever a STATE message is sent to the partner while in STARTUP 2948 state the STARTUP flag MUST be set in the message and the previously 2949 recorded failover state MUST be placed in the server-state option. 2951 8.3.2. Transition Out of STARTUP State 2953 The following algorithm is followed every time the server initializes 2954 itself, and enters STARTUP state. 2956 The variables PREVIOUS-STATE and CURRENT-STATE are defined for use in 2957 the algorithm description below. PREVIOUS-STATE is simply for 2958 storage of a state, while CURRENT-STATE not only stores the current 2959 state but also changes the current state of the failover endpoint to 2960 whatever state is set into the CURRENT-STATE. 2962 Step 1: 2964 If there is any record in stable storage of a previous failover state 2965 for this server, set PREVIOUS-STATE to the last recorded value in 2966 stable storage, and go to Step 2. 2968 If there is no record of any previous failover state in stable 2969 storage for this server, then set the PREVIOUS-STATE to RECOVER and 2970 set the TIME-OF-FAILURE to 0. This will allow two servers which 2971 already have lease information to synchronize themselves prior to 2972 operating. 2974 In some cases, an existing server will be commissioned as a failover 2975 server and brought back into operation where its partner is not yet 2976 available. In this case, the newly commissioned failover server will 2977 not operate until its partner comes online -- but it has operational 2978 responsibilities as a DHCP server nonetheless. To properly handle 2979 this situation, a server SHOULD be configurable in such a way as to 2980 move directly into PARTNER-DOWN state after the startup period 2981 expires if it has been unable to contact its partner during the 2982 startup period. 2984 Step 2: 2986 Implementations will differ in the ways that they deal with the state 2987 machine for failover endpoint states. In many cases, state 2988 transitions will occur when communications goes from "OK" to failed, 2989 or from failed to "OK", and some implementations will implement a 2990 portion of their state machine processing based on these changes. 2992 In these cases, during startup, if the PREVIOUS-STATE is one where 2993 communications was "OK", then set the PREVIOUS-STATE to the state 2994 that is the result of the communications failed state transition when 2995 in that state (if such transition exists -- some states don't have a 2996 communication failed state transition, since they allow both 2997 communications OK and failed). 2999 Step 3: 3001 Start the STARTUP state timer. The time that a server remains in the 3002 STARTUP state (absent any communications with its partner) is 3003 implementation dependent but SHOULD be short. It SHOULD be long 3004 enough for a TCP connection to be created to a heavily loaded partner 3005 across a slow network. 3007 Step 4: 3009 If the server is a primary server: attempt to create a TCP connection 3010 to the failover partner. If the server is a secondary server, listen 3011 on the failover port and wait for the primary server to connect. See 3012 Section 6.1. 3014 Step 5: 3016 Wait for "communications OK". 3018 When and if communications become "OK", clear the STARTUP flag, and 3019 set the CURRENT-STATE to the PREVIOUS-STATE. 3021 If the partner is in PARTNER-DOWN state, and if the time at which it 3022 entered PARTNER-DOWN state (as received in the start-time-of-state 3023 option in the STATE message) is later than the last recorded time of 3024 operation of this server, then set CURRENT-STATE to RECOVER. If the 3025 time at which it entered PARTNER-DOWN state is earlier than the last 3026 recorded time of operation of this server, then set CURRENT-STATE to 3027 POTENTIAL-CONFLICT. 3029 Then, transition to the CURRENT-STATE and take the "communications 3030 OK" state transition based on the CURRENT-STATE of this server and 3031 the partner. 3033 Step 6: 3035 If the startup time expires prior to communications becoming "OK", 3036 the server SHOULD transition to the PREVIOUS-STATE. 3038 8.4. PARTNER-DOWN State 3040 PARTNER-DOWN state is a state either server can enter. When in this 3041 state, the server assumes that it is the only server operating and 3042 serving the client base. If one server is in PARTNER-DOWN state, the 3043 other server MUST NOT be operating. 3045 A server can enter PARTNER-DOWN state either as a result of operator 3046 intervention (when an operator determines that the server's partner 3047 is, indeed, down), or as a result of an optional auto-partner-down 3048 capability where PARTNER-DOWN state is entered automatically after a 3049 server has been in COMMUNICATIONS-INTERRUPTED state for a pre- 3050 determined period of time. 3052 8.4.1. Operation in PARTNER-DOWN State 3054 The server MUST be responsive in PARTNER-DOWN state, regardless if it 3055 is primary or secondary. 3057 It will allow renewal of all outstanding leases. 3059 For delegable prefixes it will allocate leases from its own pool, and 3060 after a fixed period of time (the MCLT interval) has elapsed from 3061 entry into PARTNER-DOWN state, it may allocate delegable prefixes 3062 from the set of all available pools. Server MUST fully deplete its 3063 own pool, before starting allocations from its downed partner's pool. 3065 IPv6 addresses available for independent allocation by the other 3066 server (at entry to PARTNER-DOWN state) SHOULD NOT be allocated to a 3067 client. If one elects to do so anyway, they MUST NOT be allocated to 3068 a new client until the MCLT beyond the entry into PARTNER-DOWN state 3069 has elapsed. 3071 A server in PARTNER-DOWN state MUST NOT allocate a lease to a DHCP 3072 client different from that to which it was allocated at the entrance 3073 to PARTNER-DOWN state until the MCLT beyond the maximum of the 3074 following times: client expiration time, most recently transmitted 3075 partner-lifetime, most recently received ack of the partner-time from 3076 the partner, and most recently acked partner-lifetime to the partner. 3077 If this time would be earlier than the current time plus the MCLT, 3078 then the time the server entered PARTNER-DOWN state plus the MCLT is 3079 used. 3081 The server is not restricted by the MCLT when offering valid 3082 lifetimes while in PARTNER-DOWN state. 3084 In the unlikely case when there are two servers operating in a 3085 PARTNER-DOWN state, there is a chance of duplicate leases for the 3086 same prefix to be assigned. This leads to a POTENTIAL-CONFLICT 3087 (unresponsive) state when they re-establish contact. The duplicate 3088 lease issue can be postponed to a large extent by the server granting 3089 new leases first from its own pool. Therefore the server operating 3090 in PARTNER-DOWN state MUST use its own pool first for new leases 3091 before assigning any leases from its downed partner pool. 3093 8.4.2. Transition Out of PARTNER-DOWN State 3095 When a server in PARTNER-DOWN state succeeds in establishing a 3096 connection to its partner, its actions are conditional on the state 3097 and flags received in the STATE message from the other server as part 3098 of the process of establishing the connection. 3100 If the STARTUP bit is set in the server-flags option of a received 3101 STATE message, a server in PARTNER-DOWN state MUST NOT take any state 3102 transitions based on reestablishing communications. If a server is 3103 in PARTNER-DOWN state, it ignores all STATE messages from its partner 3104 that have the STARTUP bit set in the server-flags option of the STATE 3105 message. 3107 If the STARTUP bit is not set in the server-flags option of a STATE 3108 message received from its partner, then a server in PARTNER-DOWN 3109 state takes the following actions based on the state of the partner 3110 as received in a STATE message (either immediately after establishing 3111 communications or at any time later when a new state is received) 3113 o If the partner is in: [ NORMAL, COMMUNICATIONS-INTERRUPTED, 3114 PARTNER-DOWN, POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or 3115 CONFLICT-DONE ] state, then transition to POTENTIAL-CONFLICT state 3117 o If the partner is in: [ RECOVER, RECOVER-WAIT ] state stay in 3118 PARTNER-DOWN state 3120 o If the partner is in: [ RECOVER-DONE ] state transition into 3121 NORMAL state 3123 8.5. RECOVER State 3125 This state indicates that the server has no information in its stable 3126 storage or that it is re-integrating with a server in PARTNER-DOWN 3127 state after it has been down. A server in this state MUST attempt to 3128 refresh its stable storage from the other server. 3130 8.5.1. Operation in RECOVER State 3132 The server MUST NOT be responsive in RECOVER state. 3134 A server in RECOVER state will attempt to reestablish communications 3135 with the other server. 3137 8.5.2. Transition Out of RECOVER State 3139 If the other server is in POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, 3140 or CONFLICT-DONE state when communications are reestablished, then 3141 the server in RECOVER state will move to POTENTIAL-CONFLICT state 3142 itself. 3144 If the other server is in any other state, then the server in RECOVER 3145 state will request an update of missing binding information by 3146 sending an UPDREQ message. If the server has determined that it has 3147 lost its stable storage because it has no record of ever having 3148 talked to its partner, while its partner does have a record of 3149 communicating with it, it MUST send an UPDREQALL message, otherwise 3150 it MUST send an UPDREQ message. 3152 It will wait for an UPDDONE message, and upon receipt of that message 3153 it will transition to RECOVER-WAIT state. 3155 If communication fails during the reception of the results of the 3156 UPDREQ or UPDREQALL message, the server will remain in RECOVER state, 3157 and will re-issue the UPDREQ or UPDREQALL when communications are re- 3158 established. 3160 If an UPDDONE message isn't received within an implementation 3161 dependent amount of time, and no BNDUPD messages are being received, 3162 the connection SHOULD be dropped. 3164 A B 3165 Server Server 3167 | | 3168 RECOVER PARTNER-DOWN 3169 | | 3170 | >--UPDREQ--------------------> | 3171 | | 3172 | <---------------------BNDUPD--< | 3173 | >--BNDREPLY------------------> | 3174 ... ... 3175 | | 3176 | <---------------------BNDUPD--< | 3177 | >--BNDREPLY------------------> | 3178 | | 3179 | <--------------------UPDDONE--< | 3180 | | 3181 RECOVER-WAIT | 3182 | | 3183 | >--STATE-(RECOVER-WAIT)------> | 3184 | | 3185 | | 3186 Wait MCLT from last known | 3187 time of failover operation | 3188 | | 3189 RECOVER-DONE | 3190 | | 3191 | >--STATE-(RECOVER-DONE)------> | 3192 | NORMAL 3193 | <-------------(NORMAL)-STATE--< | 3194 NORMAL | 3195 | >---- State-(NORMAL)---------------> | 3196 | | 3197 | | 3199 Figure 7: Transition out of RECOVER state 3201 If at any time while a server is in RECOVER state communication 3202 fails, the server will stay in RECOVER state. When communications 3203 are restored, it will restart the process of transitioning out of 3204 RECOVER state. 3206 8.6. RECOVER-WAIT State 3208 This state indicates that the server has sent an UPDREQ or UPDREQALL 3209 and has received the UPDDONE message indicating that it has received 3210 all outstanding binding update information. In the RECOVER-WAIT 3211 state the server will wait for the MCLT in order to ensure that any 3212 processing that this server might have done prior to losing its 3213 stable storage will not cause future difficulties. 3215 8.6.1. Operation in RECOVER-WAIT State 3217 The server MUST NOT be responsive in RECOVER-WAIT state. 3219 8.6.2. Transition Out of RECOVER-WAIT State 3221 Upon entry to RECOVER-WAIT state the server MUST start a timer whose 3222 expiration is set to a time equal to the time the server went down 3223 (if known) or the time the server started (if the down-time is 3224 unknown) plus the maximum-client-lead-time. When this timer expires, 3225 the server will transition into RECOVER-DONE state. 3227 This is to allow any IPv6 addresses or prefixes that were allocated 3228 by this server prior to loss of its client binding information in 3229 stable storage to contact the other server or to time out. 3231 If the server has never before run failover, then there is no need to 3232 wait in this state and the server MAY transition immediately to 3233 RECOVER_DONE state. However, to determine if this server has run 3234 failover it is vital that the information provided by the partner be 3235 utilized, since the stable storage of this server may have been lost. 3237 If communication fails while a server is in RECOVER-WAIT state, it 3238 has no effect on the operation of this state. The server SHOULD 3239 continue to operate its timer, and if the timer expires during the 3240 period where communications with the other server have failed, then 3241 the server SHOULD transition to RECOVER-DONE state. This is rare -- 3242 failover state transitions are not usually made while communications 3243 are interrupted, but in this case there is no reason to inhibit this 3244 transition. 3246 8.7. RECOVER-DONE State 3248 This state exists to allow an interlocked transition for one server 3249 from RECOVER state and another server from PARTNER-DOWN or 3250 COMMUNICATIONS-INTERRUPTED state into NORMAL state. 3252 8.7.1. Operation in RECOVER-DONE State 3254 A server in RECOVER-DONE state SHOULD be renew responsive, and MAY 3255 respond to RENEW requests but MUST only change the state of a lease 3256 that appears in the RENEW request. It MUST NOT allocate any 3257 additional leases when in RECOVER-DONE state and should only respond 3258 only to RENEW requests where it already has a record of the lease. 3260 8.7.2. Transition Out of RECOVER-DONE State 3262 When a server in RECOVER-DONE state determines that its partner 3263 server has entered NORMAL or RECOVER-DONE state, then it will 3264 transition into NORMAL state. 3266 If the partner server enters RECOVER or RECOVER-WAIT state, this 3267 server transitions to COMMUNICATIONS-INTERRUPTED. 3269 If the partner server enters POTENTIAL-CONFLICT state then this 3270 server enters POTENTIAL-CONFLICT state as well. 3272 If communication fails while in RECOVER-DONE state, a server will 3273 stay in RECOVER-DONE state. 3275 8.8. NORMAL State 3277 NORMAL state is the state used by a server when it is communicating 3278 with the other server, and any required resynchronization has been 3279 performed. While some binding database synchronization is performed 3280 in NORMAL state, potential conflicts are resolved prior to entry into 3281 NORMAL state as is binding database data loss. 3283 When entering NORMAL state, a server will send to the other server 3284 all currently unacknowledged binding updates as BNDUPD messages. 3286 When the above process is complete, if the server entering NORMAL 3287 state is a secondary server, then it will request delegable prefixes 3288 for allocation using the POOLREQ message. 3290 8.8.1. Operation in NORMAL State 3292 The primary server is responsive in NORMAL state. The secondary is 3293 renew responsive in NORMAL state. 3295 When in NORMAL state a primary server will operate in the following 3296 manner: 3298 Valid lifetime calculations 3299 As discussed in Section 4.4, the lease interval given to a DHCP 3300 client can never be more than the MCLT greater than the most 3301 recently acknowledged partner lifetime received from the failover 3302 partner or the current time, whichever is later. 3304 As long as a server adheres to this constraint, the specifics of 3305 the lease interval that it gives to a DHCP client or the value of 3306 the partner lifetime sent to its failover partner are 3307 implementation dependent. 3309 Lazy update of partner server 3310 After sending a REPLY that includes a lease update to a client, 3311 the server servicing a DHCP client request attempts to update its 3312 partner with the new binding information. See Section 4.3. 3314 Reallocation of leases between clients 3315 Whenever a client binding is released or expires, a BNDUPD message 3316 must be sent to the partner, setting the binding state to RELEASED 3317 or EXPIRED. However, until a BNDREPLY is received for this 3318 message, the lease cannot be allocated to another client. It 3319 cannot be allocated to the same client again if a BNDUPD was sent, 3320 otherwise it can. See Section 4.2.2.1 for details. 3322 In NORMAL state, each server receives binding updates from its 3323 partner server in BNDUPD messages (see Section 7.5.5). It records 3324 these in its binding database in stable storage and then sends a 3325 corresponding BNDREPLY message to its partner server (see 3326 Section 7.6). 3328 8.8.2. Transition Out of NORMAL State 3330 If an external command is received by a server in NORMAL state 3331 informing it that its partner is down, then transition into PARTNER- 3332 DOWN state. Generally, this would be an unusual situation, where 3333 some external agency knew the partner server was down prior to the 3334 failover server discovering it on its own. 3336 If a server in NORMAL state fails to receive acks to messages sent to 3337 its partner for an implementation dependent period of time, it MAY 3338 move into COMMUNICATIONS-INTERRUPTED state. This situation might 3339 occur if the partner server was capable of maintaining the TCP 3340 connection between the server and also capable of sending a CONTACT 3341 message periodically, but was (for some reason) incapable of 3342 processing BNDUPD messages. 3344 If the communications is determined to not be "ok" (as defined in 3345 Section 6.6), then transition into COMMUNICATIONS-INTERRUPTED state. 3347 If a server in NORMAL state receives any messages from its partner 3348 where the partner has changed state from that expected by the server 3349 in NORMAL state, then the server should transition into 3350 COMMUNICATIONS-INTERRUPTED state and take the appropriate state 3351 transition from there. For example, it would be expected for the 3352 partner to transition from POTENTIAL-CONFLICT into NORMAL state, but 3353 not for the partner to transition from NORMAL into POTENTIAL-CONFLICT 3354 state. 3356 If a server in NORMAL state receives a DISCONNECT message from its 3357 partner, the server should transition into COMMUNICATIONS-INTERRUPTED 3358 state. 3360 8.9. COMMUNICATIONS-INTERRUPTED State 3362 A server goes into COMMUNICATIONS-INTERRUPTED state whenever it is 3363 unable to communicate with its partner. Primary and secondary 3364 servers cycle automatically (without administrative intervention) 3365 between NORMAL and COMMUNICATIONS-INTERRUPTED state as the network 3366 connection between them fails and recovers, or as the partner server 3367 cycles between operational and non-operational. No duplicate lease 3368 allocation can occur while the servers cycle between these states. 3370 When a server enters COMMUNICATIONS-INTERRUPTED state, if it has been 3371 configured to support an automatic transition out of COMMUNICATIONS- 3372 INTERRUPTED state and into PARTNER-DOWN state (i.e., auto-partner- 3373 down has been configured), then a timer is started for the length of 3374 the configured auto-partner-down period. 3376 A server transitioning into the COMMUNICATIONS-INTERRUPTED state from 3377 the NORMAL state SHOULD raise some alarm condition to alert 3378 administrative staff to a potential problem in the DHCP subsystem. 3380 8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State 3382 In this state a server MUST respond to all DHCP client requests. 3383 When allocating new leases, each server allocates from its own pool, 3384 where the primary MUST allocate only FREE delegable prefixes, and the 3385 secondary MUST allocate only FREE-BACKUP delegable prefixes, and each 3386 server allocates from its own independent IPv6 address ranges. When 3387 responding to RENEW messages, each server will allow continued 3388 renewal of a DHCP client's current lease regardless of whether that 3389 lease was given out by the receiving server or not, although the 3390 renewal period MUST NOT exceed the MCLT beyond the latest of: 1) the 3391 partner lifetime already acknowledged by the other server, or 2) now, 3392 or 3) the partner lifetime received from the partner server. 3394 However, since the server cannot communicate with its partner in this 3395 state, the acknowledged partner lifetime will not be updated despite 3396 continued RENEW message processing. This is likely to eventually 3397 cause the actual lifetimes to converge to the MCLT (unless this is 3398 greater than the desired lease time, which would be unusual). 3400 The server should continue to try to establish a connection with its 3401 partner. 3403 8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State 3405 If the auto-partner-down timer expires while a server is in the 3406 COMMUNICATIONS-INTERRUPTED state, it will transition immediately into 3407 PARTNER-DOWN state. 3409 If an external command is received by a server in COMMUNICATIONS- 3410 INTERRUPTED state informing it that its partner is down, it will 3411 transition immediately into PARTNER-DOWN state. 3413 If communications is restored with the other server, then the server 3414 in COMMUNICATIONS-INTERRUPTED state will transition into another 3415 state based on the state of the partner: 3417 o NORMAL or COMMUNICATIONS-INTERRUPTED: Transition into the NORMAL 3418 state. 3420 o RECOVER: Stay in COMMUNICATIONS-INTERRUPTED state. 3422 o RECOVER-DONE: Transition into NORMAL state. 3424 o PARTNER-DOWN, POTENTIAL-CONFLICT, CONFLICT-DONE, or RESOLUTION- 3425 INTERRUPTED: Transition into POTENTIAL-CONFLICT state. 3427 The following figure illustrates the transition from NORMAL to 3428 COMMUNICATIONS-INTERRUPTED state and then back to NORMAL state again. 3430 Primary Secondary 3431 Server Server 3433 NORMAL NORMAL 3434 | >--CONTACT-------------------> | 3435 | <--------------------CONTACT--< | 3436 | [TCP connection broken] | 3437 COMMUNICATIONS : COMMUNICATIONS 3438 INTERRUPTED : INTERRUPTED 3439 | [attempt new TCP connection] | 3440 | [connection succeeds] | 3441 | | 3442 | >--CONNECT-------------------> | 3443 | <---------------CONNECTREPLY--< | 3444 | NORMAL 3445 | <-------------------STATE-----< | 3446 NORMAL | 3447 | >--STATE---------------------> | 3448 | 3449 | >--BNDUPD--------------------> | 3450 | <-------------------BNDREPLY--< | 3451 | | 3452 | <---------------------BNDUPD--< | 3453 | >------BNDREPLY--------------> | 3454 ... ... 3455 | | 3456 | <--------------------POOLREQ--< | 3457 | >--POOLRESP------------------> | 3458 | | 3459 | >--BNDUPD-(#1)---------------> | 3460 | <-------------------BNDREPLY--< | 3461 | | 3462 | >--BNDUPD-(#2)---------------> | 3463 | <-------------------BNDREPLY--< | 3464 | | 3466 Figure 8: Transition from NORMAL to COMMUNICATIONS-INTERRUPTED and 3467 back 3469 8.10. POTENTIAL-CONFLICT State 3471 This state indicates that the two servers are attempting to 3472 reintegrate with each other, but at least one of them was running in 3473 a state that did not guarantee automatic reintegration would be 3474 possible. In POTENTIAL-CONFLICT state the servers may determine that 3475 the same lease has been offered and accepted by two different 3476 clients. 3478 It is a goal of the failover protocol to minimize the possibility 3479 that POTENTIAL-CONFLICT state is ever entered. 3481 When a primary server enters POTENTIAL-CONFLICT state it should 3482 request that the secondary send it all updates which the primary 3483 server has not yet acknowledged by sending an UPDREQ message to the 3484 secondary server. 3486 A secondary server entering POTENTIAL-CONFLICT state will wait for 3487 the primary to send it an UPDREQ message. 3489 8.10.1. Operation in POTENTIAL-CONFLICT State 3491 Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming 3492 DHCP requests. 3494 8.10.2. Transition Out of POTENTIAL-CONFLICT State 3496 If communication fails with the partner while in POTENTIAL-CONFLICT 3497 state, then the server will transition to RESOLUTION-INTERRUPTED 3498 state. 3500 Whenever either server receives an UPDDONE message from its partner 3501 while in POTENTIAL-CONFLICT state, it MUST transition to a new state. 3502 The primary MUST transition to CONFLICT-DONE state, and the secondary 3503 MUST transition to NORMAL state. This will cause the primary server 3504 to leave POTENTIAL-CONFLICT state prior to the secondary, since the 3505 primary sends an UPDREQ message and receives an UPDDONE before the 3506 secondary sends an UPDREQ message and receives its UPDDONE message. 3508 When a secondary server receives an indication that the primary 3509 server has made a transition from POTENTIAL-CONFLICT to CONFLICT-DONE 3510 state, it SHOULD send an UPDREQ message to the primary server. 3512 Primary Secondary 3513 Server Server 3515 | | 3516 POTENTIAL-CONFLICT POTENTIAL-CONFLICT 3517 | | 3518 | >--UPDREQ--------------------> | 3519 | | 3520 | <---------------------BNDUPD--< | 3521 | >--BNDREPLY------------------> | 3522 ... ... 3523 | | 3524 | <---------------------BNDUPD--< | 3525 | >--BNDREPLY------------------> | 3526 | | 3527 | <--------------------UPDDONE--< | 3528 CONFLICT-DONE | 3529 | >--STATE--(CONFLICT-DONE)----> | 3530 | <---------------------UPDREQ--< | 3531 | | 3532 | >--BNDUPD--------------------> | 3533 | <-------------------BNDREPLY--< | 3534 ... ... 3535 | >--BNDUPD--------------------> | 3536 | <-------------------BNDREPLY--< | 3537 | | 3538 | >--UPDDONE-------------------> | 3539 | NORMAL 3540 | <------------STATE--(NORMAL)--< | 3541 NORMAL | 3542 | >--STATE--(NORMAL)-----------> | 3543 | | 3544 | <--------------------POOLREQ--< | 3545 | >------POOLRESP--------------> | 3546 | | 3548 Figure 9: Transition out of POTENTIAL-CONFLICT 3550 8.11. RESOLUTION-INTERRUPTED State 3552 This state indicates that the two servers were attempting to 3553 reintegrate with each other in POTENTIAL-CONFLICT state, but 3554 communication failed prior to completion of re-integration. 3556 The RESOLUTION-INTERRUPTED state exists because servers are not 3557 responsive in POTENTIAL-CONFLICT state, and if one server drops out 3558 of service while both servers are in POTENTIAL-CONFLICT state, the 3559 server that remains in service will not be able to process DHCP 3560 client requests and there will be no DHCP server available to process 3561 client requests. The RESOLUTION-INTERRUPTED state is the state that 3562 a server moves to if its partner disappears while it is in POTENTIAL- 3563 CONFLICT state. 3565 When a server enters RESOLUTION-INTERRUPTED state it SHOULD raise an 3566 alarm condition to alert administrative staff of a problem in the 3567 DHCP subsystem. 3569 8.11.1. Operation in RESOLUTION-INTERRUPTED State 3571 In this state a server MUST respond to all DHCP client requests. 3572 When allocating new leases, each server SHOULD allocate from its own 3573 pool (if that can be determined), where the primary SHOULD allocate 3574 only FREE leases, and the secondary SHOULD allocate only FREE-BACKUP 3575 leases. When responding to renewal requests, each server will allow 3576 continued renewal of a DHCP client's current lease independent of 3577 whether that lease was given out by the receiving server or not, 3578 although the renewal period MUST NOT exceed the maximum client lead 3579 time (MCLT) beyond the latest of: 1) the partner lifetime already 3580 acknowledged by the other server or 2) now or 3) partner lifetime 3581 received from the partner server. 3583 However, since the server cannot communicate with its partner in this 3584 state, the acknowledged partner lifetime will not be updated in any 3585 new bindings. 3587 8.11.2. Transition Out of RESOLUTION-INTERRUPTED State 3589 If an external command is received by a server in RESOLUTION- 3590 INTERRUPTED state informing it that its partner is down, it will 3591 transition immediately into PARTNER-DOWN state. 3593 If communications is restored with the other server, then the server 3594 in RESOLUTION-INTERRUPTED state will transition into POTENTIAL- 3595 CONFLICT state. 3597 8.12. CONFLICT-DONE State 3599 This state indicates that during the process where the two servers 3600 are attempting to re-integrate with each other, the primary server 3601 has received all of the updates from the secondary server. It makes 3602 a transition into CONFLICT-DONE state in order that it may be totally 3603 responsive to the client load. There is no operational difference 3604 between CONFLICT-DONE and NORMAL for primary as in both states it 3605 responds to all clients' requests. The distinction between CONFLICT- 3606 DONE and NORMAL states is necessary in the event that a load- 3607 balancing extension is ever defined. 3609 8.12.1. Operation in CONFLICT-DONE State 3611 A primary server in CONFLICT-DONE state is fully responsive to all 3612 DHCP clients (similar to the situation in COMMUNICATIONS-INTERRUPTED 3613 state). 3615 If communication fails, remain in CONFLICT-DONE state. If 3616 communications becomes OK, remain in CONFLICT-DONE state until the 3617 conditions for transition out become satisfied. 3619 8.12.2. Transition Out of CONFLICT-DONE State 3621 If communication fails with the partner while in CONFLICT-DONE state, 3622 then the server will remain in CONFLICT-DONE state. 3624 When a primary server determines that the secondary server has made a 3625 transition into NORMAL state, the primary server will also transition 3626 into NORMAL state. 3628 9. DNS Update Considerations 3630 DHCP servers (and clients) can use DNS Updates as described in RFC 3631 2136 [RFC2136] to maintain DNS name-mappings as they maintain DHCP 3632 leases. Many different administrative models for DHCP-DNS 3633 integration are possible. Descriptions of several of these models, 3634 and guidelines that DHCP servers and clients should follow in 3635 carrying them out, are laid out in RFC 4704 [RFC4704]. 3637 The nature of the failover protocol introduces some issues concerning 3638 DNS updates that are not part of non-failover environments. This 3639 section describes these issues, and defines the information which 3640 failover partners should exchange in order to ensure consistent 3641 behavior. The presence of this section should not be interpreted as 3642 requiring an implementation of the DHCPv6 failover protocol to also 3643 support DNS updates. 3645 The purpose of this discussion is to clarify the areas where the 3646 failover and DHCP DNS update protocols intersect for the benefit of 3647 implementations which support both protocols, not to introduce a new 3648 requirement into the DHCPv6 failover protocol. Thus, a DHCP server 3649 which implements the failover protocol MAY also support DNS updates, 3650 but if it does support DNS updates it SHOULD utilize the techniques 3651 described here in order to correctly distribute them between the 3652 failover partners. See RFC 4704 [RFC4704] as well as RFC 4703 3653 [RFC4703] for information on how DHCP servers deal with potential 3654 conflicts when updating DNS even without failover. 3656 From the standpoint of the failover protocol, there is no reason why 3657 a server which is utilizing the DNS update protocol to update a DNS 3658 server should not be a partner with a server which is not utilizing 3659 the DNS update protocol to update a DNS server. However, a server 3660 which is not able to support DNS update or is not configured to 3661 support DNS update SHOULD output a warning message when it receives 3662 BNDUPD messages which indicate that its failover partner is 3663 configured to support the DNS update protocol to update a DNS server. 3664 An implementation MAY consider this an error and refuse to accept the 3665 BNDUPD by returning the status DNSUpdateNotSupported in an 3666 OPTION_STATUS_CODE option in the BNDREPLY message, or it MAY choose 3667 to operate anyway, having warned the administrator of the problem in 3668 some way. 3670 9.1. Relationship between failover and DNS update 3672 The failover protocol describes the conditions under which each 3673 failover server may renew a lease to its current DHCP client, and 3674 describes the conditions under which it may grant a lease to a new 3675 DHCP client. An analogous set of conditions determines when a 3676 failover server should initiate a DNS update, and when it should 3677 attempt to remove records from the DNS. The failover protocol's 3678 conditions are based on the desired external behavior: avoiding 3679 duplicate address and prefix assignments; allowing clients to 3680 continue using leases which they obtained from one failover partner 3681 even if they can only communicate with the other partner; allowing 3682 the secondary DHCP server to grant new leases even if it is unable to 3683 communicate with the primary server. The desired external DNS update 3684 behavior for DHCPv6 failover servers is similar to that described 3685 above for the failover protocol itself: 3687 1. Allow timely DNS updates from the server which grants a lease to 3688 a client. Recognize that there is often a DNS update lifecycle 3689 which parallels the DHCP lease lifecycle. This is likely to 3690 include the addition of records when the lease is granted, and 3691 the removal of DNS records when the lease is subsequently made 3692 available for allocation to a different client. 3694 2. Communicate enough information between the two failover servers 3695 to allow one to complete the DNS update 'lifecycle' even if the 3696 other server originally granted the lease. 3698 3. Avoid redundant or overlapping DNS updates, where both failover 3699 servers are attempting to perform DNS updates for the same lease- 3700 client binding. 3702 4. Avoid situations where one partner is attempting to add RRs 3703 related to a lease binding while the other partner is attempting 3704 to remove RRs related to the same lease binding. 3706 While DHCPv6 servers configured for DNS update typically perform 3707 these operations on both the AAAA and the PTR resource records, this 3708 is not required. It is entirely possible that a DHCPv6 server could 3709 be configured to only update the DNS with PTR records, and the DHCPv6 3710 clients could be responsible for updating the DNS with their own AAAA 3711 records. In this case, the discussions here would apply only to the 3712 PTR records. 3714 9.2. Exchanging DNS Update Information 3716 In order for either server to be able to complete a DNS update, or to 3717 remove DNS records which were added by its partner, both servers need 3718 to know the FQDN associated with the lease-client binding. In 3719 addition, to properly handle DNS updates, additional information is 3720 required. All of the following information needs to be transmitted 3721 between the failover partners: 3723 1. The FQDN that the client requested be associated with the lease. 3724 If the client doesn't request a particular FQDN and one is 3725 synthesized by the failover server or if the failover server is 3726 configured to replace a client requested FQDN with a different 3727 FQDN, then the server generated value would be used. 3729 2. The FQDN that was actually placed in the DNS for this lease. It 3730 may differ from the client requested FQDN due to some form of 3731 disambiguation or other DHCP server configuration (as described 3732 above). 3734 3. The status of and DNS update operations in progress or completed. 3736 4. Information sufficient to allow the failover partner to remove 3737 the FQDN from the DNS should that become necessary. 3739 These data items are the minimum necessary set to reliably allow two 3740 failover partners to successfully share the responsibility to keep 3741 the DNS up to date with the leases allocated to clients. 3743 This information would typically be included in BNDUPD messages sent 3744 from one failover partner to the other. Failover servers MAY choose 3745 not to include this information in BNDUPD messages if there has been 3746 no change in the status of any DNS update related to the lease. 3748 The partner server receiving BNDUPD messages containing the DNS 3749 update information SHOULD compare the status information and the FQDN 3750 with the current DNS update information it has associated with the 3751 lease binding, and update its notion of the DNS update status 3752 accordingly. 3754 Some implementations will instead choose to send a BNDUPD without 3755 waiting for the DNS update to complete, and then will send a second 3756 BNDUPD once the DNS update is complete. Other implementations will 3757 delay sending the partner a BNDUPD until the DNS update has been 3758 acknowledged by the DNS server, or until some time-limit has elapsed, 3759 in order to avoid sending a second BNDUPD. 3761 The FQDN option contains the FQDN that will be associated with the 3762 AAAA RR (if the server is performing an AAAA RR update for the 3763 client). The PTR RR can be generated automatically from the IPv6 3764 address or prefix value. The FQDN may be composed in any of several 3765 ways, depending on server configuration and the information provided 3766 by the client in its DHCP messages. The client may supply a hostname 3767 which it would like the server to use in forming the FQDN, or it may 3768 supply the entire FQDN. The server may be configured to attempt to 3769 use the information the client supplies, it may be configured with an 3770 FQDN to use for the client, or it may be configured to synthesize an 3771 FQDN. 3773 Since the server interacting with the client may not have completed 3774 the DNS update at the time it sends the first BNDUPD about the lease 3775 binding, there may be cases where the FQDN in later BNDUPD messages 3776 does not match the FQDN included in earlier messages. For example, 3777 the responsive server may be configured to handle situations where 3778 two or more DHCP client FQDNs are identical by modifying the most- 3779 specific label in the FQDNs of some of the clients in an attempt to 3780 generate unique FQDNs for them (a process sometimes called 3781 "disambiguation"). Alternatively, at sites which use some or all of 3782 the information which clients supply to form the FQDN, it's possible 3783 that a client's configuration may be changed so that it begins to 3784 supply new data. The server interacting with the client may react by 3785 removing the DNS records which it originally added for the client, 3786 and replacing them with records that refer to the client's new FQDN. 3787 In such cases, the server SHOULD include the actual FQDN that was 3788 used in subsequent DNS update options in any BNDUPD messages 3789 exchanged between the failover partners. This server SHOULD include 3790 relevant information in its BNDUPD messages. This information may be 3791 necessary in order to allow the non-responsive partner to detect 3792 client configuration changes that change the hostname or FQDN data 3793 which the client includes in its DHCPv6 requests. 3795 9.3. Adding RRs to the DNS 3797 A failover server which is going to perform DNS updates SHOULD 3798 initiate the DNS update when it grants a new lease to a client. The 3799 server which did not grant the lease SHOULD NOT initiate a DNS update 3800 when it receives the BNDUPD after the lease has been granted. The 3801 failover protocol ensures that only one of the partners will grant a 3802 lease to any individual client, so it follows that this requirement 3803 will prevent both partners from initiating updates simultaneously. 3804 The server initiating the update SHOULD follow the protocol in RFC 3805 4704 [RFC4704]. The server may be configured to perform a AAAA RR 3806 update on behalf of its clients, or not. Ordinarily, a failover 3807 server will not initiate DNS updates when it renews leases. In two 3808 cases, however, a failover server MAY initiate a DNS update when it 3809 renews a lease to its existing client: 3811 1. When the lease was granted before the server was configured to 3812 perform DNS updates, the server MAY be configured to perform 3813 updates when it next renews existing leases. 3815 2. If a server is in PARTNER-DOWN state, it can conclude that its 3816 partner is no longer attempting to perform an update for the 3817 existing client. If the remaining server has not recorded that 3818 an update for the binding has been successfully completed, the 3819 server MAY initiate a DNS update. It MAY initiate this update 3820 immediately upon entry to PARTNER-DOWN state, it may perform this 3821 in the background, or it MAY initiate this update upon next 3822 hearing from the DHCP client. 3824 Note that, regardless of the use of failover, there is a use case for 3825 updating the DNS on every lease renewal. If there is a concern that 3826 the information in the DNS does not match the information in the DHCP 3827 server, updating the DNS on lease renewal is one way to gradually 3828 ensure that the DNS has information that corresponds correctly the 3829 information in the DHCP server. 3831 9.4. Deleting RRs from the DNS 3833 The failover server which makes a lease PENDING-FREE SHOULD initiate 3834 any DNS deletes, if it has recorded that DNS records were added on 3835 behalf of the client. 3837 A server not in PARTNER-DOWN state "makes a lease PENDING-FREE" when 3838 it initiates a BNDUPD with a binding-status of FREE, FREE-BACKUP, 3839 EXPIRED, or RELEASED. Its partner confirms this status by acking 3840 that BNDUPD, and upon receipt of the BNDREPLY the server has "made 3841 the lease PENDING-FREE". Conversely, a server in PARTNER-DOWN state 3842 "makes a lease PENDING-FREE" when it sets the binding-status to FREE, 3843 since in PARTNER-DOWN state no communications is required with the 3844 partner. 3846 It is at this point that it should initiate the DNS operations to 3847 delete RRs from the DNS. Its partner SHOULD NOT initiate DNS deletes 3848 for DNS records related to the lease binding as part of sending the 3849 BNDREPLY message. The partner MAY have issued BNDUPD messages with a 3850 binding-status of FREE, EXPIRED, or RELEASED previously, but the 3851 other server will have rejected these BNDUPD messages. 3853 The failover protocol ensures that only one of the two partner 3854 servers will be able to make a lease PENDING-FREE. The server making 3855 the lease PENDING-FREE may be doing so while it is in NORMAL 3856 communication with its partner, or it may be in PARTNER-DOWN state. 3857 If a server is in PARTNER-DOWN state, it may be performing DNS 3858 deletes for RRs which its partner added originally. This allows a 3859 single remaining partner server to assume responsibility for all of 3860 the DNS update activity which the two servers were undertaking. 3862 Another implication of this approach is that no DNS RR deletes will 3863 be performed while either server is in COMMUNICATIONS-INTERRUPTED 3864 state, since no leases are moved into the PENDING-FREE state during 3865 that period. 3867 A failover server SHOULD ensure that a server failure while making a 3868 lease PENDING-FREE and initiating a DNS delete does not somehow leave 3869 the lease with a RR in the DNS with nothing recorded in the lease 3870 state database to trigger a DNS delete. 3872 9.5. Name Assignment with No Update of DNS 3874 In some cases, a DHCP server is configured to return a name to the 3875 DHCP client but not enter that name into the DNS. This is typically 3876 a name that it has discovered or generated from information it has 3877 received from the client. In this case this name information SHOULD 3878 be communicated to the failover partner, if only to ensure that they 3879 will return the same name in the event the partner becomes the server 3880 to which the DHCP client begins to interact. 3882 10. Security Considerations 3884 DHCPv6 failover is an extension of a standard DHCPv6 protocol, so all 3885 security considerations from [RFC3315], Section 23 and [RFC3633], 3886 Section 15 related to the server apply. 3888 The use of TCP introduces some additional concerns. Attacks that 3889 attempt to exhaust the DHCP server's available TCP connection 3890 resources can compromise the ability of legitimate partners to 3891 receive service. Malicious requestors who succeed in establishing 3892 connections but who then send invalid messages, partial messages, or 3893 no messages at all can also exhaust a server's pool of available 3894 connections. 3896 DHCPv6 failover can operate in secure or insecure mode. Secure mode 3897 (using TLS) would be indicated when the TCP connection between 3898 failover partners is open to external monitoring or interception. 3899 Insecure mode should only be used when the TCP connection between 3900 failover partners remains within a set of protected systems. Details 3901 of such protections are beyond the scope of this document. Failover 3902 servers MUST use the approach documented in Section 9.1 of [RFC7653] 3903 to decide to use or not to use TLS when connecting with the failover 3904 partner. 3906 The threats created by using failover directly mirror those from 3907 using DHCPv6 itself: information leakage through monitoring, and 3908 disruption of address assignment and configuration. Monitoring the 3909 failover TCP connection provides no additional data beyond that 3910 available from monitoring the interactions between DHCPv6 clients and 3911 the DHCPv6 server. Likewise, manipulating the data flow between 3912 failover servers provides no additional opportunities to disrupt 3913 address assignment and configuration beyond that provided by acting 3914 as a counterfeit DHCP server. Protection from both threats is easier 3915 than with basic DHCPv6, as only a single TCP connection needs to be 3916 protected. Either use secure mode to protect that TCP connection or 3917 ensure that it can only exist with a set of protected systems. 3919 When operating in secure mode, TLS [RFC5246] is used to secure the 3920 connection. The recommendations in [RFC7525] SHOULD be followed when 3921 negotiating a TLS connection. 3923 Servers SHOULD offer configuration parameters to limit the sources of 3924 incoming connections through validation and use of the digital 3925 certificates presented to create a TLS connection. They SHOULD also 3926 limit the number of accepted connections and limit the period of time 3927 during which an idle connection will be left open. 3929 Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to 3930 attempt to secure transmission of the messages described in this 3931 document. If authentication is desired, secure mode using TLS SHOULD 3932 be employed as described in Sections 8.2 and 9.1 of [RFC7653]. 3934 11. IANA Considerations 3936 IANA is requested to assign values for the following new DHCPv6 3937 Message types in the registry maintained in 3938 http://www.iana.org/assignments/dhcpv6-parameters: 3940 o BNDUPD (TBD1) 3942 o BNDREPLY (TBD2) 3944 o POOLREQ (TBD3) 3946 o POOLRESP (TBD4) 3948 o UPDREQ (TBD5) 3950 o UPDREQALL (TBD6) 3952 o UPDDONE (TBD7) 3954 o CONNECT (TBD8) 3956 o CONNECTREPLY (TBD9) 3958 o DISCONNECT (TBD10) 3960 o STATE (TBD11) 3962 o CONTACT (TBD12) 3964 IANA is requested to assign values for the following new DHCPv6 3965 Option codes in the registry maintained in 3966 http://www.iana.org/assignments/dhcpv6-parameters: 3968 OPTION_F_BINDING_STATUS (TBD13) 3970 OPTION_F_CONNECT_FLAGS (TBD14) 3972 OPTION_F_DNS_REMOVAL_INFO (TBD15) 3974 OPTION_F_DNS_HOST_NAME (TBD16) 3976 OPTION_F_DNS_ZONE_NAME (TBD17) 3978 OPTION_F_DNS_FLAGS (TBD18) 3980 OPTION_F_EXPIRATION_TIME (TBD19) 3982 OPTION_F_MAX_UNACKED_BNDUPD (TBD20) 3984 OPTION_F_MCLT (TBD21) 3986 OPTION_F_PARTNER_LIFETIME (TBD22) 3987 OPTION_F_PARTNER_LIFETIME_SENT (TBD23) 3989 OPTION_F_PARTNER_DOWN_TIME (TBD24) 3991 OPTION_F_PARTNER_RAW_CLT_TIME (TBD25) 3993 OPTION_F_PROTOCOL_VERSION (TBD26) 3995 OPTION_F_KEEPALIVE_TIME (TBD27) 3997 OPTION_F_RECONFIGURE_DATA (TBD28) 3999 OPTION_F_RELATIONSHIP_NAME (TBD29) 4001 OPTION_F_SERVER_FLAGS (TBD30) 4003 OPTION_F_SERVER_STATE (TBD31) 4005 OPTION_F_START_TIME_OF_STATE (TBD32) 4007 OPTION_F_STATE_EXPIRATION_TIME (TBD33) 4009 IANA is requested to assign values for the following new DHCPv6 4010 Status codes in the registry maintained in 4011 http://www.iana.org/assignments/dhcpv6-parameters: 4013 AddressInUse (TBD34) 4015 ConfigurationConflict (TBD35) 4017 MissingBindingInformation (TBD36) 4019 OutdatedBindingInformation (TBD37) 4021 ServerShuttingDown (TBD38) 4023 DNSUpdateNotSupported (TBD39) 4025 ExcessiveTimeSkew (TBD40) 4027 12. Acknowledgements 4029 This document extensively uses concepts, definitions and other parts 4030 of an effort to document failover for DHCPv4. Authors would like to 4031 thank Shawn Routhier, Greg Rabil, Bernie Volz and Marcin Siodelski 4032 for their significant involvement and contributions. In particular, 4033 Bernie Volz and Shawn Routhier provided detailed and substantive 4034 technical reviews of the draft. Authors would like to thank 4035 VithalPrasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki and 4036 Michal Hoeft for their insightful comments. 4038 13. References 4040 13.1. Normative References 4042 [RFC1035] Mockapetris, P., "Domain names - implementation and 4043 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 4044 November 1987, . 4046 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4047 Requirement Levels", BCP 14, RFC 2119, 4048 DOI 10.17487/RFC2119, March 1997, 4049 . 4051 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 4052 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 4053 RFC 2136, DOI 10.17487/RFC2136, April 1997, 4054 . 4056 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 4057 C., and M. Carney, "Dynamic Host Configuration Protocol 4058 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 4059 2003, . 4061 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 4062 Host Configuration Protocol (DHCP) version 6", RFC 3633, 4063 DOI 10.17487/RFC3633, December 2003, 4064 . 4066 [RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified 4067 Domain Name (FQDN) Conflicts among Dynamic Host 4068 Configuration Protocol (DHCP) Clients", RFC 4703, 4069 DOI 10.17487/RFC4703, October 2006, 4070 . 4072 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 4073 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 4074 Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, 4075 . 4077 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 4078 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 4079 September 2007, . 4081 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4082 (TLS) Protocol Version 1.2", RFC 5246, 4083 DOI 10.17487/RFC5246, August 2008, 4084 . 4086 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 4087 DOI 10.17487/RFC5460, February 2009, 4088 . 4090 [RFC6607] Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet 4091 Selection Options for DHCPv4 and DHCPv6", RFC 6607, 4092 DOI 10.17487/RFC6607, April 2012, 4093 . 4095 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 4096 "Recommendations for Secure Use of Transport Layer 4097 Security (TLS) and Datagram Transport Layer Security 4098 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 4099 2015, . 4101 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 4102 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 4103 October 2015, . 4105 13.2. Informative References 4107 [RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover 4108 Requirements", RFC 7031, DOI 10.17487/RFC7031, September 4109 2013, . 4111 Authors' Addresses 4113 Tomasz Mrugalski 4114 Internet Systems Consortium, Inc. 4115 950 Charter Street 4116 Redwood City, CA 94063 4117 USA 4119 Phone: +1 650 423 1345 4120 Email: tomasz.mrugalski@gmail.com 4121 Kim Kinnear 4122 Cisco Systems, Inc. 4123 1414 Massachusetts Avenue 4124 Boxborough, Massachusetts 01719 4125 USA 4127 Phone: +1 (978) 936-0000 4128 Email: kkinnear@cisco.com