idnits 2.17.1 draft-bi-savi-cps-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC3315], [RFC2131], [SAVI-framework]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2009) is 5266 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC2131' is mentioned on line 381, but not defined == Missing Reference: 'RFC3315' is mentioned on line 381, but not defined ** Obsolete undefined reference: RFC 3315 (Obsoleted by RFC 8415) == Missing Reference: 'SAVI-framework' is mentioned on line 319, but not defined == Missing Reference: 'BCP38' is mentioned on line 147, but not defined == Missing Reference: 'RFC4861' is mentioned on line 174, but not defined == Missing Reference: 'RFC4429' is mentioned on line 645, but not defined Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SAVI J. Bi, G. Yao, J. Wu 2 Internet Draft CERNET 3 Intended status: Standard Tracks F. Baker 4 Expires: April 2010 October 27, 2009 6 SAVI Solution for DHCPv4/v6 7 draft-bi-savi-cps-02.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. This document may not be modified, 13 and derivative works of it may not be created, except to publish it 14 as an RFC and to translate it into languages other than English. 16 This document may contain material from IETF Documents or IETF 17 Contributions published or made publicly available before November 10, 18 2008. The person(s) controlling the copyright in some of this 19 material may not have granted the IETF Trust the right to allow 20 modifications of such material outside the IETF Standards Process. 21 Without obtaining an adequate license from the person(s) controlling 22 the copyright in such materials, this document may not be modified 23 outside the IETF Standards Process, and derivative works of it may 24 not be created outside the IETF Standards Process, except to format 25 it for publication as an RFC or to translate it into languages other 26 than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on April 27, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document specifies the procedure of setting up bindings between 59 DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and 60 anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation 61 Improvements) device. The bindings can be used to filter packets with 62 forged IP addresses. 64 Table of Contents 66 1. Introduction ................................................ 3 67 2. Conventions used in this document............................ 4 68 3. Mechanism Overview .......................................... 4 69 4. Background and Related Protocols............................. 4 70 5. Terminology ................................................. 5 71 6. Conceptual Data Structures................................... 5 72 6.1. Binding State Table (BST)............................... 5 73 6.2. Filtering Table (FT).................................... 5 74 7. Binding States Description................................... 6 75 8. DHCP Scenario ............................................... 6 76 9. Anchor Attributes ........................................... 7 77 9.1. SAVI-Host Attribute..................................... 7 78 9.2. SAVI-Poly Attribute..................................... 7 79 9.3. SAVI-DHCP-Trust Attribute............................... 7 80 9.4. SAVI-RA-Trust Attribute................................. 8 81 10. Prefix Configuration........................................ 8 82 11. Binding Set Up ............................................. 9 83 11.1. Process of DHCP Snooping............................... 9 84 11.1.1. Initialization.................................... 9 85 11.1.1.1. Trigger Event................................ 9 86 11.1.1.2. Message Validation........................... 9 87 11.1.1.3. Following Actions............................ 9 88 11.1.2. From START to LIVE............................... 10 89 11.1.2.1. Trigger Event............................... 10 90 11.1.2.2. Message Validation.......................... 10 91 11.1.2.3. Following Actions........................... 10 92 11.1.3. From LIVE to DETECTION........................... 11 93 11.1.3.2. Message Validation.......................... 11 94 11.1.3.3. Following Actions........................... 11 95 11.1.4. From DETECTION to BOUND.......................... 12 96 11.1.4.1. Trigger Event............................... 12 97 11.1.4.2. Following Actions........................... 12 98 11.1.5. After BOUND...................................... 12 99 11.2. State Machine of DHCP Snooping ....................... 12 100 12. Filtering Specification.................................... 13 101 12.1. Filter Data Packet.................................... 13 102 12.2. Filter Control Packet................................. 13 103 13. Handle port UP/DOWN event.................................. 14 104 13.1. On port DOWN event.................................... 14 105 13.2. On port UP event...................................... 14 106 14. About Collision in Detection............................... 14 107 14.1. Whether to notify the DHCP server .................... 15 108 14.2. The result of detection without host aware ........... 15 109 15. Filtering during detection................................. 15 110 16. Binding Number Limitation.................................. 15 111 17. Constants ................................................. 15 112 18. Summary of to-be-removed sections and open issues ......... 16 113 19. Security Considerations.................................... 16 114 20. IANA Considerations........................................ 16 115 21. References ................................................ 17 116 21.1. Normative References.................................. 17 117 21.2. Informative References................................ 17 118 22. Acknowledgments ........................................... 17 120 1. Introduction 122 This document describes the procedure of setting up bindings between 123 DHCP assigned address and anchor (refer to [savi-framework]). Other 124 related details about this procedure are also specified in this 125 document. 127 These bindings can be used to filter packets with forged IP addresses. 128 How to use these bindings is specified in [savi-framework], depending 129 on the environment and configuration. The definition and examples of 130 anchor is also specified in [savi-framework]. 132 The binding process is inspired by the work of IP source guard. This 133 specification is different from IP source guard on the specification 134 on collision detection, which is quite useful in an environment with 135 multiple address assignment methods. 137 2. Conventions used in this document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Mechanism Overview 145 The mechanism specified in this document is designed to provide a 146 host level source IP address validation granularity, as a supplement 147 of BCP38 [BCP38]. This mechanism is deployed on the access device 148 (including access switch, wireless access point/controller, etc), and 149 performs DHCPv4/v6 snooping to set up bindings between DHCP assigned 150 IP address and corresponding anchors. The bindings can be used to 151 validate the source address in the packets. 153 4. Background and Related Protocols 155 This mechanism is an instance of SAVI [savi-framework] solution, 156 specialized for addresses assign through DHCP protocol. 158 Dynamic Host Configuration Protocol version 4 [RFC2131] and Dynamic 159 Host Configuration Protocol version 6 [RFC3315] specify the 160 procedures of providing a client with assigned address and other 161 configuration information from a DHCP server. If a client gets an 162 address through DHCP protocol, the address should be regarded as a 163 potential "authorized" or "registered" address of the client. 165 In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is used as 166 another address assignment mechanism. A node can use this mechanism 167 to auto-configure an IPv6 address. A DHCPv6 client may use a 168 stateless address to send message to DHCP server. Even in a DHCPv6 169 only environment, a node must assign its link-local address through 170 this mechanism. [RFC4862] also clearly requires that duplicated 171 address detection must be performed on any IPv6 address, including 172 DHCPv6 address. 174 [RFC4861] specifies the Neighbor Discovery protocol, which is an 175 essential part of IPv6 address assignment. 177 [RFC5227] specifies the procedure to detect IPv4 address collision. 178 It is not enforcement currently. However, this feature is useful to 179 determine the uniqueness of an IPv4 address on the link. 181 5. Terminology 183 The terms used in this document are described in [savi-framework], 184 [RFC2131] and [RFC3315]. 186 6. Conceptual Data Structures 188 (To be removed and merged with data structures used by other 189 mechanisms in [savi-framework] if possible) 191 This section describes the possible conceptual data structures used 192 in this mechanism. 194 Two main data structures are used to record bindings and their states 195 respectively. There are redundancy between the two structures, for 196 the consideration of separation of data plane and control plane. 198 6.1. Binding State Table (BST) 200 This table contains this state of binding between source address and 201 anchor. Entries are keyed on the anchor and source IP address. Each 202 entry has a lifetime item recording the remaining lifetime of this 203 entry, a state item recording the state of this binding and an item 204 recording other information. 206 +---------+----------+-------+-----------+-------+ 207 | Anchor | Address | State | Lifetime |Other | 208 +---------+----------+-------+-----------+-------+ 209 | A | IP_1 | Bound | 65535 | | 210 +---------+----------+-------+-----------+-------+ 211 | A | IP_2 | Bound | 10000 | | 212 +---------+----------+-------+-----------+-------+ 213 | B | IP_3 |_Start | 1 | | 214 +---------+----------+-------+-----------+-------+ 215 Figure 1 Instance of BST 217 6.2. Filtering Table (FT) 219 This table contains the bindings between anchor and address, keyed on 220 anchor. This table doesn't contain any state of the binding. This 221 table is only used to filter packet. Access Control List can be 222 regarded as a practical instance of this table. 224 +---------+----------+ 225 |Anchor |Address | 226 +---------+----------+ 227 |A |IP_1 | 228 +---------+----------+ 229 |A |IP_2 | 230 +---------+----------+ 231 Figure 2 Instance of FT 233 7. Binding States Description 235 This section describes the binding states of this mechanism. 237 START A DHCP request (or a DHCPv6 Confirm) is received from 238 host, and it may trigger a new binding. 240 LIVE A DHCP address is acknowledged by a DHCP server. 242 DETECTION A gratuitous ARP or Duplicate Address Detection NSOL 243 has been sent by the host (or the SAVI device). 245 BOUND The address has passed duplicate detection and 246 it is bound with the anchor. 248 8. DHCP Scenario 250 (This section should be removed and merged with other scenarios in 251 [savi-framework]) 253 This section specifies the deployment scenarios of this mechanism. 255 +--------+ 256 | DHCP | 257 | Server | 258 +-------,+ 259 `. 260 `. 261 `. 262 +----'-----+ 263 | SAVI | 264 | Device | 265 +-/------/-+ 266 | | 267 +----\-+ +\-----+ 268 |DHCP | |Client| 269 |Relay | | | 270 +------+ +------+ 271 Figure 3 DHCP Scenario 273 9. Anchor Attributes 275 This section specifies the anchor attributes involved in this 276 mechanism. 278 9.1. SAVI-Host Attribute 280 (This attribute should be described in the [savi-framework]) 282 If and only if an anchor is exclusively associated with a single host, 283 this anchor can be set to have SAVI-Host attribute. 285 9.2. SAVI-Poly Attribute 287 (This attribute should be described in the [savi-framework]) 289 If an anchor is associated with a small number of hosts through a 290 converge device, this anchor can be set to have SAVI-Poly attribute. 291 SAVI-Poly attribute is a conflict attribute of SAVI-Host attribute. 293 The main different process on anchor with SAVI-Poly attribute from 294 that with SAVI-Host attribute is the policy of binding consistence. 296 9.3. SAVI-DHCP-Trust Attribute 298 If and only if an anchor is associated with a trustable DHCP 299 server/relay, it can be set to have this attribute. 301 If DHCP is used to assign address in the network, there MUST be at 302 least one anchor with this attribute. DHCP Reply message not from 303 such ports MUST be dropped. 305 9.4. SAVI-RA-Trust Attribute 307 (This attribute should be described in the [savi-framework]) 309 If and only if an anchor is associated with a trustable router, it 310 can be set to have this attribute. 312 There MAY be no SAVI-RA-Trust anchor on a SAVI device. 314 Router Advertisement received not from SAVI-RA-Trust anchor MUST be 315 discarded. 317 10. Prefix Configuration 319 (This section should be included in [SAVI-framework] but not this 320 document.) 322 Before setting up a host-level granularity binding table, it is 323 important to configure correct prefixes on the SAVI device. At least 324 two prefix scopes must be set: the IPv4 prefix and IPv6 prefixes. 325 This document suggests set 3 prefix scopes: 327 IPv4 Prefix: 329 The allowed scope of any kind of IPv4 addresses. It can be set 330 manually. 332 IPv6 SLAAC Prefixes: 334 The allowed scope of SLAAC and manually configured IPv6 335 addresses. It can be set through snooping RA message from port 336 with SAVI-RA-Trust attribute, or manual configuration. 338 FE80::/64 MUST be set to a feasible prefix. 340 IPv6 DHCPv6 Prefixes: 342 The allowed scope of DHCPv6 addresses. It can be set through 343 DHCP-PD protocol, or manual configuration. 345 If some of the prefix scope is set to have non prefix, it implies 346 corresponding address assignment method is not allowed in the network. 348 There is no need to explicitly present these prefix scopes. But these 349 restrictions MUST be used as premier check in binding set up. 351 11. Binding Set Up 353 This section specifies the procedure of setting up bindings based on 354 control packet snooping. 356 11.1. Process of DHCP Snooping 358 11.1.1. Initialization 360 (Whether to keep this section is left for future discussion) 362 11.1.1.1. Trigger Event 364 A DHCPv4/v6 Request or a DHCPv6 Confirm is received with an anchor 365 which has the attribute of SAVI-Host or SAVI-Poly. 367 11.1.1.2. Message Validation 369 The SAVI device checks the Request or Confirm as follows: 371 1. Whether the limitation on binding entry number of this anchor will 372 be exceeded. 374 11.1.1.3. Following Actions 376 Forward the REQUEST message. 378 Generate an entry in the Binding State Table (BST), and set the state 379 field to be START. The lifetime of this entry is set to be 380 MAX_DHCP_RESPONSE_TIME. The Transaction ID (Refer to Section 2 in 381 [RFC2131] and Section 4.2 in [RFC3315]) field of the request packet 382 is also recorded in the entry. 384 +---------+----------+-------+-----------------------+-------+ 385 | Anchor | Address | State | Lifetime |Other | 386 +---------+----------+-------+-----------------------+-------+ 387 | A | | Start |MAX_DHCP_RESPONSE_TIME | TID | 388 +---------+----------+-------+-----------------------+-------+ 389 Figure 4 Binding entry in BST on initialization 391 The TID is kept for assurance that the response from DHCP server can 392 be delivered to the request host. This is left as an open issue for 393 future discussion. 395 11.1.2. From START to LIVE 397 11.1.2.1. Trigger Event 399 A DHCPv4 DHCPACK or DHCPv6 REPLY message is received. 401 11.1.2.2. Message Validation 403 The SAVI device checks the message as follows: 405 1. Whether the message is received with an anchor which has SAVI- 406 DHCP-Trust attribute; 408 2. Whether the entry in the BST with corresponding TID is in state of 409 START. 411 11.1.2.3. Following Actions 413 Deliver the message to the destination. 415 Set the state of the corresponding entry to be LIVE. The lifetime of 416 the entry is set to be MAX_ARP_PREPARE_DELAY or MAX_DAD_PREPARE_DELAY 417 respectively. The lease time is also recorded in the entry. 419 +---------+----------+-------+------------------------+-------+ 420 | Anchor | Address | State | Lifetime |Other | 421 +---------+----------+-------+------------------------+-------+ 422 | A | Addr | LIVE |MAX_ARP_PREPARE_DELAY or| Lease | 423 | | | |MAX_DAD_PREPARE_DELAY | Time | 424 +---------+----------+-------+------------------------+-------+ 425 Figure 5 Binding entry in BST on assignment 427 Or set the state of the corresponding entry to be DETECTION, and send 428 an ARP Request or NSOL for the assigned address. 430 +---------+----------+-----------+-----------------+-------+ 431 | Anchor | Address | State | Lifetime |Other | 432 +---------+----------+-----------+-----------------+-------+ 433 | A | Addr | DETECTION |MAX_ARP_DELAY or| Lease | 434 | | | |MAX_DAD_DELAY | Time | 435 +---------+----------+-----------+-----------------+-------+ 436 Figure 6 Binding entry in BST on assignment: another case 438 Insert an entry into the Filtering Table if the assigned address is 439 not bound with another anchor. 441 +---------+----------+ 442 |Anchor |Address | 443 +---------+----------+ 444 |A |Addr | 445 +---------+----------+ 446 Figure 7 Binding entry in FT on assignment 448 11.1.3. From LIVE to DETECTION 450 (This section should be removed or modified if all the DAD related 451 procedures are to be described in SLAAC document) 453 11.1.3.1. Trigger Event 455 A gratuitous ARP Request or Duplicate Address Detection Neighbor 456 Solicitation is received from the host. Or a timeout event of an 457 entry with state LIVE happens. 459 11.1.3.2. Message Validation 461 The SAVI device checks the message as follows: 463 1. Whether the Target IP address field of the ARP Request or Neighbor 464 Solicitation has been bound with the corresponding anchor in BST 465 or FT. 467 11.1.3.3. Following Actions 469 If timeout event of an entry with state LIVE happens, send an ARP 470 Request or a DAD NSOL, with target address set to the recorded 471 address in the entry. 473 Set the state of the entry to be DETECTION. The lifetime of the entry 474 is set to be MAX_ARP_DELAY or MAX_DAD_DELAY respectively. 476 +---------+----------+-----------+-----------------+-------+ 477 | Anchor | Address | State | Lifetime |Other | 478 +---------+----------+-----------+-----------------+-------+ 479 | A | Addr | DETECTION |MAX_ARP_DELAY or| Lease | 480 | | | |MAX_DAD_DELAY | Time | 481 +---------+----------+-----------+-----------------+-------+ 482 Figure 8 Binding entry in BST on detection 484 11.1.4. From DETECTION to BOUND 486 11.1.4.1. Trigger Event 488 A timeout event of an entry with state DETECTION happens or an ARP 489 Response or NA for an address in BST with state DETECTION is received. 491 11.1.4.2. Following Actions 493 If a timeout event of an entry with state DETECTION happens, set the 494 state of the entry to be BOUND. The lifetime of the entry is set to 495 be the Lease time acknowledged by DHCP server. 497 +---------+----------+-----------+----------------+-------+ 498 | Anchor | Address | State | Lifetime |Other | 499 +---------+----------+-----------+----------------+-------+ 500 | A | Addr | BOUND | Lease time | | 501 +---------+----------+-----------+----------------+-------+ 502 Figure 9 Binding entry in BST on finalization 504 If an ARP Response or NA for an address in BST with state DETECTION 505 is received, remove the corresponding entry in BST and FT. 507 11.1.5. After BOUND 509 Whenever a DHCP Decline is received from the host, delete the entry 510 in BST and FT. 512 Whenever a DHCP Release is received from the host, if the state of 513 the entry is BOUND, delete the entry in BST and FT. 515 If a DHCPv4 Acknowledgement or DHCPv6 Reply with Renew/Rebind sign is 516 received from the server, set lifetime of the entry in BST to be the 517 new lease time. 519 If the lifetime of an entry with state BOUND expires, delete the 520 entry in BST and Filter Table. 522 11.2. State Machine of DHCP Snooping 524 State Packet/Event Action Next State 526 - REQUEST/CONFIRM Set up new entry START 528 START ACK Record lease tim LIVE 530 START Timeout Remove entry - 531 LIVE Gra ARP REQ/DAD NS - DETECTION 533 LIVE DECLINE Remove entry - 535 LIVE Timeout Send ARP Req/DAD NS DETECTION 537 DETECTION Timeout - BOUND 539 DETECTION ARP RESPONSE Remove entry - 541 DETECTION DECLINE Remove entry - 543 BOUND RELEASE/DECLINE Remove entry - 545 BOUND Timeout Remove entry - 547 BOUND RENEW/REBOUND Set new lifetime BOUND 549 12. Filtering Specification 551 This section specifies how to use bindings to filtering packets. 553 12.1. Filter Data Packet 555 Data packets with anchor which has attribute SAVI-Host or SAVI-Poly 556 are filtered. There can be anchor with neither attributes. 558 If the source of a packet associated with its anchor is in the FT, 559 this packet will be forwarded; or else the packet MUST be discarded. 561 12.2. Filter Control Packet 563 The source address of DHCPv4 Request/Discovery must be all zero 564 address. 566 The source address of DHCPv6 Request/Confirm must be an address 567 associated with the corresponding anchor in FT. 569 The source address of IPv6 DAD NS and IPv6 gratuitous ARP must pass 570 the check on FT. 572 All DHCP Reply/Ack packets MUST be from anchor with SAVI-DHCP-Trust 573 attribute. 575 The target address and source address in all the Neighbor 576 Advertisement packets and ARP relies must also pass the checks on FT, 577 if they are associated with anchors which have SAVI-Host or SAVI-Poly 578 attribute. 580 13. Handle port UP/DOWN event 582 These events must be handled when port is used as anchor. 584 13.1. On port DOWN event 586 Whenever a port with attribute SAVI-Poly or SAVI-Host turns down, the 587 bindings with the anchor SHOULD be 589 1: removed immediately; 591 2: or kept until lease time expires; 593 3: or kept for a short time. 595 The reason for why three choices are made here is there is no perfect 596 solution. 598 If bindings are removed immediately when port turns down, the device 599 may discard legal packets when the link is very flappy. However, this 600 solution has the lightest overhead and simplest design. 602 If bindings are kept until lease time expires, the device can handle 603 the flappy link problem. The device then should make a choice whether 604 to keep the bindings or give up them whenever a Duplicate Address 605 Detection Neighbor Solicitation for the bound address arrives. Either 606 choice actually may lead to some problem. 608 If bindings are kept just for a short time, the flappy link problem 609 can also be handled. Also the device would seldom face the DAD NS for 610 the bound address in that short time. The main problem of this 611 solution is how to set the length of this time. 613 13.2. On port UP event 615 Whenever a port turns UP, the device can choose either to restore the 616 bindings not removed, or restore the bindings whenever the node uses 617 the address. 619 14. About Collision in Detection 621 The SAVI device may receive a response in detection. Some related 622 details are specified here. 624 14.1. Whether to notify the DHCP server 626 It is unnecessary for the SAVI device to notify the DHCP server, 627 because the host will send a DECLINE message to it once it finds the 628 advertised address is conflict. 630 14.2. The result of detection without host aware 632 In case the SAVI device send detection packet instead of the host, 633 the host will not get aware of the detection result. If the detection 634 succeeds, there is no trouble. However, if the detection fails, the 635 packets from the host with the assigned address will be filtered out. 636 This result can be regarded as a reasonable punishment for not 637 performing duplicate detection and using a collision address. 639 15. Filtering during detection 641 In this mechanism, whenever the DHCP server replies an address, this 642 address will be allowed immediately even before duplicate detection 643 is completed. This design is in consideration of a host may start to 644 send packets straightway without detection. Also this design is to be 645 compatible with optimistic DAD [RFC4429]. 647 However, this feature may allow an attacker to send quantities of 648 packets with source addresses already assigned to other nodes. A 649 practical solution for this vulnerability is configuring the address 650 pool and allocation algorithm of the DHCP server carefully. 652 16. Binding Number Limitation 654 It is suggested to configure some mechanism in order to prevent a 655 single node from exhausting the binding table entries on the SAVI 656 device. Either of the following mechanism is sufficient to prevent 657 such attack. 659 1. Set the upper bound of binding number for each anchor with SAVI- 660 Host or SAVI-Poly attribute. 662 2. Reserve a number of binding entries for each anchor with SAVI-Host 663 or SAVI-Poly attribute and all anchors share a pool of the other 664 binding entries. 666 17. Constants 668 MAX_DHCP_RESPONSE_TIME 120s 670 MAX_ARP_PREPARE_DELAY Default 1s but configurable 671 MAX_ARP_DELAY Default 1s but configurable 673 MAX_DAD_PREPARE_DELAY Default 1s but configurable 675 MAX_DAD_DELAY Default 1s but configurable 677 18. Summary of to-be-removed sections and open issues 679 To-be-removed sections: 681 1. Section 6: Conceptual data structures 683 2. Section 8: DHCP scenario 685 3. Part of Section 9: Anchor attributes 687 4. Section 10: Prefix configuration 689 Open issues (discussed but not finished): 691 1. Whether to keep state START 693 Should the procedure be initialized based on client request or 694 server response? 696 From Eric Levy-Abegnoli and Christian Vogt. 698 2. Whether to keep state DETECTION 700 Should DHCP interact with NDP to detect collision or should all 701 the collision detection be left to NDP and the DHCP solution just 702 snoop DHCP only? 704 From Eric Levy-Abegnoli. 706 19. Security Considerations 708 There are no security considerations currently. 710 20. IANA Considerations 712 There is no IANA consideration currently. 714 21. References 716 21.1. Normative References 718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 719 Requirement Levels", BCP 14, RFC 2119, March 1997. 721 [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless 722 Autoconfiguration", RFC4862, September, 2007. 724 [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, 725 July 2008. 727 21.2. Informative References 729 22. Acknowledgments 731 Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun, Alberto 732 Garcia, Eric Levy-Abegnoli, Jari Arkko, David Harrington, Pekka Savola, 733 Xing Li, Lixia Zhang, Robert Raszuk, Greg Daley, Joel M. Halpern and Tao 734 Lin for their valuable contributions. 736 Authors' Addresses 738 Jun Bi 739 CERNET 740 Network Research Center, Tsinghua University 741 Beijing 100084 742 China 743 Email: junbi@cernet.edu.cn 745 Guang Yao 746 CERNET 747 Network Research Center, Tsinghua University 748 Beijing 100084 749 China 750 Email: yaog@netarchlab.tsinghua.edu.cn 752 Jianping Wu 753 CERNET 754 Computer Science, Tsinghua University 755 Beijing 100084 756 China 757 Email: jianping@cernet.edu.cn 759 Fred Baker 760 Cisco Systems 761 Email: fred@cisco.com