Currently Used Terminology Related to Source Address Validation
draft-gq-savnet-sav-terms-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Nan Geng , Lancheng Qin | ||
| Last updated | 2026-09-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gq-savnet-sav-terms-02
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, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[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, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3222] Trotter, G., "Terminology for Forwarding Information Base
(FIB) based Router Performance", RFC 3222,
DOI 10.17487/RFC3222, December 2001,
<https://www.rfc-editor.org/info/rfc3222>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[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,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[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,
<https://www.rfc-editor.org/info/rfc5210>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
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, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/info/rfc6793>.
[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,
<https://www.rfc-editor.org/info/rfc8704>.
[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,
<https://www.rfc-editor.org/info/rfc9234>.
[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,
<https://www.rfc-editor.org/info/rfc9582>.
[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, <https://datatracker.ietf.org/doc/html/
draft-ietf-savnet-intra-domain-problem-statement-26>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
inter-domain-problem-statement-21>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
intra-domain-architecture-04>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
inter-domain-architecture-03>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
general-sav-capabilities-03>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-profile-29>.
[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, <https://datatracker.ietf.org/doc/html/
draft-geng-idr-bgp-savnet-06>.
[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,
<https://datatracker.ietf.org/doc/html/draft-li-sidrops-
bicone-sav-07>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
bar-sav-10>.
[caida-asrank]
"CAIDA AS Rank", August 2025,
<https://asrank.caida.org/about>.
[manrs-blog]
"Why is Source Address Validation Still a Problem?", April
2023, <https://manrs.org/2023/04/why-is-source-address-
validation-still-a-problem>.
[savnet-charter]
"Charter for SAVNET Working Group", March 2023,
<https://datatracker.ietf.org/wg/savnet/about>.
[savi-charter]
"Charter for SAVI Working Group", July 2008,
<https://datatracker.ietf.org/wg/savi/about/>.
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]