[要約] 要約：RFC 2336は、古典的なIPとARPをATMからNHRPへの移行するためのガイドラインを提供しています。 目的：このRFCの目的は、ATMネットワークでのIPとARPの使用を効果的にNHRPに移行するための手順とプロトコルを提供することです。
Network Working Group J. Luciani
Request for Comments: 2336 Bay Networks
Category: Informational July 1998
Classical IP and ARP over ATM to NHRP Transition
従来のIPおよびARP over ATMからNHRPへの移行
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document describes methods and procedures for the graceful transition from an ATMARP LIS[1] to an NHRP LIS[2] network model over ATM.
このドキュメントでは、ATMARP LIS [1]からNHRP LIS [2]ネットワークモデルへのATMによる適切な移行の方法と手順について説明します。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [6].
このドキュメントに記載されているキーワードは、必須、必須、必須、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONALであり、[6]で説明されているように解釈されます。
ATMARP defines an initial application of classical IP and ARP in an ATM network environment configured as a LIS[1]. ATMARP only considers application of ATM as a direct replacement for the "wires" and local LAN segments connecting IP end-stations and routers operating in the "classical" LAN-based paradigm.
ATMARPは、LISとして構成されたATMネットワーク環境における従来のIPおよびARPの初期アプリケーションを定義します[1]。 ATMARPは、「古典的な」LANベースのパラダイムで動作するIPエンドステーションとルーターを接続する「ワイヤー」とローカルLANセグメントの直接の代替として、ATMの適用のみを考慮します。
The NBMA Next Hop Resolution Protocol (NHRP) allows a source station (a host or router), wishing to communicate over a Non-Broadcast, Multi-Access (NBMA) subnetwork, to determine the internetworking layer addresses and NBMA addresses of suitable "NBMA next hops" toward a destination station. If the destination is connected to the NBMA subnetwork and direct communication is administratively allowed, then the NBMA next hop is the destination station itself. Otherwise, the NBMA next hop is the egress router from the NBMA subnetwork that is "nearest" to the destination station. For the purposes of this document, the NBMA network is of type ATM.
NBMAネクストホップ解決プロトコル（NHRP）を使用すると、非ブロードキャストマルチアクセス（NBMA）サブネットワークを介して通信することを望むソースステーション（ホストまたはルーター）が、適切な "NBMAのインターネットワーキングレイヤーアドレスとNBMAアドレスを決定できます。ネクストホップ」を宛先ステーションに向けて。宛先がNBMAサブネットワークに接続され、直接通信が管理上許可されている場合、NBMAネクストホップは宛先ステーション自体です。それ以外の場合、NBMAネクストホップは、宛先ステーションに「最も近い」NBMAサブネットワークからの出口ルーターです。このドキュメントでは、NBMAネットワークのタイプはATMです。
It is reasonable to expect that ATMARP Clients and NHRP Clients will initially coexist within a LIS. Thus, it is necessary to define a graceful transition, including a period of coexistance, from the use of ATMARP to the use of NHRP for address resolution in the LIS [1][2]. In short, NHSs will be required to respond to ATMARP Client queries in a fashion which will permit continued use of the ATMARP Client within the LIS during the ATMARP to NHRP transition period. Note that this document places no protocol requirements upon ATMARP[1] servers.
ATMARPクライアントとNHRPクライアントがLIS内で最初に共存することを期待することは合理的です。したがって、ATMARPの使用からLISでのアドレス解決のためのNHRPの使用への共存期間を含む、適切な移行を定義する必要があります[1] [2]。つまり、NHSは、ATMARPからNHRPへの移行期間中にLIS内でATMARPクライアントを継続して使用できるように、ATMARPクライアントクエリに応答する必要があります。このドキュメントでは、ATMARP [1]サーバーにプロトコル要件を課していないことに注意してください。
For the following, it will be assumed that the reader is familiar with the terminology as described in [1][2][3].
以下では、読者が[1] [2] [3]で説明されている用語に精通していることを前提としています。
If NHRP is to be used in a LIS then only NHSs will be used in the LIS; that is, there will not be a mixture of NHSs and ATMARP servers within the same LIS. Since ATMARP servers will not be able to understand NHCs and since, as described below, NHSs will respond to ATMARP Clients, this is a reasonable simplifying restriction.
NHRPがLISで使用される場合、NHSのみがLISで使用されます。つまり、同じLIS内にNHSとATMARPサーバーが混在することはありません。 ATMARPサーバーはNHCを理解できません。また、以下で説明するように、NHSはATMARPクライアントに応答するため、これは合理的な簡略化の制限です。
This document will only address SVC based environments and will not address PVC environments. This document will refer only to ATM AAL5 as the NBMA and IP as the protocol layer since ATMARP only addresses these protocols.
このドキュメントでは、SVCベースの環境についてのみ取り上げ、PVC環境については扱いません。 ATMARPはこれらのプロトコルのみを扱うため、このドキュメントでは、ATM AAL5のみをNBMAとして、IPをプロトコルレイヤーとして参照します。
If NHRP Servers (NHS) are to be deployed in a LIS which contains both ATMARP Clients and NHRP Clients then NHSs MUST respond to ATMARP_Requests sent by ATMARP Clients in the same fashion that an ATMARP Server would respond as described in [1]. To do this, the NHS MUST first recognize the LLC/SNAP ATMARP code point with LLC=0xAA-AA-03, OUI=0x00-00-00, and ethertype=0x08-06. Further, the NHS MUST recognize the packet formats described in Section 8.7 of [1]. However, since this document does not extend to PVC environments,
ATMARPクライアントとNHRPクライアントの両方を含むLISにNHRPサーバー（NHS）を配備する場合、NHSは、ATMARPサーバーが[1]で説明したように応答するのと同じ方法で、ATMARPクライアントが送信したATMARP_Requestsに応答する必要があります。これを行うには、NHSは最初にLLC = 0xAA-AA-03、OUI = 0x00-00-00、およびethertype = 0x08-06でLLC / SNAP ATMARPコードポイントを認識する必要があります。さらに、NHSは[1]のセクション8.7で説明されているパケット形式を認識しなければなりません（MUST）。ただし、このドキュメントはPVC環境には適用されないため、
NHSs MUST only receive/respond to values of ar$op of 1,2,10 (Decimal). If an NHS receives an ATMARP message with ar$op values other than those previously noted then the NHS MUST discard the packet and MUST NOT take any further action.
NHSは、1,2,10（10進数）のar $ opの値のみを受信/応答する必要があります。 NHSが前述の値以外のar $ op値を含むATMARPメッセージを受信した場合、NHSはパケットを破棄し、それ以上のアクションを実行してはなりません（MUST NOT）。
When an NHS receives a valid (as defined in the previous paragraph) ATMARP_Request packet, the NHS MUST follow the rules described in Section 8.4 of [1] with the following additional processing:
NHSが有効な（前の段落で定義された）ATMARP_Requestパケットを受信すると、NHSは[1]のセクション8.4で説明されている規則に従い、次の追加処理を実行する必要があります。
1) When an ATMARP_Request causes a new table entry in the NHS for an ATMARP Client, that table entry MUST be marked as being of type "ATMARP" so that it can be differentiated from an NHRP sourced entry.
1）ATMARP_Requestにより、ATMARPクライアントのNHSに新しいテーブルエントリが発生する場合、NHRPソースのエントリと区別できるように、そのテーブルエントリをタイプ "ATMARP"としてマークする必要があります。
2) An ATMARP_Request MUST NOT cause an ATMARP_Reply to be sent if that ATMARP_Request contains an off-LIS protocol address. This should never happen because the IP stack on the requesting machine should automatically send the packet to the default router. If this does occur then the ATMARP_Request MUST cause an ATMARP_NAK to be sent to the originator.
2）ATMARP_RequestにオフLISプロトコルアドレスが含まれている場合、ATMARP_RequestがATMARP_Replyを送信してはなりません（MUST NOT）。要求側のマシンのIPスタックがデフォルトのルーターにパケットを自動的に送信する必要があるため、これが発生することはありません。これが発生する場合、ATMARP_RequestはATMARP_NAKを発信者に送信する必要があります。
In [1], an ATMARP_Request packet also serves as a registraion/registration-update packet which would cause a server to add an entry to a server's cache or to update a previously existing entry. When an NHS receives an ATMARP_Request which causes the creation of a new cache entry in the NHS or updates an existing entry then that cache entry will have a holding time of 20 minutes (this is the default value in [1]).
[1]では、ATMARP_Requestパケットは、サーバーがサーバーのキャッシュにエントリを追加したり、既存のエントリを更新したりする登録/登録更新パケットとしても機能します。 NHSがATMARP_Requestを受信すると、NHSに新しいキャッシュエントリが作成されるか、既存のエントリが更新されます。そのキャッシュエントリの保持時間は20分です（これは[1]のデフォルト値です）。
An NHS receiving an NHRP Resolution Request MUST NOT send a positive NHRP Resolution Reply for a station which registered via ATMARP if the station sending the NHRP Resolution Request is outside the LIS of the station which registered itself via ATMARP. This is because the station which registered via ATMARP is almost certainly not prepared to accept a cut-through. When this occurs, the replying NHS must send NHRP Resolution Reply which contains a CIE code of "4 - Administratively Prohibited" as described in [2]. This type of reply does not preclude the station sending the NHRP Resolution Request from sending its data packets along the routed path but it does preclude that station from setting up a cut-through VC.
NHRP解決要求を受信するNHSは、NHRP解決要求を送信するステーションがATMARPを介して自身を登録したステーションのLISの外にある場合、ATMARPを介して登録したステーションに対して正のNHRP解決応答を送信してはなりません（MUST NOT）。これは、ATMARP経由で登録したステーションがカットスルーを受け入れる準備ができていないためです。これが発生すると、応答するNHSは、[2]で説明されているように、「4-管理上禁止」のCIEコードを含むNHRP解決応答を送信する必要があります。このタイプの応答は、NHRP解決要求を送信するステーションがルーティングされたパスに沿ってデータパケットを送信することを妨げませんが、そのステーションがカットスルーVCをセットアップすることを妨げます。
Since NHRP servers may work in a multi-server environment on a per LIS basis during the transition, it is necessary to know how cache synchronization occurs. These rules may be found in [5].
NHRPサーバーは移行中にLISごとにマルチサーバー環境で動作する可能性があるため、キャッシュ同期がどのように発生するかを知る必要があります。これらのルールは[5]にあります。
Not all of the security issues relating to IP over ATM are clearly understood at this time, due to the fluid state of ATM specifications, newness of the technology, and other factors.
ATM仕様の流動性、テクノロジーの新しさ、およびその他の要因により、IP over ATMに関連するすべてのセキュリティ問題が現時点で明確に理解されているわけではありません。
It is believed that ATM and IP facilities for authenticated call management, authenticated end-to-end communications, and data encryption will be needed in globally connected ATM networks. Such future security facilities and their use by IP networks are beyond the scope of this memo.
認証されたコール管理、認証されたエンドツーエンド通信、およびデータ暗号化のためのATMおよびIP機能は、グローバルに接続されたATMネットワークで必要になると考えられています。そのような将来のセキュリティ設備とIPネットワークによるそれらの使用は、このメモの範囲を超えています。
There are known security issues relating to host impersonation via the address resolution protocols used in the Internet [4]. No special security mechanisms have been added to ATMARP. While NHRP supplies some mechanisms for authentication, ATMARP does not. Since any security mechanism is only as good as its weakest link, it should be assumed that when NHRP and ATMARP exist with a given LIS, the security of a combination is only as good as that supplied by ATMARP.
インターネットで使用されるアドレス解決プロトコルを介したホストの偽装に関連する既知のセキュリティ問題があります[4]。 ATMARPに特別なセキュリティメカニズムは追加されていません。 NHRPは認証のためのいくつかのメカニズムを提供しますが、ATMARPは提供しません。どのセキュリティメカニズムも最も弱いリンクと同じくらい良いので、NHRPとATMARPが特定のLISに存在する場合、組み合わせのセキュリティはATMARPによって提供されるものと同じくらい良いと見なす必要があります。
References
参考文献
[1] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
[1] Laubach、M.およびJ. Halpern、「Classical IP and ARP over ATM」、RFC 2225、1998年4月。
[2] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[2] Luciani、J.、Katz、D.、Piscitello、D.、Cole、B。、およびN. Doraswamy、「NBMA Next Hop Resolution Protocol（NHRP）」、RFC 2332、1998年4月。
[3] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.
[3] Luciani、J.、Armitage、G.、Halpern、J。およびN. Doraswamy、「Server Cache Synchronization Protocol（SCSP）」、RFC 2334、1998年4月。
[4] Security Problems in the TCP/IP Protocol Suite, Bellovin, ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989.
[4] TCP / IPプロトコルスイートのセキュリティの問題、Bellovin、ACM Computer Communications Review、Vol。 19、Issue 2、32-48頁、1989年。
[5] Luciani, J., "A Distributed NHRP Service Using SCSP", RFC 2335, April 1998.
[5] Luciani、J。、「SCSPを使用した分散NHRPサービス」、RFC 2335、1998年4月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[6] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月。
Acknowledgments
謝辞
Thanks to Andy Malis for his input on this draft.
このドラフトに関する情報を提供してくれたAndy Malisに感謝します。
Author's Addresses
著者のアドレス
James V. Luciani Bay Networks 3 Federal Street Mail Stop: BL3-03 Billerica, MA 01821 Phone: +1 978 916 4734 Email: luciani@baynetworks.com
James V. Luciani Bay Networks 3 Federal Street Mail Stop：BL3-03 Billerica、MA 01821 Phone：+1 978 916 4734 Email：luciani@baynetworks.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。