One document matched: draft-ietf-savi-dhcp-34.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?txt version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc tocompact="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="std" docName="draft-ietf-savi-dhcp-34" ipr="trust200902">
<front>
<title abbrev="SAVI DHCP">SAVI Solution for DHCP</title>
<author fullname="Jun Bi" initials="J" surname="Bi">
<organization abbrev="Tsinghua Univ.">Tsinghua University</organization>
<address>
<postal>
<street>Network Research Center, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>China</country>
</postal>
<email>junbi@tsinghua.edu.cn</email>
</address>
</author>
<author fullname="Jianping Wu" initials="J" surname="Wu">
<organization abbrev="Tsinghua Univ.">Tsinghua University</organization>
<address>
<postal>
<street>Computer Science, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>China</country>
</postal>
<email>jianping@cernet.edu.cn</email>
</address>
</author>
<author fullname="Guang Yao" initials="G" surname="Yao">
<organization abbrev="Tsinghua Univ.">Tsinghua University</organization>
<address>
<postal>
<street>Network Research Center, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>China</country>
</postal>
<email>yaoguang@cernet.edu.cn</email>
</address>
</author>
<author fullname="Fred Baker" initials="F" surname="Baker">
<organization abbrev="Cisco">Cisco Systems</organization>
<address>
<postal>
<street/>
<city>Santa Barbara</city>
<region>CA</region>
<code>93117</code>
<country>United States</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date/>
<area>Internet</area>
<workgroup>Source Address Validation Improvement</workgroup>
<keyword>SAVI-DHCP</keyword>
<abstract>
<t>This document specifies the procedure for creating a binding between
a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source
Address Validation Improvements (SAVI) device. The bindings set up by
this procedure are used to filter packets with forged source IP
addresses. This mechanism complements BCP 38 ingress filtering,
providing finer-grained source IP address validation. </t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>This document describes a fine-grained source address validation
mechanism for IPv4 and IPv6 packets. This mechanism creates bindings
between IP addresses assigned to network interfaces by DHCP and suitable
binding anchors (<xref target="anchor_consideration"/>). As discussed in
<xref target="terminology"/> and <xref target="RFC7039"/>, a "binding
anchor" is an attribute that is immutable or difficult to change that
may be used to identify the system an IP address has been assigned to;
common examples include a MAC address found on an Ethernet switch port
or WiFi security association. The bindings are used to identify and
filter packets originated by these interfaces using forged source IP
addresses. In this way, this mechanism can prevent hosts from using IP
addresses assigned to any other attachment point in or not associated
with the network. This behavior is referred to as "spoofing", and is key
to amplification attacks, in which a set of systems send messages to
another set of systems claiming to be from a third set of systems, and
sending the replies to systems that don't expect them. Whereas <xref
target="RFC2827">BCP 38</xref> protects a network from a neighboring
network by providing prefix granularity source IP address validity, this
mechanism protects a network, including a Local Area Network, from
itself by providing address granularity source IP validity when
DHCP/DHCPv6 is used to assign IPv4/IPv6 addresses. Both provide a
certain level of traceability, in that packet drops indicate the
presence of a system that is producing packets with spoofed IP
addresses.</t>
<t>SAVI-DHCP snoops DHCP address assignments to set up bindings between
IP addresses assigned by DHCP and corresponding binding anchors. It
includes the DHCPv4 and v6 snooping process (<xref target="regular"/>),
the Data Snooping process (<xref target="bindrecovery"/>), as well as a
number of other technical details. The Data Snooping process is a
data-triggered procedure that snoops the IP header of data packets to
set up bindings. It is designed to avoid a permanent blockage of valid
addresses in the case that DHCP snooping is insufficient to set up all
the valid bindings.</t>
<t>This mechanism is designed for the stateful DHCP scenario <xref
target="RFC2131"/>, <xref target="RFC3315"/>. Stateless DHCP <xref
target="RFC3736"/> is out of scope for this document, as it has nothing
to do with IP address allocation. An alternative SAVI method would have
be used in those cases. For hosts using Stateless Address
Auto-Configuration (SLAAC) to allocate addresses, <xref
target="RFC6620">SAVI-FCFS</xref> should be enabled. SAVI-DHCP is
primarily designed for pure DHCP scenarios in which only addresses
assigned through DHCP are allowed. However, it does not block link-local
addresses, as they are not assigned using DHCP. It is RECOMMENDED that
the administration deploy a SAVI solution for link-local addresses,
e.g., <xref target="RFC6620">SAVI-FCFS</xref>.</t>
<t>This mechanism works for networks that use DHCPv4 only, DHCPv6 only,
or both DHCPv4 and DHCPv6. However, the DHCP address assignment
mechanism in IPv4/IPv6 transition scenarios, e.g., <xref
target="RFC7341"/>, are beyond the scope of this document.</t>
</section>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>Binding anchor: A "binding anchor" is defined to be a physical and/or
link-layer property of an attached device, as in <xref
target="RFC7039"/>. A list of sample binding anchors can be found in
<xref target="terminology"/>.2 of that document. To the degree possible,
a binding anchor associates an IP address with something unspoofable
that identifies a single client system or one of its interfaces. See
<xref target="anchor_consideration"/> for more detail.</t>
<t>Attribute: A configurable property of each binding anchor (port, MAC
Address, or other information) that indicates the actions to be
performed on packets received from the attached network device.</t>
<t>DHCP address: An IP address assigned via DHCP.</t>
<t>SAVI-DHCP: The name of this SAVI function for DHCP-assigned
addresses.</t>
<t>SAVI device: A network device on which SAVI-DHCP is enabled.</t>
<t>Non-SAVI device: A network device on which SAVI-DHCP is not
enabled.</t>
<t>DHCP Client-Server message: A message that is sent from a DHCP client
to a DHCP server or DHCP servers. Such a message is of one of the
following types:</t>
<t><list hangIndent="4" style="symbols">
<t>DHCPv4 Discover: DHCPDISCOVER <xref target="RFC2131"/></t>
<t>DHCPv4 Request: DHCPREQUEST generated during SELECTING state
<xref target="RFC2131"/></t>
<t>DHCPv4 Renew: DHCPREQUEST generated during RENEWING state <xref
target="RFC2131"/></t>
<t>DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state <xref
target="RFC2131"/></t>
<t>DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state
<xref target="RFC2131"/></t>
<t>Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be
identified based on the Table 4 of <xref target="RFC2131"/></t>
<t>DHCPv4 Decline: DHCPDECLINE <xref target="RFC2131"/></t>
<t>DHCPv4 Release: DHCPRELEASE <xref target="RFC2131"/></t>
<t>DHCPv4 Inform: DHCPINFORM <xref target="RFC2131"/></t>
<t>DHCPv4 DHCPLEASEQUERY: A message sent to enquire about the lease
that might exist for an IPv4 address. <xref target="RFC4388"/></t>
<t>DHCPv6 Request: REQUEST <xref target="RFC3315"/></t>
<t>DHCPv6 Solicit: SOLICIT <xref target="RFC3315"/></t>
<t>DHCPv6 Confirm: CONFIRM <xref target="RFC3315"/></t>
<t>DHCPv6 Decline: DECLINE <xref target="RFC3315"/></t>
<t>DHCPv6 Release: RELEASE <xref target="RFC3315"/></t>
<t>DHCPv6 Rebind: REBIND <xref target="RFC3315"/></t>
<t>DHCPv6 Renew: RENEW <xref target="RFC3315"/></t>
<t>DHCPv6 Information-Request: INFORMATION-REQUEST <xref
target="RFC3315"/></t>
<t>DHCPv6 LEASEQUERY: A message sent to enquire about the lease that
might exist for an IPv6 address. <xref target="RFC5007"/></t>
</list></t>
<t>DHCP Server-to-Client message: A message that is sent from a DHCP
server to a DHCP client. Such a message is of one of the following
types:</t>
<t><list hangIndent="4" style="symbols">
<t>DHCPv4 ACK: DHCPACK <xref target="RFC2131"/></t>
<t>DHCPv4 NAK: DHCPNAK <xref target="RFC2131"/></t>
<t>DHCPv4 Offer: DHCPOFFER <xref target="RFC2131"/></t>
<t>DHCPv4 DHCPLEASEACTIVE: A response to a DHCPLEASEQUERY request
containing lease information. <xref target="RFC4388"/></t>
<t>DHCPv4 DHCPLEASEUNKNOWN: A response to a DHCPLEASEQUERY request
indicating that the server does not manage the address. <xref
target="RFC4388"/></t>
<t>DHCPv4 DHCPLEASEUNASSIGNED: A response to a DHCPLEASEQUERY
request indicating that the server manages the address and there is
no current lease. <xref target="RFC4388"/></t>
<t>DHCPv6 Reply: REPLY <xref target="RFC3315"/></t>
<t>DHCPv6 Advertise: ADVERTISE <xref target="RFC3315"/></t>
<t>DHCPv6 Reconfigure: RECONFIGURE <xref target="RFC3315"/></t>
<t>DHCPv6 LEASEQUERY-REPLY: A response to a LEASEQUERY request.
<xref target="RFC5007"/></t>
</list></t>
<t>Lease time: The lease time in IPv4 <xref target="RFC2131"/> or the
valid lifetime in IPv6 <xref target="RFC3315"/>.</t>
<t>Binding entry: A rule that associates an IP address with a binding
anchor.</t>
<t>Binding State Table (BST): The data structure that contains the
binding entries.</t>
<t>Binding entry limit: The maximum number of binding entries that may
be associated with a binding anchor. Limiting the number of binding
entries per binding anchor prevents a malicious or malfunctioning node
from overloading the binding table on a SAVI device.</t>
<t>Direct attachment: Ideally, a SAVI device is an access device that
hosts are attached to directly. In such a case, the hosts are direct
attachments (i.e., they attach directly) to the SAVI device.</t>
<t>Indirect attachment: A SAVI device MAY be an aggregation device that
other access devices are attached to, and which hosts in turn attach to.
In such a case, the hosts are indirect attachments (i.e., they attach
indirectly) to the SAVI device.</t>
<t>Unprotected link: Unprotected links are links that connect to hosts
or networks of hosts receive their DHCP traffic by another path, and are
therefore outside the SAVI perimeter.</t>
<t>Unprotected device: An unprotected device is a device associated with
an unprotected link. One example might be the gateway router of a
network.</t>
<t>Protected link: If DHCP messages for a given attached device always
use a given link, the link is considered to be "protected" by the SAVI
Device, and is therefore within the SAVI perimeter.</t>
<t>Protected device: A protected device is a device associated with a
protected link. One example might be a desktop switch in the network, or
a host.</t>
<t>Cut Vertex: A cut vertex is any vertex whose removal increases the
number of connected components in a (network) graph. This is a concept
in graph theory. This term is used in <xref target="rationale"/> to
accurately specify the required deployment location of SAVI devices when
they only perform the DHCP Snooping Process.</t>
<t>Identity Association (IA): "A collection of addresses assigned to a
client." <xref target="RFC3315"/></t>
<t>Detection message: a Neighbor Solicitation or ARP message intended by
the Data Snooping Process to detect a duplicate address.</t>
<t>DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the
binding is triggered by a DHCPv6 Confirm message but a DHCPv6 lease
query exchange <xref target="RFC5007"/> cannot be performed by the SAVI
device to fetch the lease.</t>
</section>
<section anchor="scenario" title="Deployment Scenario and Configuration">
<section anchor="dhcp_scenario" title="Elements and Scenario">
<t>The essential elements in a SAVI-DHCP deployment scenario include
at least one DHCP server (which may or may not be assigned an address
using DHCP, and therefore may or may not be protected), zero or more
protected DHCP clients, and one or more SAVI devices. It may also
include DHCP relays, when the DHCP server is not co-located with a set
of clients, and zero or more protected Non-SAVI devices. Outside the
perimeter, via unprotected links, there may be many unprotected
devices.</t>
<figure anchor="fig_scenario" title="SAVI-DHCP Scenario">
<artwork align="center"><![CDATA[
+-------------+
| unprotected |
| device |
+------+------+
|
+--------+ +-----+------+ +----------+
|DHCP +-----+ Non-SAVI +----+Bogus DHCP|
|Server A| | Device 1 | |Server |
+--------+ +-----+------+ +----------+
|trusted, unprotected link
. . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
. | .
. Protection +---+------+ trusted link .
. Perimeter | SAVI +--------------+ .
. | Device C| | .
. +---+------+ | .
. | | .
. untrusted, +----------+ +---+------+ +------+---+ .
. protected | SAVI | | Non SAVI| | SAVI | .
. link+------+ Device A+----+ Device 3+-------+ Device B| .
. | +----+--+--+ +----------+ +-+---+----+ .
. | | +----------+ . . . . . | | .
. | . . . . . . | . . | | .
. | . | . | . +--------+ | .
. +----+-----+. +--+---+ . +----+-+ . +--+---+ . +---+----+ .
. | Non-SAVI |. |Client| . |DHCP | . |Client| . |DHCP | .
. | Device 2 |. |A | . |Relay | . |B | . |Server B| .
. +----------+. +------+ . +------+ . +------+ . +--------+ .
. . . . . . . . . . . . . . . . . . .
]]></artwork>
</figure>
<t><xref target="fig_scenario"/> shows a deployment scenario that
contains these elements. Note that a physical device can instantiate
multiple elements, e.g., a switch can be both a SAVI device and a DHCP
relay, or in a cloud computing environment, a physical host may
contain a virtual switch plus some number of virtual hosts. In such
cases, the links are logical links rather than physical links.</t>
<t>Networks are not usually isolated. As a result, traffic from other
networks, including transit traffic as specified in <xref
target="RFC6620"/> (e.g., traffic from another SAVI switch or a
router) may enter a SAVI-DHCP network through the unprotected links.
Since SAVI solutions are limited to validating traffic generated from
a local link, SAVI-DHCP does not set up bindings for addresses
assigned in other networks and cannot validate them. Traffic from
unprotected links should be checked by an unprotected device or <xref
target="RFC2827"/> mechanisms. The generation and deployment of such a
mechanism is beyond the scope of this document.</t>
<t>Traffic from protected links is, however, locally generated, and
should have its source addresses validated by SAVI-DHCP if possible.
In the event that there is an intervening protected non-SAVI device
between the host and the SAVI device, however, use of the physical
attachment point alone as a binding anchor is insufficiently secure,
as the several devices on a port or other point of attachment can
spoof each other. Hence, additional information such as a MAC address
SHOULD be used to disambiguate them.</t>
</section>
<section anchor="attribute" title="SAVI Binding Type Attributes">
<t>As illustrated in <xref target="fig_scenario"/>, a system attached
to a SAVI device can be a DHCP client, a DHCP relay/server, a SAVI
device, or a non-SAVI device. Different actions are performed on
traffic originated from different elements. To distinguish among their
requirements, several properties are associated with their point of
attachment on the SAVI device.</t>
<t>When a binding association is uninstantiated, e.g., when no host is
attached to the SAVI device using a given port or other binding
anchor, the binding port attributes take default values unless
overridden by configuration. By default, a SAVI switch does not filter
DHCP messages, nor does it attempt to validate source addresses, which
is to say that the binding attributes are ignored until SAVI-DHCP is
itself enabled. This is because a SAVI switch that depends on DHCP
cannot tell, a priori, which ports have valid DHCP servers attached,
or which have routers or other equipment that would validly appear to
use an arbitrary set of source addresses. When SAVI has been enabled,
the attributes take effect.</t>
<section anchor="trustattribute" title="Trust Attribute">
<t>The "Trust Attribute" is a Boolean value. If TRUE, it indicates
that the packets from the corresponding attached device need not
have their source addresses validated. Examples of a trusted
attachment would be a port to another SAVI device, or to an IP
router, as shown in <xref target="fig_scenario"/>. In both cases,
traffic using many source IP addresses will be seen. By default, the
Trust attribute is FALSE, indicating that any device found on that
port will seek an address using DHCP and be limited to using such
addresses.</t>
<t>SAVI devices will not set up bindings for points of attachment
with the Trust attribute set TRUE; no packets, including DHCP
messages, from devices with this attribute on their attachments will
be validated. However DHCP Server-to-Client messages will be snooped
on attachment points with the Trust attribute set TRUE in the same
way as if they had the DHCP-Trust attribute set (see <xref
target="savidhcptrust"/>.)</t>
</section>
<section anchor="savidhcptrust" title="DHCP-Trust Attribute">
<t>The "DHCP-Trust Attribute" is similarly a Boolean attribute. It
indicates whether the attached device is permitted to initiate DHCP
Server-to-Client messages. In <xref target="fig_scenario"/>, the
points of attachment of the DHCP Server and the DHCP Relay would
have this attribute set TRUE, and attachment points that have Trust
set TRUE are implicitly treated as if DHCP-Trust is TRUE..</t>
<t>If the DHCP-Trust Attribute is TRUE, SAVI devices will forward
DHCP Server-to-Client messages from the points of attachment with
this attribute. If the DHCP Server-to-Client messages can trigger
the state transitions, the binding setup processes specified in
<xref target="regular"/> and <xref target="bindrecovery"/> will
handle them. By default, the DHCP-Trust attribute is FALSE,
indicating that the attached system is not a DHCP server.</t>
<t>A DHCPv6 implementor can refer to <xref
target="I-D.ietf-opsec-dhcpv6-shield"/> for more details.</t>
</section>
<section anchor="dhcpsnoopingattribute"
title="DHCP-Snooping Attribute">
<t>The "DHCP-Snooping Attribute" is similarly a Boolean attribute.
It indicates whether bindings will be set up based on DHCP
snooping.</t>
<t>If this attribute is TRUE, DHCP Client-Server messages to points
of attachment with this attribute will trigger creation of bindings
based on the DHCP Snooping Process described in <xref
target="regular"/>. If it is FALSE, either the Trust attribute must
be TRUE (so that bindings become irrelevant) or another SAVI
mechanism such as SAVI-FCFS must be used on the point of
attachment.</t>
<t>The DHCP-Snooping attribute is configured on the DHCP Client's
point of attachment. This attribute can be also used on the
attachments to protected Non-SAVI devices that are used by DHCP
clients. In <xref target="fig_scenario"/>, the attachment from the
Client A to the SAVI Device A, the attachment from the Client B to
the SAVI Device B, and the attachment from the Non-SAVI Device 2 to
the SAVI Device A can be configured with this attribute.</t>
</section>
<section anchor="savibindrecovery" title="Data-Snooping Attribute">
<t>The "Data-Snooping Attribute" is a Boolean attribute. It
indicates whether data packets from the corresponding point of
attachment may trigger the binding setup procedure.</t>
<t>Data packets from points of attachment with this attribute may
trigger the setup of bindings. SAVI devices will set up bindings on
points of attachment with this attribute based on the data-triggered
process described in <xref target="bindrecovery"/>.</t>
<t>If the DHCP-Snooping attribute is configured on a point of
attachment, the bindings on this attachment are set up based on DHCP
message snooping. However, in some scenarios, a DHCP client may use
a DHCP address without the DHCP address assignment procedure being
performed on its current attachment. For such attached devices, the
Data Snooping Process, which is described in <xref
target="bindrecovery"/>, is necessary. This attribute is configured
on such attachments. The usage of this attribute is further
discussed in <xref target="bindrecovery"/>.</t>
<t>Since some networks require DHCP deployment and others avoid it,
there is no obvious universal default value for the Data-Snooping
Attribute. Hence, the Data-Snooping Attribute should default to
FALSE, and a mechanism should be implemented to conveniently set it
to TRUE on all points of attachment for which the Trust attribute is
FALSE.</t>
</section>
<section anchor="savivalidation" title="Validating Attribute">
<t>The "Validating Attribute" is a Boolean attribute. It indicates
whether packets from the corresponding attachment will have their IP
source addresses validated based on binding entries on the
attachment.</t>
<t>If it is TRUE, packets coming from attachments with this
attribute will be validated based on binding entries on the
attachment as specified in <xref target="filterrule"/>. If it is
FALSE, they will not. Since the binding table is used in common with
other SAVI algorithms, it merely signifies whether the check will be
done, not whether it will be done for SAVI-DHCP originated
bindings.</t>
<t>This attribute is by default the inverse of the Trust attribute;
source addresses on untrusted links are validated by default. It MAY
be set FALSE by the administration.</t>
<t>The expected use case is when SAVI is used to monitor but not
block forged transmissions. The network manager, in that case, may
set the DHCP-Snooping and/or Data-Snooping attribute TRUE but the
Validating attribute FALSE.</t>
</section>
<section anchor="mutualtable" title="Table of Mutual Exclusions">
<t>Different types of attributes may indicate mutually exclusive
actions on a packet. Mutually exclusive attributes MUST NOT be set
TRUE on the same attachment. The compatibility of different
attributes is listed in <xref target="fig_mutualtable"/>. Note that
although Trust and DHCP-Trust are compatible, there is no need to
configure DHCP-Trust to TRUE on an attachment with Trust attribute
TRUE.</t>
<figure anchor="fig_mutualtable" title="Table of Mutual Exclusions">
<artwork align="center"><![CDATA[+----------+----------+----------+----------+----------+----------+
| | | | DHCP- | Data- | |
| | Trust |DHCP-Trust| Snooping | Snooping |Validating|
+----------+----------+----------+----------+----------+----------+
| | | | mutually | mutually | mutually |
| Trust | - |compatible| exclusive| exclusive| exclusive|
+----------+----------+----------+----------+----------+----------+
| | | | | | |
|DHCP-Trust|compatible| - |compatible|compatible|compatible|
+----------+----------+----------+----------+----------+----------+
|DHCP- |mutually | | | | |
|Snooping |exclusive |compatible| - |compatible|compatible|
+----------+----------+----------+----------+----------+----------+
|Data- |mutually | | | | |
|Snooping |exclusive |compatible|compatible| - |compatible|
+----------+----------+----------+----------+----------+----------+
| |mutually | | | | |
|Validating|exclusive |compatible|compatible|compatible| - |
+----------+----------+----------+----------+----------+----------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="perimeter" title="Perimeter">
<section anchor="perimeter_overview"
title="SAVI-DHCP Perimeter Overview">
<t>SAVI devices form a perimeter separating trusted and untrusted
regions of a network, as SAVI-FCFS does ( Section 2.5 of <xref
target="RFC6620"/>). The perimeter is primarily designed for
scalability. It has two implications. <list style="symbols">
<t>SAVI devices only need to establish bindings for directly
attached clients, or clients indirectly attached through a
non-SAVI protected device, rather than all of the clients in the
network.</t>
<t>Each SAVI device only needs to validate the source addresses
in traffic from clients attached to it, without checking all the
traffic passing by.</t>
</list></t>
<t>Consider the example in <xref target="fig_scenario"/>. The
protection perimeter is formed by SAVI Devices A, B and C. In this
case, SAVI device B does not create a binding for client A. However,
because SAVI device A filters spoofed traffic from client A, SAVI
device B can avoid receiving spoofed traffic from client A.</t>
<t>The perimeter in SAVI-DHCP is not only a perimeter for data
packets, but also a perimeter for DHCP messages. DHCP server
response messages incoming across the perimeter will be dropped
(<xref target="filterrule"/>). The placement of the DHCP Relay and
DHCP Server, which are not involved in <xref target="RFC6620"/>, is
related to the construction of the perimeter. The requirement on the
placement and configuration of DHCP Relay and DHCP Server are
discussed in <xref target="placement"/>.</t>
</section>
<section anchor="perimeter_config"
title="SAVI-DHCP Perimeter Configuration Guideline">
<t>A perimeter separating trusted and untrusted regions of the
network is formed as follows: <list hangIndent="4"
style="format (%d)">
<t>Configure the Validating and DHCP-Snooping attributes TRUE on
the direct attachments of all DHCP clients.</t>
<t>Configure the Validating and DHCP-Snooping attributes TRUE on
the indirect attachments of all DHCP clients (i.e., DHCP clients
on protected links).</t>
<t>Configure the Trust attribute TRUE on the attachments to
other SAVI devices.</t>
<t>If a Non-SAVI device, or a number of connected Non-SAVI
devices, are attached only to SAVI devices, set the Trust
attribute TRUE on their attachments.</t>
<t>Configure the DHCP-Trust attribute TRUE on the direct
attachments to trusted DHCP relays and servers.</t>
</list></t>
<t>In this way, the points of attachments with the Validating
attribute TRUE (and generally together with attachments of
unprotected devices) on SAVI devices can form a perimeter separating
DHCP clients and trusted devices. Data packet checks are only
performed on the perimeter. The perimeter is also a perimeter for
DHCP messages. The DHCP-Trust attribute is only TRUE on links inside
the perimeter. Only DHCP Server-to-Client messages originated within
the perimeter are trusted.</t>
</section>
<section anchor="placement"
title="On the Placement of the DHCP Server and Relay">
<t>As a result of the configuration guidelines, SAVI devices only
trust DHCP Server-to-Client messages originated inside the
perimeter. Thus, the trusted DHCP Relays and DHCP Servers must be
placed within the perimeter. DHCP Server-to-Client messages will be
filtered on the perimeter. Server-to-relay messages will not be
filtered, as they are within the perimeter. In this way, DHCP
Server-to-Client messages from bogus DHCP servers are filtered on
the perimeter, having entered through untrusted points of
attachment. The SAVI devices are protected from forged DHCP
messages.</t>
<t>DHCP Server-to-Client messages arriving at the perimeter from
outside the perimeter are not trusted. There is no distinction
between a DHCP server owned and operated by the correct
administration but outside the SAVI perimeter and a bogus DHCP
server. For example, in <xref target="fig_scenario"/>, DHCP server A
is valid, but it is attached to Non-SAVI device 1. A bogus DHCP
server is also attached Non-SAVI device 1. While one could imagine a
scenario in which the valid one had a statistically configured port
number and MAC address, and therefore a binding, by default
SAVI-DHCP cannot distinguish whether a message received from the
port of Non-SAVI device 1 is from DHCP server A or the bogus DHCP
server. If the DHCP server A is contained in the perimeter, Non-SAVI
device 1 will also be contained in the perimeter. Thus, the DHCP
server A cannot be contained within the perimeter apart from manual
configuration of the binding anchor.</t>
<t>Another consideration on the placement is that if the DHCP
server/relay is not inside the perimeter, the SAVI devices may not
be able to set up bindings correctly, because the SAVI devices may
not be on the path between the clients and the server/relay, or the
DHCP messages are encapsulated (e.g., Relay-reply and
Relay-forward).</t>
</section>
<section anchor="alternative" title="An Alternative Deployment">
<t>In common deployment practice, the traffic from the unprotected
network is treated as trustworthy, which is to say that it is not
filtered. In such a case, the Trust attribute can be set TRUE on the
unprotected link. If Non-SAVI devices, or a number of connected
Non-SAVI devices, are only attached to SAVI devices and unprotected
devices, their attachment to SAVI devices can have the Trust
attribute set TRUE. Then an unclosed perimeter will be formed, as
illustrated in <xref target="fig_alternative"/>.</t>
<t/>
<figure anchor="fig_alternative"
title="Alternative Perimeter Configuration">
<artwork align="center"><![CDATA[
| . . Protection |
| | | Perimeter |
| | | |
| Unprotected | | Unprotected |
| Link | | Link |
| | | |
| | | |
| +----+---+ +----+---+ +--------+ |
| |SAVI +----+Non-SAVI+----+SAVI | |
| |Device | |Device | |Device | |
| +----+---+ +--------+ +----+---+ |
| | | |
\_____________+___________________________+________/
| |
| |
+--------+ +--------+
|DHCP | |DHCP |
|Client | |Client |
+--------+ +--------+
]]></artwork>
</figure>
</section>
<section anchor="anchor_consideration"
title="Considerations regarding Binding Anchors">
<t>The strength of this binding-based mechanism depends on the
strength of the binding anchor. The sample binding anchors in <xref
target="RFC7039"/> have the property that they associate an IP
address with a direct physical or secure virtual interface such as a
switch port, a subscriber association, or a security association. In
addition, especially in the case that a protected non-SAVI device
such as a desktop switch or a hub is between the client and SAVI
devices, they MAY be extended to also include a MAC address or other
link-layer attribute. In short, a binding anchor is intended to
associate an IP address with something unspoofable that identifies a
single client system or one of its interfaces; this may be a
physical or virtual interface or that plus disambiguating link-layer
information.</t>
<t>If the binding anchor is spoofable, such as a plain MAC address,
or non-exclusive, such as a switch port extended using a non-SAVI
device, an attacker can use a forged binding anchor to evade
validation. Indeed, using a binding anchor that can be easily
spoofed can lead to worse outcomes than allowing spoofed IP traffic.
Thus, a SAVI device MUST use a non-spoofable and exclusive binding
anchor.</t>
</section>
</section>
<section anchor="address_conf" title="Other Device Configuration">
<t>In addition to a possible binding anchor configuration specified in
<xref target="attribute"/>, an implementation has the following
configuration requirements: <list hangIndent="4" style="format (%d)">
<t>Address configuration. For DHCPv4: the SAVI device MUST have an
IPv4 address. For DHCPv6: the client of a SAVI device MUST have a
link-local address; when the DHCPv6 server is not on the same link
as the SAVI device, the SAVI device MUST also have an IPv6 address
of at least the same scope as the DHCPv6 Server.</t>
<t>DHCP server address configuration: a SAVI device MUST store the
list of the DHCP server addresses that it could contact during a
Lease query process.</t>
<t>A SAVI device may also require security parameters, such as
pre-configured keys to establish a secure connection for the Lease
query process <xref target="RFC4388"/><xref target="RFC5007"/>
connection.</t>
</list></t>
</section>
</section>
<section anchor="bst" title="Binding State Table (BST)">
<t>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 5 fields: <list hangIndent="4"
style="symbols">
<t>Binding Anchor(Anchor): the binding anchor, i.e., one or more
physical and/ or link-layer properties of the attachment.</t>
<t>IP Address(Address): the IPv4 or IPv6 address assigned to the
attachment by DHCP.</t>
<t>State: the state of the binding. Possible values of this field
are listed in <xref target="regularstate"/> and <xref
target="bindrecovery_state"/>.</t>
<t>Lifetime: the remaining seconds of the binding. Internally, this
MAY be stored as the timestamp value at which the lifetime
expires.</t>
<t>TID: the Transaction ID (TID) ( <xref target="RFC2131"/> <xref
target="RFC3315"/>) of the corresponding DHCP transaction. TID field
is used to associate DHCP Server-to-Client messages with
corresponding binding entries.</t>
<t>Timeouts: the number of timeouts that expired in the current
state (only used in Data Snooping Process, see <xref
target="bindrecovery"/>.)</t>
</list></t>
<t>The IA is not present in the BST for three reasons: <list
style="symbols">
<t>The lease of each address in one IA is assigned separately.</t>
<t>When the binding is set up based on data snooping, the IA cannot
be recovered from the lease query protocol.</t>
<t>DHCPv4 does not define an IA.</t>
</list></t>
<t>An example of such a table is shown in <xref
target="bstinstance"/>.</t>
<figure anchor="bstinstance" title="Example Binding State Table">
<artwork align="center"><![CDATA[+---------+----------+-----------+-----------+--------+----------+
| 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 |
+---------+----------+-----------+-----------+--------+----------+
]]></artwork>
</figure>
</section>
<section anchor="regular" title="DHCP Snooping Process">
<t>This section specifies the process of setting up bindings based on
DHCP snooping. This process is illustrated using a state machine.</t>
<section anchor="rationale" title="Rationale">
<t>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)/ and 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.</t>
<t>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 <xref target="bindrecovery"/>.</t>
</section>
<section anchor="regularstate" title="Binding States Description">
<t>Following binding states are present in this process and the
corresponding state machine:</t>
<t>NO_BIND: No binding has been set up.</t>
<t>INIT_BIND: A potential binding has been set up.</t>
<t>BOUND: The binding has been set up.</t>
</section>
<section anchor="regularevent" title="Events">
<t>This section describes events in this process and the corresponding
state machine transitions. The DHCP message categories (e.g., DHCPv4
Discover) defined in <xref target="terminology"/> 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.</t>
<section anchor="timerevent" title="Timer Expiration Event">
<t>EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires.</t>
</section>
<section anchor="controlevent" title="Control Message Arriving Events">
<t>EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is
received.</t>
<t>EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received.</t>
<t>EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received.</t>
<t>EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is
received.</t>
<t>EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is
received.</t>
<t>EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid
Commit option is received.</t>
<t>EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is
received.</t>
<t>EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is
received.</t>
<t>EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is
received.</t>
<t>EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY (refer
to section 4.3.3 of <xref target="RFC5007"/>) is received.</t>
<t>Note: the events listed here do not cover all the DHCP messages
in <xref target="terminology"/>. The messages which do not really
determine address usage (DHCPv4 Discover, DHCPv4 Inform, DHCPv6
Solicit without Rapid Commit, DHCPv6 Information-Request, DHCPv4
Offer, DHCPv6 Advertise, DHCPv6 Reconfigure), and which are not
necessary to snoop (DHCPv4 NAK, refer to section 6.4.2.1), are not
included. Note also that DHCPv4 DHCPLEASEQUERY is not used in the
DHCP Snooping process to avoid confusion with <xref
target="bindrecovery"/>. 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.</t>
<t>Moreover, only if a DHCP message can pass the following checks,
the corresponding event is regarded as a valid event:</t>
<t><list hangIndent="4" style="symbols">
<t>Attribute check: the DHCP Server-to-Client messages and
LEASEQUERY-REPLY should be from attachments with DHCP-Trust
attribute; the DHCP Client-Server messages should be from
attachments with DHCP-Snooping attribute.</t>
<t>Destination check: the DHCP Server-to-Client messages should
be destined to attachments with DHCP-Snooping attribute. This
check is performed to ensure the binding is set up on the SAVI
device which is nearest to the destination client.</t>
<t>Binding anchor check: the DHCP Client-Server messages which
may trigger modification or removal of an existing binding entry
must have a matching binding anchor with the corresponding
entry.</t>
<t>TID check: the DHCP Server-to-Client/Client-Server messages
which may cause modification on existing binding entries must
have matched TID with the corresponding entry. Note that this
check is not performed on Lease query and Lease query-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.</t>
<t>Binding limitation check: the DHCP messages must not cause
new binding setup on an attachment whose binding entry
limitation has been reached. (refer to <xref
target="security_limitation"/>).</t>
<t>Address check: the source address of the DHCP messages should
pass the check specified in <xref target="controlfilter"/>.</t>
</list></t>
<t>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 <xref target="controlfilter"/>, it MUST be forwarded.</t>
</section>
</section>
<section anchor="statemachine"
title="The State Machine of DHCP Snooping Process">
<t>This section specifies state transitions and their corresponding
actions.</t>
<section anchor="nb_dhcp_state"
title="Initial State: NO_BIND - No binding has been set up">
<section title="Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request message is received">
<t>The SAVI device MUST forward the message.</t>
<t>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 <xref target="bst_init"/>.</t>
<figure anchor="bst_init"
title="Binding entry in BST on Request/Rapid Commit/Reboot triggered initialization">
<artwork align="center"><![CDATA[
+--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+--------+-------+---------+-----------------------+-----+----------+
]]></artwork>
</figure>
<t>Resulting state: INIT_BIND - A potential binding has been set
up</t>
</section>
<section title="Event: EVE_DHCP_REBOOT - A DHCPv4 Reboot message is received">
<t>The SAVI device MUST forward the message.</t>
<t>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 <xref target="bst_init"/>.</t>
<t>Resulting state: INIT_BIND - A potential binding has been set
up</t>
</section>
<section title="Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message with Rapid Commit option is received">
<t>The SAVI device MUST forward the message.</t>
<t>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 <xref target="bst_init"/>.</t>
<t>Resulting state: INIT_BIND - A potential binding has been set
up</t>
</section>
<section title="Event: EVE_DHCP_CONFIRM - A DHCPv6 Confirm message is received">
<t>The SAVI device MUST forward the message.</t>
<t>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 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 <xref
target="bst_init_cfm"/>.</t>
<figure anchor="bst_init_cfm"
title="Binding entry in BST on Confirm triggered initialization">
<artwork align="center"><![CDATA[
+--------+-------+---------+-----------------------+-----+----------+
| 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 |
+--------+-------+---------+-----------------------+-----+----------+
]]></artwork>
</figure>
<t>Resulting state: INIT_BIND - A potential binding has been set
up</t>
</section>
<section title="Events that cannot happen in the NO_BIND state">
<t><list style="symbols">
<t>EVE_ENTRY_EXPIRE: The lifetime of a binding entry
expires</t>
<t>EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message
is received</t>
<t>EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is
received</t>
<t>EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is
received</t>
<t>EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline
message is received</t>
<t>EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release
message is received</t>
<t>EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY
is received</t>
</list></t>
<t>These cannot happen because they are each something that
happens AFTER a binding has been created.</t>
</section>
</section>
<section anchor="init"
title="Initial State: INIT_BIND - A potential binding has been set up">
<section title="Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message is received">
<t>The message MUST be forwarded to the corresponding client.</t>
<t>If the message is DHCPv4 ACK, the Address field of the
corresponding entry (i.e., the binding entry whose TID is the same
of 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 ACK message and MAX_DHCP_RESPONSE_TIME. The
State field is changed to BOUND.</t>
<t>If the message is DHCPv6 Reply, there are following cases:<list
style="numbers">
<t>If the status code is not "Success", no modification on
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 due to
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." <xref target="RFC3315"/>).</t>
<t>If the status code is "Success", the SAVI device checks the
IA options in the Reply message.<list style="letters">
<t>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 matched TID is set to the address. The Lifetime field
is set to the sum of the lease time in Reply message and
MAX_DHCP_RESPONSE_TIME. The State field is changed to
BOUND. If there are 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 <xref
target="bst_bound_reply"/>. SAVI devices do not specially
process IA options with NoAddrsAvail status, because there
should be no address contained in such IA options.</t>
<t>Otherwise, the DHCP Reply message is in response to a
Confirm message. The state of the binding entries with
matched TID is changed to BOUND. Because <xref
target="RFC3315"/> does not require lease time of
addresses to be contained in the Reply message, the SAVI
device SHOULD send a LEASEQUERY <xref target="RFC5007"/>
message querying by IP address to All_DHCP_Servers
multicast address <xref target="RFC3315"/> or a list of
configured DHCP server addresses. The Lease query 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 <xref
target="bst_bound_nolease"/>. If the SAVI device does not
send the LEASEQUERY message, a pre-configured 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.)</t>
</list></t>
</list></t>
<t>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.</t>
<figure anchor="bst_bound_nolease"
title="From INIT_BIND to BOUND on DHCP Reply in response to Confirm">
<artwork align="center"><![CDATA[
+--------+-------+-------+------------------------+-----+----------+
| 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 |
+--------+-------+-------+------------------------+-----+----------+
]]></artwork>
</figure>
<figure anchor="bst_bound_reply"
title="From INIT_BIND to BOUND on DHCP Reply in response to Request">
<artwork align="center"><![CDATA[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 | | |
+--------+-------+-------+------------------------+-----+----------+
]]></artwork>
</figure>
<t>Resulting state: BOUND - The binding has been set up</t>
</section>
<section title="Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry expires">
<t>The entry MUST be deleted from BST.</t>
<t>Resulting state: An entry that has been deleted from the BST
may be considered to be in the state "NO_BIND" - No binding has
been set up.</t>
</section>
<section title="Events that are ignored in INIT_BIND">
<t>If no DHCP Server-to-Client messages which 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.</t>
<t>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. <list
style="symbols">
<t>EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request
message is received</t>
<t>EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received</t>
<t>EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received</t>
<t>EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message
is received</t>
<t>EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is
received</t>
<t>EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with
Rapid Commit option is received</t>
<t>EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline
message is received</t>
<t>EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release
message is received</t>
<t>EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY
is received</t>
</list></t>
<t>In each case, the message MUST be forwarded.</t>
<t>Resulting state: INIT_BIND - A potential binding has been set
up</t>
</section>
</section>
<section anchor="state-bound"
title="Initial State: BOUND - The binding has been set up">
<section title="Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry expires">
<t>The entry MUST be deleted from BST.</t>
<t>Resulting state: An entry that has been deleted from the BST
may be considered to be in the state "NO_BIND" - No binding has
been set up.</t>
</section>
<section title="Event: EVE_DHCP_DECLINE - A DHCPv4 Decline or a DHCPv6 Decline message is received">
<t>The message MUST be forwarded.</t>
<t>The SAVI device first gets all the addresses ("Requested IP
address" in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses
in all the IA options of DHCPv6 Decline/Release) to
decline/release in the message. Then the corresponding entries
MUST be removed.</t>
<t>Resulting state in each relevant BST entry: An entry that has
been deleted from the BST may be considered to be in the state
"NO_BIND" - No binding has been set up.</t>
</section>
<section title="Event: EVE_DHCP_RELEASE - A DHCPv4 Release or a DHCPv6 Release message is received">
<t>The message MUST be forwarded.</t>
<t>The SAVI device first gets all the addresses ("Requested IP
address" in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses
in all the IA options of DHCPv6 Decline/Release) to
decline/release in the message. Then the corresponding entries
MUST be removed.</t>
<t>Resulting state in each relevant BST entry: An entry that has
been deleted from the BST may be considered to be in the state
"NO_BIND" - No binding has been set up.</t>
</section>
<section title="Event: EVE_DHCP_REBIND - A DHCPv4 Rebind or a DHCPv6 Rebind message is received">
<t>The message MUST be forwarded.</t>
<t>In such 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 TID check will not be performed on such messages.</t>
<t>Resulting state: BOUND: The binding has been set up</t>
</section>
<section title="Event: EVE_DHCP_RENEW - A DHCPv4 Renew or a DHCPv6 Renew message is received">
<t>The message MUST be forwarded.</t>
<t>In such 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 TID check will not be performed on such messages.</t>
<t>Resulting state: BOUND: The binding has been set up</t>
</section>
<section title="Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message is received">
<t>The message MUST be forwarded.</t>
<t>The DHCP Reply messages received in current states should be in
response to DHCP Renew/Rebind.</t>
<t>If the message is DHCPv4 ACK, the SAVI device updates the
binding entry with 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 state BOUND.</t>
<t>If the message is DHCPv6 Reply, the SAVI device checks each IA
Address option in each IA option. For each:<list style="numbers">
<t>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.</t>
<t>If the valid lifetime of an IA address option is 0, the
binding entry with matched TID and address is removed, leaving
it effectively in the state NO_BIND.</t>
<t>Otherwise, set the Lifetime field of the binding entry with
matched TID and address to be the sum of the new valid
lifetime and MAX_DHCP_RESPONSE_TIME, leaving the entry in the
state BOUND.</t>
</list></t>
<t>Resulting state: NO_BIND or BOUND, as specified.</t>
</section>
<section title="Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6 LEASEQUERY_REPLY is received">
<t>The message MUST be forwarded.</t>
<t>The message should be in response to the Lease query message
sent in <xref target="init"/>. The related binding entry can be
determined based on the address in the IA Address option in the
Lease query-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.</t>
<t>Resulting state: BOUND: The binding has been set up</t>
</section>
<section title="Events not processed in the state BOUND">
<t>The following events are ignored if received while the
indicated entry is in the state BOUND. Any required action will be
the result of the next message in the client/server exchange.
<list style="symbols">
<t>EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request
message is received</t>
<t>EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received</t>
<t>EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received</t>
<t>EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with
Rapid Commit option is received</t>
</list></t>
</section>
</section>
<section anchor="table_statemachine" title="Table of State Machine">
<t>The main state transits are listed as follows. Note that not all
the details are specified in the table and the diagram.</t>
<figure anchor="transit_table" title="State Transition Table">
<artwork align="center"><![CDATA[
State Event Action Next State
NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND
INIT_BIND RPL Record lease time BOUND
(send lease query 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
]]></artwork>
</figure>
<t>RQ: EVE_DHCP_REQUEST</t>
<t>CF: EVE_DHCP_CONFIRM</t>
<t>RC: EVE_DHCP_SOLICIT_RC</t>
<t>RE: EVE_DHCP_REBOOT</t>
<t>RPL: EVE_DHCP_REPLY</t>
<t>DCL: EVE_DHCP_DECLINE</t>
<t>RLS: EVE_DHCP_RELEASE</t>
<t>LQR: EVE_DHCP_LEASEQUERY</t>
<figure anchor="transit_diagram" title="Diagram of Transit">
<artwork align="center"><![CDATA[
+-------------+
| |
/--------+ 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
]]></artwork>
</figure>
</section>
</section>
</section>
<section anchor="bindrecovery" title="Data Snooping Process">
<section anchor="datatrigger_scenario" title="Scenario">
<t>The rationale of the DHCP Snooping Process specified in <xref
target="regular"/> 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:</t>
<t><list hangIndent="4" style="symbols">
<t>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 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.</t>
<t>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
address confirm/re-configuration 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.</t>
</list></t>
<t>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.</t>
<t>Snooping data traffic introduces 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.</t>
<t>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.</t>
</section>
<section anchor="bindrecovery_rationale" title="Rationale">
<t>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.</t>
<t>The Data Snooping Process provides an alternative path for binding
entries to reach the BOUND state in the exceptional cases explained in
<xref target="datatrigger_scenario"/> when there are no DHCP messages
that can be snooped by the SAVI device.</t>
<t>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.</t>
<t>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 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.</t>
<t>The security issues concerning this process are discussed is <xref
target="security_recovery"/>.</t>
</section>
<section anchor="bindrecovery_state"
title="Additional Binding States Description">
<t>In addition to NO_BIND and BOUND from <xref
target="regularstate"/>, 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.</t>
<t>DETECTION: The address in the entry is undergoing local duplication
detection.</t>
<t>RECOVERY: The SAVI device is querying the assignment and lease time
of the address in the entry through DHCP lease query.</t>
<t>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 lease query.</t>
<t>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.</t>
</section>
<section anchor="bindrecovery_event" title="Events">
<t>To handle the Data Snooping Process, five extra events, described
here, are needed in addition to those used by the DHCP Snooping
Process (see <xref target="regularevent"/>). If an event will trigger
the creation of a new binding entry, the binding entry limit on the
binding anchor MUST NOT be exceeded.</t>
<t>EVE_DATA_UNMATCH: A data packet without a matched binding is
received.</t>
<t>EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
against an address in DETECTION state is received from a host other
than the one for which the entry was added (i.e., a host attached at
another point than the one on which the triggering data packet was
received).</t>
<t>EVE_DATA_LEASEQUERY: <list style="symbols">
<t>IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time
option is received. Note that the DHCPLEASEUNKNOWN and
DHCPLEASEUNASSIGNED replies are ignored.</t>
<t>IPv6: A successful LEASEQUERY-REPLY is received.</t>
</list></t>
<t>EVE_DATA_VERIFY: An ARP Reply/Neighbor Advertisement(NA) message
has been received in the VERIFY state from the device connected to the
attachment point on which the data packet was received.</t>
<t>The triggering packet should pass the following checks to trigger a
valid event:</t>
<t><list hangIndent="4" style="symbols">
<t>Attribute check: the data packet should be from attachments
with Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY-REPLY
messages should be from attachments with DHCP-Snooping
attribute.</t>
<t>Binding limitation check: the data messages must not cause new
binding setup on an attachment whose binding entry limitation has
been reached. (refer to <xref target="security_limitation"/>).</t>
<t>Address check: For EVE_DATA_LEASEQUERY, the source address of
the DHCP Lease query messages must pass the check specified in
<xref target="controlfilter"/>. 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 <xref
target="controlfilter"/>.</t>
<t>Interval check: the interval between two successive
EVE_DATA_UNMATCH events triggered by an attachment MUST be no
smaller than DATA_SNOOPING_INTERVAL.</t>
<t>TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must
have matched TID with the corresponding entry.</t>
<t>Prefix check: the source address of the data packet should be
of a valid local prefix, as specified in section 7 of <xref
target="RFC7039"/>.</t>
</list></t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="send_functions" title="Message Sender Functions">
<t>The Data Snooping Process involves sending three different messages
to other network devices. Each message may be sent up to twice 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.</t>
<section anchor="dup_send" title="Duplicate Detection Message Sender">
<t>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): <list
hangIndent="6" style="hanging">
<t hangText="IPv4 address:">broadcast an Address Resolution
Protocol (ARP) Request <xref target="RFC0826"/> or an ARP probe
<xref target="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.</t>
<t hangText="IPv6 address:">send a Duplicate Address Detection
(DAD) message (Neighbor Solicitation message) to the solicited
node multicast address <xref target="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.</t>
</list></t>
<t>As both the ARP and DAD processes are unreliable (either the
packet to or from the other system may be lost in transit, see <xref
target="RFC6620"/>), if there is no response after the
DETECTION_TIMEOUT an EVE_ENTRY_EXPIRE is generated.</t>
</section>
<section anchor="query_send" title="Lease Query Message Sender">
<t>Send a DHCP lease query 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 pre-configured 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. See <xref
target="leasequery_security"/> regarding the securing of the process
and the advisability of using the DHCPv6
All_DHCP_Relay_Agents_and_Servers or All_DHCP_Servers multicast
addresses. The same TID should be used for all lease query 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.
<list hangIndent="4" style="format (%d)">
<t>IPv4 address: Send a DHCPLEASEQUERY <xref target="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.</t>
<t>IPv6 address: Send a LEASEQUERY <xref target="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 contain any IPv6 addresses bound to
the same link together with the lease validity time.</t>
</list></t>
<t>As DHCP lease queries are an unreliable process (either the
packet 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.</t>
</section>
<section anchor="verify_send"
title="Address Verification Message Sender">
<t>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 lease query response: <list
hangIndent="6" style="hanging">
<t hangText="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 lease query
value.</t>
<t hangText="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, a Neighbor Announcement
(NA) should be received indicating that the attached device has
the IP address configured on the interface.</t>
</list></t>
<t>As both the ARP and NS/NA processes are unreliable (either the
packet to or from the other system may be lost in transit, see <xref
target="RFC6620"/>), if there is no response after the
DETECTION_TIMEOUT an EVE_DATA_EXPIRE is generated.</t>
</section>
</section>
<section title="Initial State: state NO_BIND - No binding has been set up">
<section anchor="nobind-unmatch"
title="Event: EVE_DATA_UNMATCH: A data packet without a matched binding is received">
<t>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 attack against this process.</t>
<t>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.</t>
<t>Address conflicts MUST be detected and prevented.<list
hangIndent="6" style="hanging">
<t hangText="If local address detection is performed:"><vspace
blankLines="0"/>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
(<xref target="dup_send"/>)). Transition to state DETECTION.</t>
<t
hangText="If local address detection is not performed:"><vspace
blankLines="0"/>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
lease query messages (<xref target="query_send"/>)). Transition
to state RECOVERY.</t>
</list></t>
<t>The packet that triggers this event SHOULD be discarded.</t>
<t>An example of the BST entry during duplicate address detection is
illustrated in <xref target="bst_data_init"/>.</t>
<figure anchor="bst_data_init"
title="Binding entry in BST on data triggered initialization">
<artwork align="center"><![CDATA[
+--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr1 |DETECTION| DETECTION_TIMEOUT | | 0 |
+--------+-------+---------+-----------------------+-----+----------+
]]></artwork>
</figure>
<t>Resulting state: DETECTION - The address in the entry is
undergoing local duplication detection - or RECOVERY - DHCP lease(s)
associated with the address are being queried.</t>
</section>
<section title="Events not observed in NO_BIND for data snooping">
<t>EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
received from unexpected system</t>
<t>EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY
is received</t>
<t>EVE_DATA_VERIFY: A valid ARP Reply or NA message received from
the attached device</t>
<t>All EVE_DHCP_* events defined in <xref target="controlevent"/>
are treated as described in the DHCP Snooping Process (<xref
target="nb_dhcp_state"/>) and may result in that process being
triggered.</t>
<t>EVE_ENTRY_EXPIRE:</t>
<t>EVE_DATA_EXPIRE:</t>
</section>
</section>
<section title="Initial State: state DETECTION - The address in the entry is undergoing local duplication detection">
<section title="Event: EVE_ENTRY_EXPIRE">
<t>When this event occurs, no address conflict has been detected
during the previous DETECTION_TIMEOUT period. <list hangIndent="6"
style="hanging">
<t
hangText="If the Timeouts field in the BST entry is 0:"><vspace/>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 (<xref target="dup_send"/>)). Remain in state
DETECTION.</t>
<t
hangText="If the Timeouts field in the BST entry is 1:"><vspace/>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 lease query messages (<xref target="query_send"/>)).
Transition to state RECOVERY.</t>
</list></t>
<t>An example of the entry is illustrated in <xref
target="bst_data_detec"/>.</t>
<figure anchor="bst_data_detec"
title="Binding entry in BST on Lease Query">
<artwork align="center"><![CDATA[
+--------+-------+----------+----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+----------+----------------------+-----+----------+
| Port_1 | Addr1 | RECOVERY | MAX_LEASEQUERY_DELAY | TID | 0 |
+--------+-------+----------+----------------------+-----+----------+
]]></artwork>
</figure>
<t>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</t>
</section>
<section title="Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message received from unexpected system">
<t>Remove the entry.</t>
<t>Resulting state: NO_BIND - No binding has been set up</t>
</section>
<section title="Events not observed in DETECTION">
<t>EVE_DATA_UNMATCH: A data packet without matched binding is
received</t>
<t>All EVE_DHCP_* events defined in <xref
target="controlevent"/></t>
<t>EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is
received</t>
</section>
</section>
<section title="Initial State: state RECOVERY - The SAVI device is querying the assignment and lease time of the address in the entry through DHCP Leasequery">
<section anchor="edl_event"
title="Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or successful LEASEQUERY-REPLY is received">
<t>Set the State in the BST entry to VERIFY. Depending on the type
of triggering source IP address, process the received DHCP lease
query response: <list hangIndent="6" style="hanging">
<t hangText="IPv4 address:">Update the Lifetime field in the BST
entry to the sum of the value encoded in 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 <xref
target="verify_send"/>). Transition to state VERIFY. Start an
additional verification timer with a duration of
DETECTION_TIMEOUT. When this expires an EVE_DATA_EXPIRE event
will be generated.</t>
<t hangText="IPv6 address:">Update the Lifetime field in the BST
entry to the sum of the valid lifetime extracted from
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 <xref target="verify_send"/>). Transition to state VERIFY.
Start an additional verification timer with a duration of
DETECTION_TIMEOUT. When this expires an EVE_DATA_EXPIRE event
will be generated.<vspace blankLines="1"/> 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.</t>
</list></t>
<t>Resulting state: VERIFY - awaiting verification or otherwise of
the association of the IP address with the connected interface.</t>
</section>
<section title="Event: EVE_ENTRY_EXPIRE">
<t>Depending on the value of the Timeouts field in the BST entry,
either send repeat lease query messages or discard the binding:
<list hangIndent="6" style="hanging">
<t
hangText="If the Timeouts field in the BST entry is 0:"><vspace/>No
responses to the lease query 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 lease query messages
(<xref target="query_send"/>)). Remain in state RECOVERY.</t>
<t
hangText="If the Timeouts field in the BST entry is 1:"><vspace/>No
responses to the lease query 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 state NO_BIND.</t>
</list></t>
<t>Resulting state: RECOVERY - if repeat lease queries are sent - or
NO_BIND - if no successful responses to lease query messages have
been received.</t>
</section>
<section title="Events not observed in RECOVERY">
<t>EVE_DATA_UNMATCH: A data packet without matched binding is
received</t>
<t>EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
received from unexpected system</t>
<t>EVE_DATA_VERIFY: A valid ARP Reply or NA message received from
the attached device</t>
<t>All EVE_DHCP_* events defined in <xref
target="controlevent"/></t>
<t>EVE_DATA_EXPIRE:</t>
</section>
</section>
<section title="Initial State: state VERIFY - Verification of the use of the source IP address by the device interface attached to the SAVI device">
<section title="Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or successful LEASEQUERY-REPLY is received">
<t>If lease query messages were sent to more than one DHCP server
during RECOVERY state, additional successful lease query responses
may be received relating to the source IP address. The conflict
resolution mechanisms specified in Section 6.8 of <xref
target="RFC4388"/> and Section 4.3.4 of <xref target="RFC5007"/> can
be used to determine the message from which values are used to
update the BST Lifetime entry and the hardware address obtained from
DHCP, as described in <xref target="edl_event"/>. In the case of
DHCPv6 queries, the LEASEQUERY-REPLY may contain additional
addresses as described in <xref target="edl_event"/>. If so
additional BST entries MUST be created or ones previously created
updated as described in that section.</t>
<t>Resulting state: VERIFY (no change).</t>
</section>
<section title="Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is received from the device attached via the binding anchor">
<t>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: <list
hangIndent="6" style="hanging">
<t hangText="IPv4 address:">Check that the value of 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.</t>
<t hangText="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.</t>
</list></t>
<t>If the binding entry has been verified, set the State in the BST
entry to BOUND. Clear the TID field. Cancel the verification
timer.</t>
<t>Resulting state: VERIFY (no change) - if IPv4 DHCPLEASEQUERY
"chaddr" address does not match ARP Reply hardware address - or
BOUND - otherwise.</t>
</section>
<section title="Event: EVE_ENTRY_EXPIRE">
<t>The DHCP lease lifetime has expired before the entry could be
verified. Remove the entry. Transition to NO_BIND state.</t>
<t>Resulting state: NO_BIND - No binding has been set up</t>
</section>
<section title="Event: EVE_DATA_EXPIRE">
<t>Depending on the value of the Timeouts field in the BST entry,
either send a repeat validation message or discard the binding:
<list hangIndent="6" style="hanging">
<t
hangText="If the Timeouts field in the BST entry is 0:"><vspace/>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 <xref target="verify_send"/>).
Start a verification timer with a duration of DETECTION_TIMEOUT.
When this expires an EVE_DATA_EXPIRE event will be generated.
Remain in state VERIFY.</t>
<t
hangText="If the Timeouts field in the BST entry is 1:"><vspace/>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 state NO_BIND.</t>
</list></t>
<t>Resulting state: VERIFY - additional verification message sent -
or NO_BIND - No binding has been set up</t>
</section>
<section title="Events not observed in VERIFY">
<t>EVE_DATA_UNMATCH: A data packet without matched binding is
received</t>
<t>EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
received from unexpected system</t>
<t>All EVE_DHCP_* events defined in <xref
target="controlevent"/></t>
</section>
</section>
<section title="Initial State: state BOUND - The binding has been set up">
<t>Upon entry to the state BOUND, control the system continues as if a
DHCP message assigning the address has been observed, as in <xref
target="state-bound"/>. The BST entry has been restored.</t>
<t>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 be not executed
normally.</t>
</section>
<?rfc needLines="25" ?>
<section anchor="table_statemachine_data" title="Table of State Machine">
<t>The main state transitions are listed as follows.</t>
<figure anchor="transit_table_data" title="State Transition Table">
<artwork align="center"><![CDATA[
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 lease query RECOVERY
DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND
RECOVERY EVE_ENTRY_EXPIRE 1 Repeat lease query 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
]]></artwork>
</figure>
<figure anchor="transit_diagram_Data" title="Diagram of Transit">
<artwork align="center"><![CDATA[
+-------------+ 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)
]]></artwork>
</figure>
<t>LQ_DELAY: MAX_LEASEQUERY_DELAY<vspace/> VRF_DELAY:
DETECTION_TIMEOUT</t>
</section>
</section>
<section anchor="filterrule" title="Filtering Specification">
<t>This section specifies how to use bindings to filter out packets with
spoofed source addresses.</t>
<t>Filtering policies are different for data packets and control
packets. DHCP, ARP, and NDP (Neighbor Discovery Protocol) <xref
target="RFC4861"/> messages are classified as control packets. All other
packets are classified as data packets.</t>
<section anchor="datafilter" title="Data Packet Filtering">
<t>Data packets from attachments with the Validating attribute TRUE
MUST have their source addresses validated. There is one exception to
this rule.</t>
<t>A packet whose source IP address is a link-local address cannot be
checked against DHCP assignments, as it is not assigned using DHCP.
Note: as explained in <xref target="introduction"/>, a SAVI solution
for link-local addresses, e.g., the SAVI-FCFS <xref
target="RFC6620"/>, can be enabled to check packets with a link-local
source address.</t>
<t>If the source IP address of a packet is not a link-local address,
but there is not a matching entry in BST with state BOUND, this packet
MUST be discarded. However, the packet may trigger the Data Snooping
Process <xref target="bindrecovery"/> if the Data-Snooping attribute
is set on the attachment.</t>
<t>Data packets from an attachment with the Validating attribute set
FALSE will be forwarded without having their source addresses
validated.</t>
<t>The SAVI device MAY log packets that fail source address
validation.</t>
</section>
<section anchor="controlfilter" title="Control Packet Filtering">
<t>For attachments with the Validating attribute:</t>
<t>DHCPv4 Client-Server messages in which the source IP address is
neither all zeros nor bound with the corresponding binding anchor in
the BST MUST be discarded.</t>
<t>DHCPv6 Client-Server messages in which the source IP address is
neither a link-local address nor bound with the corresponding binding
anchor in the BST MUST be discarded.</t>
<t>NDP messages in which the source IP address is neither a link-local
address nor bound with the corresponding binding anchor MUST be
discarded.</t>
<t>NA messages in which the target address is neither a link-local
address nor bound with the corresponding binding anchor MUST be
discarded.</t>
<t>ARP messages in which the protocol is IP and sender protocol
address is neither all zeros address nor bound with the corresponding
binding anchor MUST be discarded.</t>
<t>ARP Reply messages in which the target protocol address is not
bound with the corresponding binding anchor MUST be discarded.</t>
<t>For attachments with other attributes:</t>
<t>DHCP Server-to-Client messages not from attachments with the
DHCP-Trust attribute or Trust attribute MUST be discarded.</t>
<t>For attachments with no attribute:</t>
<t>DHCP Server-to-Client messages from such attachments MUST be
discarded.</t>
<t>The SAVI device MAY record any messages that are discarded.</t>
</section>
</section>
<section anchor="restoration" title="State Restoration">
<t>If a SAVI device reboots, the information kept in volatile memory
will be lost. This section specifies the restoration of attribute
configuration and BST.</t>
<section anchor="restoration_attribute"
title="Attribute Configuration Restoration">
<t>The loss of attribute configuration will not break the network: no
action will be performed on traffic from attachments with no
attribute. However, the loss of attribute configuration makes this
SAVI function unable to work.</t>
<t>To avoid the loss of binding anchor attribute configuration, the
configuration MUST be able to be stored in non-volatile storage. After
the reboot of SAVI device, if the configuration of binding anchor
attributes is found in non-volatile storage, the configuration MUST be
used.</t>
</section>
<section anchor="restoration_state" title="Binding State Restoration">
<t>The loss of binding state will cause the SAVI devices to discard
legitimate traffic. Simply using the Data Snooping Process to recover
a large number of bindings is a heavy overhead and may cause
considerable delay. Thus, to recover bindings from non-volatile
storage, as specified below, is RECOMMENDED.</t>
<t>Binding entries MAY be saved into non-volatile storage whenever a
new binding entry changes to BOUND state. If a binding with BOUND
state is removed, the saved entry MUST be removed correspondingly. The
time when each binding entry is established is also saved.</t>
<t>If the BST is stored in non-volatile storage, the SAVI device
SHOULD restore binding state from the non-volatile storage immediately
after reboot. Using the time when each binding entry was saved, the
SAVI device should check whether the entry has become obsolete by
comparing the saved lifetime and the difference between the current
time and time when the binding entry was established. Obsolete entries
which would have expired before the reboot MUST be removed.</t>
</section>
</section>
<section anchor="constants" title="Constants">
<t>The following constants are recommended for use in this context:
<list style="symbols">
<t>MAX_DHCP_RESPONSE_TIME 120s Maximum Solicit timeout value
(SOL_MAX_RT from <xref target="RFC3315"/>)</t>
<t>MAX_LEASEQUERY_DELAY 10s Maximum LEASEQUERY timeout value
(LQ_MAX_RT from <xref target="RFC5007"/>)</t>
<t>DETECTION_TIMEOUT 0.5s Maximum duration of a hardware address
verification step in the VERIFY state (TENT_LT from <xref
target="RFC6620"/>)</t>
<t>DATA_SNOOPING_INTERVAL Minimum interval between two successive
EVE_DATA_UNMATCH events triggered by an attachment. 60s and
configurable. (recommendation)</t>
<t>OFFLINK_DELAY 30s Period after a client is last detected before
the binding anchor being removed. (recommendation)</t>
</list></t>
</section>
<section anchor="security" title="Security Considerations">
<section anchor="security_recovery"
title="Security Problems about the Data Snooping Process">
<t>There are two security problems about the Data Snooping Process
<xref target="bindrecovery"/>:</t>
<t><list hangIndent="4" style="format (%d)">
<t>The Data Snooping Process is costly, but an attacker can
trigger it simply through sending a number of data packets. To
avoid Denial of Services attack against the SAVI device itself,
the Data Snooping Process MUST be rate limited. A constant
DATA_SNOOPING_INTERVAL is used to control the frequency. Two Data
Snooping Processes on one attachment MUST be separated by a
minimum interval time DATA_SNOOPING_INTERVAL. If this value is
changed, the value needs to be large enough to minimize denial of
service attacks.</t>
<t>The Data Snooping Process may set up incorrect bindings if the
clients do not reply to the detection probes <xref
target="nobind-unmatch"/>. An attack will pass the duplicate
detection if the client assigned the target address does not reply
to the detection probes. The DHCP Lease query procedure performed
by the SAVI device just tells whether the address is assigned in
the network or not. However, the SAVI device cannot determine
whether the address is just assigned to the triggering attachment
from the DHCP LEASEQUERY Reply.</t>
</list></t>
</section>
<section anchor="leasequery_security"
title="Securing Lease Query Operations">
<t>In <xref target="RFC4388"/> and <xref target="RFC5007"/> the
specific case of DHCP lease queries originated by "access
concentrators" is addressed extensively. SAVI devices are very similar
to access concentrators in that they snoop on DHCP traffic and seek to
validate source addresses based on the results. Accordingly the
recommendations for securing lease query operations for access
concentrators in Section 7 of <xref target="RFC4388"/> and Section 5
of <xref target="RFC5007"/> MUST be followed when lease queries are
made from SAVI devices. <xref target="RFC5007"/> RECOMMENDS that
communications between the querier and the DHCP server are protected
with IPsec. It is pointed out that there are relatively few devices
involved in a given administrative domain (SAVI devices, DHCP relays
and servers) so that manual configuration of keying material would not
be overly burdensome.</t>
</section>
<section anchor="security_offlink" title="Client departure issues">
<t>After a binding is set up, the corresponding client may leave its
attachment point. It may depart temporarily due to signal fade, or
permanently by moving to a new attachment point or leaving the
network. In the signal fade case, since the client may return shortly,
the binding should be kept momentarily, lest legitimate traffic from
the client be blocked. However, if the client leaves permanently,
keeping the binding can be a security issue. If the binding anchor is
a property of the attachment point rather than the client, e.g., the
switch port but not incorporating the MAC Address, an attacker using
the same binding anchor can send packets using IP addresses assigned
to the client. Even if the binding anchor is a property of the client,
retaining binding state for a departed client for a long time is a
waste of resources.</t>
<t>Whenever a direct client departs from the network, a link-down
event associated with the binding anchor will be triggered. SAVI-DHCP
monitors such events, and performs the following mechanism.</t>
<t><list hangIndent="4" style="format (%d)">
<t>Whenever a client with the Validating attribute leaves, a timer
of duration OFFLINK_DELAY is set on the corresponding binding
entries.</t>
<t>If a DAD Neighbor Solicitation/Gratuitous ARP request is
received that targets the address during OFFLINK_DELAY, the entry
MAY be removed.</t>
<t>If the client returns on-link during OFFLINK_DELAY, cancel the
timer.</t>
</list></t>
<t>In this way, the bindings of a departing client are kept for
OFFLINK_DELAY. In case of link flapping, the client will not be
blocked. If the client leaves permanently, the bindings will be
removed after OFFLINK_DELAY.</t>
<t>SAVI-DHCP does not handle the departure of indirect clients,
because it will not be notified of such events. Switches supporting
indirect attachment (e.g., through a separate non-SAVI switch) SHOULD
use information specific to the client such as its MAC address as part
of the binding anchor.</t>
</section>
<section anchor="security_dna"
title="Compatibility with DNA (Detecting Network Attachment)">
<t><xref target="RFC4436">DNA</xref><xref target="RFC6059"/> is
designed to decrease the handover latency after re-attachment to the
same network. DNA mainly relies on performing reachability test by
sending unicast Neighbor Solicitation/Router Solicitation/ARP Request
message to determine whether a previously configured address is still
valid.</t>
<t>Although DNA provides optimization for clients, there is
insufficient information for this mechanism to migrate the previous
binding or establish a new binding. If a binding is set up only by
snooping the reachability test message, the binding may be invalid.
For example, an attacker can perform reachability test with an address
bound to another client. If binding is migrated to the attacker, the
attacker can successfully obtain the binding from the victim. Because
this mechanism wouldn't set up a binding based on snooping the DNA
procedure, it cannot achieve perfect compatibility with DNA. However,
it only means the re-configuration of the interface is slowed but not
prevented. Details are discussed as follows.</t>
<t>In Simple <xref target="RFC6059">DNAv6</xref>, the probe is sent
with the source address set to a link-local address, and such messages
will not be discarded by the policy specified in <xref
target="controlfilter"/>. If a client is re-attached to a previous
network, the detection will be completed, and the address will be
regarded as valid by the client. However, the candidate address is not
contained in the probe. Thus, the binding cannot be recovered through
snooping the probe. As the client will perform DHCP exchange at the
same time, the binding will be recovered from the DHCP Snooping
Process. The DHCP Request messages will not be filtered out in this
case because they have link-local source addresses. Before the DHCP
procedure is completed, packets will be filtered out by the SAVI
device. In other words, if this SAVI function is enabled, Simple DNAv6
will not help reduce the handover latency. If Data-Snooping attribute
is configured on the new attachment of the client, the data triggered
procedure may reduce latency.</t>
<t>In <xref target="RFC4436">DNAv4</xref>, the ARP probe will be
discarded because an unbound address is used as the sender protocol
address. As a result, the client will regard the address under
detection is valid. However, the data traffic will be filtered. The
DHCP Request message sent by the client will not be discarded, because
the source IP address field should be all zero as required by <xref
target="RFC2131"/>. Thus, if the address is still valid, the binding
will be recovered from the DHCP Snooping Process.</t>
</section>
<section anchor="security_limitation" title="Binding Number Limitation">
<t>A binding entry will consume a certain high-speed memory resources.
In general, a SAVI device can afford only a quite limited number of
binding entries. In order to prevent an attacker from overloading the
resource of the SAVI device, a binding entry limit is set on each
attachment. The binding entry limit is the maximum number of bindings
supported on each attachment with Validating attribute. No new binding
should be set up after the limit has been reached. If a DHCP Reply
assigns more addresses than the remaining binding entry quota of each
client, the message will be discarded and no binding will be set
up.</t>
</section>
<section anchor="security_privacy" title="Privacy Considerations">
<t>A SAVI device MUST delete binding anchor information as soon as
possible (i.e., as soon as the state for a given address is back to
NO_BIND), except where there is an identified reason why that
information is likely to be involved in the detection, prevention, or
tracing of actual source address spoofing. Information about the
majority of hosts that never spoof SHOULD NOT be logged.</t>
</section>
<section title="Fragmented DHCP Messages">
<t>This specification does not preclude reassembly of fragmented DHCP
messages, but it also does not require it. If DHCP fragmentation
proves to be an issue, that will need to be specified.</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
</section>
<section anchor="acknowledgment" title="Acknowledgment">
<t>Special thanks to Jean-Michel Combes, Christian Vogt, Joel M.
Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn
Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto Garcia
for careful review and valuation comments on the mechanism and text.</t>
<t>Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David
Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi
Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for
their valuable contributions.</t>
<t>This document was generated using the xml2rfc tool.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0826" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2131" ?>
<?rfc include="reference.RFC.3315" ?>
<?rfc include="reference.RFC.4388" ?>
<?rfc include="reference.RFC.4436" ?>
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.5007" ?>
<?rfc include="reference.RFC.5227" ?>
<?rfc include="reference.RFC.6059" ?>
<?rfc include="reference.RFC.6620" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-opsec-dhcpv6-shield" ?>
<?rfc include="reference.RFC.2827" ?>
<?rfc include="reference.RFC.3736" ?>
<?rfc include="reference.RFC.7039" ?>
<?rfc include="reference.RFC.7341" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:46:52 |