[要約] RFC 8955は、フロー仕様ルールの配布に関する技術的な標準を定めています。この文書の目的は、ネットワーク上でのデータフローを効率的に管理し、セキュリティを強化するためのルールを設定することです。利用場面としては、DDoS攻撃の緩和、トラフィックエンジニアリング、およびポリシーベースのルーティングがあります。
Internet Engineering Task Force (IETF) C. Loibl
Request for Comments: 8955 next layer Telekom GmbH
Obsoletes: 5575, 7674 S. Hares
Category: Standards Track Huawei
ISSN: 2070-1721 R. Raszuk
NTT Network Innovations
D. McPherson
Verisign
M. Bacher
T-Mobile Austria
December 2020
Dissemination of Flow Specification Rules
フロー仕様規則の普及
Abstract
概要
This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
このドキュメントは、IPv4ユニキャストおよびIPv4 BGP / MPLS VPNサービスの配信（ドメイン内およびドメイン間）トラフィックフローの仕様を配布するために使用できる境界ゲートウェイプロトコルネットワーク層到達可能性情報（BGP NLRI）エンコードフォーマットを定義しています。これにより、ルーティングシステムは、IP宛先プレフィックスによって定義されたトラフィック集計のより具体的なコンポーネントに関する情報を伝播させることができます。
It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.
また、BGP拡張コミュニティエンコーディングフォーマットを指定します。これは、フロー仕様NLRIと共にトラフィックフィルタリングアクションを伝播するために使用できます。これらのトラフィックフィルタリングアクションは、パケットがフロー仕様と一致した場合にルーティングシステムが実行できるアクションをエンコードします。
This document obsoletes both RFC 5575 and RFC 7674.
この文書はRFC 5575とRFC 7674の両方を廃止します。
Status of This Memo
本文書の位置付け
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.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8955.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8955で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Definitions of Terms Used in This Memo
3. Flow Specifications
4. Dissemination of IPv4 Flow Specification Information
4.1. Length Encoding
4.2. NLRI Value Encoding
4.2.1. Operators
4.2.2. Components
4.2.2.1. Type 1 - Destination Prefix
4.2.2.2. Type 2 - Source Prefix
4.2.2.3. Type 3 - IP Protocol
4.2.2.4. Type 4 - Port
4.2.2.5. Type 5 - Destination Port
4.2.2.6. Type 6 - Source Port
4.2.2.7. Type 7 - ICMP Type
4.2.2.8. Type 8 - ICMP Code
4.2.2.9. Type 9 - TCP Flags
4.2.2.10. Type 10 - Packet Length
4.2.2.11. Type 11 - DSCP (Diffserv Code Point)
4.2.2.12. Type 12 - Fragment
4.3. Examples of Encodings
5. Traffic Filtering
5.1. Ordering of Flow Specifications
6. Validation Procedure
7. Traffic Filtering Actions
7.1. Traffic Rate in Bytes (traffic-rate-bytes) Sub-Type 0x06
7.2. Traffic Rate in Packets (traffic-rate-packets) Sub-Type
0x0c
7.3. Traffic-Action (traffic-action) Sub-Type 0x07
7.4. RT Redirect (rt-redirect) Sub-Type 0x08
7.5. Traffic Marking (traffic-marking) Sub-Type 0x09
7.6. Interaction with Other Filtering Mechanisms in Routers
7.7. Considerations on Traffic Filtering Action Interference
8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks
9. Traffic Monitoring
10. Error Handling
11. IANA Considerations
11.1. AFI/SAFI Definitions
11.2. Flow Component Definitions
11.3. Extended Community Flow Specification Actions
12. Security Considerations
13. References
13.1. Normative References
13.2. Informative References
Appendix A. Example Python code: flow_rule_cmp
Appendix B. Comparison with RFC 5575
Acknowledgments
Contributors
Authors' Addresses
This document obsoletes "Dissemination of Flow Specification Rules" [RFC5575] (see Appendix B for the differences). This document also obsoletes "Clarification of the Flowspec Redirect Extended Community" [RFC7674], since it incorporates the encoding of the BGP Flow Specification Redirect Extended Community in Section 7.4.
この文書では、「フロー仕様規則の普及」[RFC5575]が廃止されています（違いについては付録Bを参照）。この文書では、セクション7.4でBGPフロー仕様リダイレクト拡張コミュニティのエンコーディングを組み込んでいるため、「フローペックリダイレクト拡張コミュニティの説明」[RFC7674]。
Modern IP routers have the capability to forward traffic and to classify, shape, rate limit, filter, or redirect packets based on administratively defined policies. These traffic policy mechanisms allow the operator to define match rules that operate on multiple fields of the packet header. Actions, such as the ones described above, can be associated with each rule.
最新のIPルータには、トラフィックを転送し、管理上の定義されたポリシーに基づいて、トラフィックを転送する機能があります。これらのトラフィックポリシーメカニズムにより、オペレータはパケットヘッダーの複数のフィールドで動作する一致ルールを定義できます。上記のものなどのアクションを各ルールに関連付けることができます。
The n-tuple consisting of the matching criteria defines an aggregate traffic Flow Specification. The matching criteria can include elements such as source and destination address prefixes, IP protocol, and transport protocol port numbers.
マッチング基準からなるNタプルは、集約トラフィックフロー仕様を定義します。マッチング基準は、送信元および宛先アドレスのプレフィックス、IPプロトコル、およびトランスポートプロトコルポート番号などの要素を含み得る。
Section 4 of this document defines a general procedure to encode Flow Specifications for aggregated traffic flows so that they can be distributed as a BGP [RFC4271] NLRI. Additionally, Section 7 of this document defines the required Traffic Filtering Actions BGP Extended Communities and mechanisms to use BGP for intra- and inter-provider distribution of traffic filtering rules in order to mitigate DoS and DDoS attacks.
このドキュメントのセクション4は、集約トラフィックフローのフロー仕様をエンコードするための一般的な手順を定義して、BGP [RFC4271] NLRIとして配布できるようにします。さらに、このドキュメントのセクション7は、DOSおよびDDOS攻撃を軽減するために、トラフィックフィルタリングルールのイントラおよびプロバイダ間の分布に対してBGPを使用するために必要なトラフィックフィルタリングアクションとメカニズムを定義します。
By expanding routing information with Flow Specifications, the routing system can take advantage of the ACL (Access Control List) or firewall capabilities in the router's forwarding path. Flow Specifications can be seen as more specific routing entries to a unicast prefix and are expected to depend upon the existing unicast data information.
ルーティング情報をフロー仕様で展開することによって、ルーティングシステムはルータの転送パス内のACL（アクセス制御リスト）またはファイアウォール機能を利用することができます。フロー仕様は、ユニキャストプレフィックスへのより具体的なルーティングエントリとして見ることができ、既存のユニキャストデータ情報に依存すると予想されます。
A Flow Specification received from an external autonomous system will need to be validated against unicast routing before being accepted (Section 6). The Flow Specification received from an internal BGP peer within the same autonomous system [RFC4271] is assumed to have been validated prior to transmission within the internal BGP (iBGP) mesh of an autonomous system. If the aggregate traffic flow defined by the unicast destination prefix is forwarded to a given BGP peer, then the local system can install more specific Flow Specifications that may result in different forwarding behavior, as requested by this system.
外部自律システムから受信したフロー仕様は、受け入れられる前にユニキャストルーティングに対して検証する必要があります（セクション6）。同じ自律システム内の内部BGPピアから受信されたフロー仕様[RFC4271]は、自律システムの内部BGP（IBGP）メッシュ内で送信前に検証されていると仮定されます。ユニキャスト先プレフィックスによって定義された集約トラフィックフローが特定のBGPピアに転送された場合、ローカルシステムはこのシステムによって要求されたように、転送動作が異なる可能性があるより具体的なフロー仕様をインストールできます。
From an operational perspective, the utilization of BGP as the carrier for this information allows a network service provider to reuse both internal route distribution infrastructure (e.g., route reflector or confederation design) and existing external relationships (e.g., inter-domain BGP sessions to a customer network).
運用上の観点から、この情報のためのキャリアとしてのBGPの利用は、ネットワークサービスプロバイダが内部経路分布インフラストラクチャ（例えば、ルートリフレクタまたはコンフェデレーション設計）および既存の外部関係の両方を再利用することを可能にする（例えば、ドメイン間BGPセッションなど）。カスタマーネットワーク）。
While it is certainly possible to address this problem using other mechanisms, this solution has been utilized in deployments because of the substantial advantage of being an incremental addition to already deployed mechanisms.
他のメカニズムを使用してこの問題に対処することは確かに可能であるが、すでに展開されたメカニズムへの増分追加であるという実質的な利点のために、この解決策は展開において利用されてきた。
Possible applications of that extension are: Automated inter-domain coordination of traffic filtering, such as what is required in order to mitigate DoS and DDoS attacks or traffic filtering in the context of a BGP/MPLS VPN service. Other applications (e.g., centralized control of traffic in a Software-Defined Networking (SDN) or Network Function Virtualization (NFV) context) are also possible.
その拡張の可能なアプリケーションは、BGP / MPLS VPNサービスのコンテキストでDOSおよびDDOS攻撃やトラフィックフィルタリングを軽減するために必要なものなど、トラフィックフィルタリングの自動ドメイン間調整を行います。他のアプリケーション（例えば、ソフトウェア定義ネットワーク（SDN）またはネットワーク機能仮想化（NFV）コンテキスト内のトラフィックの集中制御）も可能である。
In current deployments, the information distributed by this extension is originated both manually as well as automatically, the latter by systems that are able to detect malicious traffic flows. When automated systems are used, care should be taken to ensure the correctness of the automated system. The limitations of the receiving systems that need to process these automated Flow Specifications need to be taken in consideration as well (see also Section 12).
現在の展開では、この拡張によって配布された情報は、悪意のあるトラフィックフローを検出することができるシステムによって、自動的に自動的にも、後者の両方に発信されます。自動システムが使用されるとき、自動化されたシステムの正確さを確実にするために注意する必要があります。これらの自動化されたフロー仕様を処理するために必要な受信システムの制限も考慮に入れる必要があります（セクション12も参照）。
This specification defines required protocol extensions to address most common applications of IPv4 unicast and VPNv4 unicast filtering. The same mechanism can be reused and new match criteria added to address similar filtering needs for other BGP address families, such as IPv6 families [RFC8956].
この仕様は、IPv4ユニキャストおよびVPNV4ユニキャストフィルタリングの最も一般的なアプリケーションに対処するために必要なプロトコル拡張機能を定義しています。IPv6ファミリー[RFC8956]など、他のBGPアドレスファミリのための類似のフィルタリングのニーズに対処するために、同じメカニズムを再利用することができ、新しい一致基準を追加することができます。
AFI: Address Family Identifier
AFI：アドレスファミリID
AS: Autonomous System
A：自律システム
Loc-RIB: The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process [RFC4271].
LOC-RIB：LOC-RIBには、ローカルBGPスピーカーの決定プロセス[RFC4271]によって選択されたルートが含まれています。
NLRI: Network Layer Reachability Information
NLRI：ネットワーク層到達可能性情報
PE: Provider Edge router
PE：プロバイダエッジルータ
RIB: Routing Information Base
RIB：ルーティング情報ベース
SAFI: Subsequent Address Family Identifier
SAFI：その後のアドレスファミリID
VRF: Virtual Routing and Forwarding
VRF：仮想ルーティングと転送
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
A Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. A given IP packet is said to match the defined Flow Specification if it matches all the specified criteria. This n-tuple is encoded into a BGP NLRI defined below.
フロー仕様は、IPトラフィックに適用できる複数のマッチング基準からなるNタプルです。特定のIPパケットは、指定されたすべての基準に一致する場合は、定義されたフロー仕様と一致すると言われています。このn-タプルは、以下に定義されたBGP NLRIにエンコードされています。
A given Flow Specification may be associated with a set of attributes, depending on the particular application; such attributes may or may not include reachability information (i.e., NEXT_HOP). Well-known or AS-specific community attributes can be used to encode a set of predetermined actions.
特定のアプリケーションに応じて、特定のフロー仕様は一組の属性に関連付けられてもよい。そのような属性は、到達可能性情報（すなわち、Next_hop）を含んでも含まなくてもよい。よく知られているか、特有のコミュニティ属性を使用して、一連の所定のアクションをエンコードできます。
A particular application is identified by a specific (Address Family Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs should be treated independently from each other in order to assure noninterference between distinct applications.
特定のアプリケーションは、特定の（アドレスファミリ識別子、後続のアドレスファミリ識別子（AFI、SAFI））ペア[RFC4760]によって識別され、リブの異なるセットに対応しています。これらのリブは、異なるアプリケーション間の非干渉を保証するために、互いに独立して扱われるべきである。
BGP itself treats the NLRI as a key to an entry in its databases. Entries that are placed in the Loc-RIB are then associated with a given set of semantics, which is application dependent. This is consistent with existing BGP applications. For instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast reverse-path information (AFI=1, SAFI=2) are handled by BGP without any particular semantics being associated with them until installed in the Loc-RIB.
BGP自体は、NLRIをそのデータベース内のエントリのキーとして扱います。LOC-RIBに配置されているエントリは、アプリケーションに依存する特定のセマンティクスセットに関連付けられます。これは既存のBGPアプリケーションと一致しています。たとえば、IPユニキャストルーティング（AFI = 1、SAFI = 1）およびIPマルチキャストリバースパス情報（AFI = 1、SAFI = 2）は、LOC-RIBにインストールされるまで、特定のセマンティクスが関連付けられないBGPによって処理されます。。
Standard BGP policy mechanisms, such as UPDATE filtering by NLRI prefix as well as community matching, must apply to the Flow specification defined NLRI-type. Network operators can also control propagation of such routing updates by enabling or disabling the exchange of a particular (AFI, SAFI) pair on a given BGP peering session.
NLRIプレフィックスによるアップデートフィルタリングなどの標準BGPポリシーメカニズム、およびコミュニティマッチングは、フロー仕様定義済みのNLRIタイプに適用されなければなりません。ネットワーク事業者は、特定のBGPピアリングセッションで特定の（AFI、SAFI）ペアの交換を可能にするか無効化することによって、そのようなルーティング更新の伝播を制御することもできます。
This document defines a Flow Specification NLRI type (Figure 1) that may include several components, such as destination prefix, source prefix, protocol, ports, and others (see Section 4.2 below).
この文書は、宛先プレフィックス、ソースプレフィックス、プロトコル、ポートなどのいくつかのコンポーネントを含めることができるフロー仕様NLRIタイプ（図1）を定義しています（下記のセクション4.2を参照）。
This NLRI information is encoded using MP_REACH_NLRI and MP_UNREACH_NLRI attributes, as defined in [RFC4760]. When advertising Flow Specifications, the Length of the Next-Hop Network Address MUST be set to 0. The Network Address of the Next-Hop field MUST be ignored.
このNLRI情報は、[RFC4760]で定義されているように、MP_REACH_NLRIおよびMP_UNREACH_NLRI属性を使用してエンコードされています。フロー仕様の広告の場合、ネクストホップネットワークアドレスの長さを0に設定する必要があります。次のホップフィールドのネットワークアドレスは無視されます。
The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as one or more 2-tuples of the form <length, NLRI value>. It consists of a 1- or 2-octet length field followed by a variable-length NLRI value. The length is expressed in octets.
MP_REACH_NLRIおよびMP_UNREACH_NLRIのNLRIフィールドは、<長さ、NLRI値>の形式の1つ以上の2タプルとしてエンコードされています。1または2オクテット長フィールドとそれに続く可変長NLRI値で構成されています。長さはオクテットで表されます。
+-------------------------------+
| length (0xnn or 0xfnnn) |
+-------------------------------+
| NLRI value (variable) |
+-------------------------------+
Figure 1: Flow Specification NLRI for IPv4
図1：IPv4のフロー仕様NLRI
Implementations wishing to exchange Flow Specification MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1), as defined in [RFC4760]. The (AFI, SAFI) pair carried in the Multiprotocol Extension Capability MUST be (AFI=1, SAFI=133) for IPv4 Flow Specification and (AFI=1, SAFI=134) for VPNv4 Flow Specification.
交換フロー仕様を交換することを望む実装は、[RFC4760]で定義されているように、BGPの機能広告機能（コード1）を交換するためにBGPの機能広告機能を使用する必要があります。Multiprotocol拡張機能で運ばれる（AFI、SAFI）ペアは、IPv4フロー仕様のための（AFI = 1、SAFI = 133）、VPNV4フロー仕様のための（AFI = 1、SAFI = 134）でなければなりません。
The length field indicates the length in octets of the variable NLRI value:
長さフィールドは、変数NLRI値のオクテットの長さを示します。
* If the NLRI length is smaller than 240 (0xf0 hex) octets, the length field can be encoded as a single octet.
* NLRI長が240（0xF0 HEX）オクテットより小さい場合、長さフィールドは単一のオクテットとして符号化することができる。
* Otherwise, it is encoded as an extended-length 2-octet value in which the most significant nibble has the hex value 0xf.
* そうでなければ、それは最も重要なニブルが16進値0xfを有する拡張長さ2 - オクテット値として符号化される。
In Figure 1 above, values less than 240 are encoded using two hex digits (0xnn). Values above 239 are encoded using 3 hex digits (0xfnnn). The highest value that can be represented with this encoding is 4095. For example, the length value of 239 is encoded as 0xef (single octet), while 240 is encoded as 0xf0f0 (2 octets).
上記の図1では、240未満の値は2桁の数字（0xnn）を使用して符号化されています。239より上の値は、3桁の数字（0xFnNn）を使用して符号化されています。この符号化で表すことができる最高値は4095である。例えば、239の長さ値は0xef（単一オクテット）として符号化され、240は0xF0F0（2オクテット）として符号化される。
The Flow Specification NLRI value consists of a list of optional components and is encoded as follows:
フロー仕様NLRI値は、オプションのコンポーネントのリストで構成されており、次のようにエンコードされています。
Encoding: <[component]+>
A specific packet is considered to match the Flow Specification when it matches the intersection (AND) of all the components present in the Flow Specification.
特定のパケットは、フロー仕様に存在するすべてのコンポーネントの交差点（AND）と一致するときにフロー仕様と一致すると考えられています。
Components MUST follow strict type ordering by increasing numerical order. A given component type MAY (exactly once) be present in the Flow Specification. If present, it MUST precede any component of higher numeric type value.
構成要素は、数値順を増やすことによって厳密な種類の順序付けに従う必要があります。与えられたコンポーネントタイプは、フロー仕様に（一度だけ）存在することがあります。存在する場合は、より高い数値型値の任意のコンポーネントの前に必要です。
All combinations of components within a single Flow Specification are allowed. However, some combinations cannot match any packets (e.g., "ICMP Type AND Port" will never match any packets) and thus SHOULD NOT be propagated by BGP.
単一のフロー仕様内の構成要素のすべての組み合わせが許可されています。ただし、一部の組み合わせはすべてのパケット（例えば、「ICMPタイプとポート」はパケットと一致することはありません）と一致することはできず、したがってBGPによって伝播されるべきではありません。
An NLRI value not encoded as specified here, including an NLRI that contains an unknown component type, is considered malformed and error handling according to Section 10 is performed.
ここで指定されているように符号化されていないNLRI値は、未知のコンポーネントタイプを含むNLRIを含む、不正な形式と見なされ、セクション10に従ってエラー処理が実行される。
Most of the components described below make use of comparison operators. Which of the two operators is used is defined by the components in Section 4.2.2. The operators are encoded as a single octet.
以下に記載される構成要素のほとんどは比較演算子を利用する。2つの演算子のうちどれがセクション4.2.2のコンポーネントによって定義されています。演算子は単一のオクテットとして符号化されています。
This operator is encoded as shown in Figure 2.
この演算子は図2に示すように符号化されている。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | len | 0 |lt |gt |eq |
+---+---+---+---+---+---+---+---+
Figure 2: Numeric Operator (numeric_op)
図2：数値演算子（NUMERIC_OP）
e (end-of-list bit): Set in the last {op, value} pair in the list
a (AND bit): If unset, the result of the previous {op, value} pair is logically ORed with the current one. If set, the operation is a logical AND. In the first operator octet of a sequence, it MUST be encoded as unset and MUST be treated as always unset on decoding. The AND operator has higher priority than OR for the purposes of evaluating logical expressions.
A（とビット）：設定解除されていない場合、前の{op、値}ペアの結果は現在のものと論理的にORされます。設定されている場合、操作は論理的です。シーケンスの最初のオペレータオクテットでは、それは設定解除として符号化されなければならず、復号化時に常に解除されないように扱われる必要があります。AND演算子は、論理式よりも高い優先順位を持ちます。
len (length): The length of the value field for this operator given as (1 << len). This encodes 1 (len=00), 2 (len=01), 4 (len=10), and 8 (len=11) octets.
LEN（長さ）：（1 << LEN）として与えられたこの演算子の値フィールドの長さ。このエンコード1（Len = 00）、2（Len = 01）、4（Len = 10）、8（Len = 11）オクテット。
0: MUST be set to 0 on NLRI encoding and MUST be ignored during decoding
0：NLRIエンコーディングで0に設定する必要があり、デコード中に無視する必要があります。
lt: less-than comparison between data and value
LT：データと値の比較以外の比較
gt: greater-than comparison between data and value
GT：データと値の比較よりも大きい
eq: equality between data and value
EQ：データと値の間の平等
The bits lt, gt, and eq can be combined to produce common relational operators, such as "less or equal", "greater or equal", and "not equal to", as shown in Table 1.
ビットLT、GT、およびEQは、表1に示すように、「小さいまたは等しい」、「より大きい」、「より大きい」、「より大きい」、「等しくない」などの共通の関係演算子を作成することができる。
+====+====+====+==================================+
| lt | gt | eq | Resulting operation |
+====+====+====+==================================+
| 0 | 0 | 0 | false (independent of the value) |
+----+----+----+----------------------------------+
| 0 | 0 | 1 | == (equal) |
+----+----+----+----------------------------------+
| 0 | 1 | 0 | > (greater than) |
+----+----+----+----------------------------------+
| 0 | 1 | 1 | >= (greater than or equal) |
+----+----+----+----------------------------------+
| 1 | 0 | 0 | < (less than) |
+----+----+----+----------------------------------+
| 1 | 0 | 1 | <= (less than or equal) |
+----+----+----+----------------------------------+
| 1 | 1 | 0 | != (not equal value) |
+----+----+----+----------------------------------+
| 1 | 1 | 1 | true (independent of the value) |
+----+----+----+----------------------------------+
Table 1: Comparison Operation Combinations
表1：比較操作の組み合わせ
This operator is encoded as shown in Figure 3.
この演算子は図3に示すように符号化されている。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| e | a | len | 0 | 0 |not| m |
+---+---+---+---+---+---+---+---+
Figure 3: Bitmask Operator (bitmask_op)
図3：ビットマスク演算子（ビットマスク_OP）
e, a, len (end-of-list bit, AND bit, and length field): Most significant nibble; defined in the Numeric Operator format in Section 4.2.1.1.
e、a、len（リストの終わりビット、およびビット、および長さフィールド）：最も重要なニブル。セクション4.2.1.1の数値演算子形式で定義されています。
not (NOT bit): If set, logical negation of operation.
NOT（ビットではない）：設定されている場合は、操作の論理否定です。
m (Match bit): If set, this is a bitwise match operation defined as "(data AND value) == value"; if unset, (data AND value) evaluates to TRUE if any of the bits in the value mask are set in the data.
M（マッチビット）：設定されている場合、これは「（データと値）==値」として定義されているビットごとの一致操作です。設定解除されていない場合、（データと値）値マスク内のビットがデータに設定されている場合はTRUEと評価されます。
0 (all 0 bits): MUST be set to 0 on NLRI encoding and MUST be ignored during decoding
0（全0ビット）：NLRIエンコーディングで0に設定する必要があり、デコード中に無視する必要があります。
The encoding of each of the components begins with a type field (1 octet) followed by a variable length parameter. The following sections define component types and parameter encodings for the IPv4 IP layer and transport layer headers. IPv6 NLRI component types are described in [RFC8956].
各コンポーネントの符号化は、型フィールド（1オクテット）とそれに続く可変長パラメータで始まる。次のセクションでは、IPv4 IP層およびトランスポート層ヘッダーのコンポーネントタイプとパラメータエンコーディングを定義します。IPv6 NLRIコンポーネントタイプは[RFC8956]に記載されています。
Encoding: <type (1 octet), length (1 octet), prefix (variable)>
Defines the destination prefix to match. The length and prefix fields are encoded as in BGP UPDATE messages [RFC4271].
一致する宛先プレフィックスを定義します。長さフィールドとプレフィックスフィールドは、BGP更新メッセージ[RFC4271]のようにエンコードされています。
Encoding: <type (1 octet), length (1 octet), prefix (variable)>
Defines the source prefix to match. The length and prefix fields are encoded as in BGP UPDATE messages [RFC4271].
一致するソースプレフィックスを定義します。長さフィールドとプレフィックスフィールドは、BGP更新メッセージ[RFC4271]のようにエンコードされています。
Encoding: <type (1 octet), [numeric_op, value]+>
Contains a list of {numeric_op, value} pairs that are used to match the IP protocol value octet in IP packet header (see Section 3.1 of [RFC0791]).
IPパケットヘッダーのIPプロトコル値オクテットを一致させるために使用される{numeric_op、value}ペアのリストが含まれています（[RFC0791]のセクション3.1を参照）。
This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 3 component values SHOULD be encoded as single octet (numeric_op len=00).
このコンポーネントは、セクション4.2.1.1で説明されている数値演算子（NUMERIC_OP）を使用します。タイプ3のコンポーネント値は、単一のオクテット（Numeric_op Len = 00）としてエンコードされます。
Encoding: <type (1 octet), [numeric_op, value]+>
Defines a list of {numeric_op, value} pairs that match source OR destination TCP/UDP ports (see Section 3.1 of [RFC0793] and the "Format" section of [RFC0768]). This component matches if either the destination port OR the source port of an IP packet matches the value.
ソースまたは宛先TCP / UDPポートと一致する{numeric_op、value}ペアのリストを定義します（[RFC0793]のセクション3.1および[RFC0768]の「フォーマット」セクションを参照）。このコンポーネントは、IPパケットの宛先ポートまたは送信元ポートのいずれかが値と一致すると一致します。
This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 4 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01).
このコンポーネントは、セクション4.2.1.1で説明されている数値演算子（NUMERIC_OP）を使用します。タイプ4の成分値は、1または2オクテット量（数値_OP LEN = 00またはLEN = 01）として符号化されるべきである。
In case of the presence of the port (destination-port (Section 4.2.2.5), source-port (Section 4.2.2.6)) component, only TCP or UDP packets can match the entire Flow Specification. The port component, if present, never matches when the packet's IP protocol value is not 6 (TCP) or 17 (UDP), if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.
ポートが存在する場合（宛先ポート（セクション4.2.2.5）、Source-Port（セクション4.2.2.6））コンポーネントの場合、TCPまたはUDPパケットのみがフロー仕様全体に一致できます。Portコンポーネントが存在する場合は、パケットのIPプロトコル値が6（TCP）または17（UDP）が断片化されていて、これが最初のフラグメントではない場合、またはシステムがトランスポートを見つけることができない場合には一致しません。ヘッダ。さまざまな実装が、IPオプションの存在下でトランスポートヘッダをデコードすることもできない場合があり、セキュリティペイロード（ESP）NULL [RFC4303]暗号化をカプセル化できない場合があります。
Encoding: <type (1 octet), [numeric_op, value]+>
Defines a list of {numeric_op, value} pairs used to match the destination port of a TCP or UDP packet (see also Section 3.1 of [RFC0793] and the "Format" section of [RFC0768].
TCPまたはUDPパケットの宛先ポートと一致する{numeric_op、value}ペアのリストを定義します（[RFC0793]のセクション3.1、[RFC0768]の「フォーマット」セクションも参照してください。
This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 5 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01).
このコンポーネントは、セクション4.2.1.1で説明されている数値演算子（NUMERIC_OP）を使用します。タイプ5のコンポーネント値は、1または2オクテット数量（Numeric_op Len = 00またはLEN = 01）として符号化されるべきである。
The last paragraph of Section 4.2.2.4 also applies to this component.
セクション4.2.2.4の最後の段落はこのコンポーネントにも適用されます。
Encoding: <type (1 octet), [numeric_op, value]+>
Defines a list of {numeric_op, value} pairs used to match the source port of a TCP or UDP packet (see also Section 3.1 of [RFC0793] and the "Format" section of [RFC0768].
TCPまたはUDPパケットの送信元ポートと一致する{numeric_op、value}ペアのリストを定義します（[RFC0793]のセクション3.1、[RFC0768]の「フォーマット」セクションも参照してください。
This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 6 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01).
このコンポーネントは、セクション4.2.1.1で説明されている数値演算子（NUMERIC_OP）を使用します。タイプ6の成分値は、1または2オクテット数量（Numeric_op Len = 00またはLen = 01）として符号化されるべきである。
The last paragraph of Section 4.2.2.4 also applies to this component.
セクション4.2.2.4の最後の段落はこのコンポーネントにも適用されます。
Encoding: <type (1 octet), [numeric_op, value]+>
Defines a list of {numeric_op, value} pairs used to match the type field of an ICMP packet (see also the "Message Formats" section of [RFC0792]).
ICMPパケットのTypeフィールドと一致する{numeric_op、value}ペアのリストを定義します（[RFC0792]の「メッセージフォーマット」も参照）。
This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 7 component values SHOULD be encoded as single octet (numeric_op len=00).
このコンポーネントは、セクション4.2.1.1で説明されている数値演算子（NUMERIC_OP）を使用します。タイプ7のコンポーネント値は、単一のオクテット（Numeric_op Len = 00）としてエンコードされます。
In case of the presence of the ICMP type component, only ICMP packets can match the entire Flow Specification. The ICMP type component, if present, never matches when the packet's IP protocol value is not 1 (ICMP), if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.
ICMP型コンポーネントが存在する場合は、ICMPパケットのみがフロー仕様全体に一致できます。ICMPタイプコンポーネントが存在する場合は、パケットのIPプロトコル値が1（ICMP）ではない場合は一致しません。パケットがフラグメント化されている場合、またはこれが最初のフラグメントではない場合、またはシステムがトランスポートヘッダーを見つけることができない場合。さまざまな実装が、IPオプションの存在下でトランスポートヘッダをデコードすることもできない場合があり、セキュリティペイロード（ESP）NULL [RFC4303]暗号化をカプセル化できない場合があります。
Encoding: <type (1 octet), [numeric_op, value]+>
Defines a list of {numeric_op, value} pairs used to match the code field of an ICMP packet (see also the "Message Formats" section of [RFC0792]).
ICMPパケットのコードフィールドと一致する{numeric_op、value}ペアのリストを定義します（[RFC0792]の「メッセージフォーマット」セクションも参照）。
This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 8 component values SHOULD be encoded as single octet (numeric_op len=00).
このコンポーネントは、セクション4.2.1.1で説明されている数値演算子（NUMERIC_OP）を使用します。タイプ8のコンポーネント値は、単一のオクテットとしてエンコードされます（numeric_op len = 00）。
In case of the presence of the ICMP code component, only ICMP packets can match the entire Flow Specification. The ICMP code component, if present, never matches when the packet's IP protocol value is not 1 (ICMP), if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.
ICMPコードコンポーネントが存在する場合、ICMPパケットのみがフロー仕様全体に一致することができます。ICMPコードコンポーネントが存在する場合、パケットのIPプロトコル値が1（ICMP）ではなく、パケットがフラグメント化されていて最初のフラグメントではない場合、またはシステムがトランスポートヘッダーを見つけることができない場合には一致しません。さまざまな実装が、IPオプションの存在下でトランスポートヘッダをデコードすることもできない場合があり、セキュリティペイロード（ESP）NULL [RFC4303]暗号化をカプセル化できない場合があります。
Encoding: <type (1 octet), [bitmask_op, bitmask]+>
Defines a list of {bitmask_op, bitmask} pairs used to match TCP control bits (see also Section 3.1 of [RFC0793]).
TCPコントロールビットと一致するために使用される{bitmask_op、bitmask}ペアのリストを定義します（[RFC0793のセクション3.1）。
This component uses the Bitmask Operator (bitmask_op) described in Section 4.2.1.2. Type 9 component bitmasks MUST be encoded as 1- or 2-octet bitmask (bitmask_op len=00 or len=01).
このコンポーネントはセクション4.2.1.2で説明されているビットマスク演算子（bitmask_op）を使用します。タイプ9のコンポーネントビットマスクは、1または2オクテットビットマスク（bitmask_op len = 00またはlen = 01）としてエンコードする必要があります。
When a single octet (bitmask_op len=00) is specified, it matches octet 14 of the TCP header (see also Section 3.1 of [RFC0793]), which contains the TCP control bits. When a 2-octet (bitmask_op len=01) encoding is used, it matches octets 13 and 14 of the TCP header with the data offset (leftmost 4 bits) always treated as 0.
単一のオクテット（ビットマスク_OP LEN = 00）が指定されている場合、TCPヘッダーのオクテット14と一致します（[RFC0793]のセクション3.1も参照）。これにはTCPコントロールビットが含まれています。2オクテット（ビットマスク_OP LEN = 01）エンコーディングが使用されるとき、それはデータオフセット（左端の4ビット）を常に0として扱われてTCPヘッダのオクテット13および14と一致する。
In case of the presence of the TCP flags component, only TCP packets can match the entire Flow Specification. The TCP flags component, if present, never matches when the packet's IP protocol value is not 6 (TCP), if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.
TCPフラグコンポーネントが存在する場合、TCPパケットのみがフロー仕様全体に合わせることができます。TCPフラグコンポーネントが存在する場合は、パケットのIPプロトコル値が6（TCP）ではなく、パケットがフラグメント化されていて最初のフラグメントではない場合、またはシステムがトランスポートヘッダーを見つけることができない場合には一致しません。さまざまな実装が、IPオプションの存在下でトランスポートヘッダをデコードすることもできない場合があり、セキュリティペイロード（ESP）NULL [RFC4303]暗号化をカプセル化できない場合があります。
Encoding: <type (1 octet), [numeric_op, value]+>
Defines a list of {numeric_op, value} pairs used to match on the total IP packet length (excluding Layer 2 but including IP header).
合計IPパケット長（レイヤ2を除くが、IPヘッダを含む）を一致させるために使用される{numeric_op、value}ペアのリストを定義します。
This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 10 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01).
このコンポーネントは、セクション4.2.1.1で説明されている数値演算子（NUMERIC_OP）を使用します。タイプ10のコンポーネント値は、1または2オクテットの量（Numeric_op Len = 00またはLen = 01）として符号化されるべきである。
Encoding: <type (1 octet), [numeric_op, value]+>
Defines a list of {numeric_op, value} pairs used to match the 6-bit DSCP field (see also [RFC2474]).
6ビットDSCPフィールドと一致するために使用される{numeric_op、value}ペアのリストを定義します（[RFC2474]も参照）。
This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 11 component values MUST be encoded as single octet (numeric_op len=00).
このコンポーネントは、セクション4.2.1.1で説明されている数値演算子（NUMERIC_OP）を使用します。タイプ11のコンポーネント値は、単一のオクテット（numeric_op len = 00）としてエンコードする必要があります。
The six least significant bits contain the DSCP value. All other bits SHOULD be treated as 0.
6つの最下位ビットにはDSCP値が含まれています。他のすべてのビットは0として扱われるべきです。
Encoding: <type (1 octet), [bitmask_op, bitmask]+>
Defines a list of {bitmask_op, bitmask} pairs used to match specific IP fragments.
特定のIPフラグメントを一致させるために使用される{bitmask_op、bitmask}ペアのリストを定義します。
This component uses the Bitmask Operator (bitmask_op) described in Section 4.2.1.2. The Type 12 component bitmask MUST be encoded as single octet bitmask (bitmask_op len=00).
このコンポーネントはセクション4.2.1.2で説明されているビットマスク演算子（bitmask_op）を使用します。タイプ12コンポーネントビットマスクは、単一のオクテットビットマスク（bitmask_op len = 00）としてエンコードする必要があります。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 0 |LF |FF |IsF|DF |
+---+---+---+---+---+---+---+---+
Figure 4: Fragment Bitmask Operand
図4：フラグメントビットマスクオペランド
Bitmask values:
ビットマスク値：
DF (Don't Fragment): match if IP Header Flags Bit-1 (DF) [RFC0791] is 1
DF（断片化しない）：IPヘッダーフラグがBIT-1（DF）[RFC0791]の場合は一致
IsF (Is a fragment other than the first): match if the [RFC0791] IP Header Fragment Offset is not 0
ISF（最初のもの以外のフラグメント）：[RFC0791] IPヘッダーフラグメントオフセットが0でない場合は一致します
FF (First Fragment): match if the [RFC0791] IP Header Fragment Offset is 0 AND Flags Bit-2 (MF) is 1
ff（ファーストフラグメント）：[RFC0791] IPヘッダーフラグメントオフセットが0、フラグBIT-2（MF）が1の場合
LF (Last Fragment): match if the [RFC0791] IP Header Fragment Offset is not 0 AND Flags Bit-2 (MF) is 0
LF（Last Fragment）：[RFC0791] IPヘッダーフラグメントオフセットが0で、フラグBIT-2（MF）が0の場合
0: MUST be set to 0 on NLRI encoding and MUST be ignored during decoding
0：NLRIエンコーディングで0に設定する必要があり、デコード中に無視する必要があります。
An example of a Flow Specification NLRI encoding for: "all packets to 192.0.2.0/24 and TCP port 25".
"すべてのパケットから192.0.2.0/24、TCPポート25"のフロー仕様NLRIの例。
+========+================+==========+==========+
| length | destination | protocol | port |
+========+================+==========+==========+
| 0x0b | 01 18 c0 00 02 | 03 81 06 | 04 81 19 |
+--------+----------------+----------+----------+
Table 2
表2.
Decoded:
復号化：
+=======+==============================================+
| Value | |
+=======+============+=================================+
| 0x0b | length | 11 octets (if len<240, 1 octet) |
+-------+------------+---------------------------------+
| 0x01 | type | Type 1 - Destination Prefix |
+-------+------------+---------------------------------+
| 0x18 | length | 24 bit |
+-------+------------+---------------------------------+
| 0xc0 | prefix | 192 |
+-------+------------+---------------------------------+
| 0x00 | prefix | 0 |
+-------+------------+---------------------------------+
| 0x02 | prefix | 2 |
+-------+------------+---------------------------------+
| 0x03 | type | Type 3 - IP Protocol |
+-------+------------+---------------------------------+
| 0x81 | numeric_op | end-of-list, value size=1, == |
+-------+------------+---------------------------------+
| 0x06 | value | 6 (TCP) |
+-------+------------+---------------------------------+
| 0x04 | type | Type 4 - Port |
+-------+------------+---------------------------------+
| 0x81 | numeric_op | end-of-list, value size=1, == |
+-------+------------+---------------------------------+
| 0x19 | value | 25 |
+-------+------------+---------------------------------+
Table 3
表3.
This constitutes an NLRI with an NLRI length of 11 octets.
これはNLRI長が11オクテットのNLRIを構成している。
An example of a Flow Specification NLRI encoding for: "all packets to 192.0.2.0/24 from 203.0.113.0/24 and port {range [137, 139] or 8080}".
「203.0.113.0/24から192.0.2.0/24とポート{range [137,139、または8080}」のフロー仕様NLRIの例。
+========+================+================+=============+
| length | destination | source | port |
+========+================+================+=============+
| 0x12 | 01 18 c0 00 02 | 02 18 cb 00 71 | 04 03 89 45 |
| | | | 8b 91 1f 90 |
+--------+----------------+----------------+-------------+
Table 4
表4.
Decoded:
復号化：
+========+==============================================+
| Value | |
+========+============+=================================+
| 0x12 | length | 18 octets (if len<240, 1 octet) |
+--------+------------+---------------------------------+
| 0x01 | type | Type 1 - Destination Prefix |
+--------+------------+---------------------------------+
| 0x18 | length | 24 bit |
+--------+------------+---------------------------------+
| 0xc0 | prefix | 192 |
+--------+------------+---------------------------------+
| 0x00 | prefix | 0 |
+--------+------------+---------------------------------+
| 0x02 | prefix | 2 |
+--------+------------+---------------------------------+
| 0x02 | type | Type 2 - Source Prefix |
+--------+------------+---------------------------------+
| 0x18 | length | 24 bit |
+--------+------------+---------------------------------+
| 0xcb | prefix | 203 |
+--------+------------+---------------------------------+
| 0x00 | prefix | 0 |
+--------+------------+---------------------------------+
| 0x71 | prefix | 113 |
+--------+------------+---------------------------------+
| 0x04 | type | Type 4 - Port |
+--------+------------+---------------------------------+
| 0x03 | numeric_op | value size=1, >= |
+--------+------------+---------------------------------+
| 0x89 | value | 137 |
+--------+------------+---------------------------------+
| 0x45 | numeric_op | "AND", value size=1, <= |
+--------+------------+---------------------------------+
| 0x8b | value | 139 |
+--------+------------+---------------------------------+
| 0x91 | numeric_op | end-of-list, value size=2, == |
+--------+------------+---------------------------------+
| 0x1f90 | value | 8080 |
+--------+------------+---------------------------------+
Table 5
表5.
This constitutes an NLRI with an NLRI length of 18 octets.
これはNLRI長が18オクテットのNLRIを構成する。
An example of a Flow Specification NLRI encoding for: "all packets to 192.0.2.1/32 and fragment { DF or FF } (matching packet with DF bit set or First Fragments)
Flow Specification NLRIエンコーディングの例： ""すべてのパケットから192.0.2.1 / 32とフラグメント{dfまたはff}（DFビットセットまたは最初のフラグメントとのマッチングパケット）
+========+===================+==========+
| length | destination | fragment |
+========+===================+==========+
| 0x09 | 01 20 c0 00 02 01 | 0c 80 05 |
+--------+-------------------+----------+
Table 6
表6.
Decoded:
復号化：
+=======+=============================================+
| Value | |
+=======+============+================================+
| 0x09 | length | 9 octets (if len<240, 1 octet) |
+-------+------------+--------------------------------+
| 0x01 | type | Type 1 - Destination Prefix |
+-------+------------+--------------------------------+
| 0x20 | length | 32 bit |
+-------+------------+--------------------------------+
| 0xc0 | prefix | 192 |
+-------+------------+--------------------------------+
| 0x00 | prefix | 0 |
+-------+------------+--------------------------------+
| 0x02 | prefix | 2 |
+-------+------------+--------------------------------+
| 0x01 | prefix | 1 |
+-------+------------+--------------------------------+
| 0x0c | type | Type 12 - Fragment |
+-------+------------+--------------------------------+
| 0x80 | bitmask_op | end-of-list, value size=1 |
+-------+------------+--------------------------------+
| 0x05 | bitmask | DF=1, FF=1 |
+-------+------------+--------------------------------+
Table 7
表7.
This constitutes an NLRI with an NLRI length of 9 octets.
これはNLRI長さ9オクテットのNLRIを構成する。
Traffic filtering policies have been traditionally considered to be relatively static. Limitations of these static mechanisms caused this new dynamic mechanism to be designed for the three new applications of traffic filtering:
トラフィックフィルタリングポリシーは伝統的に比較的静的であると考えられてきました。これらの静的メカニズムの制限により、この新しい動的メカニズムは、トラフィックフィルタリングの3つの新しいアプリケーション用に設計されました。
* Prevention of traffic-based, denial-of-service (DoS) attacks
* トラフィックベースの、サービス拒否（DOS）攻撃の防止
* Traffic filtering in the context of BGP/MPLS VPN service
* BGP / MPLS VPNサービスのコンテキストにおけるトラフィックフィルタリング
* Centralized traffic control for SDN/NFV networks
* SDN / NFVネットワークの集中トラフィック制御
These applications require coordination among service providers and/ or coordination among the AS within a service provider.
これらのアプリケーションは、サービスプロバイダ内のサービスプロバイダおよび/または調整を必要とする。
The Flow Specification NLRI defined in Section 4 conveys information about traffic filtering rules for traffic that should be discarded or handled in a manner specified by a set of predefined actions (which are defined in BGP Extended Communities). This mechanism is primarily designed to allow an upstream autonomous system to perform inbound filtering in their ingress routers of traffic that a given downstream AS wishes to drop.
セクション4で定義されているフロー仕様NLRIは、一連の定義済みアクション（BGP拡張コミュニティで定義されている）によって指定された方法で破棄または処理されるべきトラフィックのトラフィックフィルタリングルールに関する情報を伝達します。このメカニズムは主に、上流の自律システムがトラフィックの入力ルータでインバウンドフィルタをドロップしたいと思うようにインバウンドフィルタを実行できるように設計されています。
In order to achieve this goal, this document specifies two application-specific NLRI identifiers that provide traffic filters and a set of actions encoding in BGP Extended Communities. The two application-specific NLRI identifiers are:
この目的を達成するために、このドキュメントはトラフィックフィルタを提供する2つのアプリケーション固有のNLRI識別子とBGP拡張コミュニティでエンコードされた一連のアクションを指定します。2つのアプリケーション固有のNLRI識別子は次のとおりです。
* IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with specific semantic rules for IPv4 routes and
* IPv4ルートの特定の意味論とともに、IPv4フロー仕様識別子（AFI = 1、SAFI = 133）
* VPNv4 Flow Specification identifier (AFI=1, SAFI=134) value, which can be used to propagate traffic filtering information in a BGP/ MPLS VPN environment.
* VPNv4フロー仕様識別子（AFI = 1、SAFI = 134）値は、BGP / MPLS VPN環境でトラフィックフィルタリング情報を伝播するために使用できます。
Encoding of the NLRI is described in Section 4 for IPv4 Flow Specification and in Section 8 for VPNv4 Flow Specification. The filtering actions are described in Section 7.
NLRIのエンコードは、IPv4フロー仕様およびVPNv4フロー仕様のセクション8のセクション4に記載されています。フィルタリング動作はセクション7に記載されている。
More than one Flow Specification may match a particular traffic flow. Thus, it is necessary to define the order in which Flow Specifications get matched and actions being applied to a particular traffic flow. This ordering function is such that it does not depend on the arrival order of the Flow Specification via BGP and thus is consistent in the network.
複数のフロー仕様が特定のトラフィックフローに一致する可能性があります。したがって、フロー仕様が一致して特定のトラフィックフローに適用される順序を定義する必要があります。この順序付け機能は、BGPを介したフロー仕様の到着順序に依存しないようなものであり、したがってネットワーク内で一致するようなものである。
The relative order of two Flow Specifications is determined by comparing their respective components. The algorithm starts by comparing the left-most components (lowest component type value) of the Flow Specifications. If the types differ, the Flow Specification with lowest numeric type value has higher precedence (and thus will match before) than the Flow Specification that doesn't contain that component type. If the component types are the same, then a type-specific comparison is performed (see below). If the types are equal, the algorithm continues with the next component.
2つのフロー仕様の相対順序は、それらのそれぞれの構成要素を比較することによって決定されます。アルゴリズムは、フロー仕様の左端の成分（最低の成分タイプ値）を比較することから始まります。タイプが異なる場合は、数値型の値が小さいフロー指定は、そのコンポーネントタイプを含まないフロー仕様よりも優先順位が高い（したがって、以前には一致します）。コンポーネントタイプが同じ場合、タイプ固有の比較が実行されます（下記参照）。タイプが等しい場合、アルゴリズムは次のコンポーネントで続行されます。
For IP prefix values (IP destination or source prefix), if one of the two prefixes to compare is a more specific prefix of the other, the more specific prefix has higher precedence. Otherwise, the one with the lowest IP value has higher precedence.
IPプレフィックス値（IP宛先またはソースプレフィックス）の場合、比較する2つの接頭辞のうちの2つが他のもののより具体的な接頭辞である場合、より具体的な接頭辞は優先順位が高い。そうでなければ、IP値が最も小さい方は優先順位が高いです。
For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by [ISO_IEC_9899]. For strings with equal lengths, the lowest string (memcmp) has higher precedence. For strings of different lengths, the common prefix is compared. If the common prefix is not equal, the string with the lowest prefix has higher precedence. If the common prefix is equal, the longest string is considered to have higher precedence than the shorter one.
他のすべてのコンポーネントタイプについて、特に指定のない限り、[ISO_IEC_9899]で定義されているMEMCMP（）関数を使用して、コンポーネントデータをバイナリ文字列と比較することによって比較が実行されます。等しい文字列の場合、最低文字列（memcmp）は優先順位が大きいです。長さの異なる文字列の場合、一般的なプレフィックスが比較されます。共通の接頭辞が等しくない場合、最低の接頭辞を持つ文字列は優先順位が高いです。共通の接頭辞が等しい場合、最長文字列は、より短い方の優先順位が高いと見なされます。
The code in Appendix A shows a Python3 implementation of the comparison algorithm. The full code was tested with Python 3.6.3 and can be obtained at <https://github.com/stoffi92/rfc5575bis/tree/master/flowspec-cmp>.
付録Aのコードは、比較アルゴリズムのPython3実装を示しています。フルコードはPython 3.6.3でテストされ、<https：//github.com/stoffi92/rfc5575bis/tree/master/flowspec-cmp>で入手できました。
Flow Specifications received from a BGP peer that are accepted in the respective Adj-RIB-In are used as input to the route selection process. Although the forwarding attributes of two routes for the same Flow Specification prefix may be the same, BGP is still required to perform its path selection algorithm in order to select the correct set of attributes to advertise.
各整合リブインに受け入れられたBGPピアから受信されたフロー仕様は、経路選択プロセスへの入力として使用される。同じフロー仕様プレフィックスの2つの経路の転送属性は同じであり得るが、広告の正しい属性のセットを選択するためにそのパス選択アルゴリズムを実行するためにBGPは依然として必要である。
The first step of the BGP Route Selection procedure (Section 9.1.2 of [RFC4271]) is to exclude from the selection procedure routes that are considered unfeasible. In the context of IP routing information, this step is used to validate that the NEXT_HOP attribute of a given route is resolvable.
BGP経路選択手順の最初のステップ（[RFC4271]のセクション9.1.2）は、実行不可能と見なされる選択手順ルートから除外することです。IPルーティング情報のコンテキストでは、このステップは、特定のルートのnext_hop属性が解決可能であることを検証するために使用されます。
The concept can be extended, in the case of the Flow Specification NLRI, to allow other validation procedures.
フロー仕様NLRIの場合、他の検証手順を可能にするために、概念を拡張することができます。
The validation process described below validates Flow Specifications against unicast routes received over the same AFI but the associated unicast routing information SAFI:
以下の検証プロセスは、同じAFI経由で受信されたUnicast Routeに対するフロー仕様を検証しますが、関連するユニキャストルーティング情報SAFI：
* Flow Specification received over SAFI=133 will be validated against routes received over SAFI=1.
* SAFI = 133で受信されたフロー仕様は、SAFI = 1を介して受信されたルートに対して検証されます。
* Flow Specification received over SAFI=134 will be validated against routes received over SAFI=128.
* SAFI = 134を介して受信されたフロー仕様は、SAFI = 128を介して受信されたルートに対して検証されます。
In the absence of explicit configuration, a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the conditions below are true:
明示的な構成がない場合は、以下のすべての条件が当てはまる場合に限り、フロー仕様NLRIを検証する必要があります。
a) A destination prefix component is embedded in the Flow Specification.
a) 宛先プレフィックスコンポーネントはフロー仕様に埋め込まれています。
b) The originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification (this is the unicast route with the longest possible prefix length covering the destination prefix embedded in the Flow Specification).
b) フロー仕様の発信者は、フロー仕様に埋め込まれている宛先プレフィックスの最適なユニキャストルートの発信者と一致します（これは、フロー仕様に埋め込まれた宛先プレフィックスをカバーする可能な限り長いプレフィックス長を持つユニキャストルートです）。
c) There are no "more-specific" unicast routes, when compared with the flow destination prefix, that have been received from a different neighboring AS than the best-match unicast route, which has been determined in rule b.
c) ルールBで決定された最良のマッチングユニキャストルートとは異なる隣接から受信されたフロー先のプレフィックスと比較した場合、「より特定の」ユニキャストルートはありません。
However, rule a MAY be relaxed by explicit configuration, permitting Flow Specifications that include no destination prefix component. If such is the case, rules b and c are moot and MUST be disregarded.
ただし、ルールAは明示的な構成によって緩和され、宛先プレフィックスコンポーネントを含まないフロー仕様を許可します。そのような場合は、ルールBとCが起動し、無視する必要があります。
By "originator" of a BGP route, we mean either the address of the originator in the ORIGINATOR_ID Attribute [RFC4456] or the source IP address of the BGP peer, if this path attribute is not present.
BGPルートの「発信者」とは、このパス属性が存在しない場合、ofistor_id属性[RFC4456]またはBGPピアの送信元IPアドレスのオリジネータのアドレスを意味します。
BGP implementations MUST also enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the left-most position of the AS_PATH attribute. While this rule is optional in the BGP specification, it becomes necessary to enforce it here for security reasons.
BGP実装は、外部ボーダーゲートウェイプロトコル（EBGP）を介して受信されたルートのAS_PATH属性も、AS_PATH属性の左端の位置にある隣接を含むことを強制する必要があります。この規則はBGP仕様ではオプションですが、セキュリティ上の理由からここでそれを強制する必要があります。
The best-match unicast route may change over the time independently of the Flow Specification NLRI. Therefore, a revalidation of the Flow Specification NLRI MUST be performed whenever unicast routes change. Revalidation is defined as retesting rules a to c as described above.
最適なユニキャストルートは、フロー仕様NLRIとは無関係に時間にわたって変化する可能性があります。したがって、フロー仕様NLRIの再検証は、ユニキャストルートが変更されるたびに実行されなければなりません。再検証は、上述のようにRESTING RULES A~Cとして定義されます。
Explanation:
説明：
The underlying concept is that the neighboring AS that advertises the best unicast route for a destination is allowed to advertise Flow Specification information that conveys a destination prefix that is more or equally specific. Thus, as long as there are no "more-specific" unicast routes received from a different neighboring AS, which would be affected by that Flow Specification, the Flow Specification is validated successfully.
根本的な概念は、宛先のための最良のユニキャストルートをアドバタイズする隣接が、宛先プレフィックスを提供するフロー仕様情報を広告することが許可されているということです。したがって、そのフロー仕様の影響を受けるであろう別の隣接のような「より特定の」ユニキャストルートがない限り、フロー仕様は正常に検証されます。
The neighboring AS is the immediate destination of the traffic described by the Flow Specification. If it requests these flows to be dropped, that request can be honored without concern that it represents a denial of service in itself. The reasoning is that this is as if the traffic is being dropped by the downstream autonomous system, and there is no added value in carrying the traffic to it.
隣接する隣接は、フロー仕様によって記述されたトラフィックの即時の宛先です。これらのフローをドロップさせるように要求する場合、その要求はそれ自体でサービス拒否を表すことなく尊重されます。推論は、これがダウンストリーム自律システムによってトラフィックが削除されているかのようなものであり、そのトラフィックを伝送する際に追加された値はありません。
This document defines a minimum set of Traffic Filtering Actions that it standardizes as BGP Extended Communities [RFC4360]. This is not meant to be an inclusive list of all the possible actions but only a subset that can be interpreted consistently across the network. Additional actions can be defined as either requiring standards or as vendor specific.
このドキュメントでは、BGP拡張コミュニティ[RFC4360]として標準化するトラフィックフィルタリングアクションの最小セットを定義します。これは、すべての可能なアクションの包括的なリストであることを意味していませんが、ネットワーク全体で一貫して解釈できるサブセットだけです。追加のアクションは、標準またはベンダー固有のものとして定義できます。
The default action for a matching Flow Specification is to accept the packet (treat the packet according to the normal forwarding behavior of the system).
一致するフロー仕様のデフォルトの動作は、パケットを受け入れることです（システムの通常の転送動作に従ってパケットを扱う）。
This document defines the following Extended Communities values shown in Table 8 in the form 0xttss, where tt indicates the type and ss indicates the sub-type of the Extended Community. Encodings for these Extended Communities are described below.
このドキュメントは、表8に示す次の拡張コミュニティ値を0xttssの形式で定義します。ここで、TTはタイプを示し、SSは拡張コミュニティのサブタイプを示します。これらの拡張コミュニティのエンコーディングについては後述する。
+==================+======================+=======================+
| community 0xttss | action | encoding |
+==================+======================+=======================+
| 0x8006 | traffic-rate-bytes | 2-octet AS, 4-octet |
| | (Section 7.1) | float |
+------------------+----------------------+-----------------------+
| 0x800c | traffic-rate-packets | 2-octet AS, 4-octet |
| | (Section 7.2) | float |
+------------------+----------------------+-----------------------+
| 0x8007 | traffic-action | bitmask |
| | (Section 7.3) | |
+------------------+----------------------+-----------------------+
| 0x8008 | rt-redirect AS- | 2-octet AS, 4-octet |
| | 2octet (Section 7.4) | value |
+------------------+----------------------+-----------------------+
| 0x8108 | rt-redirect IPv4 | 4-octet IPv4 address, |
| | (Section 7.4) | 2-octet value |
+------------------+----------------------+-----------------------+
| 0x8208 | rt-redirect AS- | 4-octet AS, 2-octet |
| | 4octet (Section 7.4) | value |
+------------------+----------------------+-----------------------+
| 0x8009 | traffic-marking | DSCP value |
| | (Section 7.5) | |
+------------------+----------------------+-----------------------+
Table 8: Traffic Filtering Action Extended Communities
表8：トラフィックフィルタリングアクション拡張コミュニティ
Multiple Traffic Filtering Actions defined in this document may be present for a single Flow Specification and SHOULD be applied to the traffic flow (for example, traffic-rate-bytes and rt-redirect can be applied to packets at the same time). If not all of the Traffic Filtering Actions can be applied to a traffic flow, they should be treated as interfering Traffic Filtering Actions (see below).
この文書で定義された複数のトラフィックフィルタリングアクションは、単一のフロー仕様に対して存在し、トラフィックフローに適用されるべきです（たとえば、トラフィックレートバイトとRTリダイレクトは同時にパケットに適用できます）。すべてのトラフィックフィルタリングアクションをトラフィックフローに適用できるわけではない場合は、それらを干渉するトラフィックフィルタリングアクションとして扱う必要があります（下記参照）。
Some Traffic Filtering Actions may interfere with each other or even contradict. Section 7.7 of this document provides general considerations on such Traffic Filtering Action interference. Any additional definition of Traffic Filtering Actions SHOULD specify the action to take if those Traffic Filtering Actions interfere (also with existing Traffic Filtering Actions).
いくつかのトラフィックフィルタリングアクションは、互いに干渉したり、矛盾したりする可能性があります。この文書のセクション7.7は、そのようなトラフィックフィルタリングのアクション干渉に関する一般的な考慮事項を提供します。トラフィックフィルタリングアクションの追加の定義は、それらのトラフィックフィルタリングアクションが干渉している場合に実行するアクションを指定する必要があります（既存のトラフィックフィルタリングアクションも使用）。
All Traffic Filtering Actions are specified as transitive BGP Extended Communities.
すべてのトラフィックフィルタリングアクションは、推移的BGP拡張コミュニティとして指定されています。
The traffic-rate-bytes Extended Community uses the following Extended Community encoding:
Traffic-Rate-Bytes Extendedコミュニティは、次の拡張コミュニティエンコーディングを使用します。
The first two octets carry the 2-octet id, which can be assigned from a 2-octet AS number. When a 4-octet AS number is locally present, the 2 least significant octets of such an AS number can be used. This value is purely informational and SHOULD NOT be interpreted by the implementation.
最初の2つのオクテットは2オクテットIDを運びます。これは2オクテットから数字として割り当てることができます。数が局所的に存在すると4-オクテットが存在する場合、そのようなものの2つの最下位オクテットを使用することができる。この値は純粋に情報であり、実装によって解釈されるべきではありません。
The remaining 4 octets carry the maximum rate information in IEEE floating point [IEEE.754.1985] format, units being bytes per second. A traffic-rate of 0 should result on all traffic for the particular flow to be discarded. On encoding, the traffic-rate MUST NOT be negative. On decoding, negative values MUST be treated as zero (discard all traffic).
残りの4オクテットは、IEEEフローティングポイントの最大レート情報を運びます[IEEE.754.1985]フォーマット、単位は1秒あたりバイトです。トラフィックレート0は、特定のフローのすべてのトラフィックを破棄する必要があります。エンコードでは、トラフィックレートは負ではない。復号化時に、負の値はゼロとして扱われなければなりません（すべてのトラフィックを破棄する）。
Interferes with: May interfere with the traffic-rate-packets (see Section 7.2). A policy may allow both filtering by traffic-rate-packets and traffic-rate-bytes. If the policy does not allow this, these two actions will conflict.
干渉：トラフィックレートパケットを妨げる可能性があります（セクション7.2を参照）。ポリシーでは、トラフィックレートパケットとトラフィックレートバイトによるフィルタリングの両方が可能になる可能性があります。ポリシーがこれを許可しない場合、これら2つのアクションは競合します。
The traffic-rate-packets Extended Community uses the same encoding as the traffic-rate-bytes Extended Community. The floating point value carries the maximum packet rate in packets per second. A traffic-rate-packets of 0 should result in all traffic for the particular flow to be discarded. On encoding, the traffic-rate-packets MUST NOT be negative. On decoding, negative values MUST be treated as zero (discard all traffic).
トラフィックレートパケット拡張コミュニティは、トラフィックレートバイト拡張コミュニティと同じエンコードを使用します。浮動小数点値は、毎秒パケット内の最大パケットレートを搬送します。トラフィックレートパケット0は、特定のフローが破棄されるためのすべてのトラフィックになるはずです。エンコードでは、トラフィックレートパケットは負ではない。復号化時に、負の値はゼロとして扱われなければなりません（すべてのトラフィックを破棄する）。
Interferes with: May interfere with the traffic-rate-bytes (see Section 7.1). A policy may allow both filtering by traffic-rate-packets and traffic-rate-bytes. If the policy does not allow this, these two actions will conflict.
干渉：トラフィックレートバイトを妨げる可能性があります（セクション7.1を参照）。ポリシーでは、トラフィックレートパケットとトラフィックレートバイトによるフィルタリングの両方が可能になる可能性があります。ポリシーがこれを許可しない場合、これら2つのアクションは競合します。
The traffic-action Extended Community consists of 6 octets of which only the 2 least significant bits of the 6th octet (from left to right) are defined by this document, as shown in Figure 5.
トラフィックアクション拡張コミュニティは、図5に示すように、6オクテットの2つの最下位ビットのみ（左から右へ）のみがこの文書によって定義されている6オクテットで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Action Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tr. Action Field (cont.) |S|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Traffic-Action Extended Community Encoding
図5：トラフィックアクション拡張コミュニティエンコーディング
S and T are defined as:
SとTは次のように定義されています。
T Terminal Action (bit 47): When this bit is set, the traffic filtering engine will evaluate any subsequent Flow Specifications (as defined by the ordering procedure Section 5.1). If not set, the evaluation of the traffic filters stops when this Flow Specification is evaluated.
T端子の動作（ビット47）：このビットが設定されていると、トラフィックフィルタリングエンジンは次のフロー仕様を評価します（順序付け手順セクション5.1で定義されているように）。設定されていない場合、このフロー仕様が評価されたときにトラフィックフィルタの評価が停止します。
S Sample (bit 46): Enables traffic sampling and logging for this Flow Specification (only effective when set).
■サンプル（ビット46）：このフロー仕様のトラフィックサンプリングとロギングを有効にします（設定時にのみ有効）。
Traffic Action Field: Other Traffic Action Field (see Section 11) bits unused in this specification. These bits MUST be set to 0 on encoding and MUST be ignored during decoding.
トラフィックアクションフィールド：その他のトラフィックアクションフィールド（セクション11を参照）この仕様では使用されていないビット。これらのビットはエンコード時に0に設定されなければならず、復号化中に無視される必要があります。
The use of the Terminal Action (bit 47) may result in more than one Flow Specification matching a particular traffic flow. All the Traffic Filtering Actions from these Flow Specifications shall be collected and applied. In case of interfering Traffic Filtering Actions, it is an implementation decision which Traffic Filtering Actions are selected. See also Section 7.7.
端末動作（ビット47）の使用は、特定のトラフィックフローを一致させる複数のフロー仕様をもたらし得る。これらのフロー仕様からのすべてのトラフィックフィルタリングアクションを収集して適用するものとします。トラフィックフィルタリングアクションを干渉する場合は、トラフィックフィルタリングアクションが選択される実装決定です。セクション7.7も参照してください。
Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document.
このドキュメントでは、次のBGPフロー仕様のトラフィックフィルタリングアクションを妨げます。
The redirect Extended Community allows the traffic to be redirected to a VRF routing instance that lists the specified route-target in its import policy. If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected).
リダイレクト拡張コミュニティにより、トラフィックをインポートポリシーに指定したルート対象をリストしたVRFルーティングインスタンスにリダイレクトできます。いくつかのローカルインスタンスがこの基準と一致する場合、それらの間の選択は地域的な問題です（たとえば、経路が最も低いインスタンスは選択されます）。
This Extended Community allows 3 different encodings formats for the route-target (type 0x80, 0x81, 0x82). It uses the same encoding as the Route Target Extended Community in Sections 3.1 (type 0x80: 2-octet AS, 4-octet value), 3.2 (type 0x81: 4-octet IPv4 address, 2-octet value), and 4 of [RFC4360] and Section 2 of [RFC5668] (type 0x82: 4-octet AS, 2-octet value) with the high-order octet of the Type field 0x80, 0x81, 0x82 respectively and the low-order octet of the Type field (Sub-Type) always 0x08.
この拡張コミュニティは、ルートターゲットのための3つの異なるエンコーディングフォーマットを許可します（タイプ0x80、0x81,0x82）。セクション3.1（Type 0x80：2 - オクテット、4オクテット値）、3.2（タイプ0x81：4オクテットIPv4アドレス、2オクテット値、2オクテット値、2オクテット値、2オクテット値、2オクテット値）、および4のRoute Target Extendedコミュニティと同じエンコードを使用します。[RFC5668]（RFC5668]（RFC5668]（RFC5668]のセクション2（AX82：4オクテットとして、2オクテット値とタイプ、2オクテット値）は、それぞれタイプフィールド0x80、0x81,0x82の高次オクテットとTypeフィールドの下位オクテット（サブタイプ）常に0x08。
Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document.
このドキュメントでは、次のBGPフロー仕様のトラフィックフィルタリングアクションを妨げます。
The traffic marking Extended Community instructs a system to modify the DSCP bits in the IP header (Section 3 of [RFC2474]) of a transiting IP packet to the corresponding value encoded in the 6 least significant bits of the Extended Community value, as shown in Figure 6.
トラフィックマーキング拡張コミュニティは、IPヘッダのDSCPビット（IPヘッダの[RFC2474]のセクション3）のDSCPビットを、次のように拡張コミュニティ値の6つの最下位ビットでエンコードされた対応する値に変更するように指示します。図6
The Extended Community is encoded as follows:
拡張コミュニティは次のようにエンコードされています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | reserved | reserved | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | r.| DSCP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Traffic Marking Extended Community Encoding
図6：トラフィックマーキング拡張コミュニティエンコーディング
DSCP: new DSCP value for the transiting IP packet
DSCP：トランジスタIPパケットの新しいDSCP値
reserved (r): MUST be set to 0 on encoding and MUST be ignored during decoding
予約済み（R）：エンコード時に0に設定する必要があり、デコード中に無視する必要があります。
Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document.
このドキュメントでは、次のBGPフロー仕様のトラフィックフィルタリングアクションを妨げます。
Implementations should provide mechanisms that map an arbitrary BGP community value (normal or extended) to Traffic Filtering Actions that require different mappings on different systems in the network. For instance, providing packets with a worse-than-best-effort per-hop behavior is a functionality that is likely to be implemented differently in different systems and for which no standard behavior is currently known. Rather than attempting to define it here, this can be accomplished by mapping a user-defined community value to platform-/network-specific behavior via user configuration.
実装は、ネットワーク内の異なるシステムで異なるマッピングを必要とするトラフィックフィルタリングアクションに任意のBGPコミュニティ値（通常または拡張）をマッピングするメカニズムを提供する必要があります。たとえば、ホップごとの範囲で、最悪の労力ごとの動作を持つパケットを提供することは、さまざまなシステムでは異なる方法で実装される可能性があり、標準的な動作が現在知られていない機能です。ここで定義しようとするのではなく、これはユーザー定義のコミュニティ値をユーザー構成を介してプラットフォーム/ネットワーク固有の動作にマッピングすることによって実行できます。
Since Traffic Filtering Actions are represented as BGP extended community values, Traffic Filtering Actions may interfere with each other (e.g., there may be more than one conflicting traffic-rate-bytes Traffic Filtering Action associated with a single Flow Specification). Traffic Filtering Action interference has no impact on BGP propagation of Flow Specifications (all communities are propagated according to policies).
トラフィックフィルタリングアクションはBGP拡張コミュニティ値として表されるので、トラフィックフィルタリング動作は互いに干渉する可能性がある（例えば、単一のフロー仕様に関連する1つ以上の競合するトラフィックレートバイトトラフィックフィルタリング動作がある場合がある）。トラフィックフィルタリングアクション干渉は、フロー仕様のBGP伝播に影響を与えません（すべてのコミュニティはポリシーに従って伝播されます）。
If a Flow Specification associated with interfering Traffic Filtering Actions is selected for packet forwarding, it is an implementation decision which of the interfering Traffic Filtering Actions are selected. Implementors of this specification SHOULD document the behavior of their implementation in such cases.
干渉するトラフィックフィルタリングアクションに関連するフロー指定がパケット転送のために選択された場合、それは干渉するトラフィックフィルタリング動作のうちのどの実装決定である。この仕様書の実装者は、そのような場合の実装の動作を文書化する必要があります。
Operators are encouraged to make use of the BGP policy framework supported by their implementation in order to achieve a predictable behavior. See also Section 12.
演算子は、予測可能な動作を達成するためにそれらの実装によってサポートされているBGPポリシーフレームワークを利用することを奨励されます。セクション12も参照してください。
Provider-based Layer 3 VPN networks, such as the ones using a BGP/ MPLS IP VPN [RFC4364] control plane, may have different traffic filtering requirements than Internet service providers. But also Internet service providers may use those VPNs for scenarios like having the Internet routing table in a VRF, resulting in the same traffic filtering requirements as defined for the global routing table environment within this document. This document defines an additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used to propagate Flow Specification in a BGP/MPLS VPN environment.
プロバイダベースのレイヤ3 BGP / MPLS IP VPN [RFC4364]コントロールプレーンを使用するものなどのVPNネットワークは、インターネットサービスプロバイダーとは異なるトラフィックフィルタリング要件を持つことがあります。しかし、インターネットサービスプロバイダは、インターネットルーティングテーブルをVRFに持っているようなシナリオにこれらのVPNを使用し、この文書内のグローバルルーティングテーブル環境と同じトラフィックフィルタリング要件をもたらすことがあります。このドキュメントでは、BGP / MPLS VPN環境でフロー仕様を伝播するために使用できる追加のBGP NLRIタイプ（AFI = 1、SAFI = 134）値を定義します。
The NLRI format for this address family consists of a fixed-length Route Distinguisher field (8 octets) followed by the Flow Specification NLRI value (Section 4.2). The NLRI length field shall include both the 8 octets of the Route Distinguisher as well as the subsequent Flow Specification NLRI value. The resulting encoding is shown in Figure 7.
このアドレスファミリのNLRIフォーマットは、固定長ルート識別監理誤差フィールド（8オクテット）とそれに続くフロー仕様NLRI値（セクション4.2）で構成されています。NLRI長フィールドには、ルート識別器の8オクテット、ならびに後続のフロー仕様NLRI値が含まれていなければならない。結果の符号化を図7に示す。
+--------------------------------+
| length (0xnn or 0xfnnn) |
+--------------------------------+
| Route Distinguisher (8 octets) |
+--------------------------------+
| NLRI value (variable) |
+--------------------------------+
Figure 7: Flow Specification NLRI for MPLS
図7：MPLSのフロー仕様NLRI
Propagation of this NLRI is controlled by matching Route Target extended communities associated with the BGP path advertisement with the VRF import policy, using the same mechanism as described in BGP/ MPLS IP VPNs [RFC4364].
このNLRIの伝播は、BGP / MPLS IP VPNS [RFC4364]で説明されているのと同じメカニズムを使用して、BGPパス広告に関連するルートターゲット拡張コミュニティをVRFインポートポリシーと一致させることによって制御されます。
Flow Specifications received via this NLRI apply only to traffic that belongs to the VRF(s) in which it is imported. By default, traffic received from a remote PE is switched via an MPLS forwarding decision and is not subject to filtering.
このNLRI経由で受信されたフロー仕様は、インポートされているVRFに属するトラフィックにのみ適用されます。デフォルトでは、リモートPEから受信したトラフィックはMPLS転送決定を介して切り替えられ、フィルタリングの影響を受けません。
Contrary to the behavior specified for the non-VPN NLRI, Flow Specifications are accepted by default, when received from remote PE routers.
非VPN NLRIに指定された動作とは反対に、フロー仕様は、リモートPEルータから受信されたときにデフォルトで受け入れられます。
The validation procedure (Section 6) and Traffic Filtering Actions (Section 7) are the same as for IPv4.
検証手順（セクション6）およびトラフィックフィルタリング動作（セクション7）はIPv4と同じです。
Traffic filtering applications require monitoring and traffic statistics facilities. While this is an implementation specific choice, implementations SHOULD provide:
トラフィックフィルタリングアプリケーションでは、監視統計施設と交通統計施設が必要です。これは実装固有の選択ですが、実装は次のとおりです。
* A mechanism to log the packet header of filtered traffic.
* フィルタリングされたトラフィックのパケットヘッダーを記録するためのメカニズム。
* A mechanism to count the number of matches for a given Flow Specification rule.
* 特定のフロー仕様規則の一致数をカウントするメカニズム。
Error handling according to [RFC7606] and [RFC4760] applies to this specification.
[RFC7606]と[RFC4760]に従ってエラー処理が適用されます。
This document introduces Traffic Filtering Action Extended Communities. Malformed Traffic Filtering Action Extended Communities in the sense of Section 7.14 of [RFC7606] are Extended Community values that cannot be decoded according to Section 7 of this document.
この文書はトラフィックフィルタリングアクション拡張コミュニティを紹介します。不正なトラフィックフィルタリングアクション[RFC7606]のセクション7.14のセンス内の拡張コミュニティは、このドキュメントのセクション7に従って復号できないコミュニティ値を拡張します。
This section complies with [RFC7153].
このセクションは[RFC7153]に準拠しています。
IANA maintains a registry entitled "SAFI Values". For the purpose of this work, IANA has updated the following SAFIs as shown in the table below. (Note: This document obsoletes both [RFC7674] and [RFC5575], and all references to those documents have been deleted from the registry.)
IANAは「SAFI値」と題されたレジストリを管理しています。この作業の目的のために、IANAは以下の表のように次のSAFISを更新しました。（注：この文書は[RFC7674]と[RFC5575]の両方を廃止され、それらの文書への参照はすべてレジストリから削除されました。）
+=======+===========================================+===========+
| Value | Name | Reference |
+=======+===========================================+===========+
| 133 | Dissemination of Flow Specification rules | RFC 8955 |
+-------+-------------------------------------------+-----------+
| 134 | L3VPN Dissemination of Flow Specification | RFC 8955 |
| | rules | |
+-------+-------------------------------------------+-----------+
Table 9: Registry: SAFI Values
表9：レジストリ：SAFI値
The above textual changes generalize the definition of the SAFIs rather than change its underlying meaning. Therefore, based on "The YANG 1.1 Data Modeling Language" [RFC7950], the above text means that the following YANG enums from "Common YANG Data Types for the Routing Area" [RFC8294] have had their names and descriptions at <https://www.iana.org/assignments/iana-routing-types> changed to:
上記の説明文は、その根底にある意味を変更するのではなく、Safisの定義を一般化します。したがって、「Yang 1.1データモデリング言語」[RFC7950]に基づいて、上記のテキストは、<https：/での「共通ヤングデータ型」からの次のYang inmがその名前と説明を持っていたことを意味します。/ww.iana.org/ashignments/iana-routing-types>に変更されました：
<CODE BEGINS>
enum flow-spec-safi {
value 133;
description
"Dissemination of Flow Specification rules SAFI.";
}
enum l3vpn-flow-spec-safi {
value 134;
description
"L3VPN Dissemination of Flow Specification rules SAFI.";
}
<CODE ENDS>
A new revision statement has been added to the module as follows:
次のように新しいRevisionステートメントがモジュールに追加されました。
<CODE BEGINS>
revision 2020-12-31 {
description "Non-backwards-compatible change of SAFI names
(SAFI values 133, 134).";
reference
"RFC 8955: Dissemination of Flow Specification Rules.";
}
<CODE ENDS>
A Flow Specification consists of a sequence of flow components, which are identified by an 8-bit component type. IANA has created and maintains a registry entitled "Flow Spec Component Types". IANA has updated the reference for this registry to RFC 8955. Furthermore, the references to the values have been updated according to the table below (Note: This document obsoletes both [RFC7674] and [RFC5575], and all references to those documents have been deleted from the registry.)
フロー仕様は、8ビットのコンポーネントタイプによって識別される一連のフローコンポーネントで構成されています。IANAは「Flow Spec Component Types」と題されたレジストリを作成して管理しています。IANAはこのレジストリの参照をRFC 8955に更新しました。さらに、値への参照は以下の表に従って更新されました（注：このドキュメントは[RFC7674]と[RFC5575]の両方で、それらの文書へのすべての参照がされています。レジストリから削除されました。）
+=======+====================+===========+
| Value | Name | Reference |
+=======+====================+===========+
| 1 | Destination Prefix | RFC 8955 |
+-------+--------------------+-----------+
| 2 | Source Prefix | RFC 8955 |
+-------+--------------------+-----------+
| 3 | IP Protocol | RFC 8955 |
+-------+--------------------+-----------+
| 4 | Port | RFC 8955 |
+-------+--------------------+-----------+
| 5 | Destination port | RFC 8955 |
+-------+--------------------+-----------+
| 6 | Source port | RFC 8955 |
+-------+--------------------+-----------+
| 7 | ICMP type | RFC 8955 |
+-------+--------------------+-----------+
| 8 | ICMP code | RFC 8955 |
+-------+--------------------+-----------+
| 9 | TCP flags | RFC 8955 |
+-------+--------------------+-----------+
| 10 | Packet length | RFC 8955 |
+-------+--------------------+-----------+
| 11 | DSCP | RFC 8955 |
+-------+--------------------+-----------+
| 12 | Fragment | RFC 8955 |
+-------+--------------------+-----------+
Table 10: Registry: Flow Spec Component Types
表10：レジストリ：フロー仕様の種類の種類
In order to manage the limited number space and accommodate several usages, the following policies defined by [RFC8126] are used:
限られた数のスペースを管理し、いくつかの用途に対応するために、[RFC8126]で定義されている次のポリシーが使用されます。
+==============+========================+
| Type Values | Policy |
+==============+========================+
| 0 | Reserved |
+--------------+------------------------+
| [1 .. 127] | Specification Required |
+--------------+------------------------+
| [128 .. 254] | Expert Review |
+--------------+------------------------+
| 255 | Reserved |
+--------------+------------------------+
Table 11: Flow Spec Component Types Policies
表11：Flow Specコンポーネント型ポリシー
Guidance for Experts: The registration policy for the range 128-254 is Expert Review. The experts are expected to check the clarity of purpose and use of the requested code points. The experts must also verify that any specification produced in the IETF that requests one of these code points has been made available for review by the IDR Working Group and that any specification produced outside the IETF does not conflict with work that is active or already published within the IETF. It must be pointed out that introducing new component types may break interoperability with existing implementations of this protocol.
専門家のためのガイダンス：128-254の範囲の登録方針はエキスパートレビューです。専門家たちは、要求されたコードポイントの目的と使用の明確さを確認することが期待されています。専門家はまた、ITFで作成されたいずれかのコードポイントをIDRワーキンググループによるレビューのために要求し、IETFの外で生成された仕様はアクティブなまたはすでに公開されている作業と競合しないことを確認する必要があります。IETF。新しいコンポーネントタイプを導入することは、このプロトコルの既存の実装と相互運用性を破る可能性があることを指摘する必要があります。
The Extended Community Flow Specification Action types defined in this document consist of two parts:
このドキュメントで定義されている拡張コミュニティフロー仕様アクションタイプは、2つの部分で構成されています。
* Type (BGP Transitive Extended Community Type)
* タイプ（BGP推移的拡張コミュニティタイプ）
* Sub-Type
* サブタイプ
For the type part, IANA maintains a registry entitled "BGP Transitive Extended Community Types". For the purpose of this work (Section 7), IANA has updated the references as shown in the table below. (Note: This document obsoletes both [RFC7674] and [RFC5575], and all references to those documents have been deleted in the registry.)
タイプ部品の場合、IANAは「BGP推移的拡張コミュニティタイプ」と題されたレジストリを管理しています。この作品の目的のために（セクション7）、IANAは以下の表のように参照を更新しました。（注：この文書ではRFC7674]と[RFC5575]の両方が廃止され、これらの文書への参照はすべてレジストリで削除されました。）
+=======+=======================================+===========+
| Type | Name | Reference |
| Value | | |
+=======+=======================================+===========+
| 0x81 | Generic Transitive Experimental Use | RFC 8955 |
| | Extended Community Part 2 (Sub-Types | |
| | are defined in the "Generic | |
| | Transitive Experimental Use Extended | |
| | Community Part 2 Sub-Types" Registry) | |
+-------+---------------------------------------+-----------+
| 0x82 | Generic Transitive Experimental Use | RFC 8955 |
| | Extended Community Part 3 (Sub-Types | |
| | are defined in the "Generic | |
| | Transitive Experimental Use Extended | |
| | Community Part 3 Sub-Types" Registry) | |
+-------+---------------------------------------+-----------+
Table 12: Registry: BGP Transitive Extended Community Types
表12：レジストリ：BGP推移的拡張コミュニティタイプ
For the sub-type part of the Extended Community Traffic Filtering Actions, IANA maintains the following registries. IANA has updated all names and references according to the tables below and assign a new value for the "Flow spec traffic-rate-packets" Sub-Type. (Note: This document obsoletes both [RFC7674] and [RFC5575], and all references to those documents have been deleted from the registries below.)
拡張コミュニティトラフィックフィルタリングアクションのサブタイプの部分については、IANAは次のレジストリを管理します。IANAは以下の表に従ってすべての名前と参照を更新し、「フロースペックトラフィックレートパケット」サブタイプに新しい値を割り当てました。（注：この文書は[RFC7674]と[RFC5575]の両方では、以下のレジストリから削除されました。）
+==========+=====================================+===========+
| Sub-Type | Name | Reference |
| Value | | |
+==========+=====================================+===========+
| 0x06 | Flow spec traffic-rate-bytes | RFC 8955 |
+----------+-------------------------------------+-----------+
| 0x0c | Flow spec traffic-rate-packets | RFC 8955 |
+----------+-------------------------------------+-----------+
| 0x07 | Flow spec traffic-action (Use of | RFC 8955 |
| | the "Value" field is defined in the | |
| | "Traffic Action Fields" registry) | |
+----------+-------------------------------------+-----------+
| 0x08 | Flow spec rt-redirect AS-2octet | RFC 8955 |
| | format | |
+----------+-------------------------------------+-----------+
| 0x09 | Flow spec traffic-remarking | RFC 8955 |
+----------+-------------------------------------+-----------+
Table 13: Registry: Generic Transitive Experimental Use Extended Community Sub- Types
表13：レジストリ：一般的な推移的実験的Extended Community Sub型を使用する
+================+===================================+===========+
| Sub-Type Value | Name | Reference |
+================+===================================+===========+
| 0x08 | Flow spec rt-redirect IPv4 format | RFC 8955 |
+----------------+-----------------------------------+-----------+
Table 14: Registry: Generic Transitive Experimental Use Extended Community Part 2 Sub-Types
表14：レジストリ：一般的な推移的実験的使用拡張コミュニティPart 2サブタイプ
+================+=======================+===========+
| Sub-Type Value | Name | Reference |
+================+=======================+===========+
| 0x08 | Flow spec rt-redirect | RFC 8955 |
| | AS-4octet format | |
+----------------+-----------------------+-----------+
Table 15: Registry: Generic Transitive Experimental Use Extended Community Part 3 Sub-Types
表15：レジストリ：一般的な推移的実験的使用拡張コミュニティ第3部のサブタイプ
Furthermore, IANA has updated the reference for the registries "Generic Transitive Experimental Use Extended Community Part 2 Sub-Types" and "Generic Transitive Experimental Use Extended Community Part 3 Sub-Types" to RFC 8955.
さらに、IANAは、「汎用推移的実験用拡張コミュニティ第2部サブタイプ」および「一般的な推移的実験的使用拡張コミュニティ第3部サブタイプ」をRFC 8955に更新した。
The "traffic-action" Extended Community (Section 7.3) defined in this document has 46 unused bits, which can be used to convey additional meaning. IANA created and maintains a registry entitled "Traffic Action Fields". IANA has updated the reference for this registry to RFC 8955. Furthermore, IANA has updated the references according to the table below. These values should be assigned via IETF Review rules only. (Note: This document obsoletes both [RFC7674] and [RFC5575], and all references to those documents have been deleted from the registry.)
この文書で定義されている「Traffic-Action」Extended Community（セクション7.3）は、46個の未使用のビットを持っています。これは、追加の意味を伝えるために使用できます。IANAは「トラフィックアクションフィールド」と題されたレジストリを作成して管理します。IANAはこのレジストリの参照をRFC 8955に更新しました。さらに、IANAは以下の表に従って参照を更新しました。これらの値は、IETFレビュールールを介してのみ割り当てる必要があります。（注：この文書は[RFC7674]と[RFC5575]の両方を廃止され、それらの文書への参照はすべてレジストリから削除されました。）
+=====+=================+===========+
| Bit | Name | Reference |
+=====+=================+===========+
| 47 | Terminal Action | RFC 8955 |
+-----+-----------------+-----------+
| 46 | Sample | RFC 8955 |
+-----+-----------------+-----------+
Table 16: Registry: Traffic Action Fields
表16：レジストリ：トラフィックアクションフィールド
As long as Flow Specifications are restricted to match the corresponding unicast routing paths for the relevant prefixes (Section 6), the security characteristics of this proposal are equivalent to the existing security properties of BGP unicast routing. Any relaxation of the validation procedure described in Section 6 may allow unwanted Flow Specifications to be propagated, and thus unwanted Traffic Filtering Actions may be applied to flows.
フロー仕様が関連するプレフィックスの対応するユニキャストルーティングパスに一致するように制限されている限り（セクション6）、この提案のセキュリティ特性はBGPユニキャストルーティングの既存のセキュリティプロパティと同等です。セクション6に記載されている検証手順の緩和は、不要なフロー仕様を伝播させることができ、したがって不要なトラフィックフィルタリング動作をフローに適用することができる。
Where the above mechanisms are not in place, this could open the door to further denial-of-service attacks, such as unwanted traffic filtering, remarking, or redirection.
上記のメカニズムが整っていない場合、これは望ましくないトラフィックフィルタリング、リダイレクション、またはリダイレクトなど、サービス拒否攻撃の扉を開くことができます。
Deployment of specific relaxations of the validation within an administrative boundary of a network are useful in some networks for quickly distributing filters to prevent denial-of-service attacks. For a network to utilize this relaxation, the BGP policies must support additional filtering since the origin AS field is empty. Specifications relaxing the validation restrictions MUST contain security considerations that provide details on the required additional filtering. For example, the use of origin validation can provide enhanced filtering within an AS confederation.
ネットワークの管理境界内での検証の特定の緩和の展開は、サービス拒否攻撃を防ぐためにフィルタを迅速に配信するためのいくつかのネットワークにおいて役立ちます。ネットワークがこのリラクションを利用するために、Field Asフィールドが空のため、BGPポリシーは追加のフィルタリングをサポートしている必要があります。仕様検証制限には、必要な追加のフィルタリングに関する詳細を提供するセキュリティ上の考慮事項が含まれている必要があります。たとえば、原点検証を使用すると、ASコンフェデレーション内で拡張されたフィルタリングを提供できます。
Inter-provider routing is based on a web of trust. Neighboring autonomous systems are trusted to advertise valid reachability information. If this trust model is violated, a neighboring autonomous system may cause a denial-of-service attack by advertising reachability information for a given prefix for which it does not provide service (unfiltered address space hijack). Since validation of the Flow Specification is tied to the announcement of the best unicast route, the failure in the validation of best path route may prevent the Flow Specification from being used by a local router. Possible mitigations are [RFC6811] and [RFC8205].
プロバイダ間ルーティングは信頼のWebに基づいています。隣接する自律システムは、有効な到達可能性情報を宣伝すると信頼されています。この信頼モデルが侵害された場合、隣接する自律システムは、サービスを提供していない特定のプレフィックスの到達可能性情報を広告することによってサービス拒否攻撃を引き起こす可能性があります（フィルタされていないアドレススペースHijack）。フロー仕様の検証は最高のユニキャストルートのアナウンスに関連付けられているので、最良パス経路の検証の失敗は、フロー仕様がローカルルータによって使用されるのを妨げる可能性があります。可能な緩和は[RFC6811]と[RFC8205]です。
On Internet Exchange Points (IXPs), routes are often exchanged via route servers that do not extend the AS_PATH. In such cases, it is not possible to enforce the left-most AS in the AS_PATH to be the neighbor AS (the AS of the route server). Since the validation of Flow Specification (Section 6) depends on this, additional care must be taken. It is advised to use a strict inbound route policy in such scenarios.
インターネット交換ポイント（IXPS）では、RoutesはAS_PATHを拡張しないルートサーバーを介して交換されます。そのような場合、as_PATHのように左端を囲むことは不可能です（ルートサーバーのAS）。フロー仕様の検証（セクション6）はこれに依存するため、追加の注意を払う必要があります。そのようなシナリオで厳密なインバウンドルートポリシーを使用することをお勧めします。
Enabling firewall-like capabilities in routers without centralized management could make certain failures harder to diagnose. For example, it is possible to allow TCP packets to pass between a pair of addresses but not ICMP packets. It is also possible to permit packets smaller than 900 or greater than 1000 octets to pass between a pair of addresses but not packets whose length is in the range 900-1000. Such behavior may be confusing, and these capabilities should be used with care whether manually configured or coordinated through the protocol extensions described in this document.
集中管理なしのルータでファイアウォールのような機能を有効にすると、診断に困難な障害が発生する可能性があります。例えば、TCPパケットが一対のアドレス間を通過させることを可能にすることが可能であるが、ICMPパケットを渡すことを可能にすることが可能である。900以上のパケットを、1000オクテットを超えるか、1000オクテットを超えるが、長さが900~1000の範囲内にあるパケットは一対のアドレスを通過させることもできない。そのような動作は混乱している可能性があり、この文書で説明されているプロトコル拡張機能を手動で構成または調整したかどうかを注意して使用する必要があります。
Flow Specification BGP speakers (e.g., automated DDoS controllers) not properly programmed, algorithms that are not performing as expected, or simply rogue systems may announce unintended Flow Specifications, send updates at a high rate, or generate a high number of Flow Specifications. This may stress the receiving systems, exceed their capacity, or lead to unwanted Traffic Filtering Actions being applied to flows.
フロー仕様BGPスピーカ（例えば、自動DDOSコントローラ）が正しくプログラムされていない、または単に不正なシステムではないアルゴリズム、または単に不正なシステムは、意図しないフロー仕様を発表し、高速で更新を送信するか、または多数のフロー仕様を生成することができます。これは受信システムを強調し、それらの容量を超えているか、または流れに適用されている不要なトラフィックフィルタリング動作をもたらす可能性があります。
Systems may not be able to locate all header values required to identify a packet. This can be especially problematic in the case of fragmented packets that are not the first fragment and thus lack upper-layer protocol headers or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption.
システムは、パケットを識別するために必要なすべてのヘッダー値を見つけることができない可能性があります。これは、最初のフラグメントではなく、したがって上位層プロトコルヘッダーを欠く、またはセキュリティペイロード（ESP）NULL [RFC4303]の暗号化を不足している場合に特に問題がある可能性があります。
While the general verification of the Flow Specification NLRI is specified in this document (Section 6), the Traffic Filtering Actions received by a third party may need custom verification or filtering. In particular, all non-traffic-rate actions may allow a third party to modify packet forwarding properties and potentially gain access to other routing-tables/VPNs or undesired queues. This can be avoided by proper filtering/screening of the Traffic Filtering Action communities at network borders and only exposing a predefined subset of Traffic Filtering Actions (see Section 7) to third parties. One way to achieve this is by mapping user-defined communities, which can be set by the third party, to Traffic Filtering Actions and not accepting Traffic Filtering Action extended communities from third parties.
フロー仕様NLRIの一般的な検証がこの文書で指定されている間（セクション6）、第三者によって受信されたトラフィックフィルタリングアクションは、カスタム検証またはフィルタリングが必要になる場合があります。特に、トラフィックの非レートアクションはすべて、サードパーティがパケット転送プロパティを変更し、他のルーティングテーブル/ VPNまたは望ましくないキューへのアクセスを可能にします。これは、ネットワークボーダーでのトラフィックフィルタリングアクションコミュニティの適切なフィルタリング/スクリーニングによって、そして第三者へのトラフィックフィルタリングアクションの定義済みサブセットを公開するだけでは回避できます。これを達成する1つの方法は、第三者によって設定されることができるユーザー定義のコミュニティをトラフィックフィルタリングの行動にマッピングし、第三者からのトラフィックフィルタリングアクションの拡張コミュニティを受け入れないことです。
This extension adds additional information to Internet routers. These are limited in terms of the maximum number of data elements they can hold as well as the number of events they are able to process in a given unit of time. Service providers need to consider the maximum capacity of their devices and may need to limit the number of Flow Specifications accepted and processed.
この拡張子はインターネットルータに追加情報を追加します。これらは、それらが保持できるデータ要素の最大数、ならびにそれらが所与の時間内に処理することができるイベントの数に関して制限されている。サービスプロバイダーは、それらのデバイスの最大容量を考慮する必要があり、受け入れられ処理されたフロー仕様の数を制限する必要があるかもしれません。
[IEEE.754.1985] IEEE, "Standard for Binary Floating-Point Arithmetic", IEEE 754-1985, DOI 10.1109/IEEESTD.2019.8766229, August 1985, <https://doi.org/10.1109/IEEESTD.2019.8766229>.
[IEEE.754.1985] IEEE、「バイナリ浮動小数点演算のための標準」、IEEE 754-1985、DOI 10.1109 / IEEESTD.2019.8766229、<https：//doi.org/10.1109/ieeeestd.2019.876629>。
[ISO_IEC_9899] ISO, "Information technology -- Programming languages -- C", ISO/IEC 9899:2018, June 2018.
[ISO_IEC_9899] ISO、「情報技術 - プログラミング言語 - C」、ISO / IEC 9899：2018、2018年6月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC0768] Postel、J.、 "User Datagram Protocol"、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791] Postel、J.、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0792] Postel、J.、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https：//www.rfc-editor.org/info/rfc792>。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F.、およびD.黒、「IPv4およびIPv6ヘッダーのDSフィールドの定義」、RFC 2474、DOI 10.17487 / RFC2474、1998年12月、<https：//www.rfc-editor.org/info/rfc2474>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<https://www.rfc-editor.org/info/rfc4271>。
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4360] Sangli、S.、Tappan、D.、およびY.Rekhter、「BGP Extended Communities属性」、RFC 4360、DOI 10.17487 / RFC4360、2006年2月、<https：//www.rfc-editor.org/info/ RFC4360>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E.およびY.Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPNS）"、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https：//www.rfc-editor.org/info/ RFC4364>。
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <https://www.rfc-editor.org/info/rfc4456>.
[RFC4456] Bates、T.、Chen、E.、R.Chandra、「BGPルート反射：フルメッシュ内部BGP（IBGP）」、RFC 4456、DOI 10.17487 / RFC4456、<https：//www.rfc-editor.org/info/rfc4456>。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4760]ベイツ、T.、Chandra、R.、Katz、D.、およびY.Rekhter、「BGP-4」、RFC 4760、DOI 10.17487 / RFC4760、2007年1月、<https：// www。rfc-editor.org/info/rfc4760>。
[RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS Specific BGP Extended Community", RFC 5668, DOI 10.17487/RFC5668, October 2009, <https://www.rfc-editor.org/info/rfc5668>.
[RFC5668] Rekhter、Y.、Sangli、S.、およびD. Tappan、「4-オクテットとしての特別BGP Extended Community」、RFC 5668、DOI 10.17487 / RFC5668、2009年10月、<https：//www.rfc-編集者.org / info / rfc5668>。
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <https://www.rfc-editor.org/info/rfc7153>.
[RFC7153] Rosen、E.およびY.Rekhter、RFC 7153、DOI 10.17487 / RFC7153、2014年3月、<https://www.rfc-editor.org/info/rfc7153>。
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.
[RFC7606] Chen、E.、Ed。、Scudder、J.、Ed。、Mohapatra、P.、およびK。Patel、「BGP更新メッセージの修正エラー処理」、RFC 7606、DOI 10.17487 / RFC7606、2015年8月、<https://www.rfc-editor.org/info/rfc7606>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<https：//www.rfc-editor.org/info/rfc4303>。
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, <https://www.rfc-editor.org/info/rfc5575>.
[RFC5575] Marques、P.、Sheth、N.、Raszuk、R.、Greene、B.、Mauch、J.、およびD. McPherson、「フロー仕様規則の普及」、RFC 5575、DOI 10.17487 / RFC5575、8月2009年、<https://www.rfc-editor.org/info/rfc5575>。
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.
[RFC6811] Mohapatra、P.、Scudder、J.、Ward、D.、Bush、R.、およびR.Austein、RFC 6811、DOI 10.17487 / RFC6811、2013年1月、<https：//ww.rfc-editor.org/info/rfc6811>。
[RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect Extended Community", RFC 7674, DOI 10.17487/RFC7674, October 2015, <https://www.rfc-editor.org/info/rfc7674>.
[RFC7674] HAAS、J.、ED。、「フローペックリダイレクトコミュニティの説明」、RFC 7674、DOI 10.17487 / RFC7674、2015年10月、<https://www.rfc-editor.org/info/rfc7674>。
[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>.
[RFC7950] Bjorklund、M.、ED。、「Yang 1.1データモデリング言語」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.
[RFC8205] Lepinski、M.、ED。そして、K。SRIRAM、ED。、「BGPSECプロトコル仕様」、RFC 8205、DOI 10.17487 / RFC8205、2017年9月、<https：//www.rfc-editor.org/info/rfc8205>。
[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>.
[RFC8294] Liu、X.、Qu、Y、Y、Lindem、A.、Hopps、C.、およびL. Berger、「ルーティングエリアのための一般的なヤンデータ型」、RFC 8294、DOI 10.17487 / RFC8294、2017年12月、<https://www.rfc-editor.org/info/rfc8294>。
[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>.
[RFC8956] LOIBL、C、ED。、RASZUK、R.、ED。、およびS.HARES、ED。、「IPv6のフロー仕様規則の普及」、RFC 8956、DOI 10.17487 / RFC8956、2020年12月、<HTTPS：//www.rfc-editor.org/info/rfc8956>。
Appendix A. Example Python code: flow_rule_cmp
付録A. Pythonコードの例：flow_rule_cmp.
<CODE BEGINS> """ Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved.
<コードが始まります> "" "" "" ""著作権（c）2020 IETFの信頼とコードの著者として識別された人。すべての権利予約。
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 Simplified 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). """
修正の有無にかかわらず、ソースおよびバイナリ形式での再配布と使用は、IETF文書に関連するIETF信託の法的規定のセクション4.Cに記載されている単純化されたBSDライセンスに従い、身に付けられたライセンス条項に従って許可されています（https://trustee.ietf.org/License-info）。"" ""
import itertools import collections import ipaddress
IterToolsのインポートコレクションのインポートipaddress.
EQUAL = 0 A_HAS_PRECEDENCE = 1 B_HAS_PRECEDENCE = 2 IP_DESTINATION = 1 IP_SOURCE = 2
等= 0 A_HAS_PRECENCENE = 1 B_HAS_PRECENCENE = 2 IP_DESTINATION = 1 IP_SOURCE = 2
FS_component = collections.namedtuple('FS_component', 'component_type op_value')
fs_component = collections.namedTuple（ 'fs_component'、 'component_type op_value'）
class FS_nlri(object): """ FS_nlri class implementation that allows sorting.
クラスFS_NLRI（Object）： "" ""ソートを可能にするFS_NLRIクラスの実装。
By calling .sort() on an array of FS_nlri objects these will be sorted according to the flow_rule_cmp algorithm.
fs_nlriオブジェクトの配列で.sort（）を呼び出すことによって、これらはflow_rule_cmpアルゴリズムに従ってソートされます。
Example:
nlri = [ FS_nlri(components=[
FS_component(component_type=IP_DESTINATION,
op_value=ipaddress.ip_network('10.1.0.0/16') ),
FS_component(component_type=4,
op_value=bytearray([0,1,2,3,4,5,6])),
]),
FS_nlri(components=[
FS_component(component_type=5,
op_value=bytearray([0,1,2,3,4,5,6])),
FS_component(component_type=6,
op_value=bytearray([0,1,2,3,4,5,6])),
]),
]
nlri.sort() # sorts the array according to the algorithm
"""
def __init__(self, components = None):
"""
components: list of type FS_component
"""
self.components = components
def __lt__(self, other):
# use the below algorithm for sorting
result = flow_rule_cmp(self, other)
if result == B_HAS_PRECEDENCE:
return True
else:
return False
def flow_rule_cmp(a, b):
"""
Example of the flowspec comparison algorithm.
"""
for comp_a, comp_b in itertools.zip_longest(a.components,
b.components):
# If a component type does not exist in one rule
# this rule has lower precedence
if not comp_a:
return B_HAS_PRECEDENCE
if not comp_b:
return A_HAS_PRECEDENCE
# Higher precedence for lower component type
if comp_a.component_type < comp_b.component_type:
return A_HAS_PRECEDENCE
if comp_a.component_type > comp_b.component_type:
return B_HAS_PRECEDENCE
# component types are equal -> type specific comparison
if comp_a.component_type in (IP_DESTINATION, IP_SOURCE):
# assuming comp_a.op_value, comp_b.op_value of
# type ipaddress.IPv4Network
if comp_a.op_value.overlaps(comp_b.op_value):
# longest prefixlen has precedence
if comp_a.op_value.prefixlen > \
comp_b.op_value.prefixlen:
return A_HAS_PRECEDENCE
if comp_a.op_value.prefixlen < \
comp_b.op_value.prefixlen:
return B_HAS_PRECEDENCE
# components equal -> continue with next component
elif comp_a.op_value > comp_b.op_value:
return B_HAS_PRECEDENCE
elif comp_a.op_value < comp_b.op_value:
return A_HAS_PRECEDENCE
else:
# assuming comp_a.op_value, comp_b.op_value of type
# bytearray
if len(comp_a.op_value) == len(comp_b.op_value):
if comp_a.op_value > comp_b.op_value:
return B_HAS_PRECEDENCE
if comp_a.op_value < comp_b.op_value:
return A_HAS_PRECEDENCE
# components equal -> continue with next component
else:
common = min(len(comp_a.op_value),
len(comp_b.op_value))
if comp_a.op_value[:common] > \
comp_b.op_value[:common]:
return B_HAS_PRECEDENCE
elif comp_a.op_value[:common] < \
comp_b.op_value[:common]:
return A_HAS_PRECEDENCE
# the first common bytes match
elif len(comp_a.op_value) > len(comp_b.op_value):
return A_HAS_PRECEDENCE
else:
return B_HAS_PRECEDENCE
return EQUAL
<CODE ENDS>
This document includes numerous editorial changes to [RFC5575]. It also completely incorporates the redirect action clarification document [RFC7674]. It is recommended to read the entire document. The authors, however, want to point out the following technical changes to [RFC5575]:
この文書には、[RFC5575]への多数の編集上の変更が含まれています。リダイレクト行動明確化文書[RFC7674]を完全に組み込んでいます。文書全体を読むことをお勧めします。ただし、作者は[RFC5575]の次の技術的な変更を指摘したいと考えています。
* Section 1 introduces the Flow Specification NLRI. In [RFC5575], BGP treats this NLRI as an opaque key to an entry in its databases. This specification has removed all references to an opaque key property. BGP implementations are able to understand the NLRI encoding.
* セクション1はフロー仕様NLRIを紹介します。[RFC5575]では、BGPはこのNLRIを不透明キーとしてデータベース内のエントリに扱います。この仕様は、不透明なキープロパティへの参照をすべて削除しました。BGP実装はNLRIエンコーディングを理解することができます。
* Section 4.2.1.1 defines a numeric operator and comparison bit combinations. In [RFC5575], the meaning of those bit combination was not explicitly defined and left open to the reader.
* セクション4.2.1.1は数値演算子と比較ビットの組み合わせを定義します。[RFC5575]では、それらのビットの組み合わせの意味は明示的に定義されず、読者に開かれていませんでした。
* Sections 4.2.2.3 - 4.2.2.8, 4.2.2.10, and 4.2.2.11 make use of the above numeric operator. The allowed length of the comparison value was not consistently defined in [RFC5575].
* セクション4.2.2.3 - 4.2.2.8,4.2.2.10、および4.2.2.11上記の数値演算子を使用してください。比較値の許容された長さは、[RFC5575]で一貫して定義されていませんでした。
* Section 7 defines all Traffic Filtering Action Extended Communities as transitive Extended Communities. [RFC5575] defined the traffic-rate action to be non-transitive and did not define the transitivity of the other Traffic Filtering Action communities at all.
* セクション7は、すべてのトラフィックフィルタリングアクション拡張コミュニティを推移的な拡張コミュニティとして定義します。[RFC5575]トラフィックレートの動作を非推移的であることを定義し、他のトラフィックフィルタリングアクションコミュニティの遷移性をまったく定義していませんでした。
* Section 7.2 introduces a new Traffic Filtering Action (traffic-rate-packets). This action did not exist in [RFC5575].
* セクション7.2では、新しいトラフィックフィルタリングアクション（トラフィックレートパケット）を紹介します。この動作は[RFC5575]には存在しませんでした。
* Section 7.4 contains the same redirect actions already defined in [RFC5575], however, these actions have been renamed to "rt-redirect" to make it clearer that the redirection is based on route-target. This section also completely incorporates the [RFC7674] clarifications of the Flowspec Redirect Extended Community.
* セクション7.4には、[RFC5575]で既に定義されているのと同じリダイレクトアクションが含まれていますが、これらのアクションはリダイレクトがルートターゲットに基づくことをより明確にするために "RT-Redirect"に変更されました。このセクションでは、Flowspecリダイレクト拡張コミュニティの[RFC7674]の説明も完全に組み込まれています。
* Section 7.7 contains general considerations on interfering traffic actions. Section 7.3 also cross-references Section 7.7. [RFC5575] did not mention this.
* 7.7項には、干渉トラフィックアクションに関する一般的な考慮事項が含まれています。セクション7.3も相互参照セクション7.7。[RFC5575]これに言及していませんでした。
* Section 10 contains new error handling.
* セクション10に新しいエラー処理が含まれています。
Acknowledgments
謝辞
The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris Morrow, Charlie Kaufman, and David Smith for their comments on the original [RFC5575]. Chaitanya Kodeboyina helped design the flow validation procedure, and Steven Lin and Jim Washburn ironed out all the details necessary to produce a working implementation in the original [RFC5575].
著者らは、Yakhov Rekhter、Dennis Ferguson、Chris Morrow、Charlie Kaufman、およびDavid Smithに、オリジナルの[RFC5575]のコメントに感謝します。Chaitanya KodeBoyinaは、フロー検証手順を設計し、Steven LinとJim Washburnを元の[RFC5575]に作業実装を作成するのに必要なすべての詳細を調べました。
A packet rate Traffic Filtering Action was also described in a Flow Specification extension draft and the authors would like to thank Wesley Eddy, Justin Dailey, and Gilbert Clark for their work.
パケットレートトラフィックフィルタリング動作もフロー仕様拡張ドラフトで記述され、著者はWesley Eddy、Justin Dailey、そしてGilbert Clarkに彼らの仕事のために感謝します。
Additionally, the authors would like to thank Alexander Mayrhofer, Nicolas Fevrier, Job Snijders, Jeffrey Haas, and Adam Chappell for their comments and review.
さらに、著者らは、Alexander Mayrhofer、Nicolas Fevrier、Job Snijders、Jeffrey Haas、およびAdam Chappellにコメントとレビューに感謝します。
Contributors
貢献者
Barry Greene, Pedro Marques, Jared Mauch, and Nischal Sheth were authors on [RFC5575] and, therefore, are contributing authors on this document.
Barry Greene、Pedro Marques、Jared Mauch、およびNischal Shethは、[RFC5575]の著者であり、したがってこの文書に著者の貢献者がいます。
Authors' Addresses
著者の住所
Christoph Loibl next layer Telekom GmbH Mariahilfer Guertel 37/7 1150 Vienna Austria
Christoph Loibl次の層Telekom GmbH Marialfer Guertel 37/7 1150ウィーンオーストリア
Phone: +43 664 1176414
Email: cl@tix.at
Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 United States of America
Susan Hares Huawei 7453 Hickory Hill Saline、MI 48176アメリカ
Email: shares@ndzh.com
Robert Raszuk NTT Network Innovations 940 Stewart Dr Sunnyvale, CA 94085 United States of America
Robert Raszuk NTTネットワーク革新940 Stewart Dr Sunnyvale、CA 94085アメリカ合衆国
Email: robert@raszuk.net
Danny McPherson Verisign United States of America
Danny McPherson VeriSignアメリカ合衆国
Email: dmcpherson@verisign.com
Martin Bacher T-Mobile Austria Rennweg 97-99 1030 Vienna Austria
Martin Bacher T-Mobile Austria Rennweg 97-99 1030ウィーンオーストリア
Email: mb.ietf@gmail.com