[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-bagnulo-savi-fcfs) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 6620

Network Working Group                                        E. Nordmark
Internet-Draft                                                       Sun
Intended status: Standards Track                              M. Bagnulo
Expires: January 13, 2011                                           UC3M
                                                        E. Levy-Abegnoli
                                                           Cisco Systems
                                                           July 12, 2010


FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally
                           Assigned Addresses
                        draft-ietf-savi-fcfs-04

Abstract

   This memo describes FCFS SAVI a mechanism to provide source address
   validation for IPv6 networks using the First-Come First-Serve
   approach.  The proposed mechanism is intended to complement ingress
   filtering techniques to provide a higher 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 http://datatracker.ietf.org/drafts/current/.

   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 January 13, 2011.

Copyright Notice

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Nordmark, et al.        Expires January 13, 2011                [Page 1]

Internet-Draft                  FCFS SAVI                      July 2010


   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.



































Nordmark, et al.        Expires January 13, 2011                [Page 2]

Internet-Draft                  FCFS SAVI                      July 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Design considerations  . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Scope of FCFS SAVI . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Constraints for FCFS SAVI  . . . . . . . . . . . . . . . .  5
     2.3.  Address ownership proof  . . . . . . . . . . . . . . . . .  5
     2.4.  Layer-2 Anchor considerations  . . . . . . . . . . . . . .  6
     2.5.  Special cases  . . . . . . . . . . . . . . . . . . . . . .  6
   3.  SAVI topology and port configuration . . . . . . . . . . . . .  6
     3.1.  SAVI enforcement perimeter . . . . . . . . . . . . . . . .  7
     3.2.  SAVI port configuration guidelines . . . . . . . . . . . . 10
     3.3.  VLAN support . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  FCFS SAVI specification  . . . . . . . . . . . . . . . . . . . 11
     4.1.  FCFS SAVI Data structures  . . . . . . . . . . . . . . . . 11
     4.2.  FCFS SAVI algorithm  . . . . . . . . . . . . . . . . . . . 11
       4.2.1.  Discovering on-link prefixes . . . . . . . . . . . . . 11
       4.2.2.  Processing of transit traffic  . . . . . . . . . . . . 12
       4.2.3.  Processing of local traffic. . . . . . . . . . . . . . 12
     4.3.  Protocol Constants . . . . . . . . . . . . . . . . . . . . 18
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   6.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Appendix A.  Implications of not following the reccomended
                behaviour . . . . . . . . . . . . . . . . . . . . . . 21
     A.1.  Lack of binding state due to packet loss . . . . . . . . . 21
       A.1.1.  Why initial packets may be (frequently) lost . . . . . 22
     A.2.  Lack of binding state due to a change in the topology  . . 24
     A.3.  Lack of binding state due to state loss  . . . . . . . . . 24
       A.3.1.  The case of a host directly connected to the SAVI
               device . . . . . . . . . . . . . . . . . . . . . . . . 25
       A.3.2.  The case of a host connected to the SAVI device
               through one or more legacy devices.  . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27














Nordmark, et al.        Expires January 13, 2011                [Page 3]

Internet-Draft                  FCFS SAVI                      July 2010


1.  Introduction

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


2.  Design considerations

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 verify that the source
   address of the packets generated by the hosts attached to the local
   link have not been spoofed.

   In any link there usually are hosts and routers attached.  Hosts
   generate packets with their own address as the source address.  This
   is the so-called local traffic.  While 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 what the so-called 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
   addresses, in particular with address configured through stateless
   address autoconfiguration [RFC4862].  Manually configured 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 (add reference when available).






Nordmark, et al.        Expires January 13, 2011                [Page 4]

Internet-Draft                  FCFS SAVI                      July 2010


2.2.  Constraints for FCFS SAVI

   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 must solely rely in the usage of already available
   protocols.  This means that FCFS SAVI cannot 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 any source address validation solution, we need to define some
   address ownership proof concept i.e. what it means to be able to
   proof that a given host owns a given address in the sense that the
   host is entitled to send packet 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 approach.  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 the layer-2 information that
   the FCFS SAVI box has available (e.g. the port in a switched LAN).
   Following data packets containing that IP source address must use the
   same layer-2 information 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 layer-2 information has changed.  In
   order to cope with this case, the defined FCFS SAVI behaviour implies
   the verification whether the host is still reachable using the



