Export of Source Address Validation (SAV) Information in IPFIX
draft-cao-savnet-ipfix-sav-00
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 | Qian Cao , Mingqing(Michael) Huang , Benoît Claise , Tianran Zhou | ||
| Last updated | 2026-09-16 | ||
| Replaces | draft-cao-opsawg-ipfix-sav | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| 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-cao-savnet-ipfix-sav-00
savnet Q. Cao
Internet-Draft M. Huang
Intended status: Standards Track Zhongguancun Laboratory
Expires: 21 March 2027 B. Claise
Everything OPS
T. Zhou
Huawei
17 September 2026
Export of Source Address Validation (SAV) Information in IPFIX
draft-cao-savnet-ipfix-sav-00
Abstract
This document specifies the IP Flow Information Export Information
Elements to export the context and outcome of Source Address
Validation enforcement data. These SAV-specific Information Elements
provide detailed insight into why packets are identified as spoofed
by capturing the specific SAV rules that triggered validation
decisions. This operational visibility is essential for network
operators to observe SAV enforcement behavior and analyze source
address spoofing events detected by SAV.
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 21 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Cao, et al. Expires 21 March 2027 [Page 1]
Internet-Draft SAV IPFIX September 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SAV Overview and IPFIX Export Requirements . . . . . . . . . 4
4. IPFIX SAV Information Elements . . . . . . . . . . . . . . . 5
4.1. Design Rationale . . . . . . . . . . . . . . . . . . . . 5
4.2. savRuleType (unsigned8) . . . . . . . . . . . . . . . . . 6
4.3. savTargetType (unsigned8) . . . . . . . . . . . . . . . . 6
4.4. savMatchedContentList (subTemplateList) . . . . . . . . . 7
4.5. savPolicyAction (unsigned8) . . . . . . . . . . . . . . . 7
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Operational Considerations . . . . . . . . . . . . . . . . . 8
7. YANG-IPFIX Mapping . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9.1. New IPFIX Sub-registries . . . . . . . . . . . . . . . . 11
9.1.1. IPFIX savRuleType (TBD1) Subregistry . . . . . . . . 11
9.1.2. IPFIX savTargetType (TBD2) Subregistry . . . . . . . 12
9.1.3. IPFIX savPolicyAction (TBD4) Subregistry . . . . . . 12
9.2. New Information Elements . . . . . . . . . . . . . . . . 13
9.2.1. savRuleType . . . . . . . . . . . . . . . . . . . . . 13
9.2.2. savTargetType . . . . . . . . . . . . . . . . . . . . 14
9.2.3. savMatchedContentList . . . . . . . . . . . . . . . . 14
9.2.4. savPolicyAction . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. IPFIX Encoding Examples . . . . . . . . . . . . . . 16
A.1. Template Record and Data Record with Sub-Template List . 16
A.1.1. Sub-Template Definitions . . . . . . . . . . . . . . 17
A.1.2. Main Template Record . . . . . . . . . . . . . . . . 19
A.1.3. Data Set Example . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Cao, et al. Expires 21 March 2027 [Page 2]
Internet-Draft SAV IPFIX September 2026
1. Introduction
Source Address Validation (SAV) serves as a fundamental defense
mechanism against IP source address spoofing. Despite its critical
role in network security, current SAV implementations lack
operational visibility, making it difficult to answer essential
operational questions:
* How many packets are identified as spoofed and dropped by SAV?
* Which interfaces receive spoofed packets and which source prefixes
are targeted?
* Which specific SAV rules trigger the enforcement actions?
* Are SAV rules functioning as intended or potentially
misconfigured?
This document introduces a set of SAV-specific IP Flow Information
Export (IPFIX) Information Elements (IEs) that enable detailed
reporting of Source Address Validation enforcement actions. These
elements align with the SAV concepts and operational models defined
in [I-D.ietf-savnet-general-sav-capabilities], and provide traffic
observations that can be operationally correlated with the SAV
configuration and state information available via the YANG data model
[I-D.li-savnet-sav-yang].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document makes use of the terms defined in [RFC7011], and
[I-D.ietf-savnet-general-sav-capabilities].
The following terms are used as defined in [RFC7011]:
* IPFIX
* IPFIX Information Elements
* Template
* Template Record
Cao, et al. Expires 21 March 2027 [Page 3]
Internet-Draft SAV IPFIX September 2026
* Data Record
* Data Set
* Exporter
* Collector
The following terms are used as defined in
[I-D.ietf-savnet-general-sav-capabilities].
* SAV rule
* Validation mode
3. SAV Overview and IPFIX Export Requirements
This section outlines the operational requirements for SAV telemetry
export using IPFIX, based on the generalized SAV architectural
framework defined in [I-D.ietf-savnet-general-sav-capabilities].
The SAV framework establishes four canonical validation modes that
model validation policies:
* *Interface-based prefix allowlist (Mode 1):* Validates that a
source prefix is explicitly permitted on the incoming interface.
* *Interface-based prefix blocklist (Mode 2):* Validates that a
source prefix is not explicitly blocked on the incoming interface.
* *Prefix-based interface allowlist (Mode 3):* Validates that a
packet is received on an interface explicitly permitted for its
source prefix.
* *Prefix-based interface blocklist (Mode 4):* Validates that a
packet is not received on an interface explicitly blocked for its
source prefix.
These modes can be applied independently or in combination on a
router, following a defined validation procedure (Section 2 of
[I-D.ietf-savnet-general-sav-capabilities]). Furthermore, when
identifying a packet as spoofed, a range of traffic handling policies
(e.g. discard, rate-limit, redirect) can be applied.
However, the generalized SAV model requires corresponding operational
visibility capabilities. Without integrated telemetry, operators
face significant challenges in:
Cao, et al. Expires 21 March 2027 [Page 4]
Internet-Draft SAV IPFIX September 2026
* Enforcement Visibility: Observing SAV enforcement actions and
identifying which rules were triggered.
* Operational Analysis: Understanding the context of SAV decisions
and troubleshooting unexpected enforcement behavior.
* Threat Intelligence: Analyzing traffic patterns identified as
spoofed by SAV.
To address these limitations, IPFIX [RFC7011] and [RFC7012] provide a
vendor-neutral protocol for SAV telemetry. The exported data must
provide insight into:
* The validation outcome and specific reason for the decision
* The identity and type of SAV rule or rule set that influenced the
decision
* The configured rule content that was evaluated during validation
* The enforcement action applied to spoofed packets
The following section defines the IPFIX IEs that meet these
requirements.
4. IPFIX SAV Information Elements
This section defines the IEs used for SAV telemetry. These IEs have
been specified in accordance with the guidelines in [RFC7013].
4.1. Design Rationale
The SAV IPFIX IEs are designed to provide detailed visibility into
SAV enforcement actions, enabling network operators and automation
systems to monitor and troubleshoot SAV operations effectively. The
design follows these principles:
* *Scope*. The SAV-specific IEs are used to report the outcome and
context of SAV processing for data plane traffic observations.
Interface, device or network-level SAV configuration is out of
scope for these IEs and is covered by the SAVNET YANG data model.
* *Conceptual Alignment*. The elements align with the validation
modes and rule types defined in
[I-D.ietf-savnet-general-sav-capabilities], ensuring consistency
with the architectural SAV concepts.
Cao, et al. Expires 21 March 2027 [Page 5]
Internet-Draft SAV IPFIX September 2026
* *Semantic Correlation*. The IPFIX encoding preserves the semantic
relationships defined in [I-D.li-savnet-sav-yang], which enables
correlation between IPFIX Data Records in the data plane and YANG
configuration/state data in the control plane, facilitating
comprehensive analysis.
* *Structured Encoding*. The savMatchedContentList is encoded as a
subTemplateList to represent the multi-field tuples of SAV rules.
The structure of subTemplateList was chosen because it can
encapsulate heterogeneous fields (e.g., prefix, length, interface)
within a single list element. The list semantics (allOf,
exactlyOneOf) directly encode the SAV validation logic (e.g.,
matching all rules in an allowlist vs. exactly one in a blocklist)
into the data structure.
4.2. savRuleType (unsigned8)
The savRuleType element classifies the rule as either an allowlist or
a blocklist. The values correspond to the check type concepts in the
SAV architecture:
* A value of 0 is reserved to indicate that no value is available.
* A value of 1 (allowlist) indicates the packet was validated
against an allowlist.
* A value of 2 (blocklist) indicates the packet was validated
against a blocklist.
4.3. savTargetType (unsigned8)
The savTargetType element specifies the lookup key used by the SAV
rule. It may be used in conjunction with savRuleType to fully define
the validation mode applied.
* A value of 0 is reserved to indicate that no value is available.
* A value of 1 (interface-based) indicates the rule is indexed by an
interface (e.g., "on interface X, what prefixes are allowed/
blocked?").
* A value of 2 (prefix-based) indicates the rule is indexed by a
source prefix (e.g., "for prefix Y, which interfaces are allowed/
blocked?").
Cao, et al. Expires 21 March 2027 [Page 6]
Internet-Draft SAV IPFIX September 2026
4.4. savMatchedContentList (subTemplateList)
The savMatchedContentList element carries the content of the rules
that were relevant to the validation decision, encoded as a
subTemplateList according to [RFC6313]. Each element in the list
represents a complete SAV rule tuple. The content and semantics of
the list are defined by the savRuleType:
* *For Allowlist non-matches (savRuleType=1)*: The
savMatchedContentList consists of the set of all rule tuples from
the consulted SAV allowlist at the time of the packet's
processing. The subTemplateList semantic MUST be allOf (0x03),
indicating that the packet was validated against all these rules
and did not match any of them.
* *For Blocklist matches (savRuleType=2)*: The savMatchedContentList
contains the matched rule tuple from the consulted SAV blocklist.
The subTemplateList semantic MUST be exactlyOneOf (0x01),
indicating that the packet matched this specific rule.
*Semantic Interpretation of Standard Information Elements:* When
standard IPFIX IEs (such as ingressInterface, sourceIPv4Prefix,
sourceIPv4PrefixLength or their IPv6 equivalents) are used within the
subTemplateList of savMatchedContentList, they represent values from
the SAV rule configuration, rather than from the actual packet being
validated. This contextual distinction is critical for correct
interpretation:
* *In the parent Data Record*: These IEs describe attributes of the
actual spoofed packets that were validated by SAV.
* *Within savMatchedContentList*: These same IEs describe the
configured SAV rule parameters that were evaluated during
validation.
This approach ensures clear semantic distinction by reusing existing
IEs, without requiring definition of new elements for SAV rule
parameters.
4.5. savPolicyAction (unsigned8)
The savPolicyAction indicates the action applied to packets
identified as spoofed. The action taken is a matter of local policy.
This element reports the outcome.
* A value of 0 is reserved to indicate that no value is available.
Cao, et al. Expires 21 March 2027 [Page 7]
Internet-Draft SAV IPFIX September 2026
* A value of 1 (permit) indicates packets represented by the record
were allowed to proceed (monitoring only).
* A value of 2 (discard) indicates packets represented by the record
were discarded or dropped.
* A value of 3 (rate-limit) indicates packets represented by the
record were subject to a rate-limiting policy.
* A value of 4 (redirect) indicates packets represented by the
record were redirected to an alternative destination.
* Values 5-255 are reserved for future extension.
5. Use Cases
The SAV-specific IPFIX IEs defined in this document enable network
operators to answer critical operational questions that are currently
unaddressable without telemetry for SAV:
*SAV Enforcement Monitoring:* Use savRuleType (TBD1), savTargetType
(TBD2), savPolicyAction (TBD4) and standard IPFIX counters, to
quantify SAV enforcement actions, analyze their distribution across
different validation modes, and identify applied SAV enforcement
actions (discard, rate-limit, redirect) at the data plane level.
This complements control-plane monitoring via YANG models, providing
visibility into actual enforcement behavior rather than configured
rules.
*Rule-Level Attribution and Troubleshooting:* Use
savMatchedContentList (TBD3) to determine the specific SAV rule
configuration that triggered enforcement decisions, including the
exact rule parameters (interfaces, prefixes) evaluated during
validation, whether for allowlist failures or blocklist matches.
*Forensic Analysis and Compliance:* SAV Data Records include both
SAV-specific Information Elements and traditional packet-level
details (source/destination addresses, ports, protocol), providing
complete information for incident investigation and compliance
reporting. Operators can use these records to investigate the source
and nature of spoofing attacks, and gather evidence to support
external trust initiatives and regulatory compliance reporting.
6. Operational Considerations
While this document defines new IPFIX IEs using standard IPFIX
mechanisms, implementors should consider:
Cao, et al. Expires 21 March 2027 [Page 8]
Internet-Draft SAV IPFIX September 2026
* *Exporter Implementation:* Exporters MUST properly encode the
subTemplateList structure for savMatchedContentList and ensure
semantic consistency between savRuleType and list contents.
Exporters MUST also define the sub-templates (e.g., 901-904) used
in savMatchedContentList prior to exporting Data Records that use
them.
* *Collector Processing:* Collectors MUST be capable of parsing
subTemplateList structure and understanding the context-dependent
semantics of standard IEs within savMatchedContentList.
Collectors MUST associate the sub-templates with the main template
for correct interpretation.
* *Export Volume and Aggregation:* When savMatchedContentList is
used for allowlist non-matches, the exported record carries the
full consulted allowlist, which may generate excessive IPFIX
traffic. To bound export load, exporters SHOULD consider rate
limiting, sampling [RFC5475], or aggregation [RFC7015]. Exporters
MAY aggregate packets sharing the same Flow Key and SAV context
into a single Data Record, including over a reporting interval.
For allowlist non-match events, aggregation is more constrained
because the consulted allowlist may change between packets.
Exporters SHOULD avoid combining packets validated against
different allowlist contents into the same Data Record.
7. YANG-IPFIX Mapping
The mappings between the SAV YANG data model and IPFIX IEs are
considered based on the common foundation of the general SAV
capabilities document [I-D.ietf-savnet-general-sav-capabilities].
The operational correlation is demonstrated in Table 1, which defines
the values for the designed IEs mapped from the corresponding
[I-D.li-savnet-sav-yang] SAV Management YANG Module.
Cao, et al. Expires 21 March 2027 [Page 9]
Internet-Draft SAV IPFIX September 2026
+---------------------+---------------------------------------+
| YANG Elements | IPFIX IEs |
+---------------------+---------------------------------------+
| sav-check-type | savRuleType |
| sav:sav-allow-list| 1 (allowlist) |
| sav:sav-block-list| 2 (blocklist) |
+---------------------+---------------------------------------+
| sav-mode | savTargetType |
| sav:sav-im | 1 (interface-based) |
| sav:sav-cm | 2 (prefix-based) |
+---------------------+---------------------------------------+
| SAV Rules attributes| savMatchedContentList |
| source-prefix | sourceIPv4Prefix/sourceIPv6Prefix |
| incoming-interface| ingressInterface |
+---------------------+---------------------------------------+
Table 1: Mappings between SAV YANG Data Model and IPFIX Information
Elements
The savPolicyAction element carries real-time SAV decisions applied
to spoofed packets. It does not directly map to YANG configuration
node.
The code points for these IEs are maintained by IANA in the
corresponding subregistries of the IPFIX registry. Future additions
or changes are managed via Expert Review as described in IANA
Considerations (Section 9).
8. Security Considerations
The SAV-specific Information Elements defined in this document export
data that reveals the security posture of a network's source address
validation deployment. This data is sensitive and warrants
additional considerations beyond those in [RFC7012].
* *Rule Configuration Disclosure*: The savMatchedContentList
element, when used with the allOf semantic for allowlist non-
matches, exports the complete set of source prefixes permitted on
an interface. An adversary with access to these IPFIX exports,
for example via a compromised collector, could learn which source
prefixes are allowed on each interface. This information could
then be used to forge packets with spoofed source addresses drawn
from those permitted prefixes, thereby increasing the adversary's
ability to evade source address validation.
Cao, et al. Expires 21 March 2027 [Page 10]
Internet-Draft SAV IPFIX September 2026
* *Enforcement State Disclosure*: The savPolicyAction element with
the value permit (monitoring only) reveals that SAV is not
actively enforcing on a given path. This information could be
exploited by an adversary to identify interfaces or prefixes where
spoofed traffic would not be dropped.
* *IPFIX Export Amplification*: A sustained spoofing attack can
trigger a large volume of IPFIX exports and may overload the
collector or the management plane, causing a secondary denial-of-
service effect. This risk is especially relevant when allowlist
non-match records carry the full consulted allowlist. The
guidance in Operational Considerations (Section 6) can help
mitigate this risk.
* *Transport Security*: Given the sensitivity of SAV enforcement
data, exporters and collectors SHOULD use encrypted transport such
as TLS or DTLS as described in [RFC7011] to protect SAV Data
Records from eavesdropping and tampering.
* *Access Control*: Collectors that store SAV enforcement data
SHOULD restrict access to authorized operators, as the data
reveals both the SAV configuration and its enforcement outcomes.
Other security considerations described in
[I-D.ietf-savnet-general-sav-capabilities] apply to this document.
9. IANA Considerations
This document requests IANA actions for the IPFIX registry
[IANA-IPFIX]. Specifically, it requests the creation of new
subregistries for the value spaces of selected SAV-specific
Information Elements, and the allocation of four new IPFIX
Information Elements.
9.1. New IPFIX Sub-registries
IANA is requested to create new subregistries under the IPFIX IEs
registries. These subregistries specify the value spaces for the
savRuleType, savTargetType, and savPolicyAction IEs. The
corresponding IE definitions are provided in New Information Elements
(Section 9.2). The allocation policy is Expert Review [RFC8126].
9.1.1. IPFIX savRuleType (TBD1) Subregistry
* *Reference*: This document, savRuleType (Section 4.2);
[I-D.ietf-savnet-general-sav-capabilities], Section 2 (Validation
Modes)
Cao, et al. Expires 21 March 2027 [Page 11]
Internet-Draft SAV IPFIX September 2026
* *Allocation Policy*: Expert Review [RFC8126]
* *Expert Guidance*: Experts should ensure that new values are
consistent with the SAV architecture concepts defined in
[I-D.ietf-savnet-general-sav-capabilities], particularly the
validation modes and rule types (allowlist or blocklist).
Initial values:
+-------+------------+-------------------------------------------------+
| Value | Name | Description |
+-------+------------+-------------------------------------------------+
| 0 | unassigned | Reserved; no value is available |
| 1 | allowlist | The packet was validated against an allowlist |
| 2 | blocklist | The packet was validated against a blocklist |
| 3-255 | unassigned | Reserved for future assignment |
+-------+------------+-------------------------------------------------+
9.1.2. IPFIX savTargetType (TBD2) Subregistry
* *Reference*: This document, savTargetType (Section 4.3);
[I-D.ietf-savnet-general-sav-capabilities], Section 2 (Validation
Modes)
* *Allocation Policy*: Expert Review [RFC8126]
* *Expert Guidance*: Experts should consult
[I-D.ietf-savnet-general-sav-capabilities] to ensure new values
align with the defined target types (interface-based or prefix-
based).
Initial values:
+-------+-----------------+----------------------------------------+
| Value | Name | Description |
+-------+-----------------+----------------------------------------+
| 0 | unassigned | Reserved; no value is available |
| 1 | interface-based | The rule is indexed by an interface |
| 2 | prefix-based | The rule is indexed by a prefix |
| 3-255 | unassigned | Reserved for future assignment |
+-------+-----------------+----------------------------------------+
9.1.3. IPFIX savPolicyAction (TBD4) Subregistry
* *Reference*: This document, savPolicyAction (Section 4.5);
[I-D.ietf-savnet-general-sav-capabilities], Section 4 (Traffic
Handling Policies)
Cao, et al. Expires 21 March 2027 [Page 12]
Internet-Draft SAV IPFIX September 2026
* *Allocation Policy*: Expert Review [RFC8126]
* *Expert Guidance*: Experts should ensure that new actions are
consistent with the SAV traffic handling policies defined in
[I-D.ietf-savnet-general-sav-capabilities].
Initial values:
+-------+----------+---------------------------------------------------+
| Value | Name | Description |
+-------+----------+---------------------------------------------------+
| 0 |unassigned| Reserved; no value is available |
| 1 | permit |The packet was allowed to proceed (monitoring only)|
| 2 | discard | Packet was discarded or dropped |
| 3 |rate-limit| Traffic was subjected to rate limiting |
| 4 | redirect | Packet was redirected to alternative destination |
| 5-255 |unassigned| Reserved for future assignment |
+-------+----------+---------------------------------------------------+
9.2. New Information Elements
This document also requests IANA to allocate four new IEs under the
"IPFIX Information Elements" registry [RFC7012] available at
[IANA-IPFIX]. Note that three of these IEs (savRuleType,
savTargetType, and savPolicyAction) have associated value spaces.
The corresponding subregistries are defined in New IPFIX
Sub-registries (Section 9.1).
+------------+-----------------------+
| Element ID | Name |
+------------+-----------------------+
| TBD1 | savRuleType |
| TBD2 | savTargetType |
| TBD3 | savMatchedContentList |
| TBD4 | savPolicyAction |
+------------+-----------------------+
9.2.1. savRuleType
* *ElementID*: TBD1
* *Name*: savRuleType
* *Abstract Data Type*: unsigned8
* *Data Type Semantics*: identifier
Cao, et al. Expires 21 March 2027 [Page 13]
Internet-Draft SAV IPFIX September 2026
* *Description*: Identifies the validation rule type triggered
during SAV enforcement.
* *Reference*: This document, IPFIX savRuleType Subregistry
(Section 9.1.1)
9.2.2. savTargetType
* *ElementID*: TBD2
* *Name*: savTargetType
* *Abstract Data Type*: unsigned8
* *Data Type Semantics*: identifier
* *Description*: Specifies the entity type against which validation
was performed.
* *Reference*: This document, IPFIX savTargetType Subregistry
(Section 9.1.2)
9.2.3. savMatchedContentList
* *ElementID*: TBD3
* *Name*: savMatchedContentList
* *Abstract Data Type*: subTemplateList
* *Data Type Semantics*: list
* *Description*: The content of the SAV rules relevant to the
validation decision.
* *Reference*: This document, savMatchedContentList (Section 4.4)
9.2.4. savPolicyAction
* *ElementID*: TBD4
* *Name*: savPolicyAction
* *Abstract Data Type*: unsigned8
* *Data Type Semantics*: identifier
* *Description*: Action applied to packets identified as spoofed.
Cao, et al. Expires 21 March 2027 [Page 14]
Internet-Draft SAV IPFIX September 2026
* *Reference*: This document, IPFIX savPolicyAction Subregistry
(Section 9.1.3)
10. References
10.1. Normative References
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013,
<https://www.rfc-editor.org/info/rfc7012>.
[RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and
Reviewers of IP Flow Information Export (IPFIX)
Information Elements", BCP 184, RFC 7013,
DOI 10.17487/RFC7013, September 2013,
<https://www.rfc-editor.org/info/rfc7013>.
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
"Export of Structured Data in IP Flow Information Export
(IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011,
<https://www.rfc-editor.org/info/rfc6313>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
10.2. Informative References
[I-D.li-savnet-sav-yang]
Li, D., Liu, L., Lin, C., Wu, J., Wu, T., and W. Cheng,
"YANG Data Model for Intra-domain and Inter-domain Source
Cao, et al. Expires 21 March 2027 [Page 15]
Internet-Draft SAV IPFIX September 2026
Address Validation (SAVNET)", Work in Progress, Internet-
Draft, draft-li-savnet-sav-yang-08, 12 April 2026,
<https://datatracker.ietf.org/doc/html/draft-li-savnet-
sav-yang-08>.
[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>.
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
Raspall, "Sampling and Filtering Techniques for IP Packet
Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009,
<https://www.rfc-editor.org/info/rfc5475>.
[RFC7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation
for the IP Flow Information Export (IPFIX) Protocol",
RFC 7015, DOI 10.17487/RFC7015, September 2013,
<https://www.rfc-editor.org/info/rfc7015>.
[IANA-IPFIX]
"IP Flow Information Export (IPFIX) Entities", n.d.,
<https://www.iana.org/assignments/ipfix/ipfix.xhtml>.
Appendix A. IPFIX Encoding Examples
This appendix provides encoding examples for the SAV-specific IPFIX
IEs defined in this document.
A.1. Template Record and Data Record with Sub-Template List
This example demonstrates the encoding for two observed SAV
enforcement events representing different validation scenarios and
address families as shown in Table 2.
+-----+--------------+---------+---------+-----------+-------------+
|Event|Source Address|Interface|Rule Type|Target Type|Policy Action|
+-----+--------------+---------+---------+-----------+-------------+
| 1 | 192.0.2.100 | 5001 |Allowlist| Interface | Rate-limit |
| 2 | 2001:db8::1 | 5002 |Blocklist| Prefix | Discard |
+-----+--------------+---------+---------+-----------+-------------+
Table 2: Two Observed SAV Validation Events
Cao, et al. Expires 21 March 2027 [Page 16]
Internet-Draft SAV IPFIX September 2026
The first event represents an IPv4 allowlist non-match event where a
packet from source 192.0.2.100 arriving on interface 5001 failed to
match any source prefixes configured in the interface-based
allowlist. The second event represents an IPv6 blocklist match event
where a packet from source 2001:db8::1 was received on interface
5002, which matched a prefix-based blocklist rule.
A.1.1. Sub-Template Definitions
The following sub-templates are defined for use within the
savMatchedContentList element to encode different types of SAV rule
mappings based on address family and validation target type. The
savMatchedContentList element is encoded as a subTemplateList
according to [RFC6313].
The template IDs used in these examples are exemplary and chosen
arbitrarily. In actual implementations, exporters MUST assign unique
template IDs within the IPFIX session for these sub-templates.
* *Sub-Template 901: IPv4 Interface-to-Prefix Mapping*
This sub-template is used when savTargetType=1(interface-based
validation mode) for IPv4 traffic. It contains the mapping from an
interface to source IPv4 prefixes as defined in the SAV rule
configuration. It can be used for both blocklist and allowlist.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 901 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ingressInterface = 10 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Prefix = 44 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4PrefixLength = 9 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Sub-Template 901 (IPv4 Interface-to-Prefix Mapping)
* *Sub-Template 902: IPv6 Interface-to-Prefix Mapping* This sub-
template is the IPv6 equivalent of Sub-Template 901, used for
interface-based validation with IPv6 traffic.
Cao, et al. Expires 21 March 2027 [Page 17]
Internet-Draft SAV IPFIX September 2026
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 902 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ingressInterface = 10 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv6Prefix = 170 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv6PrefixLength = 29 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Sub-Template 902 (IPv6 Interface-to-Prefix Mapping)
* *Sub-Template 903: IPv4 Prefix-to-Interface Mapping*
This sub-template is used when savTargetType=2(prefix-based
validation mode) for IPv4 traffic. It contains the mapping from a
source IPv4 prefixes to interface as defined in the SAV rule
configuration. It can be used for both blocklist and allowlist.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 903 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Prefix = 44 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4PrefixLength = 9 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ingressInterface = 10 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Sub-Template 903 (IPv4 Prefix-to-Interface Mapping)
* *Sub-Template 904: IPv6 Prefix-to-Interface Mapping*
This sub-template is the IPv6 equivalent of Sub-Template 903, used
for prefix-based validation with IPv6 traffic.
Cao, et al. Expires 21 March 2027 [Page 18]
Internet-Draft SAV IPFIX September 2026
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 904 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv6Prefix = 170 | Field Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv6PrefixLength = 29 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ingressInterface = 10 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Sub-Template 904 (IPv6 Prefix-to-Interface Mapping)
A.1.2. Main Template Record
The main Template Record (ID 400) contains fields for exporting
detailed SAV enforcement information including the validation outcome
and the specific rule content that triggered the action. The
template incorporates the savMatchedContentList element as a
variable-length subTemplateList to carry the relevant SAV rule
contents using the appropriate sub-templates defined above.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 400 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| observationTimeMicrosec=324| Field Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| savRuleType = TBD1 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| savTargetType = TBD2 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| savMatchedContentList=TBD3 | Field Length = 0xFFFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| savPolicyAction = TBD4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Main Template Record (ID 400)
Cao, et al. Expires 21 March 2027 [Page 19]
Internet-Draft SAV IPFIX September 2026
A.1.3. Data Set Example
The following Data Set contains two Data Records that represent the
two SAV validation scenarios in Table 2.
The first Data Record (allowlist non-match) encodes the complete set
of allowed prefixes using Sub-Template 901 with the allOf semantic
(0x03). The allowlist includes three SAV rules for ingressInterface
5001, with sourceIPv4Prefix values 198.51.100.0/24, 203.0.113.0/24,
and 192.0.2.128/25.
The second Data Record (blocklist match) encodes the specific blocked
interface using Sub-Template 904 with the exactlyOneOf semantic
(0x01). The matched rule is sourceIPv6Prefix 2001:db8::/32 on
ingressInterface 5002.
The figure below uses abbreviated IE names: savRT for savRuleType,
savTT for savTargetType, savAct for savPolicyAction, sPrf4Len for
sourceIPv4PrefixLength, and sPrf6Len for sourceIPv6PrefixLength.
Cao, et al. Expires 21 March 2027 [Page 20]
Internet-Draft SAV IPFIX September 2026
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 400 | Length = 88 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| observationTimeMicrosec = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x5D2F0A0000000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| savRT =1 | savTT=1 | 255 | List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = 30 | semantic=0x03 | Template ID = 901 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ingressInterface[0] = 5001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv4Prefix[0] = 198.51.100.0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|sPrf4Len[0]=24 | ingressInterface[1] = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5001 | sourceIPv4Prefix[1] = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 203.0.113.0 | sPrf4Len[1]=24| ingressInterface[2] = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5001 | sourceIPv4Prefix[2] = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.128 |sPrf4Len[2]=25 | savAct=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| observationTimeMicrosec = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x5D2F0A0000000001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| savRT =2 | savTT=2 | 255 | List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = 24 | semantic=0x01 | Template ID = 904 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sourceIPv6Prefix[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|sPrf6Len[0]=32 | ingressInterface[0] = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5002 | savAct=2 | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cao, et al. Expires 21 March 2027 [Page 21]
Internet-Draft SAV IPFIX September 2026
Figure 6: Data Set Example
Authors' Addresses
Qian Cao
Zhongguancun Laboratory
Beijing
China
Email: caoqian@zgclab.edu.cn
Mingqing Huang
Zhongguancun Laboratory
Beijing
China
Email: huangmq@mail.zgclab.edu.cn
Benoit Claise
Everything OPS
Belgium
Email: benoit@everything-ops.net
Tianran Zhou
Huawei
Beijing
China
Email: zhoutianran@huawei.com
Cao, et al. Expires 21 March 2027 [Page 22]