draft-ietf-dhc-failover-07.txt

open source dhcp server client etc...

Network Working Group                                        Ralph Droms
INTERNET DRAFT                                       Bucknell University

                                                             Kim Kinnear
                                                              Mark Stapp
                                                           Cisco Systems

                                                             Bernie Volz
                                                                 IPWorks

                                                            Steve Gonczi
                                                         Network Engines

                                                              Greg Rabil
                                                             Mike Dooley
                                                              Arun Kapur
                                                     Lucent Technologies

                                                               July 2000
                                                    Expires January 2001


                         DHCP Failover Protocol
                    <draft-ietf-dhc-failover-07.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.






Droms, et. al.            Expires January 2001                  [Page 1]

Internet Draft           DHCP Failover Protocol               July 2000


Copyright Notice

   Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

   DHCP [RFC 2131] allows for multiple servers to be operating on a
   single network.  Some sites are interested in running multiple
   servers in such a way so as to provide redundancy in case of server
   failure.  In order for this to work reliably, the cooperating primary
   and secondary servers must maintain a consistent database of the
   lease information.  This implies that servers will need to coordinate
   any and all lease activity so that this information is synchronized
   in case of failover.

   This document defines a protocol to provide such synchronization
   between two servers.  One server is designated the "primary" server,
   the other is the "secondary" server.  This document also describes a
   way to integrate the failover protocol with the DHCP load balancing
   approach.

   This document is a substantial reorganization as well as a technical
   and editorial revision of draft-ietf-dhc-failover-05.txt.

Table of Contents


    1.  Introduction................................................. 4
    2.  Terminology.................................................. 5
    2.1.  Requirements terminology................................... 5
    2.2.  DHCP and failover terminology.............................. 5
    3.  Background and External Requirements......................... 9
    3.1.  Key aspects of the DHCP protocol........................... 9
    3.2.  BOOTP relay agent implementation........................... 11
    3.3.  What does it mean if a server can't communicate with its partner? 12
    3.4.  Challenging scenarios for a Failover protocol.............. 12
    3.5.  Using TCP to detect partner server failure................. 14
    4.  Design Goals................................................. 15
    4.1.  Design goals for this protocol............................. 15
    4.2.  Limitations of this protocol............................... 16
    5.  Protocol Overview............................................ 17
    5.1.  Messages and States........................................ 17
    5.2.  Fundamental guarantees..................................... 20
    5.3.  Load balancing............................................. 26
    5.4.  Operating in NORMAL state.................................. 27
    5.5.  Operating in COMMUNICATIONS-INTERRUPTED state.............. 27
    5.6.  Operating in PARTNER-DOWN state............................ 28




Droms, et. al.            Expires January 2001                  [Page 2]

Internet Draft           DHCP Failover Protocol               July 2000



    5.7.  Operating in RECOVER state................................. 28
    5.8.  Operating in STARTUP state................................. 28
    5.9.  Time synchronization between servers....................... 28
    5.10.  IP address binding-status................................. 29
    5.11.  DNS dynamic update considerations......................... 33
    5.12.  Reservations and failover................................. 37
    5.13.  Dynamic BOOTP and failover................................ 39
    5.14.  Guidelines for selecting MCLT............................. 39
    6.  Common Message Format........................................ 40
    6.1.  Message header format...................................... 40
    6.2.  Common option format....................................... 43
    6.3.  Batching multiple binding update transactions in one BNDUPD mes- 44
    7.  Protocol Messages............................................ 46
    7.1.  BNDUPD message [3]......................................... 46
    7.2.  BNDACK message [4]......................................... 56
    7.3.  UPDREQ message [9]......................................... 59
    7.4.  UPDREQALL message [7]...................................... 60
    7.5.  UPDDONE message [8]........................................ 61
    7.6.  POOLREQ message [1]........................................ 62
    7.7.  POOLRESP message [2]....................................... 63
    7.8.  CONNECT message [5]........................................ 64
    7.9.  CONNECTACK message [6]..................................... 68
    7.10.  STATE message [10]........................................ 71
    7.11.  CONTACT message [11]...................................... 72
    7.12.  DISCONNECT message [12]................................... 73
    8.  Connection Management........................................ 74
    8.1.  Connection granularity..................................... 74
    8.2.  Creating the TCP connection................................ 74
    8.3.  Using the TCP connection for determining communications status 76
    8.4.  Using the TCP connection for binding data.................. 78
    8.5.  Using the TCP connection for control messages.............. 78
    8.6.  Losing the TCP connection.................................. 78
    9.  Failover Endpoint States..................................... 79
    9.1.  Server Initialization...................................... 79
    9.2.  Server State Transitions................................... 79
    9.3.  STARTUP state.............................................. 82
    9.4.  PARTNER-DOWN state......................................... 84
    9.5.  RECOVER state.............................................. 86
    9.6.  NORMAL state............................................... 89
    9.7.  COMMUNICATIONS-INTERRUPTED State........................... 91
    9.8.  POTENTIAL-CONFLICT state................................... 95
    9.9.  RESOLUTION-INTERRUPTED state............................... 96
    9.10.  RECOVER-DONE state........................................ 97
    9.11.  PAUSED state.............................................. 98
    9.12.  SHUTDOWN state............................................ 98
    10.  Safe Period................................................. 99
    11.  Security.................................................... 101