Nordmark, et al.        Expires January 13, 2011                [Page 5]

Internet-Draft                  FCFS SAVI                      July 2010


   previous layer-2 information.  In order to do that FCFS SAVI uses the
   Neighbour Discovery (ND) protocol.  If the host is no longer
   reachable at the previously recorded layer-2 information, FCFS SAVI
   assumes that the new location is valid and creates a new binding
   using the new layer-2 information.  In case the host is still
   reachable using the previously recorded information, the packets
   coming from the new layer-2 information 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.  Layer-2 Anchor considerations

   Any SAVI solution is not stronger than the Layer-2 anchor it uses.
   If the Layer-2 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 Layer-2
   anchor is easily spoofable and the SAVI device is configured to drop
   no compliant packets, then the usage of SAVI may open a new vector of
   Denial of Service attacks, based on spoofed Layer-2 anchors.  For
   that reason, in this document, we assume that the Layer-2 anchors
   used by the SAVI solution are not easily spoofable (e.g. ports of a
   switched network) and that the SAVI device MAY be configured to drop
   non- compliant packets.  If the SAVI solution proposed in this
   document is to be used with weaker Layer-2 anchors (such as MAC
   addresses), logging is RECOMMENDED instead of dropping non-compliant
   packets.  For the rest of the document, we will assume that the
   Layer-2 anchors are ports of a switched network.

2.5.  Special cases

   The following special cases that need to be considered
   o  Hosts with multiple physical interfaces connected to the same
      link.
   o  Anycast i.e. multiple hosts using the same source address to send
      packets.
   o  Proxy ND i.e. host sending packets on behalf of other, in a
      layer-3 transparent manner.
   o  Optimistic Duplicate Address Detection (DAD) [RFC4429].


3.  SAVI topology and port configuration






Nordmark, et al.        Expires January 13, 2011                [Page 6]

Internet-Draft                  FCFS SAVI                      July 2010


3.1.  SAVI enforcement perimeter

   SAVI provides perimetrical security.  This means that the SAVI
   devices form what can be called a SAVI enforcement perimeter and they
   verify that any packet that crosses the perimeter is compliant (i.e.
   the source address related information 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 layer-2 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 binding for each source
   address to the local layer-2 anchor through packets with that source
   address can be received through.  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 will
   store binding information about the source addresses bound to layer-2
   anchors corresponding to the interfaces that connect to the part of
   the topology that is outside of the SAVI enforcement 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



Nordmark, et al.        Expires January 13, 2011                [Page 7]

Internet-Draft                  FCFS SAVI                      July 2010


   different SAVI devices is coherent.  In particular, it is important
   to avoid that the same source address is bound to different layer-2
   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 we are 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 as described
   below 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).

   So, summarizing, the proposed SAVI approach relies on the following
   design choices:
   o  SAVI provides perimetrical security, so some interfaces of a SAVI
      device will connect to the internal (trusted) part of the topology
      and other interfaces will connect to the external (untrusted) part
      of the topology.
   o  A SAVI device only verifies packets coming though one interface
      connected to the untrusted part of the topology.
   o  A SAVI device only stores binding information for the source
      addresses that are bound to layer-2 anchors that correspond to
      interfaces that connect to the untrusted part of the topology.
   o  SAVI uses the NSOL and NADV messages to preserve the coherency of
      the SAVI binding state distributed among the SAVI devices within a
      realm.

   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



Nordmark, et al.        Expires January 13, 2011                [Page 8]

Internet-Draft                  FCFS SAVI                      July 2010


   deployment of SAVI in the topology depicted in the following picture:

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


   In the figure above, the SAVI enforcement perimeter is provided by 4
   SAVI devices, namely SAVI1, SAVI2, SAVI3 and SAVI4.  These devices
   verify information related to the source address both in data and in
   ND packets and filter packets accordingly.

   SAVI devices then have two types of ports: trusted ports and
   validating ports.
   o  Validating ports (VPs) are those in which SAVI processing is
      performed.  This means that when a packet is received through one
      of the validating ports, the SAVI processing and filtering will be
      executed.
   o  Trusted ports (TPs) are those in which SAVI processing is not
      performed.  So, packets received through trusted ports are not
      validated and no SAVI processing is performed in them.

   Trusted ports are used for connections with trusted infrastructure,
   including the communication between SAVI devices, the communication



