One document matched: draft-bi-savi-cps-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 04:16:29 |