Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7513

Source Address Validation Improvement (SAVI) Solution for DHCP

Pages: 54
Proposed Standard
Part 2 of 3 – Pages 17 to 45
First   Prev   Next

Top   ToC   RFC7513 - Page 17   prevText

5. Binding State Table (BST)

The Binding State Table, which may be implemented centrally in the switch or distributed among its ports, is used to contain the bindings between the IP addresses assigned to the attachments and the corresponding binding anchors of the attachments. Note that in this description, there is a binding entry for each IPv4 or IPv6 address associated with each binding anchor, and there may be several of each such address, especially if the port is extended using a protected non-SAVI device. Each binding entry has six fields: o Binding Anchor (listed as "Anchor" in subsequent figures): the binding anchor, i.e., one or more physical and/or link-layer properties of the attachment. o IP Address (listed as "Address" in subsequent figures): the IPv4 or IPv6 address assigned to the attachment by DHCP. o State: the state of the binding. Possible values of this field are listed in Sections 6.2 and 7.3. o Lifetime: the remaining seconds of the binding. Internally, this MAY be stored as the timestamp value at which the lifetime expires. o Transaction ID (TID): the Transaction ID [RFC2131] [RFC3315] of the corresponding DHCP transaction. The TID field is used to
Top   ToC   RFC7513 - Page 18
      associate DHCP Server-to-Client messages with corresponding
      binding entries.

   o  Timeouts: the number of timeouts that expired in the current state
      (only used in the Data Snooping Process; see Section 7).

   The IA is not present in the BST for three reasons:

   o  The lease of each address in one IA is assigned separately.

   o  When the binding is set up based on data snooping, the IA cannot
      be recovered from the leasequery protocol.

   o  DHCPv4 does not define an IA.

   An example of such a table is shown in Figure 4.

    +---------+----------+-----------+-----------+--------+----------+
    | Anchor  | Address  | State     | Lifetime  | TID    | Timeouts |
    +---------+----------+-----------+-----------+--------+----------+
    | Port_1  | IP_1     | BOUND     |  65535    | TID_1  |     0    |
    +---------+----------+-----------+-----------+--------+----------+
    | Port_1  | IP_2     | BOUND     |  10000    | TID_2  |     0    |
    +---------+----------+-----------+-----------+--------+----------+
    | Port_2  | IP_3     | INIT_BIND |      1    | TID_3  |     0    |
    +---------+----------+-----------+-----------+--------+----------+

                   Figure 4: Example Binding State Table

6. DHCP Snooping Process

This section specifies the process of setting up bindings based on DHCP snooping. This process is illustrated using a state machine.

6.1. Rationale

The rationale of the DHCP Snooping Process is that if a DHCP client is legitimately using a DHCP-assigned address, the DHCP address assignment procedure that assigns the IP address to the client must have been performed via the client's point of attachment. This assumption works when the SAVI device is always on the path(s) from the DHCP client to the DHCP server(s)/relay(s). Without considering the movement of DHCP clients, the SAVI device should be the cut vertex whose removal will separate the DHCP client and the remaining network containing the DHCP server(s)/relay(s). For most of the networks whose topologies are simple, it is possible to deploy this SAVI function at proper devices to meet this requirement.
Top   ToC   RFC7513 - Page 19
   However, if there are multiple paths from a DHCP client to the DHCP
   server and the SAVI device is only on one of them, there is an
   obvious failure case: the SAVI device may not be able to snoop the
   DHCP procedure.  Host movement may also make this requirement
   difficult to meet.  For example, when a DHCP client moves from one
   attachment to another attachment in the same network, it may fail to
   reinitialize its interface or send a Confirm message because of
   incomplete protocol implementation.  Thus, there can be scenarios in
   which only performing this DHCP Snooping Process is insufficient to
   set up bindings for all the valid DHCP addresses.  These exceptions
   and the solutions are discussed in Section 7.

6.2. Binding States Description

The following binding states are present in this process and the corresponding state machine: NO_BIND: No binding has been set up. INIT_BIND: A potential binding has been set up. BOUND: The binding has been set up.

6.3. Events

This section describes events in this process and the corresponding state machine transitions. The DHCP message categories (e.g., DHCPv4 Discover) defined in Section 3 are used extensively in the definitions of events and elsewhere in the state machine definition. If an event will trigger the creation of a new binding entry, the binding entry limit on the binding anchor MUST NOT be exceeded.

6.3.1. Timer Expiration Event

EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires.

6.3.2. Control Message Arriving Events

EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is received. EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received. EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received. EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received.
Top   ToC   RFC7513 - Page 20
   EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received.

   EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with the Rapid
   Commit option is received.

   EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received.

   EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is
   received.

   EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is
   received.

   EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY (refer to
   Section 4.3.3 of [RFC5007]) is received.

   Note: the events listed here do not cover all the DHCP messages in
   Section 3.  The messages that do not really determine address usage
   (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit,
   DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, and
   DHCPv6 Reconfigure) and that are not necessary to snoop (DHCPv4
   Negative Acknowledgment (NAK); refer to Section 6.4.2.3) are not
   included.  Note also that DHCPv4 DHCPLEASEQUERY is not used in the
   DHCP Snooping Process to avoid confusion with Section 7.  Also, since
   the LEASEQUERY should have been originated by the SAVI device itself,
   the destination check should verify that the message is directed to
   this SAVI device, and it should not be forwarded once it has been
   processed here.

   Moreover, only if a DHCP message can pass the following checks, the
   corresponding event is regarded as a valid event:

   o  Attribute check: the DHCP Server-to-Client messages and
      LEASEQUERY-REPLY should be from attachments with the DHCP-Trust
      attribute; the DHCP Client-to-Server messages should be from
      attachments with the DHCP-Snooping attribute.

   o  Destination check: the DHCP Server-to-Client messages should be
      destined to attachments with the DHCP-Snooping attribute.  This
      check is performed to ensure the binding is set up on the SAVI
      device that is nearest to the destination client.

   o  Binding anchor check: the DHCP Client-to-Server messages that may
      trigger modification or removal of an existing binding entry must
      have a matching binding anchor with the corresponding entry.
