[要約] RFC 4389は、Neighbor Discovery Proxies（ND Proxy）の仕様を定義しており、IPv6ネットワークでのネイバー発見をサポートする。目的は、ネットワーク内のノード間通信の効率を向上させるために、ネイバー発見プロキシの使用を可能にすること。
Network Working Group D. Thaler
Request for Comments: 4389 M. Talwar
Category: Experimental Microsoft
C. Patel
All Play, No Work
April 2006
Neighbor Discovery Proxies (ND Proxy)
近隣探索プロキシ（NDプロキシ）
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験的プロトコルを定義しています。インターネット規格はあらゆる種類の標準を指定していません。改善のための議論と提案が要求されます。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（c）インターネット社会（2006）。
Abstract
概要
Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances.
複数のリンクを単一のエンティティにブリッジすると、いくつかの動作上の利点があります。単一のサブネットプレフィックスは複数の物理リンクをサポートするのに十分です。サブネット番号を異なるネットワークに割り当てる必要はなく、管理を簡素化します。ただし、一部の種類のメディアにはネットワーク層のサポートが必要です。この文書では、これらのケースについて説明し、このような状況下でブリッジを可能にするIP層のサポートを指定します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. SCENARIO 1: Wireless Upstream ..............................3
1.2. SCENARIO 2: PPP Upstream ...................................4
1.3. Inapplicable Scenarios .....................................5
2. Terminology .....................................................5
3. Requirements ....................................................5
3.1. Non-requirements ...........................................6
4. Proxy Behavior ..................................................7
4.1. Forwarding Packets .........................................7
4.1.1. Sending Packet Too Big Messages .....................8
4.1.2. Proxying Packets with Link-Layer Addresses ..........8
4.1.3. IPv6 ND Proxying ....................................9
4.1.3.1. ICMPv6 Neighbor Solicitations ..............9
4.1.3.2. ICMPv6 Neighbor Advertisements .............9
4.1.3.3. ICMPv6 Router Advertisements ...............9
4.1.3.4. ICMPv6 Redirects ..........................10
4.2. Originating Packets .......................................10
5. Example ........................................................11
6. Loop Prevention ................................................12
7. Guidelines to Proxy Developers .................................12
8. IANA Considerations ............................................13
9. Security Considerations ........................................13
10. Acknowledgements ..............................................14
11. Normative References ..........................................14
12. Informative References ........................................15
Appendix A: Comparison with Naive RA Proxy ........................16
In the IPv4 Internet today, it is common for Network Address Translators (NATs) [NAT] to be used to easily connect one or more leaf links to an existing network without requiring any coordination with the network service provider. Since NATs modify IP addresses in packets, they are problematic for many IP applications. As a result, it is desirable to address the problem (for both IPv4 and IPv6) without the need for NATs, while still maintaining the property that no explicit cooperation from the router is needed.
今日のIPv4インターネットでは、ネットワークサービスプロバイダとの調整を必要とせずに、1つ以上のリーフリンクを既存のネットワークに簡単に接続するために、ネットワークアドレストランスレータ（NAT）が使用されることが一般的です。NATSはパケット内のIPアドレスを変更するため、多くのIPアプリケーションに問題があります。その結果、ルータからの明示的な協力が必要ないプロパティを依然として維持しながら、NATを必要とせずに問題（IPv4とIPv6の両方の場合）に対処することが望ましいです。
One common solution is IEEE 802 bridging, as specified in [BRIDGE]. It is expected that whenever possible links will be bridged at the link layer using classic bridge technology [BRIDGE] as opposed to using the mechanisms herein. However, classic bridging at the data-link layer has the following limitations (among others):
1つの一般的な解決策は、[Bridge]で指定されているように、IEEE 802ブリッジングです。本明細書のメカニズムを使用して、クラシックブリッジテクノロジ[ブリッジ]を使用してリンク層でリンクレイヤでリンク層で橋渡しされることが予想されます。ただし、データリンクレイヤでの古典的なブリッジングは、（とりわけ）の制限事項を有する。
o It requires the ports to support promiscuous mode.
o それはポートが無差別モードをサポートすることを要求します。
o It requires all ports to support the same type of link-layer addressing (in particular, IEEE 802 addressing).
o 同じ種類のリンクレイヤアドレス指定（特にIEEE 802アドレッシング）をサポートするようにすべてのポートが必要です。
As a result, two common scenarios, described below, are not solved, and it is these two scenarios we specifically target in this document. While the mechanism described herein may apply to other scenarios as well, we will concentrate our discussion on these two scenarios.
その結果、以下に説明する2つの一般的なシナリオが解決されておらず、この文書の中で具体的にはターゲットに対象となるこれら2つのシナリオです。本明細書に記載されているメカニズムは他のシナリオにも適用されるかもしれませんが、これら2つのシナリオについて説明します。
The following figure illustrates a likely example:
次の図は、可能性のある例を示しています。
| +-------+ +--------+
local |Ethernet | | Wireless | Access |
+---------+ A +-))) (((-+ +--> rest of network
hosts | | | link | Point |
| +-------+ +--------+
In this scenario, the access point has assigned an IPv6 subnet prefix to the wireless link, and uses link-layer encryption so that wireless clients may not see each other's data.
このシナリオでは、アクセスポイントはワイヤレスリンクにIPv6サブネットプレフィックスを割り当て、リンクレイヤの暗号化を使用して、ワイヤレスクライアントが互いのデータを表示できない可能性があります。
Classic bridging requires the bridge (node A in the above diagram) to be in promiscuous mode. In this wireless scenario, A cannot put its wireless interface into promiscuous mode, since one wireless node cannot see traffic to/from other wireless nodes.
クラシックブリッジングには、ブリッジ（上図のノードA）が無差別モードになることを要求します。この無線シナリオでは、1つの無線ノードが他のワイヤレスノードへのトラフィックを見ることができないので、無線インタフェースを無差別モードにすることはできません。
IPv4 Address Resolution Protocol (ARP) proxying has been used for some years to solve this problem without involving NAT or requiring any change to the access point or router. In this document, we describe equivalent functionality for IPv6 to remove this incentive to deploy NATs in IPv6.
IPv4アドレス解決プロトコル（ARP）プロキシは、NATを巻き込むことなく、またはアクセスポイントまたはルータへの変更を要求することなく、この問題を解決するために何年もの間使用されています。このドキュメントでは、IPv6の同等の機能を説明して、IPv6のNATを展開するためのこのインセンティブを削除します。
We also note that Prefix Delegation [PD] could also be used to solve this scenario. There are, however, two disadvantages to this. First, if an implementation already supports IPv4 ARP proxying (which is indeed the case in a number of implementations today), then IPv6 Prefix Delegation would result in separate IPv6 subnets on either side of the device, while a single IPv4 subnet would span both segments. This topological discrepancy can complicate applications and protocols that use the concept of a local subnet. Second, the extent to which Prefix Delegation is supported for any particular subscriber class is up to the service provider. Hence, there is no guarantee that Prefix Delegation will work without explicit configuration or additional charge. Bridging, on the other hand, allows the device to work with zero configuration, regardless of the service provider's policies, just as a NAT does. Hence bridging avoids the incentive to NAT IPv6 just to avoid paying for, or requiring configuration to get, another prefix.
また、このシナリオを解決するためにプレフィックス代表団[PD]を使用できることも注意してください。しかし、これには2つの欠点があります。まず、実装がすでにIPv4 ARPプロキシをサポートしている場合（これは本日、現在の実装の実装では事実です）、IPv6プレフィックスの委任はデバイスの両側に別々のIPv6サブネットになりますが、単一のIPv4サブネットは両方のセグメントにまたがるでしょう。 。このトポロジの不一致は、ローカルサブネットの概念を使用するアプリケーションとプロトコルを複雑にすることができます。第二に、特定の加入者クラスに対してプレフィックス委任がサポートされている範囲は、サービスプロバイダ次第です。したがって、プレフィックスの委任が明示的な構成や追加料金なしで機能するという保証はありません。一方、ブリッジングにより、サービスプロバイダのポリシーに関係なく、NATと同じようにデバイスがゼロ設定で動作できます。したがって、ブリッジングは、別のプレフィックスを得るために支払うことを回避するためだけに、NAT IPv6へのインセンティブを回避します。
The following figure illustrates another likely example:
次の図は、別の可能性のある例を示しています。
| +-------+ +--------+
local |Ethernet | | PPP link | |
+---------+ A +-----------+ Router +--> rest of network
hosts | | | | |
| +-------+ +--------+
In this scenario, the router has assigned a /64 to the PPP link and advertises it in an IPv6 Router Advertisement.
このシナリオでは、ルータはPPPリンクにA / 64を割り当て、それをIPv6ルータ広告にアドバタイズしました。
Classic bridging does not support non-802 media. The PPP Bridging Control Protocol [BCP] defines a mechanism for supporting bridging over PPP, but it requires both ends to be configured to support it. Hence IPv4 connectivity is often solved by making the proxy (node A in the above diagram) be a NAT or an IPv4 ARP proxy. This document specifies a solution for IPv6 that does not involve NAT or require any change to the router.
Classic Bridgingは、802以外のメディアをサポートしません。PPPブリッジング制御プロトコル[BCP]は、PPPを介してブリッジをサポートするためのメカニズムを定義していますが、両端をサポートするように設定されます。したがって、IPv4接続はしばしばプロキシ（上図のノードA）をNATまたはIPv4 ARPプロキシにすることで解決されることがよくあります。このドキュメントは、NATを含まない、またはルータに変更を必要としないIPv6のソリューションを指定します。
This document is not applicable to scenarios with loops in the physical topology, or where routers exist on multiple segments. These cases are detected and proxying is disabled (see Section 6).
この文書は、物理トポロジのループを使用したシナリオ、または複数のセグメントにルータが存在する場合には適用されません。これらのケースが検出され、プロキシが無効になります（セクション6を参照）。
In addition, this document is not appropriate for scenarios where classic bridging can be applied, or when configuration of the router can be done.
さらに、この文書は、古典的なブリッジングを適用できるシナリオには適していません。ルータの構成を実行できる場合は適切です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [KEYWORDS].
「必須」、「必須」、「必要ではない」、「しない」、「推奨する」、「推奨する」、「5月」、および「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、BCP 14、RFC 2119 [キーワード]に記載されているように解釈されること。
The term "proxy interface" will be used to refer to an interface (which could itself be a bridge interface) over which network-layer proxying is done as defined herein.
「プロキシインタフェース」という用語は、本明細書で定義されているようにネットワーク層プロキシが行われるインターフェース（それ自体がブリッジインタフェースである可能性がある）を指すために使用される。
In this document, we make no distinction between a "link" (in the classic IPv6 sense) and a "subnet". We use the term "segment" to apply to a bridged component of the link.
この文書では、「リンク」（古典的なIPv6センス内）と「サブネット」を区別しません。リンクのブリッジコンポーネントに適用するには、「セグメント」という用語を使用します。
Finally, while it is possible that functionality equivalent to that described herein may be achieved by nodes that do not fulfill all the requirements in [NODEREQ], in the remainder of this document we will describe behavior in terms of an IPv6 node as defined in that document.
最後に、本明細書で説明されているものと同等の機能が、この文書の残りの部分では、[Nodereq]ではすべての要件を満たさないノードによって達成される可能性がある。資料。
Proxy behavior is designed with the following requirements in mind:
プロキシ動作は以下の要件を断とて設計されています。
o Support connecting multiple segments with a single subnet prefix.
o 単一のサブネットプレフィックスを持つ複数のセグメントの接続をサポートします。
o Support media that cannot be bridged at the link layer.
o リンクレイヤでブリッジできないサポートメディア。
o Do not require any changes to existing routers. That is, routers on the subnet may be unaware that the subnet is being bridged.
o 既存のルータに変更を必要としないでください。つまり、サブネット上のルータは、サブネットがブリッジされていることに気付かない可能性があります。
o Provide full connectivity between all nodes in the subnet. For example, if there are existing nodes (such as any routers on the subnet) that have addresses in the subnet prefix, adding a proxy must allow bridged nodes to have full connectivity with existing nodes on the subnet.
o サブネット内のすべてのノード間の完全な接続性を提供します。たとえば、サブネットプレフィックス内のアドレスを持つ既存のノード（サブネット上の任意のルーターなど）がある場合は、プロキシを追加する必要があります。ブリッジノードは、サブネット上の既存のノードとの完全な接続を可能にする必要があります。
o Prevent loops.
o ループを防ぎます。
o Also work in the absence of any routers.
o ルーターがない場合も機能します。
o Support nodes moving between segments. For example, a node should be able to keep its address without seeing its address as a duplicate due to any cache maintained at the proxy.
o セグメント間の動きをサポートします。たとえば、ノードは、プロキシに保持されているキャッシュのために、アドレスを複製として表示せずにアドレスを保持することができます。
o Allow dynamic addition of a proxy without adversely disrupting the network.
o ネットワークを中断することなくプロキシを動的に追加します。
o The proxy behavior should not break any existing classic bridges in use on a network segment.
o プロキシ動作は、ネットワークセグメントで使用されている既存の古典的なブリッジを区切るべきではありません。
The following items are not considered requirements, as they are not met by classic bridges:
以下の項目は、それらが古典的なブリッジによって満たされていないので、要件とは見なされません。
o Show up as a hop in a traceroute.
o Tracerouteでホップとして現れる。
o Use the shortest path between two nodes on different segments.
o 異なるセグメント上の2つのノード間の最短経路を使用してください。
o Be able to use all available interfaces simultaneously. Instead, bridging technology relies on disabling redundant interfaces to prevent loops.
o 利用可能なすべてのインターフェイスを同時に使用できるようにすることができます。代わりに、ブリッジングテクノロジはループを防ぐために冗長インタフェースを無効にすることに依存しています。
o Support connecting media on which Neighbor Discovery is not possible. For example, some technologies such as [6TO4] use an algorithmic mapping from IPv6 address to the underlying link-layer (IPv4 in this case) address, and hence cannot support bridging arbitrary IP addresses.
o 近隣探索が不可能なメディアの接続をサポートします。たとえば、[6to4]のようないくつかのテクノロジは、IPv6アドレスから基礎となるリンク層（この場合はIPv4）アドレスへのアルゴリズムマッピングを使用しているため、任意のIPアドレスをブリッジすることはできません。
The following additional items are not considered requirements for this document:
次の追加項目はこの文書の要件とは見なされません。
o Support network-layer protocols other than IPv6. We do not preclude such support, but it is not specified in this document.
o IPv6以外のネットワーク層プロトコルをサポートします。このようなサポートを排除しないが、この文書では指定されていません。
o Support Redirects for off-subnet destinations that point to a router on a different segment from the redirected host. While this scenario may be desirable, no solution is currently known that does not have undesirable side effects outside the subnet. As a result, this scenario is outside the scope of this document.
o リダイレクトされたホストから別のセグメント上のルータを指すオフサブネット宛先のリダイレクトをサポートします。このシナリオが望ましいかもしれないが、サブネットの外側で望ましくない副作用を有さない解決策は知られていない。その結果、このシナリオはこの文書の範囲外です。
Network-layer support for proxying between multiple interfaces SHOULD be used only when classic bridging is not possible.
複数のインタフェース間のプロキシのためのネットワークレイヤのサポートは、古典的なブリッジングが不可能な場合にのみ使用されます。
When a proxy interface comes up, the node puts it in "all-multicast" mode so that it will receive all multicast packets. It is common for interfaces not to support full promiscuous mode (e.g., on a wireless client), but all-multicast mode is generally still supported.
プロキシインターフェイスが起動すると、ノードはすべてのマルチキャストパケットを受信するように "All-Multicast"モードになります。完全な無差別モード（例えば、無線クライアント上で）をサポートしないインターフェースは一般的にサポートされています。
As with all other interfaces, IPv6 maintains a neighbor cache for each proxy interface, which will be used as described below.
他のすべてのインターフェイスと同様に、IPv6は各プロキシインタフェースごとにネイバーキャッシュを維持します。これは以下のように使用されます。
When a packet from any IPv6 source address other than the unspecified address is received on a proxy interface, the neighbor cache of that interface SHOULD be consulted to find an entry for the source IPv6 address. If no entry exists, one is created in the STALE state.
未指定アドレス以外のIPv6送信元アドレスからのパケットがプロキシインタフェースで受信されると、そのインターフェイスのネイバーキャッシュを参照して、送信元IPv6アドレスのエントリを見つける必要があります。エントリが存在しない場合は、Stale状態で1つ作成されます。
When any IPv6 packet is received on a proxy interface, it must be parsed to see whether it is known to be of a type that negotiates link-layer addresses. This document covers the following types: Neighbor Solicitations, Neighbor Advertisements, Router Advertisements, and Redirects. These packets are ones that can carry link-layer addresses, and hence must be proxied (as described below) so that packets between nodes on different segments can be received by the proxy and have the correct link-layer address type on each segment.
IPv6パケットがプロキシインタフェースで受信されると、リンクレイヤアドレスをネゴシエーションする型であることがわかっているかどうかを確かめるために解析されなければなりません。この文書は、隣接勧誘、近隣広告、ルータ広告、およびリダイレクトを説明しています。これらのパケットはリンク層アドレスを持つことができるもので、異なるセグメント上のノード間のパケットをプロキシによって受信し、各セグメントに正しいリンク層アドレスタイプを持つことができるようにプロキシを処理する必要があります。
When any other IPv6 multicast packet is received on a proxy interface, in addition to any normal IPv6 behavior such as being delivered locally, it is forwarded unchanged (other than using a new link-layer header) out all other proxy interfaces on the same link. (As specified in [BRIDGE], the proxy may instead support multicast learning and filtering, but this is OPTIONAL.) In particular, the IPv6 Hop Limit is not updated, and no ICMP errors (except as noted in Section 4.1.1 below) are sent as a result of attempting this forwarding.
他のIPv6マルチキャストパケットがプロキシインタフェースで受信された場合、ローカルに配信されるなどの通常のIPv6の動作に加えて、同じリンク上の他のすべてのプロキシインターフェイスを変更しない（新しいリンクレイヤヘッダーを使用する以外）。。（[ブリッジ]で指定されているように、代わりにプロキシはマルチキャスト学習とフィルタリングをサポートすることがありますが、これはオプションです。この転送を試みた結果として送信されます。
When any other IPv6 unicast packet is received on a proxy interface, if it is not locally destined then it is forwarded unchanged (other than using a new link-layer header) to the proxy interface for which the next hop address appears in the neighbor cache. Again the IPv6 Hop Limit is not updated, and no ICMP errors (except as noted in Section 4.1.1 below) are sent as a result of attempting this forwarding. To choose a proxy interface to forward to, the neighbor cache is consulted, and the interface with the neighbor entry in the "best" state is used. In order of least to most preferred, the states (per [ND]) are INCOMPLETE, STALE, DELAY, PROBE, REACHABLE. A packet is never forwarded back out the same interface on which it arrived; such a packet is instead silently dropped.
他のIPv6ユニキャストパケットがプロキシインタフェースで受信された場合、ローカルに宛先されていない場合は、ネクストホップアドレスがネイバーキャッシュに表示されるプロキシインターフェイスに変更されず（新しいリンク層ヘッダーを使用する以外）転送されません。。もう一度IPv6ホップの制限は更新されず、この転送を試みた結果としてICMPエラー（下記の4.1.1項に記載されている場合を除く）は送信されません。転送するプロキシインタフェースを選択するには、ネイバーキャッシュを参照し、「最良の」状態のネイバーエントリとのインターフェイスが使用されます。最低限最も好ましい順に、状態（ND]ごと）は不完全、古い、遅延、プローブ、到達可能である。パケットはそれが到着したのと同じインターフェースを後退させません。そのようなパケットは代わりに静かにドロップされます。
If no cache entry exists (as may happen if the proxy has previously evicted the cache entry or if the proxy is restarted), the proxy SHOULD queue the packet and initiate Neighbor Discovery as if the packet were being locally generated. The proxy MAY instead silently drop the packet. In this case, the entry will eventually be re-created when the sender re-attempts Neighbor Discovery.
キャッシュエントリが存在しない場合（プロキシが以前にキャッシュエントリがキャッシュエントリを追い出した場合、またはプロキシが再起動された場合）、プロキシはパケットをキューに入れ、パケットがローカルに生成されているかのようにネイバーディスカバリを開始する必要があります。プロキシは代わりにパケットを静的に落とすことができます。この場合、送信者がネイバーディスカバリを再試行すると、エントリは最終的に再作成されます。
The link-layer header and the link-layer address within the payload for each forwarded packet will be modified as follows:
各転送パケットのペイロード内のリンク層ヘッダとリンク層アドレスは、次のように変更されます。
1) The source address will be the address of the outgoing interface.
1) 送信元アドレスは、発信インターフェイスのアドレスになります。
2) The destination address will be the address in the neighbor entry corresponding to the destination IPv6 address.
2) 宛先アドレスは、宛先IPv6アドレスに対応するネイバーエントリ内のアドレスになります。
3) The link-layer address within the payload is substituted with the address of the outgoing interface.
3) ペイロード内のリンク層アドレスは、発信インターフェイスのアドレスに置き換えられます。
Whenever any IPv6 packet is to be forwarded out an interface whose MTU is smaller than the size of the packet, the ND proxy drops the packet and sends a Packet Too Big message back to the source, as described in [ICMPv6].
MTUがパケットのサイズよりも小さいインタフェースを任意のIPv6パケットが転送されるたびに、[ICMPv6]で説明されているように、NDプロキシはパケットを削除し、パケットを送信元に送信します。
Once it is determined that the packet is either multicast or else is not locally destined (if unicast), the special types enumerated above (ARP, etc.) that carry link-layer addresses are handled by generating a proxy packet that contains the proxy's link-layer address on the outgoing interface instead. Such link-layer addresses occur in the link-layer header itself, as well as in the payloads of some protocols. As with all forwarded packets, the link-layer header is new.
パケットがマルチキャストであると判断されたら（ユニキャストの場合）、リンク層アドレスを持つ特殊タイプ（ARPなど）は、プロキシのリンクを含むプロキシパケットを生成することによって処理されます。代わりに発信インターフェイス上のレイヤアドレス。そのようなリンク層アドレスは、リンク層ヘッダ自体、ならびにいくつかのプロトコルのペイロード内で行われる。すべての転送されたパケットと同様に、リンクレイヤヘッダーは新しいです。
Section 4.1.3 enumerates the currently known cases where link-layer addresses must be changed in payloads. For guidance on handling future protocols, Section 7, "Guidelines to Proxy Developers", describes the scenarios in which the link-layer address substitution in the payload should be performed. Note that any change to the length of a proxied packet, such as when the link-layer address length changes, will require a corresponding change to the IPv6 Payload Length field.
セクション4.1.3は、リンク層アドレスをペイロードで変更する必要がある現在既知のケースを列挙します。将来のプロトコルの取り扱いに関するガイダンスについては、セクション7、「プロキシ開発者へのガイドライン」では、ペイロード内のリンク層アドレス置換を実行するシナリオについて説明します。リンク層のアドレス長が変化するときなど、プロキシパケットの長さへの変更は、IPv6ペイロード長フィールドに対応する変更を必要とすることに注意してください。
When any IPv6 packet is received on a proxy interface, it must be parsed to see whether it is known to be one of the following types: Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, or Redirect.
IPv6パケットがプロキシインターフェイスで受信されると、それが次のいずれかのタイプのいずれかであることがわかっているかどうかを確かめるために解析されなければなりません：ネイバー勧誘、ネイバー広告、ルーター広告、またはリダイレクト。
If the received packet is an ICMPv6 Neighbor Solicitation (NS), the NS is processed locally as described in Section 7.2.3 of [ND] but no NA is generated immediately. Instead the NS is proxied as described above and the NA will be proxied when it is received. This ensures that the proxy does not interfere with hosts moving from one segment to another since it never responds to an NS based on its own cache.
受信したパケットがICMPv6隣接勧誘（NS）である場合、NSは[ND]のセクション7.2.3で説明されているようにローカルに処理されますが、NAは直ちに生成されません。代わりに、NSは上記のようにプロキシされ、NAは受信されたときにプロキシされます。これにより、プロキシは、独自のキャッシュに基づいてNSに応答しないため、ホストがあるセグメントから別のセグメントへ移動するホストを妨げないようになります。
If the received packet is an ICMPv6 Neighbor Advertisement (NA), the neighbor cache on the receiving interface is first updated as if the NA were locally destined, and then the NA is proxied as described in 4.1.2 above.
受信したパケットがICMPv6隣接アドバタイズメント（NA）である場合、NAがローカルに指示されたかのように受信インタフェース上の隣接キャッシュは最初に更新され、その後、NAは上記の4.1.2で説明されているようにプロキシされる。
The following special processing is done for IPv6 Router Advertisements (RAs).
IPv6ルータ広告（RAS）については、以下の特別な処理が行われます。
A new "Proxy" bit is defined in the existing Router Advertisement flags field as follows:
次のように、[既存のルータアドバタイズフラグ]フィールドに新しい「プロキシ」ビットが定義されています。
+-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|Rsv|
+-+-+-+-+-+-+-+-+
where "P" indicates the location of the Proxy bit, and "Rsv"
indicates the remaining reserved bits.
The proxy determines an "upstream" proxy interface, typically through a (zero-configuration) physical choice dictated by the scenario (see Scenarios 1 and 2 above), or through manual configuration.
プロキシは、通常、シナリオによって決定される（上記のシナリオ1と2を参照）、または手動構成を介して、通常、「アップストリーム」プロキシインタフェースを決定します。
When an RA with the P bit clear arrives on the upstream interface, the P bit is set when the RA is proxied out all other ("downstream") proxy interfaces (see Section 6).
Pビットクリア付きRAがアップストリームインターフェイスに到着すると、RAが他のすべてのプロキシインタフェースにプロキシされたときにPビットが設定されます（セクション6を参照）。
If an RA with the P bit set has arrived on a given interface (including the upstream interface) within the last 60 minutes, that interface MUST NOT be used as a proxy interface; i.e., proxy functionality is disabled on that interface.
過去60分以内にPビットセットを持つRAが特定のインタフェース（アップストリームインターフェイスを含む）に到着した場合、そのインターフェイスはプロキシインターフェイスとして使用されてはいけません。すなわち、プロキシ機能はそのインタフェースで無効になっています。
Furthermore, if any RA (regardless of the value of the P bit) has arrived on a "downstream" proxy interface within the last 60 minutes, that interface MUST NOT be used as a proxy interface.
さらに、（Pビットの値に関係なく）RAが過去60分以内に「ダウンストリーム」プロキシインタフェースに到着した場合、そのインターフェイスはプロキシインターフェイスとして使用されてはならない。
The RA is processed locally as well as proxied as described in Section 4.1.2, unless such proxying is disabled as noted above.
RAは、そのようなプロキシが上記のように無効にされない限り、4.1.2項に記載されているようにローカルで処理されるだけである。
If the received packet is an ICMPv6 Redirect message, then the proxied packet should be modified as follows. If the proxy has a valid (i.e., not INCOMPLETE) neighbor entry for the target address on the same interface as the redirected host, then the Target Link-Layer Address (TLLA) option in the proxied Redirect simply contains the link-layer address of the target as found in the proxy's neighbor entry, since the redirected host may reach the target address directly. Otherwise, if the proxy has a valid neighbor entry for the target address on some other interface, then the TLLA option in the proxied packet contains the link-layer address of the proxy on the sending interface, since the redirected host must reach the target address through the proxy. Otherwise, the proxy has no valid neighbor entry for the target address, and the proxied packet contains no TLLA option, which will cause the redirected host to perform Neighbor Discovery for the target address.
受信したパケットがICMPv6リダイレクトメッセージの場合、プロキシパケットは次のように変更されるべきです。プロキシがリダイレクトされたホストと同じインターフェイス上のターゲットアドレスに対して有効な（すなわち、不完全な）ネイバーエントリを持つ場合、プロキシリダイレクトのプロキシリダイレクト内のターゲットリンクレイヤアドレス（TLLA）オプションには、単にリンクレイヤアドレスが含まれています。リダイレクトされたホストがターゲットアドレスに直接到達する可能性があるため、プロキシのネイバーエントリにあるターゲット。それ以外の場合、プロキシが他のインターフェイスでターゲットアドレスの有効なネイバーエントリを持つ場合、プロキシパケット内のTLLAオプションには、リダイレクトされたホストがターゲットアドレスに到達しなければならないため、送信インターフェイス上のプロキシのリンクレイヤアドレスが含まれています。プロキシを通して。それ以外の場合、プロキシはターゲットアドレスの有効なネイバーエントリを持ち、プロキシパケットにはTLLAオプションが含まれていません。これにより、リダイレクトしたホストがターゲットアドレスのネイバーディスカバリを実行させます。
Locally originated packets that are sent on a proxy interface also follow the same rules as packets received on a proxy interface. If no neighbor entry exists when a unicast packet is to be locally originated, an interface can be chosen in any implementation-specific fashion. Once the neighbor is resolved, the actual interface will be discovered and the packet will be sent on that interface. When a multicast packet is to be locally originated, an interface can be chosen in any implementation-specific fashion, and the packet will then be forwarded out other proxy interfaces on the same link as described in Section 4.1 above.
プロキシインタフェースで送信されるローカルに発信されたパケットは、プロキシインターフェイスで受信されたパケットと同じ規則に従います。ユニキャストパケットをローカルに発信する場合、隣接エントリが存在しない場合、インタフェースは実装固有の方法で選択できます。ネイバーが解決されると、実際のインターフェイスが検出され、パケットがそのインターフェイスで送信されます。マルチキャストパケットをローカルに発信する場合は、任意の実装固有の方法でインタフェースを選択でき、その後、パケットは上記のセクション4.1で説明したのと同じリンク上の他のプロキシインタフェースを転送する。
Consider the following topology, where A and B are nodes on separate segments which are connected by a proxy P:
次のトポロジを考慮して、AとBはプロキシPによって接続されている別々のセグメント上のノードです。
A---|---P---|---B
a p1 p2 b
A and B have link-layer addresses a and b, respectively. P has link-layer addresses p1 and p2 on the two segments. We now walk through the actions that happen when A attempts to send an initial IPv6 packet to B.
AとBはそれぞれリンク層アドレスAとBを有する。Pは、2つのセグメント上のリンク層アドレスP1およびP2を有する。私たちは今、最初のIPv6パケットをBに送信しようとすると起こるアクションを歩いています。
A first does a route lookup on the destination address B. This matches the on-link subnet prefix, and a destination cache entry is created as well as a neighbor cache entry in the INCOMPLETE state. Before the packet can be sent, A needs to resolve B's link-layer address and sends a Neighbor Solicitation (NS) to the solicited-node multicast address for B. The Source Link-Layer Address (SLLA) option in the solicitation contains A's link-layer address.
最初に宛先アドレスBのルート検索を行います。これは、オンリンクサブネットプレフィックスと一致し、宛先キャッシュエントリと不完全な状態のネイバーキャッシュエントリと一致します。パケットを送信する前に、Bのリンク層アドレスを解決する必要があり、BのLink-Laintitation（NS）をBの要請ノードマルチキャストアドレスに送信します。勧誘のソースリンクレイヤアドレス（SLLA）オプションには、Aのリンクが含まれています。 - 層アドレス。
P receives the solicitation (since it is receiving all link-layer multicast packets) and processes it as it would any multicast packet by forwarding it out to other segments on the link. However, before actually sending the packet, it determines if the packet being sent is one that requires proxying. Since it is an NS, it creates a neighbor entry for A on interface 1 and records its link-layer address. It also creates a neighbor entry for B (on an arbitrary proxy interface) in the INCOMPLETE state. Since the packet is multicast, P then needs to proxy the NS out all other proxy interfaces on the subnet. Before sending the packet out interface 2, it replaces the link-layer address in the SLLA option with its own link-layer address, p2.
pは、（すべてのリンク層マルチキャストパケットを受信しているので）勧誘を受け取り、リンク上の他のセグメントに転送することによってマルチキャストパケットを処理するように処理します。ただし、パケットを実際に送信する前に、送信されているパケットがプロキシを必要とするかどうかを判断します。NSなので、ON Interface 1の隣接エントリを作成し、そのリンク層アドレスを記録します。また、不完全状態のB（任意のプロキシインタフェース上の）の隣接エントリを作成します。パケットはマルチキャストですので、Pはサブネット上の他のすべてのプロキシインタフェースをNSアウトする必要があります。パケットアウトインタフェース2を送信する前に、SLLAオプションのリンク層アドレスを独自のリンク層アドレスP2に置き換える。
B receives this NS, processing it as usual. Hence it creates a neighbor entry for A mapping it to the link-layer address p2. It responds with a Neighbor Advertisement (NA) sent to A containing B's link-layer address b. The NA is sent using A's neighbor entry, i.e., to the link-layer address p2.
BはこのNSを受信し、通常どおり処理します。したがって、それはそれをリンク層アドレスP2にマッピングするための隣接エントリを作成する。Bのリンク層アドレスBを含む隣接アドバタイズメント（NA）で応答します。NAは、Aの隣接エントリを使用して、すなわちリンク層アドレスP2に送信される。
The NA is received by P, which then processes it as it would any unicast packet; i.e., it forwards this out interface 1, based on the neighbor cache. However, before actually sending the packet out, it inspects it to determine if the packet being sent is one that requires proxying. Since it is an NA, it updates its neighbor entry for B to be REACHABLE and records the link-layer address b. P then replaces the link-layer address in the TLLA option with its own link-layer address on the outgoing interface, p1. The packet is then sent out interface 1.
NAはPによって受信され、それはそれをユニキャストパケットとして処理する。すなわち、隣接キャッシュに基づいて、このアウトインタフェース1を転送する。ただし、実際にパケットを送信する前に、送信されているパケットがプロキシを必要とするものであるかどうかを判断するためにそれを検査します。NAであるため、Bの隣接エントリをBに到達可能に更新し、リンク層アドレスBを記録します。Pは、TLLAオプション内のリンク層アドレスを発信インターフェイスP1上の独自のリンク層アドレスに置き換えます。その後、パケットはインタフェース1に送信されます。
A receives this NA, processing it as usual. Hence it creates a neighbor entry for B on interface 2 in the REACHABLE state and records the link-layer address p1.
AはこのNAを受信し、通常どおり処理します。したがって、インタフェース2上のBの隣接状態でBに対する隣接エントリを作成し、リンク層アドレスP1を記録する。
An implementation MUST ensure that loops are prevented by using the P bit in RAs as follows. The proxy determines an "upstream" proxy interface, typically through a (zero-configuration) physical choice dictated by the scenario (see Scenarios 1 and 2 above), or through manual configuration. As described in Section 4.1.3.3, only the upstream interface is allowed to receive RAs, and never from other proxies. Proxy functionality is disabled on an interface otherwise. Finally, a proxy MUST wait until it has sent two P bit RAs on a given "downstream" interface before it enables forwarding on that interface.
実装は、次のようにRASのPビットを使用することによってループが防止されることを確実にする必要があります。プロキシは、通常、シナリオによって決定される（上記のシナリオ1と2を参照）、または手動構成を介して、通常、「アップストリーム」プロキシインタフェースを決定します。セクション4.1.3.3で説明されているように、アップストリームインターフェイスのみがRASを受信でき、他のプロキシからは絶対にしません。プロキシ機能は、それ以外の場合はインターフェイスで無効になっています。最後に、プロキシは、そのインターフェイス上の転送を可能にする前に、特定の「ダウンストリーム」インターフェイスに2つのPビットRASを送信するまで待機する必要があります。
Proxy developers will have to accommodate protocols or protocol options (for example, new ICMP messages) that are developed in the future, or protocols that are not mentioned in this document (for example, proprietary protocols). This section prescribes guidelines that can be used by proxy developers to accommodate protocols that are not mentioned herein.
プロキシ開発者は、将来開発されたプロトコルまたはプロトコルオプション（たとえば、新しいICMPメッセージなど）、またはこの文書に記載されていないプロトコルに対応する必要があります（たとえば、独自のプロトコルなど）。このセクションでは、本明細書に記載されていないプロトコルに対応するためにプロキシ開発者が使用できるガイドラインを規定しています。
1) If a link-layer address carried in the payload of the protocol can be used in the link-layer header of future messages, then the proxy should substitute it with its own address. For example, the link-layer address in NA messages is used in the link-layer header for future messages, and, hence, the proxy substitutes it with its own address.
1) プロトコルのペイロードで実行されているリンク層アドレスを将来のメッセージのリンクレイヤヘッダーで使用できる場合、プロキシはそれを独自のアドレスに置き換える必要があります。たとえば、NAメッセージ内のリンク層アドレスは、将来のメッセージのためにリンクレイヤヘッダーで使用され、したがって、プロキシはそれを独自のアドレスに置き換えます。
For multicast packets, the link-layer address substituted within the payload will be different for each outgoing interface.
マルチキャストパケットの場合、ペイロード内で置き換えられたリンク層アドレスは、発信インターフェイスごとに異なります。
2) If the link-layer address in the payload of the protocol will never be used in any link-layer header, then the proxy should not substitute it with its own address. No special actions are required for supporting these protocols. For example, [DHCPv6] is in this category.
2) プロトコルのペイロード内のリンクレイヤアドレスが任意のリンクレイヤヘッダーで使用されない場合、プロキシはそれを自身のアドレスに置き換えません。これらのプロトコルをサポートするために特別な行動は必要ありません。たとえば、[DHCPv6]はこのカテゴリにあります。
This document defines a new bit in the RA flags (the P bit). There is currently no registration procedure for such bits, so IANA should not take any action.
このドキュメントはRAフラグ（Pビット）の新しいビットを定義します。そのようなビットの登録手続きはありませんので、IANAは何らかの行動を起こさないでください。
Unsecured Neighbor Discovery has a number of security issues, which are discussed in detail in [PSREQ]. RFC 3971 [SEND] defines security mechanisms that can protect Neighbor Discovery.
無担保近隣探索には、いくつかのセキュリティ問題があります。これは[PSREQ]で詳しく説明されています。RFC 3971 [SEND]ネイバーディスカバリーを保護できるセキュリティメカニズムを定義します。
Proxies are susceptible to the same kind of security issues that plague hosts using unsecured Neighbor Discovery. These issues include hijacking traffic and denial-of-service within the subnet. Malicious nodes within the subnet can take advantage of this property, and hijack traffic. In addition, a Neighbor Discovery proxy is essentially a legitimate man-in-the-middle, which implies that there is a need to distinguish proxies from unwanted man-in-the-middle attackers.
プロキシは、安全でないネイバーディスカバリを使用してホストを専用にするのと同じ種類のセキュリティ問題の影響を受けやすいです。これらの問題には、サブネット内のHijacking TrafficとService of-Serviceが含まれます。サブネット内の悪意のあるノードは、このプロパティ、およびHijackトラフィックを利用できます。さらに、隣人探索プロキシは本質的に真ん中の中央であり、プロキシを望ましくないマン攻撃者から区別する必要があることを意味します。
This document does not introduce any new mechanisms for the protection of proxy Neighbor Discovery. That is, it does not provide a mechanism from authorizing certain devices to act as proxies, and it does not provide extensions to SEND to make it possible to use both SEND and proxies at the same time. We note that RFC 2461 [ND] already defines the ability to proxy Neighbor Advertisements, and extensions to SEND are already needed to cover that case, independent of this document.
この文書では、プロキシネイバーディスカバリを保護するための新しいメカニズムは導入されません。すなわち、特定のデバイスをプロキシとして機能させることができ、同時に送信とプロキシの両方を使用することを可能にするために送信する拡張機能を提供しません。RFC 2461 [ND]は、近隣の広告をプロキシする能力を既に定義しており、この文書とは無関係に、送信する拡張機能はすでにその場合カバーする必要があります。
Note also that the use of proxy Neighbor Discovery may render it impossible to use SEND both on the leaf subnet and on the external subnet. This is because the modifications performed by the proxy will invalidate the RSA Signature Option in a secured Neighbor Discovery message, and cause SEND-capable nodes to either discard the messages or treat them as unsecured. The latter is the desired operation when SEND is used together with this specification, and it ensures that SEND nodes within this environment can selectively downgrade themselves to unsecure Neighbor Discovery when proxies are present.
また、プロキシネイバーディスカバリの使用は、リーフサブネット上および外部サブネット上で両方を使用することを不可能にすることもできます。これは、プロキシによって実行された変更が確保されたネイバー検出メッセージでRSAシグネチャオプションを無効にし、送信可能なノードをメッセージを破棄したり、それらを無担保として処理したりするためです。後者はこの仕様と一緒に送信されたときの望ましい操作であり、プロキシが存在するときに、この環境内の送信ノードを選択的にダウングレードすることができます。
In the following, we outline some potential paths to follow when defining a secure proxy mechanism.
以下では、安全なプロキシメカニズムを定義するときに従う潜在的なパスを概説します。
It is reasonable for nodes on the leaf subnet to have a secure relationship with the proxy and to accept ND packets either from the owner of a specific address (normal SEND) or from a trusted proxy that it can verify (see below).
リーフサブネット上のノードがプロキシとの安全な関係を持ち、特定のアドレスの所有者からのNDパケット（通常の送信）または検証可能な信頼できるプロキシから受け入れることが合理的です（下記参照）。
For nodes on the external subnet, there is a trade-off between security (where all nodes have a secure relationship with the proxy) and privacy (where no nodes are aware that the proxy is a proxy). In the case of a point-to-point external link (Scenario 2), however, SEND may not be a requirement on that link.
外部サブネット上のノードの場合、セキュリティ間のトレードオフ（すべてのノードがプロキシとの安全な関係がある）とプライバシーがあります（ノードはプロキシがプロキシであることを認識していない場合）。ポイントツーポイント外部リンク（シナリオ2）の場合、送信はそのリンクの要件ではないかもしれません。
Verifying that ND packets come from a trusted proxy requires an extension to the SEND protocol and is left for future work [SPND], but is similar to the problem of securing Router Advertisements that is supported today. For example, a rogue node can send a Router Advertisement to cause a proxy to disable its proxy behavior, and hence cause denial-of-service to other nodes; this threat is covered in Section 4.2.1 of [PSREQ].
NDパケットが信頼できるプロキシから来ていることを確認するには、送信プロトコルの拡張が必要であり、将来の作業[SPND]のために残されていますが、今日サポートされているルーター広告を保護するという問題と似ています。たとえば、不正ノードでは、プロキシがそのプロキシ動作を無効にするためにプロキシを送信するようにルータアドバタイズメントを送信でき、したがって他のノードにサービスを拒否します。この脅威は[PSREQ]のセクション4.2.1で説明されています。
Alternative designs might involve schemes where the right for representing a particular host is delegated to the proxy, or where multiple nodes can make statements on behalf of one address [RINGSIG].
代替設計には、特定のホストを表す権利がプロキシに委任されている、あるいは複数のノードが1つのアドレス[Ringig]に代わってステートメントを作成できるスキームを含めることがあります。
The authors wish to thank Jari Arkko for contributing portions of the Security Considerations text.
著者は、セキュリティ上の考慮事項の一部を拠出するためにJari Arkkoに感謝します。
[BRIDGE] T. Jeffree, editor, "Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D, 2004, http://standards.ieee.org/ getieee802/download/802.1D-2004.pdf.
[ブリッジ] T.Jeffree、Editor、「メディアアクセス制御（Mac）Bridges」、ANSI / IEEE STD 802.1D、2004、http://standards.ieee.org/ getieee802 /ダウンロード/ 802.1d-2004.pdf。
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[ICMPv6] Conta、A.およびS.THERER、「インターネットプロトコルバージョン6（IPv6）仕様」の「インターネット制御メッセージプロトコル（ICMPv6）」、RFC 2463、1998年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S.、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[ND] Narten、T.、Nordmark、E.、およびW.Simpson、「IPバージョン6（IPv6）の隣接発見（IPv6）」、RFC 2461、1998年12月。
[NODEREQ] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294, April 2006.
[Nodereq] Loughney、J.、Ed。、「IPv6ノード要件」、RFC 4294、2006年4月。
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[6to4] Carpenter、B.およびK.ムーア、「IPv4雲を介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[BCP] Higashiyama, M., Baker, F., and T. Liao, "Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)", RFC 3518, April 2003.
[BCP]東山、M。、Baker、F.、およびT. Liao、「Point-Point Protocol（PPP）ブリッジング制御プロトコル（BCP）」、RFC 3518、2003年4月。
[DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[DHCPv6] DROM、R.、ED。、BAWE、VORZ、B、LEMON、T.、PERKINS、C、およびM.Carney、「IPv6の動的ホスト構成プロトコル（DHCPv6）」、RFC 33152003年7月。
[NAT] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT] SRISURESH、P.およびK. EGEVANG、「伝統的なIPネットワークアドレス翻訳者（伝統的なNAT）」、RFC 3022、2001年1月。
[PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[PD] Troan、O.およびR. DROMS、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション、RFC 3633、2003年12月。
[PSREQ] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[PSREQ]ニカンダー、P.、Kempf、J.、E. Nordmark、「IPv6 Noiby Discovery（ND）信頼モデルと脅威」、RFC 3756、2004年5月。
[RINGSIG] Kempf, J. and C. Gentry, "Secure IPv6 Address Proxying using Multi-Key Cryptographically Generated Addresses (MCGAs)", Work in Progress, August 2005.
[Ringsig] KEMPF、J.およびC. Gentry、「マルチキー暗号的に生成されたアドレス（McGAS）を使用したセキュアIPv6アドレスプロキシ（McGAS）」、2005年8月、進行中の作業。
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[送信] Arkko、J.、Ed。、Kempf、J.、Zill、B.、P. Nikander、「Secure Neight Discovery（Send）」、RFC 3971、2005年3月。
[SPND] Daley, G., "Securing Proxy Neighbour Discovery Problem Statement", Work in Progress, February 2005.
[SPND] Daley、G.、「プロキシネイバーディスカバリー問題宣言」、2005年2月の進行中の働き。
Appendix A: Comparison with Naive RA Proxy
付録A：Naive RAプロキシとの比較
It has been suggested that a simple Router Advertisement (RA) proxy would be sufficient, where the subnet prefix in an RA is "stolen" by the proxy and applied to a downstream link instead of an upstream link. Other ND messages are not proxied.
単純なルータ広告（RA）プロキシで十分であることが示唆されており、RA内のサブネットプレフィックスはプロキシによって「盗まれ、アップストリームリンクではなくダウンストリームリンクに適用している」と提案されている。他のNDメッセージはプロキシされていません。
There are many problems with this approach. First, it requires cooperation from all nodes on the upstream link. No node (including the router sending the RA) can have an address in the subnet or it will not have connectivity with nodes on the downstream link. This is because when a node on a downstream link tries to do Neighbor Discovery, and the proxy does not send the NS on the upstream link, it will never discover the neighbor on the upstream link. Similarly, if messages are not proxied during Duplicate Address Detection (DAD), conflicts can occur.
このアプローチには多くの問題があります。まず、アップストリームリンク上のすべてのノードからの協力が必要です。ノード（RAを送信するルータを含む）はサブネット内のアドレスを持つことも、ダウンストリームリンク上のノードと接続されません。ダウンストリームリンク上のノードがネイバーディスカバリを実行しようとすると、プロキシがアップストリームリンク上のNSを送信しないため、アップストリームリンク上のネイバーを検出することはありません。同様に、重複アドレス検出（DAD）中にメッセージがプロキシされていない場合、競合が発生する可能性があります。
Second, if the proxy assumes that no nodes on the upstream link have addresses in the prefix, such a proxy could not be safely deployed without cooperation from the network administrator since it introduces a requirement that the router itself not have an address in the prefix. This rules out use in situations where bridges and Network Address Translators (NATs) are used today, which is the problem this document is directly addressing. Instead, where a prefix is desired for use on one or more downstream links in cooperation with the network administrator, Prefix Delegation [PD] should be used instead.
第2に、プロキシが上流リンク上のノードが接頭辞にアドレスを持っていないと仮定している場合、そのようなプロキシはネットワーク管理者からの協力なしに安全にデプロイされていない可能性があるため、ルータ自身がプレフィックス内のアドレスを持たないという要件を導入できます。この文書が直接アドレス指定されている問題である問題は、ブリッジとネットワークアドレストランスファー（NAT）が使用されている状況で使用します。代わりに、ネットワーク管理者と協働して1つ以上のダウンストリームリンクでの使用に望まれる場合、代表的なプレフィックス委任[PD]を使用する必要があります。
Authors' Addresses
著者の住所
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Dave Thaler Microsoft Corporation 1つのMicrosoft Way Redmond、WA 98052-6399
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Mohit Talwar Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Mohit Talwar Microsoft Corporation 1つのMicrosoft Way Redmond、WA 98052-6399
Phone: +1 425 705 3131
EMail: mohitt@microsoft.com
Chirayu Patel All Play, No Work Bangalore, Karnataka 560038
Chirayu Patel All Play、ワークなしBangalore、Karnataka 560038
Phone: +91-98452-88078
EMail: chirayu@chirayu.org
Full Copyright Statement
完全著作権宣言
Copyright (C) The Internet Society (2006).
著作権（c）インターネット社会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれている権利、ライセンス、制限の対象となり、その中に述べた場合を除き、著者らはすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書と本明細書に含まれる情報は、「現状のまま」基準で提供されており、投稿者、または（いずれかの場合）、インターネット社会とインターネットエンジニアリングのタスクフォースがすべての保証を損なう、または本明細書における情報の使用が、特定の目的のためのあらゆる権利または黙示の保証を侵害しないことを含むがこれらに限定されないが、これに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
この文書に記載されているテクノロジの実装または使用に関連すると主張される可能性がある、またはそのような権利の下でのライセンスの使用に関連すると主張される可能性がある、またはその他の権利の下にある範囲内である可能性がある、またはその他の権利の使用に関連すると主張する可能性がある、IETFは、IETFを取りません。利用可能です。そのような権利を特定するためにそれが独立した努力をしたことを表していません。RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局へのIETF事務局と利用可能なライセンスの保証のコピー、またはこの仕様書の実装者や利用者による一般的なライセンスまたは許可を得るための試みの結果を得ることができます。IETFオンラインIPRリポジトリからhttp://www.ietf.org/ipr。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、著作権、特許または特許出願、またはこの規格を実装することが要求される可能性がある技術をカバーする可能性のある他の独自の権利を注意を及ぼすように興味のある当事者を勧めます。ietf-ipr@ietf.orgのIETFに情報を宛先に宛ててください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。