SAVI J. Bi, J. Wu, G. Yao Internet Draft CERNET Intended status: Standard Tracks F. Baker Expires: December 2009 Cisco April 9, 2009 Control Packet Snooping Based Binding draft-bi-savi-cps-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 9, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Bi Expires December 9,2009 [Page 1] Internet-Draft Control Packet Snooping Based Binding April 2009 This document specifies the Control Packet Snooping (CPS) mechanism for IP version 4 and IP version 6. This mechanism is used to set up binding between source IP address and corresponding anchor on the access device. This binding is always used to perform source address validation. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document............................ 3 3. Terminology ................................................. 3 4. Mechanism Overview .......................................... 3 5. Related Protocols ........................................... 4 6. Definition of Anchor......................................... 4 7. Conceptual Data Structures................................... 5 8. Control Packet Snooping...................................... 7 8.1. DHCPv4 Snooping......................................... 7 8.1.1. Process of DHCPv4 Snooping .........................7 8.1.2. State Machine of DHCPv4 Snooping ...................7 8.2. DHCPv6 Snooping......................................... 8 8.2.1. Process of DHCPv6 Snooping .........................8 8.2.2. State Machine of DHCPv6 Snooping ...................9 8.3. ND Snooping ............................................ 9 8.3.1. Process of ND Snooping............................. 9 8.3.2. State Machine of ND Snooping ......................10 8.4. ARP Snooping .......................................... 10 8.4.1. Process of ARP Snooping........................... 10 8.4.2. State Machine of ARP Snooping .....................11 8.5. Manually Binding....................................... 11 9. Clear Binding .............................................. 11 10. Solution for Special Situations............................ 12 10.1. Multiple Interfaces................................... 12 10.2. Port Movement ........................................ 12 11. Considerations on Security Risks........................... 13 11.1. Operating system support.............................. 13 11.2. Detection packet loss................................. 14 11.3. Malicious replier..................................... 14 11.4. Inactive node ........................................ 15 12. Filter Exception .......................................... 15 13. Constants ................................................. 15 14. Security Considerations.................................... 15 15. IANA Considerations........................................ 16 16. References ................................................ 16 16.1. Normative References.................................. 16 16.2. Informative References................................ 16 17. Acknowledgments ........................................... 16 Bi Expires October 9, 2009 [Page 2] Internet-Draft Control Packet Snooping Based Binding April 2009 Appendix A. Operating System Support Situation .................17 Authors' Addresses ............................................ 18 1. Introduction This specification defines the Control Packet Snooping (CPS) mechanism for Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). Access devices (including access switches, and wireless access point/controller, etc) can use this mechanism to set up bindings between source IP address of hosts and corresponding anchors, in accordance with the appointed address assignment method. These bindings can be used to validate the source IP address in the packets received from directly attached hosts. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology Anchor - The entity to bind source IP address with. 4. Mechanism Overview This mechanism is designed to provide a host level source IP address validation granularity, as a supplement of BCP38. This mechanism is deployed on the access device (including access switch, wireless access point/controller, etc), and performs control protocol snooping to set up bindings between source IP address and corresponding anchors. It also allows manually configured binding. The bindings are then used to check the source address in the packets from the directly attached hosts. This mechanism requires no change on host, and no new protocol is designed. The deployed devices can work with non-deployed devices; however, the protection area is limited to the deployed area. This mechanism has an assumption that any kind of address is used only after some duplicate detection protocol is used. If in any situation the address is used without any detection protocol, such packets will be regarded as source spoofing packets. However, in some situations, a source IP address may be used without detection, but cannot be considered as spoofing. These situations are discussed in section 9 and section 10. Bi Expires October 9, 2009 [Page 3] Internet-Draft Control Packet Snooping Based Binding April 2009 The binding entries generally are not permanent. Each binding has a lifetime, and some event may trigger the binding deletion. When their lifetime expires, or the event happens, this mechanism will delete the corresponding entry, or perform some process. 5. Related Protocols All the protocols related with the IP address assignment are the in the scope of this mechanism, including: Dynamic Host Configuration Protocol version 4 (DHCPv4) - A host may use this protocol to get an IPv4 address. Dynamic Host Configuration Protocol version 6 (DHCPv6) - A host may use this protocol to get an IPv6 address. Neighbor Discovery Protocol (NDP) - Whenever a host wants to assign an IPv6 address to its interface, it must perform Duplicate Address Detection first, which is composed of NDP packets. The NDP is also used to detect whether a host is still reachable. Such NDP packets can be used to determine whether to delete a binding or not. Address Resolution Protocol (ARP) - Whenever a host wants assign an IPv4 address to its interface, it will send a gratuitous ARP to make sure this address is not being used. However, this function may not be supported by all the operating systems. ARP is also used to determine whether a host is still reachable. Such ARP packets can be used to determine whether to delete a binding or not. Secure Neighbor Discovery Protocol (SeND) - SeND is a special case of NDP. If a ND packet is also a SeND packet, the validity of the source address must be checked first before this packet is taken into the process of this mechanism. There is no other difference for the mechanism to process plain ND packet and SeND packet. 6. Definition of Anchor Anchor is an important concept for this mechanism. In this document, anchor is the entity to bind source address with. To make the binding secure, the anchor itself must be unspoofable. Generally, following entities can be used as anchor: Exclusive switch port - When a switch port is exclusive for a host, this port is unspoofable for other hosts. Bi Expires October 9, 2009 [Page 4] Internet-Draft Control Packet Snooping Based Binding April 2009 MAC address in 802.1ae/af and 802.11i - 802.1ae/af and 802.11i protect the security of MAC address. When such technology is deployed in the network, MAC address can be used as anchor. However, when strict secure anchor is not achievable in the network, loose secure anchor can be used. Generally, shared switch port and MAC address are loose secure anchors. Loose secure anchor may cause false negative, thus it is not recommended to use such anchors. This document doesn't specify which entities can be used as anchor, and how secure these anchors. 7. Conceptual Data Structures This section describes the possible conceptual data structures used in this mechanism. The deployed device must maintain the following data structures: Binding State Table (BST) - This table contains this state of binding between source address and anchor. Entries are keyed on the anchor and source IP address. Each entry has a lifetime item which records the remaining lifetime of this entry, an item which records the state of this binding and an item record other information. Whenever the lifetime expires, the entry should be deleted, except for the entries with DHCPv4_DETECTION/ DHCPv4_DETECTION/SAC_START/MANUALv4_START state. Filtering Table (FT) - This table contains the bindings between anchor and address, keyed on anchor. This table doesn't contain any state of the binding. This table is used to filter packet. Access Control List can be regarded as an instance of this table. The states of binding in Binding State Table are as follows: DHCPv4_START A DHCPv4 request is received from host, and it may trigger a new binding. DHCPv4_LIVE The DHCPv4 address is acknowledged by DHCP server. Bi Expires October 9, 2009 [Page 5] Internet-Draft Control Packet Snooping Based Binding April 2009 DHCPv4_DETECTION A gratuitous ARP has been sent by the host and it is waiting for the reply. DHCPv4_BOUND The address has passed duplicate detection and it is bound with the anchor. DHCPv6_START A DHCPv6 request or confirm is received from host. DHCPv6_LIVE A DCHPv6 reply is received from server, and an address is suggested. DHCPv6_DETECTION A Duplicate Address Detection (DAD) Neighbor Solicitation has been sent by the host, and it is waiting for the reply. DHCPv6_BOUND The address has passed DAD and it is bound with the anchor. SAC_START A DAD NS has been sent by the host. The target address is neither got from DHCP nor static. SAC_BOUND The address has passed DAD and it is bound with anchor. SAC_QUERY The bound address is being queried by another node. If there is no response in a time constant, the binding should be deleted. MANUALv4_START A gratuitous ARP has been sent by the host. The target address is neither got from DHCP nor static. MANUALv4_BOUND The address has passed DAD and it is bound with anchor. MANUALv4_QUERY The bound address is being queried by another node. If there is no response in a time constant, the binding should be deleted. STATIC The address is static and the binding should not be change. Bi Expires October 9, 2009 [Page 6] Internet-Draft Control Packet Snooping Based Binding April 2009 8. Control Packet Snooping 8.1. DHCPv4 Snooping 8.1.1. Process of DHCPv4 Snooping This process is designed for DHCPv4 assigned address. Whenever a DHCPv4 request is received from attaching host, and the requested IP address does not exist in the binding table, the device will generate an entry in the Binding State Table (BST), set the state field to be DHCPv4_START. The lifetime of this entry is set to be MAX_DHCP_RESPONSE_TIME. The TID field of the request packet is also recorded in the entry. If an entry is already in the BST and the state of the entry is DHCPv4_START, set the lifetime field to be MAX_DHCP_RESPONSE_TIME. Whenever a DHCPv4 acknowledgement is received from the DHCP server, if the TID is in BST, and the state of the entry is DHCPv4_START, set the state of the entry to be DHCPv4_LIVE. The lifetime of the entry is set to be MAX_ARP_PREPARE_DELAY. The lease time is also recorded in the entry. Whenever a gratuitous ARP request is received from the host, if the state of the entry is DHCPv4_LIVE, set the state of the entry to be DHCPv4_DETECTION. The lifetime of the entry is set to be MAX_ARP _DELAY. If an ARP response for the address is received from other nodes, delete the entry. If the lifetime expires, set the state of the entry to be DHCPv4_BOUND. The lifetime of this entry is set to the lease time of the entry. An entry is added into the Filter Table. Whenever a DHCPv4 decline is received from the host, if the state of the entry is DHCPv4_LIVE, delete the entry in BST. Whenever a DHCPv4 release is received from the host, if the state of the entry is DHCPv4_BOUND, delete the entry in BST and Filter Table. If a DHCPv4 acknowledgement with renew/rebind sign is received from the server, set lifetime of the entry in BST to be the new lease time. If the lifetime of an entry with state DHCPv4_BOUND expires, delete the entry in BST and Filter Table. 8.1.2. State Machine of DHCPv4 Snooping State Packet/Event Action Next State Bi Expires October 9, 2009 [Page 7] Internet-Draft Control Packet Snooping Based Binding April 2009 Start DHCPv4 REQ Set up new entry DHCPv4_START DHCPv4_START DHCPv4 ACK Record lease time DHCPv4_LIVE DHCPv4_LIVE Gra ARP REQ - DHCPv4_DETECTION DHCPv4_LIVE DHCPv4 DEC Remove entry Start DHCPv4_DETECTION Timeout Insert into FT DHCPv4_BOUND DHCPv4_DETECTION Gra ARP RPL Remove entry Start DHCPv4_DETECTION DHCPv4 DEC Remove entry Start DHCPv4_BOUND DHCPv4 REL Remove entry Start DHCPv4_BOUND DHCPv4 REN/REB Set new lifetime DHCPv4_BOUND 8.2. DHCPv6 Snooping 8.2.1. Process of DHCPv6 Snooping This process is designed for DHCPv6 assigned address. Whenever a DHCPv6 request or confirm is received from attaching host, and the requested IP address does not exist in the binding table, the device will generate an entry in the BST, set the state field to be DHCPv6_START. The lifetime of this entry is set to be MAX_DHCP_RESPONSE_TIME. The source address of the request packet is also recorded in the entry. If an entry is already in the BST and the state of the entry is DHCPv6_START, set the lifetime field to be MAX_DHCP_RESPONSE_TIME. Whenever a DHCPv6 reply is received from the DHCP server, if the TID is in BST, and the state of the entry is DHCPv6_START, set the state of the entry to be DHCPv6_LIVE. The lifetime of the entry is set to be MAX_DAD_PREPARE_DELAY. The lease time is also recorded in the entry. Whenever a DAD NS is received from the host, if the state of the entry is DHCPv6_LIVE, set the state of the entry to be DHCPv6_DETECTION. The lifetime of the entry is set to be MAX_DAD _DELAY. If an NA response for the address is received from other nodes, delete the entry. If the lifetime expires, set the state of the entry to be DHCPv6_BOUND. The lifetime of this entry is set to the lease time of the entry. An entry is added into the Filter Table. Bi Expires October 9, 2009 [Page 8] Internet-Draft Control Packet Snooping Based Binding April 2009 Whenever a DHCPv6 decline is received from the host, if the state of the entry is DHCPv6_LIVE, delete the entry in BST. Whenever a DHCPv6 release is received from the host, if the state of the entry is DHCPv6_BOUND, delete the entry in BST and Filter Table. If a DHCPv6 reply with renew/rebind sign is received from the server, set lifetime of the entry in BST to be the new lease time. If the lifetime of an entry with state DHCPv6_BOUND expires, delete the entry in BST and Filter Table. 8.2.2. State Machine of DHCPv6 Snooping State Packet/Event Action Next State Start DHCPv6 REQ/CON Set up new entry DHCPv6_START DHCPv6_START DHCPv6 RLY Record lease time DHCPv6_LIVE DHCPv6_LIVE DAD NS - DHCPv6_DETECTION DHCPv6_DETECTION Timeout Insert into FT DHCPv6_BOUND DHCPv6_DETECTION DAD NA RLY Remove entry Start DHCPv6_LIVE DHCPv6 DEC Remove entry Start DHCPv6_BOUND DHCPv6 REL Remove entry Start DHCPv6_BOUND DHCPv4 REN/REB Set new lifetime DHCPv6_BOUND 8.3. ND Snooping 8.3.1. Process of ND Snooping This process is designed for stateless auto-configuration assigned IPv6 address and manually configured IPv6 address. Whenever a DAD NS is received from the host, if the address is not in BST and has a permitted prefix, generate a new entry in BST and set the state of the entry to be SAC_START. The lifetime of the entry is set to be MAX_DAD _DELAY. If an NA response for the address is received from other nodes, delete the entry. If the lifetime expires, set the state of the entry to be SAC_BOUND. The lifetime of this entry is set to MAX_SAC_LIFETIME. An entry is added into the Filter Table. Bi Expires October 9, 2009 [Page 9] Internet-Draft Control Packet Snooping Based Binding April 2009 If the lifetime of an entry with state SAC_BOUND expires, set the lifetime to be MAX_DAD_PREPARE_DELAY and send a NS for the address. If there is no response before the lifetime expires, delete the entry in BST and Filter Table. Else set the lifetime to be MAX_SAC_LIFETIME. Whenever a NS with target address set to one of the addresses with state SAC_BOUND, the state of the entry is set to SAC_QUERY, and the lifetime is set to MAX_DAD_PREPARE_DELAY. If there is no response from the host before the lifetime expires, delete the entry in BST and Filter Table. If a response is received from the host, set the lifetime of the corresponding entry to be MAX_SAC_LIFETIME. 8.3.2. State Machine of ND Snooping State Packet/Event Action Next State Start DAD NS Set up new entry SAC_START SAC_START Timeout Insert into FT SAC_BOUND SAC_START DAD NA RLY Remove entry Start *SAC_BOUND NS for bound addr - SAC_QUERY *SAC_QUERY NA Set lifetime to maximum SAC_BOUND *SAC_QUERY Timeout Remove binding Start (* denotes optional process.) 8.4. ARP Snooping 8.4.1. Process of ARP Snooping This process is designed for manually configured IPv4 address. Whenever a gratuitous ARP is received from the host, if the address is not in BST and has a permitted prefix, generate a new entry in BST and set the state of the entry to be MANUALv4_START. The lifetime of the entry is set to be MAX_ARP_DELAY. If an ARP response for the address is received from other nodes, delete the entry. If the lifetime expires, set the state of the entry to be MANUALv4_BOUND. The lifetime of this entry is set to MAX_MANUAL_LIFETIME. An entry is added into the Filter Table. Bi Expires October 9, 2009 [Page 10] Internet-Draft Control Packet Snooping Based Binding April 2009 If the lifetime of an entry with state MANUALv4_BOUND expires, set the lifetime to be MAX_ARP_PREPARE_DELAY and send an ARP request for the address. If there is no response before the lifetime expires, delete the entry in BST and Filter Table. Else set the lifetime to be MAX_MANUAL_LIFETIME. Whenever an ARP response with target address set to one of the addresses with state ARP_BOUND, the state of the entry is set to MANUALv4_QUERY, and the lifetime is set to MAX_ARP_PREPARE_DELAY. If there is no response from the host before the lifetime expires, delete the entry in BST and Filter Table. If a response is received from the host, set the lifetime of the corresponding entry to be MAX_MANUAL_LIFETIME. 8.4.2. State Machine of ARP Snooping State Packet/Event Action Next State Start Gra ARP REQ Set up new entry MANUALv4_START MANUALv4_START Timeout Insert into FT MANUALv4_BOUND MANUALv4_START Gra ARP RLY Remove entry Start *MANUALv4_BOUND ARP for bound addr MANUALv4_QUERY *MANUALv4_QUERY ARP RLY Set lifetime to maximum MANUALv4_BOUND *MANUALv4_QUERY Timeout Remove binding Start (* denotes optional process.) 8.5. Manually Binding To be compatible with manually configured static address, the BST is allowed to be configured manually. The configured binding has state STATIC and has an infinite lifetime. 9. Clear Binding Whenever the lifetime of any entry in the BST expires, it MUST be removed from the BST. If a binding has been inserted in to Filtering Table, this binding also MUST be removed. Whenever a node is disconnected at link layer, the corresponding binding in BST and Filtering Table MUST be removed unless the state of the entry is STATIC. Bi Expires October 9, 2009 [Page 11] Internet-Draft Control Packet Snooping Based Binding April 2009 10. Solution for Special Situations Two situations described in the charter of SAVI working group may cause this mechanism filter packets improperly: multiple interfaces and port movement. The following is the proper solution for each situation. 10.1. Multiple Interfaces If a host has multiple interfaces to the same LAN, generally this situation can be treated as multiple hosts with single interface because each interface will only use the address assigned to itself as source IP address. However, a host may configure the same address on multiple interfaces for the purpose of load balance. In this situation, the SAVI device may find an address bound with a anchor appears with another anchor, just as spoofing. This is the only multiple interfaces situation that troubles this mechanism. When this situation happens, the corresponding binding is seldom changed. Thus, manual configuration is enough for this situation. All the anchors with the host can be configured to be used by the same host and share the same entries in BST and Filtering Table. Other mechanisms can also be used to handle this situation, such as [SAVI-SeND] and [SAVI-HIP]. These mechanisms can be used to test whether two anchors are belonging to the same host and thus distinguish multiple interfaces from spoofing. However, all the mentioned mechanisms bring overhead to data packet process, and are not recommended. Currently, the only recommended mechanism is manual configuration. However, for the consideration that in the future, a host with multiple interfaces to the same network may become very common (for example, a host has a wired network interface and a wireless network interface attached to the same network, and they are configured to use the same address), an extension mechanism is still needed. The design of such mechanism is temporarily out of the scope of this document. 10.2. Port Movement DHCP assigned address and stateless address don't have the problem of port movement. If an address is assigned through DHCP, the address must be confirmed by DHCP server after port movement, and the control packets will used to set up new binding. For a stateless address, a duplicate detection must be performed when the interface is re-initialized, just as the process of address assignment. Bi Expires October 9, 2009 [Page 12] Internet-Draft Control Packet Snooping Based Binding April 2009 However, if an interface configured a static address changes port, because the corresponding is manually configured, this movement will conflict previous binding. The situation that a host with static address changes from one port to another can be handled through one of the following ways: - Manual configuration. If the host configured with static address seldom changes its port, the administrator can manually change the binding after each movement. - Changing anchor. If the anchor is not switch port, port movement will not cause any trouble. Thus an alternate way is choosing another entity as anchor, for example, the secure MAC address. - Access control mechanisms based on user account. Static address is always associated with specified user, thus the access control mechanism based on user account can be used to handle frequent port movements. 802.1x, PPPoE, and Portal are optional mechanisms. Whenever the user account is authenticated by there mechanisms, the corresponding address can be bound on the switch. The related protocol must be extended to enable such function. - Host identifier related mechanisms. [SAVI-SeND] and [SAVI-HIP] have a secure host identifier associated with the host, and this identifier can be used to handle port movement. The problem of such solutions is that they are based on immature techniques. 11. Considerations on Security Risks This mechanism has some potential risks. Some operating systems assign an address to interface without any duplicate detection. Other risks are due to the sync problem between host and SAVI device. 11.1. Operating system support The duplicate detection for IPv4 address has been prescribed in [RFC5227], but currently not all the operating systems perform duplicate detection on IPv4 address. Because the number of available IPv4 addresses in a LAN is small, a simplest solution is that whenever a new IPv4 address appears, the deployed device can perform duplicate detection instead of the host. However, this function will take data packet into control panel and would bring additional cost. A suggestion for the network administrator is IPv4 address should be assigned through DHCP or static. The supported operating systems are listed in Appendix A. Bi Expires October 9, 2009 [Page 13] Internet-Draft Control Packet Snooping Based Binding April 2009 The duplicate detection for IPv6 address has been prescribed in [RFC4862]. However, some operating systems not supporting IPv6 well will not perform DAD when assigning IPv6 address. It is suggested that the operating systems should be able to update to support [RFC5227] and [RFC4862]. For the operating system that cannot be updated, it is suggested to use static address and set up binding manually. 11.2. Detection packet loss The false positive of this mechanism is mainly caused by the risk of detection packet loss. If a critical detection packet is lost on the link, the binding may not be set up on the access device and the following data packet will be filtered incorrectly. This situation is rare for a wired network, and generally host will send the detection packet several times to avoid possible loss. The retransmit times of detection packets for IPv6 address can be configured as described in [RFC4862]. The number of detection packet for IPv4 address is 3 as described in [RFC5227]. However, this situation is still possible if the link quality is poor, especially in wireless network. If the administrator knows the link quality is poor, he can turn on the function which performs duplicate detection instead of the host. However, this function takes data packet into control panel and costs heavy. In our opinion, in such a network, the most important task is to improve the quality of the link, but not bring more burdens to the access device. 11.3. Malicious replier Another risk is that the detection packet can be replied by a malicious attacker, and the host will be prevented from getting a proper address. This problem cannot be easily handled for it is caused by non-deployed nodes. The deployed device must filter Neighbor Advertisement packets, not only by source address, but also by target address. The sender's address in ARP replies should also be checked. A practical solution for this problem is as follows: 1. Divide the address space of SAVI nodes and non-SAVI nodes; 2. Partition SAVI nodes and non-SAVI nodes to different VLANs. Then the SAVI nodes don't have to ask the non-SAVI nodes whether an address has been used by some of them. Bi Expires October 9, 2009 [Page 14] Internet-Draft Control Packet Snooping Based Binding April 2009 11.4. Inactive node The false negative may be caused by the situation that the detection packet is not replied by the assigned node. This is a troublesome situation. It is reasonable for a node to get such address because it is in accordance with the standard, unless the address is a static address. A simple process is removing the previous binding and setting up new binding for the requesting node. A more tolerant process is the SAVI device can perform ARP/ND proxy for the inactive node, and reduce the lifetime of binding to 1/4. 12. Filter Exception The filtering of data packet is based on the Filter Table, and the related control packet is handed to the Control Packet Snooping process. The source address of the control packet is always all zero (DHCPv4, IPv6 Stateless auto-configuration for link-local address) or unbound address (gratuitous ARP). Such packets don't have to pass the check on Filter Table. However, the source address of DHCPv6 request and IPv6 DAD NS for global address must pass the check on Filter Table, for always a unique link-local address is used. The target address in all the Neighbor Advertisement packets and the sender's address in all ARP relies should also pass the checks on Filter Table. 13. Constants MAX_DHCP_RESPONSE_TIME 10s MAX_ARP_PREPARE_DELAY 1s MAX_ARP_DELAY 1s MAX_DAD_PREPARE_DELAY 1s MAX_DAD_DELAY 1s MAX_SAC_LIFETIME 2h MAX_MANUAL_LIFETIME 4h 14. Security Considerations There are no security considerations currently. Bi Expires October 9, 2009 [Page 15] Internet-Draft Control Packet Snooping Based Binding April 2009 15. IANA Considerations There is no IANA consideration currently. 16. References 16.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless Autoconfiguration", RFC4862, September, 2007. [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, July 2008. [SAVI-SeND] M. Bagnulo, draft-ietf-savi-send-00.txt. [SAVI-HIP] D. Kuptsov, A. Gurtov and J. Bi, draft-kuptsov-sava-hip- 01.txt. 16.2. Informative References 17. Acknowledgments Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun, Jari Arkko, David Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, and Tao Lin for their valuable contributions. This document was prepared using 2-Word-v2.0.template.dot. Bi Expires October 9, 2009 [Page 16] Internet-Draft Control Packet Snooping Based Binding April 2009 Appendix A. Operating System Support Situation Supported systems: Windows XP SP2, Windows XP SP3, Windows Vista, Sun Solaris. Not supported systems: Ubuntu 8.10, Fedora 10. Bi Expires October 9, 2009 [Page 17] Internet-Draft Control Packet Snooping Based Binding April 2009 Authors' Addresses Jun Bi CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Jianping Wu CERNET Computer Science, Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Guang Yao CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: yaog@netarchlab.tsinghua.edu.cn Fred Baker Cisco Systems Email: fred@cisco.com Bi Expires October 9, 2009 [Page 18]