Nordmark, et al.        Expires January 13, 2011                [Page 9]

Internet-Draft                  FCFS SAVI                      July 2010


   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
   enforcement 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.2.  SAVI port configuration guidelines

   The guidelines for port configuration in SAVI devices are:
   o  Ports that are connected to another SAVI device SHOULD be
      configured as Trusted ports.  Not doing so will at least
      significantly increase the memory consumption in the SAVI devices.
   o  Ports connected to hosts SHOULD be configured as Validating ports.
      Not doing so will allow the host connected to that port to send
      packets with spoofed source address.
   o  Ports connected to routers SHOULD be configured as Trusted ports.
      Configuring them as Validating ports would increase the signaling
      due to SAVI.  The implication is that a router can generate
      traffic with any source address as they are assumed to be part of
      the trusted infrastructure.
   o  Ports connected to a chain of one or more legacy switches that
      have hosts connected SHOULD be configured as Validating ports.
      Not doing so will allow the host connected to any of these
      switches to send packets with spoofed source address.
   o  Ports connected to a chain of one or more legacy switches that
      have other SAVI devices and/or routers connected but had no hosts
      attached to them SHOULD be configured as Trusted ports.  Not doing
      so will at least significantly increase the memory consumption in
      the SAVI devices and increase the signaling traffic due to SAVI
      validation.





Nordmark, et al.        Expires January 13, 2011               [Page 10]

Internet-Draft                  FCFS SAVI                      July 2010


   o  Ports connected to a chain of one or more legacy switches that
      have a mix of SAVI devices and/or routers with hosts, SHOULD be
      configured as Validating ports.  Not doing so will allow the host
      connected to that port to send packets with spoofed source
      address.  Nevertheless, this topology will result in increased
      SAVI signaling and memory consumption compared to a topology where
      SAVI-hosts communications and inter SAVI communications are kept
      through different legacy switches.

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


4.  FCFS SAVI specification

4.1.  FCFS SAVI Data structures

   FCFS SAVI function relies on state information binding the source
   address used in data packets to the layer-2 information 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:
   o  IP source address
   o  Layer-2 information, such as Layer-2 address, port through which
      the packet was received, etc
   o  Lifetime
   o  Status:either tentative or valid
   o  Creation time: the value of the local clock when the entry was
      firstly created

   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:
   o  Prefix
   o  Interface where prefix is directly connected

4.2.  FCFS SAVI algorithm

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



Nordmark, et al.        Expires January 13, 2011               [Page 11]

Internet-Draft                  FCFS SAVI                      July 2010


   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.

4.2.2.  Processing of transit traffic

   The FCFS SAVI function is located in a forwarding device, such as a
   router or a layer-2 bridge.  The following processing is performed
   depending on the type of port the packet has been received through:
   o  If the data packet is received through a Trusted port, the data
      packet is forwarded and no SAVI processing performed to the
      packet.
   o  If the data packet is received through a Validating port, then the
      SAVI function checks whether the received data packet is local
      traffic or transit traffic.  It does so by verifying if the source
      address of the packet belongs to one of the directly connected
      prefixes available in the receiving interface.  It does so by
      searching the FCFS SAVI Prefix List.
      *  If the IP source address does not belong to one of the local
         prefixes of the receiving interface, this means that the data
         packet is transit traffic and the packet SHOULD be discarded.
         The FCFS SAVI function MAY send an ICMP Destination Unreachable
         Error back to the source address of the data packet.  (ICMPv6,
         code 5 (Source address failed ingress/egress policy) should be
         used).
      *  If the source address of the packet does belong to one of the
         prefixes available in the the receiving port, then the SAVI
         local traffic validation processes is executed as described
         below.

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




Nordmark, et al.        Expires January 13, 2011               [Page 12]

