rfc9899.original.xml   rfc9899.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.27 (Ruby 3.3. -ietf-netmod-acl-extensions-17" number="9899" updates="" obsoletes="" xml:lang="
6) --> en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sort
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft Refs="true" symRefs="true" version="3">
-ietf-netmod-acl-extensions-17" category="std" consensus="true" submissionType="
IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- [rfced] May we update the title of this document as follows? We
<!-- xml2rfc v2v3 conversion 3.28.1 --> have received guidance from Benoit Claise and the YANG Doctors
that "YANG module" and "YANG data model" are preferred, and our
suggested text more closely matches the title of RFC 8519.
Note that if the document title is updated, we will also update the
references to this document within the YANG module (Section 4).
Original:
Extensions to the Access Control Lists (ACLs) YANG Model
Perhaps:
Extensions to the YANG Data Model for Access Control Lists (ACLs)
-->
<front> <front>
<title abbrev="Enhanced ACLs">Extensions to the Access Control Lists (ACLs) YANG Model</title> <title abbrev="Enhanced ACLs">Extensions to the Access Control Lists (ACLs) YANG Model</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-acl-extensions-17 <seriesInfo name="RFC" value="9899"/>
"/> <author fullname="Oscar Gonzalez de Dios" initials="O" surname="Gonzalez de
<author fullname="Oscar Gonzalez de Dios"> Dios">
<organization>Telefonica</organization> <organization>Telefonica</organization>
<address> <address>
<email>oscar.gonzalezdedios@telefonica.com</email> <email>oscar.gonzalezdedios@telefonica.com</email>
</address> </address>
</author> </author>
<author fullname="Samier Barguil"> <author fullname="Samier Barguil" initials="S" surname="Barguil">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>samier.barguil_giraldo@nokia.com</email> <email>samier.barguil_giraldo@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Mohamed Boucadair"> <author fullname="Mohamed Boucadair" initials="M" surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Qin Wu"> <author fullname="Qin Wu" initials="Q" surname="Wu">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<email>bill.wu@huawei.com</email> <email>bill.wu@huawei.com</email>
</address> </address>
</author> </author>
<date year="2025" month="April" day="04"/> <date year="2025" month="November"/>
<area>Operations and Management</area> <area>OPS</area>
<workgroup>netmod</workgroup> <workgroup>netmod</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 92?>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<abstract>
<t>RFC 8519 defines a YANG data model for Access Control Lists <t>RFC 8519 defines a YANG data model for Access Control Lists
(ACLs). This document specifies a set of extensions that fix many of (ACLs). This document specifies a set of extensions that fix many of
the limitations of the ACL model as initially defined in RFC 8519. the limitations of the ACL model as initially defined in RFC 8519.
Specifically, it introduces augmentations to the ACL base model to enhance its f unctionality and applicability.</t> Specifically, it introduces augmentations to the ACL base model to enhance its f unctionality and applicability.</t>
<t>The document also defines IANA-maintained modules for ICMP types and IP v6 extension headers.</t> <t>The document also defines IANA-maintained modules for ICMP types and IP v6 extension headers.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
Network Modeling Working Group mailing list (netmod@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/
netmod/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/boucadair/enhanced-acl-netmod"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 101?> <?line 101?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t><xref target="RFC8519"/> defines Access Control Lists (ACLs) as a <t><xref target="RFC8519"/> defines Access Control Lists (ACLs) as a
user-ordered set of filtering rules. The model targets the user-ordered set of filtering rules. The model targets the
configuration of the filtering behavior of a device. However, the configuration of the filtering behavior of a device. However, the
model structure, as defined in <xref target="RFC8519"/>, suffers from a set of l imitations. model structure, as defined in <xref target="RFC8519"/>, suffers from a set of l imitations.
This document identifies these limitations and specifies an enhanced ACL structu re, This document identifies these limitations and specifies an enhanced ACL structu re,
introducing augmentations to the ACL base model (<xref target="sec-module"/>). introducing augmentations to the ACL base model (<xref target="sec-module"/>).
The motivation of such enhanced ACL structure is discussed in detail in <xref ta rget="ps"/>.</t> The motivation of such an enhanced ACL structure is discussed in detail in <xref target="ps"/>.</t>
<t>When managing ACLs, it is common for network operators to group <t>When managing ACLs, it is common for network operators to group
match elements in pre-defined sets. The consolidation into group matches match elements in predefined sets. The consolidation into group matches
allows for reducing the number of rules, especially in large scale allows for reducing the number of rules, especially in large-scale
networks. If, for example, it is needed to find a match against 100 networks. For example, if finding a match against 100
IP addresses (or prefixes), a single rule will suffice rather than creating IP addresses (or prefixes) is needed, a single rule will suffice rather than cre
ating
individual Access Control Entries (ACEs) for each IP address (or prefix). In individual Access Control Entries (ACEs) for each IP address (or prefix). In
doing so, implementations would optimize the performance of matching doing so, implementations would optimize the performance of matching
lists vs multiple rules matching.</t> lists versus multiple rules matching.</t>
<t>The enhanced ACL structure ("ietf-acl-enh", <xref target="sec-module"/> <t>The enhanced ACL structure (see "ietf-acl-enh" in <xref target="sec-mod
) is also meant to facilitate the management of ule"/>) is also meant to facilitate the management of
network operators. Instead of entering the IP address or port number network operators. Instead of entering the IP address or port number
literals, using user-named lists decouples the creation of the rule literals, using user-named lists decouples the creation of the rule
from the management of the sets. Hence, it is possible to remove/add from the management of the sets. Hence, it is possible to remove/add
entries to the list without redefining the (parent) ACL rule.</t> entries to the list without redefining the (parent) ACL rule.</t>
<t>In addition, the notion of ACL and defined sets <t>In addition, the notion of ACL and defined sets
is generalized so that it is not device-specific as per <xref target="RFC8519"/> is generalized so that it is not device specific as per <xref target="RFC8519"/>
. ACLs . ACLs
and defined sets may be defined at network/administrative domain level and defined sets may be defined at the network/administrative domain level
and associated to devices. This approach facilitates the reusability across mult iple and associated to devices. This approach facilitates the reusability across mult iple
network elements. For example, managing the IP prefix sets from a network network elements. For example, managing the IP prefix sets from a network
level makes it easier to maintain by the security groups.</t> level makes it easier to maintain by the security groups.</t>
<t>Network operators maintain sets of IP prefixes that are related to each other, <t>Network operators maintain sets of IP prefixes that are related to each other,
e.g., deny-lists or accept-lists that are associated with those provided by a e.g., deny-lists or accept-lists that are associated with those provided by a
VPN customer. These lists are maintained and manipulated by security expert tea ms of the network operators.</t> VPN customer. These lists are maintained and manipulated by security expert tea ms of the network operators.</t>
<t>Note that ACLs are used locally in devices but are triggered by other <t>Note that ACLs are used locally in devices but are triggered by other
tools such as DDoS mitigation <xref target="RFC9132"/> or BGP Flow Spec <xref ta tools such as DDoS mitigation <xref target="RFC9132"/> or BGP Flow Spec
rget="RFC8955"/> <xref target="RFC8955"/> <xref target="RFC8956"/>. Therefore, it is
<xref target="RFC8956"/>. Therefore, it is valuable from a network opera valuable from a network operation standpoint to support the means to
tion standpoint to support means to easily map to the filtering rules conveyed i easily map to the filtering rules conveyed in messages triggered by
n these tools.</t>
messages triggered by these tools.</t>
<t>The enhanced ACL module (<xref target="sec-module"/>) conforms to the N etwork <t>The enhanced ACL module (<xref target="sec-module"/>) conforms to the N etwork
Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t > Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t >
<t>A set of examples to illustrate the use of the enhanced ACL module are <t>A set of examples to illustrate the use of the enhanced ACL module is p
provided in <xref target="sec-examples"/>.</t> rovided in <xref target="sec-examples"/>.</t>
<t>The document also defines IANA-maintained modules for ICMP types and IP <t>This document also defines IANA-maintained modules for ICMP types and I
v6 extension headers. The design of the modules adheres to the recommendations i Pv6 extension headers. The design of the modules adheres to the recommendations
n <xref section="4.30.2" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/ in <xref section="4.30.2" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"
>. Readers should refer to the IANA websites <xref target="IANA_ICMPv4_YANG_URL" />. The latest version of these IANA-maintained modules can
/>, <xref target="IANA_ICMPv6_YANG_URL"/>, and <xref target="IANA_IPV6_YANG_URL" be retrieved from the "YANG Parameters" registry group <xref target="IANA-YAN
/> to retrieve the latest version of these IANA-maintained modules.</t> G-PARAMETERS"/>.</t>
<section anchor="editorial-note-to-be-removed-by-rfc-editor"> </section>
<name>Editorial Note (To be removed by RFC Editor)</name>
<t>Note to the RFC Editor: This section is to be removed prior to public
ation.</t>
<t>This document contains placeholder values that need to be replaced wi
th finalized values at the time of publication. This note summarizes all of the
substitutions that are needed.</t>
<t>(1) Please apply the following replacements:</t>
<ul spacing="normal">
<li>
<t>XXXX --&gt; the assigned RFC number for this I-D</t>
</li>
<li>
<t>2024-05-16 --&gt; the actual date of the publication of this docu
ment</t>
</li>
</ul>
<t>(2) The modules are provided in <xref target="iana-icmp"/>, <xref tar
get="iana-icmpv6"/>, and <xref target="iana-ipv6-ext"/> for the users convenienc
e before publication as RFC. Please remove these appendices from the final RFC.<
/t>
<t>(3) Please update the following references:</t>
<ul spacing="normal">
<li>
<t>IANA_ICMPv4_YANG_URL --&gt; The URL to retrieve the latest versio
n of the IANA-maintained ICMPv4 module.</t>
</li>
<li>
<t>IANA_ICMPv6_YANG_URL --&gt; The URL to retrieve the latest versio
n of the IANA-maintained ICMPv6 module.</t>
</li>
<li>
<t>IANA_IPV6_YANG_URL --&gt; The URL to retrieve the latest version
of the IPv6 Extension Header Types IANA module.</t>
</li>
</ul>
</section>
</section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<t>The terminology for describing YANG modules is defined in <xref target="RFC79 50"/>. <t>The terminology for describing YANG modules is defined in <xref target="RFC79 50"/>.
The meaning of the symbols in the tree diagrams is defined in The meaning of the symbols in the tree diagrams is defined in
<xref target="RFC8340"/>.</t> <xref target="RFC8340"/>.</t>
<t>In addition to the terms defined in <xref target="RFC8519"/>, this docu ment makes use of the following term:</t> <t>In addition to the terms defined in <xref target="RFC8519"/>, this docu ment makes use of the following term:</t>
<dl> <dl>
<dt>Defined set:</dt> <dt>Defined set:</dt>
<dd> <dd>
<t>Elements in a defined set typically share a logical purpose or func tion, such as IP addresses, IP prefixes, port numbers, or ICMP types.</t> <t>Elements in a defined set typically share a logical purpose or func tion, such as IP addresses, IP prefixes, port numbers, or ICMP types.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="overall-structure-of-the-enhanced-acl-module"> <section anchor="overall-structure-of-the-enhanced-acl-module">
<name>Overall Structure of the Enhanced ACL Module</name> <name>Overall Structure of the Enhanced ACL Module</name>
<section anchor="tree-structure"> <section anchor="tree-structure">
<name>Tree Structure</name> <name>Tree Structure</name>
<t><xref target="enh-acl-tree"/> shows the full tree of the enhanced ACL module (<xref target="sec-module"/>):</t> <t><xref target="enh-acl-tree"/> shows the full tree of the enhanced ACL module (<xref target="sec-module"/>):</t>
<figure anchor="enh-acl-tree"> <figure anchor="enh-acl-tree">
<name>Enhanced ACL Tree Structure</name> <name>Enhanced ACL Tree Structure</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-acl-enh module: ietf-acl-enh
augment /acl:acls: augment /acl:acls:
+--rw defined-sets +--rw defined-sets
+---u defined-sets +---u defined-sets
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches:
+--rw (payload)? +--rw (payload)?
| +--:(pattern) | +--:(pattern)
| +--rw pattern {match-on-payload}? | +--rw pattern {match-on-payload}?
| +---u payload-match | +---u payload-match
skipping to change at line 227 skipping to change at line 215
/acl:udp/acl:udp: /acl:udp/acl:udp:
+--rw source-udp-port-set? port-set-ref +--rw source-udp-port-set? port-set-ref
+--rw destination-udp-port-set? port-set-ref +--rw destination-udp-port-set? port-set-ref
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l4 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l4
/acl:icmp/acl:icmp: /acl:icmp/acl:icmp:
+--rw icmpv4-set? icmpv4-type-set-ref +--rw icmpv4-set? icmpv4-type-set-ref
+--rw icmpv6-set? icmpv6-type-set-ref +--rw icmpv6-set? icmpv6-type-set-ref
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions: augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions:
+---u acl-complementary-actions +---u acl-complementary-actions
+--rw rate-limit? decimal64 +--rw rate-limit? decimal64
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="enh-acl-grp"/> shows the reusable groupings that are de fined in the enhanced ACL module:</t> <t><xref target="enh-acl-grp"/> shows the reusable groupings that are de fined in the enhanced ACL module:</t>
<figure anchor="enh-acl-grp"> <figure anchor="enh-acl-grp">
<name>Enhanced ACL Groupings</name> <name>Enhanced ACL Groupings</name>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
grouping tcp-flags: grouping tcp-flags:
+--rw operator? operator +--rw operator? operator
+-- (mode)? +-- (mode)?
+--:(explicit) +--:(explicit)
| +-- explicit-tcp-flag* identityref | +-- explicit-tcp-flag* identityref
+--:(builtin) +--:(builtin)
+-- bitmask? uint16 +-- bitmask? uint16
grouping fragment-fields: grouping fragment-fields:
+-- operator? operator +-- operator? operator
+-- type? fragment-type +-- type? fragment-type
skipping to change at line 331 skipping to change at line 319
+-- port-sets +-- port-sets
| +---u port-sets | +---u port-sets
+-- protocol-sets +-- protocol-sets
| +---u protocol-sets | +---u protocol-sets
+-- icmpv4-type-sets +-- icmpv4-type-sets
| +---u icmpv4-type-sets | +---u icmpv4-type-sets
+-- icmpv6-type-sets +-- icmpv6-type-sets
| +---u icmpv6-type-sets | +---u icmpv6-type-sets
+-- aliases +-- aliases
+---u aliases +---u aliases
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="defined-sets"> <section anchor="defined-sets">
<name>Defined Sets</name> <name>Defined Sets</name>
<t>The augmented ACL structure includes several containers to manage reu sable sets of elements that can be matched in an ACL entry. <t>The augmented ACL structure includes several containers to manage reu sable sets of elements that can be matched in an ACL entry.
Each set is uniquely identified by a name and can be called from the relevant en try. The following sets are defined (<xref target="enh-acl-tree"/>):</t> Each set is uniquely identified by a name and can be called from the relevant en try. The following sets (seen in <xref target="enh-acl-tree"/>) are defined:</t>
<dl> <dl>
<dt>IPv4 prefix sets:</dt> <dt>IPv4 prefix sets:</dt>
<dd> <dd>
<t>An IPv4 prefix set contains a list of IPv4 prefixes. A match will be considered if the IP address (source or destination, depending on the ACL en try) is contained in any of the prefixes in the set.</t> <t>An IPv4 prefix set contains a list of IPv4 prefixes. A match will be considered if the IP address (source or destination, depending on the ACL en try) is contained in any of the prefixes in the set.</t>
</dd> </dd>
<dt>IPv6 prefix sets:</dt> <dt>IPv6 prefix sets:</dt>
<dd> <dd>
<t>An IPv6 prefix contains a list of IPv6 prefixes. A match will be considered if the IP address (source or destination, depending on the ACL entry) is contained in any of the prefixes in the set.</t> <t>An IPv6 prefix contains a list of IPv6 prefixes. A match will be considered if the IP address (source or destination, depending on the ACL entry) is contained in any of the prefixes in the set.</t>
</dd> </dd>
<dt>Port sets:</dt> <dt>Port sets:</dt>
<dd> <dd>
<t>A port set contains a list of port numbers to be used in transpor t protocol entries (e.g., TCP and UDP).</t> <t>A port set contains a list of port numbers to be used in transpor t protocol entries (e.g., TCP and UDP).</t>
</dd>
<dt/>
<dd>
<t>A port number can be a port range or a single port number along w ith an operator (equal to, greater than or equal to, etc.).</t> <t>A port number can be a port range or a single port number along w ith an operator (equal to, greater than or equal to, etc.).</t>
</dd> </dd>
<dt>Protocol sets:</dt> <dt>Protocol sets:</dt>
<dd> <dd>
<t>A protocol set contains a list of protocol values. A protocol can be identified either by a number (e.g., 17) or a name (e.g., UDP).</t> <t>A protocol set contains a list of protocol values. A protocol can be identified by either a number (e.g., 17) or a name (e.g., UDP).</t>
</dd> </dd>
<!-- [rfced] Would option A or B below clarify how "optionally the
code and the rest of the header" relates to the rest of the
sentence?
Original:
ICMP sets: An ICMP set contains a list of ICMPv4 [RFC0792] or ICMPv6
[RFC4443] types, each of them identified by a type value,
optionally the code and the rest of the header.
Perhaps A:
ICMP sets: An ICMP set contains a list of ICMPv4 [RFC0792] or ICMPv6
[RFC4443] types, and each type is identified by a type value,
the code (optionally), and the rest of the header.
or
Perhaps B:
ICMP sets: An ICMP set contains a list of ICMPv4 [RFC0792] or ICMPv6
[RFC4443] types, and each type is identified by a type value and is
optionally identified by the code and the rest of the header.
-->
<dt>ICMP sets:</dt> <dt>ICMP sets:</dt>
<dd> <dd>
<t>An ICMP set contains a list of ICMPv4 <xref target="RFC0792"/> or ICMPv6 <xref target="RFC4443"/> types, each of them identified by a type value, optionally the code and the rest of the header.</t> <t>An ICMP set contains a list of ICMPv4 <xref target="RFC0792"/> or ICMPv6 <xref target="RFC4443"/> types, each of them identified by a type value, optionally the code and the rest of the header.</t>
</dd>
<dt/>
<dd>
<t>IANA-maintained modules for ICMP types are defined in this docume nt.</t> <t>IANA-maintained modules for ICMP types are defined in this docume nt.</t>
</dd> </dd>
<dt>Aliases:</dt> <dt>Aliases:</dt>
<dd> <dd>
<t>An alias is defined by a combination of various parameters (e.g., IP prefix, protocol, port number, or VLAN <xref target="IEEE802.1Qcp"/>). When only sets of one parameter (e.g., protocol) are handled, then the relevant param eter sets should be used (e.g., protocol set) rather than an alias.</t> <t>An alias is defined by a combination of various parameters (e.g., IP prefix, protocol, port number, or VLAN <xref target="IEEE802.1Qcp"/>). When only sets of one parameter (e.g., protocol) are handled, then the relevant param eter sets should be used (e.g., protocol set) rather than an alias.</t>
</dd>
<dt/>
<dd>
<t>For example, an alias can be defined to apply ACL policies bound to a set of HTTPS servers. Such an alias will typically include these HTTPS serv er addresses (e.g., "prefix": ["2001:db8:6401::1/128","2001:db8:6401::2/128"]) a nd the TCP port number 443 (i.e., "protocol": [6] and "lower-port": 443).</t> <t>For example, an alias can be defined to apply ACL policies bound to a set of HTTPS servers. Such an alias will typically include these HTTPS serv er addresses (e.g., "prefix": ["2001:db8:6401::1/128","2001:db8:6401::2/128"]) a nd the TCP port number 443 (i.e., "protocol": [6] and "lower-port": 443).</t>
</dd>
<dt/>
<dd>
<t>Sets of aliases can be defined and referred to in ACL match crite ria.</t> <t>Sets of aliases can be defined and referred to in ACL match crite ria.</t>
</dd> </dd>
<dt>Payload-based filtering:</dt> <dt>Payload-based filtering:</dt>
<dd> <dd>
<t>Network traffic filtering technique that examines the data payloa d of packets, beyond just the header information, to identify, allow, or block t raffic based on specific content or patterns within the payload. An offset type (e.g., layer 2 or layer 3) is used to indicates the position of the data in pack et to use for the match.</t> <t>A network traffic filtering technique that examines the data payl oad of packets, beyond just the header information, to identify, allow, or block traffic based on specific content or patterns within the payload. An offset typ e (e.g., Layer 2 or Layer 3) is used to indicate the position of the data in the packet to use for the match.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="ipv6-extension-headers"> <section anchor="ipv6-extension-headers">
<name>IPv6 Extension Headers</name> <name>IPv6 Extension Headers</name>
<t>The enhanced ACL module can be used to manage ACLs that require match ing against IPv6 extension headers <xref target="RFC8200"/>. To that aim, a new IANA-maintained module for IPv6 extension header types "iana-ipv6-ext-types" is defined in this document.</t> <t>The enhanced ACL module can be used to manage ACLs that require match ing against IPv6 extension headers <xref target="RFC8200"/>. To that aim, a new IANA-maintained module for IPv6 extension header types, "iana-ipv6-ext-types", i s defined in this document.</t>
</section> </section>
<section anchor="tcp-flags-handling"> <section anchor="tcp-flags-handling">
<name>TCP Flags Handling</name> <name>TCP Flags Handling</name>
<t>The augmented ACL module includes a new container 'flags-bitmask' to better handle TCP flags (<xref section="3.1" sectionFormat="of" target="RFC9293" />). Assigned TCP flags are maintained in the "TCP Header Flags" registry under the "Transmission Control Protocol (TCP) Parameters" registry group <xref target ="IANA-TCP-FLAGS"/>.</t> <t>The augmented ACL module includes a new container 'flags-bitmask' to better handle TCP flags (<xref section="3.1" sectionFormat="of" target="RFC9293" />). Assigned TCP flags are maintained in the "TCP Header Flags" registry under the "Transmission Control Protocol (TCP) Parameters" registry group <xref target ="IANA-TCP-FLAGS"/>.</t>
<t>Clients that support both 'flags-bitmask' and 'flags' <xref target="R FC8519"/> matching fields <bcp14>MUST NOT</bcp14> set these fields in the same r equest.</t> <t>Clients that support both 'flags-bitmask' and 'flags' <xref target="R FC8519"/> matching fields <bcp14>MUST NOT</bcp14> set these fields in the same r equest.</t>
</section> </section>
<section anchor="fragments-handling"> <section anchor="fragments-handling">
<name>Fragments Handling</name> <name>Fragments Handling</name>
<t>The augmented ACL module includes new leafs 'ipv4-fragment' and 'ipv6 -fragment' to better handle fragments.</t> <t>The augmented ACL module includes new leafs 'ipv4-fragment' and 'ipv6 -fragment' to better handle fragments.</t>
<t>Clients that support both 'ipv4-fragment' and 'flags' <xref target="R FC8519"/> matching fields <bcp14>MUST NOT</bcp14> set these fields in the same r equest.</t> <t>Clients that support both 'ipv4-fragment' and 'flags' <xref target="R FC8519"/> matching fields <bcp14>MUST NOT</bcp14> set these fields in the same r equest.</t>
skipping to change at line 399 skipping to change at line 400
<section anchor="tcp-flags-handling"> <section anchor="tcp-flags-handling">
<name>TCP Flags Handling</name> <name>TCP Flags Handling</name>
<t>The augmented ACL module includes a new container 'flags-bitmask' to better handle TCP flags (<xref section="3.1" sectionFormat="of" target="RFC9293" />). Assigned TCP flags are maintained in the "TCP Header Flags" registry under the "Transmission Control Protocol (TCP) Parameters" registry group <xref target ="IANA-TCP-FLAGS"/>.</t> <t>The augmented ACL module includes a new container 'flags-bitmask' to better handle TCP flags (<xref section="3.1" sectionFormat="of" target="RFC9293" />). Assigned TCP flags are maintained in the "TCP Header Flags" registry under the "Transmission Control Protocol (TCP) Parameters" registry group <xref target ="IANA-TCP-FLAGS"/>.</t>
<t>Clients that support both 'flags-bitmask' and 'flags' <xref target="R FC8519"/> matching fields <bcp14>MUST NOT</bcp14> set these fields in the same r equest.</t> <t>Clients that support both 'flags-bitmask' and 'flags' <xref target="R FC8519"/> matching fields <bcp14>MUST NOT</bcp14> set these fields in the same r equest.</t>
</section> </section>
<section anchor="fragments-handling"> <section anchor="fragments-handling">
<name>Fragments Handling</name> <name>Fragments Handling</name>
<t>The augmented ACL module includes new leafs 'ipv4-fragment' and 'ipv6 -fragment' to better handle fragments.</t> <t>The augmented ACL module includes new leafs 'ipv4-fragment' and 'ipv6 -fragment' to better handle fragments.</t>
<t>Clients that support both 'ipv4-fragment' and 'flags' <xref target="R FC8519"/> matching fields <bcp14>MUST NOT</bcp14> set these fields in the same r equest.</t> <t>Clients that support both 'ipv4-fragment' and 'flags' <xref target="R FC8519"/> matching fields <bcp14>MUST NOT</bcp14> set these fields in the same r equest.</t>
</section> </section>
<section anchor="payload-based-filtering"> <section anchor="payload-based-filtering">
<name>Payload-based Filtering</name> <name>Payload-Based Filtering</name>
<t>Some transport protocols use existing protocols (e.g., TCP or UDP) as substrate. The match criteria for such protocols may rely upon the 'protocol' u nder 'l3', TCP/UDP match criteria, part of the TCP/UDP payload, or a combination thereof.</t> <t>Some transport protocols use existing protocols (e.g., TCP or UDP) as substrate. The match criteria for such protocols may rely upon the 'protocol' u nder 'l3', TCP/UDP match criteria, part of the TCP/UDP payload, or a combination thereof.</t>
<t>A new feature, called 'match-on-payload', is defined in the document. This can be used, for example, for QUIC <xref target="RFC9000"/> or for tunneli ng protocols. This feature requires configuring a data offset, a length, and a b inary pattern to match data against using a specified operator. The data offset indicates the position to look at in a packet (e.g., starts at the beginning of the IP header or transport header).</t> <t>A new feature, called 'match-on-payload', is defined in the document. This can be used, for example, for QUIC <xref target="RFC9000"/> or for tunneli ng protocols. This feature requires configuring a data offset, a length, and a b inary pattern to match data against using a specified operator. The data offset indicates the position to look at in a packet (e.g., it starts at the beginning of the IP header or transport header).</t>
</section> </section>
<section anchor="match-on-mpls-headers"> <section anchor="match-on-mpls-headers">
<name>Match on MPLS Headers</name> <name>Match on MPLS Headers</name>
<t>The enhanced ACL module (<xref target="sec-module"/>) can be used to create rules to match against MPLS fields of a packet. The MPLS header defined i n <xref target="RFC3032"/> and <xref target="RFC5462"/> contains the following f ields:</t> <t>The enhanced ACL module (<xref target="sec-module"/>) can be used to create rules to match against the MPLS fields of a packet. The MPLS header defin ed in <xref target="RFC3032"/> and <xref target="RFC5462"/> contains the followi ng fields:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Traffic Class: The 3-bit "Exp" field <xref target="RFC3032"/> whi ch is renamed to "Traffic Class field" ("TC field") <xref target="RFC5462"/>.</t > <t>Traffic Class: The 3-bit "Exp" field <xref target="RFC3032"/>, wh ich is renamed to "Traffic Class field" ("TC field") <xref target="RFC5462"/>.</ t>
</li> </li>
<li> <li>
<t>Label Value: A 20-bit field that carries the actual value of the MPLS label.</t> <t>Label Value: A 20-bit field that carries the actual value of the MPLS label.</t>
</li> </li>
<li> <li>
<t>TTL: A 8-bit field used to encode Time to Live (TTL) value.</t> <t>TTL: An 8-bit field used to encode the Time-to-Live (TTL) value.< /t>
</li> </li>
</ul> </ul>
<t>The augmented ACL module can be used by an operator to configure ACLs that match based upon the following data nodes:</t> <t>The augmented ACL module can be used by an operator to configure ACLs that match based upon the following data nodes:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>'traffic-class'</t> <t>'traffic-class'</t>
</li> </li>
<li> <li>
<t>'label-position' (e.g., top or bottom)</t> <t>'label-position' (e.g., top or bottom)</t>
</li> </li>
skipping to change at line 451 skipping to change at line 454
<name>VLAN Filtering</name> <name>VLAN Filtering</name>
<t>Being able to filter all packets that are bridged within a VLAN or th at <t>Being able to filter all packets that are bridged within a VLAN or th at
are routed into or out of a bridge domain is part of the VPN control are routed into or out of a bridge domain is part of the VPN control
requirements for Ethernet VPN (EVPN) <xref target="RFC7209"/>.</t> requirements for Ethernet VPN (EVPN) <xref target="RFC7209"/>.</t>
<t>All packets that are bridged within a VLAN or that are routed into or <t>All packets that are bridged within a VLAN or that are routed into or
out of a VLAN can be captured, forwarded, translated, or discarded based out of a VLAN can be captured, forwarded, translated, or discarded based
on the network policy.</t> on the network policy.</t>
</section> </section>
<section anchor="instance-service-identifier-i-sid-filtering"> <section anchor="instance-service-identifier-i-sid-filtering">
<name>Instance Service Identifier (I-SID) Filtering</name> <name>Instance Service Identifier (I-SID) Filtering</name>
<t>Provider backbone bridging (PBB) was originally defined as Virtual
Bridged Local Area Networks <xref target="IEEE-802-1ah"/> <t>Provider Backbone Bridging (PBB) was originally defined as a Virtual
standard. However, instead of multiplexing VLANs, PBB Bridged Local Area Networks standard <xref target="IEEE-802-1ah"/>.
duplicates the MAC layer of the customer frame and separates it from However, instead of multiplexing VLANs, PBB
the provider domain, by encapsulating it in a 24-bit instance service duplicates the Media Access Control (MAC) layer of the customer frame and separa
identifier (I-SID). This provides more transparency between the tes it from
the provider domain, by encapsulating it in a 24-bit Instance Service
Identifier (I-SID). This provides more transparency between the
customer network and the provider network.</t> customer network and the provider network.</t>
<t>The I-component forms the customer or access facing interface or <t>The I-component forms the customer- or access-facing interface or
routing instance. The I-component is responsible for mapping customer routing instance. The I-component is responsible for mapping customer
Ethernet traffic to the appropriate I-SID. It is Ethernet traffic to the appropriate I-SID. It is
mandatory to configure the default service identifier in the network.</t> mandatory to configure the default service identifier in the network.</t>
<t>Being able to filter by I-component Service identifier is a feature o
f <!-- [rfced] FYI - We have updated "EVNP-PBB" to "EVPN-PBB" in the text
the EVNP-PBB configuration.</t> below. Please review.
Original:
Being able to filter by I-component Service identifier is a feature
of the EVNP-PBB configuration.
Current:
Being able to filter by I-component service identifier is a feature
of the EVPN-PBB configuration.
-->
<t>Being able to filter by I-component service identifier is a feature o
f
the EVPN-PBB configuration.</t>
</section> </section>
<section anchor="additional-actions"> <section anchor="additional-actions">
<name>Additional Actions</name> <name>Additional Actions</name>
<t>In order to support rate-limiting (see <xref target="ps-rate"/>), a n ew action called 'rate-limit' is defined in this document.</t> <t>In order to support rate-limiting (see <xref target="ps-rate"/>), a n ew action called 'rate-limit' is defined in this document.</t>
<t>Also, the "ietf-acl-enh" module supports new actions to complement ex isting ones: Log ('log-action') and write a counter ('counter-action'). The vers ion of the module defined in this document supports only local actions.</t> <t>Also, the "ietf-acl-enh" module supports new actions to complement ex isting ones: log ('log-action') and write a counter ('counter-action'). The vers ion of the module defined in this document supports only local actions.</t>
</section> </section>
</section> </section>
<section anchor="sec-module"> <section anchor="sec-module">
<name>Enhanced ACL YANG Module</name> <name>Enhanced ACL YANG Module</name>
<t>This model imports types from <xref target="RFC6991"/>, <xref target="R
FC8519"/>, and <xref target="RFC8294"/>.</t> <!-- [rfced] Questions about Section 4
<sourcecode markers="true" name="ietf-acl-enh@2024-05-16.yang"><![CDATA[
a) The following sentence does not mention RFC 8341, but RFC 8341 is
referenced in the YANG module. May we update this sentence to include
RFC 8341 as well?
Original:
This model imports types from [RFC6991], [RFC8519], and [RFC8294].
Perhaps:
This Yang module imports types from [RFC6991], [RFC8341], [RFC8519],
and [RFC8294].
b) Should Qin Wu be added to the list of authors in the YANG module in
this section?
c) May we add the IANA reference information for the IANA URL listed in
this reference entry?
Original:
reference
"RFC 9293: Transmission Control Protocol (TCP),
Section 3.1
https://www.iana.org/assignments/tcp-parameters";
Perhaps:
reference
"RFC 9293: Transmission Control Protocol (TCP),
Section 3.1
IANA: Transmission Control Protocol (TCP) Parameters,
<https://www.iana.org/assignments/tcp-parameters>";
-->
<t>This Yang module imports types from <xref target="RFC6991"/>, <xref tar
get="RFC8519"/>, and <xref target="RFC8294"/>.</t>
<sourcecode markers="true" name="ietf-acl-enh@2025-11-07.yang" type="yang"
><![CDATA[
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;
reference reference
"RFC 6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
skipping to change at line 510 skipping to change at line 568
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 XXXX: Extensions to the Access Control Lists (ACLs) "RFC 9899: Extensions to the Access Control Lists (ACLs)
YANG Model"; YANG Model";
} }
import iana-icmpv6-types { import iana-icmpv6-types {
prefix iana-icmpv6-types; prefix iana-icmpv6-types;
reference reference
"RFC XXXX: Extensions to the Access Control Lists (ACLs) "RFC 9899: Extensions to the Access Control Lists (ACLs)
YANG Model"; YANG Model";
} }
import iana-ipv6-ext-types { import iana-ipv6-ext-types {
prefix iana-ipv6-ext-types; prefix iana-ipv6-ext-types;
reference reference
"RFC XXXX: Extensions to the Access Control Lists (ACLs) "RFC 9899: Extensions to the Access Control Lists (ACLs)
YANG Model"; YANG Model";
} }
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>
Author: Samier Barguil Author: Samier Barguil
mailto:samier.barguil_giraldo@nokia.com <mailto:samier.barguil_giraldo@nokia.com>
Author: Oscar Gonzalez de Dios Author: Oscar Gonzalez de Dios
mailto:oscar.gonzalezdedios@telefonica.com"; <mailto:oscar.gonzalezdedios@telefonica.com>";
description description
"This module contains YANG definitions for enhanced ACLs. "This module contains YANG definitions for enhanced ACLs.
Copyright (c) 2025 IETF Trust and the persons identified as Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject to
to the license terms contained in, the Revised BSD License the license terms contained in, the Revised BSD License set
set forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9899; see the
the RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2024-05-16 { revision 2025-11-07 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Extensions to the Access Control Lists (ACLs) "RFC 9899: Extensions to the Access Control Lists (ACLs)
YANG Model"; YANG Model";
} }
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 vlan list is supported."; "Match based on a VLAN range of a VLAN list is supported.";
} }
feature match-on-isid-filter { feature match-on-isid-filter {
description description
"Match based on an I-SID range of VLAN list is supported."; "Match based on an I-SID range of a VLAN list 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.";
} }
identity offset-type { identity offset-type {
description description
"Base identity for payload offset type."; "Base identity for payload offset type.";
} }
identity layer2 { identity layer2 {
base offset-type; base offset-type;
description description
"The offset starts at the beginning of the Data Link layer "The offset starts at the beginning of the Data Link Layer
header."; header.";
} }
identity layer3 { identity layer3 {
base offset-type; base offset-type;
description description
"The offset starts at the beginning of the IP header."; "The offset starts at the beginning of the IP header.";
} }
identity layer4 { identity layer4 {
base offset-type; base offset-type;
description description
"The offset starts right after the IP header (including "The offset starts right after the IP header (including
any options or headers pertaining to that IP layer, e.g., any options or headers pertaining to that IP layer, e.g.,
IPv6 Extension Headers and the Authentication Header (AH)). IPv6 Extension Headers and the Authentication Header (AH)).
This can be typically the beginning of transport header This can be typically the beginning of transport header
(e.g., UDP, TCP, SCTP, and DCCP) or any encapsulation (e.g., UDP, TCP, the Stream Control Transmission Protocol
scheme over IP such as IP-in-IP."; (SCTP), and the Datagram Congestion Control Protocol (DCCP))
or any encapsulation scheme over IP such as IP-in-IP.";
} }
identity payload { identity payload {
base offset-type; base offset-type;
description description
"The offset starts right after the end of the transport "The offset starts right after the end of the transport
header. For example, this represents the beginning of the header. For example, this represents the beginning of the
TCP data right after any TCP options or the beginning of TCP data right after any TCP options or the beginning of
the UDP payload right after the UDP header. the UDP payload right after the UDP header.
This type may be used for matches against any data in This type may be used for matches against any data in
the transport payload and/or any surplus area (if any, the transport payload and/or any surplus area (if any,
such as in UDP)."; such as in UDP).";
} }
identity tcp-flag { identity tcp-flag {
description description
"Base Identity for the TCP Flags."; "Base identity for the TCP Flags.";
reference reference
"RFC 9293: Transmission Control Protocol (TCP), Section 3.1"; "RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
} }
identity ack { identity ack {
base tcp-flag; base tcp-flag;
description description
"Acknowledgment TCP flag bit."; "Acknowledgment TCP flag bit.";
reference reference
"RFC 9293: Transmission Control Protocol (TCP), Section 3.1"; "RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
skipping to change at line 706 skipping to change at line 766
base tcp-flag; base tcp-flag;
description description
"Congestion Window Reduced flag bit."; "Congestion Window Reduced flag bit.";
reference reference
"RFC 9293: Transmission Control Protocol (TCP), Section 3.1"; "RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
} }
identity ae { identity ae {
base tcp-flag; base tcp-flag;
description description
"Accurate ECN. "Accurate Explicit Congestion Notification (ECN).
Previously used as NS (Nonce Sum), which is now Previously used as Nonce Sum (NS), which is now
historic."; historic.";
} }
identity mpls-acl-type { identity mpls-acl-type {
base acl:acl-base; base acl:acl-base;
description description
"An ACL that matches on fields from the MPLS header."; "An ACL that matches on fields from the MPLS header.";
} }
identity label-position { identity label-position {
skipping to change at line 737 skipping to change at line 797
} }
identity bottom { identity bottom {
base label-position; base label-position;
description description
"Bottom of the label stack."; "Bottom of the label stack.";
} }
identity log-types { identity log-types {
description description
"Base identity for deriving the Log actions."; "Base identity for deriving the log actions.";
} }
identity local-log { identity local-log {
base log-types; base log-types;
description description
"A local log is used to record the ACL results."; "A local log is used to record the ACL results.";
} }
identity counter-type { identity counter-type {
description description
skipping to change at line 763 skipping to change at line 823
description description
"Identity for counter name to be updated based on "Identity for counter name to be updated based on
the ACL match actions."; the ACL match actions.";
} }
typedef operator { typedef operator {
type bits { type bits {
bit not { bit not {
position 0; position 0;
description description
"If set, logical negation of operation."; "If set, the logical negation of operation.";
} }
bit match { bit match {
position 1; position 1;
description description
"Match bit. This is a bitwise match operation defined as "Match bit. This is a bitwise match operation defined as
'(data & value) == value'."; '(data & value) == value'.";
} }
bit any { bit any {
position 2; position 2;
description description
"Any bit. This is a match on any of the bits in bitmask. "Any bit. This is a match on any of the bits in bitmask.
It evaluates to 'true' if any of the bits in the It evaluates to 'true' if any of the bits in the
value mask are set in the data, i.e., value mask are set in the data, i.e.,
'(data & value) != 0'."; '(data & value) != 0'.";
} }
} }
description description
"Specifies how to apply the defined bitmask. "Specifies how to apply the defined bitmask. The
'any' and 'match' bits must not be set simultaneously."; 'any' and 'match' bits must not be set simultaneously.";
} }
typedef fragment-type { typedef fragment-type {
type bits { type bits {
bit df { bit df {
position 0; position 0;
description description
"Don't fragment bit for IPv4. "Don't fragment bit for IPv4. Must be set to 0 when it
Must be set to 0 when it appears in an IPv6 filter."; appears in an IPv6 filter.";
} }
bit isf { bit isf {
position 1; position 1;
description description
"Is a fragment."; "Is a fragment.";
} }
bit ff { bit ff {
position 2; position 2;
description description
"First fragment."; "First fragment.";
skipping to change at line 905 skipping to change at line 965
} }
} }
case builtin { case builtin {
leaf bitmask { leaf bitmask {
type uint16; type uint16;
description description
"The bitmask matches the last 4 bits of byte 13 "The bitmask matches the last 4 bits of byte 13
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. included in any matching. Assigned TCP flags
Assigned TCP flags and their position are maintained and their position are maintained in the IANA
in the IANA'Transmission Control Protocol (TCP) 'Transmission Control Protocol (TCP) Parameters'
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
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 {
type operator; type operator;
skipping to change at line 942 skipping to change at line 1002
} }
grouping mpls-match-parameters-config { grouping mpls-match-parameters-config {
description description
"Parameters for the configuration of MPLS match rules."; "Parameters for the configuration of MPLS match rules.";
leaf traffic-class { leaf traffic-class {
type uint8 { type uint8 {
range "0..7"; range "0..7";
} }
description description
"The value of the MPLS traffic class (TC) bits, "The value of the MPLS Traffic Class (TC) bits,
formerly known as the EXP bits."; formerly known as the EXP bits.";
} }
leaf label-position { leaf label-position {
type identityref { type identityref {
base acl-enh:label-position; base acl-enh:label-position;
} }
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 indicated the upper range The usage of this field indicates the upper
value in the top of the stack. range value in the top of the stack. This
This label value does not include the encodings label value does not include the encodings
of Traffic Class and TTL."; of Traffic Class and 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 indicated 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 Traffic Class 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 predefiend 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."; "Time-to-live 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 {
base acl-enh:offset-type; base acl-enh:offset-type;
} }
description description
"Indicates the payload offset. This will indicate "Indicates the payload offset. This will indicate
the position of the data in packet to use for the position of the data in the packet to use for
the match."; the match.";
} }
leaf length { leaf length {
type uint16; type uint16;
units "bytes"; units "bytes";
description description
"Indicates the number of bytes to ignore, starting from "Indicates the number of bytes to ignore, starting from
the offset, to perform the pattern match."; the offset, to perform the pattern match.";
} }
leaf operator { leaf operator {
skipping to change at line 1069 skipping to change at line 1129
} }
leaf-list protocol { leaf-list protocol {
type uint8; type uint8;
description description
"Identifies the target protocol number. "Identifies the target protocol number.
For example, 6 for TCP or 17 for UDP."; For example, 6 for TCP or 17 for UDP.";
} }
leaf-list fqdn { leaf-list fqdn {
type inet:domain-name; type inet:domain-name;
description description
"FQDN identifying the target."; "Fully Qualified Domain Name (FQDN) identifying the target.";
} }
leaf-list uri { leaf-list uri {
type inet:uri; type inet:uri;
description description
"URI identifying the target."; "URI identifying the target.";
} }
} }
grouping icmpv4-header-fields { grouping icmpv4-header-fields {
description description
skipping to change at line 1132 skipping to change at line 1192
"ICMP code."; "ICMP code.";
reference reference
"RFC 4443: Internet Control Message Protocol (ICMPv6) "RFC 4443: Internet Control Message Protocol (ICMPv6)
for Internet Protocol Version 6 (IPv6) for Internet Protocol Version 6 (IPv6)
Specification."; Specification.";
} }
leaf rest-of-header { leaf rest-of-header {
type binary; type binary;
description description
"Unbounded in length, the contents vary based on the "Unbounded in length, the contents vary based on the
ICMP type and code. Also referred to as 'Message Body' ICMP type and code. Also referred to as 'Message Body'
in ICMPv6."; in ICMPv6.";
reference reference
"RFC 4443: Internet Control Message Protocol (ICMPv6) "RFC 4443: Internet Control Message Protocol (ICMPv6)
for Internet Protocol Version 6 (IPv6) for Internet Protocol Version 6 (IPv6)
Specification."; Specification.";
} }
} }
grouping acl-complementary-actions { grouping acl-complementary-actions {
description description
skipping to change at line 1185 skipping to change at line 1245
leaf-list counter-name { leaf-list counter-name {
when "derived-from-or-self(../counter-type, " when "derived-from-or-self(../counter-type, "
+ "'acl-enh:counter-name')" { + "'acl-enh:counter-name')" {
description description
"Name for the counter or variable to update when "Name for the counter or variable to update when
'counter-type' is 'counter-name'."; 'counter-type' is 'counter-name'.";
} }
type string; type string;
description description
"List of possible variables or counter names to "List of possible variables or counter names to
update based on match critieria."; update based on match criteria.";
} }
} }
} }
grouping ipv4-prefix-sets { grouping ipv4-prefix-sets {
description description
"Data definitions for a list of IPv4 prefixes "Data definitions for a list of IPv4 prefixes,
prefixes which are matched as part of a policy."; which are matched as part of a policy.";
list prefix-set { list prefix-set {
key "name"; key "name";
description description
"List of the defined prefix sets."; "List of the defined prefix sets.";
leaf name { leaf name {
type string; type string;
description description
"Name of the prefix set -- this is used as a label to "Name of the prefix set -- this is used as a label to
reference the set in match conditions."; reference the set in match conditions.";
} }
leaf description { leaf description {
type string; type string;
description description
"Defined Set description."; "Defined set description.";
} }
leaf-list prefix { leaf-list prefix {
type inet:ipv4-prefix; type inet:ipv4-prefix;
description description
"List of IPv4 prefixes to be used in match "List of IPv4 prefixes to be used in match
conditions."; conditions.";
} }
} }
} }
grouping ipv6-prefix-sets { grouping ipv6-prefix-sets {
description description
"Data definitions for a list of IPv6 prefixes which are "Data definitions for a list of IPv6 prefixes, which are
matched as part of a policy."; matched as part of a policy.";
list prefix-set { list prefix-set {
key "name"; key "name";
description description
"List of the defined prefix sets."; "List of the defined prefix sets.";
leaf name { leaf name {
type string; type string;
description description
"Name of the prefix set -- this is used as a label to "Name of the prefix set -- this is used as a label to
reference the set in match conditions."; reference the set in match conditions.";
skipping to change at line 1247 skipping to change at line 1307
leaf-list prefix { leaf-list prefix {
type inet:ipv6-prefix; type inet:ipv6-prefix;
description description
"List of IPv6 prefixes to be used in match conditions."; "List of IPv6 prefixes to be used in match conditions.";
} }
} }
} }
grouping port-sets { grouping port-sets {
description description
"Data definitions for a list of ports which can "Data definitions for a list of ports, which can
be matched in policies."; be matched in policies.";
list port-set { list port-set {
key "name"; key "name";
description description
"List of port set definitions."; "List of port set definitions.";
leaf name { leaf name {
type string; type string;
description description
"Name of the port set -- this is used as a label to "Name of the port set -- this is used as a label to
reference the set in match conditions."; reference the set in match conditions.";
skipping to change at line 1285 skipping to change at line 1345
"Indicates a set of ports."; "Indicates a set of ports.";
uses packet-fields:port-range-or-operator; uses packet-fields:port-range-or-operator;
} }
} }
} }
} }
} }
grouping protocol-sets { grouping protocol-sets {
description description
"Data definitions for a list of protocols which can be "Data definitions for a list of protocols, which can be
matched in policies."; matched in policies.";
list protocol-set { list protocol-set {
key "name"; key "name";
description description
"List of protocol set definitions."; "List of protocol set definitions.";
leaf name { leaf name {
type string; type string;
description description
"Name of the protocols set -- this is used as a "Name of the protocols set -- this is used as a
label to reference the set in match conditions."; label to reference the set in match conditions.";
skipping to change at line 1310 skipping to change at line 1370
type string; type string;
} }
description description
"Value of the protocol set."; "Value of the protocol set.";
} }
} }
} }
grouping icmpv4-type-sets { grouping icmpv4-type-sets {
description description
"Data definitions for a list of ICMPv4 types which can be "Data definitions for a list of ICMPv4 types, which can be
matched in policies."; matched in policies.";
list set { list set {
key "name"; key "name";
description description
"List of ICMPv4 type set definitions."; "List of ICMPv4 type set definitions.";
leaf name { leaf name {
type string; type string;
description description
"Name of the ICMPv4 type set -- this is used as a label "Name of the ICMPv4 type set -- this is used as a label
to reference the set in match conditions."; to reference the set in match conditions.";
skipping to change at line 1333 skipping to change at line 1393
key "type"; key "type";
description description
"Includes a list of ICMPv4 types."; "Includes a list of ICMPv4 types.";
uses icmpv4-header-fields; uses icmpv4-header-fields;
} }
} }
} }
grouping icmpv6-type-sets { grouping icmpv6-type-sets {
description description
"Data definitions for a list of ICMPv6 types which can be "Data definitions for a list of ICMPv6 types, which can be
matched in policies."; matched in policies.";
list set { list set {
key "name"; key "name";
description description
"List of ICMP type set definitions."; "List of ICMP type set definitions.";
leaf name { leaf name {
type string; type string;
description description
"Name of the ICMPv6 type set -- this is used as a label "Name of the ICMPv6 type set -- this is used as a label
to reference the set in match conditions."; to reference the set in match conditions.";
skipping to change at line 1356 skipping to change at line 1416
key "type"; key "type";
description description
"Includes a list of ICMPv6 types."; "Includes a list of ICMPv6 types.";
uses icmpv6-header-fields; uses icmpv6-header-fields;
} }
} }
} }
grouping aliases { grouping aliases {
description description
"Grpuing for a set of aliases."; "Grouping for a set of aliases.";
list alias { list alias {
key "name"; key "name";
description description
"List of aliases."; "List of aliases.";
leaf name { leaf name {
type string; type string;
description description
"The name of the alias."; "The name of the alias.";
} }
uses alias; uses alias;
} }
} }
grouping defined-sets { grouping defined-sets {
description description
"Predefined sets of attributes used in policy match "Predefined sets of attributes used in policy match
statements."; statements.";
container ipv4-prefix-sets { container ipv4-prefix-sets {
description description
"Data definitions for a list of IPv4 or IPv6 "Data definitions for a list of IPv4 or IPv6
prefixes which are matched as part of a policy."; prefixes, which are matched as part of a policy.";
uses ipv4-prefix-sets; uses ipv4-prefix-sets;
} }
container ipv6-prefix-sets { container ipv6-prefix-sets {
description description
"Data definitions for a list of IPv6 prefixes which are "Data definitions for a list of IPv6 prefixes, which are
matched as part of a policy."; matched as part of a policy.";
uses ipv6-prefix-sets; uses ipv6-prefix-sets;
} }
container port-sets { container port-sets {
description description
"Data definitions for a list of ports which can "Data definitions for a list of ports, which can
be matched in policies."; be matched in policies.";
uses port-sets; uses port-sets;
} }
container protocol-sets { container protocol-sets {
description description
"Data definitions for a list of protocols which can be "Data definitions for a list of protocols, which can be
matched in policies."; matched in policies.";
uses protocol-sets; uses protocol-sets;
} }
container icmpv4-type-sets { container icmpv4-type-sets {
description description
"Data definitions for a list of ICMPv4 types which can be "Data definitions for a list of ICMPv4 types, which can be
matched in policies."; matched in policies.";
uses icmpv4-type-sets; uses icmpv4-type-sets;
} }
container icmpv6-type-sets { container icmpv6-type-sets {
description description
"Data definitions for a list of ICMPv6 types which can be "Data definitions for a list of ICMPv6 types, which can be
matched in policies."; matched in policies.";
uses icmpv6-type-sets; uses icmpv6-type-sets;
} }
container aliases { container aliases {
description description
"Top-level container for aliases."; "Top-level container for aliases.";
uses aliases; uses aliases;
} }
} }
skipping to change at line 1455 skipping to change at line 1515
"Matches based upon aliases."; "Matches based upon aliases.";
leaf-list alias-name { leaf-list alias-name {
type alias-ref; type alias-ref;
description description
"Indicates one or more aliases."; "Indicates one or more aliases.";
} }
} }
choice mpls { choice mpls {
description description
"Matches against MPLS headers, for example, label "Matches against MPLS headers, for example, label
values"; values.";
container mpls-values { container mpls-values {
if-feature "match-on-mpls"; if-feature "match-on-mpls";
description description
"Provides the rule set that matches MPLS headers."; "Provides the rule set that matches MPLS headers.";
uses mpls-match-parameters-config; uses mpls-match-parameters-config;
} }
} }
} }
augment "/acl:acls/acl:acl/acl:aces" augment "/acl:acls/acl:acl/acl:aces"
skipping to change at line 1477 skipping to change at line 1537
description description
"Adds a match type based on MAC VLAN and I-SID filters."; "Adds a match type based on MAC VLAN and I-SID filters.";
container vlan-filter { container vlan-filter {
if-feature "match-on-vlan-filter"; if-feature "match-on-vlan-filter";
description description
"Indicates how to handle MAC VLANs."; "Indicates how to handle MAC VLANs.";
leaf frame-type { leaf frame-type {
type string; type string;
description description
"Entering the frame type allows the "Entering the frame type allows the
filter to match a specific type of frame format"; filter to match a specific type of frame format.";
} }
choice vlan-type { choice vlan-type {
description description
"VLAN definition from range or operator."; "VLAN definition from range or operator.";
case range { case range {
leaf lower-vlan { leaf lower-vlan {
type uint16; type uint16;
must '. <= ../upper-vlan' { must '. <= ../upper-vlan' {
error-message error-message
"The lower-vlan must be less than or equal to "The lower-vlan must be less than or equal to
skipping to change at line 1522 skipping to change at line 1582
match."; match.";
reference reference
"IEEE Std 802.1Q: Bridges and Bridged Networks"; "IEEE Std 802.1Q: Bridges and Bridged Networks";
} }
} }
} }
} }
container isid-filter { container isid-filter {
if-feature "match-on-isid-filter"; if-feature "match-on-isid-filter";
description description
"Indicates how to handle I-SID filters. "Indicates how to handle I-SID filters. The
The I-component is responsible for mapping customer I-component is responsible for mapping customer
Ethernet traffic to the appropriate I-SID."; Ethernet traffic to the appropriate I-SID.";
choice isid-type { choice isid-type {
description description
"I-SID definition from range or operator."; "I-SID definition from range or operator.";
case range { case range {
leaf lower-isid { leaf lower-isid {
type uint16; type uint16;
must '. <= ../upper-isid' { must '. <= ../upper-isid' {
error-message error-message
"The lower-isid must be less than or equal to "The lower-isid must be less than or equal to
skipping to change at line 1697 skipping to change at line 1757
type icmpv6-type-set-ref; type icmpv6-type-set-ref;
description description
"A reference to an ICMPv6 type set to match the ICMPv6 type "A reference to an ICMPv6 type set to match the ICMPv6 type
field."; field.";
} }
} }
augment "/acl:acls/acl:acl/acl:aces" augment "/acl:acls/acl:acl/acl:aces"
+ "/acl:ace/acl:actions" { + "/acl:ace/acl:actions" {
description description
"Complementary actions including Rate-limit action."; "Complementary actions including rate-limit action.";
uses acl-complementary-actions; uses acl-complementary-actions;
leaf rate-limit { leaf rate-limit {
when "../acl:forwarding = 'acl:accept'" { when "../acl:forwarding = 'acl:accept'" {
description description
"Rate-limit valid only when accept action is used."; "Rate-limit valid only when the accept action is used.";
} }
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
units "bytes per second"; units "bytes per second";
description description
"Indicates a rate-limit for the matched traffic."; "Indicates a rate-limit for the matched traffic.";
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
<!-- [rfced] Questions about the Security Considerations (Section 5)
For reference:
YANG security considerations template:
<https://wiki.ietf.org/group/ops/yang-security-guidelines>
a) The "RPC/action operations section" does not appear in this
document. The YANG security considerations template suggests
including the following text if this section does not apply;
should this text be added to this section?
Perhaps:
"There are no particularly sensitive RPC or action operations."
b) The "Reusable groupings from other modules section" does not appear
in this document. Please review the template and confirm that this
paragraph does not apply.
c) Per the "No data nodes section" portion of the YANG security
considerations template, should it be included whether the
"ietf-acl-enh" YANG module defines a set of identities, types, and
groupings? Also, is it correct to include the three IANA modules in
this paragraph, or should the modules or this paragraph perhaps be
removed since the IANA modules were removed from the document itself?
Current:
The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and "iana-
ipv6-ext-types" define a set of identities, types, and groupings.
These nodes are intended to be reused by other YANG modules. Each
module by itself does not expose any data nodes that are writable,
data nodes that contain read-only state, or RPCs.
d) Per the "No data nodes section" portion of the YANG security
considerations template, should the following paragraph be added to
Section 5? If so, please review and let us know what we may replace
'node-example' with.
Perhaps:
Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For
example, reusing some of these groupings will expose privacy-related
information (e.g., 'node-example').
-->
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This section is modeled after the template described in <xref section=" <t>This section is modeled after the template described in <xref section="
3.7" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t> 3.7.1" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t>
<t>The "ietf-acl-enh" YANG module defines a data model that is
designed to be accessed via YANG-based management protocols, such as <t>The "ietf-acl-enh" YANG module defines a data model that is designed
NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These YA to be accessed via YANG-based management protocols, such as NETCONF
NG-based management protocols (1) have to <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These
use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref targ protocols have to use a secure transport layer (e.g., SSH <xref
et="RFC8446"/>, and target="RFC4252"/>, TLS <xref target="RFC8446"/>, and QUIC <xref
QUIC <xref target="RFC9000"/>) and (2) have to use mutual authentication.</t> target="RFC9000"/>) and have to use mutual authentication.</t>
<t>The Network Configuration Access Control Model (NACM) <xref target="RFC
8341"/> provides the means to restrict access for particular NETCONF or RESTCONF <t>The Network Configuration Access Control Model (NACM) <xref
users to a preconfigured subset of all available NETCONF or RESTCONF protocol o target="RFC8341"/> provides the means to restrict access for particular
perations and content.</t> NETCONF or RESTCONF users to a preconfigured subset of all available
NETCONF or RESTCONF protocol operations and content.</t>
<t>There are a number of data nodes defined in this YANG module that are <t>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
sensitive or vulnerable in some network environments. Write or vulnerable in some network environments. Write operations (e.g.,
operations (e.g., edit-config) and delete operations to these data edit-config) and delete operations to these data nodes without proper
nodes without proper protection or authentication can have a negative protection or authentication can have a negative effect on network
effect on network operations. The following subtrees and data nodes operations. The following subtrees and data nodes have particular
have particular sensitivities/vulnerabilities:</t> sensitivities/vulnerabilities:</t>
<dl> <dl>
<dt>'defined-sets':</dt> <dt>'defined-sets':</dt>
<dd> <dd>
<t>These lists specify a set of IP addresses, port numbers, protocols, <t>These lists specify a set of IP addresses, port numbers,
ICMP types, and aliases. Similar to <xref target="RFC8519"/>, unauthorized writ protocols, ICMP types, and aliases. Similar to <xref
e access to these target="RFC8519"/>, unauthorized write access to these lists can
lists can allow intruders to modify the entries so as to permit allow intruders to modify the entries to permit traffic that should
traffic that should not be permitted, or deny traffic that should not be permitted or deny traffic that should be permitted. The
be permitted. The former may result in a DoS attack, or former may result in a DoS attack or compromise a device. The latter
compromise a device. The latter may result in a DoS attack.</t> may result in a DoS attack.</t>
</dd>
<dt/>
<dd>
<t>These sets are defined with "nacm:default-deny-write" tagging.</t> <t>These sets are defined with "nacm:default-deny-write" tagging.</t>
</dd> </dd>
</dl> </dl>
<t>Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus <t>Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. Specifically, the following notification) to these data nodes. Specifically, the following subtrees and data
subtrees and data nodes have particular sensitivities/vulnerabilities:</t> nodes have particular sensitivities/vulnerabilities:</t>
<dl> <dl>
<dt>'defined-sets':</dt> <dt>'defined-sets':</dt>
<dd> <dd>
<t>Unauthorized read access of these lists will allow <t>Unauthorized read access of these lists will allow
an attacker to identify the actual resources that are bound an attacker to identify the actual resources that are bound
to ACLs. Likewise, access to this information will help an attacker to to ACLs. Likewise, access to this information will help an attacker to
better scope its attacks to target resources that are specific to a given networ k instead better scope its attacks to target resources that are specific to a given networ k instead
of performing random scans. Also, disclosing some of this information (e.g., IP addresses of core routers) of performing random scans. Also, disclosing some of this information (e.g., IP addresses of core routers)
may nullify the effect of topology hiding strategies in some networks.</t> may nullify the effect of topology-hiding strategies in some networks.</t>
</dd> </dd>
</dl> </dl>
<t>The document defines a match policy based on a pattern that can be obse <t>The document defines a match policy based on a pattern that can be
rved in a packet. For example, such a policy can be combined with header-based m observed in a packet. For example, such a policy can be combined with
atches in the context of DDoS mitigation. Filtering based on a pattern match is header-based matches in the context of DDoS mitigation. Filtering based
deterministic for packets with unencrypted data. However, the efficiency for enc on a pattern match is deterministic for packets with unencrypted
rypted packets depend on the presence of an unvarying pattern. Readers may also data. However, the efficiency for encrypted packets depends on the
refer to <xref section="11" sectionFormat="of" target="RFC8329"/> for security c presence of an unvarying pattern. Readers may also refer to <xref
onsiderations related to Network Security Functions (NSFs) that apply packet con section="11" sectionFormat="of" target="RFC8329"/> for security
tent matching.</t> considerations related to Network Security Functions (NSFs) that apply
<t>The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and "iana-ip packet content matching.</t>
v6-ext-types" define a set of types. These nodes are intended to be reused by ot <t>The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and
her YANG "iana-ipv6-ext-types" define a set of identities, types, and
modules. Each of these modules by itself does not expose any data nodes that groupings. These nodes are intended to be reused by other YANG
are writable, data nodes that contain read-only state, or RPCs. modules. Each module by itself does not expose any data nodes
As such, there are no additional security issues related to that are writable, data nodes that contain read-only state, or RPCs. As
these YANG modules that need to be considered.</t> such, there are no additional security issues related to these YANG
modules that need to be considered.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="uri-registrations"> <section anchor="uri-registrations">
<name>URI Registrations</name> <name>URI Registrations</name>
<t>This document requests IANA to register the following URIs in the "ns
"
subregistry within the "IETF XML Registry" <xref target="RFC3688"/>:</t>
<artwork><![CDATA[
URI: urn:ietf:params:xml:ns:yang:ietf-acl-enh
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:iana-icmpv4-types <!-- [rfced] We have included specific questions about the IANA
Registrant Contact: The IESG. text below. In addition to responding to those questions, please
XML: N/A; the requested URI is an XML namespace. review all of the IANA-related updates carefully and let us know
if any further updates are needed.
URI: urn:ietf:params:xml:ns:yang:iana-icmpv6-types a) We note that RFC 9890 is included as a reference for the "YANG Module
Registrant Contact: The IESG. Names" registry <https://www.iana.org/assignments/yang-parameters/>.
XML: N/A; the requested URI is an XML namespace. Should RFC 9890 be added to the text below and to the Informative
References section?
URI: urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types Current:
Registrant Contact: The IESG. IANA has registered the following YANG modules in the "YANG Module
XML: N/A; the requested URI is an XML namespace. Names" registry [RFC6020] within the "YANG Parameters" registry
]]></artwork> group.
Perhaps:
IANA has registered the following YANG modules in the "YANG Module
Names" registry [RFC6020] [RFC9890] within the "YANG Parameters"
registry group.
b) FYI: Per the note from the authors, we replaced the [IANA_ICMPv4_YANG_URL],
[IANA_ICMPv6_YANG_URL], and [IANA_IPV6_YANG_URL] citations with the
[IANA-YANG-PARAMETERS] citation as shown below.
Original:
(Section 1)
Readers should refer to the IANA websites [IANA_ICMPv4_YANG_URL],
[IANA_ICMPv6_YANG_URL], and [IANA_IPV6_YANG_URL] to retrieve the
latest version of these IANA-maintained modules.
(Section 6.3.1)
When this registry is modified, the YANG module "iana-
icmpv4-types" [IANA_ICMPv4_YANG_URL] must be updated as defined in
RFC 9899.
(Section 6.3.2)
When this registry is modified, the YANG module "iana-
icmpv6-types" [IANA_ICMPv6_YANG_URL] must be updated as defined in
RFC 9899.
(Section 6.3.3)
When this registry is modified, the YANG module "iana-ipv6-ext-
types" [IANA_IPV6_YANG_URL] must be updated as defined in RFC 9899.
Current:
(Section 1)
The latest version of these IANA-maintained modules can
be retrieved from the "YANG Parameters" registry group
[IANA-YANG-PARAMETERS].
(Section 6.3.1)
When this registry is modified, the YANG module "iana-
icmpv4-types" [IANA-YANG-PARAMETERS] must be updated
as defined in RFC 9899.
(Section 6.3.2)
When this registry is modified, the YANG module "iana-
icmpv6-types" [IANA-YANG-PARAMETERS] must be updated
as defined in RFC 9899.
(Section 6.3.3)
When this registry is modified, the YANG module "iana-
ipv6-ext-types" [IANA-YANG-PARAMETERS] must be updated
as defined in RFC 9899.
c) We note that the description of "enum" appears slightly different
in Sections 6.3.1, 6.3.2, and 6.3.3. Should these instances be made
consistent? If so, please let us know how to update.
In addition, should "striped" be "stripped"?
Original:
"enum": Replicates the name from the registry with all illegal
characters (e.g., spaces) are striped.
"enum": Replicates the name from the registry with all illegal
characters (e.g., spaces) striped.
"enum": Replicates the description from the registry with all spaces
striped.
Perhaps:
"enum": Replicates the name from the registry with all illegal
characters (e.g., spaces) stripped.
d) We note that this item appears slightly different in the following
sections. Please review and let us know if/how to update for
consistency.
Usage in Sections 6.3.1. and 6.3.2:
"description": Replicates the name from the registry.
Usage in Section 6.3.3:
"description": Replicates the description from the registry.
e) FYI: We typically note that a document has been added as an
additional reference to a registry within the running text (in
paragraph form). Thus, we updated the text in Sections 6.3.1, 6.3.2,
and 6.3.3 as shown below (i.e., removed "OLD/NEW" and removed RFCs
2780, 5237, and 7045 from the Informative References section as they
were only mentioned in the "OLD/NEW" text). Please let us know of
any objection.
One example (from Section 6.3.1)
Original:
IANA is requested to add this note to "ICMP Type Numbers" [IANA-ICMPv4]:
[...]
IANA is requested to update the "Reference" in the "ICMP Type Numbers"
registry as follows:
OLD: [RFC2780]
NEW: [RFC2780][RFCXXXX]
Current:
IANA has added this note to the "ICMP Type Numbers" registry [IANA-ICMPv4]
and listed this document as an additional reference for the registry:
[...]
-->
<t>IANA has registered the following URIs in the "ns"
registry within the "IETF XML Registry" <xref target="RFC3688"/>:</t>
<dl spacing="compact" newline="false">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-acl-enh</dd>
<dt>Registrant Contact:</dt><dd>The IESG</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl spacing="compact" newline="false">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:iana-icmpv4-types</dd>
<dt>Registrant Contact:</dt><dd>The IESG</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl spacing="compact" newline="false">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:iana-icmpv6-types</dd>
<dt>Registrant Contact:</dt><dd>The IESG</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<dl spacing="compact" newline="false">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types</dd>
<dt>Registrant Contact:</dt><dd>The IESG</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
</section> </section>
<section anchor="yang-module-name-registrations"> <section anchor="yang-module-name-registrations">
<name>YANG Module Name Registrations</name> <name>YANG Module Name Registrations</name>
<t>This document requests IANA to register the following YANG modules in <t>IANA has registered the following YANG modules in
the "YANG Module Names" subregistry <xref target="RFC6020"/> within the "YANG the "YANG Module Names" registry <xref target="RFC6020"/> within the "YANG
Parameters" registry.</t> Parameters" registry group.</t>
<artwork><![CDATA[
name: ietf-acl-enh
namespace: urn:ietf:params:xml:ns:yang:ietf-acl-enh
maintained by IANA: N
prefix: acl-enh
reference: RFC XXXX
name: iana-icmpv4-types
namespace: urn:ietf:params:xml:ns:yang:iana-icmpv4-types
maintained by IANA: Y
prefix: iana-icmpv4-types
reference: RFC XXXX
name: iana-icmpv6-types
namespace: urn:ietf:params:xml:ns:yang:iana-icmpv6-types
maintained by IANA: Y
prefix: iana-icmpv6-types
reference: RFC XXXX
name: iana-ipv6-ext-types <dl spacing="compact" newline="false">
namespace: urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types <dt>Name:</dt><dd>ietf-acl-enh</dd>
maintained by IANA: Y <dt>Maintained by IANA:</dt><dd>N</dd>
prefix: iana-ipv6-ext-types <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-acl-enh</dd>
reference: RFC XXXX <dt>Prefix:</dt><dd>acl-enh</dd>
]]></artwork> <dt>Reference:</dt><dd>RFC 9899</dd>
</dl>
<dl spacing="compact" newline="false">
<dt>Name:</dt><dd>iana-icmpv4-types</dd>
<dt>Maintained by IANA:</dt><dd>Y</dd>
<dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:iana-icmpv4-types</dd>
<dt>Prefix:</dt><dd>iana-icmpv4-types</dd>
<dt>Reference:</dt><dd>RFC 9899</dd>
</dl>
<dl spacing="compact" newline="false">
<dt>Name:</dt><dd>iana-icmpv6-types</dd>
<dt>Maintained by IANA:</dt><dd>Y</dd>
<dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:iana-icmpv6-types</dd>
<dt>Prefix:</dt><dd>iana-icmpv6-types</dd>
<dt>Reference:</dt><dd>RFC 9899</dd>
</dl>
<dl spacing="compact" newline="false">
<dt>Name:</dt><dd>iana-ipv6-ext-types</dd>
<dt>Maintained by IANA:</dt><dd>Y</dd>
<dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types</dd>
<dt>Prefix:</dt><dd>iana-ipv6-ext-types</dd>
<dt>Reference:</dt><dd>RFC 9899</dd>
</dl>
</section> </section>
<section anchor="considerations-for-iana-maintained-modules"> <section anchor="considerations-for-iana-maintained-modules">
<name>Considerations for IANA-Maintained Modules</name> <name>Considerations for IANA-Maintained Modules</name>
<section anchor="icmpv4-types-iana-module"> <section anchor="icmpv4-types-iana-module">
<name>ICMPv4 Types IANA Module</name> <name>ICMPv4 Types IANA Module</name>
<t>This document defines the initial version of the IANA-maintained <t>This document defines the initial version of the IANA-maintained
"iana-icmpv4-types" YANG module. The most recent version of the YANG module "iana-icmpv4-types" YANG module. The most recent version of the YANG module
is available from the "YANG Parameters" registry is available in the "YANG Parameters" registry group
<xref target="IANA-YANG-PARAMETERS"/>.</t> <xref target="IANA-YANG-PARAMETERS"/>.</t>
<t>IANA is requested to add this note to the registry <xref target="IA <t>IANA has added this note to the registry:</t>
NA-YANG-PARAMETERS"/>:</t>
<ul empty="true"> <blockquote>New values must not be directly added to the
<li> "iana-icmpv4-types" YANG module. They must instead be added to the
<t>New values must not be directly added to the "iana-icmpv4-types "ICMP Type Numbers" registry <xref
" YANG module. They must instead be added to the "ICMP Type Numbers" registry < target="IANA-ICMPv4"/>.</blockquote>
xref target="IANA-ICMPv4"/>.</t>
</li> <t>When a value is added to the "ICMP Type Numbers" registry, a new
</ul> "enum" statement must be added to the "iana-icmpv4-types" YANG
<t>When a value is added to the "ICMP Type Numbers" registry, a new "e module. The "enum" statement, and substatements thereof, should be
num" statement defined as follows:</t>
must be added to the "iana-icmpv4-types" YANG module. The "enum" statement,
and sub-statements thereof, should be defined:</t>
<dl> <dl>
<dt>"enum":</dt> <dt>"enum":</dt>
<dd> <dd>
<t>Replicates the name from the registry with all illegal characte rs (e.g., spaces) are striped.</t> <t>Replicates the name from the registry with all illegal characte rs (e.g., spaces) are striped.</t>
</dd> </dd>
<dt>"value":</dt> <dt>"value":</dt>
<dd> <dd>
<t>Contains the decimal value of the IANA-assigned value.</t> <t>Contains the decimal value of the IANA-assigned value.</t>
</dd> </dd>
<dt>"status":</dt> <dt>"status":</dt>
<dd> <dd>
<t>Is included only if a registration has been deprecated <t>Included only if a registration has been deprecated
or obsoleted. IANA "deprecated" maps to YANG status or obsoleted. IANA "deprecated" maps to YANG status
"deprecated", and IANA "obsolete" maps to YANG status "deprecated", and IANA "obsolete" maps to YANG status
"obsolete".</t> "obsolete".</t>
</dd> </dd>
<dt>"description":</dt> <dt>"description":</dt>
<dd> <dd>
<t>Replicates the name from the registry.</t> <t>Replicates the name from the registry.</t>
</dd> </dd>
<dt>"reference":</dt> <dt>"reference":</dt>
<dd> <dd>
<t>Replicates the reference(s) from the registry with the <t>Replicates the reference(s) from the registry with the
title of the document(s) added.</t> title of the document(s) added.</t>
</dd> </dd>
</dl> </dl>
<t>Unassigned, reserved, or <xref target="RFC3692"/>-style values are not present in the module.</t> <t>Unassigned, reserved, or values styled like those in <xref target=" RFC3692"/> are not present in the module.</t>
<t>When the "iana-icmpv4-types" YANG module is updated, a new "revisio n" <t>When the "iana-icmpv4-types" YANG module is updated, a new "revisio n"
statement with a unique revision date must be added in front of the statement with a unique revision date must be added in front of the
existing revision statements.</t> existing revision statements.</t>
<t>IANA is requested to add this note to "ICMP Type Numbers" <xref tar <t>IANA has added this note to "ICMP Type Numbers" registry <xref targ
get="IANA-ICMPv4"/>:</t> et="IANA-ICMPv4"/> and listed this document as an additional reference for the r
<artwork><![CDATA[ egistry:</t>
When this registry is modified, the YANG module "iana-icmpv4-types"
[IANA_ICMPv4_YANG_URL] must be updated as defined in RFC XXXX. <blockquote>When this registry is modified, the YANG module
]]></artwork> "iana-icmpv4-types" <xref target="IANA-YANG-PARAMETERS"/> must be updat
<t>IANA is requested to update the "Reference" in the "ICMP Type Numbe ed as
rs" registry defined in RFC 9899.</blockquote>
as follows:</t>
<dl>
<dt>OLD:</dt>
<dd>
<t><xref target="RFC2780"/></t>
</dd>
<dt>NEW:</dt>
<dd>
<t><xref target="RFC2780"/>[RFCXXXX]</t>
</dd>
</dl>
</section> </section>
<section anchor="icmpv6-types-iana-module"> <section anchor="icmpv6-types-iana-module">
<name>ICMPv6 Types IANA Module</name> <name>ICMPv6 Types IANA Module</name>
<t>This document defines the initial version of the IANA-maintained <t>This document defines the initial version of the IANA-maintained
"iana-icmpv6-types" YANG module. The most recent version of the YANG module "iana-icmpv6-types" YANG module. The most recent version of the YANG
is available from the "YANG Parameters" registry module is available in the "YANG Parameters" registry group <xref
<xref target="IANA-YANG-PARAMETERS"/>.</t> target="IANA-YANG-PARAMETERS"/>.</t>
<t>IANA is requested to add this note to the registry <xref target="IA
NA-YANG-PARAMETERS"/>:</t> <t>IANA has added this note to the registry:</t>
<ul empty="true">
<li> <blockquote>New values must not be directly added to the
<t>New values must not be directly added to the "iana-icmpv6-types "iana-icmpv6-types" YANG module. They must instead be added to the
" YANG module. They must instead be added to the "ICMPv6 "type" Numbers" registr "ICMPv6 "type" Numbers" registry <xref
y <xref target="IANA-ICMPv6"/>.</t> target="IANA-ICMPv6"/>.</blockquote>
</li>
</ul> <t>When a value is added to the "ICMPv6 "type" Numbers" registry, a
<t>When a value is added to the "ICMPv6 "type" Numbers" registry, a ne new "enum" statement must be added to the "iana-icmpv6-types" YANG
w "enum" statement module. The "enum" statement, and substatements thereof, should be
must be added to the "iana-icmpv6-types" YANG module. The "enum" statement, defined as follows:</t>
and sub-statements thereof, should be defined:</t>
<dl> <dl>
<dt>"enum":</dt> <dt>"enum":</dt>
<dd> <dd>
<t>Replicates the name from the registry with all illegal characte rs (e.g., spaces) striped.</t> <t>Replicates the name from the registry with all illegal characte rs (e.g., spaces) striped.</t>
</dd> </dd>
<dt>"value":</dt> <dt>"value":</dt>
<dd> <dd>
<t>Contains the decimal value of the IANA-assigned value.</t> <t>Contains the decimal value of the IANA-assigned value.</t>
</dd> </dd>
<dt>"status":</dt> <dt>"status":</dt>
<dd> <dd>
<t>Is included only if a registration has been deprecated <t>Included only if a registration has been deprecated
or obsoleted. IANA "deprecated" maps to YANG status or obsoleted. IANA "deprecated" maps to YANG status
"deprecated", and IANA "obsolete" maps to YANG status "deprecated", and IANA "obsolete" maps to YANG status
"obsolete".</t> "obsolete".</t>
</dd> </dd>
<dt>"description":</dt> <dt>"description":</dt>
<dd> <dd>
<t>Replicates the name from the registry.</t> <t>Replicates the name from the registry.</t>
</dd> </dd>
<dt>"reference":</dt> <dt>"reference":</dt>
<dd> <dd>
<t>Replicates the reference(s) from the registry with the <t>Replicates the reference(s) from the registry with the
title of the document(s) added.</t> title of the document(s) added.</t>
</dd> </dd>
</dl> </dl>
<t>Unassigned, reserved, or private experimentation values are not pre sent in the module.</t> <t>Unassigned, reserved, or private experimentation values are not pre sent in the module.</t>
<t>When the "iana-icmpv6-types" YANG module is updated, a new "revisio <t>When the "iana-icmpv6-types" YANG module is updated, a new
n" "revision" statement with a unique revision date must be added in
statement with a unique revision date must be added in front of the front of the existing revision statements.</t>
existing revision statements.</t>
<t>IANA is requested to add this note to "ICMPv6 "type" Numbers" <xref <t>IANA has added this note to the "ICMPv6 "type" Numbers" registry <x
target="IANA-ICMPv6"/>:</t> ref target="IANA-ICMPv6"/> and listed this document as an additional reference f
<artwork><![CDATA[ or the registry:</t>
When this registry is modified, the YANG module "iana-icmpv6-types"
[IANA_ICMPv6_YANG_URL] must be updated as defined in RFC XXXX. <blockquote>When this registry is modified, the YANG module
]]></artwork> "iana-icmpv6-types" <xref target="IANA-YANG-PARAMETERS"/> must be updat
<t>IANA is requested to update the "Reference" in the "ICMPv6 "type" N ed as
umbers" registry defined in RFC 9899.</blockquote>
as follows:</t>
<dl>
<dt>OLD:</dt>
<dd>
<t><xref target="RFC4443"/></t>
</dd>
<dt>NEW:</dt>
<dd>
<t><xref target="RFC4443"/>[RFCXXXX]</t>
</dd>
</dl>
</section> </section>
<section anchor="ipv6-extension-header-types-iana-module"> <section anchor="ipv6-extension-header-types-iana-module">
<name>IPv6 Extension Header Types IANA Module</name> <name>IPv6 Extension Header Types IANA Module</name>
<t>This document defines the initial version of the IANA-maintained <t>This document defines the initial version of the IANA-maintained
"iana-ipv6-ext-types" YANG module. The most recent version of the YANG module "iana-ipv6-ext-types" YANG module. The most recent version of the
is available from the "YANG Parameters" registry YANG module is available in the "YANG Parameters" registry group <xref
<xref target="IANA-YANG-PARAMETERS"/>.</t> target="IANA-YANG-PARAMETERS"/>.</t>
<t>IANA is requested to add this note to the registry <xref target="IA
NA-YANG-PARAMETERS"/>:</t> <t>IANA has added this note to the registry:</t>
<ul empty="true">
<li> <blockquote>New values must not be directly added to the
<t>New values must not be directly added to the "iana-ipv6-ext-typ "iana-ipv6-ext-types" YANG module. They must instead be added to
es" YANG module. They must instead be added to the "IPv6 Extension Header Types the "IPv6 Extension Header Types" registry <xref
" registry <xref target="IANA-IPv6"/>.</t> target="IANA-IPv6"/>.</blockquote>
</li>
</ul> <t>When a value is added to the "IPv6 Extension Header Types"
<t>When a value is added to the "IPv6 Extension Header Types" registry registry, a new "enum" statement must be added to the
, a new "enum" statement "iana-ipv6-ext-types" YANG module. The "enum" statement, and
must be added to the "iana-ipv6-ext-types" YANG module. The "enum" statement, substatements thereof, should be defined as follows</t>
and sub-statements thereof, should be defined:</t>
<dl> <dl>
<dt>"enum":</dt> <dt>"enum":</dt>
<dd> <dd>
<t>Replicates the description from the registry with all spaces st riped.</t> <t>Replicates the description from the registry with all spaces st riped.</t>
</dd> </dd>
<dt>"value":</dt> <dt>"value":</dt>
<dd> <dd>
<t>Contains the decimal value of the IANA-assigned value.</t> <t>Contains the decimal value of the IANA-assigned value.</t>
</dd> </dd>
<dt>"status":</dt> <dt>"status":</dt>
<dd> <dd>
<t>Is included only if a registration has been deprecated <t>Included only if a registration has been deprecated or
or obsoleted. IANA "deprecated" maps to YANG status obsoleted. IANA "deprecated" maps to YANG status "deprecated",
"deprecated", and IANA "obsolete" maps to YANG status and IANA "obsolete" maps to YANG status "obsolete".</t>
"obsolete".</t>
</dd> </dd>
<dt>"description":</dt> <dt>"description":</dt>
<dd> <dd>
<t>Replicates the description from the registry.</t> <t>Replicates the description from the registry.</t>
</dd> </dd>
<dt>"reference":</dt> <dt>"reference":</dt>
<dd> <dd>
<t>Replicates the reference(s) from the registry with the <t>Replicates the reference(s) from the registry with the
title of the document(s) added.</t> title of the document(s) added.</t>
</dd> </dd>
</dl> </dl>
<t>Unassigned or reserved values are not present in the module.</t> <t>Unassigned or reserved values are not present in the module.</t>
<t>When the "iana-ipv6-ext-types" YANG module is updated, a new "revis ion" <t>When the "iana-ipv6-ext-types" YANG module is updated, a new "revis ion"
statement with a unique revision date must be added in front of the statement with a unique revision date must be added in front of the
existing revision statements.</t> existing revision statements.</t>
<t>IANA is requested to add this note to the "IPv6 Extension Header Ty
pes" registry <xref target="IANA-IPv6"/>:</t> <t>IANA has added this note to the "IPv6 Extension Header Types" regis
<artwork><![CDATA[ try <xref target="IANA-IPv6"/> and listed this document as an additional referen
When this registry is modified, the YANG module "iana-ipv6-ext-types" ce for the registry:</t>
[IANA_IPV6_YANG_URL] must be updated as defined in RFC XXXX.
]]></artwork> <blockquote>When this registry is modified, the YANG module
<t>IANA is requested to update the "Reference" in the "IPv6 Extension "iana-ipv6-ext-types" <xref target="IANA-YANG-PARAMETERS"/> must be upd
Header Types" registry ated as
as follows:</t> defined in RFC 9899.</blockquote>
<dl>
<dt>OLD:</dt>
<dd>
<t><xref target="RFC2780"/><xref target="RFC5237"/><xref target="R
FC7045"/></t>
</dd>
<dt>NEW:</dt>
<dd>
<t><xref target="RFC2780"/><xref target="RFC5237"/><xref target="R
FC7045"/>[RFCXXXX]</t>
</dd>
</dl>
</section> </section>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-netmod-rfc8407bis" to="YANG-GUIDELINES"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="IANA-ICMPv4" target="https://www.iana.org/assignments /icmp-parameters/icmp-parameters.xhtml"> <reference anchor="IANA-ICMPv4" target="https://www.iana.org/assignments /icmp-parameters">
<front> <front>
<title>ICMP Type Numbers</title> <title>ICMP Type Numbers</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IANA-ICMPv6" target="https://www.iana.org/assignments /icmpv6-parameters/icmpv6-parameters.xhtml"> <reference anchor="IANA-ICMPv6" target="https://www.iana.org/assignments /icmpv6-parameters">
<front> <front>
<title>ICMPv6 type Numbers</title> <title>ICMPv6 "type" Numbers</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IANA-IPv6" target="https://www.iana.org/assignments/i pv6-parameters/ipv6-parameters.xhtml"> <reference anchor="IANA-IPv6" target="https://www.iana.org/assignments/i pv6-parameters">
<front> <front>
<title>IPv6 Extension Header Types</title> <title>IPv6 Extension Header Types</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front>
</reference>
<reference anchor="RFC8519">
<front>
<title>YANG Data Model for Network Access Control Lists (ACLs)</titl
e>
<author fullname="M. Jethanandani" initials="M." surname="Jethananda
ni"/>
<author fullname="S. Agarwal" initials="S." surname="Agarwal"/>
<author fullname="L. Huang" initials="L." surname="Huang"/>
<author fullname="D. Blair" initials="D." surname="Blair"/>
<date month="March" year="2019"/>
<abstract>
<t>This document defines a data model for Access Control Lists (AC
Ls). An ACL is a user-ordered set of rules used to configure the forwarding beha
vior in a device. Each rule is used to find a match on a packet and define actio
ns that will be performed on the packet.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8519"/>
<seriesInfo name="DOI" value="10.17487/RFC8519"/>
</reference>
<reference anchor="RFC8342">
<front>
<title>Network Management Datastore Architecture (NMDA)</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwae
lder"/>
<author fullname="P. Shafer" initials="P." surname="Shafer"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<author fullname="R. Wilton" initials="R." surname="Wilton"/>
<date month="March" year="2018"/>
<abstract>
<t>Datastores are a fundamental concept binding the data models wr
itten in the YANG data modeling language to network management protocols such as
the Network Configuration Protocol (NETCONF) and RESTCONF. This document define
s an architectural framework for datastores based on the experience gained with
the initial simpler model, addressing requirements that were not well supported
in the initial model. This document updates RFC 7950.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8342"/>
<seriesInfo name="DOI" value="10.17487/RFC8342"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC7950">
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<author fullname="M. Bjorklund" initials="M." role="editor" surname=
"Bjorklund"/>
<date month="August" year="2016"/>
<abstract>
<t>YANG is a data modeling language used to model configuration da
ta, state data, Remote Procedure Calls, and notifications for network management
protocols. This document describes the syntax and semantics of version 1.1 of t
he YANG language. YANG version 1.1 is a maintenance release of the YANG language
, addressing ambiguities and defects in the original specification. There are a
small number of backward incompatibilities from YANG version 1. This document al
so specifies the YANG mappings to the Network Configuration Protocol (NETCONF).<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="7950"/>
<seriesInfo name="DOI" value="10.17487/RFC7950"/>
</reference>
<reference anchor="RFC0792">
<front>
<title>Internet Control Message Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel"/>
<date month="September" year="1981"/>
</front>
<seriesInfo name="STD" value="5"/>
<seriesInfo name="RFC" value="792"/>
<seriesInfo name="DOI" value="10.17487/RFC0792"/>
</reference>
<reference anchor="RFC4443">
<front>
<title>Internet Control Message Protocol (ICMPv6) for the Internet P
rotocol Version 6 (IPv6) Specification</title>
<author fullname="A. Conta" initials="A." surname="Conta"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<author fullname="M. Gupta" initials="M." role="editor" surname="Gup
ta"/>
<date month="March" year="2006"/>
<abstract>
<t>This document describes the format of a set of control messages
used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Cont
rol Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]</
t>
</abstract>
</front>
<seriesInfo name="STD" value="89"/>
<seriesInfo name="RFC" value="4443"/>
<seriesInfo name="DOI" value="10.17487/RFC4443"/>
</reference>
<reference anchor="RFC8200">
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<date month="July" year="2017"/>
<abstract>
<t>This document specifies version 6 of the Internet Protocol (IPv
6). It obsoletes RFC 2460.</t>
</abstract>
</front>
<seriesInfo name="STD" value="86"/>
<seriesInfo name="RFC" value="8200"/>
<seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>
<reference anchor="RFC9293">
<front>
<title>Transmission Control Protocol (TCP)</title>
<author fullname="W. Eddy" initials="W." role="editor" surname="Eddy
"/>
<date month="August" year="2022"/>
<abstract>
<t>This document specifies the Transmission Control Protocol (TCP)
. TCP is an important transport-layer protocol in the Internet protocol stack, a
nd it has continuously evolved over decades of use and growth of the Internet. O
ver this time, a number of changes have been made to TCP as it was specified in
RFC 793, though these have only been documented in a piecemeal fashion. This doc
ument collects and brings those changes together with the protocol specification
from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,
6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 11
22, and it should be considered as a replacement for the portions of those docum
ents dealing with TCP requirements. It also updates RFC 5961 by adding a small c
larification in reset handling while in the SYN-RECEIVED state. The TCP header c
ontrol bits from RFC 793 have also been updated based on RFC 3168.</t>
</abstract>
</front>
<seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="9293"/>
<seriesInfo name="DOI" value="10.17487/RFC9293"/>
</reference>
<reference anchor="RFC3032">
<front>
<title>MPLS Label Stack Encoding</title>
<author fullname="E. Rosen" initials="E." surname="Rosen"/>
<author fullname="D. Tappan" initials="D." surname="Tappan"/>
<author fullname="G. Fedorkow" initials="G." surname="Fedorkow"/>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<author fullname="A. Conta" initials="A." surname="Conta"/>
<date month="January" year="2001"/>
<abstract>
<t>This document specifies the encoding to be used by an LSR in or
der to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on
LAN data links, and possibly on other data links as well. This document also spe
cifies rules and procedures for processing the various fields of the label stack
encoding. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3032"/>
<seriesInfo name="DOI" value="10.17487/RFC3032"/>
</reference>
<reference anchor="RFC5462">
<front>
<title>Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP"
Field Renamed to "Traffic Class" Field</title>
<author fullname="L. Andersson" initials="L." surname="Andersson"/>
<author fullname="R. Asati" initials="R." surname="Asati"/>
<date month="February" year="2009"/>
<abstract>
<t>The early Multiprotocol Label Switching (MPLS) documents define
d the form of the MPLS label stack entry. This includes a three-bit field called
the "EXP field". The exact use of this field was not defined by these documents
, except to state that it was to be "reserved for experimental use".</t>
<t>Although the intended use of the EXP field was as a "Class of S
ervice" (CoS) field, it was not named a CoS field by these early documents becau
se the use of such a CoS field was not considered to be sufficiently defined. To
day a number of standards documents define its usage as a CoS field.</t>
<t>To avoid misunderstanding about how this field may be used, it
has become increasingly necessary to rename this field. This document changes th
e name of the field to the "Traffic Class field" ("TC field"). In doing so, it a
lso updates documents that define the current use of the EXP field. [STANDARDS-T
RACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5462"/>
<seriesInfo name="DOI" value="10.17487/RFC5462"/>
</reference>
<reference anchor="RFC6991">
<front>
<title>Common YANG Data Types</title>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder"/>
<date month="July" year="2013"/>
<abstract>
<t>This document introduces a collection of common data types to b
e used with the YANG data modeling language. This document obsoletes RFC 6021.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="6991"/>
<seriesInfo name="DOI" value="10.17487/RFC6991"/>
</reference>
<reference anchor="RFC8294">
<front>
<title>Common YANG Data Types for the Routing Area</title>
<author fullname="X. Liu" initials="X." surname="Liu"/>
<author fullname="Y. Qu" initials="Y." surname="Qu"/>
<author fullname="A. Lindem" initials="A." surname="Lindem"/>
<author fullname="C. Hopps" initials="C." surname="Hopps"/>
<author fullname="L. Berger" initials="L." surname="Berger"/>
<date month="December" year="2017"/>
<abstract>
<t>This document defines a collection of common data types using t
he YANG data modeling language. These derived common types are designed to be im
ported by other modules defined in the routing area.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8294"/>
<seriesInfo name="DOI" value="10.17487/RFC8294"/>
</reference>
<reference anchor="RFC8341">
<front>
<title>Network Configuration Access Control Model</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<date month="March" year="2018"/>
<abstract>
<t>The standardization of network configuration interfaces for use
with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requ
ires a structured and secure operating environment that promotes human usability
and multi-vendor interoperability. There is a need for standard mechanisms to r
estrict NETCONF or RESTCONF protocol access for particular users to a preconfigu
red subset of all available NETCONF or RESTCONF protocol operations and content.
This document defines such an access control model.</t>
<t>This document obsoletes RFC 6536.</t>
</abstract>
</front>
<seriesInfo name="STD" value="91"/>
<seriesInfo name="RFC" value="8341"/>
<seriesInfo name="DOI" value="10.17487/RFC8341"/>
</reference>
<reference anchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author fullname="M. Mealling" initials="M." surname="Mealling"/>
<date month="January" year="2004"/>
<abstract>
<t>This document describes an IANA maintained registry for IETF st
andards which use Extensible Markup Language (XML) related items such as Namespa
ces, Document Type Declarations (DTDs), Schemas, and Resource Description Framew
ork (RDF) Schemas.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference>
<reference anchor="RFC6020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)</title>
<author fullname="M. Bjorklund" initials="M." role="editor" surname=
"Bjorklund"/>
<date month="October" year="2010"/>
<abstract>
<t>YANG is a data modeling language used to model configuration an
d state data manipulated by the Network Configuration Protocol (NETCONF), NETCON
F remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="6020"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
342.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
950.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
792.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
443.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
200.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
293.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
032.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
462.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
991.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
294.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
688.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
020.xml"/>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="IANA-YANG-PARAMETERS" target="https://www.iana.org/as signments/yang-parameters"> <reference anchor="IANA-YANG-PARAMETERS" target="https://www.iana.org/as signments/yang-parameters">
<front> <front>
<title>YANG Parameters</title> <title>YANG Parameters</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IANA-TCP-FLAGS" target="https://www.iana.org/assignme nts/tcp-parameters/"> <reference anchor="IANA-TCP-FLAGS" target="https://www.iana.org/assignme nts/tcp-parameters">
<front> <front>
<title>Transmission Control Protocol (TCP) Parameters</title> <title>Transmission Control Protocol (TCP) Parameters</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IANA_ICMPv4_YANG_URL" target="https://www.iana.org/as signments/icmpv6-parameters/iana-icmpv6-types.xhtml"> <!-- <reference anchor="IANA_ICMPv6_YANG_URL" target="https://www.iana.or g/assignments/yang-parameters/">
<front> <front>
<title>iana-icmpv6-types YANG Module</title> <title>iana-icmpv6-types YANG Module</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IANA_ICMPv6_YANG_URL" target="https://www.iana.org/as signments/icmp-parameters/iana-ipv6-ext-types.xhtml"> <reference anchor="IANA_ICMPv4_YANG_URL" target="https://www.iana.org/assignm ents/yang-parameters/">
<front> <front>
<title>iana-icmpv4-types YANG Module</title> <title>iana-icmpv4-types YANG Module</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IANA_IPV6_YANG_URL" target="https://www.iana.org/assi gnments/ipv6-parameters/iana-icmpv6-types.xhtml"> <reference anchor="IANA_IPV6_YANG_URL" target="https://www.iana.org/assi gnments/yang-parameters">
<front> <front>
<title>iana-ipv6-ext-types YANG Module</title> <title>iana-ipv6-ext-types YANG Module</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IEEE-802-1ah" target="https://standards.ieee.org/stan -->
dard/802_1ah-2008.html">
<reference anchor="IEEE-802-1ah" >
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks -- Vir tual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges</title> <title>IEEE Standard for Local and metropolitan area networks -- Vir tual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges</title>
<author initials="" surname="IEEE" fullname="IEEE"> <author initials="" surname="IEEE" fullname="IEEE">
<organization/> <organization/>
</author> </author>
<date year="2008" month="August"/> <date year="2008" month="August"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1ah-2008"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4602826"/>
</reference> </reference>
<reference anchor="IEEE802.1Qcp" target="https://doi.org/10.1109/IEEESTD
.2018.8467507"> <reference anchor="IEEE802.1Qcp">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks--Bridg es and Bridged Networks--Amendment 30: YANG Data Model</title> <title>IEEE Standard for Local and metropolitan area networks--Bridg es and Bridged Networks--Amendment 30: YANG Data Model</title>
<author initials="" surname="IEEE" fullname="IEEE"> <author>
<organization/> <organization>IEEE</organization>
</author> </author>
<date year="2018" month="September"/> <date year="2018" month="September"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1Qcp-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8467507"/>
</reference> </reference>
<reference anchor="YANG-XSLT" target="https://github.com/llhotka/iana-ya ng"> <reference anchor="YANG-XSLT" target="https://github.com/llhotka/iana-ya ng">
<front> <front>
<title>iana-yang</title> <title>iana-yang</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date month="December" year="2021"/>
</front>
</reference>
<reference anchor="RFC9132">
<front>
<title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Si
gnal Channel Specification</title>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="J. Shallow" initials="J." surname="Shallow"/>
<author fullname="T. Reddy.K" initials="T." surname="Reddy.K"/>
<date month="September" year="2021"/>
<abstract>
<t>This document specifies the Distributed Denial-of-Service Open
Threat Signaling (DOTS) signal channel, a protocol for signaling the need for pr
otection against Distributed Denial-of-Service (DDoS) attacks to a server capabl
e of enabling network traffic mitigation on behalf of the requesting client.</t>
<t>A companion document defines the DOTS data channel, a separate
reliable communication layer for DOTS management and configuration purposes.</t>
<t>This document obsoletes RFC 8782.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9132"/>
<seriesInfo name="DOI" value="10.17487/RFC9132"/>
</reference>
<reference anchor="RFC8955">
<front>
<title>Dissemination of Flow Specification Rules</title>
<author fullname="C. Loibl" initials="C." surname="Loibl"/>
<author fullname="S. Hares" initials="S." surname="Hares"/>
<author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
<author fullname="D. McPherson" initials="D." surname="McPherson"/>
<author fullname="M. Bacher" initials="M." surname="Bacher"/>
<date month="December" year="2020"/>
<abstract>
<t>This document defines a Border Gateway Protocol Network Layer R
eachability Information (BGP NLRI) encoding format that can be used to distribut
e (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast a
nd IPv4 BGP/MPLS VPN services. This allows the routing system to propagate infor
mation regarding more specific components of the traffic aggregate defined by an
IP destination prefix.</t>
<t>It also specifies BGP Extended Community encoding formats, whic
h can be used to propagate Traffic Filtering Actions along with the Flow Specifi
cation NLRI. Those Traffic Filtering Actions encode actions a routing system can
take if the packet matches the Flow Specification.</t>
<t>This document obsoletes both RFC 5575 and RFC 7674.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8955"/>
<seriesInfo name="DOI" value="10.17487/RFC8955"/>
</reference>
<reference anchor="RFC8956">
<front>
<title>Dissemination of Flow Specification Rules for IPv6</title>
<author fullname="C. Loibl" initials="C." role="editor" surname="Loi
bl"/>
<author fullname="R. Raszuk" initials="R." role="editor" surname="Ra
szuk"/>
<author fullname="S. Hares" initials="S." role="editor" surname="Har
es"/>
<date month="December" year="2020"/>
<abstract>
<t>"Dissemination of Flow Specification Rules" (RFC 8955) provides
a Border Gateway Protocol (BGP) extension for the propagation of traffic flow i
nformation for the purpose of rate limiting or filtering IPv4 protocol data pack
ets.</t>
<t>This document extends RFC 8955 with IPv6 functionality. It also
updates RFC 8955 by changing the IANA Flow Spec Component Types registry.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8956"/>
<seriesInfo name="DOI" value="10.17487/RFC8956"/>
</reference>
<reference anchor="I-D.ietf-netmod-rfc8407bis">
<front>
<title>Guidelines for Authors and Reviewers of Documents Containing
YANG Data Models</title>
<author fullname="Andy Bierman" initials="A." surname="Bierman">
<organization>YumaWorks</organization>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
</author>
<date day="14" month="January" year="2025"/>
<abstract>
<t> This memo provides guidelines for authors and reviewers of
specifications containing YANG modules, including IANA-maintained
modules. Recommendations and procedures are defined, which are
intended to increase interoperability and usability of Network
Configuration Protocol (NETCONF) and RESTCONF protocol
implementations that utilize YANG modules. This document obsoletes
RFC 8407.
Also, this document updates RFC 8126 by providing additional
guidelines for writing the IANA considerations for RFCs that specify
IANA-maintained modules. The document also updates RFC 6020 by
clarifying how modules and their revisions are handled by IANA.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis-
22"/>
</reference>
<reference anchor="RFC8340">
<front>
<title>YANG Tree Diagrams</title>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="L. Berger" initials="L." role="editor" surname="Be
rger"/>
<date month="March" year="2018"/>
<abstract>
<t>This document captures the current syntax used in YANG module t
ree diagrams. The purpose of this document is to provide a single location for t
his definition. This syntax may be updated from time to time based on the evolut
ion of the YANG language.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="215"/>
<seriesInfo name="RFC" value="8340"/>
<seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference>
<reference anchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communica
tion, low-latency connection establishment, and network path migration. QUIC inc
ludes security measures that ensure confidentiality, integrity, and availability
in a range of deployment circumstances. Accompanying documents describe the int
egration of TLS for key negotiation, loss detection, and an exemplary congestion
control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC7209">
<front>
<title>Requirements for Ethernet VPN (EVPN)</title>
<author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
<author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
<author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
<author fullname="N. Bitar" initials="N." surname="Bitar"/>
<author fullname="W. Henderickx" initials="W." surname="Henderickx"/
>
<author fullname="A. Isaac" initials="A." surname="Isaac"/>
<date month="May" year="2014"/>
<abstract>
<t>The widespread adoption of Ethernet L2VPN services and the adve
nt of new applications for the technology (e.g., data center interconnect) have
culminated in a new set of requirements that are not readily addressable by the
current Virtual Private LAN Service (VPLS) solution. In particular, multihoming
with all-active forwarding is not supported, and there's no existing solution to
leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optim
izing the delivery of multi-destination frames. Furthermore, the provisioning of
VPLS, even in the context of BGP-based auto-discovery, requires network operato
rs to specify various network parameters on top of the access configuration. Thi
s document specifies the requirements for an Ethernet VPN (EVPN) solution, which
addresses the above issues.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7209"/>
<seriesInfo name="DOI" value="10.17487/RFC7209"/>
</reference>
<reference anchor="RFC6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname="R. Enns" initials="R." role="editor" surname="Enns
"/>
<author fullname="M. Bjorklund" initials="M." role="editor" surname=
"Bjorklund"/>
<author fullname="J. Schoenwaelder" initials="J." role="editor" surn
ame="Schoenwaelder"/>
<author fullname="A. Bierman" initials="A." role="editor" surname="B
ierman"/>
<date month="June" year="2011"/>
<abstract>
<t>The Network Configuration Protocol (NETCONF) defined in this do
cument provides mechanisms to install, manipulate, and delete the configuration
of network devices. It uses an Extensible Markup Language (XML)-based data encod
ing for the configuration data as well as the protocol messages. The NETCONF pro
tocol operations are realized as remote procedure calls (RPCs). This document ob
soletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC8040">
<front>
<title>RESTCONF Protocol</title>
<author fullname="A. Bierman" initials="A." surname="Bierman"/>
<author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
<author fullname="K. Watsen" initials="K." surname="Watsen"/>
<date month="January" year="2017"/>
<abstract>
<t>This document describes an HTTP-based protocol that provides a
programmatic interface for accessing data defined in YANG, using the datastore c
oncepts defined in the Network Configuration Protocol (NETCONF).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8040"/>
<seriesInfo name="DOI" value="10.17487/RFC8040"/>
</reference>
<reference anchor="RFC4252">
<front>
<title>The Secure Shell (SSH) Authentication Protocol</title>
<author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
<author fullname="C. Lonvick" initials="C." role="editor" surname="L
onvick"/>
<date month="January" year="2006"/>
<abstract>
<t>The Secure Shell Protocol (SSH) is a protocol for secure remote
login and other secure network services over an insecure network. This document
describes the SSH authentication protocol framework and public key, password, a
nd host-based client authentication methods. Additional authentication methods a
re described in separate documents. The SSH authentication protocol runs on top
of the SSH transport layer protocol and provides a single authenticated tunnel f
or the SSH connection protocol. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4252"/>
<seriesInfo name="DOI" value="10.17487/RFC4252"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8329">
<front>
<title>Framework for Interface to Network Security Functions</title>
<author fullname="D. Lopez" initials="D." surname="Lopez"/>
<author fullname="E. Lopez" initials="E." surname="Lopez"/>
<author fullname="L. Dunbar" initials="L." surname="Dunbar"/>
<author fullname="J. Strassner" initials="J." surname="Strassner"/>
<author fullname="R. Kumar" initials="R." surname="Kumar"/>
<date month="February" year="2018"/>
<abstract>
<t>This document describes the framework for Interface to Network
Security Functions (I2NSF) and defines a reference model (including major functi
onal components) for I2NSF. Network Security Functions (NSFs) are packet-process
ing engines that inspect and optionally modify packets traversing networks, eith
er directly or in the context of sessions to which the packet is associated.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8329"/>
<seriesInfo name="DOI" value="10.17487/RFC8329"/>
</reference>
<reference anchor="RFC3692">
<front>
<title>Assigning Experimental and Testing Numbers Considered Useful<
/title>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="January" year="2004"/>
<abstract>
<t>When experimenting with or extending protocols, it is often nec
essary to use some sort of protocol number or constant in order to actually test
or experiment with the new function, even when testing in a closed environment.
For example, to test a new DHCP option, one needs an option number to identify
the new function. This document recommends that when writing IANA Considerations
sections, authors should consider assigning a small range of numbers for experi
mentation purposes that implementers can use when testing protocol extensions or
other new features. This document reserves some ranges of numbers for experimen
tation purposes in specific protocols where the need to support experimentation
has been identified.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="82"/>
<seriesInfo name="RFC" value="3692"/>
<seriesInfo name="DOI" value="10.17487/RFC3692"/>
</reference>
<reference anchor="RFC2780">
<front>
<title>IANA Allocation Guidelines For Values In the Internet Protoco
l and Related Headers</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<author fullname="V. Paxson" initials="V." surname="Paxson"/>
<date month="March" year="2000"/>
<abstract>
<t>This memo provides guidance for the IANA to use in assigning pa
rameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This
document specifies an Internet Best Current Practices for the Internet Community
, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="37"/>
<seriesInfo name="RFC" value="2780"/>
<seriesInfo name="DOI" value="10.17487/RFC2780"/>
</reference>
<reference anchor="RFC5237">
<front>
<title>IANA Allocation Guidelines for the Protocol Field</title>
<author fullname="J. Arkko" initials="J." surname="Arkko"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="February" year="2008"/>
<abstract>
<t>This document revises the IANA guidelines for allocating new Pr
otocol field values in IPv4 header. It modifies the rules specified in RFC 2780
by removing the Expert Review option. The change will also affect the allocation
of Next Header field values in IPv6. This document specifies an Internet Best C
urrent Practices for the Internet Community, and requests discussion and suggest
ions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="37"/>
<seriesInfo name="RFC" value="5237"/>
<seriesInfo name="DOI" value="10.17487/RFC5237"/>
</reference>
<reference anchor="RFC7045">
<front>
<title>Transmission and Processing of IPv6 Extension Headers</title>
<author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
<author fullname="S. Jiang" initials="S." surname="Jiang"/>
<date month="December" year="2013"/>
<abstract>
<t>Various IPv6 extension headers have been standardised since the
IPv6 standard was first published. This document updates RFC 2460 to clarify ho
w intermediate nodes should deal with such extension headers and with any that a
re defined in the future. It also specifies how extension headers should be regi
stered by IANA, with a corresponding minor update to RFC 2780.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="7045"/> <refcontent>commit 3a6cb69</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC7045"/>
</reference> </reference>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</references> 132.xml"/>
<?line 2006?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
955.xml"/>
<section anchor="iana-icmp"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<name>Initial Version of the ICMPv4 Types IANA-Maintained Module</name> 956.xml"/>
<sourcecode markers="true" name="iana-icmpv4-types@2020-09-25.yang"><![CDA
TA[
module iana-icmpv4-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-icmpv4-types";
prefix iana-icmpv4-types;
organization
"Internet Assigned Numbers Authority (IANA)";
contact
"Internet Assigned Numbers Authority
ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
Tel: +1 424 254 5300
<mailto:iana@iana.org>";
description
"This YANG module translates IANA registry 'ICMP Type Numbers' to
YANG derived types.
Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
The initial version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices.
This version of this YANG module was generated from the
corresponding IANA registry using an XSLT stylesheet from the
'iana-yang' project (https://github.com/llhotka/iana-yang).";
reference
"Internet Control Message Protocol (ICMP) Parameters
(https://www.iana.org/assignments/icmp-parameters/)";
revision 2020-09-25 {
description
"Current revision as of the revision date specified in the XML
representation of the registry page.";
reference
"https://www.iana.org/assignments/icmp-parameters/
icmp-parameters.xml";
}
/* Typedefs */
typedef icmpv4-type-name {
type enumeration {
enum EchoReply {
value 0;
description
"Echo Reply";
reference
"RFC 792";
}
enum DestinationUnreachable {
value 3;
description
"Destination Unreachable";
reference
"RFC 792";
}
enum SourceQuench {
value 4;
status deprecated;
description
"Source Quench (Deprecated)";
reference
"- RFC 792
- RFC 6633";
}
enum Redirect {
value 5;
description
"Redirect";
reference
"RFC 792";
}
enum AlternateHostAddress {
value 6;
status deprecated;
description
"Alternate Host Address (Deprecated)";
reference
"RFC 6918";
}
enum Echo {
value 8;
description
"Echo";
reference
"RFC 792";
}
enum RouterAdvertisement {
value 9;
description
"Router Advertisement";
reference
"RFC 1256";
}
enum RouterSolicitation {
value 10;
description
"Router Solicitation";
reference
"RFC 1256";
}
enum TimeExceeded {
value 11;
description
"Time Exceeded";
reference
"RFC 792";
}
enum ParameterProblem {
value 12;
description
"Parameter Problem";
reference
"RFC 792";
}
enum Timestamp {
value 13;
description
"Timestamp";
reference
"RFC 792";
}
enum TimestampReply {
value 14;
description
"Timestamp Reply";
reference
"RFC 792";
}
enum InformationRequest {
value 15;
status deprecated;
description
"Information Request (Deprecated)";
reference
"- RFC 792
- RFC 6918";
}
enum InformationReply {
value 16;
status deprecated;
description
"Information Reply (Deprecated)";
reference
"- RFC 792
- RFC 6918";
}
enum AddressMaskRequest {
value 17;
status deprecated;
description
"Address Mask Request (Deprecated)";
reference
"- RFC 950
- RFC 6918";
}
enum AddressMaskReply {
value 18;
status deprecated;
description
"Address Mask Reply (Deprecated)";
reference
"- RFC 950
- RFC 6918";
}
enum Traceroute {
value 30;
status deprecated;
description
"Traceroute (Deprecated)";
reference
"- RFC 1393
- RFC 6918";
}
enum DatagramConversionError {
value 31;
status deprecated;
description
"Datagram Conversion Error (Deprecated)";
reference
"- RFC 1475
- RFC 6918";
}
enum MobileHostRedirect {
value 32;
status deprecated;
description
"Mobile Host Redirect (Deprecated)";
reference
"- David Johnson <>
- RFC 6918";
}
enum IPv6Where-Are-You {
value 33;
status deprecated;
description
"IPv6 Where-Are-You (Deprecated)";
reference
"- Bill Simpson <mailto:Bill.Simpson&um.cc.umich.edu>
- RFC 6918";
}
enum IPv6I-Am-Here {
value 34;
status deprecated;
description
"IPv6 I-Am-Here (Deprecated)";
reference
"- Bill Simpson <mailto:Bill.Simpson&um.cc.umich.edu>
- RFC 6918";
}
enum MobileRegistrationRequest {
value 35;
status deprecated;
description
"Mobile Registration Request (Deprecated)";
reference
"- Bill Simpson <mailto:Bill.Simpson&um.cc.umich.edu>
- RFC 6918";
}
enum MobileRegistrationReply {
value 36;
status deprecated;
description
"Mobile Registration Reply (Deprecated)";
reference
"- Bill Simpson <mailto:Bill.Simpson&um.cc.umich.edu>
- RFC 6918";
}
enum DomainNameRequest {
value 37;
status deprecated;
description
"Domain Name Request (Deprecated)";
reference
"- RFC 1788
- RFC 6918";
}
enum DomainNameReply {
value 38;
status deprecated;
description
"Domain Name Reply (Deprecated)";
reference
"- RFC 1788
- RFC 6918";
}
enum SKIP {
value 39;
status deprecated;
description
"SKIP (Deprecated)";
reference
"- Tom Markson <mailto:markson&osmosys.incog.com>
- RFC 6918";
}
enum Photuris {
value 40;
description
"Photuris";
reference
"RFC 2521";
}
enum ICMPmessagesutilizedbyexperimentalmobilityprotocols {
value 41;
description
"ICMP messages utilized by experimental mobility protocols
such as Seamoby";
reference
"RFC 4065";
}
enum ExtendedEchoRequest {
value 42;
description
"Extended Echo Request";
reference
"RFC 8335";
}
enum ExtendedEchoReply {
value 43;
description
"Extended Echo Reply";
reference
"RFC 8335";
}
}
description
"This enumeration type defines mnemonic names and corresponding
numeric values of ICMPv4 types.";
reference
"RFC 2708: IANA Allocation Guidelines For Values In the
Internet Protocol and Related Headers";
}
typedef icmpv4-type {
type union {
type uint8;
type icmpv4-type-name;
}
description
"This type allows reference to an ICMPv4 type using either the
assigned mnemonic name or numeric value.";
}
}
]]></sourcecode>
</section>
<section anchor="iana-icmpv6">
<name>Initial Version of the ICMPv6 Types IANA-Maintained Module</name>
<sourcecode markers="true" name="iana-icmpv6-types@2023-04-28.yang"><![CDA
TA[
module iana-icmpv6-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-icmpv6-types";
prefix iana-icmpv6-types;
organization
"Internet Assigned Numbers Authority (IANA)";
contact
"Internet Assigned Numbers Authority
ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
Tel: +1 424 254 5300
<mailto:iana@iana.org>";
description
"This YANG module translates IANA registry 'ICMPv6 \"type\"
Numbers' to YANG derived types.
Copyright (c) 2023 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
The initial version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices.
This version of this YANG module was generated from the
corresponding IANA registry using an XSLT stylesheet from the
'iana-yang' project (https://github.com/llhotka/iana-yang).";
reference
"Internet Control Message Protocol version 6 (ICMPv6) Parameters
(https://www.iana.org/assignments/icmpv6-parameters/)";
revision 2023-04-28 {
description
"Current revision as of the revision date specified in the XML
representation of the registry page.";
reference
"https://www.iana.org/assignments/icmpv6-parameters
/icmpv6-parameters.xml";
}
/* Typedefs */
typedef icmpv6-type-name {
type enumeration {
enum DestinationUnreachable {
value 1;
description
"Destination Unreachable.";
reference
"RFC 4443";
}
enum PacketTooBig {
value 2;
description
"Packet Too Big.";
reference
"RFC 4443";
}
enum TimeExceeded {
value 3;
description
"Time Exceeded.";
reference
"RFC 4443";
}
enum ParameterProblem {
value 4;
description
"Parameter Problem.";
reference
"RFC 4443";
}
enum EchoRequest {
value 128;
description
"Echo Request.";
reference
"RFC 4443";
}
enum EchoReply {
value 129;
description
"Echo Reply.";
reference
"RFC 4443";
}
enum MulticastListenerQuery {
value 130;
description
"Multicast Listener Query.";
reference
"RFC 2710";
}
enum MulticastListenerReport {
value 131;
description
"Multicast Listener Report.";
reference
"RFC 2710";
}
enum MulticastListenerDone {
value 132;
description
"Multicast Listener Done.";
reference
"RFC 2710";
}
enum RouterSolicitation {
value 133;
description
"Router Solicitation.";
reference
"RFC 4861";
}
enum RouterAdvertisement {
value 134;
description
"Router Advertisement.";
reference
"RFC 4861";
}
enum NeighborSolicitation {
value 135;
description
"Neighbor Solicitation.";
reference
"RFC 4861";
}
enum NeighborAdvertisement {
value 136;
description
"Neighbor Advertisement.";
reference
"RFC 4861";
}
enum RedirectMessage {
value 137;
description
"Redirect Message.";
reference
"RFC 4861";
}
enum RouterRenumbering {
value 138;
description
"Router Renumbering.";
reference
"RFC 2894";
}
enum ICMPNodeInformationQuery {
value 139;
description
"ICMP Node Information Query.";
reference
"RFC 4620";
}
enum ICMPNodeInformationResponse {
value 140;
description
"ICMP Node Information Response.";
reference
"RFC 4620";
}
enum InverseNeighborDiscoverySolicitationMessage {
value 141;
description
"Inverse Neighbor Discovery Solicitation Message.";
reference
"RFC 3122";
}
enum InverseNeighborDiscoveryAdvertisementMessage {
value 142;
description
"Inverse Neighbor Discovery Advertisement Message.";
reference
"RFC 3122";
}
enum Version2MulticastListenerReport {
value 143;
description
"Version 2 Multicast Listener Report.";
reference
"RFC 3810";
}
enum HomeAgentAddressDiscoveryRequestMessage {
value 144;
description
"Home Agent Address Discovery Request Message.";
reference
"RFC 6275";
}
enum HomeAgentAddressDiscoveryReplyMessage {
value 145;
description
"Home Agent Address Discovery Reply Message.";
reference
"RFC 6275";
}
enum MobilePrefixSolicitation {
value 146;
description
"Mobile Prefix Solicitation.";
reference
"RFC 6275";
}
enum MobilePrefixAdvertisement {
value 147;
description
"Mobile Prefix Advertisement.";
reference
"RFC 6275";
}
enum CertificationPathSolicitationMessage {
value 148;
description
"Certification Path Solicitation Message.";
reference
"RFC 3971";
}
enum CertificationPathAdvertisementMessage {
value 149;
description
"Certification Path Advertisement Message.";
reference
"RFC 3971";
}
enum ICMPmessagesutilizedbyexperimentalmobilityprotocols {
value 150;
description
"ICMP messages utilized by experimental mobility protocols
such as Seamoby.";
reference
"RFC 4065";
}
enum MulticastRouterAdvertisement {
value 151;
description
"Multicast Router Advertisement.";
reference
"RFC 4286";
}
enum MulticastRouterSolicitation {
value 152;
description
"Multicast Router Solicitation.";
reference
"RFC 4286";
}
enum MulticastRouterTermination {
value 153;
description
"Multicast Router Termination.";
reference
"RFC 4286";
}
enum FMIPv6Messages {
value 154;
description
"FMIPv6 Messages.";
reference
"RFC 5568";
}
enum RPLControlMessage {
value 155;
description
"RPL Control Message.";
reference
"RFC 6550";
}
enum ILNPv6LocatorUpdateMessage {
value 156;
description
"ILNPv6 Locator Update Message.";
reference
"RFC 6743";
}
enum DuplicateAddressRequest {
value 157;
description
"Duplicate Address Request.";
reference
"RFC 6775";
}
enum DuplicateAddressConfirmation {
value 158;
description
"Duplicate Address Confirmation.";
reference
"RFC 6775";
}
enum MPLControlMessage {
value 159;
description
"MPL Control Message.";
reference
"RFC 7731";
}
enum ExtendedEchoRequest {
value 160;
description
"Extended Echo Request.";
reference
"RFC 8335";
}
enum ExtendedEchoReply {
value 161;
description
"Extended Echo Reply.";
reference
"RFC 8335";
}
}
description
"This enumeration type defines mnemonic names and corresponding
numeric values of ICMPv6 types.";
reference
"RFC 2708: IANA Allocation Guidelines For Values In the
Internet Protocol and Related Headers";
}
typedef icmpv6-type {
type union {
type uint8;
type icmpv6-type-name;
}
description
"This type allows reference to an ICMPv6 type using either the
assigned mnemonic name or numeric value.";
}
}
]]></sourcecode>
</section>
<section anchor="iana-ipv6-ext">
<name>Initial Version of the IPv6 Extension Header Types IANA-Maintained M
odule</name>
<sourcecode markers="true" name="iana-ipv6-ext-types@2023-09-29.yang"><![C
DATA[
module iana-ipv6-ext-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types";
prefix iana-ipv6-ext-types;
organization
"Internet Assigned Numbers Authority (IANA)";
contact
"Internet Assigned Numbers Authority
ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
Tel: +1 424 254 5300
<mailto:iana@iana.org>";
description
"This YANG module translates IANA registry 'IPv6 Extension Header
Types' to YANG derived types.
Copyright (c) 2023 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module was generated from the
corresponding IANA registry using an XSLT stylesheet from the
'iana-yang' project (https://github.com/llhotka/iana-yang).";
reference
"Internet Protocol Version 6 (IPv6) Parameters
(https://www.iana.org/assignments/ipv6-parameters/)";
revision 2023-09-29 {
description
"Current revision as of the revision date specified in the XML
representation of the registry page.";
reference
"https://www.iana.org/assignments/ipv6-parameters
/ipv6-parameters.xml";
}
/* Typedefs */ <!-- [I-D.ietf-netmod-rfc8407bis]
draft-ietf-netmod-rfc8407bis-28
IESG State: RFC Ed Queue (EDIT) as of 11/10/25
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-netmod-rfc8407bis.xml"/>
typedef ipv6-extension-header-type-name { <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
type enumeration { 340.xml"/>
enum IPv6Hop-by-HopOption { <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
value 0; 000.xml"/>
description <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
"IPv6 Hop-by-Hop Option"; 209.xml"/>
reference <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
"RFC 8200"; 241.xml"/>
} <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
enum RoutingHeaderforIPv6 { 040.xml"/>
value 43; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
description 252.xml"/>
"Routing Header for IPv6"; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
reference 446.xml"/>
"- RFC 8200 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
- RFC 5095"; 329.xml"/>
} <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
enum FragmentHeaderforIPv6 { 692.xml"/>
value 44;
description
"Fragment Header for IPv6";
reference
"RFC 8200";
}
enum EncapsulatingSecurityPayload {
value 50;
description
"Encapsulating Security Payload";
reference
"RFC 4303";
}
enum AuthenticationHeader {
value 51;
description
"Authentication Header";
reference
"RFC 4302";
}
enum DestinationOptionsforIPv6 {
value 60;
description
"Destination Options for IPv6";
reference
"RFC 8200";
}
enum MobilityHeader {
value 135;
description
"Mobility Header";
reference
"RFC 6275";
}
enum HostIdentityProtocol {
value 139;
description
"Host Identity Protocol";
reference
"RFC 7401";
}
enum Shim6Protocol {
value 140;
description
"Shim6 Protocol";
reference
"RFC 5533";
}
}
description
"This enumeration type defines mnemonic names and
corresponding numeric values of IPv6 Extension header
types.";
reference
"RFC 2708: IANA Allocation Guidelines For Values In the
Internet Protocol and Related Headers";
}
typedef ipv6-extension-header-type { <!-- <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
type union { 780.xml"/>
type uint8; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
type ipv6-extension-header-type-name; 237.xml"/>
} <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
description 045.xml"/>
"This type allows reference to an IPv6 Extension header -->
type using either the assigned mnemonic name or the
numeric protocol number value.";
}
}
]]></sourcecode> </references>
</section> </references>
<section anchor="ps"> <section anchor="ps">
<name>Problem Statement and Gap Analysis</name> <name>Problem Statement and Gap Analysis</name>
<section anchor="ps-sets"> <section anchor="ps-sets">
<name>Suboptimal Configuration: Lack of Support for Lists of Prefixes</n ame> <name>Suboptimal Configuration: Lack of Support for Lists of Prefixes</n ame>
<t>IP prefix-related data nodes, e.g., "destination-ipv4-network" or <t>IP prefix-related data nodes (e.g., "destination-ipv4-network" or
"destination-ipv6-network", do not support handling a list of IP "destination-ipv6-network") do not support handling a list of IP
prefixes, which may then lead to having to support large numbers of ACL entri es in a configuration file.</t> prefixes, which may then lead to having to support large numbers of ACL entri es in a configuration file.</t>
<t>The same issue is encountered when ACLs have to be in place to mitiga <t>The same issue is encountered when ACLs have to be in place to
te DDoS mitigate DDoS attacks that involve a set of sources (e.g., <xref
attacks that involve a set of sources (e.g., <xref target="RFC9132"/>). The situ target="RFC9132"/>). The situation is even worse when both a list of
ation is even worse when both a list of sources sources and destination prefixes are involved in the filtering.</t>
and destination prefixes are involved in the filtering.</t>
<t><xref target="example"/> shows an example of the required ACL configu ration for filtering traffic from two prefixes.</t> <t><xref target="example"/> shows an example of the required ACL configu ration for filtering traffic from two prefixes.</t>
<figure anchor="example"> <figure anchor="example">
<name>Example Illustrating Sub-optimal Use of the ACL Model with a Pre
fix List (Message Body)</name> <!--[rfced] We updated <artwork> to <sourcecode type="json"> for
<artwork><![CDATA[ Figure 3 in Appendix A.1. Please confirm that this is correct.
In addition, please confirm that the "type" attribute of all the
sourcecode elements are correct.
The current list of preferred values for "type" is available at
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current
list does not contain an applicable type, feel free to suggest additions
for consideration. Note that it is also acceptable to leave the "type"
attribute not set.
-->
<name>Example Illustrating Suboptimal Use of the ACL Model with a Pref
ix List (Message Body)</name>
<sourcecode type="json"><![CDATA[
{ {
"ietf-access-control-list:acls": { "ietf-access-control-list:acls": {
"acl": [ "acl": [
{ {
"name": "first-prefix", "name": "first-prefix",
"type": "ipv6-acl-type", "type": "ipv6-acl-type",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"name": "my-test-ace", "name": "my-test-ace",
skipping to change at line 3510 skipping to change at line 2513
"actions": { "actions": {
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>Such a configuration is suboptimal for both:</t> <t>Such a configuration is suboptimal for both:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Network controllers that need to manipulate large files. All or a <t>network controllers that need to manipulate large files, as all o r a
subset for this configuration will need to be passed to the subset for this configuration will need to be passed to the
underlying network devices.</t> underlying network devices, and</t>
</li> </li>
<li> <li>
<t>Devices may receive such a configuration and thus will need to <t>devices that may receive such a configuration and thus will need to
maintain it locally.</t> maintain it locally.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="manageability-impossibility-to-use-aliases-or-defined-set s"> <section anchor="manageability-impossibility-to-use-aliases-or-defined-set s">
<name>Manageability: Impossibility to Use Aliases or Defined Sets</name> <name>Manageability: Impossibility of Using Aliases or Defined Sets</nam e>
<t>The same approach as the one discussed for IP prefixes can be general ized by introducing the concept of "aliases" or "defined sets".</t> <t>The same approach as the one discussed for IP prefixes can be general ized by introducing the concept of "aliases" or "defined sets".</t>
<t>The defined sets are reusable definitions across several ACLs. Each c ategory is modeled in YANG as a list of parameters related to the class it repre sents. The following sets can be considered:</t> <t>The defined sets are reusable definitions across several ACLs. Each c ategory is modeled in YANG as a list of parameters related to the class it repre sents. The following sets can be considered:</t>
<dl> <dl>
<dt>Prefix sets:</dt> <dt>Prefix sets:</dt>
<dd> <dd>
<t>Used to create lists of IPv4 or IPv6 prefixes.</t> <t>Used to create lists of IPv4 or IPv6 prefixes.</t>
</dd> </dd>
<dt>Protocol sets:</dt> <dt>Protocol sets:</dt>
<dd> <dd>
<t>Used to create a list of protocols.</t> <t>Used to create a list of protocols.</t>
</dd> </dd>
<dt>Port number sets:</dt> <dt>Port number sets:</dt>
<dd> <dd>
<t>Used to create lists of TCP or UDP port values <t>Used to create lists of TCP or UDP port values
(or any other transport protocol that makes uses of port numbers). (or any other transport protocol that makes uses of port numbers).
The identity of the protocols is identified by the protocol set, if The identity of the protocols is identified by the protocol set, if
present. Otherwise, a set applies to any protocol.</t> present. Otherwise, a set applies to any protocol.</t>
</dd> </dd>
<dt>ICMP sets:</dt> <dt>ICMP sets:</dt>
<dd> <dd>
<t>Uses to create lists of ICMP-based filters. This applies only whe n the protocol is set to ICMP or ICMPv6.</t> <t>Used to create lists of ICMP-based filters. This applies only whe n the protocol is set to ICMP or ICMPv6.</t>
</dd> </dd>
</dl> </dl>
<t>Aliases may also be considered to manage resources that are identifie d by a combination of various parameters (e.g., prefix, protocol, port number, F QDN, or VLAN IDs). <t>Aliases may also be considered to manage resources that are identifie d by a combination of various parameters (e.g., prefix, protocol, port number, F QDN, or VLAN IDs).
Note that some aliases can be provided by decomposing them into separate sets.</ t> Note that some aliases can be provided by decomposing them into separate sets.</ t>
</section> </section>
<section anchor="bind-acls-to-devices-not-only-interfaces"> <section anchor="bind-acls-to-devices-not-only-interfaces">
<name>Bind ACLs to Devices, Not Only Interfaces</name> <name>Bind ACLs to Devices, Not Only Interfaces</name>
<t>In the context of network management, an ACL may be enforced in many <t>In the context of network management, an ACL may be enforced in many
network locations. As such, the ACL module should allow for binding an network locations. As such, the ACL module should allow for binding an
ACL to multiple devices, not only (abstract) interfaces.</t> ACL to multiple devices, not only (abstract) interfaces.</t>
<t>The ACL name must, thus, be unique at the scale of the network, but t he same name may be used in many devices when enforcing node-specific ACLs.</t> <t>Thus, the ACL name must be unique at the scale of the network, but th e same name may be used in many devices when enforcing node-specific ACLs.</t>
</section> </section>
<section anchor="ps-frag"> <section anchor="ps-frag">
<name>Partial or Lack of IPv4/IPv6 Fragment Handling</name> <name>Partial or Lack of IPv4/IPv6 Fragment Handling</name>
<t><xref target="RFC8519"/> does not support fragment handling for IPv6 but <t><xref target="RFC8519"/> does not support fragment handling for IPv6 but
offers a partial support for IPv4 through the use of 'flags'. Nevertheless, offers a partial support for IPv4 through the use of 'flags'. Nevertheless,
the use of 'flags' is problematic since it does not allow a bitmask the use of 'flags' is problematic since it does not allow a bitmask
to be defined. For example, setting other bits not covered by the to be defined. For example, setting other bits not covered by the
'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).</t> through (because it won't match the ACE).</t>
<t>Defining a new IPv4/IPv6 matching field called 'fragment' is thus req uired to efficiently handle fragment-related filtering rules.</t> <t>Defining a new IPv4/IPv6 matching field called 'fragment' is thus req uired to efficiently handle fragment-related filtering rules.</t>
</section> </section>
<section anchor="ps-flags">
<!-- [rfced] May we update as follows to avoid repetition of "defining" and "def
ined"?
Original:
Defining this field to be defined as a flag bitmask together with a set of
operations is meant to efficiently handle TCP flags filtering rules.
Perhaps:
Defining this field as a flag bitmask together with a set of
operations is meant to efficiently handle TCP flags filtering rules.
-->
<section anchor="ps-flags">
<name>Suboptimal TCP Flags Handling</name> <name>Suboptimal TCP Flags Handling</name>
<t><xref target="RFC8519"/> supports including flags in the TCP match fi elds, however <t><xref target="RFC8519"/> supports including flags in the TCP match fi elds; 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 to be defined as a
flag bitmask together with a set of operations is meant to flag bitmask together with a set of operations is meant to
efficiently handle TCP flags filtering rules.</t> efficiently handle TCP flags filtering rules.</t>
</section> </section>
<section anchor="ps-rate"> <section anchor="ps-rate">
<name>Rate-Limit Action</name> <name>Rate-Limit Action</name>
<t><xref target="RFC8519"/> specifies that forwarding actions can be 'ac cept' (i.e., accept matching <t><xref target="RFC8519"/> specifies that forwarding actions can be 'ac cept' (i.e., accept matching
traffic), 'drop' (i.e., drop matching traffic without sending any traffic), 'drop' (i.e., drop matching traffic without sending any
ICMP error message), or 'reject' (i.e., drop matching traffic and send an ICM P error message to the source). However, there are situations where the matching traffic can be accepted, but with a rate-limit policy. This capability is not s upported by <xref target="RFC8519"/>.</t> ICMP error message), or 'reject' (i.e., drop matching traffic and send an ICM P error message to the source). However, there are situations where the matching traffic can be accepted, but with a rate-limit policy. This capability is not s upported by <xref target="RFC8519"/>.</t>
</section> </section>
<section anchor="ps-pf"> <section anchor="ps-pf">
<name>Payload-based Filtering</name> <name>Payload-Based Filtering</name>
<t>Some transport protocols use existing protocols (e.g., TCP or UDP) as substrate. The match criteria for such protocols may rely upon the 'protocol' u nder 'l3', TCP/UDP match criteria, part of the TCP/UDP payload, or a combination thereof. <xref target="RFC8519"/> does not support matching based on the payloa d.</t> <t>Some transport protocols use existing protocols (e.g., TCP or UDP) as substrate. The match criteria for such protocols may rely upon the 'protocol' u nder 'l3', TCP/UDP match criteria, part of the TCP/UDP payload, or a combination thereof. <xref target="RFC8519"/> does not support matching based on the payloa d.</t>
<t>Likewise, the ACL model defined in <xref target="RFC8519"/> does not support filtering of encapsulated traffic.</t> <t>Likewise, the ACL model defined in <xref target="RFC8519"/> does not support filtering of encapsulated traffic.</t>
</section> </section>
<section anchor="reuse-the-acls-content-across-several-devices"> <section anchor="reuse-the-acls-content-across-several-devices">
<name>Reuse the ACLs Content Across Several Devices</name> <name>Reuse the Content of ACLs Across Several Devices</name>
<t>Having a global network view of the ACLs is highly valuable for servi ce providers. An ACL could be defined and applied <t>Having a global network view of the ACLs is highly valuable for servi ce providers. An ACL could be defined and applied
based on the network topology hierarchy. So, an ACL can be based on the network topology hierarchy. Therefore, an ACL can be
defined at the network level and, then, that same ACL can be used (or referenced defined at the network level, and then that same ACL can be used in (or referenc
to) ed to)
in several devices (including termination points) within the same network.</t> several devices (including termination points) within the same network.</t>
<t>This network/device ACLs differentiation introduces several new <t>This network/device differentiation of ACLs introduces several new
requirements, e.g.:</t> requirements, for example:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>An ACL name can be used at both network and device levels.</t> <t>An ACL name can be used at both network and device levels.</t>
</li> </li>
<li> <li>
<t>An ACL content updated at the network level should imply <t>An ACL content updated at the network level should imply
a transaction that updates the relevant content in all the nodes using this a transaction that updates the relevant content in all the nodes using this
ACL.</t> ACL.</t>
</li> </li>
<li> <li>
skipping to change at line 3664 skipping to change at line 2681
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="fragments-handling-1"> <section anchor="fragments-handling-1">
<name>Fragments Handling</name> <name>Fragments Handling</name>
<t><xref target="example_2"/> shows the content of a POST request to all ow the traffic destined to 198.51.100.0/24 and UDP port number 53, but to drop a ll fragmented <t><xref target="example_2"/> shows the content of a POST request to all ow the traffic destined to 198.51.100.0/24 and UDP port number 53, but to drop a ll fragmented
packets. The following ACEs are defined (in this order):</t> packets. The following ACEs are defined (in this order):</t>
<ul spacing="normal"> <dl>
<li> <dt>"drop-all-fragments" ACE:</dt><dd>discards all fragments.</dd>
<t>"drop-all-fragments" ACE: discards all fragments.</t> <dt>"allow-dns-packets" ACE:</dt><dd>accepts DNS packets destined to 198.
</li> 51.100.0/24.</dd>
<li> </dl>
<t>"allow-dns-packets" ACE: accepts DNS packets destined to 198.51.1
00.0/24.</t>
</li>
</ul>
<figure anchor="example_2"> <figure anchor="example_2">
<name>Example Illustrating Candidate Filtering of IPv4 Fragmented Pack ets (Message Body)</name> <name>Example Illustrating Candidate Filtering of IPv4 Fragmented Pack ets (Message Body)</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-access-control-list:acls": { "ietf-access-control-list:acls": {
"acl": [ "acl": [
{ {
"name": "dns-fragments", "name": "dns-fragments",
"type": "ipv4-acl-type", "type": "ipv4-acl-type",
"aces": { "aces": {
skipping to change at line 3723 skipping to change at line 2737
} }
] ]
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t><xref target="example_3"/> shows an example of the body of a POST req uest to allow the traffic destined to 2001:db8::/32 and UDP port number 53, but to drop all fragmented packets. The following ACEs are defined (in this order):< /t> <t><xref target="example_3"/> shows an example of the body of a POST req uest to allow the traffic destined to 2001:db8::/32 and UDP port number 53, but to drop all fragmented packets. The following ACEs are defined (in this order):< /t>
<ul spacing="normal"> <dl>
<li> <dt>"drop-all-fragments" ACE:</dt><dd>discards all fragments
<t>"drop-all-fragments" ACE: discards all fragments (including atomi (including atomic fragments). That is, IPv6 packets that include a
c fragments). That is, IPv6 packets that include a Fragment header (44) are drop Fragment header (44) are dropped.</dd>
ped.</t> <dt>"allow-dns-packets" ACE:</dt><dd>accepts DNS packets destined to
</li> 2001:db8::/32.</dd>
<li> </dl>
<t>"allow-dns-packets" ACE: accepts DNS packets destined to 2001:db8
::/32.</t>
</li>
</ul>
<figure anchor="example_3"> <figure anchor="example_3">
<name>An Example Illustrating Filtering of IPv6 Fragmented Packets (Me ssage Body)</name> <name>An Example Illustrating Filtering of IPv6 Fragmented Packets (Me ssage Body)</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-access-control-list:acls": { "ietf-access-control-list:acls": {
"acl": [ "acl": [
{ {
"name": "dns-fragments", "name": "dns-fragments",
"type": "ipv6-acl-type", "type": "ipv6-acl-type",
"aces": { "aces": {
skipping to change at line 3783 skipping to change at line 2797
] ]
} }
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="pattern-based-filtering"> <section anchor="pattern-based-filtering">
<name>Pattern-based Filtering</name> <name>Pattern-Based Filtering</name>
<t>Pattern-based filtering is useful to detect specific patterns, signat <t>Pattern-based filtering is useful to detect specific patterns, signat
ures, or encapsulated packets. <xref target="example_p"/> shows an example of th ures, or encapsulated packets. <xref target="example_p"/> shows an example of th
e message body of a request to install a filter to discard IP-in-IP encapsulated e message body of a request to install a filter to discard IP-in-IP encapsulated
messages with an inner destination IP address equal to "2001:db8::1". By using messages with an inner destination IP address equal to "2001:db8::1". By using
the offset at the end of layer 3, the rule targets a specific portion of the pay the offset at the end of Layer 3, the rule targets a specific portion of the pay
load that starts 20 bytes after the beginning of the data (that is, skipping the load that starts 20 bytes after the beginning of the data (that is, skipping the
first 20 bytes of the inner IPv6 header).</t> first 20 bytes of the inner IPv6 header).</t>
<t>For the readers' convenience, the textual representation of the patte <t>For the reader's convenience, the textual representation of the patte
rn is used in the example instead of the binary form.</t> rn is used in the example instead of the binary form.</t>
<figure anchor="example_p"> <figure anchor="example_p">
<name>Example of an ACL to Deny Encapsulated Messages with a Specific Inner Destination Address (Request Body)</name> <name>Example of an ACL to Deny Encapsulated Messages with a Specific Inner Destination Address (Request Body)</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-access-control-list:acls": { "ietf-access-control-list:acls": {
"acl": [ "acl": [
{ {
"name": "pattern-example", "name": "pattern-example",
"aces": { "aces": {
"ace": [ "ace": [
skipping to change at line 3894 skipping to change at line 2908
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="rate-limit"> <section anchor="rate-limit">
<name>Rate-Limit</name> <name>Rate-Limit</name>
<t><xref target="example_5"/> shows an ACL example to rate-limit incomin g SYNs during a SYN flood attack.</t> <t><xref target="example_5"/> shows an ACL example to rate-limit incomin g SYNs during a SYN flood attack.</t>
<figure anchor="example_5"> <figure anchor="example_5">
<name>An Example of Rate-Limit Incoming TCP SYNs (Message Body).</name > <name>An Example of Rate-Limiting Incoming TCP SYNs (Message Body)</na me>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"ietf-access-control-list:acls": { "ietf-access-control-list:acls": {
"acl": [ "acl": [
{ {
"name": "tcp-flags-example-with-rate-limit", "name": "tcp-flags-example-with-rate-limit",
"aces": { "aces": {
"ace": [ "ace": [
{ {
"name": "rate-limit-syn", "name": "rate-limit-syn",
skipping to change at line 3930 skipping to change at line 2944
} }
] ]
} }
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>Many thanks to Jon Shallow and Miguel Cros for the review and comments <t>Many thanks to <contact fullname="Jon Shallow"/> and <contact
to the document, including prior to publishing the document.</t> fullname="Miguel Cros"/> for their review and comments on this document.</
<t>Thanks to Qiufang Ma, Victor Lopez, Joe Clarke, and Mahesh Jethanandani t>
for the comments and suggestions.</t> <t>Thanks to <contact fullname="Qiufang Ma"/>, <contact fullname="Victor
<t>Thanks to Lou Berger for Shepherding the document.</t> Lopez"/>, <contact fullname="Joe Clarke"/>, and <contact
<t>Thanks to David Black for the tsvart review, Tim Wicinski for the intdi fullname="Mahesh Jethanandani"/> for their comments and suggestions.</t>
r review, Per Andersson for the yangdoctors review, Russ Housley <t>Thanks to <contact fullname="Lou Berger"/> for shepherding this
for genart review, and Linda Dunbar and Sean Turner for the secdir reviews.</t> document.</t>
<t>Thanks to Erik Kline, Mike Bishop, Éric Vyncke, Roman Danyliw, and Deb <t>Thanks to <contact fullname="David Black"/> for the tsvart review,
Cooley for the IESG review.</t> <contact fullname="Tim Wicinski"/> for the intdir review, <contact
<t>The IANA-maintained modules were generated using an XSLT stylesheet fro fullname="Per Andersson"/> for the yangdoctors review, <contact
m the 'iana-yang' project <xref target="YANG-XSLT"/>.</t> fullname="Russ Housley"/> for the genart review, and <contact
<t>This work is partially supported by the European Commission under Horiz fullname="Linda Dunbar"/> and <contact fullname="Sean Turner"/> for the
on 2020 Secured autonomic traffic management for a Tera of SDN secdir reviews.</t>
<t>Thanks to <contact fullname="Erik Kline"/>, <contact fullname="Mike
Bishop"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Roman
Danyliw"/>, and <contact fullname="Deb Cooley"/> for the IESG
review.</t>
<t>The IANA-maintained modules were generated using an XSLT stylesheet
from the 'iana-yang' project <xref target="YANG-XSLT"/>.</t>
<t>This work is partially supported by the European Commission under Horizon 202
0 Secured autonomic traffic management for a Tera of SDN
flows (Teraflow) project (grant agreement number 101015857).</t> flows (Teraflow) project (grant agreement number 101015857).</t>
</section> </section>
</back> </back>
<!-- ##markdown-source: </rfc>
H4sIAAAAAAAAA+29a1McR7Yo+r0izn/I3Y7YgIdu0TxaqD1jDwJksQ8gDMje
E3MmHNXd1U1tVVf11APE6DLf77+4v+WeP3bWK7OyXv0AJHn2MRG2oKoyc+XK <!-- [rfced] Abbreviations
leudK9vttpP6aeD11fHH1AsTPwoTlUYqvfHUwXDoJYk6jMI0jgJ16idpotYP
Dk+TDfWXg/Mf1Vk08gLHHQxi7xY6CG/ccOiNFH7hjKJh6E6h31HsjtO276Xj a) FYI - We have expanded the following abbreviations upon
duil02jUdodB2zOjtbsvHcdJUjcc/eoGUQhN0jjzHH8W029Jur219Wpr23Fj first use. Please review each expansion in the document carefully to
z+2r1ruZF7spwQlN1JkbuhNv6oVpy7mb9BWP4Xy466uTMPVi+Lt9hCA4Qzft ensure correctness.
qyQdOUk2mPoJDp7ez2C4k+PrN44zjEZ+CB1kAOi+M/P76q9pNNxUSRSnsTdO
4Lf7Kf7yN8dxs/QmivuOajsKfsZZEPBk3yVDN1Y/RuE/3MD7hxp56siPEvoo Datagram Congestion Control Protocol (DCCP)
iidu6P+DQO+ray/wxlHoD1166U1dP+irCJt3JtJ85I2g8Z9T82lnGE2rY165 Explicit Congestion Notification (ECN)
U9+L1Ws3nmR+UDPWefTBLwyTUIvOgFv8OvFjNxhFfw7xu/oxzqIb+HekXkfZ Media Access Control (MAC)
0B25flwzzLvYDSeePc6UW3UGutWfI/qmfoyf/FD9ktV0/DZz7zzf7njgB0Hn Stream Control Transmission Protocol (SCTP)
LvvzDb2h7pwwiqfQ4NbrO/jpycH5Qfvk8OzidrdPTfMfIfgWvlXXQALqPJsO
vDhplT8EBHlANDdpOkv6L17c3d11fKC3DsD3wgUKmoRIeMkLfzidtWduDPMA b) How should "VRF" be expanded in Appendix A.8? Perhaps one of
kqv83fl4k06DEli9eWDd9lT6XIDd9sqgFZ5UgJsHGgJmGIV667kjoDxE4RNA these options:
LANYD57jh+N8hTWwyIbaFweXB2fH18eXV01wE7e6MH0+GtZ7oF4Lthxp14cX
7TenBz82QnANhJ8I1zEc9SKOgMXAL+vQfuM5AEyHBTo0AP7KO+FXRMSv7y9P
m8DETttCIkiAiWH0WeA9JxWWxylRIcPbWwHe3WeGtwotwgpiqwHei5+XhbbQ
z/PAuwp2j4+P2/tb2+2ue9O4zeEbdYUS2Y1HCradOo2GbkDyFoaIo1kU+PBa
oUhGiXsXxR8S1W6rn/04zeDL17E/moC84HYH+Nm5/uwAgB4h4OplH7fArT8i
8TX8MADpL00rW2DkpgDaQTYBhUCBRrC/AFmJgJ90fM/zCGX60QuY/q8w/TZ2
0yHMFPsy4r3w0y79rRTLLcSWQS103en+NJw9L2rbbcEKfaeRe27e5ijd2eoz
SR25qcsKWj0mr7xZ6qFwAWR2FyFzFPmEwe5Wp9vdevUCZ3F1fdTBpp393d7L
va2Xz4NDYuj/eXV6PXcPIR9etFsmfnqTDVA3eBEEN1H6wX1h2jpOG4jVHSRp
7A5Tx7l8c6j297qvQGEb+yGimZE4QiROEYm0VHUKscMKcUdd3/iJAq03o3VI
Zt7QH/vUVeKlKhorz1Kwb9xUjf2PauqG9/DOQXU78Kew8qzZwuekgR+eyvBu
ovzQT303CO4FyhE8URryjnPFIw7xi03lp/AWoBxlQ4QhmyBU0rlW76HzgZt4
MgI89ViDh8YJ6GXhED93gRzviezc2SyA7kH3gicdx7mGPsx83SCJDPZIJIKm
BiMSnFNibwnhkJQuZn3YKWkUBjPqhjSKpMMLNPVHo8BznG9Qlae5IESO8+nT
v8G8cdoPD2bQedYKYM91ssSL21EM/QNIsiZjPwCOCXq/ihFCXEWDD6InXCsP
bINw7E8ytjv04uRtB96Ne+vD5OCNCwDd+kOvo95Gd96tF29SD9wn0BvMIYu9
TQTJWkZ7RmBoZOMxYEGN42ia049FHx2nSG3AQcOUyQ0GS4q0hGi2yDHUy0yG
mgWSowkGp7QMxax/+pR4wzav7sPDRsdh7IGKZhCVZMObhgEVzsBPhlmSMBJG
HtBLwOiYJQ8PQAW/3HghbhJ3gkDhYjJpJwr29RSGQJISLqkisgyjmOCdxFE2
c0BfxPEDMhBxC6lZ7LU14gGxsuSwwAkw3hHDDYiQDhR14CUO7KrojikYyIdx
hCgJSUHHmRIBbSqPUE3bFEYLkIgUWHVAxpqZd9TJeJN68j6601ng6SmFngcm
HwIP4MF+48GVO4FdBEKvu7XlnFwodzSKgdBhKdehC5gO8BEv2dhEQgGoAo8g
UXdgIhEhAS0qQMsNQAlsJ1RDECwpfAjLPfJB9qK4Lu2dY/gHaQV2zzHsHgLV
BUjy0a2xgfWdhGDuI0aSCOaCU7Jo5y7KghGsTQok+Q+PkAbrRLo88hrAHE0T
IQpoz94mapoFqT+TqSTmA2E6DeS03iInA3kXwpvWpiqRJ6KY2NTUc2HPIJrd
ITIzkIcE1tS4EpAlV6gK55mkwKCImYey97GhhRdESxSnQhcwI/gMBt1UGS6O
Ih4UkinNkx15QyCzgDeurE3OYnD6DnGBCnz0hAn4rQfY0EQ0i0AxHADqYH6x
N41uvRcAm4MA05rKVsbRgUZARmcpUjTuCD2ddVAl4fMNwi+CAHg/CXGKPgK3
yYQfaUDxK+Qx9q5yAJKJF+LcYdHhWcQyTwg9SoVLtoUxDZEfAqILjLCj2JVU
7hwQcQ881zyDfmWxYKpTmAeKdbQTgUGiFFIB8OGAugGtOYLdmfI2YxgSkd0g
3+IIyTwnC16V2MsSEXvKHcaAYEOghko0i+moN/bGNqxLyIS3DM9CuLv04BCQ
0OADjApo8twEvToApRakanAviz7MYoSFOBTKyvMKAzRtaCRYJDO2J9oHLDFM
LNCooP0dIZfYdLzOpLMJyAnv20ykMCMXOMQslb9NBxY6kZbgRQTSYcY6/QgB
dh3188W5AiafRlMvJm6beEL82IWlJpAO7Ib+LGOwoLmZq/cR5gab1nOnRjuq
7lBARUSbGeBD0qERMhQvQTTUPFlWXQ0yngTsi8mElAIYkFDgpFEUJCy7gC6P
jqIr0EVSf8Kb89OnH4BGX3V3tkH9ANy8/vFCvQHxoFAFk7f7r/b2Hh4c80cP
yRnmDmsQxWaz3rpB5uJmLdKCzAjHIptlBsyVGFaSzYi7IAdLeNkSH2Y1dWd6
Y5c0GpRst949CVhnChzKRSuiMGXWGGjKdQyW+WdF2GPHyMQNRxEidHKHLNkg
sO6A44MYGHjqCaM+Pzs62KhRf3Z2t0nqH+QqM+0jGgPkWUYbm5k1rKqmgzpw
cWENHdIICL3uj0b5nPorKRUjD010DaXuxB0hFRi0xR5qMmC+ibgkWK880nTV
bmdnq7ONPfxw0j7q2E70eDzc3916OfBxMuqSx1XJDUlboDLmHcR2YDbqzhsk
PjK0T5/q/EGoddpveoU3OFH91vZzAPmTlEHJcsvLgjsXJAvovUkuxxKvCaWw
DN98o45BsEQxKE2Ktu/6dYTsnaUXkShaOfzRht7iPLf8RZ+ZeCKY8wnBVi+z
GBV0eDbLBmjG4FdEBLYeDTSN8IEoCtyhdxMF6JnATaq5JqpopmP6SDgfEI6I
OvkcPkYAQeshOrVHZUhDnEaSTaduDO1QNQmMWM/AMvXTLM2NRaRn1g8B6PXu
hroIPNTE0ShjsTCOUEWljc+QkTwiZ/i36j/hR7Xb39OX7DoCUBF7osAiaacI
FtAZtdje2t5tb+21u7283ZB8O+g/0JBa0+JHFjYBzu0NbVAx6Vc2pfFUMQFa
jquc7gpeMyA5BpU4QCz8LfRRBYJVQeZaAArYN8yyo9HF1CA0CbiDfUeywOhY
tI7UBMDfMWjOZjTrCqJhm+HIjGbAWt3eIvwhGvD3pfZLZbdwj4LHTnmo3rMP
1asbyt75jxmoOXbALEoPCeb+tReDHhcF0eSe+fQH7x4MiXiUqNbZ+6trUO7p
X3X+jn6/PP7p/cnl8RH+fvX24PTU/OLIF1dv370/Pcp/y1sevjs7Oz4/4sbw
VBUeOa2zg7+0mBRb7y6uT96dH5y2kHgLtM6KBPEFHy0D0LVQg3ETB4TAMPYH
TPCvDy/+//+vuyvybrtLDgwRft2Xu/DHHRi8PFoUwsbmPwF99w5SqxtjL8gp
hu4MNFQ0LFzi+ncoe2LE3rd/Rcz8ra/+OBjOurvfywOccOGhxlnhIeGs+qTS
mJFY86hmGIPNwvMSpovwHvyl8LfGu/Xwjz8EQK6q3d3/4XuHaSTNiYZ4hGAe
Nyo58zQX8ms8Ly9f7W2hUkDcCpQrbKSZ8f10gNogLTlqix5Idt+dxKiJFvrS
2t7OLvVl20xaXiGMcxw/RZpiW8BSdHLOg/0AzznKraK+01fHlp/DtU0mVFjY
Mwi0Qoo7KMQTfALMMp6h0g4I0y6/TaP52u6GTduG2LStXPiroBjRFn53i8Zf
oK6MfS6TsNMEJPBBSsA1ItZ8jU4+0OvImkeUw9ZAKmeDDGPGvBBzNMCywgro
+uc//+nw331l+wqQeYvDS72AZ334L2EH9B/a7fhOo7JNpq34m+FNOyu/qfSi
f5F/Pf3Ao3/Fu2QPBcb3fRC5o40f6OH/Q8/78DTFZIYN/dB8Ly/UJ+qrHYVt
6eDhB+tbA6+8bNPX9rCgvbhJaVB6Ru6K6rj5u2+1x5+eAIHY3YK6rXtV0is+
arOWtGH58LmB9dKaEj59+KHo8Of50Pf8XR4Aa7O/9tHrQb8H2/ay3AZu2Gbb
yoLLevpgow4ajBEYir79YEAG8wXdXIXv1qkP/G7jhyKS++uULGGj3rQCNuDF
NDw+zkDmdHt134G9OO87GkWbzxsVeoEO9EuexMwdfvBSmLEXjJK+flfXDofU
hFEYmF/7iT+qotN6+mDTDKKJ3llosgjKQpOqQxM2LUFR+o7R1PhdDZpKZLs0
mkrtcMgaND2FbHcK49AzUJ53zS82VePfbaBUGs2iS9hY+qnMwmqURFk89NrU
luUBuYUMmdsvgC2WOAJI5RR0bJQztV3Mbz2TjAl89YOq/tjvpenz47Jnfinh
svcEXPaacNlbGpeVLua3fgQudVPj8Gizw6PImmvSHPr6z0IzevfEJdqtLlE6
nOl/7QUaB+4kaQ/8dOomH4oLhGkz9Lq6NJRRA7pOAUv6wZz1KLcrNXnmKWej
mf63X50DPH3UHMrtPu8c0O43vxR2Fuf3CBBWtk8N+JL1Yn/bK3+7ItwuKcW5
kgb0gnrjMDKBrvi+LR9ZkKCnsk1x2JrNNfKG/tQNerukk37qq29sZZeTHf7U
KqjKRf249WBryJN4VlCQOWIBSjCFCEDnsLxIlvHRoDqLpqxM63x/2MtSlHmF
n4LIg69BD4xGXkkP9D5iPoGfGoHK21Hp5209KgpIjnCn93q1dSeDDNQFPywp
kkp2eRE0I17NvEqM2cyuMLfKZGylzvQgrMx0PU8xzcdJYxcjtO1h4CbJDxac
++aTwB14AWzDhAxJ+aaMDvyQlRj+nFQi/DbWDJjgoZd5z6QdrdKAPh0E0fAD
af4EjKXU0ozSgPV3G/d6RgY7BTPEQvt4bLGoukkGXjhJb35QZZ2yRI2VNRMz
SXc9ABYX39sQkfWSQzJPfxUrWL+G3ZSCfBNBm3+EzJLQ+q36K6MaH/3Nkjwq
f2w6omYSPba+5MXFlz80fcmQscz+toaQxn8fWVOiLjg+SmuZk1Hs51/xZ/DI
RpVwYJHh5a1TNHmoj3KSZt/6w7QbAoeo7tcc/BgEUzsaa42jdhGF3z8Csp4N
We/5IWuUGH1rO07kYZFEJsaKLG8I6xN/xBCWduMwytAdafdbetPUd+kzbeib
/nOcFxV2a0L5Q9gB2MHf7J7xgYVSC3D5gP13M831qh8Ut6HehwaaEpC93xSQ
vRogtXplQyeP5sFWMya0ghb+yHwvL9i+bf4pdiWN1rG7jar3pb+es7h2FLcb
DGRVZof2t5VPVe6osm3oxtY58ixrpbC8+eNFC1y3eDk7zULeQWU2qJVLa9DH
EpPVI7THf0oLCHipY741LPC5oeotAVWvGSqSrpajkx/MBacCCOrd2Mru13a/
5p2XWVLR2Kt9K816c5tV39p7tPR98XGZFssfV16V6KEOoLq3pQVralZ+a5bE
S2owDg/LZgpYHLVWyo/a4EAD5ZtvlI5QXOFIFF4R66uaDRoOgwzYKdAphQ50
MN7jfE5OfsstG53YZHI7ycAZuiHG4NjUJBsHHuA4mP5233GOMc0JAyJ+ghv6
75mHOUE6e5YzlpgEMQQnvWHgBN6ZGHEMY95iCiF3SnHQPDRDgNmG1no5koGh
iBOM51rZYBi+OQhV6XGekOByxh5lcplPMHXtQLJEKd9zwJmsPuc4+zrwmmdt
skNAcXRM2/mY60WRcAx6hSbTl2a3wbm2OjpMCL030X+dUSa2JEDcoan16qdm
HtdPq/ebntYFaulmPhz/algiOzYmUeFMcpxTPAdG7/WWN5mZ65x3d314QcT3
/uhio5MPJXkaQpIuPySJSOl5OvfX/hZP0044PQVaaaEJ4/wd0zjSaBP4qOem
OjEY8xbNGy8ddjZw1hpKa+bWo9rZ6/ccxunYTQR8a8d5PqUm88ZjuAUR3Zcb
PDXaj/KQseJQsNEmLvm7lrI4eYIjrVsvX0nWniQ68OPd3d0dzGZCG2BTkiGJ
GKYV7kDnMmlqm5TVjEckJAUHDQVaO+YSicnTZbmIq7lsalnZUWPFhTFBTotT
mjzxaDsUTXCCtTGQnYBg3LqxH2WJyp0RGqUmrLtp1qkQ3qXo7s+nB+eYA2Yd
ccKMf0UJ+pSqoBkynuEyg+gxdMcbNDOgthFwVEpsCIssNW9J/Uk+m95Apd7w
m41Ccrsr2EBUFxJx9QtNgRpVsDs5hQpZA569GuJWHIDVw+90JuLb6+uLK/gj
vqX0visKkOs+iUnlIXaRZJJlZLe0k/d5Ki1Gfauv/tra3trq9keD/X5vF37p
d190t/dbm+XH2/T4bxuG0JBh2NseSFmt+x2Pe2dMYf+9v3EWS+50gKfwMXGZ
K1k9kfdlNGFDynaKGWc+S1Xm0WAAYcqpi+xC/Dp4SmSU56IioeokZXF5WYmq
qTe8IVnMMhzXjNIwcXJ0Aku8RcRcyCyAPTrw7iMA6r/wOGC+xZQ5JUx56pHe
vfebik5wEC2TA8vAwaBiqq1ORUceQkn2sXYbJcRFRRwINB3ceuywYp4gKxq4
93ioDlvzrzskbIh+CXMjzE2T6Wm3nmYUNF08pULTxO8x/UNnvBG6OWWyNpsq
aU7flfXUUIg2RTnShPQYWL8fe+aohTl1Up/gqvNWgDYpsVnS+11/uklpzHcN
jI75XF2Xwvjqzsi2Sik7ZW6IySOHmILtThL1FnkLGg41yqbAYDRNhtTomWqt
ECJaY9GNBCAci4ahb1Cp00m6O50uLh/i49X2qx1iiwc6xTJvUUp2F2Jq4QeS
C0cTaMFSTPAEwz0oqIQX+mq14+N5H3yKiZN381PqlJ50GPi54qwzywcRaAtl
PODu52drhYSlnFrY4lM60Yxzjoj9yRutSqEoR1oD4cgr90Yc6KutHK5b4Lnj
RK0VYtgCayEWW7OO+lUyHw11XX8mNBQZ5xvNGx3nKpp6NVoj54V5H31UdyfW
Y0uLhK2G6hJlCGYDzp2XE44Fvk2bklK+8m7wiE2MxlE2E915Tb9cE8JcC3bW
aKAXMEqpy00U5Eb90d8I59xktc5WUFCCe9GYcv9xbcegl9IxSbG91srZTTBy
mSnk2fySYW3xvNJ5O/zjp/cnh/ooxxayMUqBQ06bhaEXFLAqHQpUmlmSBUHn
QolhMvNmiYBckEMVnMzpikvYpGsRD0aMUSPNbPmQmGuOa46M1i4nCvIRmgQJ
dBxE0QfMP6csQJEkQhZJCstiktMHwCVCO9cRVEHhxogHQ3T8bIMp9YzAhpHO
Lk6vFgue6rmRoiSiI2/6oJ/BikYIjSF7hw7X8nQYG/RS4K2kVO5s0fEcTiHH
B3u7PXxgDIRiQqWOFThtdS2KwSHG5Po00g7yQtU6/jhr8ZfFQe5ufIAZCCT2
+GwfzKNV6IZbtdQ68Hv5faMAVwcGPsXwmvoZTQu0s7a3aFQeT7wbcSxnfHUy
PhkievkIIRSkw+6ur0+xm32rF410LyRT5RoPJ8Cfp3hWbh2+3+D+OnNYsL18
aGdYhiWupmwIW7XgFWXGZrhJjnmi6RDAQex/q9YKIdE1fFKMgK5pWk6jGWlz
UZpG0w38sBIB5eblMKfVaR7LpIcmeLlGpE5Gj8WLX3u0PeV0paSvYZKraKV5
kH0gJRpEbXS5K1Lj3NShs3dRlhK9Qk94cjxLmcC5pT656CcFRkpH6Vj6O8KE
WHYi3zpGJhrCXsev1o/h/xvC315ub73ig1Urw6qqsDoGVvrQOMlmyBuZ0965
8YjsO2QhdJiPeD6e9qY3TA2O0II+9Ubm173otyGefBt6YJjEeFxPnWgzHGzK
k/bVydGGvTKmjMhAlxGhWeFyrV+8fr2h7lw8xuhP/LBQQQGeSskSZ17JEjZ8
ddmUhwdHlxKxTvn7+eFgfTr0I46PSAJ7BaBwRhlVUNA8++zgUEwEWV59SpKT
R/ngvocWccpnQtED6bCHSqbLZLKJOxH2tDtL8OgkhQGE/W/v0vb3NToTRqfj
V9ApMk66Bg0girXigceBh3jkNr3z2GB3DKh68bQ1akCTF8JLTij6CQsDdpUc
G7QnLCdMkVG6dLaeTlHA7+jdcpD++CHPgtm/3SXxXhBWIZ99xu0wBbseG+kx
HLM/tOUnOfl07ncW4zFWRajoqBPs0ZniGgNjuy9yNtI0vLELi6zRqSx0+gWi
7jRwDVgwG/6rmn7QPtEah5QIOf75/KINlKQKBSl4xxzIUQM6zs/JSHgCgQpe
2GdH87wk2h2J51G5hTY+B/ms7TeOGBv9K2+1tsAaOwiwCgBZLYXz+FqACByJ
NUrCCNbR8VytBeSABD6NAM61PDy+xr6PO9Q1SY+kEDV8Uox2r20wnZTOIQkY
TTPI4SOvVsDVeYZSdsP5pnh+warepD59Yyk6crKQC2X4U+6RTVyKI7Ds7716
1eWTb/YpkFxn2d9+tUuMG8Mvfzx8d3SsXh//eHJ+9T3SUQnDf86P7HW4QI62
mqyP1Kf/4ShFdcw0Xrqd7nf4EKUg7HWgwlYWh31s1Sd3XNL/OA36YdLHZv3C
olJDcerLM3iED3nOPDYGvaXcFQ1vmuCL7/iJOUv3PyQA1cLTiYigPhi8VOsj
r2vEFeeo5UN5MOgSdweAOC2NFsKjuaPt7+x2c0fVYaHoS6lEBldWqoeAOVlb
BDVl45YgAVTNBwQooVLHibiaBo7B0Y2sn7r6N5sqP1DcbQC6EG8vgVt497UA
324AXIRDLX3pZLb5MMMma6Ix43q7FBGEekENIJUydCU6L7+fCxAe1l2xHmsN
PvMKrfPg7S2At/cbgrdYOK8O4sIXXwdm/McuX8qtWlhjVp0fX5+9O1K/wD5A
WqJYOTckq3SYyse//Kh+8QZ9+NUUYAOKxFplH7yYqgBQNba7yQsuBvBCQIN2
CDA0xDKpadTn13/WLRg6+Dng4mzwW6Wwa2WW0tW8Wq6VXoslaZu6XFSGttJt
fXXdpu6XKKbLyLdyuGQBtOwmg1c7DLgiHBXKYaWFXEp20eOOQfBhNLsHa+Mm
VevDDTxLv0dVhtU11jPOdWWQwFTzIQ8xuno6XD/P1DpBe72j0H6jbkndxZDS
KB/zEmaISTODjE++h2Tvo4Ij4XF8Im4oUsE3OTYc6TXX5YBg4lRIjoMoPhXm
AcUPTcBZFicZV09iPSXJBv/lacLNiwsNYVvp0652mJ0Vw0vv1kdvwOurIyBY
+lY6QMcWwAZQAdg57x8aB5VB4lqiTr2JG3AFSdrDBg9iAwE09P2RqHb6g3Xc
VbCpqLi05+UbSuBuYxBpI0csUUNBi/QT+0ixbaVr3vIdTEVPSheq8NPEC8ZE
NnSCNSD4sZASFiFqieIUezwduwKD8LoKoSJj4aqAplmn9fX4nrZWys7aefCf
Wd6hiB2W7CHFYh6sigORzx+mcDhzhaHIfyE5FGNK+eakgRWGLhxkXH7okC3N
fHACZdXBOfq8wrAc3F3QKyb+r9Cp5YUt9axTisVjTVJ5XsevsdKGaTSm8KsO
/Jowa8MQ5EfZ1r1TkUJr1O+aB0ULUbpf4BwnrfDUDz/wYGZbSHLHHLh2Pitc
xmk/D4TdZwGBRZo7TiUumccL1jk0B2AZvFBG1UzqmcYmcox1vFwpNidhY+iG
gNxU5Nk1PdQHuY34RMUA5yilXiSKun7wdsNi3qoQC8qTNKqoLIU7TPs884ii
XWCTHF5fsPQ7OsTAKzqvwoIDLkeiSoY3HpYAwuwPmGdeWQGkTPvkomHNSozz
WRfNC0eadMycy8RcTJ4hgRd7M9Q5OFRaJcMc3YcX7NO3x0X8UEgyp4dyJ6YD
fGFFCyvw4zsB07QpLjYxGikSSIEK9gfS8UMTWkKQJN2iMLQVaxUAYKVfyBon
WTwLsoSrM6/7Y3yY06teXNBdKE9N1laVFlefa1vIC09sXqhTfShLYIGUxzyE
vloiaSA3sHcsz0ABWjA6CmSooZ9DgwfDD2F0F3gjPmepcyDwVN4XBDy5D1cF
/Oo+HN7EYB78Az3lf8+oqpQkcn5ByMf+ypCfR+ywJ4o2mcqwXXO58CUgz+LJ
qpC/jydIJFTjEAtCfR1imSU3qwKOnPYig3a6bg7DjfqbP/UD1xTge3/5I78i
weUFQW6ycu7j0PNv2Uk/iyPSwzlpRIfqXHpwLzU76euR6cKKOw2obrSUG51+
QezFuYdzWexdeiiivtJqAw5Xhff48Lx9PLyJvhbIw7t4VZBhrAmmw0O3v/jh
KLpDF0GGzoqvAL+7MsbBJM2o3Ceg3tbnLtDUjbIEk5MSjuGeX6n184jCxdkU
oDEJGSCGctXGx1qk/rBB5aLzznRIwzJTCFapDkC5WfPg5ZzYPOfBwxiSzl4x
PNmylxoVdjvfYTWLCXr1b5ED5LkgJjeoYTjMo7CnWxx+HgPEBIyxlPwbUHl7
YFgNo3CaxuMGes1tlx5Ln5mda8bOwR2OgkFHHfZrGgUsiTaMVZyUHnsepUhY
EdtaqcFYCjYemYMqoG1nQdo0un1+9wnT1MHT+VO1TwEXZmtDMWfCBUVWD0md
yekYKq85Mk4Fs2cNMiQtrA5KHHvkjfM8JAGQMDPAuyw+6f4wFQKLj3/KBzDb
bOu7/GHNHHgeY0XJfbp4XuhNzAELU7PZMFWJYeiBeQp1Q3eXGFq8Lr5ObqT0
APjzzk90PmdeNTpPb7H7UGvrpB7+O2d5bag//Yl/W2sCGU2eOoC3lwD4ANqW
wJ3q1EHrsBUtEOi7umRHpwDxSao8KpKdcnbgGl4NuKbY8Cp3YVuh+MO5cdgp
aU6cNGnS7DeBvvGQxFwM/duf1FYNdh7mmBDmpo0bELjmeIkkjfDxnPJM12Ay
kl5MKFrjKU0xVoDkOmDgQa0EhuCGHgm/+k1QqEeyYCeMxo/eCEdRuJaawag3
yezfLS7gGc5B4AdkbFFFU8xO4nKmiRzRJE8Pu1GbaNFP6sFdZvOcUC6NQNs0
wLi+/2Vo/Y2PGvCiAYL6AXaWGODUndv/HHo88sek2lmrxaKxnGtbT0815dgK
VIVJ+NYzrH2X3qhWobQSZoX07ZPa5mH5KHbLmvQfuBf6Lv/EPELpofEwb/rm
Qiej4tKmrBy1bZx+uYLa806/9xWn31s4fbvg1zPO2xyNb5ywfPBc0zWndRum
Wap095xTtQ/2N69v/tHzTdk6JNlA3NVKas9J3KXyBE2Tf16q5rO+BP78efc+
67x7X2PevQXzNgV6n3G2ElJsmiS9fr5p8tnewuSqNermWUPW5dEgec3hPCNR
ERkVQ0IQpR8b4VsrrFtvWe0zZeCN4744ksx/eBNh3i/miebD1Xd8yJ+C0oua
ZX6oUB8EGll6wdCl02FcSM/WOnCCnJFYKbNnfyZTtopCFd/mnhFa2JI3h38e
7D8aFBt2mxhA9ZH9AsrycwhkLBab61If1tytkR8K+JBagWV0aH28Zv5c9+27
5SZyzaYIdaX9P+yvgEntsv6NTtr71FPdndI0KDeH3uzaCCjHufgHg3PDwMWL
kTihptz7dqnBMIo5PX5kwq5eHqiTcCEfEaKLRqK01IEcvDSVMsyNbKXv6s69
crTWj3ONt3gUtjIUh5YPzg/Wljn2Wmqen4JdK52CLZBIjctTlnE1x2dp9PzH
coiWvlnxEud5hP1QxwhLRS2XZ4dFA+GxPJEPRrSIQlqP4ZUFMMr8koCxbVsB
pGD3Lhg1N9Hv6B5WezxzfhLM2eLYZTTPK/A5D+c5gZqwbuV6UXLesnXG95IW
1qJwQq6EB6pMaHMyzjBqbXU6L2vM0noE0amJysFCfWyGhwXy3yCuY28BTCv0
4uBeYfw3lLiVOv7PC/qydi3rnd3z5U9B9tR6kRdO8aJUeIFPTdYBWDlUWIKx
pmDqAvpjV57loBdch5X4gIVaXJMMb28zGYjMr430p8YELK+51Zb71xeY5F57
9qEXBoF+bZhGkcfXNVo1Tfj0KNb4slpCj8UDr8j2r69PLaZbw3CJ2eIh2j5P
m0/AXiFY6lhGqSWa8pHO3/KaELBWKwb4edfE+t6szpdek9KB2tKScDm/Batw
WTRhedZcrmXGl5Ri8lLF1Vu8crZeZOiTvXX8cgFUeEy6nUagNt8KKciheu1g
xqosz4vTsrAp1EteXqLrDKYiiCzQWelbnd9W09AWMtuTYqmCQlKnxAeohJLe
N9bSrlQkp9SuOOsCrVJphhpSsJT9LESVuoUKdbJIjylOML8TmhqThjMJ6dpP
SsljJc2cb9Dg6soRmAbCFyQLujgfunk2X1A3WwyMuY+oAAsfO1i0z268xjIZ
OmtPI7DMhvkryXg0sXayhnJuPLi3Wq0xvtfUH4Qc1ubrewuTra/sO9ZtT4Vt
dVOS+Vy6q8cNn8ln+i/2Xc9w8Lw6MJiR4mptfcXH21kG6KPu+nx7zToytOIf
LjGJQr3zRTsD3XG65pN0VzsNPTYNa6r95kPjDYB26bIF416Y8ogdZRWpswqu
+7b6IqmtdC+vlehaV1bRQryli9AHFsvMMWWVabcsOetseZx51ovGCBAOU6jz
pqtV5jOtUfAtFXZlEDF0t9ZR3/9JdTov8mmuFR0lXhxHcVuuFrZfyI62BhfA
pxITtKtPFhvatShzHapdvwoFT1MT+t6TYrwi+mr2gxj/qysRpn4FywhgVBPP
6lBmZcFcyMDuka0oRZ26L+mv90cXdRyYIcVi/3X71qr4vwDgNz8dnZvyeTpd
hMFuHjaL/bpR4fGC0d5fniw1WJkr15XDnsekD6MgEM9MXhpUzjBIa6uQsAFQ
p+igypTNTCpDKWLd5JyYewHCAsRgOYXcnJYz5Urf5L2E2vnyFWidJyjFsfaF
Ob/OHRh3Vq0sHxa80suTOhVjzQYF/81nAbB488JjdI73IdX6ZM+mrtglPpmU
ZMAt6iPmtFPR8DAVW7lcNJ7RfK75Lqb63pOovvcFqb7mco3PTfVY0HcJLKt1
RkbdIUfFKS26C9PkZzkJ2oPGjU1FGRw2W6RP2VxLUtpvHwm/wQ2siPbsYrdA
gWsaZ6+j0f2a1YGvY6//2stRMXaarqtZnssUmlMOZzF7U1mFV/PaPguDoKYN
p7KO+SRhUMnWNSSmE3Krqm9TcLPoXi7l81oU3AilaL5shY8t4CTdVcz7QtTy
oQK0P7LBory5FuXueqM2Wrh4EwoeKF8n7Zyh3FStwtL/QbXW8plIvvLaRqs4
4eaY5jk68rSLPJpw1SGdrUsgMSoTLLOnu2/Szev8gPMxGFrDFzOVG5X1nKiK
1aAeSVj1+dFmneqysFcksJoU6kfQWBHOZemMlfa67O7FJGfDPY/s7N5Xpbw8
QMazgz+xjr2upcaESHCWGN6aDR1VLFsrwPE8JHpq7ntIuO6cBo4OuNp57ugE
LIAooBuxlJfP9amUej15V/TAUv7kPO5Mx9fL5UsarhUxoJqrMPhEjRvnd6u4
edELV5duNCph7jxqF7zM5MWx04CatuOplQmi86atO0XK+7BMuquto83lrMtX
8Mo4yV3XB410TKK0mlae0o1JNJclxaSLMu8oMnsLrMfPwbpox/5m/s4v+/eK
Hj5DWytshQIZle4+IYQU8DYPOU0E33s+gu/V0LeB73c6/03S+YFKvY9U+tju
rjgpXJYnEX7vUYTfm0v4qxO7SZN+ApVz4Umm7qHlZi1ekqUvPikRtoz/BLI2
tyRZEH5GmtajfQmK1hiyQSf8+KPWEnBf2HdEWTc1USRQB/SAsnnpSlCXQ86C
yaLF0ITJeVqXVWVZa/01d1o1aU+SzFrGyrwB86RWrnlvnL8FV30s9rhkL7ol
bY8vuZgHpG0X1N8lWQR4DsiFcK+5H4j2WWlIcqAlS91kWWj3UIPcuXzCPmPw
FF5hbn8w/ML2Bi7mFxYcT+EZ9v1iX4ZvmIk3MY/CsmpG8jRx2BRR0r7AsCQm
a32EzfNewn782U7xqzkusojuyic8nqKM5ec2Hkt9TyO60sGRL0N35UGbxVaB
/p5EeVRiLl+4ivTCh8vIr5P8EqW6RSywQmKDdZG65cms93xk1vvKZPY1iKz3
lYis93mIrDeXyHqPIDJ9790c2voxnmWUusX3bbLcL5ZUlKkXUoUeQSXlTp+F
Jsr+1HIWkVk9QiS9nRchsE+DzcPaBedtol2rb4h0U65S6yXGQmK7uuQhSFLQ
sfiarmrIoMn11YTbZdxfkqdkoe2R/i9NjSUYiwGwwlxqvRqPn8tcz8Zyvo18
Dr1l5lAxVh8JfJPButBk1dq2hqMR0Dpt+bHAzteY54sTDbANTyOFNKhaj6WQ
herWUqCXoZoLfY0Efwr0c6X48tD3FkNfEg2N2avRrB14t551cTnDXWHmOYP1
6lisXLtlHcFtzWOwsyKDrWGVday6MW/y8ey6lmHLbG0QzBu8j6MvScntkRfe
t+lKl6VQon+Rfz39wLMCUXIQuS+HMedi8WA0yivUcPaBlTFg7nw1yBVPR7FM
69zDJXitcH4HmpvfrUGZzvbZ3ZxVlXOplfLHbV2wuVUus72cRmVnquPhsmq+
uX0TZdXTJD4N6zxCrYJlcFRShpbHUK0S1M4VrEq8kvM49CH3lZCBN4ZhjVgs
oVkduHZedpnsRdMqXGcohZBLV1KWNXC+PL2OKuhME79eSBn47VLeSH3rl6EK
vrrUKmVXU+fbIoh5pyHnKeBL7OyaHQ2P7Z1Nvwfbj93geA8b5ddjDhDXZecU
tzpmWlNrvgH31peLFP+cEKVolNxTqyGrmAJ0QVx91sHSBsFxmJpioXLjnOyg
ILpLKtW0ZM75iYz8wmydhMCd8AXcNYaFbBzCSxn0Rh8VrkuuCvDRDqmaH+e3
o9r0SGf9S6cHDOI4kbx4CsNCXs2B/zwR/o+UCM/57NjDWrmLucnwNJ1rk8tO
IOhM+IBrvuJlmnnie7V5fsSTmlfczQ8luJvOGMxBOEHJZw0or04uC5HLEkoj
PlTQmwO3AnofCybn9K8E5kOJTOq9/w2nqqyJFH36tV5867yV9/fySs2b1jvr
PtUBXU8Y+LkmQhsCREV0t2gx6g4cLVqLeXDRyBKRWTVghT9VVQJ/GsowPPYI
UwUXtRGUgnFSvcGjgaFbXz6WoReliwUyMoYVL7S0Wi9/taWlUDA3pkkty40Z
/GdnxwjD09gx9vAkdkwgPJ4dY/Mvyo7DynpWRrQY8ooIfk6GvBDQf32WzLti
BZ682nLMjUTT0F+aKRNDdm/6yly7/Fpfuyw8ejV2/Py2wA79g/5X88tc6+At
s+cQubxcqOVSpQH+XZeISUyVU12bv8kzbYrKmGVmthVGKSbPIlBUHmmjwLUa
+VXr2EcWLyWVojgvWpPcRFkwomxfXozRphpkaaWG0yBKb6om7cryC6dusFH2
8pQqDxUdarSD+Sa6tu0Yt69H1WlY1aKjC+TtwdzynjSEMVwomEVwWAhyRyOQ
t/UlakZYRD+kUxOfH/JmmC0wlgS8PiGDuWWp5OXqUFpJGgUw9RsLRiKH2gMn
n2PL98wvS2z5ZPk935u/53s1e37lzdV7ns3Vm0+i5ZK2z0ai+qLJ5TfT14L0
X2QzhXibbek+str9JEB6+rK0+hN1Nbfk9vWfhXbLnNEkcjUN9XFSckx+7r3O
Uj0dzvS/S+30Yk1CnSxat53pq3alLuQzi/DCIF9WjlfrkQqXMVVUm/kLlSes
pAbzRrDqRa+8CXTybh1HwZcL2ckXBcwauAa6z0Xy2Wim/11Gn6Vr9Cp0bi8m
dPTbXMwvCtjXWUwMQJtfllnOQvZYaT0lFl9T06ta5Xt1ZbqUqFhAnvVyKRkl
cfcGSHvPAGlvHqS9JSB9lhWXI6NzF/awcEhan7E2d6mqS+DdoBpN8cKM4rlX
TiJoOqZtU0ac92HwzUc7tRSL4js3pvH+pNYY9KE3S9cKhzWbfIIWiCD7/REX
WqIBuBt9JlUSDuuEFy3XyBv6Uzfo7dqjgtZLrdsjf4L12Larje1CbRjJhnXH
9MTlXbSujSJ95FQnkIhHtUIfD84fD98dHavj86Or751//vOfjvMNFv3NsCoz
nu1P0DHCpfgch2rcJZ5BBNb7DjABy9xqmnqwjOinZWgHnGjx6VNeR/glhth+
OGkf0YXl7dBLoZd2PB7u7269HPjJw0MHB/JUi97L+dtW4abykSmtTkX0CAwO
8/qJAyNz8WbxctGV4PDnre9SJyYlIATVhjaGyX/a1HefOufH14fvzt8A5D9c
vjnsbe92Hx5I37o8vrLf7G/tbgHE6PhOvEXdq/XuBqgut7jLHSz2h/mXQ/TO
57e10g3C+rLeq6u3Ms7u9t72w8Omuj690iPv7vbwCQDl/PT+5FAev9raAoA2
CNb1bTMc1RacZnTizC1cOCzYlggELrlVxLd0nzrdla7Wzw8OzzZgvH9DMHYI
NTM78j71XL6SHetixP4wlUWQy7BjGDrDiyU1kuGpQSvAGSfG6tElhTGPJxuY
ZFWYw63rB3SAuq4TY4mYu6QSqYxBxTR4ypgjgf9ZlbSImsJolKf6cJVOIHWb
/HQldwcTfRCIF0OsAUa/4Yag39Q63cukWlJLGZ3QLetOP0CUI37cjY5SBzAp
3Z0NB4IY+B88vHyJ6BlGSqIQPrt3ErRZUizniSfKswB0fmoOMCfRFM0uXlMv
vPXjiMtyYx05TE9yLNQItXkjP5VcB6YfmotnI5EDMglD6DCE6KmNMiLzmSQm
6vIZcYnWKMGNKNKVS8duPccbj+F7dO9qePMBaWMB2WAsHxk7lmOKPQme5Vhy
qE+LsjRm8Bx68kKjxg/o777jqDU7lWut76i+bGG0sRN9iitPkD650Fa1B1zC
PqC1abMPo9okfLO2TsJRV/ldqrJv9rqvcPtmIaIoiv1/YCkKXBm9WTSuhdcz
YEMqygjYwIqWcTaSzQKEieByWWPYcoChhCq+cFYUSAQtonRkDUlYjDW5m4u/
S9Fio9IR4X3d19KP/b1eJCyaTfdV85V/VGRfHUVXmHrnDj9gt9IahX0cTX1i
gSPv1h963ElAqWJzOunkK0WJfbg99FalkEGrIR2vpVJ3MsGSm45zFeX547Cd
RuU9V7fn5R7uoUhEb/TY3XeS8u7PEsefIiG5Iel3ujoUAqRJQDYmSq4J1lSF
/8kGJWTCwplCOBvFvckz6eTFcoJALlkwm8lp2EzqOTbTe5us7Skx2s1Go4K5
RNBIGkjctMycoaMr6XEQeEjCC8iCzC/rPg2K1GFzaHJweAqzPgWGiTcKbhb2
Ep4WCTmtB3kRDX3jBbPSsA6RN9FhMoxQoUc6o/fcEdc8rAEkzyRC8TUB0sh5
mtxvjJ1jxjVnKiJLA8k/iqYwlIvsDqs2baqRnwyDKCGOZ2i1BL7Qhs2YuIIK
3q4M/Bg4wwaOhoQbZkFg+IOw2zGW646CaHKvbnzSmkFWg+Y28XkH2DSciJIw
ioYZqTS5AsZmiWTSmlw0Ny99mxdkUxFI8PhWrt8QN3SnWCGS9S/dn7QDdjHI
d7i49qzETr1lpVrWR5rdETINYFA+320J41C6Ak60Bkyeho9yP0W+FgJ1wkKy
wsLXV9PgWQhWWnw/w8JBuGU66m1059168aZGLiZph0MOG+ff6k5G3gxrf+t8
XKrQygeHYapZiEW+uFA2p9OqS85UpFV0TUUvFiNap+52SaUmZWwbhAoNnWgd
fljQ4aF9wCXdI6PyGXX/jdwADozn/OpNsiGUTTc/SpVq0aDym1OYMCxOCTZM
pVAk6D2tSh29FovIVo03tyUElstfPiglnD/XjLCsM1VN07oRpXYP7lVETkoE
yxGwOurYxWs7Nf/R0MLHsMG9YJxXpPc+ziIUTSABLbaIyHBwUK2mbZbfatcr
Mbw2GZCUS04C9fLiELbRQUIkTtQiCmgY4Q6mRBQ3yNfNTxJMjc3Xy0mNjWGA
p1FDzyAgF08dNOTw9pmKEffNNwrLlF7yrTL6qZIS/WaLx97fYXwgWeqElHls
IHZerpJBX2b7tcKkhT2BZDGX1uC20a9Pjq/fqP88O9WD37dEG9rp7e8/PIAs
QQsUeuyrLA77aAD2KQ836X+cBv0w6d+74aRvG4aOnkfIpehATPQ5Den46seO
A4P11fmLg+9E2NOcAF1UqJVKXCM4VNsIKNwDrC0evUzdXxOE3tcFobBrnxsI
9kZ8wxR/xmoYHQktke7j6Lawj/yQ9Aek0fJowIxscmZ67W1tg5VdoG3iNcq+
uallbm7qMGHj3PqqQL1muitQfH7nFDIvnCbg1eEYYV8XZHOMS7GvsGrjf8KP
oyGoUPCyYFQa1sHyFwNL9fuloOo9FqreilD1loWqSOcrwVVsugxkxRZ1sOmd
UWTtHOGHLttn+ShMycT2v9E+7ms6ckb7g1+X95BW75CwdSLBrdTm1OexcZx8
Nk6N0Le3WEfuN4gS3KFDHKTUofWxg+zAOHjMNQi8Nev2l/PpE8FD/reLg8uD
s+Pr48srciXSNCkPVTOclAQua9Qg7j2dZmrt8freQD59D1rTnZxqKdxsPfJh
WilIfOiaxyCQl8HKPXckFgL5LAt9kFMB10yds8uhVQGVF5bmS7cEuPpinmT5
vjbJKXOnWl6YTVv5KThH55OuPrNKX5sOqnzAT9v5ITtWhaLxphU8FoMSEM49
9B2gfg+vV8yvJ6FDGpo2CuoGeQjBuvMmQLfDGxed76hEi8lEWxe0WzLZ0tif
kbbUIozRSFJEM5GgGvnzizeJEdJdfUsgJwtAFzipLKE+6OdEB0E8iSfgje8a
VjbjblxQQT0PL7tHfyfqetq5jzmPgyRCH9wIHQdIyK38sxamUpNFSnjnsXVb
+zvWs7m57nB+Y/MVTsqKOyy/DtjQcC5BSKmheb0Oa9GwkOgkJbeVnwYG+ZpN
YTuiSdRXQr0am2iZk5lJajd7xXd6r7YfHoDo7gNP7165IlJfmqF1WKFf2UhL
kDpFhLiWrNlCsXfrI3NrOYbOhTIxzgOMSOkvFBXQLG4xnzLSQ11Rz/E+ojWK
vgLdyDqiuiyHq9v6Je7RJzNAycSpR1kMjvVgRa3RZplb1+GH+vkrdv4rd/4r
Nvj1/eXp38xcdf1dt+Bs1zKuaV5ScZTWxdyz1TIGyBz+5riJqH/otHp3eoRU
yeSx/XIf1DnHOT/+pfzwr/AbwvM3S4L2PrcE7dVy1P/LBWgjUpaRn7BmXK5l
gQztLSlD5/T3aDlaP8Hfvhz9XYb+N5ehs9i/RabrfZx5sW9uKHyKIK2j9X8l
QVqz/0ts5OnCtNcgTHtfUpjOYXRzBCreEVERqPywLFBxhGOTfvuW028/o3wt
OZp/t1GXxMtCKdu8kDWydklJu0yfj5K3C6ngM0pcu+LzHMHL4vV36fpk6ToX
319PyHI9YImIPlKUNpPxv4gwfSzreJp0LaLNlq8XP3856brMrBcarfz73vbO
S/37y63dvQZjtuljSyY77XZbDdzhB4ofimT9uSRZy27kqsNZffrGKDIPHP3g
RNPXxz+enF99z1fwVD0Hf97e2t5qb71qb+910InechxNz+VP1SdYOPymraV0
t9P9zlF5CEm1VgpmtLCxHLWqvPwOCS6KJ27o/4P4oiPpt3KH1YHe1aImqQPO
f0nv1TqiaKNFPQw5LrZ0YyZzwPjB+Tn/2gUM7alf8MpR3o5HeLHNprrKMHds
Z2uLPzuNoJdw4gWYinZ4oF5tbb3a5VfS57UX9NUfump3e1dt7+2qPWzLr/4I
alOQRoSiP+P/OjDz73kGFjflWVxX0iMxmTUg9kn7wmzNtYp3Zk3ybRR3IJf0
SLRfgDmMZvexP7lJ1fpwQyF9KIojX8e4O1FwUCoF9EZJ57r0O+5W7oAzkXTq
kbkeLVDUa2KYsB7w0hshvFgsDqkKR8DsWcqJ4YOB8ERueMZ8HEAwcVGd3qYT
IpkNcXrWJnIHkzGnZlmcZJz4xbIPFIv/wrQcjQ4EFGQQ8AbMqYYxzLEuZD3M
2C6R78Lfr6+O1Kl8m3iS6QeAAUgAs84S2e0Mzf416FtL1ClZ93QEPqF4quAA
FlDq1NPnRyLL5P36TZrOkv6LFyl243mUzI1U8kKgbmOu0oZG6XWTml4iHT+v
5Km563fcQ+IxJ8XHkq+B4a5xBuvIDgrMhhvmZENkOW+sO2CtEw9z2XBFtFzn
xsMo5rollBhVpOKM8rIwXH11eq3IpZzceLCLi12sEQtBTrOGGaK0ugZrEyCR
bNAZRtMXQXATpR/cF+bzjQ5vNKN2lJjF/Av3Nizjo7RUd3d3Hb2ZX7AWQiv6
AvmcVe/sxYYGQOR6zpOJ51Z5AB4ByQBjFH6XRm6Sp1jaSoUkyenUag+j/lqt
M3dWs+Zp2gvmZy5db+zwpzZ2AICVZ6kHLT3vgIygMR4QBy++JX4FUj9R377A
Jyn/WTiQxCX8WAFE7oaav0Rl5bGiZ+p4eBOhdnlvHkuJPLX1Xd0RFfuECrYl
1fS+lX9bRgN9Kdezms8ebBCO8kNi78PYc4c3ZMGW4dlZCI/VkbJ6ehJwV8Rg
f8qg0U0FpN28Z7YGLItkIbTcs5Ku149My41FALeVgGw9VPyw19vZqZ8IyhA0
tiuT2FsIqW76JEQeYK4jLI73NkrSA04QrcDSewpCzQgKh1B6jFUwSyh81d2v
nwLRexnk/aW2yZNQd0nJswcjkB0pyFcuhVAC49XiVaReVKGbZcDqbu/15sF1
RWWA0yJv0WB1F3MRgcvu5mlgXftT7/jj0PPQRqwA1F0IELZXuoMnLZwRfCAR
gRFNq9BsL4TG9KGkkydBhHODnTWdVUFZzF9N4+cBoV7sdHeXh+MZhM9JnsB+
yaZyFSKLQ67OlawBlB7huZh9I6cqzKoWy0/itMU5Yf+ffUbCzc/c5EPjOr18
kvQQcYEjPGGhXu1tPXpatQu1/4yTetxKrTil69gdenTeo6rCbT1lMlbHq0+i
u/NqZ5VZYKn8CXBesG3EZDvGAiTVKXWfMiU9isqHUTzOI2a4+3JvlRmeRQM/
IG2sUTXc2X7K5HgAVsbMEKvN68i99UfqP6KbMAHM/PH7lXjgxW3vFwyHtA/g
v79EWXV6O09igugtLQ6w2uRe43GvK386o7mJgwsfduThv2fTznDYyab+8Kbj
jbKVp3/SPpi23+KxjsrUn2S60NTzzn9L02ais/Pxm8TFzpPEuhC3PdAjpcaX
x0ednNl5kkJQj43Vxc3nxcVRhMF3PELRSBNPUiG4f30i5LEaRPfl/v5jZ1W7
sk/SIIpzepwCseqMrv7nyUV1Gq+eMg3qcjXIryPYPW78wSbFKf/971EyjZL7
pOOHw2iCTtOV6PDiJkqz2K+6P3YXW8u67TJGz/bedrdBOByeXUgptSRL/QAP
RQ/urWyqYBrReer7vFRIBdjFljRFV/Q4Sg+E50zsoZQeK69bYGNTCqCoK8+F
D5ey9na3ensNLpyPfDyT3Z71TGB3sVGuu1HiAqWOloFsf2dnKcjqNvLuYgu9
DNeS1nENVPz/Grc6RTFsd7LUGOLsp2noTaPQH3LIU0qcWJELPTK1h88ky6B6
yaVTBzBT9cut/T5HQA6CIJI6Hj9m/sgLCAY8vv0z93sS5uEPpUzAwgQoqH6O
nGflcHeSe9pr/Oq2S10ukpXOTZlpw20rRcIQJd8tgVz7spB5BcM47ONx9UNr
miado7AYmNxRwHpHZgpzram4NC/Q3ls60H7bWyrU3stD7Tvtrd329n5jqL33
3KH23rxQe+/3UPuzhtqBdP4XJW/+L85xsaPuqwTcd34PuP8ecP894F4JuOvJ
9jj0ftt7bPAdC0TPDb8Ln/5XD78X5qlHrb5ZKQTfWzEEv2T8e7G63RD/7iyl
Mu/uNgSOL6jOynUUvfYnFaCWiV9RmRZoD9b95ImwzA3tLRfAMpG9J6NlQWxv
cRyrEtp7IkjzjJru9nKBam3MPAsotQGN7cWh6tx6eSIYZ1mAlf6SFG8AR0b/
U+bFNTDtLDa8TVdK96Wos6Ug3H7Z3VoSQpg21vKrgrh4/9eAyL09N4xHeCNN
FcLFzKAGQuzrifAtk4ews5g71CQiLEd++70GN8syiRvdncWMoi5144mgnXug
+Q6iRVhbnBykO3pOvOk+F2Gutzx0z4k7HczS6lcVsJeLl1QHxKSTZ6G0S49L
gKJ2WgVqsQAQOrO6WW5n7r/abfYznoOxZSUMNHHgxVKBvInYm53esAIT3u1t
NzCQGjAv+ZLAmsVdwklbD6nu8qnAUqTY05R95CfDCJ7c2/uvkTKXcdpy/2YT
KjNCYYuvRLg73e3G/Jv62RT2a/N0FoucOdMpspfnmY/4y7aXlutLeHW1D25b
PU3C7+w3SdC30dQ7AEtYJ2YaHIk22LwAi4UX9q2oc5OSmS+BVldXQX5v+2WD
D33ONECXbJ7EYim3YBKo6D7PFDiSekGOyPmyeXex9JOwLPe2uoBeDsoFQnp3
sSwsgrm6pG6G8xB70g64Cze9WY5JLpaUhY4V9vwE5vjqZYNUr4C/JFdcLEtr
4H8CN2ycwHPEGbt7SwrcZw40LiemGyONhlUvZQTsrWLdPd4c2N5vyJkuQTuf
8+ytYug92qpaFtZrqo7cBOpi6VoB1erwiZC+OcNMqTNNl1XoFktP7kJvx2Qp
gPb2eg2ZB5cXp+I7bmQee0ucB7k4Lbugl+PTe3tNOu3pOczyFIO5UfyeTik3
A7hY7nF3SvpT3OFqoL5scikdZXIUX/SA5qzxxYLP9GWUilW8b72XTWKvDCNd
oaLNkCqgi8VdFVC7yydCe7YEUS6WaGePJMqXL3cahNcyuSLd3hLH5OqSRZaC
7SnZIt3eYpFSky7yWLi+Tr5I7zebL9J7Qr5I75nzRXpfMV9kQTGlOekjUhJj
YQJJoXSGpJC8am+/qk0hKXxMi/HkJJJi6Q5sXkgjKbz+PZHkORJJ6mhKoEEk
/55M8n9BMsl/08wOI2l+tjI5HpvHsVQWB7JKkUr/mlkcTTkcj8zgaLy1e/mE
Dlywt9GsPbhvwz/vZrVq9xJODeRzeT+KO1pKP9vemhMqBQpnngl7msYog7aE
S1r60QKd6vxDV4uA48x4BM96Kvnye1uvGpTdN7FL98UugHoJY1o6WhXs+Tg9
DofuLMmYwemriy7c+yByq0kqSzizCv3ldyFJj0t5JHa2GqzXg8Lth4KGCoyL
LYdiP4LPJUFbXAaEKT1pWuklbC47FUp6e6bVPhMfYgPulgmZ6y5WQNu8mEeS
npCSAkSnpUcVqsUGNJ3T1D0ZQbSUCb271WBCX934014zVEuEUqmHlaDZ26uU
QHk+41QPVtQhaqzToo56Y+mo6jdpszaKvdVN2PkS9MkWbR1mlY3aiqE7x8LF
t7qtXkVzV69cw7uE9atzAK9MFUvE+o/uDKwnN7hP8KzXN7Pkge7IucoGEcwZ
C6QW7jbuq1N3+AGp5yqbUbAYOdYp3UoJDzk85nFPdLEldHdyIdZmW1/Llt8A
t6m4KjpWI9XMEO3R3bZcotgSE6P8Qc98sKlGEZX/TASiG5hXQCoyXZfJpI59
zAQ6fZ8wXg+IIgKvSqfakzfurej/uq8Ar63Ul9ZiTweHp+ayWLqQcVi4+hmN
frndL8Hlo/voFG3gYZQh3eOFjDgm3rlp7pkekKk1C1wmIbmA0aPrGB1ziyZd
1R3eRsGtdcefvk9TysvLfdbdne2Hhw2+/SDx04yhQzjwek3AG9hNBMYgokqm
GlHSm8MXGefySaNO7g8kGIwaPdZ3RMLMP32SWykfHrC+7x1dUSaPcq3675mP
iEBklvCHyfLmykl9ky4bNneRAYOvBtM/Du52ffE53lzalmth2zitvjsMklZf
WEIL/oI//iobKmf3Ldxu8KY19uMkbfNIrc38PdXzhvdEfHhfGD2wPsDCw2ac
/Jk1WnnM0sjT+3YKOG9jo83yR3JnZ2kAeYkw1b6Zt3H6NV/D96BVdPujwX6/
ByKz3+33X/R2K+DQl0wsq3Xa3d7ZhS5f9eq71HwNJtN9WfvFGDhuO3AHHn2z
tVVU0+nnodqwlY1mTQiSaeB+b/gEPuLbtaMY1wnIsxZ6hJ872a8CVQtWaXmW
ByH0/r4AhO5WtxaIKrZKTypgAhGTclpPerBj79wYVQyEC/ffLG2Vu3Sa/vqb
U35qhq/ZmglebT/6fW/K3hz+vjfpo9/35pfam45+jkpmQQL31TdaylM19z+1
juXPkyDIuOAGegqyQVsrlu8ToxGgInAG+mCgK6tLnhUqlmpdh1xfR6P7jRZo
lFd833VRdfDxkmCjtaIigbpN33Ha5s5mUQsC1OUKlwBP3dCfoTfDE40P9biE
PebQkevQ7byocY1JIfeT0uB0Lbp1pfAM1HlzfQK0zkKwAAK6pVrfbT7ybvkg
YFsd8a+kkOIdGj4oeEndHNnznyWF8Ry8rpwjVMoHlTWie+s7pMefuSFgju+d
vwdrbTqLwM4Q0x6gwzU4CHyX7kGPARCu034Fmrulxboz2PsuZx7hcuHRCrxt
PaNJss8iVxHl/nF2bZskJx9RP8qGpNdRSCJEckQKaLkMAer6uOkYBrQeWvoK
desZqaB4ZzWdQKM3PjtP3GEMs4OPbnFgudWe7q/GtIBJZOrcewErr+SNdxNL
/82dscq685vgDWBJEb/GU8w3a1uX4xJ05vZ1fac0UKBQM77H4vLvhTSGsUcU
p62nEzw2Lw4gW9U1ZnJDBxb4OmcMW6H9Iuahbtg49PXhBY78/gjWEduxl0C2
/TpugVBfD05BL/rIGKG0l6buB8xrS9i5MMtHTzY60hGdr9XeG9n6eVKdX4hk
De4Lr3EKm8ofS0+yBB2l3iFQd37ibYpNhDevo3VGpnieRof3DWAGnoXDpHYR
4KM233XPhggtM16yIv3ShR93+koJAx+yHy+l2BEOg8tIcW0YV28wcx19gT6E
/yCDg0mJNcd3yMdeCSPID6YDbZQBtLdu7EdZYtOtGIJMP5sGwE17STbVm5+O
zumaqp9PD87VyREu0jldL4EjJ5hKLLtSU/QMw2UjhmMEihiyEtnMU9zdYDR7
CEZKEbmE+c9rPxyxqQvvhc1tKhhIvUM0kidojMoZrE6o+ULqfSRq1pySsUP3
yaA1icICUTnA8AYwnyFvZvjqHqlDt9IuKVg/ZV8gz+05BCc30JAbh0WGz94y
l5w9+CWuDmbfzYjZyATQ3UB0sO4OULYN0w1EgcxFmBa2Jh8OXoixSXx7k+7F
4FtDAM0ITQLc2shBgR0+y+QttudOeMZZks9Ww8PUyLggCQMcri3BriGzQVqM
Czem/Af02IgXB1nOC+I3edxBu0/IhzOGxw9o1uMF3vt73Vdg148iLyl4XMa6
rXG9aD82TsSJxmMkTJcOzSMAieU7IqYHc42jbEI3wlDgGUBbGwfuJFmD1TtH
hg5vQCQnm071E4ozs3cLVnyogCyHHrJqAygvsAvLm07d5IPDQlqkCoyArkpR
XzaReklXYXYHTbgPSqQ3jMnRY+feCpAQEjPHmdKJYhLTPDjtK3kMw0+81NGT
Xh94Q24KLaJwDXkpGBRCrMcYUSbBzD4tvJQmXzb6kjDue0DJKPoBxjW9IoQb
0hiM0wUG99Cr4sNroGBaMs8sofHR5fOK8SrsTtktiBLjDaKgTDD4rEwxsuD6
2iSCl9qKBwk74znTNGCf3ER3uOq4C5kjpXE2TLPYq1KfQQEr4awK4KyjhFzO
8h3vm9c/ItiwHlewP2DlDWJJqWMkFqiD9APsBgHWBASfwAIieYi+Ks44CwLU
NDxOd8DWNSjHSTMWqrhGZF/COrRP/SlQxQHnMxCCkcOiX7yIYAlti+TIFX8l
BoLm4mtsBaypdb/jgZjgPw0OCd/sddvYVGujOJqZT/GPHNnaN6czP0AcC+ck
LkxC0KMyoZLzvkHiZi32MBNhQaeUHgId6vSwYk9aJWNhudFRb5lYNvlqMb6i
Wjs9iTvGXJWjMo4ghZGAVx8h35UlRTy3A0L/DBPD70UPGLoz0aeVXyBE5g32
smi2S0FRUSremLWm1ZyN0Z5BcVvVq0ibUubGqPyxiPhcadtAKkULBe0sfekt
7adh7ONwLvFasinybtjcAILMZhHvwzX9co0tFrUW7KzRQC9QNSx2uWmKoMgW
pm9mPFta7KK6Ive+ddR8YWIWifElkEm3gNFT/4PH+p4lzMFytO6YWiCtzAoA
6J4JZCNrZLLgZbv0EPsyBiUTp3S0io2MKzEyRKdxnLccO3DVJIgGWOdF1JBb
H/h1buYSY7jxJzeAdlSy+SJEXBsvxp60moVq50EoHvLiLXm0O1gbHTkFJOkx
0wgoNpoAp/EByHh4A7R7FRnlianeMd2lhcYBzIwicoRgyrtC/os6SN6Y9ZB1
uoxNYl/INzcczBgT1GjtZD1n+ql1DmIWgcaUbNB2EzHA2g7D0ZHLK+XPF9wb
o3Dkj2lQUCbY9Bfb0suNP5CSjog8ysHhQBPYYt9qtJJWZc8GZknREI0IjoHQ
qIQT4Mvf5mvC1GDuOKvDoWiXPqgVyBNd3uLMkBmr3FxfmAetUGDovlGRCALu
F2NlEjNEQeWQbkrwED6KK2kDzSEml70CJJG0ekYI10oiDkDd6caaMyZJNPRp
ipot0gEUNLZ+vnyzSaIRSM3H3pP7JPWmsvNv/Rg4cMA9M5i6TyZdinjd3CfU
FHBtdeSHoI4Yia89Gch7zi5Or3SE2GjZSWEZc5uOhCmbV6Yt6xe4YbSStogf
EdMcZyEtG8KixLOFUc7EG7ZFcUSlhyg2kexD2cmo+I6BB+jPECBf+8Q8W+PF
X70QtIOhxMbESlnXsa2gDa9bG4yQqgJmRd9+3Z0Tf9NidBCNyAx39Q18BFqY
pEh2rvBJfIa+HlAnUHuLpkg/pK/pI0MSNcVGrM5kIahDHKJT/5VE4fPG59Lh
jJVMjfhn9fOHWRC0OeK6op8f4GryYtvL12fYRZFc0qOMJkx43+RVzvva3Xq1
V/PNZ3Ysow73rG5l2538627ZoYwUG2rb/MgDOxjJ8RxLrB3QwpmTaGpdn4kx
rmPYONrSrd8422bjGG8E397pqot3V9f2VtGGnWf0SQ4YMBPqvtrv7HU73a2t
ztaL7V0SJ8a/Jn65vR0x9SNWhGkPCXgg3JlBJXK5bu5oBKOQ3aCa8a/7cqFn
FANn3CAxR8vShh7busekhS37ejsnheFIurVoSu1RCIopjy1NWENO1NH5lbDN
ZN5kP9vmR8jy6dRHAHc/TwSwBp0rBwJ3l+IQNAc9ynIcggZu4g8GN8m4vE3x
5+tzh83lVqBKnM+3AI35RzBuibirOFwxqPm4sOLCqOLezpdf3M8QUyww/+25
0cRD4Kk+pfa/sW06cim+MWxUqgMmNYHEnO3vzNGXcj1pNQlgAuv9Fzvbj+D/
yvD/L8D+bTMNSG5KaVfyjhLJMPkMzCgOTglGJSWNrkIH9BgfsmQ8ru/ubjCg
AAtdx/4EEVPA5lcVMJ8pxeQ5BExjpklZwPR+FzB5f88oYB6R6mNl4CBp/y5e
vpx42dHi5SBUtRKmLFd6y8kV8vqmmOVe9vo6TvFF7oz0yd07zgKSBl6K5/WM
f2bGjYD/Ypa4i26RhBwtBf+lkRe5XJt9Dj/AyUXbD9snF8XRjUOAPUXolsPi
X3YaMTRxpTgDjOTSVC3q77Y66vW98XMhoGMK6afiGxkhmIF7D93usP83pnO4
mLODmSEWwoBorYN84j7WsSQXY1HbW2pwj943d5xKEv7AmwDQstzkSsNM9fVU
C7/kgz+baeAoUTjvRVrwpIlUWAqiu+aN+Nti9lytoV1564U++k15HhjzRoTU
n0OU5RcaMYnXej1xrTCFXesr+TndzyYnBaLP4oPRfXefkf1ayYu73aU4bEFi
CkhNvTOdkgi0WxGlNiRoBl44SW+gyfZW7fvlhG8rB6ywj766xH0CU54tdvgc
23znrMh3KLJLPOCEtqJ9zM7ct1zxCyHLplQYi1PnXPSlzUXpCIjOdSz4cm/Q
GIjIwY25OtRf7IYTfUTis+1GHOnXNyen18eXz7oTV96BNvXfBm7Y5ok37RtQ
t7y4jR9SVmwthWdgOZhvtmsyip+TsucsyOfVRF7WEL1Fj/U6xsnVyVE9wfaW
I1iqjICd2FTKB3k+k/Me76D6zVCon/ijpSgUP+SU9jkkKh9t12W9/7eg0V7F
GZPTXz2B5iksNnHuzSFOK+vCRJuu/nKeqFEWc3wd/lLjIIow3Ine/i8XaGqj
gGnnED4rIefdtpP78LcTe5pr+Oc9bdd88GWMw0Wqm7VepCR1trY+3xbZqzEo
8ZagPJXrxI6hEmUXd06Hto46GH4Io7vAG7EnCAZhl6E3+lNr7AaJh5+dYRIo
GCfhB4oq/wdoOFc3kusIttKZP8m8QB3GUWIi/lgRxbuTImZT9vxJOtVIyt1s
Wll6s9iPyPSbZQPYQzfa9tHfUpaGHv8nPxuDHFFn7qb62R9iWcNTIKV/bAJk
njoM3PiDx6V/zlwg5Rv1Hx4CDw/c0DcQGrC4RtBkgvobpvHaQ51GmXrtgdXH
BTKubrzZjccJb43g8UXNrwOMEOrB0uQWc5gYK5t4d4v6xR+CPfUhB8gP05Ef
m28usKwpJkcliRxYxY+wcA6MmkZ0coC/vMxA1XwbZUng3Tv44cQL7dFwgqc+
zF4dZeHAjenBlQdM8TqLQ5kapWl4wxyCIiKOY/+D+p944H4T1vsDEBGsUjTb
VP/7/8Vz4j/fh0NE+mU0hW6PgF4CX0Y+8gbqMIoANjPOyfHVjzKK5DBT/bNp
Xv+MMxJA1caUurx40cKSRLXViD59wgMYbWxDuXKUPUH5M3LBlo8HWYrpddjX
cQb2B6LpEEjFT+iMPaervY1i/x9cNmiLq5JgVkyWRiE5tLWTPk8op6m7WE7V
pUPtR+fOmI70r+Mj/HUjL540iTE9x53EHrcVJz6e5uru7e+9BEv//wBbF+JT
VJEBAA==
1) VPN Routing and Forwarding (VRF)
2) Virtual Routing and Forwarding (VRF)
3) Verifiable Random Function (VRF)
--> -->
</rfc> <!-- [rfced] Terminology
a) Section 4: In this section's YANG module, we note mixed use of
abbreviation and expansion for the terms below. For consistency, may
we update to use the abbreviated form of these terms after their first
expansions?
Traffic Class vs. TC
Time-to-live vs. TTL
c) We note a few instances of "ISID" in Appendix B. Should these
instances be updated to "I-SID" for consistency?
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice. -->
 End of changes. 187 change blocks. 
2491 lines changed or deleted 844 lines changed or added

This html diff was produced by rfcdiff 1.48.