< draft-bi-savi-wlan-22.txt		draft-bi-savi-wlan-23.txt >
	Source Address Validation Improvements (SAVI) J. Bi		Source Address Validation Improvements (SAVI) J.B. Bi
	Internet-Draft J. Wu		Internet-Draft J.W. Wu
	Intended status: Standards Track Tsinghua University		Intended status: Standards Track Tsinghua University
	Expires: May 14, 2022 T. Lin		Expires: 12 November 2022 T.L. Lin
	New H3C Technologies Co. Ltd		New H3C Technologies Co. Ltd
	Y. Wang		Y.W. Wang
	L. He		L.H. He
	Tsinghua University		Tsinghua University
	November 10, 2021		11 May 2022
	A SAVI Solution for WLAN		A SAVI Solution for WLAN
	draft-bi-savi-wlan-22		draft-bi-savi-wlan-23
	Abstract		Abstract
	This document describes a source address validation solution for		This document describes a source address validation solution for
	WLANs where 802.11i or other security mechanisms are enabled to		WLANs where 802.11i or other security mechanisms are enabled to
	secure MAC addresses. This mechanism snoops NDP and DHCP packets to		secure MAC addresses. This mechanism snoops NDP and DHCP packets to
	bind IP addresses to MAC addresses, and relies on the security of MAC		bind IP addresses to MAC addresses, and relies on the security of MAC
	addresses guaranteed by 802.11i or other mechanisms to filter IP		addresses guaranteed by 802.11i or other mechanisms to filter IP
	spoofing packets. It can work in the special situations described in		spoofing packets. It can work in the special situations described in
	the charter of SAVI (Source Address Validation Improvements)		the charter of SAVI (Source Address Validation Improvements)
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 May 14, 2022.		This Internet-Draft will expire on 12 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
	3. IP-MAC Binding . . . . . . . . . . . . . . . . . . . . . . . 4		3. IP-MAC Binding . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 4		3.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 4
	3.1.1. IP-MAC Mapping Table . . . . . . . . . . . . . . . . 4		3.1.1. IP-MAC Mapping Table . . . . . . . . . . . . . . . . 4
	3.1.2. MAC-IP Mapping Table . . . . . . . . . . . . . . . . 4		3.1.2. MAC-IP Mapping Table . . . . . . . . . . . . . . . . 4
	3.2. Pre-conditions for Binding . . . . . . . . . . . . . . . 4		3.2. Pre-conditions for Binding . . . . . . . . . . . . . . . 5
	3.3. Binding IP addresses to MAC addresses . . . . . . . . . . 5		3.3. Binding IP addresses to MAC addresses . . . . . . . . . . 5
	3.4. Binding Migration . . . . . . . . . . . . . . . . . . . . 5		3.4. Binding Migration . . . . . . . . . . . . . . . . . . . . 6
	3.5. Binding Clearing . . . . . . . . . . . . . . . . . . . . 5		3.5. Binding Clearing . . . . . . . . . . . . . . . . . . . . 6
	4. Source Address Validation . . . . . . . . . . . . . . . . . . 6		4. Source Address Validation . . . . . . . . . . . . . . . . . . 6
	5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 6		5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 7
	5.1. Centralized WLAN . . . . . . . . . . . . . . . . . . . . 7		5.1. Centralized WLAN . . . . . . . . . . . . . . . . . . . . 7
	5.1.1. AP Filtering . . . . . . . . . . . . . . . . . . . . 7		5.1.1. AP Filtering . . . . . . . . . . . . . . . . . . . . 7
	5.1.1.1. Candidate Binding . . . . . . . . . . . . . . . . 7		5.1.1.1. Candidate Binding . . . . . . . . . . . . . . . . 7
	5.1.1.2. Packet Filtering . . . . . . . . . . . . . . . . 7		5.1.1.2. Packet Filtering . . . . . . . . . . . . . . . . 8
	5.1.1.3. Negative Entries . . . . . . . . . . . . . . . . 8		5.1.1.3. Negative Entries . . . . . . . . . . . . . . . . 8
	5.1.1.4. CAPWAP Extension . . . . . . . . . . . . . . . . 8		5.1.1.4. CAPWAP Extension . . . . . . . . . . . . . . . . 9
	5.1.1.5. Mobility Solution . . . . . . . . . . . . . . . . 11		5.1.1.5. Mobility Solution . . . . . . . . . . . . . . . . 12
	5.1.2. AC Filtering . . . . . . . . . . . . . . . . . . . . 12		5.1.2. AC Filtering . . . . . . . . . . . . . . . . . . . . 12
	5.2. Autonomous WLAN . . . . . . . . . . . . . . . . . . . . . 12		5.2. Autonomous WLAN . . . . . . . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 13		7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	This document describes a mechanism to perform per packet IP source		This document describes a mechanism for performing per-packet IP
	address validation in WLAN. This mechanism performs ND snooping or		source address validation in wireless local area networks (WLANs).
	DHCP snooping to bind allocated IP addresses with authenticated MAC		The mechanism performs ND snooping or DHCP snooping to bind the
	addresses. Static addresses are bound to the MAC addresses of		assigned IP address to the verified MAC address. Static addresses
	corresponding hosts manually. Then the mechanism can check the		are manually bound to the MAC address of the corresponding host. The
	validity of the source IP addresses in local packets according to the		mechanism can then check the validity of the source IP address in the
	binding association. The security of MAC address is assured by		local packet against the binding association. The MAC address is
	802.11i or other mechanisms, thus the binding association is secure.		secured by 802.11i or other mechanisms, so the binding association is
			secure.
	IP-MAC binding table in control plane and MAC-IP binding table in		This mechanism utilizes two important data structures, the IP-MAC
	data plane are two important data structures, which are introduced in		mapping table on the control plane and the MAC-IP mapping table on
	detail in the document.		the data plane, to implement source address validation, which is
			described in detail in this document.
	The situation that one interface with multiple MAC addresses is a		The case of an interface with multiple MAC addresses is a special
	special case mentioned in the charter of SAVI. And this situation is		case mentioned in the SAVI charter and is the only special case that
	the only special case that challenges MAC-IP binding. The mechanism		challenges MAC-IP binding. The mechanism to handle this case is
	to handle this situation is specified in the document.		specified in the document.
	There are three deployment scenarios specified in this document. The		Three deployment scenarios for this mechanism are specified in this
	mechanism is deployed on different devices in different scenarios.		document, describing the devices and details of deployment in
	The deployment details are described in the document.		different scenarios.
	When hosts move from one access point to another, the migration of		When a host moves from one access point to another, the migration of
	binding entries may be triggered according to the specific mobility		binding entries can be triggered depending on the specific mobility
	scenario. The mechanism to handle host mobility is specified in the		scenario. The mechanism for handling host mobility is specified in
	document according to different deployment scenarios.		the documentation based on different deployment scenarios.
	1.1. Terminology		1.1. Terminology
	FIT Access Points: the name of Access Points in Centralized WLAN		FIT access points: The access points used in centralized WLAN
	deployment scenario.		deployment scenario.
	FAT Access Points: the name of Access Points in Autonomous WLAN		FAT access points: The access points used in autonomous WLAN
	deployment scenario.		deployment scenario.
			Binding anchor: A "binding anchor" is defined to be a physical and/or
			link-layer property of an attached device, as defined in [RFC7039].
			In this document, the binding anchor refers to th MAC address.
			Binding entry: A rule that associates an IP address with a binding
			anchor.
	Familiarity with SAVI-DHCP and its terminology, as defined in		Familiarity with SAVI-DHCP and its terminology, as defined in
	[RFC7513], is assumed.		[RFC7513], is assumed.
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. IP-MAC Binding		3. IP-MAC Binding
	This section specifies the operations for creating and clearing		This section specifies the operations for creating and clearing
	bindings between IP addresses and MAC addresses.		bindings between IP addresses and MAC addresses.
	3.1. Data Structures		3.1. Data Structures
			The binding relationship between IP address and MAC address is stored
			using two data structures, i.e., the IP-MAC mapping table and MAC-IP
			mapping table.
	3.1.1. IP-MAC Mapping Table		3.1.1. IP-MAC Mapping Table
	This table maps IP addresses to corresponding MAC addresses. IP		This table maps IP addresses to their corresponding MAC addresses.
	address is the index of the table. One IP address can only have one		The IP address is the index of the table. An IP address can have
	corresponding MAC address, while different IP addresses can be mapped		only one corresponding MAC address. Different IP addresses can be
	to the same MAC address.		mapped to the same MAC address.
	This table is used in the control process. Before creating new IP-		This table is used in the control process. Before creating a new IP-
	MAC bindings, this table must first be consulted in case of conflicts		MAC binding, this table must be queried to prevent conflicting
	in binding entries. Also, this table must be consulted before doing		binding entries. Also, this table must be queried before any packet
	any packet filtering. This table must be synchronized with the MAC-		filtering is performed. This table must be synchronized with the
	IP table specified in Section 3.1.2.		MAC-IP mapping table specified in Section 3.1.2.
	Each entry in IP-MAC mapping table must also record the binding state		Each entry in the IP-MAC mapping table must also record the binding
	of the IP address. The addresses snooped in DHCP address assignment		method of the IP address. Addresses snooped in the DHCP address
	procedure must record their state as "DHCPv6", and the addresses		assignment procedure must have their binding method recorded as
	snooped in Duplicate Address Detection procedure must record their		"DHCP", and addresses snooped in the Duplicate Address Detection
	state as "SLAAC".		procedure [RFC4862] must have their binding method recorded as
			"SLAAC".
	3.1.2. MAC-IP Mapping Table		3.1.2. MAC-IP Mapping Table
	This table maps MAC addresses to the corresponding IP addresses. MAC		This table maps MAC addresses to the corresponding IP addresses. The
	address is the index of the table. It is a one-to-many mapping		MAC address is the index of the table. It is a one-to-many mapping
	table, which means a MAC address can be mapped to multiple IP		table, which means a MAC address can be mapped to multiple IP
	addresses. Though multiple MAC addresses may exist on one interface,		addresses. Although multiple MAC addresses may exist on one
	these MAC addresses must be mapped to different IP addresses.		interface, these MAC addresses must be mapped to different IP
			addresses.
	This table is used for filtering. Different from wired network, MAC-		This table is used for filtering. Different from wired networks, the
	IP mapping table and IP-MAC mapping table can be maintained		MAC-IP mapping table and the IP-MAC mapping table can be maintained
	separately on different devices. Mechanisms for synchronization		separately on different devices. A synchronization mechanism must be
	between the two tables must be employed for the consistency of the		used between these two tables to ensure the consistency of the
	bindings. We will specify the details in Section 5 according to		bindings. We will explain the details in Section 5 for different
	different deployment scenarios.		deployment scenarios.
	3.2. Pre-conditions for Binding		3.2. Pre-conditions for Binding
	In the binding based mechanism, the security of IP address is based		As specified in [RFC7039], in a binding-based mechanism, the security
	on the security of the binding anchor. In WLAN, 802.11i or other		of IP address is dependent on the security of the binding anchor. In
	security mechanisms on link layer make MAC address a strong enough		WLANs, 802.11i or other link-layer security mechanisms make MAC
	binding anchor.		address a strong enough binding anchor.
	If MAC address has no protection, attackers can spoof MAC address to		If the MAC address is unprotected, an attacker can spoof the MAC
	succeed in validation.		address to pass validation successfully.
	3.3. Binding IP addresses to MAC addresses		3.3. Binding IP addresses to MAC addresses
	All the static IP-MAC address pairs are configured into the IP-MAC		All the static IP-MAC address pairs are configured into the IP-MAC
	Mapping Table with the mechanism enabled.		mapping table with the mechanism enabled.
	An individual procedure handles the binding of DHCP addresses to MAC		A separate procedure handles the binding of DHCP addresses to MAC
	addresses. This procedure snoops the DHCP address assignment process		addresses. This procedure snoops on the DHCP address assignment
	between attached hosts and DHCP server. DHCP snooping in WLANs is		process between the attached host and the DHCP server. DHCP snooping
	the same as that in wired networks specified in [RFC7513].		in WLANs is the same as that in wired networks specified in
			[RFC7513].
	An individual procedure handles the binding of stateless addresses to		A separate procedure handles the binding of stateless addresses to
	MAC addresses. This procedure snoops Address Resolution procedure		MAC addresses. This procedure snoops Duplicate Address Detection
	between attached hosts and neighbors as described in [RFC4861] or		procedure as described in [RFC4862] or Address Resolution procedure
	Duplicate Address Detection procedure as described in [RFC4862].		between attached hosts and neighbors as described in [RFC4861].
	Based on the principle of roaming experience first in WLAN, the new		Based on the principle of roaming experience first in WLAN, the new
	binding anchor is preferred, and removing the security connection of		binding anchor is selected in preference and triggers the deletion of
	the old binding anchor is triggered.		the secure connection of the old binding anchor.
	In some deployment scenarios, the functions of address snooping and		In some deployment scenarios, the functions of address snooping and
	IP-MAC table maintenance may also be separated onto different		IP-MAC mapping table maintenance may also be separated to different
	devices. Thus, to prevent conflicts in binding entries, the device		devices. Therefore, to prevent conflicting binding entries, the
	for address snooping must interact with the device that maintains the		device for address snooping must interact with the device that
	IP-MAC table. We will specify the details in Section 5.1.1.		maintains the IP-MAC mapping table. We will specify the details in
			Section 5.1.1.
	3.4. Binding Migration		3.4. Binding Migration
	Different from wired network, SAVI for WLAN must handle the migration		Different from wired networks, SAVI for WLAN must handle the
	of binding entries when a mobile host moves from one access point to		migration of binding entries when a mobile host moves from one access
	another. After the movement, the host will not perform another		point to another. After the move, the host will not perform another
	address allocation procedure to obtain new IP addresses, but continue		address configuration procedure to obtain new IP addresses but
	to use the existing IP address(es). Thus, binding entries in the		continue to use the existing IP address(es). Thus, binding entries
	foreign device that the mobile hosts access to cannot be established		in the foreign device accessed by mobile hosts cannot be established
	by snooping. A new mechanism is needed to correctly migrate the		by snooping. A new mechanism is needed to correctly migrate the
	binding entry related to the IP address of the mobile host from the		binding entry associated with the mobile host's IP address from the
	home device to the foreign device. If the host binds multiple		home device to the foreign device. If the host binds multiple
	entries, multiple entries will be migrated. For example, when the		entries, multiple entries will be migrated. For example, when the
	host is assigned multiple addresses, multiple binding entries will be		host is assigned multiple addresses, multiple binding entries will be
	generated, and these entries will be migrated. We will specify the		generated, and these entries will be migrated. We will specify the
	details in Section 5, according to different deployment scenarios.		details in Section 5 depending on different deployment scenarios.
	3.5. Binding Clearing		3.5. Binding Clearing
	Three kinds of events will trigger binding clearing:		Three kinds of events will trigger binding clearing:
	1. A host leaves explicitly this access point. The entries for all		1. A host leaves explicitly this access point. All entries in the
	related MAC addresses in MAC-IP table MUST be cleared.		MAC-IP mapping table associated with this MAC address MUST be
	2. A DHCP RELEASE message is received from the owner of the
	corresponding IP address. This IP entry in IP-MAC mapping table
	and the corresponding entries in MAC-IP mapping table MUST be
	cleared.		cleared.
	3. A timeout message of AC's client idle-time is received. The		2. A DHCP RELEASE message is received from the owner of the
	entries for all related MAC addresses in MAC-IP table MUST be		corresponding IP address. This IP entry in the IP-MAC mapping
	cleared.		table and the corresponding entries in the MAC-IP mapping table
			MUST be cleared.
			3. A timeout message of the AC's client idle-time is received. All
			entries in the MAC-IP mapping table related to the MAC address
			MUST be cleared.
	4. Source Address Validation		4. Source Address Validation
	This section describes source address validation procedure on		This section describes source address validation procedure for
	packets. In this procedure, all the frames are assumed to have		packets. In this procedure, all the frames are considered to have
	passed the verifications of 802.11i or other security mechanisms.		passed the verification of 802.11i or other security mechanisms.
	This procedure has the following steps:		This procedure has the following steps:
	1. Extract the IP source and MAC source from the frame. Lookup the		1. Extract the IP source address and MAC source address from the
	MAC address in the MAC-IP Mapping Table and check if the MAC-IP		frame. Look up the MAC address in the MAC-IP mapping table and
	pair exists. If yes, forward the packet. Otherwise, go to step		check if the MAC-IP pair exists. If exists, forward the packet.
	2.		Otherwise, go to step 2.
	2. Look up the IP address in the IP-MAC Mapping Table and check if		2. Look up the IP address in the IP-MAC mapping table and check if
	the IP address exists. If not, go to step 3. If yes, check		the IP address exists. If it does not exist, go to step 3. If it
	whether the MAC address in the entry is the same as that in the		exists, check whether the MAC address in the entry is the same as
	frame. If yes, forward the packet. Otherwise, drop the packet.		that in the frame. If so, forward the packet. Otherwise, drop
			the packet.
	In step 2, after the packet is judged to be valid and forwarded,		In step 2, after the packet is judged to be valid and forwarded,
	synchronization between the MAC-IP and IP-MAC mapping tables should		synchronization between the MAC-IP and IP-MAC mapping tables should
	be triggered. The MAC-IP binding of the packet should be		be triggered. The MAC-IP binding of the packet should be
	synchronized from IP-MAC mapping table to MAC-IP mapping table, and		synchronized from the IP-MAC mapping table to the MAC-IP mapping
	thus the following packets with the same MAC-IP pair will be		table, and thus subsequent packets with the same MAC-IP pair will be
	forwarded without going to step 2.		forwarded without going to step 2.
	5. Deployment Scenarios		5. Deployment Scenarios
	This section specifies three deployment scenarios, including two		This section specifies three deployment scenarios, including two
	under centralized WLAN and one under autonomous WLAN. The deployment		under centralized WLAN and one under autonomous WLAN. The deployment
	details and solutions for host mobility between access points are		details and solutions for host mobility between access points are
	described respectively for each scenario.		described for each scenario, respectively.
	5.1. Centralized WLAN		5.1. Centralized WLAN
	Centralized WLAN is comprised of FIT Access Points (AP) and Access		Centralized WLAN is comprised of FIT access points (AP) and access
	Controllers (AC). In this scenario, this document proposes the		controllers (AC). In this scenario, this document proposes the
	following two deployment solutions.		following two deployment solutions.
	5.1.1. AP Filtering		5.1.1. AP Filtering
	With this deployment solution, the validated data packets received by		With this deployment scheme, validated data packets received by an AP
	an AP do not go through the AC, and only control packets and the		do not pass through the AC; only control packets and the questionable
	questionable data packets go through the AC. In this scenario, the		data packets pass through the AC. In this case, the AC maintains the
	AC maintains IP-MAC Mapping Table, while the AP maintains MAC-IP		IP-MAC mapping table, while the AP maintains the MAC-IP mapping table
	Mapping Table and performs address snooping.		and performs address snooping.
	5.1.1.1. Candidate Binding		5.1.1.1. Candidate Binding
	An AP executes the procedure specified in Section 3.3. The candidate		An AP executes the procedure specified in Section 3.3. The candidate
	bindings are generated after snooping procedure. Candidate bindings		bindings are generated after the snooping procedure. Candidate
	must be confirmed by the AC to be valid.		bindings MUST be confirmed by the AC to be valid.
	After a candidate binding is generated, the AC is notified and checks		After a candidate binding is generated, the AC is notified and checks
	whether the binding is valid or not. The validity of a candidate		whether the binding is valid or not. If a candidate binding does not
	binding is determined if the binding does not violate any existing		violate any existing binding in the IP-MAC mapping table, the
	bindings in the IP-MAC Mapping Table. Otherwise, if an address is		validity of the binding is determined. Otherwise, if an address is
	not suitable for a host to use, the AC notifies the corresponding AP.		not suitable for use by the host, the AC notifies the corresponding
	If the candidate binding is valid, the AC adds an entry into the IP-		AP. If the candidate binding is valid, the AC adds an entry to the
	MAC Mapping Table and notifies the AP. Afterwards, the AP also adds		IP-MAC mapping table and notifies the AP. Afterwards, the AP also
	an entry into the local MAC-IP Mapping Table.		adds an entry to the local MAC-IP mapping table.
	5.1.1.2. Packet Filtering		5.1.1.2. Packet Filtering
	As specified in Section 4, for incoming data packets, an AP looks up		As specified in Section 4, for incoming data packets, an AP looks up
	the MAC address in the local MAC-IP Mapping Table and checks if the		the MAC address in the local MAC-IP mapping table and checks if the
	MAC-IP pair exists. If yes, the AP forwards the packet. Otherwise,		MAC-IP pair exists. If exists, the AP forwards the packet.
	the AP delivers the packet to the AC for further processing.		Otherwise, the AP delivers the packet to the AC for further
			processing.
	When receiving a data packet from the AP, the AC looks up the IP		When receiving a data packet from the AP, the AC looks up the IP
	address in the local IP-MAC Mapping Table and checks if the IP		address in the local IP-MAC mapping table and checks if the IP
	address exists. If not, the AC drops the packet. If yes, the AC		address exists. If it does not exist, the AC drops the packet. If
	checks whether the MAC address in the entry is the same as that in		it exists, the AC checks whether the MAC address in the entry is the
	the frame. If yes, the AC forwards the packet. Otherwise, the AC		same as that in the frame. If so, the AC forwards the packet.
	drops the packet.		Otherwise, the AC drops the packet.
	After the AC forwards a valid packet, it synchronizes the related		After the AC forwards a valid packet, it synchronizes the associated
	MAC-IP binding to the MAC-IP mapping table on the AP from which the		MAC-IP binding to the MAC-IP mapping table on the AP from which the
	packet comes. Following packets with the same MAC-IP pair will be		packet comes. Subsequent packets with the same MAC-IP pair will be
	forwarded directly by the AP without going to the AC.		forwarded directly by the AP without going through the AC.
	5.1.1.3. Negative Entries		5.1.1.3. Negative Entries
	In the AP Filtering scenario, APs MAY drop packets directly without		In the AP filtering scenario, APs MAY drop packets directly without
	sending them to the AC by enabling the establishment of negative		sending them to the AC by enabling the establishment of negative
	entries on APs. Specifically, APs may establish negative entries in		entries on APs. Specifically, APs may establish negative entries in
	the following circumstances.		the following circumstances.
	1. When an AP receives a certain number of packets within a certain		1. When an AP receives a certain number of packets within a certain
	amount of time with the same MAC-IP pair that does not exist in		amount of time with the same MAC-IP pair that does not exist in
	the local MAC-IP Table, it establishes a negative entry for this		the local MAC-IP mapping table, it establishes a negative entry
	MAC-IP pair. Then the AP drops all following packets that have		for this MAC-IP pair. Then the AP drops all following packets
	the same MAC-IP pair as indicated in this negative entry without		that have the same MAC-IP pair as indicated in this negative entry
	sending them to the AC for further processing.		without sending them to the AC for further processing.
	2. When an AP receives a certain number of packets within a certain		2. When an AP receives a certain number of packets within a certain
	amount of time with the same MAC address but different MAC-IP		amount of time with the same MAC address but different MAC-IP
	pairs and none of these MAC-IP pairs exist in the local MAC-IP		pairs and none of these MAC-IP pairs exist in the local MAC-IP
	Table, it establishes a negative entry for this MAC address. Then		mapping table, it establishes a negative entry for this MAC
	the AP drops all following packets that have the same MAC address		address. Then the AP drops all the following packets that have
	as indicated in this negative entry without sending them to the AC		the same MAC address as indicated in this negative entry without
	for further processing.		sending them to the AC for further processing.
	Each negative entry has a limited lifetime. The number of packets		Each negative entry has a limited lifetime. The number of packets
	and duration of time to trigger the establishment of the negative		and duration of time to trigger the establishment of the negative
	entry, and the lifetime of the negative entry are configurable.		entry, and the lifetime of the negative entry are configurable.
	5.1.1.4. CAPWAP Extension		5.1.1.4. CAPWAP Extension
	CAPWAP protocol is used for communication between the AP and the AC.		CAPWAP protocol is used for communication between the AP and the AC.
	A new CAPWAP protocol message element is introduced, which extends		A new CAPWAP protocol message element is introduced, which extends
	[RFC5415]. The host IP message element is used by both the AP and		[RFC5415]. The host IP message element is used by both the AP and
	the AC to exchange the binding information of hosts.		the AC to exchange the binding information of hosts.
	The host IP message element can be used in the process of		The host IP message element can be used in the process of confirming
	confirmation of candidate bindings. When the AP generates a		candidate bindings. When the AP generates a candidate binding, it
	candidate binding, it reports the MAC address and related IP		reports the MAC address and related IP addresses to the AC using this
	addresses to the AC using this message, with suggestions of the state		message, with suggestions of the status of each IP address (e.g.,
	of each IP address as specified in Section 3.1.1. After the AC		available, unavailable, candidate). After the AC checks the validity
	checks the validation of the candidate binding, it replies using a		of the candidate binding, it replies using a message of the same
	message of the same format to inform the AP of the validation of each		format, informing the AP of the validation of each IP address with a
	IP address with a suggested state.		suggested status.
	The host IP message element can be used in the process of binding		The host IP message element can be used in the process of binding
	migration. When migration happens, the source device uses this		migration. When migration occurs, the source device uses this
	message to report the MAC address and related IP addresses to the		message to report the MAC address and related IP addresses to the
	destination device, with suggestions for the state of each IP address		destination device, with suggestions for the status of each IP
	as specified in Section 3.1.1. After the destination device checks		address. After the destination device checks the validity of the
	the validation of the candidate binding, it replies using a message		candidate binding, it replies using a message of the same format to
	of the same format to inform the source device the validation of each		inform the source device of the validity of each IP address with a
	IP address with a suggested state.		suggested status.
	The host IP message element can also be used in other scenarios when		The host IP message element can also be used in other scenarios when
	the synchronization between MAC-IP and IP-MAC tables is required as		the synchronization between MAC-IP and IP-MAC mapping tables is
	specified in Section 3.5 and Section 4. When the synchronization		required as specified in Section 3.5 and Section 4. When the
	from IP-MAC table to MAC-IP table is triggered, the source device		synchronization from IP-MAC mapping table to MAC-IP mapping table is
	which holds the IP-MAC table reports the MAC address and the related		triggered, the source device which holds the IP-MAC mapping table
	IP addresses to the destination device which holds the MAC-IP table		reports the MAC address and the related IP addresses to the
	using this message, with suggestions of the state of each IP address		destination device which holds the MAC-IP mapping table using this
	as specified in Section 3.1.1. The destination device replies using		message, with suggestions of the status of each IP address. The
	a message of the same format to acknowledge the source device.		destination device replies using a message of the same format to
			acknowledge the source device.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Radio ID | Total Length +		| Radio ID | Total Length +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sender ID | Length | Description +		| Sender ID | Length | Description +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MAC flag | Length | MAC Address... +		| MAC flag | Length | MAC Address... +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MAC Address... +		| MAC Address... +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 flag | Length | blank ... +		| IPv4 flag | Length | blank ... +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Address 1(32 bit) +		| IPv4 Address 1(32 bit) +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| State | blank ... +		| Status | blank ... +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| lifetime +		| lifetime +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Address 2(32 bit) +		| IPv4 Address 2(32 bit) +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| State | blank ... +		| Status | blank ... +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| lifetime +		| lifetime +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ........ +		| ........ +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Address n(32 bit) +		| IPv4 Address n(32 bit) +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| State | blank ... +		| Status | blank ... +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| lifetime +		| lifetime +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 flag | Length | IPv6 Address... +		| IPv6 flag | Length | IPv6 Address... +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 Address 1(128 bit) +		| IPv6 Address 1(128 bit) +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| State | blank ... +		| Status | blank ... +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| lifetime +		| lifetime +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 Address 2(128 bit) +		| IPv6 Address 2(128 bit) +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| State | blank ... +		| Status | blank ... +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| lifetime +		| lifetime +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ........ +		| ........ +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 Address n(128 bit) +		| IPv6 Address n(128 bit) +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| State | blank ... +		| Status | blank ... +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| lifetime +		| lifetime +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BSSID flag | Length | BSSID... +		| BSSID flag | Length | BSSID... +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BSSID +		| BSSID +
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Radio ID: An 8-bit value representing the radio, whose value is		Radio ID: An 8-bit value representing the radio, whose value is
	between 1 and 31.		between 1 and 31.
	skipping to change at page 11, line 12 ¶		skipping to change at page 11, line 35 ¶
	block MUST appear in the message, otherwise the message is considered		block MUST appear in the message, otherwise the message is considered
	as invalid.		as invalid.
	IPv4 flag: An 8-bit value representing that the sub-field's type is		IPv4 flag: An 8-bit value representing that the sub-field's type is
	IPv4 address, whose value is 2.		IPv4 address, whose value is 2.
	Length: The length of the IPv4 Address field.		Length: The length of the IPv4 Address field.
	IPv4 Address: An IPv4 address of the host. There may exist many		IPv4 Address: An IPv4 address of the host. There may exist many
	entries, and each entry is comprised of an IPv4 address, an 8-bit		entries, and each entry is comprised of an IPv4 address, an 8-bit
	value for address state (value 1 means available, value 0 means		value for address status (value 1 means available, value 0 means
	unavailable, value 255 means candidate), and a 32-bit value for		unavailable, value 255 means candidate), and a 32-bit value for
	lifetime. Lifetime is a reserved field for future application under		lifetime. Lifetime is a reserved field for future application under
	abnormal conditions. It is required to list all IPv4 addresses		abnormal conditions. It is required to list all IPv4 addresses
	before IPv6 address blocks.		before IPv6 address blocks.
	IPv6 flag: An 8-bit value representing that the sub-field's type is		IPv6 flag: An 8-bit value representing that the sub-field's type is
	IPv6 address, a DHCPv6-assigned IP address represented by value 3 and		IPv6 address, a DHCPv6-assigned IP address represented by value 3 and
	a locally assigned IP address represented by value 4.		a locally assigned IP address represented by value 4.
	Length: The length of the IPv6 Address field.		Length: The length of the IPv6 Address field.
	IPv6 Address: An IPv6 address of the host. There may exist many		IPv6 Address: An IPv6 address of the host. There may exist many
	entries, and each entry is comprised of an IPv6 address, an 8-bit		entries, and each entry is comprised of an IPv6 address, an 8-bit
	value of address state (value 1 means available, value 0 means		value of address status (value 1 means available, value 0 means
	unavailable, value 255 means candidate), and a 32-bit value lifetime.		unavailable, value 255 means candidate), and a 32-bit value lifetime.
	Lifetime is a reserved field for future application under abnormal		Lifetime is a reserved field for future application under abnormal
	conditions. All IPv4 and IPv6 addresses bind to the MAC address that		conditions. All IPv4 and IPv6 addresses bind to the MAC address that
	appears before them in the message.		appears before them in the message.
	BSSID flag: An 8-bit value representing that the sub-field's type is		BSSID flag: An 8-bit value representing that the sub-field's type is
	BSSID, whose value is 5.		BSSID, whose value is 5.
	Length: The length of the BSSID field. The formats and lengths		Length: The length of the BSSID field. The formats and lengths
	specified in EUI-48 and EUI-64 [EUI] are supported.		specified in EUI-48 and EUI-64 [EUI] are supported.
	BSSID: A basic service set identifier representing the BSS.		BSSID: A basic service set identifier representing the BSS.
	5.1.1.5. Mobility Solution		5.1.1.5. Mobility Solution
	When a host moves from one AP to another, layer-2 association happens		When a host moves from one AP to another, layer-2 association happens
	before the IP packets are forwarded. The home AP deletes the binding		before the IP packets are forwarded. The home AP deletes the binding
	when mobile host is disconnected, and the foreign AP immediately		when the mobile host is disconnected, and the foreign AP immediately
	requests the bound addresses with the associated MAC from the AC.		requests the bound addresses with the associated MAC address from the
	The AC returns the binding with a suggested state. After the foreign		AC. The AC returns the binding with a suggested status. After the
	AP get the addresses should be bound, the binding migration is		foreign AP gets the addresses that should be bound, the binding
	completed. The protocol used for communication between the foreign		migration is completed. The protocol used for communication between
	AP and the AC is the same as described in Section 5.1.1.4, while in		the foreign AP and the AC is the same as described in
	this scenario, the AC serves the role of the source device and the		Section 5.1.1.4, while in this scenario, the AC serves the role of
	foreign AP serves the role of the destination device.		the source device and the foreign AP serves the role of the
			destination device.
	In WLAN, a host can move from an AC to another AC while keeping using		In WLAN, a host can move from an AC to another AC while keeping using
	the same IP address. To be compatible with such scenario, ACs must		the same IP address. To be compatible with such scenario, ACs must
	communicate to perform the binding migration. The protocol used for		communicate to perform the binding migration. The protocol used for
	communication between ACs is the same as described in		communication between ACs is the same as described in
	Section 5.1.1.4, while in this scenario the home AC serves the role		Section 5.1.1.4, while in this scenario the home AC serves the role
	of the source device and the foreign AC serves the role of the		of the source device and the foreign AC serves the role of the
	destination device.		destination device.
	5.1.2. AC Filtering		5.1.2. AC Filtering
	In this scenario, an AC maintains both MAC-IP and IP-MAC Mapping		In this scenario, an AC maintains both the MAC-IP and IP-MAC mapping
	Table and performs both address snooping and packet filtering. So,		tables and performs both address snooping and packet filtering.
	all the packets must be forwarded to the AC first.		Therefore, all the packets must be forwarded to the AC first.
	The AC executes the procedure specified in Section 3.3 and checks the		The AC executes the procedure specified in Section 3.3 and checks the
	validity of IP-MAC pairs by consulting the local IP-MAC mapping		validity of IP-MAC pairs by consulting the local IP-MAC mapping
	table. No extra procedure is needed to establish the IP-MAC		table. No extra procedure is needed to establish the IP-MAC
	bindings.		bindings.
	The AC executes the procedure specified in Section 4 for packet		The AC executes the procedure specified in Section 4 for packet
	filtering, and no extra procedure is involved.		filtering, and no extra procedure is involved.
	Mobility within one AC does not trigger any binding migration.		Host movement within an AC does not trigger any binding migration.
	Mobility between different ACs triggers binding migration. ACs must		Host movement between different ACs triggers binding migration. ACs
	communicate to perform the binding migration. The protocol used for		must communicate to perform binding migration. The protocol used for
	communication between ACs is the same as described in		communication between ACs is the same as described in
	Section 5.1.1.4, while in this scenario the home AC serves the role		Section 5.1.1.4, while in this scenario the home AC serves the role
	of the source device and the foreign AC serves the role of the		of the source device and the foreign AC serves the role of the
	destination device.		destination device.
	5.2. Autonomous WLAN		5.2. Autonomous WLAN
	Autonomous WLAN is comprised of FAT Access Points. In this scenario,		Autonomous WLAN is comprised of FAT access points. In this scenario,
	a FAT AP maintains both MAC-IP and IP-MAC Mapping Table and performs		a FAT AP maintains both the MAC-IP and IP-MAC mapping tables and
	both address snooping and packet filtering.		performs both address snooping and packet filtering.
	The FAT AP executes the procedure specified in Section 3.3 and checks		The FAT AP executes the procedure specified in Section 3.3 and checks
	the validity of IP-MAC pairs by consulting the local IP-MAC mapping		the validity of IP-MAC pairs by consulting the local IP-MAC mapping
	table. No extra procedure is needed to establish the IP-MAC		table. No extra procedure is needed to establish the IP-MAC
	bindings.		bindings.
	The FAT AP executes the procedure specified in Section 4 for packet		The FAT AP executes the procedure specified in Section 4 for packet
	filtering, and no extra procedure is involved.		filtering, and no extra procedure is involved.
	Mobility between different FAT APs will trigger binding migration.		Mobility between different FAT APs will trigger binding migration.
	skipping to change at page 14, line 16 ¶		skipping to change at page 15, line 5 ¶
	Address Autoconfiguration", RFC 4862,		Address Autoconfiguration", RFC 4862,
	DOI 10.17487/RFC4862, September 2007,		DOI 10.17487/RFC4862, September 2007,
	<https://www.rfc-editor.org/info/rfc4862>.		<https://www.rfc-editor.org/info/rfc4862>.
	[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,		[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
	Ed., "Control And Provisioning of Wireless Access Points		Ed., "Control And Provisioning of Wireless Access Points
	(CAPWAP) Protocol Specification", RFC 5415,		(CAPWAP) Protocol Specification", RFC 5415,
	DOI 10.17487/RFC5415, March 2009,		DOI 10.17487/RFC5415, March 2009,
	<https://www.rfc-editor.org/info/rfc5415>.		<https://www.rfc-editor.org/info/rfc5415>.
			[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
			"Source Address Validation Improvement (SAVI) Framework",
			RFC 7039, DOI 10.17487/RFC7039, October 2013,
			<https://www.rfc-editor.org/info/rfc7039>.
	[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address		[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
	Validation Improvement (SAVI) Solution for DHCP",		Validation Improvement (SAVI) Solution for DHCP",
	RFC 7513, DOI 10.17487/RFC7513, May 2015,		RFC 7513, DOI 10.17487/RFC7513, May 2015,
	<https://www.rfc-editor.org/info/rfc7513>.		<https://www.rfc-editor.org/info/rfc7513>.
	Authors' Addresses		Authors' Addresses
	Jun Bi		Jun Bi
	Tsinghua University		Tsinghua University
	Beijing 100084		Beijing
			100084
	China		China
	Email: junbi@cernet.edu.cn		Email: junbi@cernet.edu.cn
	Jianping Wu		Jianping Wu
	Tsinghua University		Tsinghua University
	Beijing 100084		Beijing
			100084
	China		China
	Email: jianping@cernet.edu.cn		Email: jianping@cernet.edu.cn
	Tao Lin		Tao Lin
	New H3C Technologies Co. Ltd		New H3C Technologies Co. Ltd
	466 Changhe Road, Binjiang District		466 Changhe Road, Binjiang District
	Hangzhou, Zhejiang 310052		Hangzhou
			Zhejiang, 310052
	China		China
	Email: lintao@h3c.com		Email: lintao@h3c.com
	You Wang		You Wang
	Tsinghua University		Tsinghua University
	Beijing 100084		Beijing
			100084
	China		China
	Email: you@opennetworking.org		Email: you@opennetworking.org
	Lin He		Lin He
	Tsinghua University		Tsinghua University
	Beijing 100084		Beijing
			100084
	China		China
	Email: he-l14@mails.tsinghua.edu.cn		Email: he-l14@mails.tsinghua.edu.cn
End of changes. 90 change blocks.
	228 lines changed or deleted		254 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/