Top   ToC   RFC7513 - Page 21
   o  TID check: the DHCP Server-to-Client/Client-to-Server messages
      that may cause modification of existing binding entries must have
      a matched TID with the corresponding entry.  Note that this check
      is not performed on LEASEQUERY and LEASEQUERY-REPLY messages as
      they are exchanged between the SAVI devices and the DHCP servers.
      Besides, this check is not performed on DHCP Renew/Rebind
      messages.

   o  Binding limitation check: the DHCP messages must not cause new
      binding setup on an attachment whose binding entry limitation has
      been reached (refer to Section 11.5).

   o  Address check: the source address of the DHCP messages should pass
      the check specified in Section 8.2.

   On receiving a DHCP message without triggering a valid event, the
   state will not change, and the actions will not be performed.  Note
   that if a message does not trigger a valid event but it can pass the
   checks in Section 8.2, it MUST be forwarded.

6.4. The State Machine of DHCP Snooping Process

This section specifies state transitions and their corresponding actions.

6.4.1. Initial State: NO_BIND

6.4.1.1. Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request message is received
The SAVI device MUST forward the message. The SAVI device will generate an entry in the BST. The Binding Anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. If the message is DHCPv4 Request, the Address field can be set to the address to request, i.e., the 'requested IP address'. An example of the entry is illustrated in Figure 5.
Top   ToC   RFC7513 - Page 22
   +--------+-------+---------+-----------------------+-----+----------+
   | Anchor |Address| State   | Lifetime              | TID | Timeouts |
   +--------+-------+---------+-----------------------+-----+----------+
   | Port_1 |       |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |     0    |
   +--------+-------+---------+-----------------------+-----+----------+

       Figure 5: Binding Entry in BST on Initialization Triggered by
                   Request/Rapid Commit/Reboot Messages

   Resulting state: INIT_BIND - A potential binding has been set up.

6.4.1.2. Event: EVE_DHCP_REBOOT - A DHCPv4 Reboot message is received
The SAVI device MUST forward the message. The SAVI device will generate an entry in the BST. The Binding Anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. If the message is DHCPv4 Reboot, the Address field can be set to the address to request, i.e., the 'requested IP address'. An example of the entry is illustrated in Figure 5. Resulting state: INIT_BIND - A potential binding has been set up.
6.4.1.3. Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message with the Rapid Commit option is received
The SAVI device MUST forward the message. The SAVI device will generate an entry in the BST. The Binding Anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. An example of the entry is illustrated in Figure 5. Resulting state: INIT_BIND - A potential binding has been set up.
6.4.1.4. Event: EVE_DHCP_CONFIRM - A DHCPv6 Confirm message is received
The SAVI device MUST forward the message. The SAVI device will generate corresponding entries in the BST for each address in each Identity Association (IA) option of the Confirm message. The Binding Anchor field is set to the binding anchor of the attachment from which the message is received. The State field
Top   ToC   RFC7513 - Page 23
   is set to INIT_BIND.  The Lifetime field is set to be
   MAX_DHCP_RESPONSE_TIME.  The TID field is set to the TID of the
   message.  The Address field is set to the address(es) to confirm.  An
   example of the entries is illustrated in Figure 6.

   +--------+-------+---------+-----------------------+-----+----------+
   | Anchor |Address| State   | Lifetime              | TID | Timeouts |
   +--------+-------+---------+-----------------------+-----+----------+
   | Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |    0     |
   +--------+-------+---------+-----------------------+-----+----------+
   | Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |    0     |
   +--------+-------+---------+-----------------------+-----+----------+

    Figure 6: Binding Entry in BST on Confirm-Triggered Initialization

   Resulting state: INIT_BIND - A potential binding has been set up.

6.4.1.5. Events That Cannot Happen in the NO_BIND State
o EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received o EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is received o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is received o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is received These cannot happen because they are each something that happens AFTER a binding has been created.
Top   ToC   RFC7513 - Page 24

6.4.2. Initial State: INIT_BIND

