[要約] RFC 6361は、PPP Transparent Interconnection of Lots of Links（TRILL）プロトコル制御プロトコルに関するものであり、TRILLネットワークでのPPPセッションの制御を提供します。目的は、TRILLネットワーク内のPPPセッションの確立、維持、および終了を効率的に管理することです。
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
多くのリンク（TRILL）プロトコル制御プロトコルのPPP透明な相互接続
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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]は、Rbridge間の通信に使用される一連のメカニズムを定義します。これらのデバイスは、従来のスパニングツリーメカニズム[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は2つの個別の倫理を使用して、[IS-IS] [RFC6326]に基づいたプロトコルを使用してネットワークトポロジを計算するリンク状態のメッセージとリンク状態メッセージを伝達するカプセル化ヘッダーを区別します。これらの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を超えるイーサネットフレームの直接ブリッジが可能になります。ただし、このメカニズムは非効率的であり、Trillにとって不十分であり、PPPリンクを介して使用するために最適化できます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 Network Control Protocol（TNCP）は、PPPリンクでTrill Network Protocol（TNP）およびTrill Link State Protocol（TLSP）の使用を交渉する責任があります。TNCPは、LCP（[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.
TNCPパケットは、PPPがネットワーク層プロトコルフェーズに達するまで交換してはなりません。そのフェーズにない場合に受信した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.
TNPパケットで運ばれるカプセル化されたネットワークレイヤーデータ、およびTLSPパケットで運ばれるトポロジ情報は、TNCPが開いた状態にない限り送信してはなりません。TNCPがオープン状態にない場合にTNPまたはTLSPパケットが受信され、LCPがオープン状態にある場合、実装は予期しない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.
PPPプロトコルフィールドがHEX 805D（TNCP）に設定されたPPP情報フィールドには、正確に1つのTNCPパケットが配信されます。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コード値1〜7（configure-request、configure-ack、configure-nak、configure-reject、terminate-request、exterinate-cack、code-reject）のみが使用されます。他のすべてのコードの結果、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は、タイプ長DATAシーケンスを使用し、コード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パケットは、PPPプロトコルフィールドをHEX 005D（TNP）に設定し、PPP情報フィールドに1つのカプセル化されたパケットを表す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（メディアアクセス制御）ヘッダーとethertypeが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パケットはPPPプロトコルフィールドをHEX 405D（TLSP）に設定し、正確に1つのIS-ISペイロードを配置して送信されます（[RFC6325]のセクション4.2.3、「Trill IS-IS Frames」）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.
1. PPPリンクでは、Trillは常にポイントツーポイント（P2P）Hellosを使用します。Trill-Helloフレームは必要ありませんし、ポートごとの構成も必要ありません。P2P Hello Messages、「ポイントツーポイントはIS Hello PDU」（[IS-IS]のセクション9.7）で、イーサネットと同じ方法でネイバーIDを使用しません。ただし、[RFC6325]のセクション4.2.4.1に従って、PPPなどのポイントツーポイントリンクでは、拡張回路IDを使用した3方向IS ISハンドシェイクが必要です。
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の1つのみがリンクで交渉され、両方ではなく交渉されることを保証する必要があります。ピアがRbridgeである場合、リンクには心配するトリルに無知なピアがないため、カプセル化されていないフレームを渡す必要はありません。ピアが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.
3. PPPリンクのみを備えた実装には、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. PPPリンクでは、Trill MTU-ProbeおよびTrill MTU-ackメッセージ（[RFC6325]のセクション4.3.2）は必要ありません。実装は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およびIS-ISセキュリティメカニズムは、PPPリンクによって相互接続されたRbridgesのネットワークで重要な役割を果たす可能性があります。Trill 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-Over-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.
また、レイヤー2トンネリングプロトコル（L2TP）[RFC3931]などのトンネルメカニズムを介してPPPが実行されると、トンネルセキュリティプロトコルが利用可能になる場合があります。
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.
IANAは、このドキュメントのセクション1で説明されているように、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-Numbersレジストリに新しい「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].
0を除くすべてのTNCP構成オプションタイプは、BCP 26 [RFC5226]で説明されているように、「IETFレビュー」に基づいて、「IETFレビュー」に基づいて「未割り当て」であり、将来使用できます。[RFC2153]で説明されているように、オプション0はベンダー固有のオプションで使用するために割り当てられます。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、ed。、「ポイントツーポイントプロトコル（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、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.
[IS-IS]国際標準化機関、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと併せて使用するためのドメイン内型システム内領域内領域内領域内領域内領域内領域内領域内部情報交換プロトコル」、ISO/IEC 10589：2002、第2版、2002年11月。
[RFC1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[RFC1968] Meyer、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.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「Extensible認証プロトコル（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] Lau、J.、ed。、Ed。、Townsley、M.、ed。、およびI. Goyret、ed。、「レイヤー2トンネリングプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年3月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「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] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R.、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、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] Touch、J。およびR. Perlman、「多くのリンクの透明な相互接続（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] Eastlake、D.、Banerjee、A.、Dutt、D.、Perlman、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.
著者は、Jari Arkko、Stewart Bryant、Ralph Droms、Linda Dunbar、Adrian Farrel、Stephen Farrell、Radia Perlman、Mike Shand、William A. Simpsonのコメントと助けに感謝します。
Authors' Addresses
著者のアドレス
James Carlson WorkingCode 25 Essex Street North Andover, MA 01845 USA
ジェームズカールソンワーキングコード25エセックスストリートノースアンドーバー、マサチューセッツ州01845 USA
Phone: +1-781-301-2471
EMail: carlsonj@workingcode.com
Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク3rd Huawei Technologies 155 Beaver Street Milford、MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com