<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-tong-idr-bgp-ls-sav-rule-04" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title abbrev="BGP-LS for advertising SAV Rules">Advertising SAV Rule-related Information using BGP Link-State</title>
    <seriesInfo name="Internet-Draft" value="draft-tong-idr-bgp-ls-sav-rule-04"/>
    <author initials="T." surname="Tong" fullname="Tian Tong">
      <organization>China Unicom</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>tongt5@chinaunicom.cn</email>
      </address>
    </author>
    <author initials="D." surname="Li" fullname="Dan Li">
      <organization>Tsinghua University</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>tolidan@tsinghua.edu.cn</email>
      </address>
    </author>
    <author initials="N." surname="Geng" fullname="Nan Geng">
      <organization>Huawei</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>gengnan@huawei.com</email>
      </address>
    </author>
    <author initials="N." surname="Wang" fullname="Nan Wang">
      <organization>China Unicom</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>wangn161@chinaunicom.cn</email>
      </address>
    </author>
    <author initials="S." surname="Zhuang" fullname="Shunwan Zhuang">
      <organization>Huawei</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhuangshunwan@huawei.com</email>
      </address>
    </author>
    <author initials="J." surname="Zhao" fullname="Jing Zhao">
      <organization>China Unicom</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhaoj501@chinaunicom.cn</email>
      </address>
    </author>
    <date year="2026" month="March" day="02"/>
    <area>rtg</area>
    <workgroup>idr</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 72?>
<t>This document proposes extensions to the BGP Link-State protocol for advertising Source Address Validation (SAV) rule-related information.</t>
    </abstract>
  </front>
  <middle>
    <?line 75?>

