RFC 6620

FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses

📅 published May 2012, from ietf

RFC 6620 🎀 FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses

Part 1 of 8 💅 this is the start of the doc, more parts are coming!!

Okay bestie, so this is RFC 6620 (ISSN 2070-1721) 🦋, an Internet Standards Track doc from the IETF, published in May 2012. The authors are E. Nordmark (Cisco Systems), M. Bagnulo (UC3M), and E. Levy-Abegnoli (Cisco Systems). It doesn't list any RFCs that it obsoletes or updates, so it's standing on its own, no cap ✨

Abstract ✨

Okay so this memo describes FCFS SAVI (First-Come, First-Served Source Address Validation Improvement) 🌸. It's a mechanism that checks source addresses on IPv6 networks using the FCFS principle. It's meant to team up with ingress filtering techniques to help catch and stop source address spoofing 🫶

Status of This Memo 📜

This is an Internet Standards Track document 💜

This doc is a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 🧚

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6620 🔥

Copyright (c) 2012 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, which you can find at http://trustee.ietf.org/license-info. These are the versions in effect on the date this doc was published. Please read them carefully, because they spell out your rights and restrictions for this document 📖

Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License 🍓

This document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 🙈

So, unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be made outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🎀

Table of Contents

   1. Introduction ....................................................4
      1.1. Terminology ................................................4
   2. Background to FCFS SAVI .........................................4
      2.1. Scope of FCFS SAVI .........................................4
      2.2. Constraints for FCFS SAVI Design ...........................5
      2.3. Address Ownership Proof ....................................5
      2.4. Binding Anchor Considerations ..............................6
      2.5. FCFS SAVI Protection Perimeter .............................6
      2.6. Special Cases .............................................10
   3. FCFS SAVI Specification ........................................11
      3.1. FCFS SAVI Data Structures .................................12
      3.2. FCFS SAVI Algorithm .......................................12
           3.2.1. Discovering On-Link Prefixes .......................12
           3.2.2. Processing of Transit Traffic ......................13
           3.2.3. Processing of Local Traffic ........................13
           3.2.4. FCFS SAVI Port Configuration Guidelines ............21
           3.2.5. VLAN Support .......................................22
      3.3. Default Protocol Values ...................................22
   4. Security Considerations ........................................22
      4.1. Denial-of-Service Attacks .................................22
      4.2. Residual Threats ..........................................23
      4.3. Privacy Considerations ....................................24
      4.4. Interaction with Secure Neighbor Discovery ................25
   5. Contributors ...................................................25
   6. Acknowledgments ................................................25
   7. References .....................................................26
      7.1. Normative References ......................................26
      7.2. Informative References ....................................26
   Appendix A.  Implications of Not Following the Recommended
                Behavior .............................................28
     A.1.  Implications of Not Generating DAD_NS Packets upon the
           Reception of Non-Compliant Data Packets ...................28
       A.1.1.  Lack of Binding State due to Packet Loss...............28
       A.1.2.  Lack of Binding State due to a Change in the
               Topology ..............................................31
       A.1.3.  Lack of Binding State due to State Loss ...............31
     A.2.  Implications of Not Discarding Non-Compliant Data
           Packets ...................................................35

1. Introduction ✨

Okay so this memo describes FCFS SAVI, a mechanism that checks source addresses on IPv6 networks using the FCFS principle 💖 It's meant to complement ingress filtering techniques so spoofed source addresses can be detected and stopped. Section 2 gives the background and a description of FCFS SAVI, and Section 3 spells out the FCFS SAVI protocol 🧚

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📚

2. Background to FCFS SAVI 🌸

2.1. Scope of FCFS SAVI

The application scenario for FCFS SAVI is limited to the local link. So the goal is to check that the source addresses of packets from hosts attached to the local link haven't been spoofed 👀

On a link, you usually have hosts and routers attached. Hosts generate packets with their own address as the source address, and that's called "local traffic" 🦋 Routers send packets with a source IP address that isn't their own, because they're forwarding packets from other hosts (usually on a different link). That's called "transit traffic" 🚀

FCFS SAVI only applies to local traffic. It checks whether the traffic from hosts on the local link has a valid source address. Checking the source address of transit traffic is out of scope for FCFS SAVI. For transit traffic, other techniques like ingress filtering [RFC2827] are recommended. So FCFS SAVI complements ingress filtering: it leans on ingress filtering for transit traffic, and it validates local traffic, which ingress filtering doesn't cover. Using both techniques together raises the security level 🔥

FCFS SAVI is also designed for locally assigned IPv6 addresses, especially addresses configured through Stateless Address Autoconfiguration (SLAAC) [RFC4862] 💅 Manually configured IPv6 addresses can be supported by FCFS SAVI too, but manually configuring the binding on the FCFS SAVI device gives higher security, and it seems compatible with manual address management ✨ FCFS SAVI can also be used with IPv6 addresses assigned via DHCPv6. Those addresses ought to go through the Duplicate Address Detection (DAD) procedure. There's also a specific mechanism for DHCP-assigned addresses, defined in [SAVI-DHCP] 🎀 For more on how to use FCFS SAVI depending on the type of address management and the nature of the addresses, see the framework document [SAVI-FRAMEWORK] 🧚

2.2. Constraints for FCFS SAVI Design

FCFS SAVI is designed to be deployed in existing networks with a minimum set of changes 🌈 That's why FCFS SAVI doesn't need any changes in the host whose source address is being verified. Any verification relies only on protocols that are already available. FCFS SAVI doesn't define a new protocol, doesn't define any new message on existing protocols, and doesn't require a host to use an existing protocol message in a different way. In other words, no host changes are required 🫶

FCFS SAVI validation is done by the FCFS SAVI function. That function can live in different types of devices, including a router or a Layer 2 (L2) bridge 🍓 The basic idea is that the FCFS SAVI function sits at the points in the topology that can enforce correct usage of the source address, by dropping the non-compliant packets 👑

2.3. Address Ownership Proof ✨

okay so the main job of FCFS SAVI is checking that the source address in a data packet actually belongs to whoever sent it 🎀 Since FCFS SAVI only works on the local link, the sender is sitting right there on that link 🫶 To make this work we first need to pin down "address ownership," meaning what it actually means for a host to own an address and be allowed to send packets with it 💅 Once that's defined, we can figure out how a device confirms that the source address in a datagram belongs to the host that sent it 🦋