6.4.2.1. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message is received
The message MUST be forwarded to the corresponding client. If the message is DHCPv4 ACK, the Address field of the corresponding entry (i.e., the binding entry whose TID is the same as the message) is set to the address in the message (i.e., 'yiaddr' in DHCPv4 ACK). The Lifetime field is set to the sum of the lease time in the ACK message and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. If the message is DHCPv6 Reply, note the following cases: 1. If the status code is not "Success", no modification of corresponding entries will be made. Corresponding entries will expire automatically if no "Success" Reply is received during the lifetime. The entries are not removed immediately because the client may be able to use the addresses whenever a "Success" Reply is received ("If the client receives any Reply messages that do not indicate a NotOnLink status, the client can use the addresses in the IA and ignore any messages that indicate a NotOnLink status" [RFC3315]). 2. If the status code is "Success", the SAVI device checks the IA options in the Reply message. A. If there are IA options in the Reply message, the SAVI device checks each IA option. When the first assigned address is found, the Address field of the binding entry with a matched TID is set to the address. The Lifetime field is set to the sum of the lease time in the Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. If there is more than one address assigned in the message, new binding entries are set up for the remaining address assigned in the IA options. An example of the entries is illustrated in Figure 8. SAVI devices do not specially process IA options with a NoAddrsAvail status because there should be no address contained in such IA options. B. Otherwise, the DHCP Reply message is in response to a Confirm message. The state of the binding entries with a matched TID is changed to BOUND. Because [RFC3315] does not require the lease time of addresses to be contained in the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007] message querying by IP address to the All_DHCP_Servers multicast
Top   ToC   RFC7513 - Page 25
           address [RFC3315] or a list of configured DHCP server
           addresses.  The LEASEQUERY message is generated for each IP
           address if multiple addresses are confirmed.  The lifetime of
           corresponding entries is set to 2*MAX_LEASEQUERY_DELAY.  If
           there is no response message after MAX_LEASEQUERY_DELAY, send
           the LEASEQUERY message again.  An example of the entries is
           illustrated in Figure 7.  If the SAVI device does not send
           the LEASEQUERY message, a preconfigured lifetime
           DHCP_DEFAULT_LEASE MUST be set on the corresponding entry.
           (Note: it is RECOMMENDED to use T1 configured on DHCP servers
           as the DHCP_DEFAULT_LEASE.)

   Note: the SAVI devices do not check if the assigned addresses are
   duplicated because in SAVI-DHCP scenarios, the DHCP servers are the
   only source of valid addresses.  However, the DHCP servers should be
   configured to make sure no duplicated addresses are assigned.

   +--------+-------+-------+------------------------+-----+----------+
   | Anchor |Address| State | Lifetime               | TID | Timeouts |
   +--------+-------+-------+------------------------+-----+----------+
   | Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID |    0     |
   +--------+-------+-------+------------------------+-----+----------+
   | Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID |    0     |
   +--------+-------+-------+------------------------+-----+----------+

      Figure 7: From INIT_BIND to BOUND on DHCP Reply in Response to
                                  Confirm

   Transition
   +--------+-------+-------+------------------------+-----+----------+
   | Anchor |Address| State | Lifetime               | TID | Timeouts |
   +--------+-------+-------+------------------------+-----+----------+
   | Port_1 | Addr1 | BOUND |Lease time+             | TID |    0     |
   |        |       |       |MAX_DHCP_RESPONSE_TIME  |     |          |
   +--------+-------+-------+------------------------+-----+----------+
   | Port_1 | Addr2 | BOUND |Lease time+             | TID |    0     |
   |        |       |       |MAX_DHCP_RESPONSE_TIME  |     |          |
   +--------+-------+-------+------------------------+-----+----------+

      Figure 8: From INIT_BIND to BOUND on DHCP Reply in Response to
                                  Request

   Resulting state: BOUND - The binding has been set up.
Top   ToC   RFC7513 - Page 26
6.4.2.2. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry expires
The entry MUST be deleted from the BST. Resulting state: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
6.4.2.3. Events That Are Ignored in INIT_BIND
If no DHCP Server-to-Client messages that assign addresses or confirm addresses are received, corresponding entries will expire automatically. Thus, other DHCP Server-to-Client messages (e.g., DHCPv4 NAK) are not specially processed. As a result, the following events, should they occur, are ignored until either a DHCPv4 ACK or a DHCPv6 Reply message is received or the lifetime of the binding entry expires. o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is received o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with the Rapid Commit option is received o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is received o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is received o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is received In each case, the message MUST be forwarded. Resulting state: INIT_BIND - A potential binding has been set up.
Top   ToC   RFC7513 - Page 27

6.4.3. Initial State: BOUND

6.4.3.1. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry expires
The entry MUST be deleted from the BST. Resulting state: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
6.4.3.2. Event: EVE_DHCP_DECLINE - A DHCPv4 Decline or a DHCPv6 Decline message is received
The message MUST be forwarded. First, the SAVI device gets all the addresses ("Requested IP address" in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, and addresses in all the IA options of DHCPv6 Decline/Release) to decline/release in the message. Then, the corresponding entries MUST be removed. Resulting state in each relevant BST entry: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
6.4.3.3. Event: EVE_DHCP_RELEASE - A DHCPv4 Release or a DHCPv6 Release message is received
The message MUST be forwarded. First, the SAVI device gets all the addresses ("Requested IP address" in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, and addresses in all the IA options of DHCPv6 Decline/Release) to decline/release in the message. Then, the corresponding entries MUST be removed. Resulting state in each relevant BST entry: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
6.4.3.4. Event: EVE_DHCP_REBIND - A DHCPv4 Rebind or a DHCPv6 Rebind message is received
The message MUST be forwarded. In such a case, a new TID will be used by the client. The TID field of the corresponding entries MUST be set to the new TID. Note that the TID check will not be performed on such messages. Resulting state: BOUND: The binding has been set up.
Top   ToC   RFC7513 - Page 28
6.4.3.5. Event: EVE_DHCP_RENEW - A DHCPv4 Renew or a DHCPv6 Renew message is received
The message MUST be forwarded. In such a case, a new TID will be used by the client. The TID field of the corresponding entries MUST be set to the new TID. Note that the TID check will not be performed on such messages. Resulting state: BOUND: The binding has been set up.
6.4.3.6. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message is received
The message MUST be forwarded. The DHCP Reply messages received in current states should be in response to DHCP Renew/Rebind. If the message is DHCPv4 ACK, the SAVI device updates the binding entry with a matched TID, with the Lifetime field set to be the sum of the new lease time and MAX_DHCP_RESPONSE_TIME, leaving the entry in the BOUND state. If the message is DHCPv6 Reply, the SAVI device checks each IA Address option in each IA option. For each: 1. If the IA entry in the REPLY message has the status "NoBinding", there is no address in the option, and no operation on an address is performed. 2. If the valid lifetime of an IA Address option is 0, the binding entry with a matched TID and address is removed, leaving it effectively in the NO_BIND state. 3. Otherwise, set the Lifetime field of the binding entry with the matched TID and address to be the sum of the new valid lifetime and MAX_DHCP_RESPONSE_TIME, leaving the entry in the BOUND state. Resulting state: NO_BIND or BOUND, as specified.
Top   ToC   RFC7513 - Page 29
6.4.3.7. Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6 LEASEQUERY_REPLY is received
The message MUST be forwarded. The message should be in response to the LEASEQUERY message sent in Section 6.4.2. The related binding entry can be determined based on the address in the IA Address option in the LEASEQUERY-REPLY message. The Lifetime field of the corresponding binding entry is set to the sum of the lease time in the LEASEQUERY-REPLY message and MAX_DHCP_RESPONSE_TIME. Resulting state: BOUND: The binding has been set up.
6.4.3.8. Events Not Processed in the State BOUND
The following events are ignored if received while the indicated entry is in the BOUND state. Any required action will be the result of the next message in the client/server exchange. o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is received o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with the Rapid Commit option is received
Top   ToC   RFC7513 - Page 30