<section anchor="sec-intro">
      <name>Introduction</name>
      <t>Source Address Validation (SAV) is an effective method to mitigate source address spoofing attacks. It is typically deployed at network edges, such as edge routers or Autonomous System Border Routers (ASBRs). Currently, various intra‑domain and inter‑domain SAV mechanisms ([RFC3704], [RFC8704], <xref target="I-D.ietf-sidrops-bar-sav"/>, <xref target="I-D.geng-idr-bgp-savnet"/>) exist, where SAV rules can be generated based on information advertised by routing protocols (such as OSPF, OSPFv3, IS-IS, BGP, etc.). The SAV rules on a router are dynamically constructed according to the topology (including source prefixes) of subnets or Autonomous Systems (AS) connected to it.</t>
      <t>To facilitate SAV rule monitoring, attack traceback, and service anomaly analysis, it is critical to dynamically and in real time obtain SAV rule‑related information for source prefixes associated with the subnets or AS connected to routers. The BGP Link‑State (BGP‑LS) protocol <xref target="RFC9552"/> can efficiently collect link‑state and trafiic engineering information from networks. This document proposes extensions to BGP‑LS to support the collection of SAV rule‑related information from routers. For the purpose of advertising SAV rules within BGP‑LS advertisements, two new NLRIs called SAV Rule NLRIs are proposed for IPv4 and IPv6, respectively.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="sec-nlri">
      <name>BGP-LS NLRI Advertisement for SAV Rule-related Information</name>
      <t>The "Link-State NLRI" defined in <xref target="RFC9552"/> is extended to carry the SAV rule-related information. The format of "Link-State NLRI" is defined in <xref target="RFC9552"/> as follows:</t>
      <figure anchor="fig-nlri">
        <name>Link-State NLRI</name>
        <artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            NLRI Type          |     Total NLRI Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                  Link-State NLRI (variable)                 //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>This document defines two new NLRI Types known as IPv4 SAV Rule NLRI and IPv6 SAV Rule NLRI (values are TBD) for the advertisement of SAV rule-related information.</t>
      <section anchor="sav-rule-nlris">
        <name>SAV Rule NLRIs</name>
        <t>This document defines SAV Rule NLRI Types with their common format as shown in the following figure:</t>
        <figure anchor="fig-rule-nlri">
          <name>BGP-LS SAV Rule NLRI</name>
          <artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+
    |  Protocol-ID  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Identifier                          |
    +                           (8 octets)                          +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //            Local Node Descriptors TLVs (variable)            //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //            SAV Rule Descriptors TLVs (variable)             //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>The fields are defined as follows:</t>
        <ul spacing="normal">
          <li>
            <t>Protocol-ID: Specifies the source of SAV rules in this NLRI. Protocol-ID values defined in [RFC9552][RFC9086] can be reused.</t>
          </li>
          <li>
            <t>Identifier: An 8 octet value as defined in <xref target="RFC9552"/>.</t>
          </li>
          <li>
            <t>Local Node Descriptors TLV: Contains Node Descriptors for the nodes storing SAV rules. This is a mandatory TLV in SAV Rule NLRIs. The Type is 256. The length of this TLV is variable. The value contains one or more Node Descriptor sub-TLVs defined in <xref target="RFC9552"/>.</t>
          </li>
          <li>
            <t>SAV Rule Descriptors TLVs: There can be one or more SAV Rule Descriptors TLVs for carrying SAV rules.</t>
          </li>
        </ul>
      </section>
      <section anchor="sav-rule-descriptors-tlvs">
        <name>SAV Rule Descriptors TLVs</name>
        <t>The SAV Rule Descriptor field is a set of TLV triplets. SAV Rule Descriptors TLVs identify a set of SAV rules having the same set of valid interfaces as defined in <xref target="I-D.ietf-savnet-general-sav-capabilities"/>. The following TLVs are valid as SAV Rule Descriptors in the SAV Rule NLRI:</t>
        <figure anchor="fig-rule-descriptor">
          <name>SAV Rule Descriptor TLVs</name>
          <artwork><![CDATA[
    +-------------+---------------------+----------+
    |   TLV Code  | Description         |  Length  |
    |    Point    |                     |          |
    +-------------+---------------------+----------+
    |     TBD     | Interface Name      | variable |
    |     TBD     | Interface Group     |    4     |
    |     TBD     | SAV Prefix          | variable |
    +-------------+---------------------+----------+
]]></artwork>
        </figure>
        <section anchor="sec-intf-name-tlv">
          <name>Interface Name TLV</name>
          <t>An Interface Name TLV is used to identify one valid interface of the source prefixes carried in SAV Prefix TLVs. The format of Interface Name TLV is as follows:</t>
          <figure anchor="fig-intf-name-tlv">
            <name>Interface Name TLV</name>
            <artwork><![CDATA[
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Type             |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                     Interface Name    (variable)            //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>There can be zero, one or more Interface Name TLVs in the SAV Rule Descriptor field.</t>
        </section>
        <section anchor="sec-intf-group-tlv">
          <name>Interface Group TLV</name>
          <t>An Interface Group TLV is to identify a group of valid interfaces of the source prefixes carried in SAV Prefix TLVs. The format of Interface Group TLV is as follows:</t>
          <figure anchor="fig-intf-group-tlv">
            <name>Interface Group TLV</name>
            <artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type             |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //                       Interface Group (4 octets)            //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>The Interface Group value can have either a local meaning or a global meaning. On the one hand, it can be a local interface property on the target routers, and the meaning of it depends on the configurations of network administrator <xref target="I-D.ietf-idr-flowspec-interfaceset"/>. On the other hand, a global meaning Group Identifier field carries an AS number, which represents all the interfaces connected to the neighboring AS with the AS number. <xref target="I-D.geng-idr-flowspec-sav"/></t>
          <t>Interface Group value can also be an Interface ID for identifying a specific interface.</t>
          <t>There can be zero, one or more Interface Group TLVs in the SAV Rule Descriptor field. Interface Group TLVs can be used together with Interface Name TLVs.</t>
          <t>When there is neither an Interface Name TLV nor an Interface Group TLV, the source prefixes carried in SAV Prefix TLVs are considered valid for all the interfaces on the router.</t>
        </section>
        <section anchor="sec-prefix-tlv">
          <name>SAV Prefix TLV</name>
          <t>A SAV Prefix TLV carries one IP address prefix (IPv4 or IPv6). The format of SAV Prefix TLV is as follows:</t>
          <figure anchor="fig-sav-prefix-tlv">
            <name>SAV Prefix TLV</name>
            <artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type             |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Prefix Length | IP Prefix (variable)                         //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>There can be one or more SAV Prefix TLVs in the SAV Rule Descriptor field. The IPv4 SAV Prefix TLVs will only appear in the IPv4 SAV Rule NLRI, and The IPv6 SAV Prefix TLVs are only for the IPv6 SAV Rule NLRI</t>
          <t>There can be more than one SAV mechanisms based on the same source (identified by Protocol-ID). In order to distinguish the different sources of rules in a more fine-grained manner, the Type field needs to be allocated for multiple values, and each value identifies a specific SAV mechanism based on the same source identified by Protocol-ID.</t>
        </section>
      </section>
    </section>
    <section anchor="sec-attr">
      <name>BGP-LS Attribute for SAV Mode</name>
      <t>The BGP-LS Attribute, an optional and non-transitive BGP Attribute, is used to carry the validation mode information of SAV rules {I-D.ietf-savnet-general-sav-capabilities}. The following SAV Mode Attribute TLV is defined for the BGP-LS Attribute associated with a SAV Rule NLRI:</t>
      <figure anchor="fig-sav-mode-tlv">
        <name>SAV Mode TLV</name>
        <artwork><![CDATA[
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Type             |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |M  |  Reserved |
  +-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>The SAV Mode TLV carries a Mode field (The "M" field is shown in the figure and occupies two bits) describing the validation mode of SAV.</t>
      <ul spacing="normal">
        <li>
          <t>When M field is set to 00, the mode is IBA-SAV: interface-based prefix allowlist. The NLRI carries the source prefixes and interfaces. Only the carried prefixes are valid on the carried interfaces, and any other prefixes are invalid on these interfaces.</t>
        </li>
        <li>
          <t>When M field is set to 01, the mode is IBB-SAV: interface-based prefix blocklist. The NLRI carries the source prefixes and interfaces. Only the carried prefixes are invalid on the carried interfaces, and any other prefixes are valid on these interfaces.</t>
        </li>
        <li>
          <t>When M field is set to 10, the mode is PBA-SAV: prefix-based interface allowlist. The NLRI carries the source prefixes and interfaces. Only the carried interfaces are valid for the carried prefixes, and any other interfaces are invalid for those prefixes. Any other prefixes will not be validated.</t>
        </li>
        <li>
          <t>When M field is set to 11, the mode is PBB-SAV: prefix-based interface blocklist. The NLRI carries the source prefixes and interfaces. Only the carried interfaces are invalid for the carried prefixes, and any other interfaces are valid for those prefixes. Any other prefixes will not be validated.</t>
        </li>
      </ul>
    </section>
    <section anchor="bgp-ls-attribute-for-sav-actions">
      <name>BGP-LS Attribute for SAV Actions</name>
      <t>SAV actions in this document adopt the traffic filtering actions defined in [RFC8955] and [RFC8956].</t>
      <t>Traffic filtering actions defined in [RFC8955] include traffic-rate-bytes, traffic-rate-packets, traffic-action, rt-redirect, and traffic-marking, which are applicable to IPv4 and IPv6. Rt-redirect-ipv6 is a new traffic filtering action defined in [RFC8956], which is applicable to IPv6. The encapsulation formats of SAV actions are consistent with the encapsulation formats defined in [RFC8955] and [RFC8956].</t>
      <t>A SAV rule may match multiple SAV actions, and there may be conflicts among these SAV actions. Section 7.7 of [RFC8955] describes the conflicts among Traffic filtering actions.</t>
    </section>
    <section anchor="procedures">
      <name>Procedures</name>
      <t>SAV rules only exist on the routers running SAV mechanisms/protocols and the controller, these routers are usually access routers or boundary routers. This document describes extensions to the BGP-LS NLRI. The Routers running SAV mechanisms/protocols establish BGP-LS sessions with the controller respectively to report multi-sourced SAV rules.</t>
      <figure anchor="fig-advertisement-of-sav-rules">
        <name>Advertisement of SAV Rules using BGP-LS</name>
        <artwork><![CDATA[
                     +--------------------------+
                     |        Controller        |
                     +--------------------------+
                        /                    \       
                       /                      \  BGP-LS advertisements for SAV Rule NLRIs
+---------------------/------------------------\--------------+    +---------------+
|   AS100            /                          \             |    |   AS200       |
|                +---------+                +---------+       |    |  +---------+  |
|  access router | Router1 |                | Router2 |-------|----|--| Router3 |  |
|                +---------+                +---------+       |    |  |+--------+  |
|                 /      \                  boundary router   |    |               |
|                /        \                                   |    +---------------+
|               /          \                                  |
|              /            \                                 |
|      +---------+         +---------+                        |
|      | Subnet1 |         | Subnet2 |                        |
|      +---------+         +---------+                        |
|                                                             |  
+-------------------------------------------------------------+
]]></artwork>
      </figure>
      <t>Based on Figure 8, the process of reporting SAV rules via BGP-LS is described as follows:
Step 1: R1 and R2 run SAV mechanism/protocol, and generate multi-sourced SAV rules. R1 serves as an access router connecting local subnets, while R2 functions as a border router peering with external AS. These routers running SAV mechanisms can exchange SAV specific information between them.
Step 2: R1 and R2 respectively establish BGP-LS sessions with the controller.
Step 3: R1 and R2 generate BGP-LS advertisements for the SAV Rule NLRIs.
Step 4: R1 and R2 report multi-sourced SAV rules to the controller through the sav rule NLRIs (as defined in Section 2). This enables the controller to monitor and manage multi-sourced SAV rules.</t>
    </section>
    <section anchor="manageability-considerations">
      <name>Manageability Considerations</name>
      <t>The Existing BGP operational and management procedures apply to this document. No new procedures are defined in this document. The considerations as specified in <xref target="RFC9552"/> apply to this document.</t>
    </section>
    <section anchor="sec-iana">
      <name>IANA Considerations</name>
      <t>This section describes the code point allocation by IANA for this document.</t>
      <section anchor="bgp-ls-nlri-types-registry">
        <name>"BGP-LS NLRI-Types" registry</name>
        <t>This document requests assigning code-points from the registry for SAV Rule NLRIs:</t>
        <artwork><![CDATA[
+------+---------------------------+
| Type | NLRI Type                 |
+------+---------------------------+
| TBD  | IPv4 SAV Rule NLRI        |
| TBD  | IPv6 SAV Rule NLRI        |
+------+---------------------------+
]]></artwork>
      </section>
      <section anchor="bgp-ls-sav-rule-descriptors-tlvs-registry">
        <name>"BGP-LS SAV Rule Descriptors TLVs" registry</name>
        <t>This document requests assigning code-points from the registry for BGP-LS SAV Rule Descriptors TLVs based on <xref target="fig-rule-descriptor"/>.</t>
      </section>
      <section anchor="bgp-ls-sav-mode-attribute-tlv-registry">
        <name>"BGP-LS SAV Mode Attribute TLV" registry</name>
        <t>This document requests assigning a code-point from the registry for the BGP-LS SAV Mode attribute TLV.</t>
      </section>
    </section>
    <section anchor="sec-security">
      <name>Security Considerations</name>
      <t>Procedures and protocol extensions defined in this document do not affect the base BGP security model. See [RFC6952] for details. The security considerations of the base BGP-LS specification as described in <xref target="RFC9552"/> also apply.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC9552" target="https://www.rfc-editor.org/info/rfc9552" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml">
          <front>
            <title>Distribution of Link-State and Traffic Engineering Information Using BGP</title>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <date month="December" year="2023"/>
            <abstract>
              <t>In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.</t>
              <t>This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control.</t>
              <t>Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).</t>
              <t>This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9552"/>
          <seriesInfo name="DOI" value="10.17487/RFC9552"/>
        </reference>
        <reference anchor="I-D.ietf-savnet-general-sav-capabilities" target="https://datatracker.ietf.org/doc/html/draft-ietf-savnet-general-sav-capabilities-02" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-savnet-general-sav-capabilities.xml">
          <front>
            <title>General Source Address Validation Capabilities</title>
            <author fullname="Mingqing(Michael) Huang" initials="M." surname="Huang">
              <organization>Zhongguancun Laboratory</organization>
            </author>
            <author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Dan Li" initials="D." surname="Li">
              <organization>Tsinghua University</organization>
            </author>
            <author fullname="Nan Geng" initials="N." surname="Geng">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Li Chen" initials="L." surname="Chen">
              <organization>Zhongguancun Laboratory</organization>
            </author>
            <date day="10" month="October" year="2025"/>
            <abstract>
              <t>The SAV rules of existing source address validation (SAV) mechanisms, are derived from other core data structures, e.g., FIB-based uRPF, which are not dedicatedly designed for source filtering. Therefore there are some limitations related to deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces the general SAV capabilities from data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-savnet-general-sav-capabilities-02"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.geng-idr-bgp-savnet" target="https://datatracker.ietf.org/doc/html/draft-geng-idr-bgp-savnet-05" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.geng-idr-bgp-savnet.xml">
          <front>
            <title>BGP Extensions for Source Address Validation Networks (BGP SAVNET)</title>
            <author fullname="Nan Geng" initials="N." surname="Geng">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Zhenbin Li" initials="Z." surname="Li">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Zhen Tan" initials="Z." surname="Tan">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Mingxing Liu" initials="" surname="Liu">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Dan Li" initials="D." surname="Li">
              <organization>Tsinghua University</organization>
            </author>
            <date day="18" month="September" year="2025"/>
            <abstract>
              <t>Many source address validation (SAV) mechanisms have been proposed for preventing source address spoofing. However, existing SAV mechanisms are faced with the problems of inaccurate validation or high operational overhead in some scenarios. This document proposes BGP SAVNET by extending BGP protocol for SAV. This protocol can propagate SAV-related information through BGP messages. The propagated information will help edge/border routers automatically generate accurate SAV rules. These rules construct a validation boundary for the network and help check the validity of source addresses of arrival data packets.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-geng-idr-bgp-savnet-05"/>
        </reference>
        <reference anchor="I-D.ietf-sidrops-bar-sav" target="https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-bar-sav-08" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-sidrops-bar-sav.xml">
          <front>
            <title>Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-SAV)</title>
            <author fullname="Kotikalapudi Sriram" initials="K." surname="Sriram">
              <organization>USA National Institute of Standards and Technology</organization>
            </author>
            <author fullname="Igor Lubashev" initials="I." surname="Lubashev">
              <organization>Akamai Technologies</organization>
            </author>
            <author fullname="Doug Montgomery" initials="D." surname="Montgomery">
              <organization>USA National Institute of Standards and Technology</organization>
            </author>
            <date day="20" month="October" year="2025"/>
            <abstract>
              <t>Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-bar-sav-08"/>
        </reference>
        <reference anchor="I-D.ietf-idr-flowspec-interfaceset" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-interfaceset-06" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-interfaceset.xml">
          <front>
            <title>Applying BGP flowspec rules on a specific interface-set</title>
            <author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
              <organization>Cisco</organization>
            </author>
            <author fullname="Adam Simpson" initials="A." surname="Simpson">
              <organization>Nokia</organization>
            </author>
            <author fullname="Keyur Patel" initials="K." surname="Patel">
              <organization>Arrcus, Inc</organization>
            </author>
            <author fullname="Jeffrey Haas" initials="J." surname="Haas">
              <organization>HPE</organization>
            </author>
            <date day="2" month="September" year="2025"/>
            <abstract>
              <t>The BGP Flow Specification (flowspec) Network Layer Reachability Information (BGP NLRI) extension ([RFC8955]) is used to distribute traffic flow specifications into BGP. The primary application of this extension is the distribution of traffic filtering policies for the mitigation of distributed denial of service (DDoS) attacks. By default, flow specification filters are applied on all forwarding interfaces that are enabled for use by the BGP flowspec extension. A network operator may wish to apply a given filter selectively to a subset of interfaces based on an internal classification scheme. Examples of this include "all customer interfaces", "all peer interfaces", "all transit interfaces", etc. This document defines BGP Extended Communities ([RFC4360]) that permit such filters to be selectively applied to sets of forwarding interfaces sharing a common group identifier. The BGP Extended Communities carrying this group identifier are referred to as the BGP Flowspec "interface-set" Extended Communities.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-flowspec-interfaceset-06"/>
        </reference>
        <reference anchor="I-D.geng-idr-flowspec-sav" target="https://datatracker.ietf.org/doc/html/draft-geng-idr-flowspec-sav-06" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.geng-idr-flowspec-sav.xml">
          <front>
            <title>BGP Flow Specification for Source Address Validation</title>
            <author fullname="Nan Geng" initials="N." surname="Geng">
              <organization>Huawei</organization>
            </author>
            <author fullname="Dan Li" initials="D." surname="Li">
              <organization>Tsinghua University</organization>
            </author>
            <author fullname="tongtian124" initials="" surname="tongtian124">
              <organization>China Unicom</organization>
            </author>
            <author fullname="Mingqing(Michael) Huang" initials="M." surname="Huang">
              <organization>Zhongguancun Laboratory</organization>
            </author>
            <date day="17" month="October" year="2025"/>
            <abstract>
              <t>BGP FlowSpec reuses BGP route to distribute infrastructure and propagates traffic flow information with filtering actions. This document proposes some extensions to BGP FlowSpec for disseminating SAV rules.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-geng-idr-flowspec-sav-06"/>
        </reference>
      </references>
    </references>
    <?line 323?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+07W3LbSJL/jNAdauUfaVqgJVmWbcW8KMvu1oQka0V1T8z0
+KMIFMkagwAHBUjNttSxV9gb7FnmKHOSzUcVgAJASnLTG7Gxi46WiXpkZWbl
q7ISQRBs9HKdx+pIDKIbleXa6GQihoMfxFURqyBTscxVJE6TcZrNZK7TRBQ0
5PjbS3Gmk0/BMIcRGz05GmXq5gjbg7OhgOFCdkA0G70oDRM5gxWjTI7zIE+T
SaCjLBhN5kFsAiNvggzX3j3Y6KUjk8YqV+Zoo1fMI8m/8F/4J4R/Jmm2OBIm
jzZ6phjNtDGA4vViDuBP312/3+ht9PQ8OxJ5Vph8f3f3ze4+4JopeSSyfLLR
u02zT5MsLeZHAnDY6H1SC2iKYHaSqyxReXCCWCIcWeTTNIN1BTBNCJ2YI3Hd
F9eAP74zTddaJmVTmk1kon8mth2Jt1OdSPF9osN0hr1qJnUMmMHg/OUfQ+wt
qLMfJtgf6hxIO1b675rBhWmR5EguQfLwOOnDZlRYnAAS/O6jcI17MS0IC9gb
Ayt4mMQ6kskfczuqr6LiC3C56ItvVZ0nF4CNa/Hx+a6Qt0rXUJjAsARQmFJH
33Lqiav/WTZXdy2P2pBbGJzsHe79yi0Z9sVfgYw6KsNpkQD0WvsD7PiZBhqe
9iuY8ifERaYVJn9CnXRNj+LKzzD47y93v4grG72ErccNqq0QV+/fvnn5cp9+
nwYnfa3yMeo9qhtIgMpkTGYglHM50rHONak9qLIzQxYQTkaRKe0HA2kAhs50
boKRzLDf78SJ4zi9NXMVBhp1fixDZWowSvjlMAdko9fv9xGtIAiEHJk8kyFY
iuupNgKMXDFTSS7msHZqlBHqp1wlaJ0MKJrIp6phQnFknoZp3LadaZGFCgx0
lCljxA8S1ZRM8RaY1W2R1S21rix1XzjkZjqKYoVvz9CwZWlUhATg8zPDdGfp
/UbvoYWALpBeNR6rELdAzBRYxAjJmcEeTZAIwyCkBWHmaTpGGmSey/CT6YvT
HMHki7kOZRwvRKTmcboAxGUuYOvQHgsVTZTZEaYIp0IaehVgo2FzDAirGBRg
M9NZWhgxXJhczcQxmGyViSs7ZmswPL4y233xtsgy2IR4sSNuZKZxBtIq//Uf
/xmlINcJ0IMsg1lVE7qqmQqnoBNmBsB+BHF98Wr34OOOwJ+v+efnz8sE7P7e
9XaI5v39NkiCNvmOuJ2qTNFquIFGhMDbkRKsALiVI2ngL3C/tqelYGD/griC
7HWyA+g6rn0YXr7fob83L3bE6TA4He6gyO0IlYd9YM71tL46grZMFuAfRbQA
S2H3KAShBQcaIlIyDIHZuKaV4hzkO04nC7GlkzAuqMtKwTxTY/2TMtsiHcNu
joD+7g2kLdvGdRJFqwBsnZNuXacCNBKNAIqXw1fM0kTnaQaL7VjZEqh+agS/
dmhXjcpuNIoirCSBCJnAX6NBrjSJYJiBzAJ9uFadWJYIASECdOmZEukod2KB
S4OgdOgaKW2DbNgFk4aaht7qfErsqrNh6FNsRZx3xhkHWI7Nwxa0wMsZ8Km0
FD9aS/qRhAcUU4ea5B0AxzEAFjGDMAQCSQMujbUOBYimTpRCDvp0ZOnMKSKh
8ghj5jDD36aYz9MsJ1otEggWBOAhBuLCJQveA38QxLzIcEWc3wwnWW6RsbA7
JQqlfiDCsNlACJBzKy7Ork5RxwCjqIxGbSvKuyUtoo08vbw5IG7Bj8MdkAW0
+2jy4gUJJdjRZ+JK/aPQGa8jzsBPF3JCNha3D+JIgYGkEZvn3w+vN3f4X3Hx
gX5fvfv370+v3p3g7+F3g7Oz8kfPjhh+9+H7s5PqVzXz7Yfz83cXJzwZWoXX
1Ns8H/xlk1Vg88Pl9emHi8HZJkp07m0l0gzbBQaHzB/ILGm36UXKgGqMaHfE
8dvLf/7X3gHYs38DUdvf23tzf29fXu+9OoAXsGIJr5YmIHf8Cju36Mn5XMkM
oQDTgfNzUOEYdgRsk5mmt4lA+9fv9X7zI3Lm45H47Sic7x383jYgwV6j45nX
SDxrt7QmMxM7mjqWKbnptTc47eM7+Iv37vhea/ztH0AVlQj2Xv/h9yxB7qiE
MlievkicSAZXnsHYbydxpu9Z3jZrgQQC3ATHCo6Xd7EyE9qqbsQWJ5RZtiA9
cwrVHUfgCvyKitheCwWraznY6jHYAIibKHz75ZdfMG4SYle0n72Otv2OthcO
xB50vxAH4qU4FK/Ea/HmKW0M5JvgV/7HYO7q+NF24gm0auL+6xTkn7vPwPqC
Pyj7vx42X/BYbJ4/b3c1Nl5sYVQlR7Habg19/nyt2KyBNyR9n4/Es7GekOoI
QamP37Xk+Z6teN1csngbz53QLhvxKUFjBqJOXsNzLaUPaTQD3+JCseO5Pj7Z
JoVHNfS8V91pduqldUS+N1uGuY8Bo+6iEp2Br57NOIxBLS9tNPkNZbUYPS8w
r8jU/xJ1LkXw0kZMwenJ/6S6nUawA3qsIaZ+UMBXgNl6LVIIEnPTVrPyWa/y
r4k3vg05SzHcvkgjJU4oyJhDBG/E9dkPZoklcUbkq6BTKsQjkVknNp4tIv32
DJKNDDyVdVYJlFGrOGLj4bxuw9EGdYE/EkOIXlEKDZ9A+JRSMy6mDA9xob6n
LdZSdbl3+rH7+vCjO7pmqoAImlMiNdk/EoNEWBFmeIhvF0Q7dbmgHIm3aYLH
MdPudjY0gQ4wX3w6rGi0ZxnMYYgZ2GUJAxYIU9jDXWVCOeAhHw7D918eckPM
XhsYR7yiqUY4WeExTF7okEwh5AO0ZinsVQNhPAkGJG4rOLFURo9wNQBqOV9f
Z7lcI4co5GswpjzSLJ3KgtfRzcLIXDWKXBbyJYfeGAxWfwU2mgVkUc2s5HEq
byjFgOIq4QxuB9xgRkpUabqGHNVzMquziff3Lqh1fo1QQpXiNaTpxtz6Q09e
fGf4TVB//LeO1prdRsa9RSGBN7cmBvulbRZl4HhXs/aXKTCkfGtb9A7j/qUY
CoxWLNRTtwviAnfItjpt8DDsnPUt3rpUGB7UMWzOQnZfUlalTldzrafT1TbD
USXZzhh3ST1KCxtk1JtnTWbgTpap1XGAOfcgj29gAljCjrGgPmg5Ke3ltAJV
uiHvbHpUK8+EOq1ZBWqcQhybR7futZcd09YS2a0ptltXDNDUEv+k1upvnNQq
EV0bPl3nLHja6rU6RFp7VOJJbqkMbQEq45LKG/2ssnTH80ntaW1T2nQq7Jd8
7WKj0VAvur/t0q9qtDaebklBczpdyhp1zFv//2Iu5MvVa03YLFEu0dqkrYOu
I9bXivh9se1QrlJyqqi/2WkjTdA4CJaUUHCUx6sbEVPwPFMywbAGrxLFJE5H
VVtffGDNQwWdQiRMNyJWdd38yudgYlxlOTokvu+R2QSiMZup59QvtpcrjhFc
pOYqiYybBAExJQ4ob0E65u76ZDTTica7U1T8WgS39GYWYzdHAdHMNDTJtGyq
HcE5VGVFppvMwVAkxWykMryM0+EUDjCg74YS+pizxiVqlsG7rKGThtKT6YjP
GQCrvOMp4fabF4H1O+R72trl2ypjQ/l5WTdpcCLDKN5ZMrpaFYbPd2GFLNvO
RxvlUtweY5U7p9lFbBQDAoIbQwzpMP2M3Z+nitbK6JSVOAHuDJCStNFTLr3z
RGtNMT5eaAILMxjB9p+u3Ns7bqWXZb3v3JEP0XoiXtp5oeYYJ3TI/tPL8nqc
J4ktyhzyvdPhdtOfNED9vyspXYX39rVdyZ3bBLvQHW6kbVqRB3fP13IleLKt
ZM87tFRC0xGjNTMGdRV52AaQQ3Lp7vrUWw1aRDeB1fVfXh9cnprZc1hAh51q
SnBcWqcjjd4iiqjJwR8QeY1CjrKcosoqsNXY0s5HUE1FLfu1jdZOcHEJlgmA
nwKLW2jDdj7S47HCAhMLiRxbmVCTjA5mJ8DXS0pSzCS4kIxtFskz+6REqcjY
61gwQ2lIqX6kfFbEOaZSbB6OmaYk+Cp2FCXqpu4HPMqXE76Ubht6uxvKQZ5n
egQ2sLyYPMc0BRs+CZ1lkNKcgPiKlNIY4JkR9yRNAnD2YH+phAjLHGqjawfh
6m7ypqpDmuG69aoBL2v0+PRPM/tT0lSRam2tSy85MWyxpFnkIVckh369gV6D
fV6LPVyLbV4PJue02pXCgh/YhG7IHVYTZallM0kIvLi73loFj9zE2rtFF/Dn
m1Uu1L87oxszLpEIw2Ku7TXiSONpw5ZbuGxnU9ZZvm0ln6CQ6by2DgTioCq7
u2xRWDuMOD0eBDDrqAplArYBNt5AE3MbgzFjNSBb6ijriqbKIjmKijD6jlkz
XZhVjSwTqC7wLwMxN51NmEwWNnr35uqkPtsob9nVPNhr8uB4JQ9GYGU/fTUe
+HQ8lQsreLCaCXsNQbh0gmAjBOZAdbZbuyDUU/MlIc50NjnV5EFjsuMhT8ci
MDexLwZtxlHkkaQ5+lCrRSp6kGF7TYYdr2TY2qVmJc1PZtnaGLbC9Q9CPsM/
w3HYIG1Du8QsAs/POYNMYm0isD/OueTQTWrcfb1+8/LlR6LRvh3yTdj10wBw
JWq5boD1tMFokSMDvba5DD+pvNbKYHdElgdwOtQZnPd3yrpJHDCT2SeqOuWM
AXIdIt1Yh3QTASLl1Q72xVUFKNBzCGHpqgxLSJYxpYOkw49uPZzdXM5eT6oE
QhxTxGU9KoRIxgVIjl3l6dfkuEVlyqJ78iN2h8RlUCvMlQv4PwdUy9C1tn6Z
Lsp45IhTQ0APplxmKXtB483pi6EtIn3Vf4X0VKi4WkVTJpnqkJYKjQtvIeIN
VQTO2bAku0po0FGq0fbP/wb6k8RFi9XB4nlVfO1yYXj/m2HxK4f6pgKB/C9M
wZXGYYhJgFpl+ygtkkhmi3opsF/L4+jt/JrAVROyPFw9FmtlcpAmPNRYGEYZ
Bl2KR0WQVwxLVcuK6n1ptwO2f1Hzcrl2o9R4um/p6veOracMLd9WSNWjyvWs
Ak9n7vhv9t+l05ZknGGe5a5foezVeroKrm58ny+j4W8NkrpIBjqRcYPh3q53
ClmWIK+Rys+d+zMY7pcg7hiq93zjI7K6y0H1ehiqpx4whuV5r33N7br2xZ2F
cWf/uJ4XOGltuN5908K18TzvYiA9DQ2v89UjqQNquVMdYFvPnU+CJwOdQB8F
to2WJz4PQ6gAdHF+xW60AdyJIX1KURcI17a/vA5ujRh84XOHxmOFRXrE0zzO
eiYlSMflR7SmPNwOuipL6Yvc6oNesE587j12GaP3fHZ9zVHyHP2l4SwXWX3/
U4wbLZ2No8SJ+47AS1cPczUXe0fiao+85dU++iffN5WuiaMF90HUchcDsOjw
T5lxvDnxLIe9tkFc+W7LfoJDIRXYXEBhXCQuPsLobMQZPzt/br+SIWeIfjfD
XNZgSF7WPBQd8Jc5P+HrhMOa2m1NlccaqfxW8X3IrG+5tO9xqe52n+SxHbgX
dXAlU5c7pVadk3GQDnzEVvl/F53UAoh8Chyb2K+h5A2HjfwhzpZfz+Xivv1t
GwipBMNe04KYuu/BCKmZTORkubhw7HdOgzgjuMBQgi6E+H7SpX7e/cQJX8pS
4i2orCUyeRX3WZSNIyk4XzDRtcCtLy64bLw+sla+2Tw6cQAXekhRTbYt5Gx+
ZtG9qP3ec3AxaNDniieAgntbLm6UO3v4ETUcouZUX2bT0iSrCwbKQtJa8ZnY
rMWiAVWab4KYTPCWd9Eurc/UPwoQaPpcTk9IhXDdgNY1/F0YReEWQkfEVCVZ
rV1dZV7JC1LC8q7rY43KzD8aFtap3XWV/9ddRjWqeY3x1BWJUI/RS4ss1873
hxasLhs+f+4oqru/b8pId+b9iXjLGuZLEK8dkcolZX1Jqy5gc4qsbRKsyhjb
S17ysqbMSVR9lVk7my1TcPhBqRdJ31ITcsg4MjRuDUpKxXj6VaTrh29Q15GW
SOVSx7bwqBzeMBe2jsmBJS9hPY/9krjuo317gpUHZFTKz9vxu1oud/xvYM4u
fjREAAA=

-->

</rfc>