FCFS SAVI proves ownership using the First-Come, First-Served principle 👑 The first host to claim a source address owns it until further notice, lowkey iconic energy 💖 Since no host changes are acceptable, we have to confirm ownership without needing a brand-new protocol 🙈 So the first time a source address shows up, the device doing FCFS SAVI creates a state 🧚 That state binds the address to a binding anchor, which is just Layer 2 info the FCFS SAVI box can see (for example, the port on a switched LAN) 🌸

After that, any later data packets using that IP source address get checked against the same binding anchor 🔥 If the anchor matches, the sender is confirmed as the owner 💅

BUT there's more to think about, bestie 😭 Picture a host that moves from one segment of a LAN to another segment of the same subnetwork and keeps its IP address 🍓 The host still owns that address, but its binding anchor may have changed 💀 To handle this, FCFS SAVI behavior checks whether the host can still be reached through the previously recorded binding anchor 🧚 It does this using the Neighbor Discovery (ND) protocol 🌈 If the host can't be reached at the old anchor anymore, FCFS SAVI assumes the new location is legit and creates a new binding using the new binding anchor ✨ But if the host is still reachable through the previously recorded anchor, packets coming in from the new anchor get dropped 🙅‍♀️ not the vibe 😤

Also, this only covers local traffic 🫶 Transit traffic generated by a router gets verified using other techniques, like ingress filtering 🦋 FCFS SAVI checks won't be satisfied by transit traffic, because the router isn't the owner of the source address inside those packets 💜

2.4. Binding Anchor Considerations 💜

here's the tea: any SAVI solution is only as strong as the binding anchor it uses 🥀 If the anchor is easy to spoof, like a Media Access Control (MAC) address, the whole solution is weak 😬 The way you handle non-compliant packets has to be tuned to match 🎀 Especially if the anchor is easy to fake and the FCFS SAVI device is set to drop non-compliant packets, using FCFS SAVI could accidentally open up a brand-new Denial-of-Service (DoS) attack vector built on spoofed binding anchors 💀 That's why this specification says only switch ports MUST be used as binding anchors 👑 Any other kind of binding anchor is outside the scope of this specification 🙈 Before anyone uses one, they need to properly analyze what using it would mean 🧐 iykyk 🫶

2.5. FCFS SAVI Protection Perimeter

okay so FCFS SAVI is all about perimeter security 🏰✨ the FCFS SAVI devices basically build a wall called the FCFS SAVI protection perimeter, and they check every packet that crosses it to make sure the source address is legit (validated!). once a packet is inside the wall, nobody checks it again 🙈 this totally shapes how you deploy these devices in your network AND how you configure the boxes themselves 💅

so if the perimeter is the big deal, that means your topology has an inside part and an outside part 🌸 packets coming in from the outside need validating by the FCFS SAVI device, but packets from the inside part don't. this seriously cuts down how much processing the FCFS SAVI device has to do 🧠💖 it also means every FCFS SAVI device sitting on the perimeter must be able to verify the source addresses of packets coming in from the external side. to make that happen, the device binds the source address to a binding anchor 🎀

now, one option would be for every FCFS SAVI device to store binding info about every source address on the subnetwork. honestly? main character energy for the wrong reasons 😭 that would be a huge memory burden on each device. so instead, this spec splits up the FCFS SAVI binding storage across all the FCFS SAVI devices in a subnetwork 🦋 the rule is: each device only stores binding info for source addresses bound to anchors that match interfaces connected to the part of the topology OUTSIDE the perimeter. since every untrusted source is outside by definition, packets from each one will hit the perimeter through an FCFS SAVI device interface, and the binding for that source address gets stored in the first FCFS SAVI device the packet reaches 💜

so the binding info ends up spread across multiple devices, and that's where it gets tricky. for source validation to actually work, the info across all those devices has to stay coherent 🫶 the big no-no is the same source address being bound to different binding anchors on different FCFS SAVI devices. that would mean two hosts could send packets with the same source address, which is literally what FCFS SAVI is trying to stop 💀 to keep everything coherent across the devices in a realm, the spec uses the Neighbor Discovery (ND) protocol [RFC4861], specifically the Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages 📮 here's a simplified version of how that goes: before a device creates an FCFS SAVI binding in its local database, it sends an NS message asking about the address. if any host answers with an NA message, the device that sent the NS infers that a binding for that address already exists on another FCFS SAVI device, so it does NOT create a local one. if no NA comes back, the local device infers that no other FCFS SAVI device has a binding for it, so it creates the local binding ✨

to sum it all up, the FCFS SAVI approach runs on these design choices:

  • An FCFS SAVI provides perimetrical security, so some interfaces of an FCFS SAVI device connect to the internal (trusted) part of the topology, and other interfaces connect to the external (untrusted) part of the topology.
  • An FCFS SAVI device only verifies packets coming through an interface connected to the untrusted part of the topology.
  • An FCFS SAVI device only stores binding information for the source addresses that are bound to binding anchors corresponding to interfaces that connect to the untrusted part of the topology.
  • An FCFS SAVI uses NS and NA messages to preserve the coherency of the FCFS SAVI binding state distributed among the FCFS SAVI devices within a realm.

so, if your link is made of multiple L2 devices and only some of them are FCFS SAVI capable, the FCFS-SAVI-capable devices MUST be deployed forming a connected perimeter 🧱 (aka no data packet can sneak inside without passing through an FCFS SAVI device). packets that cross the perimeter get validated, and packets that don't cross it don't, so FCFS SAVI protection simply isn't provided for those 🙅‍♀️ check out this topology where FCFS SAVI gets deployed:

                                            +--------+
  +--+   +--+                          +--+ | +--+   |
  |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|                            |SWITCH-B |
|  +--+|  +--+                            +---------+
+------+                                    |    |
                                         +--+  +--+
                                         |H5|  |H6|
                                         +--+  +--+

Figure 1: SAVI Protection Perimeter 🖼️

in Figure 1, the FCFS SAVI protection perimeter is made by four FCFS SAVI devices: SAVI1, SAVI2, SAVI3, and SAVI4 🌈 they verify source addresses and filter packets accordingly 💅

