SAVNET N. Geng Internet-Draft Huawei Intended status: Informational L. Qin Expires: 8 March 2027 Zhongguancun Laboratory 4 September 2026 Currently Used Terminology Related to Source Address Validation draft-gq-savnet-sav-terms-02 Abstract This document provides an overview of terms and abbreviations related to Source Address Validation (SAV). Its purpose is to establish a common and consistent set of terminology for use across SAV-related discussions and documents. This document explicitly does not serve as an authoritative source of correct terminology. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 March 2027. Copyright Notice Copyright (c) 2026 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 (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Geng & Qin Expires 8 March 2027 [Page 1] Internet-Draft SAV Terminology September 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. General Terms . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Network and Topology Terms . . . . . . . . . . . . . . . 3 3.2. Router and Interface Terms . . . . . . . . . . . . . . . 4 3.3. Routing Terms . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Routing Security Terms . . . . . . . . . . . . . . . . . 5 3.5. Scenario Terms . . . . . . . . . . . . . . . . . . . . . 6 4. SAV Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. General SAV Terms . . . . . . . . . . . . . . . . . . . . 7 4.2. SAV Enforcement Terms . . . . . . . . . . . . . . . . . . 8 4.3. SAV Mechanism Terms . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Informative References . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction This document provides an overview of terms and abbreviations related to Source Address Validation (SAV). Its purpose is to establish a common and consistent set of terminology for use across SAV-related discussions and documents. This document explicitly does not serve as an authoritative source of correct terminology. 2. Acronyms The following acronyms are commonly used in the context of source address validation: * *ACL:* Access Control List * *AS:* Autonomous System * *ASBR:* AS Border Router * *ASN:* AS Number * *ASPA:* Autonomous System Provider Authorization * *BAR-SAV:* Source Address Validation Using BGP UPDATEs, ASPA, and ROA * *BGP:* Border Gateway Protocol * *CC:* Customer Cone Geng & Qin Expires 8 March 2027 [Page 2] Internet-Draft SAV Terminology September 2026 * *DSR:* Direct Server Return * *eBGP:* external Border Gateway Protocol * *EFP-uRPF:* Enhanced Feasible-Path unicast Reverse Path Forwarding * *FIB:* Forwarding Information Base * *FP-uRPF:* Feasible-Path unicast Reverse Path Forwarding * *HP:* Hidden Prefix * *IGP:* Interior Gateway Protocol * *IRR:* Internet Routing Registry * *IS-IS:* Intermediate System to Intermediate System * *LPP:* Limited Propagation of a Prefix * *OSPF:* Open Shortest Path First * *RIB:* Routing Information Base * *ROA:* Route Origin Authorization * *RPKI:* Resource Public Key Infrastructure * *SAV:* Source Address Validation * *SAVA:* Source Address Validation Architecture * *SAVI:* Source Address Validation Improvements * *SAVNET:* Source Address Validation in Intra-domain and Inter- domain Networks * *uRPF:* unicast Reverse Path Forwarding * *VRF:* Virtual Routing and Forwarding 3. General Terms 3.1. Network and Topology Terms * *Autonomous System (AS):* A set of routers under a single technical administration [RFC4271]. Geng & Qin Expires 8 March 2027 [Page 3] Internet-Draft SAV Terminology September 2026 * *AS Number (ASN):* A 16-bit [RFC4271] or 32-bit [RFC6793] number uniquely identifying an Autonomous System. * *Customer (aka Customer AS):* The customer in a customer-to- provider relationship. A Customer may propagate any route learned from a Customer, or that is locally originated, to a Provider. All other routes must not be propagated [RFC9234]. * *Customer Cone (CC):* The Customer Cone of a given AS, denoted as AS-A, includes: (1) AS-A itself, (2) AS-A's direct customers (ASes), (3) The customers of AS-A's direct customers (indirect customers), (4) And so on, recursively, following all chains of provider-to-customer links down the hierarchy [I-D.ietf-savnet-inter-domain-problem-statement][caida-asrank]. * *Peer (aka Peer AS or Lateral Peer or Lateral Peer AS):* The peers in a lateral peering relationship. A Peer may propagate any route learned from a Customer, or that is locally originated, to a Peer. All other routes must not be propagated [RFC9234]. * *Provider (aka Provider AS):* The provider in a customer-to- provider relationship (if looked at from the opposite direction, provider-to-customer [caida-asrank]). A Provider may propagate any available route to a Customer [RFC9234]. * *Provider Cone:* The set of ASes that an AS can reach by using only customer-to-provider links [I-D.li-sidrops-bicone-sav]. 3.2. Router and Interface Terms * *AS Border Router (ASBR):* The router that connects an AS to other ASes. * *Customer Interface (aka Customer-facing Interface):* The interface of an ASBR facing a Customer [RFC8704]. * *Edge Router:* The router that is directly connected to a Sub Network or a host [I-D.geng-idr-bgp-savnet]. * *Internal Router:* The router that is neither an edge router nor a border router in an AS. * *Lateral Peer Interface (aka Lateral Peer-facing Interface):* The interface of an ASBR facing a Lateral Peer [RFC8704]. * *Provider Interface (aka Provider-facing Interface):* The interface of an ASBR facing a Provider [RFC8704]. Geng & Qin Expires 8 March 2027 [Page 4] Internet-Draft SAV Terminology September 2026 3.3. Routing Terms * *Asymmetric Routing:* Asymmetric routing means a packet traverses from a source to a destination in one path and takes a different path when it returns to the source. Asymmetric routing can occur within an AS due to routing policy, traffic engineering, etc [I-D.ietf-savnet-intra-domain-problem-statement]. * *Border Gateway Protocol (BGP):* A path-vector routing protocol used in the global Internet to exchange routing information between different ASes [RFC4271]. * *Forwarding Information Base (FIB):* The table containing the information necessary to forward IP Datagrams [RFC3222]. FIB is also known as forwarding table. FIB stores the best active routes, which are a subset of those found in the RIB. * *Interior Gateway Protocol (IGP):* A type of routing protocol used within a single AS to exchange routing information between routers. * *Intermediate System to Intermediate System (IS-IS):* A link-state routing protocol belonging to IGP and designed to dynamically exchange routing information within a single AS [RFC1195]. * *Open Shortest Path First (OSPF):* Another link-state routing protocol belonging to IGP and designed to dynamically exchange routing information within a single AS [RFC2328][RFC5340]. * *Routing Information Base (RIB):* A database within a router or network host that stores routing information. RIB is also known as routing table. * *Virtual Routing and Forwarding (VRF):* The routing (or forwarding) tables separate from the global routing (or forwarding) table in a router [RFC4364][RFC8704]. 3.4. Routing Security Terms * *Autonomous System Provider Authorization (ASPA):* A digitally signed object in the RPKI, that authorizes one or more other ASes as its upstream providers [I-D.ietf-sidrops-aspa-profile]. * *Internet Routing Registry (IRR):* A public database which allows Internet service providers to publish and look up Internet number bindings and policy objectives. Geng & Qin Expires 8 March 2027 [Page 5] Internet-Draft SAV Terminology September 2026 * *Resource holder:* A legitimate holder of either IP address or AS number resources [RFC6480]. * *Resource Public Key infrastructure (RPKI):* A specialized public key infrastructure (PKI) framework to support improved security for the Internet's BGP routing infrastructure [RFC6480]. * *Route Origin Authorization (ROA):* A digitally signed object in the RPKI that provides a means of verifying that an IP address block holder has authorized an AS to originate routes to one or more prefixes within the address block [RFC9582]. 3.5. Scenario Terms * *Direct Server Return (DSR):* A traffic delivery model commonly used by Content Delivery Networks (CDNs) that use anycast service addresses while delivering data from edge locations that do not announce those addresses. In such deployments, a request is received by the anycast server, but the response is sent directly by another server (i.e., the edge server) with the anycast service address as the source address, rather than the address used to reach the edge server. This can create a legitimate hidden-prefix scenario. [I-D.ietf-savnet-intra-domain-problem-statement][I-D.ietf-savnet-inter-domain-problem-statement]. * *Hidden Prefix (HP):* A prefix that a network does not intend to advertise through routing protocols, but intends to use as a source prefix for legitimate traffic. Such a prefix is hidden from SAV mechanisms that construct SAV Tables solely based on routing information, because the routing information does not indicate that the network can legitimately use the prefix as a source prefix. [I-D.ietf-savnet-intra-domain-problem-statement][I-D.ietf-savnet-inter-domain-problem-statement]. * *Limited Propagation of a Prefix (LPP):* A scenario in which a Provider does not further propagate a prefix route learned from a Customer to its upstream Provider(s), for example due to NO_EXPORT, NO_ADVERTISE, or other selective-export policies. As a result, an upstream Provider may not receive the prefix route through that path. [I-D.ietf-savnet-inter-domain-problem-statement]. 4. SAV Terms Geng & Qin Expires 8 March 2027 [Page 6] Internet-Draft SAV Terminology September 2026 4.1. General SAV Terms * *Access Network SAV:* It prevents a host in a network from spoofing the address of another host in the same network segment. Access Network SAV enables source address-granularity of protection [RFC5210]. * *Inter-domain SAV (aka Inter-AS SAV):* Inter-domain SAV, defined in the context of Internet routing using BGP-4 [RFC4271], checks the source addresses of data traffic received from a neighboring Autonomous System (AS), whether that traffic originated within the neighbor's network or is being transited through it. Inter-domain SAV is applied at border routers to incoming traffic on external interfaces directly connected to a neighboring AS. The local AS (SAV performing AS) and the neighbor AS are connected using external BGP (eBGP). The neighbor AS could be using either a public AS number (ASN) or a private ASN [RFC6996]. [I-D.ietf-savnet-inter-domain-problem-statement] * *Intra-domain SAV (aka Intra-AS SAV):* The AS validates the source addresses of data traffic that it originates directly or indirectly. Intra-domain SAV is applied at external interfaces (on routers) facing entities that are not deployed as neighboring ASes and are therefore not covered by inter-domain SAV. For example, an entity can be a single host, a set of hosts, or a customer network with no AS that manages one or more IP prefixes. The entity may source traffic using prefixes assigned by the AS or its own BYOIP prefixes. From the perspective of other ASes, such traffic is originated by the AS. [I-D.ietf-savnet-intra-domain-problem-statement] * *SAV Rule:* The rule that indicates the validity of a specific source IP address or source IP prefix per router interface. It is used by a router to make SAV decisions [I-D.ietf-savnet-intra-domain-problem-statement]. * *SAV Table:* The table of prefixes that indicates the validity of a specific source IP address or source IP prefix per interface. Sometimes the terms 'RPF (Reverse Path Forwarding) list' or 'SAV rules' are used interchangeably with 'SAV table' [I-D.ietf-savnet-inter-domain-problem-statement]. * *Source Address Spoofing (aka Source Address Forgery):* The act of using spoofed source IP addresses assigned to other machines. Malicious actors use IP spoofing to invoke a variety of attacks, including Distributed Denial of Service (DDoS) attacks, policy evasion, and a range of application-level attacks [manrs-blog]. A spoofed source address can be either IPv4 or IPv6. Geng & Qin Expires 8 March 2027 [Page 7] Internet-Draft SAV Terminology September 2026 * *Source Address Validation (SAV):* A kind of techniques for the detection and mitigation of Source Address Spoofing [RFC8704]. Routers conduct SAV on data packet in the data plane. SAV focuses on the scenarios of native IP forwarding or IP-encapsulated tunnel (IPsec, GRE, SRv6, etc.). Note that, the SAV mechanisms that the SAVNET working group is interested in should not modify data plane packets [savnet-charter]. * *Source Address Validation Architecture (SAVA):* A multiple-fence architecture that takes Access Network SAV, Intra-AS SAV, and inter-AS SAV [RFC5210]. The assumption here is that when access- network SAV is not universally deployed, Intra-AS SAV and Inter-AS SAV can increase the defense in depth by blocking spoofing packets that have entered the network. * *Source Address Validation Improvements (SAVI):* A set of access- network SAV mechanisms that provide fine-grained source address validation and prevent nodes attached to the same IP link from spoofing each other's IP addresses [savi-charter]. * *Source Address Validation in Intra-domain and Inter-domain Networks (SAVNET):* It refers to both Intra-domain SAV and Inter- domain SAV. The SAVNET working group was created for the evolvement of SAVNET mechanisms [savnet-charter]. 4.2. SAV Enforcement Terms * *Improper Block (aka False Positive):* The validation results in packets with legitimate source addresses being blocked improperly due to inaccurate SAV rules. (The terms 'improper block' and 'false positive' are used synonymously.) [I-D.ietf-savnet-intra-domain-problem-statement][I-D.ietf-savnet-inter-domain-problem-statement]. * *Improper Permit (aka False Negative):* The validation results in packets with spoofed source addresses being permitted improperly due to inaccurate SAV rules. (The terms 'improper permit' and 'false negative' are used synonymously.) [I-D.ietf-savnet-intra-domain-problem-statement][I-D.ietf-savnet-inter-domain-problem-statement]. * *Interface-based Source Prefix Allowlist (aka Source Prefix Allowlist):* A Validation Mode that takes effect on a specific interface. The interface enabling this mode maintains a source prefix list. Only the source addresses encompassed by the source prefixes recorded in the list will be considered valid, otherwise invalid [I-D.ietf-savnet-general-sav-capabilities]. Geng & Qin Expires 8 March 2027 [Page 8] Internet-Draft SAV Terminology September 2026 * *Interface-based Source Prefix Blocklist (aka Source Prefix Blocklist):* A Validation Mode that takes effect on a specific interface. The interface enabling this mode maintains a source prefix list. Any source addresses encompassed by the source prefixes recorded in the list will be considered invalid, otherwise valid [I-D.ietf-savnet-general-sav-capabilities]. * *Source Prefix-based Interface Allowlist:* A Validation Mode that takes effect at the router scale. The router enabling this mode will record the source prefixes attached with an interface allowlist. For the packet whose source address is encompassed by a recorded source prefix, the packet is considered valid only when its incoming interface is included in the corresponding interface allowlist. Otherwise, the packet is considered invalid. For the packet whose source address is encompassed by no recorded source prefix, the validity of the packet is unknown [I-D.ietf-savnet-general-sav-capabilities]. * *Source Prefix-based Interface Blocklist:* A Validation Mode that takes effect at the router scale. The router enabling this mode will record the source prefixes attached with an interface blocklist. For the packet whose source address is encompassed by a recorded source prefix, the packet is considered valid only when its incoming interface is not included in the corresponding interface allowlist. Otherwise, the packet is considered invalid. For the packet whose source address is encompassed by no recorded source prefix, the validity of the packet is unknown [I-D.ietf-savnet-general-sav-capabilities]. * *Traffic Handling Policy:* The data plane action taken on the incoming packet after the SAV process on the packet. Besides "Discard", many other actions such as "Permit", "Rate Limit", and "Traffic Redirect" can be chosen and taken for the packet with the invalid state [I-D.ietf-savnet-general-sav-capabilities]. * *Validation Mode:* The mode indicates how SAV Rules are logically organized and used to conduct validation [I-D.ietf-savnet-general-sav-capabilities]. 4.3. SAV Mechanism Terms * *Access Control List (ACL) for SAV:* A filter that checks the source address of a data packet against a list of acceptable or unacceptable prefixes [RFC2827]. * *BAR-SAV:* A mechanism that generates source prefix allowlists by using BGP UPDATE messages, ASPA, and ROA [I-D.ietf-sidrops-bar-sav]. Geng & Qin Expires 8 March 2027 [Page 9] Internet-Draft SAV Terminology September 2026 * *Configuration Information:* This information is configured locally by the AS operator. For example, an AS provisions (suballocates) prefixes p1 and p2 for a non-BGP customer network, which also owns an RIR-allocated prefix p3. The customer instructs the AS to advertise p1 via eBGP on the public Internet, restrict p2 strictly to internal use (in the customer network), and refrain from advertising p3 while still allowing it to source outbound traffic. The AS locally configures these prefixes accordingly. This configuration information is valuable for both intra-domain SAV to permit expected prefixes and inter-domain SAV at other interfaces to block unexpected prefixes. [I-D.ietf-savnet-inter-domain-problem-statement] * *Enhanced Feasible-Path uRPF (EFP-uRPF):* A mechanism that is more flexible about directionality than the FP-uRPF and is for enhancing FP-uRPF in some cases. It is based on the principle that if BGP updates for multiple prefixes with the same origin AS were received on different interfaces (at border routers), then incoming data packets with source addresses in any of those prefixes should be accepted on any of those interfaces [RFC8704]. * *Feasible-Path uRPF (FP-uRPF):* An extension of Strict uRPF. Instead of just inserting one best route there, the alternative paths (if any) have been added as well, and are valid for consideration [RFC3704]. * *General SAV Information:* The information that is not specialized for SAV but can be utilized to generate SAV rules, and is initially utilized for other purposes. Currently, the General SAV Information consists of the information from RPKI ROA objects and ASPA objects, local routing information, and the information from IRR data [I-D.ietf-savnet-inter-domain-architecture]. * *Loose uRPF:* A mechanism checks only for the existence of a route (even a default route, if applicable), not where the route points to (At least some implementations of Loose uRPF check where the default route points to) [RFC3704]. * *Loose uRPF Ignoring Default Route:* Loose uRPF checks only for the existence of a explicit route (default routes are excluded) [RFC3704]. Geng & Qin Expires 8 March 2027 [Page 10] Internet-Draft SAV Terminology September 2026 * *SAV-related Information:* Routing information (e.g., RIBs and FIBs populated by routing protocols or by the local configuration information -- described below -- provided by the AS operator) and objects published in the Resource Public Key Infrastructure (RPKI) that were originally proposed for non-SAV purposes but may also be used for SAV. The RPKI objects include existing RPKI object types (e.g., ROAs and ASPAs) as well as any new types that may be proposed. [I-D.ietf-savnet-inter-domain-problem-statement] * *SAV-specific Information:* Information dedicated to SAV, which may be defined and exchanged between ASes using potentially new inter-AS communication protocol or an extension of an existing protocol. The information may also take the form of new RPKI object type(s). It may also come from the local configuration information provided by the AS operator. [I-D.ietf-savnet-inter-domain-problem-statement] * *Source Entity (aka Source Router or Source AS):* The Entity (Router/AS) that propagates its SAV-specific information to Validation Entity (Router/AS) [I-D.ietf-savnet-intra-domain-architecture][I-D.ietf-savnet-inter-domain-architecture]. Source Entity is the producer of SAV-specific information. * *Strict unicast Reverse Path Forwarding (uRPF):* A mechanism that uses FIB for SAV. An ingress packet is accepted only if the FIB contains a prefix that encompasses the source address and forwarding information for that prefix points back to the interface over which the packet was received [RFC3704]. * *Validation Entity (aka Validation Router or Validation AS):* The Entity (Router/AS) that receives SAV-specific information from Source Entity (Router/AS) [I-D.ietf-savnet-intra-domain-architecture][I-D.ietf-savnet-inter-domain-architecture]. Validation Entity is the consumer of SAV-specific information. * *VRF uRPF:* A mechanism that takes SAV based on VRF table instead of FIB. The specific routes received from external BGP peers will be stored in a dedicated VRF table. VRF uRPF can be implemented to support the strict mode like Strict uRPF or the loose mode like Loose uRPF [RFC8704]. 5. Security Considerations This document provides an overview of terms and abbreviations related to SAV and does not have security considerations. Geng & Qin Expires 8 March 2027 [Page 11] Internet-Draft SAV Terminology September 2026 6. IANA Considerations This document does not require any IANA actions. 7. Informative References [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC3222] Trotter, G., "Terminology for Forwarding Information Base (FIB) based Router Performance", RFC 3222, DOI 10.17487/RFC3222, December 2001, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, "A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience", RFC 5210, DOI 10.17487/RFC5210, June 2008, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . Geng & Qin Expires 8 March 2027 [Page 12] Internet-Draft SAV Terminology September 2026 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, . [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, . [RFC9234] Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. Sriram, "Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages", RFC 9234, DOI 10.17487/RFC9234, May 2022, . [RFC9582] Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S. Kent, "A Profile for Route Origin Authorizations (ROAs)", RFC 9582, DOI 10.17487/RFC9582, May 2024, . [I-D.ietf-savnet-intra-domain-problem-statement] Qin, L., Li, D., Wu, J., Huang, M., and N. Geng, "Problem Statement, Gap Analysis, and Requirements for Intra-domain Source Address Validation", Work in Progress, Internet- Draft, draft-ietf-savnet-intra-domain-problem-statement- 26, 1 June 2026, . [I-D.ietf-savnet-inter-domain-problem-statement] Li, D., Qin, L., Liu, L., Huang, M., and K. Sriram, "Problem Statement, Gap Analysis, and Requirements for Inter-Domain Source Address Validation", Work in Progress, Internet-Draft, draft-ietf-savnet-inter-domain-problem- statement-21, 19 July 2026, . Geng & Qin Expires 8 March 2027 [Page 13] Internet-Draft SAV Terminology September 2026 [I-D.ietf-savnet-intra-domain-architecture] Li, D., Wu, J., Qin, L., Geng, N., and L. Chen, "Intra- domain Source Address Validation Architecture", Work in Progress, Internet-Draft, draft-ietf-savnet-intra-domain- architecture-04, 29 June 2026, . [I-D.ietf-savnet-inter-domain-architecture] Li, D., Chen, L., Geng, N., Liu, L., and L. Qin, "Inter- domain Source Address Validation (SAVNET) Architecture", Work in Progress, Internet-Draft, draft-ietf-savnet-inter- domain-architecture-03, 1 March 2026, . [I-D.ietf-savnet-general-sav-capabilities] Huang, M., Cheng, W., Li, D., Geng, N., and L. Chen, "General Source Address Validation Capabilities", Work in Progress, Internet-Draft, draft-ietf-savnet-general-sav- capabilities-03, 21 June 2026, . [I-D.ietf-sidrops-aspa-profile] Snijders, J., Azimov, A., Uskov, E., Bush, R., Housley, R., and B. Maddison, "A Profile for Autonomous System Provider Authorization", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-profile-29, 29 July 2026, . [I-D.geng-idr-bgp-savnet] Geng, N., Li, Z., Tan, Z., Liu, and D. Li, "BGP Extensions for Source Address Validation Networks (BGP SAVNET)", Work in Progress, Internet-Draft, draft-geng-idr-bgp-savnet-06, 24 March 2026, . [I-D.li-sidrops-bicone-sav] Qin, L., Li, D., Chen, L., and L. Liu, "Bicone Source Address Validation", Work in Progress, Internet-Draft, draft-li-sidrops-bicone-sav-07, 7 July 2025, . Geng & Qin Expires 8 March 2027 [Page 14] Internet-Draft SAV Terminology September 2026 [I-D.ietf-sidrops-bar-sav] Sriram, K., Lubashev, I., and D. Montgomery, "Source Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR- SAV)", Work in Progress, Internet-Draft, draft-ietf- sidrops-bar-sav-10, 19 July 2026, . [caida-asrank] "CAIDA AS Rank", August 2025, . [manrs-blog] "Why is Source Address Validation Still a Problem?", April 2023, . [savnet-charter] "Charter for SAVNET Working Group", March 2023, . [savi-charter] "Charter for SAVI Working Group", July 2008, . Authors' Addresses Nan Geng Huawei Beijing China Email: gengnan@huawei.com Lancheng Qin Zhongguancun Laboratory Beijing China Email: qinlc@zgclab.edu.cn Geng & Qin Expires 8 March 2027 [Page 15]