Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 6328                                        Huawei
BCP: 164                                                       July 2011
Category: Best Current Practice
ISSN: 2070-1721
        
       IANA Considerations for Network Layer Protocol Identifiers
        

Abstract

抽象

Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) Network Layer Protocol Identifier (NLPID). This document provides NLPID IANA considerations.

IETFによって開発または拡張されている一部のプロトコルは、ネットワーク層プロトコル識別子(NLPID)ISO / IEC(標準/国際電気標準会議のための国際機構)を使用しています。この文書では、NLPID IANA問題を提供します。

Status of This Memo

このメモのステータス

This memo documents an Internet Best Current Practice.

このメモはインターネット最も良い現在の練習を説明します。

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 BCPs is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース(IETF)の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ(IESG)によって公表のために承認されています。 BCPの詳細については、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/rfc6328.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6328で取得することができます。

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. NLPIDs ..........................................................3
      2.1. Sub-Ranges of the NLPID ....................................3
      2.2. Code Point 0x80 ............................................4
      2.3. NLPIDs Available for IANA Allocation .......................4
   3. IANA Considerations .............................................5
   4. Security Considerations .........................................5
   5. References ......................................................5
      5.1. Normative References .......................................5
      5.2. Informative References .....................................6
   6. Acknowledgements ................................................7
   Appendix A. Initial IANA NLPID Web Page ............................8
   Appendix B. RFC References to NLPID ................................9
        
1. Introduction
1. はじめに

Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) Network Layer Protocol Identifier (NLPID).

IETFによって開発または拡張されている一部のプロトコルは、ネットワーク層プロトコル識別子(NLPID)ISO / IEC(標準/国際電気標準会議のための国際機構)を使用しています。

The term "NLPID" is not actually used in [ISO9577], which refers to one-octet IPIs (Initial Protocol Identifiers) and SPIs (Subsequent Protocol Identifiers). While these are two logically separate kinds of one-octet identifiers, most values are usable as both an IPI and an SPI. In the remainder of this document, the term NLPID is used for such values.

用語「NLPID」は実際には1オクテットIPIの(初期プロトコル識別子)とのSPI(その後のプロトコル識別子)を指す[ISO9577]で使用されていません。これらは1オクテット識別子二論理的に別々の種類があるが、ほとんどの値は、IPIとSPIの両方として使用可能です。この文書の残りでは、用語NLPIDは、そのような値のために使用されます。

The registry of NLPID values is maintained by ISO/IEC by updating [ISO9577]. The procedure specified by ISO/IEC in that document is that an NLPID code point can be allocated without approval by ISO/IEC, as long as the code point is not in a range of values categorized for an organization other than the organization allocating the code point and as long as ISO/IEC JTC1 SC6 is informed.

NLPID値のレジストリは[ISO9577]を更新することにより、ISO / IECによって維持されます。その文書にISO / IECによって指定された手順は、NLPIDコードポイントがあれば、コードポイントコードを割り当てる組織以外の組織の分類値の範囲内にないように、ISO / IECの承認なしに割り当てることができるということですポイントおよび限り、ISO / IEC JTC1 SC6が通知されます。

This document provides NLPID IANA considerations. That is, it specifies the level of IETF approval necessary for a code point to be allocated for IETF use, the procedures to be used and actions to be taken by IANA in connection with NLPIDs, and related guidelines.

この文書では、NLPID IANA問題を提供します。すなわち、IETF IETF使用するために割り当てられるコードポイントのために必要な承認、使用される手順とNLPIDs、および関連するガイドラインに関してIANAによって取られるべきアクションのレベルを指定する、です。

[RFC5226] is incorporated herein except to the extent that there are contrary provisions in this document.

[RFC5226]は、この文書に記載されている反対の規定が存在することを除き、本明細書に組み込まれます。

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]に記載されているように解釈されます。

2. NLPIDs
2. NLPIDs

[ISO9577] defines one-octet network layer protocol identifiers that are commonly called NLPIDs, which is the term used in this document.

[ISO9577]はこの文書で使用される用語である一般NLPIDs呼ばれる1オクテットのネットワーク層プロトコル識別子を定義します。