now FCFS SAVI devices have two kinds of ports: Trusted Ports and Validating Ports 🎀

  • Validating Ports (VPs) are where FCFS SAVI processing happens. when a packet comes in through one of these, FCFS SAVI processing and filtering get executed.
  • Trusted Ports (TPs) are where FCFS SAVI processing does NOT happen. packets received through them aren't validated, and no FCFS SAVI processing is performed on them.

Trusted Ports are used for connections with trusted infrastructure 🛡️ that includes the links between FCFS SAVI devices, links to routers, and links to other switches that aren't FCFS SAVI devices but only connect to trusted infrastructure (other FCFS SAVI devices, routers, or other trusted nodes). so in Figure 1, Port 3 of SAVI1 and Port 1 of SAVI3 are trusted because they connect two FCFS SAVI devices 🤝 Port 4 of SAVI1, Port 3 of SAVI2, Port 2 of SAVI3, and Port 1 of SAVI4 are trusted because they connect to SWITCH-A, and only trusted nodes hang off SWITCH-A 🦋 and Port 2 of SAVI2 and Port 3 of SAVI3 are Trusted Ports too, because they connect to routers 👑

Validating Ports are for connections with non-trusted infrastructure 🙈 hosts usually plug into Validating Ports, and non-SAVI switches that sit outside the perimeter also connect through Validating Ports. specifically, non-SAVI devices that connect directly to hosts, or that have no SAVI-capable device between themselves and the hosts, go through a Validating Port. so in Figure 1, Ports 1 and 2 of SAVI1, Port 1 of SAVI2, and Port 4 of SAVI 3 are Validating Ports because they connect to hosts 💖 and Port 4 of SAVI4 is a Validating Port too, since it's connected to SWITCH-B, which is a non-SAVI-capable switch that hooks up hosts H5 and H6 🫶

2.6. Special Cases

okay now for the edge cases, which are honestly so fun 🧚

Multi-subnet links: sometimes one subnet has several prefixes 🌸 SAVI handles this directly, since any port can support multiple prefixes. forwarding packets between different prefixes with a router is even supported, as long as the router is connected to a Trusted Port, as recommended for all the routers.

Multihomed hosts: a multihomed host is a host with multiple interfaces 🍓 here's the tea on how SAVI and multihomed hosts interact. if each interface gets a different IP address and packets sent from each interface always carry the address assigned to that interface as the source address, then from a SAVI device's point of view, that's the same as two hosts with one interface each, each with its own IP address. SAVI supports that with no extra considerations ✨ but if the interfaces share the same IP address, OR the interfaces have different addresses but the host sends packets using one interface's address out of any of the interfaces, then SAVI does NOT directly support it 😬 that would need either connecting at least one interface of the multihomed host to a Trusted Port, or manually configuring the SAVI bindings so the host's address can be bound to multiple anchors at the same time.

Untrusted routers: okay picture this one 📱 routers can get dynamically attached to an FCFS SAVI network. a classic example is a mobile phone connecting to an FCFS SAVI switch while acting as a router for other personal devices that access the network through it. the router doesn't really count as trusted infrastructure here (if it did, it's likely all devices would be trusted too 🙃), so it can't be connected to a Trusted Port. and if it IS connected to a Validating Port, the FCFS SAVI switch would discard all the packets containing an off-link source address coming from that device 💀 so the default recommendation in this spec doesn't support that scenario 😭

3. FCFS SAVI Specification ✨

3.1. FCFS SAVI Data Structures

okay so the FCFS SAVI function has to remember who's who 🫶 It relies on state info that binds the source address used in data packets to the binding anchor of whichever packet first used that source IP address ✨ That info lives in an FCFS SAVI database (DB) 💾, and the DB holds a set of entries about the IP source addresses that are currently in use. Each entry has:

  • IP source address
  • Binding anchor: port through which the packet was received
  • Lifetime
  • Status: either TENTATIVE, VALID, TESTING_VP, or TESTING_TP-LT
  • Creation time: the value of the local clock when the entry was firstly created

FCFS SAVI also needs to know which prefixes are directly connected 🌈 so it keeps a data structure called the FCFS SAVI Prefix List, which has:

  • Prefix
  • Interface where prefix is directly connected

3.2. FCFS SAVI Algorithm

To tell local traffic apart from transit traffic 🦋, the FCFS SAVI device uses the FCFS SAVI Prefix List, which holds the set of on-link IPv6 prefixes. An FCFS SAVI device MUST support the following two methods for filling up that Prefix List: manual configuration and Router Advertisement, as detailed next.

Manual configuration: An FCFS SAVI device MUST support manual configuration of the on-link prefixes included in the Prefix List. For example, this can be used when there are no prefixes being advertised on the link. 🎀

Router Advertisement: An FCFS SAVI device MUST support discovery of on-link prefixes through Router Advertisement messages in Trusted Ports. For Trusted Ports, the FCFS SAVI device learns the on-link prefixes by 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 get configured in the FCFS SAVI Prefix List rather than in the ND Prefix List. Also, when the FCFS 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 lives in a forwarding device, like a router or a Layer 2 switch 🧚 What happens next depends on the type of port the packet came in through:

  • If the data packet is received through a Trusted Port, the data packet is forwarded, and no SAVI processing is performed on the packet.
  • If the data packet is received through a Validating Port, then the FCFS SAVI function checks whether the received data packet is local traffic or transit traffic. It does this by verifying whether the source address of the packet belongs to one of the directly connected prefixes available on the receiving interface, and it does that by searching the FCFS SAVI Prefix List.
    • If the IP source address does not belong to one of the on-link prefixes of the receiving interface, the data packet is transit traffic, and the packet SHOULD be discarded. (If for some reason discarding the packets is not acceptable, logging or triggering of alarms MAY be used.) The FCFS SAVI function MAY send an ICMP Destination Unreachable Error back to the source address of the data packet, and 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 on the receiving port, then the FCFS SAVI local traffic validation process is executed as described below. 🏠
    • If the source address of the packet is an unspecified address, the packet is forwarded, and no SAVI processing is performed, except for the case of the Neighbor Solicitation messages involved in the Duplicate Address Detection, which are treated as described in Section 3.2.3. 🌸

3.2.3. Processing of Local Traffic

Next up is local traffic, both control and data packets 📦 The FCFS SAVI device handles all of it with a state machine approach, and this is where things get spicy 🌶️

