[要約] RFC 8955は、BGPを用いてトラフィックのフロー仕様（Flowspec）を配布し、動的なフィルタリングや制御を実現するための標準仕様を規定しています。プレフィックス、ポート、プロトコル等の条件を組み合わせたNLRIと、対応するアクション（破棄、帯域制限、リダイレクト等）のエンコード方法を定義しています。本文書はRFC 5575および7674を置換し、検証手順の厳格化や新アクションの追加を通じて、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サービス向けのトラフィックFlow Specificationを（ドメイン内およびドメイン間で）配布するための、Border Gateway Protocol Network Layer Reachability Information（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/rfc8955で確認できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2020 IETF Trustおよび文書の著者として記載された人々。All rights reserved.
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 Trustの法的条項（https://trustee.ietf.org/license-info）が適用されます。これらの条項には本書に関する権利と制限が記載されているため、内容をよく確認してください。本書から抽出したCode Componentには、Trust Legal ProvisionsのSection 4.eで定めるSimplified BSD Licenseの文言を含める必要があります。また、Simplified BSD Licenseに記載のとおり、保証なしで提供されます。
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
1. Introduction
1. はじめに
2. Definitions of Terms Used in This Memo
2. このメモで使用される用語の定義
3. Flow Specifications
3. フロー仕様
4. Dissemination of IPv4 Flow Specification Information
4. IPv4 Flow Specification情報の配布
4.1. Length Encoding
4.1. 長さエンコーディング
4.2. NLRI Value Encoding
4.2. NLRI値エンコーディング
4.2.1. Operators
4.2.1. 演算子
4.2.2. Components
4.2.2. コンポーネント
4.2.2.1. Type 1 - Destination Prefix
4.2.2.1. タイプ1 - 宛先プレフィックス
4.2.2.2. Type 2 - Source Prefix
4.2.2.2. タイプ2 - ソースプレフィックス
4.2.2.3. Type 3 - IP Protocol
4.2.2.3. タイプ3 - IPプロトコル
4.2.2.4. Type 4 - Port
4.2.2.4. タイプ4 - ポート
4.2.2.5. Type 5 - Destination Port
4.2.2.5. 5 - 宛先ポートのタイプ
4.2.2.6. Type 6 - Source Port
4.2.2.6. タイプ6 - ソースポート
4.2.2.7. Type 7 - ICMP Type
4.2.2.7. タイプ7 - ICMPタイプ
4.2.2.8. Type 8 - ICMP Code
4.2.2.8. タイプ8 - ICMPコード
4.2.2.9. Type 9 - TCP Flags
4.2.2.9. タイプ9 - TCPフラグ
4.2.2.10. Type 10 - Packet Length
4.2.2.10. タイプ10パケット長
4.2.2.11. Type 11 - DSCP (Diffserv Code Point)
4.2.2.11. タイプ11 - DSCP（DiffServコードポイント）
4.2.2.12. Type 12 - Fragment
4.2.2.12. タイプ12 - フラグメント
4.3. Examples of Encodings
4.3. 符号化例
5. Traffic Filtering
5. トラフィックフィルタリング
5.1. Ordering of Flow Specifications
5.1. Flow Specificationの順序付け
6. Validation Procedure
6. 検証手順
7. Traffic Filtering Actions
7. トラフィックフィルタリングアクション
7.1. Traffic Rate in Bytes (traffic-rate-bytes) Sub-Type 0x06
7.1. バイト単位のトラフィックレート（traffic-rate-bytes）サブタイプ0x06
7.2. Traffic Rate in Packets (traffic-rate-packets) Sub-Type
0x0c
7.2. パケット単位のトラフィックレート（traffic-rate-packets）サブタイプ0x0c
7.3. Traffic-Action (traffic-action) Sub-Type 0x07
7.3. トラフィックアクション（トラフィックアクション）サブタイプ0x07
7.4. RT Redirect (rt-redirect) Sub-Type 0x08
7.4. RT Redirect（rt-redirect）サブタイプ0x08
7.5. Traffic Marking (traffic-marking) Sub-Type 0x09
7.5. トラフィックマーキング（traffic-marking）サブタイプ0x09
7.6. Interaction with Other Filtering Mechanisms in Routers
7.6. ルーター内の他のフィルタリング機構との相互作用
7.7. Considerations on Traffic Filtering Action Interference
7.7. トラフィックフィルタリングアクションの競合に関する考慮事項
8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks
8. BGP/MPLS VPNネットワークにおけるトラフィックフィルタリングの配布
9. Traffic Monitoring
9. トラフィックの監視
10. Error Handling
10. エラー処理
11. IANA Considerations
11. IANAに関する考慮事項
11.1. AFI/SAFI Definitions
11.1. AFI/SAFIの定義
11.2. Flow Component Definitions
11.2. フローコンポーネントの定義
11.3. Extended Community Flow Specification Actions
11.3. 拡張コミュニティFlow Specificationアクション
12. Security Considerations
12. セキュリティに関する考慮事項
13. References
13. 参考文献
13.1. Normative References
13.1. 規範的参考文献
13.2. Informative References
13.2. 参考引用
Appendix A. Example Python code: flow_rule_cmp
Appendix A. Pythonコード例：flow_rule_cmp
Appendix B. Comparison with RFC 5575
Appendix B. 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.
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.
本書のSection 4では、集約トラフィックフローのFlow Specificationを符号化し、BGP [RFC4271] NLRIとして配布するための一般的な手順を定めます。さらにSection 7では、必要なTraffic Filtering ActionsのBGP Extended Communityと、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.
外部自律システムから受信したFlow Specificationは、受け入れる前にユニキャスト経路情報に照らして検証する必要があります（Section 6）。同じ自律システム内の内部BGPピアから受信したFlow Specification [RFC4271]は、その自律システムの内部BGP（iBGP）メッシュ内で伝送される前に検証済みであると想定します。ユニキャスト宛先プレフィックスで定義された集約トラフィックフローが特定のBGPピアに転送される場合、ローカルシステムは、要求に応じて転送動作を変える可能性のある、より具体的なFlow Specificationを導入できます。
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.
この拡張の用途として、DoSやDDoS攻撃を緩和するために必要となるトラフィックフィルタリングの自動的なドメイン間調整や、BGP/MPLS VPNサービスにおけるトラフィックフィルタリングがあります。Software-Defined Networking（SDN）やNetwork Function Virtualization（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).
現在の配備では、この拡張で配布する情報は手動でも自動でも生成されます。自動生成するのは、悪意のあるトラフィックフローを検出できるシステムです。自動システムを使う場合は、そのシステムの正確性を確保するよう注意する必要があります。また、自動生成されたFlow Specificationを処理する受信側システムの能力上の制約も考慮する必要があります（Section 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
AS：Autonomous System（自律システム）
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スピーカーのDecision Process [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：仮想ルーティングと転送
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.
特定のFlow Specificationには、用途に応じた属性の集合を関連付けることができます。これらの属性に到達可能性情報（NEXT_HOP）が含まれる場合も、含まれない場合もあります。well-knownまたはAS固有のcommunity属性を使って、所定のアクションを符号化できます。
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]によって識別され、RIBの異なるセットに対応しています。これらのRIBは、異なるアプリケーション間の非干渉を保証するために、互いに独立して扱われるべきです。
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プレフィックスによるUPDATEのフィルタリングやcommunity照合など、標準的なBGPポリシー機構をFlow Specification用に定義された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属性を使って符号化します。Flow Specificationを広告するとき、Next-Hop Network Addressの長さを0に設定しなければなりません (MUST)。Next-HopフィールドのNetwork Addressは無視しなければなりません (MUST)。
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フィールドは、<length, NLRI value>形式の2タプルを1つ以上並べて符号化します。各タプルは、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.
Flow Specificationを交換する実装は、[RFC4760]で定義されたBGP Capability Advertisement機構を使い、Multiprotocol Extension Capability（Code 1）を交換しなければなりません (MUST)。Multiprotocol Extension Capabilityで通知する（AFI、SAFI）ペアは、IPv4 Flow Specificationでは（AFI=1、SAFI=133）、VPNv4 Flow Specificationでは（AFI=1、SAFI=134）でなければなりません (MUST)。
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）オクテット未満の場合、長さフィールドは1オクテットで符号化できます。
* 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).
上のFigure 1では、240未満の値を2桁の16進数（0xnn）で符号化します。239より大きい値は3桁の16進数（0xfnnn）で符号化します。この符号化で表せる最大値は4095です。たとえば長さ239は0xef（1オクテット）、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.
コンポーネントは、数値が小さい順に厳密に並べなければなりません (MUST)。各コンポーネントタイプは、Flow Specification内にちょうど1回含めてもよい (MAY) です。含める場合は、それより数値の大きいタイプのコンポーネントより前に置かなければなりません (MUST)。
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.
単一のFlow Specification内では、構成要素のあらゆる組み合わせが許可されます。ただし、一部の組み合わせは一致するパケットがありません（例：「ICMP Type AND Port」はどのパケットにも一致しません）。そのため、こうした組み合わせをBGPで伝播すべきではありません (SHOULD NOT)。
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も含む）は不正形式と見なし、Section 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.
以下で説明する構成要素の多くは比較演算子を使います。どちらの演算子を使うかはSection 4.2.2の各構成要素で定めます。演算子は1オクテットで符号化します。
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（ANDビット）：このビットが未設定の場合、直前の{op, value}ペアの結果と現在の結果を論理和（OR）で結合します。設定されている場合は論理積（AND）で結合します。シーケンスの最初の演算子オクテットでは、このビットを未設定として符号化しなければならず (MUST)、復号時にも常に未設定として扱わなければなりません (MUST)。論理式の評価では、AND演算子はOR演算子より優先されます。
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（長さ）：この演算子のvalueフィールドの長さを（1 << len）で示します。len=00は1オクテット、len=01は2オクテット、len=10は4オクテット、len=11は8オクテットを表します。
0: MUST be set to 0 on NLRI encoding and MUST be ignored during decoding
0：NLRIを符号化するときは0に設定しなければならず (MUST)、復号時には無視しなければなりません (MUST)。
lt: less-than comparison between data and value
lt：dataとvalueの小なり比較。
gt: greater-than comparison between data and value
gt：dataとvalueの大なり比較。
eq: equality between data and value
eq：dataとvalueの等価比較。
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の各ビットを組み合わせると、Table 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（それぞれend-of-listビット、ANDビット、長さフィールド）：最上位ニブルに置かれます。定義はSection 4.2.1.1のNumeric Operator形式と同じです。
not (NOT bit): If set, logical negation of operation.
not（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（Matchビット）：設定されている場合、(data AND value) == valueで定義されるビット単位の一致判定を行います。未設定の場合、data内でvalueマスクのいずれかのビットが設定されていれば、(data AND value)はTRUEと評価されます。
0 (all 0 bits): MUST be set to 0 on NLRI encoding and MUST be ignored during decoding
0（全0ビット）：NLRIエンコーディングで0に設定しなければならず (MUST)、デコード中に無視しなければなりません (MUST)。
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 UPDATEメッセージ[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 UPDATEメッセージ[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プロトコル値オクテット（[RFC0791]のSection 3.1参照）と照合するための{numeric_op, value}ペアのリストを含みます。
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）としてエンコードすべきです (SHOULD)。
Encoding: <type (1 octet), [numeric_op, value]+>
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).
このコンポーネントはSection 4.2.1.1で説明するNumeric Operator（numeric_op）を使います。Type 4のコンポーネント値は、1または2オクテット（numeric_op len=00またはlen=01）で符号化すべきです (SHOULD)。
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.
destination-port（Section 4.2.2.5）またはsource-port（Section 4.2.2.6）コンポーネントがある場合、Flow Specification全体に一致できるのはTCPまたはUDPパケットだけです。portコンポーネントがあるとき、パケットのIPプロトコル値が6（TCP）または17（UDP）でない場合、パケットがフラグメント化されていて最初のフラグメントでない場合、またはシステムがトランスポートヘッダーを特定できない場合は一致しません。IPオプションまたはNULL暗号化を伴うEncapsulating Security Payload（ESP）[RFC4303]がある場合、トランスポートヘッダーを復号できる実装とできない実装があります。
Encoding: <type (1 octet), [numeric_op, value]+>
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).
このコンポーネントはSection 4.2.1.1で説明するNumeric Operator（numeric_op）を使います。Type 5のコンポーネント値は、1または2オクテット（numeric_op len=00またはlen=01）で符号化すべきです (SHOULD)。
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]+>
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).
このコンポーネントはSection 4.2.1.1で説明するNumeric Operator（numeric_op）を使います。Type 6のコンポーネント値は、1または2オクテット（numeric_op len=00またはlen=01）で符号化すべきです (SHOULD)。
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フィールド（[RFC0792]の「Message Formats」節も参照）と照合する{numeric_op, value}ペアのリストを定義します。
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）としてエンコードすべきです (SHOULD)。
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 typeコンポーネントがある場合、Flow Specification全体に一致できるのはICMPパケットだけです。ICMP typeコンポーネントがあるとき、パケットのIPプロトコル値が1（ICMP）でない場合、パケットがフラグメント化されていて最初のフラグメントでない場合、またはシステムがトランスポートヘッダーを特定できない場合は一致しません。IPオプションまたはNULL暗号化を伴うEncapsulating Security Payload（ESP）[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パケットのcodeフィールド（[RFC0792]の「Message Formats」節も参照）と照合する{numeric_op, value}ペアのリストを定義します。
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）としてエンコードすべきです (SHOULD)。
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 codeコンポーネントがある場合、Flow Specification全体に一致できるのはICMPパケットだけです。ICMP codeコンポーネントがあるとき、パケットのIPプロトコル値が1（ICMP）でない場合、パケットがフラグメント化されていて最初のフラグメントでない場合、またはシステムがトランスポートヘッダーを特定できない場合は一致しません。IPオプションまたはNULL暗号化を伴うEncapsulating Security Payload（ESP）[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制御ビット（[RFC0793]のSection 3.1も参照）と照合する{bitmask_op, bitmask}ペアのリストを定義します。
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）としてエンコードしなければなりません (MUST)。
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.
1オクテット（bitmask_op len=00）を指定した場合、TCP制御ビットを含むTCPヘッダーのオクテット14（[RFC0793]のSection 3.1も参照）と照合します。2オクテット（bitmask_op len=01）で符号化した場合はTCPヘッダーのオクテット13と14に照合し、data offset（左端の4ビット）は常に0として扱います。
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 flagsコンポーネントがある場合、Flow Specification全体に一致できるのはTCPパケットだけです。TCP flagsコンポーネントがあるとき、パケットのIPプロトコル値が6（TCP）でない場合、パケットがフラグメント化されていて最初のフラグメントでない場合、またはシステムがトランスポートヘッダーを特定できない場合は一致しません。IPオプションまたはNULL暗号化を伴うEncapsulating Security Payload（ESP）[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).
Layer 2ヘッダーを除き、IPヘッダーを含む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).
このコンポーネントはSection 4.2.1.1で説明するNumeric Operator（numeric_op）を使います。Type 10のコンポーネント値は、1または2オクテット（numeric_op len=00またはlen=01）で符号化すべきです (SHOULD)。
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フィールド（[RFC2474]も参照）と照合する{numeric_op, value}ペアのリストを定義します。
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).
このコンポーネントはSection 4.2.1.1で説明するNumeric Operator（numeric_op）を使います。Type 11のコンポーネント値は1オクテット（numeric_op len=00）で符号化しなければなりません (MUST)。
The six least significant bits contain the DSCP value. All other bits SHOULD be treated as 0.
最下位6ビットにDSCP値を格納します。それ以外のビットは0として扱うべきです (SHOULD)。
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).
このコンポーネントはSection 4.2.1.2で説明するBitmask Operator（bitmask_op）を使います。Type 12のコンポーネントビットマスクは1オクテット（bitmask_op len=00）で符号化しなければなりません (MUST)。
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（Don't Fragment）：[RFC0791]で定義されたIP Header FlagsのBit-1（DF）が1の場合に一致します。
IsF (Is a fragment other than the first): match if the [RFC0791] IP Header Fragment Offset is not 0
IsF（最初ではないフラグメント）：[RFC0791]で定義されたIP Header Fragment Offsetが0以外の場合に一致します。
FF (First Fragment): match if the [RFC0791] IP Header Fragment Offset is 0 AND Flags Bit-2 (MF) is 1
FF（最初のフラグメント）：[RFC0791]で定義されたIP Header Fragment Offsetが0で、Flags 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（最後のフラグメント）：[RFC0791]で定義されたIP Header Fragment Offsetが0以外で、Flags Bit-2（MF）が0の場合に一致します。
0: MUST be set to 0 on NLRI encoding and MUST be ignored during decoding
0：NLRIエンコーディングで0に設定しなければならず (MUST)、デコード中に無視しなければなりません (MUST)。
An example of a Flow Specification NLRI encoding for: "all packets to 192.0.2.0/24 and TCP port 25".
Flow Specification NLRI符号化の例：「宛先192.0.2.0/24かつTCPポート25のすべてのパケット」。
+========+================+==========+==========+
| 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オクテットです。
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}".
Flow Specification NLRI符号化の例：「宛先192.0.2.0/24、送信元203.0.113.0/24、ポートは範囲[137, 139]または8080のすべてのパケット」。
+========+================+================+=============+
| 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オクテットです。
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で、fragmentが{DF or FF}（DFビットが設定されたパケットまたはFirst Fragment）に一致するすべてのパケット」。
+========+===================+==========+
| 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オクテットです。
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.
これらの用途には、サービスプロバイダー間の調整、またはサービスプロバイダー内のAS間の調整が必要です。
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.
Section 4で定義するFlow Specification NLRIは、破棄するか、BGP Extended Communityで定義する事前設定済みのアクションに従って処理するトラフィックのフィルタリング規則を伝えます。この機構は主に、下流ASが破棄したいトラフィックを、上流ASが自ASのイングレスルーターでインバウンドフィルタリングできるよう設計されています。
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 Flow Specification識別子（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.
IPv4 Flow SpecificationのNLRI符号化はSection 4に、VPNv4 Flow SpecificationのNLRI符号化はSection 8に記載されています。フィルタリングアクションはSection 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.
1つのトラフィックフローに複数のFlow Specificationが一致する場合があります。そのため、どの順序でFlow Specificationを照合し、各トラフィックフローにアクションを適用するかを定める必要があります。この順序はBGP経由でFlow Specificationが到着した順序に依存しないため、ネットワーク内で一貫します。
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つのFlow Specificationの相対的な順序は、それぞれの構成要素を比較して決めます。アルゴリズムは各Flow Specificationの最左（最小の構成要素タイプ値）の構成要素から比較します。タイプが異なる場合、数値の小さいタイプの構成要素を含むFlow Specificationは、そのタイプの構成要素を含まないFlow Specificationより優先され、先に照合されます。タイプが同じ場合は、後述するタイプ固有の方法で比較します。タイプ固有の比較でも等しい場合、次の構成要素に進みます。
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値が小さい方を優先します。
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()値が小さい文字列を優先します。長さが異なる場合は共通のプレフィックスを比較します。共通プレフィックスが異なるときは、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ピアから受信し、対応するAdj-RIB-Inに受け入れたFlow Specificationは、経路選択プロセスの入力として使います。同じFlow Specificationプレフィックスに対する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]のSection 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で受信したFlow Specificationを、対応するユニキャストルーティング情報の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を検証しなければなりません (MUST)。
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) Flow Specificationの宛先プレフィックスより具体的で、かつ規則bで特定した最良一致ユニキャスト経路とは異なる隣接ASから受信したユニキャスト経路が存在しないこと。
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を緩和し、宛先プレフィックスコンポーネントを含まないFlow Specificationを許可してもよい (MAY) です。この場合、規則bとcは適用対象外となるため、無視しなければなりません (MUST)。
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経路の「originator」とは、ORIGINATOR_ID属性[RFC4456]に記録されたoriginator address、またはこのパス属性がない場合は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実装は、External BGP（eBGP）経由で受信した経路のAS_PATH属性に、隣接ASがAS_PATHの最左位置に含まれていることも強制しなければなりません (MUST)。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.
最良一致ユニキャスト経路は、Flow Specification NLRIとは独立して変化することがあります。そのため、ユニキャスト経路が変わるたびにFlow Specification NLRIを再検証しなければなりません (MUST)。再検証では、前述の規則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.
基本的な考え方は、宛先への最良のユニキャスト経路を広告する隣接ASに対し、その宛先プレフィックスと同じか、より具体的な宛先プレフィックスを指定するFlow Specification情報の広告を認めることです。そのFlow Specificationの影響を受ける、別の隣接ASから受信したより具体的なユニキャスト経路がなければ、そのFlow Specificationは正常に検証されます。
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.
Flow Specificationが記述するトラフィックの直近の宛先は、当該隣接ASです。そのASが対象フローの破棄を要求した場合、その要求を受け入れても、それ自体がサービス拒否攻撃に当たる懸念はありません。下流AS自身が同じトラフィックを破棄するのと同等であり、そのASまでトラフィックを運んでも利点がないためです。
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.
本書では、Table 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).
本書で定義する複数のTraffic Filtering Actionを1つのFlow Specificationに含め、トラフィックフローに適用すべきです (SHOULD)（例：traffic-rate-bytesとrt-redirectを同じパケットに同時に適用できます）。すべてのTraffic Filtering Actionをトラフィックフローに適用できない場合は、干渉するTraffic Filtering Actionとして扱います（後述）。
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).
Traffic Filtering Action同士は干渉したり、矛盾したりすることがあります。本書のSection 7.7では、このような干渉に関する一般的な考慮事項を示します。Traffic Filtering Actionを追加定義する場合、既存のものを含めてアクション同士が干渉したときに取るべき対応を定めることが推奨されます (SHOULD)。
All Traffic Filtering Actions are specified as transitive BGP Extended Communities.
すべてのTraffic Filtering Actionは、transitive BGP Extended Communityとして指定します。
The traffic-rate-bytes Extended Community uses the following Extended Community encoding:
traffic-rate-bytes Extended Communityは、次のExtended Community符号化形式を使います。
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を格納します。このIDには2オクテットAS番号を割り当てられます。4オクテットAS番号がローカルで利用できる場合は、そのAS番号の下位2オクテットを使用できます。この値は情報提供のみを目的とし、実装は解釈すべきではありません (SHOULD NOT)。
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秒あたりのバイト数です。traffic-rateが0の場合、対象フローのすべてのトラフィックが破棄される結果になります。符号化時にtraffic-rateを負の値にしてはなりません (MUST NOT)。復号化時に負の値は0として扱わなければなりません (MUST)（すべてのトラフィックを破棄します）。
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.
干渉対象：traffic-rate-packets（Section 7.2）と干渉する場合があります。ポリシーによってはtraffic-rate-packetsとtraffic-rate-bytesの両方によるフィルタリングを許可しますが、許可しない場合は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).
traffic-rate-packets Extended Communityは、traffic-rate-bytes Extended Communityと同じ形式で符号化します。浮動小数点値は、1秒あたりの最大パケット数を表します。traffic-rate-packetsが0の場合、対象フローのすべてのトラフィックが破棄される結果になります。符号化時にtraffic-rate-packetsを負の値にしてはなりません (MUST NOT)。復号化時に負の値は0として扱わなければなりません (MUST)（すべてのトラフィックを破棄します）。
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.
干渉対象：traffic-rate-bytes（Section 7.1）と干渉する場合があります。ポリシーによってはtraffic-rate-packetsとtraffic-rate-bytesの両方によるフィルタリングを許可しますが、許可しない場合は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.
トラフィックアクション拡張コミュニティは6オクテットで構成されます。この文書では、図5に示すように、左から数えて6番目のオクテットの最下位2ビットだけを定義します。
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で定義）に従って後続のFlow Specificationを評価します。設定されていない場合、このFlow Specificationの評価後にトラフィックフィルタの評価を停止します。
S Sample (bit 46): Enables traffic sampling and logging for this Flow Specification (only effective when set).
S サンプリング（ビット46）：このFlow Specificationに対するトラフィックのサンプリングとログ記録を有効にします（このビットが設定されている場合にのみ有効です）。
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に設定しなければなりません (MUST)。デコード時にはこれらのビットを無視しなければなりません (MUST)。
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）を使用すると、特定のトラフィックフローに複数のFlow Specificationが一致する場合があります。それらのFlow Specificationに含まれるすべてのトラフィックフィルタリングアクションを収集して適用します。トラフィックフィルタリングアクションが相互に競合する場合、どのアクションを選択するかは実装に委ねられます。セクション7.7も参照してください。
Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document.
干渉するもの：この文書には、他のBGP Flow Specificationトラフィックフィルタリングアクションはありません。
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).
リダイレクト拡張コミュニティを使うと、指定されたroute-targetをインポートポリシーに含むVRFルーティングインスタンスへトラフィックをリダイレクトできます。この条件に一致するローカルインスタンスが複数ある場合、どのインスタンスを選ぶかはローカルで決定します（例えば、Route Distinguisher値が最も小さいインスタンスを選択できます）。
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.
この拡張コミュニティでは、route-targetに3種類のエンコーディング形式（タイプ0x80、0x81、0x82）を使用できます。これは、[RFC4360]のセクション3.1（タイプ0x80：2オクテットのAS番号と4オクテットの値）、セクション3.2（タイプ0x81：4オクテットのIPv4アドレスと2オクテットの値）およびセクション4、ならびに[RFC5668]のセクション2（タイプ0x82：4オクテットのAS番号と2オクテットの値）に記載されたRoute Target拡張コミュニティと同じエンコーディングを使用します。Typeフィールドの上位オクテットはそれぞれ0x80、0x81、0x82で、下位オクテット（Sub-Type）は常に0x08です。
Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document.
干渉するもの：この文書には、他のBGP Flow Specificationトラフィックフィルタリングアクションはありません。
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.
図6に示すように、トラフィックマーキング拡張コミュニティは、通過中のIPパケットのIPヘッダーにあるDSCPビットを、拡張コミュニティ値の最下位6ビットにエンコードされた値に変更するようシステムに指示します（[RFC2474]のセクション3）。
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
reserved（r）：エンコード時には0に設定しなければならず (MUST)、デコード時には無視しなければなりません (MUST)。
Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document.
干渉するもの：この文書には、他のBGP Flow Specificationトラフィックフィルタリングアクションはありません。
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コミュニティ値（通常のコミュニティまたは拡張コミュニティ）をそのアクションに対応付ける機構を提供することが望まれます。例えば、ベストエフォートより低い品質のper-hop behaviorをパケットに適用する機能は、システムごとに実装方法が異なる可能性が高く、現時点で標準の動作は知られていません。ここでその動作を定義するのではなく、ユーザー設定によってユーザー定義のコミュニティ値をプラットフォームまたはネットワーク固有の動作に対応付けることで実現できます。
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つのFlow Specificationに、互いに競合する複数のtraffic-rate-bytesトラフィックフィルタリングアクションが関連付けられる場合があります）。アクションの競合は、Flow Specificationの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.
競合するトラフィックフィルタリングアクションが関連付けられたFlow Specificationがパケット転送に選択された場合、競合するアクションのうちどれを選ぶかは実装に委ねられます。この仕様の実装者は、そのような場合の実装動作を文書化すべきです (SHOULD)。
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.
BGP/MPLS IP VPN [RFC4364]の制御プレーンを使うものなど、プロバイダー型のレイヤー3 VPNネットワークでは、インターネットサービスプロバイダーとは異なるトラフィックフィルタリング要件がある場合があります。一方、インターネットサービスプロバイダーも、例えばインターネットのルーティングテーブルをVRFに保持する用途でこれらのVPNを利用することがあり、その場合はこの文書で定義するグローバルルーティングテーブル環境と同じ要件になります。この文書では、BGP/MPLS VPN環境でFlow Specificationを配布するために使用できる、追加の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形式は、固定長のRoute Distinguisherフィールド（8オクテット）と、それに続くFlow Specification NLRI値（セクション4.2）で構成されます。NLRI長フィールドには、Route Distinguisherの8オクテットと、その後に続くFlow Specification NLRI値の両方を含めます。結果のエンコーディングを図7に示します。
+--------------------------------+
| length (0xnn or 0xfnnn) |
+--------------------------------+
| Route Distinguisher (8 octets) |
+--------------------------------+
| NLRI value (variable) |
+--------------------------------+
Figure 7: Flow Specification NLRI for MPLS
図7：MPLS用Flow Specification 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 VPN [RFC4364]で説明されているのと同じ機構を使い、BGPパス広告に付随するRoute Target拡張コミュニティを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を介して受信したFlow Specificationは、インポート先の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ルーターから受信したFlow Specificationは、デフォルトで受け入れられます。
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:
トラフィックフィルタリングアプリケーションには、監視機能とトラフィック統計機能が必要です。これらをどのように実装するかは実装に委ねられますが、実装は次の機能を提供すべきです (SHOULD)。
* A mechanism to log the packet header of filtered traffic.
* フィルタリングされたトラフィックのパケットヘッダーを記録する機構。
* A mechanism to count the number of matches for a given Flow Specification rule.
* 指定されたFlow Specification規則に一致した回数を数える機構。
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に従ってデコードできない拡張コミュニティ値です。
+=======+===========================================+===========+
| 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 Valuesレジストリ
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:
<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:
次のリビジョン記述がモジュールに追加されました。
<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.)
+=======+====================+===========+
| 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：Flow Spec Component Typesレジストリ
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 Component Typesのポリシー
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の範囲の登録ポリシーはExpert Reviewです。専門家は、要求されたコードポイントの目的と用途が明確であることを確認するものとします。また、IETFで作成され、これらのコードポイントのいずれかを要求する仕様については、IDR Working Groupによるレビューを受けられる状態になっていることを確認します。IETF外で作成された仕様については、IETFで進行中または公開済みの作業と競合しないことも確認します。新しいコンポーネント型を導入すると、このプロトコルの既存実装との相互運用性が損なわれる可能性がある点も指摘しなければなりません。
The Extended Community Flow Specification Action types defined in this document consist of two parts:
この文書で定義する拡張コミュニティFlow Specificationアクション型は、次の2つの部分で構成されます。
* Type (BGP Transitive Extended Community Type)
* Type（BGP Transitive Extended Community Type）
* Sub-Type
* 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.)
+=======+=======================================+===========+
| 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 Transitive Extended Community Typesレジストリ
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.)
+==========+=====================================+===========+
| 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：Generic Transitive Experimental Use Extended Community Sub-Typesレジストリ
+================+===================================+===========+
| 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：Generic Transitive Experimental Use Extended Community Part 2 Sub-Typesレジストリ
+================+=======================+===========+
| 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：Generic Transitive Experimental Use Extended Community Part 3 Sub-Typesレジストリ
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は「Generic Transitive Experimental Use Extended Community Part 2 Sub-Types」および「Generic Transitive Experimental Use Extended Community Part 3 Sub-Types」レジストリの参照先を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.)
+=====+=================+===========+
| Bit | Name | Reference |
+=====+=================+===========+
| 47 | Terminal Action | RFC 8955 |
+-----+-----------------+-----------+
| 46 | Sample | RFC 8955 |
+-----+-----------------+-----------+
Table 16: Registry: Traffic Action Fields
表16：Traffic Action Fieldsレジストリ
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.
Flow Specificationが、関連するプレフィックスの対応するユニキャスト経路（セクション6）に一致するよう制限されている限り、この提案のセキュリティ特性はBGPユニキャストルーティングが既に持つセキュリティ特性と同等です。セクション6に記載した検証手順を緩和すると、望ましくないFlow Specificationが伝播し、その結果、望ましくないトラフィックフィルタリングアクションがフローに適用される可能性があります。
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.
ネットワークの管理境界内で検証を特定の形で緩和すると、サービス拒否攻撃を防ぐフィルターを迅速に配布できるため、一部のネットワークでは有用です。この緩和を利用するネットワークでは、origin ASフィールドが空であるため、BGPポリシーで追加のフィルタリングをサポートする必要があります。検証制限を緩和する仕様は、必要な追加フィルタリングの詳細を示すセキュリティ上の考慮事項を含めなければなりません (MUST)。例えば、オリジン検証を利用すると、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].
プロバイダー間ルーティングは信頼の網に基づいています。隣接する自律システムは、有効な到達可能性情報を広告すると信頼されています。この信頼モデルが破られると、隣接する自律システムが、自身ではサービスを提供していないプレフィックスの到達可能性情報を広告し、サービス拒否攻撃を引き起こす可能性があります（フィルタリングされていないアドレス空間のハイジャック）。Flow Specificationの検証は最良のユニキャスト経路の広告に結び付いているため、最良経路の検証に失敗すると、ローカルルーターでFlow Specificationを使用できなくなる可能性があります。緩和策として[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.
インターネットエクスチェンジポイント（IXP）では、AS_PATHを延長しないルートサーバーを介して経路を交換することがよくあります。この場合、AS_PATHの最左端のASが隣接AS（ルートサーバーのAS）であることを強制できません。Flow Specificationの検証（セクション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.
集中管理を行わずにルーターでファイアウォールに似た機能を有効にすると、一部の障害の診断が難しくなることがあります。例えば、2つのアドレス間でTCPパケットは通過させる一方、ICMPパケットは通過させない設定が可能です。また、2つのアドレス間で900オクテット未満または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.
Flow Specificationを扱うBGPスピーカー（例えば自動化されたDDoS対策コントローラー）のプログラムに誤りがある場合、アルゴリズムが想定どおりに動作しない場合、または不正なシステムが存在する場合、意図しないFlow Specificationを広告したり、高頻度でUPDATEを送信したり、大量のFlow Specificationを生成したりする可能性があります。その結果、受信システムに過大な負荷をかけたり、処理能力を超過させたり、望ましくないトラフィックフィルタリングアクションをフローに適用させたりするおそれがあります。
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.
システムによっては、パケットを識別するために必要なヘッダー値をすべて取得できない場合があります。特に、最初のフラグメントではないため上位層プロトコルヘッダーを含まないフラグメントや、NULL暗号化を使用するEncapsulating Security Payload（ESP）[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.
この文書ではFlow Specification NLRIの一般的な検証手順を定めています（セクション6）が、第三者から受信するトラフィックフィルタリングアクションには、個別の検証やフィルタリングが必要になる場合があります。特に、トラフィックレートアクション以外は、第三者がパケット転送の特性を変更し、別のルーティングテーブルやVPN、または望ましくないキューに影響を及ぼす可能性があります。ネットワーク境界でトラフィックフィルタリングアクションのコミュニティを適切にフィルタリングまたはスクリーニングし、定義済みのアクションだけを第三者に公開することで、これを防止できます（セクション7を参照）。その方法の一つは、第三者が設定できるユーザー定義コミュニティをトラフィックフィルタリングアクションに対応付け、第三者からのトラフィックフィルタリングアクション拡張コミュニティは受け入れないことです。
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.
この拡張はインターネットルーターに情報を追加します。ルーターが保持できるデータ要素の最大数と、一定時間内に処理できるイベント数には上限があります。サービスプロバイダーは装置の最大容量を考慮し、受け入れて処理するFlow Specificationの数を制限する必要がある場合があります。
[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, "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>.
[ISO_IEC_9899] ISO, "Information technology -- Programming languages -- C", ISO/IEC 9899:2018, June 2018.
[ISO_IEC_9899] ISO, "Information technology -- Programming languages -- C", ISO/IEC 9899:2018, June 2018.
[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, August 1980, <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., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <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., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <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, September 1981, <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., "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>.
[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., 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>.
[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] 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>.
[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., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <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. 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>.
[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., 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>.
[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] 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>.
[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., 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>.
[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. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <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., 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>.
[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] 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>.
[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., "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>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <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., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 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., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.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., "Clarification of the Flowspec Redirect Extended Community", RFC 7674, DOI 10.17487/RFC7674, October 2015, <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., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <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. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <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., 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>.
[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., 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>.
<CODE BEGINS> """ Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the 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). """
import itertools import collections import ipaddress
EQUAL = 0 A_HAS_PRECEDENCE = 1 B_HAS_PRECEDENCE = 2 IP_DESTINATION = 1 IP_SOURCE = 2
FS_component = collections.namedtuple('FS_component', 'component_type op_value')
class FS_nlri(object): """ FS_nlri class implementation that allows sorting.
By calling .sort() on an array of FS_nlri objects these will be sorted according to the flow_rule_cmp algorithm.
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>
* 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でFlow Specification 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]ではtraffic-rateアクションを非推移的と定義しており、他のトラフィックフィルタリングアクションコミュニティが推移的かどうかは定義していませんでした。
* Section 7.2 introduces a new Traffic Filtering Action (traffic-rate-packets). This action did not exist in [RFC5575].
* セクション7.2で、新しいトラフィックフィルタリングアクション（traffic-rate-packets）を導入しました。このアクションは[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.
* 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に新しいエラー処理を記載しました。
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].
著者らは、[RFC5575]の原文に対するコメントを寄せたYakov Rekhter、Dennis Ferguson、Chris Morrow、Charlie Kaufman、David Smithに感謝します。また、Chaitanya KodeboyinaにはFlow Specificationの検証手順の設計に感謝します。
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.
Flow Specification拡張のドラフトにはパケットレートのトラフィックフィルタリングアクションも記載されていました。著者らは、この作業を行った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に感謝します。
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]の著者であり、この文書にも著者として貢献しています。
Christoph Loibl next layer Telekom GmbH Mariahilfer Guertel 37/7 1150 Vienna Austria
Christoph Loibl next layer Telekom GmbH Mariahilfer Guertel 37/7 1150 Vienna Austria
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 United States of America
Email: shares@ndzh.com
Robert Raszuk NTT Network Innovations 940 Stewart Dr Sunnyvale, CA 94085 United States of America
Robert Raszuk NTT Network Innovations 940 Stewart Dr Sunnyvale, CA 94085 United States of America
Email: robert@raszuk.net
Danny McPherson Verisign United States of America
Danny McPherson Verisign United States of America
Email: dmcpherson@verisign.com
Martin Bacher T-Mobile Austria Rennweg 97-99 1030 Vienna Austria
Martin Bacher T-Mobile Austria Rennweg 97-99 1030 Vienna Austria
Email: mb.ietf@gmail.com