idnits 2.17.1 draft-bi-savi-dhcp-00.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 11 instances of too long lines in the document, the longest one being 10 characters 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: MUST not deliver to the host which the SAVI device is performing DAD on behavior of. == 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 (November 9, 2009) is 5281 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC2131' is mentioned on line 409, but not defined == Missing Reference: 'RFC3315' is mentioned on line 409, but not defined ** Obsolete undefined reference: RFC 3315 (Obsoleted by RFC 8415) == Missing Reference: 'SAVI-framework' is mentioned on line 335, but not defined == Missing Reference: 'BCP38' is mentioned on line 151, but not defined == Missing Reference: 'RFC4861' is mentioned on line 628, but not defined == Missing Reference: 'RFC3307' is mentioned on line 622, but not defined == Missing Reference: 'RFC4429' is mentioned on line 731, but not defined Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SAVI J. Bi, J. Wu, G. Yao 2 Internet Draft CERNET 3 Intended status: Standard Tracks F. Baker 4 Expires: May 2010 Cisco 5 November 9, 2009 7 SAVI Solution for DHCPv4/v6 8 draft-bi-savi-dhcp-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be modified, 14 and derivative works of it may not be created, except to publish it 15 as an RFC and to translate it into languages other than English. 17 This document may contain material from IETF Documents or IETF 18 Contributions published or made publicly available before November 10, 19 2008. The person(s) controlling the copyright in some of this 20 material may not have granted the IETF Trust the right to allow 21 modifications of such material outside the IETF Standards Process. 22 Without obtaining an adequate license from the person(s) controlling 23 the copyright in such materials, this document may not be modified 24 outside the IETF Standards Process, and derivative works of it may 25 not be created outside the IETF Standards Process, except to format 26 it for publication as an RFC or to translate it into languages other 27 than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on May 9, 2010. 46 Copyright Notice 48 Copyright (c) 2009 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 in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document specifies the procedure for creating bindings between a 60 DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and an 61 anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation 62 Improvements) device. The bindings can be used to filter packets with 63 forged IP addresses generated on the local link. 65 Table of Contents 67 1. Introduction ................................................ 3 68 2. Conventions used in this document............................ 4 69 3. Mechanism Overview .......................................... 4 70 4. Background and Related Protocols............................. 4 71 5. Terminology ................................................. 5 72 6. Conceptual Data Structures................................... 5 73 6.1. Binding State Table (BST)............................... 5 74 6.2. Filtering Table (FT).................................... 5 75 7. Binding States Description................................... 6 76 8. DHCP Scenario ............................................... 6 77 9. Anchor Attributes ........................................... 7 78 9.1. SAVI-Host Attribute..................................... 7 79 9.2. SAVI-Poly Attribute..................................... 7 80 9.3. SAVI-DHCP-Trust Attribute............................... 7 81 9.4. SAVI-RA-Trust Attribute................................. 8 82 9.5. SAVI-SAVI Attribute..................................... 8 83 10. Prefix Configuration........................................ 8 84 11. Binding Set Up ............................................. 9 85 11.1. Process of DHCP Snooping............................... 9 86 11.1.1. Initialization.................................... 9 87 11.1.1.1. Trigger Event................................ 9 88 11.1.1.2. Message Validation........................... 9 89 11.1.1.3. Following Actions........................... 10 90 11.1.2. From START to LIVE............................... 10 91 11.1.2.1. Trigger Event............................... 10 92 11.1.2.2. Message Validation.......................... 10 93 11.1.2.3. Following Actions........................... 10 94 11.1.3. From LIVE to DETECTION........................... 11 95 11.1.3.2. Message Validation.......................... 11 96 11.1.3.3. Following Actions........................... 12 97 11.1.4. From DETECTION to BOUND.......................... 12 98 11.1.4.1. Trigger Event............................... 12 99 11.1.4.2. Following Actions........................... 12 100 11.1.5. After BOUND...................................... 12 101 11.2. State Machine of DHCP Snooping ....................... 13 102 12. Filtering Specification.................................... 13 103 12.1. Filter Data Packet.................................... 13 104 12.2. Filter Control Packet................................. 14 105 13. Format and Delivery of Probe Messages ..................... 14 106 14. Data packet trigger on SAVI-Poly anchor ................... 15 107 15. Binding Remove ............................................ 16 108 16. Handle port DOWN event..................................... 16 109 17. About Collision in Detection............................... 16 110 17.1. Whether to notify the DHCP server .................... 16 111 17.2. The result of detection without host aware ........... 16 112 18. Filtering during detection................................. 17 113 19. Binding Number Limitation.................................. 17 114 20. MLD Consideration ......................................... 17 115 21. Constants ................................................. 17 116 22. Summary of to-be-removed sections and open issues ......... 18 117 23. Security Considerations.................................... 18 118 24. IANA Considerations........................................ 18 119 25. References ................................................ 18 120 25.1. Normative References.................................. 18 121 25.2. Informative References................................ 19 122 26. Acknowledgments ........................................... 19 124 1. Introduction 126 This document describes the procedure for creating bindings between 127 DHCP assigned addresses and an anchor (refer to [savi-framework]). 128 Other related details about this procedure are also specified in this 129 document. 131 These bindings can be used to filter packets with forged IP addresses. 132 How to use these bindings is specified in [savi-framework], depending 133 on the environment and configuration. The definition and examples of 134 anchor is also specified in [savi-framework]. 136 The binding process is inspired by the work of IP source guard. This 137 specification differs from IP source guard in the specification for 138 collision detection, which is quite useful in an environment with 139 multiple address assignment methods. 141 2. Conventions used in this document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 3. Mechanism Overview 149 The mechanism specified in this document is designed to provide a 150 host level source IP address validation granularity, as a supplement 151 to BCP38 [BCP38]. This mechanism is deployed on the access device 152 (including access switch, wireless access point/controller, etc), and 153 performs mainly DHCPv4/v6 snooping to set up bindings between DHCP 154 assigned IP address and corresponding anchors. The bindings can be 155 used to validate the source address in the packets. 157 4. Background and Related Protocols 159 This mechanism is an instance of a SAVI [savi-framework] solution, 160 specialized for addresses assigned using the DHCP protocol. 162 Dynamic Host Configuration Protocol version 4 [RFC2131] and Dynamic 163 Host Configuration Protocol version 6 [RFC3315] specify the 164 procedures for providing a client with assigned address and other 165 configuration information from a DHCP server. If a client gets an 166 address through the DHCP protocol, the address should be regarded as 167 a potential "authorized" or "registered" address of the client. 169 In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is used as 170 another address assignment mechanism. A node can use this mechanism 171 to auto-configure an IPv6 address. A DHCPv6 client may use a 172 stateless address to send message to DHCP server. Even in a DHCPv6- 173 only environment, a node must assign its link-local address through 174 this mechanism. [RFC4862] also clearly requires that duplicated 175 address detection must be performed on any IPv6 address, including 176 DHCPv6 address. 178 [RFC4861] specifies the Neighbor Discovery protocol, which is an 179 essential part of IPv6 address assignment. 181 [RFC5227] specifies the procedure to detect IPv4 address collision. 182 It is not required currently. However, this feature is useful to 183 determine the uniqueness of an IPv4 address on the link. 185 5. Terminology 187 The terms used in this document are described in [savi-framework], 188 [RFC2131] and [RFC3315]. 190 6. Conceptual Data Structures 192 (To be removed and merged with data structures used by other 193 mechanisms in [savi-framework] if possible) 195 This section describes the possible conceptual data structures used 196 in this mechanism. 198 Two main data structures are used to record bindings and their states 199 respectively. There is redundancy between the two structures, for the 200 consideration of separation of data plane and control plane. 202 6.1. Binding State Table (BST) 204 This table contains the state of binding between source address and 205 anchor. Entries are keyed on the anchor and source IP address. Each 206 entry has a lifetime field recording the remaining lifetime of the 207 entry, a state field recording the state of the binding and a field 208 for recording other information. 210 +---------+----------+-------+-----------+-------+ 211 | Anchor | Address | State | Lifetime |Other | 212 +---------+----------+-------+-----------+-------+ 213 | A | IP_1 | Bound | 65535 | | 214 +---------+----------+-------+-----------+-------+ 215 | A | IP_2 | Bound | 10000 | | 216 +---------+----------+-------+-----------+-------+ 217 | B | IP_3 |_Start | 1 | | 218 +---------+----------+-------+-----------+-------+ 219 Figure 1 Instance of BST 221 6.2. Filtering Table (FT) 223 This table contains the bindings between anchor and address, keyed on 224 anchor. This table doesn't contain any state of the binding. This 225 table is only used to filter packets. An Access Control List can be 226 regarded as a practical instance of this table. 228 +---------+----------+ 229 |Anchor |Address | 230 +---------+----------+ 231 |A |IP_1 | 232 +---------+----------+ 233 |A |IP_2 | 234 +---------+----------+ 235 Figure 2 Instance of FT 237 7. Binding States Description 239 This section describes the binding states of this mechanism. 241 START A DHCP request (or a DHCPv6 Confirm) has been received 242 from host, and it may trigger a new binding. 244 LIVE A DHCP address has been acknowledged by a DHCP server. 246 DETECTION A gratuitous ARP or Duplicate Address Detection NSOL 247 has been sent by the host (or the SAVI device). 249 BOUND The address has passed duplicate detection and 250 it is bound with the anchor. 252 8. DHCP Scenario 254 (This section should be removed and merged with other scenarios in 255 [savi-framework]) 257 This section specifies the deployment scenarios of this mechanism. 259 +--------+ 260 | DHCP | 261 | Server | 262 +-------,+ 263 `. 264 `. 265 `. 266 +----'-----+ 267 | SAVI | 268 | Device | 269 +-/------/-+ 270 | | 271 +----\-+ +\-----+ 272 |DHCP | |Client| 273 |Relay | | | 274 +------+ +------+ 275 Figure 3 DHCP Scenario 277 9. Anchor Attributes 279 This section specifies the anchor attributes involved in this 280 mechanism. 282 9.1. SAVI-Host Attribute 284 (This attribute should be described in the [savi-framework]) 286 If and only if an anchor is exclusively associated with a single host, 287 this anchor can be set to have SAVI-Host attribute. 289 9.2. SAVI-Poly Attribute 291 (This attribute should be described in the [savi-framework]) 293 If an anchor is associated with a small number of hosts through a 294 converged device, this anchor can be set to have the SAVI-Poly 295 attribute. The SAVI-Poly attribute is mutually exclusive with the 296 SAVI-Host attribute. 298 The main difference in process on an anchor with the SAVI-Poly 299 attribute from one with the SAVI-Host attribute is the policy of 300 binding consistency. 302 9.3. SAVI-DHCP-Trust Attribute 304 If and only if an anchor is associated with a trustable DHCP 305 server/relay, it can be set to have this attribute. 307 If DHCP is used to assign address in the network, there MUST be at 308 least one anchor with this attribute. DHCP Reply message not coming 309 from such ports MUST be dropped. 311 9.4. SAVI-RA-Trust Attribute 313 (This attribute should be described in the [savi-framework]) 315 If and only if an anchor is associated with a trustable router, it 316 can be set to have this attribute. 318 There MAY be no SAVI-RA-Trust anchor on a SAVI device. 320 Router Advertisement not received from a SAVI-RA-Trust anchor MUST be 321 discarded. 323 9.5. SAVI-SAVI Attribute 325 (This attribute should be described in the [savi-framework]) 327 If and only if an anchor is associated with another SAVI device, it 328 can be set to have this attribute. 330 This attribute is mutually exclusive with SAVI-Host and SAVI-Poly 331 attribute. 333 10. Prefix Configuration 335 (This section should be included in [SAVI-framework] but not this 336 document.) 338 Before setting up a host-level granularity binding table, it is 339 important to configure correct prefixes on the SAVI device. At least 340 two prefix scopes must be set: the IPv4 prefix and IPv6 prefixes. 341 This document suggests set 3 prefix scopes: 343 IPv4 Prefix: 345 The allowed scope of any kind of IPv4 addresses. It can be set 346 manually. 348 IPv6 SLAAC Prefixes: 350 The allowed scope of SLAAC and manually configured IPv6 351 addresses. It can be set through snooping RA message from port 352 with SAVI-RA-Trust attribute, or manual configuration. 354 FE80::/64 MUST be set to a feasible prefix. 356 IPv6 DHCPv6 Prefixes: 358 The allowed scope of DHCPv6 addresses. It can be set through RA 359 snooping, DHCP-PD protocol, or manual configuration. 361 If some of the prefix scope is set to have non prefix, it implies 362 corresponding address assignment method is not allowed in the network. 364 There is no need to explicitly present these prefix scopes. But these 365 restrictions MUST be used as premier check in binding set up. 367 Refer to security consideration for other discussions. 369 11. Binding Set Up 371 This section specifies the procedure of setting up bindings based on 372 control packet snooping. 374 11.1. Process of DHCP Snooping 376 11.1.1. Initialization 378 This procedure will not be performed if: 380 1. Option 82 is used to keep anchor in DHCP Request and Reply, or 382 2. Unspoofable MAC is used as anchor(802.11i,802.1ae/af), or 384 3. The mapping table from MAC to anchor is secure. 386 If none of these three requirements are satisfied, this procedure 387 MUST be performed. 389 11.1.1.1. Trigger Event 391 A DHCPv4/v6 Request or a DHCPv6 Confirm is received with an anchor 392 which has the attribute of SAVI-Host or SAVI-Poly. 394 11.1.1.2. Message Validation 396 The SAVI device checks the Request or Confirm as follows: 398 1. Whether the limitation on binding entry number of this anchor will 399 be exceeded. 401 11.1.1.3. Following Actions 403 Forward the REQUEST message if binding entry limitation will not be 404 exceeded. 406 Generate an entry in the Binding State Table (BST) and set the state 407 field to START. The lifetime of this entry is set to be 408 MAX_DHCP_RESPONSE_TIME. The Transaction ID (Refer to Section 2 in 409 [RFC2131] and Section 4.2 in [RFC3315]) field of the request packet 410 is also recorded in the entry. 412 +---------+----------+-------+-----------------------+-------+ 413 | Anchor | Address | State | Lifetime |Other | 414 +---------+----------+-------+-----------------------+-------+ 415 | A | | Start |MAX_DHCP_RESPONSE_TIME | TID | 416 +---------+----------+-------+-----------------------+-------+ 417 Figure 4 Binding entry in BST on initialization 419 The TID is kept for assurance that the response from the DHCP server 420 can be delivered to the request host. This is left as an open issue 421 for future discussion. 423 11.1.2. From START to LIVE 425 11.1.2.1. Trigger Event 427 A DHCPv4 DHCPACK or DHCPv6 REPLY message is received. 429 11.1.2.2. Message Validation 431 The SAVI device checks the message as follows: 433 1. Whether the message is received with an anchor which has the SAVI- 434 DHCP-Trust attribute; 436 2. Whether the entry in the BST with corresponding TID is in the 437 START state. 439 11.1.2.3. Following Actions 441 Deliver the message to the destination. 443 Set the state of the corresponding entry to be LIVE. The lifetime of 444 the entry is set to be MAX_ARP_PREPARE_DELAY or MAX_DAD_PREPARE_DELAY 445 respectively. The lease time is also recorded in the entry. 447 +---------+----------+-------+------------------------+-------+ 448 | Anchor | Address | State | Lifetime |Other | 449 +---------+----------+-------+------------------------+-------+ 450 | A | Addr | LIVE |MAX_ARP_PREPARE_DELAY or| Lease | 451 | | | |MAX_DAD_PREPARE_DELAY | Time | 452 +---------+----------+-------+------------------------+-------+ 453 Figure 5 Binding entry in BST on assignment 455 Or set the state of the corresponding entry to be DETECTION, and send 456 an ARP Request or NSOL for the assigned address. 458 +---------+----------+-----------+-----------------+-------+ 459 | Anchor | Address | State | Lifetime |Other | 460 +---------+----------+-----------+-----------------+-------+ 461 | A | Addr | DETECTION |MAX_ARP_DELAY or | Lease | 462 | | | |MAX_DAD_DELAY | Time | 463 +---------+----------+-----------+-----------------+-------+ 464 Figure 6 Binding entry in BST on assignment: another case 466 Insert an entry into the Filtering Table if the assigned address is 467 not bound with another anchor. 469 +---------+----------+ 470 |Anchor |Address | 471 +---------+----------+ 472 |A |Addr | 473 +---------+----------+ 474 Figure 7 Binding entry in FT on assignment 476 11.1.3. From LIVE to DETECTION 478 (This section should be removed or modified if all the DAD related 479 procedures are to be described in SLAAC document) 481 11.1.3.1. Trigger Event 483 A gratuitous ARP Request or Duplicate Address Detection Neighbor 484 Solicitation is received from the host. Or a timeout event of an 485 entry with state LIVE occurs. 487 11.1.3.2. Message Validation 489 The SAVI device checks the message as follows: 491 1. Whether the Target IP address field of the ARP Request or Neighbor 492 Solicitation has been bound with the corresponding anchor in BST 493 or FT. 495 11.1.3.3. Following Actions 497 If timeout event of an entry with state LIVE happens, send an ARP 498 Request or a DAD NSOL, with target address set to the recorded 499 address in the entry. 501 Set the state of the entry to be DETECTION. The lifetime of the entry 502 is set to be MAX_ARP_DELAY or MAX_DAD_DELAY respectively. 504 +---------+----------+-----------+-----------------+-------+ 505 | Anchor | Address | State | Lifetime |Other | 506 +---------+----------+-----------+-----------------+-------+ 507 | A | Addr | DETECTION |MAX_ARP_DELAY or| Lease | 508 | | | |MAX_DAD_DELAY | Time | 509 +---------+----------+-----------+-----------------+-------+ 510 Figure 8 Binding entry in BST on detection 512 11.1.4. From DETECTION to BOUND 514 11.1.4.1. Trigger Event 516 A timeout event of an entry with state DETECTION occurs or an ARP 517 Response or NA for an address in BST with state DETECTION is received. 519 11.1.4.2. Following Actions 521 If a timeout event of an entry with state DETECTION occurs, set the 522 state of the entry to be BOUND. The lifetime of the entry is set to 523 be the Lease time acknowledged by DHCP server. 525 +---------+----------+-----------+----------------+-------+ 526 | Anchor | Address | State | Lifetime |Other | 527 +---------+----------+-----------+----------------+-------+ 528 | A | Addr | BOUND | Lease time | | 529 +---------+----------+-----------+----------------+-------+ 530 Figure 9 Binding entry in BST on finalization 532 If an ARP Response or NA for an address in BST with state DETECTION 533 is received, remove the corresponding entry in BST and FT. 535 11.1.5. After BOUND 537 Whenever a DHCP Decline is received from the host, delete the entry 538 in BST and FT. 540 Whenever a DHCP Release is received from the host, if the state of 541 the entry is BOUND, delete the entry in BST and FT. 543 If a DHCPv4 Acknowledgement or DHCPv6 Reply with Renew/Rebind sign is 544 received from the server, set lifetime of the entry in BST to be the 545 new lease time. 547 If the lifetime of an entry with state BOUND expires, delete the 548 entry in BST and Filter Table. 550 11.2. State Machine of DHCP Snooping 552 State Packet/Event Action Next State 554 -* REQUEST/CONFIRM Set up new entry START 556 START ACK Record lease time LIVE 558 START Timeout Remove entry - 560 LIVE Gra ARP REQ/DAD NS - DETECTION 562 LIVE DECLINE Remove entry - 564 LIVE Timeout Send ARP Req/DAD NS DETECTION 566 DETECTION Timeout - BOUND 568 DETECTION ARP RESPONSE Remove entry - 570 DETECTION DECLINE Remove entry - 572 BOUND RELEASE/DECLINE Remove entry - 574 BOUND Timeout Remove entry - 576 BOUND RENEW/REBOUND Set new lifetime BOUND 578 *: optional. 580 12. Filtering Specification 582 This section specifies how to use bindings to filter packets. 584 12.1. Filter Data Packet 586 Data packets with an anchor which has attribute SAVI-Host or SAVI- 587 Poly are filtered. There can be an anchor with neither attribute. 589 If the source of a packet associated with its anchor is in the FT, 590 this packet will be forwarded; or else the packet MUST be discarded. 592 12.2. Filter Control Packet 594 The source address of DHCPv4 Request/Discovery must be set to all 595 zeros. 597 The source address of DHCPv6 Request/Confirm must be an address 598 associated with the corresponding anchor in FT. 600 The source address of IPv6 NS and IPv6 gratuitous ARP must pass the 601 check on FT. The source address of DAD NS MUST be unspecified address. 603 All DHCP Reply/Ack packets MUST be from an anchor with the SAVI-DHCP- 604 Trust attribute. 606 The target address and source address in all the Neighbor 607 Advertisement packets and ARP replies must also pass the checks on FT, 608 if they are associated with anchors which have SAVI-Host or SAVI-Poly 609 attribute. 611 13. Format and Delivery of Probe Messages 613 1. Duplicate detection on behavior of host; 615 Message Type: DAD NS, Gratuitous ARP Request 617 Format: 619 Link layer source - link layer address of host; 621 Link layer destination - For IPv6, use multicast address 622 specified in [RFC3307]; For IPv4, use broadcast address; 624 IP source - Unspecified address for IPv6; The tentative address 625 for IPv4; 627 IP destination - For IPv6, multicast address specified in 628 section 5.4.2 of [RFC4861]; For IPv4, the tentative address; 630 Delivery: 632 MUST not deliver to the host which the SAVI device is 633 performing DAD on behavior of. 635 2. Send reply on behavior of host to hold bound address for inactive 636 node; 638 Message Type: NA, ARP Response 640 Link layer source - link layer address of host; 642 Link layer destination - The source address of the detecting node; 644 IP source - The target address in the detection message; 646 IP destination -The source address of the detecting node; 648 3. Send probe to detect whether an address is still in use (generally 649 in case of port down/up event). 651 Message Type: NUD, ARP Request 653 Link layer source - link layer address of the SAVI device; 655 Link layer destination - The link layer address of the node; 657 IP source - The manage IP address of the SAVI device; 659 IP destination - The address is suspicious to be inactive. 661 14. Data packet trigger on SAVI-Poly anchor 663 To handle the case of movement from one SAVI-Poly port to another, 664 data packet based binding MUST be performed on SAVI-Poly anchor. 666 Whenever a packet with source address not bound locally is received 667 from a SAVI-Poly anchor, the SAVI device MUST send a DHCP CONFIRM to 668 the DHCP server to ensure the address can be used on the link; if the 669 address can be used, the SAVI device MUST send a DAD NS on behavior 670 of the host to check the uniqueness of the address. If the address 671 passes these two checks, it can be bound with the anchor. 673 Data packet triggered binging will cause heavy burden and 674 unpredictable danger on the SAVI device. It is not suggested to 675 configure SAVI-Poly anchor and allow mobility between SAVI-Poly 676 anchors. If this function is turned off, the administrator must be 677 aware of the packets from SAVI-Poly anchor may be filtered 678 incorrectly after movement. 680 15. Binding Remove 682 If the lifetime of an entry with state BOUND expires, the entry MUST 683 be removed. 685 When the SAVI device receives a DAD NS/Gra ARP request target at an 686 address bound and there is no reply from the anchor, if the anchor is 687 a SAVI-Host anchor, hold the binding entry through sending NA/ARP 688 Reply; if the anchor is a SAVI-Poly anchor, remove this binding or 689 hold it. 691 16. Handle port DOWN event 693 Whenever a port with attribute SAVI-Poly or SAVI-Host turns down, the 694 bindings with the anchor MUST be kept for a short time. 696 To handle movement, if receiving DAD NS/Gra ARP request target at the 697 address during the period, remove the entry. 699 If port turns UP during the period: 701 ?Optionally send probes to SAVI-host port for assurance; 703 ?MUST send probes to SAVI-Poly port for assurance. 705 17. About Collision in Detection 707 The SAVI device may receive a response in detection. Some related 708 details are specified here. 710 17.1. Whether to notify the DHCP server 712 It is unnecessary for the SAVI device to notify the DHCP server, 713 because the host will send a DECLINE message to it once it finds the 714 advertised address is conflict. 716 17.2. The result of detection without host aware 718 In case the SAVI device send detection packet instead of the host, 719 the host will not be aware of the detection result. If the detection 720 succeeds, there is no problem. However, if the detection fails, the 721 packets from the host with the assigned address will be filtered out. 722 This result can be regarded as a reasonable punishment for not 723 performing duplicate detection and using a collision address. 725 18. Filtering during detection 727 In this mechanism, whenever the DHCP server replies an address, this 728 address will be allowed immediately even before duplicate detection 729 is completed. This design is in consideration of a host may start to 730 send packets straightway without detection. Also this design is to be 731 compatible with optimistic DAD [RFC4429]. 733 However, this feature may allow an attacker to send quantities of 734 packets with source addresses already assigned to other nodes. A 735 practical solution for this vulnerability is configuring the address 736 pool and allocation algorithm of the DHCP server carefully. 738 19. Binding Number Limitation 740 It is suggested to configure some mechanism in order to prevent a 741 single node from exhausting the binding table entries on the SAVI 742 device. Either of the following mechanism is sufficient to prevent 743 such attack. 745 1. Set the upper bound of binding number for each anchor with SAVI- 746 Host or SAVI-Poly attribute. 748 2. Reserve a number of binding entries for each anchor with SAVI-Host 749 or SAVI-Poly attribute and all anchors share a pool of the other 750 binding entries. 752 3. Limit DHCP Request rate per anchor, using the bound entry number 753 of each anchor as reverse indicator. 755 20. MLD Consideration 757 The SAVI device MUST join the tentative address multicast group 758 whenever perform duplicate detection on behavior of host. 760 21. Constants 762 MAX_DHCP_RESPONSE_TIME 120s 764 MAX_ARP_PREPARE_DELAY Default 1s but configurable 766 MAX_ARP_DELAY Default 1s but configurable 768 MAX_DAD_PREPARE_DELAY Default 1s but configurable 770 MAX_DAD_DELAY Default 1s but configurable 772 22. Summary of to-be-removed sections and open issues 774 To-be-removed sections: 776 1. Section 6: Conceptual data structures 778 2. Section 8: DHCP scenario 780 3. Part of Section 9: Anchor attributes 782 4. Section 10: Prefix configuration 784 Open issues (discussed but not finished): 786 1. Whether to keep state START 788 Should the procedure be initialized based on client request or 789 server response? 791 From Eric Levy-Abegnoli and Christian Vogt. 793 2. Whether to keep state DETECTION 795 Should DHCP interact with NDP to detect collision or should all 796 the collision detection be left to NDP and the DHCP solution just 797 snoop DHCP only? 799 From Eric Levy-Abegnoli. 801 23. Security Considerations 803 For prefix level granularity filtering is the basis of host level 804 granularity filtering, to learn and configure correct prefix is of 805 great importance to this mechanism. Thus, it's important to keep RA 806 and DHCP-PD secure. [draft-ietf-v6ops-ra-guard-03] describes a 807 mechanism to improve the security of RA message. 809 24. IANA Considerations 811 There is no IANA consideration currently. 813 25. References 815 25.1. Normative References 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels", BCP 14, RFC 2119, March 1997. 820 [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless 821 Autoconfiguration", RFC4862, September, 2007. 823 [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, 824 July 2008. 826 25.2. Informative References 828 26. Acknowledgments 830 Thanks to Christian Vogt, Eric Levy-Abegnoli, Mark Williams, Erik 831 Nordmark, Marcelo Bagnulo Braun, Alberto Garcia, Jari Arkko, David 832 Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg 833 Daley, Joel M. Halpern and Tao Lin for their valuable contributions. 835 Authors' Addresses 837 Jun Bi 838 CERNET 839 Network Research Center, Tsinghua University 840 Beijing 100084 841 China 842 Email: junbi@cernet.edu.cn 844 Jianping Wu 845 CERNET 846 Computer Science, Tsinghua University 847 Beijing 100084 848 China 849 Email: jianping@cernet.edu.cn 851 Guang Yao 852 CERNET 853 Network Research Center, Tsinghua University 854 Beijing 100084 855 China 856 Email: yaog@netarchlab.tsinghua.edu.cn 858 Fred Baker 859 Cisco Systems 860 Email: fred@cisco.com