The state machine describes the binding of one given source IP address (called IPAddr) on one given FCFS SAVI device. That means every packet described as an input in the state machine refers to that same IP address. For data packets, the source address of the packet is IPAddr. For DAD_NS packets, the Target Address is IPAddr. The key attribute is the IP address, and the full state information is:

  • IP ADDRESS: IPAddr
  • BINDING ANCHOR: P
  • LIFETIME: LT

The possible states are:

  • NO_BIND
  • TENTATIVE
  • VALID
  • TESTING_TP-LT
  • TESTING_VP

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

After bootstrapping (when no binding exists), the state for all source IP addresses is NO-BIND, which means 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 them. 🫧

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

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

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

  • When a Duplicate Address Detection Neighbor 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 be 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. 🕵️
  • The lifetime of the binding entry is about to expire. This is due to the fact that no packets have been seen by the FCFS SAVI device for the LIFETIME period. This may be due to the host simply being silent or because the host has left the location. To determine which is the case, a test is performed to figure out whether the binding information should be discarded. 🙈

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

Next, we describe 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 in Figure 2 below. 🖼️

NO_BIND

  • Upon the reception through a Validating Port (VP) of a Neighbor Solicitation (NS) generated by the Duplicate Address Detection (DAD) procedure (hereafter named DAD_NS) containing Target Address IPAddr, the FCFS SAVI device MUST forward the NS, and T_WAIT milliseconds later, it MUST send a copy of the same message. These DAD_NS messages are not sent through any of the ports configured as Validating Ports. The DAD_NS messages are sent through the Trusted Ports (but, of course, subject to usual switch behavior and possible Multicast Listener Discovery (MLD) snooping optimizations). The state is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e., LT:=TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and the Creation time is set to the current value of the local clock. 🎯
  • 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 Neighbor 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 Neighbor Solicitation messages for that address will be sent by the SAVI device) and RetransTimer set to T_WAIT milliseconds (i.e., the time between two Neighbor Solicitation messages is T_WAIT milliseconds). The implications of not following the recommended behavior are described in Appendix A. The DAD_NS messages are not sent through any of the ports configured as Validating Ports. The DAD_NSOL messages are sent through Trusted Ports (but, of course, subject to usual switch behavior and possible MLD snooping optimizations). The SAVI device MAY discard the data packets while the DAD procedure is being executed, or it MAY store them until the binding is created. In any case, it MUST NOT forward the data packets until the binding has been verified. The state is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e., LT:=TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and the Creation time is set to the current value of the local clock. 🫶
  • Data packets containing IPAddr as the source address received through Trusted Ports are processed and forwarded as usual (i.e., no special SAVI processing). 🌷
  • DAD_NS packets containing IPAddr as the Target Address that are received through a Trusted Port MUST NOT be forwarded through any of the Validating Ports, but they are sent through the Trusted Ports (but, of course, subject to usual switch behavior and possible MLD snooping optimizations). 🚧
  • Neighbor Advertisement packets sent to all nodes as a reply to the DAD_NS (hereafter called DAD_NA) containing IPAddr as the Target Address, coming through a Validating Port, are discarded. 🗑️
  • Other signaling packets are processed and forwarded as usual (i.e., no SAVI processing). 📡

TENTATIVE

  • 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 (if any) are forwarded. 🎉
  • If a Neighbor Advertisement (NA) is received through a Trusted Port with the Target Address set to IPAddr, then the message is forwarded through port P, the state is set to NO_BIND, and the BINDING ANCHOR and the LIFETIME are cleared. Data packets stored corresponding to this binding are discarded. 💨
  • If an NA is received through a Validating Port with the Target Address set to IPAddr, the NA packet is discarded. 🙅‍♀️
  • If a data packet with source address IPAddr is received with binding anchor equal to P, then the packet is either stored or discarded. 🧺
  • If a data packet with source address IPAddr is received through a Trusted Port, the data packet is forwarded. The state is unchanged. 💜
  • If a data packet with source address IPAddr is received through a Validating Port other than P, the data packet is discarded. 🚫
  • okay so if a DAD_NS shows up from a Trusted Port with the Target Address set to IPAddr 💌, it gets forwarded to the Validating Port P, the state goes to NO_BIND, and the BINDING ANCHOR and LIFETIME get cleared. any data packets stored for that binding get discarded 🗑️ bye bye
  • if a DAD_NS with the Target Address set to IPAddr comes in from a Validating Port P' that isn't P, it gets forwarded to P and to the Trusted Ports, and the state stays in TENTATIVE 🦋. the BINDING ANCHOR switches from P to P', and LIFETIME becomes TENT_LT. any data packets stored for the binding with P get discarded 💅
  • other signaling packets get processed and forwarded as usual (aka no SAVI processing) 🫶

VALID 💖

  • if a data packet with IPAddr as the source address arrives from Validating Port P, then LIFETIME becomes DEFAULT_LT and the packet gets forwarded as usual ✨
  • if a DAD_NS comes from a Trusted Port, the DAD_NS gets forwarded to port P and also to the Trusted Ports (but obviously subject to usual switch behavior and possible MLD snooping optimizations 🧚). the state changes to TESTING_TP-LT, and LIFETIME is set to TENT_LT 🌸
  • if a data packet with source address IPAddr or a DAD_NA packet with the Target Address set to IPAddr arrives through a Validating Port P' other than P, then the SAVI device runs the process of sending DAD_NS messages described in Section 5.4.2 of [RFC4862] for IPAddr, using these default parameters: DupAddrDetectTransmits set to 2 (aka two NS messages for that address get sent by the SAVI device) and RetransTimer set to T_WAIT milliseconds (aka the time between two NS messages is T_WAIT milliseconds) ⏱️. the DAD_NS message gets forwarded to port P. the state moves to TESTING_VP, and LIFETIME is set to TENT_LT. the SAVI device MAY discard the data packet while the DAD procedure is running, or it MAY store them until the binding is created. but in any case, it MUST NOT forward the data packets until the binding has been verified 🔒
  • if a DAD_NS packet with the Target Address set to IPAddr arrives through a Validating Port P' other than P, then the SAVI device forwards the DAD_NS packet. then, T_WAIT milliseconds later, it runs the process of sending DAD_NS messages from Section 5.4.2 of [RFC4862] for IPAddr, with these default parameters: DupAddrDetectTransmits set to 1 and RetransTimer set to T_WAIT milliseconds. the DAD_NS messages get forwarded to port P. the state moves to TESTING_VP, and LIFETIME is set to TENT_LT. the SAVI device MAY discard the data packets while DAD is running, or it MAY store them until the binding is created. in any case, it MUST NOT forward the data packets until the binding has been verified 🙈
  • if LIFETIME expires, the SAVI device runs the process of sending DAD_NS messages described in Section 5.4.2 of [RFC4862] for IPAddr, with these default parameters: DupAddrDetectTransmits set to 2 (aka two NS messages for that address get sent by the SAVI device) and RetransTimer set to T_WAIT milliseconds (aka the time between two NS messages is T_WAIT milliseconds) 🍓. the DAD_NS messages get forwarded to port P. the state changes to TESTING_TP-LT, and LIFETIME is set to TENT_LT.
  • if a data packet with IPAddr as a source address arrives from a Trusted Port, the packet MAY be discarded. the event MAY be logged 👀
  • other signaling packets get processed and forwarded as usual (aka no SAVI processing). specifically, a DAD_NA coming from port P with IPAddr as the Target Address gets forwarded as usual 🌈

