< draft-ietf-savi-dhcp-29.txt		draft-ietf-savi-dhcp-30.txt >
	SAVI J. Bi		Source Address Validation Improvement J. Bi
	Internet-Draft J. Wu		Internet-Draft J. Wu
	Intended status: Standards Track G. Yao		Intended status: Standards Track G. Yao
	Expires: January 23, 2015 Tsinghua Univ.		Expires: June 6, 2015 Tsinghua Univ.
	F. Baker		F. Baker
	Cisco		Cisco
	July 22, 2014		December 3, 2014
	SAVI Solution for DHCP		SAVI Solution for DHCP
	draft-ietf-savi-dhcp-29		draft-ietf-savi-dhcp-30
	Abstract		Abstract
	This document specifies the procedure for creating a binding between		This document specifies the procedure for creating a binding between
	a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI		a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source
	(Source Address Validation Improvements) device. The bindings set up		Address Validation Improvements (SAVI) device. The bindings set up
	by this procedure is used to filter out packets with forged source IP		by this procedure are used to filter packets with forged source IP
	address in DHCP scenario. This mechanism is proposed as a complement		addresses. This mechanism complements BCP 38 ingress filtering,
	to ingress filtering to provide finer-grained source IP address		providing finer-grained source IP address validation.
	validation.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 23, 2015.		This Internet-Draft will expire on June 6, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other
	than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Deployment Scenario and Configuration . . . . . . . . . . . . 7		4. Deployment Scenario and Configuration . . . . . . . . . . . . 8
	4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 7		4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8
	4.2. Attribute . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. SAVI Binding Type Attributes . . . . . . . . . . . . . . 9
	4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10		4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 9
	4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 10		4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 10
	4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11		4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 10
	4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11		4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11
	4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 11		4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 11
	4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 12		4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 12
	4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13		4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 13		4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 12
	4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 13		4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 13
	4.3.3. On the Placement of DHCP Server/Relay . . . . . . . . 14		4.3.3. On the Placement of the DHCP Server and Relay . . . . 14
	4.3.4. An Alternative Deployment . . . . . . . . . . . . . . 15		4.3.4. An Alternative Deployment . . . . . . . . . . . . . . 14
	4.3.5. Considerations on Binding Anchor . . . . . . . . . . 16		4.3.5. Considerations regarding Binding Anchors . . . . . . 15
	4.4. Other Device Configuration . . . . . . . . . . . . . . . 17		4.4. Other Device Configuration . . . . . . . . . . . . . . . 16
	5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 17		5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 16
	6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 18		6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 17
	6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 18		6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 17
	6.2. Binding States Description . . . . . . . . . . . . . . . 19		6.2. Binding States Description . . . . . . . . . . . . . . . 18
	6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 19		6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 19		6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 18
	6.3.2. Control Message Arriving Events . . . . . . . . . . . 19		6.3.2. Control Message Arriving Events . . . . . . . . . . . 18
	6.4. The State Machine of DHCP Snooping Process . . . . . . . 21		6.4. The State Machine of DHCP Snooping Process . . . . . . . 20
	6.4.1. From NO_BIND to INIT_BIND . . . . . . . . . . . . . . 21		6.4.1. Initial State: NO_BIND - No binding has been set up . 20
	6.4.2. From INIT_BIND to Other States . . . . . . . . . . . 22		6.4.2. Initial State: INIT_BIND - A potential binding has
	6.4.3. From BOUND to Other States . . . . . . . . . . . . . 24		been set up . . . . . . . . . . . . . . . . . . . . . 22
	6.5. Table of State Machine . . . . . . . . . . . . . . . . . 26		6.4.3. Initial State: BOUND - The binding has been set up . 25
	7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 27		6.4.4. Table of State Machine . . . . . . . . . . . . . . . 27
	7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 27		7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 29
	7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 28		7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 29
	7.3. Additional Binding States Description . . . . . . . . . . 28		7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 30
	7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 29		7.3. Additional Binding States Description . . . . . . . . . . 30
	7.5. State Machine of Binding Recovery Process . . . . . . . . 30		7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 31
	7.5.1. From NO_BIND to DETECTION . . . . . . . . . . . . . . 30		7.5. Initial State: state NO_BIND - No binding has been set up 32
	7.5.2. From DETECTION to Other States . . . . . . . . . . . 31		7.5.1. Event: EVE_DATA_UNMATCH: A data packet without
	7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 32		matched binding is received . . . . . . . . . . . . . 32
	7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 33		7.5.2. Events not observed in NO_BIND . . . . . . . . . . . 33
	7.6. Table of State Machine . . . . . . . . . . . . . . . . . 34
	8. Filtering Specification . . . . . . . . . . . . . . . . . . . 35		7.6. Initial State: state DETECTION - The address in the entry
	8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 36		is under local duplication detection . . . . . . . . . . 33
	8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 36		7.6.1. Event: EVE_ENTRY_EXPIRE (e.g., Timeout) . . . . . . . 33
	9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 37		7.6.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor
	9.1. Attribute Configuration Restoration . . . . . . . . . . . 37		Advertisement(NA) message received from unexpected
	9.2. Binding State Restoration . . . . . . . . . . . . . . . . 37		system . . . . . . . . . . . . . . . . . . . . . . . 34
	10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 38		7.6.3. Events not observed in DETECTION . . . . . . . . . . 34
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 38		7.7. Initial State: state RECOVERY - The SAVI device is
	11.1. Security Problems about the Data Snooping Process . . . 38		querying the assignment and lease time of the address in
	11.2. Issues about Leaving Clients . . . . . . . . . . . . . . 38		the entry through DHCP Leasequery . . . . . . . . . . . . 34
	11.3. Duplicate Bindings to the Same Address . . . . . . . . . 39		7.7.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
	11.4. Compatibility with DNA (Detecting Network Attachment) . 40		or LEASEQUERY-REPLY is received . . . . . . . . . . . 34
	11.5. Binding Number Limitation . . . . . . . . . . . . . . . 41		7.7.2. Event: EVE_ENTRY_EXPIRE (e.g., Timeout) . . . . . . . 36
	11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 41		7.7.3. Events not observed in RECOVERY . . . . . . . . . . . 36
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41		7.8. Initial State: state BOUND - The binding has been set up 36
	13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 41		7.8.1. Event: EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 42		Renew message is received . . . . . . . . . . . . . . 36
	14.1. Normative References . . . . . . . . . . . . . . . . . . 42		7.8.2. Event: EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6
	14.2. Informative References . . . . . . . . . . . . . . . . . 43		Rebind message is received . . . . . . . . . . . . . 36
			7.8.3. Events not observed in BOUND . . . . . . . . . . . . 37
			7.9. Table of State Machine . . . . . . . . . . . . . . . . . 37
			8. Filtering Specification . . . . . . . . . . . . . . . . . . . 38
			8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 38
			8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 39
			9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 40
			9.1. Attribute Configuration Restoration . . . . . . . . . . . 40
			9.2. Binding State Restoration . . . . . . . . . . . . . . . . 40
			10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 41
			11. Security Considerations . . . . . . . . . . . . . . . . . . . 41
			11.1. Security Problems about the Data Snooping Process . . . 41
			11.2. Client departure issues . . . . . . . . . . . . . . . . 41
			11.3. Duplicate Bindings to the Same Address . . . . . . . . . 42
			11.4. Compatibility with DNA (Detecting Network Attachment) . 43
			11.5. Binding Number Limitation . . . . . . . . . . . . . . . 44
			11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 44
			12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
			13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 44
			14. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
			14.1. Normative References . . . . . . . . . . . . . . . . . . 45
			14.2. Informative References . . . . . . . . . . . . . . . . . 46
	1. Introduction		1. Introduction
	This document describes a fine-grained source IP address validation		This document describes a fine-grained source IPv4 or IPv6 source
	mechanism. This mechanism creates bindings between IP addresses		address validation mechanism. This mechanism creates bindings
	assigned to network attachment points by DHCP and suitable binding		between IP addresses assigned to network interfaces by DHCP and
	anchors (refer to Section 3) of the attachments. Then the bindings		suitable binding anchors (Section 4.3.5). As discussed in Section 3
	are used to identify and filter out packets originated from these		and [RFC7039], a "binding anchor" is an attribute that is immutable
	attachments with forged source IP addresses. In this way, this		or difficult to change that may be used to identify the system an IP
	mechanism can prevent hosts from spoofing IP addresses assigned to		address has been assigned to; common examples include a MAC address
	the other attachment points. Compared with [RFC2827], which provides		found on an Ethernet switch port or WiFi security association. The
	prefix granularity source IP address validity, this mechanism can		bindings are used to identify and filter packets originated by these
	benefit the network with finer-grained validity and traceability of		interfaces using forged source IP addresses. In this way, this
	source IP addresses.		mechanism can prevent hosts from using IP addresses assigned to the
			other attachment points or invalid in 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. If [RFC2827] 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.
	This mechanism primarily performs DHCP snooping to set up bindings		SAVI-DHCP snoops DHCP address assignments to set up bindings between
	between IP addresses assigned by DHCP and corresponding binding		IP addresses assigned by DHCP and corresponding binding anchors. It
	anchors. This binding process is inspired by the work of [BA2007].		includes the DHCPv4 and v6 snooping process (Section 6), the Data
	Different from [BA2007], which designs specifications about DHCPv4,		Snooping process (Section 7), as well as a number of other technical
	this mechanism covers the DHCPv6 snooping process, the Data Snooping		details. The Data Snooping process is a data-triggered procedure
	process (refer to Section 7), as well as a number of other technical		that snoops the header of data packet to set up bindings. It is
	details. Specially, the Data Snooping process is a data-triggered		designed to avoid a permanent block of valid addresses in the case
	procedure which snoops the header of data packet to set up bindings.		that DHCP snooping is insufficient to set up all the valid bindings.
	It is designed to avoid permanent block of valid address in case that
	DHCP snooping is insufficient to set up all the valid bindings.
	This mechanism is designed for the stateful DHCP scenario [RFC2131],		This mechanism is designed for the stateful DHCP scenario [RFC2131],
	[RFC3315]. Stateless DHCP [RFC3736] is out of scope for this		[RFC3315]. Stateless DHCP [RFC3736] is out of scope for this
	document, because it has nothing to do with IP address allocation. A		document, because it has nothing to do with IP address allocation.
	client doing stateless DHCP acquires its IP address(es) using some		The appropriate SAVI method must be used in those cases. For hosts
	other mechanism. The appropriate SAVI method must be based on this		using Stateless Auto-Configuration to allocate addresses, SAVI-FCFS
	mechanism. For example, for hosts using Stateless Auto-configuration		[RFC6620] should be enabled. Besides, this mechanism is primarily
	address, SAVI-FCFS [RFC6620] should be enabled. Besides, this		designed for pure DHCP scenarios in which only addresses assigned
	mechanism is primarily designed for pure DHCP scenarios in which only		through DHCP are allowed. However, it does not block link-local
	addresses assigned through DHCP are allowed. However, it does not		addresses, as they are not assigned using DHCP. It is RECOMMENDED
	block any link-local address. It is because link-local addresses are		that the administration enable a SAVI solution for link-local
	used by DHCPv6 clients before the clients are assigned a DHCPv6		addresses, e.g., SAVI-FCFS [RFC6620].
	address. Considering that link-local addresses are generally self-
	generated, and the spoofing of link local address may disturb this
	mechanism, it is RECOMMENDED to enable a SAVI solution for link-local
	addresses, e.g., the SAVI-FCFS [RFC6620].
	This mechanism works for DHCPv4-only, DHCPv6-only, or both DHCPv4 and		This mechanism works for DHCPv4-only, DHCPv6-only, or both DHCPv4 and
	DHCPv6. However, the DHCP address assignment mechanims in IPv4/IPv6		DHCPv6. However, the DHCP address assignment mechanism in IPv4/IPv6
	transition scenarios, e.g., [I-D.ietf-dhc-dhcpv4-over-dhcpv6], are		transition scenarios, e.g., [RFC7341], are beyond the scope of this
	beyond the scope of this document.		document.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Terminology		3. Terminology
	Binding anchor: A "binding anchor" is defined to be a link layer		Binding anchor: A "binding anchor" is defined to be a physical and/or
	property of network attachment in [RFC7039]. A list of proper		link-layer property of an attached device, as in [RFC7039]. A list
	binding anchors can be found in Section 3.2 of [RFC7039].		of sample binding anchors can be found in Section 3.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 Section 4.3.5 for more detail.
	Attribute: A configurable property of each network attachment which		Attribute: A configurable property of each binding anchor (port, MAC
	indicates the actions to be performed on packets received from the		Address, or other information) that indicates the actions to be
	network attachment.		performed on packets received from the attached network device.
	DHCP address: An IP address assigned via DHCP.		DHCP address: An IP address assigned via DHCP.
	SAVI-DHCP: The name of this SAVI function for DHCP address.		SAVI-DHCP: The name of this SAVI function for DHCP-assigned
			addresses.
	SAVI device: A network device on which this SAVI function is enabled.		SAVI device: A network device on which SAVI-DHCP is enabled.
	Non-SAVI device: A network device on which this SAVI function is not		Non-SAVI device: A network device on which SAVI-DHCP is not enabled.
	enabled.
	DHCP Client-Server message: A message that is sent from a DHCP client		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		to a DHCP server or DHCP servers. Such a message is of one of the
	following types:		following types:
	o DHCPv4 Discover: DHCPDISCOVER [RFC2131]		o DHCPv4 Discover: DHCPDISCOVER [RFC2131]
	o DHCPv4 Request: DHCPREQUEST generated during SELECTING state		o DHCPv4 Request: DHCPREQUEST generated during SELECTING state
	[RFC2131]		[RFC2131]
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 22 ¶
	o DHCPv6 Solicit: SOLICIT [RFC3315]		o DHCPv6 Solicit: SOLICIT [RFC3315]
	o DHCPv6 Confirm: CONFIRM [RFC3315]		o DHCPv6 Confirm: CONFIRM [RFC3315]
	o DHCPv6 Decline: DECLINE [RFC3315]		o DHCPv6 Decline: DECLINE [RFC3315]
	o DHCPv6 Release: RELEASE [RFC3315]		o DHCPv6 Release: RELEASE [RFC3315]
	o DHCPv6 Rebind: REBIND [RFC3315]		o DHCPv6 Rebind: REBIND [RFC3315]
	o DHCPv6 Renew: RENEW [RFC3315]		o DHCPv6 Renew: RENEW [RFC3315]
	o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315]		o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315]
	DHCP Server-Client message: A message that is sent from a DHCP server		DHCP Server-to-Client message: A message that is sent from a DHCP
	to a DHCP client. Such a message is of one of the following types:		server to a DHCP client. Such a message is of one of the following
			types:
	o DHCPv4 ACK: DHCPACK [RFC2131]		o DHCPv4 ACK: DHCPACK [RFC2131]
	o DHCPv4 NAK: DHCPNAK [RFC2131]		o DHCPv4 NAK: DHCPNAK [RFC2131]
	o DHCPv4 Offer: DHCPOFFER [RFC2131]		o DHCPv4 Offer: DHCPOFFER [RFC2131]
	o DHCPv6 Reply: REPLY [RFC3315]		o DHCPv6 Reply: REPLY [RFC3315]
	o DHCPv6 Advertise: ADVERTISE [RFC3315]		o DHCPv6 Advertise: ADVERTISE [RFC3315]
	o DHCPv6 Reconfigure: RECONFIGURE [RFC3315]		o DHCPv6 Reconfigure: RECONFIGURE [RFC3315]
	Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in		Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in
	IPv6 [RFC3315].		IPv6 [RFC3315].
	Binding entry: An 'permit' rule that defines a valid association		Binding entry: A rule that associates an IP address with a binding
	between an IP address and a binding anchor.		anchor.
	Binding State Table (BST): The data structure that contains all the		Binding State Table (BST): The data structure that contains the
	binding entries.		binding entries.
	Binding entry limit: The maximum number of binding entries that may		Binding entry limit: The maximum number of binding entries that may
	be associated with any binding anchor. Limiting the number of		be associated with a binding anchor. Limiting the number of binding
	binding entries per binding anchor prevents a malicious or		entries per binding anchor prevents a malicious or malfunctioning
	malfunctioning node from overloading the binding table on a SAVI		node from overloading the binding table on a SAVI device.
	device.
	Direct attachment: Ideally, a SAVI device should be an access device		Direct attachment: Ideally, a SAVI device is an access device that
	which is directly attached by hosts. In such case, the hosts are		hosts are attached to directly. In such a case, the hosts are direct
	direct attachments of the SAVI device.		attachments (e.g., they attach directly) to the SAVI device.
	Indirect attachment: A SAVI device can be an aggregation device which		Indirect attachment: A SAVI device MAY be an aggregation device that
	is connected with a number of access devices, which are attached by		other access devices are attached to, and which hosts in turn attach
	hosts. In such case, the hosts are indirect attachments of the SAVI		to. In such a case, the hosts are indirect attachments (e.g., they
	device. Sometimes, it is expressed as "the hosts are indirectly		attach indirectly) to the SAVI device.
	attached to the SAVI device".
	Upstream link: Upstream links are links connected to non-SAVI devices		Upstream link: Upstream links are links that connect to hosts that
	from which the valid source address space of traffic contains the		the device may not see DHCP messages to, and are therefore outside
	prefixes of other networks.		the SAVI perimiter.
	Upstream device: An upstream device is a non-SAVI device associated		Upstream device: An upstream device is a device associated with an
	with an upstream link. For example, the gateway router of the		upstream link. One example might be the gateway router of a network.
	network.
	Downstream link: Downstream links are links connected to non-SAVI		Downstream link: Downstream inks are links that connect to hosts that
	devices from which the valid source address space of traffic only		the device will invariably see DHCP messages to, and are therefore
	contains the prefix(es) of the local network.		within the SAVI perimiter..
	Downstream device: A downstream device is a non-SAVI device		Downstream device: A downstream device is a device associated with a
	associated with an downstream link. For example, an access switch in		downstream link. One example might be a desktop switch in the
	the network.		network, or a host.
	CUT VERTEX: A cut vertex is 'any vertex whose removal increases the		Cut Vertex: A cut vertex is any vertex whose removal increases the
	number of connected components'. This is a concept in graph theory.		number of connected components. This is a concept in graph theory.
	This term is used in Section 6.1 to accurately specify the required		This term is used in Section 6.1 to accurately specify the required
	deployment location of SAVI devices when they only perform the DHCP		deployment location of SAVI devices when they only perform the DHCP
	snooping process.		snooping process.
	Identity Association (IA): "A collection of addresses assigned to a		Identity Association (IA): "A collection of addresses assigned to a
	client." [RFC3315]		client." [RFC3315]
	Detection message: a Neighbor Solicitation or ARP message intended to		Detection message: a Neighbor Solicitation or ARP message intended to
	detect a duplicate address by the Data Snooping Process.		detect a duplicate address by the Data Snooping Process.
	DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the		DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the
	binding is triggered by a DHCPv6 Confirm message but a DHCPv6		binding is triggered by a DHCPv6 Confirm message but a DHCPv6 lease
	leasequery exchange [RFC5007] cannot be performed by the SAVI device		query exchange [RFC5007] cannot be performed by the SAVI device to
	to fetch the lease.		fetch the lease.
	4. Deployment Scenario and Configuration		4. Deployment Scenario and Configuration
	4.1. Elements and Scenario		4.1. Elements and Scenario
	A list of essential elements in a SAVI-DHCP deployment scenario is		The essential elements in a SAVI-DHCP deployment scenario include a
	given as follows:		DHCP server, zero or more downstream DHCP clients, and one or more
			SAVI devices. It may also include DHCP relays, when the DHCP server
	(1) DHCP server		is not co-located with a set of clients, and zero or more downstream
			Non-SAVI devices.
	(2) DHCP client
	(3) SAVI device
	And there may be following optional elements in a SAVI-DHCP
	deployment scenario:
	(1) DHCP relay
	(2) Non-SAVI device
	Figure 1 shows a deployment scenario that contains these elements.
	Note that a physical device can be multiple elements, e.g, a switch
	can be both a SAVI device and a DHCP relay. In such cases, the links
	are logic links rather than physical links. The "Bogus DHCP Server"
	is only used to help illustrate the case in Section 4.3.3, but not a
	necessary element.
	+--------+ +------------+ +----------+		+--------+ +------------+ +----------+
	|DHCP |-----| Non-SAVI |----|Bogus DHCP|		|DHCP |-----| Non-SAVI |----|Bogus DHCP|
	|Server A| | Device 1 | |Server |		|Server A| | Device 1 | |Server |
	+--------+ +-----|------+ +----------+		+--------+ +-----|------+ +----------+
	......................|............................		|upstream link
	. | upstream link .		. . . . . . . . . . .|. . . . . . . . . . . . . .
	. Protection +---|------+ .		. | .
	. Perimeter | SAVI |--------------+ .		. Protection +---|------+ .
	. | Device C| | .		. Perimeter | SAVI |--------------+ .
	. +---|------+ | .		. | Device C| | .
	. | | .		. +---|------+ | .
	. +----------+ +---|------+ +------|---+ .		. | | .
	downstream . | SAVI | | Non SAVI| | SAVI | .		. +----------+ +---|------+ +------|---+ .
	link +----.-| Device A|----| Device 3|-------| Device B| .		downstream . | SAVI | | Non SAVI| | SAVI | .
	| . +----|--|--+ +----------+ +-|---|----+ .		link +----.-| Device A|----| Device 3|-------| Device B| .
	| . | +----------+ ............ | | .		| . +----|--|--+ +----------+ +-|---|----+ .
	| '.............. | . . | | .		| . | +----------+ . . . . . | | .
	| | . | . +--------+ | .		| '. . . . . . . | . . | | .
	+----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ .		| | . | . +--------+ | .
	| Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | .		+----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ .
	| Device 2 | |A | . |Relay | . |B | . |Server B| .		| Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | .
	+----------+ +------+ . +------+ . +------+ . +--------+ .		| Device 2 | |A | . |Relay | . |B | . |Server B| .
	............ ...............		+----------+ +------+ . +------+ . +------+ . +--------+ .
			. . . . . . . . . . . .
	Figure 1: SAVI-DHCP Scenario		Figure 1: SAVI-DHCP Scenario
	Networks are not isolated and traffic from other networks, i.e.,		Figure 1 shows a deployment scenario that contains these elements.
	transit traffic specified in [RFC6620], may get into the network with		Note that a physical device can instantiate multiple elements, e.g.,
	SAVI-DHCP deployed through the upstream links. Since SAVI solutions		a switch can be both a SAVI device and a DHCP relay, or in a cloud
	are limited to check traffic generated from local link, SAVI-DHCP is		computing environment, a physical host may contain a virtual switch
	not to set up bindings for addresses assigned in other networks.		plus some number of virtual hosts. In such cases, the links are
	Thus, SAVI-DHCP will not set up bindings for addresses appearing on		logical links rather than physical links.
	upstream links and will not check data traffic from upstream links.
	This is why to distinguish upstream/downstream links is essential for
	SAVI-DHCP. The traffic from upstream links should be checked by a
	prefix granularity source address validation mechanism to avoid
	spoofing of local addresses from other networks. How to generate and
	deploy such a mechanism is beyond the scope of this document.
	However, traffic from downstream links are generated from local
	network. For example, a hub, which is attached by some DHCP clients,
	is on the downstream link of a SAVI device. The traffic from
	downstream links should be checked by SAVI-DHCP if possible.
	However, because DHCP clients on the downstream links are indirectly
	attached, the security problem caused by shared binding anchor, as
	described in Section 4.3.5, can be introduced.
	4.2. Attribute		Networks are not usually isolated. As a result, traffic from other
			networks, including transit traffic as specified in [RFC6620] (e.g.,
			traffic from another SAVI switch or a router) may enter a SAVI-DHCP
			network through the upstream 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 upstream links should be checked by an
			upstream system or [RFC2827] mechanisms. The generation and
			deployment of such a mechanism is beyond the scope of this document.
	As illustrated in Figure 1, an attachment to a SAVI device can be		Traffic from downstream links is, however, locally generated, and
	from either a DHCP client, or a DHCP relay/server, or a SAVI device,		should be checked by SAVI-DHCP if possible. In the event that there
	or a non-SAVI device. Different actions are performed on traffic		is an intervening downstream non-SAVI device between the host and the
	originated from different elements. To distinguish different types		SAVI device, however, use of the physical attachment point alone as a
	of attachments, an attachment property named 'attribute' is		binding anchor is insufficiently secure, as the several devices on a
	configured on SAVI devices. This section specifies the attributes		port or other point of attachment can spoof each other. Hence,
	used by SAVI-DHCP.		additional information such as a MAC address SHOULD be used to
			disambiguate them.
	Before configuration, an attachment is with no attribute. An		4.2. SAVI Binding Type Attributes
	attachment MAY be configured to have one or more compatible
	attributes (refer to Section 4.2.6). The attributes of each
	attachment MUST be configured before the SAVI-DHCP function is
	enabled. The procedure performed by SAVI devices on traffic from
	each attachment is determined by the attribute(s) set on the
	attachment.
	Particularly, if an attachment has no attribute, data traffic from		As illustrated in Figure 1, an system attached to a SAVI device can
	this attachment will not be checked by SAVI-DHCP and will be		be a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI
	forwarded directly. This prevents SAVI-DHCP from causing a break in		device. Different actions are performed on traffic originated from
	the network when it is turned on without any binding anchors		different elements. To distinguish among their requirements, several
	configured. However, if a binding anchor has no attribute, this		properties are associated with their point of attachment on the SAVI
	means that the SAVI-DHCP-Trust attribute is not present. Because of		device.
	this, DHCP server-client messages associated to this binding anchor
	will be discarded. This prevents a host from connecting to an
	unconfigured binding anchor and acting as a DHCP server. It is
	SUGGESTED to configure SAVI-DHCP-Trust on necessary binding anchors
	before turning on the SAVI-DHCP function.
	Binding anchors associated with upstream links MAY have no attribute		When a binding association is uninstantiated, e.g. when no host is
	after configuration. For example, in Figure 1, the attachment from		attached to the SAVI device using a given port or other binding
	the Non-SAVI Device 1 to the SAVI Device C should be configured with		anchor, the binding port attributes take default values unless
	no attribute. It means 1) SAVI devices will neither set up bindings		overridden by configuration. By default, a SAVI switch does not
	for upstream hosts nor check traffic from upstream hosts; 2) SAVI		filter DHCP messages, nor does it attempt to validate source
	devices will drop DHCP server-client messages from upstream devices		addresses. This is because a SAVI switch that depends on DHCP cannot
	unless the DHCP-Trust attribute (refer to Section 4.2.2) is set on		tell, a priori, which ports have valid DHCP servers attached, or
	the corresponding attachment. The reason that DHCP messages from		which have routers or other equipment that would validly appear to
	upstream devices are not trusted is discussed in Section 4.3.3.		use an arbitrary set of source addresses.
	4.2.1. Trust Attribute		4.2.1. Trust Attribute
	The "Trust Attribute" indicates the packets from the corresponding		The "Trust Attribute" is a Boolean value. If TRUE, it indicates that
	attachment are completely trustable.		the packets from the corresponding attached device need not have
			their source addresses validated. Examples of a trusted binding
	SAVI devices will not set up bindings for attachments with Trust		anchor would be a port to another SAVI device, or to an IP router, as
	attribute; DHCP messages and data packets from such attachments with		shown in Figure 1. In both cases, traffic using many source IP
	this attribute will not be checked. If the DHCP Server-Client		addresses will be seen. By default, the Trust attribute is FALSE,
	messages from attachments with this attribute can trigger the state		indicating that any device found on that port will seek an address
	transitions specified in Section 6 and Section 7, these messages will		using DHCP and be limited to using such addresses.
	be handled by the corresponding processes in Section 6 and Section 7.
	This attribute is generally configured on the attachments from other		SAVI devices will not set up bindings for points of attachment with
	SAVI devices. For example, in Figure 1, the attachment from the SAVI		the Trust attribute set TRUE; DHCP messages and data packets from
	Device B to the SAVI Device C and the attachment from the SAVI Device		attached devices with this attribute will not be checked. If the
	C to the SAVI Device B should be configured with this attribute.		DHCP Server-to-Client messages from attached devices with this
	Besides, it can be configured on attachments from Non-SAVI devices		attribute can trigger the state transitions specified in Section 6
	only if the Non-SAVI devices will not introduce unchecked traffic		and Section 7, the corresponding processes in Section 6 and Section 7
	from DHCP clients. For example, the attachments from Non-SAVI device		will handle these messages.
	3 to SAVI device A, SAVI device B and SAVI device C can be configured
	with this attribute, only if Non-SAVI device 3 does not have
	attachment from DHCP clients.
	4.2.2. DHCP-Trust Attribute		4.2.2. DHCP-Trust Attribute
	The "DHCP-Trust Attribute" indicates the DHCP Server-Client messages		The "DHCP-Trust Attribute" is similarly a Boolean attribute. It
	from the corresponding attachment is trustable.		indicates whether the attached device is permitted to initiate DHCP
			Server-to-Client messages. In Figure 1, the points of attachment of
	SAVI devices will forward DHCP Server-Client messages coming from the		the DHCP Server and the DHCP Relay would have this attribute set
	attachments with this attribute. If the DHCP Server-Client messages		TRUE, and ports that are trusted would have it set TRUE.
	can trigger the state transitions, they will be handled by the
	binding setup processes specified in Section 6 and Section 7.
	This attribute is generally used on the direct attachments from the		If the DHCP-Trust Attribute is TRUE, SAVI devices will forward DHCP
	trusted DHCP servers/relays. In Figure 1, the attachment from the		Server-to-Client messages from the points of attachment with this
	DHCP Relay to the SAVI Device A, and the attachment from the DHCP		attribute. If the DHCP Server-to-Client messages can trigger the
	Server B to the SAVI Device B should be configured with this		state transitions, the binding setup processes specified in Section 6
	attribute. It is NOT RECOMMENDED to configure this attribute on any		and Section 7 will handle them. By default, the DHCP-Trust attribute
	indirect attachment point of the non-neighboring DHCP servers and		is FALSE, indicating that the attached system is not a DHCP server.
	relays, unless all the elements that can be reached through that
	attachment point can be trusted, i.e., bogus DHCP Server-Client
	messages will not be generated by these elements. For example, in
	Figure 1, the attachment from the Non-SAVI Device 1 to the SAVI
	Device C should not be configured with this attribute. This issue is
	discussed in Section 4.3.3.
	The implementation for DHCPv6 can refer to		A DHCPv6 implementor can refer to [I-D.ietf-opsec-dhcpv6-shield] for
	[I-D.ietf-opsec-dhcpv6-shield] for more details.		more details.
	4.2.3. DHCP-Snooping Attribute		4.2.3. DHCP-Snooping Attribute
	The "DHCP-Snooping Attribute" indicates bindings will be set up based		The "DHCP-Snooping Attribute" is similarly a Boolean attribute. It
	on DHCP snooping.		indicates whether bindings will be set up based on DHCP snooping.
	DHCP Client-Server messages from attachments with this attribute will		If this attribute is TRUE, DHCP Client-Server messages to points of
	trigger the setup of bindings. SAVI devices will set up bindings on		attachment with this attribute will trigger creation of bindings
	attachments with this attribute based on the DHCP snooping procedure		based on the DHCP snooping procedure described in Section 6. If it
	described in Section 6.		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.
	DHCP-Snooping attribute is configured on the attachments from DHCP		The DHCP-Snooping attribute is configured on the DHCP Client's point
	clients. This attribute can be also used on the attachments from		of attachment. This attribute can be also used on the attachments to
	downstream Non-SAVI devices which are attached by DHCP clients. In		downstream Non-SAVI devices that are used by DHCP clients. In
	Figure 1, the attachment from the Client A to the SAVI Device A, the		Figure 1, 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		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		from the Non-SAVI Device 2 to the SAVI Device A can be configured
	with this attribute.		with this attribute.
	Whenever this attribute is set on an attachment, the "Validating		Whenever this attribute is set TRUE on a point of attachment, the
	Attribute" MUST be set on the same attachment.		"Validating Attribute" MUST also be set TRUE.
	4.2.4. Data-Snooping Attribute		4.2.4. Data-Snooping Attribute
	The "Data-Snooping Attribute" indicates data packets from the		The "Data-Snooping Attribute" is a Boolean attribute. It indicates
	corresponding attachment may trigger binding setup procedure.		whether data packets from the corresponding point of attachment may
			trigger the binding setup procedure.
	Data packets from attachments with this attribute may trigger the		Data packets from points of attachment with this attribute may
	setup of bindings. SAVI devices will set up bindings on attachments		trigger the setup of bindings. SAVI devices will set up bindings on
	with this attribute based on the data-triggered process described in		points of attachment with this attribute based on the data-triggered
	Section 7.		process described in Section 7.
	If DHCP-Snooping attribute is configured on an attachment, the		If the DHCP-Snooping attribute is configured on a point of
	bindings on this attachment are set up based on DHCP message		attachment, the bindings on this attachment are set up based on DHCP
	snooping. However, in some scenarios, a DHCP address may be used by		message snooping. However, in some scenarios, a DHCP client may use
	a DHCP client without DHCP address assignment procedure performed on		a DHCP address without the DHCP address assignment procedure being
	its current attachment. For such attachments, the Data-Snooping		performed on its current attachment. For such attached devices, the
	process, which is described in Section 7, is necessary. This		Data-Snooping process, which is described in Section 7, is necessary.
	attribute is configured on such attachments. The usage of this		This attribute is configured on such attachments. The usage of this
	attribute is further discussed in Section 7.		attribute is further discussed in Section 7.
	Whenever this attribute is set on an attachment, the "Validating		Whenever this attribute is set on an attachment, the "Validating
	Attribute" MUST be set on the same attachment.		Attribute" MUST be set on the same attachment. Since some networks
			require DHCP deployment and others avoid it, there is no obvious
			universal default value for the Data-Snooping Attribute. However,
			note that deployment of SLAAC (and therefore SAVI-FCFS) is generally
			configuration-free, while the deployment of DHCP involves at minimum
			the deployment of a server. 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.
	4.2.5. Validating Attribute		4.2.5. Validating Attribute
	The "Validating Attribute" indicates packets from the corresponding		The "Validating Attribute" is a Boolean attribute. It indicates
	attachment will be checked based on binding entries on the		whether packets from the corresponding attachment will have their IP
			source addresses validated based on binding entries on the
	attachment.		attachment.
	Packets coming from attachments with this attribute will be checked		If it is TRUE, packets coming from attachments with this attribute
	based on binding entries on the attachment as specified in Section 8.		will be checked based on binding entries on the attachment as
			specified in Section 8. If it is FALSE, they will not. Since the
	Validating attribute is configured on the attachments from which the		binding table is used in common with other SAVI algorithms, it merely
	data packets should be checked. For example, the DHCP clients.		signifies whether the check will be done, not whether it will be done
			for SAVI-DHCP originated bindings.
	This attribute MUST be used together with "DHCP-Snooping Attribute"		This attribute is by default the inverse of the Trust attribute;
	or "Data-Snooping Attribute".		source addresses on untrusted links are validated by default. It MAY
			be set FALSE by the administration.
	4.2.6. Table of Mutual Exclusions		4.2.6. Table of Mutual Exclusions
	Different types of attributes may indicate mutually exclusive actions		Different types of attributes may indicate mutually exclusive actions
	on packet. Mutually exclusive attributes MUST NOT be set on the same		on a packet. Mutually exclusive attributes MUST NOT be set TRUE on
	attachment. The compatibility of different attributes is listed in		the same attachment. The compatibility of different attributes is
	Figure 2. Note that although Trust and DHCP-Trust are compatible,		listed in Figure 2. Note that although Trust and DHCP-Trust are
	there is no need to configure DHCP-Trust on an attachment with Trust		compatible, there is no need to configure DHCP-Trust to TRUE on an
	attribute.		attachment with Trust attribute TRUE.
	+----------+----------+----------+----------+----------+----------+		+----------+----------+----------+----------+----------+----------+
	| | | | DHCP- | Data- | |		| | | | DHCP- | Data- | |
	| | Trust |DHCP-Trust| Snooping | Snooping |Validating|		| | Trust |DHCP-Trust| Snooping | Snooping |Validating|
	+----------+----------+----------+----------+----------+----------+		+----------+----------+----------+----------+----------+----------+
	| | | | mutually | mutually | mutually |		| | | | mutually | mutually | mutually |
	| Trust | - |compatible| exclusive| exclusive| exclusive|		| Trust | - |compatible| exclusive| exclusive| exclusive|
	+----------+----------+----------+----------+----------+----------+		+----------+----------+----------+----------+----------+----------+
	| | | | | | |		| | | | | | |
	|DHCP-Trust|compatible| - |compatible|compatible|compatible|		|DHCP-Trust|compatible| - |compatible|compatible|compatible|
	+----------+----------+----------+----------+----------+----------+		+----------+----------+----------+----------+----------+----------+
	|DHCP- |mutually | | | | |		|DHCP- |mutually | | | | |
	|Snooping |exclusive |compatible| - |compatible|compatible|		|Snooping |exclusive |compatible| - |compatible|compatible|
	+----------+----------+----------+----------+----------+----------+		+----------+----------+----------+----------+----------+----------+
	|Data- |mutually | | | | |		|Data- |mutually | | | | |
	|Snooping |exclusive |compatible|compatible| - |compatible|		|Snooping |exclusive |compatible|compatible| - |compatible|
	+----------+----------+----------+----------+----------+----------+		+----------+----------+----------+----------+----------+----------+
	| |mutually | | | | |		| |mutually | | | | |
	|Validating|exclusive |compatible|compatible|compatible| - |		|Validating|exclusive |compatible|compatible|compatible| - |
	+----------+----------+----------+----------+----------+----------+		+----------+----------+----------+----------+----------+----------+
	Figure 2: Table of Mutual Exclusions		Figure 2: Table of Mutual Exclusions
	4.3. Perimeter		4.3. Perimeter
	4.3.1. SAVI-DHCP Perimeter Overview		4.3.1. SAVI-DHCP Perimeter Overview
	SAVI devices can form a perimeter separating untrusted and trusted		SAVI devices form a perimeter separating trusted and untrusted
	areas, similarly to SAVI-FCFS (refer to Section 2.5 of [RFC6620]).		regions of a network, as SAVI-FCFS does ( Section 2.5 of [RFC6620]).
	Each SAVI device need only establish bindings for a client if it is		The perimeter is primarily designed for scalability. It has two
	connected to that client by a link that crosses the perimeter that		implications.
	encloses the SAVI device.
	The perimeter is primarily designed for scalability. This has two		o SAVI devices only need to establish bindings for directly attached
	implications. First, SAVI devices only need to establish bindings		clients, or clients indirectly attached through a non-SAVI
	for directly attached clients, or clients indirectly attached through		downstream device, rather than all of the clients in the network.
	non-SAVI device, rather than all the clients in the network. Second,
	each SAVI device only need to check traffic from clients attached to		o Each SAVI device only need to validate traffic from clients
	it, without checking all the traffic passing by.		attached to it, without checking all the traffic passing by.
	Consider the example in Figure 1. The protection perimeter is formed		Consider the example in Figure 1. The protection perimeter is formed
	by SAVI Device A, B and C. In this case, SAVI device B doesn't		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		create a binding for client A. However, because SAVI device A filters
	filters spoofing traffic from client A, SAVI device B can avoid		spoofed traffic from client A, SAVI device B can avoid receiving
	receiving spoofing traffic from client A.		spoofed traffic from client A.
	The perimeter in SAVI-DHCP is not only a perimeter for data packets,		The perimeter in SAVI-DHCP is not only a perimeter for data packets,
	but also a perimeter for DHCP messages. The placement of DHCP Relay/		but also a perimeter for DHCP messages. The placement of the DHCP
	Server, which is not involved in [RFC6620] , is related with the		Relay and DHCP Server, which are not involved in [RFC6620], is
	construction of the perimeter. The requirement on the placement and		related to the construction of the perimeter. The requirement on the
	configuration of DHCP Relay/Server are discussed in Section 4.3.3.		placement and configuration of DHCP Relay and DHCP Server are
			discussed in Section 4.3.3.
	4.3.2. SAVI-DHCP Perimeter Configuration Guideline		4.3.2. SAVI-DHCP Perimeter Configuration Guideline
	Through configuring attribute of each attachment properly, a		A perimeter separating trusted and untrusted regions of the network
	perimeter separating untrusted area and trusted area MUST be formed		is formed as follows:
	as follows:
	(1) Configure Validating and DHCP-Snooping attribute on the direct		(1) Configure the Validating and DHCP-Snooping attributes TRUE on
	attachments of all the DHCP clients.		the direct attachments of all DHCP clients.
	(2) Configure Validating and DHCP-Snooping attribute on the indirect		(2) Configure the Validating and DHCP-Snooping attributes TRUE on
	attachments of all the DHCP clients (i.e., DHCP clients on the		the indirect attachments of all DHCP clients (i.e., DHCP clients
	downstream links).		on downstream links).
	(3) Configure Trust attribute on the attachments of other SAVI		(3) Configure the Trust attribute TRUE on the attachments to other
	devices.		SAVI devices.
	(4) If a Non-SAVI device, or a number of connected Non-SAVI devices,		(4) If a Non-SAVI device, or a number of connected Non-SAVI devices,
	have only attachments from SAVI devices, set their attachments to		are attached only to SAVI devices, set the Trust attribute TRUE
	SAVI devices with Trust attribute.		on their attachments.
	(5) Configure DHCP-Trust attribute on the direct attachments of		(5) Configure the DHCP-Trust attribute TRUE on the direct
	trusted DHCP relays/servers.		attachments to trusted DHCP relays and servers.
	In this way, the points of attachments with Validating attribute (and		In this way, the points of attachments with the Validating attribute
	generally together with attachments of upstream devices) on SAVI		TRUE (and generally together with attachments of upstream devices) on
	devices can form a perimeter separating DHCP clients and trusted		SAVI devices can form a perimeter separating DHCP clients and trusted
	devices. Data packet check is only performed on the perimeter. The		devices. Data packet checks are only performed on the perimeter.
	perimeter is also a perimeter for DHCP messages. DHCP-Trust		The perimeter is also a perimeter for DHCP messages. The DHCP-Trust
	attribute is only configured on the inside links of the perimeter.		attribute is only TRUE on the inside links of the perimeter. Only
	Only DHCP server-client messages originated in the perimeter are		DHCP server-to-client messages originated within the perimeter are
	trusted.		trusted.
	4.3.3. On the Placement of DHCP Server/Relay		4.3.3. On the Placement of the DHCP Server and Relay
	Based on the configuration guideline, it can be found that the SAVI
	devices only trust DHCP Server-Client messages originated inside the
	perimeter. It means the trusted DHCP relays/servers must be placed
	in the perimeter. DHCP server-client messages will be filtered on
	the perimeter (Note: server-relay messages will not be filtered). In
	this way, DHCP server-client messages from bogus DHCP servers are
	filtered on the perimeter, and then the SAVI devices can be protected
	from forged DHCP messages.
	Such a requirement is due to the limitation of this binding based
	mechanism. This document makes no assumption that the DHCP server-
	client messages arriving the perimeter from the outside can be
	trusted. The binding anchor of a trusted remote DHCP server can be
	shared by a bogus DHCP server. Thus, the SAVI device cannot
	distinguish bogus and valid DHCP messages only based on the
	associated binding anchor of DHCP messages in such case.
	Note that even if a DHCP server is valid, it may be not contained in		As a result of the configuration guideline, SAVI devices only trust
	the perimeter based on the guideline. For example, in Figure 1, DHCP		DHCP Server-to-Client messages originated inside the perimeter.
	server A is valid, but it is attached to the Non-SAVI device 1. The		Thus, the trusted DHCP Relays and DHCP Servers must be placed within
	Non-SAVI device 1 is attached by a bogus DHCP server. This binding		the perimeter. DHCP server-to-client messages will be filtered on
	based mechanism may not have the ability to distinguish whether a		the perimeter. Server-to-relay messages will not be filtered, as
	message received from the port of the Non-SAVI device 1 is from DHCP		they are within the perimeter. In this way, DHCP server-to-client
	server A or the bogus DHCP server. If the DHCP server A is contained		messages from bogus DHCP servers are filtered on the perimeter,
	in the perimeter, the Non-SAVI device 1 will also be contained in the		having entered through untrusted points of attachment. The SAVI
	perimeter. However, the Non-SAVI device 1 can introduce forged DHCP		devices are protected from forged DHCP messages.
	messages into the perimeter. Thus, the DHCP server A cannot be
	contained in the perimeter.
	In this case, the SAVI devices can set up bindings for addresses		DHCP server-to-client messages arriving at the perimeter from outside
	assigned by DHCP server A through snooping the messages relayed by		the perimeter are not trusted. There is no distinction between a
	trusted relay in the network. For example, the DHCP relay may relay		DHCP server owned and operated by the correct administration but
	messages between DHCP server A and the clients in the network, and		outside the SAVI perimeter and a bogus DHCP server. For example, in
	the SAVI devices can snoop the last hop messages from the DHCP relay,		Figure 1, DHCP server A is valid, but it is attached to Non-SAVI
	which is inside the perimeter. The authentication mechanism (i.e.,		device 1. A bogus DHCP server is also attached Non-SAVI device 1.
	IPsec, as specified in section 21.1 of [RFC3315]) enforced between		While one could imagine a scenario in which the valid one had a
	the DHCP relay and the DHCP server outside the perimeter can		statistically configured port number and MAC address, and therefore a
	compensate this binding based mechanism. It is SUGGESTED to		binding, by default SAVI-DHCP cannot distinguish whether a message
	configure IPsec between the DHCP relay and the DHCP server in such		received from the port of Non-SAVI device 1 is from DHCP server A or
	case. If source address validation is enforced in the whole network,		the bogus DHCP server. If the DHCP server A is contained in the
	which makes the source IP address trustable, the DHCP relay and the		perimeter, Non-SAVI device 1 will also be contained in the perimeter.
	DHCP server can simply authenticate the messages from each other		Thus, the DHCP server A cannot be contained within the perimeter
	based on the source IP address. Nevertheless, it should be noted		apart from manual configuration of the binding anchor.
	that the integrity of the messages is not ensured.
	Another consideration on the placement is that if the DHCP server/		Another consideration on the placement is that if the DHCP server/
	relay is not inside the perimeter, the SAVI devices may not be able		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		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		the path between the clients and the server/relay, or the DHCP
	messages are encapsulated (e.g., Relay-reply and Relay-forward).		messages are encapsulated (e.g., Relay-reply and Relay-forward).
	4.3.4. An Alternative Deployment		4.3.4. An Alternative Deployment
	In a number of deployment practices, the traffic from the upstream		In common deployment practice, the traffic from the upstream network
	network are all treated as trustable. In such a case, Trust		is treated as trustworthy, which is to say that it is not filtered.
	attribute can be set on the upstream link; and if a Non-SAVI device,		In such a case, the Trust attribute can be set TRUE on the upstream
	or a number of connected Non-SAVI devices, have only attachments from		link. If Non-SAVI devices, or a number of connected Non-SAVI
	SAVI devices and upstream devices, their attachment to SAVI devices		devices, are only attached to SAVI devices and upstream devices,
	can be set Trust attribute. Then an unclosed perimeter will be		their attachment to SAVI devices can have the Trust attribute set
	formed, as illustrate in Figure 3.		TRUE. Then an unclosed perimeter will be formed, as illustrated in
			Figure 3.
	| . . Protection |		To configure such a perimeter, at minimum the DHCP messages from
	| | | Perimeter |		upstream networks MUST be ensured to be trustworthy. Achieving this
	| | | |		is beyond the scope of this document.
	| Upstream | | Upstream |
	| Link | | Link |
	| | | |
	| | | |
	| +--------+ +--------+ +--------+ |
	| |SAVI |----|Non-SAVI|----|SAVI | |
	| |Device | |Device | |Device | |
	| +--------+ +--------+ +--------+ |
	| | | |
	\________________________________________________/
	| |
	| |
	+--------+ +--------+
	|DHCP | |DHCP |
	|Client | |Client |
	+--------+ +--------+
	Figure 3: Alternative Perimeter Configuration		| . . Protection |
			| | | Perimeter |
			| | | |
			| Upstream | | Upstream |
			| Link | | Link |
			| | | |
			| | | |
			| +--------+ +--------+ +--------+ |
			| |SAVI |----|Non-SAVI|----|SAVI | |
			| |Device | |Device | |Device | |
			| +--------+ +--------+ +--------+ |
			| | | |
			\________________________________________________/
			| |
			| |
			+--------+ +--------+
			|DHCP | |DHCP |
			|Client | |Client |
			+--------+ +--------+
	To configure such a perimeter, at least the DHCP messages from		Figure 3: Alternative Perimeter Configuration
	upstream networks MUST be ensured to be trustable. How to achieve
	this is beyond the scope of this document.
	4.3.5. Considerations on Binding Anchor		4.3.5. Considerations regarding Binding Anchors
	The strength of this binding based mechanism depends on the strength		The strength of this binding-based mechanism depends on the strength
	of the binding anchor. If the binding anchor is spoofable, e.g.,		of the binding anchor. The sample binding anchors in [RFC7039] have
	plain MAC address, an attacker can use forged binding anchor to send		the property that they associate an IP address with a direct physical
	packet which will not be regarded as spoofing by SAVI device.		or secure virtual interface such as a switch port, a subscriber
	Indeed, using binding anchor that can be easily spoofed can lead to		association, or a security association. In addition, especially in
	worse outcomes than allowing IP spoofing traffic. For example, an		the case that a downstream non-SAVI device such as a desktop switch
	attacker can use the binding anchor of another client to bind a large		or a hub is between the client device and the SAVI switch, they MAY
	number of addresses, and the SAVI device will refuse to set up new		be extended to also include a MAC address or other link-layer
	binding for the client whenever the binding number limitation has		attribute. In short, a binding anchor is intended to associate an IP
	been reached; as a result, even the legitimate clients cannot access		address with something unspoofable that identifies a single client
	the network. Thus, it is RECOMMENDED to use unspoofable binding		system or one of its interfaces; this may be a physical or virtual
	anchor, e.g., switch port. By default,t his document assumes the		interface or that plus disambiguating link-layer information.
	binding anchor is switch port. The implications of using other forms
	of binding anchors should be properly analyzed.
	If the binding anchor is shared by more than one clients, the clients		If the binding anchor is spoofable, such as a plain MAC address, or
	can spoof each other addresses. For example, if a switch port is		non-exclusive, such as a switch port extended using a non-SAVI
	used as binding anchor, a number of clients can attach to the same		device, an attacker can use a forged binding anchor to evade
	switch port of a SAVI device through a hub. The SAVI device cannot		validation. Indeed, using a binding anchor that can be easily
	distinguish packets from different clients and thus the spoofing		spoofed can lead to worse outcomes than allowing IP spoofing traffic.
	between them will not be detected. A number of the above security		Thus, a SAVI device MUST use a non-spoofable and exclusive binding
	problems are caused by sharing binding anchors. For example, an		anchor.
	attacker can send a DHCP Release message to remove the binding of a
	client sharing the same binding anchor. Thus, it is RECOMMENDED to
	use exclusive binding anchor.
	4.4. Other Device Configuration		4.4. Other Device Configuration
	Other than the per binding anchor configuration specified in		In addition to a possible binding anchor configuration specified in
	Section 4.2, an implementation has the following configuration		Section 4.2, an implementation has the following configuration
	requirements:		requirements:
	(1) Address configuration. For DHCPv4: a SAVI device MUST have an		(1) Address configuration. For DHCPv4: the client of a SAVI device
	IPv4 address. For DHCPv6: a SAVI device MUST have a link-local		MUST have an IPv4 address. For DHCPv6: the client of a SAVI
	address; when the DHCPv6 server is not on the same link as the		device MUST have a link-local address; when the DHCPv6 server is
	SAVI device, the SAVI device needs also a global IPv6 address.		not on the same link as the SAVI device, the SAVI device MUST
			also have a global IPv6 address.
	(2) DHCP server address configuration: a SAVI device MUST store the		(2) DHCP server address configuration: a SAVI device MUST store the
	list of the DHCP server addresses that it could contact during a		list of the DHCP server addresses that it could contact during a
	Leasequery process.		Lease query process.
	5. Binding State Table (BST)		5. Binding State Table (BST)
	Binding State Table is used to contain the bindings between the IP		The Binding State Table, which may be implemented centrally in the
	addresses assigned to the attachments and the corresponding binding		switch or distributed among its ports, is used to contain the
	anchors of the attachments. Each entry of the table, i.e., binding		bindings between the IP addresses assigned to the attachments and the
	entry, has 5 fields:		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 downstream
			non-SAVI device. Each binding entry, has 5 fields:
	o Binding Anchor(Anchor): the binding anchor, i.e., a link-layer		o Binding Anchor(Anchor): the binding anchor, i.e., a physical and/
	property of the attachment.		or link-layer property of the attachment.
	o IP Address(Address): the IP address assigned to the attachment by		o IP Address(Address): the IPv4 or IPv6 address assigned to the
	DHCP.		attachment by DHCP.
	o State: the state of the binding. Possible values of this field		o State: the state of the binding. Possible values of this field
	are listed in Section 6.2 and Section 7.3.		are listed in Section 6.2 and Section 7.3.
	o Lifetime: the remaining seconds of the binding. The Lifetime		o Lifetime: the remaining seconds of the binding. Internally, this
	field counts down automatically.		MAY be stored as the timestamp value at which the lifetime
			expires.
	o TID: the Transaction ID (TID) (refer to [RFC2131] [RFC3315]) of		o TID: the Transaction ID (TID) ( [RFC2131] [RFC3315]) of the
	the corresponding DHCP transaction. TID field is used to		corresponding DHCP transaction. TID field is used to associate
	associate DHCP Server-Client messages with corresponding binding		DHCP Server-to-Client messages with corresponding binding entries.
	entries.
	IA does not present in the BST because the lease of each address in		The IA is not present in the BST for three reasons:
	one IA is assigned respectively. Another reason is, when the binding
	is set up based on data-snooping, IA cannot be recovered from the		o The lease of each address in one IA is assigned separately.
	leasequery protocol. Last reason is there is no IA for DHCPv4.
			o When the binding is set up based on data-snooping, the IA cannot
			be recovered from the lease query protocol.
			o DHCPv4 does not define an IA.
	An instance of this table is shown in Figure 4.		An instance of this table is shown in Figure 4.
	+---------+----------+----------+-----------+-------+		+---------+----------+----------+-----------+-------+
	| Anchor | Address | State | Lifetime |TID |		| Anchor | Address | State | Lifetime |TID |
	+---------+----------+----------+-----------+-------+		+---------+----------+----------+-----------+-------+
	| Port_1 | IP_1 | BOUND | 65535 |TID_1 |		| Port_1 | IP_1 | BOUND | 65535 |TID_1 |
	+---------+----------+----------+-----------+-------+		+---------+----------+----------+-----------+-------+
	| Port_1 | IP_2 | BOUND | 10000 |TID_2 |		| Port_1 | IP_2 | BOUND | 10000 |TID_2 |
	+---------+----------+----------+-----------+-------+		+---------+----------+----------+-----------+-------+
	| Port_2 | IP_3 |INIT_BIND | 1 |TID_3 |		| Port_2 | IP_3 |INIT_BIND | 1 |TID_3 |
	+---------+----------+----------+-----------+-------+		+---------+----------+----------+-----------+-------+
	Figure 4: Instance of BST		Figure 4: Instance of BST
	6. DHCP Snooping Process		6. DHCP Snooping Process
	This section specifies the process of setting up bindings based on		This section specifies the process of setting up bindings based on
	DHCP snooping, named DHCP Snooping Process. This process is		DHCP snooping. This process is illustrated using a state machine.
	illustrated making use of a state machine.
	6.1. Rationale		6.1. Rationale
	The rationale of the DHCP Snooping Process is that if a DHCP client		The rationale of the DHCP Snooping Process is that if a DHCP client
	is legitimate to use a DHCP address, the DHCP address assignment		is legitimately using a DHCP-assigned address, the DHCP address
	procedure which assigns the IP address to the client must have been		assignment procedure that assigns the IP address to the client must
	performed on the attachment of the client. This basis stands when		have been performed on the client's point of attachment. This basis
	the SAVI device is always on the path(s) from the DHCP client to the		works when the SAVI device is always on the path(s) from the DHCP
	DHCP server(s)/relay(s). Without considering the movement of DHCP		client to the DHCP server(s)/relay(s). Without considering the
	clients, the SAVI device should be the CUT VERTEX whose removal will		movement of DHCP clients, the SAVI device should be the cut vertex
	disjoin the DHCP client and the remaining network containing the DHCP		whose removal will separate the DHCP client and the remaining network
	server(s)/relay(s). For most of the networks whose topologies are		containing the DHCP server(s)/ and relay(s). For most of the
	simple, it is possible to deploy this SAVI function at proper devices		networks whose topologies are simple, it is possible to deploy this
	to meet this requirement.		SAVI function at proper devices to meet this requirement.
	However, a deployment of this SAVI function may not meet the		However, if there are multiple paths from a DHCP client to the DHCP
	requirement. For example, there are multiple paths from a DHCP		server and the SAVI device is only on one of them, there is an
	client to the DHCP server and the SAVI device is only on one of them.		obvious failure case: the SAVI device may not be able to snoop the
	Then the SAVI device may not be able to snoop the DHCP procedure.		DHCP procedure. Host movement may also make this requirement
	Host movement may also make this requirement can not be met. For		difficult to meet. For example, when a DHCP client moves from one
	example, when a DHCP client moves from one attachment to another		attachment to another attachment in the same network, it may fail to
	attachment in the same network, it may not reinitialize its interface		reinitialize its interface or send a Confirm message because of
	or send a Confirm message because of incomplete protocol		incomplete protocol implementation. Thus, there can be scenarios in
	implementation. Thus, there can be scenarios in which only		which only performing this DHCP snooping process is insufficient to
	performing this DHCP snooping process is insufficient to set up		set up bindings for all the valid DHCP addresses. These exceptions
	bindings for all the valid DHCP addresses. These exceptions and the		and the solutions are discussed in Section 7.
	solutions are discussed in Section 7.
	6.2. Binding States Description		6.2. Binding States Description
	Following binding states present in this process and the		Following binding states are present in this process and the
	corresponding state machine:		corresponding state machine:
	NO_BIND: The state before a binding has been set up.		NO_BIND: No binding has been set up.
	INIT_BIND: A potential binding has been set up.		INIT_BIND: A potential binding has been set up.
	BOUND: The binding has been set up.		BOUND: The binding has been set up.
	6.3. Events		6.3. Events
	This section describes events in this process and the corresponding		This section describes events in this process and the corresponding
	state machine.		state machine.
	skipping to change at page 20, line 21 ¶		skipping to change at page 19, line 18 ¶
	Note: the events listed here do not cover all the DHCP messages in		Note: the events listed here do not cover all the DHCP messages in
	section 3. The messages which do not really determine address usage		section 3. The messages which do not really determine address usage
	(DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit,		(DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit,
	DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6		DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6
	Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer		Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer
	to section 6.4.2.1), are not included.		to section 6.4.2.1), are not included.
	Moreover, only if a DHCP message can pass the following checks, the		Moreover, only if a DHCP message can pass the following checks, the
	corresponding event is regarded as a valid event:		corresponding event is regarded as a valid event:
	o Attribute check: the DHCP Server-Client messages and		o Attribute check: the DHCP Server-to-Client messages and
	LEASEQUERY_REPLY should be from attachments with DHCP-Trust		LEASEQUERY_REPLY should be from attachments with DHCP-Trust
	attribute; the DHCP Client-Server messages should be from		attribute; the DHCP Client-Server messages should be from
	attachments with DHCP-Snooping attribute.		attachments with DHCP-Snooping attribute.
	o Destination check: the DHCP Server-Client messages should be		o Destination check: the DHCP Server-to-Client messages should be
	destined to attachments with DHCP-Snooping attribute. This check		destined to attachments with DHCP-Snooping attribute. This check
	is performed to ensure the binding is set up on the SAVI device		is performed to ensure the binding is set up on the SAVI device
	which is nearest to the destination client.		which is nearest to the destination client.
	o Binding anchor check: the DHCP Client-Server messages which may		o Binding anchor check: the DHCP Client-Server messages which may
	trigger modification or removal of an existing binding entry must		trigger modification or removal of an existing binding entry must
	have matched binding anchor with the corresponding entry.		have a matching binding anchor with the corresponding entry.
	o TID check: the DHCP Server-Client/Client-Server messages which may		o TID check: the DHCP Server-to-Client/Client-Server messages which
	cause modification on existing binding entries must have matched		may cause modification on existing binding entries must have
	TID with the corresponding entry. Note that this check is not		matched TID with the corresponding entry. Note that this check is
	performed on Leasequery and Leasequery-reply messages as they are		not performed on Lease query and Lease query-reply messages as
	exchanged between the SAVI devices and the DHCP servers. Besides,		they are exchanged between the SAVI devices and the DHCP servers.
	this check is not performed on DHCP Renew/Rebind messages		Besides, this check is not performed on DHCP Renew/Rebind
	(Section 6.4.3).		messages.
	o Binding limitation check: the DHCP messages must not cause new		o Binding limitation check: the DHCP messages must not cause new
	binding setup on an attachment whose binding entry limitation has		binding setup on an attachment whose binding entry limitation has
	been reached. (refer to Section 11.5).		been reached. (refer to Section 11.5).
	o Address check: the source address of the DHCP messages should pass		o Address check: the source address of the DHCP messages should pass
	the check specified in Section 8.2.		the check specified in Section 8.2.
	On receiving a DHCP message without triggering a valid event, the		On receiving a DHCP message without triggering a valid event, the
	state will not transit and actions will not be performed. Note that		state will not change, and the actions will not be performed. Note
	if a message does not trigger a valid event but it can pass the		that if a message does not trigger a valid event but it can pass the
	checks in Section 8.2, it MUST be forwarded.		checks in Section 8.2, it MUST be forwarded.
	6.4. The State Machine of DHCP Snooping Process		6.4. The State Machine of DHCP Snooping Process
	This section specifies the transits of each state and the		This section specifies state transitions and their corresponding
	corresponding actions.		actions.
	6.4.1. From NO_BIND to INIT_BIND		6.4.1. Initial State: NO_BIND - No binding has been set up
	6.4.1.1. Trigger Events		6.4.1.1. Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request
			message is received
	Trigger events: EVE_DHCP_REQUEST, EVE_DHCP_SOLICIT_RC,		The SAVI device MUST forward the message.
	EVE_DHCP_CONFIRM, EVE_DHCP_REBOOT.
	6.4.1.2. Following Actions		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 or DHCPv4 Reboot, the Address field can be set to the address
			to request, i.e., the 'requested IP address'. An example of the
			entry is illustrated in Figure 5.
	If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_SOLICIT_RC/		+---------+-------+---------+-----------------------+-------+
	EVE_DHCP_REBOOT:		| Anchor |Address| State | Lifetime |TID |
			+---------+-------+---------+-----------------------+-------+
			| Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |
			+---------+-------+---------+-----------------------+-------+
			Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot
			triggered initialization
			Resulting state: INIT_BIND - A potential binding has been set up
			6.4.1.2. Event: EVE_DHCP_REBOOT - A DHCPv4 Reboot message is received
	The SAVI device MUST forward the message.		The SAVI device MUST forward the message.
	The SAVI device will generate an entry in the BST. The Binding		The SAVI device will generate an entry in the BST. The Binding
	anchor field is set to the binding anchor of the attachment from		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.		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		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		field is set to the TID of the message. If the message is DHCPv4
	Request or DHCPv4 Reboot, the Address field can be set to the address		Request or DHCPv4 Reboot, the Address field can be set to the address
	to request, i.e., the 'requested IP address'. An example of the		to request, i.e., the 'requested IP address'. An example of the
	entry is illustrated in Figure 5.		entry is illustrated in Figure 5.
	+---------+-------+---------+-----------------------+-------+		Resulting state: INIT_BIND - A potential binding has been set up
	| Anchor |Address| State | Lifetime |TID |
	+---------+-------+---------+-----------------------+-------+
	| Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |
	+---------+-------+---------+-----------------------+-------+
	Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot		6.4.1.3. Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message
	triggered initialization		with Rapid Commit option is received
	If the triggering event is EVE_DHCP_CONFIRM:		The SAVI device MUST forward the message.
			The SAVI device will generate an entry in the BST. The Binding
			anchor field is set to the binding anchor of the attachment from
			which the message is received. The State field is set to INIT_BIND.
			The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID
			field is set to the TID of the message. If the message is DHCPv4
			Request or DHCPv4 Reboot, the Address field can be set to the address
			to request, i.e., the 'requested IP address'. An example of the
			entry is illustrated in Figure 5.
			Resulting state: INIT_BIND - A potential binding has been set up
			6.4.1.4. Event: EVE_DHCP_CONFIRM - A DHCPv6 Confirm message is received
	The SAVI device MUST forward the message.		The SAVI device MUST forward the message.
	The SAVI device will generate corresponding entries in the BST for		The SAVI device will generate corresponding entries in the BST for
	all the addresses in each the IA option of the Confirm message. The		each address in each Identity Association (IA) option of the Confirm
	Binding anchor field is set to the binding anchor of the attachment		message. The Binding anchor field is set to the binding anchor of
	from which the message is received. The State field is set to		the attachment from which the message is received. The State field
	INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME.		is set to INIT_BIND. The Lifetime field is set to be
	The TID field is set to the TID of the message. The Address field is		MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the
	set to the address(es) to confirm. An example of the entries is		message. The Address field is set to the address(es) to confirm. An
	illustrated in Figure 6.		example of the entries is illustrated in Figure 6.
	+---------+--------+---------+-----------------------+-------+		+---------+--------+---------+-----------------------+-------+
	| Anchor | Address| State | Lifetime |TID |		| Anchor | Address| State | Lifetime |TID |
	+---------+--------+---------+-----------------------+-------+		+---------+--------+---------+-----------------------+-------+
	| Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |		| Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |
	+---------+--------+---------+-----------------------+-------+		+---------+--------+---------+-----------------------+-------+
	| Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |		| Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |
	+---------+--------+---------+-----------------------+-------+		+---------+--------+---------+-----------------------+-------+
	Figure 6: Binding entry in BST on Confirm triggered initialization		Figure 6: Binding entry in BST on Confirm triggered initialization
	6.4.2. From INIT_BIND to Other States		Resulting state: INIT_BIND - A potential binding has been set up
	6.4.2.1. Trigger Events		6.4.1.5. Events that cannot happen in the NO_BIND state
	Trigger events: EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE.		o EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires
	Note: If no DHCP Server-Client messages which assign addresses or		o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is
	confirm addresses are received, corresponding entries will expire		received
	automatically. Thus, other DHCP Server-Client messages (e.g., DHCPv4
	NAK) are not specially processed.
	6.4.2.2. Following Actions		o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is
			received
	If the trigger event is EVE_DHCP_REPLY:		o EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received
			o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is
			received
			o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is
			received
			o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY is
			received
			These cannot happen because they are each something that happens
			AFTER a binding has been created.
			6.4.2. Initial State: INIT_BIND - A potential binding has been set up
			6.4.2.1. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message
			is received
	The message MUST be forwarded to the corresponding client.		The message MUST be forwarded to the corresponding client.
	If the message is DHCPv4 ACK, the Address field of the corresponding		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)		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).		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		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.		and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND.
	If the message is DHCPv6 Reply, there are following cases:		If the message is DHCPv6 Reply, there are following cases:
	1. If the status code is not "Success", no modification on		1. If the status code is not "Success", no modification on
	corresponding entries will be made. Corresponding entries will		corresponding entries will be made. Corresponding entries will
	expire automatically if no "Success" Reply is received during the		expire automatically if no "Success" Reply is received during the
	lifetime. The entries are not removed immediately due to the client		lifetime. The entries are not removed immediately due to the
	may be able to use the addresses whenever a "Success" Reply is		client may be able to use the addresses whenever a "Success"
	received ("If the client receives any Reply messages that do not		Reply is received ("If the client receives any Reply messages
	indicate a NotOnLink status, the client can use the addresses in the		that do not indicate a NotOnLink status, the client can use the
	IA and ignore any messages that indicate a NotOnLink status."		addresses in the IA and ignore any messages that indicate a
	[RFC3315]).		NotOnLink status." [RFC3315]).
	2. If the status code is "Success", the SAVI device checks the IA		2. If the status code is "Success", the SAVI device checks the IA
	options in the Reply message.		options in the Reply message.
	2.1 If there are no IA options in the Reply message, the DHCP Reply		A. If there are IA options in the Reply message, the SAVI device
	message is in response to a Confirm message. The state of the		checks each IA option. When the first assigned address is
	binding entries with matched TID is changed to BOUND. Because		found, the Address field of the binding entry with matched
	[RFC3315] does not require lease time of addresses to be contained in		TID is set to the address. The Lifetime field is set to the
	the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007]		sum of the lease time in Reply message and
	message querying by IP address to All_DHCP_Servers multicast address		MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND.
	[RFC3315] or a list of configured DHCP server addresses. The		If there are more than one address assigned in the message,
	Leasequery message is generated for each IP address if multiple		new binding entries are set up for the remaining address
	addresses are confirmed. The Lifetime of corresponding entries is		assigned in the IA options. An example of the entries is
	set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after		illustrated in Figure 8. SAVI devices do not specially
	MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example		process IA options with NoAddrsAvail status, because there
	of the entries is illustrated in Figure 7. If the SAVI device does		should be no address contained in such IA options.
	not send the LEASEQUERY message, a pre-configured lifetime
	DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. (Note: it
	is SUGGESUTED to use T1 configured on DHCP servers as the
	DHCP_DEFAULT_LEASE.)
	2.2 If there are IA options in the Reply message, the SAVI device		B. Otherwise, the DHCP Reply message is in response to a Confirm
	checks each IA option. When the first assigned address is found, the		message. The state of the binding entries with matched TID
	Address field of the binding entry with matched TID is set to the		is changed to BOUND. Because [RFC3315] does not require
	address. The Lifetime field is set to the sum of the lease time in		lease time of addresses to be contained in the Reply message,
	Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed		the SAVI device SHOULD send a LEASEQUERY [RFC5007] message
	to BOUND. If there are more than one address assigned in the		querying by IP address to All_DHCP_Servers multicast address
	message, new binding entries are set up for the remaining address		[RFC3315] or a list of configured DHCP server addresses. The
	assigned in the IA options. An example of the entries is illustrated		Lease query message is generated for each IP address if
	in Figure 8. SAVI devices do not specially process IA options with		multiple addresses are confirmed. The Lifetime of
	NoAddrsAvail status, because there should be no address contained in		corresponding entries is set to 2*MAX_LEASEQUERY_DELAY. If
	such IA options.		there is no response message after MAX_LEASEQUERY_DELAY, send
			the LEASEQUERY message again. An example of the entries is
			illustrated in Figure 7. If the SAVI device does not send
			the LEASEQUERY message, a 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.)
	Note: the SAVI devices do not check if the assigned addresses are		Note: the SAVI devices do not check if the assigned addresses are
	duplicated because in SAVI-DHCP scenarios, the DHCP servers are the		duplicated because in SAVI-DHCP scenarios, the DHCP servers are the
	only source of valid addresses. However, the DHCP servers should be		only source of valid addresses. However, the DHCP servers should be
	configured to make sure no duplicated addresses are assigned.		configured to make sure no duplicated addresses are assigned.
	+---------+----------+-------+------------------------+-------+		+---------+----------+-------+------------------------+-------+
	| Anchor | Address | State | Lifetime |TID |		| Anchor | Address | State | Lifetime |TID |
	+---------+----------+-------+------------------------+-------+		+---------+----------+-------+------------------------+-------+
	| Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID |		| Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID |
	+---------+----------+-------+------------------------+-------+		+---------+----------+-------+------------------------+-------+
	| Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID |		| Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID |
	+---------+----------+-------+------------------------+-------+		+---------+----------+-------+------------------------+-------+
	Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to		Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to
	Confirm		Confirm
	+---------+----------+-------+------------------------+-------+		+---------+----------+-------+------------------------+-------+
	| Anchor | Address | State | Lifetime |TID |		| Anchor | Address | State | Lifetime |TID |
	+---------+----------+-------+------------------------+-------+		+---------+----------+-------+------------------------+-------+
	| Port_1 | Addr1 | BOUND |Lease time+ |TID |		| Port_1 | Addr1 | BOUND |Lease time+ |TID |
	| | | |MAX_DHCP_RESPONSE_TIME | |		| | | |MAX_DHCP_RESPONSE_TIME | |
	+---------+----------+-------+------------------------+-------+		+---------+----------+-------+------------------------+-------+
	| Port_1 | Addr2 | BOUND |Lease time+ |TID |		| Port_1 | Addr2 | BOUND |Lease time+ |TID |
	| | | |MAX_DHCP_RESPONSE_TIME | |		| | | |MAX_DHCP_RESPONSE_TIME | |
	+---------+----------+-------+------------------------+-------+		+---------+----------+-------+------------------------+-------+
	Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to		Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to
	Request		Request
	If the trigger event is EVE_ENTRY_EXPIRE:		Resulting state: BOUND - The binding has been set up
			6.4.2.2. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry
			expires
	The entry MUST be deleted from BST.		The entry MUST be deleted from BST.
	6.4.3. From BOUND to Other States		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.
	6.4.3.1. Trigger Events		6.4.2.3. Events that are ignored in INIT_BIND
	Trigger events: EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE,		If no DHCP Server-to-Client messages which assign addresses or
	EVE_DHCP_REPLY, EVE_DHCP_LEASEQUERY, EVE_DHCP_RENEW, EVE_DHCP_REBIND.		confirm addresses are received, corresponding entries will expire
			automatically. Thus, other DHCP Server-to-Client messages (e.g.,
			DHCPv4 NAK) are not specially processed.
	6.4.3.2. Following Actions		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.
	If the trigger event is EVE_ENTRY_EXPIRE:		o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is
			received
	Remove the corresponding entry in BST.		o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received
	If the trigger event is EVE_DHCP_RELEASE/EVE_DHCP_DECLINE:		o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received
			o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is
			received
			o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is
			received
			o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid
			Commit option is received
			o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is
			received
			o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is
			received
			o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY is
			received
			In each case, the message MUST be forwarded.
			Resulting state: INIT_BIND - A potential binding has been set up
			6.4.3. Initial State: BOUND - The binding has been set up
			6.4.3.1. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry
			expires
			The entry MUST be deleted from BST.
			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.
			6.4.3.2. Event: EVE_DHCP_DECLINE - A DHCPv4 Decline or a DHCPv6 Decline
			message is received
	The message MUST be forwarded.		The message MUST be forwarded.
	The SAVI device first gets all the addresses ("Requested IP address"		The SAVI device first gets all the addresses ("Requested IP address"
	in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the		in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the
	IA options of DHCPv6 Decline/Release) to decline/release in the		IA options of DHCPv6 Decline/Release) to decline/release in the
	message. Then the corresponding entries MUST be removed.		message. Then the corresponding entries MUST be removed.
	If the trigger event is EVE_DHCP_RENEW/EVE_DHCP_REBIND:		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.
			6.4.3.3. Event: EVE_DHCP_RELEASE - A DHCPv4 Release or a DHCPv6 Release
			message is received
			The message MUST be forwarded.
			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.
			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.
			6.4.3.4. Event: EVE_DHCP_REBIND - A DHCPv4 Rebind or a DHCPv6 Rebind
			message is received
	The message MUST be forwarded.		The message MUST be forwarded.
	In such case, a new TID will be used by the client. The TID field of		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		the corresponding entries MUST be set to the new TID. Note that TID
	check will not be performed on such messages.		check will not be performed on such messages.
	If the trigger event is EVE_DHCP_REPLY:		Resulting state: BOUND: The binding has been set up
			6.4.3.5. Event: EVE_DHCP_RENEW - A DHCPv4 Renew or a DHCPv6 Renew
			message is received
			The message MUST be forwarded.
			In such 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.
			Resulting state: BOUND: The binding has been set up
			6.4.3.6. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message
			is received
	The message MUST be forwarded.		The message MUST be forwarded.
	The DHCP Reply messages received in current states should be in		The DHCP Reply messages received in current states should be in
	response to DHCP Renew/Rebind.		response to DHCP Renew/Rebind.
	If the message is DHCPv4 ACK, the SAVI device just simply update the		If the message is DHCPv4 ACK, the SAVI device updates the binding
	binding entry with matched TID, with the Lifetime field set to be the		entry with matched TID, with the Lifetime field set to be the sum of
	sum of the new lease time and MAX_DHCP_RESPONSE_TIME.		the new lease time and MAX_DHCP_RESPONSE_TIME, leaving the entry in
			the state BOUND.
	If the message is DHCPv6 Reply, the SAVI device checks each IA		If the message is DHCPv6 Reply, the SAVI device checks each IA
	Address option in each IA option. If the valid lifetime of an IA		Address option in each IA option. For each:
	address option is 0, the binding entry with matched TID and address
	is removed. Or else, 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.
	The SAVI device does not specially process IA options in Reply		1. If the IA entry in the REPLY message has the status "NoBinding",
	message with status NoBinding, because no address is contained in		there is no address in the option, and no operation on an address
	such IA options and no actions will be performed.		is performed.
	If the trigger event is EVE_DHCP_LEASEQUERY:		2. 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.
			3. 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.
			Resulting state: NO_BIND or BOUND, as specified.
			6.4.3.7. Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6
			LEASEQUERY_REPLY is received
	The message MUST be forwarded.		The message MUST be forwarded.
	The message should be in response to the Leasequery message sent in		The message should be in response to the Lease query message sent in
	Section 6.4.2. The related binding entry can be determined based on		Section 6.4.2. The related binding entry can be determined based on
	the address in the IA Address option in the Leasequery-reply message.		the address in the IA Address option in the Lease query-reply
	The Lifetime field of the corresponding binding entry is set to the		message. The Lifetime field of the corresponding binding entry is
	sum of the lease time in the LEASEQUERY_REPLY message and		set to the sum of the lease time in the LEASEQUERY_REPLY message and
	MAX_DHCP_RESPONSE_TIME.		MAX_DHCP_RESPONSE_TIME.
	6.5. Table of State Machine		Resulting state: BOUND: The binding has been set up
			6.4.3.8. Events not processed in the state BOUND
			The following events are ignored if received while the indicated
			entry is in the state BOUND. Any required action will be the result
			of the next message in the client/server exchange.
			o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is
			received
			o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received
			o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received
			o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid
			Commit option is received
			6.4.4. Table of State Machine
	The main state transits are listed as follows. Note that not all the		The main state transits are listed as follows. Note that not all the
	details are specified in the table and the diagram.		details are specified in the table and the diagram.
	State Event Action Next State		State Event Action Next State
	NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND		NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND
	INIT_BIND RPL Record lease time BOUND		INIT_BIND RPL Record lease time BOUND
	(send lease query if no lease)		(send lease query if no lease)
	INIT_BIND Timeout Remove entry NO_BIND		INIT_BIND EVE_ENTRY_EXPIRE Remove entry NO_BIND
	BOUND RLS/DCL Remove entry NO_BIND		BOUND RLS/DCL Remove entry NO_BIND
	BOUND Timeout Remove entry NO_BIND		BOUND EVE_ENTRY_EXPIRE Remove entry NO_BIND
	BOUND RPL Set new lifetime BOUND		BOUND RPL Set new lifetime BOUND
	BOUND LQR Record lease time BOUND		BOUND LQR Record lease time BOUND
	Figure 9: Table of Transit		Figure 9: Table of Transit
	RQ: EVE_DHCP_REQUEST		RQ: EVE_DHCP_REQUEST
	CF: EVE_DHCP_CONFIRM		CF: EVE_DHCP_CONFIRM
	RC: EVE_DHCP_SOLICIT_RC		RC: EVE_DHCP_SOLICIT_RC
	skipping to change at page 27, line 10 ¶		skipping to change at page 29, line 10 ¶
	LQR: EVE_DHCP_LEASEQUERY		LQR: EVE_DHCP_LEASEQUERY
	Timeout: EVE_ENTRY_EXPIRE		Timeout: EVE_ENTRY_EXPIRE
	+-------------+		+-------------+
	| |		| |
	/---------| NO_BIND |<----------\		/---------| NO_BIND |<----------\
	| ------>| | |		| ------>| | |
	| | +-------------+ |EVE_DHCP_RELEASE		| | +-------------+ |EVE_DHCP_RELEASE
	EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE		EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE
	EVE_DHCP_CONFIRM | |TIMEOUT |TIMEOUT		EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE
	EVE_DHCP_SOLICIT_RC| | |		EVE_DHCP_SOLICIT_RC| | |
	EVE_DHCP_REBOOT | | |		EVE_DHCP_REBOOT | | |
	| | |		| | |
	| | |		| | |
	v | |		v | |
	+-------------+ +------------+		+-------------+ +------------+
	| | EVE_DHCP_REPLY | |		| | EVE_DHCP_REPLY | |
	| INIT_BIND ------------------------>| BOUND |<-\		| INIT_BIND ------------------------>| BOUND |<-\
	| | | | |		| | | | |
	+-------------+ +------------+ |		+-------------+ +------------+ |
	skipping to change at page 27, line 40 ¶		skipping to change at page 29, line 40 ¶
	7.1. Scenario		7.1. Scenario
	The rationale of the DHCP Snooping Process specified in Section 6 is		The rationale of the DHCP Snooping Process specified in Section 6 is
	that if a DHCP client's use of a DHCP address is legitimate, the		that if a DHCP client's use of a DHCP address is legitimate, the
	corresponding DHCP address assignment procedure must have been		corresponding DHCP address assignment procedure must have been
	finished on the attachment of the DHCP client. This is the case		finished on the attachment of the DHCP client. This is the case
	stands when the SAVI device is persistently on the path(s) from the		stands when the SAVI device is persistently on the path(s) from the
	DHCP client to the DHCP server(s)/relay(s). However, there are two		DHCP client to the DHCP server(s)/relay(s). However, there are two
	case when this does not work:		case when this does not work:
	o Multiple paths: there is more than one feasible layer-2 paths from		o Multiple paths: there is more than one feasible link-layer paths
	the client to the DHCP server/relay, and the SAVI device is not on		from the client to the DHCP server/relay, and the SAVI device is
	everyone of them. The client may get its address through one of		not on everyone of them. The client may get its address through
	the paths not passing by the SAVI device, but packets from the		one of the paths not passing by the SAVI device, but packets from
	client can travel through paths that pass through the SAVI device.		the client can travel through paths that pass through the SAVI
	Because the SAVI device could not snoop the DHCP packet exchange		device. Because the SAVI device could not snoop the DHCP packet
	procedure, the DHCP snooping procedure cannot set up the		exchange procedure, the DHCP snooping procedure cannot set up the
	corresponding binding.		corresponding binding.
	o Dynamic path: there is only one feasible layer-2 path from the		o Dynamic path: there is only one feasible link-layer path from the
	client to the DHCP server/relay, but the path is dynamic due to		client to the DHCP server/relay, but the path is dynamic due to
	topology change (for example, some link turns broken due to		topology change (for example, some link turns broken due to
	failure or as planned) or layer-2 path change. This situation		failure or as planned) or link-layer path change. This situation
	also covers the local-link movement of clients without address		also covers the local-link movement of clients without address
	confirm/re-configuration process. For example, a host changes its		confirm/re-configuration process. For example, a host changes its
	attached switch port in a very short time. In such cases, the		attached switch port in a very short time. In such cases, the
	DHCP snooping process will not set up the corresponding binding.		DHCP snooping process will not set up the corresponding binding.
	Data Snooping Process prevents permanently blocking legitimate		Data Snooping Process prevents permanently blocking legitimate
	traffic in case of these two exceptions. This process is performed		traffic in case of these two exceptions. This process is performed
	on attachments with the Data-Snooping attribute. Data packets		on attachments with the Data-Snooping attribute. Data packets
	without matching binding entry may trigger this process to set up		without matching binding entry may trigger this process to set up
	bindings.		bindings.
	skipping to change at page 28, line 37 ¶		skipping to change at page 30, line 33 ¶
	there is no need to implement this process in such scenarios.		there is no need to implement this process in such scenarios.
	This process is not intended to set up a binding whenever a data		This process is not intended to set up a binding whenever a data
	packet without matched binding entry is received. Instead, unmatched		packet without matched binding entry is received. Instead, unmatched
	data packets trigger this process probabilistically and generally a		data packets trigger this process probabilistically and generally a
	number of unmatched packets will be discarded before the binding is		number of unmatched packets will be discarded before the binding is
	set up.		set up.
	7.2. Rationale		7.2. Rationale
	This process makes use of NS/ARP and DHCP Leasequery to set up		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		bindings. If an address is not used by another client in the
	network, and the address has been assigned in the network, the		network, and the address has been assigned in the network, the
	address can be bound with the binding anchor of the attachment from		address can be bound with the binding anchor of the attachment from
	which the unmatched packet is received.		which the unmatched packet is received.
	The security issues about this process is discussed is Section 11.1.		The security issues about this process is discussed is Section 11.1.
	7.3. Additional Binding States Description		7.3. Additional Binding States Description
	In addition to Section 6.2, new states used in this process are		In addition to NO_BIND and BOUND from Section 6.2, two new states
	listed here:		used in this process are listed here. The INIT_BIND state is not
			used, as it is entered by observing a DHCP message.
	DETECTION: The address in the entry is under local duplication		DETECTION: The address in the entry is under local duplication
	detection.		detection.
	RECOVERY: The SAVI device is querying the assignment and lease time		RECOVERY: The SAVI device is querying the assignment and lease time
	of the address in the entry through DHCP Leasequery.		of the address in the entry through DHCP Lease query.
	7.4. Events		7.4. Events
	Additional events in this process are described here. Also, if an		In addition to EVE_DATA_LEASEQUERY and EVE_DHCP_REBIND, these
	event will trigger the creation of a new binding entry, the binding		additional events are described here. If an event will trigger the
	entry limit on the binding anchor MUST NOT be exceeded.		creation of a new binding entry, the binding entry limit on the
			binding anchor MUST NOT be exceeded.
	EVE_DATA_UNMATCH: A data packet without matched binding is received.		EVE_DATA_UNMATCH: A data packet without matched binding is received.
	EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message		EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
	against an address in DETECTION state is received from a host other		against an address in DETECTION state is received from a host other
	than the one for which the entry was added.		than the one for which the entry was added.
	EVE_DATA_LEASEQUERY:		EVE_DATA_LEASEQUERY:
	IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option		o IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option
	is received.		is received.
	IPv6: A successful LEASEQUERY-REPLY is received.		o IPv6: A successful LEASEQUERY-REPLY is received.
	The triggering packet should pass the following checks to trigger a		The triggering packet should pass the following checks to trigger a
	valid event:		valid event:
	o Attribute check: the data packet should be from attachments with		o Attribute check: the data packet should be from attachments with
	Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY		Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY
	messages should be from attachments with DHCP-Snooping attribute.		messages should be from attachments with DHCP-Snooping attribute.
	o Binding limitation check: the DHCP messages must not cause new		o Binding limitation check: the DHCP messages must not cause new
	binding setup on an attachment whose binding entry limitation has		binding setup on an attachment whose binding entry limitation has
	been reached. (refer to Section 11.5).		been reached. (refer to Section 11.5).
	o Address check: For EVE_DATA_LEASEQUERY, the source address of the		o Address check: For EVE_DATA_LEASEQUERY, the source address of the
	DHCP Leasequery messages must pass the check specified in		DHCP Lease query messages must pass the check specified in
	Section 8.2. For EVE_DATA_CONFLICT, the source address and target		Section 8.2. For EVE_DATA_CONFLICT, the source address and target
	address of the ARP or NA messages must pass the check specified in		address of the ARP or NA messages must pass the check specified in
	Section 8.2.		Section 8.2.
	o Interval check: the interval between two successive		o Interval check: the interval between two successive
	EVE_DATA_UNMATCH events triggered by an attachment MUST be no		EVE_DATA_UNMATCH events triggered by an attachment MUST be no
	smaller than DATA_SNOOPING_INTERVAL.		smaller than DATA_SNOOPING_INTERVAL.
	o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have		o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have
	matched TID with the corresponding entry.		matched TID with the corresponding entry.
	o Prefix check: the source address of the data packet should be of a		o Prefix check: the source address of the data packet should be of a
	valid local prefix, as specified in section 7 of [RFC7039].		valid local prefix, as specified in section 7 of [RFC7039].
	7.5. State Machine of Binding Recovery Process		EVE_ENTRY_EXPIRE: A timer expires.
	Through using additional states, the state machine of this process
	doesn't conflict the regular process described in Section 6. Thus,
	it can be implemented separately without changing the state machine
	in Section 6.
	7.5.1. From NO_BIND to DETECTION
	7.5.1.1. Trigger Event
	Trigger event: EVE_DATA_UNMATCH.		7.5. Initial State: state NO_BIND - No binding has been set up
	7.5.1.2. Following Actions		7.5.1. Event: EVE_DATA_UNMATCH: A data packet without matched binding
			is received
	Make a probabilistic determination whether to act on this event. The		Make a probabilistic determination whether to act on this event. The
	probability can be configured or calculated based on the state of the		probability may be configured or calculated based on the state of the
	SAVI device. This probability should be low enough to mitigate the		SAVI device. This probability should be low enough to mitigate the
	damage from DoS attack against this process.		damage from DoS attack against this process.
	Create a new entry in the BST. Set the Binding Anchor field to the		Create a new entry in the BST. Set the Binding Anchor field to the
	corresponding binding anchor of the attachment. Set the Address		corresponding binding anchor of the attachment. Set the Address
	field to be source address of the packet. Set the State field to		field to the source address of the packet. Set the State field to
	DETECTION. Set the Lifetime of the created entry to		DETECTION. Set the Lifetime of the created entry to
	2*DETECTION_TIMEOUT.		2*DETECTION_TIMEOUT.
	Check if the address has a local conflict (it violates an address		Check if the address has a local conflict (it violates an address
	being used by another node):		being used by another node):
	(1) IPv4 address: send an Address Resolution Protocol (ARP) Request		(1) IPv4 address: send an Address Resolution Protocol (ARP) Request
	[RFC0826]or a ARP probe [RFC5227] on the address; if there is no		[RFC0826] or an ARP probe [RFC5227] on the address; if there is
	response message after DETECTION_TIMEOUT, send another ARP		no response message after DETECTION_TIMEOUT, send another ARP
	Request or ARP probe;		Request or ARP probe;
	(2) IPv6 address: send a Neighbor Solicitation message [RFC4861]		(2) IPv6 address: send a Duplicate Address Detection message
	targeting on the address; if there is no response message after		[RFC4861] targeting the address; ideally, only the host on that
	DETECTION_TIMEOUT, send another Neighbor Solicitation message.		point of attachment responds with a Neighbor Advertisement; if
			more than one Neighbor Advertisement is observed, the BST entry
			should be removed.
	Because the delivery of detection message is unreliable, the		Because the delivery of the detection message is unreliable, the
	detection message may fail to reach the targeting node. If there is		detection message may fail to reach the targeting node. If there is
	a node that has the IP address seen in the Data Snooping Process, it		a node that has the IP address seen in the Data Snooping Process, it
	may not get the detection messages. This failure mode enables an		may not get the detection messages. This failure mode enables an
	attack against the Data Snooping Process. Thus, the detection is		attack against the Data Snooping Process. Thus, the detection is
	performed again if there is no response after the first detection.		performed again if there is no response after the first detection.
	The messages MUST NOT be sent to the attachment from which the		The packet that triggers this event SHOULD be discarded.
	triggering packet is received.
	The packet which triggers this event SHOULD be discarded.
	This local conflict process SHOULD be performed. If it is not		This local conflict process SHOULD be performed. If it is not
	performed, the state of the entry is set to RECOVERY, the lifetime is		performed, the state of the entry is set to RECOVERY, the lifetime is
	set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified		set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified
	in the following section will be performed directly.		in the following section will be performed directly.
	An example of the entry is illustrated in Figure 11.		An example of the entry is illustrated in Figure 11.
	+---------+-------+---------+-----------------------+-------+		+---------+-------+---------+-----------------------+-------+
	| Anchor |Address| State | Lifetime |TID |		| Anchor |Address| State | Lifetime |TID |
	+---------+-------+---------+-----------------------+-------+		+---------+-------+---------+-----------------------+-------+
	| Port_1 | Addr1 |DETECTION|2*DETECTION_TIMEOUT | |		| Port_1 | Addr1 |DETECTION|2*DETECTION_TIMEOUT | |
	+---------+-------+---------+-----------------------+-------+		+---------+-------+---------+-----------------------+-------+
	Figure 11: Binding entry in BST on data triggered initialization		Figure 11: Binding entry in BST on data triggered initialization
	7.5.2. From DETECTION to Other States		Resulting state: DETECTION - The address in the entry is under local
			duplication detection
	7.5.2.1. Trigger Event		7.5.2. Events not observed in NO_BIND
	Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_CONFLICT.		EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
			received from unexpected system
	7.5.2.2. Following Actions		EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received
	If the trigger event is EVE_ENTRY_EXPIRE:		EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is
			received
			EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is
			received
			EVE_ENTRY_EXPIRE
			7.6. Initial State: state DETECTION - The address in the entry is under
			local duplication detection
			7.6.1. Event: EVE_ENTRY_EXPIRE (e.g., Timeout)
	(1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying		(1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying
	by IP address to each DHCPv4 server with IP Address Lease Time		by IP address to each DHCPv4 server with IP Address Lease Time
	option (option 51). A list of authorized DHCP servers are kept		option (option 51). A list of authorized DHCP servers are kept
	by the SAVI device. The list should be pre-configured or		by the SAVI device. The list should be pre-configured or
	discovered by sending DHCPv4 Discover messages and parsing the		discovered by sending DHCPv4 Discover messages and parsing the
	replied DHCPv4 Offer messages. Change the state of the		replied DHCPv4 Offer messages. Change the state of the
	corresponding entry to RECOVERY. Change the lifetime of the		corresponding entry to RECOVERY. Change the lifetime of the
	entry to be 2*MAX_LEASEQUERY_DELAY. The TID field is set to the		entry to be 2*MAX_LEASEQUERY_DELAY. The TID field is set to the
	TID used in the DHCPLEASEQUERY message. If there is no response		TID used in the DHCPLEASEQUERY message. If there is no response
	skipping to change at page 32, line 9 ¶		skipping to change at page 34, line 10 ¶
	address to All_DHCP_Relay_Agents_and_Servers multicast address or		address to All_DHCP_Relay_Agents_and_Servers multicast address or
	a list of pre-configured DHCPv6 server addresses. Change the		a list of pre-configured DHCPv6 server addresses. Change the
	state of the corresponding entry to RECOVERY. Change the		state of the corresponding entry to RECOVERY. Change the
	lifetime of the entry to be 2*MAX_LEASEQUERY_DELAY. The TID		lifetime of the entry to be 2*MAX_LEASEQUERY_DELAY. The TID
	field is set to the TID used in the LEASEQUERY message. If there		field is set to the TID used in the LEASEQUERY message. If there
	is no response message after MAX_LEASEQUERY_DELAY, send the		is no response message after MAX_LEASEQUERY_DELAY, send the
	LEASEQUERY message again.		LEASEQUERY message again.
	An example of the entry is illustrated in Figure 12.		An example of the entry is illustrated in Figure 12.
	+---------+-------+---------+-----------------------+-------+		+---------+-------+---------+-----------------------+-------+
	| Anchor |Address| State | Lifetime |TID |		| Anchor |Address| State | Lifetime |TID |
	+---------+-------+---------+-----------------------+-------+		+---------+-------+---------+-----------------------+-------+
	| Port_1 | Addr1 |RECOVERY |2*MAX_LEASEQUERY_DELAY |TID |		| Port_1 | Addr1 |RECOVERY |2*MAX_LEASEQUERY_DELAY |TID |
	+---------+-------+---------+-----------------------+-------+		+---------+-------+---------+-----------------------+-------+
	Figure 12: Binding entry in BST on Lease Query		Figure 12: Binding entry in BST on Lease Query
	If the trigger event is EVE_DATA_CONFLICT:		Resulting state: RECOVERY - The SAVI device is querying the
			assignment and lease time of the address in the entry through DHCP
			Leasequery
			7.6.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA)
			message received from unexpected system
	Remove the entry.		Remove the entry.
	7.5.3. From RECOVERY to Other States		Resulting state: NO_BIND - No binding has been set up
	7.5.3.1. Trigger Event		7.6.3. Events not observed in DETECTION
	Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_LEASEQUERY.		EVE_DATA_UNMATCH: A data packet without matched binding is received
	7.5.3.2. Following Actions		EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received
	If the trigger event is EVE_DATA_LEASEQUERY:		EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is
			received
			EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is
			received
			7.7. Initial State: state RECOVERY - The SAVI device is querying the
			assignment and lease time of the address in the entry through DHCP
			Leasequery
			7.7.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or
			LEASEQUERY-REPLY is received
	IPv4 address:		IPv4 address:
	(1) Send an ARP Request with the Target Protocol Address set to the		(1) Send an ARP Request with the Target Protocol Address set to the
	IP address in the corresponding entry. The ARP Request is only		IP address in the corresponding entry. The ARP Request is only
	sent to the attachment which triggers the binding. If there is		sent to the attachment which triggers the binding. If there is
	no response after DETECTION_TIMEOUT, send another ARP Request.		no response after DETECTION_TIMEOUT, send another ARP Request.
	If there is still no response, the following actions will not be		If there is still no response, remove the entry.
	performed. If there is only one identical response, get the
	sender hardware address. Check if the 'chaddr' field (hardware
	address) of the DHCPLEASEACTIVE message matches the sender
	hardware address. If the two addresses do not match, the
	following actions will not be performed. If there is more than
	one response, if any of the sender hardware addresses matches the
	'chaddr' field (hardware address) of the DHCPLEASEACTIVE message,
	the following actions are to be performed.
	(2) Change the state of the corresponding binding to BOUND. Set		(2) If there is only one identical response, get the sender hardware
	life time to the sum of the value encoded in IP Address Lease		address. Check if the 'chaddr' field (hardware address) of the
	Time option of the DHCPLEASEACTIVE message and		DHCPLEASEACTIVE message matches the sender hardware address. If
	MAX_DHCP_RESPONSE_TIME. Erase the TID field.		the two addresses do not match, the following actions will not be
			performed. If there is more than one response, if any of the
			sender hardware addresses matches the 'chaddr' field (hardware
			address) of the DHCPLEASEACTIVE message,
			* Set life time to the sum of the value encoded in IP Address
			Lease Time option of the DHCPLEASEACTIVE message and
			MAX_DHCP_RESPONSE_TIME.
			* Erase the TID field.
	IPv6 address:		IPv6 address:
	(1) Send a Neighbor Solicitation message with the target address set		(1) Send a Neighbor Solicitation message with the target address set
	to the IP address in the corresponding entry. The Neighbor		to the IP address in the corresponding entry. The Neighbor
	Solicitation is only sent to the attachment which triggers the		Solicitation is only sent to the attachment which triggers the
	binding. If there is no response after DETECTION_TIMEOUT, send		binding. If there is no response after DETECTION_TIMEOUT, send
	another Neighbor Solicitation. If there is still no response,		another Neighbor Solicitation. If there is still no response,
	the following actions will not be performed.		remove the entry.
	(2) Change the state of the corresponding binding to BOUND. Set the		(2) On receipt of a valid Neighbor Announcement,
	lifetime to the sum of the valid lifetime extracted from
	OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message and
	MAX_DHCP_RESPONSE_TIME. Erase the TID field.
	(3) After the above checks, if multiple addresses are specified in		* Set the lifetime to the sum of the valid lifetime extracted
	the LEASEQUERY-REPLY message and there are no corresponding		from OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY
	binding entries, new entries MUST also be created correspondingly		message and MAX_DHCP_RESPONSE_TIME.
	on the same binding anchor.
	If responses are received from multiple DHCP servers, the conflict		* Erase the TID field.
	resolution mechanisms specified in section 6.8 of [RFC4388] and
	section 4.3.4 of [RFC5007] will be used to determine which message
	should be used.
	If the trigger event is EVE_ENTRY_EXPIRE:		* After the above checks, if multiple addresses are specified
			in the LEASEQUERY-REPLY message and there are no
			corresponding binding entries, new entries MUST also be
			created correspondingly on the same binding anchor.
	Remove the entry.		In the event that responses are received from multiple DHCP servers,
			the conflict resolution mechanisms specified in section 6.8 of
			[RFC4388] and section 4.3.4 of [RFC5007] will be used to determine
			which message should be used.
	7.5.4. After BOUND		Resulting state: if ARP or ND succeeds (there is a valid response),
			BOUND - The binding has been set up. Otherwise, the resulting state
			is NO_BIND - No binding has been set up
			7.7.2. Event: EVE_ENTRY_EXPIRE (e.g., Timeout)
			Remove the entry
			Resulting state: NO_BIND - No binding has been set up
			7.7.3. Events not observed in RECOVERY
			EVE_DATA_UNMATCH: A data packet without matched binding is received
			EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
			received from unexpected system
			EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received
			EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is
			received
			7.8. Initial State: state BOUND - The binding has been set up
	Note that the TID field contains no value after the binding state		Note that the TID field contains no value after the binding state
	changes to BOUND. The TID field is recovered from snooping DHCP		changes to BOUND. The TID field is recovered from snooping DHCP
	Renew/Rebind messages. Because TID is used to associate binding		Renew/Rebind messages. Because TID is used to associate binding
	entries with messages from DHCP servers, it must be recovered; or		entries with messages from DHCP servers, it must be recovered; or
	else a number of state transits of this mechanism will be not		else a number of state transits of this mechanism will be not
	executed normally.		executed normally.
	7.5.4.1. Trigger Event		7.8.1. Event: EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message
			is received
	Trigger events: EVE_DHCP_RENEW, EVE_DHCP_REBIND.		Set the TID field of the corresponding entry to the TID in the
			triggering message.
	7.5.4.2. Following Action		Resulting state: BOUND - The binding has been set up
			7.8.2. Event: EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind
			message is received
	Set the TID field of the corresponding entry to the TID in the		Set the TID field of the corresponding entry to the TID in the
	triggering message.		triggering message.
	7.6. Table of State Machine		Resulting state: BOUND - The binding has been set up
			7.8.3. Events not observed in BOUND
			EVE_DATA_UNMATCH: A data packet without matched binding is received
			EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
			received from unexpected system
			EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is
			received
			EVE_ENTRY_EXPIRE
			7.9. Table of State Machine
	The main state transits are listed as follows.		The main state transits are listed as follows.
	State Event Action Next State		State Event Action Next State
	NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION		NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION
	DETECTION Timeout Send Leasequery RECOVERY		DETECTION EVE_ENTRY_EXPIRE Send Leasequery RECOVERY
	DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND		DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND
	RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND		RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND
	RECOVERY Timeout Remove entry NO_BIND		RECOVERY EVE_ENTRY_EXPIRE Remove entry NO_BIND
	BOUND RENEW/REBIND Record TID BOUND		BOUND RENEW/REBIND Record TID BOUND
	Figure 13: Table of Transit		Figure 13: Table of Transit
	RENEW: EVE_DHCP_RENEW		RENEW: EVE_DHCP_RENEW
	REBIND: EVE_DHCP_REBIND		REBIND: EVE_DHCP_REBIND
	Timeout: EVE_ENTRY_EXPIRE		Timeout: EVE_ENTRY_EXPIRE
	+-------------+		+-------------+
	| |		| |
	/---------| NO_BIND |<--------\		/---------| NO_BIND |<--------\
	| ------>| | | TIMEOUT		| ------>| | | EVE_ENTRY_EXPIRE
	| | +-------------+ |(2nd LQ_DELAY)		| | +-------------+ |(2nd LQ_DELAY)
	EVE_DATA_UNMATCH | | |		EVE_DATA_UNMATCH | | |
	| | |		| | |
	1st | | |		1st | | |
	DETECTION_TIMEOUT | | | 1st LQ_DELAY		DETECTION_TIMEOUT | | | 1st LQ_DELAY
	/------\ | | | /---------\		/------\ | | | /---------\
	| | | | EVE_DATA_CONFLICT | | |		| | | | EVE_DATA_CONFLICT | | |
	| v v | | v |		| v v | | v |
	| +-------------+ TIMEOUT +------------+ |		| +-------------+ EVE_ENTRY_EXPIRE +------------+ |
	| | |(2nd DETECTION_TIMEOUT) | | |		| | |(2nd DETECTION_TIMEOUT) | | |
	\----| DETECTION ------------------------>| RECOVERY ----/		\----| DETECTION ------------------------>| RECOVERY ----/
	| | | |		| | | |
	+-------------+ +------------+		+-------------+ +------------+
	EVE_DATA_LEASEQUERY|		EVE_DATA_LEASEQUERY|
	/----------\ (+ 2x DETECTION) |		/----------\ (+ 2x DETECTION) |
	EVE_DHCP_RENEW| | |		EVE_DHCP_RENEW| | |
	EVE_DHCP_REBIND| +-----v-------+ |		EVE_DHCP_REBIND| +-----v-------+ |
	| | | |		| | | |
	\----| BOUND |<----------/		\----| BOUND |<----------/
	| |		| |
	+-------------+		+-------------+
	Figure 14: Diagram of Transit		Figure 14: Diagram of Transit
	LQ_DELAY: MAX_LEASEQUERY_DELAY		LQ_DELAY: MAX_LEASEQUERY_DELAY
	8. Filtering Specification		8. Filtering Specification
	This section specifies how to use bindings to filter out spoofing		This section specifies how to use bindings to filter out packets with
	packets.		spoofed source addresses.
	Filtering policies are different for data packets and control		Filtering policies are different for data packets and control
	packets. DHCP and NDP (Neighbor Discovery Protocol) [RFC4861]		packets. DHCP, ARP, and NDP (Neighbor Discovery Protocol) [RFC4861]
	messages that may cause state transit are classified as control		messages are classified as control packets. All other packets are
	packet. Neighbor Advertisement (NA) and ARP Reply are also included
	in control packet because the Target Address of NA and ARP Reply
	should be checked to prevent spoofing. All other packets are
	classified as data packets.		classified as data packets.
	8.1. Data Packet Filtering		8.1. Data Packet Filtering
	Data packets from attachments with the Validating attribute MUST be		Data packets from attachments with the Validating attribute MUST be
	checked.		checked.
	Packet whose source IP address is a link-local address will not be		Packet whose source IP address is a link-local address will not be
	checked. Note: as explained in Section 1, a SAVI solution for link-		checked. Note: as explained in Section 1, a SAVI solution for link-
	local addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to		local addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to
	check packets with link-local source address.		check packets with link-local source address.
	If the source IP address of a packet is not a link-local address, but		If the source IP address of a packet is not a link-local address, but
	there is not a matched entry in BST with state BOUND, this packet		there is not a matched entry in BST with state BOUND, this packet
	MUST be discarded. However, the packet may trigger Data Snooping		MUST be discarded. However, the packet may trigger the Data Snooping
	Process Section 7 if Data-Snooping attribute is set on the		Process Section 7 if the Data-Snooping attribute is set on the
	attachment.		attachment.
	Data packets from attachments with no attribute will forwarded		Data packets from attachments with no attribute will forwarded
	without checking.		without being validated.
	The SAVI device MAY record any violation.		The SAVI device MAY log packets that fail source address validation.
	8.2. Control Packet Filtering		8.2. Control Packet Filtering
	For attachments with the Validating attribute:		For attachments with the Validating attribute:
	DHCPv4 Client-Server messages where source IP address is neither all		DHCPv4 Client-Server messages in which the source IP address is
	zeros nor bound with the corresponding binding anchor in the BST MUST		neither all zeros nor bound with the corresponding binding anchor in
	be discarded.
	DHCPv6 Client-Server messages where source IP address is neither a
	link-local address nor bound with the corresponding binding anchor in
	the BST MUST be discarded.		the BST MUST be discarded.
	NDP messages where source IP address is neither a link-local address		DHCPv6 Client-Server messages in which the source IP address is
	nor bound with the corresponding binding anchor MUST be discarded.		neither a link-local address nor bound with the corresponding binding
			anchor in the BST MUST be discarded.
	NA messages where target address is neither a link-local address nor		NDP messages in which the source IP address is neither a link-local
	bound with the corresponding binding anchor MUST be discarded.		address nor bound with the corresponding binding anchor MUST be
			discarded.
	ARP messages where protocol is IP and sender protocol address is		NA messages in which the target address is neither a link-local
	neither all zeros address nor bound with the corresponding binding		address nor bound with the corresponding binding anchor MUST be
			discarded.
			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.		anchor MUST be discarded.
	ARP Reply messages where target protocol address is not bound with		ARP Reply messages in which the target protocol address is not bound
	the corresponding binding anchor MUST be discarded.		with the corresponding binding anchor MUST be discarded.
	For attachments with other attributes:		For attachments with other attributes:
	DHCP Server-Client messages not from attachments with the DHCP-Trust		DHCP Server-to-Client messages not from attachments with the DHCP-
	attribute or Trust attribute MUST be discarded.		Trust attribute or Trust attribute MUST be discarded.
	For attachments with no attribute:		For attachments with no attribute:
	DHCP Server-Client messages from such attachments MUST be discarded.		DHCP Server-to-Client messages from such attachments MUST be
			discarded.
	The SAVI device MAY record any violation.		The SAVI device MAY record any messages that are discarded.
	9. State Restoration		9. State Restoration
	If a SAVI device reboots, the information kept in volatile memory		If a SAVI device reboots, the information kept in volatile memory
	will be lost. This section specifies the restoration of attribute		will be lost. This section specifies the restoration of attribute
	configuration and BST.		configuration and BST.
	9.1. Attribute Configuration Restoration		9.1. Attribute Configuration Restoration
	The loss of attribute configuration will not break the network: no		The loss of attribute configuration will not break the network: no
	skipping to change at page 38, line 36 ¶		skipping to change at page 41, line 36 ¶
	Denial of Services attack against the SAVI device itself, the		Denial of Services attack against the SAVI device itself, the
	Data Snooping Process MUST be rate limited. A constant		Data Snooping Process MUST be rate limited. A constant
	DATA_SNOOPING_INTERVAL is used to control the frequency. Two		DATA_SNOOPING_INTERVAL is used to control the frequency. Two
	Data Snooping Processes on one attachment MUST have a minimum		Data Snooping Processes on one attachment MUST have a minimum
	interval time DATA_SNOOPING_INTERVAL. This constant SHOULD be		interval time DATA_SNOOPING_INTERVAL. This constant SHOULD be
	configured prudently to avoid Denial of Service attacks.		configured prudently to avoid Denial of Service attacks.
	(2) The Data Snooping Process may set up wrong bindings if the		(2) The Data Snooping Process may set up wrong bindings if the
	clients do not reply to the detection probes. An attack will		clients do not reply to the detection probes. An attack will
	pass the duplicate detection if the client assigned the target		pass the duplicate detection if the client assigned the target
	address does not reply to the detection probes. The DHCP		address does not reply to the detection probes. The DHCP Lease
	Leasequery procedure performed by the SAVI device just tells		query procedure performed by the SAVI device just tells whether
	whether the address is assigned in the network or not. However,		the address is assigned in the network or not. However, the SAVI
	the SAVI device cannot determine whether the address is just		device cannot determine whether the address is just assigned to
	assigned to the triggering attachment from the DHCP Leasequery		the triggering attachment from the DHCP LEASEQUERY Reply.
	Reply.
	11.2. Issues about Leaving Clients		11.2. Client departure issues
	After a binding is set up, the corresponding client may leave its		After a binding is set up, the corresponding client may leave its
	attachment point. It may leave temporarily due to link flapping, or		attachment point. It may depart temporarily due to signal fade, or
	permanently by moving to a new attachment point or leaving the		permanently by moving to a new attachment point or leaving the
	network. Since the client may return shortly, the binding should be		network. In the signal fade case, since the client may return
	kept, or legitimate traffic from the client will be blocked.		shortly, the binding should be kept momentarily, lest legitimate
	However, if the client leaves permanently, it may be insecure to keep		traffic from the client be blocked. However, if the client leaves
	the binding. If the binding anchor is a property of the attachment		permanently, keeping the binding can be a security issue. If the
	point rather than the client, e.g., the switch port, an attacker		binding anchor is a property of the attachment point rather than the
	which is attached to the attachment point of the leaving client can		client, e.g., the switch port but not incorporating the MAC Address,
	send spoofing packets with the addresses assigned to the client.		an attacker using the same binding anchor can send packets using IP
	Even if the binding anchor is a property of the client, it is a waste		addresses assigned to the client. Even if the binding anchor is a
	of binding resources to keep bindings for departed clients.		property of the client, retaining binding state for a departed client
			for a long time is a waste of resources.
	SAVI-DHCP handles the leaving of directly attached clients. Whenever		Whenever a direct client departs from the network, a link-down event
	a direct client leaves, a link-down event associated with the binding		associated with the binding anchor will be triggered. SAVI-DHCP
	anchor will be triggered. SAVI-DHCP monitors such events, and		monitors such events, and performs the following mechanism.
	perform the following mechanism.
	(1) Whenever a client with the Validating attribute leaves, a timer		(1) Whenever a client with the Validating attribute leaves, a timer
	of duration OFFLINK_DELAY is set on the corresponding binding		of duration OFFLINK_DELAY is set on the corresponding binding
	entries.		entries.
	(2) If a DAD Neighbor Solicitation/Gratuitous ARP request is		(2) If a DAD Neighbor Solicitation/Gratuitous ARP request is
	received that targets the address during OFFLINK_DELAY, the entry		received that targets the address during OFFLINK_DELAY, the entry
	MAY be removed.		MAY be removed.
	(3) If the client returns on-link during OFFLINK_DELAY, cancel the		(3) If the client returns on-link during OFFLINK_DELAY, cancel the
	timer.		timer.
	In this way, the bindings of a departing client are kept for		In this way, the bindings of a departing client are kept for
	OFFLINK_DELAY. In case of link flapping, the client will not be		OFFLINK_DELAY. In case of link flapping, the client will not be
	blocked. If the client leaves permanently, the bindings will be		blocked. If the client leaves permanently, the bindings will be
	removed after OFFLINK_DELAY.		removed after OFFLINK_DELAY.
	SAVI-DHCP does not handle the leaving of indirect clients, because it		SAVI-DHCP does not handle the departure of indirect clients, because
	will not be notified of such events. Then the threats illustrated at		it will not be notified of such events. Switches supporting indirect
	the beginning of this section will be introduced. If SAVI-DHCP is		attachment (e.g., through a separate non-SAVI switch) SHOULD use
	enabled on indirect DHCP clients, this problem should be well		information specific to the client such as its MAC address as part of
	understood.		the binding anchor.
	11.3. Duplicate Bindings to the Same Address		11.3. Duplicate Bindings to the Same Address
	The same address may be bound to multiple binding anchors only if the		The same address may be bound to multiple binding anchors only if the
	binding setup processes successfully complete for each binding		binding setup processes successfully complete for each binding
	anchor. This mechanism is designed to address the case where a		anchor. This mechanism is designed to address the case where a
	client moves on the local link, and the case where a client has		client moves on the local link, and the case where a client has
	multiple attachments to a SAVI device.		multiple attachments to a SAVI device.
	There are two security issues with such a design:		There are two security issues with such a design:
	skipping to change at page 40, line 11 ¶		skipping to change at page 43, line 10 ¶
	Second, in the local link movement scenario, the former binding may		Second, in the local link movement scenario, the former binding may
	not be removed and it can be used by an attacker sharing the same		not be removed and it can be used by an attacker sharing the same
	binding anchor. For example, when a switch port is used as binding		binding anchor. For example, when a switch port is used as binding
	anchor and the port is shared by an attacker and a client with a hub,		anchor and the port is shared by an attacker and a client with a hub,
	the attacker can make use of the address assigned to the client after		the attacker can make use of the address assigned to the client after
	the client leaves.		the client leaves.
	11.4. Compatibility with DNA (Detecting Network Attachment)		11.4. Compatibility with DNA (Detecting Network Attachment)
	DNA [RFC4436] [RFC6059] is designed to decrease the handover latency		DNA [RFC4436][RFC6059] is designed to decrease the handover latency
	after re-attachment to the same network. DNA mainly relies on		after re-attachment to the same network. DNA mainly relies on
	performing reachability test by sending unicast Neighbor		performing reachability test by sending unicast Neighbor Solicitation
	Solicitation/Router Solicitation/ARP Request message to determine		/Router Solicitation/ARP Request message to determine whether a
	whether a previously configured address is still valid.		previously configured address is still valid.
	Although DNA provides optimization for clients, there is insufficient		Although DNA provides optimization for clients, there is insufficient
	information for this mechanism to migrate the previous binding or		information for this mechanism to migrate the previous binding or
	establish a new binding. If a binding is set up only by snooping the		establish a new binding. If a binding is set up only by snooping the
	reachability test message, the binding may be invalid. For example,		reachability test message, the binding may be invalid. For example,
	an attacker can perform reachability test with an address bound to		an attacker can perform reachability test with an address bound to
	another client. If binding is migrated to the attacker, the attacker		another client. If binding is migrated to the attacker, the attacker
	can successfully obtain the binding from the victim. Because this		can successfully obtain the binding from the victim. Because this
	mechanism wouldn't set up a binding based on snooping the DNA		mechanism wouldn't set up a binding based on snooping the DNA
	procedure, it cannot achieve perfect compatibility with DNA.		procedure, it cannot achieve perfect compatibility with DNA.
	skipping to change at page 41, line 33 ¶		skipping to change at page 44, line 33 ¶
	possible (i.e., as soon as the state for a given address is back to		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		NO_BIND), except where there is an identified reason why that
	information is likely to be involved in the detection, prevention, or		information is likely to be involved in the detection, prevention, or
	tracing of actual source address spoofing. Information about the		tracing of actual source address spoofing. Information about the
	majority of hosts that never spoof SHOULD NOT be logged.		majority of hosts that never spoof SHOULD NOT be logged.
	12. IANA Considerations		12. IANA Considerations
	This memo asks the IANA for no new parameters.		This memo asks the IANA for no new parameters.
	Note to RFC Editor: This section will have served its purpose if it
	correctly tells IANA that no new assignments or registries are
	required, or if those assignments or registries are created during
	the RFC publication process. From the authors' perspective, it may
	therefore be removed upon publication as an RFC at the RFC Editor's
	discretion.
	13. Acknowledgment		13. Acknowledgment
	Special thanks to Jean-Michel Combes, Christian Vogt, Joel M.		Special thanks to Jean-Michel Combes, Christian Vogt, Joel M.
	Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn		Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn
	Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto		Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto
	Garcia for careful review and valuation comments on the mechanism and		Garcia for careful review and valuation comments on the mechanism and
	text.		text.
	Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David		Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David
	Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi		Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi
	Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for		Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for
	their valuable contributions.		their valuable contributions.
	This document was generated using the xml2rfc tool.		This document was generated using the xml2rfc tool.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
			[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
			converting network protocol addresses to 48.bit Ethernet
			address for transmission on Ethernet hardware", STD 37,
			RFC 826, November 1982.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
	"Source Address Validation Improvement (SAVI) Framework",		2131, March 1997.
	RFC 7039, October 2013.
	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
	and M. Carney, "Dynamic Host Configuration Protocol for		and M. Carney, "Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6)", RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC		[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
	2131, March 1997.		Protocol (DHCP) Leasequery", RFC 4388, February 2006.
	[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS		[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
	SAVI: First-Come, First-Served Source Address Validation		Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
	Improvement for Locally Assigned IPv6 Addresses", RFC
	6620, May 2012.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting		[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
	Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.		"DHCPv6 Leasequery", RFC 5007, September 2007.
			[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
			July 2008.
	[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for		[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
	Detecting Network Attachment in IPv6", RFC 6059, November		Detecting Network Attachment in IPv6", RFC 6059, November
	2010.		2010.
	[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or		[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
	converting network protocol addresses to 48.bit Ethernet		SAVI: First-Come, First-Served Source Address Validation
	address for transmission on Ethernet hardware", STD 37,		Improvement for Locally Assigned IPv6 Addresses", RFC
	RFC 826, November 1982.		6620, May 2012.
	[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
	July 2008.
	[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
	"DHCPv6 Leasequery", RFC 5007, September 2007.
	[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration		14.2. Informative References
	Protocol (DHCP) Leasequery", RFC 4388, February 2006.
	[I-D.ietf-opsec-dhcpv6-shield]		[I-D.ietf-opsec-dhcpv6-shield]
	Gont, F., Will, W., and G. Velde, "DHCPv6-Shield:		Gont, F., Will, W., and G. Velde, "DHCPv6-Shield:
	Protecting Against Rogue DHCPv6 Servers", draft-ietf-		Protecting Against Rogue DHCPv6 Servers", draft-ietf-
	opsec-dhcpv6-shield-03 (work in progress), June 2014.		opsec-dhcpv6-shield-04 (work in progress), July 2014.
	[I-D.ietf-dhc-dhcpv4-over-dhcpv6]
	Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
	Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
	dhcpv4-over-dhcpv6-09 (work in progress), June 2014.
	14.2. Informative References		[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
			Defeating Denial of Service Attacks which employ IP Source
			Address Spoofing", BCP 38, RFC 2827, May 2000.
	[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol		[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
	(DHCP) Service for IPv6", RFC 3736, April 2004.		(DHCP) Service for IPv6", RFC 3736, April 2004.
	[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
	Defeating Denial of Service Attacks which employ IP Source		"Source Address Validation Improvement (SAVI) Framework",
	Address Spoofing", BCP 38, RFC 2827, May 2000.		RFC 7039, October 2013.
	[BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF		[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
	Internet draft (work in progress), November 2007.		Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC
			7341, August 2014.
	Authors' Addresses		Authors' Addresses
	Jun Bi		Jun Bi
	Tsinghua University		Tsinghua University
	Network Research Center, Tsinghua University		Network Research Center, Tsinghua University
	Beijing 100084		Beijing 100084
	China		China
	EMail: junbi@tsinghua.edu.cn		EMail: junbi@tsinghua.edu.cn
End of changes. 224 change blocks.
	918 lines changed or deleted		1085 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/