Network Working Group E. Nordmark
Internet-Draft Cisco
Intended status: Standards Track M. Bagnulo
Expires: October 15, 2011 UC3M
E.L.A. Levy-Abegnoli
Cisco Systems
April 13, 2011

FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned IPv6 Addresses


This memo describes FCFS SAVI a mechanism to provide source address validation for IPv6 networks using the First-Come First-Serve principle. The proposed mechanism is intended to complement ingress filtering techniques to provide a finer granularity on the control of the source addresses used.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at

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."

This Internet-Draft will expire on October 15, 2011.

Copyright Notice

Copyright (c) 2011 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. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1. Introduction

This memo describes FCFS SAVI, a mechanism to provide source address validation for IPv6 networks using the First-Come First-Serve principle. The proposed mechanism is intended to complement ingress filtering techniques to provide a finer granularity on the control of the source addresses used.

2. Non-normative background to FCFS SAVI

2.1. Scope of FCFS SAVI

The application scenario for FCFS SAVI is limited to the local link. This means that the goal of FCFS SAVI is to verify that the source address of the packets generated by the hosts attached to the local link have not been spoofed.

In a link there usually are hosts and routers attached. Hosts generate packets with their own address as the source address. This is called the local traffic. Routers send packets containing a source address other than their own, since they are forwarding packets generated by other hosts (usually located in a different link). This is called the transit traffic.

The applicability of FCFS SAVI is limited to the local traffic i.e. to verify if the traffic generated by the hosts attached to the local link contains a valid source address. The verification of the source address of the transit traffic is out of the scope of FCFS SAVI. Other techniques, like ingress filtering [RFC2827], are recommended to validate transit traffic. In that sense, FCFS SAVI complements ingress filtering, since it relies on ingress filtering to validate transit traffic but is provides validation of local traffic, which is not provided by ingress filtering. Hence, the security level is increased by using these two techniques.

In addition, FCFS SAVI is designed to be used with locally assigned IPv6 addresses, in particular with IPv6 addresses configured through Stateless Address Auto-Configuration (SLAAC) [RFC4862]. Manually configured IPv6 addresses can be supported by FCFS SAVI, but manual configuration of the binding on the SAVI device provides higher security and seems compatible with manual address management. Additional considerations about how to use FCFS SAVI depending on the type of address management used and the nature of the addresses is discussed in the framework document [I-D.ietf-savi-framework].

2.2. Constraints for FCFS SAVI design

FCFS SAVI is designed to be deployed in existing networks requiring a minimum set of changes. For that reason, FCFS SAVI does not require any changes in the hosts which source address is to be verified. Any verification solely relies in the usage of already available protocols. This means that FCFS SAVI does not define a new protocol nor define any new message on existing protocols nor require that a host uses an existent protocol message in a different way. In other words, the requirement is no host changes.

FCFS SAVI validation is performed by the FCFS SAVI function. Such function can be placed in different type of devices, including a router or a layer-2 bridge. The basic idea is that the FCFS SAVI function is located in the points of the topology that can enforce the correct usage of source address by dropping the non-compliant packets.

2.3. Address ownership proof

The main function performed by FCFS SAVI is to verify that the source address used in data packets actually belongs to the originator of the packet. Since FCFS SAVI scope is limited to the local link, the originator of the packet is attached to the local link. In order to define a source address validation solution, we need to define some address ownership proof concept i.e. what it means that a given host owns a given address in the sense that the host is entitled to send packets with that source address.

Since no host changes are acceptable, we need to find the means to proof address ownership without requiring a new protocol. In FCFS SAVI the address ownership proof is based in the First-Come First-Serve principle. This means that the first host that claims a given source address is the owner of the address until further notice. More precisely, whenever a source address is used for the first time, a state is created in the device that is performing the FCFS SAVI function binding the source address to a binding anchor which consists on layer-2 information that the FCFS SAVI box has available (e.g. the port in a switched LAN). Subsequent data packets containing that IP source address must use the same binding anchor in order to be compliant.

