Internet Engineering Task Force (IETF) O. Gonzalez de Dios
Request for Comments: 9899 Telefonica
Category: Standards Track S. Barguil
ISSN: 2070-1721 Nokia
M. Boucadair
Orange
Q. Wu
Huawei
December 2025
RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document specifies a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. Specifically, it introduces augmentations to the ACL base model to enhance its functionality and applicability.
RFC 8519 は、アクセス制御リスト (ACL) の YANG データ モデルを定義しています。この文書は、RFC 8519 で最初に定義された ACL モデルの制限の多くを修正する一連の拡張機能を指定します。具体的には、ACL 基本モデルに拡張機能を導入して、その機能と適用性を強化します。
This document also creates initial versions of IANA-maintained modules for ICMP types and IPv6 extension headers.
この文書は、ICMP タイプおよび IPv6 拡張ヘッダー用の IANA 管理モジュールの初期バージョンも作成します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9899.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9899 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
3. Overall Structure of the Enhanced ACL Module
3.1. Tree Structure
3.2. Defined Sets
3.3. IPv6 Extension Headers
3.4. TCP Flags Handling
3.5. Fragments Handling
3.6. Payload-Based Filtering
3.7. Match on MPLS Headers
3.8. VLAN Filtering
3.9. Instance Service Identifier (I-SID) Filtering
3.10. Additional Actions
4. Enhanced ACL YANG Module
5. Security Considerations
6. IANA Considerations
6.1. URI Registrations
6.2. YANG Module Name Registrations
6.3. Considerations for IANA-Maintained Modules
6.3.1. ICMPv4 Types IANA Module
6.3.2. ICMPv6 Types IANA Module
6.3.3. IPv6 Extension Header Types IANA Module
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Problem Statement and Gap Analysis
A.1. Suboptimal Configuration: Lack of Support for Lists of
Prefixes
A.2. Manageability: Impossibility of Using Aliases or Defined
Sets
A.3. Bind ACLs to Devices, Not Only Interfaces
A.4. Partial or Lack of IPv4/IPv6 Fragment Handling
A.5. Suboptimal TCP Flags Handling
A.6. Rate-Limit Action
A.7. Payload-Based Filtering
A.8. Reuse the Content of ACLs Across Several Devices
A.9. Match MPLS Headers
Appendix B. Examples
B.1. TCP Flags Handling
B.2. Fragments Handling
B.3. Pattern-Based Filtering
B.4. VLAN Filtering
B.5. I-SID Filtering
B.6. Rate-Limit
Acknowledgments
Authors' Addresses
[RFC8519] defines Access Control Lists (ACLs) as a user-ordered set of filtering rules. The model targets the configuration of the filtering behavior of a device. However, the model structure, as defined in [RFC8519], suffers from a set of limitations. This document identifies these limitations and specifies an enhanced ACL structure, introducing augmentations to the ACL base model (Section 4). The motivation of such an enhanced ACL structure is discussed in detail in Appendix A.
[RFC8519] では、アクセス制御リスト (ACL) をユーザーが順序付けしたフィルタリング ルールのセットとして定義しています。このモデルは、デバイスのフィルタリング動作の構成を対象としています。ただし、[RFC8519] で定義されているモデル構造には一連の制限があります。この文書では、これらの制限を特定し、拡張された ACL 構造を指定し、ACL 基本モデルに拡張を導入します (セクション 4)。このような強化された ACL 構造の動機については、付録 A で詳しく説明します。
When managing ACLs, it is common for network operators to group match elements in predefined sets. The consolidation into group matches allows for reducing the number of rules, especially in large-scale networks. For example, if finding a match against 100 IP addresses (or prefixes) is needed, a single rule will suffice rather than creating individual Access Control Entries (ACEs) for each IP address (or prefix). In doing so, implementations would optimize the performance of matching lists versus multiple rules matching.
ACL を管理する場合、ネットワーク オペレータは事前定義されたセット内の一致要素をグループ化するのが一般的です。グループ マッチに統合することで、特に大規模なネットワークでルールの数を減らすことができます。たとえば、100 個の IP アドレス (またはプレフィックス) に対する一致を見つける必要がある場合、IP アドレス (またはプレフィックス) ごとに個別のアクセス コントロール エントリ (ACE) を作成するのではなく、単一のルールで十分です。そうすることで、実装では、複数のルールのマッチングに対するリストのマッチングのパフォーマンスが最適化されます。
The enhanced ACL structure (see "ietf-acl-enh" in Section 4) is also meant to facilitate the management of network operators. Instead of entering the IP address or port number literals, using user-named lists decouples the creation of the rule from the management of the sets. Hence, it is possible to remove/add entries to the list without redefining the (parent) ACL rule.
強化された ACL 構造 (セクション 4 の「ietf-acl-enh」を参照) は、ネットワーク オペレータの管理を容易にすることも目的としています。IP アドレスまたはポート番号リテラルを入力する代わりに、ユーザー名付きリストを使用すると、ルールの作成がセットの管理から切り離されます。したがって、(親) ACL ルールを再定義せずに、リストへのエントリの削除/追加を行うことができます。
In addition, the notion of ACL and defined sets is generalized so that it is not device specific as per [RFC8519]. ACLs and defined sets may be defined at the network/administrative domain level and associated to devices. This approach facilitates the reusability across multiple network elements. For example, managing the IP prefix sets from a network level makes it easier to maintain by the security groups.
さらに、ACL と定義されたセットの概念は [RFC8519] に従ってデバイス固有ではないように一般化されています。ACL および定義済みセットは、ネットワーク/管理ドメイン レベルで定義し、デバイスに関連付けることができます。このアプローチにより、複数のネットワーク要素間での再利用が容易になります。たとえば、ネットワーク レベルから IP プレフィックス セットを管理すると、セキュリティ グループによる保守が容易になります。
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 VPN customer. These lists are maintained and manipulated by security expert teams of the network operators.
ネットワーク オペレータは、VPN 顧客が提供するものに関連付けられた拒否リストや受け入れリストなど、相互に関連する IP プレフィックスのセットを維持します。これらのリストは、ネットワーク オペレーターのセキュリティ専門家チームによって維持および操作されます。
Note that ACLs are used locally in devices but are triggered by other tools such as DDoS mitigation [RFC9132] or BGP Flow Spec [RFC8955] [RFC8956]. Therefore, it is valuable from a network operation standpoint to support the means to easily map to the filtering rules conveyed in messages triggered by these tools.
ACL はデバイス内でローカルに使用されますが、DDoS 緩和 [RFC9132] や BGP フロー仕様 [RFC8955] [RFC8956] などの他のツールによってトリガーされることに注意してください。したがって、ネットワーク運用の観点からは、これらのツールによってトリガーされるメッセージで伝達されるフィルタリング ルールに簡単にマッピングする手段をサポートすることが重要です。
The enhanced ACL module (Section 4) conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342].
拡張 ACL モジュール (セクション 4) は、[RFC8342] で定義されているネットワーク管理データストア アーキテクチャ (NMDA) に準拠しています。
A set of examples to illustrate the use of the enhanced ACL module is provided in Appendix B.
拡張 ACL モジュールの使用法を示す一連の例は、付録 B に記載されています。
This document also creates initial versions of IANA-maintained modules for ICMP types and IPv6 extension headers. The design of the modules adheres to the recommendations in Section 4.30.2 of [YANG-GUIDELINES]. The latest version of these IANA-maintained modules can be retrieved from the "YANG Parameters" registry group [IANA-YANG-PARAMETERS].
この文書は、ICMP タイプおよび IPv6 拡張ヘッダー用の IANA 管理モジュールの初期バージョンも作成します。モジュールの設計は、[YANG-GUIDELINES] のセクション 4.30.2 の推奨事項に準拠しています。これらの IANA が管理するモジュールの最新バージョンは、「YANG Parameters」レジストリ グループ [IANA-YANG-PARAMETERS] から取得できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The terminology for describing YANG modules is defined in [RFC7950]. The meaning of the symbols in the tree diagrams is defined in [RFC8340].
YANG モジュールを説明するための用語は [RFC7950] で定義されています。樹形図内の記号の意味は [RFC8340] で定義されています。
In addition to the terms defined in [RFC8519], this document makes use of the following term:
[RFC8519] で定義されている用語に加えて、この文書では次の用語が使用されます。
Defined set:
定義されたセット:
Elements in a defined set typically share a logical purpose or function, such as IP addresses, IP prefixes, port numbers, or ICMP types.
定義されたセット内の要素は通常、IP アドレス、IP プレフィックス、ポート番号、ICMP タイプなどの論理的な目的または機能を共有します。
Figure 1 shows the full tree of the enhanced ACL module (Section 4):
図 1 は、拡張 ACL モジュールの完全なツリーを示しています (セクション 4)。
module: ietf-acl-enh
augment /acl:acls:
+--rw defined-sets
+---u defined-sets
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches:
+--rw (payload)?
| +--:(pattern)
| +--rw pattern {match-on-payload}?
| +---u payload-match
+--rw (alias)?
| +--:(alias-name)
| +--rw alias-name* alias-ref
+--rw (mpls)?
+--:(mpls-values)
+--rw mpls-values {match-on-mpls}?
+---u mpls-match-parameters-config
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l2:
+--rw vlan-filter {match-on-vlan-filter}?
| +--rw frame-type? string
| +--rw (vlan-type)?
| +--:(range)
| | +--rw lower-vlan uint16
| | +--rw upper-vlan uint16
| +--:(operator)
| +--rw operator? packet-fields:operator
| +--rw vlan* uint16
+--rw isid-filter {match-on-isid-filter}?
+--rw (isid-type)?
+--:(range)
| +--rw lower-isid uint16
| +--rw upper-isid uint16
+--:(operator)
+--rw operator? packet-fields:operator
+--rw isid* uint16
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l3
/acl:ipv4/acl:ipv4:
+--rw ipv4-fragment
| +---u fragment-fields
+--rw source-ipv4-prefix-list? ipv4-prefix-set-ref
+--rw destination-ipv4-prefix-list? ipv4-prefix-set-ref
+--rw protocol-set? protocol-set-ref
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l3
/acl:ipv6/acl:ipv6:
+--rw ipv6-fragment
| +---u fragment-fields
+--rw source-ipv6-prefix-list? ipv6-prefix-set-ref
+--rw destination-ipv6-prefix-list? ipv6-prefix-set-ref
+--rw protocol-set? protocol-set-ref
+--rw extension-header?
iana-ipv6-ext-types:ipv6-extension-header-type
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l4
/acl:tcp/acl:tcp:
+--rw flags-bitmask
| +---u tcp-flags
+--rw source-tcp-port-set? port-set-ref
+--rw destination-tcp-port-set? port-set-ref
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l4
/acl:udp/acl:udp:
+--rw source-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
/acl:icmp/acl:icmp:
+--rw icmpv4-set? icmpv4-type-set-ref
+--rw icmpv6-set? icmpv6-type-set-ref
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions:
+---u acl-complementary-actions
+--rw rate-limit? decimal64
Figure 1: Enhanced ACL Tree Structure
図 1: 拡張された ACL ツリー構造
Figure 2 shows the reusable groupings that are defined in the enhanced ACL module:
図 2 は、拡張 ACL モジュールで定義されている再利用可能なグループを示しています。
grouping tcp-flags:
+--rw operator? operator
+-- (mode)?
+--:(explicit)
| +-- explicit-tcp-flag* identityref
+--:(builtin)
+-- bitmask? uint16
grouping fragment-fields:
+-- operator? operator
+-- type? fragment-type
grouping mpls-match-parameters-config:
+-- traffic-class? uint8
+-- label-position? identityref
+-- upper-label-range? rt-types:mpls-label
+-- lower-label-range? rt-types:mpls-label
+-- label-block-name? string
+-- ttl-value? uint8
grouping payload-match:
+-- offset? identityref
+-- length? uint16
+-- operator? operator
+-- pattern? binary
grouping alias:
+-- vlan* uint16
+-- prefix* inet:ip-prefix
+-- port-range* [lower-port]
| +-- lower-port inet:port-number
| +-- upper-port? inet:port-number
+-- protocol* uint8
+-- fqdn* inet:domain-name
+-- uri* inet:uri
grouping icmpv4-header-fields:
+-- type? iana-icmpv4-types:icmpv4-type
+-- code? uint8
+-- rest-of-header? binary
grouping icmpv6-header-fields:
+-- type? iana-icmpv6-types:icmpv6-type
+-- code? uint8
+-- rest-of-header? binary
grouping acl-complementary-actions:
+-- log-action
| +-- log-type? identityref
| +-- log-id? string
+-- counter-action
+-- counter-type? identityref
+-- counter-name* string
grouping ipv4-prefix-sets:
+-- prefix-set* [name]
+-- name string
+-- description? string
+-- prefix* inet:ipv4-prefix
grouping ipv6-prefix-sets:
+-- prefix-set* [name]
+-- name string
+-- description? string
+-- prefix* inet:ipv6-prefix
grouping port-sets:
+-- port-set* [name]
+-- name string
+-- port* [id]
+-- id string
+-- (port)?
+--:(port-range-or-operator)
+-- port-range-or-operator
+---u packet-fields:port-range-or-operator
grouping protocol-sets:
+-- protocol-set* [name]
+-- name string
+-- protocol* union
grouping icmpv4-type-sets:
+-- set* [name]
+-- name string
+-- icmpv4-type* [type]
+---u icmpv4-header-fields
grouping icmpv6-type-sets:
+-- set* [name]
+-- name string
+-- icmpv6-type* [type]
+---u icmpv6-header-fields
grouping aliases:
+-- alias* [name]
+-- name string
+---u alias
grouping defined-sets:
+-- ipv4-prefix-sets
| +---u ipv4-prefix-sets
+-- ipv6-prefix-sets
| +---u ipv6-prefix-sets
+-- port-sets
| +---u port-sets
+-- protocol-sets
| +---u protocol-sets
+-- icmpv4-type-sets
| +---u icmpv4-type-sets
+-- icmpv6-type-sets
| +---u icmpv6-type-sets
+-- aliases
+---u aliases
Figure 2: Enhanced ACL Groupings
図 2: 拡張された ACL グループ化
The augmented ACL structure includes several containers to manage reusable 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 entry. The following sets (seen in Figure 1) are defined:
拡張された ACL 構造には、ACL エントリ内で一致する要素の再利用可能なセットを管理するためのいくつかのコンテナが含まれています。各セットは名前によって一意に識別され、関連するエントリから呼び出すことができます。次のセット (図 1 を参照) が定義されています。
IPv4 prefix sets:
IPv4 プレフィックス セット:
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 entry) is contained in any of the prefixes in the set.
IPv4 プレフィックス セットには、IPv4 プレフィックスのリストが含まれます。IP アドレス (ACL エントリに応じて送信元または宛先) がセット内のいずれかのプレフィックスに含まれている場合、一致とみなされます。
IPv6 prefix sets:
IPv6 プレフィックス セット:
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.
IPv6 プレフィックスには、IPv6 プレフィックスのリストが含まれます。IP アドレス (ACL エントリに応じて送信元または宛先) がセット内のいずれかのプレフィックスに含まれている場合、一致とみなされます。
Port sets:
ポートセット:
A port set contains a list of port numbers to be used in transport protocol entries (e.g., TCP and UDP).
ポート セットには、トランスポート プロトコル エントリ (TCP や UDP など) で使用されるポート番号のリストが含まれています。
A port number can be a port range or a single port number along with an operator (equal to, greater than or equal to, etc.).
ポート番号には、ポート範囲を指定することも、単一のポート番号と演算子 (等しい、以上など) を指定することもできます。
Protocol sets:
プロトコルセット:
A protocol set contains a list of protocol values. A protocol can be identified by either a number (e.g., 17) or a name (e.g., UDP).
プロトコル セットには、プロトコル値のリストが含まれます。プロトコルは、番号 (17 など) または名前 (UDP など) で識別できます。
ICMP sets:
ICMP セット:
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.
ICMP セットには ICMPv4 [RFC0792] または ICMPv6 [RFC4443] タイプのリストが含まれており、各タイプはタイプ値によって識別され、オプションでコードとヘッダーの残りの部分によって識別されます。
IANA-maintained modules for ICMP types are created in this document.
IANA が管理する ICMP タイプのモジュールは、このドキュメントで作成されます。
Aliases:
別名:
An alias is defined by a combination of various parameters (e.g., IP prefix, protocol, port number, or VLAN [IEEE802.1Qcp]). When only sets of one parameter (e.g., protocol) are handled, then the relevant parameter sets should be used (e.g., protocol set) rather than an alias.
エイリアスは、さまざまなパラメータ (IP プレフィックス、プロトコル、ポート番号、VLAN [IEEE802.1Qcp] など) の組み合わせによって定義されます。1 つのパラメータのセット (プロトコルなど) のみを処理する場合は、エイリアスではなく、関連するパラメータ セット (プロトコル セットなど) を使用する必要があります。
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 server addresses (e.g., "prefix": ["2001:db8:6401::1/128","2001:db8:6401::2/128"]) and the TCP port number 443 (i.e., "protocol": [6] and "lower-port": 443).
たとえば、エイリアスを定義して、一連の HTTPS サーバーにバインドされた ACL ポリシーを適用できます。このようなエイリアスには通常、HTTPS サーバー アドレス (例: "prefix": ["2001:db8:6401::1/128","2001:db8:6401::2/128"]) と TCP ポート番号 443 (つまり、"protocol": [6] および " lower-port": 443) が含まれます。
Sets of aliases can be defined and referred to in ACL match criteria.
エイリアスのセットを定義し、ACL 一致基準で参照できます。
Payload-based filtering:
ペイロードベースのフィルタリング:
A network traffic filtering technique that examines the data payload of packets, beyond just the header information, to identify, allow, or block traffic based on specific content or patterns within the payload. An offset type (e.g., Layer 2 or Layer 3) is used to indicate the position of the data in the packet to use for the match.
ヘッダー情報だけでなくパケットのデータ ペイロードを検査し、ペイロード内の特定のコンテンツやパターンに基づいてトラフィックを識別、許可、またはブロックするネットワーク トラフィック フィルタリング技術。オフセット タイプ (レイヤー 2 またはレイヤー 3 など) は、一致に使用するパケット内のデータの位置を示すために使用されます。
The enhanced ACL module can be used to manage ACLs that require matching against IPv6 extension headers [RFC8200]. To that aim, a new IANA-maintained module for IPv6 extension header types, "iana-ipv6-ext-types", is created in this document.
拡張 ACL モジュールは、IPv6 拡張ヘッダー [RFC8200] との照合を必要とする ACL を管理するために使用できます。この目的のために、この文書では、IPv6 拡張ヘッダー タイプ用の新しい IANA 管理モジュール「iana-ipv6-ext-types」が作成されています。
The augmented ACL module includes a new container 'flags-bitmask' to better handle TCP flags (Section 3.1 of [RFC9293]). Assigned TCP flags are maintained in the "TCP Header Flags" registry under the "Transmission Control Protocol (TCP) Parameters" registry group [IANA-TCP-FLAGS].
拡張された ACL モジュールには、TCP フラグをより適切に処理するための新しいコンテナ「flags-bitmask」が含まれています ([RFC9293] のセクション 3.1)。割り当てられた TCP フラグは、「伝送制御プロトコル (TCP) パラメーター」レジストリ グループ [IANA-TCP-FLAGS] の下の「TCP ヘッダー フラグ」レジストリに維持されます。
Clients that support both 'flags-bitmask' and 'flags' [RFC8519] matching fields MUST NOT set these fields in the same request.
「flags-bitmask」と「flags」[RFC8519] の両方の一致フィールドをサポートするクライアントは、同じリクエスト内でこれらのフィールドを設定してはなりません (MUST NOT)。
The augmented ACL module includes new leafs 'ipv4-fragment' and 'ipv6-fragment' to better handle fragments.
拡張された ACL モジュールには、フラグメントをより適切に処理するための新しいリーフ「ipv4-fragment」および「ipv6-fragment」が含まれています。
Clients that support both 'ipv4-fragment' and 'flags' [RFC8519] matching fields MUST NOT set these fields in the same request.
「ipv4-fragment」と「flags」[RFC8519] の両方の一致フィールドをサポートするクライアントは、同じリクエスト内でこれらのフィールドを設定してはなりません (MUST NOT)。
Some transport protocols use existing protocols (e.g., TCP or UDP) as substrate. The match criteria for such protocols may rely upon the 'protocol' under 'l3', TCP/UDP match criteria, part of the TCP/UDP payload, or a combination thereof.
一部のトランスポート プロトコルは、既存のプロトコル (TCP や UDP など) を基質として使用します。このようなプロトコルの一致基準は、「l3」の下の「プロトコル」、TCP/UDP 一致基準、TCP/UDP ペイロードの一部、またはそれらの組み合わせに依存する場合があります。
A new feature, called 'match-on-payload', is defined in the document. This can be used, for example, for QUIC [RFC9000] or for tunneling protocols. This feature requires configuring a data offset, a length, and a binary 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).
「match-on-payload」と呼ばれる新しい機能がこの文書で定義されています。これは、たとえば、QUIC [RFC9000] やトンネリング プロトコルに使用できます。この機能では、指定された演算子を使用してデータを照合するために、データ オフセット、長さ、およびバイナリ パターンを構成する必要があります。データ オフセットは、パケット内で参照する位置を示します (たとえば、IP ヘッダーまたはトランスポート ヘッダーの先頭から始まります)。
The enhanced ACL module (Section 4) can be used to create rules to match against the MPLS fields of a packet. The MPLS header defined in [RFC3032] and [RFC5462] contains the following fields:
拡張 ACL モジュール (セクション 4) を使用して、パケットの MPLS フィールドと照合するルールを作成できます。[RFC3032] および [RFC5462] で定義されている MPLS ヘッダーには、次のフィールドが含まれます。
* Traffic Class: The 3-bit "Exp" field [RFC3032], which is renamed to "Traffic Class field" ("TC field") [RFC5462].
* トラフィック クラス: 3 ビットの「Exp」フィールド [RFC3032]、「トラフィック クラス フィールド」(「TC フィールド」) [RFC5462] に名前変更されました。
* Label Value: A 20-bit field that carries the actual value of the MPLS label.
* ラベル値: MPLS ラベルの実際の値を伝送する 20 ビットのフィールド。
* TTL: An 8-bit field used to encode the Time-to-Live (TTL) value.
* TTL: Time-to-Live (TTL) 値をエンコードするために使用される 8 ビットのフィールド。
The augmented ACL module can be used by an operator to configure ACLs that match based upon the following data nodes:
オペレータは拡張 ACL モジュールを使用して、次のデータ ノードに基づいて一致する ACL を設定できます。
* 'traffic-class'
* 「トラフィッククラス」
* 'label-position' (e.g., top or bottom)
* 'label-position' (例: 上部または下部)
* 'upper-label-range'
* 'ラベル範囲の上限'
* 'lower-label-range'
* '下位ラベル範囲'
* 'label-block-name'
* 'ラベルブロック名'
* 'ttl-value'
* 'ttl値'
Being able to filter all packets that are bridged within a VLAN or that are routed into or out of a bridge domain is part of the VPN control requirements for Ethernet VPN (EVPN) [RFC7209].
VLAN 内でブリッジされるすべてのパケット、またはブリッジ ドメインに出入りするすべてのパケットをフィルタリングできることは、イーサネット VPN (EVPN) [RFC7209] の VPN 制御要件の一部です。
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 on the network policy.
VLAN 内でブリッジされるすべてのパケット、または VLAN 内または VLAN からルーティングされるすべてのパケットは、ネットワーク ポリシーに基づいてキャプチャ、転送、変換、または破棄できます。
Provider Backbone Bridging (PBB) was originally defined as a Virtual Bridged Local Area Networks standard [IEEE-802-1ah]. However, instead of multiplexing VLANs, PBB duplicates the Media Access Control (MAC) layer of the customer frame and separates 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.
プロバイダー バックボーン ブリッジング (PBB) は、もともと仮想ブリッジ ローカル エリア ネットワーク標準 [IEEE-802-1ah] として定義されました。ただし、VLAN を多重化する代わりに、PBB は顧客フレームのメディア アクセス コントロール (MAC) 層を複製し、24 ビットのインスタンス サービス識別子 (I-SID) でカプセル化することでプロバイダー ドメインから分離します。これにより、顧客ネットワークとプロバイダー ネットワーク間の透明性が高まります。
The I-component forms the customer- or access-facing interface or routing instance. The I-component is responsible for mapping customer Ethernet traffic to the appropriate I-SID. It is mandatory to configure the default service identifier in the network.
I コンポーネントは、顧客またはアクセスに面するインターフェイスまたはルーティング インスタンスを形成します。I コンポーネントは、顧客のイーサネット トラフィックを適切な I-SID にマッピングする役割を果たします。ネットワーク内にデフォルトのサービス識別子を設定することは必須です。
Being able to filter by I-component service identifier is a feature of the EVPN-PBB configuration.
I コンポーネント サービス ID でフィルタリングできることは、EVPN-PBB 構成の機能です。
In order to support rate-limiting (see Appendix A.6), a new action called 'rate-limit' is defined in this document.
レート制限 (付録 A.6 を参照) をサポートするために、このドキュメントでは「レート制限」と呼ばれる新しいアクションが定義されています。
Also, the "ietf-acl-enh" module supports new actions to complement existing ones: log ('log-action') and write a counter ('counter-action'). The version of the module defined in this document supports only local actions.
また、「ietf-acl-enh」モジュールは、既存のアクションを補完する新しいアクション、ログ ('log-action') およびカウンターの書き込み ('counter-action') をサポートします。このドキュメントで定義されているモジュールのバージョンは、ローカル アクションのみをサポートします。
This YANG module imports types from [RFC6991], [RFC8519], and [RFC8294].
この YANG モジュールは、[RFC6991]、[RFC8519]、および [RFC8294] から型をインポートします。
module ietf-acl-enh {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-acl-enh";
prefix acl-enh;
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control Model";
}
import ietf-access-control-list {
prefix acl;
reference
"RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs), Section 4.1";
}
import ietf-packet-fields {
prefix packet-fields;
reference
"RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs), Section 4.2";
}
import ietf-routing-types {
prefix rt-types;
reference
"RFC 8294: Common YANG Data Types for the Routing Area";
}
import iana-icmpv4-types {
prefix iana-icmpv4-types;
reference
"RFC 9899: Extensions to the YANG Data Model for Access
Control Lists (ACLs)";
}
import iana-icmpv6-types {
prefix iana-icmpv6-types;
reference
"RFC 9899: Extensions to the YANG Data Model for Access
Control Lists (ACLs)";
}
import iana-ipv6-ext-types {
prefix iana-ipv6-ext-types;
reference
"RFC 9899: Extensions to the YANG Data Model for Access
Control Lists (ACLs)";
}
organization
"IETF NETMOD Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Author: Samier Barguil
<mailto:samier.barguil_giraldo@nokia.com>
Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com>";
description
"This module contains YANG definitions for enhanced ACLs.
Copyright (c) 2025 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 is part of RFC 9899; see the
RFC itself for full legal notices.";
revision 2025-12-22 {
description
"Initial revision.";
reference
"RFC 9899: Extensions to the YANG Data Model for Access
Control Lists (ACLs)";
}
feature match-on-payload {
description
"Match based on a pattern is supported.";
}
feature match-on-vlan-filter {
description
"Match based on a VLAN range is supported.";
}
feature match-on-isid-filter {
description
"Match based on an I-SID range is supported.";
}
feature match-on-alias {
description
"Match based on aliases.";
}
feature match-on-mpls {
description
"Match based on MPLS headers.";
}
identity offset-type {
description
"Base identity for payload offset type.";
}
identity layer2 {
base offset-type;
description
"The offset starts at the beginning of the Data Link Layer
header.";
}
identity layer3 {
base offset-type;
description
"The offset starts at the beginning of the IP header.";
}
identity layer4 {
base offset-type;
description
"The offset starts right after the IP header (including
any options or headers pertaining to that IP layer, e.g.,
IPv6 Extension Headers and the Authentication Header (AH)).
This can be typically the beginning of transport header
(e.g., UDP, TCP, the Stream Control Transmission Protocol
(SCTP), and the Datagram Congestion Control Protocol (DCCP))
or any encapsulation scheme over IP such as IP-in-IP.";
}
identity payload {
base offset-type;
description
"The offset starts right after the end of the transport
header. For example, this represents the beginning of the
TCP data right after any TCP options or the beginning of
the UDP payload right after the UDP header.
This type may be used for matches against any data in
the transport payload and/or any surplus area (if any,
such as in UDP).";
}
identity tcp-flag {
description
"Base identity for the TCP Flags.";
reference
"RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
}
identity ack {
base tcp-flag;
description
"Acknowledgment TCP flag bit.";
reference
"RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
}
identity syn {
base tcp-flag;
description
"Synchronize sequence numbers.";
reference
"RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
}
identity fin {
base tcp-flag;
description
"No more data from the sender.";
reference
"RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
}
identity urg {
base tcp-flag;
description
"Urgent pointer TCP flag bit.";
reference
"RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
}
identity psh {
base tcp-flag;
description
"The Push function flag is similar to the URG flag and tells
the receiver to process these packets as they are received
instead of buffering them.";
reference
"RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
}
identity rst {
base tcp-flag;
description
"Reset TCP flag bit.";
reference
"RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
}
identity ece {
base tcp-flag;
description
"ECN-Echo TCP flag bit.";
reference
"RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
}
identity cwr {
base tcp-flag;
description
"Congestion Window Reduced flag bit.";
reference
"RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
}
identity ae {
base tcp-flag;
description
"Accurate Explicit Congestion Notification (ECN).
Previously used as Nonce Sum (NS), which is now
historic.";
}
identity mpls-acl-type {
base acl:acl-base;
description
"An ACL that matches on fields from the MPLS header.";
}
identity label-position {
description
"Base identity for deriving MPLS label position.";
}
identity top {
base label-position;
description
"Top of the label stack.";
}
identity bottom {
base label-position;
description
"Bottom of the label stack.";
}
identity log-types {
description
"Base identity for deriving the log actions.";
}
identity local-log {
base log-types;
description
"A local log is used to record the ACL results.";
}
identity counter-type {
description
"Base identity for deriving the counter actions.";
}
identity counter-name {
base counter-type;
description
"Identity for counter name to be updated based on
the ACL match actions.";
}
typedef operator {
type bits {
bit not {
position 0;
description
"If set, the logical negation of operation.";
}
bit match {
position 1;
description
"Match bit. This is a bitwise match operation defined as
'(data & value) == value'.";
}
bit any {
position 2;
description
"Any bit. This is a match on any of the bits in bitmask.
It evaluates to 'true' if any of the bits in the
value mask are set in the data, i.e.,
'(data & value) != 0'.";
}
}
description
"Specifies how to apply the defined bitmask. The
'any' and 'match' bits must not be set simultaneously.";
}
typedef fragment-type {
type bits {
bit df {
position 0;
description
"Don't fragment bit for IPv4. Must be set to 0 when it
appears in an IPv6 filter.";
}
bit isf {
position 1;
description
"Is a fragment.";
}
bit ff {
position 2;
description
"First fragment.";
}
bit lf {
position 3;
description
"Last fragment.";
}
}
description
"Different fragment types to match against.";
}
typedef ipv4-prefix-set-ref {
type leafref {
path "/acl:acls/acl-enh:defined-sets/acl-enh:ipv4-prefix-sets"
+ "/acl-enh:prefix-set/acl-enh:name";
}
description
"Defines a reference to an IPv4 prefix set.";
}
typedef ipv6-prefix-set-ref {
type leafref {
path "/acl:acls/acl-enh:defined-sets/acl-enh:ipv6-prefix-sets"
+ "/acl-enh:prefix-set/acl-enh:name";
}
description
"Defines a reference to an IPv6 prefix set.";
}
typedef port-set-ref {
type leafref {
path "/acl:acls/acl-enh:defined-sets/acl-enh:port-sets"
+ "/acl-enh:port-set/acl-enh:name";
}
description
"Defines a reference to a port set.";
}
typedef protocol-set-ref {
type leafref {
path "/acl:acls/acl-enh:defined-sets/acl-enh:protocol-sets"
+ "/acl-enh:protocol-set/acl-enh:name";
}
description
"Defines a reference to a protocol set.";
}
typedef icmpv4-type-set-ref {
type leafref {
path "/acl:acls/acl-enh:defined-sets/acl-enh:icmpv4-type-sets"
+ "/acl-enh:set/acl-enh:name";
}
description
"Defines a reference to an ICMPv4 type set.";
}
typedef icmpv6-type-set-ref {
type leafref {
path "/acl:acls/acl-enh:defined-sets/acl-enh:icmpv6-type-sets"
+ "/acl-enh:set/acl-enh:name";
}
description
"Defines a reference to an ICMPv6 type set.";
}
typedef alias-ref {
type leafref {
path "/acl:acls/acl-enh:defined-sets/acl-enh:aliases"
+ "/acl-enh:alias/acl-enh:name";
}
description
"Defines a reference to an alias.";
}
grouping tcp-flags {
description
"Operations on TCP flags.";
leaf operator {
type operator;
description
"How to interpret the TCP flags.";
}
choice mode {
description
"Choice of how flags are indicated.";
case explicit {
leaf-list explicit-tcp-flag {
type identityref {
base acl-enh:tcp-flag;
}
description
"An explicit list of the TCP flags that are to be
matched.";
}
}
case builtin {
leaf bitmask {
type uint16;
description
"The bitmask matches the last 4 bits of byte 13
and byte 14 of the TCP header.
For clarity, the 4 bits of byte 12
corresponding to the TCP data offset field are not
included in any matching. Assigned TCP flags
and their position are maintained in the IANA
'Transmission Control Protocol (TCP) Parameters'
registry group.";
reference
"RFC 9293: Transmission Control Protocol (TCP),
Section 3.1
IANA: Transmission Control Protocol (TCP) Parameters,
<https://www.iana.org/assignments/tcp-parameters>";
}
}
}
}
grouping fragment-fields {
description
"Operations on fragment types.";
leaf operator {
type operator;
default "match";
description
"How to interpret the fragment type.";
}
leaf type {
type fragment-type;
description
"Specifies what fragment type to look for.";
}
}
grouping mpls-match-parameters-config {
description
"Parameters for the configuration of MPLS match rules.";
leaf traffic-class {
type uint8 {
range "0..7";
}
description
"The value of the MPLS Traffic Class (TC) bits,
formerly known as the EXP bits.";
}
leaf label-position {
type identityref {
base acl-enh:label-position;
}
description
"Position of the label.";
}
leaf upper-label-range {
type rt-types:mpls-label;
description
"Match MPLS label value on the MPLS header.
The usage of this field indicates the upper
range value in the top of the stack. This
label value does not include the encodings
of TC and Time-to-Live (TTL).";
reference
"RFC 3032: MPLS Label Stack Encoding";
}
leaf lower-label-range {
type rt-types:mpls-label;
description
"Match MPLS label value on the MPLS header.
The usage of this field indicates the lower
range value in the top of the stack.
This label value does not include the
encodings of TC and TTL.";
reference
"RFC 3032: MPLS Label Stack Encoding";
}
leaf label-block-name {
type string;
description
"Reference to a label block predefined in the
implementation.";
}
leaf ttl-value {
type uint8;
description
"TTL MPLS packet value match.";
reference
"RFC 3032: MPLS Label Stack Encoding";
}
}
grouping payload-match {
description
"Operations on payload match.";
leaf offset {
type identityref {
base acl-enh:offset-type;
}
description
"Indicates the payload offset. This will indicate
the position of the data in the packet to use for
the match.";
}
leaf length {
type uint16;
units "bytes";
description
"Indicates the number of bytes to ignore, starting from
the offset, to perform the pattern match.";
}
leaf operator {
type operator;
default "match";
description
"How to interpret the pattern match.";
}
leaf pattern {
type binary;
description
"The binary pattern to match against starting.
The match starts from the byte indicated by
'offset' + length'.";
}
}
grouping alias {
description
"Specifies an alias.";
leaf-list vlan {
type uint16;
description
"VLAN of the alias.";
reference
"IEEE Std 802.1Q: Bridges and Bridged Networks";
}
leaf-list prefix {
type inet:ip-prefix;
description
"IPv4 or IPv6 prefix of the alias.";
}
list port-range {
key "lower-port";
description
"Port range. When only lower-port is
present, it represents a single port number.";
leaf lower-port {
type inet:port-number;
mandatory true;
description
"Lower port number of the port range.";
}
leaf upper-port {
type inet:port-number;
must '. >= ../lower-port' {
error-message
"The upper-port number must be greater than
or equal to the lower-port number.";
}
description
"Upper port number of the port range.";
}
}
leaf-list protocol {
type uint8;
description
"Identifies the target protocol number.
For example, 6 for TCP or 17 for UDP.";
}
leaf-list fqdn {
type inet:domain-name;
description
"Fully Qualified Domain Name (FQDN) identifying the target.";
}
leaf-list uri {
type inet:uri;
description
"URI identifying the target.";
}
}
grouping icmpv4-header-fields {
description
"Collection of ICMPv4 header fields that can be
used to set up a match filter.";
leaf type {
type iana-icmpv4-types:icmpv4-type;
description
"Also known as control messages.";
reference
"RFC 792: Internet Control Message Protocol.";
}
leaf code {
type uint8;
description
"ICMP subtype.";
reference
"RFC 792: Internet Control Message Protocol.";
}
leaf rest-of-header {
type binary;
description
"Unbounded in length, the contents vary based on the
ICMP type and code.";
reference
"RFC 792: Internet Control Message Protocol";
}
}
grouping icmpv6-header-fields {
description
"Collection of ICMPv6 header fields that can be
used to set up a match filter.";
leaf type {
type iana-icmpv6-types:icmpv6-type;
description
"Also known as control messages.";
reference
"RFC 4443: Internet Control Message Protocol (ICMPv6)
for Internet Protocol Version 6 (IPv6)
Specification.";
}
leaf code {
type uint8;
description
"ICMP code.";
reference
"RFC 4443: Internet Control Message Protocol (ICMPv6)
for Internet Protocol Version 6 (IPv6)
Specification.";
}
leaf rest-of-header {
type binary;
description
"Unbounded in length, the contents vary based on the
ICMP type and code. Also referred to as 'Message Body'
in ICMPv6.";
reference
"RFC 4443: Internet Control Message Protocol (ICMPv6)
for Internet Protocol Version 6 (IPv6)
Specification.";
}
}
grouping acl-complementary-actions {
description
"Collection of complementary ACL actions.";
container log-action {
description
"Container for defining log actions.";
leaf log-type {
type identityref {
base acl-enh:log-types;
}
description
"The type of log action to be performed.";
}
leaf log-id {
when "derived-from-or-self(../log-type, "
+ "'acl-enh:local-log')" {
description
"Name of the log file updated when type is 'local-log'.";
}
type string;
description
"The name of the counter action.";
}
}
container counter-action {
description
"Container for defining counter actions.";
leaf counter-type {
type identityref {
base acl-enh:counter-type;
}
description
"The type of counter action to be performed.";
}
leaf-list counter-name {
when "derived-from-or-self(../counter-type, "
+ "'acl-enh:counter-name')" {
description
"Name for the counter or variable to update when
'counter-type' is 'counter-name'.";
}
type string;
description
"List of possible variables or counter names to
update based on match criteria.";
}
}
}
grouping ipv4-prefix-sets {
description
"Data definitions for a list of IPv4 prefixes,
which are matched as part of a policy.";
list prefix-set {
key "name";
description
"List of the defined prefix sets.";
leaf name {
type string;
description
"Name of the prefix set -- this is used as a label to
reference the set in match conditions.";
}
leaf description {
type string;
description
"Defined set description.";
}
leaf-list prefix {
type inet:ipv4-prefix;
description
"List of IPv4 prefixes to be used in match
conditions.";
}
}
}
grouping ipv6-prefix-sets {
description
"Data definitions for a list of IPv6 prefixes, which are
matched as part of a policy.";
list prefix-set {
key "name";
description
"List of the defined prefix sets.";
leaf name {
type string;
description
"Name of the prefix set -- this is used as a label to
reference the set in match conditions.";
}
leaf description {
type string;
description
"A textual description of the prefix list.";
}
leaf-list prefix {
type inet:ipv6-prefix;
description
"List of IPv6 prefixes to be used in match conditions.";
}
}
}
grouping port-sets {
description
"Data definitions for a list of ports, which can
be matched in policies.";
list port-set {
key "name";
description
"List of port set definitions.";
leaf name {
type string;
description
"Name of the port set -- this is used as a label to
reference the set in match conditions.";
}
list port {
key "id";
description
"Port numbers along with the operator on which to
match.";
leaf id {
type string;
description
"Identifier of the list of port numbers.";
}
choice port {
description
"Choice of specifying the port number or referring to a
group of port numbers.";
container port-range-or-operator {
description
"Indicates a set of ports.";
uses packet-fields:port-range-or-operator;
}
}
}
}
}
grouping protocol-sets {
description
"Data definitions for a list of protocols, which can be
matched in policies.";
list protocol-set {
key "name";
description
"List of protocol set definitions.";
leaf name {
type string;
description
"Name of the protocols set -- this is used as a
label to reference the set in match conditions.";
}
leaf-list protocol {
type union {
type uint8;
type string;
}
description
"Value of the protocol set.";
}
}
}
grouping icmpv4-type-sets {
description
"Data definitions for a list of ICMPv4 types, which can be
matched in policies.";
list set {
key "name";
description
"List of ICMPv4 type set definitions.";
leaf name {
type string;
description
"Name of the ICMPv4 type set -- this is used as a label
to reference the set in match conditions.";
}
list icmpv4-type {
key "type";
description
"Includes a list of ICMPv4 types.";
uses icmpv4-header-fields;
}
}
}
grouping icmpv6-type-sets {
description
"Data definitions for a list of ICMPv6 types, which can be
matched in policies.";
list set {
key "name";
description
"List of ICMP type set definitions.";
leaf name {
type string;
description
"Name of the ICMPv6 type set -- this is used as a label
to reference the set in match conditions.";
}
list icmpv6-type {
key "type";
description
"Includes a list of ICMPv6 types.";
uses icmpv6-header-fields;
}
}
}
grouping aliases {
description
"Grouping for a set of aliases.";
list alias {
key "name";
description
"List of aliases.";
leaf name {
type string;
description
"The name of the alias.";
}
uses alias;
}
}
grouping defined-sets {
description
"Predefined sets of attributes used in policy match
statements.";
container ipv4-prefix-sets {
description
"Data definitions for a list of IPv4 or IPv6
prefixes, which are matched as part of a policy.";
uses ipv4-prefix-sets;
}
container ipv6-prefix-sets {
description
"Data definitions for a list of IPv6 prefixes, which are
matched as part of a policy.";
uses ipv6-prefix-sets;
}
container port-sets {
description
"Data definitions for a list of ports, which can
be matched in policies.";
uses port-sets;
}
container protocol-sets {
description
"Data definitions for a list of protocols, which can be
matched in policies.";
uses protocol-sets;
}
container icmpv4-type-sets {
description
"Data definitions for a list of ICMPv4 types, which can be
matched in policies.";
uses icmpv4-type-sets;
}
container icmpv6-type-sets {
description
"Data definitions for a list of ICMPv6 types, which can be
matched in policies.";
uses icmpv6-type-sets;
}
container aliases {
description
"Top-level container for aliases.";
uses aliases;
}
}
augment "/acl:acls" {
description
"predefined sets.";
container defined-sets {
description
"Predefined sets of attributes used in policy match
statements.";
uses defined-sets;
nacm:default-deny-write;
}
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace"
+ "/acl:matches" {
description
"Adds a match type based on the payload.";
choice payload {
description
"Matches based upon a prefix pattern.";
container pattern {
if-feature "match-on-payload";
description
"Indicates the rule to perform the payload-based match.";
uses payload-match;
}
}
choice alias {
description
"Matches based upon aliases.";
leaf-list alias-name {
type alias-ref;
description
"Indicates one or more aliases.";
}
}
choice mpls {
description
"Matches against MPLS headers, for example, label
values.";
container mpls-values {
if-feature "match-on-mpls";
description
"Provides the rule set that matches MPLS headers.";
uses mpls-match-parameters-config;
}
}
}
augment "/acl:acls/acl:acl/acl:aces"
+ "/acl:ace/acl:matches/acl:l2" {
description
"Adds a match type based on MAC VLAN and I-SID filters.";
container vlan-filter {
if-feature "match-on-vlan-filter";
description
"Indicates how to handle MAC VLANs.";
leaf frame-type {
type string;
description
"Entering the frame type allows the
filter to match a specific type of frame format.";
}
choice vlan-type {
description
"VLAN definition from range or operator.";
case range {
leaf lower-vlan {
type uint16;
must '. <= ../upper-vlan' {
error-message
"The lower-vlan must be less than or equal to
the upper-vlan.";
}
mandatory true;
description
"Lower boundary for a VLAN.";
}
leaf upper-vlan {
type uint16;
mandatory true;
description
"Upper boundary for a VLAN.";
}
}
case operator {
leaf operator {
type packet-fields:operator;
default "eq";
description
"Operator to be applied on the VLAN below.";
}
leaf-list vlan {
type uint16;
description
"VLAN number along with the operator on which to
match.";
reference
"IEEE Std 802.1Q: Bridges and Bridged Networks";
}
}
}
}
container isid-filter {
if-feature "match-on-isid-filter";
description
"Indicates how to handle I-SID filters. The
I-component is responsible for mapping customer
Ethernet traffic to the appropriate I-SID.";
choice isid-type {
description
"I-SID definition from range or operator.";
case range {
leaf lower-isid {
type uint16;
must '. <= ../upper-isid' {
error-message
"The lower-isid must be less than or equal to
the upper-isid.";
}
mandatory true;
description
"Lower boundary for an I-SID.";
}
leaf upper-isid {
type uint16;
mandatory true;
description
"Upper boundary for an I-SID.";
}
}
case operator {
leaf operator {
type packet-fields:operator;
default "eq";
description
"Operator to be applied on the I-SID below.";
}
leaf-list isid {
type uint16;
description
"I-SID number along with the operator on which to
match.";
reference
"IEEE 802.1ah: Provider Backbone Bridges";
}
}
}
}
}
augment "/acl:acls/acl:acl/acl:aces"
+ "/acl:ace/acl:matches/acl:l3/acl:ipv4/acl:ipv4" {
description
"Handle non-initial and initial fragments for IPv4 packets.";
container ipv4-fragment {
must 'not(../acl:flags)' {
error-message
"Either flags or fragment should be provided, but not
both.";
}
description
"Indicates how to handle IPv4 fragments.";
uses fragment-fields;
}
leaf source-ipv4-prefix-list {
type ipv4-prefix-set-ref;
description
"A reference to an IPv4 prefix list to match the source
address.";
}
leaf destination-ipv4-prefix-list {
type ipv4-prefix-set-ref;
description
"A reference to a prefix list to match the destination
address.";
}
leaf protocol-set {
type protocol-set-ref;
description
"A reference to a protocol set to match the protocol
field.";
}
}
augment "/acl:acls/acl:acl/acl:aces"
+ "/acl:ace/acl:matches/acl:l3/acl:ipv6/acl:ipv6" {
description
"Handles non-initial and initial fragments for IPv6 packets.";
container ipv6-fragment {
description
"Indicates how to handle IPv6 fragments.";
uses fragment-fields;
}
leaf source-ipv6-prefix-list {
type ipv6-prefix-set-ref;
description
"A reference to a prefix list to match the source address.";
}
leaf destination-ipv6-prefix-list {
type ipv6-prefix-set-ref;
description
"A reference to a prefix list to match the destination
address.";
}
leaf protocol-set {
type protocol-set-ref;
description
"A reference to a protocol set to match the next-header
field.";
}
leaf extension-header {
type iana-ipv6-ext-types:ipv6-extension-header-type;
description
"IPv6 extension header value.";
}
}
augment "/acl:acls/acl:acl/acl:aces"
+ "/acl:ace/acl:matches/acl:l4/acl:tcp/acl:tcp" {
description
"Handles TCP flags and port sets.";
container flags-bitmask {
must 'not(../acl:flags)' {
error-message
"Either flags or flags-bitmask should be provided, but not
both.";
}
description
"Indicates how to handle TCP flags.";
uses tcp-flags;
}
leaf source-tcp-port-set {
type port-set-ref;
description
"A reference to a port set to match the source port.";
}
leaf destination-tcp-port-set {
type port-set-ref;
description
"A reference to a port set to match the destination port.";
}
}
augment "/acl:acls/acl:acl/acl:aces"
+ "/acl:ace/acl:matches/acl:l4/acl:udp/acl:udp" {
description
"Handle UDP port sets.";
leaf source-udp-port-set {
type port-set-ref;
description
"A reference to a port set to match the source port.";
}
leaf destination-udp-port-set {
type port-set-ref;
description
"A reference to a port set to match the destination port.";
}
}
augment "/acl:acls/acl:acl/acl:aces"
+ "/acl:ace/acl:matches/acl:l4/acl:icmp/acl:icmp" {
description
"Handle ICMP type sets.";
leaf icmpv4-set {
type icmpv4-type-set-ref;
description
"A reference to an ICMPv4 type set to match the ICMPv4 type
field.";
}
leaf icmpv6-set {
type icmpv6-type-set-ref;
description
"A reference to an ICMPv6 type set to match the ICMPv6 type
field.";
}
}
augment "/acl:acls/acl:acl/acl:aces"
+ "/acl:ace/acl:actions" {
description
"Complementary actions including rate-limit action.";
uses acl-complementary-actions;
leaf rate-limit {
when "../acl:forwarding = 'acl:accept'" {
description
"Rate-limit valid only when the accept action is used.";
}
type decimal64 {
fraction-digits 2;
}
units "bytes per second";
description
"Indicates a rate-limit for the matched traffic.";
}
}
}
This section is modeled after the template described in Section 3.7.1 of [YANG-GUIDELINES].
このセクションは、[YANG-GUIDELINES] のセクション 3.7.1 で説明されているテンプレートをモデルにしています。
The "ietf-acl-enh" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication.
「ietf-acl-enh」YANG モジュールは、NETCONF [RFC6241] や RESTCONF [RFC8040] などの YANG ベースの管理プロトコル経由でアクセスできるように設計されたデータ モデルを定義します。これらの YANG ベースの管理プロトコルは、(1) 安全なトランスポート層 (SSH [RFC4252]、TLS [RFC8446]、QUIC [RFC9000] など) を使用する必要があり、(2) 相互認証を使用する必要があります。
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
Network Configuration Access Control Model (NACM) [RFC8341] は、特定の NETCONF または RESTCONF ユーザーのアクセスを、利用可能なすべての NETCONF または RESTCONF プロトコルの操作およびコンテンツの事前構成されたサブセットに制限する手段を提供します。
There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be reasonably sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities:
この YANG モジュールには、書き込み可能/作成可能/削除可能 (つまり、デフォルトの「config true」) のデータ ノードが多数定義されています。すべての書き込み可能なデータ ノードは、一部のネットワーク環境ではかなり機密性が高いか、脆弱である可能性があります。適切な保護や認証を行わずにこれらのデータ ノードへの書き込み操作 (edit-config など) や削除操作を行うと、ネットワーク操作に悪影響を及ぼす可能性があります。次のサブツリーとデータ ノードには、特定の感度/脆弱性があります。
'defined-sets':
'定義済みセット':
These lists specify a set of IP addresses, port numbers, protocols, ICMP types, and aliases. Similar to [RFC8519], unauthorized write access to these lists can allow intruders to modify the entries to permit traffic that should not be permitted or deny traffic that should be permitted. The former may result in a DoS attack or compromise a device. The latter may result in a DoS attack.
これらのリストは、IP アドレス、ポート番号、プロトコル、ICMP タイプ、およびエイリアスのセットを指定します。[RFC8519] と同様に、これらのリストへの不正な書き込みアクセスにより、侵入者がエントリを変更して、許可すべきでないトラフィックを許可したり、許可すべきトラフィックを拒否したりする可能性があります。前者の場合、DoS 攻撃が発生したり、デバイスが侵害されたりする可能性があります。後者は DoS 攻撃につながる可能性があります。
These sets are defined with "nacm:default-deny-write" tagging.
これらのセットは、「nacm:default-deny-write」タグで定義されます。
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 notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/ vulnerabilities:
この YANG モジュールの読み取り可能なデータ ノードの一部は、一部のネットワーク環境では機密であるか脆弱であると見なされる場合があります。したがって、これらのデータ ノードへの読み取りアクセス (get、get-config、通知など) を制御することが重要です。具体的には、次のサブツリーとデータ ノードには特定の感度/脆弱性があります。
'defined-sets':
'定義済みセット':
Unauthorized read access of these lists will allow an attacker to identify the actual resources that are bound 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 network instead 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.
これらのリストへの不正な読み取りアクセスにより、攻撃者は ACL にバインドされている実際のリソースを特定できるようになります。同様に、この情報にアクセスすると、攻撃者はランダム スキャンを実行するのではなく、特定のネットワークに固有のリソースをターゲットとする攻撃の範囲を絞りやすくなります。また、この情報の一部 (コア ルータの IP アドレスなど) を公開すると、一部のネットワークではトポロジ隠蔽戦略の効果が無効になる可能性があります。
There are no particularly sensitive RPC or action operations.
特に機密性の高い RPC 操作やアクション操作はありません。
The document defines a match policy based on a pattern that can be observed in a packet. For example, such a policy can be combined with header-based matches in the context of DDoS mitigation. Filtering based on a pattern match is deterministic for packets with unencrypted data. However, the efficiency for encrypted packets depends on the presence of an unvarying pattern. Readers may also refer to Section 11 of [RFC8329] for security considerations related to Network Security Functions (NSFs) that apply packet content matching.
この文書では、パケット内で観察できるパターンに基づいて一致ポリシーを定義します。たとえば、このようなポリシーは、DDoS 軽減のコンテキストでヘッダーベースの一致と組み合わせることができます。パターン一致に基づくフィルタリングは、暗号化されていないデータを含むパケットに対して決定的です。ただし、暗号化されたパケットの効率は、不変のパターンの存在に依存します。読者は、パケットコンテンツマッチングを適用するネットワークセキュリティ機能 (NSF) に関連するセキュリティ上の考慮事項について、[RFC8329] のセクション 11 を参照することもできます。
The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and "iana-ipv6-ext-types" define a set of types. 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. As such, there are no additional security issues related to these YANG modules that need to be considered.
YANG モジュール「iana-icmpv4-types」、「iana-icmpv6-types」、および「iana-ipv6-ext-types」は、タイプのセットを定義します。これらのノードは、他の YANG モジュールによって再利用されることを目的としています。各モジュール自体は、書き込み可能なデータ ノード、読み取り専用状態を含むデータ ノード、または RPC を公開しません。そのため、これらの YANG モジュールに関連して考慮する必要のある追加のセキュリティ問題はありません。
IANA has registered the following URIs in the "ns" registry within the "IETF XML Registry" [RFC3688]:
IANA は、「IETF XML レジストリ」[RFC3688] 内の「ns」レジストリに次の URI を登録しました。
URI:
URI:
urn:ietf:params:xml:ns:yang:ietf-acl-enh
urn:ietf:params:xml:ns:yang:ietf-acl-enh
Registrant Contact:
登録者の連絡先:
The IESG
IESG
XML:
XML:
N/A; the requested URI is an XML namespace.
該当なし。要求された URI は XML 名前空間です。
URI:
URI:
urn:ietf:params:xml:ns:yang:iana-icmpv4-types
urn:ietf:params:xml:ns:yang:iana-icmpv4-types
Registrant Contact:
登録者の連絡先:
The IESG
IESG
XML:
XML:
N/A; the requested URI is an XML namespace.
該当なし。要求された URI は XML 名前空間です。
URI:
URI:
urn:ietf:params:xml:ns:yang:iana-icmpv6-types
urn:ietf:params:xml:ns:yang:iana-icmpv6-types
Registrant Contact:
登録者の連絡先:
The IESG
IESG
XML:
XML:
N/A; the requested URI is an XML namespace.
該当なし。要求された URI は XML 名前空間です。
URI:
URI:
urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types
urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types
Registrant Contact:
登録者の連絡先:
The IESG
IESG
XML:
XML:
N/A; the requested URI is an XML namespace.
該当なし。要求された URI は XML 名前空間です。
IANA has registered the following YANG modules in the "YANG Module Names" registry [RFC6020] [RFC9890] within the "YANG Parameters" registry group.
IANA は、「YANG Parameters」レジストリ グループ内の「YANG Module Names」レジストリ [RFC6020] [RFC9890] に次の YANG モジュールを登録しました。
Name:
名前：
ietf-acl-enh
ietf-acl-enh
Maintained by IANA:
IANA によって保守されています:
N
N
Namespace:
名前空間:
urn:ietf:params:xml:ns:yang:ietf-acl-enh
urn:ietf:params:xml:ns:yang:ietf-acl-enh
Prefix:
プレフィックス:
acl-enh
acl-enh
Reference:
参照：
RFC 9899
RFC 9899
Name:
名前：
iana-icmpv4-types
iana-icmpv4-types
Maintained by IANA:
IANA によって保守されています:
Y
Y
Namespace:
名前空間:
urn:ietf:params:xml:ns:yang:iana-icmpv4-types
urn:ietf:params:xml:ns:yang:iana-icmpv4-types
Prefix:
プレフィックス:
iana-icmpv4-types
iana-icmpv4-types
Reference:
参照：
RFC 9899
RFC 9899
Name:
名前：
iana-icmpv6-types
iana-icmpv6-types
Maintained by IANA:
IANA によって保守されています:
Y
Y
Namespace:
名前空間:
urn:ietf:params:xml:ns:yang:iana-icmpv6-types
urn:ietf:params:xml:ns:yang:iana-icmpv6-types
Prefix:
プレフィックス:
iana-icmpv6-types
iana-icmpv6-types
Reference:
参照：
RFC 9899
RFC 9899
Name:
名前：
iana-ipv6-ext-types
iana-ipv6-ext-types
Maintained by IANA:
IANA によって保守されています:
Y
Y
Namespace:
名前空間:
urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types
urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types
Prefix:
プレフィックス:
iana-ipv6-ext-types
iana-ipv6-ext-types
Reference:
参照：
RFC 9899
RFC 9899
This document creates the initial version of the IANA-maintained "iana-icmpv4-types" YANG module. The most recent version of the YANG module is available in the "YANG Parameters" registry group [IANA-YANG-PARAMETERS].
この文書は、IANA が管理する「iana-icmpv4-types」YANG モジュールの初期バージョンを作成します。YANG モジュールの最新バージョンは、「YANG パラメータ」レジストリ グループ [IANA-YANG-PARAMETERS] で入手できます。
IANA has added this note to the registry:
IANA は次のメモをレジストリに追加しました。
New values must not be directly added to the "iana-icmpv4-types" YANG module. They must instead be added to the "ICMP Type Numbers" registry [IANA-ICMPv4].
新しい値を「iana-icmpv4-types」YANG モジュールに直接追加しないでください。代わりに、それらを「ICMP Type Numbers」レジストリ [IANA-ICMPv4] に追加する必要があります。
When a value is added to the "ICMP Type Numbers" registry, a new "enum" statement must be added to the "iana-icmpv4-types" YANG module. The "enum" statement, and substatements thereof, should be defined as follows:
「ICMP Type Numbers」レジストリに値を追加するときは、新しい「enum」ステートメントを「iana-icmpv4-types」YANG モジュールに追加する必要があります。「enum」ステートメントとそのサブステートメントは、次のように定義する必要があります。
"enum":
"列挙型":
Replicates the name from the registry with all illegal characters (e.g., spaces) stripped.
無効な文字 (スペースなど) をすべて削除して、レジストリから名前を複製します。
"value":
"価値"：
Contains the decimal value of the IANA-assigned value.
IANA によって割り当てられた値の 10 進数値が含まれます。
"status":
"状態"：
Included only if a registration has been deprecated or obsoleted. IANA "deprecated" maps to YANG status "deprecated", and IANA "obsolete" maps to YANG status "obsolete".
登録が非推奨または廃止された場合にのみ含まれます。IANA "deprecated" は YANG ステータス "deprecated" にマップされ、IANA "obsolete" は YANG ステータス "obsolete" にマップされます。
"description":
"説明"：
Replicates the name from the registry.
レジストリから名前を複製します。
"reference":
"参照"：
Replicates the reference(s) from the registry with the title of the document(s) added.
ドキュメントのタイトルを追加して、レジストリからの参照を複製します。
Unassigned, reserved, or values styled like those in [RFC3692] are not present in the module.
未割り当て、予約済み、または [RFC3692] のようなスタイルの値はモジュール内に存在しません。
When the "iana-icmpv4-types" YANG module is updated, a new "revision" statement with a unique revision date must be added in front of the existing revision statements.
「iana-icmpv4-types」YANG モジュールが更新されるときは、一意のリビジョン日付を持つ新しい「revision」ステートメントを既存のリビジョン ステートメントの前に追加する必要があります。
IANA has added this note to "ICMP Type Numbers" registry [IANA-ICMPv4] and listed this document as an additional reference for the registry:
IANA は、このメモを「ICMP Type Numbers」レジストリ [IANA-ICMPv4] に追加し、この文書をレジストリの追加参照としてリストしました。
When this registry is modified, the YANG module "iana-icmpv4-types" [IANA-YANG-PARAMETERS] must be updated as defined in RFC 9899.
このレジストリを変更する場合、YANG モジュール "iana-icmpv4-types" [IANA-YANG-PARAMETERS] を RFC 9899 の定義に従って更新する必要があります。
This document creates the initial version of the IANA-maintained "iana-icmpv6-types" YANG module. The most recent version of the YANG module is available in the "YANG Parameters" registry group [IANA-YANG-PARAMETERS].
この文書は、IANA が管理する「iana-icmpv6-types」YANG モジュールの初期バージョンを作成します。YANG モジュールの最新バージョンは、「YANG パラメータ」レジストリ グループ [IANA-YANG-PARAMETERS] で入手できます。
IANA has added this note to the registry:
IANA は次のメモをレジストリに追加しました。
New values must not be directly added to the "iana-icmpv6-types" YANG module. They must instead be added to the "ICMPv6 "type" Numbers" registry [IANA-ICMPv6].
新しい値を「iana-icmpv6-types」YANG モジュールに直接追加しないでください。代わりに、それらを「ICMPv6 "type" Numbers」レジストリ [IANA-ICMPv6] に追加する必要があります。
When a value is added to the "ICMPv6 "type" Numbers" registry, a new "enum" statement must be added to the "iana-icmpv6-types" YANG module. The "enum" statement, and substatements thereof, should be defined as follows:
「ICMPv6 "type" Numbers」レジストリに値を追加するときは、新しい「enum」ステートメントを「iana-icmpv6-types」YANG モジュールに追加する必要があります。「enum」ステートメントとそのサブステートメントは、次のように定義する必要があります。
"enum":
"列挙型":
Replicates the name from the registry with all illegal characters (e.g., spaces) stripped.
無効な文字 (スペースなど) をすべて削除して、レジストリから名前を複製します。
"value":
"価値"：
Contains the decimal value of the IANA-assigned value.
IANA によって割り当てられた値の 10 進数値が含まれます。
"status":
"状態"：
Included only if a registration has been deprecated or obsoleted. IANA "deprecated" maps to YANG status "deprecated", and IANA "obsolete" maps to YANG status "obsolete".
登録が非推奨または廃止された場合にのみ含まれます。IANA "deprecated" は YANG ステータス "deprecated" にマップされ、IANA "obsolete" は YANG ステータス "obsolete" にマップされます。
"description":
"説明"：
Replicates the name from the registry.
レジストリから名前を複製します。
"reference":
"参照"：
Replicates the reference(s) from the registry with the title of the document(s) added.
ドキュメントのタイトルを追加して、レジストリからの参照を複製します。
Unassigned, reserved, or private experimentation values are not present in the module.
未割り当て、予約済み、またはプライベート実験値はモジュールに存在しません。
When the "iana-icmpv6-types" YANG module is updated, a new "revision" statement with a unique revision date must be added in front of the existing revision statements.
「iana-icmpv6-types」YANG モジュールが更新されるときは、一意のリビジョン日付を持つ新しい「revision」ステートメントを既存のリビジョン ステートメントの前に追加する必要があります。
IANA has added this note to the "ICMPv6 "type" Numbers" registry [IANA-ICMPv6] and listed this document as an additional reference for the registry:
IANA は、このメモを「ICMPv6 "type" Numbers」レジストリ [IANA-ICMPv6] に追加し、この文書をレジストリの追加参照としてリストしました。
When this registry is modified, the YANG module "iana-icmpv6-types" [IANA-YANG-PARAMETERS] must be updated as defined in RFC 9899.
このレジストリを変更する場合、YANG モジュール "iana-icmpv6-types" [IANA-YANG-PARAMETERS] を RFC 9899 の定義に従って更新する必要があります。
This document creates the initial version of the IANA-maintained "iana-ipv6-ext-types" YANG module. The most recent version of the YANG module is available in the "YANG Parameters" registry group [IANA-YANG-PARAMETERS].
この文書は、IANA が管理する「iana-ipv6-ext-types」YANG モジュールの初期バージョンを作成します。YANG モジュールの最新バージョンは、「YANG パラメータ」レジストリ グループ [IANA-YANG-PARAMETERS] で入手できます。
IANA has added this note to the registry:
IANA は次のメモをレジストリに追加しました。
New values must not be directly added to the "iana-ipv6-ext-types" YANG module. They must instead be added to the "IPv6 Extension Header Types" registry [IANA-IPv6].
新しい値を「iana-ipv6-ext-types」YANG モジュールに直接追加しないでください。代わりに、それらを「IPv6 拡張ヘッダー タイプ」レジストリ [IANA-IPv6] に追加する必要があります。
When a value is added to the "IPv6 Extension Header Types" registry, a new "enum" statement must be added to the "iana-ipv6-ext-types" YANG module. The "enum" statement, and substatements thereof, should be defined as follows
「IPv6 拡張ヘッダー タイプ」レジストリに値を追加するときは、新しい「enum」ステートメントを「iana-ipv6-ext-types」YANG モジュールに追加する必要があります。「enum」ステートメントとそのサブステートメントは次のように定義する必要があります。
"enum":
"列挙型":
Replicates the description from the registry with all spaces stripped.
すべてのスペースを削除して、レジストリから説明を複製します。
"value":
"価値"：
Contains the decimal value of the IANA-assigned value.
IANA によって割り当てられた値の 10 進数値が含まれます。
"status":
"状態"：
Included only if a registration has been deprecated or obsoleted. IANA "deprecated" maps to YANG status "deprecated", and IANA "obsolete" maps to YANG status "obsolete".
登録が非推奨または廃止された場合にのみ含まれます。IANA "deprecated" は YANG ステータス "deprecated" にマップされ、IANA "obsolete" は YANG ステータス "obsolete" にマップされます。
"description":
"説明"：
Replicates the description from the registry.
レジストリから説明を複製します。
"reference":
"参照"：
Replicates the reference(s) from the registry with the title of the document(s) added.
ドキュメントのタイトルを追加して、レジストリからの参照を複製します。
Unassigned or reserved values are not present in the module.
未割り当てまたは予約された値はモジュール内に存在しません。
When the "iana-ipv6-ext-types" YANG module is updated, a new "revision" statement with a unique revision date must be added in front of the existing revision statements.
「iana-ipv6-ext-types」YANG モジュールが更新されるときは、一意のリビジョン日付を持つ新しい「revision」ステートメントを既存のリビジョン ステートメントの前に追加する必要があります。
IANA has added this note to the "IPv6 Extension Header Types" registry [IANA-IPv6] and listed this document as an additional reference for the registry:
IANA は、このメモを「IPv6 拡張ヘッダー タイプ」レジストリ [IANA-IPv6] に追加し、この文書をレジストリの追加参照としてリストしました。
When this registry is modified, the YANG module "iana-ipv6-ext-types" [IANA-YANG-PARAMETERS] must be updated as defined in RFC 9899.
このレジストリを変更する場合、YANG モジュール「iana-ipv6-ext-types」[IANA-YANG-PARAMETERS] を RFC 9899 の定義に従って更新する必要があります。
[IANA-ICMPv4]
IANA, "ICMP Type Numbers",
<https://www.iana.org/assignments/icmp-parameters>.
[IANA-ICMPv6]
IANA, "ICMPv6 "type" Numbers",
<https://www.iana.org/assignments/icmpv6-parameters>.
[IANA-IPv6]
IANA, "IPv6 Extension Header Types",
<https://www.iana.org/assignments/ipv6-parameters>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294,
DOI 10.17487/RFC8294, December 2017,
<https://www.rfc-editor.org/info/rfc8294>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
"YANG Data Model for Network Access Control Lists (ACLs)",
RFC 8519, DOI 10.17487/RFC8519, March 2019,
<https://www.rfc-editor.org/info/rfc8519>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[IANA-TCP-FLAGS]
IANA, "Transmission Control Protocol (TCP) Parameters",
<https://www.iana.org/assignments/tcp-parameters>.
[IANA-YANG-PARAMETERS]
IANA, "YANG Parameters",
<https://www.iana.org/assignments/yang-parameters>.
[IEEE-802-1ah]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Virtual Bridged Local Area Networks Amendment
7: Provider Backbone Bridges", IEEE Std 802.1ah-2008,
DOI 10.1109/IEEESTD.2008.4602826, August 2008,
<https://doi.org/10.1109/IEEESTD.2008.4602826>.
[IEEE802.1Qcp]
IEEE, "IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks--Amendment 30: YANG
Data Model", IEEE Std 802.1Qcp-2018,
DOI 10.1109/IEEESTD.2018.8467507, September 2018,
<https://doi.org/10.1109/IEEESTD.2018.8467507>.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692,
DOI 10.17487/RFC3692, January 2004,
<https://www.rfc-editor.org/info/rfc3692>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N.,
Henderickx, W., and A. Isaac, "Requirements for Ethernet
VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014,
<https://www.rfc-editor.org/info/rfc7209>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
<https://www.rfc-editor.org/info/rfc8329>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/info/rfc8955>.
[RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed.,
"Dissemination of Flow Specification Rules for IPv6",
RFC 8956, DOI 10.17487/RFC8956, December 2020,
<https://www.rfc-editor.org/info/rfc8956>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
"Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification", RFC 9132,
DOI 10.17487/RFC9132, September 2021,
<https://www.rfc-editor.org/info/rfc9132>.
[RFC9890] Bierman, A., Boucadair, M., Ed., and Q. Wu, "An Update to
YANG Module Names Registration", RFC 9890,
DOI 10.17487/RFC9890, October 2025,
<https://www.rfc-editor.org/info/rfc9890>.
[YANG-GUIDELINES]
Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
Authors and Reviewers of Documents Containing YANG Data
Models", Work in Progress, Internet-Draft, draft-ietf-
netmod-rfc8407bis-28, 5 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
rfc8407bis-28>.
[YANG-XSLT]
"iana-yang", commit 3a6cb69, December 2021,
<https://github.com/llhotka/iana-yang>.
IP prefix-related data nodes (e.g., "destination-ipv4-network" or "destination-ipv6-network") do not support handling a list of IP prefixes, which may then lead to having to support large numbers of ACL entries in a configuration file.
IP プレフィックス関連のデータ ノード (例: 「destination-ipv4-network」または「destination-ipv6-network」) は、IP プレフィックスのリストの処理をサポートしていないため、構成ファイル内で多数の ACL エントリをサポートする必要が生じる可能性があります。
The same issue is encountered when ACLs have to be in place to mitigate DDoS attacks that involve a set of sources (e.g., [RFC9132]). The situation is even worse when both a list of sources and destination prefixes are involved in the filtering.
一連のソース ([RFC9132] など) が関与する DDoS 攻撃を軽減するために ACL を導入する必要がある場合にも、同じ問題が発生します。送信元のリストと宛先プレフィックスの両方がフィルタリングに関与している場合、状況はさらに悪化します。
Figure 3 shows an example of the required ACL configuration for filtering traffic from two prefixes.
図 3 は、2 つのプレフィックスからのトラフィックをフィルタリングするために必要な ACL 設定の例を示しています。
{
"ietf-access-control-list:acls": {
"acl": [
{
"name": "first-prefix",
"type": "ipv6-acl-type",
"aces": {
"ace": [
{
"name": "my-test-ace",
"matches": {
"ipv6": {
"destination-ipv6-network":
"2001:db8:6401:1::/64",
"source-ipv6-network":
"2001:db8:1234::/96",
"protocol": 17,
"flow-label": 10000
},
"udp": {
"source-port": {
"operator": "lte",
"port": 80
},
"destination-port": {
"operator": "neq",
"port": 1010
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
},
{
"name": "second-prefix",
"type": "ipv6-acl-type",
"aces": {
"ace": [
{
"name": "my-test-ace",
"matches": {
"ipv6": {
"destination-ipv6-network":
"2001:db8:6401:c::/64",
"source-ipv6-network":
"2001:db8:1234::/96",
"protocol": 17,
"flow-label": 10000
},
"udp": {
"source-port": {
"operator": "lte",
"port": 80
},
"destination-port": {
"operator": "neq",
"port": 1010
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
}
Figure 3: Example Illustrating Suboptimal Use of the ACL Model with a Prefix List (Message Body)
図 3: プレフィックス リスト (メッセージ本文) を使用した ACL モデルの準最適な使用例を示す例
Such a configuration is suboptimal for both:
このような構成は、次の両方にとって最適ではありません。
* network controllers that need to manipulate large files, as all or a subset for this configuration will need to be passed to the underlying network devices, and
* この構成のすべてまたはサブセットを基盤となるネットワーク デバイスに渡す必要があるため、大きなファイルを操作する必要があるネットワーク コントローラー。
* devices that may receive such a configuration and thus will need to maintain it locally.
* デバイスはそのような構成を受け取る可能性があるため、それをローカルに維持する必要があります。
The same approach as the one discussed for IP prefixes can be generalized by introducing the concept of "aliases" or "defined sets".
IP プレフィックスについて説明したアプローチと同じアプローチは、「エイリアス」または「定義済みセット」の概念を導入することで一般化できます。
The defined sets are reusable definitions across several ACLs. Each category is modeled in YANG as a list of parameters related to the class it represents. The following sets can be considered:
定義されたセットは、複数の ACL にわたって再利用可能な定義です。YANG では、各カテゴリが、それが表すクラスに関連するパラメータのリストとしてモデル化されます。次のセットが考えられます。
Prefix sets:
プレフィックス セット:
Used to create lists of IPv4 or IPv6 prefixes.
IPv4 または IPv6 プレフィックスのリストを作成するために使用されます。
Protocol sets:
プロトコルセット:
Used to create a list of protocols.
プロトコルのリストを作成するために使用されます。
Port number sets:
ポート番号セット:
Used to create lists of TCP or UDP port values (or any other transport protocol that makes uses of port numbers). The identity of the protocols is identified by the protocol set, if present. Otherwise, a set applies to any protocol.
TCP または UDP ポート値 (またはポート番号を使用するその他のトランスポート プロトコル) のリストを作成するために使用されます。プロトコルの ID は、プロトコル セット (存在する場合) によって識別されます。それ以外の場合、セットは任意のプロトコルに適用されます。
ICMP sets:
ICMP セット:
Used to create lists of ICMP-based filters. This applies only when the protocol is set to ICMP or ICMPv6.
ICMP ベースのフィルターのリストを作成するために使用されます。これは、プロトコルが ICMP または ICMPv6 に設定されている場合にのみ適用されます。
Aliases may also be considered to manage resources that are identified by a combination of various parameters (e.g., prefix, protocol, port number, FQDN, or VLAN IDs). Note that some aliases can be provided by decomposing them into separate sets.
エイリアスは、さまざまなパラメータ (プレフィックス、プロトコル、ポート番号、FQDN、または VLAN ID など) の組み合わせによって識別されるリソースを管理するためにも考慮される場合があります。一部のエイリアスは、別個のセットに分解することで提供できることに注意してください。
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 ACL to multiple devices, not only (abstract) interfaces.
ネットワーク管理のコンテキストでは、多くのネットワークの場所で ACL が適用される場合があります。したがって、ACL モジュールは、(抽象) インターフェイスだけでなく、複数のデバイスに ACL をバインドできるようにする必要があります。
Thus, the ACL name must be unique at the scale of the network, but the same name may be used in many devices when enforcing node-specific ACLs.
したがって、ACL 名はネットワークの規模では一意である必要がありますが、ノード固有の ACL を強制する場合、多くのデバイスで同じ名前が使用される可能性があります。
[RFC8519] does not support fragment handling for IPv6 but 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 to be defined. For example, setting other bits not covered by the 'flags' filtering clause in a packet will allow that packet to get through (because it won't match the ACE).
[RFC8519] は IPv6 のフラグメント処理をサポートしていませんが、「フラグ」の使用を通じて IPv4 の部分的なサポートを提供しています。それにもかかわらず、ビットマスクを定義できないため、「フラグ」の使用には問題があります。たとえば、パケット内の「flags」フィルタリング句でカバーされていない他のビットを設定すると、そのパケットの通過が許可されます（ACE と一致しないため）。
Defining a new IPv4/IPv6 matching field called 'fragment' is thus required to efficiently handle fragment-related filtering rules.
したがって、フラグメント関連のフィルタリング ルールを効率的に処理するには、「フラグメント」と呼ばれる新しい IPv4/IPv6 一致フィールドを定義する必要があります。
[RFC8519] supports including flags in the TCP match fields; however, that structure does not support matching operations as those supported in BGP Flow Spec. Defining this field as a flag bitmask together with a set of operations is meant to efficiently handle TCP flags filtering rules.
[RFC8519] は、TCP 一致フィールドにフラグを含めることをサポートしています。ただし、その構造は、BGP フロー仕様でサポートされているようなマッチング操作をサポートしていません。このフィールドを一連の操作とともにフラグ ビットマスクとして定義することは、TCP フラグ フィルタリング ルールを効率的に処理することを目的としています。
[RFC8519] specifies that forwarding actions can be 'accept' (i.e., accept matching traffic), 'drop' (i.e., drop matching traffic without sending any ICMP error message), or 'reject' (i.e., drop matching traffic and send an ICMP 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 supported by [RFC8519].
[RFC8519] は、転送アクションが 'accept' (つまり、一致するトラフィックを受け入れる)、'drop' (つまり、ICMP エラー メッセージを送信せずに一致するトラフィックをドロップする)、または 'reject' (つまり、一致するトラフィックをドロップして送信元に ICMP エラー メッセージを送信する) にできることを指定しています。ただし、レート制限ポリシーが適用されている場合でも、一致するトラフィックが受け入れられる場合があります。この機能は [RFC8519] ではサポートされていません。
Some transport protocols use existing protocols (e.g., TCP or UDP) as substrate. The match criteria for such protocols may rely upon the 'protocol' under 'l3', TCP/UDP match criteria, part of the TCP/UDP payload, or a combination thereof. [RFC8519] does not support matching based on the payload.
一部のトランスポート プロトコルは、既存のプロトコル (TCP や UDP など) を基質として使用します。このようなプロトコルの一致基準は、「l3」の下の「プロトコル」、TCP/UDP 一致基準、TCP/UDP ペイロードの一部、またはそれらの組み合わせに依存する場合があります。[RFC8519] はペイロードに基づくマッチングをサポートしていません。
Likewise, the ACL model defined in [RFC8519] does not support filtering of encapsulated traffic.
同様に、[RFC8519] で定義されている ACL モデルは、カプセル化されたトラフィックのフィルタリングをサポートしていません。
Having a global network view of the ACLs is highly valuable for service providers. An ACL could be defined and applied based on the network topology hierarchy. Therefore, an ACL can be defined at the network level, and then that same ACL can be used in (or referenced to) several devices (including termination points) within the same network.
ACL のグローバル ネットワーク ビューを持つことは、サービス プロバイダーにとって非常に価値があります。ACL は、ネットワーク トポロジ階層に基づいて定義および適用できます。したがって、ACL をネットワーク レベルで定義すると、その同じ ACL を同じネットワーク内の複数のデバイス (終端ポイントを含む) で使用 (または参照) できます。
This network/device differentiation of ACLs introduces several new requirements, for example:
この ACL のネットワーク/デバイスの区別により、次のようないくつかの新しい要件が導入されます。
* An ACL name can be used at both network and device levels.
* ACL 名は、ネットワーク レベルとデバイス レベルの両方で使用できます。
* An ACL content updated at the network level should imply a transaction that updates the relevant content in all the nodes using this ACL.
* ネットワーク レベルで更新された ACL コンテンツは、この ACL を使用してすべてのノード内の関連コンテンツを更新するトランザクションを意味する必要があります。
* ACLs defined at the device level have a local meaning for the specific node.
* デバイス レベルで定義された ACL は、特定のノードに対してローカルな意味を持ちます。
* A device can be associated with a router, a Virtual Routing and Forwarding (VRF), a logical system, or a virtual node. ACLs can be applied in physical and logical infrastructure.
* デバイスは、ルーター、仮想ルーティングおよび転送（VRF）、論理システム、または仮想ノードに関連付けることができます。ACL は、物理インフラストラクチャと論理インフラストラクチャに適用できます。
The ACLs can be used to create rules to match MPLS fields on a packet. [RFC8519] does not support such function.
ACL を使用して、パケットの MPLS フィールドと一致するルールを作成できます。[RFC8519] はそのような機能をサポートしていません。
This section provides a few examples to illustrate the use of the enhanced ACL module ("ietf-acl-enh").
このセクションでは、拡張 ACL モジュール (「ietf-acl-enh」) の使用法を説明するために、いくつかの例を示します。
Figure 4 shows an example of the message body of a request to install a filter to discard incoming TCP messages having all flags unset.
図 4 は、すべてのフラグが設定されていない受信 TCP メッセージを破棄するためのフィルターをインストールする要求のメッセージ本文の例を示しています。
{
"ietf-access-control-list:acls": {
"acl": [
{
"name": "tcp-flags-example",
"aces": {
"ace": [
{
"name": "null-attack",
"matches": {
"tcp": {
"ietf-acl-enh:flags-bitmask": {
"operator": "not any",
"bitmask": 4095
}
}
},
"actions": {
"forwarding": "drop"
}
}
]
}
}
]
}
}
Figure 4: Example of an ACL to Deny TCP Null Attack Messages (Request Body)
図 4: TCP Null 攻撃メッセージを拒否する ACL の例 (リクエスト本文)
Figure 5 shows the content of a POST request to allow the traffic destined to 198.51.100.0/24 and UDP port number 53, but to drop all fragmented packets. The following ACEs are defined (in this order):
図 5 は、198.51.100.0/24 および UDP ポート番号 53 を宛先とするトラフィックを許可し、フラグメント化されたパケットをすべてドロップする POST リクエストの内容を示しています。次の ACE が (この順序で) 定義されます。
"drop-all-fragments" ACE:
「ドロップオールフラグメント」ACE:
discards all fragments.
すべてのフラグメントを破棄します。
"allow-dns-packets" ACE:
「allow-dns-packets」ACE:
accepts DNS packets destined to 198.51.100.0/24.
198.51.100.0/24 宛ての DNS パケットを受け入れます。
{
"ietf-access-control-list:acls": {
"acl": [
{
"name": "dns-fragments",
"type": "ipv4-acl-type",
"aces": {
"ace": [
{
"name": "drop-all-fragments",
"matches": {
"ipv4": {
"ietf-acl-enh:ipv4-fragment": {
"operator": "match",
"type": "isf"
}
}
},
"actions": {
"forwarding": "drop"
}
},
{
"name": "allow-dns-packets",
"matches": {
"ipv4": {
"destination-ipv4-network": "198.51.100.0/24"
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
}
Figure 5: Example Illustrating Candidate Filtering of IPv4 Fragmented Packets (Message Body)
図 5: IPv4 断片化パケットの候補フィルタリングを示す例 (メッセージ本文)
Figure 6 shows an example of the body of a POST request 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):
図 6 は、2001:db8::/32 および UDP ポート番号 53 宛てのトラフィックを許可し、フラグメント化されたパケットをすべてドロップする POST リクエストの本文の例を示しています。次の ACE が (この順序で) 定義されます。
"drop-all-fragments" ACE:
「ドロップオールフラグメント」ACE:
discards all fragments (including atomic fragments). That is, IPv6 packets that include a Fragment header (44) are dropped.
すべてのフラグメント (アトミックフラグメントを含む) を破棄します。つまり、Fragment ヘッダー (44) を含む IPv6 パケットはドロップされます。
"allow-dns-packets" ACE:
「allow-dns-packets」ACE:
accepts DNS packets destined to 2001:db8::/32.
2001:db8::/32 宛ての DNS パケットを受け入れます。
{
"ietf-access-control-list:acls": {
"acl": [
{
"name": "dns-fragments",
"type": "ipv6-acl-type",
"aces": {
"ace": [
{
"name": "drop-all-fragments",
"matches": {
"ipv6": {
"ietf-acl-enh:ipv6-fragment": {
"operator": "match",
"type": "isf"
}
}
},
"actions": {
"forwarding": "drop"
}
},
{
"name": "allow-dns-packets",
"matches": {
"ipv6": {
"destination-ipv6-network": "2001:db8::/32"
},
"udp": {
"destination-port": {
"operator": "eq",
"port": 53
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
}
Figure 6: An Example Illustrating Filtering of IPv6 Fragmented Packets (Message Body)
図 6: IPv6 断片化パケット (メッセージ本文) のフィルタリングを示す例
Pattern-based filtering is useful to detect specific patterns, signatures, or encapsulated packets. Figure 7 shows an example of the 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 the offset at the end of Layer 3, the rule targets a specific portion of the payload that starts 20 bytes after the beginning of the data (that is, skipping the first 20 bytes of the inner IPv6 header).
パターンベースのフィルタリングは、特定のパターン、シグネチャ、またはカプセル化されたパケットを検出するのに役立ちます。図 7 は、内部宛先 IP アドレスが「2001:db8::1」である IP-in-IP カプセル化メッセージを破棄するフィルタをインストールする要求のメッセージ本文の例を示しています。このルールは、レイヤー 3 の末尾のオフセットを使用することにより、データの先頭から 20 バイト後に始まるペイロードの特定の部分をターゲットにします (つまり、内部 IPv6 ヘッダーの最初の 20 バイトをスキップします)。
For the reader's convenience, the textual representation of the pattern is used in the example instead of the binary form.
読者の便宜のため、例ではバイナリ形式ではなくパターンのテキスト表現が使用されています。
{
"ietf-access-control-list:acls": {
"acl": [
{
"name": "pattern-example",
"aces": {
"ace": [
{
"name": "pattern-1",
"matches": {
"ipv6": {
"protocol": 41
},
"ietf-acl-enh:pattern": {
"offset": "ietf-acl-enh:layer4",
"length": 20,
"operator": "match",
"pattern": "2001:db8::1"
}
},
"actions": {
"forwarding": "drop"
}
}
]
}
}
]
}
}
Figure 7: Example of an ACL to Deny Encapsulated Messages with a Specific Inner Destination Address (Request Body)
図 7: 特定の内部宛先アドレス (リクエスト本文) を持つカプセル化されたメッセージを拒否する ACL の例
Figure 8 shows an ACL example to illustrate how to apply a VLAN range filter.
図 8 は、VLAN 範囲フィルタを適用する方法を示す ACL の例を示しています。
{
"ietf-access-control-list:acls": {
"acl": [
{
"name": "VLAN_FILTER",
"aces": {
"ace": [
{
"name": "1",
"matches": {
"ietf-acl-enh:vlan-filter": {
"lower-vlan": 10,
"upper-vlan": 20
}
},
"actions": {
"forwarding": "ietf-access-control-list:accept"
}
}
]
}
}
]
}
}
Figure 8: Example of VLAN Filter (Message Body)
図 8: VLAN フィルターの例 (メッセージ本文)
Figure 9 shows an ACL example to illustrate the I-SID range filtering.
図 9 は、I-SID 範囲フィルタリングを説明するための ACL の例を示しています。
{
"ietf-access-control-list:acls": {
"acl": [
{
"name": "test",
"aces": {
"ace": [
{
"name": "1",
"matches": {
"ietf-acl-enh:isid-filter": {
"lower-isid": 100,
"upper-isid": 200
}
},
"actions": {
"forwarding": "ietf-access-control-list:accept"
}
}
]
}
}
]
}
}
Figure 9: Example I-SID Filter (Message Body)
図 9: I-SID フィルターの例 (メッセージ本文)
Figure 10 shows an ACL example to rate-limit incoming SYNs during a SYN flood attack.
図 10 は、SYN フラッド攻撃中に受信 SYN をレート制限する ACL の例を示しています。
{
"ietf-access-control-list:acls": {
"acl": [
{
"name": "tcp-flags-example-with-rate-limit",
"aces": {
"ace": [
{
"name": "rate-limit-syn",
"matches": {
"tcp": {
"ietf-acl-enh:flags-bitmask": {
"operator": "match",
"bitmask": 2
}
}
},
"actions": {
"forwarding": "accept",
"ietf-acl-enh:rate-limit": "20.00"
}
}
]
}
}
]
}
}
Figure 10: An Example of Rate-Limiting Incoming TCP SYNs (Message Body)
図 10: レート制限された受信 TCP SYN の例 (メッセージ本文)
Many thanks to Jon Shallow and Miguel Cros for their review and comments on this document.
この文書に関するレビューとコメントをくださった Jon Shallow 氏と Miguel Cros 氏に心より感謝いたします。
Thanks to Qiufang Ma, Victor Lopez, Joe Clarke, and Mahesh Jethanandani for their comments and suggestions.
コメントと提案をくださった Qiufang Ma、Victor Lopez、Joe Clarke、Mahesh Jethanandani に感謝します。
Thanks to Lou Berger for shepherding this document.
この文書を導いてくださった Lou Berger に感謝します。
Thanks to David Black for the tsvart review, Tim Wicinski for the intdir review, Per Andersson for the yangdoctors review, Russ Housley for the genart review, and Linda Dunbar and Sean Turner for the secdir reviews.
tsvart レビューの David Black、intdir レビューの Tim Wicinski、yangdoctors レビューの Per Andersson、genart レビューの Russ Housley、secdir レビューの Linda Dunbar と Sean Turner に感謝します。
Thanks to Erik Kline, Mike Bishop, Éric Vyncke, Roman Danyliw, and Deb Cooley for the IESG review.
IESG のレビューに協力してくれた Erik Kline、Mike Bishop、Éric Vyncke、Roman Danyliw、Deb Cooley に感謝します。
The IANA-maintained modules were generated using an XSLT stylesheet from the 'iana-yang' project [YANG-XSLT].
IANA が管理するモジュールは、「iana-yang」プロジェクト [YANG-XSLT] の XSLT スタイルシートを使用して生成されました。
This work is partially supported by the European Commission under Horizon 2020 Secured autonomic traffic management for a Tera of SDN flows (Teraflow) project (grant agreement number 101015857).
この研究は、Horizon 2020 Secured Autonomic Traffic Management for a Tera of SDN flows (Teraflow) プロジェクト (助成契約番号 101015857) に基づいて欧州委員会によって部分的に支援されています。
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
Samier Barguil
Nokia
Email: samier.barguil_giraldo@nokia.com
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Qin Wu
Huawei
Email: bill.wu@huawei.com