< draft-ietf-savi-dhcp-23.txt		draft-ietf-savi-dhcp-24.txt >
	SAVI J. Bi		SAVI J. Bi
	Internet-Draft J. Wu		Internet-Draft J. Wu
	Intended status: Standards Track G. Yao		Intended status: Standards Track G. Yao
	Expires: October 11, 2014 Tsinghua Univ.		Expires: November 6, 2014 Tsinghua Univ.
	F. Baker		F. Baker
	Cisco		Cisco
	April 9, 2014		May 5, 2014
	SAVI Solution for DHCP		SAVI Solution for DHCP
	draft-ietf-savi-dhcp-23		draft-ietf-savi-dhcp-24
	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 SAVI
	(Source Address Validation Improvements) device. The bindings set up		(Source Address Validation Improvements) device. The bindings set up
	by this procedure can be used to filter out packets with forged		by this procedure can be used to filter out packets with forged
	source IP address in DHCP scenario. This mechanism is proposed as a		source IP address in DHCP scenario. This mechanism is proposed as a
	complement to ingress filtering to provide finer-grained source IP		complement to ingress filtering to provide finer-grained source IP
	address validation.		address validation.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 October 11, 2014.		This Internet-Draft will expire on November 6, 2014.
	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
	skipping to change at page 3, line 44 ¶		skipping to change at page 3, line 44 ¶
	6.4.2. From INIT_BIND to Other States . . . . . . . . . . . . 21		6.4.2. From INIT_BIND to Other States . . . . . . . . . . . . 21
	6.4.2.1. Trigger Events . . . . . . . . . . . . . . . . . . 21		6.4.2.1. Trigger Events . . . . . . . . . . . . . . . . . . 21
	6.4.2.2. Following Actions . . . . . . . . . . . . . . . . 22		6.4.2.2. Following Actions . . . . . . . . . . . . . . . . 22
	6.4.3. From BOUND to Other States . . . . . . . . . . . . . . 24		6.4.3. From BOUND to Other States . . . . . . . . . . . . . . 24
	6.4.3.1. Trigger Events . . . . . . . . . . . . . . . . . . 24		6.4.3.1. Trigger Events . . . . . . . . . . . . . . . . . . 24
	6.4.3.2. Following Actions . . . . . . . . . . . . . . . . 24		6.4.3.2. Following Actions . . . . . . . . . . . . . . . . 24
	6.5. Table of State Machine . . . . . . . . . . . . . . . . . . 25		6.5. Table of State Machine . . . . . . . . . . . . . . . . . . 25
	7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 26		7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 26
	7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 26		7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 26
	7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 27		7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.3. Additional Binding States Description . . . . . . . . . . 28		7.3. Additional Binding States Description . . . . . . . . . . 27
	7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 28		7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	7.5. State Machine of Binding Recovery Process . . . . . . . . 29		7.5. State Machine of Binding Recovery Process . . . . . . . . 29
	7.5.1. From NO_BIND to DETECTION . . . . . . . . . . . . . . 29		7.5.1. From NO_BIND to DETECTION . . . . . . . . . . . . . . 29
	7.5.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 29		7.5.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 29
	7.5.1.2. Following Actions . . . . . . . . . . . . . . . . 29		7.5.1.2. Following Actions . . . . . . . . . . . . . . . . 29
	7.5.2. From DETECTION to Other States . . . . . . . . . . . . 30		7.5.2. From DETECTION to Other States . . . . . . . . . . . . 30
	7.5.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 30		7.5.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 30
	7.5.2.2. Following Actions . . . . . . . . . . . . . . . . 30		7.5.2.2. Following Actions . . . . . . . . . . . . . . . . 30
	7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 31		7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 31
	7.5.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 31		7.5.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 31
	7.5.3.2. Following Actions . . . . . . . . . . . . . . . . 31		7.5.3.2. Following Actions . . . . . . . . . . . . . . . . 31
	7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 32		7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 32
	7.5.4.1. Trigger Event . . . . . . . . . . . . . . . . . . 33		7.5.4.1. Trigger Event . . . . . . . . . . . . . . . . . . 32
	7.5.4.2. Following Action . . . . . . . . . . . . . . . . . 33		7.5.4.2. Following Action . . . . . . . . . . . . . . . . . 33
	7.6. Table of State Machine . . . . . . . . . . . . . . . . . . 33		7.6. Table of State Machine . . . . . . . . . . . . . . . . . . 33
	8. Filtering Specification . . . . . . . . . . . . . . . . . . . 34		8. Filtering Specification . . . . . . . . . . . . . . . . . . . 34
	8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 35		8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 35
	8.2. Control Packet Filtering . . . . . . . . . . . . . . . . . 35		8.2. Control Packet Filtering . . . . . . . . . . . . . . . . . 35
	9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 36		9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 36
	9.1. Attribute Configuration Restoration . . . . . . . . . . . 36		9.1. Attribute Configuration Restoration . . . . . . . . . . . 36
	9.2. Binding State Restoration . . . . . . . . . . . . . . . . 36		9.2. Binding State Restoration . . . . . . . . . . . . . . . . 36
	10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 37		10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 37		11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	skipping to change at page 8, line 36 ¶		skipping to change at page 8, line 36 ¶
	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 DAD or ARP message intended to detect a		Detection message: a Neighbor Solicitation or ARP message intended to
	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
			binding the triggered by CONFIRM but LQ cannot be performed by the
			SAVI device to 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		A list of essential elements in a SAVI-DHCP deployment scenario is
	given as follows:		given as follows:
	(1) DHCP server		(1) DHCP server
	skipping to change at page 22, line 36 ¶		skipping to change at page 22, line 36 ¶
	IA and ignore any messages that indicate a NotOnLink status."		IA and ignore any messages that indicate a NotOnLink status."
	[RFC3315]).		[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		2.1 If there are no IA options in the Reply message, the DHCP Reply
	message is in response to a Confirm message. The state of the		message is in response to a Confirm message. The state of the
	binding entries with matched TID is changed to BOUND. Because		binding entries with matched TID is changed to BOUND. Because
	[RFC3315] does not require lease time of addresses to be contained in		[RFC3315] does not require lease time of addresses to be contained in
	the Reply message, the SAVI device MUST send a LEASEQUERY [RFC5007]		the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007]
	message querying by IP address to All_DHCP_Servers multicast address		message querying by IP address to All_DHCP_Servers multicast address
	[RFC3315] or a list of configured DHCP server addresses. The		[RFC3315] or a list of configured DHCP server addresses. The
	Leasequery message is generated for each IP address if multiple		Leasequery message is generated for each IP address if multiple
	addresses are confirmed. The Lifetime of corresponding entries is		addresses are confirmed. The Lifetime of corresponding entries is
	set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after		set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after
	MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example		MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example
	of the entries is illustrated in Figure 6. The related security		of the entries is illustrated in Figure 6. The related security
	problem about DHCPv6 LEASEQUERY is discussed in Section 11.5.		problem about DHCPv6 LEASEQUERY is discussed in Section 11.5. If the
			SAVI device does not send the LEASEQUERY message, a pre-configured
			lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry.
	2.2 If there are IA options in the Reply message, the SAVI device		2.2 If there are IA options in the Reply message, the SAVI device
	checks each IA option. When the first assigned address is found, the		checks each IA option. When the first assigned address is found, the
	Address field of the binding entry with matched TID is set to the		Address field of the binding entry with matched TID is set to the
	address. The Lifetime field is set to the sum of the lease time in		address. The Lifetime field is set to the sum of the lease time in
	Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed		Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed
	to BOUND. If there are more than one address assigned in the		to BOUND. If there are more than one address assigned in the
	message, new binding entries are set up for the remaining address		message, new binding entries are set up for the remaining address
	assigned in the IA options. An example of the entries is illustrated		assigned in the IA options. An example of the entries is illustrated
	in Figure 7. SAVI devices do not specially process IA options with		in Figure 7. SAVI devices do not specially process IA options with
	skipping to change at page 27, line 36 ¶		skipping to change at page 27, line 36 ¶
	exceptions. For example, if the implementation is to be used in		exceptions. For example, if the implementation is to be used in
	networks with tree topology and without host local-link movement,		networks with tree topology and without host local-link movement,
	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.
	To perform this process, the SAVI device MUST join the Solicited Node
	Multicast group of the source address of triggering IPv6 data packet
	whenever performing duplicate detection.
	7.2. Rationale		7.2. Rationale
	This process makes use of DAD/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 Section 6.2, new states used in this process are
	skipping to change at page 29, line 38 ¶		skipping to change at page 29, line 28 ¶
	7.5.1.2. Following Actions		7.5.1.2. Following Actions
	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 can 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 be source address of the packet. Set the State field to
	DETECTION. Set the Lifetime of the created entry to 2*DAD_TIMEOUT.		DETECTION. Set the Lifetime of the created entry to
			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
	[RFC826]or a ARP probe [RFC5227] on the address; if there is no		[RFC826]or a ARP probe [RFC5227] on the address; if there is no
	response message after DAD_TIMEOUT, send another ARP Request or		response message after DETECTION_TIMEOUT, send another ARP
	ARP probe;		Request or ARP probe;
	(2) IPv6 address: perform Duplicate Address Detection (DAD)		(2) IPv6 address: send a Neighbor Solicitation message [RFC4861]
	[RFC4862] on the address; if there is no response message after		targeting on the address; if there is no response message after
	DAD_TIMEOUT, perform another DAD procedure.		DETECTION_TIMEOUT, send another Neighbor Solicitation message.
	Because the delivery of detection message is unreliable, the		Because the delivery of 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 messages MUST NOT be sent to the attachment from which the
	triggering packet is received.		triggering packet is received.
	The packet which triggers this event SHOULD be discarded.		The packet which triggers this event SHOULD be discarded.
			This local conflict process SHOULD be performed. If it is not
			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
			in the following section will be performed directly.
	An example of the entry is illustrated in Figure 10.		An example of the entry is illustrated in Figure 10.
	+---------+-------+---------+-----------------------+-------+		+---------+-------+---------+-----------------------+-------+
	| Anchor |Address| State | Lifetime |TID |		| Anchor |Address| State | Lifetime |TID |
	+---------+-------+---------+-----------------------+-------+		+---------+-------+---------+-----------------------+-------+
	| Port_1 | Addr1 |DETECTION|2*DAD_TIMEOUT | |		| Port_1 | Addr1 |DETECTION|2*DETECTION_TIMEOUT | |
	+---------+-------+---------+-----------------------+-------+		+---------+-------+---------+-----------------------+-------+
	Figure 10: Binding entry in BST on data triggered initialization		Figure 10: Binding entry in BST on data triggered initialization
	7.5.2. From DETECTION to Other States		7.5.2. From DETECTION to Other States
	7.5.2.1. Trigger Event		7.5.2.1. Trigger Event
	Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_CONFLICT.		Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_CONFLICT.
	skipping to change at page 31, line 43 ¶		skipping to change at page 31, line 37 ¶
	7.5.3.2. Following Actions		7.5.3.2. Following Actions
	If the trigger event is EVE_DATA_LEASEQUERY:		If the trigger event is EVE_DATA_LEASEQUERY:
	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 DAD_TIMEOUT, send another ARP Request. If		no response after DETECTION_TIMEOUT, send another ARP Request.
	there is still no response, the following actions will not be		If there is still no response, the following actions will not be
	performed. If there is only one identical response, get the		performed. If there is only one identical response, get the
	sender hardware address. Check if the 'chaddr' field (hardware		sender hardware address. Check if the 'chaddr' field (hardware
	address) of the DHCPLEASEACTIVE message matches the sender		address) of the DHCPLEASEACTIVE message matches the sender
	hardware address. If the two addresses do not match, the		hardware address. If the two addresses do not match, the
	following actions will not be performed. If there is more than		following actions will not be performed. If there is more than
	one response, if any of the sender hardware addresses matches		one response, if any of the sender hardware addresses matches
	the 'chaddr' field (hardware address) of the DHCPLEASEACTIVE		the 'chaddr' field (hardware address) of the DHCPLEASEACTIVE
	message, the following actions are to be performed.		message, the following actions are to be performed.
	(2) Change the state of the corresponding binding to BOUND. Set		(2) Change the state of the corresponding binding to BOUND. Set
	life time to the sum of the value encoded in IP Address Lease		life time to the sum of the value encoded in IP Address Lease
	Time option of the DHCPLEASEACTIVE message and		Time option of the DHCPLEASEACTIVE message and
	MAX_DHCP_RESPONSE_TIME. Erase the TID field.		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 DAD_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.		the following actions will not be performed.
	(2) Change the state of the corresponding binding to BOUND. Set the		(2) Change the state of the corresponding binding to BOUND. Set the
	lifetime to the sum of the valid lifetime extracted from		lifetime to the sum of the valid lifetime extracted from
	OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message and		OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message and
	MAX_DHCP_RESPONSE_TIME. Erase the TID field.		MAX_DHCP_RESPONSE_TIME. Erase the TID field.
	(3) After the above checks, if multiple addresses are specified in		(3) After the above checks, if multiple addresses are specified in
	the LEASEQUERY-REPLY message and there are no corresponding		the LEASEQUERY-REPLY message and there are no corresponding
	skipping to change at page 34, line 11 ¶		skipping to change at page 34, line 11 ¶
	REBIND: EVE_DHCP_REBIND		REBIND: EVE_DHCP_REBIND
	Timeout: EVE_ENTRY_EXPIRE		Timeout: EVE_ENTRY_EXPIRE
	+-------------+		+-------------+
	| |		| |
	/---------| NO_BIND |<--------\		/---------| NO_BIND |<--------\
	| ------>| | | TIMEOUT		| ------>| | | TIMEOUT
	| | +-------------+ |(2nd LQ_DELAY)		| | +-------------+ |(2nd LQ_DELAY)
	EVE_DATA_UNMATCH | | |		EVE_DATA_UNMATCH | | |
	| | |		| | |
	| | |		1st | | |
	1st DAD_TIMEOUT | | | 1st LQ_DELAY		DETECTION_TIMEOUT | | | 1st LQ_DELAY
	/------\ | | | /---------\		/------\ | | | /---------\
	| | | | EVE_DATA_CONFLICT | | |		| | | | EVE_DATA_CONFLICT | | |
	| v v | | v |		| v v | | v |
	| +-------------+ TIMEOUT +------------+ |		| +-------------+ TIMEOUT +------------+ |
	| | | (2nd DAD_TIMEOUT) | | |		| | |(2nd DETECTION_TIMEOUT) | | |
	\----| DETECTION ------------------------>| RECOVERY ----/		\----| DETECTION ------------------------>| RECOVERY ----/
	| | | |		| | | |
	+-------------+ +------------+		+-------------+ +------------+
	EVE_DATA_LEASEQUERY|		EVE_DATA_LEASEQUERY|
	/----------\ (+ 2x DAD) |		/----------\ (+ 2x DETECTION) |
	EVE_DHCP_RENEW| | |		EVE_DHCP_RENEW| | |
	EVE_DHCP_REBIND| +-----v-------+ |		EVE_DHCP_REBIND| +-----v-------+ |
	| | | |		| | | |
	\----| BOUND |<----------/		\----| BOUND |<----------/
	| |		| |
	+-------------+		+-------------+
	Figure 13: Diagram of Transit		Figure 13: Diagram of Transit
	LQ_DELAY: MAX_LEASEQUERY_DELAY		LQ_DELAY: MAX_LEASEQUERY_DELAY
	skipping to change at page 37, line 15 ¶		skipping to change at page 37, line 15 ¶
	10. Constants		10. Constants
	MAX_DHCP_RESPONSE_TIME 120s		MAX_DHCP_RESPONSE_TIME 120s
	DATA_SNOOPING_INTERVAL 60s and configurable		DATA_SNOOPING_INTERVAL 60s and configurable
	MAX_LEASEQUERY_DELAY 10s		MAX_LEASEQUERY_DELAY 10s
	OFFLINK_DELAY 30s		OFFLINK_DELAY 30s
	DAD_TIMEOUT 0.5s		DETECTION_TIMEOUT 0.5s
	11. Security Considerations		11. Security Considerations
	11.1. Security Problems about the Data Snooping Process		11.1. Security Problems about the Data Snooping Process
	There are two security problems about the Data Snooping Process		There are two security problems about the Data Snooping Process
	Section 7:		Section 7:
	(1) The Data Snooping Process is costly, but an attacker can trigger		(1) The Data Snooping Process is costly, but an attacker can trigger
	it simply through sending a number of data packets. To avoid		it simply through sending a number of data packets. To avoid
	skipping to change at page 42, line 34 ¶		skipping to change at page 42, line 34 ¶
	[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration		[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
	Protocol (DHCP) Leasequery", RFC 4388, February 2006.		Protocol (DHCP) Leasequery", RFC 4388, February 2006.
	[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting		[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
	Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.		Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
	[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.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, September 2007.
	[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,		[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
	"DHCPv6 Leasequery", RFC 5007, September 2007.		"DHCPv6 Leasequery", RFC 5007, September 2007.
	[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,		[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
	July 2008.		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,		Detecting Network Attachment in IPv6", RFC 6059,
	November 2010.		November 2010.
End of changes. 23 change blocks.
	33 lines changed or deleted		38 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/