Droms, et. al.            Expires January 2001                  [Page 3]

Internet Draft           DHCP Failover Protocol               July 2000


    11.1.  Simple shared secret...................................... 101
    11.2.  TLS....................................................... 102
    12.  Failover Options............................................ 103
    12.1.  addresses-transferred..................................... 103
    12.2.  assigned-IP-address....................................... 103
    12.3.  binding-status............................................ 104
    12.4.  client-identifier......................................... 104
    12.5.  client-hardware-address................................... 105
    12.6.  client-last-transaction-time.............................. 105
    12.7.  client-reply-options...................................... 105
    12.8.  client-request-options.................................... 106
    12.9.  DDNS...................................................... 107
    12.10.  delayed-service-parameter................................ 108
    12.11.  hash-bucket-assignment................................... 108
    12.12.  lease-expiration-time.................................... 108
    12.13.  max-unacked-bndupd....................................... 109
    12.14.  MCLT..................................................... 109
    12.15.  message.................................................. 109
    12.16.  message-digest........................................... 110
    12.17.  potential-expiration-time................................ 110
    12.18.  receive-timer............................................ 110
    12.19.  protocol-version......................................... 111
    12.20.  reject-reason............................................ 112
    12.21.  sending-server-IP-address................................ 113
    12.22.  server-flags............................................. 113
    12.23.  server-state............................................. 114
    12.24.  start-time-of-state...................................... 114
    12.25.  TLS-reply................................................ 115
    12.26.  TLS-request.............................................. 115
    12.27.  vendor-class-identifier.................................. 115
    12.28.  vendor-specific-options.................................. 116
    13.  IANA Considerations......................................... 116
    14.  Acknowledgments............................................. 116
    15.  References.................................................. 118
    16.  Author's information........................................ 119
    17.  Full Copyright Statement.................................... 120


1.  Introduction

   DHCP [RFC 2131] allows for multiple servers to be operating on a sin-
   gle network.  Some sites are interested in running multiple servers
   in such a way so as to provide redundancy in case of server failure
   since the DHCP subsystem is in many cases a critical part of the net-
   work infrastructure.

   This document defines a protocol to provide synchronization between
   two servers in order that each can take over for the other should



Droms, et. al.            Expires January 2001                  [Page 4]

Internet Draft           DHCP Failover Protocol               July 2000


   either one fail or become unreachable.

   One server is designated the "primary" server,  the other is the
   "secondary" server, and most DHCP client requests are sent to each
   server (see Section 3.1.1 for details).

   In order to provide a  high availability DHCP service, these
   cooperating primary and secondary servers must maintain a consistent
   database of lease information.  This implies that servers will need
   to coordinate all lease activity so that this information is syn-
   chronized in case failover is required.  The protocol messages and
   processing techniques required to maintain a consistent database are
   specified in the protocol described here.

   The failover protocol also contains a way to integrate the DHCP load-
   balancing algorithm described in [LOADB] with the failover protocol.

2.  Terminology

   This section discusses both the generic requirements terminology com-
   mon to many IETF protocol specifications as well as specialized DHCP
   and failover protocol specific terminology.

2.1.  Requirements terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC 2119].


2.2.  DHCP and failover terminology

   This document uses the following terms:

      o  "binding"

         A binding is a collection of configuration parameters, includ-
         ing at least an IP address, associated with or "bound to" a
         DHCP client.  Bindings are managed by DHCP servers.

      o  "binding database"

         The collection of bindings managed by a primary and secondary.

      o  "binding update transaction"

         A binding update transaction refers to the set of information
         (contained in options) necessary to perform a binding update



Droms, et. al.            Expires January 2001                  [Page 5]

Internet Draft           DHCP Failover Protocol               July 2000