[要約] RFC 2333は、NHRPプロトコルの適用性に関する文書であり、NHRPプロトコルの使用方法と目的を説明しています。NHRPは、ネットワーク上のホストとそのサービスを特定するためのプロトコルです。
Network Working Group D. Cansever
Request for Comments: 2333 GTE Laboratories, Inc.
Category: Standards Track April 1998
NHRP Protocol Applicability Statement
NHRPプロトコル適用性ステートメント
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
As required by the Routing Protocol Criteria [RFC 1264], this memo discusses the applicability of the Next Hop Resolution Protocol (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access (NBMA) networks, such as ATM, SMDS and X.25.
ルーティングプロトコル基準[RFC 1264]で要求されているように、このメモでは、ATM、SMDS、Xなどの非ブロードキャストマルチアクセス（NBMA）ネットワークを介したIPデータグラムのルーティングにおける次ホップ解決プロトコル（NHRP）の適用性について説明します。 25。
The NHRP protocol description is defined in [1]. The NHRP MIB description is defined in [2].
NHRPプロトコルの説明は、[1]で定義されています。 NHRP MIBの説明は、[2]で定義されています。
This document summarizes the key features of NHRP and discusses the environments for which the protocol is well suited. For the purposes of description, NHRP can be considered a generalization of Classical IP and ARP over ATM which is defined in [3] and of the Transmission of IP Datagrams over the SMDS Service, defined in [4]. This generalization occurs in 2 distinct directions.
このドキュメントでは、NHRPの主要な機能を要約し、プロトコルが適している環境について説明します。説明の目的で、NHRPは、[3]で定義されているATM上の従来のIPおよびARPと、[4]で定義されているSMDSサービスを介したIPデータグラムの送信の一般化と見なすことができます。この一般化は、2つの異なる方向で発生します。
Firstly, NHRP avoids the need to go through extra hops of routers when the Source and Destination belong to different Logical Internet Subnets (LIS). Of course, [3] and [4] specify that when the source and destination belong to different LISs, the source station must forward data packets to a router that is a member of multiple LISs, even though the source and destination stations may be on the same logical NBMA network. If the source and destination stations belong to the same logical NBMA network, NHRP provides the source station with an inter-LIS address resolution mechanism at the end of which both stations can exchange packets without having to use the services of intermediate routers. This feature is also referred to as "short-cut" routing. If the destination station is not part of the logical NBMA network, NHRP provides the source with the NBMA address of the current egress router towards the destination.
まず、NHRPは、送信元と宛先が異なる論理インターネットサブネット（LIS）に属している場合に、ルーターの追加のホップを経由する必要を回避します。もちろん、[3]と[4]は、ソースと宛先が異なるLISに属している場合、ソースステーションと宛先ステーションがオンであっても、ソースステーションが複数のLISのメンバーであるルーターにデータパケットを転送する必要があることを指定します。同じ論理NBMAネットワーク。送信元ステーションと宛先ステーションが同じ論理NBMAネットワークに属している場合、NHRPは送信元ステーションにLIS間アドレス解決メカニズムを提供します。このメカニズムの両端で、中間ルーターのサービスを使用せずにパケットを交換できます。この機能は、「ショートカット」ルーティングとも呼ばれます。宛先ステーションが論理NBMAネットワークの一部ではない場合、NHRPは、宛先に向かう現在の出口ルーターのNBMAアドレスをソースに提供します。
The second generalization is that NHRP is not specific to a particular NBMA technology. Of course, [3] assumes an ATM network and [4] assumes an SMDS network at their respective subnetwork layers.
2つ目の一般化は、NHRPは特定のNBMAテクノロジーに固有ではないということです。もちろん、[3]はATMネットワークを想定し、[4]はそれぞれのサブネットワーク層でのSMDSネットワークを想定しています。
NHRP is specified for resolving the destination NBMA addresses of IP datagrams over IP subnets within a large NBMA cloud. NHRP has been designed to be extensible to network layer protocols other than IP, possibly subject to other network layer protocol specific additions.
NHRPは、大規模なNBMAクラウド内のIPサブネット上のIPデータグラムの宛先NBMAアドレスを解決するために指定されています。 NHRPは、IP以外のネットワークレイヤープロトコルに拡張できるように設計されており、他のネットワークレイヤープロトコル固有の追加が適用される可能性があります。
As an important application of NHRP, the Multiprotocol Over ATM (MPOA) Working Group of the ATM Forum has decided to adopt and to integrate NHRP into its MPOA Protocol specification [5]. As such, NHRP will be used in resolving the ATM addresses of MPOA packets destined outside the originating subnet.
NHRPの重要なアプリケーションとして、ATMフォーラムのマルチプロトコルオーバーATM（MPOA）ワーキンググループは、NHRPを採用してMPOAプロトコル仕様に統合することを決定しました[5]。そのため、NHRPは、発信元サブネットの外部に宛てられたMPOAパケットのATMアドレスの解決に使用されます。
NHRP provides a mechanism to obtain the NBMA network address of the destination, or of a router along the path to the destination. NHRP is not a routing protocol, but may make use of routing information. This is further discussed in Section 5.
NHRPは、宛先、または宛先へのパスに沿ったルーターのNBMAネットワークアドレスを取得するメカニズムを提供します。 NHRPはルーティングプロトコルではありませんが、ルーティング情報を利用する場合があります。これについては、セクション5で詳しく説明します。
The most prominent feature of NHRP is that it avoids extra router hops in an NBMA with multiple LISs. To this goal, NHRP provides the source with the NBMA address of the destination, if the destination is directly attached to the NBMA. If the destination station is not attached to the NBMA, then NHRP provides the source with the NBMA address of an exit router that has connectivity to the destination. In general, there may be multiple exit routers that have connectivity to the destination. If NHRP uses the services of a dynamic routing algorithm in fulfilling its function, which is necessary for robust and scalable operation, then the exit router identified by NHRP reflects the selection made by the network layer dynamic routing protocol. In general, the selection made by the routing protocol would often reflect a desirable attribute, such as identifying the exit router that induces the least number of hops in the original routed path.
NHRPの最も顕著な機能は、複数のLISを持つNBMAで余分なルーターホップを回避することです。この目的のために、宛先がNBMAに直接接続されている場合、NHRPはソースに宛先のNBMAアドレスを提供します。宛先ステーションがNBMAに接続されていない場合、NHRPは、宛先に接続している出口ルーターのNBMAアドレスをソースに提供します。一般的に、宛先への接続を持つ複数の出口ルーターがある場合があります。 NHRPがその機能を果たすために動的ルーティングアルゴリズムのサービスを使用する場合、これは堅牢でスケーラブルな動作に必要です。NHRPによって識別される出口ルーターは、ネットワーク層動的ルーティングプロトコルによって行われた選択を反映します。一般に、ルーティングプロトコルによる選択は、元のルーティングされたパスのホップ数が最小になる出口ルーターを識別するなど、望ましい属性を反映することがよくあります。
NHRP is defined for avoiding extra hops in the delivery of IP packets with a single destination. As such, it is not intended for direct use in a point-to-multipoint communication setting. However, elements of NHRP may be used in certain multicast scenarios for the purpose of providing short cut routing. Such an effort is discussed in [6]. In this case, NHRP would avoid intermediate routers in the multicast path. The scalability of providing short-cut paths in a multicast environment is an open issue.
NHRPは、単一の宛先を持つIPパケットの配信で余分なホップを回避するために定義されています。そのため、ポイントツーマルチポイント通信設定での直接使用は意図されていません。ただし、NHRPの要素は、ショートカットルーティングを提供する目的で、特定のマルチキャストシナリオで使用される場合があります。このような取り組みについては、[6]で説明しています。この場合、NHRPはマルチキャストパスの中間ルーターを回避します。マルチキャスト環境でショートカットパスを提供するスケーラビリティは、未解決の問題です。
NHRP can be used in host-host, host-router and router-host communications. When used in router-router communication, NHRP (as defined in [1]) can produce persistent routing loops if the underlying routing protocol looses information critical to loop suppression. This may occur when there is a change in router metrics across the autonomous system boundaries. NHRP for router-router communication that avoids persistent forwarding loops will be addressed in a separate document.
NHRPは、ホスト-ホスト、ホスト-ルーター、およびルーター-ホストの通信で使用できます。ルーターとルーターの通信で使用する場合、NHRP（[1]で定義）は、基盤となるルーティングプロトコルがループ抑制に重要な情報を失うと、永続的なルーティングループを生成できます。これは、自律システムの境界を越えてルーターメトリックに変更がある場合に発生する可能性があります。永続的な転送ループを回避するルーター間通信のNHRPについては、別のドキュメントで説明します。
A special case of router-router communication where loops will not occur is when the destination host is directly adjacent to the non-NBMA interface of the egress router. If it is believed that the adjacency of the destination station to the egress router is a stable topological configuration, then NHRP can safely be used in this router-router communication scenario. If the NHRP Request has the Q bit set, indicating that the requesting party is a router, and if the destination station is directly adjacent to the egress router as a stable topological configuration, then the egress router can issue a corresponding NHRP reply. If the destination is not adjacent to the egress router, and if Q bit is set in the Request, then a safe mode of operation for the egress router would be to issue a negative NHRP Reply (NAK) for this particular request, thereby enforce data packets to follow the routed path.
ループが発生しないルーター-ルーター通信の特殊なケースは、宛先ホストが出力ルーターの非NBMAインターフェイスに直接隣接している場合です。宛先ステーションと出力ルーターとの隣接関係が安定したトポロジ構成であると考えられる場合、NHRPはこのルーター間通信シナリオで安全に使用できます。 NHRP要求にQビットセットがあり、要求側がルーターであることを示し、宛先ステーションが安定したトポロジ構成として出力ルーターに直接隣接している場合、出力ルーターは対応するNHRP応答を発行できます。宛先が出力ルーターに隣接しておらず、要求でQビットが設定されている場合、出力ルーターの安全な動作モードは、この特定の要求に対して否定的なNHRP応答（NAK）を発行し、それによってデータを適用することです。ルーティングされたパスをたどるパケット。
As a result of having inter-LIS address resolution capability, NHRP allows the communicating parties to exchange packets by fully utilizing the particular features of the NBMA network. One such example is the use of QoS guarantees when the NMBA network is ATM.
NHSは、LIS間アドレス解決機能を備えているため、NBMAネットワークの特定の機能を完全に利用して、通信相手がパケットを交換できるようにします。そのような例の1つは、NMBAネットワークがATMである場合のQoS保証の使用です。
Here, due to short-cut routing, ATM provided QoS guarantees can be implemented without having to deal with the issues of re-assembling and re-segmenting IP packets at each network layer hop.
ここでは、ショートカットルーティングにより、ATMが提供するQoS保証は、各ネットワークレイヤーホップでのIPパケットの再構成や再セグメント化の問題に対処する必要なく実装できます。
NHRP protocol can be viewed as a client-server interaction. An NHRP Client is the one who issues an NHRP Request. An NHRP Server is the one who issues a reply to an NHRP request, or the one who forwards a received NHRP request to another Server. Of course, an NHRP entity may act both as a Client and a Server.
NHRPプロトコルは、クライアント/サーバーの相互作用と見なすことができます。 NHRPクライアントは、NHRP要求を発行するクライアントです。 NHRPサーバーは、NHRP要求への応答を発行するサーバー、または受信したNHRP要求を別のサーバーに転送するサーバーです。もちろん、NHRPエンティティはクライアントとサーバーの両方として機能できます。
In general, issuing an NHRP request is an application dependent action [7]. For applications that do not have particular QoS requirements, and that are executed within a short period of time, an NBMA short-cut may not be a necessity. In situations where there is a "cost" associated with NBMA short-cuts, such applications may be better served by network layer hop-by-hop routing. Here, "cost" may be understood in a monetary context, or as additional strain on the equipment that implements short-cuts. Therefore, there is a trade-off between the "cost" of a short-cut path and its utility to the user. Reference [7] proposes that this trade-off should be addressed at the application level. In an environment consisting of LANs and routers that are interconnected via dedicated links, the basic routing decision is whether to forward a packet to a router, or to broadcast it locally. Such a decision on local vs. remote is based on the destination address. When routing IP packets over an NBMA network, where there is potentially a direct Source to Destination connectivity with QoS options, the decision on local vs. remote is no longer as fundamentally important as in the case where packets have to traverse routers that are interconnected via dedicated links. Thus, in an NBMA network with QoS options, the basic decision becomes the one of short-cut vs. hop-by-hop network layer routing. In this case, the relevant criterion becomes applications' QoS requirements [7]. NHRP is particularly applicable for environments where the decision on local vs. remote is superseded by the decision on short-cut vs. hop-by-hop network layer routing.
一般に、NHRP要求の発行は、アプリケーションに依存するアクションです[7]。特定のQoS要件がなく、短時間で実行されるアプリケーションの場合、NBMAショートカットは必要ない場合があります。 NBMAショートカットに関連する「コスト」がある状況では、そのようなアプリケーションは、ネットワーク層のホップバイホップルーティングによってより適切に処理される場合があります。ここで、「コスト」は、金銭的な文脈で、またはショートカットを実装する機器への追加の負担として理解することができます。したがって、ショートカットパスの「コスト」とユーザーにとってのユーティリティとの間にはトレードオフがあります。参考文献[7]は、このトレードオフはアプリケーションレベルで対処する必要があることを提案しています。専用リンクを介して相互接続されたLANとルーターで構成される環境では、基本的なルーティングの決定は、パケットをルーターに転送するか、ローカルにブロードキャストするかです。ローカルとリモートのこのような決定は、宛先アドレスに基づいています。 QoSオプションを使用して送信元から宛先への直接接続が存在する可能性があるNBMAネットワークを介してIPパケットをルーティングする場合、ローカルまたはリモートの決定は、パケットが経由して相互接続されているルーターを通過する必要がある場合ほど根本的に重要ではなくなります専用リンク。したがって、QoSオプションを備えたNBMAネットワークでは、基本的な決定は、ショートカットとホップバイホップのネットワーク層ルーティングのどちらかになります。この場合、関連する基準はアプリケーションのQoS要件になります[7]。 NHRPは、ローカルとリモートのどちらの決定が、ショートカットとホップバイホップのネットワーク層ルーティングの決定に取って代わられる環境に特に適用されます。
Let us assume that the trade-off is in favor of a short-cut NBMA route. Generally, an NHRP request can be issued by a variety of NHRP aware entities, including hosts and routers with NBMA interfaces. If an IP packet traverses multiple hops before a short-cut path has been established, then there is a chance that multiple short-cut paths could be formed. In order to avoid such an undesirable situation, a useful operation rule is to authorize only the following entities to issue an NHRP request and to perform short-cut routing.
トレードオフがショートカットNBMAルートに有利であると仮定しましょう。一般に、NHRP要求は、NBMAインターフェイスを備えたホストやルーターを含む、さまざまなNHRP対応エンティティによって発行できます。ショートカットパスが確立される前にIPパケットが複数のホップを通過する場合、複数のショートカットパスが形成される可能性があります。このような望ましくない状況を回避するために、有用な操作規則は、NHRP要求を発行し、ショートカットルーティングを実行することを次のエンティティのみに許可することです。
i) The host that originates the IP packet, if the host has an NBMA interface. ii) The first router along the routing path of the IP packet such that the next hop is reachable through the NBMA interface of that particular router. iii) A policy router within an NBMA network through which the IP packet has to traverse.
i）ホストにNBMAインターフェイスがある場合、IPパケットを発信するホスト。 ii）IPパケットのルーティングパスに沿った最初のルーターで、その特定のルーターのNBMAインターフェイスを介して次のホップに到達できるようにします。 iii）IPパケットが通過する必要があるNBMAネットワーク内のポリシールーター。
As previously indicated, NHRP is defined for the delivery of IP packets with a single destination. Thus, this discussion is confined to a unicast setting. The scalability of NHRP can be analyzed at three distinct levels:
前述のように、NHRPは単一の宛先を持つIPパケットの配信用に定義されています。したがって、この説明はユニキャスト設定に限定されています。 NHRPのスケーラビリティは、3つの異なるレベルで分析できます。
o Client level o LIS level o Domain level
o クライアントレベルo LISレベルoドメインレベル
At the the Client level, the scalability of NHRP is affected by the processing and memory limitations of the NIC that provides interface to the NBMA network. When the NBMA network is connection oriented, such as ATM, NIC limitations may bound the scalability of NHRP in certain applications. For example, a server that handles hundreds of requests per second using an ATM interface may be bounded by the performance characteristics of the corresponding NIC. Similarly, when the NHRP Client resides at an NBMA interface of a router, memory and processing limitations of router's NIC may bound the scalability of NHRP. This is because routers generally deal with an aggregation of traffic from multiple sources, which in turn creates a potentially large number of SVCCs out of the router's NBMA interface.
クライアントレベルでは、NHRPのスケーラビリティは、NBMAネットワークへのインターフェイスを提供するNICの処理およびメモリ制限の影響を受けます。 NBMAネットワークがATMなどの接続指向である場合、NICの制限により、特定のアプリケーションでNHRPのスケーラビリティが制限される場合があります。たとえば、ATMインターフェイスを使用して1秒あたり数百のリクエストを処理するサーバーは、対応するNICのパフォーマンス特性によって制限される場合があります。同様に、NHRPクライアントがルーターのNBMAインターフェイスにある場合、ルーターのNICのメモリと処理の制限により、NHRPのスケーラビリティが制限される場合があります。これは、通常、ルーターが複数のソースからのトラフィックの集約を処理するため、ルーターのNBMAインターフェイスから多数のSVCCが潜在的に作成されるためです。
At the LIS level, the main issue is to maintain and deliver a sizable number of NBMA to Network layer address mappings within large LISs. To this goal, NHRP implementations can use the services of the Server Cache Synchronization Protocol (SCSP) [8] that allows multiple synchronized NHSs within an LIS, and hence resolve the associated scalability issue.
LISレベルでの主な問題は、大規模なLIS内でかなりの数のNBMAからネットワーク層アドレスへのマッピングを維持および配信することです。この目標を達成するために、NHRP実装はLIS内で複数の同期されたNHSを許可するサーバーキャッシュ同期プロトコル（SCSP）[8]のサービスを使用でき、関連するスケーラビリティの問題を解決します。
At the NHRP Domain level, network layer routing is used in resolving the NBMA address of a destination outside the LIS. As such, the scalability of NHRP is closely tied to the scalability of the network layer routing protocol used by NHRP. Dynamic network layer routing protocols are proven to scale well. Thus, when used in conjunction with dynamic routing algorithms, at the NHRP domain level, NHRP should scale in the same order as the routing algorithm, subject to the assumption that all the routers along the path are NHRP aware. If an NHRP Request is processed by a router that does not implement NHRP, it will be silently discarded. Then, short-cuts cannot be implemented and connectivity will be provided on a hop-by-hop basis.
NHRPドメインレベルでは、LIS外の宛先のNBMAアドレスを解決する際にネットワーク層ルーティングが使用されます。そのため、NHRPのスケーラビリティは、NHRPで使用されるネットワーク層ルーティングプロトコルのスケーラビリティと密接に関連しています。動的ネットワーク層ルーティングプロトコルは、適切に拡張できることが証明されています。したがって、動的ルーティングアルゴリズムと組み合わせて使用する場合、NHRPドメインレベルで、NHRPはルーティングアルゴリズムと同じ順序でスケーリングする必要があります。ただし、パス上のすべてのルーターがNHRPに対応しているという前提に従います。 NHRP要求がNHRPを実装していないルーターによって処理された場合、その要求は通知なく破棄されます。その場合、ショートカットは実装できず、接続はホップバイホップで提供されます。
Thus, when NHRP is implemented in conjunction with dynamic network layer routing, a scaling requirement for NHRP is that virtually all the routers within a logical NBMA network should be NHRP aware.
したがって、NHRPが動的ネットワーク層ルーティングと組み合わせて実装される場合、NHRPのスケーリング要件は、論理NBMAネットワーク内の実質的にすべてのルーターがNHRPを認識する必要があることです。
One can also use static routing in conjunction with NHRP. Then, not all the routers in the NBMA network need to be NHRP aware. That is, since the routers that need to process NHRP control messages are specified by static routing, routers that are not included in the manually defined static paths do not have to be NHRP aware. Of course, static routing does not scale, and if the destination is off the NBMA network, then the use of static routing could result in persistently suboptimal routes. Use of static routing also has fairly negative failure modes.
NHRPと組み合わせて静的ルーティングを使用することもできます。次に、NBMAネットワーク内のすべてのルーターがNHRP対応である必要はありません。つまり、NHRP制御メッセージを処理する必要があるルーターは静的ルーティングによって指定されるため、手動で定義された静的パスに含まれていないルーターはNHRPを認識する必要はありません。もちろん、スタティックルーティングはスケーリングされません。宛先がNBMAネットワーク外にある場合、スタティックルーティングを使用すると、ルートが次第に最適化されなくなる可能性があります。静的ルーティングの使用には、かなり否定的な障害モードもあります。
NHRP does not replace existing routing protocols. In general, routing protocols are used to determine the proper path from a source host or router, or intermediate router, to a particular destination. If the routing protocol indicates that the proper path is via an interface to an NBMA network, then NHRP may be used at the NBMA interface to resolve the destination IP address into the corresponding NBMA address. Of course, the use of NHRP is subject to considerations discussed in Section 4.
NHRPは既存のルーティングプロトコルを置き換えません。一般に、ルーティングプロトコルは、送信元ホストまたはルーター、または中間ルーターから特定の宛先への適切なパスを決定するために使用されます。ルーティングプロトコルが適切なパスがNBMAネットワークへのインターフェイスを経由していることを示している場合、NBMAインターフェイスでNHRPを使用して、宛先IPアドレスを対応するNBMAアドレスに解決できます。もちろん、NHRPの使用には、セクション4で説明する考慮事項が適用されます。
Assuming that NHRP is applicable and the destination address has been resolved, packets are forwarded using the particular data forwarding and path determination mechanisms of the underlying NBMA network. Here, the sequence of events are such that route determination is performed by IP routing, independent of NHRP. Then, NHRP is used to create a short-cut track upon the path determined by the IP routing protocol. Therefore, NHRP "shortens" the routed path. NHRP (as defined in [1]) is not sufficient to suppress persistent forwarding loops when used for router-router communication if the underlying routing protocol looses information critical to loop suppression [9]. Work is in progress [10] to augment NHRP to enable its use for the router-router communication without persistent forwarding loops.
NHRPが適用可能であり、宛先アドレスが解決されていると仮定すると、パケットは、基礎となるNBMAネットワークの特定のデータ転送およびパス決定メカニズムを使用して転送されます。ここで、イベントのシーケンスは、NHRPとは無関係に、ルート決定がIPルーティングによって実行されるようなものです。次に、NHRPを使用して、IPルーティングプロトコルによって決定されたパス上にショートカットトラックを作成します。したがって、NHRPはルーティングされたパスを「短縮」します。基礎となるルーティングプロトコルがループ抑制に重要な情報を失う場合、ルータールーター通信に使用する場合、NHRP（[1]で定義）は永続的な転送ループを抑制するには不十分です[9]。 NHRPを拡張して、永続的な転送ループなしでルーター間通信を使用できるようにする作業が進行中です[10]。
When the routed path keeps changing on some relatively short time scale, such as seconds, this situation will have an effect on the operation of NHRP. In certain router-router operations, changes in the routed path could create persistent routing loops. In host-router, or router-host communications, frequent changes in routed paths could result in inefficiencies such as frequent creation of short-cut paths which are short lived.
ルーティングされたパスが秒などの比較的短い時間スケールで変化し続ける場合、この状況はNHRPの動作に影響します。特定のルータールーター操作では、ルーティングされたパスの変更により、永続的なルーティングループが作成される可能性があります。ホストとルーター、またはルーターとホストの通信では、ルーティングされたパスが頻繁に変更されると、有効期間が短いショートカットパスが頻繁に作成されるなど、非効率になる可能性があります。
NHRP is an address resolution protocol, and SCSP is a database synchronization protocol. As such, they are possibly subject to server (for NHRP) or peer (for SCSP) spoofing and denial of service attacks. They both provide authentication mechanisms to allow their use in environments in which spoofing is a concern. Details can be found in sections 5.3.4 in [1] and B.3.1 in [8]. There are no additional security constraints or concerns raised in this document that are not already discussed in the referenced sections.
NHRPはアドレス解決プロトコルであり、SCSPはデータベース同期プロトコルです。そのため、サーバー（NHRPの場合）またはピア（SCSPの場合）のなりすましやサービス拒否攻撃を受ける可能性があります。どちらも、なりすましが懸念される環境での使用を可能にする認証メカニズムを提供します。詳細は、[1]のセクション5.3.4および[8]のB.3.1にあります。このドキュメントでは、参照されるセクションでまだ説明されていないセキュリティ上の制約や懸念事項はありません。
References
参考文献
[1] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[1] Luciani、J.、Katz、D.、Piscitello、D.、Cole、B。、およびN. Doraswamy、「NMBA Next Hop Resolution Protocol（NHRP）」、RFC 2332、1998年4月。
[2] Greene, M., and J. Luciani, "NHRP Management Information Base", Work in Progress.
[2] Greene、M。、およびJ. Luciani、「NHRP管理情報ベース」、Work in Progress。
[3] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
[3] Laubach、M。、およびJ. Halpern、「Classical IP and ARP over ATM」、RFC 2225、1998年4月。
[4] Lawrance, J., and D. Piscitello, "The Transmission of IP datagrams over the SMDS service", RFC 1209, March 1991.
[4] Lawrance、J.、およびD. Piscitello、「The Transmission of IP datagrams over the SMDS service」、RFC 1209、1991年3月。
[5] Multiprotocol Over ATM Version 1.0, ATM Forum Document af-mpoa-0087.000
[5] マルチプロトコルオーバーATMバージョン1.0、ATMフォーラムドキュメントaf-mpoa-0087.000
[6] Rekhter, Y., and D. Farinacci, "Support for Sparse Mode PIM over ATM", Work in Progress.
[6] Rekhter、Y。、およびD. Farinacci、「ATM上のスパースモードPIMのサポート」、作業中。
[7] Rekhter, Y., and D. Kandlur, "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks", RFC 1937, May 1996.
[7] Rekhter、Y。、およびD. Kandlur、「スイッチドデータリンクサブネットワークにおけるローカル/リモート」転送決定」、RFC 1937、1996年5月。
[8] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP) - NBMA", RFC 2334, April 1998.
[8] Luciani、J.、Armitage、G.、Halpern、J。、およびN. Doraswamy、「Server Cache Synchronization Protocol（SCSP）-NBMA」、RFC 2334、1998年4月。
[9] Cole, R., Shur, D., and C. Villamizar, "IP over ATM: A Framework Document", RFC 1932, April 1996.
[9] Cole、R.、Shur、D。、およびC. Villamizar、「IP over ATM：A Framework Document」、RFC 1932、1996年4月。
[10] Rekhter, Y., "NHRP for Destinations off the NBMA Subnetwork", Work in Progress.
[10] Rekhter、Y。、「NBMAサブネットワーク外の宛先のNHRP」、作業中。
Acknowledgements
謝辞
The author acknowledges valuable contributions and comments from many participants of the ION Working Group, in particular from Joel Halpern of Newbridge Networks, David Horton of Centre for Information Technology Research, Andy Malis of Nexion, Yakov Rekhter and George Swallow of Cisco Systems and Curtis Villamizar of ANS.
著者は、IONワーキンググループの多くの参加者、特にNewbridge NetworksのJoel Halpern、情報技術研究センターのDavid Horton、NexionのAndy Malis、Cisco SystemsおよびCurtis VillamizarのYakov RekhterおよびGeorge Swallowからの貴重な貢献とコメントを認めます。 ANSの。
Author's Address
著者のアドレス
Derya H. Cansever GTE Laboratories Inc. 40 Sylvan Rd. MS 51 Waltham MA 02254
Derya H. Cansever GTE Laboratories Inc. 40 Sylvan Rd。 MS 51ウォルサムMA 02254
Phone: +1 617 466 4086
EMail: dcansever@gte.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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。