There are however additional considerations to be taken into account. For instance, consider the case of a host that moves from one segment of a LAN to another segment of the same subnetwork and it keeps the same IP address. In this case, the host is still the owner of the IP address, but the associated binding anchor may have changed. In order to cope with this case, the defined FCFS SAVI behaviour implies the verification whether the host is still reachable using the previous binding anchor. In order to do that FCFS SAVI uses the Neighbour Discovery (ND) protocol. If the host is no longer reachable at the previously recorded binding anchor, FCFS SAVI assumes that the new location is valid and creates a new binding using the new binding anchor. In case the host is still reachable using the previously recorded binding anchor, the packets coming from the new binding anchor are dropped.

Note that this only applies to local traffic. Transit traffic generated by a router would be verified using alternative techniques, such as ingress filtering. SAVI checks would not be fulfilled by the transit traffic, since the router is not the owner of the source address contained in the packets.

2.4. Binding Anchor considerations

Any SAVI solution is not stronger than the binding anchor it uses. If the binding anchor is easily spoofable (e.g. a MAC address), then the resulting solution will be weak. The treatment of non-compliant packets needs to be tuned accordingly. In particular, if the binding anchor is easily spoofable and the SAVI device is configured to drop non-compliant packets, then the usage of SAVI may open a new vector of Denial of Service attacks, based on spoofed binding anchors. For that reason, in this document, we assume that the binding anchors used by the SAVI solution are not easily spoofable (e.g. ports of a switched network) and that the SAVI device can be configured to drop non- compliant packets. For the rest of the document, we will assume that the binding anchors are ports of a switched network.

2.5. SAVI Logging

While the primary goal of SAVI is simply to prevent improper use of IP addresses, a secondary goal is to assist in traceability for determining who an imp-roper actor is. For example, if a remote site reports that a DoS (or component of a DDoS) is coming from the SAVI site, SAVI enforcement can be a useful component in a response.

In order to support these and other similar activities, it is a good idea if SAVI devices perform logging of the creation, modification, or removal of address bindings. Any protocol support, such as SYSLOG support for sending those logs to a common server, would be a topic for a future separate document.

2.6. SAVI protection perimeter

SAVI provides perimetrical security. This means that the SAVI devices form what can be called a SAVI protection perimeter and they verify that any packet that crosses the perimeter is compliant (i.e. the source address is validated). Once the packet is inside the perimeter, no further validations are performed to the packet. This model has implications both on how SAVI devices are deployed in the topology and on the configuration of the SAVI boxes.

The implication of this perimetrical security approach, is that there is part of the topology that is inside the perimeter and part of the topology that is outside the perimeter. This means that while packets coming from interfaces connected to the external part of the topology need to be validated by the SAVI device, packets coming from interfaces connected to the the internal part of the topology do not need to be validated. This significantly reduces the processing requirements of the SAVI device. It also implies that each SAVI device that is part of the perimeter, must be able to verify the source addresses of the packets coming from the interfaces connected to the external part of the perimeter. In order to do so, the SAVI device binds the source address to a binding anchor.

One possible approach would be for every SAVI device to store binding information about every source addresses in the subnetwork. This means that every SAVI device would store a binding for each source address of the local link. The problem with this approach is that it imposes significant memory burden on the SAVI devices. In order to reduce the memory requirements imposed to each device, the SAVI solution described in this specification distributes the storage of SAVI binding information among the multiple SAVI devices of a subnetwork. The SAVI binding state is distributed across the SAVI devices according to the following criteria: each SAVI device only stores binding information about the source addresses bound to anchors corresponding to the interfaces that connect to the part of the topology that is outside of the SAVI protection perimeter. Since all the untrusted packet sources are by definition in the external part of the perimeter, this means that the packets generated by each of the untrusted sources will reach the perimeter through one interface of a SAVI device. The binding information for that particular source address will be stored in this first SAVI device the packet reaches to.