6.4.4. Table of State Machine

The main state transits are listed as follows. Note that not all the details are specified in the table and the diagram. State Event Action Next State --------------------------------------------------------------------- NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND INIT_BIND RPL Record lease time BOUND (send leasequery if no lease) INIT_BIND EVE_ENTRY_EXPIRE Remove entry NO_BIND BOUND RLS/DCL Remove entry NO_BIND BOUND EVE_ENTRY_EXPIRE Remove entry NO_BIND BOUND RPL Set new lifetime BOUND BOUND LQR Record lease time BOUND Figure 9: State Transition Table RQ: EVE_DHCP_REQUEST RC: EVE_DHCP_SOLICIT_RC CF: EVE_DHCP_CONFIRM RE: EVE_DHCP_REBOOT RPL: EVE_DHCP_REPLY RLS: EVE_DHCP_RELEASE DCL: EVE_DHCP_DECLINE LQR: EVE_DHCP_LEASEQUERY
Top   ToC   RFC7513 - Page 31
                               +-------------+
                               |             |
                      /--------+   NO_BIND   |<--------\
                      |  ----->|             |         |
                      |  |     +-------------+         |EVE_DHCP_RELEASE
   EVE_DHCP_REQUEST   |  |                             |EVE_DHCP_DECLINE
   EVE_DHCP_CONFIRM   |  |EVE_ENTRY_EXPIRE             |EVE_ENTRY_EXPIRE
   EVE_DHCP_SOLICIT_RC|  |                             |
   EVE_DHCP_REBOOT    |  |                             |
                      |  |                             |
                      |  |                             |
                      v  |                             |
              +-------------+                      +------------+
              |             |    EVE_DHCP_REPLY   |            |
              |  INIT_BIND  --------------------->|    BOUND   |<-\
              |             |                     |            |  |
              +-------------+                     +------------+  |
                                                         |        |
                                                         \--------/
                                               EVE_DHCP_REPLY
                                               EVE_DHCP_LEASEQUERY

                       Figure 10: Diagram of Transit

7. Data Snooping Process

7.1. Scenario

The rationale of the DHCP Snooping Process specified in Section 6 is that if a DHCP client's use of a DHCP address is legitimate, the corresponding DHCP address assignment procedure must have been finished during the attachment of the DHCP client. This is the case when the SAVI device is continuously on the path(s) from the DHCP client to the DHCP server(s)/relay(s). However, there are two cases in which this does not work: o Multiple paths: there is more than one feasible link-layer path from the client to the DHCP server/relay, and the SAVI device is not on every one of them. The client may get its address through one of the paths that does not pass through the SAVI device, but packets from the client can travel on paths that pass through the SAVI device, such as when the path through the link-layer network changes. Because the SAVI device could not snoop the DHCP packet exchange procedure, the DHCP Snooping Process cannot set up the corresponding binding.
Top   ToC   RFC7513 - Page 32
   o  Dynamic path: there is only one feasible link-layer path from the
      client to the DHCP server/relay, but the path is dynamic due to
      topology change (for example, some link becomes broken due to
      failure or some planned change) or link-layer path change.  This
      situation also covers the local-link movement of clients without
      the address confirm/reconfiguration process.  For example, a host
      changes its attached switch port in a very short time.  In such
      cases, the DHCP Snooping Process will not set up the corresponding
      binding.

   The Data Snooping Process can avoid the permanent blocking of
   legitimate traffic in case one of these two exceptions occurs.  This
   process is performed on attachments with the Data-Snooping attribute.
   Data packets without a matching binding entry may trigger this
   process to set up bindings.

   Snooping data traffic introduces a considerable burden on the
   processor and ASIC-to-Processor bandwidth of SAVI devices.  Because
   of the overhead of this process, the implementation of this process
   is OPTIONAL.  This function SHOULD be enabled unless the
   implementation is known to be used in the scenarios without the above
   exceptions.  For example, if the implementation is to be used in
   networks with tree topology and without host local-link movement,
   there is no need to implement this process in such scenarios.

   This process is not intended to set up a binding whenever a data
   packet without a matched binding entry is received.  Instead,
   unmatched data packets trigger this process probabilistically, and
   generally a number of unmatched packets will be discarded before the
   binding is set up.  The parameter(s) of this probabilistic process
   SHOULD be configurable, defaulting to a situation where data snooping
   is disabled.

7.2. Rationale