TESTING_TP-LT 🎀

  • if LIFETIME expires, the BINDING ANCHOR gets cleared and the state changes to NO_BIND 😭
  • if an NA message with IPAddr as the Target Address is received through the Validating Port P as a reply to the DAD_NS message, then the NA gets forwarded as usual and the state changes to VALID. LIFETIME is set to DEFAULT_LT 🥳
  • if a data packet with IPAddr as the source address is received through port P, then the packet gets forwarded and the state changes to VALID. LIFETIME is set to DEFAULT_LT 💜
  • if a DAD_NS is received from a Trusted Port, the DAD_NS is forwarded as usual 🧃
  • if a DAD_NS is received from a Validating Port P' other than P, the DAD_NS gets forwarded as usual, and the state moves to TESTING_VP 🦋
  • if a data packet is received through a Validating Port P' that isn't port P, then the packet gets discarded 🚫
  • if a data packet is received through a Trusted Port, then the packet MAY be discarded. the event MAY be logged 📝

TESTING_VP 🌷

  • if LIFETIME expires, the BINDING ANCHOR gets changed from P to P', LIFETIME becomes DEFAULT_LT, and the state changes to VALID. stored data packets coming from P' get forwarded 🎉
  • if an NA message with IPAddr as the Target Address is received through the Validating Port P as a reply to the DAD_NS message, then the NA gets forwarded as usual and the state changes to VALID. LIFETIME is set to DEFAULT_LT 💖
  • if a data packet with IPAddr as the source address is received through port P, then the packet gets forwarded 🛣️
  • if a data packet with IPAddr as the source address is received through a Validating Port P'' that isn't port P or P', then the packet gets discarded 🗑️
  • if a data packet with IPAddr as the source address is received through a Trusted Port (aka any port other than P), the state moves to TESTING_TP-LT, and the packet MAY be discarded 🙃
  • if a DAD_NS is received through a Trusted Port, the packet gets forwarded as usual, and the state moves to TESTING_TP-LT 🧚
  • if a DAD_NS is received through Validating Port P'' that isn't P or P', the packet gets forwarded as usual, and P'' is stored as the tentative port, aka P':=P''. the state stays the same 💅

Here's the simplified state machine, because one picture is worth a thousand bullet points 🌸

   +---------+  VP_NS, VP_DATA/2xNS                    +-----------+
   |         |---------------------------------------->|           |
   | NO_BIND |                                         | TENTATIVE |
   |         |<----------------------------------------|           |
   +---------+                    TP_NA, TP_NS/-       +-----------+
          ^                                                |
          |                                                | TimeOut
   Timeout|                                                |
          |                                                v
   +---------+  VP_NA/-                                +-----------+
   |         |---------------------------------------->|           |
   | TESTING |                                TP_NS/-  |           |
   |  TP-LT  |<----------------------------------------|   VALID   |
   |         |                           TimeOut/2xNS  |           |
   |         |<----------------------------------------|           |
   +---------+                                         +-----------+
     ^   |                                                ^    |
     |   |                                                |    |
     |   +---------------------      ---------------------+    |
     |       VP_NS/-          |     |  NP_NA, TimeOut/-        |
     |                        v     |                          |
     |                     +-----------+                       |
     |                     |           |                       |
     +---------------------|  TESTING  |<----------------------+
          VP_NS, VP_DATA/- |    VP     |  VP_DATA, VP_NS,
                           +-----------+  VP_NA/2xNS

                    Figure 2: Simplified State Machine

MLD Considerations 🧦

The FCFS SAVI device MUST join the solicited node multicast group for all the addresses with a state other than NO_BIND. this is needed so the FCFS SAVI device actually receives the DAD_NS for those addresses 📬. heads up, it may not be enough to rely on the host behind the Validating Port to do this, since the node may move, and after a while the packets for that particular solicited node multicast group won't be forwarded to the FCFS SAVI device anymore 😬. so the FCFS SAVI device MUST join the solicited node multicast groups for all the addresses that are in a state other than NO_BIND 💜

3.2.4. FCFS SAVI Port Configuration Guidelines 🔌

here's how port configuration works in FCFS SAVI devices 🫶

  • the FCFS SAVI realm (aka the realm inside the FCFS SAVI protection perimeter) MUST be connected. if it isn't, legitimate transit traffic may get dropped 🙅
  • ports connected to another FCFS SAVI device MUST be configured as Trusted Ports. skipping this will significantly increase the memory consumption in the FCFS SAVI devices and may result in legitimate transit traffic getting dropped 🧠
  • ports connected to hosts SHOULD be configured as Validating Ports. not doing so will let the host on that port send packets with spoofed source addresses 🫣. the valid exception is a trusted host (e.g., a server) that could be on a Trusted Port, but untrusted hosts MUST be connected to Validating Ports 🔐
  • ports connected to routers MUST be configured as Trusted Ports. configuring them as Validating Ports should result in transit traffic getting dropped 🚧
  • 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 let the host on any of those switches send packets with spoofed source addresses 👻. the valid exception is when the legacy switch only has trusted hosts attached, in which case it could be on a Trusted Port, but if there's at least one untrusted host on the legacy switch, then it MUST be connected to Validating Ports 🫠
  • ports connected to a chain of one or more legacy switches that have other FCFS SAVI devices and/or routers connected but no hosts attached MUST be configured as Trusted Ports. skipping this will at least significantly increase the memory consumption in the FCFS SAVI devices, increase the signaling traffic due to FCFS SAVI validation, and may result in legitimate transit traffic getting dropped 📈