This means the SAVI binding information will be distributed across multiple devices. In order to provide proper source address validation, it is critical that the information distributed among the different SAVI devices is coherent. In particular, it is important to avoid that the same source address is bound to different binding anchors in different SAVI devices. Should that occur, then it would mean that two hosts are allowed to send packets with the same source address, which is what SAVI is trying to prevent. In order to preserve the coherency of the SAVI bindings distributed among the SAVI devices within a realm, the Neighbour Discovery (ND) protocol is used, in particular the Neighbour Solicitation (NSOL) and Neighbour Advertisement (NADV) messages. Before creating a SAVI binding in the local SAVI database, the SAVI device will send a NSOL message querying for the address involved. Should any host reply to that message with a NADV message, the SAVI device that sent the NADV will infer that a binding for that address exists in another SAVI device and will not create a local binding for it. If no NADV message is received as a reply to the NSOL, then the local SAVI device will infer that no binding for that address exists in other SAVI device and will create the local SAVI binding for that address. (NOTE that the description included here is overly simplified to illustrate the mechanism used to preserve the coherency of the binding databases of the different SAVI devices. The actual SAVI mechanism normative specification as described in Section 3 varies in the fact that in some cases it is the SAVI device that generates the NSOL while in other cases it simply forwards the NSOL generated by the end host, and that the SAVI device will send multiple copies of the NSOL in order to improve the reliability of the message exchange, among other things).

So, summarizing, the proposed SAVI approach relies on the following design choices:

So, in a link that is constituted of multiple L2 devices, some of which are SAVI capable and some of which are not, the SAVI capable devices should be deployed forming a connected perimeter (i.e. that no data packet can get inside the perimeter without passing through a SAVI device). Packets that cross the perimeter will be validated while packets that do no cross the perimeter are not validated (hence SAVI protection is not provided for these packets). Consider the deployment of SAVI in the topology depicted in the following picture:

   +--+   +--+                          +--+ | +--+   |
   |H1|   |H2|                          |H3| | |R1|   |
   +--+   +--+                          +--+ | +--+   |
     |     |                              |  |  |     |
+-------------SAVI-PROTECTION-PERIMETER------+  |     |
|    |     |                              |     |     |
|  +-1-----2-+                          +-1-----2-+   |
|  |  SAVI1  |                          |  SAVI2  |   |
|  +-3--4----+                          +--3------+   |
|    |  |          +--------------+        |          |   
|    |  +----------|              |--------+          |
|    |             |   SWITCH-A   |                   |
|    |  +----------|              |--------+          |
|    |  |          +--------------+        |          |
|  +-1--2----+                          +--1------+   |
|  |  SAVI3  |                          |  SAVI4  |   |
|  +-3-----4-+                          +----4----+   |
|    |     |                                 |        |
|      +------SAVI-PROTECTION-PERIMETER---------------+
|    | |   |                                 |
|  +--+|  +--+                            +---------+
|  |R2||  |H4|                            |SWICTH-B |
|  +--+|  +--+                            +---------+
+------+   	                                |    |
                                          +--+  +--+
                                          |H5|  |H6|
                                          +--+  +--+


In the figure above, the SAVI protection perimeter is provided by 4 SAVI devices, namely SAVI1, SAVI2, SAVI3 and SAVI4. These devices verify the source address and filter packets accordingly.

SAVI devices then have two types of ports: trusted ports and validating ports.

Trusted ports are used for connections with the trusted infrastructure, including the communication between SAVI devices, the communication with routers and the communication of other switches that while they are not SAVI devices, they only connect to trusted infrastructure (i.e. other SAVI devices, routers or other trusted nodes). So, in the figure above, Port 3 of SAVI1 and port 1 of SAVI3 are trusted because the connect two SAVI devices. Port 4 of SAVI1, port 3 of SAVI2, port 2 of SAVI3 and port 1 of SAVI4 are trusted because the connect to SWITCH-A to which only trusted nodes are connected. In the figure above, port 2 of SAVI2 and port 3 of SAVI3 are trusted ports because they connect to routers.

Validating ports are used for connection with non-trusted infrastructure. In particular, hosts are normally connected to validating ports. Non-SAVI switches that are outside of the SAVI protection perimeter also are connected through validating port. In particular, non-SAVI devices that connect directly to hosts or that have no SAVI capable device between themselves and the hosts are connected through a validating port. So, in the figure above, ports 1 and 2 of SAVI1, port 1 of SAVI2, port 4 of SAVI 3 are validating ports because they connect to hosts. Port 4 of SAVI4 is also a validating port because it is connected to SWITCH-B which is a non-SAVI capable switch which is connected to hosts H5 and H6.

3. FCFS SAVI normative specification

3.1. FCFS SAVI Data structures