This process makes use of NS/ARP and DHCP Leasequery to set up bindings. If an address is not used by another client in the network, and the address has been assigned in the network, the address can be bound with the binding anchor of the attachment from which the unmatched packet is received. The Data Snooping Process provides an alternative path for binding entries to reach the BOUND state in the exceptional cases explained in Section 7.1 when there are no DHCP messages that can be snooped by the SAVI device.
Top   ToC   RFC7513 - Page 33
   In some of the exceptional cases (especially the dynamic topology
   case), by the time the binding has reached the BOUND state, the DHCP
   messages may be passing through the SAVI device.  In this case, the
   events driven by DHCP messages that are expected in the BOUND state
   in the DHCP Snooping Process may occur, and the binding can be
   handled by the DHCP Snooping Process state machine.

   In any event, the lease expiry timeout event will occur even if no
   others do.  This will cause the binding to be deleted and the state
   to logically return to NO_BIND state.  Either the DHCP or the Data
   Snooping Process will be reinvoked if the lease is still in place.
   If DHCP messages are still not passing through the SAVI device, there
   will be a brief disconnection during which data packets passing
   through the SAVI device will be dropped.  The probabilistic
   initiation of the Data Snooping Process can then take over again and
   return the binding state to BOUND in due course.

   The security issues concerning this process are discussed in
   Section 11.1.

7.3. Additional Binding States Description

In addition to NO_BIND and BOUND from Section 6.2, three new states used in this process are listed here. The INIT_BIND state is not used, as it is entered by observing a DHCP message. DETECTION: The address in the entry is undergoing local duplication detection. RECOVERY: The SAVI device is querying the assignment and lease time of the address in the entry through DHCP Leasequery. VERIFY: The SAVI device is verifying that the device connected to the attachment point has a hardware address that matches the one returned in the DHCP Leasequery. Because the mechanisms used for the operations carried out while the binding is in these three states operate over unreliable protocols, each operation is carried out twice with a timeout that is triggered if no response is received.

7.4. Events

To handle the Data Snooping Process, six extra events, described here, are needed in addition to those used by the DHCP Snooping Process (see Section 6.3). If an event will trigger the creation of a new binding entry, the binding entry limit on the binding anchor MUST NOT be exceeded.
Top   ToC   RFC7513 - Page 34
   EVE_DATA_UNMATCH: A data packet without a matched binding is
   received.

   EVE_DATA_CONFLICT: An ARP Reply / Neighbor Advertisement (NA) message
   against an address in the DETECTION state is received from a host
   other than the one for which the entry was added (i.e., a host
   attached at a point other than the one on which the triggering data
   packet was received).

   EVE_DATA_LEASEQUERY:

   o  IPv4: A DHCPLEASEACTIVE message with the IP Address Lease Time
      option is received.  Note that the DHCPLEASEUNKNOWN and
      DHCPLEASEUNASSIGNED replies are ignored.

   o  IPv6: A successful LEASEQUERY-REPLY is received.

   EVE_DATA_VERIFY: An ARP Reply / NA message has been received in the
   VERIFY state from the device connected to the attachment point on
   which the data packet was received.

   The triggering packet should pass the following checks to trigger a
   valid event:

   o  Attribute check: the data packet should be from attachments with
      the Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY-REPLY
      messages should be from attachments with the DHCP-Snooping
      attribute.

   o  Binding limitation check: the data messages must not cause new
      binding setup on an attachment whose binding entry limitation has
      been reached (refer to Section 11.5).

   o  Address check: For EVE_DATA_LEASEQUERY, the source address of the
      DHCPLEASEQUERY messages must pass the check specified in
      Section 8.2.  For EVE_DATA_CONFLICT and EVE_DATA_VERIFY, the
      source address and target address of the ARP or NA messages must
      pass the check specified in Section 8.2.

   o  Interval check: the interval between two successive
      EVE_DATA_UNMATCH events triggered by an attachment MUST be no
      smaller than DATA_SNOOPING_INTERVAL.

   o  TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have
      a matched TID with the corresponding entry.

   o  Prefix check: the source address of the data packet should be of a
      valid local prefix, as specified in Section 7 of [RFC7039].
Top   ToC   RFC7513 - Page 35
   EVE_DATA_EXPIRE: A timer expires indicating that a response to a
   hardware address verification message sent in the VERIFY state has
   not been received within the specified DETECTION_TIMEOUT period.

   EVE_ENTRY_EXPIRE: A timer expires after the Lifetime indicated in the
   relevant BST entry has elapsed.  This is identical to the usage in
   the DHCP Snooping Process.

7.5. Message Sender Functions

The Data Snooping Process involves sending three different messages to other network devices. Each message may be sent up to two times since they are sent over unreliable transports and are sent in different states. The functions defined in this section specify the messages to be sent in the three cases. In each case, the message to be sent depends on whether the triggering data packet is an IPv4 or an IPv6 packet.

7.5.1. Duplicate Detection Message Sender

Send a message to check if the source address in the data packet that triggered the Data Snooping Process has a local conflict (that is, it uses an address that is being used by another node): IPv4 address: Broadcast an Address Resolution Protocol (ARP) Request [RFC826] or an ARP Probe [RFC5227] for the address to the local network. An ARP Response will be expected from the device on the attachment point on which the triggering data packet was received. An ARP Reply received on any other port indicates a duplicate address. IPv6 address: Send a Duplicate Address Detection (DAD) message (Neighbor Solicitation message) to the solicited-node multicast address [RFC4861] targeting the address. Ideally, only the host on that point of attachment responds with a Neighbor Advertisement. A Neighbor Advertisement received on any other port indicates a duplicate address. As both the ARP and DAD processes are unreliable (the packet either to or from the other system may be lost in transit; see [RFC6620]), if there is no response after the DETECTION_TIMEOUT, an EVE_ENTRY_EXPIRE is generated.
Top   ToC   RFC7513 - Page 36

7.5.2. Leasequery Message Sender