3.2.5. VLAN Support 🎀

if the FCFS SAVI device is a switch that supports customer VLANs [IEEE.802-1Q.2005], the FCFS SAVI implementation MUST behave as if there's one FCFS SAVI process per customer VLAN 🏠. the FCFS SAVI process for each customer VLAN stores the binding information for the nodes attached to that particular customer VLAN 🗂️

3.3. Default Protocol Values 🌈

these are the default values used in the FCFS SAVI specification 💖

TENT_LT is 500 milliseconds

DEFAULT_LT is 5 minutes

T_WAIT is 250 milliseconds

an implementation MAY allow these values to be modified, but tuning them precisely is considered out of scope for this document 🧁

4. Security Considerations ✨

4.1. Denial-of-Service Attacks ✨

okay bestie, so there are two kinds of Denial-of-Service (DoS) attacks [RFC4732] that can be envisaged in an FCFS SAVI environment 🚨. one kind goes after the FCFS SAVI device's own resources, and the other goes after the hosts connected to the network where FCFS SAVI is running 💀.

attacks on the FCFS SAVI device basically mean making it eat up its resources until it's totally out 😩. like, an attacker could send packets with loads of different source addresses so the device creates state for each one and wastes memory. eventually the device runs out of memory and has to decide what to do, so some kind of garbage collection is needed to prune the entries 🧹. when the FCFS SAVI device runs out of the memory allocated for the FCFS SAVI DB, it is RECOMMENDED that it make room by deleting the entries with a higher Creation time 🎀. that means older entries are kept and newer entries overwrite each other. in an attack where the attacker sends a batch of data packets with different source addresses, each new source address is likely to overwrite another address the attack itself created 🙃. entries also get garbage collected using the LIFETIME, which is updated by data packets 💅. so for an attacker to actually fill the FCFS SAVI DB with false source addresses, they'd have to keep sending data packets for all the different addresses so the entries grow old and compete with the legit ones. the cost of the attack goes way up for the attacker, iykyk 💸.

in addition, it is RECOMMENDED that an FCFS 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 four bindings associated with the port. here's the motivation: an attacker attached to a given port of an FCFS SAVI device could try a DoS attack by creating many bindings for different addresses, and they can do that by sending DAD_NS for different addresses. the attack would then eat all the memory available in the FCFS SAVI device. the reserved minimum per port means hosts on different ports can still use their reserved memory even if a DoS attack is happening on a different port 🛡️.

as the FCFS SAVI device may store data packets while the address is being verified, the memory for data packet storage can also be a target of DoS attacks 🫣. the effects may be limited to a lack of capacity to store new data packets, and the effect will be that data packets get dropped during the verification period. so an FCFS SAVI device MUST limit the amount of memory used to store data packets, so the other functions still have memory available even when attacks like those above are happening 🙌.

the FCFS SAVI device generates two DAD_NS packets upon the reception of a DAD_NS or a data packet. that makes it a juicy amplifier for attackers 🚨. to limit this type of attack, the FCFS SAVI device MUST perform rate limiting of the messages it generates. the rate limiting is done per port, since an attack on one port shouldn't stop the FCFS SAVI device from working normally on the rest of the ports 🦋.

4.2. Residual Threats 🕵️‍♀️

okay so FCFS SAVI does its thing by binding an IP source address to a binding anchor 🔗. if the attacker manages to send packets using the binding anchor associated with a given IP address, FCFS SAVI validation will pass and the FCFS SAVI device will let the packet through 😬. this can happen by spoofing the binding anchor, or by sharing the binding anchor between the legit owner of the address and the attacker. an example of the sharing case is when the binding anchor is a port of a switched network and a legacy switch (i.e., not a SAVI-capable switch) is plugged into that port. all the source addresses of the hosts on that legacy switch share the same binding anchor (the switch port), so those hosts can spoof each other's IP address and FCFS SAVI won't catch it 🙈. the fix is not sharing binding anchors among hosts.

FCFS SAVI assumes a host will be able to defend its address when the DAD procedure runs for its addresses 🛡️. this is needed (among other things) to support mobility within a link, so a host can detach and reconnect to a different Layer 2 anchor of the same IP subnetwork without changing its IP address 🧳. so when a DAD_NS is issued for an IP address that already has a binding in an FCFS SAVI device, the device expects to see a DAD_NA coming from the binding anchor associated with that IP address in order to keep the binding. if it doesn't see the DAD_NA, it may grant the binding to a different binding anchor. so if an attacker stops a host from defending its source address, they can wipe the existing binding and create a new one with a different binding anchor 😈. an attacker could do this by intercepting the DAD_NA, or by launching a DoS attack on the host so it can't send proper DAD replies.

even if routers are considered trusted, nothing can stop a router from being compromised and sending traffic with spoofed IP source addresses 💀. that traffic would still be allowed by the current FCFS SAVI spec. one way to mitigate this could be a new port type (e.g., Router Port (RP)) that acts as a Trusted Port for the transit traffic and as a Validating Port for the local traffic ✨. a detailed solution for this is outside the scope of this document 📚.

4.3. Privacy Considerations 🔐

personally identifying info MUST NOT be included in the FCFS SAVI DB, with the MAC address as the canonical example, except when there's an attack attempt involved 🙅‍♀️. also, compliant implementations MUST NOT log binding anchor information unless there's an identified reason that the info is likely to be involved in detecting, preventing, or tracing actual source address spoofing 🕵️. info that isn't logged MUST be deleted as soon as possible (i.e., as soon as the state for a given address is back to NO_BIND) 🗑️. and info about the majority of hosts that never spoof SHOULD NOT be logged 🫶.

4.4. Interaction with Secure Neighbor Discovery 🧩

so even if FCFS SAVI could get info from ND messages secured with Secure Neighbor Discovery (SEND) [RFC3971], sometimes the FCFS SAVI device has to spoof DAD_NS messages without knowing the security credentials tied to the IPAddr (i.e., the private key used to sign the DAD_NS messages) 😭. so when SEND is deployed, it is recommended to use SEND SAVI [SAVI-SEND] rather than FCFS SAVI 💜.

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