FCFS SAVI function relies on state information binding the source address used in data packets to the binding anchor that contained the first packet that used that source IP address. Such information is stored in FCFS SAVI Data Base (DB). The FCFS SAVI DB will contain a set of entries about the currently used IP source addresses. So each entry will contain the following information:

In addition to this, FCFS SAVI need to know what are the prefixes that are directly connected, so it maintains a data structure called the the FCFS SAVI prefix list, which contains:

3.2. FCFS SAVI algorithm

3.2.1. Discovering on-link prefixes

In order to distinguish local traffic form transit traffic, the SAVI device relies on the FCFS SAVI Prefix list, which contains the set of on-link prefixes. A SAVI device MUST support the following two methods for populating the Prefix List: Manual configuration and Router Advertisement, as detailed next.

Manual configuration: A SAVI device MUST support manual configuration of the on-link prefixes included in the Prefix List.

Router Advertisement: A SAVI device MUST support discovery of on-link prefixes through Router Advertisement messages. The SAVI device will learn the on-link prefixes following the procedure defined for a host to process the Prefix Information options described in section 6.3.4 of [RFC4861] with the difference that the prefixes will be configured in the FCFS SAVI Prefix List instead than in the ND Prefix List. In addition, when the SAVI device boots, it MUST send a Router Solicitation message as described in section 6.3.7 of [RFC4861], using the unspecified source address.

3.2.2. Processing of transit traffic

The FCFS SAVI function is located in a forwarding device, such as a router or a layer-2 switch. The following processing is performed depending on the type of port the packet has been received through:

3.2.3. Processing of local traffic.

We describe next how the local traffic, including both control and data packets are processed by the SAVI device using a state machine approach.

The state machine described is for the binding of a given source IP address in a given SAVI device. So this means that all the packets described as inputs in the state machine above refer to that given IP address. The key attribute is the IP address. The full state information is:

The possible states are:

We will use VP for Validating Port and TP for Trusted Port.

After bootstrapping (when no binding exists), the state for all source IP address is NO-BIND i.e. there is no binding for the IP address to any binding anchor.

NO_BIND: The binding for a source IP address entry is in this state when it does not have any binding to an anchor. All addresses are in this state by default after bootstrapping, unless bindings were created for it.

TENTATIVE: The binding for a source address for which a data packet or a DAD_NSOL has been received is in this state during the waiting period during which the DAD procedure is being executed (either by the host itself the SAVI device on its behalf).

VALID: The binding for the source address is in this state after it has been verified. It means that it is valid and usable for filtering traffic.

TESTING_TP-LT: A binding for a source address enters in this state due to one of two reasons:

TESTING_VP: A binding for a source address enters in this state when a Duplicate Address Detection Neighbour Solicitation or a data packet has been received through a Validating port other than the one address is currently bound to. This implies that a host is performing the DAD procedure for that source address through a different port. This may due to an attack or to the fact that the host may have moved or just because another host tries to configure an address already used. The binding in this state is then being tested to determine which is the situation.

We describe next how the different inputs are processed depending on the state of the binding of the IP address (IPAddr).

A simplified figure of the state machine is included below.






Simplified state machine figure

+---------+  VP_NSOL, VP_DATA/2xNSOL                +-----------+
|         |---------------------------------------->|           |
| NO_BIND |                                         | TENTATIVE |
|         |<----------------------------------------|           |
+---------+                    TP_NADV, TP_NSOL/-   +-----------+
      ^                                                 |
      |                                                 | T.O.
  T.O.|                                                 |
      |                                                 v
+---------+  VP_NADV/-                              +-----------+
|         |---------------------------------------->|           |
| TESTING |                                         |   VALID   |
|  TP-LT  |<----------------------------------------|           |
+---------+                             TP_NSOL/-   +-----------+
  ^   |                                                ^    |
  |   |                                                |    |
  |   +---------------------      ---------------------+    |
  |      VP_NSOL/-         |      |  NP_NADV, T.O./-        |
  |                        v      |                         |
  |                     +-----------+                       |
  |                     |           |                       |
  +---------------------|  TESTING  |<----------------------+
     VP_NSOL, VP_DATA/- |    VP     |  T.O., VP_DATA, VP_NSOL,
                        +-----------+  VP_NADV/2xNSOL

MLD considerations

