idnits 2.17.1 draft-bi-savi-wlan-22.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 (November 10, 2021) is 870 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. Bi 3 Internet-Draft J. Wu 4 Intended status: Standards Track Tsinghua University 5 Expires: May 14, 2022 T. Lin 6 New H3C Technologies Co. Ltd 7 Y. Wang 8 L. He 9 Tsinghua University 10 November 10, 2021 12 A SAVI Solution for WLAN 13 draft-bi-savi-wlan-22 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 May 14, 2022. 46 Copyright Notice 48 Copyright (c) 2021 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 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 66 3. IP-MAC Binding . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 4 68 3.1.1. IP-MAC Mapping Table . . . . . . . . . . . . . . . . 4 69 3.1.2. MAC-IP Mapping Table . . . . . . . . . . . . . . . . 4 70 3.2. Pre-conditions for Binding . . . . . . . . . . . . . . . 4 71 3.3. Binding IP addresses to MAC addresses . . . . . . . . . . 5 72 3.4. Binding Migration . . . . . . . . . . . . . . . . . . . . 5 73 3.5. Binding Clearing . . . . . . . . . . . . . . . . . . . . 5 74 4. Source Address Validation . . . . . . . . . . . . . . . . . . 6 75 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 6 76 5.1. Centralized WLAN . . . . . . . . . . . . . . . . . . . . 7 77 5.1.1. AP Filtering . . . . . . . . . . . . . . . . . . . . 7 78 5.1.1.1. Candidate Binding . . . . . . . . . . . . . . . . 7 79 5.1.1.2. Packet Filtering . . . . . . . . . . . . . . . . 7 80 5.1.1.3. Negative Entries . . . . . . . . . . . . . . . . 8 81 5.1.1.4. CAPWAP Extension . . . . . . . . . . . . . . . . 8 82 5.1.1.5. Mobility Solution . . . . . . . . . . . . . . . . 11 83 5.1.2. AC Filtering . . . . . . . . . . . . . . . . . . . . 12 84 5.2. Autonomous WLAN . . . . . . . . . . . . . . . . . . . . . 12 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 13 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 91 9.2. Informative References . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 This document describes a mechanism to perform per packet IP source 97 address validation in WLAN. This mechanism performs ND snooping or 98 DHCP snooping to bind allocated IP addresses with authenticated MAC 99 addresses. Static addresses are bound to the MAC addresses of 100 corresponding hosts manually. Then the mechanism can check the 101 validity of the source IP addresses in local packets according to the 102 binding association. The security of MAC address is assured by 103 802.11i or other mechanisms, thus the binding association is secure. 105 IP-MAC binding table in control plane and MAC-IP binding table in 106 data plane are two important data structures, which are introduced in 107 detail in the document. 109 The situation that one interface with multiple MAC addresses is a 110 special case mentioned in the charter of SAVI. And this situation is 111 the only special case that challenges MAC-IP binding. The mechanism 112 to handle this situation is specified in the document. 114 There are three deployment scenarios specified in this document. The 115 mechanism is deployed on different devices in different scenarios. 116 The deployment details are described in the document. 118 When hosts move from one access point to another, the migration of 119 binding entries may be triggered according to the specific mobility 120 scenario. The mechanism to handle host mobility is specified in the 121 document according to different deployment scenarios. 123 1.1. Terminology 125 FIT Access Points: the name of Access Points in Centralized WLAN 126 deployment scenario. 128 FAT Access Points: the name of Access Points in Autonomous WLAN 129 deployment scenario. 131 Familiarity with SAVI-DHCP and its terminology, as defined in 132 [RFC7513], is assumed. 134 2. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 3. IP-MAC Binding 142 This section specifies the operations for creating and clearing 143 bindings between IP addresses and MAC addresses. 145 3.1. Data Structures 147 3.1.1. IP-MAC Mapping Table 149 This table maps IP addresses to corresponding MAC addresses. IP 150 address is the index of the table. One IP address can only have one 151 corresponding MAC address, while different IP addresses can be mapped 152 to the same MAC address. 154 This table is used in the control process. Before creating new IP- 155 MAC bindings, this table must first be consulted in case of conflicts 156 in binding entries. Also, this table must be consulted before doing 157 any packet filtering. This table must be synchronized with the MAC- 158 IP table specified in Section 3.1.2. 160 Each entry in IP-MAC mapping table must also record the binding state 161 of the IP address. The addresses snooped in DHCP address assignment 162 procedure must record their state as "DHCPv6", and the addresses 163 snooped in Duplicate Address Detection procedure must record their 164 state as "SLAAC". 166 3.1.2. MAC-IP Mapping Table 168 This table maps MAC addresses to the corresponding IP addresses. MAC 169 address is the index of the table. It is a one-to-many mapping 170 table, which means a MAC address can be mapped to multiple IP 171 addresses. Though multiple MAC addresses may exist on one interface, 172 these MAC addresses must be mapped to different IP addresses. 174 This table is used for filtering. Different from wired network, MAC- 175 IP mapping table and IP-MAC mapping table can be maintained 176 separately on different devices. Mechanisms for synchronization 177 between the two tables must be employed for the consistency of the 178 bindings. We will specify the details in Section 5 according to 179 different deployment scenarios. 181 3.2. Pre-conditions for Binding 183 In the binding based mechanism, the security of IP address is based 184 on the security of the binding anchor. In WLAN, 802.11i or other 185 security mechanisms on link layer make MAC address a strong enough 186 binding anchor. 188 If MAC address has no protection, attackers can spoof MAC address to 189 succeed in validation. 191 3.3. Binding IP addresses to MAC addresses 193 All the static IP-MAC address pairs are configured into the IP-MAC 194 Mapping Table with the mechanism enabled. 196 An individual procedure handles the binding of DHCP addresses to MAC 197 addresses. This procedure snoops the DHCP address assignment process 198 between attached hosts and DHCP server. DHCP snooping in WLANs is 199 the same as that in wired networks specified in [RFC7513]. 201 An individual procedure handles the binding of stateless addresses to 202 MAC addresses. This procedure snoops Address Resolution procedure 203 between attached hosts and neighbors as described in [RFC4861] or 204 Duplicate Address Detection procedure as described in [RFC4862]. 205 Based on the principle of roaming experience first in WLAN, the new 206 binding anchor is preferred, and removing the security connection of 207 the old binding anchor is triggered. 209 In some deployment scenarios, the functions of address snooping and 210 IP-MAC table maintenance may also be separated onto different 211 devices. Thus, to prevent conflicts in binding entries, the device 212 for address snooping must interact with the device that maintains the 213 IP-MAC table. We will specify the details in Section 5.1.1. 215 3.4. Binding Migration 217 Different from wired network, SAVI for WLAN must handle the migration 218 of binding entries when a mobile host moves from one access point to 219 another. After the movement, the host will not perform another 220 address allocation procedure to obtain new IP addresses, but continue 221 to use the existing IP address(es). Thus, binding entries in the 222 foreign device that the mobile hosts access to cannot be established 223 by snooping. A new mechanism is needed to correctly migrate the 224 binding entry related to the IP address of the mobile host from the 225 home device to the foreign device. If the host binds multiple 226 entries, multiple entries will be migrated. For example, when the 227 host is assigned multiple addresses, multiple binding entries will be 228 generated, and these entries will be migrated. We will specify the 229 details in Section 5, according to different deployment scenarios. 231 3.5. Binding Clearing 233 Three kinds of events will trigger binding clearing: 235 1. A host leaves explicitly this access point. The entries for all 236 related MAC addresses in MAC-IP table MUST be cleared. 238 2. A DHCP RELEASE message is received from the owner of the 239 corresponding IP address. This IP entry in IP-MAC mapping table 240 and the corresponding entries in MAC-IP mapping table MUST be 241 cleared. 243 3. A timeout message of AC's client idle-time is received. The 244 entries for all related MAC addresses in MAC-IP table MUST be 245 cleared. 247 4. Source Address Validation 249 This section describes source address validation procedure on 250 packets. In this procedure, all the frames are assumed to have 251 passed the verifications of 802.11i or other security mechanisms. 253 This procedure has the following steps: 255 1. Extract the IP source and MAC source from the frame. Lookup the 256 MAC address in the MAC-IP Mapping Table and check if the MAC-IP 257 pair exists. If yes, forward the packet. Otherwise, go to step 258 2. 260 2. Look up the IP address in the IP-MAC Mapping Table and check if 261 the IP address exists. If not, go to step 3. If yes, check 262 whether the MAC address in the entry is the same as that in the 263 frame. If yes, forward the packet. Otherwise, drop the packet. 265 In step 2, after the packet is judged to be valid and forwarded, 266 synchronization between the MAC-IP and IP-MAC mapping tables should 267 be triggered. The MAC-IP binding of the packet should be 268 synchronized from IP-MAC mapping table to MAC-IP mapping table, and 269 thus the following packets with the same MAC-IP pair will be 270 forwarded without going to step 2. 272 5. Deployment Scenarios 274 This section specifies three deployment scenarios, including two 275 under centralized WLAN and one under autonomous WLAN. The deployment 276 details and solutions for host mobility between access points are 277 described respectively for each scenario. 279 5.1. Centralized WLAN 281 Centralized WLAN is comprised of FIT Access Points (AP) and Access 282 Controllers (AC). In this scenario, this document proposes the 283 following two deployment solutions. 285 5.1.1. AP Filtering 287 With this deployment solution, the validated data packets received by 288 an AP do not go through the AC, and only control packets and the 289 questionable data packets go through the AC. In this scenario, the 290 AC maintains IP-MAC Mapping Table, while the AP maintains MAC-IP 291 Mapping Table and performs address snooping. 293 5.1.1.1. Candidate Binding 295 An AP executes the procedure specified in Section 3.3. The candidate 296 bindings are generated after snooping procedure. Candidate bindings 297 must be confirmed by the AC to be valid. 299 After a candidate binding is generated, the AC is notified and checks 300 whether the binding is valid or not. The validity of a candidate 301 binding is determined if the binding does not violate any existing 302 bindings in the IP-MAC Mapping Table. Otherwise, if an address is 303 not suitable for a host to use, the AC notifies the corresponding AP. 304 If the candidate binding is valid, the AC adds an entry into the IP- 305 MAC Mapping Table and notifies the AP. Afterwards, the AP also adds 306 an entry into the local MAC-IP Mapping Table. 308 5.1.1.2. Packet Filtering 310 As specified in Section 4, for incoming data packets, an AP looks up 311 the MAC address in the local MAC-IP Mapping Table and checks if the 312 MAC-IP pair exists. If yes, the AP forwards the packet. Otherwise, 313 the AP delivers the packet to the AC for further processing. 315 When receiving a data packet from the AP, the AC looks up the IP 316 address in the local IP-MAC Mapping Table and checks if the IP 317 address exists. If not, the AC drops the packet. If yes, the AC 318 checks whether the MAC address in the entry is the same as that in 319 the frame. If yes, the AC forwards the packet. Otherwise, the AC 320 drops the packet. 322 After the AC forwards a valid packet, it synchronizes the related 323 MAC-IP binding to the MAC-IP mapping table on the AP from which the 324 packet comes. Following packets with the same MAC-IP pair will be 325 forwarded directly by the AP without going to the AC. 327 5.1.1.3. Negative Entries 329 In the AP Filtering scenario, APs MAY drop packets directly without 330 sending them to the AC by enabling the establishment of negative 331 entries on APs. Specifically, APs may establish negative entries in 332 the following circumstances. 334 1. When an AP receives a certain number of packets within a certain 335 amount of time with the same MAC-IP pair that does not exist in 336 the local MAC-IP Table, it establishes a negative entry for this 337 MAC-IP pair. Then the AP drops all following packets that have 338 the same MAC-IP pair as indicated in this negative entry without 339 sending them to the AC for further processing. 341 2. When an AP receives a certain number of packets within a certain 342 amount of time with the same MAC address but different MAC-IP 343 pairs and none of these MAC-IP pairs exist in the local MAC-IP 344 Table, it establishes a negative entry for this MAC address. Then 345 the AP drops all following packets that have the same MAC address 346 as indicated in this negative entry without sending them to the AC 347 for further processing. 349 Each negative entry has a limited lifetime. The number of packets 350 and duration of time to trigger the establishment of the negative 351 entry, and the lifetime of the negative entry are configurable. 353 5.1.1.4. CAPWAP Extension 355 CAPWAP protocol is used for communication between the AP and the AC. 356 A new CAPWAP protocol message element is introduced, which extends 357 [RFC5415]. The host IP message element is used by both the AP and 358 the AC to exchange the binding information of hosts. 360 The host IP message element can be used in the process of 361 confirmation of candidate bindings. When the AP generates a 362 candidate binding, it reports the MAC address and related IP 363 addresses to the AC using this message, with suggestions of the state 364 of each IP address as specified in Section 3.1.1. After the AC 365 checks the validation of the candidate binding, it replies using a 366 message of the same format to inform the AP of the validation of each 367 IP address with a suggested state. 369 The host IP message element can be used in the process of binding 370 migration. When migration happens, the source device uses this 371 message to report the MAC address and related IP addresses to the 372 destination device, with suggestions for the state of each IP address 373 as specified in Section 3.1.1. After the destination device checks 374 the validation of the candidate binding, it replies using a message 375 of the same format to inform the source device the validation of each 376 IP address with a suggested state. 378 The host IP message element can also be used in other scenarios when 379 the synchronization between MAC-IP and IP-MAC tables is required as 380 specified in Section 3.5 and Section 4. When the synchronization 381 from IP-MAC table to MAC-IP table is triggered, the source device 382 which holds the IP-MAC table reports the MAC address and the related 383 IP addresses to the destination device which holds the MAC-IP table 384 using this message, with suggestions of the state of each IP address 385 as specified in Section 3.1.1. The destination device replies using 386 a message of the same format to acknowledge the source device. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Radio ID | Total Length + 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Sender ID | Length | Description + 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | MAC flag | Length | MAC Address... + 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | MAC Address... + 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | IPv4 flag | Length | blank ... + 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | IPv4 Address 1(32 bit) + 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | State | blank ... + 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | lifetime + 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | IPv4 Address 2(32 bit) + 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | State | blank ... + 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | lifetime + 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | ........ + 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | IPv4 Address n(32 bit) + 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | State | blank ... + 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | lifetime + 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | IPv6 flag | Length | IPv6 Address... + 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | IPv6 Address 1(128 bit) + 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | State | blank ... + 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | lifetime + 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | IPv6 Address 2(128 bit) + 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | State | blank ... + 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | lifetime + 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | ........ + 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | IPv6 Address n(128 bit) + 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | State | blank ... + 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | lifetime + 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | BSSID flag | Length | BSSID... + 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | BSSID + 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Radio ID: An 8-bit value representing the radio, whose value is 449 between 1 and 31. 451 Total Length: Total length of the following fields. 453 Sender ID: An 8-bit value representing the sender of the message. AP 454 is represented by value 1 and AC is represented by value 2. 456 Length: The length of the Value field. 458 Description: A 16-bit value for a description of the sender (AP or 459 AC). 461 MAC flag: An 8-bit value representing that the sub-field's type is 462 MAC address, whose value is 1. 464 Length: The length of the MAC Address field. The formats and lengths 465 specified in EUI-48 and EUI-64 [EUI] are supported. 467 MAC Address: A MAC address of the host. At least one MAC address 468 block MUST appear in the message, otherwise the message is considered 469 as invalid. 471 IPv4 flag: An 8-bit value representing that the sub-field's type is 472 IPv4 address, whose value is 2. 474 Length: The length of the IPv4 Address field. 476 IPv4 Address: An IPv4 address of the host. There may exist many 477 entries, and each entry is comprised of an IPv4 address, an 8-bit 478 value for address state (value 1 means available, value 0 means 479 unavailable, value 255 means candidate), and a 32-bit value for 480 lifetime. Lifetime is a reserved field for future application under 481 abnormal conditions. It is required to list all IPv4 addresses 482 before IPv6 address blocks. 484 IPv6 flag: An 8-bit value representing that the sub-field's type is 485 IPv6 address, a DHCPv6-assigned IP address represented by value 3 and 486 a locally assigned IP address represented by value 4. 488 Length: The length of the IPv6 Address field. 490 IPv6 Address: An IPv6 address of the host. There may exist many 491 entries, and each entry is comprised of an IPv6 address, an 8-bit 492 value of address state (value 1 means available, value 0 means 493 unavailable, value 255 means candidate), and a 32-bit value lifetime. 494 Lifetime is a reserved field for future application under abnormal 495 conditions. All IPv4 and IPv6 addresses bind to the MAC address that 496 appears before them in the message. 498 BSSID flag: An 8-bit value representing that the sub-field's type is 499 BSSID, whose value is 5. 501 Length: The length of the BSSID field. The formats and lengths 502 specified in EUI-48 and EUI-64 [EUI] are supported. 504 BSSID: A basic service set identifier representing the BSS. 506 5.1.1.5. Mobility Solution 508 When a host moves from one AP to another, layer-2 association happens 509 before the IP packets are forwarded. The home AP deletes the binding 510 when mobile host is disconnected, and the foreign AP immediately 511 requests the bound addresses with the associated MAC from the AC. 512 The AC returns the binding with a suggested state. After the foreign 513 AP get the addresses should be bound, the binding migration is 514 completed. The protocol used for communication between the foreign 515 AP and the AC is the same as described in Section 5.1.1.4, while in 516 this scenario, the AC serves the role of the source device and the 517 foreign AP serves the role of the destination device. 519 In WLAN, a host can move from an AC to another AC while keeping using 520 the same IP address. To be compatible with such scenario, ACs must 521 communicate to perform the binding migration. The protocol used for 522 communication between ACs is the same as described in 523 Section 5.1.1.4, while in this scenario the home AC serves the role 524 of the source device and the foreign AC serves the role of the 525 destination device. 527 5.1.2. AC Filtering 529 In this scenario, an AC maintains both MAC-IP and IP-MAC Mapping 530 Table and performs both address snooping and packet filtering. So, 531 all the packets must be forwarded to the AC first. 533 The AC executes the procedure specified in Section 3.3 and checks the 534 validity of IP-MAC pairs by consulting the local IP-MAC mapping 535 table. No extra procedure is needed to establish the IP-MAC 536 bindings. 538 The AC executes the procedure specified in Section 4 for packet 539 filtering, and no extra procedure is involved. 541 Mobility within one AC does not trigger any binding migration. 542 Mobility between different ACs triggers binding migration. ACs must 543 communicate to perform the binding migration. The protocol used for 544 communication between ACs is the same as described in 545 Section 5.1.1.4, while in this scenario the home AC serves the role 546 of the source device and the foreign AC serves the role of the 547 destination device. 549 5.2. Autonomous WLAN 551 Autonomous WLAN is comprised of FAT Access Points. In this scenario, 552 a FAT AP maintains both MAC-IP and IP-MAC Mapping Table and performs 553 both address snooping and packet filtering. 555 The FAT AP executes the procedure specified in Section 3.3 and checks 556 the validity of IP-MAC pairs by consulting the local IP-MAC mapping 557 table. No extra procedure is needed to establish the IP-MAC 558 bindings. 560 The FAT AP executes the procedure specified in Section 4 for packet 561 filtering, and no extra procedure is involved. 563 Mobility between different FAT APs will trigger binding migration. 564 FAT APs must communicate to perform the binding migration. The 565 protocol used for communication between FAT APs is the same as 566 described in Section 5.1.1.4, while in this scenario the home FAT AP 567 serves the role of the source device and the foreign FAT AP serves 568 the role of the destination device. 570 6. IANA Considerations 572 There is no IANA consideration currently. 574 7. Security Considerations 576 The security of address allocation methods matters the security of 577 this mechanism. Thus, it is necessary to improve the security of 578 stateless auto-configuration and DHCP first. 580 7.1. Privacy Considerations 582 A SAVI device MUST delete binding anchor information as soon as 583 possible, except where there is an identified reason why that 584 information is likely to be involved in the detection, prevention, or 585 tracing of actual source-address spoofing. Information about hosts 586 that never spoof (probably the majority of hosts) SHOULD NOT be 587 logged. 589 8. Acknowledgements 591 The authors would like to thank Guang Yao, Yang Shi, and Hao Wang for 592 their contributions to this document. 594 9. References 596 9.1. Normative References 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, 600 DOI 10.17487/RFC2119, March 1997, 601 . 603 9.2. Informative References 605 [EUI] IEEE Standards Association, "Guidelines for Use of 606 Extended Unique Identifier (EUI), Organizationally Unique 607 Identifier (OUI), and Company ID (CID)", 2017, 608 . 611 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 612 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 613 DOI 10.17487/RFC4861, September 2007, 614 . 616 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 617 Address Autoconfiguration", RFC 4862, 618 DOI 10.17487/RFC4862, September 2007, 619 . 621 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 622 Ed., "Control And Provisioning of Wireless Access Points 623 (CAPWAP) Protocol Specification", RFC 5415, 624 DOI 10.17487/RFC5415, March 2009, 625 . 627 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 628 Validation Improvement (SAVI) Solution for DHCP", 629 RFC 7513, DOI 10.17487/RFC7513, May 2015, 630 . 632 Authors' Addresses 634 Jun Bi 635 Tsinghua University 636 Beijing 100084 637 China 639 Email: junbi@cernet.edu.cn 641 Jianping Wu 642 Tsinghua University 643 Beijing 100084 644 China 646 Email: jianping@cernet.edu.cn 648 Tao Lin 649 New H3C Technologies Co. Ltd 650 466 Changhe Road, Binjiang District 651 Hangzhou, Zhejiang 310052 652 China 654 Email: lintao@h3c.com 655 You Wang 656 Tsinghua University 657 Beijing 100084 658 China 660 Email: you@opennetworking.org 662 Lin He 663 Tsinghua University 664 Beijing 100084 665 China 667 Email: he-l14@mails.tsinghua.edu.cn