NLPIDs are used in a number of protocols. For example, in the mar$pro.type field of the multicast address resolution server protocol [RFC2022], the ar$pro.type field of the NBMA (Non-Broadcast Multi-Access) next hop resolution protocol [RFC2332] and in the IS-IS Protocols Supported TLV [RFC1195]. See Appendix B.

NLPIDsは、多くのプロトコルで使用されています。例えば、マルチキャストアドレス解決サーバプロトコル[RFC2022]、NBMA(非ブロードキャストマルチアクセス)のARする$ pro.typeフィールドネクストホップ解決プロトコル[RFC2332]の擦傷の$ pro.typeフィールド内とでIS-ISプロトコルはTLV [RFC1195]サポートされています。付録Bを参照してください。

2.1. Sub-Ranges of the NLPID
2.1. NLPIDの小範囲

Sub-ranges of the possible NLPID values are categorized by [ISO9577] for organizations as shown below, primarily for the ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) and the ITU-T (International Telecommunication Union - Telecommunication Standardization Sector):

以下に示すように可能NLPID値のサブレンジを組織に[ISO9577]で分類され、主にISO / IEC(標準/国際電気標準会議国際機構)とITU-Tのための(国際電気通信連合 - 電気通信標準化部門) :

      Code Point  Category
      ----------  --------
      0x00        ISO/IEC
      0x01-0x0F   ITU-T
      0x10-0x3F   ITU-T Rec. X.25 and ISO/IEC 8208
      0x40-0x43   ISO/IEC
      0x44        ITU-T
      0x45-0x4F   ISO/IEC
      0x50-0x6F   ITU-T Rec. X.25 and ISO/IEC 8208
      0x70-0x7F   Joint ITU-T and ISO/IEC
      0x80        ISO/IEC (see Section 2.2)
      0x81-0x8F   ISO/IEC
      0x90-0xAF   ITU-T Rec. X.25 and ISO/IEC 8208
      0xB0-0xBF   ITU-T
      0xC0-0xCF   Potentially available for IANA (see Section 2.3)
      0xD0-0xEF   ITU-T Rec. X.25 and ISO/IEC 8208
      0xF0-0xFE   Joint ITU-T and ISO/IEC
      0xFF        Reserved for an Extension mechanism to be
                  jointly developed by ITU-T and ISO/IEC
        
2.2. Code Point 0x80
2.2. コードポイントは0x80

NLPID 0x80 is known as the IEEE (Institute of Electrical & Electronics Engineers) SNAP (SubNetwork Access Protocol) code point. It is followed by five octets, using the IEEE SNAP SAP (Service Access Point) conventions, to specify the protocol. Those conventions are described in Section 3 of [RFC5342]. In particular, it is valid for such a five-octet sequence to start with the IANA OUI (Organizationally Unique Identifier) followed by two further octets assigned by IANA as provided in [RFC5342]. The same IANA registry is used for such protocol identifiers whether they are planned to be introduced by the 0x80 NLPID or the IEEE SNAP SAP LSAPs (Link-Layer Service Access Points) (0xAAAA). Values allocated by IANA may be used in either context as appropriate.

NLPID 0x80では、IEEE(電気電子学会)SNAP(サブネットワークアクセスプロトコル)コード・ポイントとして知られています。これは、プロトコルを指定するには、IEEE SNAPのSAP(サービスアクセスポイント)の規則を使用して、5つのオクテットが続いています。これらの規則は、[RFC5342]のセクション3に記載されています。特に、それは、[RFC5342]に提供されるIANAによって割り当てられた2つの更なるオクテット続いIANA OUI(組織固有識別子)で開始するような5オクテットのシーケンスに対して有効です。同じIANAレジストリは、それらが0x80のNLPIDまたはIEEE SNAP SAPのLSAPs(リンク層サービスアクセスポイント)(0xAAAA)によって導入されるように計画されているかどうか、そのようなプロトコル識別子のために使用されています。 IANAによって割り当てられた値は、必要に応じていずれかの文脈で使用されてもよいです。

Because of the limited number of NLPID code points available for IANA allocation, use of the IEEE SNAP NLPID is RECOMMENDED rather than allocation of a new one-octet NLPID code point.