Internet-Draft                  FCFS SAVI                      July 2010


   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:
   o  IP ADDRESS: IPAddr
   o  LAYER_2 ANCHOR: P
   o  LIFETIME: LT

   The possible states are:
   o  NO_BIND
   o  TENTATIVE
   o  VALID
   o  TESTING_TP
   o  TESTING_VP
   o  TESTING_LIFETIME

   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 Layer-2 anchor.

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

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

   VALID: The binding for the source address has been verified, it is
   valid and usable for filtering traffic.

   TESTING_TP: A binding for a source address enters in this state when
   a Duplicate Address Detection Neighbour Solicitation has been
   received through a Trusted port.  This implies that a host is
   performing the DAD procedure for that source address in another
   switch.  This may due to an attack or to the fact that the host may
   have moved.  The binding in this state is then being tested to
   determine which is the situation.

   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



Nordmark, et al.        Expires January 13, 2011               [Page 13]

Internet-Draft                  FCFS SAVI                      July 2010


   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.

   TESTING_LIFETIME: A binding for a source address is in this state
   cause the lifetime of the entry is about to expire.  This is due to
   the fact that no packets has been seen by the SAVI device for the
   LIFETIME period.  This may be due to the host simply being silent or
   because the host has left the location.  In order to determine which
   is the case, a test is performed, in order to determine if the
   binding information should be discarded.

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

   A simplified figure of the state machine can be found at
   http://www.it.uc3m.es/~marcelo/SAVI_state_machine.pdf

   NO_BIND

   o  Upon the reception through a Validating Port (VP) of a Neighbour
      Solicitation (NSOL) generated by the Duplicate Address Detection
      (DAD) procedure (hereafter named DAD_NSOL) containing Target
      Address IPAddr, the SAVI device MUST execute the process of
      sending Neighbour Solicitation messages of the Duplicate Address
      Detection process as described in section 5.4.2 of [RFC4862] for
      the IPAddr using the following default parameters:
      DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour Solicitation
      messages for that address will be sent by the SAVI device) and
      RetransTimer set to 500 milliseconds (i.e. the time between two
      Neighbour Solicitation messages is 500 millisecs and also the wait
      time for replies in the form of Neighbour Advertisement for the
      queried address).  This is equivalent to sending the received
      DAD_NSOL message twice.  The DAD_NSOL messages are not sent
      through any of the ports configured as Validating Ports.  The NSOL
      messages are sent through the proper Trusted Ports (as defined by
      the switch behaviour that will depend on whether it performs MLD
      snooping or not).
      *  EDITOR NOTE: We need to rate limit the emission of NSOL of the
         SAVI device as a whole.
      *  EDITOR NOTE 2: should we send the NSOL through the port the
         packet was received through?. --JMC-- IMHO, if the SAVI device
         has lost all the bindings (e.g. due to a crash) and, in fact,
         had already before a binding for this IPAddr/Port, if the
         action is triggered by a data packet, it should send the
         DAD_NSOL through this port to regenerate the binding. --JMC--



Nordmark, et al.        Expires January 13, 2011               [Page 14]