6. Acknowledgments 👑

this document benefited from the input of the following people: Joel Halpern, Christian Vogt, Dong Zhang, Frank Xia, Jean-Michel Combes, Jari Arkko, Stephen Farrel, Dan Romascanu, Russ Housley, Pete Resnick, Ralph Droms, Wesley Eddy, Dave Harrington, 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

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[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

[SAVI-FRAMEWORK]
            Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
            "Source Address Validation Improvement Framework", Work
            in Progress, December 2011.

[SAVI-DHCP] Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for
            DHCP", Work in Progress, February 2012.

[SAVI-SEND] Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source-
            Address Validation Implementation", Work in Progress,
            March 2012.

[RFC1958]   Carpenter, B., "Architectural Principles of the
            Internet", RFC 1958, June 1996.

[RFC3971]   Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
            Neighbor Discovery (SEND)", RFC 3971, March 2005.

[RFC4732]   Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
            Service Considerations", RFC 4732, December 2006.

[IEEE.802-1D.1998]
            Institute of Electrical and Electronics Engineers, "IEEE
            Standard for Local and Metropolitan Area Networks Media
            Access Control (MAC) Bridges", IEEE Standard 802.1D,
            1998.

[IEEE.802-1D.2004]
            Institute of Electrical and Electronics Engineers, "IEEE
            Standard for Local and Metropolitan Area Networks Media
            Access Control (MAC) Bridges", IEEE Standard 802.1D,
            2004.

[IEEE.802-1Q.2005]
            Institute of Electrical and Electronics Engineers, "IEEE
            Standard for Local and metropolitan area networks -
            Virtual Bridged Local Area Networks", IEEE Standard
            802.1Q, May 2005.

[IEEE.802-1X.2004]
            Institute of Electrical and Electronics Engineers, "IEEE
            Standard for Local and metropolitan area networks - Port-
            Based Network Access Control", IEEE Standard 802.1X,
            2004.

this section qualifies some of the SHOULDs included in this specification by explaining the implications of not following the recommended behavior 🧐. we start by describing the implication of not generating DAD_NS upon the reception of a data packet for which there is no binding, and then we describe the implications of not discarding the non-compliant packets 💅.

A.1. Implications of Not Generating DAD_NS Packets upon the Reception of Non-Compliant Data Packets

Okay bestie, so this spec recommends that SAVI implementations generate a DAD_NS message when they get a data packet they have no binding for ✨ This section is about what happens if they don't do that and just discard the data packet instead 💀

The main argument against dropping the packet is the overall robustness of the network 😭 The big worry is that a SAVI network that discards data packets like this could end up disconnecting legit users by filtering their packets. That makes the whole network less robust, because real users would experience it as a network failure 🙈 There are three different causes for the binding device to be missing state for a legit address: packet loss, state loss, and topology change. We're going to analyze each one 🔍

A.1.1. Lack of Binding State due to Packet Loss

DAD is literally unreliable by design 💅 It sends an NS packet, and if no NA packet comes back, it assumes success and the host starts using the address. Usually no reply means no other host has that address configured on its interface. But it could also mean the NS packet or the NA packet got lost. From the sending host's point of view there's no difference, so it assumes it can use the address. In other words, the default action is to let the host get network connectivity 🦋

Losing a DAD packet doesn't really hurt network performance, since address collisions are super rare and the host assumes success in that case 🌸 But if we design a SAVI solution that discards packets with no binding, we totally flip the default behavior 😱 Now the default becomes: if the DAD packets get lost, the node is disconnected from the network, because its packets get filtered. Even worse, the node has basically no clue what went wrong, since it configured an address just fine but has no connectivity 💀 Net result: the overall reliability of the network drops hard, because losing a single packet can cut a host off entirely 📉

The only way DAD can get more reliable is by sending multiple NSs. But [RFC4862] defines a default value of 1 NS message for the DAD procedure, so requiring a higher value would mean manually configuring every host connected to the SAVI domain 🥲

A.1.1.1. Why Initial Packets May Be (Frequently) Lost

The Case of LANs 🌈

Devices connecting to a network can lose packets for a while after the link layer comes up, for two reasons: Invalid Authentication state and incomplete topology assessment. In both cases the physical connection is up and there's a medium where packets can be transmitted, but frame forwarding isn't available across the LAN yet 🧚

For the authentication side, devices on a controlled port are forced to complete 802.1X authentication, which may take multiple round trips and many milliseconds (see [IEEE.802-1X.2004]). During that time, initial DHCP, IPv6 Neighbor Discovery, Multicast Listener, or Duplicate Address Detection messages may get sent. Some devices can also have their IP stack not see the port as up until 802.1X has finished. So that issue needs investigating to figure out how common it is now 🤔

Also, any system that needs user input at this stage can make authentication take longer, which makes the outage longer too. This is a problem for hosts that rely on DHCP for their address and time out 😩

Once authentication finishes, it's possible to signal upper-layer protocols that LAN forwarding is available. That's not typical today though, so we have to assume protocols aren't aware of the earlier loss period 🫠

For environments without authentication, adding a new link can cause loops where LAN frames get forwarded forever 🔁 To prevent loops, all LANs today run a spanning tree protocol, which selectively disables redundant ports. The devices doing spanning tree calculations are either traditional Spanning Tree Protocol (STP) (see [IEEE.802-1D.1998]) or the faster converging versions of the same thing (Rapid Spanning Tree Protocol (RSTP) / Multiple Spanning Tree Protocol (RSTP)) (see [IEEE.802-1D.2004] and [IEEE.802-1Q.2005]) 🌳

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

For ports that aren't connected to rapid protocol switches, edge port determination takes a minimum of three seconds (see [IEEE.802-1D.2004]). Completing the Listening phase takes 15 seconds (see [IEEE.802-1D.1998]). During this window the link layer looks available, but the initial packet transmissions into and out of that port will fail 😵‍💫

You can pre-assess ports as edge ports with manual configuration of all the involved devices, so they're immediately transmissible. But that is never default behavior, bestie 🙅‍♀️

The Case of Fixed Access Networks 🏠

In fixed access networks like DSL and cable, end hosts usually connect to the access network through a residential gateway (RG). If the host interface comes up before the RG has been authenticated and connected to the access network, the access network never sees the DAD packets the host sent out 👀 For example, in DSL networks, the Access Node (Digital Subscriber Link Access Multiplexer (DSLAM)) that needs to create and maintain binding state will never see the DAD message needed to create that state 💔

A.1.1.1.1. Special Sub-Case: SAVI Device Rate-Limiting Packets

This is a particular sub-case where the SAVI device itself "drops" ND packets 🙃 To protect itself against DoS attacks and flash-crowds, the SAVI device has to rate limit how it processes packets that trigger the state-creation process (which requires processing from the SAVI device). So the SAVI device may not process all the ND packets when it's under heavy load 🔥 The result is that it fails to create a binding for a given DAD_NS packet, which means the data packets from the host that sent the DAD_NS will get filtered if this approach is adopted. The problem is that the host assumes DAD succeeded and won't run DAD again, so it stays disconnected from the network 😭 It's true that the SAVI device also has to rate limit data packet processing, but the host keeps sending data packets, so it's possible to recover with the alternative approach where data packets trigger the binding-creation procedure ✨

A.1.2. Lack of Binding State due to a Change in the Topology

If SAVI is deployed in a switched Ethernet network, topology changes can make a SAVI device receive packets from a legit user that it has no binding for 🦋 Let's look at this example:

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

                        Figure 3: Topology Example

Say that after bootstrapping, everything is working properly. The spanning tree is rooted in the router and includes one branch that follows the path SWITCH I - SAVI I - SWITCH II, and another branch that follows SWITCH I-SAVI II 🌿

Now the host boots at this moment and sends the DAD_NS. The message is propagated through the spanning tree and is received by SAVI I but not by SAVI II. SAVI I creates the binding 🎀

Then SAVI I fails and the spanning tree reconverges to SWITCH I - SAVI II - SWITCH II. Now the host's data packets get routed through SAVI II, which doesn't have binding state, so it drops the packets 💀

A.1.3. Lack of Binding State due to State Loss

The other reason a SAVI device might not have state for a legit address is that it simply lost it 😵 State can get lost because the SAVI device rebooted or for other reasons like memory corruption. Here's how it goes: the host performs DAD, and the SAVI device creates a binding for the host's address. The host communicates successfully for a while. Then the SAVI device reboots and loses the binding state. Now the packets from the host get discarded because there's no binding state for that address. Worth noting: in this case, the host was able to use the address successfully for a certain period of time 🕰️

Architecturally, the drop in network robustness here is easy to explain: this approach to SAVI implementation breaks the fate-sharing principle. [RFC1958] says:

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 tying the host's connectivity to the state in the SAVI device, we break this principle, and the result is degraded network resilience 📉💖

Okay, moving on to more practical matters 🧚 We can dig deeper into the actual behavior by considering two scenarios: 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.1.3.1. The Case of a Host Directly Connected to the SAVI Device

The considered scenario is depicted in the following diagram:

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

           Figure 4: Host Attached Directly to SAVI Device

Okay bestie, this is the scenario where the host is plugged directly into the SAVI device 🎀 Picture it like a little cute pair, host and SAVI device, holding hands ✨ The key thing here is that if the SAVI device reboots, the host sees its carrier disappear and then come back 🦋

[RFC4862] requires that the DAD procedure is performed when the IP address is assigned to the interface (see [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:
   ...

Lowkey, some of the popular OSs actually run DAD every time the link comes up 👑 but we'd need more data before we can totally take that for granted 💀 Assuming they do, then if the SAVI device's state loss also takes the link to the host down, the host redoes DAD, the binding state gets recreated in the SAVI device, and the host stays connected 🫶 That's what happens when the SAVI device reboots. BUT, it's also possible the binding state disappears because of an error in the SAVI process and the SAVI link never goes down. In that case the host won't redo DAD 😭 Someone pointed out that the SAVI process could flap the links of the device it's running on, so the link goes down every time the SAVI process restarts. That way the host is more likely to redo DAD when the SAVI process reboots 🌸

A.1.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 diagram:

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

             Figure 5: Host Attached to a Legacy Device

Now this one is giving plot twist 🧚 The host is not directly connected to the SAVI device. So if the SAVI device reboots, the host won't notice any changes at all 🙈

The host gets cut off from the rest of the network, since the SAVI device filters all its packets once the state is gone. And because the node won't perform DAD again, it stays disconnected until it reboots 💔

Also, it might not be obvious to the network admin which scenario their network is running 👀 Imagine a campus network where every switch is SAVI capable. A small hub in an office turns this into the scenario where the host isn't directly connected to the SAVI device. And a host running multiple virtual machines through a virtual hub? Depending on how that virtual hub is implemented, a directly connected host can turn into the case where the multiple (virtual) hosts are connected through a legacy (virtual) hub 🍓

A.1.3.2.1. Enforcing Direct Connectivity between the SAVI Device and the Host

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

  • First, it may well be the case in some scenarios that 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 behavior 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 does not reboot. So, the argument being made is that this approach is not good enough to provide a robust network service, but it is not bad enough to enforce the direct connectivity of the host to the SAVI switch. 🤷‍♀️
  • Third, it should be noted that topology enforcement is not part of the SAVI problem space, and the SAVI problem by itself is complex enough without adding additional requirements. 🧠

A.2. Implications of Not Discarding Non-Compliant Data Packets

The FCFS SAVI mechanism is composed of two main functions, namely, the mechanisms for tracking compliant and non-compliant data packets and the actions to be performed upon the detection of a non-compliant packet. Throughout this specification, we recommend discarding non- compliant data packets. This is because forwarding non-compliant data packets is essentially allowing packets with spoofed source addresses to flow throughout the network. However, there are alternative actions that can be taken with respect to these packets.

For instance, it would be possible to forward the packets and trigger an alarm to network administrators to make them aware of the situation. Similarly, it would be possible to log these events and allow the tracking down of cases where packets with spoofed addresses were used for malicious purposes. A site deploying SAVI may not want to take milder actions like the ones mentioned above instead of discarding packets, because there may be cases where the non-compliant packets are legitimate packets (for example, in the case that the SAVI device is malfunctioning and has failed to create the appropriate bindings upon the reception of a DAD packet). 🔥

Authors' Addresses

Erik Nordmark Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 United States

EMail: nordmark@acm.org

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

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

EMail: elevyabe@cisco.com

📦 where this page comes from