rfc9899v1.txt   rfc9899.txt 
skipping to change at line 12 skipping to change at line 12
Internet Engineering Task Force (IETF) O. Gonzalez de Dios Internet Engineering Task Force (IETF) O. Gonzalez de Dios
Request for Comments: 9899 Telefonica Request for Comments: 9899 Telefonica
Category: Standards Track S. Barguil Category: Standards Track S. Barguil
ISSN: 2070-1721 Nokia ISSN: 2070-1721 Nokia
M. Boucadair M. Boucadair
Orange Orange
Q. Wu Q. Wu
Huawei Huawei
November 2025 November 2025
Extensions to the Access Control Lists (ACLs) YANG Model Extensions to the YANG Data Model for Access Control Lists (ACLs)
Abstract Abstract
RFC 8519 defines a YANG data model for Access Control Lists (ACLs). RFC 8519 defines a YANG data model for Access Control Lists (ACLs).
This document specifies a set of extensions that fix many of the This document specifies a set of extensions that fix many of the
limitations of the ACL model as initially defined in RFC 8519. limitations of the ACL model as initially defined in RFC 8519.
Specifically, it introduces augmentations to the ACL base model to Specifically, it introduces augmentations to the ACL base model to
enhance its functionality and applicability. enhance its functionality and applicability.
The document also defines IANA-maintained modules for ICMP types and This document also defines initial versions of IANA-maintained
IPv6 extension headers. modules for ICMP types and IPv6 extension headers.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
skipping to change at line 98 skipping to change at line 98
A.5. Suboptimal TCP Flags Handling A.5. Suboptimal TCP Flags Handling
A.6. Rate-Limit Action A.6. Rate-Limit Action
A.7. Payload-Based Filtering A.7. Payload-Based Filtering
A.8. Reuse the Content of ACLs Across Several Devices A.8. Reuse the Content of ACLs Across Several Devices
A.9. Match MPLS Headers A.9. Match MPLS Headers
Appendix B. Examples Appendix B. Examples
B.1. TCP Flags Handling B.1. TCP Flags Handling
B.2. Fragments Handling B.2. Fragments Handling
B.3. Pattern-Based Filtering B.3. Pattern-Based Filtering
B.4. VLAN Filtering B.4. VLAN Filtering
B.5. ISID Filtering B.5. I-SID Filtering
B.6. Rate-Limit B.6. Rate-Limit
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
[RFC8519] defines Access Control Lists (ACLs) as a user-ordered set [RFC8519] defines Access Control Lists (ACLs) as a user-ordered set
of filtering rules. The model targets the configuration of the of filtering rules. The model targets the configuration of the
filtering behavior of a device. However, the model structure, as filtering behavior of a device. However, the model structure, as
defined in [RFC8519], suffers from a set of limitations. This defined in [RFC8519], suffers from a set of limitations. This
skipping to change at line 155 skipping to change at line 155
[RFC8956]. Therefore, it is valuable from a network operation [RFC8956]. Therefore, it is valuable from a network operation
standpoint to support the means to easily map to the filtering rules standpoint to support the means to easily map to the filtering rules
conveyed in messages triggered by these tools. conveyed in messages triggered by these tools.
The enhanced ACL module (Section 4) conforms to the Network The enhanced ACL module (Section 4) conforms to the Network
Management Datastore Architecture (NMDA) defined in [RFC8342]. Management Datastore Architecture (NMDA) defined in [RFC8342].
A set of examples to illustrate the use of the enhanced ACL module is A set of examples to illustrate the use of the enhanced ACL module is
provided in Appendix B. provided in Appendix B.
This document also defines IANA-maintained modules for ICMP types and This document also defines initial versions of IANA-maintained
IPv6 extension headers. The design of the modules adheres to the modules for ICMP types and IPv6 extension headers. The design of the
recommendations in Section 4.30.2 of [YANG-GUIDELINES]. The latest modules adheres to the recommendations in Section 4.30.2 of
version of these IANA-maintained modules can be retrieved from the [YANG-GUIDELINES]. The latest version of these IANA-maintained
"YANG Parameters" registry group [IANA-YANG-PARAMETERS]. modules can be retrieved from the "YANG Parameters" registry group
[IANA-YANG-PARAMETERS].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The terminology for describing YANG modules is defined in [RFC7950]. The terminology for describing YANG modules is defined in [RFC7950].
skipping to change at line 389 skipping to change at line 390
transport protocol entries (e.g., TCP and UDP). transport protocol entries (e.g., TCP and UDP).
A port number can be a port range or a single port number along A port number can be a port range or a single port number along
with an operator (equal to, greater than or equal to, etc.). with an operator (equal to, greater than or equal to, etc.).
Protocol sets: A protocol set contains a list of protocol values. A Protocol sets: A protocol set contains a list of protocol values. A
protocol can be identified by either a number (e.g., 17) or a name protocol can be identified by either a number (e.g., 17) or a name
(e.g., UDP). (e.g., UDP).
ICMP sets: An ICMP set contains a list of ICMPv4 [RFC0792] or ICMPv6 ICMP sets: An ICMP set contains a list of ICMPv4 [RFC0792] or ICMPv6
[RFC4443] types, each of them identified by a type value, [RFC4443] types, and each type is identified by a type value and
optionally the code and the rest of the header. is optionally identified by the code and the rest of the header.
IANA-maintained modules for ICMP types are defined in this IANA-maintained modules for ICMP types are defined in this
document. document.
Aliases: An alias is defined by a combination of various parameters Aliases: An alias is defined by a combination of various parameters
(e.g., IP prefix, protocol, port number, or VLAN [IEEE802.1Qcp]). (e.g., IP prefix, protocol, port number, or VLAN [IEEE802.1Qcp]).
When only sets of one parameter (e.g., protocol) are handled, then When only sets of one parameter (e.g., protocol) are handled, then
the relevant parameter sets should be used (e.g., protocol set) the relevant parameter sets should be used (e.g., protocol set)
rather than an alias. rather than an alias.
skipping to change at line 527 skipping to change at line 528
In order to support rate-limiting (see Appendix A.6), a new action In order to support rate-limiting (see Appendix A.6), a new action
called 'rate-limit' is defined in this document. called 'rate-limit' is defined in this document.
Also, the "ietf-acl-enh" module supports new actions to complement Also, the "ietf-acl-enh" module supports new actions to complement
existing ones: log ('log-action') and write a counter ('counter- existing ones: log ('log-action') and write a counter ('counter-
action'). The version of the module defined in this document action'). The version of the module defined in this document
supports only local actions. supports only local actions.
4. Enhanced ACL YANG Module 4. Enhanced ACL YANG Module
This Yang module imports types from [RFC6991], [RFC8519], and This YANG module imports types from [RFC6991], [RFC8519], and
[RFC8294]. [RFC8294].
<CODE BEGINS> file "ietf-acl-enh@2025-11-07.yang" <CODE BEGINS> file "ietf-acl-enh@2025-11-07.yang"
module ietf-acl-enh { module ietf-acl-enh {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-acl-enh"; namespace "urn:ietf:params:xml:ns:yang:ietf-acl-enh";
prefix acl-enh; prefix acl-enh;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
skipping to change at line 566 skipping to change at line 567
Control Lists (ACLs), Section 4.2"; Control Lists (ACLs), Section 4.2";
} }
import ietf-routing-types { import ietf-routing-types {
prefix rt-types; prefix rt-types;
reference reference
"RFC 8294: Common YANG Data Types for the Routing Area"; "RFC 8294: Common YANG Data Types for the Routing Area";
} }
import iana-icmpv4-types { import iana-icmpv4-types {
prefix iana-icmpv4-types; prefix iana-icmpv4-types;
reference reference
"RFC 9899: Extensions to the Access Control Lists (ACLs) "RFC 9899: Extensions to the YANG Data Model for Access
YANG Model"; Control Lists (ACLs)";
} }
import iana-icmpv6-types { import iana-icmpv6-types {
prefix iana-icmpv6-types; prefix iana-icmpv6-types;
reference reference
"RFC 9899: Extensions to the Access Control Lists (ACLs) "RFC 9899: Extensions to the YANG Data Model for Access
YANG Model"; Control Lists (ACLs)";
} }
import iana-ipv6-ext-types { import iana-ipv6-ext-types {
prefix iana-ipv6-ext-types; prefix iana-ipv6-ext-types;
reference reference
"RFC 9899: Extensions to the Access Control Lists (ACLs) "RFC 9899: Extensions to the YANG Data Model for Access
YANG Model"; Control Lists (ACLs)";
} }
organization organization
"IETF NETMOD Working Group"; "IETF NETMOD Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/> "WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
Author: Mohamed Boucadair Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
skipping to change at line 615 skipping to change at line 616
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9899; see the This version of this YANG module is part of RFC 9899; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2025-11-07 { revision 2025-11-07 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 9899: Extensions to the Access Control Lists (ACLs) "RFC 9899: Extensions to the YANG Data Model for Access
YANG Model"; Control Lists (ACLs)";
} }
feature match-on-payload { feature match-on-payload {
description description
"Match based on a pattern is supported."; "Match based on a pattern is supported.";
} }
feature match-on-vlan-filter { feature match-on-vlan-filter {
description description
"Match based on a VLAN range of a VLAN list is supported."; "Match based on a VLAN range is supported.";
} }
feature match-on-isid-filter { feature match-on-isid-filter {
description description
"Match based on an I-SID range of a VLAN list is supported."; "Match based on an I-SID range is supported.";
} }
feature match-on-alias { feature match-on-alias {
description description
"Match based on aliases."; "Match based on aliases.";
} }
feature match-on-mpls { feature match-on-mpls {
description description
"Match based on MPLS headers."; "Match based on MPLS headers.";
skipping to change at line 970 skipping to change at line 971
and byte 14 of the TCP header. and byte 14 of the TCP header.
For clarity, the 4 bits of byte 12 For clarity, the 4 bits of byte 12
corresponding to the TCP data offset field are not corresponding to the TCP data offset field are not
included in any matching. Assigned TCP flags included in any matching. Assigned TCP flags
and their position are maintained in the IANA and their position are maintained in the IANA
'Transmission Control Protocol (TCP) Parameters' 'Transmission Control Protocol (TCP) Parameters'
registry group."; registry group.";
reference reference
"RFC 9293: Transmission Control Protocol (TCP), "RFC 9293: Transmission Control Protocol (TCP),
Section 3.1 Section 3.1
IANA: Transmission Control Protocol (TCP) Parameters,
<https://www.iana.org/assignments/tcp-parameters>"; <https://www.iana.org/assignments/tcp-parameters>";
} }
} }
} }
} }
grouping fragment-fields { grouping fragment-fields {
description description
"Operations on fragment types."; "Operations on fragment types.";
leaf operator { leaf operator {
skipping to change at line 1017 skipping to change at line 1019
description description
"Position of the label."; "Position of the label.";
} }
leaf upper-label-range { leaf upper-label-range {
type rt-types:mpls-label; type rt-types:mpls-label;
description description
"Match MPLS label value on the MPLS header. "Match MPLS label value on the MPLS header.
The usage of this field indicates the upper The usage of this field indicates the upper
range value in the top of the stack. This range value in the top of the stack. This
label value does not include the encodings label value does not include the encodings
of Traffic Class and TTL."; of TC and Time-to-Live (TTL).";
reference reference
"RFC 3032: MPLS Label Stack Encoding"; "RFC 3032: MPLS Label Stack Encoding";
} }
leaf lower-label-range { leaf lower-label-range {
type rt-types:mpls-label; type rt-types:mpls-label;
description description
"Match MPLS label value on the MPLS header. "Match MPLS label value on the MPLS header.
The usage of this field indicates the lower The usage of this field indicates the lower
range value in the top of the stack. range value in the top of the stack.
This label value does not include the This label value does not include the
encodings of Traffic Class and TTL."; encodings of TC and TTL.";
reference reference
"RFC 3032: MPLS Label Stack Encoding"; "RFC 3032: MPLS Label Stack Encoding";
} }
leaf label-block-name { leaf label-block-name {
type string; type string;
description description
"Reference to a label block predefined in the "Reference to a label block predefined in the
implementation."; implementation.";
} }
leaf ttl-value { leaf ttl-value {
type uint8; type uint8;
description description
"Time-to-live MPLS packet value match."; "TTL MPLS packet value match.";
reference reference
"RFC 3032: MPLS Label Stack Encoding"; "RFC 3032: MPLS Label Stack Encoding";
} }
} }
grouping payload-match { grouping payload-match {
description description
"Operations on payload match."; "Operations on payload match.";
leaf offset { leaf offset {
type identityref { type identityref {
skipping to change at line 1780 skipping to change at line 1782
} }
<CODE ENDS> <CODE ENDS>
5. Security Considerations 5. Security Considerations
This section is modeled after the template described in Section 3.7.1 This section is modeled after the template described in Section 3.7.1
of [YANG-GUIDELINES]. of [YANG-GUIDELINES].
The "ietf-acl-enh" YANG module defines a data model that is designed The "ietf-acl-enh" YANG module defines a data model that is designed
to be accessed via YANG-based management protocols, such as NETCONF to be accessed via YANG-based management protocols, such as NETCONF
[RFC6241] and RESTCONF [RFC8040]. These protocols have to use a [RFC6241] and RESTCONF [RFC8040]. These YANG-based management
secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC protocols (1) have to use a secure transport layer (e.g., SSH
[RFC9000]) and have to use mutual authentication. [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use
mutual authentication.
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., "config true", which is the writable/creatable/deletable (i.e., "config true", which is the
default). All writable data nodes are likely to be reasonably default). All writable data nodes are likely to be reasonably
sensitive or vulnerable in some network environments. Write sensitive or vulnerable in some network environments. Write
skipping to change at line 1824 skipping to change at line 1827
'defined-sets': Unauthorized read access of these lists will allow 'defined-sets': Unauthorized read access of these lists will allow
an attacker to identify the actual resources that are bound to an attacker to identify the actual resources that are bound to
ACLs. Likewise, access to this information will help an attacker ACLs. Likewise, access to this information will help an attacker
to better scope its attacks to target resources that are specific to better scope its attacks to target resources that are specific
to a given network instead of performing random scans. Also, to a given network instead of performing random scans. Also,
disclosing some of this information (e.g., IP addresses of core disclosing some of this information (e.g., IP addresses of core
routers) may nullify the effect of topology-hiding strategies in routers) may nullify the effect of topology-hiding strategies in
some networks. some networks.
There are no particularly sensitive RPC or action operations.
The document defines a match policy based on a pattern that can be The document defines a match policy based on a pattern that can be
observed in a packet. For example, such a policy can be combined observed in a packet. For example, such a policy can be combined
with header-based matches in the context of DDoS mitigation. with header-based matches in the context of DDoS mitigation.
Filtering based on a pattern match is deterministic for packets with Filtering based on a pattern match is deterministic for packets with
unencrypted data. However, the efficiency for encrypted packets unencrypted data. However, the efficiency for encrypted packets
depends on the presence of an unvarying pattern. Readers may also depends on the presence of an unvarying pattern. Readers may also
refer to Section 11 of [RFC8329] for security considerations related refer to Section 11 of [RFC8329] for security considerations related
to Network Security Functions (NSFs) that apply packet content to Network Security Functions (NSFs) that apply packet content
matching. matching.
The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and "iana- The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and "iana-
ipv6-ext-types" define a set of identities, types, and groupings. ipv6-ext-types" define a set of types. These nodes are intended to
These nodes are intended to be reused by other YANG modules. Each be reused by other YANG modules. Each module by itself does not
module by itself does not expose any data nodes that are writable, expose any data nodes that are writable, data nodes that contain
data nodes that contain read-only state, or RPCs. As such, there are read-only state, or RPCs. As such, there are no additional security
no additional security issues related to these YANG modules that need issues related to these YANG modules that need to be considered.
to be considered.
6. IANA Considerations 6. IANA Considerations
6.1. URI Registrations 6.1. URI Registrations
IANA has registered the following URIs in the "ns" registry within IANA has registered the following URIs in the "ns" registry within
the "IETF XML Registry" [RFC3688]: the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-acl-enh URI: urn:ietf:params:xml:ns:yang:ietf-acl-enh
Registrant Contact: The IESG Registrant Contact: The IESG
skipping to change at line 1868 skipping to change at line 1872
Registrant Contact: The IESG Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types URI: urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types
Registrant Contact: The IESG Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
6.2. YANG Module Name Registrations 6.2. YANG Module Name Registrations
IANA has registered the following YANG modules in the "YANG Module IANA has registered the following YANG modules in the "YANG Module
Names" registry [RFC6020] within the "YANG Parameters" registry Names" registry [RFC6020] [RFC9890] within the "YANG Parameters"
group. registry group.
Name: ietf-acl-enh Name: ietf-acl-enh
Maintained by IANA: N Maintained by IANA: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-acl-enh Namespace: urn:ietf:params:xml:ns:yang:ietf-acl-enh
Prefix: acl-enh Prefix: acl-enh
Reference: RFC 9899 Reference: RFC 9899
Name: iana-icmpv4-types Name: iana-icmpv4-types
Maintained by IANA: Y Maintained by IANA: Y
Namespace: urn:ietf:params:xml:ns:yang:iana-icmpv4-types Namespace: urn:ietf:params:xml:ns:yang:iana-icmpv4-types
skipping to change at line 1916 skipping to change at line 1920
| New values must not be directly added to the "iana-icmpv4-types" | New values must not be directly added to the "iana-icmpv4-types"
| YANG module. They must instead be added to the "ICMP Type | YANG module. They must instead be added to the "ICMP Type
| Numbers" registry [IANA-ICMPv4]. | Numbers" registry [IANA-ICMPv4].
When a value is added to the "ICMP Type Numbers" registry, a new When a value is added to the "ICMP Type Numbers" registry, a new
"enum" statement must be added to the "iana-icmpv4-types" YANG "enum" statement must be added to the "iana-icmpv4-types" YANG
module. The "enum" statement, and substatements thereof, should be module. The "enum" statement, and substatements thereof, should be
defined as follows: defined as follows:
"enum": Replicates the name from the registry with all illegal "enum": Replicates the name from the registry with all illegal
characters (e.g., spaces) are striped. characters (e.g., spaces) stripped.
"value": Contains the decimal value of the IANA-assigned value. "value": Contains the decimal value of the IANA-assigned value.
"status": Included only if a registration has been deprecated or "status": Included only if a registration has been deprecated or
obsoleted. IANA "deprecated" maps to YANG status "deprecated", obsoleted. IANA "deprecated" maps to YANG status "deprecated",
and IANA "obsolete" maps to YANG status "obsolete". and IANA "obsolete" maps to YANG status "obsolete".
"description": Replicates the name from the registry. "description": Replicates the name from the registry.
"reference": Replicates the reference(s) from the registry with the "reference": Replicates the reference(s) from the registry with the
skipping to change at line 1963 skipping to change at line 1967
| New values must not be directly added to the "iana-icmpv6-types" | New values must not be directly added to the "iana-icmpv6-types"
| YANG module. They must instead be added to the "ICMPv6 "type" | YANG module. They must instead be added to the "ICMPv6 "type"
| Numbers" registry [IANA-ICMPv6]. | Numbers" registry [IANA-ICMPv6].
When a value is added to the "ICMPv6 "type" Numbers" registry, a new When a value is added to the "ICMPv6 "type" Numbers" registry, a new
"enum" statement must be added to the "iana-icmpv6-types" YANG "enum" statement must be added to the "iana-icmpv6-types" YANG
module. The "enum" statement, and substatements thereof, should be module. The "enum" statement, and substatements thereof, should be
defined as follows: defined as follows:
"enum": Replicates the name from the registry with all illegal "enum": Replicates the name from the registry with all illegal
characters (e.g., spaces) striped. characters (e.g., spaces) stripped.
"value": Contains the decimal value of the IANA-assigned value. "value": Contains the decimal value of the IANA-assigned value.
"status": Included only if a registration has been deprecated or "status": Included only if a registration has been deprecated or
obsoleted. IANA "deprecated" maps to YANG status "deprecated", obsoleted. IANA "deprecated" maps to YANG status "deprecated",
and IANA "obsolete" maps to YANG status "obsolete". and IANA "obsolete" maps to YANG status "obsolete".
"description": Replicates the name from the registry. "description": Replicates the name from the registry.
"reference": Replicates the reference(s) from the registry with the "reference": Replicates the reference(s) from the registry with the
skipping to change at line 2010 skipping to change at line 2014
| New values must not be directly added to the "iana-ipv6-ext-types" | New values must not be directly added to the "iana-ipv6-ext-types"
| YANG module. They must instead be added to the "IPv6 Extension | YANG module. They must instead be added to the "IPv6 Extension
| Header Types" registry [IANA-IPv6]. | Header Types" registry [IANA-IPv6].
When a value is added to the "IPv6 Extension Header Types" registry, When a value is added to the "IPv6 Extension Header Types" registry,
a new "enum" statement must be added to the "iana-ipv6-ext-types" a new "enum" statement must be added to the "iana-ipv6-ext-types"
YANG module. The "enum" statement, and substatements thereof, should YANG module. The "enum" statement, and substatements thereof, should
be defined as follows be defined as follows
"enum": Replicates the description from the registry with all spaces "enum": Replicates the description from the registry with all spaces
striped. stripped.
"value": Contains the decimal value of the IANA-assigned value. "value": Contains the decimal value of the IANA-assigned value.
"status": Included only if a registration has been deprecated or "status": Included only if a registration has been deprecated or
obsoleted. IANA "deprecated" maps to YANG status "deprecated", obsoleted. IANA "deprecated" maps to YANG status "deprecated",
and IANA "obsolete" maps to YANG status "obsolete". and IANA "obsolete" maps to YANG status "obsolete".
"description": Replicates the description from the registry. "description": Replicates the description from the registry.
"reference": Replicates the reference(s) from the registry with the "reference": Replicates the reference(s) from the registry with the
skipping to change at line 2209 skipping to change at line 2213
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
"Distributed Denial-of-Service Open Threat Signaling "Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification", RFC 9132, (DOTS) Signal Channel Specification", RFC 9132,
DOI 10.17487/RFC9132, September 2021, DOI 10.17487/RFC9132, September 2021,
<https://www.rfc-editor.org/info/rfc9132>. <https://www.rfc-editor.org/info/rfc9132>.
[RFC9890] Bierman, A., Boucadair, M., Ed., and Q. Wu, "An Update to
YANG Module Names Registration", RFC 9890,
DOI 10.17487/RFC9890, October 2025,
<https://www.rfc-editor.org/info/rfc9890>.
[YANG-GUIDELINES] [YANG-GUIDELINES]
Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
Authors and Reviewers of Documents Containing YANG Data Authors and Reviewers of Documents Containing YANG Data
Models", Work in Progress, Internet-Draft, draft-ietf- Models", Work in Progress, Internet-Draft, draft-ietf-
netmod-rfc8407bis-28, 5 June 2025, netmod-rfc8407bis-28, 5 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod- <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
rfc8407bis-28>. rfc8407bis-28>.
[YANG-XSLT] [YANG-XSLT]
"iana-yang", commit 3a6cb69, December 2021, "iana-yang", commit 3a6cb69, December 2021,
skipping to change at line 2378 skipping to change at line 2387
'flags' filtering clause in a packet will allow that packet to get 'flags' filtering clause in a packet will allow that packet to get
through (because it won't match the ACE). through (because it won't match the ACE).
Defining a new IPv4/IPv6 matching field called 'fragment' is thus Defining a new IPv4/IPv6 matching field called 'fragment' is thus
required to efficiently handle fragment-related filtering rules. required to efficiently handle fragment-related filtering rules.
A.5. Suboptimal TCP Flags Handling A.5. Suboptimal TCP Flags Handling
[RFC8519] supports including flags in the TCP match fields; however, [RFC8519] supports including flags in the TCP match fields; however,
that structure does not support matching operations as those that structure does not support matching operations as those
supported in BGP Flow Spec. Defining this field to be defined as a supported in BGP Flow Spec. Defining this field as a flag bitmask
flag bitmask together with a set of operations is meant to together with a set of operations is meant to efficiently handle TCP
efficiently handle TCP flags filtering rules. flags filtering rules.
A.6. Rate-Limit Action A.6. Rate-Limit Action
[RFC8519] specifies that forwarding actions can be 'accept' (i.e., [RFC8519] specifies that forwarding actions can be 'accept' (i.e.,
accept matching traffic), 'drop' (i.e., drop matching traffic without accept matching traffic), 'drop' (i.e., drop matching traffic without
sending any ICMP error message), or 'reject' (i.e., drop matching sending any ICMP error message), or 'reject' (i.e., drop matching
traffic and send an ICMP error message to the source). However, traffic and send an ICMP error message to the source). However,
there are situations where the matching traffic can be accepted, but there are situations where the matching traffic can be accepted, but
with a rate-limit policy. This capability is not supported by with a rate-limit policy. This capability is not supported by
[RFC8519]. [RFC8519].
skipping to change at line 2424 skipping to change at line 2433
* An ACL name can be used at both network and device levels. * An ACL name can be used at both network and device levels.
* An ACL content updated at the network level should imply a * An ACL content updated at the network level should imply a
transaction that updates the relevant content in all the nodes transaction that updates the relevant content in all the nodes
using this ACL. using this ACL.
* ACLs defined at the device level have a local meaning for the * ACLs defined at the device level have a local meaning for the
specific node. specific node.
* A device can be associated with a router, a VRF, a logical system, * A device can be associated with a router, a Virtual Routing and
or a virtual node. ACLs can be applied in physical and logical Forwarding (VRF), a logical system, or a virtual node. ACLs can
infrastructure. be applied in physical and logical infrastructure.
A.9. Match MPLS Headers A.9. Match MPLS Headers
The ACLs can be used to create rules to match MPLS fields on a The ACLs can be used to create rules to match MPLS fields on a
packet. [RFC8519] does not support such function. packet. [RFC8519] does not support such function.
Appendix B. Examples Appendix B. Examples
This section provides a few examples to illustrate the use of the This section provides a few examples to illustrate the use of the
enhanced ACL module ("ietf-acl-enh"). enhanced ACL module ("ietf-acl-enh").
skipping to change at line 2676 skipping to change at line 2685
} }
] ]
} }
} }
] ]
} }
} }
Figure 8: Example of VLAN Filter (Message Body) Figure 8: Example of VLAN Filter (Message Body)
B.5. ISID Filtering B.5. I-SID Filtering
Figure 9 shows an ACL example to illustrate the ISID range filtering. Figure 9 shows an ACL example to illustrate the I-SID range
filtering.
{ {
"ietf-access-control-list:acls": { "ietf-access-control-list:acls": {
"acl": [ "acl": [
{ {
"name": "test", "name": "test",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"name": "1", "name": "1",
skipping to change at line 2706 skipping to change at line 2716
"forwarding": "ietf-access-control-list:accept" "forwarding": "ietf-access-control-list:accept"
} }
} }
] ]
} }
} }
] ]
} }
} }
Figure 9: Example ISID Filter (Message Body) Figure 9: Example I-SID Filter (Message Body)
B.6. Rate-Limit B.6. Rate-Limit
Figure 10 shows an ACL example to rate-limit incoming SYNs during a Figure 10 shows an ACL example to rate-limit incoming SYNs during a
SYN flood attack. SYN flood attack.
{ {
"ietf-access-control-list:acls": { "ietf-access-control-list:acls": {
"acl": [ "acl": [
{ {
 End of changes. 29 change blocks. 
48 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.48.