Internet-Draft                  FCFS SAVI                      July 2010


      The state is moved to TENTATIVE.  The LIFETIME is set to TENT_LT
      (i.e.  LT==TENT_LT) and the LAYER_2 ANCHOR is set to VP (i.e.
      P==VP)
   o  Upon the reception through a Validating Port (VP) of a DATA packet
      containing IPAddr as the source address, the SAVI device SHOULD
      execute the process of sending Neighbour Solicitation messages of
      the Duplicate Address Detection process as described in section
      5.4.2 of [RFC4862] for the IPAddr using the following default
      parameters: DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour
      Solicitation messages for that address will be sent by the SAVI
      device) and RetransTimer set to 500 milliseconds (i.e. the time
      between two Neighbour Solicitation messages is 500 millisecs and
      also the wait time for replies in the form of Neighbour
      Advertisement for the queried address).  The implications of not
      following the reccomended behaviour are described in Appendix A
      The DAD_NSOL messages are not sent through any of the ports
      configured as Validating Ports.  The NSOL messages are sent
      through the proper Trusted Ports (as defined by the switch
      behaviour that will depend on whether it performs MLD snooping or
      not).  The SAVI device MAY discard the data packet while the DAD
      procedure is being executed.
      *  EDITOR NOTE: We need to rate limit the emission of NSOL of the
         SAVI device as a whole.
      *  EDITOR NOTE 2: should we send the NSOL through the port the
         packet was received through?. --JMC-- IMHO, if the SAVI device
         has lost all the bindings (e.g. due to a crash) and, in fact,
         had already before a binding for this IPAddr/Port, if the
         action is triggered by a data packet, it should send the
         DAD_NSOL through this port to regenerate the binding. --JMC--
      The state is moved to TENTATIVE.  The LIFETIME is set to TENT_LT
      (i.e.  LT==TENT_LT) and the LAYER_2 ANCHOR is set to VP (i.e.
      P==VP)
   o  Data packets containing IPAddr as the source address received
      through Trusted ports are processed and forwarded as usual (i.e.
      no special SAVI processing)
   o  DAD_NSOL packets containing IPAddr as the target address received
      through a Trusted port are NOT forwarded through any of the
      Validating ports but they are sent through the proper Trusted
      Ports (as defined by the switch behaviour that will depend on
      whether it performs MLD snooping or not)
   o  Neighbor Advertisement packets sent to all nodes as a reply to the
      DAD_NSOL (hereafter called DAD_NADV) containing IPAddr as the
      target address coming through a Validating port are discarded.
   o  Other signaling packets are processed and forwarded as usual (i.e.
      no SAVI processing)

   TENTATIVE




Nordmark, et al.        Expires January 13, 2011               [Page 15]