なぜならIANA割り当てのために利用可能NLPIDコードポイントの限られた数の、IEEE SNAP NLPIDを使用することはなく、新たな1オクテットNLPIDコードポイントの割り当てよりも推奨されます。

2.3. NLPIDs Available for IANA Allocation
2.3. IANAの割り当てに使用できるNLPIDs

A limited number of code points are available that could be allocated by IANA under [ISO9577]. Because of this, it is desirable, where practical, to use code point 0x80, as discussed in Section 2.2 above, or to get code points allocated from the ranges categorized to other organizations. For example, code point 0x8E was allocated for IPv6 [RFC2460], although it is in a range of code points categorized for ISO/IEC. One-byte code points are assigned to TRILL and IEEE 802.1aq as they are intended for use within the IS-IS Protocols Supported TLV [RFC1195].

コードポイントの限られた数は、[ISO9577]のIANAによって割り当てられることができることを利用可能です。このため、それは、上のセクション2.2で説明したように、コード・ポイントは0x80を使用すること、または他の組織に分類範囲から割り当てられたコードポイントを取得する場合に実用的で、望ましいです。それはISO / IECのための分類コードポイントの範囲内であるが、例えば、コードポイント0x8Eがは、IPv6の[RFC2460]のために割り当てられました。それらはIS-ISプロトコル内での使用を目的としているように、1バイトのコードポイントは、TRILLおよびIEEE 802.1aqに割り当てられている[RFC1195] TLVをサポート。

The table below, which includes two new code point allocations made by this document, shows those still available.

このドキュメントによって作られた2つの新しいコードポイント割り当てを含む以下の表は、まだ入手可能なものを示しています。

      Code Point  Status
      ----------  --------
      0xC0        TRILL [RFC6325]
      0xC1        IEEE 802.1aq [802.1aq]
      0xC2-0xCB   Available
      0xCC        IPv4 [RFC791]
      0xCD-0xCE   Available
      0xCF        PPP [RFC1661]
        
3. IANA Considerations
3. IANAの考慮事項

As long as code points are available, IANA will allocate additional values when required by applying the IETF Review policy as per [RFC5226].

[RFC5226]に従ってIETFレビューポリシーを適用することによって、必要なときに限り、コードポイントが利用可能であるように、IANAは、追加の値を割り当てます。

Whenever it allocates an NLPID, IANA will inform the IETF liaison to ISO/IEC JTC1 SC6 (Joint Technical Committee 1, Study Committee 6) [JTC1SC6], or if IANA is unable to determine that IETF liaison, the IAB. The liaison (or the IAB) will then ensure that ISO/IEC JTC1 SC6 is informed so that [ISO9577] can be updated since ISO/IEC JTC1 SC6 is the body that maintains [ISO9577]. To simplify this process, it is desirable that the IAB maintain an IETF liaison to ISO/IEC JTC1 SC6.

それはNLPIDを割り当てるたびに、IANAは[JTC1SC6] ISO / IEC JTC1 SC6(合同技術委員会1、研究会6)にIETF連絡を通知する、またはIANAは、IETF連絡、IABを決定できない場合。リエゾン(又はIAB)を[ISO9577]は、ISO / IEC JTC1 SC6が保持体[ISO9577]があるので、更新することができるように、ISO / IEC JTC1 SC6が通知されることを保証します。このプロセスを簡略化するために、IABは、ISO / IEC JTC1 SC6にIETFの連絡を維持することが望ましいです。

This document allocates the code points 0xC0 and 0xC1 as shown in Section 2.3 and IANA shall request the liaison (or the IAB) to so inform ISO/IEC JTC1 SC6.

セクション2.3に示すように、このドキュメントは、コードポイント0xC0のと0xC1を割り当て、IANAのでISO / IEC JTC1 SC6を通知する連絡(又はIAB)を要求しなければなりません。

IANA maintains a web page showing NLPIDs that have been allocated to a protocol being developed or extended by the IETF or are otherwise of interest. The initial state of the web page is as shown in Appendix A. IANA will update this web page for (1) NLPIDs allocated by IANA and (2) other allocations or de-allocations when IANA is requested to make such changes to this web page by the IETF liaison mentioned above.