The SAVI device must join the Solicited Node Multicast group for all the addresses which state is other than NO_BIND. This is needed to make sure that the SAVI device will receive the DAD_NSOL for those addresses. Please note that it may not be enough to relay on the host behind the Validating port doing so, since the node may move and after a while, the packets for that particular solicited node multicast group will no longer be forwarded to the SAVI device. So, the SAVI device SHOULD join the solicited node multicast groups for all the addresses that are in a state other than NO_BIND

3.2.4. SAVI port configuration guidelines

The guidelines for port configuration in SAVI devices are:

3.2.5. VLAN support

In the case the SAVI device is a switch that supports VLANs, the SAVI implementation will behave as if there was one SAVI process per VLAN. The SAVI process of each VLAN will store the binding information corresponding the the nodes attached to that particular VLAN.

3.3. Protocol Constants

TENT_LT is 500 miliseconds

DEFAULT_LT is 5 minutes

4. Security Considerations

First of all, it should be noted that any SAVI solution will be as strong as the binding anchor that it uses. In particular, if the binding anchor is forgeable, then the resulting SAVI solution will be weak. For example, if the binding anchor is a MAC address that can be easily spoofed, then the resulting SAVI will not be stronger than that. On the other hand, if we use switch ports as binding anchors (and there is only one host connected to each port) it is likely that the resulting SAVI solution will be considerably more secure.

Denial of service attacks

There are two types of DoS attacks that can be envisaged in a SAVI environment. On one hand, we can envision attacks against the SAVI device resources. On the other hand, we can envision DoS attacks against the hosts connected to the network where SAVI is running.

The attacks against the SAVI device basically consist on making the SAVI device to consume its resource until it runs out of them. For instance, a possible attack would be to send packets with different source addresses, making the SAVI device to create state for each of the addresses and waste memory. At some point the SAVI device runs out of memory and it needs to decide how to react in this situation. The result is that some form of garbage collection is needed to prune the entries. It is RECOMMENDED that when the SAVI device runs out of the memory allocated for the SAVI DB, it creates new entries by deleting the entries which Creation Time is higher. This implies that older entries are preserved and newer entries overwrite each other. In an attack scenario where the attacker sends a batch of data packets with different source address, each new source address is likely to rewrite another source address created by the attack itself. It should be noted that entries are also garbage collected using the LIFETIME, which is updated using data packets. The result is that in order for an attacker to actually fill the SAVI DB with false source addresses, it needs to continuously send data packets for all the different source addresses, in order for the entries to grow old and compete with the legitimate entries. The result is that the cost of the attack for the attacker is highly increased.

In addition, it is also RECOMMENDED that a SAVI device reserves a minimum amount of memory for each available port (in the case where the port is used as part of the L2 anchor). The recommended minimum is the memory needed to store 4 bindings associated to the port. The motivation for this recommendation is as follows: an attacker attached to a given port of a SAVI device may attempt to launch a DoS attack towards the SAVI device by creating many bindings for different addresses. It can do so, by sending DAD NSOL for different addresses. The result is that the attack will consume all the memory available in the SAVI device. The above recommendation aims to reserve a minimum amount of memory per port, so that hosts located in different ports can make use of the reserved memory for their port even if a DoS attack is occurring in a different port.

As the SAVI device may store data packets while the address is being verified, the memory for data packet storage may also be a target of DoS attacks. The effects of such attacks may be limited to the lack of capacity to store new data packets. The effect of such attack will be then that data packets will be dropped during the verification period. A SAVI device MUST limit the amount of memory used to store data packets, allowing the other functions to have available memory even in the case of an attacks as the above described.

The other type of attack is when an attacker manages to create state in the SAVI device that will result in blocking the data packets sent by the legitimate owner of the address. In IPv6 these attacks are not an issue thanks to the 2^64 addresses available in each link.

The SAVI device generates 2 DAD_NSOL packets upon the reception of a DAD_NSOL or a data packet. As such, the SAVI device can be used as an amplifier by attackers. In order to limit this type of attack, it is RECOMMENDED that the SAVI device performs rate limiting of the messages it generates. The rate limiting is performed on a per port basis, since having an attack on a given port should not prevent the SAVI device to function normally in the rest of the ports.

Residual threats.

