idnits 2.17.1 draft-bi-savi-wlan-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (11 May 2022) is 709 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Source Address Validation Improvements (SAVI) J.B. Bi 3 Internet-Draft J.W. Wu 4 Intended status: Standards Track Tsinghua University 5 Expires: 12 November 2022 T.L. Lin 6 New H3C Technologies Co. Ltd 7 Y.W. Wang 8 L.H. He 9 Tsinghua University 10 11 May 2022 12 A SAVI Solution for WLAN 13 draft-bi-savi-wlan-23 15 Abstract 17 This document describes a source address validation solution for 18 WLANs where 802.11i or other security mechanisms are enabled to 19 secure MAC addresses. This mechanism snoops NDP and DHCP packets to 20 bind IP addresses to MAC addresses, and relies on the security of MAC 21 addresses guaranteed by 802.11i or other mechanisms to filter IP 22 spoofing packets. It can work in the special situations described in 23 the charter of SAVI (Source Address Validation Improvements) 24 workgroup, such as multiple MAC addresses on one interface. This 25 document describes three different deployment scenarios, with 26 solutions for migration of binding entries when hosts move from one 27 access point to another. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 12 November 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 65 3. IP-MAC Binding . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 4 67 3.1.1. IP-MAC Mapping Table . . . . . . . . . . . . . . . . 4 68 3.1.2. MAC-IP Mapping Table . . . . . . . . . . . . . . . . 4 69 3.2. Pre-conditions for Binding . . . . . . . . . . . . . . . 5 70 3.3. Binding IP addresses to MAC addresses . . . . . . . . . . 5 71 3.4. Binding Migration . . . . . . . . . . . . . . . . . . . . 6 72 3.5. Binding Clearing . . . . . . . . . . . . . . . . . . . . 6 73 4. Source Address Validation . . . . . . . . . . . . . . . . . . 6 74 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 7 75 5.1. Centralized WLAN . . . . . . . . . . . . . . . . . . . . 7 76 5.1.1. AP Filtering . . . . . . . . . . . . . . . . . . . . 7 77 5.1.1.1. Candidate Binding . . . . . . . . . . . . . . . . 7 78 5.1.1.2. Packet Filtering . . . . . . . . . . . . . . . . 8 79 5.1.1.3. Negative Entries . . . . . . . . . . . . . . . . 8 80 5.1.1.4. CAPWAP Extension . . . . . . . . . . . . . . . . 9 81 5.1.1.5. Mobility Solution . . . . . . . . . . . . . . . . 12 82 5.1.2. AC Filtering . . . . . . . . . . . . . . . . . . . . 12 83 5.2. Autonomous WLAN . . . . . . . . . . . . . . . . . . . . . 13 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 14 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 9.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 This document describes a mechanism for performing per-packet IP 96 source address validation in wireless local area networks (WLANs). 97 The mechanism performs ND snooping or DHCP snooping to bind the 98 assigned IP address to the verified MAC address. Static addresses 99 are manually bound to the MAC address of the corresponding host. The 100 mechanism can then check the validity of the source IP address in the 101 local packet against the binding association. The MAC address is 102 secured by 802.11i or other mechanisms, so the binding association is 103 secure. 105 This mechanism utilizes two important data structures, the IP-MAC 106 mapping table on the control plane and the MAC-IP mapping table on 107 the data plane, to implement source address validation, which is 108 described in detail in this document. 110 The case of an interface with multiple MAC addresses is a special 111 case mentioned in the SAVI charter and is the only special case that 112 challenges MAC-IP binding. The mechanism to handle this case is 113 specified in the document. 115 Three deployment scenarios for this mechanism are specified in this 116 document, describing the devices and details of deployment in 117 different scenarios. 119 When a host moves from one access point to another, the migration of 120 binding entries can be triggered depending on the specific mobility 121 scenario. The mechanism for handling host mobility is specified in 122 the documentation based on different deployment scenarios. 124 1.1. Terminology 126 FIT access points: The access points used in centralized WLAN 127 deployment scenario. 129 FAT access points: The access points used in autonomous WLAN 130 deployment scenario. 132 Binding anchor: A "binding anchor" is defined to be a physical and/or 133 link-layer property of an attached device, as defined in [RFC7039]. 134 In this document, the binding anchor refers to th MAC address. 136 Binding entry: A rule that associates an IP address with a binding 137 anchor. 139 Familiarity with SAVI-DHCP and its terminology, as defined in 140 [RFC7513], is assumed. 142 2. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 3. IP-MAC Binding 150 This section specifies the operations for creating and clearing 151 bindings between IP addresses and MAC addresses. 153 3.1. Data Structures 155 The binding relationship between IP address and MAC address is stored 156 using two data structures, i.e., the IP-MAC mapping table and MAC-IP 157 mapping table. 159 3.1.1. IP-MAC Mapping Table 161 This table maps IP addresses to their corresponding MAC addresses. 162 The IP address is the index of the table. An IP address can have 163 only one corresponding MAC address. Different IP addresses can be 164 mapped to the same MAC address. 166 This table is used in the control process. Before creating a new IP- 167 MAC binding, this table must be queried to prevent conflicting 168 binding entries. Also, this table must be queried before any packet 169 filtering is performed. This table must be synchronized with the 170 MAC-IP mapping table specified in Section 3.1.2. 172 Each entry in the IP-MAC mapping table must also record the binding 173 method of the IP address. Addresses snooped in the DHCP address 174 assignment procedure must have their binding method recorded as 175 "DHCP", and addresses snooped in the Duplicate Address Detection 176 procedure [RFC4862] must have their binding method recorded as 177 "SLAAC". 179 3.1.2. MAC-IP Mapping Table 181 This table maps MAC addresses to the corresponding IP addresses. The 182 MAC address is the index of the table. It is a one-to-many mapping 183 table, which means a MAC address can be mapped to multiple IP 184 addresses. Although multiple MAC addresses may exist on one 185 interface, these MAC addresses must be mapped to different IP 186 addresses. 188 This table is used for filtering. Different from wired networks, the 189 MAC-IP mapping table and the IP-MAC mapping table can be maintained 190 separately on different devices. A synchronization mechanism must be 191 used between these two tables to ensure the consistency of the 192 bindings. We will explain the details in Section 5 for different 193 deployment scenarios. 195 3.2. Pre-conditions for Binding 197 As specified in [RFC7039], in a binding-based mechanism, the security 198 of IP address is dependent on the security of the binding anchor. In 199 WLANs, 802.11i or other link-layer security mechanisms make MAC 200 address a strong enough binding anchor. 202 If the MAC address is unprotected, an attacker can spoof the MAC 203 address to pass validation successfully. 205 3.3. Binding IP addresses to MAC addresses 207 All the static IP-MAC address pairs are configured into the IP-MAC 208 mapping table with the mechanism enabled. 210 A separate procedure handles the binding of DHCP addresses to MAC 211 addresses. This procedure snoops on the DHCP address assignment 212 process between the attached host and the DHCP server. DHCP snooping 213 in WLANs is the same as that in wired networks specified in 214 [RFC7513]. 216 A separate procedure handles the binding of stateless addresses to 217 MAC addresses. This procedure snoops Duplicate Address Detection 218 procedure as described in [RFC4862] or Address Resolution procedure 219 between attached hosts and neighbors as described in [RFC4861]. 220 Based on the principle of roaming experience first in WLAN, the new 221 binding anchor is selected in preference and triggers the deletion of 222 the secure connection of the old binding anchor. 224 In some deployment scenarios, the functions of address snooping and 225 IP-MAC mapping table maintenance may also be separated to different 226 devices. Therefore, to prevent conflicting binding entries, the 227 device for address snooping must interact with the device that 228 maintains the IP-MAC mapping table. We will specify the details in 229 Section 5.1.1. 231 3.4. Binding Migration 233 Different from wired networks, SAVI for WLAN must handle the 234 migration of binding entries when a mobile host moves from one access 235 point to another. After the move, the host will not perform another 236 address configuration procedure to obtain new IP addresses but 237 continue to use the existing IP address(es). Thus, binding entries 238 in the foreign device accessed by mobile hosts cannot be established 239 by snooping. A new mechanism is needed to correctly migrate the 240 binding entry associated with the mobile host's IP address from the 241 home device to the foreign device. If the host binds multiple 242 entries, multiple entries will be migrated. For example, when the 243 host is assigned multiple addresses, multiple binding entries will be 244 generated, and these entries will be migrated. We will specify the 245 details in Section 5 depending on different deployment scenarios. 247 3.5. Binding Clearing 249 Three kinds of events will trigger binding clearing: 251 1. A host leaves explicitly this access point. All entries in the 252 MAC-IP mapping table associated with this MAC address MUST be 253 cleared. 255 2. A DHCP RELEASE message is received from the owner of the 256 corresponding IP address. This IP entry in the IP-MAC mapping 257 table and the corresponding entries in the MAC-IP mapping table 258 MUST be cleared. 260 3. A timeout message of the AC's client idle-time is received. All 261 entries in the MAC-IP mapping table related to the MAC address 262 MUST be cleared. 264 4. Source Address Validation 266 This section describes source address validation procedure for 267 packets. In this procedure, all the frames are considered to have 268 passed the verification of 802.11i or other security mechanisms. 270 This procedure has the following steps: 272 1. Extract the IP source address and MAC source address from the 273 frame. Look up the MAC address in the MAC-IP mapping table and 274 check if the MAC-IP pair exists. If exists, forward the packet. 275 Otherwise, go to step 2. 277 2. Look up the IP address in the IP-MAC mapping table and check if 278 the IP address exists. If it does not exist, go to step 3. If it 279 exists, check whether the MAC address in the entry is the same as 280 that in the frame. If so, forward the packet. Otherwise, drop 281 the packet. 283 In step 2, after the packet is judged to be valid and forwarded, 284 synchronization between the MAC-IP and IP-MAC mapping tables should 285 be triggered. The MAC-IP binding of the packet should be 286 synchronized from the IP-MAC mapping table to the MAC-IP mapping 287 table, and thus subsequent packets with the same MAC-IP pair will be 288 forwarded without going to step 2. 290 5. Deployment Scenarios 292 This section specifies three deployment scenarios, including two 293 under centralized WLAN and one under autonomous WLAN. The deployment 294 details and solutions for host mobility between access points are 295 described for each scenario, respectively. 297 5.1. Centralized WLAN 299 Centralized WLAN is comprised of FIT access points (AP) and access 300 controllers (AC). In this scenario, this document proposes the 301 following two deployment solutions. 303 5.1.1. AP Filtering 305 With this deployment scheme, validated data packets received by an AP 306 do not pass through the AC; only control packets and the questionable 307 data packets pass through the AC. In this case, the AC maintains the 308 IP-MAC mapping table, while the AP maintains the MAC-IP mapping table 309 and performs address snooping. 311 5.1.1.1. Candidate Binding 313 An AP executes the procedure specified in Section 3.3. The candidate 314 bindings are generated after the snooping procedure. Candidate 315 bindings MUST be confirmed by the AC to be valid. 317 After a candidate binding is generated, the AC is notified and checks 318 whether the binding is valid or not. If a candidate binding does not 319 violate any existing binding in the IP-MAC mapping table, the 320 validity of the binding is determined. Otherwise, if an address is 321 not suitable for use by the host, the AC notifies the corresponding 322 AP. If the candidate binding is valid, the AC adds an entry to the 323 IP-MAC mapping table and notifies the AP. Afterwards, the AP also 324 adds an entry to the local MAC-IP mapping table. 326 5.1.1.2. Packet Filtering 328 As specified in Section 4, for incoming data packets, an AP looks up 329 the MAC address in the local MAC-IP mapping table and checks if the 330 MAC-IP pair exists. If exists, the AP forwards the packet. 331 Otherwise, the AP delivers the packet to the AC for further 332 processing. 334 When receiving a data packet from the AP, the AC looks up the IP 335 address in the local IP-MAC mapping table and checks if the IP 336 address exists. If it does not exist, the AC drops the packet. If 337 it exists, the AC checks whether the MAC address in the entry is the 338 same as that in the frame. If so, the AC forwards the packet. 339 Otherwise, the AC drops the packet. 341 After the AC forwards a valid packet, it synchronizes the associated 342 MAC-IP binding to the MAC-IP mapping table on the AP from which the 343 packet comes. Subsequent packets with the same MAC-IP pair will be 344 forwarded directly by the AP without going through the AC. 346 5.1.1.3. Negative Entries 348 In the AP filtering scenario, APs MAY drop packets directly without 349 sending them to the AC by enabling the establishment of negative 350 entries on APs. Specifically, APs may establish negative entries in 351 the following circumstances. 353 1. When an AP receives a certain number of packets within a certain 354 amount of time with the same MAC-IP pair that does not exist in 355 the local MAC-IP mapping table, it establishes a negative entry 356 for this MAC-IP pair. Then the AP drops all following packets 357 that have the same MAC-IP pair as indicated in this negative entry 358 without sending them to the AC for further processing. 360 2. When an AP receives a certain number of packets within a certain 361 amount of time with the same MAC address but different MAC-IP 362 pairs and none of these MAC-IP pairs exist in the local MAC-IP 363 mapping table, it establishes a negative entry for this MAC 364 address. Then the AP drops all the following packets that have 365 the same MAC address as indicated in this negative entry without 366 sending them to the AC for further processing. 368 Each negative entry has a limited lifetime. The number of packets 369 and duration of time to trigger the establishment of the negative 370 entry, and the lifetime of the negative entry are configurable. 372 5.1.1.4. CAPWAP Extension 374 CAPWAP protocol is used for communication between the AP and the AC. 375 A new CAPWAP protocol message element is introduced, which extends 376 [RFC5415]. The host IP message element is used by both the AP and 377 the AC to exchange the binding information of hosts. 379 The host IP message element can be used in the process of confirming 380 candidate bindings. When the AP generates a candidate binding, it 381 reports the MAC address and related IP addresses to the AC using this 382 message, with suggestions of the status of each IP address (e.g., 383 available, unavailable, candidate). After the AC checks the validity 384 of the candidate binding, it replies using a message of the same 385 format, informing the AP of the validation of each IP address with a 386 suggested status. 388 The host IP message element can be used in the process of binding 389 migration. When migration occurs, the source device uses this 390 message to report the MAC address and related IP addresses to the 391 destination device, with suggestions for the status of each IP 392 address. After the destination device checks the validity of the 393 candidate binding, it replies using a message of the same format to 394 inform the source device of the validity of each IP address with a 395 suggested status. 397 The host IP message element can also be used in other scenarios when 398 the synchronization between MAC-IP and IP-MAC mapping tables is 399 required as specified in Section 3.5 and Section 4. When the 400 synchronization from IP-MAC mapping table to MAC-IP mapping table is 401 triggered, the source device which holds the IP-MAC mapping table 402 reports the MAC address and the related IP addresses to the 403 destination device which holds the MAC-IP mapping table using this 404 message, with suggestions of the status of each IP address. The 405 destination device replies using a message of the same format to 406 acknowledge the source device. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Radio ID | Total Length + 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Sender ID | Length | Description + 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | MAC flag | Length | MAC Address... + 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | MAC Address... + 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | IPv4 flag | Length | blank ... + 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | IPv4 Address 1(32 bit) + 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Status | blank ... + 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | lifetime + 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | IPv4 Address 2(32 bit) + 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Status | blank ... + 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | lifetime + 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | ........ + 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | IPv4 Address n(32 bit) + 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Status | blank ... + 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | lifetime + 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | IPv6 flag | Length | IPv6 Address... + 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | IPv6 Address 1(128 bit) + 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Status | blank ... + 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | lifetime + 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | IPv6 Address 2(128 bit) + 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Status | blank ... + 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | lifetime + 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | ........ + 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | IPv6 Address n(128 bit) + 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Status | blank ... + 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | lifetime + 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | BSSID flag | Length | BSSID... + 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | BSSID + 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Radio ID: An 8-bit value representing the radio, whose value is 469 between 1 and 31. 471 Total Length: Total length of the following fields. 473 Sender ID: An 8-bit value representing the sender of the message. AP 474 is represented by value 1 and AC is represented by value 2. 476 Length: The length of the Value field. 478 Description: A 16-bit value for a description of the sender (AP or 479 AC). 481 MAC flag: An 8-bit value representing that the sub-field's type is 482 MAC address, whose value is 1. 484 Length: The length of the MAC Address field. The formats and lengths 485 specified in EUI-48 and EUI-64 [EUI] are supported. 487 MAC Address: A MAC address of the host. At least one MAC address 488 block MUST appear in the message, otherwise the message is considered 489 as invalid. 491 IPv4 flag: An 8-bit value representing that the sub-field's type is 492 IPv4 address, whose value is 2. 494 Length: The length of the IPv4 Address field. 496 IPv4 Address: An IPv4 address of the host. There may exist many 497 entries, and each entry is comprised of an IPv4 address, an 8-bit 498 value for address status (value 1 means available, value 0 means 499 unavailable, value 255 means candidate), and a 32-bit value for 500 lifetime. Lifetime is a reserved field for future application under 501 abnormal conditions. It is required to list all IPv4 addresses 502 before IPv6 address blocks. 504 IPv6 flag: An 8-bit value representing that the sub-field's type is 505 IPv6 address, a DHCPv6-assigned IP address represented by value 3 and 506 a locally assigned IP address represented by value 4. 508 Length: The length of the IPv6 Address field. 510 IPv6 Address: An IPv6 address of the host. There may exist many 511 entries, and each entry is comprised of an IPv6 address, an 8-bit 512 value of address status (value 1 means available, value 0 means 513 unavailable, value 255 means candidate), and a 32-bit value lifetime. 514 Lifetime is a reserved field for future application under abnormal 515 conditions. All IPv4 and IPv6 addresses bind to the MAC address that 516 appears before them in the message. 518 BSSID flag: An 8-bit value representing that the sub-field's type is 519 BSSID, whose value is 5. 521 Length: The length of the BSSID field. The formats and lengths 522 specified in EUI-48 and EUI-64 [EUI] are supported. 524 BSSID: A basic service set identifier representing the BSS. 526 5.1.1.5. Mobility Solution 528 When a host moves from one AP to another, layer-2 association happens 529 before the IP packets are forwarded. The home AP deletes the binding 530 when the mobile host is disconnected, and the foreign AP immediately 531 requests the bound addresses with the associated MAC address from the 532 AC. The AC returns the binding with a suggested status. After the 533 foreign AP gets the addresses that should be bound, the binding 534 migration is completed. The protocol used for communication between 535 the foreign AP and the AC is the same as described in 536 Section 5.1.1.4, while in this scenario, the AC serves the role of 537 the source device and the foreign AP serves the role of the 538 destination device. 540 In WLAN, a host can move from an AC to another AC while keeping using 541 the same IP address. To be compatible with such scenario, ACs must 542 communicate to perform the binding migration. The protocol used for 543 communication between ACs is the same as described in 544 Section 5.1.1.4, while in this scenario the home AC serves the role 545 of the source device and the foreign AC serves the role of the 546 destination device. 548 5.1.2. AC Filtering 550 In this scenario, an AC maintains both the MAC-IP and IP-MAC mapping 551 tables and performs both address snooping and packet filtering. 552 Therefore, all the packets must be forwarded to the AC first. 554 The AC executes the procedure specified in Section 3.3 and checks the 555 validity of IP-MAC pairs by consulting the local IP-MAC mapping 556 table. No extra procedure is needed to establish the IP-MAC 557 bindings. 559 The AC executes the procedure specified in Section 4 for packet 560 filtering, and no extra procedure is involved. 562 Host movement within an AC does not trigger any binding migration. 563 Host movement between different ACs triggers binding migration. ACs 564 must communicate to perform binding migration. The protocol used for 565 communication between ACs is the same as described in 566 Section 5.1.1.4, while in this scenario the home AC serves the role 567 of the source device and the foreign AC serves the role of the 568 destination device. 570 5.2. Autonomous WLAN 572 Autonomous WLAN is comprised of FAT access points. In this scenario, 573 a FAT AP maintains both the MAC-IP and IP-MAC mapping tables and 574 performs both address snooping and packet filtering. 576 The FAT AP executes the procedure specified in Section 3.3 and checks 577 the validity of IP-MAC pairs by consulting the local IP-MAC mapping 578 table. No extra procedure is needed to establish the IP-MAC 579 bindings. 581 The FAT AP executes the procedure specified in Section 4 for packet 582 filtering, and no extra procedure is involved. 584 Mobility between different FAT APs will trigger binding migration. 585 FAT APs must communicate to perform the binding migration. The 586 protocol used for communication between FAT APs is the same as 587 described in Section 5.1.1.4, while in this scenario the home FAT AP 588 serves the role of the source device and the foreign FAT AP serves 589 the role of the destination device. 591 6. IANA Considerations 593 There is no IANA consideration currently. 595 7. Security Considerations 597 The security of address allocation methods matters the security of 598 this mechanism. Thus, it is necessary to improve the security of 599 stateless auto-configuration and DHCP first. 601 7.1. Privacy Considerations 603 A SAVI device MUST delete binding anchor information as soon as 604 possible, except where there is an identified reason why that 605 information is likely to be involved in the detection, prevention, or 606 tracing of actual source-address spoofing. Information about hosts 607 that never spoof (probably the majority of hosts) SHOULD NOT be 608 logged. 610 8. Acknowledgements 612 The authors would like to thank Guang Yao, Yang Shi, and Hao Wang for 613 their contributions to this document. 615 9. References 617 9.1. Normative References 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, 621 DOI 10.17487/RFC2119, March 1997, 622 . 624 9.2. Informative References 626 [EUI] IEEE Standards Association, "Guidelines for Use of 627 Extended Unique Identifier (EUI), Organizationally Unique 628 Identifier (OUI), and Company ID (CID)", 2017, 629 . 632 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 633 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 634 DOI 10.17487/RFC4861, September 2007, 635 . 637 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 638 Address Autoconfiguration", RFC 4862, 639 DOI 10.17487/RFC4862, September 2007, 640 . 642 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 643 Ed., "Control And Provisioning of Wireless Access Points 644 (CAPWAP) Protocol Specification", RFC 5415, 645 DOI 10.17487/RFC5415, March 2009, 646 . 648 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 649 "Source Address Validation Improvement (SAVI) Framework", 650 RFC 7039, DOI 10.17487/RFC7039, October 2013, 651 . 653 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 654 Validation Improvement (SAVI) Solution for DHCP", 655 RFC 7513, DOI 10.17487/RFC7513, May 2015, 656 . 658 Authors' Addresses 660 Jun Bi 661 Tsinghua University 662 Beijing 663 100084 664 China 665 Email: junbi@cernet.edu.cn 667 Jianping Wu 668 Tsinghua University 669 Beijing 670 100084 671 China 672 Email: jianping@cernet.edu.cn 674 Tao Lin 675 New H3C Technologies Co. Ltd 676 466 Changhe Road, Binjiang District 677 Hangzhou 678 Zhejiang, 310052 679 China 680 Email: lintao@h3c.com 682 You Wang 683 Tsinghua University 684 Beijing 685 100084 686 China 687 Email: you@opennetworking.org 688 Lin He 689 Tsinghua University 690 Beijing 691 100084 692 China 693 Email: he-l14@mails.tsinghua.edu.cn