[要約] RFC 7978は、TRILLプロトコルのRBridgeチャネルヘッダー拡張に関する仕様です。その目的は、RBridgeチャネルヘッダーを使用して、TRILLネットワーク内の複数のリンクを透過的に相互接続することです。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7978 Huawei
Updates: 7178 M. Umair
Category: Standards Track IPinfusion
ISSN: 2070-1721 Y. Li
Huawei
September 2016
Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension
多数のリンクの透過的な相互接続（TRILL）：RBridgeチャネルヘッダー拡張
Abstract
概要
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism (specified in RFC 7178) called RBridge Channel for the transmission of typed messages between TRILL switches in the same campus and the transmission of such messages between TRILL switches and end stations on the same link. This document specifies extensions to the RBridge Channel protocol header to support two features as follows: (1) a standard method to tunnel payloads whose type can be indicated by Ethertype through encapsulation in RBridge Channel messages; and (2) a method to support security facilities for RBridge Channel messages. This document updates RFC 7178.
IETF TRILL（多くのリンクの透過的相互接続）プロトコルには、同じキャンパス内のTRILLスイッチ間で型付けされたメッセージを送信し、TRILLスイッチと端末の間でそのようなメッセージを送信するためのRBridge Channelと呼ばれるオプションのメカニズム（RFC 7178で指定）が含まれています同じリンク上。このドキュメントでは、RBridgeチャネルプロトコルヘッダーの拡張を指定して、次の2つの機能をサポートします。（1）RBridgeチャネルメッセージのカプセル化を通じてEthertypeでタイプを示すことができるペイロードをトンネリングする標準的な方法。 （2）RBridge Channelメッセージのセキュリティ機能をサポートする方法。このドキュメントはRFC 7178を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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 http://www.rfc-editor.org/info/rfc7978.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7978で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology and Acronyms ...................................4
2. RBridge Channel Header Extension Format .........................5
3. Extended RBridge Channel Payload Types ..........................8
3.1. Null Payload ...............................................8
3.2. Ethertyped Payload .........................................9
3.2.1. RBridge Channel Message as the Payload ..............9
3.2.2. TRILL Data Packet as the Payload ...................10
3.2.3. TRILL IS-IS Packet as the Payload ..................10
3.3. Ethernet Frame ............................................11
4. Extended RBridge Channel Security ..............................13
4.1. Derived Keying Material ...................................14
4.2. SType None ................................................14
4.3. IS-IS CRYPTO_AUTH-Based Authentication ....................15
4.4. DTLS Pairwise Security ....................................17
4.5. Composite Security ........................................18
5. Extended RBridge Channel Errors ................................18
5.1. SubERRs ...................................................19
5.2. Secure Nested RBridge Channel Errors ......................19
6. IANA Considerations ............................................19
6.1. Extended RBridge Channel Protocol Number ..................19
6.2. RBridge Channel Protocol Subregistries ....................20
6.2.1. RBridge Channel Error Codes ........................20
6.2.2. RBridge Channel SubError Codes .....................20
6.2.3. Extended RBridge Channel Payload Types
Subregistry ........................................20
6.2.4. Extended RBridge Channel Security Types
Subregistry ........................................21
7. Security Considerations ........................................21
8. Normative References ...........................................22
9. Informative References .........................................23
Acknowledgements ..................................................25
Authors' Addresses ................................................25
The IETF TRILL base protocol [RFC6325] [RFC7780] has been extended with the RBridge Channel [RFC7178] facility to support transmission of typed messages (for example, Bidirectional Forwarding Detection (BFD) [RFC7175]) between two TRILL switches (RBridges) in the same campus and the transmission of such messages between RBridges and end stations on the same link. When sent between RBridges in the same campus, a TRILL Data packet with a TRILL Header is used, and the destination RBridge is indicated by nickname. When sent between a RBridge and an end station on the same link in either direction, a native RBridge Channel message [RFC7178] is used with no TRILL Header, and the destination port or ports are indicated by a Media Access Control (MAC) address. (There is no mechanism to stop end stations on the same link from sending native RBridge Channel messages to each other; however, such use is outside the scope of this document.)
IETF TRILLベースプロトコル[RFC6325] [RFC7780]はRBridge Channel [RFC7178]機能で拡張され、2つのTRILLスイッチ（RBridges）間の型付きメッセージ（たとえば、Bidirectional Forwarding Detection（BFD）[RFC7175]）の送信をサポートしています。同じキャンパス、および同じリンク上のRBridgeとエンドステーション間のそのようなメッセージの送信。同じキャンパス内のRBridge間で送信される場合、TRILLヘッダー付きのTRILLデータパケットが使用され、宛先RBridgeはニックネームで示されます。同じリンク上のRBridgeとエンドステーションの間でいずれかの方向に送信される場合、ネイティブのRBridge Channelメッセージ[RFC7178]がTRILLヘッダーなしで使用され、宛先ポートはメディアアクセスコントロール（MAC）アドレスで示されます。 （同じリンク上のエンドステーションがネイティブのRBridge Channelメッセージを互いに送信しないようにするメカニズムはありませんが、そのような使用法はこのドキュメントの範囲外です。）
This document updates [RFC7178] and specifies extensions to the RBridge Channel header that provide two additional facilities as follows:
このドキュメントは[RFC7178]を更新し、次の2つの追加機能を提供するRBridge Channelヘッダーの拡張を指定します。
(1) A standard method to tunnel payloads, whose type may be indicated by Ethertype, through encapsulation in RBridge Channel messages.
（1）RBridgeチャネルメッセージのカプセル化を通じて、タイプがEthertypeで示される可能性があるペイロードをトンネリングする標準的な方法。
(2) A method to provide security facilities for RBridge Channel messages. Example uses requiring such facilities are the security of Pull Directory messages [RFC7067], address flush messages [AddrFlush], and port shutdown messages [TRILL-AF].
（2）RBridge Channelメッセージにセキュリティ機能を提供する方法。このような機能を必要とする使用例は、プルディレクトリメッセージのセキュリティ[RFC7067]、アドレスフラッシュメッセージ[AddrFlush]、およびポートシャットダウンメッセージ[TRILL-AF]です。
Use of each of these facilities is optional, except that, as specified below, if this header extension is implemented, there are two payload types that MUST be implemented. Both of the above facilities can be used in the same packet. In case of conflict between this document and [RFC7178], this document takes precedence.
これらの各機能の使用はオプションですが、以下に指定されているように、このヘッダー拡張が実装されている場合は、2つのペイロードタイプが実装されている必要があります。上記の機能はどちらも同じパケットで使用できます。このドキュメントと[RFC7178]との間に矛盾がある場合、このドキュメントが優先されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
This document uses terminology and abbreviations defined in [RFC6325] and [RFC7178]. Some of these are listed below for convenience along with new terms and abbreviations.
このドキュメントでは、[RFC6325]と[RFC7178]で定義されている用語と略語を使用しています。これらのいくつかは、便宜上、新しい用語と略語とともに以下にリストされています。
application_data - A DTLS [RFC6347] message type.
application_data-DTLS [RFC6347]メッセージタイプ。
Data Label - VLAN or FGL.
データラベル-VLANまたはFGL。
DTLS - Datagram Transport Layer Security [RFC6347].
DTLS-データグラムトランスポート層セキュリティ[RFC6347]。
FCS - Frame Check Sequence.
FCS-フレームチェックシーケンス。
FGL - Fine-Grained Label [RFC7172].
FGL-きめの細かいラベル[RFC7172]。
HKDF - HMAC-based Key Derivation Function [RFC5869].
HKDF-HMACベースの鍵導出関数[RFC5869]。
IS-IS - Intermediate System to Intermediate System [IS-IS].
IS-IS-中間システムから中間システム[IS-IS]。
PDU - Protocol Data Unit.
PDU-プロトコルデータユニット。
MTU - Maximum Transmission Unit.
MTU-最大転送単位。
RBridge - An alternative term for a TRILL switch.
RBridge-TRILLスイッチの別名。
SHA - Secure Hash Algorithm [RFC6234].
SHA-Secure Hash Algorithm [RFC6234]。
Sz - Campus-wide minimum link MTU [RFC6325] [RFC7780].
Sz-キャンパス全体の最小リンクMTU [RFC6325] [RFC7780]。
TRILL - Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer.
TRILL-リンク層での多数のリンクまたはトンネルルーティングの透過的な相互接続。
TRILL switch - A device that implements the TRILL protocol [RFC6325] [RFC7780], sometimes referred to as an RBridge.
TRILLスイッチ-TRILLプロトコル[RFC6325] [RFC7780]を実装するデバイス。RBridgeとも呼ばれます。
The general structure of an RBridge Channel message between two TRILL switches (RBridges) in the same campus is shown in Figure 1 below. The structure of a native RBridge Channel message sent between an RBridge and an end station on the same link, in either direction, is shown in Figure 2 and, compared with the first case, omits the TRILL Header, inner Ethernet addresses, and Data Label. A Protocol field in the RBridge Channel Header gives the type of RBridge Channel message and indicates how to interpret the Channel-Protocol-Specific Payload [RFC7178].
同じキャンパス内の2つのTRILLスイッチ（RBridges）間のRBridge Channelメッセージの一般的な構造を以下の図1に示します。図2は、同じリンク上のRBridgeと端末の間で送信されるネイティブRBridge Channelメッセージの構造を示しています。最初のケースと比較すると、TRILLヘッダー、内部イーサネットアドレス、およびデータラベルが省略されています。 。 RBridgeチャネルヘッダーのプロトコルフィールドは、RBridgeチャネルメッセージのタイプを示し、チャネルプロトコル固有のペイロードを解釈する方法を示します[RFC7178]。
+-----------------------------------+
| Link Header |
+-----------------------------------+
| TRILL Header |
+-----------------------------------+
| Inner Ethernet Addresses |
+-----------------------------------+
| Data Label (VLAN or FGL) |
+-----------------------------------+
| RBridge Channel Header |
+-----------------------------------+
| Channel-Protocol-Specific Payload |
+-----------------------------------+
| Link Trailer (FCS if Ethernet) |
+-----------------------------------+
Figure 1: RBridge Channel Packet Structure
図1：RBridgeチャネルのパケット構造
+-----------------------------------+
| Ethernet Link Header |
+-----------------------------------+
| RBridge Channel Header |
+-----------------------------------+
| Channel-Protocol-Specific Payload |
+-----------------------------------+
| FCS |
+-----------------------------------+
Figure 2: Native RBridge Channel Frame
図2：ネイティブRBridgeチャネルフレーム
The RBridge Channel Header looks like this:
RBridgeチャネルヘッダーは次のようになります。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x8946 | CHV=0 | Channel Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ Channel-Protocol-Specific Data /
/-+-+-+-+-+- /
Figure 3: RBridge Channel Header
図3：RBridgeチャネルヘッダー
where 0x8946 is the RBridge-Channel Ethertype and CHV is the Channel Header Version. This document is based on RBridge Channel version zero.
ここで、0x8946はRBridge-Channel Ethertypeで、CHVはチャネルヘッダーバージョンです。このドキュメントは、RBridge Channelバージョン0に基づいています。
The header extensions specified herein are in the form of an RBridge Channel protocol, the Extended RBridge Channel Protocol. Figure 4 below expands the RBridge Channel Header and Protocol-Specific Payload above for the case where the header extension is present.
ここで指定されたヘッダー拡張は、RBridge Channelプロトコル、Extended RBridge Channel Protocolの形式です。以下の図4は、ヘッダー拡張が存在する場合の上記のRBridgeチャネルヘッダーとプロトコル固有のペイロードを展開しています。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x8946 | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Extension Specific: | SubERR| RESV4 | SType | PType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Tunneled Data, variable length
| ...
Figure 4: RBridge Channel Header Extension Structure
図4：RBridgeチャネルヘッダー拡張構造
The RBridge Channel Header Protocol field is used to indicate that the header extension is present. Its contents MUST be the value allocated for this purpose (see Section 6). The use of an RBridge Channel protocol to indicate extensions makes it easy to determine if a remote RBridge in the campus supports extensions since RBridges advertise in their LSP which such protocols they support.
RBridge Channel Header Protocolフィールドは、ヘッダー拡張が存在することを示すために使用されます。その内容は、この目的のために割り当てられた値でなければなりません（セクション6を参照）。 RBridgeチャネルプロトコルを使用して拡張を示すと、RBridgeがサポートするプロトコルがLSPでアドバタイズされるため、キャンパス内のリモートRBridgeが拡張をサポートしているかどうかを簡単に判断できます。
The Extended RBridge Channel-Protocol-Specific Data fields are as follows:
拡張RBridgeチャネルプロトコル固有のデータフィールドは次のとおりです。
SubERR: This field provides further details when an error is indicated in the RBridge Channel ERR field. If ERR is zero, then SubERR MUST be sent as zero and ignored on receipt. See Section 5.
SubERR：このフィールドは、RBridge Channel ERRフィールドにエラーが示されている場合の詳細を提供します。 ERRがゼロの場合、SubERRはゼロとして送信され、受信時に無視される必要があります。セクション5を参照してください。
RESV4: This field MUST be sent as zero. If non-zero when received, this is an error condition. See Section 5.
RESV4：このフィールドはゼロとして送信する必要があります。受信時にゼロ以外の場合、これはエラー条件です。セクション5を参照してください。
SType: This field describes the type of security information and features, including keying material, being used or provided by the extended RBridge Channel message. See Section 4.
SType：このフィールドは、拡張RBridgeチャネルメッセージによって使用または提供されているセキュリティ情報と機能（キー情報を含む）のタイプを示します。セクション4を参照してください。
PType: Payload Type. This describes the tunneled data. See Section 3.
PType：ペイロードタイプ。これは、トンネルされたデータを記述します。セクション3を参照してください。
Security Information: Variable-length information. Length is zero if SType is zero. See Section 4.
セキュリティ情報：可変長情報。 STypeがゼロの場合、長さはゼロです。セクション4を参照してください。
The RBridge Channel Header Extension is integrated with the RBridge Channel facility. Extension errors are reported as if they were RBridge Channel errors, using newly allocated code points in the ERR field of the RBridge Channel Header supplemented by the SubERR field.
RBridge Channelヘッダー拡張は、RBridge Channel機能と統合されています。拡張エラーは、RBERRチャネルエラーであるかのように報告され、SubERRフィールドで補足されたRBridgeチャネルヘッダーのERRフィールドに新しく割り当てられたコードポイントを使用します。
The Extended RBridge Channel Protocol can carry a variety of payloads as indicated by the PType (Payload Type) field. Values are shown in the table below with further explanation below the table (see also Section 6.2.2).
拡張RBridgeチャネルプロトコルは、PType（ペイロードタイプ）フィールドで示されるさまざまなペイロードを伝送できます。値は下の表に示され、表の下にさらに説明があります（セクション6.2.2も参照）。
PType Description Reference
----- ----------- ---------
0 Reserved
1 Null Section 3.1 of RFC 7978
2 Ethertyped Payload Section 3.2 of RFC 7978
3 Ethernet Frame Section 3.3 of RFC 7978
4-14 Unassigned
15 Reserved
Table 1: Payload Type Values
表1：ペイロードタイプの値
While implementation of the RBridge Channel Header Extension is optional, if it is implemented, PType 1 (Null) MUST be implemented and PType 2 (Ethertyped Payload) with the RBridge-Channel Ethertype MUST be implemented. PType 2 for any Ethertypes other than the RBridge-Channel Ethertype MAY be implemented. PType 3 MAY be implemented.
RBridge Channelヘッダー拡張の実装はオプションですが、実装する場合は、PType 1（Null）を実装する必要があり、RBridge-Channel Ethertypeを使用したPType 2（Ethertypedペイロード）を実装する必要があります。 RBridge-Channel Ethertype以外のEthertypeのPType 2が実装される場合があります。 PType 3が実装される場合があります。
The processing of any particular extended header RBridge Channel message and its payload depends on meeting local security and other policy at the destination TRILL switch or end station.
特定の拡張ヘッダーRBridgeチャネルメッセージとそのペイロードの処理は、宛先のTRILLスイッチまたはエンドステーションでのローカルセキュリティとその他のポリシーを満たすことに依存します。
The Null payload type (PType = 1) is intended to be used for testing or for messages such as key negotiation or the like where only security information is present. It indicates that there is no user data payload. Any tunneled user data after the Security Information field is ignored. If the RBridge Channel Header Extension is implemented, the Null Payload MUST be supported in the sense that an "Unsupported PType" error is not returned (see Section 5). Any particular use of the Null Payload should specify what VLAN or FGL and what priority should be used in the inner Data Label of the RBridge Channel message (or in an outer VLAN tag for the native RBridge Channel message case) when those values are relevant.
Nullペイロードタイプ（PType = 1）は、セキュリティ情報のみが存在するテストまたはキーネゴシエーションなどのメッセージに使用することを目的としています。ユーザーデータペイロードがないことを示します。 [セキュリティ情報]フィールドの後のトンネルされたユーザーデータは無視されます。 RBridgeチャネルヘッダー拡張が実装されている場合、「サポートされていないPType」エラーが返されないという意味で、Nullペイロードをサポートする必要があります（セクション5を参照）。 Nullペイロードの特定の使用では、RBridgeチャネルメッセージの内部データラベル（またはネイティブRBridgeチャネルメッセージの場合は外部VLANタグ）で使用するVLANまたはFGLと優先度を指定する必要があります（これらの値が関連する場合）。
A PType of 2 indicates that the payload (tunneled data) of the extended RBridge Channel message begins with an Ethertype. A TRILL switch supporting the RBridge Channel Header Extension MUST support a PType of 2 with a payload beginning with the RBridge-Channel Ethertype as described in Section 3.2.1. Other Ethertypes, including the TRILL and L2-IS-IS Ethertypes as described in Sections 3.2.2 and 3.2.3, MAY be supported.
PType 2は、拡張RBridge Channelメッセージのペイロード（トンネルデータ）がEthertypeで始まることを示します。 RBridge Channelヘッダー拡張をサポートするTRILLスイッチは、セクション3.2.1で説明されているように、RBridge-Channel Ethertypeで始まるペイロードで2のPTypeをサポートする必要があります。セクション3.2.2および3.2.3で説明されているTRILLおよびL2-IS-IS Ethertypeを含む他のEthertypeは、サポートされる場合があります。
A PType of 2 whose payload has an initial RBridge-Channel Ethertype indicates an encapsulated RBridge Channel message. A typical reason for sending an RBridge Channel message inside an extended RBridge Channel message is to provide security services, such as authentication or encryption, for the encapsulated message.
ペイロードが最初のRBridge-Channel Ethertypeを持つPType 2は、カプセル化されたRBridge Channelメッセージを示します。拡張RBridge Channelメッセージ内でRBridge Channelメッセージを送信する一般的な理由は、カプセル化されたメッセージに認証や暗号化などのセキュリティサービスを提供するためです。
This RBridge Channel message type looks like the following:
このRBridge Channelメッセージタイプは次のようになります。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | CHV=0 |Nested Channel Protocol|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Nested Channel-Protocol-Specific Data ... /
/ /
Figure 5: Message Structure with RBridge Channel Payload
図5：RBridgeチャネルペイロードを含むメッセージ構造
A PType of 2 whose payload has an initial TRILL Ethertype indicates an encapsulated TRILL Data packet as shown in Figure 6. If this Ethertype is supported for PType = 2 and the message meets local policy for acceptance, the TRILL Data packet is handled as if it had been received by the destination TRILL switch on the port where the Extended RBridge Channel message was received.
ペイロードに最初のTRILL EthertypeがあるPType 2は、図6に示すように、カプセル化されたTRILLデータパケットを示します。このEthertypeがPType = 2でサポートされ、メッセージが受け入れに関するローカルポリシーを満たす場合、TRILLデータパケットはあたかも拡張RBridgeチャネルメッセージが受信されたポートの宛先TRILLスイッチによって受信されました。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL (0x22F3) | V |A|C|M| RESV |F| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Optional Flags Word /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacDA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacDA continued | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Data Label (2 or 4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| TRILL Data Packet payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 6: Message Structure with TRILL Data Packet Payload
図6：TRILLデータパケットペイロードを含むメッセージ構造
The optional flags word is only present if the F bit in the TRILL Header is one [RFC7780].
オプションのフラグワードは、TRILLヘッダーのFビットが1 [RFC7780]の場合にのみ存在します。
A PType of 2 and an initial L2-IS-IS Ethertype indicate that the payload of the Extended RBridge Channel protocol message is an encapsulated TRILL IS-IS PDU as shown in Figure 7. If this Ethertype is supported for PType = 2, the tunneled TRILL IS-IS packet is processed by the destination RBridge if it meets local policy. One possible use is to expedite the receipt of a link state PDU (LSP) by some TRILL switch or switches with an immediate requirement for the link state information. A link local IS-IS PDU would not normally be sent via this Extended RBridge Channel method except possibly to encrypt the PDU since such PDUs can just be transmitted on the link and do not normally need RBridge Channel handling. (Link local IS-IS PDUs are (1) Hello, CSNP, PSNP [IS-IS]; (2) MTU-probe, MTU-ack [RFC7176]; and (3) circuit scoped FS-LSP, FS-CSNP, and FS-PSNP [RFC7356].)
PType 2と最初のL2-IS-IS Ethertypeは、図7に示すように、拡張RBridge Channelプロトコルメッセージのペイロードがカプセル化されたTRILL IS-IS PDUであることを示します。このEthertypeがPType = 2でサポートされている場合、トンネルTRILL IS-ISパケットは、ローカルポリシーを満たす場合、宛先RBridgeによって処理されます。可能な使用法の1つは、いくつかのTRILLスイッチまたはリンク状態情報の即時要件があるスイッチによるリンク状態PDU（LSP）の受信を迅速化することです。リンクローカルIS-IS PDUは、このPDUを暗号化する場合を除いて、通常はこの拡張RBridge Channelメソッドを介して送信されません。そのようなPDUはリンク上で送信されるだけで、通常はRBridge Channel処理が必要ないためです。 （リンクローカルIS-IS PDUは、（1）Hello、CSNP、PSNP [IS-IS]、（2）MTUプローブ、MTU-ack [RFC7176]、および（3）サーキットスコープのFS-LSP、FS-CSNP、およびFS-PSNP [RFC7356]。）
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| L2-IS-IS (0x22F4) | 0x83 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rest of IS-IS PDU
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 7: Message Structure with TRILL IS-IS Packet Payload
図7：TRILL IS-ISパケットペイロードを使用したメッセージ構造
If PType is 3, the extended RBridge Channel payload is an Ethernet frame as might be received from or sent to an end station except that the encapsulated Ethernet frame's FCS is omitted, as shown in Figure 8. (There is still an overall final FCS if the RBridge Channel message is being sent on an Ethernet link.) If this PType is implemented and the message meets local policy, the encapsulated frame is handled as if it had been received on the port on which the Extended RBridge Channel message was received.
PTypeが3の場合、図8に示すように、カプセル化されたイーサネットフレームのFCSが省略されていることを除いて、拡張RBridgeチャネルペイロードは、エンドステーションで受信または送信される可能性があるイーサネットフレームです。 RBridge Channelメッセージがイーサネットリンクで送信されています。）このPTypeが実装されており、メッセージがローカルポリシーを満たしている場合、カプセル化されたフレームは、拡張RBridge Channelメッセージが受信されたポートで受信されたかのように処理されます。
The priority of the RBridge Channel message can be copied from the Ethernet frame VLAN tag, if one is present, except that priority 7 SHOULD only be used for messages critical to establishing or maintaining adjacency and priority 6 SHOULD only be used for other important control messages.
RBridge Channelメッセージの優先度は、イーサネットフレームVLANタグが存在する場合は、それからコピーできます。ただし、優先度7は隣接の確立または維持に重要なメッセージにのみ使用し、優先度6は他の重要な制御メッセージにのみ使用してください。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | 0x0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MacDA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MacDA (cont.) | MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MacSA (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Any Ethernet frame tagging...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Ethernet frame payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 8: Message Structure with Ethernet Frame Payload
図8：イーサネットフレームペイロードを含むメッセージ構造
In the case of a non-Ethernet link, such as a PPP (Point-to-Point Protocol) link [RFC6361], the ports on the link are considered to have link-local synthetic 48-bit MAC addresses constructed as described below. Such a constructed address MAY be used as a MacSA. If the RBridge Channel message is individually addressed to a link-local port, the source TRILL switch will have the information to construct such a MAC address for the destination TRILL switch port, and that MAC address MAY be used as the MacDA. By the use of such a MacSA and either such a unicast MacDA or a group-addressed MacDA, an Ethernet frame can be sent between two TRILL switch ports connected by a non-Ethernet link.
PPP（Point-to-Point Protocol）リンク[RFC6361]などの非イーサネットリンクの場合、リンク上のポートは、以下に説明するように構築されたリンクローカルの合成48ビットMACアドレスを持つと見なされます。そのような構築されたアドレスは、MacSAとして使用される場合があります。 RBridgeチャネルメッセージがリンクローカルポートに個別にアドレス指定されている場合、ソースTRILLスイッチは、宛先TRILLスイッチポートのそのようなMACアドレスを構築するための情報を持ち、そのMACアドレスはMacDAとして使用できます。そのようなMacSAと、そのようなユニキャストMacDAまたはグループアドレス指定されたMacDAのいずれかを使用することにより、非イーサネットリンクで接続された2つのTRILLスイッチポート間でイーサネットフレームを送信できます。
These synthetic TRILL switch port MAC addresses for non-Ethernet ports are constructed as follows (and as shown in Figure 9): 0xFEFF, the nickname of the TRILL switch used in TRILL Hellos sent on that port, and the Port ID that the TRILL switch has assigned to that port. (Both the Port ID of the port on which a TRILL Hello is sent and the nickname of the sending TRILL switch appear in the Special VLANs and Flags sub-TLV [RFC7176] in TRILL IS-IS Hellos.) The resulting MAC address has the Local bit on and the Group bit off [RFC7042]. However, since there will be no Ethernet end stations on a non-Ethernet link in a TRILL campus, such synthetic MAC addresses cannot conflict on the link with a real Ethernet port address regardless of their values.
非イーサネットポートのこれらの合成TRILLスイッチポートMACアドレスは、次のように構成されます（図9に示すように）：0xFEFF、そのポートで送信されるTRILL Helloで使用されるTRILLスイッチのニックネーム、およびTRILLスイッチが使用するポートIDそのポートに割り当てられています。 （TRILL Helloが送信されるポートのポートIDと送信TRILLスイッチのニックネームの両方がTRILL IS-IS Hellosの特別なVLANおよびフラグサブTLV [RFC7176]に表示されます。）結果のMACアドレスには、ローカルビットオンとグループビットオフ[RFC7042]。ただし、TRILLキャンパスの非イーサネットリンクにはイーサネットエンドステーションがないため、そのような合成MACアドレスは、値に関係なく、リンク上で実際のイーサネットポートアドレスと競合することはできません。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFEFF | Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Synthetic MAC Address
図9：合成MACアドレス
Table 2 below gives the assigned values of the SType (Security Type) field and their meaning. Use of DTLS Pairwise Security (SType = 2) or Composite Security (SType = 3) is RECOMMENDED.
以下の表2は、SType（セキュリティタイプ）フィールドに割り当てられた値とその意味を示しています。 DTLSペアワイズセキュリティ（SType = 2）または複合セキュリティ（SType = 3）の使用をお勧めします。
While IS-IS CRYPTO_AUTH-based authentication is also specified and can be used for both pairwise and multi-destination traffic, it provides only authentication and is not considered to meet current security standards. For example, it does not provide for key negotiation; thus, its use is NOT RECOMMENDED.
IS-IS CRYPTO_AUTHベースの認証も指定されており、ペアワイズトラフィックとマルチ宛先トラフィックの両方に使用できますが、認証のみを提供し、現在のセキュリティ基準を満たしているとは見なされません。たとえば、キーネゴシエーションは提供されません。したがって、その使用は推奨されません。
The Extended RBridge Channel DTLS-based security specified in Section 4.4 and the Composite Security specified in Section 4.5 are intended for pairwise (known unicast) use. That is, the case where the M bit in the TRILL Header is zero and any Outer.MacDA is individually addressed.
セクション4.4で指定された拡張RBridgeチャネルDTLSベースのセキュリティとセクション4.5で指定された複合セキュリティは、ペアワイズ（既知のユニキャスト）での使用を目的としています。つまり、TRILLヘッダーのMビットが0で、Outer.MacDAが個別にアドレス指定されている場合です。
Multi-destination Extended RBridge Channel packets would be those with the M bit in the TRILL Header set to one or, in the native RBridge Channel case, the Outer.MacDA would be group addressed. The DTLS Pairwise Security and Composite Security STypes can also be used in the multi-destination case by serially unicasting the messages to all data-accessible RBridges (or stations in the native RBridge Channel case) in the recipient group. For TRILL Data packets, that group is specified by the Data Label; for native frames, the group is specified by the groupcast destination MAC address. It is intended to specify a true group keyed SType to secure multi-destination packets in a separate document [GroupKey].
複数の宛先の拡張RBridgeチャネルパケットは、TRILLヘッダーのMビットが1に設定されたパケットになるか、ネイティブのRBridgeチャネルの場合、Outer.MacDAがグループアドレス指定されます。 DTLSペアワイズセキュリティおよびコンポジットセキュリティSTypeは、受信者グループ内のすべてのデータアクセス可能なRBridge（またはネイティブRBridgeチャネルの場合はステーション）にメッセージをシリアルユニキャストすることにより、複数宛先の場合にも使用できます。 TRILLデータパケットの場合、そのグループはデータラベルで指定されます。ネイティブフレームの場合、グループはグループキャスト宛先MACアドレスによって指定されます。別のドキュメント[GroupKey]でマルチ宛先パケットを保護するために、真のグループキー付きSTypeを指定することを目的としています。
SType Description Reference
----- ----------- ---------
0 None Section 4.2 of RFC 7978
1 IS-IS CRYPTO_AUTH-Based Section 4.3 of RFC 7978
Authentication
2 DTLS Pairwise Security Section 4.4 of RFC 7978
3 Composite Security Section 4.5 of RFC 7978
4-14 Unassigned
15 Reserved
Table 2: SType Values
表2：SType値
In some cases, it is possible to use material derived from IS-IS CRYPTO_AUTH keying material [RFC5310] as an element of Extended RBridge Channel security. It is assumed that the IS-IS keying material is of high quality. The material actually used is derived from the IS-IS keying material as follows:
場合によっては、IS-IS CRYPTO_AUTHキーイングマテリアル[RFC5310]から派生したマテリアルを拡張RBridgeチャネルセキュリティの要素として使用することが可能です。 IS-ISキーイングマテリアルは高品質であると想定されています。実際に使用される資料は、次のようにIS-ISキーイング資料から派生しています。
Derived Material = HKDF-Expand-SHA256 ( IS-IS-key, "Extended Channel" | 0x0S, L )
派生マテリアル= HKDF-Expand-SHA256（IS-IS-key、 "Extended Channel" | 0x0S、L）
where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is as in [RFC6234], IS-IS-key is the input IS-IS keying material, "Extended Channel" is the 16-character ASCII [RFC20] string indicated without any leading length byte or trailing zero byte, 0x0S is a single byte where S is the SType for which this key derivation is being used and the upper nibble is zero, and L is the length of the output-derived material needed.
ここで「|」連結を示します。HKDFは[RFC5869]と同じで、SHA256は[RFC6234]と同じです。IS-IS-keyは入力IS-ISキー情報です。「拡張チャネル」は16文字のASCII [RFC20]文字列で、何も表示されていません先行長バイトまたは後続ゼロバイト、0x0Sは1バイトで、Sはこのキー派生が使用されているSTypeで、上部ニブルはゼロ、Lは必要な出力派生マテリアルの長さです。
Whenever IS-IS keying material is being used as above, the underlying IS-IS CRYPTO_AUTH keying material [RFC5310] might expire or be invalidated. At the time of or before such expiration or invalidation, the use of the Derived Material from the IS-IS keying material MUST cease. Continued security MAY use new derived material from currently valid IS-IS CRYPTO_AUTH keying material.
IS-ISキーイングマテリアルが上記のように使用されている場合は常に、基礎となるIS-IS CRYPTO_AUTHキーイングマテリアル[RFC5310]が期限切れになるか、無効になる可能性があります。そのような満了または無効化の時またはその前に、IS-ISキーイングマテリアルからの派生マテリアルの使用を中止しなければなりません。継続的なセキュリティは、現在有効なIS-IS CRYPTO_AUTHキーイングマテリアルからの新しい派生マテリアルを使用する場合があります。
No security services are being invoked. The length of the Security Information field (see Figure 4) is zero.
セキュリティサービスは呼び出されていません。 [セキュリティ情報]フィールド（図4を参照）の長さはゼロです。
This SType provides security for Extended RBridge Channel messages similar to that provided for [IS-IS] PDUs by the [IS-IS] Authentication TLV. The Security Information (see Figure 4) is as shown in Figure 10.
このSTypeは、[IS-IS]認証TLVによって[IS-IS] PDUに提供されるものと同様の拡張RBridgeチャネルメッセージにセキュリティを提供します。セキュリティ情報（図4を参照）は、図10に示すとおりです。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+
| Authentication Data (Variable)
+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 10: SType 1 Security Information
図10：SType 1セキュリティ情報
o RESV: Four bits that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受信時に無視する必要がある4ビット。
o Size: Set to 2 + the size of Authentication Data in bytes.
o サイズ：2 +認証データのサイズ（バイト単位）に設定します。
o Key ID: specifies the keying value and authentication algorithm that the Key ID specifies for TRILL IS-IS LSP [RFC5310] Authentication TLVs. The keying material actually used is always derived as shown in Section 4.1.
o キーID：キーIDがTRILL IS-IS LSP [RFC5310]認証TLVに指定するキーイング値と認証アルゴリズムを指定します。セクション4.1に示すように、実際に使用されるキー情報は常に導出されます。
o Authentication Data: The authentication data produced by the derived key and algorithm associated with the Key ID acting on the part of the TRILL Data packet shown. Length of the authentication data depends on the algorithm. The authentication value is included in the security information field and is treated as zero when authentication is calculated.
o 認証データ：表示されたTRILLデータパケットの一部に作用するキーIDに関連付けられた派生キーとアルゴリズムによって生成された認証データ。認証データの長さはアルゴリズムによって異なります。認証値はセキュリティ情報フィールドに含まれ、認証の計算時にゼロとして扱われます。
As show in Figure 11, the area covered by this authentication starts with the byte immediately after the TRILL Header optional Flag Word if it is present. If the Flag Word is not present, it starts after the TRILL Header Ingress Nickname. In either case, it extends to just before the TRILL Data packet link trailer. For example, for an Ethernet packet it would extend to just before the FCS.
図11に示すように、この認証でカバーされる領域は、TRILLヘッダーのオプションのフラグワードがある場合、その直後のバイトから始まります。フラグワードが存在しない場合は、TRILLヘッダー入力ニックネームの後に始まります。どちらの場合も、TRILLデータパケットリンクトレーラーの直前まで拡張されます。たとえば、イーサネットパケットの場合、FCSの直前まで拡張されます。
+-----------------------------+
| Link Header |
+-----------------------------+
| TRILL Header |
| (plus optional Flag Word) |
+-----------------------------+ ^
| Inner Ethernet Addresses | |
+-----------------------------+ .
| Data Label (VLAN or FGL) | |
+-----------------------------+ .
| RBridge Channel Header | | <-authentication
+-----------------------------+ .
| Extended Channel Header | |
| (plus Security Information)| .
+-----------------------------+ |
| Payload | .
+-----------------------------+ v
| Link Trailer |
+-----------------------------+
Figure 11: SType 1 Authentication Coverage
図11：SType 1認証カバレッジ
In the native RBridge Channel case, this authentication coverage is as specified in the above paragraph except that it starts with the RBridge-Channel Ethertype, since there is no TRILL Header, inner Ethernet addresses, or inner Data Label (see Figure 12).
ネイティブのRBridge Channelの場合、この認証カバレッジは上記の段落で指定されているとおりです。ただし、TRILLヘッダー、内部イーサネットアドレス、または内部データラベルがないため、RBridge-Channel Ethertypeで始まります（図12を参照）。
+-----------------------------+
| Ethernet Header |
+-----------------------------+ ^
| RBridge Channel Header | |
+-----------------------------+ .
| Extended Channel Header | | <-authentication
| (plus Security Information)| .
+-----------------------------+ |
| Payload | .
+-----------------------------+ v
| Ethernet Trailer |
+-----------------------------+
Figure 12: Native SType 1 Authentication Coverage
図12：ネイティブSType 1認証のカバレッジ
RBridges, which are IS-IS routers, can reasonably be expected to hold IS-IS CRYPTO_AUTH keying material [RFC5310] so that this SType can be used for RBridge Channel messages, which go between RBridges. How end stations might come to hold IS-IS CRYPTO_AUTH keying material is beyond the scope of this document. Thus, this SType might not be applicable to native RBridge Channel messages, which are between an RBridge and an end station.
IS-ISルーターであるRBridgeは、IS-IS CRYPTO_AUTHキー情報[RFC5310]を保持すると合理的に期待できるため、RBridge間を移動するRBridge ChannelメッセージにこのSTypeを使用できます。端末がIS-IS CRYPTO_AUTHキーイングマテリアルを保持する方法については、このドキュメントの範囲外です。したがって、このSTypeは、RBridgeとエンドステーションの間のネイティブRBridge Channelメッセージには適用できない場合があります。
DTLS [RFC6347] supports key negotiation and provides both encryption and authentication. The RBridge Channel Extended Header DTLS Pairwise SType uses a negotiated DTLS version that MUST NOT be less than 1.2.
DTLS [RFC6347]はキーネゴシエーションをサポートし、暗号化と認証の両方を提供します。 RBridgeチャネル拡張ヘッダーDTLSペアワイズSTypeは、1.2未満であってはならない交渉済みDTLSバージョンを使用します。
When DTLS pairwise security is used, the entire payload of the Extended RBridge Channel packet, starting just after the null Security Information and ending just before the link trailer, is one or more DTLS records [RFC6347]. As specified in [RFC6347], DTLS records MUST be limited by the path MTU, in this case so that each record fits entirely within a single Extended RBridge Channel message. A minimum path MTU can be determined from the TRILL campus minimum MTU Sz, which will not be less than 1470 bytes, by allowing for the TRILL Data packet, extended RBridge Channel, and DTLS framing overhead. With this SType, the security information between the extended RBridge Channel header and the payload is null because all the security information is in the payload area.
DTLSペアワイズセキュリティを使用する場合、拡張RBridgeチャネルパケットのペイロード全体は、ヌルのセキュリティ情報の直後からリンクトレーラーの直前まで、1つ以上のDTLSレコードです[RFC6347]。 [RFC6347]で指定されているように、DTLSレコードはパスMTUによって制限されている必要があります。この場合、各レコードは単一の拡張RBridgeチャネルメッセージ内に完全に収まるようにします。最小パスMTUは、TRILLデータパケット、拡張RBridgeチャネル、およびDTLSフレーミングオーバーヘッドを考慮して、TRILLキャンパスの最小MTU Sz（1470バイト以上）から決定できます。このSTypeでは、すべてのセキュリティ情報がペイロード領域にあるため、拡張RBridgeチャネルヘッダーとペイロードの間のセキュリティ情報はnullです。
The DTLS Pairwise keying is set up between a pair of RBridges, independent of Data Label, using messages of a priority configurable at the RBridge level, which defaults to priority 6. DTLS message types other than application_data can be the payload of an extended RBridge Channel message with a TRILL Header using any Data Label, and, for such DTLS message types, the PType in the RBridge Channel Header Extension is ignored.
DTLSペアワイズキーイングは、データラベルとは関係なく、RBridgeレベルで構成可能な優先度のメッセージを使用して、RBridgeのペア間で設定されます。デフォルトは優先度6です。application_data以外のDTLSメッセージタイプは、拡張RBridgeチャネルのペイロードにすることができます。任意のデータラベルを使用したTRILLヘッダーを含むメッセージ、およびそのようなDTLSメッセージタイプの場合、RBridgeチャネルヘッダー拡張のPTypeは無視されます。
Actual application_data sent within such a message using this SType SHOULD use the Data Label and priority as specified for that application_data. In this case, the PType value in the RBridge Channel Header Extension applies to the decrypted application_data.
このSTypeを使用してそのようなメッセージ内で送信された実際のapplication_dataは、そのapplication_dataに指定されたデータラベルと優先度を使用する必要があります（SHOULD）。この場合、RBridge Channel Header ExtensionのPType値は、復号化されたapplication_dataに適用されます。
TRILL switches that implement the extended RBridge Channel DTLS Pairwise SType SHOULD support the use of certificates for DTLS, but certificate size may be limited by the DTLS requirement that each record fit within a single message. Appropriate certificate contents are out of scope for this document.
拡張RBridge Channel DTLSペアワイズSTypeを実装するTRILLスイッチは、DTLSの証明書の使用をサポートする必要がありますが、証明書のサイズは、各レコードが単一のメッセージ内に収まるDTLS要件によって制限される場合があります。適切な証明書の内容は、このドキュメントの範囲外です。
TRILL switches that support the extended RBridge Channel DTLS Pairwise SType MUST support the use of pre-shared keys. If the psk_identity (see [RFC4279]) is two bytes, it is interpreted as a Key ID as defined in [RFC5310], and the value derived as shown in Section 4.1 from that key is used as a pre-shared key for DTLS
拡張RBridgeチャネルDTLSペアワイズSTypeをサポートするTRILLスイッチは、事前共有キーの使用をサポートする必要があります。 psk_identity（[RFC4279]を参照）が2バイトの場合、[RFC5310]で定義されているキーIDとして解釈され、セクション4.1でそのキーから導出された値がDTLSの事前共有キーとして使用されます
negotiation. A psk_identity with a length other than two bytes MAY be used to indicate other implementation-dependent pre-shared keys. Pre-shared keys used for DTLS negotiation SHOULD be shared only by the pair of endpoints; otherwise, security could be attacked by diverting messages to another endpoint holding that pre-shared key.
ネゴシエーション。 2バイト以外の長さのpsk_identityを使用して、他の実装に依存する事前共有キーを示すことができます。 DTLSネゴシエーションに使用される事前共有鍵は、エンドポイントのペアのみが共有する必要があります（SHOULD）。そうしないと、事前共有キーを保持している別のエンドポイントにメッセージを転送することにより、セキュリティが攻撃される可能性があります。
Composite Security (SType = 3) is the combination of DTLS Pairwise Security and IS-IS CRYPTO_AUTH-Based Authentication. On transmission, the DTLS record or records to be sent are secured as specified in Section 4.4 then used as the payload for the application of Authentication as specified in Section 4.3. On reception, the IS-IS CRYPTO_AUTH-based authentication is verified first and an error is returned if it fails. If the IS-IS CRYPTO_AUTH-based authentication succeeds, then the DTLS record or records are processed.
複合セキュリティ（SType = 3）は、DTLSペアワイズセキュリティとIS-IS CRYPTO_AUTHベースの認証を組み合わせたものです。送信時に、送信されるDTLSレコードはセクション4.4で指定されたように保護され、セクション4.3で指定された認証アプリケーションのペイロードとして使用されます。受信時に、IS-IS CRYPTO_AUTHベースの認証が最初に検証され、失敗するとエラーが返されます。 IS-IS CRYPTO_AUTHベースの認証が成功すると、DTLSレコードが処理されます。
An advantage of Composite Security is that the payload is authenticated and encrypted with a modern security protocol; in addition, the RBridge Channel Header and (except in the native case) preceding the MAC addresses and Data Label are provided with some authentication.
複合セキュリティの利点は、ペイロードが最新のセキュリティプロトコルで認証および暗号化されることです。さらに、RBridgeチャネルヘッダーと（ネイティブの場合を除いて）MACアドレスとデータラベルの前に、いくつかの認証が提供されます。
RBridge Channel Header Extension errors are reported like RBridge Channel errors. The ERR field is set to one of the following error codes:
RBridge Channel Header Extensionエラーは、RBridge Channelエラーと同様に報告されます。 ERRフィールドは、次のエラーコードのいずれかに設定されます。
Value RBridge Channel Error Code Meaning
----- ------------------------------------
6 Unknown or unsupported field value
7 Authentication failure
8 Error in nested RBridge Channel message
Table 3: Additional ERR Values
表3：追加のERR値
If the ERR field is 6, the SubERR field indicates the problematic field or value as shown in the table below. At this time no suberrror codes are assigned under any other ERR field value.
ERRフィールドが6の場合、SubERRフィールドは、以下の表に示すように、問題のあるフィールドまたは値を示します。現時点では、他のERRフィールド値の下にサブエラーコードは割り当てられていません。
Err SubERR Meaning (for ERR = 6)
--- ------ -----------------------
0 No Error; suberrors not allowed
1-5 (no suberrors assigned)
6 0 Reserved
6 1 Non-zero RESV4 nibble
6 2 Unsupported SType
6 3 Unsupported PType
6 4 Unknown Key ID
6 5 Unsupported Ethertype with PType = 2
6 6 Unsupported authentication algorithm for SType = 1
6 7 Non-zero SubERR with zero ERR field
7-14 (no suberrors assigned)
15 Reserved
Table 4: SubERR Values
表4：SubERR値
If o an extended RBridge Channel message is sent with security and with a payload type (PType) indicating an Ethertyped payload and the Ethertype indicates a nested RBridge Channel message and o there is an error in the processing of that nested message that results in a return RBridge Channel message with a non-zero ERR field, then that returned message SHOULD also be nested in an extended RBridge Channel message using the same type of security. In this case, the ERR field in the Extended RBridge Channel envelope is set to 8 indicating that there is a nested error in the message being tunneled back.
o拡張RBridgeチャネルメッセージがセキュリティとペイロードタイプ（PType）で送信され、Ethertypeされたペイロードを示し、EthertypeがネストされたRBridgeチャネルメッセージを示し、oネストされたメッセージの処理でエラーが発生し、結果が返される場合ゼロ以外のERRフィールドを持つRBridgeチャネルメッセージの場合、その返されるメッセージは、同じタイプのセキュリティを使用して拡張RBridgeチャネルメッセージにもネストする必要があります（SHOULD）。この場合、Extended RBridge ChannelエンベロープのERRフィールドは8に設定されており、トンネリングされるメッセージにネストされたエラーがあることを示しています。
IANA has assigned 0x004 from the range assigned by Standards Action [RFC5226] as the RBridge Channel protocol number to indicate RBridge Channel Header Extension.
IANAは、RBridge Channelヘッダー拡張を示すRBridge Channelプロトコル番号として、Standards Action [RFC5226]によって割り当てられた範囲から0x004を割り当てました。
The added "RBridge Channel Protocols" registry in the TRILL Parameters registry is as follows:
TRILL Parametersレジストリに追加された「RBridge Channel Protocols」レジストリは次のとおりです。
Protocol Description Reference
-------- -------------------------- ----------------
0x004 RBridge Channel Extension RFC 7978
IANA has created three subregistries under the "RBridge Channel Protocols" registry as detailed in the subsections below.
IANAは、以下のサブセクションで説明するように、「RBridge Channel Protocols」レジストリの下に3つのサブレジストリを作成しました。
IANA has assigned three additional code points in the "RBridge Channel Error Codes" subregistry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry. The additional entries are as shown in Table 3 in Section 5 and the "Reference" column value is "RFC 7978" for those rows.
IANAは、「リンクの透過的相互接続（TRILL）パラメータ」レジストリの「RBridgeチャネルエラーコード」サブレジストリに3つの追加コードポイントを割り当てました。追加のエントリは、セクション5の表3に示すとおりであり、これらの行の「参照」列の値は「RFC 7978」です。
IANA has created a subregistry indented under the "RBridge Channel Error Codes" registry, for RBridge Channel SubError Codes. The initial contents of this subregistry are shown in Table 4 in Section 5.1 and the fourth column "Reference" includes value "RFC 7978" for all rows. The header information is as follows:
IANAは、RBridgeチャネルサブエラーコード用に、「RBridgeチャネルエラーコード」レジストリの下にインデントされたサブレジストリを作成しました。このサブレジストリの最初の内容は、セクション5.1の表4に示されています。4番目の列「参照」には、すべての行の値「RFC 7978」が含まれています。ヘッダー情報は次のとおりです。
Registry Name: RBridge Channel SubError Codes Registration Procedures: IETF Review Reference: RFC 7978
レジストリ名：RBridge Channel SubError Codes登録手順：IETFレビューリファレンス：RFC 7978
IANA has created an "Extended RBridge Channel Payload Types" subregistry after the "RBridge Channel Protocols" registry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry. The header information is as follows:
IANAは、「リンクの透過的な相互接続（TRILL）パラメータ」レジストリの「RBridgeチャネルプロトコル」レジストリの後に「拡張RBridgeチャネルペイロードタイプ」サブレジストリを作成しました。ヘッダー情報は次のとおりです。
Registration Procedures: IETF Review Reference: RFC 7978
登録手順：IETFレビューリファレンス：RFC 7978
The initial registry content is in Table 1 in Section 3 of this document.
レジストリの初期コンテンツは、このドキュメントのセクション3の表1にあります。
IANA has created an "Extended RBridge Channel Security Types" subregistry after the "Extended RBridge Channel Payload Types" registry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry. The header information is as follows:
IANAは、「リンクの透過的な相互接続（TRILL）パラメータ」レジストリの「拡張RBridgeチャネルペイロードタイプ」レジストリの後に「拡張RBridgeチャネルセキュリティタイプ」サブレジストリを作成しました。ヘッダー情報は次のとおりです。
Registration Procedures: IETF Review Reference: RFC 7978
登録手順：IETFレビューリファレンス：RFC 7978
The initial registry content is in Table 2 in Section 4 of this document.
レジストリの初期コンテンツは、このドキュメントのセクション4の表2にあります。
The RBridge Channel Header Extension has potentially positive and negative effects on security.
RBridgeチャネルヘッダー拡張は、セキュリティにプラスとマイナスの影響を与える可能性があります。
On the positive side, it provides optional security that can be used to authenticate and/or encrypt RBridge Channel messages. Some RBridge Channel message payloads, such as BFD [RFC7175], provide their own security but where this is not true, consideration should be given, when specifying an RBridge Channel protocol, to recommending or requiring use of the security features of the RBridge Channel Header Extension.
肯定的な面では、RBridgeチャネルメッセージの認証や暗号化に使用できるオプションのセキュリティを提供します。 BFD [RFC7175]などの一部のRBridgeチャネルメッセージペイロードは独自のセキュリティを提供しますが、これが当てはまらない場合は、RBridgeチャネルプロトコルを指定するときに、RBridgeチャネルヘッダーのセキュリティ機能の使用を推奨または要求することを考慮する必要があります拡張。
On the negative side, the optional ability to tunnel more payload types, and to tunnel them between TRILL switches and to and from end stations, can increase risk unless precautions are taken. The processing of decapsulated extended RBridge Channel payloads is a place where you SHOULD NOT be liberal in what you accept. This is because the tunneling facility makes it easier for unexpected messages to pop up in unexpected places in a TRILL campus due to accidents or the actions of an adversary. Local policies SHOULD generally be strict and only accept payload types required and then only with adequate security for the particular circumstances.
マイナス面として、より多くのペイロードタイプをトンネリングし、それらをTRILLスイッチ間およびエンドステーションとの間でトンネリングするオプション機能は、予防策を講じない限り、リスクを増大させる可能性があります。カプセル化解除された拡張RBridgeチャネルペイロードの処理は、受け入れることに寛容であるべきではない場所です。これは、トンネリング機能により、事故や敵の行動により、予期しないメッセージがTRILLキャンパスの予期しない場所にポップアップしやすくなるためです。ローカルポリシーは一般に厳格であり、必要なペイロードタイプのみを受け入れ、特定の状況に対して十分なセキュリティを備えている必要があります。
See the first paragraph of Section 4 for recommendations on SType usage.
STypeの使用に関する推奨事項については、セクション4の最初の段落を参照してください。
See [RFC7457] for security considerations of DTLS.
DTLSのセキュリティに関する考慮事項については、[RFC7457]を参照してください。
If IS-IS authentication is not being used, then IS-IS CRYPTO_AUTH keying material [RFC5310] would not normally be available but that presumably represents a judgment by the TRILL campus operator that no security is needed.
IS-IS認証が使用されていない場合、IS-IS CRYPTO_AUTHキー情報[RFC5310]は通常は利用できませんが、これはおそらく、セキュリティが不要であるというTRILLキャンパスオペレーターによる判断を表します。
See [RFC7178] for general RBridge Channel security considerations and [RFC6325] for general TRILL security considerations.
RBridgeチャネルのセキュリティに関する一般的な考慮事項については[RFC7178]を、TRILLのセキュリティに関する一般的な考慮事項については[RFC6325]を参照してください。
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, 2002.
[IS-IS]国際標準化機構、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービスを提供するためのプロトコルと組み合わせて使用する、中間システムから中間システムのドメイン内ルーティング情報交換プロトコル（ISO 8473）」、ISO / IEC 10589：2002、Second Edition、2002。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<http://www.rfc-editor.org/info/rfc20>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <http://www.rfc-editor.org/info/rfc4279>.
[RFC4279] Eronen、P.、Ed。およびH. Tschofenig、Ed。、 "Pre-Shared Key Ciphersuites for Transport Layer Security（TLS）"、RFC 4279、DOI 10.17487 / RFC4279、December 2005、<http：// www.rfc-editor.org/info/rfc4279>。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310,v February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 v 2009年2月、<http://www.rfc-editor.org/info/rfc5310>。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <http://www.rfc-editor.org/info/rfc5869>.
[RFC5869] Krawczyk、H。およびP. Eronen、「HMACベースの抽出および拡張キー導出関数（HKDF）」、RFC 5869、DOI 10.17487 / RFC5869、2010年5月、<http：//www.rfc-editor .org / info / rfc5869>。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<http://www.rfc-editor.org/info/rfc6325>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172] Eastlake 3rd、D.、Zhang、M.、Agarwal、P.、Perlman、R.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、RFC 7172、DOI 10.17487 / RFC7172、2014年5月、<http://www.rfc-editor.org/info/rfc7172>。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、DOI 10.17487 / RFC7176、2014年5月、<http://www.rfc-editor.org/info/rfc7176>。
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>.
[RFC7178] Eastlake 3rd、D.、Manral、V.、Li、Y.、Aldrin、S.、and D. Ward、 "Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Support"、RFC 7178、DOI 10.17487 / RFC7178、2014年5月、<http://www.rfc-editor.org/info/rfc7178>。
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356] Ginsberg、L.、Previdi、S。、およびY. Yang、「IS-IS Flooding Scope Link State PDU（LSPs）」、RFC 7356、DOI 10.17487 / RFC7356、2014年9月、<http：// www。 rfc-editor.org/info/rfc7356>。
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>.
[RFC7780] Eastlake 3rd、D.、Zhang、M.、Perlman、R.、Banerjee、A.、Ghanwani、A.、and S. Gupta、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、andアップデート」、RFC 7780、DOI 10.17487 / RFC7780、2016年2月、<http://www.rfc-editor.org/info/rfc7780>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<http：//www.rfc- editor.org/info/rfc6234>。
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, <http://www.rfc-editor.org/info/rfc6361>.
[RFC6361]カールソン、J。およびD.イーストレイク3rd、「PPP Transparent Interconnection of Lots of Links（TRILL）Protocol Control Protocol」、RFC 6361、DOI 10.17487 / RFC6361、2011年8月、<http：//www.rfc-editor .org / info / rfc6361>。
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <http://www.rfc-editor.org/info/rfc7042>.
[RFC7042] Eastlake 3rd、D。およびJ. Abley、「IANAの考慮事項とIEEE 802パラメータのIETFプロトコルおよびドキュメントの使用法」、BCP 141、RFC 7042、DOI 10.17487 / RFC7042、2013年10月、<http：//www.rfc -editor.org/info/rfc7042>。
[RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, <http://www.rfc-editor.org/info/rfc7067>.
[RFC7067] Dunbar、L.、Eastlake 3rd、D.、Perlman、R。、およびI. Gashinsky、「Directory Assistance Problem and High-Level Design Proposal」、RFC 7067、DOI 10.17487 / RFC7067、2013年11月、<http： //www.rfc-editor.org/info/rfc7067>。
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, DOI 10.17487/RFC7175, May 2014, <http://www.rfc-editor.org/info/rfc7175>.
[RFC7175] Manral、V.、Eastlake 3rd、D.、Ward、D。、およびA. Banerjee、「多数のリンクの透過的相互接続（TRILL）：双方向転送検出（BFD）サポート」、RFC 7175、DOI 10.17487 / RFC7175、2014年5月、<http://www.rfc-editor.org/info/rfc7175>。
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <http://www.rfc-editor.org/info/rfc7457>.
[RFC7457] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムTLS（DTLS）に対する既知の攻撃の要約」、RFC 7457、DOI 10.17487 / RFC7457、2015年2月、 <http://www.rfc-editor.org/info/rfc7457>。
[AddrFlush] Hao, W., Eastlake, D., and Y. Li, "TRILL: Address Flush Message", Work in Progress, draft-ietf-trill-address-flush-00, May 2016.
[AddrFlush] Hao、W.、Eastlake、D.、Y。Li、「TRILL：Address Flush Message」、作業中、draft-ietf-trill-address-flush-00、2016年5月。
[GroupKey] Eastlake, D., "TRILL: Group Keying", Work in Progress, draft-eastlake-trill-group-keying-00, July 2016.
[GroupKey]イーストレイク、D。、「TRILL：グループキーイング」、作業中、draft-eastlake-trill-group-keying-00、2016年7月。
[TRILL-AF] Eastlake, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "TRILL: Appointed Forwarders", Work in Progress, draft-ietf-trill-rfc6439bis-03, August 2016.
[TRILL-AF] Eastlake、D.、Li、Y.、Umair、M.、Banerjee、A。、およびF. Hu、「TRILL：Appointed Forwarders」、Work in Progress、draft-ietf-trill-rfc6439bis-03 、2016年8月。
Acknowledgements
謝辞
The contributions of the following are hereby gratefully acknowledged:
以下の貢献に感謝いたします。
Stephen Farrell, Jonathan Hardwick, Susan Hares, Gayle Noble, Alvaro Retana, Yaron Sheffer, and Peter Yee.
スティーブン・ファレル、ジョナサン・ハードウィック、スーザン・ヘアズ、ゲイル・ノーブル、アルバロ・レタナ、ヤロン・シェファー、ピーター・イー。
Authors' Addresses
著者のアドレス
Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
ドナルドE.イーストレイク、第3ファーウェイテクノロジーズ155ビーバーストリートミルフォード、マサチューセッツ州01757アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Mohammed Umair IPinfusion
Mohammed Umair IPinfusion
Email: mohammed.umair2@gmail.com
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
Y I週l IH UAはテクノロジー101ソフトウェアアベニューNaNjing 210012中国
Phone: +86-25-56622310
Email: liyizhou@huawei.com