Diff: rfc9899v1.txt - rfc9899.txt

	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	The document also defines initial versions of IANA-maintained modules
	IPv6 extension headers.	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 1824 ¶	skipping to change at line 1826 ¶

	'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 1871 ¶
	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 2209 ¶	skipping to change at line 2212 ¶
	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 2386 ¶
	'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 2432 ¶

	* 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 2684 ¶
	}	}
	]	]
	}	}
	}	}
	]	]
	}	}
	}	}

	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 2715 ¶
	"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. 22 change blocks.
	39 lines changed or deleted	48 lines changed or added
This html diff was produced by rfcdiff 1.48.