Internet-Draft                  FCFS SAVI                      July 2010


   o  If the LIFETIME times out, the state is moved to VALID.  The
      LIFETIME is set to DEFAULT_LT (i.e.  LT== DEFAULT_LT).  Stored
      data packets are forwarded (if any).
   o  If a Neighbour Advertisement (NADV) is received through a Trusted
      Port with Target Address set to IPAddr, then state is set to
      NO_BIND and the LAYER_2 ANCHOR and the LIFETIME are cleared.  Data
      packets stored corresponding to this binding are discarded.
   o  If a NADV is received through a Validating Port with Target
      Address set to IPAddr, the NADV packet is discarded
   o  If a data packet with source address IPAddr is received with
      Layer_2 anchor equal to P, then the packet is either stored or
      discarded.
      *  EDITOR NOTE: we need to define a maximum storage space for the
         data packets.  Having a single default value may be hard since
         it will heavily depend on the capability of the device.  Maybe
         it would be enough that the device has a maximum and that the
         value can be configured?
   o  If a data packet with source address IPAddr is received through a
      Trusted port, the data packet is forwarded.  The state is
      unchanged. ( waiting for the NADV?)
   o  If a data packet with source address IPAddr is received through a
      Validating port other than P, the data packet is discarded.
   o  Other signaling packets are processed and forwarded as usual (i.e.
      no SAVI processing)
      *  EDITOR NOTE: this may need more thought

   VALID

   o  If a data packet containing IPAddr as a source address arrives
      from Validating port P, then the LIFETIME is set to DEFAULT_LT and
      the packet is forwarded as usual.
      *  EDITOR NOTE: Is this feasible? i.e. to reset a timer each time
         a data packet arrives?  We could just have a long lifetime and
         actively check for the host when the lifetime is about to
         expire.
   o  If a DAD_NSOL is received from a Trusted port, then the DAD_NSOL
      message is forwarded to port P and it is also forwarded to the
      proper Trusted Ports (as defined by the switch behaviour that will
      depend on whether it performs MLD snooping or not).  The state is
      changed to TESTING_TP.  The LIFETIME is set to TENT_LT.
   o  If a data packet containing source address IPAddr or a DAD_NSOL
      packet with target address set to IPAddr is received through a
      Validating port P' other than P, then the SAVI device will execute
      the process of sending DAD_NSOL messages as described in section
      5.4.2 of [RFC4862] for the IPAddr using the following default
      parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL messages
      for that address will be sent by the SAVI device) and RetransTimer
      set to 500 milliseconds (i.e. the time between two NSOL messages



Nordmark, et al.        Expires January 13, 2011               [Page 16]

Internet-Draft                  FCFS SAVI                      July 2010


      is 500 millisecs and also the wait time for replies in the form of
      Neighbour Advertisement for the queried address).  The DAD_NSOL
      message will be forwarded to the port P.
      *  EDITOR NOTE: should we also forward it though the TP?
         Theoretically, there shouldn't be another binding in any other
         SAVI device, so there should not be a need for this.
      The state is moved to TESTING_VP.  The LIFETIME is set to TENT_LT.
      The SAVI device MAY discard the data packet while the DAD
      procedure is being executed.
   o  If the LIFETIME expires, then the SAVI device will execute the
      process of sending DAD_NSOL messages as described in section 5.4.2
      of [RFC4862] for the IPAddr using the following default
      parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL messages
      for that address will be sent by the SAVI device) and RetransTimer
      set to 500 milliseconds (i.e. the time between two NSOL messages
      is 500 millisecs and also the wait time for replies in the form of
      Neighbour Advertisement for the queried address).  The DAD_NSOL
      messages will be forwarded to the port P. The state is changed to
      TESTING_LIFETIME and the LIFETIME is set to TENT_LT.
   o  If a data packet containing IPAddr as a source address arrives
      from Trusted port, the packet is discarded.
      *  EDITOR NOTE: receiving such a packet means that another SAVI
         device has created a binding for this address, or that the
         perimeter has been breached.  This should be logged?
   o  Other signaling packets are processed and forwarded as usual (i.e.
      no SAVI processing).  In particular DAD_NADV containing IPAddr as
      the target address are forwarded as usual.

   TESTING_TP

   o  If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the
      state is changed to NO_BIND
   o  If a NADV message containing the IPAddr as target address is
      received through the Validating port P as a reply to the DAD_NSOL
      message, then the NADV is forwarded as usual and the state is
      changed to VALID.  The LIFETIME is set to DEFAULT_LT
   o  If a data packet containing IPAddr as the source address is
      received through port P, then the packet is forwarded.
      *  EDITOR NOTE: should we move back to VALID? --JMC-- As the host
         has been able to perform DAD before (i.e. as result, creation
         of a Binding in the SAVI device), the same device should be
         able to reply to the DAD_NSOL with a DAD_NADV: so, unless there
         is a specific case I missed, I would suggest to keep the STATE
         to TESTING_TP --JMC--
   o  If a data packet is received through a port that is other than
      port P, then the packet is discarded.

   TESTING_VP



Nordmark, et al.        Expires January 13, 2011               [Page 17]

Internet-Draft                  FCFS SAVI                      July 2010


   o  If the LIFETIME expires, the LAYER_2 ANCHOR is modified from P to
      P', the LIFETIME is set to DEFAULT_LT and the state is changed to
      VALID.  Data packet stored coming from P' are forwarded.
   o  If a NADV message containing the IPAddr as target address is
      received through the Validating port P as a reply to the DAD_NSOL
      message, then the NADV is forwarded as usual and the state is
      changed to VALID.  The LIFETIME is set to DEFAULT_LT
   o  If a data packet containing IPAddr as the source address is
      received through port P, then the packet is forwarded.
      *  EDITOR NOTE: should we move back to VALID? --JMC-- see similar
         comment above --JMC--
   o  If a data packet is received through a port that is other than
      port P, then the packet is discarded.

   TESTING_LIFETIME

   o  If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the
      state is changed to NO_BIND
   o  If a NADV message containing the IPAddr as target address is
      received through the Validating port P as a reply to the DAD_NSOL
      message, then the NADV is forwarded as usual and the state is
      changed to VALID.  The LIFETIME is set to DEFAULT_LT.
   o  If a data packet containing IPAddr as the source address is
      received through port P, then the packet is forwarded and the
      state is changed to VALID.  The LIFETIME is set to DEFAULT_LT.

   Rate limiting of messages: TBD

   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

4.3.  Protocol Constants

   TENT_LT

   DEFAULT_LT






Nordmark, et al.        Expires January 13, 2011               [Page 18]