Send a DHCPLEASEQUERY message to the DHCP server(s) to determine if it has given out a lease for the source address in the triggering data packet. A list of authorized DHCP servers is kept by the SAVI device. The list should be either preconfigured with the IPv4 and/or IPv6 addresses or dynamically discovered: For networks using IPv4, this can be done by sending DHCPv4 Discover messages and parsing the returned DHCPv4 Offer messages; for networks using IPv6, discovery can be done by sending DHCPv6 SOLICIT messages and parsing the returned ADVERTISE messages. The same TID should be used for all LEASEQUERY messages sent in response to a triggering data message on an attachment point. The TID is generated if the TID field in the BST entry is empty and recorded in the TID field of the BST entry when the first message is sent. Subsequent messages use the TID from the BST entry. (1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to each DHCPv4 server in the list of authorized servers with an IP Address Lease Time option (option 51). If the server has a valid lease for the address, the requested information will be returned in a DHCPLEASEACTIVE message. (2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP address to each DHCPv6 server in the list of authorized servers using the server address as the link-address in the LEASEQUERY message. If the server has a valid lease for the address, the requested information will be returned in a LEASEQUERY-REPLY message marked as successful (i.e., without an OPTION_STATUS_CODE in the reply). The IA Address option(s) returned contains any IPv6 addresses bound to the same link together with the lease validity time. As DHCP Leasequeries are an unreliable process (the packet either to or from the server may be lost in transit), if there is no response after the MAX_LEASEQUERY_DELAY, an EVE_DATA_EXPIRE is generated. Note that multiple response messages may be received if the list of authorized servers contains more than one address of the appropriate type and, in the case of DHCPv6, the responses may contain additional addresses for which leases have been allocated.

7.5.3. Address Verification Message Sender

Send a message to verify that the link-layer address in the attached device that sent the triggering data packet matches the link-layer address contained in the leasequery response:
Top   ToC   RFC7513 - Page 37
   IPv4 address:  Send an ARP Request with the Target Protocol Address
         set to the IP address in the BST entry.  The ARP Request is
         only sent to the attachment that triggered the binding.  If the
         attached device has the IP address bound to the interface
         attached to the SAVI device, an ARP Reply should be received
         containing the hardware address of the interface on the
         attached device that can be compared with the leasequery value.

   IPv6 address:  Send a Neighbor Solicitation (NS) message with the
         target address set to the IP address in the BST entry.  The NS
         is only sent to the attachment that triggered the binding.  If
         the attached device has the IP address bound to the interface
         attached to the SAVI device, an NA should be received
         indicating that the attached device has the IP address
         configured on the interface.

   As both the ARP and NS/NA processes are unreliable (the packet either
   to or from the other system may be lost in transit; see [RFC6620]),
   if there is no response after the DETECTION_TIMEOUT, an
   EVE_DATA_EXPIRE is generated.

7.6. Initial State: NO_BIND

7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a matched binding is received

Make a probabilistic determination as to whether to act on this event. The probability may be configured or calculated based on the state of the SAVI device. This probability should be low enough to mitigate the damage from DoS attacks against this process. Create a new entry in the BST. Set the Binding Anchor field to the corresponding binding anchor of the attachment. Set the Address field to the source address of the packet. Address conflicts MUST be detected and prevented. If local address detection is performed: Set the State field to DETECTION. Set the Lifetime of the created entry to DETECTION_TIMEOUT. Set the Timeouts field to 0. Start the detection of any local address conflicts by sending a Duplicate Address Detection Message (Section 7.5.1). Transition to DETECTION state.
Top   ToC   RFC7513 - Page 38
   If local address detection is not performed:
         Set the State field to RECOVERY.  Set the Lifetime of the
         created entry to LEASEQUERY_DELAY.  Set the Timeouts field to
         0.  Start the recovery of any DHCP lease associated with the
         source IP address by sending one or more LEASEQUERY messages
         (Section 7.5.2).  Transition to RECOVERY state.

   The packet that triggers this event SHOULD be discarded.

   An example of the BST entry during duplicate address detection is
   illustrated in Figure 11.

   +--------+-------+---------+-----------------------+-----+----------+
   | Anchor |Address|  State  | Lifetime              | TID | Timeouts |
   +--------+-------+---------+-----------------------+-----+----------+
   | Port_1 | Addr1 |DETECTION| DETECTION_TIMEOUT     |     |    0     |
   +--------+-------+---------+-----------------------+-----+----------+

     Figure 11: Binding Entry in BST on Data-Triggered Initialization

   Resulting state: DETECTION - The address in the entry is undergoing
   local duplication detection - or RECOVERY - The DHCP lease(s)
   associated with the address is being queried.

7.6.2. Events Not Observed in NO_BIND for Data Snooping

EVE_DATA_CONFLICT: An ARP Reply / NA message is received from an unexpected system. EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is received. EVE_DATA_VERIFY: A valid ARP Reply or NA message is received from the attached device. All EVE_DHCP_* events defined in Section 6.3.2 are treated as described in the DHCP Snooping Process (Section 6.4.1) and may result in that process being triggered. EVE_ENTRY_EXPIRE: Expiration of the DECTECTION_TIMEOUT EVE_DATA_EXPIRE: Expiration of the DECTECTION_TIMEOUT
Top   ToC   RFC7513 - Page 39

7.7. Initial State: DETECTION

7.7.1. Event: EVE_ENTRY_EXPIRE

When this event occurs, no address conflict has been detected during the previous DETECTION_TIMEOUT period. If the Timeouts field in the BST entry is 0: Set the Lifetime of the BST entry to DETECTION_TIMEOUT. Set the Timeouts field to 1. Restart the detection of any local address conflicts by sending a second Duplicate Address Detection Message (Section 7.5.1). Remain in DETECTION state. If the Timeouts field in the BST entry is 1: Assume that there is no local address conflict. Set the State field to RECOVERY. Set the Lifetime of the BST entry to LEASEQUERY_DELAY. Set the Timeouts field to 0. Start the recovery of any DHCP lease associated with the source IP address by sending one or more LEASEQUERY messages (Section 7.5.2). Transition to RECOVERY state. An example of the entry is illustrated in Figure 12. +--------+-------+----------+----------------------+-----+----------+ | Anchor |Address| State | Lifetime | TID | Timeouts | +--------+-------+----------+----------------------+-----+----------+ | Port_1 | Addr1 | RECOVERY | MAX_LEASEQUERY_DELAY | TID | 0 | +--------+-------+----------+----------------------+-----+----------+ Figure 12: Binding Entry in BST on Leasequery Resulting state: DETECTION - If a second local conflict period is required - or RECOVERY - The SAVI device is querying the assignment and lease time of the address in the entry through DHCP Leasequery.

7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply / NA Message Received from Unexpected System

Remove the entry. Resulting state: NO_BIND - No binding has been set up.

7.7.3. Events Not Observed in DETECTION

EVE_DATA_UNMATCH: A data packet without a matched binding is received All EVE_DHCP_* events defined in Section 6.3.2
Top   ToC   RFC7513 - Page 40
   EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is
   received

7.8. Initial State: RECOVERY

7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or successful LEASEQUERY-REPLY is received

Set the State in the BST entry to VERIFY. Depending on the type of triggering source IP address, process the received DHCP Leasequery response: IPv4 address: Update the Lifetime field in the BST entry to the sum of the value encoded in the IP Address Lease Time option of the DHCPLEASEACTIVE message and MAX_DHCP_RESPONSE_TIME. Record the value of the "chaddr" field (hardware address) in the message for checking against the hardware address received during verification in the next state. Set the Timeouts field to 0. Start the verification process by sending an Address Verification Message (see Section 7.5.3). Transition to VERIFY state. Start an additional verification timer with a duration of DETECTION_TIMEOUT. When this expires, an EVE_DATA_EXPIRE event will be generated. IPv6 address: Update the Lifetime field in the BST entry to the sum of the valid lifetime extracted from the OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message and MAX_DHCP_RESPONSE_TIME. Set the Timeouts field to 0. Start the verification process by sending an Address Verification Message (see Section 7.5.3). Transition to VERIFY state. Start an additional verification timer with a duration of DETECTION_TIMEOUT. When this expires, an EVE_DATA_EXPIRE event will be generated. If multiple addresses are received in the LEASEQUERY-REPLY, new BST entries MUST be created for the additional addresses using the same binding anchor. The entries are created with state set to VERIFY and the other fields set as described in this section for the triggering source IP address. Also, start the verification process and start verification timers for each additional address. Resulting state: VERIFY - Awaiting verification or otherwise of the association of the IP address with the connected interface.
Top   ToC   RFC7513 - Page 41

7.8.2. Event: EVE_ENTRY_EXPIRE

Depending on the value of the Timeouts field in the BST entry, either send repeat LEASEQUERY messages or discard the binding: If the Timeouts field in the BST entry is 0: No responses to the LEASEQUERY message(s) sent have been received during the first LEASEQUERY_DELAY period. Set the Lifetime of the BST entry to LEASEQUERY_DELAY. Set the Timeouts field to 1. Restart the recovery of any DHCP lease associated with the source IP address by sending one or more LEASEQUERY messages (Section 7.5.2). Remain in RECOVERY state. If the Timeouts field in the BST entry is 1: No responses to the LEASEQUERY messages sent during two LEASEQUERY_DELAY periods were received. Assume that no leases exist and hence that the source IP address is bogus. Delete the BST entry. Transition to NO_BIND state. Resulting state: RECOVERY - If repeat leasequeries are sent - or NO_BIND - If no successful responses to LEASEQUERY messages have been received.

7.8.3. Events Not Observed in RECOVERY

EVE_DATA_UNMATCH: A data packet without a matched binding is received EVE_DATA_CONFLICT: An ARP Reply / NA message is received from an unexpected system EVE_DATA_VERIFY: A valid ARP Reply or NA message is received from the attached device All EVE_DHCP_* events defined in Section 6.3.2 EVE_DATA_EXPIRE: Expiration of the DECTECTION_TIMEOUT

7.9. Initial State: VERIFY

7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or successful LEASEQUERY-REPLY is received

If LEASEQUERY messages were sent to more than one DHCP server during RECOVERY state, additional successful leasequery responses may be received relating to the source IP address. The conflict resolution mechanisms specified in Section 6.8 of [RFC4388] and Section 4.3.4 of [RFC5007] can be used to determine the message from which values are used to update the BST Lifetime entry and the hardware address
Top   ToC   RFC7513 - Page 42
   obtained from DHCP, as described in Section 7.8.1.  In the case of
   DHCPv6 queries, the LEASEQUERY-REPLY may contain additional addresses
   as described in Section 7.8.1.  If so, additional BST entries MUST be
   created or ones previously created updated as described in that
   section.

   Resulting state: VERIFY (no change).

7.9.2. Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is received from the device attached via the binding anchor

Depending on the type of triggering source IP address, this event may indicate that the device attached via the binding anchor in the BST entry is configured by DHCP using the IP address: IPv4 address: Check that the value of the sender hardware address in the ARP Reply matches the saved "chaddr" field (hardware address) from the previously received DHCPLEASEACTIVE message. If not, ignore this event; a subsequent retry may provide verification. If the hardware addresses match, the binding entry has been verified. IPv6 address: Simple receipt of a valid NA from the triggering source IP address at the binding anchor port provides verification for the binding entry. If the binding entry has been verified, set the state in the BST entry to BOUND. Clear the TID field. Cancel the verification timer. Resulting state: VERIFY (no change) - If the IPv4 DHCPLEASEQUERY "chaddr" address does not match the ARP Reply hardware address. Otherwise, the resulting state is BOUND.

7.9.3. Event: EVE_ENTRY_EXPIRE

The DHCP lease lifetime has expired before the entry could be verified. Remove the entry. Transition to NO_BIND state. Resulting state: NO_BIND - No binding has been set up.
Top   ToC   RFC7513 - Page 43

7.9.4. Event: EVE_DATA_EXPIRE

Depending on the value of the Timeouts field in the BST entry, either send a repeat validation message or discard the binding: If the Timeouts field in the BST entry is 0: No response to the verification message sent has been received during the first DETECTION_TIMEOUT period. Set the Timeouts field to 1. Restart the verification process by sending an Address Verification Message (see Section 7.5.3). Start a verification timer with a duration of DETECTION_TIMEOUT. When this expires, an EVE_DATA_EXPIRE event will be generated. Remain in VERIFY state. If the Timeouts field in the BST entry is 1: No responses to the verification messages sent during two DETECTION_TIMEOUT periods were received. Assume that the configuration of the triggering source IP address cannot be verified and hence that the source IP address is bogus. Delete the BST entry. Transition to NO_BIND state. Resulting state: VERIFY - Additional verification message sent - or NO_BIND - No binding has been set up.

7.9.5. Events Not Observed in VERIFY

EVE_DATA_UNMATCH: A data packet without a matched binding is received EVE_DATA_CONFLICT: An ARP Reply / NA message is received from an unexpected system All EVE_DHCP_* events defined in Section 6.3.2

7.10. Initial State: BOUND

Upon entry to the BOUND state, control of the system continues as if a DHCP message assigning the address has been observed, as in Section 6.4.3. The BST entry has been restored. Note that the TID field contains no value after the binding state changes to BOUND. The TID field is recovered from snooping DHCP Renew/Rebind messages if these are observed as described in the DHCP Snooping Process. Because TID is used to associate binding entries with messages from DHCP servers, it must be recovered or else a number of state transitions of this mechanism will not be executed normally.
Top   ToC   RFC7513 - Page 44

7.11. Table of State Machine

The main state transitions are listed as follows. State Event Action Next State --------------------------------------------------------------------- NO_BIND EVE_DATA_UNMATCH Start duplicate detect DETECTION DETECTION EVE_ENTRY_EXPIRE 1 Repeat duplicate detect DETECTION DETECTION EVE_ENTRY_EXPIRE 2 Start leasequery RECOVERY DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND RECOVERY EVE_ENTRY_EXPIRE 1 Repeat leasequery RECOVERY RECOVERY EVE_ENTRY_EXPIRE 2 No lease found; remove entry NO_BIND RECOVERY EVE_DATA_LEASEQUERY Set lease time; start verify VERIFY VERIFY EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND VERIFY EVE_DATA_LEASEQUERY Resolve lease conflict(s) VERIFY VERIFY EVE_DATA_VERIFY Finish validation BOUND or NO_BIND VERIFY EVE_DATA_EXPIRE 1 Repeat verify VERIFY VERIFY EVE_DATA_EXPIRE 2 Verify failed; remove entry NO_BIND BOUND EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND BOUND RENEW/REBIND Record TID BOUND Figure 13: State Transition Table
Top   ToC   RFC7513 - Page 45
                               +-------------+         EVE_ENTRY_EXPIRE
                     /---------+             |<------------------------\
                     |         |   NO_BIND   |         EVE_DATA_EXPIRE |
    EVE_DATA_UNMATCH |  /----->|             |<----\   (2nd VRF_DELAY) |
                     |  |      +-------------+     |                   |
                     |  |         EVE_ENTRY_EXPIRE |                   |
                     |  |           (2nd LQ_DELAY) |                   |
   EVE_ENTRY_EXPIRE  |  |                          |  EVE_ENTRY_EXPIRE |
   (1st DAD_DELAY)   |  |                          |   (1st LQ_DELAY)  |
         /------\    |  |                          |        /--------\ |
         |      |    |  | EVE_DATA_CONFLICT        \---\    |        | |
         |      v    v  |                              |    v        | |
         |    +-------------+ EVE_ENTRY_EXPIRE       +------------+  | |
         |    |             | (2nd DAD_DELAY)        |            |  | |
         \----+  DETECTION  ------------------------>|  RECOVERY  +--/ |
              |             |                        |            |    |
              +-------------+   (To NO_BIND)         +------------+    |
                                ^                               |      |
                                |           EVE_DATA_LEASEQUERY |      |
                  /----------\  |                               |      |
                  |          |  | EVE_ENTRY_EXPIRE              |      |
    EVE_DHCP_RENEW|          v  |                               v      |
   EVE_DHCP_REBIND|    +-------------+                +-------------+  |
                  |    |             |                |             +--/
                  \----+   BOUND     |<---------------+   VERIFY    |
                       |             | EVE_DATA_VERIFY|             |<-\
                       +-------------+                +-------------+  |
                                                            |          |
                                                            \----------/
                                                     EVE_DATA_LEASEQUERY
                                                         EVE_DATA_EXPIRE
                                                         (1st VRF_DELAY)

                       Figure 14: Diagram of Transit

   LQ_DELAY:  MAX_LEASEQUERY_DELAY
   VRF_DELAY: DETECTION_TIMEOUT



(page 45 continued on part 3)

Next Section