[要約] RFC 2332は、NBMA Next Hop Resolution Protocol（NHRP）に関する仕様です。NHRPは、NBMAネットワーク上でのホストの次のホップを解決するためのプロトコルです。このRFCは、NHRPの目的と動作についての詳細な説明を提供しています。
Network Working Group J. Luciani
Request for Comments: 2332 Bay Networks
Category: Standards Track D. Katz
cisco Systems
D. Piscitello
Core Competence, Inc.
B. Cole
Juniper Networks
N. Doraswamy
Bay Networks
April 1998
NBMA Next Hop Resolution Protocol (NHRP)
NBMAネクストホップ解決プロトコル（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
概要
This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP can be used by a source station (host or router) connected to a Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the "NBMA next hop" towards a destination station. If the destination is connected to the NBMA subnetwork, 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. NHRP is intended for use in a multiprotocol internetworking layer environment over NBMA subnetworks.
このドキュメントでは、NBMAネクストホップ解決プロトコル（NHRP）について説明します。 NHRPは、Non-Broadcast、Multi-Access（NBMA）サブネットワークに接続されたソースステーション（ホストまたはルーター）で使用され、宛先ステーションに向かう「NBMAネクストホップ」のインターネットワーキングレイヤーアドレスとNBMAサブネットワークアドレスを決定します。宛先がNBMAサブネットワークに接続されている場合、NBMAネクストホップは宛先ステーション自体です。それ以外の場合、NBMAネクストホップは、宛先ステーションに「最も近い」NBMAサブネットワークからの出口ルーターです。 NHRPは、NBMAサブネットワーク上のマルチプロトコルインターネットワーキングレイヤー環境での使用を目的としています。
Note that while this protocol was developed for use with NBMA subnetworks, it is possible, if not likely, that it will be applied to BMA subnetworks as well. However, this usage of NHRP is for further study.
このプロトコルはNBMAサブネットワークで使用するために開発されましたが、可能でない場合は、BMAサブネットワークにも適用される可能性があることに注意してください。ただし、NHRPのこの使用法は、今後の検討課題です。
This document is intended to be a functional superset of the NBMA Address Resolution Protocol (NARP) documented in [1].
このドキュメントは、[1]に記載されているNBMAアドレス解決プロトコル（NARP）の機能的なスーパーセットを対象としています。
Operation of NHRP as a means of establishing a transit path across an NBMA subnetwork between two routers will be addressed in a separate document (see [13]).
2つのルーター間のNBMAサブネットワークを通過するトランジットパスを確立する手段としてのNHRPの操作については、別のドキュメントで説明します（[13]を参照）。
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 [15].
このドキュメントに記載されているキーワードは、必須、必須、必須、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONALであり、[15]で説明されているように解釈されます。
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. A subnetwork can be non-broadcast either because it technically doesn't support broadcasting (e.g., an X.25 subnetwork) or because broadcasting is not feasible for one reason or another (e.g., an SMDS multicast group or an extended Ethernet would be too large). If the destination is connected to the NBMA subnetwork, 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.
NBMAネクストホップ解決プロトコル（NHRP）を使用すると、非ブロードキャストマルチアクセス（NBMA）サブネットワークを介して通信することを望むソースステーション（ホストまたはルーター）が、適切な "NBMAのインターネットワーキングレイヤーアドレスとNBMAアドレスを決定できます。ネクストホップ」を宛先ステーションに向けて。サブネットワークは、ブロードキャストを技術的にサポートしていないため（X.25サブネットワークなど）、または何らかの理由でブロードキャストを実行できないため（たとえば、SMDSマルチキャストグループや拡張イーサネットも可能）、非ブロードキャストにすることができます。大）。宛先がNBMAサブネットワークに接続されている場合、NBMAネクストホップは宛先ステーション自体です。それ以外の場合、NBMAネクストホップは、宛先ステーションに「最も近い」NBMAサブネットワークからの出口ルーターです。
One way to model an NBMA network is by using the notion of logically independent IP subnets (LISs). LISs, as defined in [3] and [4], have the following properties:
NBMAネットワークをモデル化する1つの方法は、論理的に独立したIPサブネット（LIS）の概念を使用することです。 [3]と[4]で定義されているLISには、次のプロパティがあります。
1) All members of a LIS have the same IP network/subnet number and address mask.
1）LISのすべてのメンバーは、同じIPネットワーク/サブネット番号とアドレスマスクを持っています。
2) All members of a LIS are directly connected to the same NBMA subnetwork.
2）LISのすべてのメンバーが同じNBMAサブネットワークに直接接続されている。
3) All hosts and routers outside of the LIS are accessed via a router.
3）LISの外部にあるすべてのホストとルーターは、ルーターを介してアクセスされます。
4) All members of a LIS access each other directly (without routers).
4）LISのすべてのメンバーは互いに直接（ルーターなしで）アクセスします。
Address resolution as described in [3] and [4] only resolves the next hop address if the destination station is a member of the same LIS as the source station; otherwise, the source station must forward packets to a router that is a member of multiple LIS's. In multi-LIS configurations, hop-by-hop address resolution may not be sufficient to resolve the "NBMA next hop" toward the destination station, and IP packets may have multiple IP hops through the NBMA subnetwork.
[3]と[4]で説明されているアドレス解決は、宛先ステーションがソースステーションと同じLISのメンバーである場合にのみ、ネクストホップアドレスを解決します。そうでない場合、送信元ステーションは、複数のLISのメンバーであるルーターにパケットを転送する必要があります。マルチLIS構成では、ホップバイホップのアドレス解決では宛先ステーションへの「NBMAネクストホップ」を解決するのに十分ではなく、IPパケットはNBMAサブネットワークを介して複数のIPホップを持つ場合があります。
Another way to model NBMA is by using the notion of Local Address Groups (LAGs) [10]. The essential difference between the LIS and the LAG models is that while with the LIS model the outcome of the "local/remote" forwarding decision is driven purely by addressing information, with the LAG model the outcome of this decision is decoupled from the addressing information and is coupled with the Quality of Service and/or traffic characteristics. With the LAG model any two entities on a common NBMA network could establish a direct communication with each other, irrespective of the entities' addresses.
NBMAをモデル化する別の方法は、ローカルアドレスグループ（LAG）[10]の概念を使用することです。 LISモデルとLAGモデルの本質的な違いは、LISモデルでは「ローカル/リモート」転送決定の結果はアドレス指定情報によって純粋に駆動されるが、LAGモデルではこの決定の結果はアドレス指定情報から切り離されるということです。また、サービスの品質やトラフィックの特性と連動しています。 LAGモデルを使用すると、エンティティのアドレスに関係なく、共通のNBMAネットワーク上の2つのエンティティが相互に直接通信を確立できます。
Support for the LAG model assumes the existence of a mechanism that allows any entity (i.e., host or router) connected to an NBMA network to resolve an internetworking layer address to an NBMA address for any other entity connected to the same NBMA network. This resolution would take place regardless of the address assignments to these entities. Within the parameters described in this document, NHRP describes such a mechanism. For example, when the internetworking layer address is of type IP, once the NBMA next hop has been resolved, the source may either start sending IP packets to the destination (in a connectionless NBMA subnetwork such as SMDS) or may first establish a connection to the destination with the desired bandwidth (in a connection-oriented NBMA subnetwork such as ATM).
LAGモデルのサポートは、NBMAネットワークに接続されているエンティティ（ホストまたはルーターなど）が、同じNBMAネットワークに接続されている他のエンティティのNBMAアドレスにインターネットワーキングレイヤーアドレスを解決できるようにするメカニズムの存在を前提としています。この解決は、これらのエンティティへのアドレス割り当てに関係なく行われます。このドキュメントで説明されているパラメータ内で、NHRPはそのようなメカニズムを説明しています。たとえば、インターネットワーキングレイヤーのアドレスのタイプがIPの場合、NBMAネクストホップが解決されると、ソースは宛先へのIPパケットの送信を開始するか（SMDSなどのコネクションレスNBMAサブネットワーク内）、最初に接続を確立します。目的の帯域幅を持つ宛先（ATMなどのコネクション型NBMAサブネットワーク内）。
Use of NHRP may be sufficient for hosts doing address resolution when those hosts are directly connected to an NBMA subnetwork, allowing for straightforward implementations in NBMA stations. NHRP also has the capability of determining the egress point from an NBMA subnetwork when the destination is not directly connected to the NBMA subnetwork and the identity of the egress router is not learned by other methods (such as routing protocols). Optional extensions to NHRP provide additional robustness and diagnosability.
ホストがNBMAサブネットワークに直接接続されている場合にアドレス解決を行うホストでは、NHRPの使用で十分であり、NBMAステーションでの簡単な実装が可能になります。 NHRPには、宛先がNBMAサブネットワークに直接接続されておらず、他の方法（ルーティングプロトコルなど）で出力ルーターのIDが学習されていない場合に、NBMAサブネットワークからの出力ポイントを決定する機能もあります。 NHRPのオプションの拡張により、堅牢性と診断性が向上します。
Address resolution techniques such as those described in [3] and [4] may be in use when NHRP is deployed. ARP servers and services over NBMA subnetworks may be required to support hosts that are not capable of dealing with any model for communication other than the LIS model, and deployed hosts may not implement NHRP but may continue to support ARP variants such as those described in [3] and [4]. NHRP is intended to reduce or eliminate the extra router hops required by the LIS model, and can be deployed in a non-interfering manner with existing ARP services [14].
NHRPが展開されている場合、[3]や[4]で説明されているようなアドレス解決手法が使用されている可能性があります。 NBMAサブネットワークを介したARPサーバーとサービスは、LISモデル以外の通信モデルを処理できないホストをサポートするために必要になる場合があり、展開されたホストはNHRPを実装しない場合がありますが、[で説明されているようなARPバリアントを引き続きサポートする場合があります。 3]と[4]。 NHRPは、LISモデルに必要な追加のルーターホップを削減または排除することを目的としており、既存のARPサービスと干渉しない方法で展開できます[14]。
The operation of NHRP to establish transit paths across NBMA subnetworks between two routers requires additional mechanisms to avoid stable routing loops, and will be described in a separate document (see [13]).
2つのルーター間でNBMAサブネットワーク全体のトランジットパスを確立するNHRPの操作には、安定したルーティングループを回避するための追加のメカニズムが必要であり、別のドキュメントで説明します（[13]を参照）。
The term "network" is highly overloaded, and is especially confusing in the context of NHRP. We use the following terms:
「ネットワーク」という用語は非常に過負荷であり、NHRPのコンテキストでは特に混乱します。次の用語を使用します。
Internetwork layer--the media-independent layer (IP in the case of TCP/IP networks).
インターネットワーク層-メディアに依存しない層（TCP / IPネットワークの場合はIP）。
Subnetwork layer--the media-dependent layer underlying the internetwork layer, including the NBMA technology (ATM, X.25, SMDS, etc.)
サブネットワーク層-NBMAテクノロジー（ATM、X.25、SMDSなど）を含む、インターネットワーク層の基礎となるメディア依存層
The term "server", unless explicitly stated to the contrary, refers to a Next Hop Server (NHS). An NHS is an entity performing the Next Hop Resolution Protocol service within the NBMA cloud. An NHS is always tightly coupled with a routing entity (router, route server or edge device) although the converse is not yet guaranteed until ubiquitous deployment of this functionality occurs. Note that the presence of intermediate routers that are not coupled with an NHS entity may preclude the use of NHRP when source and destination stations on different sides of such routers and thus such routers may partition NHRP reachability within an NBMA network.
「サーバー」という用語は、そうでないことが明示的に述べられていない限り、ネクストホップサーバー（NHS）を指します。 NHSは、NBMAクラウド内でNext Hop Resolution Protocolサービスを実行するエンティティです。 NHSは常にルーティングエンティティ（ルーター、ルートサーバー、またはエッジデバイス）と密に結合されていますが、この機能のユビキタスな展開が行われるまで、その逆はまだ保証されていません。 NHSエンティティーと結合されていない中間ルーターが存在すると、そのようなルーターの異なる側にある送信元ステーションと宛先ステーションがNHRPの使用を妨げる可能性があるため、そのようなルーターがNBMAネットワーク内のNHRP到達可能性を分割する可能性があることに注意してください。
The term "client", unless explicitly stated to the contrary, refers to a Next Hop Resolution Protocol client (NHC). An NHC is an entity which initiates NHRP requests of various types in order to obtain access to the NHRP service.
「クライアント」という用語は、そうでないことが明示的に述べられていない限り、ネクストホップ解決プロトコルクライアント（NHC）を指します。 NHCは、NHRPサービスへのアクセスを取得するために、さまざまなタイプのNHRP要求を開始するエンティティです。
The term "station" generally refers to a host or router which contains an NHRP entity. Occasionally, the term station will describe a "user" of the NHRP client or service functionality; the difference in usage is largely semantic.
「ステーション」という用語は一般に、NHRPエンティティを含むホストまたはルーターを指します。ステーションという用語は、NHRPクライアントまたはサービス機能の「ユーザー」を表すことがあります。使用法の違いは主にセマンティックです。
In this section, we briefly describe how a source S (which potentially can be either a router or a host) uses NHRP to determine the "NBMA next hop" to destination D.
このセクションでは、ソースS（ルーターまたはホストの可能性があります）がNHRPを使用して宛先Dへの「NBMAネクストホップ」を決定する方法について簡単に説明します。
For administrative and policy reasons, a physical NBMA subnetwork may be partitioned into several, disjoint "Logical NBMA subnetworks". A Logical NBMA subnetwork is defined as a collection of hosts and routers that share unfiltered subnetwork connectivity over an NBMA subnetwork. "Unfiltered subnetwork connectivity" refers to the absence of closed user groups, address screening or similar features that may be used to prevent direct communication between stations connected to the same NBMA subnetwork. (Hereafter, unless otherwise specified, we use the term "NBMA subnetwork" to mean *logical* NBMA subnetwork.)
管理上およびポリシー上の理由により、物理NBMAサブネットワークは、いくつかの互いに素な「論理NBMAサブネットワーク」に分割される場合があります。論理NBMAサブネットワークは、NBMAサブネットワークを介してフィルタリングされていないサブネットワーク接続を共有するホストとルーターのコレクションとして定義されます。 「フィルタリングされていないサブネットワーク接続」とは、同じNBMAサブネットワークに接続されているステーション間の直接通信を防ぐために使用できる、閉じたユーザーグループ、アドレススクリーニング、または同様の機能がないことを指します。 （以下、特に指定のない限り、「NBMAサブネットワーク」という用語は*論理* NBMAサブネットワークを意味するために使用します。）
Placed within the NBMA subnetwork are one or more entities that implement the NHRP protocol. Such stations which are capable of answering NHRP Resolution Requests are known as "Next Hop Servers" (NHSs). Each NHS serves a set of destination hosts, which may or may not be directly connected to the NBMA subnetwork. NHSs cooperatively resolve the NBMA next hop within their logical NBMA subnetwork. In addition to NHRP, NHSs may support "classical" ARP service; however, this will be the subject of a separate document [14].
NBMAサブネットワーク内には、NHRPプロトコルを実装する1つ以上のエンティティが配置されます。 NHRP解決要求に応答できるこのようなステーションは、「ネクストホップサーバー」（NHS）として知られています。各NHSは、NBMAサブネットワークに直接接続されているかどうかに関係なく、一連の宛先ホストを提供します。 NHSは、論理的なNBMAサブネットワーク内でNBMAネクストホップを協調的に解決します。 NHRPに加えて、NHSは「クラシック」ARPサービスをサポートする場合があります。ただし、これは別のドキュメントの主題になります[14]。
An NHS maintains a cache which contains protocol layer address to NBMA subnetwork layer address resolution information. This cache can be constructed from information obtained from NHRP Register packets (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply packets, or through mechanisms outside the scope of this document (examples of such mechanisms might include ARP[3] and pre-configured tables). Section 6.2 further describes cache management issues.
NHSは、NBMAサブネットワーク層アドレス解決情報へのプロトコル層アドレスを含むキャッシュを維持します。このキャッシュは、NHRP Registerパケット（セクション5.2.3および5.2.4を参照）、NHRP解決要求/応答パケット、またはこのドキュメントの範囲外のメカニズム（このようなメカニズムの例にはARP [ 3]および事前設定されたテーブル）。セクション6.2では、キャッシュ管理の問題についてさらに説明します。
For a station within a given LIS to avoid providing NHS functionality, there must be one or more NHSs within the NBMA subnetwork which are providing authoritative address resolution information on its behalf. Such an NHS is said to be "serving" the station. A station on a LIS that lacks NHS functionality and is a client of the NHRP service is known as NHRP Client or just NHCs. If a serving NHS is to be able to supply the address resolution information for an NHC then NHSs must exist at each hop along all routed paths between the NHC making the resolution request and the destination NHC. The last NHRP entity along the routed path is the serving NHS; that is, NHRP Resolution Requests are not forwarded to destination NHCs but rather are processed by the serving NHS.
特定のLIS内のステーションがNHS機能の提供を回避するためには、NBMAサブネットワーク内に、その代理として信頼できるアドレス解決情報を提供している1つ以上のNHSが必要です。そのようなNHSはステーションに「サービスを提供している」と言われています。 NHS機能がなく、NHRPサービスのクライアントであるLIS上のステーションは、NHRPクライアントまたは単にNHCと呼ばれます。サービングNHSがNHCのアドレス解決情報を提供できるようにする場合、NHSは、解決要求を行うNHCと宛先NHCの間のすべてのルーティングパスに沿った各ホップに存在する必要があります。ルーティングされたパスに沿った最後のNHRPエンティティは、サービングNHSです。つまり、NHRP解決要求は宛先NHCに転送されず、サービスを提供するNHSによって処理されます。
An NHC also maintains a cache of protocol address to NBMA address resolution information. This cache is populated through information obtained from NHRP Resolution Reply packets, from manual configuration, or through mechanisms outside the scope of this document.
NHCは、NBMAアドレス解決情報へのプロトコルアドレスのキャッシュも維持します。このキャッシュは、NHRP解決応答パケットから、手動構成から、またはこのドキュメントの範囲外のメカニズムから取得された情報を通じて入力されます。
The protocol proceeds as follows. An event occurs triggering station S to want to resolve the NBMA address of a path to D. This is most likely to be when a data packet addressed to station D is to be emitted from station S (either because station S is a host, or station S is a transit router), but the address resolution could also be triggered by other means (a routing protocol update packet, for example). Station S first determines the next hop to station D through normal routing processes (for a host, the next hop may simply be the default router; for routers, this is the "next hop" to the destination internetwork layer address). If the destination's address resolution information is already available in S's cache then that information is used to forward the packet. Otherwise, if the next hop is reachable through one of its NBMA interfaces, S constructs an NHRP Resolution Request packet (see Section 5.2.1) containing station D's internetwork layer address as the (target) destination address, S's own internetwork layer address as the source address (Next Hop Resolution Request initiator), and station S's NBMA addressing information. Station S may also indicate that it prefers an authoritative NHRP Resolution Reply (i.e., station S only wishes to receive an NHRP Resolution Reply from an NHS serving the destination NHC). Station S emits the NHRP Resolution Request packet towards the destination.
プロトコルは次のように進行します。ステーションSをトリガーしてDへのパスのNBMAアドレスを解決しようとするイベントが発生します。これは、ステーションDにアドレス指定されたデータパケットがステーションSから送信される場合（ステーションSがホストであるか、ステーションSは中継ルーターです）が、アドレス解決は他の手段（ルーティングプロトコル更新パケットなど）によってもトリガーできます。ステーションSはまず、通常のルーティングプロセスを通じてステーションDへのネクストホップを決定します（ホストの場合、ネクストホップは単にデフォルトのルーターである場合があります。ルーターの場合、これは宛先インターネットワークレイヤーアドレスへの「ネクストホップ」です）。宛先のアドレス解決情報がSのキャッシュですでに利用可能な場合、その情報はパケットの転送に使用されます。それ以外の場合、NBMAインターフェースの1つを介してネクストホップに到達できる場合、SはステーションDのインターネットワークレイヤーアドレスを（ターゲット）宛先アドレスとして、Sの独自のインターネットワークレイヤーアドレスを含むNHRP解決要求パケット（セクション5.2.1を参照）を構築します。送信元アドレス（Next Hop Resolution Request Initiator）、およびステーションSのNBMAアドレス情報。ステーションSは、信頼できるNHRP解決応答を優先することも示します（つまり、ステーションSは、宛先NHCにサービスを提供しているNHSからNHRP解決応答を受信することのみを望みます）。ステーションSはNHRP解決要求パケットを宛先に向けて発信します。
If the NHRP Resolution Request is triggered by a data packet then S may, while awaiting an NHRP Resolution Reply, choose to dispose of the data packet in one of the following ways:
NHRP解決要求がデータパケットによってトリガーされた場合、SはNHRP解決応答を待っている間に、次のいずれかの方法でデータパケットを破棄することを選択できます。
(a) Drop the packet (b) Retain the packet until the NHRP Resolution Reply arrives and a more optimal path is available (c) Forward the packet along the routed path toward D
（a）パケットをドロップする（b）NHRP解決応答が到着し、より最適なパスが利用可能になるまでパケットを保持する（c）ルーティングされたパスに沿ってDに向けてパケットを転送する
The choice of which of the above to perform is a local policy matter, though option (c) is the recommended default, since it may allow data to flow to the destination while the NBMA address is being resolved. Note that an NHRP Resolution Request for a given destination MUST NOT be triggered on every packet.
上記のうちどれを選択するかはローカルポリシーの問題ですが、NBMAアドレスが解決されている間にデータを宛先に流すことができるため、オプション（c）が推奨されるデフォルトです。特定の宛先に対するNHRP解決要求は、すべてのパケットでトリガーされてはならないことに注意してください。
When the NHS receives an NHRP Resolution Request, a check is made to see if it serves station D. If the NHS does not serve D, the NHS forwards the NHRP Resolution Request to another NHS. Mechanisms for determining how to forward the NHRP Resolution Request are discussed in Section 3.
NHSは、NHRP解決要求を受信すると、ステーションDにサービスを提供しているかどうかを確認します。NHSがDにサービスを提供していない場合、NHSはNHRP解決要求を別のNHSに転送します。 NHRP解決要求の転送方法を決定するメカニズムについては、セクション3で説明します。
If this NHS serves D, the NHS resolves station D's NBMA address information, and generates a positive NHRP Resolution Reply on D's behalf. NHRP Resolution Replies in this scenario are always marked as "authoritative". The NHRP Resolution Reply packet contains the address resolution information for station D which is to be sent back to S. Note that if station D is not on the NBMA subnetwork, the next hop internetwork layer address will be that of the egress router through which packets for station D are forwarded.
このNHSがDにサービスを提供する場合、NHSはステーションDのNBMAアドレス情報を解決し、Dの代わりに肯定的なNHRP解決応答を生成します。このシナリオでのNHRP解決応答は常に「信頼できる」とマークされます。 NHRP解決応答パケットには、ステーションDのアドレス解決情報が含まれています。これは、Sに送り返されます。ステーションDがNBMAサブネットワーク上にない場合、ネクストホップのインターネットワークレイヤーアドレスは、パケットが通過する出口ルーターのアドレスになります。ステーションDが転送されます。
A transit NHS receiving an NHRP Resolution Reply may cache the address resolution information contained therein. To a subsequent NHRP Resolution Request, this NHS may respond with the cached, "non-authoritative" address resolution information if the NHS is permitted to do so (see Sections 5.2.2 and 6.2 for more information on non-authoritative versus authoritative NHRP Resolution Replies). Non-authoritative NHRP Resolution Replies are distinguished from authoritative NHRP Resolution Replies so that if a communication attempt based on non-authoritative information fails, a source station can choose to send an authoritative NHRP Resolution Request. NHSs MUST NOT respond to authoritative NHRP Resolution Requests with cached information.
NHRP解決応答を受信するトランジットNHSは、そこに含まれるアドレス解決情報をキャッシュすることができます。後続のNHRP解決要求に対して、NHSが許可されている場合、このNHSはキャッシュされた「権限のない」アドレス解決情報で応答します（権限のないNHRP解決と権限のないNHRP解決の詳細については、セクション5.2.2および6.2を参照してください）。返信）。権限のないNHRP解決応答は、権限のあるNHRP解決応答とは区別されるため、権限のない情報に基づく通信試行が失敗した場合、ソースステーションは、権限のあるNHRP解決要求を送信することを選択できます。 NHSは、キャッシュされた情報を使用して、信頼できるNHRP解決要求に応答してはなりません（MUST NOT）。
If the determination is made that no NHS in the NBMA subnetwork can reply to the NHRP Resolution Request for D then a negative NHRP Resolution Reply (NAK) is returned. This occurs when (a) no next-hop resolution information is available for station D from any NHS, or (b) an NHS is unable to forward the NHRP Resolution Request (e.g., connectivity is lost).
NBMAサブネットワークのNHSがDのNHRP解決要求に応答できないと判断された場合、否定のNHRP解決応答（NAK）が返されます。これは、（a）NHSからのステーションDのネクストホップ解決情報がない場合、または（b）NHSがNHRP解決要求を転送できない場合（接続が失われた場合など）に発生します。
NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies, and NHRP Error Indications follow a routed path in the same fashion that NHRP Resolution Requests and NHRP Resolution Replies do. Specifically, "requests" and "indications" follow the routed path from Source Protocol Address (which is the address of the station initiating the communication) to the Destination Protocol Address. "Replies", on the other hand, follow the routed path from the Destination Protocol Address back to the Source Protocol Address with the following exceptions: in the case of a NHRP Registration Reply and in the case of an NHC initiated NHRP Purge Request, the packet is always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if one does not exists then one MUST be created.
NHRP登録要求、NHRPパージ要求、NHRPパージ応答、およびNHRPエラー表示は、NHRP解決要求およびNHRP解決応答と同じ方法でルーティングされたパスに従います。具体的には、「要求」と「表示」は、ソースプロトコルアドレス（通信を開始するステーションのアドレス）から宛先プロトコルアドレスへのルーティングパスに従います。一方、「応答」は、次の例外を除いて、宛先プロトコルアドレスから送信元プロトコルアドレスに戻る経路をたどります。NHRP登録応答の場合、およびNHCが開始したNHRPパージ要求の場合、パケットは常に直接VC経由で返されます（セクション5.2.4および5.2.5を参照）。存在しない場合は作成する必要があります。
NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA subnetwork however further study is being done in this area (see Section 7). Thus, the internetwork layer data traffic out of and into an NBMA subnetwork always traverses an internetwork layer router at its border.
NHRP要求とNHRP応答はNBMAサブネットワークの境界を越えることはありませんが、この領域でさらに調査が行われています（セクション7を参照）。したがって、NBMAサブネットワークを出入りするインターネットワーク層のデータトラフィックは、常に境界でインターネットワーク層ルーターを通過します。
NHRP optionally provides a mechanism to send a NHRP Resolution Reply which contains aggregated address resolution information. For example, suppose that router X is the next hop from station S to station D and that X is an egress router for all stations sharing an internetwork layer address prefix with station D. When an NHRP Resolution Reply is generated in response to a NHRP Resolution Request, the responder may augment the internetwork layer address of station D with a prefix length (see Section 5.2.0.1). A subsequent (non-authoritative) NHRP Resolution Request for some destination that shares an internetwork layer address prefix (for the number of bits specified in the prefix length) with D may be satisfied with this cached information. See section 6.2 regarding caching issues.
NHRPは、オプションで、集約されたアドレス解決情報を含むNHRP解決応答を送信するメカニズムを提供します。たとえば、ルーターXがステーションSからステーションDへのネクストホップであり、XがステーションDとインターネットワークレイヤアドレスプレフィックスを共有するすべてのステーションの出力ルーターであるとします。NHRP解決への応答としてNHRP解決応答が生成される場合リクエスト、レスポンダは、ステーションDのインターネットワークレイヤアドレスをプレフィックス長で増やします（セクション5.2.0.1を参照）。 Dとインターネットワーク層アドレスプレフィックス（プレフィックス長で指定されたビット数）を共有する宛先に対する後続の（権限のない）NHRP解決要求は、このキャッシュされた情報で満たされる場合があります。キャッシュの問題については、セクション6.2を参照してください。
To dynamically detect subnetwork-layer filtering in NBMA subnetworks (e.g., X.25 closed user group facility, or SMDS address screens), to trace the routed path that an NHRP packet takes, or to provide loop detection and diagnostic capabilities, a "Route Record" may be included in NHRP packets (see Sections 5.3.2 and 5.3.3). The Route Record extensions are the NHRP Forward Transit NHS Record Extension and the NHRP Reverse Transit NHS Record Extension. They contain the internetwork (and subnetwork layer) addresses of all intermediate NHSs between source and destination and between destination and source respectively. When a source station is unable to communicate with the responder (e.g., an attempt to open an SVC fails), it may attempt to do so successively with other subnetwork layer addresses in the NHRP Forward Transit NHS Record Extension until it succeeds (if authentication policy permits such action). This approach can find a suitable egress point in the presence of subnetwork-layer filtering (which may be source/destination sensitive, for instance, without necessarily creating separate logical NBMA subnetworks) or subnetwork-layer congestion (especially in connection-oriented media).
NBMAサブネットワーク（X.25クローズドユーザーグループファシリティ、またはSMDSアドレス画面など）でサブネットワークレイヤーフィルタリングを動的に検出する、NHRPパケットが経由するルーティングパスを追跡する、またはループ検出と診断機能を提供するには、「ルート記録」はNHRPパケットに含まれている場合があります（セクション5.3.2および5.3.3を参照）。ルートレコード拡張は、NHRP Forward Transit NHSレコード拡張とNHRP Reverse Transit NHSレコード拡張です。これらには、それぞれ送信元と宛先の間、および宛先と送信元の間のすべての中間NHSのインターネットワーク（およびサブネットワークレイヤー）アドレスが含まれています。ソースステーションがレスポンダと通信できない場合（SVCを開く試みが失敗した場合など）は、成功するまで、NHRP Forward Transit NHS Record Extension内の他のサブネットワークレイヤーアドレスと連続して通信を試みる場合があります（認証ポリシーの場合）。そのような行為を許可する）。このアプローチは、サブネットワークレイヤーフィルタリング（たとえば、必ずしも送信元/宛先に依存する可能性があり、個別の論理NBMAサブネットワークを作成する必要がない場合）またはサブネットワークレイヤーの輻輳（特に接続指向のメディア）がある場合に、適切な出口ポイントを見つけることができます。
NHRP Resolution Requests traverse one or more hops within an NBMA subnetwork before reaching the station that is expected to generate a response. Each station, including the source station, chooses a neighboring NHS to which it will forward the NHRP Resolution Request. The NHS selection procedure typically involves applying a destination protocol layer address to the protocol layer routing table which causes a routing decision to be returned. This routing decision is then used to forward the NHRP Resolution Request to the downstream NHS. The destination protocol layer address previously mentioned is carried within the NHRP Resolution Request packet. Note that even though a protocol layer address was used to acquire a routing decision, NHRP packets are not encapsulated within a protocol layer header but rather are carried at the NBMA layer using the encapsulation described in Section 5.
NHRP解決要求は、応答の生成が予想されるステーションに到達する前に、NBMAサブネットワーク内の1つ以上のホップを通過します。ソースステーションを含む各ステーションは、NHRP解決要求の転送先となる隣接NHSを選択します。 NHS選択手順では、通常、宛先プロトコルレイヤーアドレスをプロトコルレイヤールーティングテーブルに適用して、ルーティングの決定を返します。このルーティング決定は、NHRP解決要求をダウンストリームNHSに転送するために使用されます。前述の宛先プロトコル層アドレスは、NHRP解決要求パケット内で運ばれます。プロトコル層アドレスがルーティング決定の取得に使用されたとしても、NHRPパケットはプロトコル層ヘッダー内にカプセル化されず、セクション5で説明されているカプセル化を使用してNBMA層で運ばれることに注意してください。
Each NHS/router examines the NHRP Resolution Request packet on its way toward the destination. Each NHS which the NHRP packet traverses on the way to the packet's destination might modify the packet (e.g., updating the Forward Record extension). Ignoring error situations, the NHRP Resolution Request eventually arrives at a station that is to generate an NHRP Resolution Reply. This responding station "serves" the destination. The responding station generates an NHRP Resolution Reply using the source protocol address from within the NHRP packet to determine where the NHRP Resolution Reply should be sent.
各NHS /ルーターは、宛先に向かう途中でNHRP解決要求パケットを調べます。 NHRPパケットがパケットの宛先に向かう途中で通過する各NHSは、パケットを変更する可能性があります（たとえば、転送レコード拡張の更新）。エラー状況を無視して、NHRP解決要求は最終的にNHRP解決応答を生成するステーションに到着します。この応答ステーションは宛先を「提供」します。応答ステーションは、NHRPパケット内からソースプロトコルアドレスを使用してNHRP解決応答を生成し、NHRP解決応答の送信先を決定します。
Rather than use routing to determine the next hop for an NHRP packet, an NHS may use other applicable means (such as static configuration information ) in order to determine to which neighboring NHSs to forward the NHRP Resolution Request packet as long as such other means would not cause the NHRP packet to arrive at an NHS which is not along the routed path. The use of static configuration information for this purpose is beyond the scope of this document.
NHRPは、ルーティングを使用してNHRPパケットのネクストホップを決定するのではなく、他の適用可能な手段（静的構成情報など）を使用して、NHRP解決要求パケットを転送する近隣のNHSを決定することができますNHRPパケットがルーティングされたパスに沿っていないNHSに到着しないようにします。この目的で静的構成情報を使用することは、このドキュメントの範囲外です。
The NHS serving a particular destination must lie along the routed path to that destination. In practice, this means that all egress routers must double as NHSs serving the destinations beyond them, and that hosts on the NBMA subnetwork are served by routers that double as NHSs. Also, this implies that forwarding of NHRP packets within an NBMA subnetwork requires a contiguous deployment of NHRP capable routers. It is important that, in a given LIS/LAG which is using NHRP, all NHSs within the LIS/LAG have at least some portion of their resolution databases synchronized so that a packet arriving at one router/NHS in a given LIS/LAG will be forwarded in the same fashion as a packet arriving at a different router/NHS for the given LIS/LAG. One method, among others, is to use the Server Cache Synchronization Protocol (SCSP) [12]. It is RECOMMENDED that SCSP be the method used when a LIS/LAG contains two or more router/NHSs.
特定の宛先にサービスを提供するNHSは、その宛先へのルーティングされたパスに沿っている必要があります。実際には、これはすべての出口ルーターが宛先を超えるNHSとして機能する必要があり、NBMAサブネットワーク上のホストはNHSを兼ねるルーターによって処理されることを意味します。また、これは、NBMAサブネットワーク内でNHRPパケットを転送するには、NHRP対応ルーターを連続して配置する必要があることを意味します。 NHRPを使用する特定のLIS / LAGでは、LIS / LAG内のすべてのNHSが解決データベースの少なくとも一部を同期しているため、特定のLIS / LAGの1つのルーター/ NHSに到着するパケットは、特定のLIS / LAGの異なるルーター/ NHSに到着するパケットと同じ方法で転送されます。とりわけ、1つの方法は、サーバーキャッシュ同期プロトコル（SCSP）を使用することです[12]。 LIS / LAGに2つ以上のルーター/ NHSが含まれている場合、SCSPを使用する方法をお勧めします。
During migration to NHRP, it cannot be expected that all routers within the NBMA subnetwork are NHRP capable. Thus, NHRP traffic which would otherwise need to be forwarded through such routers can be expected to be dropped due to the NHRP packet not being recognized. In this case, NHRP will be unable to establish any transit paths whose discovery requires the traversal of the non-NHRP speaking routers. If the client has tried and failed to acquire a cut through path then the client should use the network layer routed path as a default.
NHRPへの移行中、NBMAサブネットワーク内のすべてのルーターがNHRP対応であることは期待できません。したがって、そうでなければそのようなルータを介して転送する必要があるNHRPトラフィックは、NHRPパケットが認識されないためにドロップされることが予想されます。この場合、NHRPは、非NHRPを話すルーターの通過が必要なディスカバリーの通過パスを確立できません。クライアントがカットスルーパスを取得しようとして失敗した場合、クライアントはデフォルトとしてネットワーク層のルーティングされたパスを使用する必要があります。
If an NBMA technology offers a group, an anycast, or a multicast addressing feature then the NHC may be configured with such an address (appropriate to the routing realm it participates in) which would be assigned to all NHS serving that routing realm. This address can then be used for establishing an initial connection to an NHS to transmit a registration request. This address may not be used for sending NHRP requests. The resulting VC may be used for NHRP requests if and only if the registration response is received over that VC, thereby indicating that one happens to have anycast connected to an NHS serving the LIS/LAG. In the case of non-connection oriented networks, or of multicast (rather than anycast) addresses, the addres MUST NOT be used for sending NHRP resolution requests.
NBMAテクノロジーがグループ、エニーキャスト、またはマルチキャストアドレッシング機能を提供する場合、NHCは、そのルーティングレルムにサービスを提供するすべてのNHSに割り当てられるアドレス（それが参加するルーティングレルムに適切）で構成されます。このアドレスは、NHSへの初期接続を確立して登録要求を送信するために使用できます。このアドレスは、NHRP要求の送信には使用できません。結果のVCは、登録応答がそのVCを介して受信された場合にのみNHRP要求に使用できます。これにより、LIS / LAGを提供するNHSにエニーキャストが接続されていることを示します。非接続指向ネットワークの場合、またはマルチキャスト（エニーキャストではなく）アドレスの場合、アドレスはNHRP解決要求の送信に使用してはなりません（MUST NOT）。
When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined for the NHC directly to the NHC. That is, the NHRP message MUST NOT transit through any NHS which is not serving the NHC when the NHRP message is currently at an NHS which does serve the NHC (this, of course, assumes the NHRP message is destined for the NHC). Further, an NHS which serves an NHC SHOULD have a direct NBMA level connection to that NHC (see Section 5.2.3 and 5.2.4 for examples).
NHSがNHCを「提供」する場合、NHSはNHC宛てのNHRPメッセージを直接NHCに送信する必要があります。つまり、NHRPメッセージが現在NHCにサービスを提供しているNHSにある場合、NHRPメッセージはNHCにサービスを提供していないNHSを通過してはなりません（もちろん、これはNHRPメッセージがNHC宛てであることを前提としています）。さらに、NHCを提供するNHSは、そのNHCに直接NBMAレベルで接続する必要があります（例については、セクション5.2.3および5.2.4を参照してください）。
With the exception of NHRP Registration Requests (see Section 5.2.3 and 5.2.4 for details of the NHRP Registration Request case), an NHC MUST send NHRP messages over a direct NBMA level connection between the serving NHS and the served NHC.
NHRP登録要求（NHRP登録要求の詳細については、セクション5.2.3および5.2.4を参照）を除き、NHCは、サービスするNHSとサービスされるNHCの間の直接NBMAレベルの接続を介してNHRPメッセージを送信する必要があります。
It may not be desirable to maintain semi-permanent NBMA level connectivity between the NHC and the NHS. In this case, when NBMA level connectivity is initially setup between the NHS and the NHC (as described in Section 5.2.4), the NBMA address of the NHS should be obtained through the NBMA level signaling technology. This address should be stored for future use in setting up subsequent NBMA level connections. A somewhat more information rich technique to obtain the address information (and more) of the serving NHS would be for the NHC to include the Responder Address extension (see Section 5.3.1) in the NHRP Registration Request and to store the information returned to the NHC in the Responder Address extension which is subsequently included in the NHRP Registration Reply. Note also that, in practice, a client's default router should also be its NHS; thus a client may be able to know the NBMA address of its NHS from the configuration which was already required for the client to be able to communicate. Further, as mentioned in Section 4, NHCs may be configured with the addressing information of one or more NHSs.
NHCとNHSの間の半永久的なNBMAレベルの接続を維持することは望ましくない場合があります。この場合、NBMAレベルの接続がNHSとNHCの間で最初にセットアップされるとき（セクション5.2.4で説明）、NHSのNBMAアドレスは、NBMAレベルのシグナリングテクノロジーを介して取得する必要があります。このアドレスは、後続のNBMAレベルの接続のセットアップで将来使用するために保存する必要があります。 NHCがNHRP登録要求にレスポンダーアドレス拡張（セクション5.3.1を参照）を含め、返された情報をNHRP Registration Replyに後で含まれるResponder Address拡張のNHC。また、実際には、クライアントのデフォルトルーターもNHSである必要があります。したがって、クライアントは、クライアントが通信できるようにするためにすでに必要であった構成から、NHSのNBMAアドレスを知ることができる場合があります。さらに、セクション4で述べたように、NHCは1つ以上のNHSのアドレス指定情報を使用して構成できます。
Next Hop Clients
ネクストホップクライアント
An NHC connected to an NBMA subnetwork MAY be configured with the Protocol address(es) and NBMA address(es) of its NHS(s). The NHS(s) will likely also represent the NHC's default or peer routers, so their NBMA addresses may be obtained from the NHC's existing configuration. If the NHC is attached to several subnetworks (including logical NBMA subnetworks), the NHC should also be configured to receive routing information from its NHS(s) and peer routers so that it can determine which internetwork layer networks are reachable through which subnetworks.
NBMAサブネットワークに接続されたNHCは、そのNHSのプロトコルアドレスとNBMAアドレスで構成できます。 NHSはおそらくNHCのデフォルトまたはピアルーターも表すため、それらのNBMAアドレスはNHCの既存の構成から取得できます。 NHCが複数のサブネットワーク（論理NBMAサブネットワークを含む）に接続されている場合、NHSは、NHSとピアルーターからルーティング情報を受信するように構成して、どのサブネットワークを介して到達できるインターネットワークレイヤーネットワークを判別できるようにする必要があります。
Next Hop Servers
ネクストホップサーバー
An NHS is configured with knowledge of its own internetwork layer and NBMA addresses. An NHS MAY also be configured with a set of internetwork layer address prefixes that correspond to the internetwork layer addresses of the stations it serves. The NBMA addresses of the stations served by the NHS may be learned via NHRP Registration packets.
NHSは、独自のインターネットワーク層とNBMAアドレスの知識で構成されています。 NHSは、サービスを提供するステーションのインターネットワークレイヤーアドレスに対応するインターネットワークレイヤーアドレスプレフィックスのセットで構成することもできます（MAY）。 NHSがサービスを提供するステーションのNBMAアドレスは、NHRP登録パケットを介して学習できます。
If a served NHC is attached to several subnetworks, the router/route-server coresident with the serving NHS may also need to be configured to advertise routing information to such NHCs.
サービス対象のNHCが複数のサブネットワークに接続されている場合、サービス提供NHSと共存するルーター/ルートサーバーも、そのようなNHCにルーティング情報を通知するように構成する必要がある場合があります。
If an NHS acts as an egress router for stations connected to other subnetworks than the NBMA subnetwork, the NHS must, in addition to the above, be configured to exchange routing information between the NBMA subnetwork and these other subnetworks.
NHSがNBMAサブネットワーク以外の他のサブネットワークに接続されたステーションの出力ルーターとして機能する場合、上記に加えて、NHSを構成して、NBMAサブネットワークと他のサブネットワークの間でルーティング情報を交換する必要があります。
In all cases, routing information is exchanged using conventional intra-domain and/or inter-domain routing protocols.
すべての場合において、ルーティング情報は、従来のドメイン内および/またはドメイン間ルーティングプロトコルを使用して交換されます。
This section describes the format of NHRP packets. In the following, unless otherwise stated explicitly, the unqualified term "request" refers generically to any of the NHRP packet types which are "requests". Further, unless otherwise stated explicitly, the unqualified term "reply" refers generically to any of the NHRP packet types which are "replies".
このセクションでは、NHRPパケットのフォーマットについて説明します。以下では、特に明記されていない限り、「要求」という限定されていない用語は、「要求」であるNHRPパケットタイプのいずれかを総称的に指します。さらに、特に明記されていない限り、「無条件」という用語「応答」は、一般的に「応答」であるNHRPパケットタイプのいずれかを指します。
An NHRP packet consists of a Fixed Part, a Mandatory Part, and an Extensions Part. The Fixed Part is common to all NHRP packet types. The Mandatory Part MUST be present, but varies depending on packet type. The Extensions Part also varies depending on packet type, and need not be present.
NHRPパケットは、固定部分、必須部分、および拡張部分で構成されています。固定部分は、すべてのNHRPパケットタイプに共通です。必須部分は必ず存在する必要がありますが、パケットタイプによって異なります。拡張部分もパケットタイプによって異なり、存在する必要はありません。
The length of the Fixed Part is fixed at 20 octets. The length of the Mandatory Part is determined by the contents of the extensions offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part length is equal to total packet length (ar$pktsz) minus 20 otherwise the mandatory part length is equal to ar$extoff minus 20. The length of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs may increase the size of an NHRP packet as a result of extension processing, but not beyond the offered maximum packet size of the NBMA network.
固定部分の長さは20オクテットに固定されています。必須部分の長さは、拡張オフセットフィールド（ar $ extoff）の内容によって決まります。 ar $ extoff = 0x0の場合、必須部分の長さは合計パケット長（ar $ pktsz）-20に等しく、それ以外の場合、必須部分の長さはar $ extoff-20に等しくなります。拡張部分の長さは、ar $ pktszに含まれます。マイナスar $ extoff。 NHSは、拡張処理の結果としてNHRPパケットのサイズを増やす可能性がありますが、NBMAネットワークの提供された最大パケットサイズを超えることはありません。
NHRP packets are actually members of a wider class of address mapping and management protocols being developed by the IETF. A specific encapsulation, based on the native formats used on the particular NBMA network over which NHRP is carried, indicates the generic IETF mapping and management protocol. For example, SMDS networks always use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet is preceded by the following LLC/SNAP encapsulation:
NHRPパケットは、実際には、IETFによって開発されているより広範なクラスのアドレスマッピングおよび管理プロトコルのメンバーです。 NHRPが伝送される特定のNBMAネットワークで使用されるネイティブフォーマットに基づく特定のカプセル化は、一般的なIETFマッピングおよび管理プロトコルを示します。たとえば、SMDSネットワークは常にNBMAレイヤーでLLC / SNAPカプセル化を使用し[4]、NHRPパケットの前に次のLLC / SNAPカプセル化が続きます。
[0xAA-AA-03] [0x00-00-5E] [0x00-03]
[0xAA-AA-03] [0x00-00-5E] [0x00-03]
The first three octets are LLC, indicating that SNAP follows. The SNAP OUI portion is the IANA's OUI, and the SNAP PID portion identifies the mapping and management protocol. A field in the Fixed Header following the encapsulation indicates that it is NHRP.
最初の3つのオクテットはLLCであり、SNAPが続くことを示します。 SNAP OUI部分はIANAのOUIであり、SNAP PID部分はマッピングおよび管理プロトコルを識別します。カプセル化に続く固定ヘッダーのフィールドは、それがNHRPであることを示しています。
ATM uses either LLC/SNAP encapsulation of each packet (including NHRP), or uses no encapsulation on VCs dedicated to a single protocol (see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or identification of NHRP, using a NLPID of 0x0080 and the same SNAP contents as above (see [8], [9]).
ATMは、各パケット（NHRPを含む）のLLC / SNAPカプセル化を使用するか、単一のプロトコル専用のVCでカプセル化を使用しません（[7]を参照）。フレームリレーとX.25はどちらも、NLPID / SNAPカプセル化またはNHRPの識別を使用し、NLPIDを0x0080とし、上記と同じSNAPコンテンツを使用します（[8]、[9]を参照）。
Fields marked "unused" MUST be set to zero on transmission, and ignored on receipt.
「未使用」とマークされたフィールドは、送信時にゼロに設定し、受信時に無視する必要があります。
Most packet types (ar$op.type) have both internetwork layer protocol-independent fields and protocol-specific fields. The protocol type/snap fields (ar$pro.type/snap) qualify the format of the protocol-specific fields.
ほとんどのパケットタイプ（ar $ op.type）には、インターネットワーク層のプロトコルに依存しないフィールドとプロトコル固有のフィールドの両方があります。プロトコルタイプ/スナップフィールド（ar $ pro.type / snap）は、プロトコル固有フィールドのフォーマットを修飾します。
The Fixed Part of the NHRP packet contains those elements of the NHRP packet which are always present and do not vary in size with the type of packet.
NHRPパケットの固定部分には、常に存在し、パケットのタイプによってサイズが変化しないNHRPパケットの要素が含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$afn | ar$pro.type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$pro.snap | ar$hopcnt | ar$pktsz |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$chksum | ar$extoff |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$op.version | ar$op.type | ar$shtl | ar$sstl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ar$afn Defines the type of "link layer" addresses being carried. This number is taken from the 'address family number' list specified in [6]. This field has implications to the coding of ar$shtl and ar$sstl as described below.
ar $ afn伝送される「リンク層」アドレスのタイプを定義します。この番号は、[6]で指定された「アドレスファミリー番号」リストから取得されます。このフィールドは、以下で説明するように、ar $ shtlおよびar $ sstlのコーディングに影響を与えます。
ar$pro.type field is a 16 bit unsigned integer representing the following number space:
ar $ pro.typeフィールドは、次の数値スペースを表す16ビットの符号なし整数です。
0x0000 to 0x00FF Protocols defined by the equivalent NLPIDs. 0x0100 to 0x03FF Reserved for future use by the IETF. 0x0400 to 0x04FF Allocated for use by the ATM Forum. 0x0500 to 0x05FF Experimental/Local use. 0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes.
0x0000〜0x00FF同等のNLPIDで定義されたプロトコル。 0x0100〜0x03FF IETFによる将来の使用のために予約されています。 0x0400〜0x04FF ATMフォーラムで使用するために割り当てられます。 0x0500〜0x05FF実験的/ローカルでの使用。同等のEthertypeで定義された0x0600〜0xFFFFプロトコル。
(based on the observations that valid Ethertypes are never smaller than 0x600, and NLPIDs never larger than 0xFF.)
（有効なEthertypeは決して0x600より小さく、NLPIDは決して0xFFより大きくないという観察に基づいています。）
ar$pro.snap When ar$pro.type has a value of 0x0080, a SNAP encoded extension is being used to encode the protocol type. This snap extension is placed in the ar$pro.snap field. This is termed the 'long form' protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be zero on transmit and ignored on receive. The ar$pro.type field itself identifies the protocol being referred to. This is termed the 'short form' protocol ID.
ar $ pro.snap ar $ pro.typeの値が0x0080の場合、SNAPエンコードされた拡張機能がプロトコルタイプのエンコードに使用されています。このスナップ拡張は、ar $ pro.snapフィールドに配置されます。これは「長い形式」のプロトコルIDと呼ばれます。 ar $ pro！= 0x0080の場合、ar $ pro.snapフィールドは送信時にゼロであり、受信時に無視される必要があります。 ar $ pro.typeフィールド自体は、参照されるプロトコルを識別します。これは「短縮形」のプロトコルIDと呼ばれます。
In all cases, where a protocol has an assigned number in the ar$pro.type space (excluding 0x0080) the short form MUST be used when transmitting NHRP messages; i.e., if Ethertype or NLPID codings exist then they are used on transmit rather than the ethertype. If both Ethertype and NLPID codings exist then when transmitting NHRP messages, the Ethertype coding MUST be used (this is consistent with RFC 1483 coding). So, for example, the following codings exist for IP:
すべての場合において、プロトコルがar $ pro.typeスペース（0x0080を除く）に割り当てられた番号を持っている場合、NHRPメッセージを送信するときに短い形式を使用する必要があります。つまり、EthertypeまたはNLPIDコーディングが存在する場合、それらはEthertypeではなく送信で使用されます。 EthertypeコーディングとNLPIDコーディングの両方が存在する場合、NHRPメッセージを送信するときは、Ethertypeコーディングを使用する必要があります（これはRFC 1483コーディングと一致しています）。したがって、たとえば、IPには次のコーディングが存在します。
SNAP: ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00
NLPID: ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00
Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00
and thus, since the Ethertype coding exists, it is used in preference.
したがって、Ethertypeコーディングが存在するため、優先的に使用されます。
ar$hopcnt The Hop count indicates the maximum number of NHSs that an NHRP packet is allowed to traverse before being discarded. This field is used in a similar fashion to the way that a TTL is used in an IP packet and should be set accordingly. Each NHS decrements the TTL as the NHRP packet transits the NHS on the way to the next hop along the routed path to the destination. If an NHS receives an NHRP packet which it would normally forward to a next hop and that packet contains an ar$hopcnt set to zero then the NHS sends an error indication message back to the source protocol address stating that the hop count has been exceeded (see Section 5.2.7) and the NHS drops the packet in error; however, an error indication is never sent as a result of receiving an error indication. When a responding NHS replies to an NHRP request, that NHS places a value in ar$hopcnt as if it were sending a request of its own.
ar $ hopcntホップカウントは、NHRPパケットが破棄されるまでに通過できるNHSの最大数を示します。このフィールドは、TTLがIPパケットで使用されるのと同じように使用され、それに応じて設定する必要があります。 NHRPパケットが宛先へのルーテッドパスに沿ってネクストホップに向かう途中でNHSを通過するときに、各NHSはTTLをデクリメントします。 NHSが通常次のホップに転送するNHRPパケットを受信し、そのパケットに0に設定されたar $ hopcntが含まれている場合、NHSはホップ数が超過したことを示すエラー表示メッセージを送信元プロトコルアドレスに送信します（セクション5.2.7を参照）、NHSはエラーのあるパケットをドロップします。ただし、エラー表示を受信した結果としてエラー表示が送信されることはありません。応答するNHSがNHRP要求に応答すると、そのNHSは独自の要求を送信しているかのように値をar $ hopcntに入れます。
ar$pktsz The total length of the NHRP packet, in octets (excluding link layer encapsulation).
ar $ pktsz NHRPパケットの全長（オクテット単位）（リンク層カプセル化を除く）。
ar$chksum The standard IP checksum over the entire NHRP packet starting at the fixed header. If the packet is an odd number of bytes in length then this calculation is performed as if a byte set to 0x00 is appended to the end of the packet.
ar $ chksum固定ヘッダーから始まるNHRPパケット全体の標準IPチェックサム。パケットの長さが奇数バイトである場合、この計算は、0x00に設定されたバイトがパケットの最後に追加されるかのように実行されます。
ar$extoff This field identifies the existence and location of NHRP extensions. If this field is 0 then no extensions exist otherwise this field represents the offset from the beginning of the NHRP packet (i.e., starting from the ar$afn field) of the first extension.
ar $ extoffこのフィールドは、NHRP拡張の存在と場所を識別します。このフィールドが0の場合、拡張は存在しません。それ以外の場合、このフィールドは、最初の拡張のNHRPパケットの先頭からの（つまり、ar $ afnフィールドからの）オフセットを表します。
ar$op.version This field indicates what version of generic address mapping and management protocol is represented by this message.
ar $ op.versionこのフィールドは、このメッセージによって表される汎用アドレスマッピングおよび管理プロトコルのバージョンを示します。
0 MARS protocol [11]. 1 NHRP as defined in this document. 0x02 - 0xEF Reserved for future use by the IETF. 0xF0 - 0xFE Allocated for use by the ATM Forum. 0xFF Experimental/Local use.
0 MARSプロトコル[11]。このドキュメントで定義されている1 NHRP。 0x02-0xEF IETFによる将来の使用のために予約されています。 0xF0-0xFE ATMフォーラムで使用するために割り当てられます。 0xFF実験的/ローカル使用。
ar$op.type When ar$op.version == 1, this is the NHRP packet type: NHRP Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP Purge Reply(6), or NHRP Error Indication(7). Use of NHRP packet Types in the range 128 to 255 are reserved for research or use in other protocol development and will be administered by IANA as described in Section 9.
ar $ op.type ar $ op.version == 1の場合、これはNHRPパケットタイプです。NHRP解決要求（1）、NHRP解決応答（2）、NHRP登録要求（3）、NHRP登録応答（4）、 NHRPパージ要求（5）、NHRPパージ応答（6）、またはNHRPエラー表示（7）。 128から255の範囲のNHRPパケットタイプの使用は、研究または他のプロトコル開発での使用のために予約されており、セクション9で説明されているようにIANAによって管理されます。
ar$shtl Type & length of source NBMA address interpreted in the context of the 'address family number'[6] indicated by ar$afn. See below for more details.
ar $ shtl ar $ afnで示される「アドレスファミリ番号」[6]のコンテキストで解釈されるソースNBMAアドレスのタイプと長さ。詳細については、以下を参照してください。
ar$sstl Type & length of source NBMA subaddress interpreted in the context of the 'address family number'[6] indicated by ar$afn. When an NBMA technology has no concept of a subaddress, the subaddress length is always coded ar$sstl = 0 and no storage is allocated for the subaddress in the appropriate mandatory part. See below for more details.
ar $ sstl ar $ afnで示される「アドレスファミリ番号」[6]のコンテキストで解釈されるソースNBMAサブアドレスのタイプと長さ。 NBMAテクノロジーにサブアドレスの概念がない場合、サブアドレスの長さは常にar $ sstl = 0とコーディングされ、適切な必須部分のサブアドレスにストレージは割り当てられません。詳細については、以下を参照してください。
Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr T/L) and subnetwork layer subaddresses type/length fields (e.g., ar$sstl, Cli SAddr T/L) are coded as follows:
サブネットワークレイヤーのアドレスタイプ/長さフィールド（ar $ shtl、Cli Addr T / Lなど）とサブネットワークレイヤーのサブアドレスタイプ/長さフィールド（ar $ sstl、Cli SAddr T / Lなど）は、次のようにコーディングされます。
7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|0|x| length |
+-+-+-+-+-+-+-+-+
The most significant bit is reserved and MUST be set to zero. The second most significant bit (x) is a flag indicating whether the address being referred to is in:
最上位ビットは予約されており、ゼロに設定する必要があります。 2番目の最上位ビット（x）は、参照されているアドレスが次のいずれにあるかを示すフラグです。
- NSAP format (x = 0). - Native E.164 format (x = 1).
- NSAP形式（x = 0）。 -ネイティブE.164形式（x = 1）。
For NBMA technologies that use neither NSAP nor E.164 format addresses, x = 0 SHALL be used to indicate the native form for the particular NBMA technology.
NSAPもE.164形式のアドレスも使用しないNBMAテクノロジーの場合、x = 0を使用して、特定のNBMAテクノロジーのネイティブフォームを示す必要があります。
If the NBMA network is ATM and a subaddress (e.g., Source NBMA SubAddress, Client NBMA SubAddress) is to be included in any part of the NHRP packet then ar$afn MUST be set to 0x000F; further, the subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr T/L) and subnetwork layer subaddress type/length fields (e.g., ar$sstl, Cli SAddr T/L) MUST be coded as in [11]. If the NBMA network is ATM and no subaddress field is to be included in any part of the NHRP packet then ar$afn MAY be set to 0x0003 (NSAP) or 0x0008 (E.164) accordingly.
NBMAネットワークがATMであり、サブアドレス（たとえば、ソースNBMAサブアドレス、クライアントNBMAサブアドレス）がNHRPパケットの任意の部分に含まれる場合は、ar $ afnを0x000Fに設定する必要があります。さらに、サブネットワークレイヤーのアドレスタイプ/長さフィールド（ar $ shtl、Cli Addr T / Lなど）とサブネットワークレイヤーのサブアドレスタイプ/長さフィールド（ar $ sstl、Cli SAddr T / Lなど）は、[ 11]。 NBMAネットワークがATMであり、サブアドレスフィールドをNHRPパケットのどの部分にも含めない場合は、ar $ afnを0x0003（NSAP）または0x0008（E.164）に応じて設定できます（MAY）。
The bottom 6 bits is an unsigned integer value indicating the length of the associated NBMA address in octets. If this value is zero the flag x is ignored.
下位6ビットは、関連するNBMAアドレスの長さをオクテットで示す符号なし整数値です。この値がゼロの場合、フラグxは無視されます。
The Mandatory Part of the NHRP packet contains the operation specific information (e.g., NHRP Resolution Request/Reply, etc.) and variable length data which is pertinent to the packet type.
NHRPパケットの必須部分には、操作固有の情報（NHRP解決要求/応答など）およびパケットタイプに関連する可変長データが含まれます。
Sections 5.2.1 through 5.2.6 have a very similar mandatory part. This mandatory part includes a common header and zero or more Client Information Entries (CIEs). Section 5.2.7 has a different format which is specified in that section.
セクション5.2.1から5.2.6には、非常によく似た必須部分があります。この必須部分には、共通のヘッダーと0個以上のクライアント情報エントリ（CIE）が含まれます。セクション5.2.7には、そのセクションで指定されている別の形式があります。
The common header looks like the following:
共通ヘッダーは次のようになります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
And the CIEs have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Prefix Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.....................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Prefix Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Unit | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meanings of the fields are as follows:
フィールドの意味は次のとおりです。
Src Proto Len This field holds the length in octets of the Source Protocol Address.
Src Proto Lenこのフィールドは、送信元プロトコルアドレスの長さをオクテット単位で保持します。
Dst Proto Len This field holds the length in octets of the Destination Protocol Address.
Dst Proto Lenこのフィールドは、宛先プロトコルアドレスの長さをオクテット単位で保持します。
Flags These flags are specific to the given message type and they are explained in each section.
フラグこれらのフラグは特定のメッセージタイプに固有であり、各セクションで説明されています。
Request ID A value which, when coupled with the address of the source, provides a unique identifier for the information contained in a "request" packet. This value is copied directly from an "request" packet into the associated "reply". When a sender of a "request" receives "reply", it will compare the Request ID and source address information in the received "reply" against that found in its outstanding "request" list. When a match is found then the "request" is considered to be acknowledged.
要求IDソースのアドレスと組み合わせたときに、「要求」パケットに含まれる情報に一意の識別子を提供する値。この値は、「要求」パケットから関連する「応答」に直接コピーされます。 「リクエスト」の送信者が「返信」を受信すると、受信した「返信」のリクエストIDとソースアドレス情報を、未処理の「リクエスト」リストにあるものと比較します。一致が見つかると、「要求」は確認されたと見なされます。
The value is taken from a 32 bit counter that is incremented each time a new "request" is transmitted. The same value MUST be used when resending a "request", i.e., when a "reply" has not been received for a "request" and a retry is sent after an appropriate interval.
この値は、新しい「要求」が送信されるたびにインクリメントされる32ビットカウンターから取得されます。 「リクエスト」を再送信するとき、つまり「リクエスト」に対する「リプライ」が受信されておらず、適切な間隔の後にリトライが送信されるときは、同じ値を使用する必要があります。
It is RECOMMENDED that the initial value for this number be 0. A node MAY reuse a sequence number if and only if the reuse of the sequence number is not precluded by use of a particular method of synchronization (e.g., as described in Appendix A).
この番号の初期値は0にすることをお勧めします。シーケンス番号の再利用が特定の同期方法（たとえば、付録Aで説明されている）の使用によって妨げられない場合に限り、ノードはシーケンス番号を再利用できます（MAY）。 。
The NBMA address/subaddress form specified below allows combined E.164/NSAPA form of NBMA addressing. For NBMA technologies without a subaddress concept, the subaddress field is always ZERO length and ar$sstl = 0.
以下に指定するNBMAアドレス/サブアドレス形式では、NBMAアドレス指定のE.164 / NSAPA形式を組み合わせることができます。サブアドレスの概念がないNBMAテクノロジーの場合、サブアドレスフィールドは常に長さがゼロであり、ar $ sstl = 0です。
Source NBMA Address The Source NBMA address field is the address of the source station which is sending the "request". If the field's length as specified in ar$shtl is 0 then no storage is allocated for this address at all.
ソースNBMAアドレスソースNBMAアドレスフィールドは、「要求」を送信しているソースステーションのアドレスです。 ar $ shtlで指定されたフィールドの長さが0の場合、このアドレスにはストレージがまったく割り当てられません。
Source NBMA SubAddress The Source NBMA subaddress field is the address of the source station which is sending the "request". If the field's length as specified in ar$sstl is 0 then no storage is allocated for this address at all.
ソースNBMAサブアドレスソースNBMAサブアドレスフィールドは、「要求」を送信しているソースステーションのアドレスです。 ar $ sstlで指定されたフィールドの長さが0の場合、このアドレスにはストレージがまったく割り当てられません。
For those NBMA technologies which have a notion of "Calling Party Addresses", the Source NBMA Addresses above are the addresses used when signaling for an SVC.
「発呼者アドレス」の概念を持つこれらのNBMAテクノロジの場合、上記のソースNBMAアドレスは、SVCのシグナリング時に使用されるアドレスです。
"Requests" and "indications" follow the routed path from Source Protocol Address to the Destination Protocol Address. "Replies", on the other hand, follow the routed path from the Destination Protocol Address back to the Source Protocol Address with the following exceptions: in the case of a NHRP Registration Reply and in the case of an NHC initiated NHRP Purge Request, the packet is always returned via a direct VC (see Sections 5.2.4 and 5.2.5).
「リクエスト」と「インジケーション」は、ソースプロトコルアドレスから宛先プロトコルアドレスへのルーティングパスに従います。一方、「応答」は、次の例外を除いて、宛先プロトコルアドレスから送信元プロトコルアドレスに戻る経路をたどります。NHRP登録応答の場合、およびNHCが開始したNHRPパージ要求の場合、パケットは常に直接VC経由で返されます（セクション5.2.4および5.2.5を参照）。
Source Protocol Address This is the protocol address of the station which is sending the "request". This is also the protocol address of the station toward which a "reply" packet is sent.
ソースプロトコルアドレスこれは、「要求」を送信しているステーションのプロトコルアドレスです。これは、「応答」パケットが送信されるステーションのプロトコルアドレスでもあります。
Destination Protocol Address This is the protocol address of the station toward which a "request" packet is sent.
宛先プロトコルアドレスこれは、「要求」パケットが送信されるステーションのプロトコルアドレスです。
Code This field is message specific. See the relevant message sections below. In general, this field is a NAK code; i.e., when the field is 0 in a reply then the packet is acknowledging a request and if it contains any other value the packet contains a negative acknowledgment.
コードこのフィールドはメッセージ固有です。以下の関連するメッセージセクションを参照してください。通常、このフィールドはNAKコードです。つまり、応答でフィールドが0の場合、パケットは要求を確認し、他の値が含まれている場合、パケットには否定の確認が含まれています。
Prefix Length This field is message specific. See the relevant message sections below. In general, however, this fields is used to indicate that the information carried in an NHRP message pertains to an equivalence class of internetwork layer addresses rather than just a single internetwork layer address specified. All internetwork layer addresses that match the first "Prefix Length" bit positions for the specific internetwork layer address are included in the equivalence class. If this field is set to 0x00 then this field MUST be ignored and no equivalence information is assumed (note that 0x00 is thus equivalent to 0xFF).
プレフィックス長このフィールドはメッセージ固有です。以下の関連するメッセージセクションを参照してください。ただし、一般に、このフィールドは、NHRPメッセージで運ばれる情報が、指定された単一のインターネットワークレイヤーアドレスだけでなく、インターネットワークレイヤーアドレスの同等クラスに関連することを示すために使用されます。特定のインターネットワークレイヤーアドレスの最初の「プレフィックス長」ビット位置に一致するすべてのインターネットワークレイヤーアドレスは、同等クラスに含まれます。このフィールドが0x00に設定されている場合、このフィールドは無視されなければならず（MUST）、等価情報は想定されていません（したがって、0x00は0xFFと同等であることに注意してください）。
Maximum Transmission Unit This field gives the maximum transmission unit for the relevant client station. If this value is 0 then either the default MTU is used or the MTU negotiated via signaling is used if such negotiation is possible for the given NBMA.
最大伝送ユニットこのフィールドは、関連するクライアントステーションの最大伝送ユニットを示します。この値が0の場合、デフォルトのMTUが使用されるか、特定のNBMAでそのようなネゴシエーションが可能な場合は、シグナリングを介してネゴシエートされたMTUが使用されます。
Holding Time The Holding Time field specifies the number of seconds for which the Next Hop NBMA information specified in the CIE is considered to be valid. Cached information SHALL be discarded when the holding time expires. This field must be set to 0 on a NAK.
保持時間[保持時間]フィールドは、CIEで指定されたネクストホップNBMA情報が有効であると見なされる秒数を指定します。キャッシュされた情報は、保持時間が経過すると破棄されます。このフィールドは、NAKで0に設定する必要があります。
Cli Addr T/L Type & length of next hop NBMA address specified in the CIE. This field is interpreted in the context of the 'address family number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM).
CIE Addr T / L CIEで指定されたネクストホップNBMAアドレスのタイプと長さ。このフィールドは、ar $ afnによって示される「アドレスファミリ番号」[6]のコンテキストで解釈されます（たとえば、ATMの場合、ar $ afn = 0x0003）。
Cli SAddr T/L Type & length of next hop NBMA subaddress specified in the CIE. This field is interpreted in the context of the 'address family number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes the address an E.164 and the subaddress an ATM Forum NSAP address). When an NBMA technology has no concept of a subaddress, the subaddress is always null with a length of 0. When the address length is specified as 0 no storage is allocated for the address.
CIEで指定されたCli SAddr T / LタイプとネクストホップNBMAサブアドレスの長さ。このフィールドは、ar $ afnによって示される「アドレスファミリ番号」[6]のコンテキストで解釈されます（たとえば、ATMの場合、ar $ afn = 0x0015はアドレスをE.164にし、サブアドレスをATM Forum NSAPアドレスにします）。 NBMAテクノロジーにサブアドレスの概念がない場合、サブアドレスは常に長さが0のヌルです。アドレス長を0に指定すると、アドレスにストレージは割り当てられません。
Cli Proto Len This field holds the length in octets of the Client Protocol Address specified in the CIE.
Cli Proto Lenこのフィールドは、CIEで指定されたクライアントプロトコルアドレスの長さをオクテット単位で保持します。
Preference This field specifies the preference for use of the specific CIE relative to other CIEs. Higher values indicate higher preference. Action taken when multiple CIEs have equal or highest preference value is a local matter.
Preferenceこのフィールドは、他のCIEと比較した特定のCIEの使用に関する優先順位を指定します。値が大きいほど、優先度が高くなります。複数のCIEが同じまたは最も高い優先度値を持っているときに取られるアクションは、ローカルの問題です。
Client NBMA Address This is the client's NBMA address.
クライアントNBMAアドレスこれはクライアントのNBMAアドレスです。
Client NBMA SubAddress This is the client's NBMA subaddress.
クライアントNBMAサブアドレスこれはクライアントのNBMAサブアドレスです。
Client Protocol Address This is the client's internetworking layer address specified.
クライアントプロトコルアドレスこれは、指定されたクライアントのインターネットワーキングレイヤーアドレスです。
Note that an NHS may cache source address binding information from an NHRP Resolution Request if and only if the conditions described in Section 6.2 are met for the NHS. In all other cases, source address binding information appearing in an NHRP message MUST NOT be cached.
NHSが6.2で説明した条件を満たしている場合に限り、NHSがNHRP解決要求からの送信元アドレスバインディング情報をキャッシュする場合があることに注意してください。他のすべての場合では、NHRPメッセージに表示される送信元アドレスバインディング情報はキャッシュしてはなりません（MUST NOT）。
The NHRP Resolution Request packet has a Type code of 1. Its mandatory part is coded as described in Section 5.2.0.1 and the message specific meanings of the fields are as follows:
NHRP解決要求パケットのタイプコードは1です。その必須部分はセクション5.2.0.1で説明されているようにコード化されており、フィールドのメッセージ固有の意味は次のとおりです。
Flags - The flags field is coded as follows:
フラグ-フラグフィールドは次のようにコーディングされます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q Set if the station sending the NHRP Resolution Request is a router; clear if the it is a host.
Q NHRP解決要求を送信するステーションがルーターである場合に設定されます。それがホストである場合はクリアします。
A This bit is set in a NHRP Resolution Request if only authoritative next hop information is desired and is clear otherwise. See the NHRP Resolution Reply section below for further details on the "A" bit and its usage.
Aこのビットは、信頼できるネクストホップ情報のみが必要な場合はNHRP解決要求で設定され、それ以外の場合はクリアされます。 「A」ビットとその使用法の詳細については、下の「NHRP解決応答」セクションを参照してください。
D Unused (clear on transmit)
D未使用（送信時にクリア）
U This is the Uniqueness bit. This bit aids in duplicate address detection. When this bit is set in an NHRP Resolution Request and one or more entries exist in the NHS cache which meet the requirements of the NHRP Resolution Request then only the CIE in the NHS's cache with this bit set will be returned. Note that even if this bit was set at registration time, there may still be multiple CIEs that might fulfill the NHRP Resolution Request because an entire subnet can be registered through use of the Prefix Length in the CIE and the address of interest might be within such a subnet. If the "uniqueness" bit is set and the responding NHS has one or more cache entries which match the request but no such cache entry has the "uniqueness" bit set, then the NHRP Resolution Reply returns with a NAK code of "13 - Binding Exists But Is Not Unique" and no CIE is included. If a client wishes to receive non- unique Next Hop Entries, then the client must have the "uniqueness" bit set to zero in its NHRP Resolution Request. Note that when this bit is set in an NHRP Registration Request, only a single CIE may be specified in the NHRP Registration Request and that CIE must have the Prefix Length field set to 0xFF.
Uこれは一意性ビットです。このビットは、重複アドレスの検出に役立ちます。このビットがNHRP解決要求で設定され、NHRP解決要求の要件を満たす1つ以上のエントリがNHSキャッシュに存在する場合、このビットが設定されたNHSのキャッシュ内のCIEのみが返されます。このビットが登録時に設定された場合でも、CRPのプレフィックス長を使用してサブネット全体を登録でき、対象のアドレスがそのような範囲内にある可能性があるため、NHRP解決要求を満たす複数のCIEがまだ存在する可能性があることに注意してください。サブネット。 「一意性」ビットが設定されていて、応答するNHSに要求と一致する1つ以上のキャッシュエントリがあるが、そのようなキャッシュエントリに「一意性」ビットが設定されていない場合、NHRP解決応答は「13-バインディング」のNAKコードで返されます。存在しますが一意ではありません」とCIEは含まれていません。クライアントが非一意のネクストホップエントリを受信する場合は、クライアントのNHRP解決要求で「一意性」ビットをゼロに設定する必要があります。このビットがNHRP登録要求で設定されている場合、NHRP登録要求で指定できるCIEは1つだけであり、CIEのプレフィックス長フィールドを0xFFに設定する必要があることに注意してください。
S Set if the binding between the Source Protocol Address and the Source NBMA information in the NHRP Resolution Request is guaranteed to be stable and accurate (e.g., these addresses are those of an ingress router which is connected to an ethernet stub network or the NHC is an NBMA attached host).
S NHRP解決要求のソースプロトコルアドレスとソースNBMA情報の間のバインディングが安定していて正確であることが保証されている場合に設定します（たとえば、これらのアドレスは、イーサネットスタブネットワークに接続されている入力ルーターのアドレスであるか、NHCがNBMA接続ホスト）。
Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP Resolution Request. If one is specified then that entry carries the pertinent information for the client sourcing the NHRP Resolution Request. Usage of the CIE in the NHRP Resolution Request is described below:
ゼロまたは1つのCIE（セクション5.2.0.1を参照）は、NHRP解決要求で指定できます。指定されている場合、そのエントリには、NHRP解決要求をソースするクライアントの関連情報が含まれます。 NHRP解決要求でのCIEの使用法を以下に説明します。
Prefix Length If a CIE is specified in the NHRP Resolution Request then the Prefix Length field may be used to qualify the widest acceptable prefix which may be used to satisfy the NHRP Resolution Request. In the case of NHRP Resolution Request/Reply, the Prefix Length specifies the equivalence class of addresses which match the first "Prefix Length" bit positions of the Destination Protocol Address. If the "U" bit is set in the common header then this field MUST be set to 0xFF.
プレフィックス長NHRP解決要求でCIEが指定されている場合、プレフィックス長フィールドを使用して、NHRP解決要求を満たすために使用できる最も広い許容可能なプレフィックスを修飾できます。 NHRP解決要求/応答の場合、プレフィックス長は、宛先プロトコルアドレスの最初の「プレフィックス長」ビット位置と一致するアドレスの同等クラスを指定します。 「U」ビットが共通ヘッダーで設定されている場合、このフィールドは0xFFに設定する必要があります。
Maximum Transmission Unit This field gives the maximum transmission unit for the source station. A possible use of this field in the NHRP Resolution Request packet is for the NHRP Resolution Requester to ask for a target MTU.
最大伝送ユニットこのフィールドは、ソースステーションの最大伝送ユニットを示します。 NHRP解決要求パケットでこのフィールドを使用できるのは、NHRP解決要求者がターゲットMTUを要求する場合です。
Holding Time The Holding Time specified in the one CIE permitted to be included in an NHRP Resolution Request is the amount of time which the source address binding information in the NHRP Resolution Request is permitted to cached by transit and responding NHSs. Note that this field may only have a non-zero value if the S bit is set.
保持時間NHRP解決要求に含めることが許可されている1つのCIEで指定された保持時間は、NHRP解決要求内の送信元アドレスバインディング情報が転送および応答NHSによってキャッシュされることを許可される時間です。このフィールドは、Sビットが設定されている場合にのみゼロ以外の値を持つ可能性があることに注意してください。
All other fields in the CIE MUST be ignored and SHOULD be set to 0.
CIEの他のすべてのフィールドは無視する必要があり、0に設定する必要があります。
The Destination Protocol Address in the common header of the Mandatory Part of this message contains the protocol address of the station for which resolution is desired. An NHC MUST send the NHRP Resolution Request directly to one of its serving NHSs (see Section 3 for more information).
このメッセージの必須部分の共通ヘッダーにある宛先プロトコルアドレスには、解決が必要なステーションのプロトコルアドレスが含まれています。 NHCは、NHRP解決要求を、サービスを提供しているNHSの1つに直接送信する必要があります（詳細については、セクション3を参照してください）。
The NHRP Resolution Reply packet has a Type code of 2. CIEs correspond to Next Hop Entries in an NHS's cache which match the criteria in the NHRP Resolution Request. Its mandatory part is coded as described in Section 5.2.0.1. The message specific meanings of the fields are as follows:
NHRP解決応答パケットのタイプコードは2です。CIEは、NHRP解決要求の基準に一致するNHSのキャッシュ内のネクストホップエントリに対応します。その必須部分は、セクション5.2.0.1で説明されているようにコーディングされます。フィールドのメッセージ固有の意味は次のとおりです。
Flags - The flags field is coded as follows:
フラグ-フラグフィールドは次のようにコーディングされます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q Copied from the NHRP Resolution Request. Set if the NHRP Resolution Requester is a router; clear if it is a host.
NHRP解決要求からコピーされたQ。 NHRP解決リクエスターがルーターの場合に設定します。それがホストである場合はクリアします。
A Set if the next hop CIE in the NHRP Resolution Reply is authoritative; clear if the NHRP Resolution Reply is non-authoritative.
NHRP解決応答のネクストホップCIEが信頼できる場合のセット。 NHRP解決応答が権限を持たない場合は明確にします。
When an NHS receives a NHRP Resolution Request for authoritative information for which it is the authoritative source, it MUST respond with a NHRP Resolution Reply containing all and only those next hop CIEs which are contained in the NHS's cache which both match the criteria of the NHRP Resolution Request and are authoritative cache entries. An NHS is an authoritative source for a NHRP Resolution Request if the information in the NHS's cache matches the NHRP Resolution Request criteria and that information was obtained through a NHRP Registration Request or through synchronization with an NHS which obtained this information through a NHRP Registration Request. An authoritative cache entry is one which is obtained through a NHRP Registration Request or through synchronization with an NHS which obtained this information through a NHRP Registration Request.
NHSは、信頼できるソースである信頼できる情報のNHRP解決要求を受信すると、NHRPの基準に一致するNHSのキャッシュに含まれるすべてのネクストホップCIEのみを含むNHRP解決応答で応答する必要があります。解決要求とは、信頼できるキャッシュエントリです。 NHSは、NHSのキャッシュ内の情報がNHRP解決要求基準に一致し、その情報がNHRP登録要求を通じて、またはNHRP登録要求を通じてこの情報を取得したNHSとの同期を通じて取得された場合、NHRP解決要求の信頼できるソースです。信頼できるキャッシュエントリは、NHRP登録要求を通じて、またはNHRP登録要求を通じてこの情報を取得したNHSとの同期を通じて取得されるものです。
An NHS obtains non-authoritative CIEs through promiscuous listening to NHRP packets other than NHRP Registrations which are directed at it. A NHRP Resolution Request which indicates a request for non-authoritative information should cause a NHRP Resolution Reply which contains all entries in the replying NHS's cache (i.e., both authoritative and non-authoritative) which match the criteria specified in the request.
NHSは、NHSに向けられたNHRP登録以外のNHRPパケットを無差別にリッスンして、権限のないCIEを取得します。信頼できない情報の要求を示すNHRP解決要求は、要求で指定された基準に一致する、応答するNHSのキャッシュ内のすべてのエントリ（つまり、信頼できるものと信頼できないものの両方）を含むNHRP解決応答を生成する必要があります。
D Set if the association between destination and the associate next hop information included in all CIEs of the NHRP Resolution Reply is guaranteed to be stable for the lifetime of the information (the holding time). This is the case if the Next Hop protocol address in a CIE identifies the destination (though it may be different in value than the Destination address if the destination system has multiple addresses) or if the destination is not connected directly to the NBMA subnetwork but the egress router to that destination is guaranteed to be stable (such as when the destination is immediately adjacent to the egress router through a non-NBMA interface).
D NHRP解決応答のすべてのCIEに含まれる宛先と関連ネクストホップ情報との間の関連付けが、情報の存続期間（保持時間）にわたって安定していることが保証される場合に設定します。これは、CIEの次ホッププロトコルアドレスが宛先を識別する場合（宛先システムに複数のアドレスがある場合は宛先アドレスと値が異なる場合があります）、または宛先がNBMAサブネットワークに直接接続されていないが、その宛先への出口ルーターは、安定していることが保証されています（宛先が非NBMAインターフェイスを介して出口ルーターに直接隣接している場合など）。
U This is the Uniqueness bit. See the NHRP Resolution Request section above for details. When this bit is set, only one CIE is included since only one unique binding should exist in an NHS's cache.
Uこれは一意性ビットです。詳細については、上記のNHRP解決要求セクションを参照してください。このビットが設定されている場合、NHSのキャッシュに存在する固有のバインディングは1つだけなので、CIEは1つだけ含まれます。
S Copied from NHRP Resolution Request message.
S NHRP解決要求メッセージからコピーされました。
One or more CIEs are specified in the NHRP Resolution Reply. Each CIE contains NHRP next hop information which the responding NHS has cached and which matches the parameters specified in the NHRP Resolution Request. If no match is found by the NHS issuing the NHRP Resolution Reply then a single CIE is enclosed with the a CIE Code set appropriately (see below) and all other fields MUST be ignored and SHOULD be set to 0. In order to facilitate the use of NHRP by minimal client implementations, the first CIE MUST contain the next hop with the highest preference value so that such an implementation need parse only a single CIE.
NHRP解決応答で1つ以上のCIEが指定されています。各CIEには、応答NHSがキャッシュし、NHRP解決要求で指定されたパラメーターと一致するNHRPネクストホップ情報が含まれています。 NHRP解決応答を発行するNHSによって一致が見つからない場合、単一のCIEがCIEコードセットで適切に囲まれ（以下を参照）、他のすべてのフィールドは無視する必要があり、0に設定する必要があります（SHOULD）。最小のクライアント実装によるNHRPの場合、最初のCIEは、最高の優先度値を持つネクストホップを含まなければならないため、そのような実装は単一のCIEのみを解析する必要があります。
Code If this field is set to zero then this packet contains a positively acknowledged NHRP Resolution Reply. If this field contains any other value then this message contains an NHRP Resolution Reply NAK which means that an appropriate internetworking layer to NBMA address binding was not available in the responding NHS's cache. If NHRP Resolution Reply contains a Client Information Entry with a NAK Code other than 0 then it MUST NOT contain any other CIE. Currently defined NAK Codes are as follows:
コードこのフィールドがゼロに設定されている場合、このパケットには、肯定応答されたNHRP解決応答が含まれています。このフィールドに他の値が含まれている場合、このメッセージにはNHRP解決応答NAKが含まれます。これは、NBMAアドレスバインディングへの適切なインターネットワーキングレイヤーが、応答するNHSのキャッシュで利用できなかったことを意味します。 NHRP解決応答にNAKコードが0以外のクライアント情報エントリが含まれている場合は、他のCIEを含めることはできません。現在定義されているNAKコードは次のとおりです。
4 - Administratively Prohibited
4-管理上禁止されている
An NHS may refuse an NHRP Resolution Request attempt for administrative reasons (due to policy constraints or routing state). If so, the NHS MUST send an NHRP Resolution Reply which contains a NAK code of 4.
NHSは、管理上の理由から（ポリシーの制約またはルーティング状態により）NHRP解決要求の試行を拒否する場合があります。その場合、NHSは4のNAKコードを含むNHRP解決応答を送信する必要があります。
5 - Insufficient Resources
5-不十分なリソース
If an NHS cannot serve a station due to a lack of resources (e.g., can't store sufficient information to send a purge if routing changes), the NHS MUST reply with a NAKed NHRP Resolution Reply which contains a NAK code of 5.
リソースが不足しているためにNHSがステーションにサービスを提供できない場合（たとえば、ルーティングが変更された場合にパージを送信するのに十分な情報を格納できない場合）、NHSはNAKコード5を含むNAKed NHRP解決応答で応答する必要があります。
12 - No Internetworking Layer Address to NBMA Address Binding Exists
12-NBMAアドレスバインディングへのインターネットワーキングレイヤーアドレスが存在しない
This code states that there were absolutely no internetworking layer address to NBMA address bindings found in the responding NHS's cache.
このコードは、応答するNHSのキャッシュで見つかったNBMAアドレスバインディングへのインターネットワーキングレイヤーアドレスがまったくなかったことを示しています。
13 - Binding Exists But Is Not Unique
13-バインドは存在するが一意ではない
This code states that there were one or more internetworking layer address to NBMA address bindings found in the responding NHS's cache, however none of them had the uniqueness bit set.
このコードは、応答するNHSのキャッシュで見つかった1つ以上のインターネットワーキングレイヤーアドレスからNBMAアドレスへのバインディングがあったことを示していますが、一意性ビットが設定されていませんでした。
Prefix Length In the case of NHRP Resolution Reply, the Prefix Length specifies the equivalence class of addresses which match the first "Prefix Length" bit positions of the Destination Protocol Address.
プレフィックス長NHRP解決応答の場合、プレフィックス長は、宛先プロトコルアドレスの最初の「プレフィックス長」ビット位置と一致するアドレスの同等クラスを指定します。
Holding Time The Holding Time specified in a CIE of an NHRP Resolution Reply is the amount of time remaining before the expiration of the client information which is cached at the replying NHS. It is not the value which was registered by the client.
保持時間NHRP解決応答のCIEで指定された保持時間は、応答NHSでキャッシュされるクライアント情報の有効期限が切れるまでの残り時間です。クライアントが登録した値ではありません。
The remainder of the fields for the CIE for each next hop are filled out as they were defined when the next hop was registered with the responding NHS (or one of the responding NHS's synchronized servers) via the NHRP Registration Request.
各次ホップのCIEの残りのフィールドは、NHRP登録要求を介して次ホップが応答NHS（または応答NHSの同期サーバーの1つ）に登録されたときに定義されたとおりに入力されます。
Load-splitting may be performed when more than one Client Information Entry is returned to a requester when equal preference values are specified. Also, the alternative addresses may be used in case of connectivity failure in the NBMA subnetwork (such as a failed call attempt in connection-oriented NBMA subnetworks).
同じ設定値が指定されているときに複数のクライアント情報エントリがリクエスタに返されると、負荷分割が実行される場合があります。また、NBMAサブネットワークでの接続障害（接続指向のNBMAサブネットワークでの呼び出し試行の失敗など）の場合にも、代替アドレスを使用できます。
Any extensions present in the NHRP Resolution Request packet MUST be present in the NHRP Resolution Reply even if the extension is non-Compulsory.
NHRP解決要求パケットに存在する拡張は、拡張が非必須であっても、NHRP解決応答に存在する必要があります。
If an unsolicited NHRP Resolution Reply packet is received, an Error Indication of type Invalid NHRP Resolution Reply Received SHOULD be sent in response.
要請されていないNHRP解決応答パケットが受信された場合、無効なNHRP解決応答受信タイプのエラー表示が応答として送信される必要があります。
When an NHS that serves a given NHC receives an NHRP Resolution Reply destined for that NHC then the NHS must MUST send the NHRP Resolution Reply directly to the NHC (see Section 3).
特定のNHCにサービスを提供するNHSがそのNHC宛てのNHRP解決応答を受信した場合、NHSはNHRP解決応答を直接NHCに送信する必要があります（セクション3を参照）。
The NHRP Registration Request is sent from a station to an NHS to notify the NHS of the station's NBMA information. It has a Type code of 3. Each CIE corresponds to Next Hop information which is to be cached at an NHS. The mandatory part of an NHRP Registration Request is coded as described in Section 5.2.0.1. The message specific meanings of the fields are as follows:
NHRP登録要求はステーションからNHSに送信され、ステーションのNBMA情報をNHSに通知します。タイプコードは3です。各CIEは、NHSでキャッシュされるNext Hop情報に対応しています。 NHRP登録要求の必須部分は、セクション5.2.0.1で説明されているようにコーディングされます。フィールドのメッセージ固有の意味は次のとおりです。
Flags - The flags field is coded as follows:
フラグ-フラグフィールドは次のようにコーディングされます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U This is the Uniqueness bit. When set in an NHRP Registration Request, this bit indicates that the registration of the protocol address is unique within the confines of the set of synchronized NHSs. This "uniqueness" qualifier MUST be stored in the NHS/NHC cache. Any attempt to register a binding between the protocol address and an NBMA address when this bit is set MUST be rejected with a Code of "14 - Unique Internetworking Layer Address Already Registered" if the replying NHS already has a cache entry for the protocol address and the cache entry has the "uniqueness" bit set. A registration of a CIE's information is rejected when the CIE is returned with the Code field set to anything other than 0x00. See the description of the uniqueness bit in NHRP Resolution Request section above for further details. When this bit is set only, only one CIE MAY be included in the NHRP Registration Request.
Uこれは一意性ビットです。 NHRP登録要求で設定されている場合、このビットは、プロトコルアドレスの登録が、同期されたNHSのセットの範囲内で一意であることを示します。この「一意性」修飾子は、NHS / NHCキャッシュに格納する必要があります。このビットが設定されているときにプロトコルアドレスとNBMAアドレス間のバインディングを登録しようとする試みは、応答するNHSにすでにプロトコルアドレスのキャッシュエントリがあり、キャッシュエントリには「一意性」ビットが設定されています。 Codeフィールドを0x00以外に設定してCIEが返された場合、CIEの情報の登録は拒否されます。詳細については、上記のNHRP解決要求セクションの一意性ビットの説明を参照してください。このビットのみが設定されている場合、NHRP登録要求に含めることができるCIEは1つだけです。
Request ID The request ID has the same meaning as described in Section 5.2.0.1. However, the request ID for NHRP Registrations which is maintained at each client MUST be kept in non-volatile memory so that when a client crashes and reregisters there will be no inconsistency in the NHS's database. In order to reduce the overhead associated with updating non-volatile memory, the actual updating need not be done with every increment of the Request ID but could be done, for example, every 50 or 100 increments. In this scenario, when a client crashes and reregisters it knows to add 100 to the value of the Request ID in the non-volatile memory before using the Request ID for subsequent registrations.
リクエストIDリクエストIDは、セクション5.2.0.1で説明されているのと同じ意味です。ただし、クライアントがクラッシュして再登録したときにNHSのデータベースに不整合が生じないように、各クライアントで維持されるNHRP登録のリクエストIDは不揮発性メモリに保持する必要があります。不揮発性メモリの更新に関連するオーバーヘッドを削減するために、実際の更新はリクエストIDのすべての増分で実行する必要はありませんが、たとえば50または100の増分ごとに実行できます。このシナリオでは、クライアントがクラッシュして再登録するときに、後続の登録に要求IDを使用する前に、不揮発性メモリの要求IDの値に100を追加することがわかっています。
One or more CIEs are specified in the NHRP Registration Request. Each CIE contains next hop information which a client is attempting to register with its servers. Generally, all fields in CIEs enclosed in NHRP Registration Requests are coded as described in Section 5.2.0.1. However, if a station is only registering itself with the NHRP Registration Request then it MAY code the Cli Addr T/L, Cli SAddr T/L, and Cli Proto Len as zero which signifies that the client address information is to be taken from the source information in the common header (see Section 5.2.0.1). Below, further clarification is given for some fields in a CIE in the context of a NHRP Registration Request.
NHRP登録要求で1つ以上のCIEが指定されています。各CIEには、クライアントがサーバーに登録しようとしているネクストホップ情報が含まれています。一般に、NHRP登録要求に含まれるCIEのすべてのフィールドは、セクション5.2.0.1で説明されているようにコード化されます。ただし、ステーションがNHRP登録要求にそれ自体を登録しているだけの場合は、クライアントアドレス情報が共通ヘッダー内のソース情報（セクション5.2.0.1を参照）。以下では、NHRP登録要求のコンテキストでCIEの一部のフィールドについてさらに説明します。
Code This field is set to 0x00 in NHRP Registration Requests.
コードこのフィールドは、NHRP登録要求で0x00に設定されます。
Prefix Length
プレフィックス長
This field may be used in a NHRP Registration Request to register equivalence information for the Client Protocol Address specified in the CIE of an NHRP Registration Request In the case of NHRP Registration Request, the Prefix Length specifies the equivalence class of addresses which match the first "Prefix Length" bit positions of the Client Protocol Address. If the "U" bit is set in the common header then this field MUST be set to 0xFF.
このフィールドは、NHRP登録要求で使用され、NHRP登録要求のCIEで指定されたクライアントプロトコルアドレスの同等情報を登録します。NHRP登録要求の場合、プレフィックス長は、最初の「クライアントプロトコルアドレスのプレフィックス長」ビット位置。 「U」ビットが共通ヘッダーで設定されている場合、このフィールドは0xFFに設定する必要があります。
The NHRP Registration Request is used to register an NHC's NHRP information with its NHSs. If an NHC is configured with the protocol address of a serving NHS then the NHC may place the NHS's protocol address in the Destination Protocol Address field of the NHRP Registration Request common header otherwise the NHC must place its own protocol address in the Destination Protocol Address field.
NHRP登録要求は、NHCのNHRP情報をNHSに登録するために使用されます。 NHCがサービングNHSのプロトコルアドレスで構成されている場合、NHCはNHSのプロトコルアドレスをNHRP登録要求共通ヘッダーの宛先プロトコルアドレスフィールドに配置できます。そうでない場合、NHCは独自のプロトコルアドレスを宛先プロトコルアドレスフィールドに配置する必要があります。 。
When an NHS receives an NHRP Registration Request which has the Destination Protocol Address field set to an address which belongs to a LIS/LAG for which the NHS is serving then if the Destination Protocol Address field is equal to the Source Protocol Address field (which would happen if the NHC put its protocol address in the Destination Protocol Address) or the Destination Protocol Address field is equal to the protocol address of the NHS then the NHS processes the NHRP Registration Request after doing appropriate error checking (including any applicable policy checking).
NHSが、NHSがサービスを提供しているLIS / LAGに属するアドレスに設定された宛先プロトコルアドレスフィールドを持つNHRP登録要求を受信すると、宛先プロトコルアドレスフィールドがソースプロトコルアドレスフィールドと等しい場合（ NHCがプロトコルアドレスをDestination Protocol Addressに入力した場合、またはDestination Protocol AddressフィールドがNHSのプロトコルアドレスと等しい場合、NHSは適切なエラーチェック（該当するポリシーチェックを含む）を実行した後、NHRP登録要求を処理します。
When an NHS receives an NHRP Registration Request which has the Destination Protocol Address field set to an address which does not belong to a LIS/LAG for which the NHS is serving then the NHS forwards the packet down the routed path toward the appropriate LIS/LAG.
NHSが、NHSがサービスを提供しているLIS / LAGに属していないアドレスに設定された宛先プロトコルアドレスフィールドを持つNHRP登録要求を受信すると、NHSはルーティングされたパスを介して適切なLIS / LAGにパケットを転送します。 。
When an NHS receives an NHRP Registration Request which has the Destination Protocol Address field set to an address which belongs to a LIS/LAG for which the NHS is serving then if the Destination Protocol Address field does not equal the Source Protocol Address field and the Destination Protocol Address field does not equal the protocol address of the NHS then the NHS forwards the message to the appropriate NHS within the LIS/LAG as specified by Destination Protocol Address field.
NHSが、NHSがサービスを提供しているLIS / LAGに属するアドレスに設定された宛先プロトコルアドレスフィールドを持つNHRP登録要求を受信すると、宛先プロトコルアドレスフィールドが送信元プロトコルアドレスフィールドと宛先に等しくない場合[プロトコルアドレス]フィールドがNHSのプロトコルアドレスと等しくない場合、NHSは[宛先プロトコルアドレス]フィールドで指定されたLIS / LAG内の適切なNHSにメッセージを転送します。
It is possible that a misconfigured station will attempt to register with the wrong NHS (i.e., one that cannot serve it due to policy constraints or routing state). If this is the case, the NHS MUST reply with a NAK-ed Registration Reply of type Can't Serve This Address.
誤って設定されたステーションが間違ったNHS（つまり、ポリシーの制約やルーティング状態のためにサービスを提供できないステーション）に登録しようとする可能性があります。これが事実である場合、NHSはタイプ「Ca n't Serve This Address」のNAK-ed Registration Replyで応答する必要があります。
If an NHS cannot serve a station due to a lack of resources, the NHS MUST reply with a NAK-ed Registration Reply of type Registration Overflow.
リソースが不足しているためにNHSがステーションにサービスを提供できない場合、NHSはタイプRegistration OverflowのNAK-ed Registration Replyで応答する必要があります。
In order to keep the registration entry from being discarded, the station MUST re-send the NHRP Registration Request packet often enough to refresh the registration, even in the face of occasional packet loss. It is recommended that the NHRP Registration Request packet be sent at an interval equal to one-third of the Holding Time specified therein.
登録エントリが破棄されないようにするために、ステーションはNHRP登録要求パケットを頻繁に再送信して、パケット損失が発生した場合でも、登録を更新する必要があります。 NHRP登録要求パケットは、そこに指定された保持時間の3分の1に等しい間隔で送信することをお勧めします。
The NHRP Registration Reply is sent by an NHS to a client in response to that client's NHRP Registration Request. If the Code field of a CIE in the NHRP Registration Reply has anything other than zero in it then the NHRP Registration Reply is a NAK otherwise the reply is an ACK. The NHRP Registration Reply has a Type code of 4.
NHRP登録応答は、クライアントのNHRP登録要求に応答して、NHSからクライアントに送信されます。 NHRP登録応答のCIEのコードフィールドにゼロ以外のものが含まれている場合、NHRP登録応答はNAKであり、それ以外の場合、応答はACKです。 NHRP登録応答のタイプコードは4です。
An NHRP Registration Reply is formed from an NHRP Registration Request by changing the type code to 4, updating the CIE Code field, and filling in the appropriate extensions if they exist. The message specific meanings of the fields are as follows:
NHRP登録応答は、タイプコードを4に変更し、CIEコードフィールドを更新し、適切な拡張子が存在する場合はそれを埋めることによって、NHRP登録要求から形成されます。フィールドのメッセージ固有の意味は次のとおりです。
Attempts to register the information in the CIEs of an NHRP Registration Request may fail for various reasons. If this is the case then each failed attempt to register the information in a CIE of an NHRP Registration Request is logged in the associated NHRP Registration Reply by setting the CIE Code field to the appropriate error code as shown below:
NHRP登録要求のCIEに情報を登録しようとすると、さまざまな理由で失敗する場合があります。これに該当する場合、NHRP登録要求のCIEに情報を登録しようとして失敗した各試行は、以下に示すように、CIEコードフィールドを適切なエラーコードに設定することにより、関連するNHRP登録応答に記録されます。
CIE Code
CIEコード
0 - Successful Registration
0-登録成功
The information in the CIE was successfully registered with the NHS.
CIEの情報はNHSに正常に登録されました。
4 - Administratively Prohibited
4-管理上禁止されている
An NHS may refuse an NHRP Registration Request attempt for administrative reasons (due to policy constraints or routing state). If so, the NHS MUST send an NHRP Registration Reply which contains a NAK code of 4.
NHSは、管理上の理由から（ポリシーの制約またはルーティング状態により）NHRP登録要求の試行を拒否する場合があります。その場合、NHSは、NAKコード4を含むNHRP登録応答を送信する必要があります。
5 - Insufficient Resources
5-不十分なリソース
If an NHS cannot serve a station due to a lack of resources, the NHS MUST reply with a NAKed NHRP Registration Reply which contains a NAK code of 5.
リソース不足のためにNHSがステーションにサービスを提供できない場合、NHSは、NAKコード5を含むNAKされたNHRP登録応答で応答する必要があります。
14 - Unique Internetworking Layer Address Already Registered If a client tries to register a protocol address to NBMA address binding with the uniqueness bit on and the protocol address already exists in the NHS's cache then if that cache entry also has the uniqueness bit on then this NAK Code is returned in the CIE in the NHRP Registration Reply.
14-登録済みの一意のインターネットワーキングレイヤーアドレスクライアントが一意性ビットをオンにしてプロトコルアドレスをNBMAアドレスバインディングに登録しようとし、そのプロトコルアドレスがすでにNHSのキャッシュに存在する場合、そのキャッシュエントリにも一意性ビットがオンになっていると、このNAKコードは、NHRP Registration ReplyのCIEで返されます。
Due to the possible existence of asymmetric routing, an NHRP Registration Reply may not be able to merely follow the routed path back to the source protocol address specified in the common header of the NHRP Registration Reply. As a result, there MUST exist a direct NBMA level connection between the NHC and its NHS on which to send the NHRP Registration Reply before NHRP Registration Reply may be returned to the NHC. If such a connection does not exist then the NHS must setup such a connection to the NHC by using the source NBMA information supplied in the common header of the NHRP Registration Request.
非対称ルーティングが存在する可能性があるため、NHRP登録応答は、ルーティングされたパスをたどって、NHRP登録応答の共通ヘッダーで指定されたソースプロトコルアドレスに戻ることができない場合があります。結果として、NHRP登録応答がNHCに返される前に、NHCとそのNHSの間にNHRP登録応答を送信するための直接のNBMAレベルの接続が存在する必要があります。そのような接続が存在しない場合、NHSはNHRP登録要求の共通ヘッダーで提供されるソースNBMA情報を使用して、NHCへのそのような接続をセットアップする必要があります。
The NHRP Purge Request packet is sent in order to invalidate cached information in a station. The NHRP Purge Request packet has a type code of 5. The mandatory part of an NHRP Purge Request is coded as described in Section 5.2.0.1. The message specific meanings of the fields are as follows:
NHRPパージ要求パケットは、ステーションでキャッシュされた情報を無効にするために送信されます。 NHRPパージ要求パケットのタイプコードは5です。NHRPパージ要求の必須部分は、セクション5.2.0.1で説明されているようにコーディングされます。フィールドのメッセージ固有の意味は次のとおりです。
Flags - The flags field is coded as follows:
フラグ-フラグフィールドは次のようにコーディングされます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N When set, this bit tells the receiver of the NHRP Purge Request that the requester does not expect to receive an NHRP Purge Reply. If an unsolicited NHRP Purge Reply is received by a station where that station is identified in the Source Protocol Address of the packet then that packet must be ignored.
N設定されている場合、このビットは、リクエスターがNHRPパージ応答を受信することを予期していないことをNHRPパージ要求の受信側に通知します。パケットの送信元プロトコルアドレスでステーションが識別されているステーションが非請求NHRPパージ応答を受信した場合、そのパケットは無視する必要があります。
One or more CIEs are specified in the NHRP Purge Request. Each CIE contains next hop information which is to be purged from an NHS/NHC cache. Generally, all fields in CIEs enclosed in NHRP Purge Requests are coded as described in Section 5.2.0.1. Below, further clarification is given for some fields in a CIE in the context of a NHRP Purge Request.
NHRPパージ要求で1つ以上のCIEが指定されています。各CIEには、NHS / NHCキャッシュから削除されるネクストホップ情報が含まれています。一般に、NHRPパージ要求に含まれるCIEのすべてのフィールドは、セクション5.2.0.1で説明されているようにコーディングされます。以下では、NHRPパージ要求のコンテキストでCIEの一部のフィールドについてさらに説明します。
Code This field is set to 0x00 in NHRP Purge Requests.
コードこのフィールドは、NHRPパージ要求で0x00に設定されます。
Prefix Length
プレフィックス長
In the case of NHRP Purge Requests, the Prefix Length specifies the equivalence class of addresses which match the first "Prefix Length" bit positions of the Client Protocol Address specified in the CIE. All next hop information which contains a protocol address which matches an element of this equivalence class is to be purged from the receivers cache.
NHRPパージ要求の場合、プレフィックス長は、CIEで指定されたクライアントプロトコルアドレスの最初の「プレフィックス長」ビット位置に一致するアドレスの同等クラスを指定します。この同等クラスの要素と一致するプロトコルアドレスを含むすべてのネクストホップ情報は、レシーバーキャッシュから削除されます。
The Maximum Transmission Unit and Preference fields of the CIE are coded as zero. The Holding Time should be coded as zero but there may be some utility in supplying a "short" holding time to be applied to the matching next hop information before that information would be purged; this usage is for further study. The Client Protocol Address field and the Cli Proto Len field MUST be filled in. The Client Protocol Address is filled in with the protocol address to be purged from the receiving station's cache while the Cli Proto Len is set the length of the purged client's protocol address. All remaining fields in the CIE MAY be set to zero although the client NBMA information (and associated length fields) MAY be specified to narrow the scope of the NHRP Purge Request if requester desires. However, the receiver of an NHRP Purge Request may choose to ignore the Client NBMA information if it is supplied.
CIEのMaximum Transmission UnitおよびPreferenceフィールドはゼロとしてコード化されます。保持時間はゼロとしてコード化する必要がありますが、情報が削除される前に、一致するネクストホップ情報に適用される「短い」保持時間を提供することに何らかの有用性がある場合があります。この使用法は、さらなる研究のためです。クライアントプロトコルアドレスフィールドとCli Proto Lenフィールドに入力する必要があります。クライアントプロトコルアドレスには、受信ステーションのキャッシュから削除されるプロトコルアドレスが入力されますが、Cli Proto Lenには、削除されるクライアントのプロトコルアドレスの長さが設定されます。 。クライアントのNBMA情報（および関連する長さフィールド）を指定して、リクエスターが希望する場合はNHRPパージ要求の範囲を狭めることができますが、CIEの残りのすべてのフィールドはゼロに設定される場合があります。ただし、NHRPパージ要求の受信者は、クライアントNBMA情報が提供されている場合、それを無視することを選択できます。
An NHRP Purge Request packet is sent from an NHS to a station to cause it to delete previously cached information. This is done when the information may be no longer valid (typically when the NHS has previously provided next hop information for a station that is not directly connected to the NBMA subnetwork, and the egress point to that station may have changed).
NHRPパージ要求パケットがNHSからステーションに送信され、以前にキャッシュされた情報を削除します。これは、情報が無効になる可能性がある場合に行われます（通常、NHSが以前にNBMAサブネットワークに直接接続されていないステーションのネクストホップ情報を提供し、そのステーションへの出口ポイントが変更された可能性がある場合）。
An NHRP Purge Request packet may also be sent from an NHC to an NHS with which the NHC had previously registered. This allows for an NHC to invalidate its registration with NHRP before it would otherwise expire via the holding timer. If an NHC does not have knowledge of a protocol address of a serving NHS then the NHC must place its own protocol address in the Destination Protocol Address field and forward the packet along the routed path. Otherwise, the NHC must place the protocol address of a serving NHS in this field.
NHRPパージ要求パケットは、NHCから以前に登録されたNHSにNHCから送信される場合もあります。これにより、NHCは保持タイマーを介して期限切れになる前に、NHRPへの登録を無効にすることができます。 NHCがサービングNHSのプロトコルアドレスを認識していない場合、NHCは自身のプロトコルアドレスを[宛先プロトコルアドレス]フィールドに配置し、ルーティングされたパスに沿ってパケットを転送する必要があります。それ以外の場合、NHCは、サービスを提供するNHSのプロトコルアドレスをこのフィールドに配置する必要があります。
Serving NHSs may need to send one or more new NHRP Purge Requests as a result of receiving a purge from one of their served NHCs since the NHS may have previously responded to NHRP Resolution Requests for that NHC's NBMA information. These purges are "new" in that they are sourced by the NHS and not the NHC; that is, for each NHC that previously sent a NHRP Resolution Request for the purged NHC NBMA information, an NHRP Purge Request is sent which contains the Source Protocol/NBMA Addresses of the NHS and the Destination Protocol Address of the NHC which previously sent an NHRP Resolution Request prior to the purge.
NHSはそのNHCのNBMA情報に対するNHRP解決要求に以前に応答した可能性があるため、サービスを提供するNHSは、サービスを提供するNHCの1つからパージを受信した結果、1つ以上の新しいNHRPパージ要求を送信する必要がある場合があります。これらのパージは、NHCではなくNHSから供給されるという点で「新しい」ものです。つまり、以前にパージされたNHC NBMA情報のNHRP解決要求を送信した各NHCに対して、NHRPを送信したNHSのソースプロトコル/ NBMAアドレスおよびNHCの宛先プロトコルアドレスを含むNHRPパージ要求が送信されます。削除前の解決要求。
The station sending the NHRP Purge Request MAY periodically retransmit the NHRP Purge Request until either NHRP Purge Request is acknowledged or until the holding time of the information being purged has expired. Retransmission strategies for NHRP Purge Requests are a local matter.
NHRPパージ要求を送信するステーションは、NHRPパージ要求が確認されるか、パージされる情報の保持時間が経過するまで、NHRPパージ要求を定期的に再送信する場合があります。 NHRPパージ要求の再送信戦略は地域の問題です。
When a station receives an NHRP Purge Request, it MUST discard any previously cached information that matches the information in the CIEs.
ステーションはNHRPパージ要求を受信すると、CIEの情報と一致する以前にキャッシュされた情報を破棄しなければなりません（MUST）。
An NHRP Purge Reply MUST be returned for the NHRP Purge Request even if the station does not have a matching cache entry assuming that the "N" bit is off in the NHRP Purge Request.
「N」ビットがNHRPパージ要求でオフであると想定して、ステーションに一致するキャッシュエントリがない場合でも、NHRPパージ要求に対してNHRPパージ応答を返さなければなりません（MUST）。
If the station wishes to reestablish communication with the destination shortly after receiving an NHRP Purge Request, it should make an authoritative NHRP Resolution Request in order to avoid any stale cache entries that might be present in intermediate NHSs (See section 6.2.2.). It is recommended that authoritative NHRP Resolution Requests be made for the duration of the holding time of the old information.
ステーションがNHRPパージ要求を受信した直後に宛先との通信を再確立する場合は、中間NHSに存在する可能性のある古いキャッシュエントリを回避するために、権限のあるNHRP解決要求を作成する必要があります（セクション6.2.2を参照）。古い情報の保持期間中は、信頼できるNHRP解決要求を行うことをお勧めします。
The NHRP Purge Reply packet is sent in order to assure the sender of an NHRP Purge Request that all cached information of the specified type has been purged from the station sending the reply. The NHRP Purge Reply has a type code of 6.
NHRPパージ応答パケットは、NHRPパージ要求の送信者に、指定されたタイプのすべてのキャッシュされた情報が応答を送信するステーションからパージされたことを保証するために送信されます。 NHRPパージ応答のタイプコードは6です。
An NHRP Purge Reply is formed from an NHRP Purge Request by merely changing the type code in the request to 6. The packet is then returned to the requester after filling in the appropriate extensions if they exist.
NHRPパージ応答は、要求のタイプコードを6に変更するだけで、NHRPパージ要求から形成されます。パケットは、適切な拡張が存在する場合は、適切な拡張を埋めた後、要求者に返されます。
The NHRP Error Indication is used to convey error indications to the sender of an NHRP packet. It has a type code of 7. The Mandatory Part has the following format:
NHRPエラー表示は、NHRPパケットの送信者にエラー表示を伝えるために使用されます。タイプコードは7です。必須部分の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Error Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of NHRP Packet in error (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src Proto Len This field holds the length in octets of the Source Protocol Address.
Src Proto Lenこのフィールドは、送信元プロトコルアドレスの長さをオクテット単位で保持します。
Dst Proto Len This field holds the length in octets of the Destination Protocol Address.
Dst Proto Lenこのフィールドは、宛先プロトコルアドレスの長さをオクテット単位で保持します。
Error Code An error code indicating the type of error detected, chosen from the following list:
エラーコード次のリストから選択された、検出されたエラーのタイプを示すエラーコード。
1 - Unrecognized Extension
1-認識されない拡張子
When the Compulsory bit of an extension in NHRP packet is set, the NHRP packet cannot be processed unless the extension has been processed. The responder MUST return an NHRP Error Indication of type Unrecognized Extension if it is incapable of processing the extension. However, if a transit NHS (one which is not going to generate a reply) detects an unrecognized extension, it SHALL ignore the extension.
NHRPパケット内の拡張の強制ビットが設定されている場合、拡張が処理されない限り、NHRPパケットを処理できません。拡張機能を処理できない場合、レスポンダはタイプUnrecognized ExtensionのNHRPエラー表示を返さなければなりません（MUST）。ただし、トランジットNHS（応答を生成しないもの）が認識できない拡張を検出した場合、その拡張を無視する必要があります（SHALL）。
3 - NHRP Loop Detected
3-NHRPループが検出されました
A Loop Detected error is generated when it is determined that an NHRP packet is being forwarded in a loop.
NHRPパケットがループで転送されていると判断された場合、ループ検出エラーが生成されます。
6 - Protocol Address Unreachable
6-プロトコルアドレスに到達できません
This error occurs when a packet it moving along the routed path and it reaches a point such that the protocol address of interest is not reachable.
このエラーは、パケットがルーティングされたパスに沿って移動し、目的のプロトコルアドレスに到達できないポイントに到達したときに発生します。
7 - Protocol Error
7-プロトコルエラー
A generic packet processing error has occurred (e.g., invalid version number, invalid protocol type, failed checksum, etc.)
一般的なパケット処理エラーが発生しました（無効なバージョン番号、無効なプロトコルタイプ、失敗したチェックサムなど）
8 - NHRP SDU Size Exceeded
8-NHRP SDUサイズの超過
If the SDU size of the NHRP packet exceeds the MTU size of the NBMA network then this error is returned.
NHRPパケットのSDUサイズがNBMAネットワークのMTUサイズを超える場合、このエラーが返されます。
9 - Invalid Extension
9-無効な拡張子
If an NHS finds an extension in a packet which is inappropriate for the packet type, an error is sent back to the sender with Invalid Extension as the code.
NHSがパケットタイプに適さない拡張をパケット内で検出した場合、コードとして無効な拡張を使用してエラーが送信者に送り返されます。
10 - Invalid NHRP Resolution Reply Received
10-無効なNHRP解決応答を受け取りました
If a client receives a NHRP Resolution Reply for a Next Hop Resolution Request which it believes it did not make then an error packet is sent to the station making the reply with an error code of Invalid Reply Received.
クライアントが、ネクストホップ解決要求に対するNHRP解決応答を受け取ったが、それが行わなかったと考える場合、エラーパケットがステーションに送信され、無効な応答を受信したというエラーコードで応答が返されます。
11 - Authentication Failure
11-認証失敗
If a received packet fails an authentication test then this error is returned.
受信したパケットが認証テストに失敗した場合、このエラーが返されます。
15 - Hop Count Exceeded
15-ホップカウント超過
The hop count which was specified in the Fixed Header of an NHRP message has been exceeded.
NHRPメッセージの固定ヘッダーで指定されたホップカウントを超えました。
Error Offset The offset in octets into the original NHRP packet in which an error was detected. This offset is calculated starting from the NHRP Fixed Header.
エラーオフセットエラーが検出された元のNHRPパケットへのオクテット単位のオフセット。このオフセットは、NHRP固定ヘッダーから計算されます。
Source NBMA Address The Source NBMA address field is the address of the station which observed the error.
発信元NBMAアドレス発信元NBMAアドレスフィールドは、エラーが発生したステーションのアドレスです。
Source NBMA SubAddress The Source NBMA subaddress field is the address of the station which observed the error. If the field's length as specified in ar$sstl is 0 then no storage is allocated for this address at all.
ソースNBMAサブアドレスソースNBMAサブアドレスフィールドは、エラーが発生したステーションのアドレスです。 ar $ sstlで指定されたフィールドの長さが0の場合、このアドレスにはストレージがまったく割り当てられません。
Source Protocol Address This is the protocol address of the station which issued the Error packet.
ソースプロトコルアドレスこれは、エラーパケットを発行したステーションのプロトコルアドレスです。
Destination Protocol Address This is the protocol address of the station which sent the packet which was found to be in error.
宛先プロトコルアドレスこれは、エラーが見つかったパケットを送信したステーションのプロトコルアドレスです。
An NHRP Error Indication packet SHALL NEVER be generated in response to another NHRP Error Indication packet. When an NHRP Error Indication packet is generated, the offending NHRP packet SHALL be discarded. In no case should more than one NHRP Error Indication packet be generated for a single NHRP packet.
NHRPエラー表示パケットは、別のNHRPエラー表示パケットに応答して生成されることは決してありません。 NHRPエラー表示パケットが生成されると、問題のNHRPパケットは破棄される必要があります。 1つのNHRPパケットに対して複数のNHRPエラー表示パケットが生成されることはありません。
If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA and Source Protocol address fields of a transiting NHRP Error Indication packet then the NHS will quietly drop the packet and do nothing (this scenario would occur when the NHRP Error Indication packet was itself in a loop).
NHSが、通過するNHRPエラー表示パケットの送信元NBMAおよび送信元プロトコルアドレスフィールドに独自のプロトコルとNBMAアドレスを確認すると、NHSは静かにパケットをドロップし、何もしません（このシナリオは、NHRPエラー表示パケット自体が発生した場合に発生します）ループ内）。
Note that no extensions may be added to an NHRP Error Indication.
NHRPエラー表示に拡張機能を追加できないことに注意してください。
The Extensions Part, if present, carries one or more extensions in {Type, Length, Value} triplets.
拡張部分が存在する場合、それは{Type、Length、Value}トリプレットで1つ以上の拡張を運びます。
Extensions have the following format:
拡張機能の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|u| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C "Compulsory." If clear, and the NHS does not recognize the type code, the extension may safely be ignored. If set, and the NHS does not recognize the type code, the NHRP "request" is considered to be in error. (See below for details.)
C「強制」。明確で、NHSがタイプコードを認識しない場合、拡張子は無視しても問題ありません。設定され、NHSがタイプコードを認識しない場合、NHRPの「要求」はエラーと見なされます。 （詳細は以下を参照してください。）
u Unused and must be set to zero.
u未使用で、ゼロに設定する必要があります。
Type The extension type code (see below). The extension type is not qualified by the Compulsory bit, but is orthogonal to it.
タイプ拡張タイプコード（下記参照）。拡張タイプは強制ビットでは修飾されませんが、それとは直交しています。
Length The length in octets of the value (not including the Type and Length fields; a null extension will have only an extension header and a length of zero).
長さ値のオクテット単位の長さ（タイプフィールドと長さフィールドは含まれません。null拡張は、拡張ヘッダーと長さ0のみを持ちます）。
When extensions exist, the extensions list is terminated by the Null TLV, having Type = 0 and Length = 0.
拡張が存在する場合、拡張リストは、Type = 0およびLength = 0のNull TLVで終了します。
Extensions may occur in any order, but any particular extension type may occur only once in an NHRP packet unless explicitly stated to the contrary in the extensions definition. For example, the vendor-private extension may occur multiple times in a packet in order to allow for extensions which do not share the same vendor ID to be represented. It is RECOMMENDED that a given vendor include no more than one Vendor Private Extension.
拡張は任意の順序で発生する可能性がありますが、特定の拡張タイプは、拡張の定義で明示的に反対の記述がない限り、NHRPパケットで1回だけ発生する可能性があります。たとえば、ベンダープライベート拡張は、同じベンダーIDを共有しない拡張を表すことができるようにするために、パケット内で複数回発生することがあります。特定のベンダーにはベンダープライベート拡張機能を1つだけ含めることをお勧めします。
An NHS MUST NOT change the order of extensions. That is, the order of extensions placed in an NHRP packet by an NHC (or by an NHS when an NHS sources a packet) MUST be preserved as the packet moves between NHSs. Minimal NHC implementations MUST only recognize, but not necessarily parse, the Vendor Private extension and the End Of Extensions extension. Extensions are only present in a "reply" if they were present in the corresponding "request" with the exception of Vendor Private extensions. The previous statement is not intended to preclude the creation of NHS-only extensions which might be added to and removed from NHRP packets by the same NHS; such extensions MUST not be propagated to NHCs.
NHSは拡張の順序を変更してはなりません。つまり、NHCによって（またはNHSがパケットをソースする場合はNHSによって）NHRPパケットに配置される拡張の順序は、パケットがNHS間を移動するときに保持される必要があります。最小限のNHC実装は、ベンダープライベート拡張とエンドオブエクステンション拡張のみを認識する必要がありますが、必ずしも解析する必要はありません。拡張は、ベンダープライベート拡張を除いて、対応する「リクエスト」に存在する場合にのみ「応答」に存在します。前のステートメントは、同じNHSによってNHRPパケットに追加および削除される可能性のあるNHSのみの拡張機能の作成を排除することを意図したものではありません。そのような拡張はNHCに伝播してはならない（MUST NOT）。
The Compulsory bit provides for a means to add to the extension set. If the bit is set in an extension then the station responding to the NHRP message which contains that extension MUST be able to understand the extension (in this case, the station responding to the message is the station that would issue an NHRP reply in response to a NHRP request). As a result, the responder MUST return an NHRP Error Indication of type Unrecognized Extension. If the Compulsory bit is clear then the extension can be safely ignored; however, if an ignored extension is in a "request" then it MUST be returned, unchanged, in the corresponding "reply" packet type.
強制ビットは、拡張セットに追加する手段を提供します。ビットが拡張に設定されている場合、その拡張を含むNHRPメッセージに応答するステーションは、拡張を理解できなければなりません（この場合、メッセージに応答するステーションは、応答にNHRP応答を発行するステーションです） NHRP要求）。その結果、レスポンダはタイプUnrecognized ExtensionのNHRPエラー表示を返さなければなりません（MUST）。強制ビットがクリアされている場合、拡張は安全に無視できます。ただし、無視された拡張子が「リクエスト」に含まれている場合は、対応する「応答」パケットタイプで変更せずに返す必要があります。
If a transit NHS (one which is not going to generate a "reply") detects an unrecognized extension, it SHALL ignore the extension. If the Compulsory bit is set, the transit NHS MUST NOT cache the information contained in the packet and MUST NOT identify itself as an egress router (in the Forward Record or Reverse Record extensions). Effectively, this means, if a transit NHS encounters an extension which it cannot process and which has the Compulsory bit set then that NHS MUST NOT participate in any way in the protocol exchange other than acting as a forwarding agent.
トランジットNHS（「応答」を生成しないもの）が認識できない拡張を検出した場合、その拡張を無視する必要があります（SHALL）。強制ビットが設定されている場合、トランジットNHSはパケットに含まれている情報をキャッシュしてはならず、自身を（フォワードレコードまたはリバースレコード拡張で）出力ルーターとして識別してはなりません（MUST NOT）。事実上、これは、トランジットNHSが処理できず、強制ビットが設定されている拡張に遭遇した場合、NHSが転送エージェントとして機能する以外の方法でプロトコル交換に参加してはならないことを意味します。
The NHRP extension Type space is subdivided to encourage use outside the IETF.
NHRP拡張タイプスペースは、IETF以外での使用を促進するために細分されます。
0x0000 - 0x0FFF Reserved for NHRP. 0x1000 - 0x11FF Allocated to the ATM Forum. 0x1200 - 0x37FF Reserved for the IETF. 0x3800 - 0x3FFF Experimental use.
0x0000-0x0FFF NHRP用に予約済み。 0x1000-0x11FFがATMフォーラムに割り当てられています。 0x1200-0x37FF IETF用に予約済み。 0x3800-0x3FFF実験的使用。
IANA will administer the ranges reserved for the IETF as described in Section 9. Values in the 'Experimental use' range have only local significance.
IANAは、セクション9で説明されているように、IETF用に予約された範囲を管理します。「実験的使用」範囲の値は、ローカルでのみ意味があります。
Compulsory = 1 Type = 0 Length = 0
強制= 1タイプ= 0長さ= 0
When extensions exist, the extensions list is terminated by the End Of Extensions/Null TLV.
拡張が存在する場合、拡張リストはEnd Of Extensions / Null TLVで終了します。
Compulsory = 1 Type = 3 Length = variable
強制= 1タイプ= 3長さ=可変
This extension is used to determine the address of the NHRP responder; i.e., the entity that generates the appropriate "reply" packet for a given "request" packet. In the case of an NHRP Resolution Request, the station responding may be different (in the case of cached replies) than the system identified in the Next Hop field of the NHRP Resolution Reply. Further, this extension may aid in detecting loops in the NHRP forwarding path.
この拡張は、NHRPレスポンダのアドレスを決定するために使用されます。つまり、特定の「要求」パケットに対して適切な「応答」パケットを生成するエンティティ。 NHRP解決要求の場合、応答するステーションは（キャッシュされた応答の場合）NHRP解決応答の次ホップフィールドで識別されるシステムとは異なる場合があります。さらに、この拡張は、NHRP転送パスでループを検出するのに役立ちます。
This extension uses a single CIE with the extension specific meanings of the fields set as follows:
この拡張機能は、次のように設定されたフィールドの拡張固有の意味を持つ単一のCIEを使用します。
The Prefix Length fields MUST be set to 0 and ignored.
接頭辞の長さフィールドは0に設定して無視する必要があります。
CIE Code 5 - Insufficient Resources If the responder to an NHRP Resolution Request is an egress point for the target of the address resolution request (i.e., it is one of the stations identified in the list of CIEs in an NHRP Resolution Reply) and the Responder Address extension is included in the NHRP Resolution Request and insufficient resources to setup a cut-through VC exist at the responder then the Code field of the Responder Address Extension is set to 5 in order to tell the client that a VC setup attempt would in all likelihood be rejected; otherwise this field MUST be coded as a zero. NHCs MAY use this field to influence whether they attempt to setup a cut-through to the egress router.
CIEコード5-不十分なリソースNHRP解決要求への応答側がアドレス解決要求のターゲットの出口ポイントである場合（つまり、NHRP解決応答のCIEのリストで識別されるステーションの1つ）と応答側アドレス拡張がNHRP解決要求に含まれ、カットスルーVCをセットアップするためのリソースがレスポンダーに存在しない場合、レスポンダーアドレス拡張のコードフィールドが5に設定され、VCセットアップの試行がすべてであることをクライアントに通知します。拒否される可能性;それ以外の場合、このフィールドはゼロとしてコーディングする必要があります。 NHCはこのフィールドを使用して、出力ルーターへのカットスルーをセットアップしようとするかどうかに影響を与える場合があります。
Maximum Transmission Unit This field gives the maximum transmission unit preferred by the responder. If this value is 0 then either the default MTU is used or the MTU negotiated via signaling is used if such negotiation is possible for the given NBMA.
最大伝送ユニットこのフィールドは、レスポンダが優先する最大伝送ユニットを示します。この値が0の場合、デフォルトのMTUが使用されるか、特定のNBMAでそのようなネゴシエーションが可能な場合は、シグナリングを介してネゴシエートされたMTUが使用されます。
Holding Time The Holding Time field specifies the number of seconds for which the NBMA information of the responser is considered to be valid. Cached information SHALL be discarded when the holding time expires.
保持時間[保持時間]フィールドは、レスポンダのNBMA情報が有効であると見なされる秒数を指定します。キャッシュされた情報は、保持時間が経過すると破棄されます。
"Client Address" information is actually "Responder Address" information for this extension. Thus, for example, Cli Addr T/L is the responder NBMA address type and length field.
「クライアントアドレス」情報は、実際にはこの拡張機能の「レスポンダーアドレス」情報です。したがって、たとえば、Cli Addr T / LはレスポンダNBMAアドレスタイプおよび長さフィールドです。
If a "requester" desires this information, the "requester" SHALL include this extension with a value of zero. Note that this implies that no storage is allocated for the Holding Time and Type/Length fields until the "Value" portion of the extension is filled out.
「リクエスタ」がこの情報を必要とする場合、「リクエスタ」はゼロの値を持つこの拡張を含める必要があります。これは、拡張の「値」部分が入力されるまで、保持時間とタイプ/長さフィールドにストレージが割り当てられないことを意味することに注意してください。
If an NHS is generating a "reply" packet in response to a "request" containing this extension, the NHS SHALL include this extension, containing its protocol address in the "reply". If an NHS has more than one protocol address, it SHALL use the same protocol address consistently in all of the Responder Address, Forward Transit NHS Record, and Reverse Transit NHS Record extensions. The choice of which of several protocol address to include in this extension is a local matter.
NHSがこの拡張を含む「要求」に応答して「応答」パケットを生成する場合、NHSはこの拡張を含め（SHALL）、「応答」にプロトコルアドレスを含めます。 NHSに複数のプロトコルアドレスがある場合は、すべてのレスポンダアドレス、順方向トランジットNHSレコード、および逆方向トランジットNHSレコード拡張で一貫して同じプロトコルアドレスを使用する必要があります。この拡張機能に含めるプロトコルアドレスの選択は、ローカルな問題です。
If an NHRP Resolution Reply packet being forwarded by an NHS contains a protocol address of that NHS in the Responder Address Extension then that NHS SHALL generate an NHRP Error Indication of type "NHRP Loop Detected" and discard the NHRP Resolution Reply.
NHSによって転送されているNHRP解決応答パケットに、そのNHSのプロトコルアドレスがレスポンダーアドレス拡張に含まれている場合、そのNHSはタイプ「NHRPループ検出」のNHRPエラー表示を生成し、NHRP解決応答を破棄する必要があります。
If an NHRP Resolution Reply packet is being returned by an intermediate NHS based on cached data, it SHALL place its own address in this extension (differentiating it from the address in the Next Hop field).
キャッシュされたデータに基づいてNHRP解決応答パケットが中間NHSによって返されている場合は、この拡張に独自のアドレスを配置する必要があります（ネクストホップフィールドのアドレスと区別します）。
Compulsory = 1 Type = 4 Length = variable
強制= 1タイプ= 4長さ=可変
The NHRP Forward Transit NHS record contains a list of transit NHSs through which a "request" has traversed. Each NHS SHALL append to the extension a Forward Transit NHS element (as specified below) containing its Protocol address. The extension length field and the ar$chksum fields SHALL be adjusted appropriately.
NHRP Forward Transit NHSレコードには、「要求」が通過した通過NHSのリストが含まれています。各NHSは、プロトコルアドレスを含むForward Transit NHS要素（下記に指定）を拡張に追加するものとします（SHALL）。拡張長さフィールドとar $ chksumフィールドは適切に調整する必要があります。
The responding NHS, as described in Section 5.3.1, SHALL NOT update this extension.
セクション5.3.1で説明されているように、応答するNHSはこの拡張を更新してはなりません（SHALL NOT）。
In addition, NHSs that are willing to act as egress routers for packets from the source to the destination SHALL include information about their NBMA Address.
さらに、送信元から宛先へのパケットの出力ルーターとして機能するNHSは、NBMAアドレスに関する情報を含む必要があります。
This extension uses a single CIE per NHS Record element with the extension specific meanings of the fields set as follows:
この拡張は、NHSレコード要素ごとに1つのCIEを使用し、フィールドの拡張固有の意味は次のように設定されます。
The Prefix Length fields MUST be set to 0 and ignored.
接頭辞の長さフィールドは0に設定して無視する必要があります。
CIE Code 5 - Insufficient Resources If an NHRP Resolution Request contains an NHRP Forward Transit NHS Record Extension and insufficient resources to setup a cut-through VC exist at the current transit NHS then the CIE Code field for NHRP Forward Transit NHS Record Extension is set to 5 in order to tell the client that a VC setup attempt would in all likelihood be rejected; otherwise this field MUST be coded as a zero. NHCs MAY use this field to influence whether they attempt to setup a cut-through as described in Section 2.2. Note that the NHRP Reverse Transit NHS Record Extension MUST always have this field set to zero.
CIEコード5-リソースが不十分NHRP解決要求にNHRP転送トランジットNHSレコード拡張が含まれ、カットスルーVCをセットアップするのに十分なリソースが現在のトランジットNHSに存在しない場合、NHRP転送トランジットNHSレコード拡張のCIEコードフィールドは次のように設定されます。 5 VCセットアップの試行はおそらく拒否されることをクライアントに伝えるため。それ以外の場合、このフィールドはゼロとしてコーディングする必要があります。 NHCは、このフィールドを使用して、セクション2.2で説明されているようにカットスルーをセットアップしようとするかどうかに影響を与えることができます。 NHRPリバーストランジットNHSレコード拡張では、このフィールドを常にゼロに設定する必要があることに注意してください。
Maximum Transmission Unit This field gives the maximum transmission unit preferred by the transit NHS. If this value is 0 then either the default MTU is used or the MTU negotiated via signaling is used if such negotiation is possible for the given NBMA.
最大伝送ユニットこのフィールドは、トランジットNHSが優先する最大伝送ユニットを示します。この値が0の場合、デフォルトのMTUが使用されるか、特定のNBMAでそのようなネゴシエーションが可能な場合は、シグナリングを介してネゴシエートされたMTUが使用されます。
Holding Time The Holding Time field specifies the number of seconds for which the NBMA information of the transit NHS is considered to be valid. Cached information SHALL be discarded when the holding time expires.
保持時間[保持時間]フィールドは、トランジットNHSのNBMA情報が有効であると見なされる秒数を指定します。キャッシュされた情報は、保持時間が経過すると破棄されます。
"Client Address" information is actually "Forward Transit NHS Address" information for this extension. Thus, for example, Cli Addr T/L is the transit NHS NBMA address type and length field.
「クライアントアドレス」情報は、実際にはこの拡張機能の「Forward Transit NHSアドレス」情報です。したがって、たとえば、Cli Addr T / LはトランジットNHS NBMAアドレスタイプおよび長さフィールドです。
If a "requester" wishes to obtain this information, it SHALL include this extension with a length of zero. Note that this implies that no storage is allocated for the Holding Time and Type/Length fields until the "Value" portion of the extension is filled out.
「リクエスタ」がこの情報を取得したい場合は、長さがゼロのこの拡張を含める必要があります。これは、拡張の「値」部分が入力されるまで、保持時間とタイプ/長さフィールドにストレージが割り当てられないことを意味することに注意してください。
If an NHS has more than one Protocol address, it SHALL use the same Protocol address consistently in all of the Responder Address, Forward NHS Record, and Reverse NHS Record extensions. The choice of which of several Protocol addresses to include in this extension is a local matter.
NHSに複数のプロトコルアドレスがある場合、すべてのレスポンダーアドレス、フォワードNHSレコード、およびリバースNHSレコード拡張で一貫して同じプロトコルアドレスを使用する必要があります。この拡張機能に含めるプロトコルアドレスの選択は、ローカルの問題です。
If a "request" that is being forwarded by an NHS contains the Protocol Address of that NHS in one of the Forward Transit NHS elements then the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop Detected" and discard the "request".
NHSによって転送されている「リクエスト」に、転送トランジットNHS要素の1つにそのNHSのプロトコルアドレスが含まれている場合、NHSはタイプ「NHRPループ検出」のNHRPエラー表示を生成し、「リクエスト」を破棄する必要があります。
Compulsory = 1 Type = 5 Length = variable
強制= 1タイプ= 5長さ=可変
The NHRP Reverse Transit NHS record contains a list of transit NHSs through which a "reply" has traversed. Each NHS SHALL append a Reverse Transit NHS element (as specified below) containing its Protocol address to this extension. The extension length field and ar$chksum SHALL be adjusted appropriately.
NHRPリバーストランジットNHSレコードには、「応答」が通過したトランジットNHSのリストが含まれています。各NHSは、プロトコルアドレスを含むリバーストランジットNHS要素（以下で指定）をこの拡張に追加するものとします（SHALL）。拡張長さフィールドとar $ chksumは適切に調整する必要があります。
The responding NHS, as described in Section 5.3.1, SHALL NOT update this extension.
セクション5.3.1で説明されているように、応答するNHSはこの拡張を更新してはなりません（SHALL NOT）。
In addition, NHSs that are willing to act as egress routers for packets from the source to the destination SHALL include information about their NBMA Address.
さらに、送信元から宛先へのパケットの出力ルーターとして機能するNHSは、NBMAアドレスに関する情報を含む必要があります。
This extension uses a single CIE per NHS Record element with the extension specific meanings of the fields set as follows:
この拡張は、NHSレコード要素ごとに1つのCIEを使用し、フィールドの拡張固有の意味は次のように設定されます。
The CIE Code and Prefix Length fields MUST be set to 0 and ignored.
CIE CodeおよびPrefix Lengthフィールドは0に設定して無視する必要があります。
Maximum Transmission Unit This field gives the maximum transmission unit preferred by the transit NHS. If this value is 0 then either the default MTU is used or the MTU negotiated via signaling is used if such negotiation is possible for the given NBMA.
最大伝送ユニットこのフィールドは、トランジットNHSが優先する最大伝送ユニットを示します。この値が0の場合、デフォルトのMTUが使用されるか、特定のNBMAでそのようなネゴシエーションが可能な場合は、シグナリングを介してネゴシエートされたMTUが使用されます。
Holding Time The Holding Time field specifies the number of seconds for which the NBMA information of the transit NHS is considered to be valid. Cached information SHALL be discarded when the holding time expires.
保持時間[保持時間]フィールドは、トランジットNHSのNBMA情報が有効であると見なされる秒数を指定します。キャッシュされた情報は、保持時間が経過すると破棄されます。
"Client Address" information is actually "Reverse Transit NHS Address" information for this extension. Thus, for example, Cli Addr T/L is the transit NHS NBMA address type and length field.
「クライアントアドレス」情報は、実際にはこの拡張の「Reverse Transit NHSアドレス」情報です。したがって、たとえば、Cli Addr T / LはトランジットNHS NBMAアドレスタイプおよび長さフィールドです。
If a "requester" wishes to obtain this information, it SHALL include this extension with a length of zero. Note that this implies that no storage is allocated for the Holding Time and Type/Length fields until the "Value" portion of the extension is filled out.
「リクエスタ」がこの情報を取得したい場合は、長さがゼロのこの拡張を含める必要があります。これは、拡張の「値」部分が入力されるまで、保持時間とタイプ/長さフィールドにストレージが割り当てられないことを意味することに注意してください。
If an NHS has more than one Protocol address, it SHALL use the same Protocol address consistently in all of the Responder Address, Forward NHS Record, and Reverse NHS Record extensions. The choice of which of several Protocol addresses to include in this extension is a local matter.
NHSに複数のプロトコルアドレスがある場合、すべてのレスポンダーアドレス、フォワードNHSレコード、およびリバースNHSレコード拡張で一貫して同じプロトコルアドレスを使用する必要があります。この拡張機能に含めるプロトコルアドレスの選択は、ローカルの問題です。
If a "reply" that is being forwarded by an NHS contains the Protocol Address of that NHS in one of the Reverse Transit NHS elements then the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop Detected" and discard the "reply".
NHSによって転送されている「応答」に、Reverse Transit NHS要素の1つにそのNHSのプロトコルアドレスが含まれている場合、NHSはタイプ「NHRPループ検出」のNHRPエラー表示を生成して、「応答」を破棄する必要があります。
Note that this information may be cached at intermediate NHSs; if so, the cached value SHALL be used when generating a reply.
この情報は中間NHSでキャッシュされる場合があることに注意してください。その場合、キャッシュされた値は、応答を生成するときに使用される必要があります。
Compulsory = 1 Type = 7 Length = variable
The NHRP Authentication Extension is carried in NHRP packets to convey authentication information between NHRP speakers. The Authentication Extension may be included in any NHRP "request" or "reply" only.
NHRP認証拡張機能はNHRPパケットで伝送され、NHRPスピーカー間で認証情報を伝達します。認証拡張機能は、NHRPの「要求」または「応答」にのみ含めることができます。
The authentication is always done pairwise on an NHRP hop-by-hop basis; i.e., the authentication extension is regenerated at each hop. If a received packet fails the authentication test, the station SHALL generate an Error Indication of type "Authentication Failure" and discard the packet. Note that one possible authentication failure is the lack of an Authentication Extension; the presence or absence of the Authentication Extension is a local matter.
認証は、常にNHRPホップバイホップベースでペアで行われます。つまり、認証拡張は各ホップで再生成されます。受信したパケットが認証テストに失敗した場合、ステーションはタイプ「認証失敗」のエラー表示を生成して、パケットを破棄するものとします（SHALL）。認証に失敗する可能性の1つは、認証拡張機能がないことです。認証拡張機能の有無はローカルな問題です。
The authentication header has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Parameter Index (SPI)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Parameter Index (SPI) can be thought of as an index into a table that maintains the keys and other information such as hash algorithm. Src and Dst communicate either offline using manual keying or online using a key management protocol to populate this table. The sending NHRP entity always allocates the SPI and the parameters associated with it.
セキュリティパラメータインデックス（SPI）は、ハッシュアルゴリズムなどのキーとその他の情報を保持するテーブルへのインデックスと考えることができます。 SrcとDstは、手動のキーイングを使用してオフラインで通信するか、キー管理プロトコルを使用してオンラインで通信して、このテーブルにデータを入力します。送信NHRPエンティティは常に、SPIとそれに関連付けられたパラメーターを割り当てます。
Src Addr a variable length field is the address assigned to the outgoing interface. The length of the addr is obtained from the source protocol length field in the mandatory part of the NHRP header. The tuple <spi, src addr> uniquely identifies the key and other parameters that are used in authentication.
Src Addr可変長フィールドは、発信インターフェイスに割り当てられたアドレスです。 addrの長さは、NHRPヘッダーの必須部分のソースプロトコル長フィールドから取得されます。タプル<spi、src addr>は、認証で使用されるキーおよびその他のパラメーターを一意に識別します。
The length of the authentication data field is dependent on the hash algorithm used. The data field contains the keyed hash calculated over the entire NHRP payload. The authentication data field is zeroed out before the hash is calculated.
認証データフィールドの長さは、使用するハッシュアルゴリズムによって異なります。データフィールドには、NHRPペイロード全体で計算されたキー付きハッシュが含まれます。ハッシュが計算される前に、認証データフィールドがゼロに設定されます。
SPI's can be negotiated either manually or using an Internet Key Management protocol. Manual keying MUST be supported. The following parameters are associated with the tuple <SPI, src>- lifetime, Algorithm, Key. Lifetime indicates the duration in seconds for which the key is valid. In case of manual keying, this duration can be infinite. Also, in order to better support manual keying, there may be multiple tuples active at the same time (Dst being the same).
SPIは、手動で、またはインターネットキー管理プロトコルを使用してネゴシエートできます。手動キーイングをサポートする必要があります。以下のパラメーターは、タプル<SPI、src>-ライフタイム、アルゴリズム、キーに関連付けられています。ライフタイムは、キーが有効である期間を秒単位で示します。手動キーイングの場合、この期間は無限になる可能性があります。また、手動キーイングをより適切にサポートするために、同時にアクティブな複数のタプルがある場合があります（Dstは同じです）。
Algorithm specifies the hash algorithm agreed upon by the two entities. HMAC-MD5-128 [16] is the default algorithm. Other algorithms MAY be supported by defining new values. IANA will assign the numbers to identify the algorithm being used as described in Section 9.
Algorithmは、2つのエンティティが合意したハッシュアルゴリズムを指定します。 HMAC-MD5-128 [16]がデフォルトのアルゴリズムです。他のアルゴリズムは、新しい値を定義することによってサポートされるかもしれません。 IANAは、セクション9で説明されているように、使用されているアルゴリズムを識別するために番号を割り当てます。
Any Internet standard key management protocol MAY so be used to negotiate the SPI and parameters.
インターネット標準の鍵管理プロトコルは、SPIとパラメータのネゴシエーションに使用できる場合があります。
At the time of adding the authentication extension header, src looks up in a table to fetch the SPI and the security parameters based on the outgoing interface address. If there are no entries in the table and if there is support for key management, the src initiates the key management protocol to fetch the necessary parameters. The src constructs the Authentication Extension payload and calculates the hash by zeroing authentication data field. The result replaces in the zeroed authentication data field. The src address field in the payload is the IP address assigned to the outgoing interface.
認証拡張ヘッダーを追加するときに、srcはテーブルを検索して、発信インターフェイスアドレスに基づいてSPIとセキュリティパラメータを取得します。テーブルにエントリがなく、キー管理のサポートがある場合、srcはキー管理プロトコルを開始して、必要なパラメータをフェッチします。 srcは認証拡張ペイロードを構築し、認証データフィールドをゼロ化することによってハッシュを計算します。結果は、ゼロ化された認証データフィールドで置き換えられます。ペイロードのsrcアドレスフィールドは、発信インターフェイスに割り当てられたIPアドレスです。
If key management is not supported and authentication is mandatory, the packet is dropped and this information is logged.
キー管理がサポートされておらず、認証が必須である場合、パケットはドロップされ、この情報がログに記録されます。
On the receiving end, dst fetches the parameters based on the SPI and the ip address in the authentication extension payload. The authentication data field is extracted before zeroing out to calculate the hash. It computes the hash on the entire payload and if the hash does not match, then an "abnormal event" has occurred.
受信側では、dstは認証拡張ペイロードのSPIとIPアドレスに基づいてパラメーターをフェッチします。認証データフィールドは、ハッシュを計算するためにゼロ設定する前に抽出されます。ペイロード全体のハッシュを計算し、ハッシュが一致しない場合は、「異常なイベント」が発生しています。
It is important that the keys chosen are strong as the security of the entire system depends on the keys being chosen properly and the correct implementation of the algorithms.
システム全体のセキュリティは、適切に選択されたキーとアルゴリズムの正しい実装に依存するため、選択されたキーは強力であることが重要です。
The security is performed on a hop by hop basis. The data received can be trusted only so much as one trusts all the entities in the path traversed. A chain of trust is established amongst NHRP entities in the path of the NHRP Message . If the security in an NHRP entity is compromised, then security in the entire NHRP domain is compromised.
セキュリティは、ホップごとに実行されます。受信したデータを信頼できるのは、通過したパス内のすべてのエンティティを信頼できる場合のみです。 NHRPメッセージのパスにあるNHRPエンティティ間で信頼の連鎖が確立されます。 NHRPエンティティのセキュリティが侵害されると、NHRPドメイン全体のセキュリティが侵害されます。
Data integrity covers the entire NHRP payload. This guarantees that the message was not modified and the source is authenticated as well. If authentication extension is not used or if the security is compromised, then NHRP entities are liable to both spoofing attacks, active attacks and passive attacks.
データの整合性はNHRPペイロード全体をカバーします。これにより、メッセージが変更されておらず、ソースも認証されていることが保証されます。認証拡張機能が使用されていない場合、またはセキュリティが侵害されている場合、NHRPエンティティは、スプーフィング攻撃、アクティブ攻撃、パッシブ攻撃の両方に対して責任があります。
There is no mechanism to encrypt the messages. It is assumed that a standard layer 3 confidentiality mechanism will be used to encrypt and decrypt messages. It is recommended to use an Internet standard key management protocol to negotiate the keys between the neighbors. Transmitting the keys in clear text, if other methods of negotiation is used, compromises the security completely.
メッセージを暗号化するメカニズムはありません。メッセージの暗号化と復号化には、標準のレイヤー3機密性メカニズムが使用されると想定されています。ネイバー間でキーをネゴシエートするには、インターネット標準のキー管理プロトコルを使用することをお勧めします。平文でキーを送信すると、他のネゴシエーション方法が使用されると、セキュリティが完全に損なわれます。
Any NHS is susceptible to Denial of Service (DOS) attacks that cause it to become overloaded, preventing legitimate packets from being acted upon properly. A rogue host can send request and registration packets to the first hop NHS. If the authentication option is not used, the registration packet is forwarded along the routed path requiring processing along each NHS. If the authentication option is used, then only the first hop NHS is susceptible to DOS attacks (i.e., unauthenticated packets will be dropped rather than forwarded on). If security of any host is compromised (i.e., the keys it is using to communicate with an NHS become known), then a rogue host can send NHRP packets to the first hop NHS of the host whose keys were compromised, which will then forward them along the routed path as in the case of unauthenticated packets. However, this attack requires that the rogue host to have the same first hop NHS as that of the compromised host. Finally, it should be noted that denial of service attacks that cause routers on the routed path to expend resources processing NHRP packets are also susceptable to attacks that flood packets at the same destination as contained in an NHRP packet's Destination Protocol Address field.
すべてのNHSは、サービス拒否（DOS）攻撃の影響を受けやすくなり、過負荷になり、正当なパケットが適切に処理されなくなります。不正なホストは、要求および登録パケットを最初のホップのNHSに送信できます。認証オプションを使用しない場合、登録パケットは各NHSに沿った処理を必要とするルーティングされたパスに沿って転送されます。認証オプションが使用されている場合、最初のホップのNHSのみがDOS攻撃の影響を受けやすくなります（つまり、認証されていないパケットは転送されずにドロップされます）。ホストのセキュリティが危険にさらされた場合（つまり、NHSとの通信に使用されているキーが既知になった場合）、不正なホストは、キーが危険にさらされたホストの最初のホップNHSにNHRPパケットを送信できます。認証されていないパケットの場合のように、ルーティングされたパスに沿って。ただし、この攻撃では、不正なホストが侵害されたホストと同じ最初のホップNHSを持っている必要があります。最後に、ルーティングされたパス上のルーターにNHRPパケットの処理にリソースを消費させるサービス拒否攻撃も、NHRPパケットの宛先プロトコルアドレスフィールドに含まれているのと同じ宛先でパケットをフラッディングする攻撃を受けやすいことに注意してください。
Compulsory = 0 Type = 8 Length = variable
強制= 0タイプ= 8長さ=可変
The NHRP Vendor-Private Extension is carried in NHRP packets to convey vendor-private information or NHRP extensions between NHRP speakers.
NHRP Vendor-Private ExtensionはNHRPパケットで伝送され、NHRPスピーカー間でベンダープライベート情報またはNHRP拡張機能を伝達します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Data.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID 802 Vendor ID as assigned by the IEEE [6]
ベンダーID 802 IEEEによって割り当てられたベンダーID [6]
Data The remaining octets after the Vendor ID in the payload are vendor-dependent data.
データペイロードのベンダーIDに続く残りのオクテットはベンダー依存のデータです。
This extension may be added to any "request" or "reply" packet and it is the only extension that may be included multiple times. If the receiver does not handle this extension, or does not match the Vendor ID in the extension then the extension may be completely ignored by the receiver. If a Vendor Private Extension is included in a "request" then it must be copied to the corresponding "reply".
この拡張子は、「要求」または「応答」パケットに追加でき、複数回含めることができる唯一の拡張子です。受信者がこの拡張機能を処理しない場合、または拡張機能のベンダーIDと一致しない場合、拡張機能は受信者によって完全に無視される可能性があります。 Vendor Private Extensionが「リクエスト」に含まれている場合は、対応する「返信」にコピーする必要があります。
In this section, we discuss certain operational considerations of NHRP.
このセクションでは、NHRPの運用上の考慮事項について説明します。
In practice, the initiating and responding stations may be either hosts or routers. However, there is a possibility under certain conditions that a stable routing loop may occur if NHRP is used between two routers. In particular, attempting to establish an NHRP path across a boundary where information used in route selection is lost may result in a routing loop. Such situations include the loss of BGP path vector information, the interworking of multiple routing protocols with dissimilar metrics (e.g, RIP and OSPF), etc. In such circumstances, NHRP should not be used. This situation can be avoided if there are no "back door" paths between the entry and egress router outside of the NBMA subnetwork. Protocol mechanisms to relax these restrictions are under investigation.
実際には、開始ステーションと応答ステーションはホストまたはルーターのいずれかです。ただし、特定の条件下では、2つのルーター間でNHRPを使用すると、安定したルーティングループが発生する可能性があります。特に、ルート選択で使用された情報が失われる境界を越えてNHRPパスを確立しようとすると、ルーティングループが発生する可能性があります。このような状況には、BGPパスベクトル情報の損失、異なるメトリックを持つ複数のルーティングプロトコルの相互作用（RIPやOSPFなど）などが含まれます。このような状況では、NHRPを使用しないでください。この状況は、NBMAサブネットワーク外の入口ルーターと出口ルーターの間に「バックドア」パスがない場合に回避できます。これらの制限を緩和するプロトコルメカニズムは調査中です。
In general it is preferable to use mechanisms, if they exist, in routing protocols to resolve the egress point when the destination lies outside of the NBMA subnetwork, since such mechanisms will be more tightly coupled to the state of the routing system and will probably be less likely to create loops.
一般に、宛先がNBMAサブネットワークの外部にある場合、ルーティングプロトコルでメカニズムが存在する場合は、それらを使用して出口点を解決することをお勧めします。このようなメカニズムは、ルーティングシステムの状態により密接に結合され、おそらくループを作成する可能性が低くなります。
The management of NHRP caches in the source station, the NHS serving the destination, and any intermediate NHSs is dependent on a number of factors.
ソースステーション、宛先にサービスを提供するNHS、および中間のNHSのNHRPキャッシュの管理は、いくつかの要因に依存します。
Source Stations
ソースステーション
Source stations MUST cache all received NHRP Resolution Replies that they are actively using. They also must cache "incomplete" entries, i.e., those for which a NHRP Resolution Request has been sent but those for which an NHRP Resolution Reply has not been received. This is necessary in order to preserve the Request ID for retries, and provides the state necessary to avoid triggering NHRP Resolution Requests for every data packet sent to the destination.
ソースステーションは、アクティブに使用しているすべての受信したNHRP解決応答をキャッシュする必要があります。また、「不完全な」エントリ、つまりNHRP解決要求が送信されたもので、NHRP解決応答が受信されなかったものもキャッシュする必要があります。これは、再試行の要求IDを保持するために必要であり、宛先に送信されるすべてのデータパケットに対してNHRP解決要求のトリガーを回避するために必要な状態を提供します。
Source stations MUST purge expired information from their caches. Source stations MUST purge the appropriate cached information upon receipt of an NHRP Purge Request packet.
ソースステーションは、期限切れの情報をキャッシュから削除する必要があります。ソースステーションは、NHRPパージ要求パケットの受信時に、キャッシュされた適切な情報をパージする必要があります。
When a station has a co-resident NHC and NHS, the co-resident NHS may reply to NHRP Resolution Requests from the co-resident NHC with information which the station cached as a result of the co-resident NHC making its own NHRP Resolution Requests as long as the co-resident NHS follows the rules for Transit NHSs as seen below.
ステーションに共存するNHCとNHSがある場合、共存するNHSは、共存するNHCが独自のNHRP解決要求を作成した結果としてステーションがキャッシュした情報で、共存するNHCからのNHRP解決要求に応答できます。共存するNHSが、以下に示すトランジットNHSのルールに従う限り。
Serving NHSs
NHSの提供
The NHS serving the destination (the one which responds authoritatively to NHRP Resolution Requests) SHOULD cache protocol address information from all NHRP Resolution Requests to which it has responded if the information in the NHRP Resolution Reply has the possibility of changing during its lifetime (so that an NHRP Purge Request packet can be issued). The internetworking to NBMA binding information provided by the source station in the NHRP Resolution Request may also be cached if and only if the "S" bit is set, the NHRP Resolution Request has included a CIE with the Holding Time field set greater than zero (this is the valid Holding Time for the source binding), and only for non-authoritative use for a period not to exceed the Holding Time.
宛先にサービスを提供するNHS（NHRP解決要求に正式に応答するもの）は、NHRP解決応答内の情報がその存続期間中に変更される可能性がある場合、応答したすべてのNHRP解決要求からプロトコルアドレス情報をキャッシュする必要があります（そのため、 NHRPパージ要求パケットを発行できます）。 「S」ビットが設定されている場合に限り、NHRP解決要求でソースステーションによって提供されたNBMAバインディング情報へのインターネットワーキングもキャッシュされる可能性があり、NHRP解決要求には、保持時間フィールドがゼロより大きく設定されたCIEが含まれています（これは、ソースバインディングの有効な保持時間です。保持時間を超えない期間、権限のない使用にのみ使用されます。
Transit NHSs
トランジットNHS
A Transit NHS (lying along the NHRP path between the source station and the responding NHS) may cache source binding information contained in NHRP Resolution Request packets that it forwards if and only if the "S" bit is set, the NHRP Resolution Request has included a CIE with the Holding Time field set greater than zero (this is the valid Holding Time for the source binding), and only for non-authoritative use for a period not to exceed the Holding Time.
トランジットNHS（ソースステーションと応答するNHSの間のNHRPパスに沿っている）は、「S」ビットが設定されている場合にのみ転送するNHRP解決要求パケットに含まれるソースバインディング情報をキャッシュし、NHRP解決要求が含まれている場合があります。保持時間フィールドがゼロより大きく設定されたCIE（これはソースバインディングの有効な保持時間です）であり、保持時間を超えない期間、権限のない使用のみを目的としています。
A Transit NHS may cache destination information contained in NHRP Resolution Reply CIE if only if the D bit is set and then only for non-authoritative use for a period not to exceed the Holding Time value contained in the CIE. A Transit NHS MUST NOT cache source binding information contained in an NHRP Resolution Reply.
トランジットNHSは、Dビットが設定されている場合に限り、CRPに含まれている保持時間の値を超えない期間に限り、権限のない使用のためにのみ、NHRP解決応答CIEに含まれている宛先情報をキャッシュできます。中継NHSは、NHRP解決応答に含まれるソースバインディング情報をキャッシュしてはなりません（MUST NOT）。
Further, a transit NHS MUST discard any cached information when the prescribed time has expired. It may return cached information in response to non-authoritative NHRP Resolution Requests only.
さらに、トランジットNHSは、指定された時間が経過すると、キャッシュされた情報を破棄する必要があります。権限のないNHRP解決要求にのみ応答して、キャッシュされた情報を返す場合があります。
NBMA-Connected Destinations
NBMAに接続された宛先
NHRP's most basic function is that of simple NBMA address resolution of stations directly attached to the NBMA subnetwork. These mappings are typically very static, and appropriately chosen holding times will minimize problems in the event that the NBMA address of a station must be changed. Stale information will cause a loss of connectivity, which may be used to trigger an authoritative NHRP Resolution Request and bypass the old data. In the worst case, connectivity will fail until the cache entry times out.
NHRPの最も基本的な機能は、NBMAサブネットワークに直接接続されているステーションの単純なNBMAアドレス解決の機能です。これらのマッピングは通常非常に静的であり、適切に選択された保持時間は、ステーションのNBMAアドレスを変更する必要がある場合の問題を最小限に抑えます。古い情報は接続の喪失を引き起こします。これは、信頼できるNHRP解決要求をトリガーし、古いデータをバイパスするために使用される可能性があります。最悪の場合、キャッシュエントリがタイムアウトするまで、接続は失敗します。
This applies equally to information marked in NHRP Resolution Replies as being "stable" (via the "D" bit).
これは、NHRP解決応答で（「D」ビットを介して）「安定」であるとマークされた情報にも同様に適用されます。
Destinations Off of the NBMA Subnetwork
NBMAサブネットワーク外の宛先
If the source of an NHRP Resolution Request is a host and the destination is not directly attached to the NBMA subnetwork, and the route to that destination is not considered to be "stable," the destination mapping may be very dynamic (except in the case of a subnetwork where each destination is only singly homed to the NBMA subnetwork). As such the cached information may very likely become stale. The consequence of stale information in this case will be a suboptimal path (unless the internetwork has partitioned or some other routing failure has occurred).
NHRP解決要求の送信元がホストであり、宛先がNBMAサブネットワークに直接接続されておらず、その宛先へのルートが「安定」していると見なされない場合、宛先マッピングは非常に動的な場合があります（ただし、各宛先が1つだけNBMAサブネットワークにホームしているサブネットワークの）。そのため、キャッシュされた情報が古くなる可能性が非常に高くなります。この場合、情報が古くなると次善の経路になります（インターネットワークが分割されていないか、他のルーティングエラーが発生した場合を除きます）。
A certain amount of care needs to be taken when using the Prefix Length field of a CIE, in particular with regard to the prefix length advertised (and thus the size of the equivalence class specified by it). Assuming that the routers on the NBMA subnetwork are exchanging routing information, it should not be possible for an NHS to create a black hole by advertising too large of a set of destinations, but suboptimal routing (e.g., extra internetwork layer hops through the NBMA) can result. To avoid this situation an NHS that wants to send the Prefix Length MUST obey the following rule:
CIEのPrefix Lengthフィールドを使用するときは、特にアドバタイズされるプレフィックス長（したがって、それによって指定される等価クラスのサイズ）に関して、ある程度の注意を払う必要があります。 NBMAサブネットワーク上のルーターがルーティング情報を交換していると仮定すると、NHSが宛先のセットをあまりにも多くアドバタイズしてブラックホールを作成することはできませんが、ルーティングが最適ではありません（たとえば、NBMAを介した余分なインターネットワークレイヤーホップ）。結果になる可能性があります。この状況を回避するには、プレフィックス長を送信するNHSが次のルールに従う必要があります。
The NHS examines the Network Layer Reachability Information (NLRI) associated with the route that the NHS would use to forward towards the destination (as specified by the Destination internetwork layer address in the NHRP Resolution Request), and extracts from this NLRI the shortest address prefix such that: (a) the Destination internetwork layer address (from the NHRP Resolution Request) is covered by the prefix, (b) the NHS does not have any routes with NLRI which form a subset of what is covered by the prefix. The prefix may then be used in the CIE.
NHSは、NHSが宛先に転送するために使用するルートに関連付けられたネットワークレイヤー到達可能性情報（NLRI）を調べ（NHRP解決要求の宛先インターネットワークレイヤーアドレスで指定）、このNLRIから最短アドレスプレフィックスを抽出します。 （a）（NHRP解決要求からの）宛先インターネットワーク層アドレスがプレフィックスでカバーされている、（b）NHSに、プレフィックスでカバーされているもののサブセットを形成するNLRIのルートがない。接頭辞はCIEで使用できます。
The Prefix Length field of the CIE should be used with restraint, in order to avoid NHRP stations choosing suboptimal transit paths when overlapping prefixes are available. This document specifies the use of the prefix length only when all the destinations covered by the prefix are "stable". That is, either:
重複するプレフィックスが使用可能な場合にNHRPステーションが最適ではないトランジットパスを選択するのを防ぐために、CIEのプレフィックス長フィールドを制限して使用する必要があります。このドキュメントでは、プレフィックスでカバーされるすべての宛先が「安定」している場合にのみ、プレフィックス長の使用を指定しています。つまり、次のいずれかです。
(a) All destinations covered by the prefix are on the NBMA network, or (b) All destinations covered by the prefix are directly attached to the NHRP responding station.
（a）プレフィックスの対象となるすべての宛先がNBMAネットワーク上にある、または（b）プレフィックスの対象となるすべての宛先がNHRP応答ステーションに直接接続されている。
Use of the Prefix Length field of the CIE in other circumstances is outside the scope of this document.
他の状況でのCIEのプレフィックス長フィールドの使用は、このドキュメントの範囲外です。
One could easily imagine a situation where a router, acting as an ingress station to the NBMA subnetwork, receives a data packet, such that this packet triggers an NHRP Resolution Request. If the router forwards this data packet without waiting for an NHRP transit path to be established, then when the next router along the path receives the packet, the next router may do exactly the same - originate its own NHRP Resolution Request (as well as forward the packet). In fact such a data packet may trigger NHRP Resolution Request generation at every router along the path through an NBMA subnetwork. We refer to this phenomena as the NHRP "domino" effect.
NBMAサブネットワークへの入口ステーションとして機能するルーターがデータパケットを受信し、このパケットがNHRP解決要求をトリガーする状況を容易に想像できます。 NHRPトランジットパスが確立されるのを待たずにルーターがこのデータパケットを転送する場合、パスに沿った次のルーターがパケットを受信すると、次のルーターがまったく同じように動作する可能性があります-独自のNHRP解決要求を送信（および転送）パケット）。実際、このようなデータパケットは、NBMAサブネットワークを経由するパスに沿ったすべてのルーターでNHRP解決要求の生成をトリガーする可能性があります。この現象をNHRPの「ドミノ」効果と呼びます。
The NHRP domino effect is clearly undesirable. At best it may result in excessive NHRP traffic. At worst it may result in an excessive number of virtual circuits being established unnecessarily. Therefore, it is important to take certain measures to avoid or suppress this behavior. NHRP implementations for NHSs MUST provide a mechanism to address this problem. One possible strategy to address this problem would be to configure a router in such a way that NHRP Resolution Request generation by the router would be driven only by the traffic the router receives over its non-NBMA interfaces (interfaces that are not attached to an NBMA subnetwork). Traffic received by the router over its NBMA-attached interfaces would not trigger NHRP Resolution Requests. Such a router avoids the NHRP domino effect through administrative means.
NHRPドミノ効果は明らかに望ましくありません。せいぜい、過剰なNHRPトラフィックが発生する可能性があります。最悪の場合、過度に多くの仮想回線が不必要に確立される可能性があります。したがって、この動作を回避または抑制するための特定の対策を講じることが重要です。 NHSのNHRP実装は、この問題に対処するメカニズムを提供する必要があります。この問題に対処するための1つの可能な戦略は、ルーターによるNHRP解決要求の生成が、非NBMAインターフェイス（NBMAに接続されていないインターフェイス）経由でルーターが受信するトラフィックによってのみ駆動されるようにルーターを構成することです。サブネットワーク）。ルータがNBMAに接続されたインターフェースを介して受信したトラフィックは、NHRP解決要求をトリガーしません。このようなルーターは、管理手段を通じてNHRPドミノ効果を回避します。
There would appear to be no significant impediment to running NHRP over legacy broadcast subnetworks. There may be issues around running NHRP across multiple subnetworks. Running NHRP on broadcast media has some interesting possibilities; especially when setting up a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both end stations are legacy attached. This use for NHRP requires further research.
レガシーブロードキャストサブネットワーク上でNHRPを実行することに大きな障害はないようです。複数のサブネットワーク間でNHRPを実行する際に問題が発生する可能性があります。ブロードキャストメディアでNHRPを実行すると、いくつかの興味深い可能性があります。特に、一方または両方のエンドステーションがレガシー接続されているときに、ELAN間LIS / LAG間トラフィックのカットスルーを設定する場合。 NHRPのこの使用には、さらに調査が必要です。
The result of an NHRP Resolution Request depends on how routing is configured among the NHSs of an NBMA subnetwork. If the destination station is directly connected to the NBMA subnetwork and the routed path to it lies entirely within the NBMA subnetwork, the NHRP Resolution Replies always return the NBMA address of the destination station itself rather than the NBMA address of some egress router. On the other hand, if the routed path exits the NBMA subnetwork, NHRP will be unable to resolve the NBMA address of the destination, but rather will return the address of the egress router. For destinations outside the NBMA subnetwork, egress routers and routers in the other subnetworks should exchange routing information so that the optimal egress router may be found.
NHRP解決要求の結果は、NBMAサブネットワークのNHS間でルーティングがどのように構成されるかによって異なります。宛先ステーションがNBMAサブネットワークに直接接続されており、そこへの経路指定されたパスが完全にNBMAサブネットワーク内にある場合、NHRP解決応答は常に、いくつかの出口ルーターのNBMAアドレスではなく、宛先ステーション自体のNBMAアドレスを返します。一方、ルーティングされたパスがNBMAサブネットワークを出る場合、NHRPは宛先のNBMAアドレスを解決できず、出力ルーターのアドレスを返します。 NBMAサブネットワーク外の宛先の場合、最適な出力ルーターが見つかるように、出力ルーターと他のサブネットワークのルーターはルーティング情報を交換する必要があります。
In addition to NHSs, an NBMA station could also be associated with one or more regular routers that could act as "connectionless servers" for the station. The station could then choose to resolve the NBMA next hop or just send the packets to one of its connectionless servers. The latter option may be desirable if communication with the destination is short-lived and/or doesn't require much network resources. The connectionless servers could, of course, be physically integrated in the NHSs by augmenting them with internetwork layer switching functionality.
NHSに加えて、NBMAステーションは、ステーションの「コネクションレスサーバー」として機能する1つ以上の通常のルーターに関連付けることもできます。次に、ステーションはNBMAネクストホップを解決するか、そのコネクションレス型サーバーの1つにパケットを送信するかを選択できます。宛先との通信が短期間であるか、ネットワークリソースをあまり必要としない場合は、後者のオプションが望ましい場合があります。もちろん、コネクションレス型サーバーは、インターネットワークレイヤースイッチング機能で拡張することにより、NHSに物理的に統合できます。
IANA will take advice from the Area Director appointed designated subject matter expert, in order to assign numbers from the various number spaces described herein. In the event that the Area Director appointed designated subject matter expert is unavailable, the relevant IESG Area Director will appoint another expert. Any and all requests for value assignment within a given number space will be accepted when the usage of the value assignment documented. Possible forms of documentantion include, but is not limited to, RFCs or the product of another cooperative standards body (e.g., the MPOA and LANE subworking group of the ATM Forum).
IANAは、ここに記載されているさまざまな番号スペースから番号を割り当てるために、指定された主題の専門家であるエリアディレクターからアドバイスを受けます。エリアディレクターが任命した主題の専門家が任命できない場合、関連するIESGエリアディレクターが別の専門家を任命します。値の割り当ての使用法が文書化されている場合、特定の番号スペース内の値の割り当てに対するすべての要求が受け入れられます。ドキュメンテーションの可能な形式には、RFCや他の共同標準化団体（ATMフォーラムのMPOAおよびLANEサブワーキンググループなど）の製品が含まれますが、これらに限定されません。
References
参考文献
[1] Heinanen, J., and R. Govindan, "NBMA Address Resolution Protocol (NARP)", RFC 1735, December 1994.
[1] Heinanen、J。、およびR. Govindan、「NBMAアドレス解決プロトコル（NARP）」、RFC 1735、1994年12月。
[2] Plummer, D., "Address Resolution Protocol", STD 37, RFC 826, November 1982.
[2] Plummer、D。、「Address Resolution Protocol」、STD 37、RFC 826、1982年11月。
[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] Piscitello,, D., and J. Lawrence, "Transmission of IP datagrams over the SMDS service", RFC 1209, March 1991.
[4] Piscitello ,, D.、and J. Lawrence、 "Transmission of IP datagrams over the SMDS service"、RFC 1209、March 1991。
[5] Protocol Identification in the Network Layer, ISO/IEC TR 9577:1990.
[5] ネットワーク層のプロトコル識別、ISO / IEC TR 9577：1990。
[6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[6] Reynolds、J.、およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。
[7] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[7] Heinanen、J。、「ATMアダプテーションレイヤー5上のマルチプロトコルカプセル化」、RFC 1483、1993年7月。
[8] Malis, A., Robinson, D., and R. Ullmann, "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, August 1992.
[8] Malis、A.、Robinson、D。、およびR. Ullmann、「X.25上のマルチプロトコル相互接続およびパケットモードのISDN」、RFC 1356、1992年8月。
[9] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1490, July 1993.
[9] Bradley、T.、Brown、C。、およびA. Malis、「Multiprotocol Interconnect over Frame Relay」、RFC 1490、1993年7月。
[10] Rekhter, Y., and D. Kandlur, ""Local/Remote" Forwarding Decision in Switched Data Link Subnetworks", RFC 1937, May 1996.
[10] Rekhter、Y。、およびD. Kandlur、「スイッチドデータリンクサブネットワークにおける「ローカル/リモート」転送決定」、RFC 1937、1996年5月。
[11] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[11] アーミテージ、G。、「UNI 3.0 / 3.1ベースのATMネットワーク上のマルチキャストのサポート」、RFC 2022、1996年11月。
[12] Luciani, J., Armitage, G., and J. Halpern, "Server Cache Synchronization Protocol (SCSP) - NBMA", RFC 2334, April 1998.
[12] Luciani、J.、Armitage、G。、およびJ. Halpern、「Server Cache Synchronization Protocol（SCSP）-NBMA」、RFC 2334、1998年4月。
[13] Rekhter, Y., "NHRP for Destinations off the NBMA Subnetwork", Work In Progress.
[13] Rekhter、Y。、「NBMAサブネットワーク外の宛先のNHRP」、作業中。
[14] Luciani, J., et. al., "Classical IP and ARP over ATM to NHRP Transition", Work In Progress.
[14] ルチアーニ、J。らその他、「ATMからNHRPへの移行に伴うクラシックIPおよびARP」、進行中の作業。
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[15] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[16] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[16] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed Hashing for Message Authentication」、RFC 2104、1997年2月。
Acknowledgments
謝辞
We would like to thank (in no particular order) Thomas Narten of IBM for his comments in the role of Internet AD, Juha Heinenan of Telecom Finland and Ramesh Govidan of ISI for their work on NBMA ARP and the original NHRP draft, which served as the basis for this work. Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco, and Grenville Armitage of Bellcore should also be acknowledged for comments and suggestions that improved this work substantially. We would also like to thank the members of the ION working group of the IETF, whose review and discussion of this document have been invaluable.
IBMのThomas NartenがインターネットAD、Telecom FinlandのJuha Heinenan、ISIのRamesh Govidanの役割について、NBMA ARPと元のNHRPドラフトの作業を担当してくれたことに感謝します（順不同）。この作業の基礎。 IBMのラッセルガルド、アダプティブのジョンバーネット、ANSのデニスファーガソン、ベイネットワークスのアンドレフレデット、ニューブリッジのジョエルハルパーン、NTTのポールフランシス、トニーリー、ブライアングリーソン、およびシスコのヤコブレクター、ベルコアのグレンビルアーミテージもこの作業を大幅に改善したコメントや提案については認めてください。また、この文書のレビューと議論が非常に貴重であるIETFのIONワーキンググループのメンバーにも感謝します。
Authors' Addresses
著者のアドレス
James V. Luciani Dave Katz
Bay Networks cisco Systems
3 Federal Street 170 W. Tasman Dr.
Mail Stop: BL3-03 San Jose, CA 95134 USA
Billerica, MA 01821 Phone: +1 408 526 8284
Phone: +1 978 916 4734 EMail: dkatz@cisco.com
EMail: luciani@baynetworks.com
David Piscitello Bruce Cole
Core Competence Juniper Networks
1620 Tuckerstown Road 3260 Jay St.
Dresher, PA 19025 USA Santa Clara, CA 95054
Phone: +1 215 830 0692 Phone: +1 408 327 1900
EMail: dave@corecom.com EMail: bcole@jnx.com
Naganand Doraswamy Bay Networks, Inc. 3 Federal Street Mail Stop: Bl3-03 Billerica, MA 01801 Phone: +1 978 916 1323 EMail: naganand@baynetworks.com
Naganand Doraswamy Bay Networks、Inc. 3 Federal Street Mail Stop：Bl3-03 Billerica、MA 01801 Phone：+1 978 916 1323 EMail：naganand@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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。