Internet-Draft                  FCFS SAVI                      July 2010


5.  Security Considerations

   First of all, it should be noted that any SAVI solution will be as
   strong as the lower layer anchor that it uses.  In particular, if the
   lower layer anchor is forgeable, then the resulting SAVI solution
   will be weak.  For example, if the lower layer 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
   lower layer 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.

   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.

   Compare with Threat analysis and identify residual threats: TBD




Nordmark, et al.        Expires January 13, 2011               [Page 19]

Internet-Draft                  FCFS SAVI                      July 2010


6.  Contributors

      Jun Bi
      CERNET
      Network Research Center, Tsinghua University
      Beijing 100084
      China
      Email: junbi@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

      Alberto Garcia Martinez
      University Carlos III of Madrid
      Email: alberto@it.uc3m.es


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


8.  References

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



Nordmark, et al.        Expires January 13, 2011               [Page 20]

Internet-Draft                  FCFS SAVI                      July 2010


              Address Autoconfiguration", RFC 4862, September 2007.

8.2.  Informative References

   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, April 2006.


Appendix A.  Implications of not following the reccomended 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.

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



Nordmark, et al.        Expires January 13, 2011               [Page 21]

Internet-Draft                  FCFS SAVI                      July 2010


   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.

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 transmissable, 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).



Nordmark, et al.        Expires January 13, 2011               [Page 22]

Internet-Draft                  FCFS SAVI                      July 2010


   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.

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.





Nordmark, et al.        Expires January 13, 2011               [Page 23]

Internet-Draft                  FCFS SAVI                      July 2010


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.

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



Nordmark, et al.        Expires January 13, 2011               [Page 24]

Internet-Draft                  FCFS SAVI                      July 2010


   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:
      An end-to-end protocol design should not rely on the maintenance
      of state (i.e. information about the state of the end-to-end
      communication) inside the network.  Such state should be
      maintained only in the endpoints, in such a way that the state can
      only be destroyed when the endpoint itself breaks (known as fate-
      sharing).
   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.

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:
      Duplicate Address Detection MUST be performed on all unicast
      addresses prior to assigning them to an interface, regardless of
      whether they are obtained through stateless autoconfiguration,
      DHCPv6, or manual configuration, with the following exceptions:...

   However, it has been stated that some of the widely used OSes



Nordmark, et al.        Expires January 13, 2011               [Page 25]

Internet-Draft                  FCFS SAVI                      July 2010


   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.

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.



Nordmark, et al.        Expires January 13, 2011               [Page 26]

Internet-Draft                  FCFS SAVI                      July 2010


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

   Some people have 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:
      First, it may well be the case in some scenarios this is
      desirable, but it is certainly not the case in most scenarios.
      Because of that, the issue of enforcing direct connectivity must
      be treated as orthogonal to how data packets for which there is no
      binding are treated, since a general solution must support
      directly connected nodes and nodes connected through legacy
      switches.
      Second, as a matter of fact, the resulting behaviour described
      above would not actually enforce direct connectivity between the
      end host and the SAVI device as it would work as long as the SAVI
      device would not reboot.  So, the argument being made is that this
      approach is not good enough to provide a a robust network service,
      but it is not bad enough to enforce the direct connectivity of
      host to the SAVI switch.
      Third, it should be noted that topology enforcement is not part of
      the SAVI problem space and that the SAVI problem by itself is hard
      enough to add additional requirements.


Authors' Addresses

   Erik Nordmark
   Sun Microsystems, Inc.
   17 Network Circle
   Menlo Park, CA  94025
   USA

   Phone: +1 650 786 2921
   Email: Erik.Nordmark@Sun.COM


   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid  28911
   SPAIN

   Phone: 34 91 6248814
   Email: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es





Nordmark, et al.        Expires January 13, 2011               [Page 27]

Internet-Draft                  FCFS SAVI                      July 2010


   Eric Levy-Abegnoli
   Cisco Systems
   Village d'Entreprises Green Side - 400, Avenue Roumanille
   Biot-Sophia Antipolis - 06410
   France

   Email: elevyabe@cisco.com












































Nordmark, et al.        Expires January 13, 2011               [Page 28]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/