IANAは、開発やIETFによって拡張されているプロトコルに割り当てられているか、そうでない場合は、関心のあるされていますNLPIDsを示すWebページを維持しています。 IANAは、このWebページへのそのような変更を行うことが要求された場合、付録A. IANAに示すように、ウェブページの初期状態は、(1)IANAによって割り当てられNLPIDs及び(2)他の割当てまたは非割当てのために、このウェブページを更新しますIETFのリエゾンは、上記によります。

4. Security Considerations
4.セキュリティについての考慮事項

This document is concerned with allocation of NLPIDs. It is not directly concerned with security.

この文書はNLPIDsの割り当てに関するものです。これは、セキュリティに直接関係はありません。

5. References
5.参考文献
5.1. Normative References
5.1. 引用規格

[ISO9577] International Organization for Standardization "Information technology - Telecommunications and Information exchange between systems - Protocol identification in the network layer", ISO/IEC TR 9577:1999, 1999-12-15.

[ISO9577]国際標準化機構「情報技術 - システム間のテレコミュニケーションと情報交換 - ネットワーク層におけるプロトコル識別」のため、ISO / IEC TR 9577:1999、1999年12月15日。

[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月。

[RFC5342] Eastlake 3rd., D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008.

[RFC5342]イーストレイク3位。、D.、 "IANAの考慮事項およびIEEE 802個のパラメータのためのIETFプロトコルの使用"、BCP 141、RFC 5342、2008年9月。

[RFC6325] Radia, P., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, July 2011.

[RFC6325]のRadia、P.、イーストレーク、D.、ダット、D.、ガイ、S.、およびA. Ghanwani、 "RBridges:基本プロトコル仕様"、RFC 6325、2011年7月。

5.2. Informative References
5.2. 参考文献

[802.1aq] Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Amendment 9: Shortest Path Bridging, Draft IEEE P802.1aq/D2.1, 21 August 2009.

[802.1aq]ローカルおよびメトロポリタンエリアネットワーク/仮想ブリッジローカルエリアネットワーク/修正9のための標準:最短パスブリッジ、ドラフトIEEE P802.1aq / D2.1、2009年8月21日。

[JTC1SC6] ISO/IEC JTC1 SC6 (International Organization for Standardization / International Electrotechnical Commission, Joint Technical Committee 1, Study Committee 6), http://www.iso.org/iso/ iso_technical_committee.html?commid=45072

[JTC1SC6] ISO / IEC JTC1 SC6(国際標準化機構/国際電気標準会議、合同技術委員会1、調査委員会の6のため)、http://www.iso.org/iso/ iso_technical_committee.html?commid = 45072

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。

[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.

[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。

[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月。

[RFC1707] McGovern, M. and R. Ullmann, "CATNIP: Common Architecture for the Internet", RFC 1707, October 1994.

[RFC1707]マクガバン、M.とR.ウルマン、 "CATNIP:インターネットのための共通のアーキテクチャ"、RFC 1707、1994年10月。

[RFC2022] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.

[RFC2022]アーミテージ、G.、RFC 2022、1996年11月 "ATM網をベースUNI 3.0 / 3.1以上のマルチキャストのサポート"。

[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.

[RFC2332]ルチアーニ、J.、カッツ、D.、Piscitello、D.、コール、B.、およびN. Doraswamy、 "NBMAネクストホップ解決プロトコル(NHRP)"、RFC 2332、1998年4月。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6(IPv6)の仕様"、RFC 2460、1998年12月。

6. Acknowledgements
6.謝辞

The contributions and support of the following people, listed in alphabetic order, are gratefully acknowledged:

アルファベット順にリストされている以下の人々の貢献とサポートは、深く感謝しています。

Ayan Banerjee, Gonzalo Camarillo, Dinesh Dutt, Don Fedyk, Alfred Hines, Russ Housley, Andrew Malis, Radia Perlman, Dan Romascanu, and Peter Ashwood-Smith.

アヤンバネルジー、ゴンサロ・カマリロ、ディネッシュダット、ドンFedyk、アルフレッド・ハインズ、ラスHousley、アンドリューMalis、ラディア・パールマン、ダンRomascanu、およびピーター・アッシュウッド・スミス。

Appendix A. Initial IANA NLPID Web Page

付録A.初期IANA NLPIDのWebページ

NLPIDs of Interest

関心のNLPIDs

      Code Point  Use
      ----------  --------
       0x00       Null
       0x08       Q.933 (RFC 2427)
       0x80       IEEE SNAP (RFC 6328)
       0x81       ISO CLNP (Connectionless Network Protocol)
       0x82       ISO ES-IS
       0x83       IS-IS (RFC 1195)
       0x8E       IPv6 (RFC 2460)
       0xB0       FRF.9 (RFC 2427)
       0xB1       FRF.12 (RF C2427)
       0xC0       TRILL (RFC 6325)
       0xC1       IEEE 802.1aq
       0xCC       IPv4 (RFC 791)
       0xCF       PPP (RFC 1661)
        

Note: According to [RFC1707], NLPID 0x70 was assigned to IPv7. That assignment appears to no longer be in effect as it is not listed in ISO/IEC 9577. IPv7 was itself a temporary code point assignment made while a decision was being made between three candidates for the next generation of IP after IPv4. Those candidates were assigned IPv6, IPv7, and IPv8. IPv6 was selected.

注:[RFC1707]によると、NLPID 0x70はIPv7に割り当てられました。その割り当ては、IPv7自体決定はIPv4の後にIPの次の世代のための3つの候補者の間で行われていた間に行われた仮のコードポイント割り当てたISO / IEC 9577.に記載されていないとして、もはや有効ではないように思われます。これらの候補者は、IPv6、IPv7、およびIPv8を割り当てられました。 IPv6が選ばれました。

Appendix B. RFC References to NLPID

NLPIDの付録B.は、RFCの参考資料

The following RFCs, issued before the end of March 2009, excluding other survey RFCs and obsolete RFCs, reference the NLPID as such:

次のRFC、2009年3月末以前に発行された他の調査RFCと時代遅れのRFCを除く、参照するようなNLPID:

RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments RFC 1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode RFC 1377 The PPP OSI Network Layer Control Protocol (OSINLCP) RFC 1661 The Point-to-Point Protocol (PPP) RFC 1707 CATNIP: Common Architecture for the Internet RFC 1755 ATM Signaling Support for IP over ATM RFC 2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks RFC 2332 NBMA Next Hop Resolution Protocol (NHRP) RFC 2337 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM RFC 2363 PPP Over FUNI RFC 2390 Inverse Address Resolution Protocol RFC 2427 Multiprotocol Interconnect over Frame Relay RFC 2590 Transmission of IPv6 Packets over Frame Relay Networks Specification RFC 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5 RFC 2955 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function RFC 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay RFC 5308 Routing IPv6 with IS-IS

RFC 1195 OSIの使用パケットモードRFC 1377でのX.25およびISDN上のTCP / IPおよびデュアル環境のRFC 1356マルチプロトコルインターコネクトでのルーティングのためのIS-IS PPP OSIネットワーク層制御プロトコル(OSINLCP)RFC 1661ザポイント・ツーPointプロトコル(PPP)RFC 1707 CATNIP:共通のアーキテクチャインターネットRFC 3.0 / 3.1ベースのATMネットワークスRFC 2332 NBMAネクストホップ解決プロトコル(NHRP)RFC 2337イントラUNI経由のマルチキャストのためのATM RFC 2022のサポートオーバーIPのための1755 ATMシグナリングのサポートのために2363 PPPオーバーFUNI RFC 2390逆アドレス解決プロトコルのRFC 2427マルチインターコネクトフレームリレーRFCを超える2590フレームリレーネットワーク仕様のRFCの上のIPv6パケットのトランスミッション2684マルチプロトコルカプセル化ATM上アダプテーションレイヤ5 RFCをスパースモードPIMのRFCを使用してATM経由ルータ間LIS IPマルチキャスト2955の監視のための管理対象オブジェクトの定義およびフレームリレーRFC 530を介してフレームリレー/ ATM PVCサービスインターワーキング機能RFC 3070レイヤ2トンネリングプロトコル(L2TP)を制御しますIS-ISと8 IPv6ルーティング

Author's Address

著者のアドレス

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