RFC2336 日本語訳
2336 Classical IP to NHRP Transition. J. Luciani. July 1998. (Format: TXT=10500 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Luciani Request for Comments: 2336 Bay Networks Category: Informational July 1998
Lucianiがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2336年のベイネットワークスカテゴリ: 情報の1998年7月
Classical IP and ARP over ATM to NHRP Transition
NHRP変遷への気圧での古典的なIPとARP
Status of this Memo
この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)インターネット協会(1998)。 All rights reserved。
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.
このドキュメントはATMの上の優雅なATMARP LIS[1]からNHRP LIS[2]ネットワークモデルまでの変遷のための方法と手順について説明します。
1. Introduction
1. 序論
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].
キーワードが解釈しなければならない、本書では現れるとき、[6]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
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[1]として構成されたATMネットワーク環境で古典的なIPとARPの初期のアプリケーションを定義します。 ATMARPは、ATMのアプリケーションが「ワイヤ」とのダイレクト交換と、IP端ステーションをつなげる地方のLANセグメントとLANベースの「古典的な」パラダイムで作動するルータであるとみなすだけです。
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 Next Hop Resolutionプロトコル(NHRP)は発信局(ホストかルータ)を許容します、目的地ステーションに向かって適当な「次のNBMAは跳ぶ」インターネットワーキング層のアドレスとNBMAアドレスを決定するためにNon-放送、Multi-アクセス(NBMA)サブネットワークの上で交信することを願っていて。 目的地がNBMAサブネットワークにつなげられて、ダイレクトコミュニケーションが行政上許容されているなら、次のNBMAが飛び越すその時による目的地ステーション自体です。 さもなければ、“nearest"であるNBMAサブネットワークから目的地ステーションまでNBMA次ホップは出口ルータです。 このドキュメントの目的のために、NBMAネットワークはタイプATMへのものです。
Luciani Informational [Page 1] RFC 2336 Classical IP and ARP over ATM to NHRP July 1998
NHRP1998年7月への気圧でのLucianiの情報[1ページ]のRFC2336の古典的なIPとARP
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 ClientsとNHRP Clientsが初めはLISの中に共存すると予想するのは妥当です。 したがって、優雅な変遷を定義するのが必要です、coexistanceの期間を含んでいて、ATMARPの使用からNHRPのLIS[1][2]でのアドレス解決の使用まで。 要するに、NHSsはATMARPの間にLISの中でATMARP Clientの継続的な使用をNHRP過渡期に可能にするファッションでATMARP Client質問に応じなければならないでしょう。 このドキュメントがプロトコル要件を全く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]で説明されるように用語に詳しいと思われるでしょう。
2. Service Requirements
2. サービス要件
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で使用されるつもりであると、NHSsだけがLISで使用されるでしょう。 すなわち、同じLISの中にNHSsとATMARPサーバの混合物がないでしょう。 ATMARPサーバがNHCsを理解できないで、NHSsが以下で説明されるようにATMARP Clientsに応じるので、これは合理的な簡素化制限です。
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がこれらのプロトコルを記述するだけであるのでプロトコルとしてのNBMAとIPが層にされるとき、このドキュメントはATM AAL5だけを参照するでしょう。
2.1 NHRP Server Requirements
2.1 NHRPサーバ要件
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,
NHRP Servers(NHS)がATMARP ClientsとNHRP Clientsの両方を含むLISで配備されるつもりであるなら、NHSsは、ATMARP Serverが[1]で説明されるように応じると同じファッションでATMARP Clientsによって送られたATMARP_Requestsに応答しなければなりません。 これをするために、NHS MUSTは最初に、LLC=0xAA- AA-03があるLLC/SNAP ATMARPコード・ポイント、OUI=0x00 00-00、およびethertype=0×08-06を認識します。 さらに、NHS MUSTは[1]のセクション8.7で説明されたパケット・フォーマットを認識します。 しかしながら、このドキュメントが達しないので、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.
NHSsは1、2、10(10進)のオプアートをar$の値に受けるだけでよいか、または反応させるだけでよいです。 NHSがar$でATMARPメッセージを受け取るなら、それら以外のオプアート値は、その時、以前に、NHS MUSTがパケットを捨てることに注意して、少しのさらなる行動も取ってはいけません。
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 MUSTは[1]のセクション8.4で以下の追加処理で説明された規則に従います:
Luciani Informational [Page 2] RFC 2336 Classical IP and ARP over ATM to NHRP July 1998
NHRP1998年7月への気圧でのLucianiの情報[2ページ]のRFC2336の古典的なIPとARP
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 Clientのために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を送らせてはいけません。 要求マシンの上の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パケットはサーバがサーバのキャッシュにエントリーを加えるか、または以前に既存のエントリーをアップデートすることを引き起こす登録registraion/アップデートパケットとして機能します。 NHSがNHSでの新しいキャッシュエントリーの創造を引き起こすか、またはその時既存のエントリーをアップデートするATMARP_Requestを受けるとき、そのキャッシュエントリーには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 Resolution Requestを受けるNHSはLISの外にNHRP Resolution Requestを送るステーションがあるならATMARPを通して登録されたステーションに積極的なNHRP Resolution Replyを送ってはいけません。 これはATMARPを通して登録されたステーションが確かに通じて切れると受け入れるようにほとんど準備されないからです。 これが起こると、返答しているNHSは[2]で説明されるように「4--行政上禁止されている」CIEコードを含むNHRP Resolution Replyを送らなければなりません。 このタイプの回答は発送された経路に沿ってデータ・パケットを送るのからNHRP Resolution Requestを送るステーションを排除しませんが、それは、深く切っているVCをセットアップするので、そのステーションを排除します。
2.2 Multi-server environments
2.2 マルチサーバ環境
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基礎あたりのaに動作するかもしれないので、キャッシュ同期がどのように起こるかを知るのが必要です。 これらの規則は[5]で見つけられるかもしれません。
3. Security Considerations
3. セキュリティ問題
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に関連する安全保障問題のすべてがこのとき明確に理解されているというわけではありません、ATM仕様、技術の新しさの流体状態、および他の要素のため。
Luciani Informational [Page 3] RFC 2336 Classical IP and ARP over ATM to NHRP July 1998
NHRP1998年7月への気圧でのLucianiの情報[3ページ]のRFC2336の古典的なIPとARP
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.のアルペルンと、「気圧での古典的なIPとARP」、RFC2225、4月1998日
[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.、キャッツ、D.、Piscitello、D.、コール、B.、およびN.Doraswamy、「次のNBMAは解決プロトコル(NHRP)を飛び越します」、RFC2332、1998年4月。
[3] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.
[3]LucianiとJ.とアーミテージとG.とアルペルンとJ.とN.Doraswamy、「サーバキャッシュ同期プロトコル(SCSP)」、RFC2334、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プロトコルSuite、Bellovin、ACMコンピュータCommunications Review、Vol.19、Issue2、ページのセキュリティProblems 32-48, 1989.
[5] Luciani, J., "A Distributed NHRP Service Using SCSP", RFC 2335, April 1998.
[5]Luciani、J.、「SCSPを使用する分配されたNHRPサービス」、RFC2335、1998年4月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
Acknowledgments
承認
Thanks to Andy Malis for his input on this draft.
この草稿に関する彼の意見をアンディ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
ジェームスV.Lucianiベイネットワークス3の連邦政府の通りメール停止: BL3-03ビルリカ、MA 01821は以下に電話をします。 +1 4734年の978 916メール: luciani@baynetworks.com
Luciani Informational [Page 4] RFC 2336 Classical IP and ARP over ATM to NHRP July 1998
NHRP1998年7月への気圧でのLucianiの情報[4ページ]のRFC2336の古典的なIPとARP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Luciani Informational [Page 5]
Luciani情報です。[5ページ]
一覧
スポンサーリンク