idnits 2.17.1 draft-ietf-dhc-dhcpv6-failover-protocol-00.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 834 has weird spacing: '... Value bind...' == Line 2119 has weird spacing: '... accept acc...' == Line 2121 has weird spacing: '... accept acc...' == Line 2122 has weird spacing: '... accept acc...' == Line 2123 has weird spacing: '... reject rej...' -- The document date (October 16, 2015) is 3116 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 (~~), 6 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: April 18, 2016 Cisco 6 October 16, 2015 8 DHCPv6 Failover Protocol 9 draft-ietf-dhc-dhcpv6-failover-protocol-00 11 Abstract 13 DHCPv6 defined in "Dynamic Host Configuration Protocol for IPv6 14 (DHCPv6)" does not offer server redundancy. This document defines a 15 specific protocol implementation to provide for DHCPv6 failover, a 16 mechanism for running two servers on the same network with capability 17 for either server to take over clients' leases in case of server 18 failure or network partition. It meets the requirements for DHCPv6 19 failover detailed in "DHCPv6 Failover Requirements". 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 April 18, 2016. 38 Copyright Notice 40 Copyright (c) 2015 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4. Failover Concepts and Mechanisms . . . . . . . . . . . . . . 7 59 4.1. Required Server Configuration . . . . . . . . . . . . . . 7 60 4.2. IPv6 Address and Delegable Prefix Allocation . . . . . . 8 61 4.2.1. Independent Allocation . . . . . . . . . . . . . . . 8 62 4.2.2. Proportional Allocation . . . . . . . . . . . . . . . 9 63 4.3. Lazy Updates . . . . . . . . . . . . . . . . . . . . . . 11 64 4.4. Maximum Client Lead Time (MCLT) . . . . . . . . . . . . . 12 65 4.4.1. MCLT example . . . . . . . . . . . . . . . . . . . . 13 66 5. Message and Option Definitions . . . . . . . . . . . . . . . 14 67 5.1. Message Framing for TCP . . . . . . . . . . . . . . . . . 15 68 5.2. Failover Message Format . . . . . . . . . . . . . . . . . 15 69 5.3. Messages . . . . . . . . . . . . . . . . . . . . . . . . 16 70 5.3.1. BNDUPD . . . . . . . . . . . . . . . . . . . . . . . 16 71 5.3.2. BNDACK . . . . . . . . . . . . . . . . . . . . . . . 16 72 5.3.3. POOLREQ . . . . . . . . . . . . . . . . . . . . . . . 16 73 5.3.4. POOLRESP . . . . . . . . . . . . . . . . . . . . . . 16 74 5.3.5. UPDREQ . . . . . . . . . . . . . . . . . . . . . . . 16 75 5.3.6. UPDREQALL . . . . . . . . . . . . . . . . . . . . . . 16 76 5.3.7. UPDDONE . . . . . . . . . . . . . . . . . . . . . . . 17 77 5.3.8. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 17 78 5.3.9. CONNECTACK . . . . . . . . . . . . . . . . . . . . . 17 79 5.3.10. DISCONNECT . . . . . . . . . . . . . . . . . . . . . 17 80 5.3.11. STATE . . . . . . . . . . . . . . . . . . . . . . . . 17 81 5.3.12. CONTACT . . . . . . . . . . . . . . . . . . . . . . . 17 82 5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 5.4.1. OPTION_F_BINDING_STATUS . . . . . . . . . . . . . . . 18 84 5.4.2. OPTION_F_DNS_REMOVAL_INFO . . . . . . . . . . . . . . 19 85 5.4.3. OPTION_F_DNS_HOST_NAME . . . . . . . . . . . . . . . 19 86 5.4.4. OPTION_F_DNS_ZONE_NAME . . . . . . . . . . . . . . . 20 87 5.4.5. OPTION_F_DNS_FLAGS . . . . . . . . . . . . . . . . . 21 88 5.4.6. OPTION_F_EXPIRATION_TIME . . . . . . . . . . . . . . 21 89 5.4.7. OPTION_F_MAX_UNACKED_BNDUPD . . . . . . . . . . . . . 22 90 5.4.8. OPTION_F_MCLT . . . . . . . . . . . . . . . . . . . . 23 91 5.4.9. OPTION_F_PARTNER_LIFETIME . . . . . . . . . . . . . . 23 92 5.4.10. OPTION_F_PARTNER_LIFETIME_SENT . . . . . . . . . . . 24 93 5.4.11. OPTION_F_PARTNER_DOWN_TIME . . . . . . . . . . . . . 24 94 5.4.12. OPTION_F_PARTNER_RAW_CLT_TIME . . . . . . . . . . . . 25 95 5.4.13. OPTION_F_PROTOCOL_VERSION . . . . . . . . . . . . . . 25 96 5.4.14. OPTION_F_RECEIVE_TIME . . . . . . . . . . . . . . . . 26 97 5.4.15. OPTION_F_RECONFIGURE_DATA . . . . . . . . . . . . . . 26 98 5.4.16. OPTION_F_RELATIONSHIP_NAME . . . . . . . . . . . . . 27 99 5.4.17. OPTION_F_SERVER_FLAGS . . . . . . . . . . . . . . . . 28 100 5.4.18. OPTION_F_SERVER_STATE . . . . . . . . . . . . . . . . 29 101 5.4.19. OPTION_F_START_TIME_OF_STATE . . . . . . . . . . . . 30 102 5.4.20. OPTION_F_STATE_EXPIRATION_TIME . . . . . . . . . . . 31 103 5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 31 104 6. Connection Management . . . . . . . . . . . . . . . . . . . . 32 105 6.1. Creating Connections . . . . . . . . . . . . . . . . . . 32 106 6.1.1. Sending a CONNECT message . . . . . . . . . . . . . . 33 107 6.1.2. Receiving a CONNECT message . . . . . . . . . . . . . 33 108 6.1.3. Receiving a CONNECTACK message . . . . . . . . . . . 34 109 6.2. Endpoint Identification . . . . . . . . . . . . . . . . . 35 110 6.3. Sending a STATE message . . . . . . . . . . . . . . . . . 35 111 6.4. Receiving a STATE message . . . . . . . . . . . . . . . . 36 112 6.5. Connection Maintenance Parameters . . . . . . . . . . . . 37 113 6.6. Unreachability detection . . . . . . . . . . . . . . . . 37 114 7. Binding Updates and Acks . . . . . . . . . . . . . . . . . . 38 115 7.1. Time Skew . . . . . . . . . . . . . . . . . . . . . . . . 38 116 7.2. Information model . . . . . . . . . . . . . . . . . . . . 38 117 7.3. Times Required for Exchanging Binding Updates . . . . . . 42 118 7.4. Sending Binding Updates . . . . . . . . . . . . . . . . . 43 119 7.5. Receiving Binding Updates . . . . . . . . . . . . . . . . 45 120 7.5.1. Correcting Time Skew . . . . . . . . . . . . . . . . 45 121 7.5.2. Processing Binding Updates . . . . . . . . . . . . . 46 122 7.5.3. Accept or Reject? . . . . . . . . . . . . . . . . . . 47 123 7.5.4. Accepting Updates . . . . . . . . . . . . . . . . . . 48 124 7.6. Sending Binding Acks . . . . . . . . . . . . . . . . . . 49 125 7.7. Receiving Binding Acks . . . . . . . . . . . . . . . . . 50 126 7.8. Acknowledging Reception . . . . . . . . . . . . . . . . . 51 127 7.9. BNDUPD/BNDACK Data Flow . . . . . . . . . . . . . . . . . 51 128 8. Endpoint States . . . . . . . . . . . . . . . . . . . . . . . 52 129 8.1. State Machine Operation . . . . . . . . . . . . . . . . . 52 130 8.2. State Machine Initialization . . . . . . . . . . . . . . 55 131 8.3. STARTUP State . . . . . . . . . . . . . . . . . . . . . . 55 132 8.3.1. Operation in STARTUP State . . . . . . . . . . . . . 56 133 8.3.2. Transition Out of STARTUP State . . . . . . . . . . . 56 134 8.4. PARTNER-DOWN State . . . . . . . . . . . . . . . . . . . 58 135 8.4.1. Operation in PARTNER-DOWN State . . . . . . . . . . . 58 136 8.4.2. Transition Out of PARTNER-DOWN State . . . . . . . . 59 137 8.5. RECOVER State . . . . . . . . . . . . . . . . . . . . . . 59 138 8.5.1. Operation in RECOVER State . . . . . . . . . . . . . 60 139 8.5.2. Transition Out of RECOVER State . . . . . . . . . . . 60 140 8.6. RECOVER-WAIT State . . . . . . . . . . . . . . . . . . . 61 141 8.6.1. Operation in RECOVER-WAIT State . . . . . . . . . . . 62 142 8.6.2. Transition Out of RECOVER-WAIT State . . . . . . . . 62 143 8.7. RECOVER-DONE State . . . . . . . . . . . . . . . . . . . 62 144 8.7.1. Operation in RECOVER-DONE State . . . . . . . . . . . 62 145 8.7.2. Transition Out of RECOVER-DONE State . . . . . . . . 63 146 8.8. NORMAL State . . . . . . . . . . . . . . . . . . . . . . 63 147 8.8.1. Operation in NORMAL State . . . . . . . . . . . . . . 63 148 8.8.2. Transition Out of NORMAL State . . . . . . . . . . . 64 149 8.9. COMMUNICATIONS-INTERRUPTED State . . . . . . . . . . . . 65 150 8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State . . . . 65 151 8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State . 66 152 8.10. POTENTIAL-CONFLICT State . . . . . . . . . . . . . . . . 67 153 8.10.1. Operation in POTENTIAL-CONFLICT State . . . . . . . 68 154 8.10.2. Transition Out of POTENTIAL-CONFLICT State . . . . . 68 155 8.11. RESOLUTION-INTERRUPTED State . . . . . . . . . . . . . . 69 156 8.11.1. Operation in RESOLUTION-INTERRUPTED State . . . . . 70 157 8.11.2. Transition Out of RESOLUTION-INTERRUPTED State . . . 70 158 8.12. CONFLICT-DONE State . . . . . . . . . . . . . . . . . . . 70 159 8.12.1. Operation in CONFLICT-DONE State . . . . . . . . . . 71 160 8.12.2. Transition Out of CONFLICT-DONE State . . . . . . . 71 161 9. Dynamic DNS Considerations . . . . . . . . . . . . . . . . . 71 162 9.1. Relationship between failover and dynamic DNS update . . 72 163 9.2. Exchanging DDNS Information . . . . . . . . . . . . . . . 73 164 9.3. Adding RRs to the DNS . . . . . . . . . . . . . . . . . . 74 165 9.4. Deleting RRs from the DNS . . . . . . . . . . . . . . . . 75 166 9.5. Name Assignment with No Update of DNS . . . . . . . . . . 76 167 10. Security Considerations . . . . . . . . . . . . . . . . . . . 76 168 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 169 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 170 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 79 171 13.1. Normative References . . . . . . . . . . . . . . . . . . 79 172 13.2. Informative References . . . . . . . . . . . . . . . . . 80 173 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 175 1. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC2119]. 181 2. Glossary 183 This is a supplemental glossary that should be combined with 184 definitions in Section 3 of RFC 7031 [RFC7031]. 186 o Absolute Time 188 The time in seconds since midnight January 1, 2000 UTC, modulo 189 2^32). 191 o auto-partner-down 192 A capability where a failover server will move from 193 COMMUNICATIONS-INTERRUPTED state to PARTNER-DOWN state 194 automatically, without operator intervention. 196 o DDNS 198 Dynamic DNS. Typically used as an acronym referring to dynamic 199 update of the DNS. 201 o Delegable Prefix 203 A prefix from which other prefixes may be delegated, as described 204 in [RFC3633]. 206 o Failover endpoint 208 The failover protocol allows for there to be a unique failover 209 'endpoint' for each failover relationship in which a failover 210 server participates. The failover relationship is defined by a 211 relationship name, and includes the failover partner IP address, 212 the role this server takes with respect to that partner (primary 213 or secondary), and the prefixes associated with that relationship. 214 The failover endpoint can take actions and hold unique states. 215 Typically, there is one failover endpoint per partner (server), 216 although there may be more. 218 o Failover communication 220 All messages exchanged between partners. 222 o Independent Allocation 224 An allocation algorithm that splits the available pool of 225 resources between the primary and secondary servers that is 226 particularly well suited for vast pools (i.e. when available 227 resources are not expected to deplete). It is used for IPv6 228 address allocations. See Section 4.2.1. 230 o Lease 232 An association of a DHCPv6 client with an IPv6 address or 233 delegated prefix. 235 o MCLT 237 Maximum Client Lead Time. The fundamental relationship on which 238 much of the correctness of this protocol depends is that the lease 239 expiration time known to a DHCPv6 client MUST NOT be greater by 240 more than the MCLT beyond the partner lifetime time acknowledged 241 by that servers's failover partner. See Section 4.4. 243 o Partner 245 Name of the other DHCPv6 server that participates in failover 246 relationship. When the role (primary or secondary) is not 247 important, the other server is referred to as a "failover partner" 248 or somtimes simply "partner". 250 o Primary Server 252 First out of two DHCPv6 servers that participate in a failover 253 relationship. When both servers are operating this server handles 254 most of the client traffic. Its failover partner is referred to 255 as secondary server. 257 o Proportional Allocation 259 An allocation algorithm that splits the available resources 260 between the primary and secondary servers and maintains a more or 261 less fixed proportion of the available resources between both 262 servers. It is particularly well suited for more limited 263 resources. It is used for allocations of delegated prefixes. See 264 Section 4.2.2. 266 o Resource 268 Any type of resource that is managed by DHCPv6. Currently there 269 are three types of such resources defined: a non-temporary IPv6 270 address, a temporary IPv6 address, and an IPv6 delegated prefix. 271 Only the non-temporary IPv6 addresses and IPv6 delegated prefixes 272 are involved in DHCPv6 failover. 274 o Responsive 276 A server that is responsive will respond to DHCPv6 client 277 requests. 279 o Secondary Server 281 Second of two DHCPv6 servers that participate in a failover 282 relationship. Its failover partner is referred to as the primary 283 server. When both servers are operating this server (the 284 secondary) typically does not handle client traffic and acts as a 285 backup to the primary server. 287 o Server 288 A DHCPv6 server that implements DHCPv6 failover. 'Server' and 289 'failover endpoint' are synonymous only if the server participates 290 in only one failover relationship. 292 o Unresponsive 294 A server that is unresponsive will not respond to DHCPv6 client 295 requests. 297 3. Introduction 299 The failover protocol provides a means for cooperating DHCPv6 servers 300 to work together to provide a DHCPv6 service with availability that 301 is increased beyond that which could be provided by a single DHCPv6 302 server operating alone. It is designed to protect DHCPv6 clients 303 against server unreachability, including server failure and network 304 partition. It is possible to deploy exactly two servers that are 305 able to continue providing a lease on an IPv6 address [RFC3315] or on 306 an IPv6 prefix [RFC3633] without the DHCPv6 client experiencing lease 307 expiration or a reassignment of a lease to a different IPv6 address 308 (or prefix) in the event of failure by one or the other of the two 309 servers. 311 This protocol defines an active-passive mode, sometimes also called a 312 hot standby model. This means that during normal operation one 313 server is active (i.e. actively responds to clients' requests) while 314 the second is passive (i.e. it receives clients' requests, but does 315 not respond to them and only maintains a copy on the binding database 316 and is ready to take over incoming queries in case of primary server 317 failure). 319 The failover protocol is designed to provide lease stability for 320 leases with lease times beyond a short period. Due in part to the 321 additional overhead required as well as requirements to handle time 322 skew between failover partners (See Section 7.1) failover is not 323 suitable for leases shorter than 30 seconds. The DHCPv6 Failover 324 protocol MUST NOT be used for leases shorter than 30 seconds. 326 This protocol fulfills all DHCPv6 failover requirements defined in 327 [RFC7031]. 329 4. Failover Concepts and Mechanisms 331 4.1. Required Server Configuration 333 Servers frequently have several kinds of resources available on a 334 particular network segment. The failover protocol assumes that both 335 primary and secondary servers are configured identically with regard 336 to the prefixes and links involved in DHCPv6. For delegated prefixes 337 (involved in proportional allocation) the primary server is 338 responsible for allocating to the secondary server the correct 339 proportion of the available delegated prefixes. IPv6 addresses 340 (involved in independent allocation) are allocated to the primary and 341 secondary servers algorithmically, and do not require an explicit 342 message transfer to be distributed. 344 4.2. IPv6 Address and Delegable Prefix Allocation 346 Currently there are two allocation algorithms defined for resources 347 (IPv6 addresses or delegable prefixes). 349 4.2.1. Independent Allocation 351 In this allocation scheme, used for allocating individual DHCPv6 IPv6 352 addresses, available IPv6 addresses are permanently (until server 353 configuration changes) split between servers. Available IPv6 354 addresses are split between the primary and secondary servers as part 355 of initial connection establishment. Once IPv6 addresses are 356 allocated to each server, there is no need to reassign them. The 357 IPv6 address allocation is algorithmic in nature, and does not 358 require a message exchange for each IPv6 address allocated. This 359 algorithm is simpler than proportional allocation since it does not 360 require a rebalancing mechanism. It assumes that the pool assigned 361 to each server will never deplete. 363 Once each server is assigned a pool of IPv6 addresses during initial 364 connection establishment, it may allocate its assigned IPv6 addresses 365 to clients. Once a client releases a resource or its lease on an 366 IPv6 address expires, the returned IPv6 address returns to the pool 367 for the server that leased it. A lease on an IPv6 address can be 368 renewed by any responsive server. When an IPv6 address goes FREE* it 369 is owned by whichever server it is allocated to by the independent 370 allocation algorithm. 372 IPv6 addresses (which use the independent allocation approach) are 373 ignored when a server processes a POOLREQ message. 375 During COMMUNICATION-INTERRUPTED events, a partner MAY continue 376 extending existing leases when requested by clients. A healthy 377 partner MUST NOT lease IPv6 addresses that were assigned to its 378 downed partner and later released by a client unless it is in 379 PARTNER-DOWN state. When it is in PARTNER-DOWN state, a server 380 SHOULD use its own pool first and then it can start making new 381 assignments from its downed partner's pool. 383 4.2.1.1. Independent Allocation Algorithm 385 For every prefix from which IPv6 addresses can be allocated, the 386 primary server MUST allocate only IPv6 addresses when the low-order 387 bit (i.e., bit 15) is equal to 1, and the secondary server MUST 388 allocate only the IPv6 addresses when the low-order bit (i.e., bit 389 15) is equal to 0. 391 4.2.2. Proportional Allocation 393 In this allocation scheme, each server has its own pool of prefixes 394 available for delegation. Remaining available delegeable prefixes 395 are split between the primary and secondary servers in a configured 396 proportion. Note that a delegable prefix is not "owned" by a 397 particular server throughout its entire lifetime. Only a delegable 398 prefix which is available is "owned" by a particular server -- once 399 it has been leased to a client, it is not owned by either failover 400 partner. When it finally becomes available again, it will be owned 401 initially by the primary server, and it may or may not be allocated 402 to the secondary server by the primary server. 404 The flow of a delegable prefix is as follows: initially a delegable 405 prefix is owned by the primary server. It may be allocated to the 406 secondary server if it is available, and then it is owned by the 407 secondary server. Either server can allocate available delegable 408 prefixes which they own to clients, in which case they cease to own 409 them. When the client releases the delegated prefix or the lease on 410 it expires, it will again become available and will be owned by the 411 primary. 413 Pools governed by proportional allocation are used for allocation 414 when the server is in all states, except PARTNER-DOWN. In PARTNER- 415 DOWN state the operational partner can allocate from either pool 416 (both its own, and its partner's after some time constraints have 417 elapsed). The allocation and maintenance of these address pools is 418 important, since the goal is to maintain a more or less constant 419 ratio of available addresses between the two servers. 421 The initial allocation when the servers first integrate is triggered 422 by the POOLREQ message from the secondary to the primary. This is 423 followed (at some point) by the POOLRESP message where the primary 424 tells the secondary that it received and processed the POOLREQ 425 message. The primary sends the allocated delegable prefixes to the 426 secondary via BNDUPD messages. The POOLRESP message may be sent 427 before, during, or at the completion of the BNDUPD message exchanges 428 that were triggered by the POOLREQ message. The POOLREQ/POOLRESP 429 message exchange is a trigger to the primary to perform a scan of its 430 database and to ensure that the secondary has enough delegable 431 prefixes (based on some configured ratio). 433 The delegable prefixes are sent to the secondary using the BNDUPD 434 message with a state of FREE_BACKUP, which indicates the delegable 435 prefix is now available for allocation by the secondary. Once the 436 message is sent, the primary MUST NOT use these prefixes for 437 allocation to DHCPv6 clients. 439 The POOLREQ/POOLRESP message exchange initiated by the secondary is 440 valid at any time both partners remain in contact, and the primary 441 server SHOULD, whenever it receives the POOLREQ message, scan its 442 database of prefixes and determine if the secondary needs more 443 delegable prefixes from any of the delegable prefixes which it 444 currently owns. 446 In order to support a reasonably dynamic balance of the resources 447 between the failover partners, the primary server needs to do 448 additional work to ensure that the secondary server has as many 449 delegable prefixes as it needs (but that it doesn't have more than it 450 needs). 452 The primary server SHOULD examine the balance of delegable prefixes 453 between the primary and secondary for a particular prefix whenever 454 the number of available prefixes for either the primary or secondary 455 changes by more than a configured limit. The primary server SHOULD 456 adjust the delegable prefix balance as required to ensure the 457 configured delegable prefix balance, excepting that the primary 458 server SHOULD employ some threshold mechanism to such a balance 459 adjustment in order to minimize the overhead of maintaining this 460 balance. 462 An example of a threshold approach is: do not attempt to re-balance 463 the prefixes on the primary and secondary until the out of balance 464 value exceeds a configured value. 466 The primary server can, at any time, send an available delegable 467 prefix to the secondary using a BNDUPD with the state FREE_BACKUP. 468 The primary server can attempt to take an available delegable prefix 469 away from the secondary by sending a BNDUPD with the state FREE. If 470 the secondary accepts the BNDUPD, then the resource is now available 471 to the primary and not available to the secondary. Of course, the 472 secondary MUST reject that BNDUPD if it has already used that 473 resource for a DHCPv6 client. 475 4.2.2.1. Re-allocating Leases 477 When in PARTNER-DOWN state there is a waiting period after which a 478 delegated prefix can be re-allocated to another client. For 479 delegable prefixes which are available when the server enters 480 PARTNER-DOWN state, the period is the MCLT from the entry into 481 PARTNER-DOWN state. For delegated prefixes which are not available 482 when the server enters PARTNER-DOWN state, the period is the MCLT 483 after the later of the following times: the acked-partner-lifetime, 484 the partner-lifetime (if any), and the expiration-time. If this time 485 would be earlier than the current time plus the MCLT, then the time 486 the server entered PARTNER-DOWN state plus the maximum-client-lead- 487 time is used. 489 In any other state, a server cannot reallocate a delegated prefix 490 from one client to another without first notifying its partner 491 (through a BNDUPD message) and receiving acknowledgement (through a 492 BNDACK message) that its partner is aware that the first client is 493 not using the resource. 495 This may be modeled in the following way. 497 An "available" delegable prefix on a server may be allocated to any 498 client. A prefix which was delegated (leased) to a client and which 499 expired or was released by that client would take on a new state, 500 EXPIRED or RELEASED respectively. The partner server would then be 501 notified that this delegated prefix was EXPIRED or RELEASED through a 502 BNDUPD. When the sending server received the BNDACK for that 503 delegated prefix showing it was FREE, it would move the resource from 504 EXPIRED or RELEASED to FREE, and it would be available for allocation 505 by the primary server to any clients. 507 A server MAY reallocate a delegated prefix in the EXPIRED or RELEASED 508 state to the same client with no restrictions provided it has not 509 sent a BNDUPD message to its partner. This situation would exist if 510 the lease expired or was released after the transition into PARTNER- 511 DOWN state, for instance. 513 4.3. Lazy Updates 515 The DHCPv6 Failover Requirements document includes the requirement 516 that failover must not introduce significant performance impact on 517 server response times (See Sections 7 and 5.2.2 of [RFC7031] ). In 518 order to realize this requirement a server implementing the failover 519 protocol must be able respond to a DHCPv6 client without waiting to 520 update its failover partner whenever the binding database changes. 521 The lazy update mechanism allows a server to allocate a new lease or 522 extend an existing lease, respond to the DHCPv6 client, and then 523 update its failover partner as time permits. 525 Although the lazy update mechanism does not introduce additional 526 delays in server response times, it introduces other difficulties. 527 The key problem with lazy update is that when a server fails after 528 updating a DHCPv6 client with a particular lease time and before 529 updating its failover partner, the failover partner will eventually 530 believe that the client's lease has expired -- even though the DHCPv6 531 client still retains a valid lease on that address or prefix. It is 532 also possible that the failover partner will have no record at all of 533 the lease of the resource to the DHCPv6 client. Both of these issues 534 are dealt with by use of the MCLT when allocating or extending leases 535 (see Section 4.4). 537 4.4. Maximum Client Lead Time (MCLT) 539 In order to handle problems introduced by lazy updates (see 540 Section 4.3), a period of time known as the "Maximum Client Lead 541 Time" (MCLT) is defined and must be known to both the primary and 542 secondary servers. Proper use of this time interval places an upper 543 bound on the difference allowed between the lease time provided to a 544 DHCPv6 client by a server and the lease time known by that server's 545 failover partner. 547 The MCLT is typically much less than the lease time that a server has 548 been configured to offer a client, and so some strategy must exist to 549 allow a server to offer the configured lease time to a client. 550 During a lazy update the updating server updates its failover partner 551 with a partner lifetime which is longer than the lease time 552 previously given to the DHCPv6 client and which is longer than the 553 lease time that the server has been configured to give a client. 554 This allows the server to give the configured lease time to the 555 client the next time the client renews its lease, since the time that 556 it will give to the client will not be longer than the MCLT beyond 557 the partner lifetime acknowledged by its partner. 559 The fundamental relationship on which this protocol depends is: the 560 lease expiration time known to a DHCPv6 client MUST NOT be greater by 561 more than the MCLT beyond the partner lifetime acknowledged by that 562 server's failover partner. 564 The remainder of this section makes the above fundamental 565 relationship more explicit. 567 This protocol requires a DHCPv6 server to deal with several different 568 lease intervals and places specific restrictions on their 569 relationships. The purpose of these restrictions is to allow the 570 other server in the pair to be able to make certain assumptions in 571 the absence of an ability to communicate between servers. 573 In the following explanation, all of the lifetimes are "valid" 574 lifetimes, in the context of [RFC3315]. 576 The different times are: 578 desired lifetime: 579 The desired lifetime is the lease interval that a DHCPv6 server 580 would like to give to a DHCPv6 client in the absence of any 581 restrictions imposed by the failover protocol. Its determination 582 is outside of the scope of this protocol. Typically this is the 583 result of external configuration of a DHCPv6 server. 585 actual lifetime: 586 The actual lifetime is the lease interval that a DHCPv6 server 587 gives out to a DHCPv6 client. It may be shorter than the desired 588 lifetime (as explained below). 590 partner lifetime: 591 The partner lifetime is the lease expiration interval the local 592 server tells to its partner in a BNDUPD message. 594 acknowledged partner lifetime: 595 The acknowledged partner lifetime is the partner lifetime the 596 partner server has most recently acknowledged in a BNDACK message. 598 4.4.1. MCLT example 600 The following example demonstrates the MCLT concept in practice. The 601 values used are arbitrarily chosen and are not a recommendation for 602 actual values. The MCLT in this case is 1 hour. The desired 603 lifetime is 3 days, and its renewal time is half the lifetime. 605 When a server makes an offer for a new lease on an IPv6 address to a 606 DHCPv6 client, it determines the desired lifetime (in this case, 3 607 days). It then examines the acknowledged partner lifetime (which in 608 this case is zero) and determines the remainder of the time left to 609 run, which is also zero. It adds the MCLT to this value. Since the 610 actual lifetime cannot be allowed to exceed the remainder of the 611 current acknowledged partner lifetime plus the MCLT, the offer made 612 to the client is for the remainder of the current acknowledged 613 partner lifetime (i.e. zero) plus the MCLT. Thus, the actual 614 lifetime is 1 hour (the MCLT). 616 Once the server has sent the REPLY to the DHCPv6 client, it will 617 update its failover partner with the lease information using a BNDUPD 618 message. However, the desired partner lifetime will be composed of 619 one half of the current actual lifetime added to the desired 620 lifetime. Thus, the failover partner is updated with a BNDUPD with a 621 partner lifetime of 1/2 hour + 3 days. 623 When the primary server receives a BNDACK to its update of the 624 secondary server's (partner's) partner lifetime, it records that as 625 the acknowledged partner lifetime. A server MUST NOT send a BNDACK 626 in response to a BNDUPD message until it is sure that the information 627 in the BNDUPD message has been updated in its lease database. See 628 Section 7.8. Thus, the primary server in this case can be sure that 629 the secondary server has recorded the parnter lease interval in its 630 stable storage when the primary server receives a BNDACK message from 631 the secondary server. 633 When the DHCPv6 client attempts to renew at T1 (approximately one 634 half an hour from the start of the lease), the primary server again 635 determines the desired lifetime, which is still 3 days. It then 636 compares this with the original acknowledged partner lifetime (1/2 637 hour + 3 days) and adjusts for the time passed since the secondary 638 was last updated (1/2 hour). Thus the time remaining of the 639 acknowledged partner interval is 3 days. Adding the MCLT to this 640 yields 3 days plus 1 hour, which is more than the desired lifetime of 641 3 days. So the client may have its lease renewed for the desired 642 lifetime -- 3 days. 644 When the primary DHCPv6 server updates the secondary DHCPv6 server 645 after the DHCPv6 client's renewal REPLY is complete, it will 646 calculate the desired partner lifetime as the T1 fraction of the 647 actual client lifetime (1/2 of 3 days this time = 1.5 days). To this 648 it will add the desired client lifetime of 3 days, yielding a total 649 desired partner lifetime of 4.5 days. In this way, the primary 650 attempts to have the secondary always "lead" the client in its 651 understanding of the client's lifetime so as to be able to always 652 offer the client the desired client lifetime. 654 Once the initial actual client lifetime of the MCLT is past, the 655 protocol operates effectively like the DHCPv6 protocol does today in 656 its behavior concerning lifetimes. However, the guarantee that the 657 actual client lifetime will never exceed the remaining acknowledged 658 partner server partner lifetime by more than the MCLT allows full 659 recovery from a variety of DHCPv6 server failures. 661 5. Message and Option Definitions 662 5.1. Message Framing for TCP 664 Failover communication is conducted over a TCP connection established 665 between the partners. The protocol uses the framing format specified 666 in Section 5.1 of DHCPv6 Bulk Leasequery [RFC5460], but uses 667 different message types with a different message format, described in 668 Section 5.2. All information is sent over the connection as typical 669 DHCPv6 messages that convey DHCPv6 options, following the format 670 defined in Section 22.1 of [RFC3315]. 672 5.2. Failover Message Format 674 All Failover messages defined below share a common format with a 675 fixed size header and a variable format area for options. All values 676 in the message header and in any included options are in network byte 677 order. 679 The following diagram illustrates the format of DHCPv6 messages 680 exchanged between failover partners (which is compatible with the 681 format described in Section 6 of [RFC3315]): 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | msg-type | transaction-id | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | sent-time | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | . 691 . options . 692 . (variable) . 693 . | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 msg-type Identifies the DHCPv6 message type; the 697 available message types are listed in 698 below. 700 transaction-id The transaction ID for this message exchange. 702 sent-time The time the message was transmitted (set 703 as close to transmission as practical), 704 in seconds since midnight (UTC), 705 January 1, 2000, modulo 2^32. Used to 706 determine the time skew of the failover 707 partners. 709 options Options carried in this message. 711 5.3. Messages 713 The following list contains the new message types created for 714 failover communication. 716 5.3.1. BNDUPD 718 The binding update message BNDUPD (TBD1) is used to send the binding 719 lease changes to the partner. One message may contain one or more 720 lease updates. The partner is expected to respond with a BNDACK 721 message. 723 5.3.2. BNDACK 725 The binding acknowledgement message BNDACK (TBD2) is used for 726 confirmation of the received BNDUPD message. It may contain a 727 positive or negative response (e.g. due to detected lease conflict). 729 5.3.3. POOLREQ 731 The Pool Request message POOLREQ (TBD3) is used by the secondary 732 server to request allocation of resources (addresses or prefixes) 733 from the primary server. The primary responds with POOLRESP. 735 5.3.4. POOLRESP 737 The Pool Response POOLRESP (TBD4) message is used by the primary 738 server to indicate that it has responded to the secondary's request 739 for resource allocation. 741 5.3.5. UPDREQ 743 The update request message UPDREQ (TBD5) is used by one server to 744 request that its partner send all binding database changes that have 745 not yet been confirmed. The partner is expected to respond with zero 746 or more BNDUPD messages, followed by an UPDDONE message that signals 747 that all of the BNDUPD messages have been sent and a corresponding 748 BNDACK message has been received for each of them. 750 5.3.6. UPDREQALL 752 The update request all UPDREQALL (TBD6) is used by one server to 753 request that all binding database information present in the other 754 server be sent to the requesting server, in order to recover from a 755 total loss of its binding database by the requesting server. A 756 server receiving this request responds with zero or more BNDUPD 757 messages, followed by an UPDDONE that signals that all of the BNDUPD 758 messages have been sent and a corresponding BNDACK message has been 759 received for each of them. 761 5.3.7. UPDDONE 763 The update done message UPDDONE (TBD7) is used by the server 764 responding to an UPDREQ or UPDREQALL to indicate that all requested 765 updates have been sent by the responding server and acked by the 766 requesting server. 768 5.3.8. CONNECT 770 The connect message CONNECT (TBD8) is used by the primary server to 771 establish a failover connection with the secondary server, and to 772 transmit several important configuration data items between the 773 servers. The partner is expected to confirm by responding with 774 CONNECTACK message. 776 5.3.9. CONNECTACK 778 The connect acknowledgement message CONNECTACK (TBD9) is used by the 779 secondary server to respond to a CONNECT message from the primary 780 server. 782 5.3.10. DISCONNECT 784 The disconnect message DISCONNECT (TBD10) is used by either server 785 when closing a connection and shutting down. No response is required 786 for this message. The DISCONNECT message SHOULD contain an 787 OPTION_STATUS_CODE option with an appropriate status. Often this 788 will be ServerShuttingDown. See Section 5.5. A server SHOULD 789 include a descriptive message as to the reasons causing the 790 disconnect message. 792 5.3.11. STATE 794 The state message STATE (TBD11) is used by either server to inform 795 its partner about a change of failover state. In some cases it may 796 be used to also inform the partner about the current state, e.g. 797 after connection is established in COMMUNICATIONS-INTERRUPTED or 798 PARTNER-DOWN states. 800 5.3.12. CONTACT 802 The contact message CONTACT (TBD12) is used by either server to 803 ensure that its partner continues to see the connection as 804 operational. It MUST be transmitted periodically over every 805 established connection if other message traffic is not flowing, and 806 it MAY be sent at any time. See Section 6.5. 808 5.4. Options 810 The following new options are defined. 812 5.4.1. OPTION_F_BINDING_STATUS 814 The binding-status represents an implementation independent 815 representation of the status (or the state) of a resource (IPv6 816 address or prefix). 818 This is an unsigned byte. 820 The code for this option is TBD13. 822 0 1 2 3 823 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 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | OPTION_F_BINDING_STATUS | option-len | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | binding-status| 828 +-+-+-+-+-+-+-+-+ 830 option-code OPTION_F_BINDING_STATUS (TBD13). 831 option-len 1. 832 binding-status The binding status. See below. 834 Value binding-status 835 ----- -------------- 836 0 reserved 837 1 ACTIVE 838 2 EXPIRED 839 3 RELEASED 840 4 FREE* 841 5 FREE 842 6 FREE_BACKUP 843 7 ABANDONED 844 8 RESET 846 The binding-status values are discussed in Section 7.2 848 5.4.2. OPTION_F_DNS_REMOVAL_INFO 850 This option contains the information necessary to remove a DNS name 851 that was entered by the failover partner. 853 The code for this option is TBD14. 855 0 1 2 3 856 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 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | OPTION_F_DNS_REMOVAL_INFO | option-len | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | sub-options | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 option-code OPTION_F_DNS_REMOVAL_INFO (TBD14). 864 option-len 4. 865 sub-options Three possible sub-options: 866 OPTION_F_DNS_HOST_NAME 867 OPTION_F_DNS_ZONE_NAME 868 OPTION_F_DNS_FLAGS 870 5.4.3. OPTION_F_DNS_HOST_NAME 872 Contains the host name that was entered into DNS by the failover 873 partner. 875 This is a DNS name encoded in [RFC1035] format as specified in 876 Section 8 of [RFC3315]. 878 This is a suboption of OPTION_F_DNS_REMOVAL_INFO. The suboption code 879 for this suboption is 1. 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | OPTION_F_DNS_HOST_NAME | option-len | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | . 887 . . 888 . host-name . 889 . (variable) . 890 . | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 option-code OPTION_F_DNS_HOST_NAME (1). 894 option-len 0 + length of host-name. 895 host-name RFC 1035 encoded host-name. 897 5.4.4. OPTION_F_DNS_ZONE_NAME 899 Contains the zone name that was entered into DNS by the failover 900 partner. 902 This is a DNS name encoded in [RFC1035] format as specified in 903 Section 8 of [RFC3315]. 905 This is a suboption of OPTION_F_DNS_REMOVAL_INFO. The suboption code 906 for this suboption is 2. 908 0 1 2 3 909 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 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | OPTION_F_DNS_ZONE_NAME | option-len | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | . 914 . . 915 . zone-name . 916 . (variable) . 917 . | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 option-code OPTION_F_DNS_ZONE_NAME (2). 921 option-len 0 + length of zone-name. 922 zone-name RFC 1035 encoded zone name. 924 5.4.5. OPTION_F_DNS_FLAGS 926 Flags which indicate what needs to be done to remove this DNS name. 928 This consists an unsigned 16 bit value in network byte order. 930 This is a suboption of OPTION_F_DNS_REMOVAL_INFO. The suboption code 931 for this suboption is 3. 933 0 1 2 3 934 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 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | OPTION_F_DNS_FLAGS | option-len | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | flags | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 option-code OPTION_F_DNS_FLAGS (3). 942 option-len 2. 943 flags flag bits, see below: 945 0 1 2 3 4 5 6 7 946 +-+-+-+-+-+-+-+-+ 947 | MBZ |U|S|R|F| 948 +-+-+-+-+-+-+-+-+ 950 The bits (numbered from the least-significant bit in network 951 byte-order) are used as follows: 953 4 (U): USING_REQUESTED_FQDN 954 Set to 1 to indicate that name used came from the 955 FQDN that was received from the client. 956 5 (S): SYNTHESIZED_NAME 957 Set to 1 to indicate that the name was synthesized 958 based on some algorithm. 959 6 (R): REV_UPTODATE 960 Set to 1 to indicate that the reverse zone is up to date. 961 7 (F): FWD_UPTODATE 962 Set to 1 to indicate that the forward zone is up to date. 963 0-3 : MBZ 964 Must be zero 966 5.4.6. OPTION_F_EXPIRATION_TIME 968 The greatest lifetime that this server has ever acked to its partner 969 in a BNDACK. This MUST be an absolute time (i.e. seconds since 970 midnight January 1, 2000 UTC, modulo 2^32). 972 This is an unsigned 32 bit integer in network byte order. 974 The code for this option is TBD15. 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | OPTION_F_EXPIRATION_TIME | option-len | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | expiration-time | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 option-code OPTION_F_EXPIRATION_TIME (TBD15). 985 option-len 4. 986 expiration-time The expiration time. This MUST be an 987 absolute time (i.e. seconds since midnight 988 January 1, 2000 UTC, modulo 2^32). 990 5.4.7. OPTION_F_MAX_UNACKED_BNDUPD 992 The maximum number of BNDUPD messages that this server is prepared to 993 accept over the TCP connection without causing the TCP connection to 994 block. 996 This is an unsigned 32 bit integer in network byte order. 998 The code for this option is TBD16. 1000 0 1 2 3 1001 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 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | OPTION_F_MAX_UNACKED_BNDUPD | option-len | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | max-unacked-bndupd | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 option-code OPTION_F_MAX_UNACKED_BNDUPD (TBD16). 1009 option-len 4. 1010 max-unacked-bndupd Maximum number of unacked BNDUPD message 1011 allowed. 1013 5.4.8. OPTION_F_MCLT 1015 The maximum-client-lead-time (MCLT) is the is the upper bound on the 1016 difference allowed between the lease time provided to a DHCPv6 client 1017 by a server and the lease time known by that server's failover 1018 partner. It is an interval, measured in seconds. See Section 4.4. 1020 This is an unsigned 32 bit integer in network byte order. 1022 The code for this option is TBD17. 1024 0 1 2 3 1025 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 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | OPTION_F_MCLT | option-len | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | mclt | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 option-code OPTION_F_MCLT (TBD17). 1033 option-len 4. 1034 mclt The maximum-client-lease-time, in seconds. 1036 5.4.9. OPTION_F_PARTNER_LIFETIME 1038 The time after which the partner can consider an IPv6 address expired 1039 and is able to re-use the IPv6 address. This MUST be an absolute 1040 time (i.e. seconds since midnight January 1, 2000 UTC, modulo 2^32). 1042 This is an unsigned 32 bit integer in network byte order. 1044 The code for this option is TBD18. 1046 0 1 2 3 1047 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 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | OPTION_F_PARTNER_LIFETIME | option-len | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | partner-lifetime | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 option-code OPTION_F_PARTER_LIFETIME (TBD18). 1055 option-len 4. 1056 partner-lifetime The partner-lifetime. This MUST be an 1057 absolute time (i.e. seconds since midnight 1058 January 1, 2000 UTC, modulo 2^32). 1060 5.4.10. OPTION_F_PARTNER_LIFETIME_SENT 1062 The time that was received in an OPTION_F_PARTNER_LIFETIME 1063 Section 5.4.9 option. This is an exact duplicate (echo) of the time 1064 received in the OPTION_F_PARTNER_LIFETIME option, uncorrected and 1065 unadjusted in any way. This MUST be an absolute time (i.e. seconds 1066 since midnight January 1, 2000 UTC, modulo 2^32). 1068 This is an unsigned 32 bit integer in network byte order. 1070 The code for this option is TBD19. 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 |OPTION_F_PARTNER_LIFETIME_SENT | option-len | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | partner-lifetime-sent | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 option-code OPTION_F_PARTNER_LIFETIME_SENT (TBD19). 1081 option-len 4. 1082 partner-lifetime-sent The partner-lifetime received in an 1083 OPTION_F_PARTNER_LIFETIME option. 1084 This MUST be an absolute time 1085 (i.e. seconds since midnight 1086 January 1, 2000 UTC, modulo 2^32). 1088 5.4.11. OPTION_F_PARTNER_DOWN_TIME 1090 The time that the partner most recently lost commmunications with its 1091 failover partner. This MUST be an absolute time (i.e. seconds since 1092 midnight January 1, 2000 UTC, modulo 2^32). 1094 This is an unsigned 32 bit integer in network byte order. 1096 The code for this option is TBD20. 1098 0 1 2 3 1099 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 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | OPTION_F_PARTNER_DOWN_TIME | option-len | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | partner-down-time | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 option-code OPTION_F_PARTNER_DOWN_TIME (TBD20). 1107 option-len 4. 1108 partner-down-time Contains the partner-down-time. This MUST be an 1109 absolute time (i.e. seconds since midnight 1110 January 1, 2000 UTC, modulo 2^32). 1112 5.4.12. OPTION_F_PARTNER_RAW_CLT_TIME 1114 The time when the partner most recently interacted with the DHCPv6 1115 client associated with this IPv6 address. This MUST be an absolute 1116 time (i.e. seconds since midnight January 1, 2000 UTC, modulo 2^32). 1117 This time is uncorrected for clock skew, and remains in the time 1118 context of the partner server. 1120 This is an unsigned 32 bit integer in network byte order. 1122 The code for this option is TBD21. 1124 0 1 2 3 1125 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 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | OPTION_F_PARTNER_RAW_CLT_TIME | option-len | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | partner-raw-clt-time | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 option-code OPTION_F_PARTNER_RAW_CLT_TIME (TBD21). 1133 option-len 4. 1134 partner-raw-clt-time Contains the partner-raw-clt-time. This MUST 1135 be an absolute time (i.e. seconds since 1136 midnight January 1, 2000 UTC, modulo 2^32). 1138 5.4.13. OPTION_F_PROTOCOL_VERSION 1140 The protocol version allows the one failover partner to determine the 1141 version of the protocol being used by the other partner, to allow for 1142 changes and upgrades in the future. 1144 This is an unsigned integer in network byte order. 1146 The code for this option is TBD22. 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | OPTION_F_PROTOCOL_VERSION | option-len | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | protocol-version | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 option-code OPTION_F_PROTOCOL_VERSION (TBD22). 1157 option-len 4. 1158 protocol-version The version of the protocol. 1160 5.4.14. OPTION_F_RECEIVE_TIME 1162 The number of seconds (an interval) within which the server must 1163 receive a message from its partner, or it will assume that 1164 communications from the partner is not ok. 1166 This is an unsigned 32 bit integer in network byte order. 1168 The code for this option is TBD23. 1170 0 1 2 3 1171 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 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | OPTION_F_RECEIVE_TIME | option-len | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | receive-time | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 option-code OPTION_F_RECEIVE_TIME (TBD23). 1179 option-len 4. 1180 receive-time The receive-time. An interval of seconds. 1182 5.4.15. OPTION_F_RECONFIGURE_DATA 1184 Contains the information necessary for one failover partner to use 1185 the reconfigure-key created on the other failover partner. 1187 The code for this option is TBD24. 1189 0 1 2 3 1190 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 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | OPTION_F_RECONFIGURE_DATA | option-len | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | reconfigure-time | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | . 1197 . . 1198 . reconfigure-key . 1199 . (variable) . 1200 . | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 option-code OPTION_F_RECONFIGURE_DATA (TBD24). 1204 option-len 4 + length of reconfigure-key. 1205 reconfigure-time Time at which reconfigure-key was created. 1206 This MUST be an absolute time (i.e. seconds 1207 since midnight 1208 January 1, 2000 UTC, modulo 2^32). 1209 reconfigure-key The reconfigure-key. 1211 5.4.16. OPTION_F_RELATIONSHIP_NAME 1213 A name for this failover relationshiop. 1215 A UTF-8 encoded text string suitable for display to an end user, 1216 which MUST NOT be null-terminated. 1218 The code for this option is TBD25. 1220 0 1 2 3 1221 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 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | OPTION_F_RELATIONSHIP_NAME | option-len | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 | . 1226 . . 1227 . relationship-name . 1228 . (variable) . 1229 . | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 option-code OPTION_F_RELATIONSHIP_NAME (TBD25). 1233 option-len 0 + length of relationship-name. 1234 relationship-name A UTF-8 encoded text string suitable for 1235 display to an end user, which MUST NOT be 1236 null-terminated. 1238 5.4.17. OPTION_F_SERVER_FLAGS 1240 The OPTION_F_SERVER_FLAGS option specifies information associated 1241 with the failover endpoint sending the option. 1243 This is an unsigned byte. 1245 The code for this option is TBD26. 1247 0 1 2 3 1248 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 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | OPTION_F_SERVER_FLAGS | option-len | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | server-flags | 1253 +-+-+-+-+-+-+-+-+ 1255 option-code OPTION_F_SERVER_FLAGS (TBD26). 1256 option-len 1. 1257 server-flags The server flags, see below: 1259 0 1 2 3 4 5 6 7 1260 +-+-+-+-+-+-+-+-+ 1261 | MBZ |B|A|S|C| 1262 +-+-+-+-+-+-+-+-+ 1264 The bits (numbered from the least-significant bit in network 1265 byte-order) are used as follows: 1267 4 (B): SECONDARY (BACKUP) 1268 Indicates that the sending server is a secondary 1269 (or backup) server. 1270 5 (A): ACK_STARTUP 1271 Set to 1 to indicate that the OPTION_F_SERVER_FLAGS most 1272 recently received contained the STARTUP bit set. 1273 6 (S): STARTUP, 1274 MUST be set to 1 whenever the server is in STARTUP state. 1275 7 (C): COMMUNICATED 1276 Set to 1 to indicate that the sending server has 1277 communicated with its partner. 1278 0-3 : MBZ 1279 Must be zero 1281 5.4.18. OPTION_F_SERVER_STATE 1283 The OPTION_F_SERVER_STATE option specifies the endpoint state of the 1284 server sending the option. 1286 This is an unsigned byte. 1288 The code for this option is TBD27. 1290 0 1 2 3 1291 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 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | OPTION_F_SERVER_STATE | option-len | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | server-state | 1296 +-+-+-+-+-+-+-+-+ 1298 option-code OPTION_F_SERVER_STATE (TBD27). 1299 option-len 1. 1300 server-state Failover endpoint state. 1302 Value Server State 1303 ----- ---------------------------------------------------------- 1304 0 reserved 1305 1 STARTUP Startup state (1) 1306 2 NORMAL Normal state 1307 3 COMMUNICATIONS-INTERRUPTED Communication interrupted 1308 4 PARTNER-DOWN Partner down 1309 5 POTENTIAL-CONFLICT Synchronizing 1310 6 RECOVER Recovering bindings from partner 1311 7 SHUTDOWN Shutting down for an long period. 1312 8 RECOVER-DONE Interlock state prior to NORMAL 1313 9 RESOLUTION-INTERRUPTED Comm. failed during resolution 1314 10 CONFLICT-DONE Primary resolved its conflicts 1316 These states are discussed in detail in Section 8. 1318 (1) The STARTUP state is never sent to the partner server, it is 1319 indicated by the STARTUP bit in the server-flags options (see 1320 Section 8.3. 1322 5.4.19. OPTION_F_START_TIME_OF_STATE 1324 The time at which the associated state began to hold its current 1325 value. When this option appears in a STATE message, the state to 1326 which it refers is the server endpoint state. When it appears in an 1327 IA_NA or IA_PD message, the state to which it refers is the binding- 1328 status value in the IA_NA or IA_PD option. This MUST be an absolute 1329 time (i.e. seconds since midnight January 1, 2000 UTC, modulo 2^32). 1331 This is an unsigned 32 bit integer in network byte order. 1333 The code for this option is TBD28. 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_START_TIME_OF_STATE | option-len | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | start-time-of-state | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 option-code OPTION_F_START_TIME_OF_STATE (TBD28). 1344 option-len 4. 1345 start-time-of-state The start-time-of-state. This MUST be an 1346 absolute time (i.e. seconds since midnight 1347 January 1, 2000 UTC, modulo 2^32). 1349 5.4.20. OPTION_F_STATE_EXPIRATION_TIME 1351 The state-expiration-time is the time at which the current state of 1352 this lease will expire. This MUST be an absolute time (i.e. seconds 1353 since midnight January 1, 2000 UTC, modulo 2^32). 1355 This is an unsigned 32 bit integer in network byte order. 1357 The code for this option is TBD29. 1359 0 1 2 3 1360 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 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 | OPTION_F_STATE_EXPIRATION_TIME| option-len | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | state-expiration-time | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 option-code OPTION_F_STATE_EXPIRATION_TIME (TBD29). 1368 option-len 4. 1369 state-expiration-time The state-expiration-time. This MUST be an 1370 absolute time (i.e. seconds since midnight 1371 January 1, 2000 UTC, modulo 2^32). 1373 5.5. Status Codes 1375 The following new status codes are defined, to be used in the 1376 OPTION_STATUS_CODE option. 1378 AddressInUseByOtherClient (TBD30) 1379 The one client on one server has leased resources that are in 1380 conflict with the resources that this client has leased on another 1381 server. 1383 ConfigurationConflict (TBD31) 1384 The configuration implied by the information in a BNDUPD (e.g. the 1385 IPV6 address or prefix address) is in direct conflict with the 1386 information known to the receiving server. 1388 MissingBindingInformation (TBD32) 1389 There is insufficient information in a BNDUPD to effectively 1390 process it. 1392 OutdatedBindingInformation (TBD33) 1393 Returned when the information in a server's binding database 1394 conflicts with the information found in an incoming BNDUPD, and 1395 the server believes that the information in its binding database 1396 more accurately reflects reality. 1398 ServerShuttingDown (TBD34) 1399 Returned when the server is undergoing an operator directed or 1400 otherwise planned shutdown. 1402 6. Connection Management 1404 6.1. Creating Connections 1406 Every primary server implementing the failover protocol MUST attempt 1407 to connect to all of its configured partners periodically, where the 1408 period is implementation dependent and SHOULD be configurable. In 1409 the event that a connection has been rejected by a CONNECTACK message 1410 with a reject-reason option contained in it or a DISCONNECT message, 1411 a server SHOULD reduce the frequency with which it attempts to 1412 connect to that server but it MUST continue to attempt to connect 1413 periodically. 1415 Every secondary server implementing the failover protocol MUST listen 1416 for connection attempts from the primary server. 1418 When a primary server attempts to connect with a secondary server, it 1419 MUST do so as described in Section 8.2 of [RFC7653]. In the language 1420 of that section, the primary failover server operates as the 1421 "requestor" and the secondary failover server operates as the "DHCPv6 1422 server". The message that is sent over the newly established 1423 connection is a CONNECT message, instead of an ACTIVELEASEQUERY 1424 message. 1426 When a connection attempt is received by a secondary server, the only 1427 information that the secondary server has is the IP address of the 1428 partner initiating a connection. If it has any relationships with 1429 the connecting server for which it is a secondary server, it should 1430 operate as described in Section 9.1 of [RFC7653], with the exception 1431 that instead of waiting for an Active Leasequery message it will wait 1432 for a CONNECT message. Once it has received the CONNECT message, it 1433 will use the information in that message to determine which 1434 relationship this connection is to service. 1436 If it has no secondary relationships with the connecting server, it 1437 MUST drop the connection. 1439 To summarize -- a primary server MUST use a connection that it has 1440 initiated in order to send a CONNECT message. Every server that is a 1441 secondary server in a relationship MUST listen for CONNECT messages 1442 from the primary server. 1444 When the CONNECT and CONNECTACK exchange successfully produces a 1445 working failover connection, the next message sent over a new 1446 connection is a STATE message. See Section 6.3. Upon the receipt of 1447 the STATE message, the receiver can consider communications ok. 1449 6.1.1. Sending a CONNECT message 1451 The CONNECT message is sent with information about the failover 1452 configuration on the primary server. The message MUST contain at 1453 least the following information in the options area: 1455 o OPTION_F_PROTOCOL_VERSION containing the protocol version. 1457 o OPTION_F_MCLT containing the configured MCLT. 1459 o OPTION_F_RECEIVE_TIME containing the the number of seconds (an 1460 interval) within which the server must receive a message from its 1461 partner, or it will assume that communications from the partner is 1462 not ok. 1464 o OPTION_F_UNACKED_BNDUPD containing the maximum number of BNDUPD 1465 messages that this server is prepared to accept over the failover 1466 connection without causing the connection to block. 1468 6.1.2. Receiving a CONNECT message 1470 A server receiving a CONNECT message must process the information in 1471 the message and decide whether or not accept the connection. The 1472 processing is performed as follows: 1474 o OPTION_F_PROTOCOL_VERSION - The secondary server decides if the 1475 protocol version of the primary server is supported by the 1476 secondary server. If it is not, return NotSupported in the 1477 OPTION_STATUS_CODE to reject the CONNECT message. 1479 o OPTION_F_MCLT - Compare the MCLT received with the configured 1480 MCLT, and if they are different the server MUST alert operational 1481 staff of this difference. Use the MCLT supplied by the primary 1482 server until something explicitly alters the MCLT defined on the 1483 secondary server. 1485 o OPTION_F_RECEIVE_TIME - Remember the receive-time as the 1486 FO_RECEIVE_TIME when implementing the Unreachability Detection 1487 algorithm described in Section 6.6. 1489 o OPTION_F_UNACKED_BNDUPD - Ensure that the maximum amount of 1490 unacked BNDUPD messages queued to the primary server never exceeds 1491 the value in the OPTION_F_UNACKED_BNDUPD option. 1493 A CONNECT message SHOULD always be followed by a CONNECTACK message, 1494 either to accept the connection or to reject the connection by 1495 including an OPTION_STATUS_CODE option with an error reject. In 1496 order to reject the connection attempt, simply send a CONNECTACK 1497 message with the OPTION_STATUS_CODE with the correct status. If 1498 accepting the connection attempt, then send a CONNECTACK message with 1499 the following information: 1501 o OPTION_F_PROTOCOL_VERSION containing the protocol version being 1502 used by the secondary server. 1504 o OPTION_F_MCLT containing the MCLT currently in use on the 1505 secondary server. This MUST equal the MCLT that was in the 1506 OPTION_F_MCLT option in the CONNECT. 1508 o OPTION_F_RECEIVE_TIME containing the the number of seconds (an 1509 interval) within which the server must receive a message from its 1510 partner, or it will assume that communications from the partner is 1511 not ok. 1513 o OPTION_F_UNACKED_BNDUPD containing the maximum number of BNDUPD 1514 messages that this server is prepared to accept over the failover 1515 connection without causing the connection to block. 1517 After sending a CONNECTACK message to accept the primary server's 1518 CONNECT message, the secondary server MUST send a STATE message (see 1519 Section 6.3). 1521 6.1.3. Receiving a CONNECTACK message 1523 A server receiving a CONNECTACK message must process the information 1524 in the message and decide whether or not continue to employ the 1525 connection. The processing is performed as follows: 1527 o OPTION_F_PROTOCOL_VERSION - The primary server decides if the 1528 protocol version in use by the secondary server is supported by 1529 the primary server. If it is not, send a DISCONNECT message and 1530 drop the connection. If it is supported, continue processing. 1532 o OPTION_F_MCLT - Compare the MCLT received with the configured 1533 MCLT, and if they are different send a DISCONNECT message and drop 1534 the connection. 1536 o OPTION_F_RECEIVE_TIME - Remember the receive-time as the 1537 FO_RECEIVE_TIME when implementing the Unreachability Detection 1538 algorithm described in Section 6.6. 1540 o OPTION_F_UNACKED_BNDUPD - Ensure that the maximum amount of 1541 unacked BNDUPD messages queued to the secondary server never 1542 exceeds the value in the OPTION_F_UNACKED_BNDUPD option. 1544 After receiving a CONNECTACK message that accepted the primary 1545 server's CONNECT message, the primary server MUST send a STATE 1546 message (see Section 6.3). 1548 6.2. Endpoint Identification 1550 A failover endpoint is always associated with a set of DHCPv6 1551 prefixes that are configured on the DHCPv6 server where the endpoint 1552 appears. A DHCPv6 prefix MUST NOT be associated with more than one 1553 failover endpoint. 1555 The failover protocol SHOULD be configured with one failover 1556 relationship between each pair of failover servers. In this case 1557 there is one failover endpoint for that relationship on each failover 1558 partner. This failover relationship MUST have a unique name. 1560 Any failover endpoint can take actions and hold unique states. 1562 This document frequently describes the behavior of the protocol in 1563 terms of primary and secondary servers, not primary and secondary 1564 failover endpoints. However, it is important to remember that every 1565 'server' described in this document is in reality a failover endpoint 1566 that resides in a particular process, and that several failover end- 1567 points may reside in the same server process. 1569 It is not the case that there is a unique failover endpoint for each 1570 prefix that participates in a failover relationship. On one server, 1571 there is (typically) one failover endpoint per partner, regardless of 1572 how many prefixes are managed by that combination of partner and 1573 role. On a particular server, any given prefix that participates in 1574 failover will be associated with exactly one failover endpoint. 1576 When a connection is received from the partner, the unique failover 1577 endpoint to which the message is directed is determined solely by the 1578 IPv6 address of the partner, the relationship-name, and the role of 1579 the receiving server. 1581 6.3. Sending a STATE message 1583 A server MUST send a STATE message to its failover partner whenever 1584 the state of the failover endpoint changes. Sending the occasional 1585 duplicate STATE message will cause no problems, and not updating the 1586 failover partner with information about a failover endpoint state 1587 change can, in many cases, cause the entire failover protocol to be 1588 inoperative. 1590 The STATE message is sent with information about the endpoint state 1591 of the failover relationship. The STATE message MUST contain at 1592 least the following information in the options area: 1594 o OPTION_F_SERVER_STATE containing the state of the failover 1595 endpoint. 1597 o OPTION_F_SERVER_FLAGS containing the flag values associated with 1598 this failover endpoint. 1600 o OPTION_F_START_TIME_OF_STATE containing the time when this became 1601 the state of the failover endpoint. 1603 o OPTION_F_PARTNER_DOWN_TIME containing time that this failover 1604 endpoint went into PARTNER-DOWN state if this server is in 1605 PARTNER-DOWN state. If this server isn't in PARTNER-DOWN state, 1606 do not include this option. 1608 The server sending a STATE message SHOULD ensure that this 1609 information is written to stable storage prior to enqueuing it to its 1610 failover partner. 1612 6.4. Receiving a STATE message 1614 A server receiving a STATE message must process the information in 1615 the message and decide how to react to the information. The 1616 processing is performed as follows: 1618 o OPTION_F_SERVER_STATE - If this represents a change in state for 1619 the failover partner, react according to the direction in 1620 Section 8.1. If the state is not PARTNER-DOWN, clear any memory 1621 of the partner-down-time. 1623 o OPTION_F_SERVER_FLAGS - Remember these flags in an appropriate 1624 data area so they can be referenced by code implementing other 1625 parts of this document. 1627 o OPTION_F_START_TIME_OF_STATE - Remember this information in an 1628 appropriate data area. 1630 o OPTION_F_PARTNER_DOWN_TIME - Remember this information in an 1631 appropriate data area if the value of the OPTION_F_SERVER_STATE is 1632 PARTNER-DOWN. 1634 A server receiving a STATE message SHOULD ensure that this 1635 information is written to stable storage. 1637 6.5. Connection Maintenance Parameters 1639 The following parameters and timers are used to ensure the integrity 1640 of the connections between two failover servers. 1642 Parameter Default Description 1643 ------------------------------------------ 1644 FO_RECEIVE_TIMER timer counts down to time connection 1645 assumed dead due to lack of packets 1647 FO_RECEIVE_TIME 60 maximum time server will consider 1648 connection still up with no packets 1650 FO_CONTACT_PER_RECEIVE_TIME number of CONTACT messages to send 1651 4 during partner's FO_RECEIVE_TIME 1652 period 1654 FO_SEND_TIMER timer counts down to time to send next 1655 CONTACT message 1657 FO_SEND_TIME 15 maximum time to wait between sending 1658 CONTACT packets if no other traffic 1659 Created from partner's FO_RECEIVE_TIME 1660 divided by FO_CONTACT_PER_RECEIVE_TIME 1662 FO_SKEW_AVG 10 Number of time-skew values to include 1663 in the moving average time-skew 1664 calculatin 1666 6.6. Unreachability detection 1668 Each partner MUST maintain an FO_SEND_TIMER for each failover 1669 connection. The FO_SEND_TIMER is reset to FO_SEND_TIME every time 1670 any message is transmitted, and counts down once per second. If the 1671 timer reaches zero, a CONTACT message is transmitted and timer is 1672 reset to FO_SEND_TIME. The CONTACT message may be transmitted at any 1673 time. An implementation MAY use additional mechanisms to detect 1674 partner unreachability. 1676 The FO_SEND_TIME is initialized from the configured FO_RECEIVE_TIME 1677 divided by FO_CONTACT_PER_RECEIVE_TIME. When a CONNECT or CONNECTACK 1678 message is received, the OPTION_F_RECEIVE_TIME option is checked, and 1679 if it appears then the value in that option is used to calculate the 1680 FO_SEND_TIME by dividing the value received by the configured 1681 FO_CONTACT_PER_RECEIVE_TIME. 1683 Each partner MUST maintain an FO_RECEIVE_TIMER for each failover 1684 connection. This timer is initialized to FO_RECEIVE_TIME and counts 1685 down once per second. It is reset to FO_RECEIVE_TIME whenever a 1686 packet is received. If it ever reaches zero, the connection is 1687 considered dead. In addition, the FO_RECEIVE_TIME MUST be sent to 1688 the failover partner on every CONNECT or CONNECTACK messages, in the 1689 OPTION_F_RECEIVE_TIME option. 1691 7. Binding Updates and Acks 1693 7.1. Time Skew 1695 Partners exchange information about known lease states. To reliably 1696 compare a known lease state with an update received from a partner, 1697 servers must be able to reliably compare the times stored in the 1698 known lease state with the times received in the update. Although a 1699 simple approach would be to require both partners to use synchronized 1700 time, e.g. by using the Network Time Protocol, such a service may not 1701 always be available. Therefore a mechanism to measure and track 1702 relative time differences between servers is necessary. To do so, 1703 each message contains the time of the transmission in the time 1704 context of the transmitter in the sent-time field of the message 1705 Section 5.2. The transmitting server MUST set this as close to the 1706 actual transmission as possible. The receiving partner MUST store 1707 its own timestamp of reception as close to the actual reception as 1708 possible. The received timestamp information is then compared with 1709 local timestamp. 1711 To account for packet delay variation (jitter), the measured 1712 difference is not used directly, but rather the moving average of the 1713 last FO_SKEW_AVG packets time difference is calculated. This 1714 averaged value is referred to as the time skew. Note that the time 1715 skew algorithm allows cooperation between servers with completely 1716 desynchronized clocks as well as those whose desynchronization itself 1717 is not constant. 1719 7.2. Information model 1721 In most DHCPv6 servers a resource (an IPv6 address or a prefix) can 1722 take on several different binding-status values, sometimes also 1723 called lease states. While no two DHCPv6 server implementations will 1724 have exactly the same possible binding-status values, [RFC3315] 1725 enforces some commonality among the general semantics of the binding- 1726 status values used by various DHCPv6 server implementations. 1728 In order to transmit binding database updates between one server and 1729 another using the failover protocol, some common binding-status 1730 values must be defined. It is not expected that these values 1731 correspond with any actual implementation of the DHCPv6 protocol in a 1732 DHCPv6 server, but rather that the binding-status values defined in 1733 this document should be convertable back and forth between those 1734 defined below and those in use by many DHCPv6 server implementations. 1736 The lease binding-status values defined for the failover protocol are 1737 listed below. Unless otherwise noted below, there MAY be client 1738 information associated with each of these binding-status value. 1740 ACTIVE -- The lease is assigned to a client. Client identification 1741 data MUST appear. 1743 EXPIRED -- indicates that a client's binding on a given lease has 1744 expired. When the partner acks the BNDUPD of an expired lease, 1745 the server sets its internal state to FREE*. Client identification 1746 SHOULD appear. 1748 RELEASED -- indicates that a client sent in RELEASE message. When 1749 the partner acks the BNDUPD of a released lease, the server sets 1750 its internal state to FREE*. Client identification SHOULD appear. 1752 FREE* -- Once a lease is expired or released, its state becomes 1753 FREE*. Depending on which algorithm and which pool was used to 1754 allocate a given lease, FREE* may either mean FREE or FREE_BACKUP. 1755 Implementations do not have to implement this FREE* state, but may 1756 choose to switch to the destination state directly. For a clarity 1757 of representation, this transitional FREE* state is treated as a 1758 separate state. 1760 FREE -- Is used when a DHCPv6 server needs to communicate that a 1761 resource is unused by any client, but it was not just released, 1762 expired or reset by a network administrator. When the partner 1763 acks the BNDUPD of a FREE lease, the server marks the lease as 1764 available for assignment by the primary server. Note that on a 1765 secondary server running in PARTNER-DOWN state, after waiting the 1766 MCLT, the resource MAY be allocated to a client by the secondary 1767 server. Client identification MAY appear and indicates the last 1768 client to have used this resource as a hint. 1770 FREE_BACKUP -- indicates that this resource can be allocated by the 1771 secondary server to a client at any time. Note that the primary 1772 server running in PARTNER-DOWN state, after waiting the MCLT, the 1773 resource MAY be allocated to a client by the primary server if 1774 proportional algorithm was used. Client identification MAY appear 1775 and indicates the last client to have used this resource as a 1776 hint. 1778 ABANDONED -- indicates that a lease is considered unusable by the 1779 DHCPv6 system. The primary reason for entering such state is 1780 reception of DECLINE message for the lease. Client identification 1781 MAY appear. 1783 RESET -- indicates that this resource was made available by operator 1784 command. This is a distinct state so that the reason that the 1785 resource became FREE can be determined. Client identification MAY 1786 appear. 1788 The lease state machine is presented in Figure 1. Most states are 1789 stationary, i.e. the lease stays in a given state until external 1790 event triggers transition to another state. The only transitive 1791 state is FREE*. Once it is reached, the state machine immediately 1792 transitions to either FREE or FREE_BACKUP state. 1794 +---------+ 1795 /------------->| ACTIVE |<--------------\ 1796 | +---------+ | 1797 | | | | | 1798 | /--(8)--/ (3) \--(9)-\ | 1799 | | | | | 1800 | V V V | 1801 | +-------+ +--------+ +---------+ | 1802 | |EXPIRED| |RELEASED| |ABANDONED| | 1803 | +-------+ +--------+ +---------+ | 1804 | | | | | 1805 | | | (10) | 1806 | | | V | 1807 | | | +---------+ | 1808 | | | | RESET | | 1809 | | | +---------+ | 1810 | | | | | 1811 | \--(4)--\ (4) /--(4)--/ | 1812 | | | | | 1813 (1) V V V (2) 1814 | /---------\ | 1815 | | FREE* | | 1816 | \---------/ | 1817 | | | | 1818 | /-(5)--/ \-(6)-\ | 1819 | | | | 1820 | V V | 1821 | +-------+ +-----------+ | 1822 \----| FREE |<--(7)-->|FREE_BACKUP|-----/ 1823 +-------+ +-----------+ 1825 FREE* transition 1827 Figure 1: Lease State Machine 1829 Transitions between states are results of the following events: 1831 1. Primary server allocates a lease. 1833 2. Secondary server allocates a lease. 1835 3. Client sends RELEASE and the lease is released. 1837 4. Partner acknowledges state change. This transition MAY also 1838 occur if the server is in PARTNER-DOWN state and the MCLT has 1839 passed since the entry in RELEASED, EXPIRED, or RESET states. 1841 5. The lease belongs to a pool that is governed by the 1842 proportional allocation, or independent allocation is used and 1843 this lease belongs to primary server pool. 1845 6. The lease belongs to a pool that is governed by the 1846 independent allocation and the lease belongs to the secondary 1847 server. 1849 7. Pool rebalance event occurs (POOLREQ/POOLRESP messages are 1850 exchanged). Addresses (or prefixes) belonging to the primary 1851 server can be assigned to the secondary server pool (transition 1852 from FREE to FREE_BACKUP) or vice versa. 1854 8. The lease has expired. 1856 9. DECLINE message is received or a lease is deemed unusable for 1857 other reasons. 1859 10. An administrative action is taken to recover an abandoned 1860 lease back to usable state. This transition MAY occur due to an 1861 implementation specific handling on ABANDONED resource. One 1862 possible example of such use is a Neighbor Discovery or ICMPv6 1863 Echo check if the address is still in use. 1865 The resource that is no longer in use (due to expiration or release), 1866 becomes FREE*. Depending of what allocation algorithm is used, the 1867 resource that is no longer is use, returns to the primary (FREE) or 1868 secondary pool (FREE_BACKUP). The conditions for specific 1869 transitions are depicted in Figure 2. 1871 +----------------+---------+-----------+ 1872 | \Resource owner| | | 1873 | \----------\ | Primary | Secondary | 1874 |Algorithm \ | | | 1875 +----------------+---------+-----------+ 1876 | Proportional | FREE |FREE_BACKUP| 1877 | Independent | FREE | FREE | 1878 +----------------+---------+-----------+ 1880 Figure 2: FREE* State Transitions 1882 7.3. Times Required for Exchanging Binding Updates 1884 Each server must keep track of the following specific times beyond 1885 those required by the base DHCPv6 protocol [RFC3315]. 1887 expiration-time 1888 The greatest lifteime that this server has ever acked to its 1889 failover partner in a BNDACK. 1891 acked-partner-lifetime 1892 The greatest lifetime that the failover partner has ever acked to 1893 this server in a BNDACK. 1895 partner-lifetime 1896 The time that we will send (or have sent) the partner, which will 1897 be the time after which the partner can consider the IPv6 address 1898 expired. 1900 client-last-transaction-time 1901 The time when the this server most recently intereacted with the 1902 client associated with this IPv6 address. 1904 partner-raw-clt-time 1905 The time when the partner most recently interacted with the client 1906 associated with this IPv6 address. This time remains exactly as 1907 it was received by this server, and MUST NOT be adjusted to be in 1908 the time context of this server. 1910 start-time-of-state 1911 The time when the binding status of this lease was changed to its 1912 current value. 1914 state-expiration-time 1915 The time when the current state of this lease will expire. 1917 7.4. Sending Binding Updates 1919 Each server updates its failover partner about recent changes in 1920 lease states using the BNDUPD message. Every BNDUPD message contains 1921 information about one or more client bindings. All information about 1922 a particular client binding is contained in a single 1923 OPTION_CLIENT_DATA option (see [RFC5007] Section 4.1.2.2). 1925 The OPTION_CLIENT_DATA option MUST contain at least the data shown 1926 below in its client-options section: 1928 o OPTION_CLIENTID containing the DUID of the client most recently 1929 associated with this IPv6 address*; 1931 o OPTION_LQ_BASE_TIME containing the absolute time that the 1932 information was placed into this OPTION_CLIENT_DATA option. (see 1933 [RFC7653] Section 6.3.1); 1935 o OPTION_F_RECONFIGURE_DATA containing the time and reconfigure key, 1936 if any*; 1938 o OPTION_LQ_RELAY_DATA containing information described in 1939 Section 4.1.2.4 of [RFC5007]*; 1941 o OPTION_IA_NA for an IPv6 Address or OPTION_IA_PD for an IPv6 1942 Prefix. More than one of either of these options MAY appear if 1943 there are more than one associated with this client; 1945 * IAID - Identity Association used by the client, while obtaining 1946 a given lease. (Note1: one client may use many IAIDs 1947 simultaneously. Note2: IAID for IA, TA and PD are orthogonal 1948 number spaces.)*; 1950 * T1 time sent to client*; 1952 * T2 time sent to client*; 1954 * Inside of the IA_NA-options or IA_PD-option sections: 1956 + OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for 1957 a IPv6 prefix; 1959 - IPv6 Address or IPv6 Prefix (with length); 1961 - preferred lifetime sent to client*; 1963 - valid lifetime sent to client*; 1965 - Inside of the IAaddr-options or IAprefix-options: 1967 o OPTION_F_BINDING_STATUS containing the binding-status; 1969 o OPTION_F_START_TIME_OF_STATE containing the start- 1970 time-of-state; 1972 o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing 1973 the state-expiration-time**; 1975 o OPTION_CLT_TIME (relative) containing the client-last- 1976 transaction-time. See [RFC5007] for this option*; 1978 o OPTION_F_PARTNER_LIFETIME (absolute) containing 1979 partner-lifetime**; 1981 o OPTION_F_PARTNER_RAW_CLT_TIME (absolute) containing 1982 the partner-raw-clt-time*; 1984 o OPTION_F_EXPIRATION_TIME (absolute) containing the 1985 expiration-time**; 1987 o DHCP_O_CLIENT_FQDN containing the the FQDN information 1988 associated with this resource and client*; 1990 Note that additonal data MAY be included beyond that listed above. 1991 The IAddr_options or IAprefix-options area are the places where 1992 additional information should be included. 1994 Items marked with a single asterisk (*) MUST appear only if the 1995 resource is associated with a client. Otherwise it MUST NOT appear. 1997 Items marked with a double asterisk (**) MUST appear only if the 1998 value in the OPTION_F_BINDING_STATUS is associated with a timeout, 1999 otherwise it MUST NOT appear. 2001 The OPTION_CLT_TIME MUST, if it appears, be the time that the server 2002 last interacted with the DHCPv6 client. It MUST NOT be, for 2003 instance, the time that the lease on an IPv6 address expired. If 2004 there has been no interaction with the DHCPv6 client in question (or 2005 there is no DHCPv6 client presently associated with this resource), 2006 then there will be no OPTION_CLT_TIME option in the 2007 OPTION_CLIENT_DATA option 2009 A server SHOULD be prepared to clean up DNS information once the 2010 lease expires or is released. See Section 9 for a detailed 2011 discussion about Dynamic DNS. Another reason the partner may be 2012 interested in keeping additional data is a better support for 2013 leasequery [RFC5007], bulk leasequery [RFC5460] or active leasequery 2014 [RFC7653], some of which features queries based on Relay-ID, by link 2015 address and by Remote-ID. 2017 7.5. Receiving Binding Updates 2019 7.5.1. Correcting Time Skew 2021 Unless otherwise specified, all of the times discussed below are 2022 corrected to be in the time context of the receiving server, as 2023 follows: 2025 1. The sent-time from the Failover message is compared with the 2026 current time of the receiving server as recorded when it received 2027 the message. The difference is noted, and used to affect the 2028 time correction by being included in the moving average of the 2029 last FO_SKEW_AVG differences. This is called the time- 2030 correction. 2032 2. Any OPTION_LQ_BASE_TIME options in the BNDUPD message MUST be 2033 corrected with the time-correction. The result is called the 2034 corrected-base-time. 2036 3. Any relative time values received in the BNDUPD MUST be added to 2037 or subtracted from the corrected-base-time. 2039 4. Any absolute time values received in the BNDUPD MUST be corrected 2040 with the time-correction 2042 When all of this is done to an incoming time, that time can be 2043 before, after, or essentially the same as another time. Any time 2044 which ends up being +/- 5 seconds of another time SHOULD be 2045 considered to be representing the same time when performing a 2046 comparison between two times. 2048 7.5.2. Processing Binding Updates 2050 When a BNDUPD is received each OPTION_CLIENT_DATA option is processed 2051 separately, and each must be independently accepted or rejected. 2053 When analyzing an OPTION_CLIENT_DATA option from a partner server, if 2054 there is insufficient information in the OPTION_CLIENT_DATA to 2055 process it, then it is rejected with an OPTION_STATUS_CODE of 2056 "MissingBindingInformation". 2058 The server receiving a BNDUPD update from its partner must evaluate 2059 the received information in each OPTION_CLIENT_DATA option to see if 2060 it is consistent with the server's already known state, and if it is 2061 not, decide which information - that previously known or that just 2062 received - is "better". If the information in the BNDUPD is 2063 "better", the receiving server will accept the information in the 2064 BNDUPD. If the information in the server's binding database is 2065 "better", the server will reject the information in the BNDUPD. 2067 A server receving a BNDUPD message MUST respond to the sender of that 2068 message with a BNDACK message which contains the same transaction-id 2069 as the BNDUPD message. This BNDACK message MUST contain one or more 2070 OPTION_CLIENT_DATA options, each of which corresponds to one of the 2071 OPTION_CLIENT_DATA options in the BNDUPD message. 2073 Each OPTION_CLIENT_DATA in the BNDACK which is accepted SHOULD NOT 2074 contain an OPTION_STATUS_CODE unless a status message needs to be 2075 sent to the failover partner, in which case it SHOULD include an 2076 OPTION_STATUS_CODE option with a status code indicating success and 2077 whatever message is needed. 2079 To indicate rejection of the information in an OPTION_CLIENT_DATA, an 2080 OPTION_STATUS_CODE SHOULD be included with a status code indicating 2081 an error, in the OPTION_CLIENT_DATA option in the BNDACK message. 2083 7.5.3. Accept or Reject? 2085 The first task in processing the information in an OPTION_CLIENT_DATA 2086 option is extract the client information and resource information out 2087 of the OPTION_CLIENT_DATA option, and to access the resource (IPv6 2088 address or prefix) information in the server's binding database. 2090 If the resource specified in the OPTION_CLIENT_DATA is not a resource 2091 associated with the failover endpoint which received the 2092 OPTION_CLIENT_DATA option, then reject it with reject-reason 2093 "ConfigurationConflict". 2095 In general, acceptance or rejection is based around the comparison of 2096 two different time values, one from the OPTION_CLIENT_DATA and one 2097 from receiving server's binding database associated with the resource 2098 found in the OPTION_CLIENT_DATA. The time for the OPTION_CLIENT_DATA 2099 is the OPTION_CLT_TIME if one appears, and the 2100 OPTION_F_START_TIME_OF_STATE if one does not. The time for the 2101 resource in the server's binding database is the client-last- 2102 transaction-time, if one appears, and the start-time-of-state if one 2103 does not. 2105 The basic approach is to compare these times, and if the one from the 2106 OPTION_CLIENT_DATA is clearly later, then accept the information in 2107 the OPTION_CLIENT_DATA. If the one from the server's binding 2108 database is clearly later, then reject the information in the 2109 OPTION_CLIENT_DATA. The challenge comes when they are essentially 2110 the same (i.e., +/- 5 seconds). The table below (Figure 3) contains 2111 the rules for dealing with these situations. 2113 binding-status in received OPTION_CLIENT_DATA 2114 binding-status 2115 in receiving FREE RESET 2116 server ACTIVE EXPIRED RELEASED FREE_BACKUP ABANDONED 2118 ACTIVE accept(4) time(2) time(1) time(2) accept 2119 EXPIRED time(1) accept accept accept accept 2120 RELEASED time(1) time(1) accept accept accept 2121 FREE/FREE_BACKUP accept accept accept accept accept 2122 RESET time(3) accept accept accept accept 2123 ABANDONED reject reject reject reject accept 2125 Figure 3: Conflict Resolution 2127 time(1): If the time value in the OPTION_CLIENT_DATA is later than 2128 the time value in the server's binding database, accept it, else 2129 reject it. 2131 time(2): If the current time is later than the receiving server's 2132 state-expiration-time, accept it, else reject it. 2134 time(3): If the OPTION_CLT_TIME value in the OPTION_CLIENT_DATA is 2135 later than the start-time-of-state in the receiving server's binding, 2136 accept it, else reject it. 2138 (1,2,3): If rejecting, use reject reason 2139 "OutdatedBindingInformation". 2141 (4): If the client in an OPTION_CLIENT_DATA option and in a receiving 2142 server's binding differ, then if the receiving server is a secondary 2143 accept it, else reject it with a reject reason of 2144 "AddressInUseByOtherClient". 2146 The lease update may be accepted or rejected. Rejection SHOULD NOT 2147 change the flag in a lease that says that it should be transmitted to 2148 the failover partner. If this flag is set, then it should be 2149 transmitted, but if it is not already set, the rejection of a lease 2150 state update SHOULD NOT trigger an automatic update of the failover 2151 partner sending the rejected update. The potential for update storms 2152 is too great, and in the unusual case where the servers simply can't 2153 agree, that disagreement is better than an update storm. 2155 7.5.4. Accepting Updates 2157 When the information in an OPTION_CLIENT_DATA option has been 2158 accepted, some of that information is stored in the receiving 2159 server's binding database, and corresponding OPTION_CLIENT_DATA is 2160 entered into a BNDACK. The information to enter into the 2161 OPTION_CLIENT_DATA in the BNDACK is described in Section 7.6. 2163 The information contained in the accepted OPTION_CLIENT_DATA option 2164 is stored in the receiving server's binding database as follows: 2166 1. The OPTION_CLIENTID is used to find the client. 2168 2. The other data contained in the top level of the 2169 OPTION_CLIENT_DATA option is stored with the client as 2170 appropriate. 2172 3. For each of the IA_NA or IA_PD options in the OPTION_CLIENT_DATA 2173 option and for each of the OPTION_IADDR or OPTION_IAPREFIX 2174 options in the IA_* options: 2176 1. OPTION_F_BINDING_STATUS is stored as the binding-status 2178 2. OPTION_F_PARTNER_LIFETIME is stored in the expiration-time 2180 3. OPTION_F_STATE_EXPIRATION_TIME is stored in the state- 2181 expiration-time 2183 4. OPTION_F_CLT_TIME (which MUST NOT be converted with the 2184 corrected-base-time, but MUST be converted with the raw value 2185 from the OPTION_LQ_BASE_TIME) is stored in the partner-raw- 2186 clt-time 2188 5. OPTION_F_PARTNER_RAW_CLT_TIME (which MUST NOT be corrected 2189 with the time-correction) replaces the client-last- 2190 transaction-time if it is later than the current client-last- 2191 transaction-time. 2193 6. OPTION_F_EXPIRATION_TIME replaces the partner-lifetime if it 2194 is later than the current partner-lifetime. 2196 7.6. Sending Binding Acks 2198 A server MUST respond to every BNDUPD message with a BNDACK message. 2199 The BNDACK message MUST contain an OPTION_CLIENT_DATA option 2200 corresponding to every OPTION_CLIENT_DATA option in the BNDUPD 2201 message. The BNDACK message MUST have the same transaction-id as the 2202 BNDUPD message to which it is a response. Each OPTION_CLIENT_DATA 2203 option MUST contain at least the data shown below in its client- 2204 options section: 2206 o OPTION_CLIENTID containing the DUID of the client most recently 2207 associated with this IPv6 address*; 2209 o OPTION_IA_NA for an IPv6 Address or OPTION_IA_PD for an IPv6 2210 Prefix. More than one of either of these options MAY appear if 2211 there are more than one associated with this client; 2213 * Inside of the IA_NA-options or IA_PD-option sections: 2215 + OPTION_IAADDR for an IPv6 address or an OPTION_IAPREFIX for 2216 a IPv6 prefix; 2218 - IPv6 Address or IPv6 Prefix (with length); 2220 - Inside of the IAaddr-options or IAprefix-options: 2222 o OPTION_STATUS_CODE containing an error code, or 2223 containing a success code if a message is required. 2225 If the information in the corresponding 2226 OPTION_CLIENT_DATA in the BNDACK was accepted, and no 2227 status message was required (which is the usual case), 2228 no OPTION_STATUS_CODE option appears. 2230 o OPTION_F_BINDING_STATUS containing the binding-status 2231 received in the BNDUPD; 2233 o OPTION_F_STATE_EXPIRATION_TIME (absolute) containing 2234 the state-expiration-time received in the BNDUPD; 2236 o OPTION_F_PARTNER_LIFETIME_SENT (absolute) containing a 2237 duplicate of the OPTION_F_PARTNER_LIFETIME received in 2238 the BNDUPD; 2240 7.7. Receiving Binding Acks 2242 When a BNDACK is received each OPTION_CLIENT_DATA option is processed 2243 separately, and each can either represent an ACK or a NAK. If a 2244 particular OPTION_CLIENT_DATA option does not contain an 2245 OPTION_STATUS_CODE option, or if there is an OPTION_STATUS_CODE 2246 option which contains a success code, then the OPTION_CLIENT_DATA 2247 option represents an acknowledgement (ACK) that the BNDUPD was a 2248 success. 2250 Alternatively, the appearance of an OPTION_STATUS_CODE representing 2251 an error in an OPTION_CLIENT_DATA option indicates a NAK of the 2252 BNDUPD represented by the OPTION_CLIENT_DATA. 2254 The information contained in the BNDACK in an OPTION_CLIENT_DATA that 2255 represents an ACK is stored with the appropriate client and lease, as 2256 follows: 2258 1. The OPTION_CLIENTID is used to find the client. 2260 2. For each of the IA_NA or IA_PD options in the OPTION_CLIENT_DATA 2261 option and for each of the OPTION_IADDR or OPTION_IAPREFIX 2262 options: 2264 1. OPTION_F_PARTNER_LIFETIME_SENT is stored in the acked- 2265 partner-lifetime 2267 2. The time partner-lifetime is set to 0. 2269 7.8. Acknowledging Reception 2271 Upon acceptance of a binding update, the server MUST notify its 2272 partner that it updated its binding database by sending a BNDACK. A 2273 server MUST NOT send the BNDACK before its binding database is 2274 updated. 2276 7.9. BNDUPD/BNDACK Data Flow 2278 The following diagram shows the relationship of the times described 2279 in Section 7.3 with the options used to transmit them. It also 2280 relates the times on one failover partner to the other failover 2281 partner. 2283 ----------------------- BNDUPD ------------------------------ 2285 Source on OPTION_F in Storage on 2286 Sending Server -> BNDUPD message -> Receiving Server 2288 [ always update ] 2290 partner-lifetime PARTNER_LIFETIME expiration-time 2291 client-last-transaction-time CLT_TIME (uncorrected) 2292 partner-raw-clt-time 2293 start-time-of-state START_TIME_OF_STATE start-time-of-state 2294 state-expiration-time STATE_EXPIRATION_TIME state-expiration-time 2296 [update only if received > current] 2298 expiration-time EXPIRATION_TIME partner-lifetime 2299 partner-raw-clt-time PARTNER_RAW_CLT_TIME 2300 client-last-transaction-time 2302 ----------------------- BNDACK ------------------------------ 2304 Storage on OPTION_F in Storage on 2305 Receiving Server <- BNDUPD message <- Sending Server 2307 [ always update ] 2309 acked-partner-lifetime PARTNER_LIFETIME_SENT duplicate of received 2310 PARTNER_LIFETIME 2311 STATE_EXPIRATION_TIME state-expiration-time 2313 ------------------------------------------------------------- 2315 Figure 4: BNDUPD and BNDACK Time Handling 2317 8. Endpoint States 2319 8.1. State Machine Operation 2321 Each server (or, more accurately, failover endpoint) can take on a 2322 variety of failover states. These states play a crucial role in 2323 determining the actions that a server will perform when processing a 2324 request from a DHCPv6 client as well as dealing with changing 2325 external conditions (e.g., loss of connection to a failover partner). 2327 The failover state in which a server is running controls the 2328 following behaviors: 2330 o Responsiveness -- the server is either responsive to DHCPv6 client 2331 requests or it is not. 2333 o Allocation Pool -- which pool of addresses (or prefixes) can be 2334 used for advertisement on receipt of a SOLICIT or allocation on 2335 receipt of a REQUEST message. 2337 o MCLT -- ensure that valid lifetimes are not beyond what the 2338 partner has acked plus the MCLT (or not). 2340 A server will transition from one failover state to another based on 2341 the specific values held by the following state variables: 2343 o Current failover state. 2345 o Communications status (OK or not OK). 2347 o Partner's failover state (if known). 2349 Whenever any of the above state variables changes state, the state 2350 machine is invoked, which may then trigger a change in the current 2351 failover state. Thus, whenever the communications status changes, 2352 the state machine processing is invoked. This may or may not result 2353 in a change in the current failover state. 2355 Whenever a server transitions to a new failover state, the new state 2356 MUST be communicated to its failover partner in a STATE message if 2357 the communications status is OK. In addition, whenever a server 2358 makes a transition into a new state, it MUST record the new state, 2359 its current understanding of its partner's state, and the time at 2360 which it entered the new state in stable storage. 2362 The following state transition diagram gives a condensed view of the 2363 state machine. If there is a difference between the words describing 2364 a particular state and the diagram below, the words should be 2365 considered authoritative. 2367 In the diagram below, the word (responsive) or (unresponsive) appers 2368 in the states, and refers to whether the server in this state is 2369 allowed to respond to client DHCPv6 requests. 2371 In the state transition diagram below, the "+" or "-" in the upper 2372 right corner of each state is a notation about whether communication 2373 is ongoing with the other server. 2375 +---------------+ V +--------------+ 2376 | RECOVER -|+| | | STARTUP - | 2377 |(unresponsive) | +->+(unresponsive)| 2378 +------+--------+ +--------------+ 2379 +-Comm. OK +-----------------+ 2380 | Other State: | PARTNER DOWN - +<---------------------+ 2381 | RESOLUTION-INTER. | (responsive) | ^ 2382 All POTENTIAL- +----+------------+ | 2383 Others CONFLICT------------ | --------+ | 2384 | CONFLICT-DONE Comm. OK | +--------------+ | 2385 UPDREQ or Other State: | +--+ RESOLUTION - | | 2386 UPDREQALL | | | | | INTERRUPTED | | 2387 Rcv UPDDONE RECOVER All | | | (responsive) | | 2388 | +---------------+ | Others | | +------------+-+ | 2389 +->+RECOVER-WAIT +-| RECOVER | | | ^ | | 2390 |(unresponsive) | WAIT or | | Comm. | Ext. | 2391 +-----------+---+ DONE | | OK Comm. Cmd---->+ 2392 Comm.---+ Wait MCLT | V V V Failed | 2393 Changed | V +---+ +---+-----+--+-+ | | 2394 | +---+----------++ | | POTENTIAL + +-------+ | 2395 | |RECOVER-DONE +-| Wait | CONFLICT +------+ | 2396 +->+(unresponsive) | for |(unresponsive)| Primary | 2397 +------+--------+ Other +>+----+--------++ resolve Comm. | 2398 Comm. OK State: | | ^ conflict Changed| 2399 +---Other State:-+ RECOVER | Secondary | V V | | 2400 | | | DONE | resolve | ++----------+---++ | 2401 | All Others: POTENT. | | conflict | |CONFLICT-DONE-|+| | 2402 | Wait for CONFLICT--|-----+ | | | (responsive) | | 2403 | Other State: V V | +------+---------+ | 2404 | NORMAL or RECOVER ++------------+---+ | Other State: NORMAL | 2405 | | DONE | NORMAL + +<--------------+ | 2406 | +--+----------+-->+ (responsive) +-------External Command-->+ 2407 | ^ ^ +--------+--------+ | 2408 | | | | | | 2409 | Wait for Comm. OK Comm. Failed | | 2410 | Other Other | | External 2411 | State: State: | | Command 2412 | RECOVER-DONE NORMAL Start Safe Comm. OK or 2413 | | COMM. INT. Period Timer Other State: Safe 2414 | Comm. OK. | V All Others Period 2415 | Other State: | +---------+--------+ | expiration 2416 | RECOVER +--+ COMMUNICATIONS - +----+ | 2417 | +-------------+ INTERRUPTED | | 2418 RECOVER | (responsive) +------------------------->+ 2419 RECOVER-WAIT--------->+------------------+ 2421 Figure 5: Failover Endpoint State Machine 2423 8.2. State Machine Initialization 2425 The state machine is characterized by storage (in stable storage) of 2426 at least the following information: 2428 o Current failover state. 2430 o Previous failover state. 2432 o Start time of current failover state. 2434 o Partner's failover state. 2436 o Start time of partner's failover state. 2438 o Time most recent packet received from partner. 2440 The state machine is initialized by reading these data items from 2441 stable storage and restoring their values from the information saved. 2442 If there is no information in stable storage concerning these items, 2443 then they should be initialized as follows: 2445 o Current failover state: Primary: PARTNER-DOWN, Secondary: RECOVER 2447 o Previous failover state: None. 2449 o Start time of current failover state: Current time. 2451 o Partner's failover state: None until reception of STATE message. 2453 o Start time of partner's failover state: None until reception of 2454 STATE message. 2456 o Time most recent packet received from partner: None until packet 2457 received. 2459 8.3. STARTUP State 2461 The STARTUP state affords an opportunity for a server to probe its 2462 partner server, before starting to service DHCP clients. When in the 2463 STARTUP state, a server attempts to learn its partner's state and 2464 determine (using that information if it is available) what state it 2465 should enter. 2467 The STARTUP state is not shown with any specific state transitions in 2468 the state machine diagram (Figure 5) because the processing during 2469 the STARTUP state can cause the server to transition to any of the 2470 other states, so that specific state transition arcs would only 2471 obscure other information. 2473 8.3.1. Operation in STARTUP State 2475 The server MUST NOT be responsive to DHCPv6 clients in STARTUP state. 2477 Whenever a STATE message is sent to the partner while in STARTUP 2478 state the STARTUP flag MUST be set in the message and the previously 2479 recorded failover state MUST be placed in the server-state option. 2481 8.3.2. Transition Out of STARTUP State 2483 The following algorithm is followed every time the server initializes 2484 itself, and enters STARTUP state. 2486 Step 1: 2488 If there is any record in stable storage of a previous failover state 2489 for this server, set PREVIOUS-STATE to the last recorded value in 2490 stable storage, and go to Step 2. 2492 If there is no record of any previous failover state in stable 2493 storage for this server, then set the PREVIOUS-STATE to RECOVER and 2494 set the TIME-OF-FAILURE to 0. This will allow two servers which 2495 already have lease information to synchronize themselves prior to 2496 operating. 2498 In some cases, an existing server will be commissioned as a failover 2499 server and brought back into operation where its partner is not yet 2500 available. In this case, the newly commissioned failover server will 2501 not operate until its partner comes online -- but it has operational 2502 responsibilities as a DHCPv6 server nonetheless. To properly handle 2503 this situation, a server SHOULD be configurable in such a way as to 2504 move directly into PARTNER-DOWN state after the startup period 2505 expires if it has been unable to contact its partner during the 2506 startup period. 2508 Step 2: 2510 Implementations will differ in the ways that they deal with the state 2511 machine for failover endpoint states. In many cases, state 2512 transitions will occur when communications goes from "OK" to failed, 2513 or from failed to "OK", and some implementations will implement a 2514 portion of their state machine processing based on these changes. 2516 In these cases, during startup, if the previous state is one where 2517 communications was "OK", then set the previous state to the state 2518 that is the result of the communications failed state transition when 2519 in that state (if such transition exists -- some states don't have a 2520 communications failed state transition, since they allow both 2521 communications OK and failed). 2523 Step 3: 2525 Start the STARTUP state timer. The time that a server remains in the 2526 STARTUP state (absent any communications with its partner) is 2527 implementation dependent but SHOULD be short. It SHOULD be long 2528 enough for a TCP connection to be created to a heavily loaded partner 2529 across a slow network. 2531 Step 4: 2533 If the server is a primary server: attempt to create a TCP connection 2534 to the failover partner. If the server is a secondary server, listen 2535 on the failover port and wait for the primary server to connect. See 2536 Section 6.1. 2538 Step 5: 2540 Wait for "communications OK". 2542 When and if communications become "OK", clear the STARTUP flag, and 2543 set the current state to the PREVIOUS-STATE. 2545 If the partner is in PARTNER-DOWN state, and if the time at which it 2546 entered PARTNER-DOWN state (as received in the start-time-of-state 2547 option in the STATE message) is later than the last recorded time of 2548 operation of this server, then set CURRENT-STATE to RECOVER. If the 2549 time at which it entered PARTNER-DOWN state is earlier than the last 2550 recorded time of operation of this server, then set CURRENT-STATE to 2551 POTENTIAL-CONFLICT. 2553 Then, transition to the current state and take the "communications 2554 OK" state transition based on the current state of this server and 2555 the partner. 2557 Step 6: 2559 If the startup time expires prior to communications becoming "OK", 2560 the server SHOULD transition to the PREVIOUS-STATE. 2562 8.4. PARTNER-DOWN State 2564 PARTNER-DOWN state is a state either server can enter. When in this 2565 state, the server assumes that it is the only server operating and 2566 serving the client base. If one server is in PARTNER-DOWN state, the 2567 other server MUST NOT be operating. 2569 A server can enter PARTNER-DOWN state either as a result of operator 2570 intervention (when an operator determines that the server's partner 2571 is, indeed, down), or as a result of an optional auto-partner-down 2572 capability where PARTNER-DOWN state is entered automatically after a 2573 server has been in COMMUNICATIONS-INTERRUPTED state for a pre- 2574 determined period of time. 2576 8.4.1. Operation in PARTNER-DOWN State 2578 The server MUST be responsive in PARTNER-DOWN state, regardless if it 2579 is primary or secondary. 2581 It will allow renewal of all outstanding leases on all resources. 2583 For those resources for which the server is using proportional 2584 allocation (i.e. prefixes), it will allocate resources from its own 2585 pool, and after a fixed period of time (the MCLT interval) has 2586 elapsed from entry into PARTNER-DOWN state, it may allocate IPv6 2587 addresses from the set of all available pools. Server MUST fully 2588 deplete its own pool, before starting allocations from its downed 2589 partner's pool. 2591 IPv6 addresses available for independent allocation by the other 2592 server (at entry to PARTNER-DOWN state) MUST NOT be allocated to a 2593 new client until the MCLT beyond the entry into PARTNER-DOWN state 2594 has elapsed. 2596 A server in PARTNER-DOWN state MUST NOT allocate a resource to a 2597 DHCPv6 client different from that to which it was allocated at the 2598 entrance to PARTNER-DOWN state until the MCLT beyond the maximum of 2599 the following times: client expiration time, most recently 2600 transmitted partner-lifetime, most recently received ack of the 2601 partner-time from the partner, and most recently acked partner- 2602 lifetime to the partner. If this time would be earlier than the 2603 current time plus the MCLT, then the time the server entered PARTNER- 2604 DOWN state plus the MCLT is used. 2606 The server is not restricted by the MCLT when offering lease times 2607 while in PARTNER-DOWN state. 2609 In the unlikely case when there are two servers operating in a 2610 PARTNER-DOWN state, there is a chance of duplicate leases for the 2611 same prefix to be assigned. This leads to a POTENTIAL-CONFLICT 2612 (unresponsive) state when they re-establish contact. The duplicate 2613 lease issue can be postponed to a large extent by the server granting 2614 new leases first from its own pool. Therefore the server operating 2615 in PARTNER-DOWN state MUST use its own pool first for new leases 2616 before assigning any leases from its downed partner pool. 2618 8.4.2. Transition Out of PARTNER-DOWN State 2620 When a server in PARTNER-DOWN state succeeds in establishing a 2621 connection to its partner, its actions are conditional on the state 2622 and flags received in the STATE message from the other server as part 2623 of the process of establishing the connection. 2625 If the STARTUP bit is set in the server-flags option of a received 2626 STATE message, a server in PARTNER-DOWN state MUST NOT take any state 2627 transitions based on reestablishing communications. If a server is 2628 in PARTNER-DOWN state, it ignores all STATE messages from its partner 2629 that have the STARTUP bit set in the server-flags option of the STATE 2630 message. 2632 If the STARTUP bit is not set in the server-flags option of a STATE 2633 message received from its partner, then a server in PARTNER-DOWN 2634 state takes the following actions based on the state of the partner 2635 as received in a STATE message (either immediately after establishing 2636 communications or at any time later when a new state is received) 2638 o If the partner is in: [ NORMAL, COMMUNICATIONS-INTERRUPTED, 2639 PARTNER-DOWN, POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, or 2640 CONFLICT-DONE ] state, then transition to POTENTIAL-CONFLICT state 2642 o If the partner is in: [ RECOVER, RECOVER-WAIT ] state stay in 2643 PARTNER-DOWN state 2645 o If the partner is in: [ RECOVER-DONE ] state transition into 2646 NORMAL state 2648 8.5. RECOVER State 2650 This state indicates that the server has no information in its stable 2651 storage or that it is re-integrating with a server in PARTNER-DOWN 2652 state after it has been down. A server in this state MUST attempt to 2653 refresh its stable storage from the other server. 2655 8.5.1. Operation in RECOVER State 2657 The server MUST NOT be responsive in RECOVER state. 2659 A server in RECOVER state will attempt to reestablish communications 2660 with the other server. 2662 8.5.2. Transition Out of RECOVER State 2664 If the other server is in POTENTIAL-CONFLICT, RESOLUTION-INTERRUPTED, 2665 or CONFLICT-DONE state when communications are reestablished, then 2666 the server in RECOVER state will move to POTENTIAL-CONFLICT state 2667 itself. 2669 If the other server is in any other state, then the server in RECOVER 2670 state will request an update of missing binding information by 2671 sending an UPDREQ message. If the server has determined that it has 2672 lost its stable storage because it has no record of ever having 2673 talked to its partner, while its partner does have a record of 2674 communicating with it, it MUST send an UPDREQALL message, otherwise 2675 it MUST send an UPDREQ message. 2677 It will wait for an UPDDONE message, and upon receipt of that message 2678 it will transition to RECOVER-WAIT state. 2680 If communications fails during the reception of the results of the 2681 UPDREQ or UPDREQALL message, the server will remain in RECOVER state, 2682 and will re-issue the UPDREQ or UPDREQALL when communications are re- 2683 established. 2685 If an UPDDONE message isn't received within an implementation 2686 dependent amount of time, and no BNDUPD messages are being received, 2687 the connection SHOULD be dropped. 2689 A B 2690 Server Server 2692 | | 2693 RECOVER PARTNER-DOWN 2694 | | 2695 | >--UPDREQ--------------------> | 2696 | | 2697 | <---------------------BNDUPD--< | 2698 | >--BNDACK--------------------> | 2699 ... ... 2700 | | 2701 | <---------------------BNDUPD--< | 2702 | >--BNDACK--------------------> | 2703 | | 2704 | <--------------------UPDDONE--< | 2705 | | 2706 RECOVER-WAIT | 2707 | | 2708 | >--STATE-(RECOVER-WAIT)------> | 2709 | | 2710 | | 2711 Wait MCLT from last known | 2712 time of failover operation | 2713 | | 2714 RECOVER-DONE | 2715 | | 2716 | >--STATE-(RECOVER-DONE)------> | 2717 | NORMAL 2718 | <-------------(NORMAL)-STATE--< | 2719 NORMAL | 2720 | >---- State-(NORMAL)---------------> | 2721 | | 2722 | | 2724 Figure 6: Transition out of RECOVER state 2726 If at any time while a server is in RECOVER state communications 2727 fails, the server will stay in RECOVER state. When communications 2728 are restored, it will restart the process of transitioning out of 2729 RECOVER state. 2731 8.6. RECOVER-WAIT State 2733 This state indicates that the server has sent an UPDREQ or UPDREQALL 2734 and has received the UPDDONE message indicating that it has received 2735 all outstanding binding update information. In the RECOVER-WAIT 2736 state the server will wait for the MCLT in order to ensure that any 2737 processing that this server might have done prior to losing its 2738 stable storage will not cause future difficulties. 2740 8.6.1. Operation in RECOVER-WAIT State 2742 The server MUST NOT be responsive in RECOVER-WAIT state. 2744 8.6.2. Transition Out of RECOVER-WAIT State 2746 Upon entry to RECOVER-WAIT state the server MUST start a timer whose 2747 expiration is set to a time equal to the time the server went down 2748 (if known) or the time the server started (if the down-time is 2749 unknown) plus the maximum-client-lead-time. When this timer expires, 2750 the server will transition into RECOVER-DONE state. 2752 This is to allow any IPv6 addresses that were allocated by this 2753 server prior to loss of its client binding information in stable 2754 storage to contact the other server or to time out. 2756 If the server has never before run failover, then there is no need to 2757 wait in this state and the server MAY transition immediately to 2758 RECOVER_DONE state. However, to determine if this server has run 2759 failover it is vital that the information provided by the partner be 2760 utilized, since the stable storage of this server may have been lost. 2762 If communications fails while a server is in RECOVER-WAIT state, it 2763 has no effect on the operation of this state. The server SHOULD 2764 continue to operate its timer, and if the timer expires during the 2765 period where communications with the other server have failed, then 2766 the server SHOULD transition to RECOVER-DONE state. This is rare -- 2767 failover state transitions are not usually made while communications 2768 are interrupted, but in this case there is no reason to inhibit this 2769 transition. 2771 8.7. RECOVER-DONE State 2773 This state exists to allow an interlocked transition for one server 2774 from RECOVER state and another server from PARTNER-DOWN or 2775 COMMUNICATIONS-INTERRUPTED state into NORMAL state. 2777 8.7.1. Operation in RECOVER-DONE State 2779 A server in RECOVER-DONE state SHOULD be unresponsive, but MAY 2780 respond to RENEW requests but MUST only change the state of resources 2781 that appear in the RENEW request. It MUST NOT allocate any 2782 additional resources when in RECOVER-DONE state. 2784 8.7.2. Transition Out of RECOVER-DONE State 2786 When a server in RECOVER-DONE state determines that its partner 2787 server has entered NORMAL or RECOVER-DONE state, then it will 2788 transition into NORMAL state. 2790 If communication fails while in RECOVER-DONE state, a server will 2791 stay in RECOVER-DONE state. 2793 8.8. NORMAL State 2795 NORMAL state is the state used by a server when it is communicating 2796 with the other server, and any required resynchronization has been 2797 performed. While some bindings database synchronization is performed 2798 in NORMAL state, potential conflicts are resolved prior to entry into 2799 NORMAL state as is binding database data loss. 2801 When entering NORMAL state, a server will send to the other server 2802 all currently unacknowledged binding updates as BNDUPD messages. 2804 When the above process is complete, if the server entering NORMAL 2805 state is a secondary server, then it will request resources 2806 (prefixes) for allocation using the POOLREQ message. 2808 8.8.1. Operation in NORMAL State 2810 The primary server is responsive in NORMAL state. The secondary is 2811 unresponsive in NORMAL state. 2813 When in NORMAL state a primary server will operate in the following 2814 manner: 2816 Lease time calculations 2817 As discussed in Section 4.4, the lease interval given to a DHCPv6 2818 client can never be more than the MCLT greater than the most 2819 recently acknowledged partner lifetime received from the failover 2820 partner or the current time, whichever is later. 2822 As long as a server adheres to this constraint, the specifics of 2823 the lease interval that it gives to a DHCPv6 client or the value 2824 of the partner lifetime sent to its failover partner are 2825 implementation dependent. 2827 Lazy update of partner server 2828 After sending a REPLY that includes a lease update to a client, 2829 the server servicing a DHCPv6 client request attempts to update 2830 its partner with the new binding information. See Section 4.3. 2832 Reallocation of resources between clients 2833 Whenever a client binding is released or expires, a BNDUPD message 2834 must be sent to the partner, setting the binding state to RELEASED 2835 or EXPIRED. However, until a BNDACK is received for this message, 2836 the resource cannot be allocated to another client. It cannot be 2837 allocated to the same client again if a BNDUPD was sent, otherwise 2838 it can. See Section 4.2.2.1 for details. 2840 In NORMAL state, each server receives binding updates from its 2841 partner server in BNDUPD messages (see Section 7.5.4). It records 2842 these in its binding database in stable storage and then sends a 2843 corresponding BNDACK message to its partner server (see Section 7.6). 2845 8.8.2. Transition Out of NORMAL State 2847 If an external command is received by a server in NORMAL state 2848 informing it that its partner is down, then transition into PARTNER- 2849 DOWN state. Generally, this would be an unusual situation, where 2850 some external agency knew the partner server was down prior to the 2851 failover server discovering it on its own. 2853 If a server in NORMAL state fails to receive acks to messages sent to 2854 its partner for an implementation dependent period of time, it MAY 2855 move into COMMUNICATIONS-INTERRUPTED state. This situation might 2856 occur if the partner server was capable of maintaining the TCP 2857 connection between the server and also capable of sending a CONTACT 2858 message periodically, but was (for some reason) incapable of 2859 processing BNDUPD messages. 2861 If the communications is determined to not be "ok" (as defined in 2862 Section 6.6), then transition into COMMUNICATIONS-INTERRUPTED state. 2864 If a server in NORMAL state receives any messages from its partner 2865 where the partner has changed state from that expected by the server 2866 in NORMAL state, then the server should transition into 2867 COMMUNICATIONS-INTERRUPTED state and take the appropriate state 2868 transition from there. For example, it would be expected for the 2869 partner to transition from POTENTIAL-CONFLICT into NORMAL state, but 2870 not for the partner to transition from NORMAL into POTENTIAL-CONFLICT 2871 state. 2873 If a server in NORMAL state receives a DISCONNECT message from its 2874 partner, the server should transition into COMMUNICATIONS-INTERRUPTED 2875 state. 2877 8.9. COMMUNICATIONS-INTERRUPTED State 2879 A server goes into COMMUNICATIONS-INTERRUPTED state whenever it is 2880 unable to communicate with its partner. Primary and secondary 2881 servers cycle automatically (without administrative intervention) 2882 between NORMAL and COMMUNICATIONS-INTERRUPTED state as the network 2883 connection between them fails and recovers, or as the partner server 2884 cycles between operational and non-operational. No duplicate 2885 resource allocation can occur while the servers cycle between these 2886 states. 2888 When a server enters COMMUNICATIONS-INTERRUPTED state, if it has been 2889 configured to support an automatic transition out of COMMUNICATIONS- 2890 INTERRUPTED state and into PARTNER-DOWN state (i.e., auto-partner- 2891 down has been configured), then a timer is started for the length of 2892 the configured auto-partner-down period. 2894 A server transitioning into the COMMUNICATIONS-INTERRUPTED state from 2895 the NORMAL state SHOULD raise some alarm condition to alert 2896 administrative staff to a potential problem in the DHCP subsystem. 2898 8.9.1. Operation in COMMUNICATIONS-INTERRUPTED State 2900 In this state a server MUST respond to all DHCPv6 client requests. 2901 When allocating new leases, each server allocates from its own pool, 2902 where the primary MUST allocate only FREE delegable prefixes, and the 2903 secondary MUST allocate only FREE_BACKUP delegable prefixes, and each 2904 server allocates from its own independent IPv6 address ranges. When 2905 responding to RENEW messages, each server will allow continued 2906 renewal of a DHCPv6 client's current lease on a resource regardless 2907 of whether that lease was given out by the receiving server or not, 2908 although the renewal period MUST NOT exceed the MCLT beyond the 2909 latest of: 1) the partner lifetime already acknowledged by the other 2910 server, or 2) now, or 3) the partner lifetime received from the 2911 partner server. 2913 However, since the server cannot communicate with its partner in this 2914 state, the acknowledged partner lifetime will not be updated despite 2915 continued RENEW message processing. This is likely to eventually 2916 cause the actual lifetimes to converge to the MCLT (unless this is 2917 greater than the desired-client-lease-time, which would be unusual). 2919 The server should continue to try to establish a connection with its 2920 partner. 2922 8.9.2. Transition Out of COMMUNICATIONS-INTERRUPTED State 2924 If the auto-partner-down timer expires while a server is in the 2925 COMMUNICATIONS-INTERRUPTED state, it will transition immediately into 2926 PARTNER-DOWN state. 2928 If an external command is received by a server in COMMUNICATIONS- 2929 INTERRUPTED state informing it that its partner is down, it will 2930 transition immediately into PARTNER-DOWN state. 2932 If communications is restored with the other server, then the server 2933 in COMMUNICATIONS-INTERRUPTED state will transition into another 2934 state based on the state of the partner: 2936 o NORMAL or COMMUNICATIONS-INTERRUPTED: Transition into the NORMAL 2937 state. 2939 o RECOVER: Stay in COMMUNICATIONS-INTERRUPTED state. 2941 o RECOVER-DONE: Transition into NORMAL state. 2943 o PARTNER-DOWN, POTENTIAL-CONFLICT, CONFLICT-DONE, or RESOLUTION- 2944 INTERRUPTED: Transition into POTENTIAL-CONFLICT state. 2946 The following figure illustrates the transition from NORMAL to 2947 COMMUNICATIONS-INTERRUPTED state and then back to NORMAL state again. 2949 Primary Secondary 2950 Server Server 2952 NORMAL NORMAL 2953 | >--CONTACT-------------------> | 2954 | <--------------------CONTACT--< | 2955 | [TCP connection broken] | 2956 COMMUNICATIONS : COMMUNICATIONS 2957 INTERRUPTED : INTERRUPTED 2958 | [attempt new TCP connection] | 2959 | [connection succeeds] | 2960 | | 2961 | >--CONNECT-------------------> | 2962 | <-----------------CONNECTACK--< | 2963 | NORMAL 2964 | <-------------------STATE-----< | 2965 NORMAL | 2966 | >--STATE---------------------> | 2967 | 2968 | >--BNDUPD--------------------> | 2969 | <---------------------BNDACK--< | 2970 | | 2971 | <---------------------BNDUPD--< | 2972 | >------BNDACK----------------> | 2973 ... ... 2974 | | 2975 | <--------------------POOLREQ--< | 2976 | >--POOLRESP------------------> | 2977 | | 2978 | >--BNDUPD-(#1)---------------> | 2979 | <---------------------BNDACK--< | 2980 | | 2981 | >--BNDUPD-(#2)---------------> | 2982 | <---------------------BNDACK--< | 2983 | | 2985 Figure 7: Transition from NORMAL to COMMUNICATIONS-INTERRUPTED and 2986 back 2988 8.10. POTENTIAL-CONFLICT State 2990 This state indicates that the two servers are attempting to 2991 reintegrate with each other, but at least one of them was running in 2992 a state that did not guarantee automatic reintegration would be 2993 possible. In POTENTIAL-CONFLICT state the servers may determine that 2994 the same resource has been offered and accepted by two different 2995 clients. 2997 It is a goal of this protocol to minimize the possibility that 2998 POTENTIAL-CONFLICT state is ever entered. 3000 When a primary server enters POTENTIAL-CONFLICT state it should 3001 request that the secondary send it all updates which the primary 3002 server has not yet acknowledged by sending an UPDREQ message to the 3003 secondary server. 3005 A secondary server entering POTENTIAL-CONFLICT state will wait for 3006 the primary to send it an UPDREQ message. 3008 8.10.1. Operation in POTENTIAL-CONFLICT State 3010 Any server in POTENTIAL-CONFLICT state MUST NOT process any incoming 3011 DHCPv6 requests. 3013 8.10.2. Transition Out of POTENTIAL-CONFLICT State 3015 If communications fails with the partner while in POTENTIAL-CONFLICT 3016 state, then the server will transition to RESOLUTION-INTERRUPTED 3017 state. 3019 Whenever either server receives an UPDDONE message from its partner 3020 while in POTENTIAL-CONFLICT state, it MUST transition to a new state. 3021 The primary MUST transition to CONFLICT-DONE state, and the secondary 3022 MUST transition to NORMAL state. This will cause the primary server 3023 to leave POTENTIAL-CONFLICT state prior to the secondary, since the 3024 primary sends an UPDREQ message and receives an UPDDONE before the 3025 secondary sends an UPDREQ message and receives its UPDDONE message. 3027 When a secondary server receives an indication that the primary 3028 server has made a transition from POTENTIAL-CONFLICT to CONFLICT-DONE 3029 state, it SHOULD send an UPDREQ message to the primary server. 3031 Primary Secondary 3032 Server Server 3034 | | 3035 POTENTIAL-CONFLICT POTENTIAL-CONFLICT 3036 | | 3037 | >--UPDREQ--------------------> | 3038 | | 3039 | <---------------------BNDUPD--< | 3040 | >--BNDACK--------------------> | 3041 ... ... 3042 | | 3043 | <---------------------BNDUPD--< | 3044 | >--BNDACK--------------------> | 3045 | | 3046 | <--------------------UPDDONE--< | 3047 CONFLICT-DONE | 3048 | >--STATE--(CONFLICT-DONE)----> | 3049 | <---------------------UPDREQ--< | 3050 | | 3051 | >--BNDUPD--------------------> | 3052 | <---------------------BNDACK--< | 3053 ... ... 3054 | >--BNDUPD--------------------> | 3055 | <---------------------BNDACK--< | 3056 | | 3057 | >--UPDDONE-------------------> | 3058 | NORMAL 3059 | <------------STATE--(NORMAL)--< | 3060 NORMAL | 3061 | >--STATE--(NORMAL)-----------> | 3062 | | 3063 | <--------------------POOLREQ--< | 3064 | >------POOLRESP--------------> | 3065 | | 3067 Figure 8: Transition out of POTENTIAL-CONFLICT 3069 8.11. RESOLUTION-INTERRUPTED State 3071 This state indicates that the two servers were attempting to 3072 reintegrate with each other in POTENTIAL-CONFLICT state, but 3073 communications failed prior to completion of re-integration. 3075 The RESOLUTION-INTERRUPTED state exists because servers are not 3076 responsive in POTENTIAL-CONFLICT state, and if one server drops out 3077 of service while both servers are in POTENTIAL-CONFLICT state, the 3078 server that remains in service will not be able to process DHCPv6 3079 client requests and there will be no DHCPv6 service available. The 3080 RESOLUTION-INTERRUPTED state is the state that a server moves to if 3081 its partner disappears while it is in POTENTIAL-CONFLICT state. 3083 When a server enters RESOLUTION-INTERRUPTED state it SHOULD raise an 3084 alarm condition to alert administrative staff of a problem in the 3085 DHCPv6 subsystem. 3087 8.11.1. Operation in RESOLUTION-INTERRUPTED State 3089 In this state a server MUST respond to all DHCPv6 client requests. 3090 When allocating new resources, each server SHOULD allocate from its 3091 own pool (if that can be determined), where the primary SHOULD 3092 allocate only FREE resources, and the secondary SHOULD allocate only 3093 FREE_BACKUP resources. When responding to renewal requests, each 3094 server will allow continued renewal of a DHCPv6 client's current 3095 lease independent of whether that lease was given out by the 3096 receiving server or not, although the renewal period MUST NOT exceed 3097 the maximum client lead time (MCLT) beyond the latest of: 1) the 3098 partner lifetime already acknowledged by the other server or 2) now 3099 or 3) partner lifetime received from the partner server. 3101 However, since the server cannot communicate with its partner in this 3102 state, the acknowledged partner lifetime will not be updated in any 3103 new bindings. 3105 8.11.2. Transition Out of RESOLUTION-INTERRUPTED State 3107 If an external command is received by a server in RESOLUTION- 3108 INTERRUPTED state informing it that its partner is down, it will 3109 transition immediately into PARTNER-DOWN state. 3111 If communications is restored with the other server, then the server 3112 in RESOLUTION-INTERRUPTED state will transition into POTENTIAL- 3113 CONFLICT state. 3115 8.12. CONFLICT-DONE State 3117 This state indicates that during the process where the two servers 3118 are attempting to re-integrate with each other, the primary server 3119 has received all of the updates from the secondary server. It makes 3120 a transition into CONFLICT-DONE state in order that it may be totally 3121 responsive to the client load. There is no operational difference 3122 between CONFLICT-DONE and NORMAL for primary as in both states it 3123 responds to all clients' requests. The distinction between CONFLICT- 3124 DONE and NORMAL states will is necessary in the event that a load- 3125 balancing extension is ever defined. 3127 8.12.1. Operation in CONFLICT-DONE State 3129 A primary server in CONFLICT-DONE state is fully responsive to all 3130 DHCPv6 clients (similar to the situation in COMMUNICATIONS- 3131 INTERRUPTED state). 3133 If communications fails, remain in CONFLICT-DONE state. If 3134 communications becomes OK, remain in CONFLICT-DONE state until the 3135 conditions for transition out become satisfied. 3137 8.12.2. Transition Out of CONFLICT-DONE State 3139 If communications fails with the partner while in CONFLICT-DONE 3140 state, then the server will remain in CONFLICT-DONE state. 3142 When a primary server determines that the secondary server has made a 3143 transition into NORMAL state, the primary server will also transition 3144 into NORMAL state. 3146 9. Dynamic DNS Considerations 3148 DHCPv6 servers (and clients) can use DNS Dynamic Updates as described 3149 in RFC 2136 [RFC2136] to maintain DNS name-mappings as they maintain 3150 DHCPv6 leases. Many different administrative models for DHCP-DNS 3151 integration are possible. Descriptions of several of these models, 3152 and guidelines that DHCPv6 servers and clients should follow in 3153 carrying them out, are laid out in RFC 4704 [RFC4704]. 3155 The nature of the failover protocol introduces some issues concerning 3156 dynamic DNS (DDNS) updates that are not part of non-failover 3157 environments. This section describes these issues, and defines the 3158 information which failover partners should exchange in order to 3159 ensure consistent behavior. The presence of this section should not 3160 be interpreted as requiring an implementation of the DHCPv6 failover 3161 protocol to also support DDNS updates. 3163 The purpose of this discussion is to clarify the areas where the 3164 failover and DHCP-DDNS protocols intersect for the benefit of 3165 implementations which support both protocols, not to introduce a new 3166 requirement into the DHCPv6 failover protocol. Thus, a DHCPv6 server 3167 which implements the failover protocol MAY also support dynamic DNS 3168 updates, but if it does support dynamic DNS updates it SHOULD utilize 3169 the techniques described here in order to correctly distribute them 3170 between the failover partners. See RFC 4704 [RFC4704] as well as RFC 3171 4703 [RFC4703] for information on how DHCPv6 servers deal with 3172 potential conflicts when updating DNS even without failover. 3174 From the standpoint of the failover protocol, there is no reason why 3175 a server which is utilizing the DDNS protocol to update a DNS server 3176 should not be a partner with a server which is not utilizing the DDNS 3177 protocol to update a DNS server. However, a server which is not able 3178 to support DDNS or is not configured to support DDNS SHOULD output a 3179 warning message when it receives BNDUPD messages which indicate that 3180 its failover partner is configured to support the DDNS protocol to 3181 update a DNS server. An implementation MAY consider this an error 3182 and refuse to operate, or it MAY choose to operate anyway, having 3183 warned the administrator of the problem in some way. 3185 9.1. Relationship between failover and dynamic DNS update 3187 The failover protocol describes the conditions under which each 3188 failover server may renew a lease to its current DHCPv6 client, and 3189 describes the conditions under which it may grant a lease to a new 3190 DHCPv6 client. An analogous set of conditions determines when a 3191 failover server should initiate a DDNS update, and when it should 3192 attempt to remove records from the DNS. The failover protocol's 3193 conditions are based on the desired external behavior: avoiding 3194 duplicate address and prefix assignments; allowing clients to 3195 continue using leases which they obtained from one failover partner 3196 even if they can only communicate with the other partner; allowing 3197 the secondary DHCPv6 server to grant new leases even if it is unable 3198 to communicate with the primary server. The desired external DDNS 3199 behavior for DHCPv6 failover servers is similar to that described 3200 above for the failover protocol itself: 3202 1. Allow timely DDNS updates from the server which grants a lease to 3203 a client. Recognize that there is often a DDNS update lifecycle 3204 which parallels the DHCP lease lifecycle. This is likely to 3205 include the addition of records when the lease is granted, and 3206 the removal of DNS records when the leased resource is 3207 subsequently made available for allocation to a different client. 3209 2. Communicate enough information between the two failover servers 3210 to allow one to complete the DDNS update 'lifecycle' even if the 3211 other server originally granted the lease. 3213 3. Avoid redundant or overlapping DDNS updates, where both failover 3214 servers are attempting to perform DDNS updates for the same 3215 lease-client binding. 3217 4. Avoid situations where one partner is attempting to add RRs 3218 related to a lease binding while the other partner is attempting 3219 to remove RRs related to the same lease binding. 3221 While DHCPv6 servers configured for DDNS typically perform these 3222 operations on both the AAAA and the PTR resource records, this is not 3223 required. It is entirely possible that a DHCPv6 server could be 3224 configured to only update the DNS with PTR records, and the DHCPv6 3225 clients could be responsible for updating the DNS with their own AAAA 3226 records. In this case, the discussions here would apply only to the 3227 PTR records. 3229 9.2. Exchanging DDNS Information 3231 In order for either server to be able to complete a DDNS update, or 3232 to remove DNS records which were added by its partner, both servers 3233 need to know the FQDN associated with the lease-client binding. In 3234 addition, to properly handle DDNS updates, additional information is 3235 required. All of the following information needs to be transmitted 3236 between the failover partners: 3238 1. The FQDN that the client requested be associated with the 3239 resource. If the client doesn't request a particular FQDN and 3240 one is synthesized by the failover server or if the failover 3241 server is configured to replace a client requested FQDN with a 3242 different FQDN, then the server generated value would be used. 3244 2. The FQDN that was actually placed in the DNS for this lease. It 3245 may differ from the client requested FQDN due to some form of 3246 disambiguation or other DHCP server configuration (as described 3247 above). 3249 3. The status of and DDNS operations in progress or completed. 3251 4. Information sufficient to allow the failover partner to remove 3252 the FQDN from the DNS should that become necessary. 3254 These data items are the minimum necessary set to reliably allow two 3255 failover partners to successfully share the responsibility to keep 3256 the DNS up to date with the resources allocated to clients. 3258 This information would typically be included in BNDUPD messages sent 3259 from one failover partner to the other. Failover servers MAY choose 3260 not to include this information in BNDUPD messages if there has been 3261 no change in the status of any DDNS update related to the lease. 3263 The partner server receiving BNDUPD messages containing the DDNS 3264 information SHOULD compare the status information and the FQDN with 3265 the current DDNS information it has associated with the lease 3266 binding, and update its notion of the DDNS status accordingly. 3268 Some implementations will instead choose to send a BNDUPD without 3269 waiting for the DDNS update to complete, and then will send a second 3270 BNDUPD once the DDNS update is complete. Other implementations will 3271 delay sending the partner a BNDUPD until the DDNS update has been 3272 acknowledged by the DNS server, or until some time-limit has elapsed, 3273 in order to avoid sending a second BNDUPD. 3275 The FQDN option contains the FQDN that will be associated with the 3276 AAAA RR (if the server is performing an AAAA RR update for the 3277 client). The PTR RR can be generated automatically from the IPv6 3278 address or prefix value. The FQDN may be composed in any of several 3279 ways, depending on server configuration and the information provided 3280 by the client in its DHCP messages. The client may supply a hostname 3281 which it would like the server to use in forming the FQDN, or it may 3282 supply the entire FQDN. The server may be configured to attempt to 3283 use the information the client supplies, it may be configured with an 3284 FQDN to use for the client, or it may be configured to synthesize an 3285 FQDN. 3287 Since the server interacting with the client may not have completed 3288 the DDNS update at the time it sends the first BNDUPD about the lease 3289 binding, there may be cases where the FQDN in later BNDUPD messages 3290 does not match the FQDN included in earlier messages. For example, 3291 the responsive server may be configured to handle situations where 3292 two or more DHCP client FQDNs are identical by modifying the most- 3293 specific label in the FQDNs of some of the clients in an attempt to 3294 generate unique FQDNs for them (a process sometimes called 3295 "disambiguation"). Alternatively, at sites which use some or all of 3296 the information which clients supply to form the FQDN, it's possible 3297 that a client's configuration may be changed so that it begins to 3298 supply new data. The server interacting with the client may react by 3299 removing the DNS records which it originally added for the client, 3300 and replacing them with records that refer to the client's new FQDN. 3301 In such cases, the server SHOULD include the actual FQDN that was 3302 used in subsequent DDNS options in any BNDUPD messages exchanged 3303 between the failover partners. This server SHOULD include relevant 3304 information in its BNDUPD messages. This information may be 3305 necessary in order to allow the non-responsive partner to detect 3306 client configuration changes that change the hostname or FQDN data 3307 which the client includes in its DHCPv6 requests. 3309 9.3. Adding RRs to the DNS 3311 A failover server which is going to perform DDNS updates SHOULD 3312 initiate the DDNS update when it grants a new lease to a client. The 3313 server which did not grant the lease SHOULD NOT initiate a DDNS 3314 update when it receives the BNDUPD after the lease has been granted. 3315 The failover protocol ensures that only one of the partners will 3316 grant a lease to any individual client, so it follows that this 3317 requirement will prevent both partners from initiating updates 3318 simultaneously. The server initiating the update SHOULD follow the 3319 protocol in RFC 4704 [RFC4704]. The server may be configured to 3320 perform a AAAA RR update on behalf of its clients, or not. 3321 Ordinarily, a failover server will not initiate DDNS updates when it 3322 renews leases. In two cases, however, a failover server MAY initiate 3323 a DDNS update when it renews a lease to its existing client: 3325 1. When the lease was granted before the server was configured to 3326 perform DDNS updates, the server MAY be configured to perform 3327 updates when it next renews existing leases. The server which 3328 granted the lease is the server which should initiate the DDNS 3329 update. 3331 2. If a server is in PARTNER-DOWN state, it can conclude that its 3332 partner is no longer attempting to perform an update for the 3333 existing client. If the remaining server has not recorded that 3334 an update for the binding has been successfully completed, the 3335 server MAY initiate a DDNS update. It MAY initiate this update 3336 immediately upon entry to PARTNER-DOWN state, it may perform this 3337 in the background, or it MAY initiate this update upon next 3338 hearing from the DHCPv6 client. 3340 9.4. Deleting RRs from the DNS 3342 The failover server which makes a resource FREE* SHOULD initiate any 3343 DDNS deletes, if it has recorded that DNS records were added on 3344 behalf of the client. 3346 A server not in PARTNER-DOWN state "makes a resource FREE*" when it 3347 initiates a BNDUPD with a binding-status of FREE, FREE_BACKUP, 3348 EXPIRED, or RELEASED. Its partner confirms this status by acking 3349 that BNDUPD, and upon receipt of the BNDACK the server has "made the 3350 resource FREE*". Conversely, a server in PARTNER-DOWN state "makes a 3351 resource FREE*" when it sets the binding-status to FREE, since in 3352 PARTNER-DOWN state no communications is required with the partner. 3354 It is at this point that it should initiate the DDNS operations to 3355 delete RRs from the DDNS. Its partner SHOULD NOT initiate DDNS 3356 deletes for DNS records related to the lease binding as part of 3357 sending the BNDACK message. The partner MAY have issued BNDUPD 3358 messages with a binding-status of FREE, EXPIRED, or RELEASED 3359 previously, but the other server will have rejected these BNDUPD 3360 messages. 3362 The failover protocol ensures that only one of the two partner 3363 servers will be able to make a resource FREE*. The server making the 3364 resource FREE* may be doing so while it is in NORMAL communication 3365 with its partner, or it may be in PARTNER-DOWN state. If a server is 3366 in PARTNER-DOWN state, it may be performing DDNS deletes for RRs 3367 which its partner added originally. This allows a single remaining 3368 partner server to assume responsibility for all of the DDNS activity 3369 which the two servers were undertaking. 3371 Another implication of this approach is that no DDNS RR deletes will 3372 be performed while either server is in COMMUNICATIONS-INTERRUPTED 3373 state, since no resource are moved into the FREE* state during that 3374 period. 3376 9.5. Name Assignment with No Update of DNS 3378 In some cases, a DHCPv6 server is configured to return a name to the 3379 DHCPv6 client but not enter that name into the DNS. This is 3380 typically a name that it has discovered or generated from information 3381 it has received from the client. In this case this name information 3382 SHOULD be communicated to the failover partner, if only to ensure 3383 that they will return the same name in the event the partner becomes 3384 the server to which the DHCPv6 client begins to interact. 3386 10. Security Considerations 3388 DHCPv6 failover is an extension of a standard DHCPv6 protocol, so all 3389 security considerations from [RFC3315], Section 23 and [RFC3633], 3390 Section 15 related to the server apply. 3392 The use of TCP introduces some additional concerns. Attacks that 3393 attempt to exhaust the DHCPv6 server's available TCP connection 3394 resources can compromise the ability of legitimate partners to 3395 receive service. Malicious requestors who succeed in establishing 3396 connections but who then send invalid messages, partial messages, or 3397 no messages at all can also exhaust a server's pool of available 3398 connections. 3400 When operating in secure mode, TLS [RFC5246] is used to secure the 3401 connection. The recommendations in [RFC7525] SHOULD be followed when 3402 negotiating a TLS connection. 3404 Servers SHOULD offer configuration parameters to limit the sources of 3405 incoming connections through validation and use of the digital 3406 certificates presented to create a TLS connection. They SHOULD also 3407 limit the number of accepted connections and limit the period of time 3408 during which an idle connection will be left open. 3410 Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to 3411 attempt to secure transmission of the messages described in this 3412 document. 3414 11. IANA Considerations 3416 IANA is requested to assign values for the following new DHCPv6 3417 Message types in the registry maintained in 3418 http://www.iana.org/assignments/dhcpv6-parameters: 3420 o BNDUPD (TBD1) 3422 o BNDACK (TBD2) 3424 o POOLREQ (TBD3) 3426 o POOLRESP (TBD4) 3428 o UPDREQ (TBD5) 3430 o UPDREQALL (TBD6) 3432 o UPDDONE (TBD7) 3434 o CONNECT (TBD8) 3436 o CONNECTACK (TBD9) 3438 o DISCONNECT (TBD10) 3440 o STATE (TBD11) 3442 o CONTACT (TBD12) 3444 IANA is requested to assign values for the following new DHCPv6 3445 Option codes in the registry maintained in 3446 http://www.iana.org/assignments/dhcpv6-parameters: 3448 OPTION_F_BINDING_STATUS (TBD13) 3450 OPTION_F_DNS_REMOVAL_INFO (TBD14) 3452 OPTION_F_FAILOVER_EXPIRE_TIME (TBD15) 3454 OPTION_F_MAX_UNACKED_BNDUPD (TBD16) 3456 OPTION_F_MCLT (TBD17) 3457 OPTION_F_PARTNER_LIFETIME (TBD18) 3459 OPTION_F_PARTNER_LIFETIME_SENT (TBD19) 3461 OPTION_F_PARTNER_DOWN_TIME (TBD20) 3463 OPTION_F_PARTNER_RAW_CLT_TIME (TBD21) 3465 OPTION_F_PROTOCOL_VERSION (TBD22) 3467 OPTION_F_RECEIVE_TIME (TBD23) 3469 OPTION_F_RECONFIGURE_DATA (TBD24) 3471 OPTION_F_RELATIONSHIP_NAME (TBD25) 3473 OPTION_F_SERVER_FLAGS (TBD26) 3475 OPTION_F_SERVER_STATE (TBD27) 3477 OPTION_F_START_TIME_OF_STATE (TBD28) 3479 OPTION_F_STATE_EXPIRATION_TIME (TBD29) 3481 IANA is requested to assign values for the following new DHCPv6 3482 Status codes in the registry maintained in 3483 http://www.iana.org/assignments/dhcpv6-parameters: 3485 AddressInUseByOtherClient (TBD30) 3487 ConfigurationConflict (TBD31) 3489 MissingBindingInformation (TBD32) 3491 OutdatedBindingInformation (TBD33) 3493 ServerShuttingDown (TBD34) 3495 12. Acknowledgements 3497 This document extensively uses concepts, definitions and other parts 3498 of an effort to document failover for DHCPv4. Authors would like to 3499 thank Shawn Routher, Greg Rabil, Bernie Volz and Marcin Siodelski for 3500 their significant involvement and contributions. Authors would like 3501 to thank VithalPrasad Gaitonde, Krzysztof Gierlowski, Krzysztof 3502 Nowicki and Michal Hoeft for their insightful comments. 3504 This work has been partially supported by Department of Computer 3505 Communications (a division of Gdansk University of Technology) and 3506 the Polish Ministry of Science and Higher Education under the 3507 European Regional Development Fund, Grant No. 3508 POIG.01.01.02-00-045/09-00 (Future Internet Engineering Project). 3510 13. References 3512 13.1. Normative References 3514 [RFC1035] Mockapetris, P., "Domain names - implementation and 3515 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 3516 November 1987, . 3518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3519 Requirement Levels", BCP 14, RFC 2119, 3520 DOI 10.17487/RFC2119, March 1997, 3521 . 3523 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 3524 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 3525 RFC 2136, DOI 10.17487/RFC2136, April 1997, 3526 . 3528 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 3529 C., and M. Carney, "Dynamic Host Configuration Protocol 3530 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 3531 2003, . 3533 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 3534 Host Configuration Protocol (DHCP) version 6", RFC 3633, 3535 DOI 10.17487/RFC3633, December 2003, 3536 . 3538 [RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified 3539 Domain Name (FQDN) Conflicts among Dynamic Host 3540 Configuration Protocol (DHCP) Clients", RFC 4703, 3541 DOI 10.17487/RFC4703, October 2006, 3542 . 3544 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 3545 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 3546 Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, 3547 . 3549 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 3550 "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, 3551 September 2007, . 3553 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3554 (TLS) Protocol Version 1.2", RFC 5246, 3555 DOI 10.17487/RFC5246, August 2008, 3556 . 3558 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 3559 DOI 10.17487/RFC5460, February 2009, 3560 . 3562 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 3563 "Recommendations for Secure Use of Transport Layer 3564 Security (TLS) and Datagram Transport Layer Security 3565 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 3566 2015, . 3568 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 3569 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, 3570 October 2015, . 3572 13.2. Informative References 3574 [RFC7031] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover 3575 Requirements", RFC 7031, DOI 10.17487/RFC7031, September 3576 2013, . 3578 Authors' Addresses 3580 Tomasz Mrugalski 3581 Internet Systems Consortium, Inc. 3582 950 Charter Street 3583 Redwood City, CA 94063 3584 USA 3586 Phone: +1 650 423 1345 3587 Email: tomasz.mrugalski@gmail.com 3589 Kim Kinnear 3590 Cisco Systems, Inc. 3591 1414 Massachusetts Avenue 3592 Boxborough, Massachusetts 01719 3593 USA 3595 Phone: +1 (978) 936-0000 3596 Email: kkinnear@cisco.com