SAVI perform its function by binding an IP source address to a binding anchor. If the attacker manages to send packets using the binding anchor associated to a given IP address, SAVI validation will be successful and the SAVI device will allow the packet through. This can be achieved by spoofing the binding anchor or because the binding anchor is shared among the legitimate owner of the address and the attacker. An example of the latter is the case where the binding anchor is a port of a switched network and a legacy switch (i.e. no SAVI capable switch) is connected to that port. All the source addresses of the hosts connected to the legacy switch will share the same binding anchor (i.e. the switch port). This means that hosts connected to the legacy switch can spoof each others IP address and this will not be detected by the SAVI device. This can be prevented by not sharing binding anchors among hosts.

FCFS SAVI assumes that a host will be able to defend its address when the DAD procedure is executed for its addresses. This is needed, among other things, to support mobility within a link (i.e. to allow a host to detach and reconnect to a different Layer_2 anchor of the same IP subnetwork, without changing its IP address). This means that when a DAD_NSOL is issued for a given IP address for which a binding exists in a SAVI device, the SAVI device expects to see a DAD_NADV coming from the binding anchor associated to that IP address in order to preserve the binding. If the SAVI device does not sees the DAD_NADV, it may grant the binding to a different binding anchor. This means that if an attacker manages to prevent a host from defending its source address, it will be able to destroy the existing binding and create a new one, with a different binding anchor. An attacker may do so for example by intercepting the DAD_NADV or launching a DoS attack to the host that will prevent it to issue proper DAD replies.

Security Logging

In order to improve the integration of SAVI into an overall security environment, and enable response to additional indirect security issues which SAVI can help ameliorate, it is helpful if SAVI systems log the creation, modification, and deletion of binding entries.

5. Contributors

6. Acknowledgments

This draft benefited from the input from: Joel Halpern, Christian Vogt, Dong Zhang, Frank Xia, Jean-Michel Combes and Lin Tao.

Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.

7. References

7.1. Normative References

