Internet Engineering Task Force (IETF) J. Carlson
Request for Comments: 6361 WorkingCode
Category: Standards Track D. Eastlake 3rd
ISSN: 2070-1721 Huawei
August 2011
PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol
リンクの多くのPPP透明な相互接続（TRILL）プロトコル制御プロトコル
Abstract
抽象
The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links.
ポイントツーポイントプロトコル（PPP）は、リンク制御プロトコル（LCP）およびポイントツーポイントリンクを介してマルチプロトコルトラフィックの使用を交渉するための方法を定義します。このドキュメントは、PPPリンクを介してルーティングブリッジ（RBridges）の間の直接通信が可能、リンク（TRILL）プロトコルの多くの透明な相互接続のためのPPPのサポートについて説明します。
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 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション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/rfc6361.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6361で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. PPP TRILL Negotiation ...........................................3
2.1. TNCP Packet Format .........................................3
2.2. TNP Packet Format ..........................................4
2.3. TLSP Packet Format .........................................5
3. TRILL PPP Behavior ..............................................5
4. Security Considerations .........................................6
5. IANA Considerations .............................................6
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
7. Acknowledgements ................................................8
The TRILL Protocol [RFC6325] defines a set of mechanisms used to communicate between RBridges. These devices can bridge together large 802 networks using link-state protocols in place of the traditional spanning tree mechanisms [RFC5556].
TRILLプロトコル[RFC6325]はRBridges間の通信に使用されるメカニズムのセットを定義します。これらのデバイスは、従来のスパニングツリーメカニズム[RFC5556]の代わりに、リンクステートプロトコルを使用して大規模なネットワーク802を一緒にブリッジすることができます。
Over Ethernet, TRILL uses two separate Ethertypes to distinguish between encapsulation headers, which carry user data, and link-state messages, which compute network topology using a protocol based on [IS-IS] [RFC6326]. These two protocols must be distinguished from one another, and segregated from all other traffic.
イーサネット上で、TRILLは[IS-IS]に基づくプロトコル[RFC6326]を使用してネットワークトポロジを計算し、ユーザデータ、及びリンクステートメッセージを運ぶカプセル化ヘッダー、区別するために2つの別個のさらにEthertypeを使用します。これらの2つのプロトコルは、互いに区別、および他のすべてのトラフィックから隔離されなければなりません。
In a network where PPP [RFC1661] is used to interconnect routers (often over telecommunications links), it may be advantageous to be able to bridge between Ethernet segments over those PPP links, and thus integrate remote networks with an existing TRILL cloud. The existing Bridging Control Protocol (BCP) [RFC3518] allows direct bridging of Ethernet frames over PPP. However, this mechanism is inefficient and inadequate for TRILL, which can be optimized for use over PPP links.
PPP [RFC1661]は（多くの場合、通信リンクを介して）ルータを相互接続するために使用されているネットワークでは、これらのPPPリンクを介してイーサネットセグメント間のブリッジ、及び従って既存のTRILLクラウドとリモートネットワークを統合することができることが有利であり得ます。既存のブリッジ制御プロトコル（BCP）[RFC3518]はPPP上のイーサネットフレームのダイレクトブリッジングを可能にします。しかし、このメカニズムは、PPPリンク上での使用に最適化することができTRILL、ため非効率的で不十分です。
To interconnect these devices over PPP links, three protocol numbers are needed, and are reserved as follows:
PPPリンク上でこれらのデバイスを相互接続するために、3つのプロトコル番号が必要とされており、次のように予約されています：
Value (in hex) Protocol Name
-------------- -------------------------------------
005d TRILL Network Protocol (TNP)
405d TRILL Link State Protocol (TLSP)
805d TRILL Network Control Protocol (TNCP)
The usage of these three protocols is described in detail in the following section.
これら3つのプロトコルの使用は、次のセクションで詳細に記載されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The TRILL Network Control Protocol (TNCP) is responsible for negotiating the use of the TRILL Network Protocol (TNP) and TRILL Link State Protocol (TLSP) on a PPP link. TNCP uses the same option negotiation mechanism and state machine as described for LCP (Section 4 of [RFC1661]).
TRILLネットワーク制御プロトコル（TNCP）は、PPPリンク上でTRILLネットワークプロトコル（TNP）とTRILLリンク状態プロトコル（TLSP）の使用を交渉する責任があります。 LCPのために記載したようTNCPは（[RFC1661]のセクション4）同じオプションネゴシエーションメカニズムと状態マシンを使用しています。
TNCP packets MUST NOT be exchanged until PPP has reached the Network-Layer Protocol phase. Any TNCP packets received when not in that phase MUST be silently ignored.
PPPはネットワーク層プロトコルフェーズに達するまでTNCPパケットが交換されてはなりません。ないその段階で静かに無視されなければならないとき、どれTNCPパケットを受信しました。
The encapsulated network layer data, carried in TNP packets, and topology information, carried in TLSP packets, MUST NOT be sent unless TNCP is in the Opened state. If a TNP or TLSP packet is received when TNCP is not in the Opened state and LCP is in the Opened state, an implementation MUST silently discard the unexpected TNP or TLSP packet.
TNCPが開状態にある場合を除きTLSPパケットで運ばれたカプセル化されたTNPパケットで運ばれたネットワーク・レイヤ・データ、およびトポロジ情報は、送信されてはいけません。 TNCPが開いた状態ではなく、LCPが開状態にあるときにTNP又はTLSPパケットを受信した場合、実装は静かに予期しないTNPまたはTLSPパケットを捨てなければなりません。
Exactly one TNCP packet is carried in the PPP Information field, with the PPP Protocol field set to hex 805d (TNCP). A summary of the TNCP packet format is shown below. The fields are transmitted from left to right.
正確に一つTNCPパケットが805d（TNCP）をHexにPPPプロトコルフィールドを設定して、PPP情報フィールドで運ばれます。 TNCPパケットフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
コード
Only LCP Code values 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, and Code-Reject) are used. All other codes SHOULD result in a TNCP Code-Reject reply.
のみLCPコード7を介して1値（設定要求、設定肯定応答、通信設定否定応答、構成拒否、終了要求を終了-ACKを、そしてコード拒否）が使用されます。他のすべてのコードはTNCPコード拒否応答を生じるはずです。
Identifier and Length
識別子と長さ
These are as documented for LCP.
LCPのために文書化されているようにこれらは。
Data
データ
This field contains data formatted as described in Section 5 of [RFC1661]. Codes 1-4 use Type-Length-Data sequences, Codes 5 and 6 use uninterpreted data, and Code 7 uses a Rejected-Packet, all as described in [RFC1661].
このフィールドは、[RFC1661]のセクション5に記載されているようにフォーマットされたデータを含みます。符号1-4利用タイプレングスデータシーケンス、コード5と6つの用途非解釈データ、およびコード7は、[RFC1661]に記載されているすべてのように、拒否・パケットを使用します。
Because no Configuration Options have been defined for TNCP, negotiating the use of the TRILL Protocol with IS-IS for the link state protocol is the default when no options are specified. A future document may specify the use of Configuration Options to enable different TRILL operating modes, such as the use of a different link state protocol.
何の設定オプションがTNCPのために定義されていないので、リンク状態プロトコルのISは、ISとTRILLプロトコルの使用を交渉することはオプションが指定されていないデフォルトです。将来の文書は、そのような別のリンク状態プロトコルの使用など、さまざまなTRILLの動作モードを有効にする設定オプションの使用を指定することもできます。
When TNCP is in the Opened state, TNP packets are sent by setting the PPP Protocol field to hex 005d (TNP) and placing TRILL-encapsulated data representing exactly one encapsulated packet in the PPP Information field.
TNCPが開状態にあるときに、TNPパケットは005D（TNPを）ヘキサするPPPプロトコルフィールドを設定し、PPP情報フィールドに正確に一つのカプセル化されたパケットを表すTRILLカプセル化データを配置することによって送信されます。
A summary of this format is provided below:
この形式の概要は以下の通りであります：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | R |M|Op-Length| Hop Count | Egress (RB2) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress (RB1) Nickname | Inner Destination MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
This is identical to the TRILL Ethernet format (Section 4.1 of [RFC6325], "Ethernet Data Encapsulation"), except that the Outer MAC (Media Access Control) header and Ethertype are replaced by the PPP headers and Protocol Field, and the Ethernet Frame Check Sequence (FCS) is not present. Both user data and End-Station Address Distribution Information (ESADI) packets are encoded in this format.
このアウターMAC（メディアアクセス制御）ヘッダとイーサタイプがPPPヘッダおよびプロトコルフィールドによって置き換えられることを除いてTRILLイーサネットフォーマット（[RFC6325]、「イーサネットデータのカプセル化」のセクション4.1）、およびイーサネットフレームと同一でありますチェックシーケンス（FCS）が存在しません。どちらのユーザーデータとエンドステーションアドレス分布情報（ESADI）パケットは、この形式でエンコードされています。
The PPP FCS follows the encapsulated data on links where the PPP FCS is in use.
PPP FCSは、PPP FCSが使用されているリンク上でカプセル化されたデータを次の。
Unlike the TRILL Ethernet encapsulation, PPP nodes do not have MAC addresses, so no outer MAC is present. (High-Level Data Link Control (HDLC) addresses MAY be present in some situations; such usage is outside the scope of this document.)
TRILLのイーサネットカプセル化とは異なり、PPPノードは、MACアドレスを持っていないので、何の外MACは存在しません。 （ハイレベルデータリンク制御（HDLC）のアドレスは、いくつかの状況では存在していてもよく、このような使用は、このドキュメントの範囲外です。）
When TNCP is in the Opened state, TLSP packets are sent by setting the PPP Protocol field to hex 405d (TLSP) and placing exactly one IS-IS Payload (Section 4.2.3 of [RFC6325], "TRILL IS-IS Frames") in the PPP Information field.
TNCPが開状態にあるときに、TLSPパケットは405D（TLSPを）ヘキサするPPPプロトコルフィールドを設定し、正確に一つを配置することによって送信されるペイロード-IS（[RFC6325]のセクション4.2.3、「TRILLは、IS-ISフレーム」） PPP情報フィールドインチ
Note that point-to-point IS-IS links have only an arbitrary circuit ID, and do not use MAC addresses for identification.
なお、ポイント・ツー・ポイントは、IS-ISリンクは任意の回路のIDを持っている、と識別のためにMACアドレスを使用しないでください。
1. On a PPP link, TRILL always uses point-to-point (P2P) Hellos. There is no need for TRILL-Hello frames, nor is per-port configuration necessary. P2P Hello messages, per "Point-to-Point IS to IS hello PDU" (Section 9.7 of [IS-IS]), do not use Neighbor IDs in the same manner as on Ethernet. However, per Section 4.2.4.1 of [RFC6325], the three-way IS-IS handshake using extended circuit IDs is required on point-to-point links, such as PPP.
PPPリンク上1.、TRILLは常にポイントツーポイント（P2P）helloを使用します。そこTRILL-ハローフレームの必要がなく、また、ポートごとの設定が必要です。あたりのP2P helloメッセージ、「ポイント・ツー・ポイントのことですハローPDU IS」（のセクション9.7は[-IS IS]）、イーサネット上と同じように隣人IDを使用しないでください。しかしながら、[RFC6325]のセクション4.2.4.1当たり、拡張回路IDを使用して三元IS-ISのハンドシェイクは、PPPなどのポイントツーポイントリンク上で必要とされます。
2. RBridges are never appointed forwarders on PPP links. If an implementation includes BCP [RFC3518], then it MUST ensure that only one of BCP or TNCP is negotiated on a link, and not both. If the peer is an RBridge, then there is no need to pass unencapsulated frames, as the link can have no TRILL-ignorant peer to be concerned about. If the peer is not an RBridge, then TNCP negotiation fails and TRILL is not used on the link.
2. RBridgesは、PPPリンクのフォワーダを任命されることはありません。実装はBCP [RFC3518]を含む場合、それはBCPまたはTNCPの一方のみが両方のリンクをネゴシエートし、されていないことを確認しなければなりません。ピアがRBridgeであれば、リンクは懸念すべきTRILL-無知なピアを持つことができないとして、カプセル化されていないフレームを渡す必要はありません。ピアがRBridgeない場合、TNCP交渉は失敗し、TRILLはリンク上で使用されていません。
3. An implementation that has only PPP links might have no Organizationally Unique Identifier (OUI) that can form an IS-IS System ID. Resolving that issue is outside the scope of this document; however, it is strongly RECOMMENDED that all TRILL implementations have at least one zero-configuration mechanism to obtain a valid System ID. Refer to ISO/IEC 10589 [IS-IS] regarding System ID uniqueness requirements.
唯一のPPPリンクを持っている3.実装では、IS-ISシステムIDを形成することができるいかなる組織固有識別子（OUI）を持っていないかもしれません。その問題を解決することは、この文書の範囲外です。しかし、強く、すべてのTRILLの実装が有効なシステムIDを取得するために、少なくとも1つのゼロコンフィギュレーションメカニズムを持っていることが推奨されます。システムIDの一意性要件に関するISO / IEC 10589 [IS-IS]を参照してください。
4. TRILL MTU-probe and TRILL MTU-ack messages (Section 4.3.2 of [RFC6325]) are not needed on a PPP link. Implementations MUST NOT send MTU-probe messages and SHOULD NOT reply to these messages. The MTU computed by LCP SHOULD be used instead. Negotiating an LCP MTU of at least 1524, to allow for an inner Ethernet payload of 1500 octets, is RECOMMENDED.
4. TRILL MTU-プローブとTRILL MTU-ACKメッセージ（[RFC6325]のセクション4.3.2）PPPリンク上で必要とされていません。実装はMTU-プローブメッセージを送ってはいけませんし、これらのメッセージに返信すべきではありません。 LCPによって計算MTUを代わりに使用してください。 1500オクテットの内部イーサネットペイロードを可能にするために、少なくとも1524のLCP MTUを交渉、推奨されています。
Existing PPP and IS-IS security mechanisms may play important roles in a network of RBridges interconnected by PPP links. At the TRILL IS-IS layer, the IS-IS authentication mechanism [RFC5304] [RFC5310] prevents fabrication of link-state control messages.
PPPを既存のセキュリティメカニズムは、PPPリンクによって相互接続さRBridgesのネットワークで重要な役割を果たしている可能性がIS-IS。 TRILLは、AT層IS-IS、IS-IS認証メカニズム[RFC5304]は[RFC5310]リンク状態制御メッセージの製造を防止します。
Not all implementations need to include specific security mechanisms at the PPP layer, for example if they are designed to be deployed only in cases where the networking environment is trusted or where other layers provide adequate security. A complete enumeration of possible deployment scenarios and associated threats and options is not possible and is outside the scope of this document. For applications involving sensitive data, end-to-end security should always be considered in addition to link security to provide security in depth.
いないすべての実装は、それらが唯一のネットワーク環境が信頼されているか、他の層は、十分なセキュリティを提供する場合には展開されるように設計されている場合、たとえば、PPP層で特定のセキュリティ・メカニズムを含める必要があります。可能な展開シナリオと関連する脅威やオプションの完全な列挙は不可能であり、この文書の範囲外です。機密データを含むアプリケーションでは、エンドツーエンドのセキュリティは常に深さのセキュリティを提供するために、セキュリティをリンクに加えて考慮されるべきです。
However, in case a PPP layer authentication mechanism is needed to protect the establishment of a link and identify a link with a known peer, implementation of the PPP Challenge Handshake Authentication Protocol (CHAP) [RFC1994] is RECOMMENDED. Should greater flexibility than that provided by CHAP be required, the Extensible Authentication Protocol (EAP) [RFC3748] is a good alternative.
しかし、場合にPPP層認証メカニズムは、リンクの確立を保護し、既知のピアとのリンクを識別するために必要とされる、PPPチャレンジハンドシェイク認証プロトコル（CHAP）[RFC1994]の実装が推奨されます。 CHAPによって提供されるより大きな柔軟性が必要とされなければならない、拡張認証プロトコル（EAP）[RFC3748]は良い代替です。
If TRILL-over-PPP packets also require confidentiality, the PPP Encryption Control Protocol (ECP) link encryption mechanisms [RFC1968] can protect the confidentiality and integrity of all packets on the PPP link.
TRILLオーバーPPPパケットはまた、機密性が必要な場合は、PPP暗号化制御プロトコル（ECP）リンク暗号化メカニズム[RFC1968]はPPPリンク上のすべてのパケットの機密性と完全性を保護することができます。
And when PPP is run over tunneling mechanisms, such as the Layer Two Tunneling Protocol (L2TP) [RFC3931], tunnel security protocols may be available.
PPPは、このようなレイヤ2トンネリングプロトコル（L2TP）などのトンネリングメカニズム、[RFC3931]の上で実行されると、トンネルのセキュリティプロトコルが利用可能であってもよいです。
For general TRILL protocol security considerations, see [RFC6325].
一般TRILLプロトコルセキュリティの考慮事項については、[RFC6325]を参照してください。
IANA has assigned three PPP Protocol field values, 005d, 405d, and 805d, as described in Section 1 of this document.
このドキュメントのセクション1で説明したようにIANAは、3つのPPPプロトコルフィールド値、005D、405D、および805dを割り当てました。
IANA has created a new "PPP TNCP Configuration Option Types" registry in the PPP-Numbers registry, using the same format as the existing "PPP LCP Configuration Option Types" registry.
IANAは、既存の「PPP LCP設定オプションの種類」レジストリと同じフォーマットを使用して、PPP-数字レジストリに新しい「PPP TNCP設定オプションの種類」レジストリを作成しました。
All TNCP Configuration Option Types except 0 are "Unassigned" and available for future use, based on "IETF Review", as described in BCP 26 [RFC5226]. Option 0 is allocated for use with Vendor-Specific Options, as described in [RFC2153].
BCP 26 [RFC5226]で説明したように0を除くすべてのTNCP設定オプションの種類は、「未割り当て」と「IETFレビュー」に基づいて、将来の使用のために用意されています。 [RFC2153]に記載されているようにオプション0は、ベンダー固有のオプションで使用するために割り当てられます。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、編、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325]パールマン、R.、イーストレーク3、D.、ダット、D.、ガイ、S.、およびA. Ghanwani、 "ルーティングブリッジ（RBridges）：基本プロトコル仕様"、RFC 6325、2011年7月。
[IS-IS] International Organization for Standardization, "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, November 2002.
2002：[IS-IS]国際標準化機構、ISO / IEC 10589「の中間システムイントラドメインへの中間システムが接続モード・ネットワーク・サービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための情報交換プロトコルをrouteingします」 、第2版、2002年11月。
[RFC1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[RFC1968]マイヤー、G.、 "PPP暗号化制御プロトコル（ECP）"、RFC 1968、1996年6月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]シンプソン、W.、 "PPPチャレンジハンドシェイク認証プロトコル（CHAP）"、RFC 1994、1996年8月。
[RFC2153] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
[RFC2153]シンプソン、W.、 "PPPベンダー拡張機能"、RFC 2153、1997年5月。
[RFC3518] Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)", RFC 3518, April 2003.
[RFC3518]東山、M.、ベイカー、F.、およびT.リャオ、 "ポイントツーポイントプロトコル（PPP）ブリッジ制御プロトコル（BCP）"、RFC 3518、2003年4月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]ラウ、J.、エド、Townsley、M.、エド、およびI. Goyret、エド、 "レイヤ2トンネリングプロトコル - バージョン3（L2TPv3の）"。。。、RFC 3931、2005年3月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]李、T.、およびR.アトキンソンは、 "IS-IS暗号認証"、RFC 5304、2008年10月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310]はバティア、M.、Manral、V.は、李、T.、アトキンソン、R.、ホワイト、R.、およびM. Fantoは、 "IS-ISジェネリック暗号認証"、RFC 5310、2009年2月。
[RFC5556] Touch, J. and R. Perlman, "Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement", RFC 5556, May 2009.
[RFC5556]タッチ、J.とR.パールマン、 "リンクの多くの透明な相互接続（TRILL）：問題と適用性声明"、RFC 5556、2009年5月。
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011.
[RFC6326]イーストレイク、D.、バネルジー、A.、ダット、D.、パールマン、R.、およびA. Ghanwani、 "リンクのIS-ISの（TRILL）の使用の多くの透明な相互接続"、RFC 6326、2011年7月。
The authors thank Jari Arkko, Stewart Bryant, Ralph Droms, Linda Dunbar, Adrian Farrel, Stephen Farrell, Radia Perlman, Mike Shand, and William A. Simpson for their comments and help.
作者は彼らのコメント、助けをヤリArkko、スチュワートブライアント、ラルフDroms、リンダ・ダンバー、エードリアンファレル、スティーブン・ファレル、ラディア・パールマン、マイク・シャンド、およびウィリアムA.シンプソンに感謝します。
Authors' Addresses
著者のアドレス
James Carlson WorkingCode 25 Essex Street North Andover, MA 01845 USA
ジェームズ・カールソンWorkingCode 25エセックスストリートノースアンドーヴァー、MA 01845 USA
Phone: +1-781-301-2471 EMail: carlsonj@workingcode.com
電話：+ 1-781-301-2471 Eメール：carlsonj@workingcode.com
Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク第三華為技術155ビーバー通りミルフォード、MA 01757 USA
Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com
電話：+ 1-508-333-2270 Eメール：d3e3e3@gmail.com