[要約] RFC 2583は、Next Hop Client（NHC）開発者向けのガイドラインであり、NHCの設計と実装に関する指針を提供します。このRFCの目的は、NHCの開発者が効果的なNHCを作成するためのベストプラクティスを理解し、適切なネットワーク接続を確立することです。
Network Working Group R. Carlson
Request for Comments: 2583 ANL
Category: Informational L. Winkler
ANL
May 1999
Guidelines for Next Hop Client (NHC) Developers
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). It assumes that the clients are directly connected to an ATM based NBMA network. The same principles will apply to clients connected to other types of NBMA networks. The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. The NHC is capable of sending NHRP requests to a Next Hop Resolution Protocol Server (NHS) to resolve both inter and intra LIS addresses. The NHS reply may be positive (ACK) indicating a short-cut path is available or negative (NAK) indicating that a shortcut is not available and the routed path must be used. The NHC must cache (maintain state) for both the ACK and NAK replies in order to use the correct shortcut or routed path. The NAK reply must be cached to avoid making repeated requests to the NHS when the routed path is being used.
この文書では、ネクストホップ解決プロトコルクライアント（NHC）の開発者向けのガイドラインを提供します。これは、クライアントが直接ATMベースのNBMAネットワークに接続されていることを前提としています。同じ原理がNBMAネットワークの他のタイプに接続されたクライアントに適用されます。意図は、NHCコードとローカル・ホスト・オペレーティング・システムのTCP / IPプロトコルスタックとの間の相互作用を定義することです。 NHCは、インターとイントラ両方LISアドレスを解決するためにネクストホップ解決プロトコルサーバ（NHS）にNHRPリクエストを送信することが可能です。 NHS返信ショートカットパスが利用可能であるか、または負（NAK）のショートカットが利用できないとルーティング経路を使用しなければならないことを示しているかを示す肯定（ACK）であってもよいです。 NHCは、ACKとNAKの両方のために（状態を維持）をキャッシュしなければならない正しいショートカットまたはルーティングされたパスを使用するために応答します。 NAK応答は、ルーティングされたパスが使用されているとき、NHSへの再三の要求を避けるためにキャッシュする必要があります。
In the Classical IP over ATM model [1], an ATM attached host communicates with an ATMARP server to resolve IP to ATM address semantics. This model supports the concept of a Logical IP Subnet (LIS) with intra LIS communications using direct PVCs/SVCs and inter LIS communications using IP routers to forward packets. This model easily maps to the conventional LAN model of subnets and routers. The Next Hop Resolution Protocol (NHRP) [2] defines how the LIS model can be modified to allow direct ATM SVCs (shortcut paths) for inter LIS traffic. With NHRP, nodes directly attached to an ATM network can bypass the IP routers and establish a direct switched virtual circuit to improve performance when needed.
ATMモデル[1]を介したClassical IPでは、ATMは、ホストがアドレスのセマンティクスを気圧までIPを解決するためのATMARPサーバと通信接続しました。このモデルは、直接のPVC / SVCおよびパケットを転送するためにIPルータを使用して、インターLIS通信を使用して内LIS通信に論理IPサブネット（LIS）の概念をサポートしています。このモデルは、簡単にサブネットとルータの従来のLANモデルにマッピングされます。ネクストホップ解決プロトコル（NHRP）[2] LISモデルはインターLISトラフィックに対して直接ATM SVCの（ショートカットパス）を可能にするように改変することができる方法を定義します。 NHRPを使用すると、直接ATMネットワークに接続されたノードは、IPルータをバイパスし、必要なときにパフォーマンスを向上させるための直接交換仮想回線を確立することができます。
The NHS code replaces the ATMARP code in the ATMARP server. Each NHS serves a set of destination client hosts and cooperates with other NHSs to resolve NHRP next hop requests within their own logical ATM network. The NHC to NHS and NHS to NHS protocol interactions are described in [2]. Other documents in the NHRP series define the general applicability [3] and the transition from ATMARP servers to NHSs [4].
NHSコードがATMARPサーバにATMARPコードを置き換えます。各NHSは、宛先クライアントホストのセットを提供しており、自身の論理ATMネットワーク内のNHRPネクストホップの要求を解決するために、他のNHSSと協働します。 NHSのNHS及びNHSへNHCは、プロトコル相互作用は、[2]に記載されています。 NHRPシリーズの他の文書は一般的な適用[3]及びNHSSにATMARPサーバからの遷移を定義する[4]。
The NHC code replaces the ATMARP code in the local workstations. This code will take the destination IP address and map it into the ATM End Station Address (AESA) for both intra and inter LIS destinations. The returned AESA will be stored in a local cache table. In addition to storing the positive replies, the NHC will need to store the negative replies to avoid making repeated NHS calls when using the routed path.
NHCコードは、ローカルワークステーションにATMARPコードを置き換えます。このコードは、宛先IPアドレスを取り、内および間LIS先の両方のためにATMエンドステーションアドレス（AESA）にマップされます。返さAESAは、ローカル・キャッシュ・テーブルに格納されます。肯定応答を格納することに加えて、NHCはルーティングされたパスを使用するときに繰り返しNHSの呼び出しを避けるために、負の応答を格納する必要があります。
This document describes a base line method for caching the returned information. Other methods may be used as long as the same functionality is provided.
この文書では、返された情報をキャッシュするためのベースライン方法を説明します。他の方法があれば、同じ機能が提供されるように使用することができます。
In the Classical IP LIS model [1] the TCP/IP protocol stack treats the ATM network as a simple data link layer protocol. When an application sends data using the Classical IP protocol, IP performs a routing table lookup to determine if the destination is reachable via a local interface or whether an intermediate router is the next hop to the IP destination.
古典的なIP LISモデル[1] TCP / IPプロトコルスタックは、単純なデータリンク層プロトコルとしてATMネットワークを扱います。アプリケーションは、古典的なIPプロトコルを使用してデータを送信する際、IP宛先がローカルインタフェースを介して、または中間ルータがIP宛先への次ホップであるか否かを到達可能であるかどうかを決定するためにルーティングテーブルルックアップを行います。
If the destination is found to be local (e.g. in the same LIS as the source) the packet will be passed to the local ATM interface with the next hop IP address set to the destination nodes IP address. At this point the ATMARP table will be searched to determine the ATM Address of the destination node. If no ATMARP table entry is found an ATMARP request will be sent to the ATMARP server. This server can reply with a positive (ACK) or negative (NAK) answer depending on the current information it has in its cache. If an ACK is received the host's local ATMARP table is filled in appropriately and the source is now able to send IP datagrams to the destination. If a NAK is returned, the calling application is notified of this error condition (e.g., ICMP destination unreachable).
宛先が（ソースと同じLISに例えば）をローカルであると判明した場合、パケットは、宛先ノードのIPアドレスに設定ネクストホップIPアドレスをローカルATMインターフェイスに渡されます。この時点でATMARPテーブルは、宛先ノードのATMアドレスを決定するために検索されます。全くATMARPテーブルエントリが見つからない場合はATMARP要求がATMARPサーバに送信されます。このサーバは、正（ACK）またはそれはそのキャッシュ内にあり、現在の情報に応じたネガティブ（NAK）答えを返信することができます。 ACKを受信した場合、ホストのローカルATMARPテーブルを適切に充填され、ソースは今、先にIPデータグラムを送信することができます。 NAKが返された場合、呼び出し元のアプリケーションは、このエラー条件（例えば、ICMP宛先到達不能）が通知されます。
If the destination is found to be remote (e.g., in a different LIS from the source) the IP address of the next hop router is extracted from the IP routing table and the ATM Address of this router is looked up in the ATMARP table. Since the router is in the same LIS as the source node, the ATMARP procedure described above will find the correct ATM Address or the packet will be marked as undeliverable and the user application will be notified of the error.
目的地が遠隔であることが見出された場合（例えば、ソースとは異なるLISに）次のホップルータのIPアドレスは、IPルーティングテーブルから抽出され、このルータのATMアドレスをATMARPテーブル内で検索されます。ルータは、ソースノードと同じLISであるため、上記ATMARP手順は正しいATMアドレスを検索するか、またはパケットが配信不能としてマークされ、ユーザ・アプリケーションがエラーを通知します。
The ATMARP service functions exactly as the existing ARP service provided on Ethernet broadcast networks. Since the ARP service will only try and resolve addresses for nodes that are in a single IP subnet, the ARP table only needs to keep positive answers. No state information is retained about failed mappings.
ATMARPサービス機能を正確にイーサネットブロードキャストネットワーク上で提供される既存のARPサービスとして。 ARPサービスだけ試してみて、単一のIPサブネット内にあるノードのアドレスを解決しますので、ARPテーブルが唯一の肯定の答えを維持する必要があります。いかなる状態情報は、失敗したマッピングについては保持されません。
In this section we briefly describe what is required in order for a host to take advantage of shortcuts through the ATM network. On the host, a NHC process initiates various NHRP requests in order to obtain access to the NHRP service. Within the ATM subnetwork, the ATMARP server is replaced with a NHS. As defined in [4] the NHS is required to respond to both ATMARP and NHRP Resolution requests. In the nodes wishing to take advantage of shortcut paths across the ATM subnetwork, the ATMARP client code must be replaced with NHC code. This allows the source node to ask for the ATM AESA of both local and remote nodes. Finally the source node must be modified to know when it should ask for the ATM AESA of a remote node and when the local LIS router should be used. These modifications are described in the remainder of this document.
このセクションでは、簡単にATMネットワークを介してのショートカットを利用するホストのために必要とされるものについて説明します。ホストで、NHCプロセスは、NHRPサービスへのアクセスを得るために、様々なNHRP要求を開始します。 ATMサブネットワーク内では、ATMARPサーバは、NHSに置き換えられます。 [4] NHSで定義されるようにATMARPとNHRP解決要求の両方に応答する必要があります。 ATMサブネットワーク間でのショートカットのパスを利用したいノードでは、ATMARPクライアントコードは、NHCコードに置き換える必要があります。これは、ソースノードは、ローカルとリモートの両方のノードのATM AESAを要求することを可能にします。最後に、ソースノードは、ローカルLISルータを使用する必要があるときには、リモート・ノードのATM AESAを求めるとすべきときを知るように変更する必要があります。これらの改変は、本文書の残りの部分に記載されています。
The protocol processing described in [2] states a source may query a NHS for the ATM AESA of a destination node. However as is pointed out in [5], to achieve shortcut paths through the ATM network, it is not enough to simply replace the ATMARP client code with the NHC code. This is because the source host will never ask the NHS for the ATM AESA of a node in a remote LIS. When the source consults the IP routing table, it performs the local/remote test, before the NHC code is processed. As a result, the IP address of the next hop router will be used by the NHC instead of the IP address of the remote (inter LIS) host. The NHC code must ignore the result of the IP routing table lookup and perform its own local/remote test.
〔2〕に記載のプロトコル処理は、宛先ノードのATM AESAためNHSを照会することができるソースを述べています。 ATMネットワークを介してショートカットパスを達成するために、[5]で指摘されているようしかし、単にNHCコードでATMARPクライアントコードを置き換えるのに十分ではありません。送信元ホストがリモートLIS内のノードのATM AESAのためのNHSを尋ねることは決してありませんので、これがあります。ソースは、IPルーティングテーブルを参照するときNHCコードが処理される前に、それは、ローカル/リモートのテストを行います。その結果、次ホップルータのIPアドレスは、NHCの代わりに、遠隔（インターLIS）ホストのIPアドレスで使用されます。 NHCコードは、IPルーティングテーブルルックアップの結果を無視し、自身のローカル/リモート・テストを実行しなければなりません。
The NHC must perform the following functions:
NHCは、次の機能を実行する必要があります。
1. Test to see if the destination node is `local' to this LIS. If so use the existing ATMARP rules described in [1]. 2. If not; send an NHRP message to the local NHS and attempt to setup a `shortcut' path. If successful; save the IP to ATM AESA mapping in the local NHC cache. 3. If not successful; use the routed path and save this state in the NHC cache so future requests don't test for a shortcut again.
宛先ノードがこのLISへ `ローカルであるかどうかを確認するために1テスト。その場合は、[1]に記載の既存のATMARPルールを使用します。 2.そうでない場合は、地元のNHSとセットアップへの試み `ショートカット」パスにNHRPメッセージを送信します。成功した場合、ローカルNHCキャッシュ内のATM AESAへのマッピングIPを保存します。 3.成功していない場合は、将来の要求を再度ショートカットをテストしていないので、ルーティングされたパスを使用し、NHCキャッシュにこの状態を保存します。
4. Allow user application to override system default operation and explicitly request a shortcut or routed path for a flow.
4.ユーザアプリケーションがシステムのデフォルトの動作をオーバーライドして、明示的に流すためのショートカットまたはルーティングされたパスを要求することを許可します。
It is required that this routed path state will be maintained in the same manner as the existing ATMARP service. That is a timer will be used to expire old information and some administrative function exists to manually delete data if needed.
このルーティングパスの状態は、既存のATMARPサービスと同じ方法で維持されることが必要です。これはタイマーが古い情報を期限切れにするために使用され、いくつかの管理機能が必要な場合は、手動でデータを削除するために存在しています。
It is obvious that the IP to ATM AESA mappings should be maintained in a local cache to improve network performance. This soft state is maintained in today's ARP and ATMARP systems using timers to purge old or unused data. The NHC will maintain both inter and intra LIS IP to ATM Address mappings in the same manner. It may be less obvious that an NHC will also need to maintain this same soft state for inter LIS mappings using the routed path. If this state is not maintained, the source node will send requests to the NHS asking if a shortcut path can be setup every time a packet is sent over the routed path.
ATM AESAへのマッピングIPは、ネットワークのパフォーマンスを改善するために、ローカルキャッシュに維持されなければならないことは明らかです。このソフト状態は、古いまたは未使用のデータを消去するためにタイマーを使用して、今日のARPとATMARPシステムで維持されています。 NHCは、同じようにアドレスマッピングを気圧の両方の間とイントラLIS IPを維持します。 NHCはまた、ルーティングされたパスを使用して、インターLISマッピングのために、この同じソフト状態を維持する必要があることにあまり目立たないかもしれません。この状態が維持されていない場合は、ソースノードは、ショートカットのパスは、パケットがルーティングパス上で送信されるたびに設定することができるかどうかを尋ねるNHSに要求を送信します。
Some of the features of this state are:
この状態の機能のいくつかは以下のとおりです。
1. Cache lookups must be fast as they are done on every packet. 2. The cache lookup must be on the destination IP address instead of the next-hop router IP address. 3. Both ACK and NAK data should be cached for the length of the holding time parameter in the NHRP response.
彼らはすべてのパケット上で行われて1キャッシュ検索が高速である必要があります。 2.キャッシュ検索ではなく、ネクストホップルータのIPアドレスの送信先IPアドレスにする必要があります。 3. ACKとNAKの両方のデータがNHRP応答の保持時間パラメータの長さのためにキャッシュされるべきです。
Since state must be maintained, the questions of where to maintain it, how to manually managed it, and how to selectively override it need to be addressed. No matter where this state information is kept, a method for manually examining and changing this state information must be provided. This is essential to insure that the network is operating properly.
状態が維持されなければならないので、それを維持する場所の問題は、それを手動で管理する方法、および選択的に無効にするために、どのように対処する必要があります。この状態情報が保持さに関係なく、手動でこの状態情報を調べ、変更するための方法が提供されなければなりません。これは、ネットワークが正常に動作していることを保証することが不可欠です。
There are several possible locations for storing this state information, they are:
この状態情報を格納するためのいくつかの可能な場所はありますが、彼らは以下のとおりです。
1. Store state in the `ARP' table. This is the traditional location for this IP to ATM address mappings. This table must be extended to handle the caching of negative (routed path) information. This solution provides a system wide service that may be used by the NHC. 2. Store state in the IP routing table. This is the traditional location for the local/remote state information.
`ARP」テーブル1.ストア状態。これは、このIPアドレスのマッピングを気圧のための伝統的な場所です。このテーブルは、負（経由パス）情報のキャッシングを扱うように拡張されなければなりません。この溶液を、NHCによって使用することができるシステム全体のサービスを提供します。 IPルーティングテーブル内の2店舗状態。これは、ローカル/リモートの状態情報の伝統的な場所です。
3. Store state in an ATM MIB structure. This is the traditional location for storing ATM VCC data. It also provides a system wide service that is geared toward ATM services. This avoids munging the `ARP' table to hold negative data. 4. Store state in the TCP Process Control Block. This allows a per process tailoring of shortcut or routed path information. This works well for TCP connections, but not UDP style services. 5. Store state in the socket structure. This also allows per process tailoring of the state information. 6. Store state in a newly defined table.
ATM MIB構造の3店舗状態。これは、ATM VCCデータを格納するための伝統的な場所です。また、ATMサービス向けですシステム全体のサービスを提供しています。これは、負のデータを保持するために、 `ARP」テーブルをいじる避けることができます。 TCPのプロセス制御ブロック内の4店舗状態。これは、ショートカットまたはルーティングされたパス情報のプロセスあたりの調整を可能にします。これは、TCP接続ではなく、UDPスタイルのサービスに適しています。ソケット構造5.ストア状態。また、これは、状態情報のプロセスのテーラリングあたりのことができます。新しく定義されたテーブルで6店舗状態。
The NHC should also support both local (per-process) and global (per-system) state. This would allow a system wide default while allowing a specific application to tailor the operation for a specific task. For example assume a site runs both a DNS server and FTP server on a single host. Inter LIS communications to the DNS server should take the routed path to avoid setup overhead. While an FTP session would benefit from the shortcut path to improve performance. Supporting both operations from a single client will require both a global state (e.g. use shortcut for FTP) and a local state (e.g. use routed path for DNS).
NHCは、（プロセスごとの）ローカルおよびグローバル（システムごとの）状態の両方をサポートしなければなりません。特定のタスクのための操作を調整するために特定のアプリケーションを可能にしながら、これは、システム全体のデフォルトを可能にします。例えば、サイトは単一のホスト上のDNSサーバーとFTPサーバーの両方を実行しますと仮定します。 DNSサーバへのインターLIS通信は、セットアップのオーバーヘッドを避けるためにルーティングされたパスを取る必要があります。 FTPセッションは、パフォーマンスを向上させるために、ショートカットパスの恩恵を受けるだろうが。単一のクライアントからの両方の動作をサポートするグローバル状態（FTP用の例えば使用ショートカット）とローカル状態の両方を必要とするであろう（例えば、DNSのためのルーティングパスを使用）。
TCP is a connection orientated protocol that provides per-process state information using a TCP Protocol Control Block (PCB). This PCB can be used to save the shortcut/routed path state information. Using a quad-state flag that shows the USE_SHORT_CUT, TRY_SHORT_CUT, USE_ROUTED_PATH, or TRY_ROUTED_PATH states would allow each process to use the service it chooses. The advantage of this approach is that it allows per flow control over the use of the shortcut or routed path. The disadvantage is that this PCB is only created for TCP connections. UDP connections will only use the system default action.
TCPは、TCPプロトコル制御ブロック（PCB）を使用してプロセスごとの状態情報を提供する接続志向プロトコルです。このPCBは、ショートカット/ルーティングパスの状態情報を保存するために使用することができます。 USE_SHORT_CUT、TRY_SHORT_CUT、USE_ROUTED_PATH、又はTRY_ROUTED_PATH状態を示すクワッド状態フラグを使用すると、各プロセスは、それが選択したサービスを利用できるようになります。このアプローチの利点は、ショートカットやルーティングパスの使用上のフロー制御ごと可能にすることです。欠点は、このPCBは唯一のTCP接続のために作成されていることです。 UDP接続は、システムのデフォルトのアクションを使用します。
A second option is to store this information in the socket PCB and use the socket function (setsockopt) to save this information. This option will allow both TCP and UDP applications to set a per flow action to override the system default operation. To enable this option, the IP kernel code will need to be modified to allow this quad-state flag to be set. In addition this flag will need to be checked when each packet is sent to determine the if the shortcut or routed path is being used.
2番目のオプションは、ソケットPCBにこの情報を保存し、この情報を保存するためのソケット機能（のsetsockopt）を使用することです。このオプションは、TCPとUDPの両方のアプリケーションがシステムのデフォルトの動作を無効にするために、フローごとのアクションを設定することができます。このオプションを有効にするには、IPカーネルコードは、このクアッド状態フラグを設定できるように変更する必要があります。各パケットはショートカットまたはルーティングパスが使用されているかどうかを決定するために送信されるときに加えて、このフラグをチェックする必要があります。
UDP is a connectionless orientated protocol that doesn't provide any support for state information. It relies on the application to provide the necessary state information. In this case where should the state be stored? The user application could store this itself and pass this down to the kernel in some manner. Another option is to store this information in an ATM MIB structure. A third option is to allow a socket option (setsockopt) that the user application can set to override the default behavior.
UDPは、状態情報のいずれかのサポートを提供していませんコネクション指向のプロトコルです。これは、必要な状態情報を提供するために、アプリケーションに依存しています。この場合、どこの状態が保存されるべきですか？ユーザアプリケーションは、この自分自身を保存し、何らかの方法でカーネルにこれをダウン渡すことができます。別のオプションは、ATM MIB構造内でこの情報を保存することです。第三の選択肢は、ユーザアプリケーションがデフォルトの動作を上書きするように設定できることをソケットオプション（のsetsockoptを）できるようにすることです。
In keeping with the tradition of using ICMP echo packets for Internet management functions (e.g. ping, traceroute) then it will be necessary to allow these applications to run over the shortcut and routed paths. The user will need to be able to specify which path to use and a default action needs to be defined too.
インターネット管理機能のためのICMPエコーパケットを使用する伝統（例えばピング、トレースルート）に合わせて、これらのアプリケーションは、ショートカット上で動作し、パスをルーティングできるようにするために必要であろう。ユーザーが使用するパスを指定することができるようにする必要がありますし、デフォルトのアクションも定義する必要があります。
NHRP provides new services and functionality for IP nodes using ATM networks. To use these services the client must store state information that describes whether a destination node is reachable via a shortcut or a routed path.
NHRPはATMネットワークを使用してIPノードの新しいサービスや機能を提供します。これらのサービスを利用するには、クライアントは、宛先ノードがショートカットまたはルーティング経路を介して到達可能であるかどうかを記述する状態情報を格納する必要があります。
The state information should be stored on a global per-application basis with per-process override functionality. This allows short lived functions (e.g. DNS requests) and long lived requests (e.g. ftp sessions) to use different paths. Storing state only based on the destination address means that all processes must use the same path and this creates unreasonable demands on the network. To accomplish this the /etc/services file should be modified to carry a new flag to indicate the per-application default (shortcut vs. routed path) behavior.
状態情報は、プロセスごとのオーバーライド機能をグローバルアプリケーションごとに保存されるべきです。これは短命な機能（例えば、DNS要求）と異なるパスを使用するように長寿命の要求（例えば、FTPセッション）を可能にします。唯一の宛先アドレスに基づいて状態を保存するすべてのプロセスが同じパスを使用しなければならないことを意味し、これは、ネットワーク上の不当な要求を作成します。これを達成するためには/ etc / servicesファイルには、（ショートカット対ルーティングされたパス）の挙動をアプリケーションごとのデフォルトを示すために、新しいフラグを運ぶために変更する必要があります。
This state information is required to avoid having the client make a call to the NHS for every packet it sends along the routed path. It is recommended that the IP routing table be modified to support a new flag. This flag will indicate whether the NHS returned an ACK or NAK to the NHRP request.
この状態情報は、クライアントがルーティングされたパスに沿って送信するすべてのパケットのためのNHSへの呼び出しを行うことを避けるために必要とされます。 IPルーティングテーブルが新しいフラグをサポートするように変更することをお勧めします。このフラグは、NHSがNHRP要求にACKまたはNAKを返したかどうかを示すであろう。
In addition, application programmers and system administrators require the ability to explicitly request a specific service (e.g. use the routed path or shortcut path). This includes the ability to verify network operation by specifying how ICMP echo requests (e.g. ping, traceroute) are handled. The NHC must support the manual setting of this state information. A new socket option that allows the user to specify the operation needs to be supported.
また、アプリケーションプログラマおよびシステム管理者が明示的に特定のサービスを要求する能力を必要とする（例えばルーティングパスまたはショートカットパスを使用）。これはICMPエコー要求（例えばピング、トレースルート）が処理される方法を指定することにより、ネットワークの動作を確認する能力を含みます。 NHCは、この状態情報の手動設定をサポートしている必要があります。ユーザーが操作を指定することを可能にする新しいソケットオプションがサポートされる必要があります。
To support this capability a new socket option will be created to allow the user application to control the operation of a particular connection (flow). This option will allow the user to specify that a connection use one of the following:
この機能をサポートするために新しいソケットオプションは、ユーザーのアプリケーションが特定の接続（フロー）の動作を制御できるようにするために作成されます。このオプションは、接続は、次のいずれかを使用することをユーザーが指定できるようになります。
* USE_SYSTEM_DEFAULT. Use the shortcut or routed path based on the system configuration information for this application. (This is the default behavior.) * USE_SHORT_CUT. If a shortcut path exists, then use it to deliver the data. If it doesn't exist, then try and create it. If the shortcut cannot be created, fail the connection and notify the user. * TRY_SHORT_CUT. If a shortcut path exists, then use it to deliver the data. If it doesn't exist, then try and create it. If the shortcut cannot be created, try using the routed path. * USE_ROUTED_PATH. Use the routed path regardless of whether a shortcut exists or not. * TRY_ROUTED_PATH. If a shortcut doesn't exist, don't try and create it, use the routed path instead.
* USE_SYSTEM_DEFAULT。このアプリケーションのシステム構成情報に基づいてショートカットまたはルーティングされたパスを使用してください。 （これがデフォルトの動作です。）* USE_SHORT_CUT。ショートカットのパスが存在する場合は、データを配信するためにそれを使用。それが存在しない場合は、試してみて、それを作成します。ショートカットが作成できない場合は、接続に失敗し、ユーザーに通知します。 * TRY_SHORT_CUT。ショートカットのパスが存在する場合は、データを配信するためにそれを使用。それが存在しない場合は、試してみて、それを作成します。ショートカットが作成できない場合は、ルーティングされたパスを使用してみてください。 * USE_ROUTED_PATH。かかわらず、ショートカットが存在するかどうかのルーティングパスを使用してください。 * TRY_ROUTED_PATH。ショートカットが存在しない場合は、代わりにルーティングされたパスを使用して、試してみて、それを作成しないでください。
The security issues for NHRP are addressed in other NHRP documents [2,3]. Some specific security issues for the NHC developer are discussed below.
NHRPのためのセキュリティ問題は、他のNHRP文書[2,3]で扱われています。 NHCの開発者のためのいくつかの特定のセキュリティ問題については後述します。
* Address spoofing at the IP or ATM layer may allow an attacker to hi-jack an IP connection or service. This threat may be reduced by limiting the scope of the ATM routing domain. In this way only trusted IP hosts will be able to reach and use the services of the NHS. * Denial of service attacks may be launched at both the IP and ATM layers of the NHS. At the ATM layer, the attacker may repeatedly generate signaling messages that consuming system resources thus preventing NHCs from using the NHS services. At the IP layer, the attacker may register false IP to ATM mappings thus preventing a NHC from registering the correct IP to ATM mapping. * When a NHC creates or accepts a short-cut path it bypasses the site border router. Therefore, any security features in the border router are also bypassed. This threat may be reduced by limiting the scope of the ATM routing domain, increasing security features in the NHC host, allowing the NHS to evaluate security features when short-cut paths are requested or a compination of all of these methods.
* IPまたはATMレイヤでのアドレススプーフィングがhi-ジャックIP接続またはサービスへの攻撃を可能にすることができます。この脅威は、ATMルーティングドメインの範囲を制限することによって減少させることができます。この方法でのみ、信頼できるIPホストが到達し、NHSのサービスを使用することができるようになります。 *サービス妨害攻撃は、NHSの両方のIPおよびATM層で発表することができます。 ATM層では、攻撃者がシステムリソースを消費するため、NHSのサービスを使用してからNHCSを防止シグナリングメッセージを繰り返し生成することがあります。 IP層では、攻撃者は、ATMマッピングは、このようにマッピングをATMには、正しいIPを登録からNHCを防止する偽のIPを登録することもできます。 NHCは、短いカットパスを作成するか、受け付けると*それは、サイトの境界ルータをバイパスします。したがって、境界ルータのいずれかのセキュリティ機能もバイパスされます。この脅威は、ショートカットパスが要求されたときNHSはセキュリティ機能を評価することができ、またはこれらの方法の全てのcompination、ATMルーティングドメインの範囲を限定するNHCホストのセキュリティ機能を増加させることによって減少させることができます。
Richard Carlson Argonne National Laboratory
リチャード・カールソンアルゴンヌ国立研究所
EMail: RACarlson@anl.gov
メールアドレス：RACarlson@anl.gov
Linda Winkler Argonne National Laboratory
リンダ・ウィンクラーアルゴンヌ国立研究所
EMail: lwinkler@anl.gov
メールアドレス：lwinkler@anl.gov
[1] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
[1]ラウバッハ、M.及びJ.アルペルン、 "古典IPおよびATM上ARP"、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]ルチアーニ、J.、カッツ、D.、Piscitello、D.、コールB.およびN. Doraswamy、 "NBMAネクストホップ解決プロトコル（NHRP）"、RFC 2332、1998年4月。
[3] Cansever, D., "NHRP Protocol Applicability Statement", RFC 2333, April 1998.
[3] Cansever、D.、 "NHRPプロトコルの適用性に関する声明"、RFC 2333、1998年4月。
[4] Luciani, J., "Classical IP to NHRP Transition", RFC 2336, July 1998.
[4]ルチアーニ、J.、 "NHRP移行に古典IP"、RFC 2336、1998年7月。
[5] Rekhter, Y. and D. Kandlur, "Local/Remote Forwarding Decision in Switched Data link Subnetworks", RFC 1937, May 1996.
[5] Rekhter、Y.、およびD. Kandlur、 "交換データリンクサブネットワークにおけるローカル/リモート転送の決定"、RFC 1937、1996年5月。
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。