[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

7.2. Informative References

[I-D.ietf-savi-framework] Wu, J, Bi, J, Bagnulo, M, Baker, F and C Vogt, "Source Address Validation Improvement Framework", Internet-Draft draft-ietf-savi-framework-05, July 2011.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.

Appendix A. Implications of not following the reccommended behaviour

This specification recommends SAVI implementations to generate a DAD_NSOL message upon the reception of a data packet for which they have no binding for. In this section we describe the implications of not doing so and simply discarding the data packet instead.

The main argument against discarding the data packet is the overall robustness of the resulting network. The main concern that has been stated is that a network running SAVI that discard data packets in this case may end up disconnecting legitimate users from the network, by filtering packets coming from them. The net result would a degraded robustness of the network as w whole, since legitimate users would perceive this as a network failure. There are three different causes that resulted in the lack of state in the binding device for a legitimate address, namely, packet loss, state loss and topology change. We will next perform an analysis for each of them.

Appendix A.1. Lack of binding state due to packet loss

The DAD procedure is inherently unreliable. It consists on sending a NSOL packet and if no NADV packet is received back, success is assumed and the host starts using the address. In general, the lack of response is because no other host has that particular address configured in their interface, but it may also be the case that the NSOL packet or the NADV packet has been lost. From the sending host perspective there is no difference and the host assumes that it can use the address. In other words, the default action is to allow the host to obtain network connectivity.

It should be noted that the loss of a DAD packet has little impact on the network performance, since address coalition is very rare and the host assumes success in that case. By designing a SAVI solution that would discard packets for which there is no binding, we are diametrically changing the default behavior in this respect, since the default would be that if the DAD packets are lost, then the node is disconnected from the network (as its packets are filtered). What is worse, the node has little clue of what is going wrong, since it has successfully configured an address but it has no connectivity. The net result is that the overall reliability of the network has significantly decreased as the lost of a single packet would imply that a host is disconnected from the network.

The only mechanism that the DAD has to improve its reliability is to send multiple NSOL. However, current RFC4862 defines a default value of 1 NSOL message for the DAD procedure, so requiring any higher value would imply manual configuration of all the hosts connected to the SAVI domain.

Appendix A.1.1. Why initial packets may be (frequently) lost

The case of LANs

Devices connecting to a network may experience periods of packet loss after the link-layer becomes available for two reasons: Invalid Authentication state and incomplete topology assessment. In both cases, physical-layer connection occurs initially and presents a medium where packeted are transmissible, but frame forwarding is not available across the LAN.

For the authentication system, devices on a controlled port are forced to complete 802.1X authentication which may take multiple round trips and many milliseconds to complete (see IEEE 802.1X-2004). In this time, initial DHCP, IPv6 Neighbour Discovery, Multicast Listener or Duplicate Address Detection messages may be transmitted. However, it has also been noted that some devices have the ability for the IP stack to not see the port as up until 802.1x has completed. Hence, that issue needs investigation to determine how common it is now.

Additionally, any system which requires user input at this stage can extend the authentication time, and thus the outage. This is problematic where hosts relying upon DHCP for address configuration time out.

Upon completion of authentication, it is feasible to signal upper layer protocols as to LAN forwarding availability. This is not typical today, so it is necessary to assume that protocols are not aware of the preceding loss period.

For environments which do not require authentication, addition of a new link can cause loops where LAN frames are forwarded continually. In order to prevent loops, all LANs today run a spanning-tree protocol, which selectively disables redundant ports. Devices which perform spanning-tree calculations are either traditional Spanning-Tree Protocol (STP) (see IEEE802.1D-1998) or rapidly converging versions of the same (RSTP/MSTP) (see IEEE 802.1D-2004 and IEEE 802.1Q-2005).

Until a port is determined to be an edge port (RSTP/MSTP), the rapid protocol speaker has identified its position within the spanning-tree (RSTP/MSTP) or completed a Listening phase (STP), its packets are discarded.

For ports which are not connected to rapid protocol switches, it takes a minimum three seconds to perform edge port determination (see IEEE 802.1D-2004). Alternatively completion of Listening phase takes 15 seconds (see IEEE 802.1D-1998). This means that during this period, the link-layer appears available, but initial packet transmissions into and out of this port will fail.

It is possible to pre-assess ports as edge ports using manual configuration of all the involved devices and thus make them immediately transmissible. This is never default behaviour though.

The case fixed access networks

In fixed access networks such as DSL and Cable the end hosts are usually connected to the access network through a residential gateway (RG). If the host interface is initialized prior to the residential gateway getting authenticated and connected to the access network, the access network is not aware of the DAD packets that the host sent out. As an example, in DSL networks the Access Node(DSLAM) that needs to create and maintain binding state will never see the DAD message that is required to create such state.

Appendix A.1.1.1. Special sub-case:SAVI device rate-limiting packets

A particular sub-case is the one where the SAVI device itself "drops" ND packets. In order to protect itself against DoS attacks and flash-crowds, the SAVI device will have to rate-limit the processing of packets triggering the state creation process (which require processing from the SAVI device). This implies that the SAVI device may not process all the ND packets in case it is under heavy conditions. The result is that the SAVI device will fail to create a binding for a given DAD NSOL packet, which implies that the data packets coming from the host that sent the DAD NSOL packet will be filtered if this approach is adopted. The problem is that the host will assume that the DAD procedure was successful and will not perform the DAD procedure again which in turn will imply that the host will be disconnected from the network. While it is true that the SAVI device will also have to rate limit the processing of the data packets, the host will keep on sending data packets, so it is possible to recover from the alternative approach where data packets trigger the binding creation procedure.

Appendix A.2. Lack of binding state due to a change in the topology

In the case SAVI is being deployed in a switched Ethernet network, topology changes may result in a SAVI device receiving packets from a legitimate user for which the SAVI device does not have a binding for. Consider the following example:

	+------+             +--------+       +---------------+
	|SAVI I|-------------|SWITCH I|-------|rest of the net|
	+------+             +--------+       +---------------+
	   |                    |
	   |                 +--------+
	   |                 | SAVI II|
	   |                 +--------+
	   |   +----------+     |
	   +---|SWITCH II |-----+
	        | Host|


Suppose that after bootstrapping all the elements are working properly and the spanning tree is rooted in the router and it includes one branch that goes SWITCH I-SAVI I- SWITCH II and another branch that goes SWITCH I-SAVI II.

Suppose that the Host boots at this moment and sends the DAD NSOL. The message is propagated through the spanning tree and it received by SAVI I but not by SAVI II. SAVI I creates the binding.

Suppose that SAVI I fails and the spanning tree reconverges to SWITCH I- SAVI II- SWITCH II. Now data packets coming from the Host will be coursed through SAVI II which does not have binding state and will drop the packets.

Appendix A.3. Lack of binding state due to state loss

The other reason why a SAVI device may not have state for a legitimate address is simply because it lost it. State can be lost due to a reboot of the SAVI device or other reasons such as memory corruption. So, the situation would be as follows: The host performs the DAD procedure and the SAVI device creates a binding for the host's address. The host successfully communicate for a while. The SAVI device reboots and lost the binding state. The packets coming from the host are now discarded as there is no binding state for that address. It should be noted that in this case, the host has been able to use the address successfully for a certain period of time.

Architecturally, the degradation of the network robustness in this case can be easily explained by observing that this approach to SAVI implementation breaks the fate-sharing principle. RFC 1958 reads:

By binding the fate of the host's connectivity to the state in the SAVI device, we are breaking this principle and the result is degraded network resilience.

Moving on to more practical matters, we can dig deeper into the actual behaviour by considering two scenarios, namely, the case where the host is directly connected to the SAVI device and the case where there is an intermediate device between the two.

Appendix A.3.1. The case of a host directly connected to the SAVI device

The considered scenario is depicted in the following picture:

	+------+             +-----------+       +---------------+
	| Host |-------------|SAVI device|-------|rest of the net|
	+------+             +-----------+       +---------------+


The key distinguishing element of this scenario is that the host is directly connected to the SAVI device. As a result, if the SAVI device reboots, the host will see the carrier disappear and appear again.

RFC4862 requires that the DAD procedure is performed when the IP address is assigned to the interface, quoting RFC4862 section 5.4. Duplicate Address Detection:

However, it has been stated that some of the widely used OSes actually do perform DAD each time the link is up, but further data would be required to take this for granted. Assuming that behaviour, that implies that if the lost of state in the SAVI device also results in the link to the host going down, then the host using the tested OSes would redo the DAD procedure allowing the recreation of the binding state in the SAVI device and preserving the connectivity of the host. This would be the case if the SAVI device reboots. It should be noted though, that it is also possible that the binding state is lost for whatever error in the SAVI process and that the SAVI link does not goes down. In this case, the host would not redo the DAD procedure. However, it has been pointed out that it would be possible to require the SAVI process to flap the links of the device it is running, in order to make sure that the links goes down each time the SAVI process restarts and improving the chances the host will redo the DAD procedure when the SAVI process is rebooted.

Appendix A.3.2. The case of a host connected to the SAVI device through one or more legacy devices.

The considered scenario is depicted in the following picture:

	+------+      +-------------+       +-----------+       +---------------+
	| Host |------|Legacy device|-------|SAVI device|-------|rest of the net|
	+------+      +-------------+       +-----------+       +---------------+


The key distinguishing element of this scenario is that the host is not directly connected to the SAVI device. As a result, if the SAVI device reboots, the host will not see any changes.

In this case, the host would get get disconnected from the rest of the network since the SAVI device would filter all its packets once the state has gone. As the node will not perform the DAD procedure again, it will remain disconnected until it reboots.

As a final comment, it should be noted that it may not be obvious to the network admin which scenario its network is running. Consider the case of a campus network where all the switches in the network are SAVI capable. A small hub connected in the office would turn this into the scenario where the host is not directly connected to the SAVI device. Moreover, consider the case of a host running multiple virtual machines connected through a virtual hub, depending on the implementation of such a virtual hub, may turn a directly connected host scenario to the scenario where the multiple (virtual) hosts are connected through a legacy (virtual) hub.

Appendix A.3.2.1. Enforcing direct connectivty between the SAVI device and the host

It has been argued that enforcing the direct connectivity between the SAVI device and the end host is actually a feature. There are several comments that can be made in this respect:

Authors' Addresses

Erik Nordmark Cisco 510 McCarthy Blvd. Milpitas, California 95035 UNITED STATES EMail:
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6248814 EMail: URI:
Eric Levy-Abegnoli Cisco Systems Village d'Entreprises Green Side - 400, Avenue Roumanille Biot-Sophia Antipolis - 06410, France EMail: