Network Working Group JH. Choi
Request for Comments: 4135 Samsung AIT
Category: Informational G. Daley
CTIE Monash University
August 2005
Goals of Detecting Network Attachment in IPv6
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid. During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment (DNA). DNA schemes should be precise, sufficiently fast, secure, and of limited signaling.
ホストが新しいリンク層接続を確立するとき、それは、またはインターネット接続のための有効なIP構成があってもなくてもよいです。ホストはリンク変更（すなわち、リンクの変更が発生したかどうかを判断する）をチェックして、次に、その結果に基づいて、それが自動的にIP設定がまだ有効であるかどうかを決定することができます。リンクアイデンティティ検出時には、ホストは、IPサブネットが変更された場合は、新しいIPの設定を開始するのに必要な情報を収集することができます。このメモでは、この手順は、ネットワーク接続検出（DNA）と呼ばれています。 DNAスキームは、正確な十分に速い、安全な、そして限られたシグナリングであるべきです。
Table of Contents
目次
1. Introduction ....................................................2
2. Problems in Detecting Network Attachment ........................3
2.1. Wireless Link Properties ...................................3
2.2. Link Identity Detection with a Single RA ...................3
2.3. Delays .....................................................4
3. Goals for Detecting Network Attachment ..........................5
3.1. Goals List .................................................6
4. Security Considerations .........................................6
5. Acknowledgements ................................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
When a host has established a new link-layer connection, it can send and receive some IPv6 packets on the link, including those used for configuration. On the other hand, the host has Internet connectivity only when it is able to exchange packets with off-link destinations.
ホストが新しいリンク層接続を確立している場合は、設定のために使用されるものを含む、リンクの上にいくつかのIPv6パケットを送受信することができます。一方、ホストは、オフリンク先でパケットを交換することが可能である場合にのみ、インターネットに接続されています。
When a link-layer connection is established or re-established, the host may not know whether its existing IP configuration is still valid for Internet connectivity. A subnet change might have occurred when the host changed its point of attachment.
リンク層接続が確立または再確立されると、ホストは、その既存のIP設定は、まだインターネット接続のために有効であるかどうか知らないかもしれません。ホストが接続点を変更したときに、サブネットの変更が発生した可能性があります。
In practice, the host doesn't know which of its addresses are valid on the newly attached link. It also doesn't know whether its existing default router is on this link or whether its neighbor cache entries are valid. Correct configuration of each of these components is necessary in order to send packets on and off the link.
実際には、ホストは、新たに接続したリンク上で有効なそのアドレスのどちらかを知りません。また、既存のデフォルトルータがこのリンク上にあるかどうか、その近隣キャッシュエントリが有効であるかどうか分かりません。これらの成分の各々の正確な構成は、リンクのオンとオフパケットを送信するために必要です。
To examine the status of the existing configuration, a host may check whether a 'link change' has occurred. In this document, the term 'link' is as defined in RFC 2461 [1]. The notion 'link' is not identical with the notion 'subnet', as defined in RFC 3753 [2]. For example, there may be more than one subnet on a link, and a host connected to a link may be part of one or more of the subnets on the link.
既存の設定の状態を調べるために、ホストは、「リンクの変更が」発生したかどうかをチェックします。この文書では、用語「リンク」は、RFC 2461で定義された通りである[1]。 RFC 3753で定義されている概念「リンク」は、概念「サブネット」と同一ではない[2]。例えば、そこにリンク上の複数のサブネットとすることができ、リンクに接続されたホストは、リンク上のサブネットのうちの1つまたは複数の一部であってもよいです。
Today, a link change necessitates an IP configuration change. Whenever a host detects that it has remained at the same link, it can usually assume its IP configuration is still valid. Otherwise, the existing one is no longer valid, and a new configuration must be acquired. Therefore, to examine the validity of an IP configuration, all that is required is that the host checks for link change.
今日では、リンクの変更は、IPの設定変更が必要となります。ホストはそれが同じリンクで推移していることを検出するたびに、それは通常、そのIP設定がまだ有効であると仮定することができます。それ以外の場合は、既存のものは、もはや有効ではない、新しいコンフィギュレーションを取得する必要があります。そのため、IP設定の妥当性を検討するために、必要とされるすべては、リンク変更のためのホストチェックということです。
In the process of checking for link change, a host may collect some of the necessary information for a new IP configuration, such as on-link prefixes. So, when an IP subnet change has occurred, the host can immediately initiate the process of getting a new IP configuration. This may reduce handoff delay and minimize signaling.
リンク変更をチェックする過程では、ホストは、オンリンクプレフィックスとして、新しいIPの設定に必要な情報の一部を収集することがあります。 IPサブネットの変更が発生したときに、ホストは、すぐに新しいIP設定を取得するプロセスを開始することができます。これは、ハンドオフ遅延を低減し、シグナリングを最小限にすることができます。
Rapid attachment detection is required for a device that changes subnet while having on-going sessions. This may be the case if a host is connected intermittently, is a mobile node, or has urgent data to transmit upon attachment to a link.
迅速な装着検出は、進行中のセッションを有しながらサブネットを変更するデバイスのために必要とされます。ホストが断続的に接続されている場合、このような場合であってもよいし、モバイルノードであるか、またはリンクへの取り付け時に送信する緊急データを有しています。
Detecting Network Attachment (DNA) is the process by which a host collects the appropriate information and detects the identity of its currently attached link to ascertain the validity of its IP configuration.
ネットワークアタッチメント（DNA）を検出すると、ホストは、適切な情報を収集し、そのIP構成の妥当性を確認するために、その現在接続されているリンクのアイデンティティを検出するプロセスです。
DNA schemes are typically run per interface. When a host has multiple interfaces, the host separately checks for link changes on each interface.
DNAのスキームは、典型的インターフェイスごとに実行されます。ホストが複数のインタフェースを有する場合、ホストは、別々に各インタフェースのリンクの変更をチェックします。
It is important to note that DNA process does not include the actual IP configuration procedure. For example, with respect to DHCP, the DNA process may determine that the host needs to get some configuration information from a DHCP server. However, the process of actually retrieving the information from a DHCP server falls beyond the scope of DNA.
DNAプロセスは、実際のIPの設定手順が含まれていないことに注意することが重要です。例えば、DHCPに対して、DNAプロセスは、ホストがDHCPサーバからいくつかの構成情報を取得する必要があると判断してもよいです。しかし、実際にはDHCPサーバから情報を取得するプロセスは、DNAの範囲を超えて落ちます。
This document considers the DNA procedure only from the IPv6 point of view, unless explicitly mentioned otherwise. Thus, the term "IP" is to be understood to denote IPv6, by default. For the IPv4 case, refer to [7].
明示的に言及しない限り、このドキュメントは、表示のみのIPv6のポイントからDNA手順を検討します。したがって、用語「IP」は、デフォルトでは、IPv6を意味すると理解されるべきです。 IPv4のケースのために、[7]を参照。
A number of issues make DNA complicated. First, wireless connectivity is not as clear-cut as wired connectivity. Second, it's difficult for a single Router Advertisement (RA) message to indicate a link change. Third, the current Router Discovery specification specifies that routers wait a random delay of 0-.5 seconds prior to responding with a solicited RA. This delay can be significant and may result in service disruption.
多くの問題は、DNAが複雑にします。まず、ワイヤレス接続は、として明確な有線接続のようではありません。第二に、それはリンクの変更を示すために、単一のルータ広告（RA）メッセージのために困難です。第三に、現在のルータ発見仕様では、ルータが前に募集RAで応答に0から0.5秒のランダム遅延を待つことを指定します。この遅延は重要なことができ、サービスの中断をもたらすことができます。
Unlike in wired environments, what constitutes a wireless link is variable both in time and space. Wireless links do not have clear boundaries. This may be illustrated by the fact that a host may be within the coverage area of multiple (802.11) access points at the same time. Moreover, connectivity on a wireless link can be very volatile, which may make link identity detection hard. For example, it takes time for a host to check for link change. If the host ping-pongs between two links and doesn't stay long enough at a given link, it can't complete the DNA procedure.
有線環境とは異なり、どのような無線リンクを構成することは、時間と空間の両方の変数です。無線リンクは明確な境界を持っていません。これは、ホストが同時に複数（802.11）アクセスポイントのカバレッジエリア内であってもよいという事実によって説明することができます。また、無線リンクの接続性は、リンクのアイデンティティの検出が困難にする可能性がある、非常に揮発することができます。例えば、それはリンクの変更を確認するためにホストのための時間を要します。 2つのリンクとの間で、ホストのping-pongsが与えられたリンクで十分に長く滞在していない場合、それはDNAの手続きを完了することはできません。
Usually, a host gets the information necessary for IP configuration from RA messages. Based on the current definition [1], it's difficult for a host to check for link change upon receipt of a single RA.
通常、ホストは、RAメッセージからIP構成に必要な情報を取得します。ホストは、単一のRAを受信すると、リンクの変更をチェックするために現在の定義[1]に基づいて、それは難しいです。
To detect link identity, a host may compare the information in an RA, such as router address or prefixes, with the locally stored information.
リンクIDを検出するために、ホストは、ローカルに格納された情報を用いて、そのようなルータのアドレス又はプレフィックスとして、RA内の情報を比較することができます。
The host may use received router addresses to check for link change. The router address in the source address field of an RA is of link-local scope, however, so its uniqueness is not guaranteed outside a link. If it happens that two different router interfaces on different links have the same link-local address, the host can't detect that it has moved from one link to another by checking the router address in RA messages.
ホストはリンク変更を確認するために受信したルータのアドレスを使用することができます。その独自性は、リンクの外に保証するものではありませんので、RAの送信元アドレスフィールドにルータアドレスは、しかし、リンクローカルスコープです。それは異なるリンク上の2つの異なるルータインターフェイスは、同じリンクローカルアドレスを持っていることを発生した場合、ホストはRAメッセージ内のルータアドレスをチェックすることによって、別のリンクから移動したことを検出することはできません。
The set of all global prefixes assigned to a link can represent link identity. The host may compare the prefixes in an incoming RA with the currently stored ones. An unsolicited RA message, however, can omit some prefixes for convenience [1], and it's not easy for a host to attain and retain all the prefixes on a link with certainty. Therefore, neither the absence of a previously known prefix nor the presence of a previously unknown prefix in the RA guarantees that a link change has occurred.
リンクに割り当てられたすべてのグローバルプレフィックスのセットは、リンクのアイデンティティを表現することができます。ホストは、現在保存されているものと入ってくるRAでプレフィックスを比較することができます。迷惑RAメッセージは、しかし、利便[1]のためのいくつかの接頭辞を省略することができ、そしてホストが到達し、確実にリンク上のすべてのプレフィックスを保持することは簡単ではありません。そのため、以前から知られている接頭辞がない場合もRAで以前に未知のプレフィックスの存在でもないが、リンクの変更が発生していることを保証します。
The following issues cause DNA delay that may result in communication disruption.
次の問題は、通信途絶をもたらすことができるDNAの遅延を引き起こします。
1) Delay for receiving a hint
1）ヒントを受信するための遅延
A hint is an indication that a link change might have occurred. This hint itself doesn't confirm a link change, but initiates appropriate DNA procedures to detect the identity of the currently attached link.
ヒントは、リンクの変更が発生している可能性があることを示すものです。このヒント自体は、リンクの変更を確認しますが、現在接続されているリンクのアイデンティティを検出するために、適切なDNAの手続きを開始しません。
Hints come in various forms and differ in how they indicate a possible link change. They can be link-layer event notifications [6], the lack of RA from the default router, or the receipt of a new RA. The time taken to receive a hint also varies.
ヒントは、様々な形で来て、彼らは可能なリンクの変更を示す方法が異なります。彼らは、[6]デフォルトルータからのRAの欠如、または新規RAの受信リンク層イベント通知することができます。ヒントを受信するのにかかる時間も変化します。
As soon as a new link-layer connection has been made, the link layer may send a link-up notification to the IP layer. A host may interpret the new link-layer connection as a hint for a possible link change. With link-layer support, a host can receive such a hint almost instantly.
すぐに新しいリンク層接続が行われたとして、リンク層はIP層にリンクアップ通知を送信することができます。ホストは、可能なリンク変更のためのヒントとして、新しいリンク層接続を解釈することがあります。リンクレイヤのサポートにより、ホストは、ほぼ瞬時に、このようなヒントを受け取ることができます。
Mobile IPv6 [4] defines the use of RA Interval Timer expiry for a hint. A host keeps monitoring for periodic RAs and interprets the lack of them as a hint. It may implement its own policy to determine the number of missing RAs needed to interpret that as a hint. Thus, the delay depends on the Router Advertisement interval.
モバイルIPv6 [4]ヒントのためのRAインターバルタイマ満了の使用を規定します。ホストは、定期的なRAのための監視を続けると、ヒントとしてそれらの欠如を解釈します。これは、RASがヒントとしてそれを解釈するために必要な行方不明の数を決定するために、独自の政策を実施することができます。このように、遅延は、ルータ広告間隔に依存します。
Without schemes such as those above, a host must receive a new RA from a new router to detect a possible link change. The detection time then also depends on the Router Advertisement frequency.
例えば上のスキームたものなどがなければ、ホストは、可能なリンクの変更を検出するために、新しいルータから新しいRAを受けなければなりません。検出時間は、その後も、ルータ広告の周波数に依存します。
Periodic RA beaconing transmits packets within an interval varying randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds. Because a network attachment is unrelated to the advertisement time on the new link, hosts are expected to arrive, on average, halfway through the interval. This is approximately 1.75 seconds with Neighbor Discovery [1] advertisement rates.
周期的RAビーコンはMaxRtrAdvInterval秒MinRtrAdvInterval間でランダムに変化する間隔内にパケットを送信します。ネットワーク接続は、新しいリンク上の広告時間には無関係であるため、ホストは、途中区間を通じて、平均して、到着すると予想されます。これは、近隣探索[1]広告速度で約1.75秒です。
2) Random delay execution for RS/RA exchange
RS / RA交換用2）ランダム遅延実行
Router Solicitation and Router Advertisement messages are used for Router Discovery. According to [1], it is sometimes necessary for a host to wait a random amount of time before it may send an RS, and for a router to wait before it may reply with an RA.
ルータ要請およびルータ広告メッセージは、ルータ検出のために使用されています。ホストはそれがRSを送信することが前にランダムな時間を待って、それはRAで応答することができる前に待機するルータのためにするために、[1]によると、それは時には必要です。
According to RFC 2461 [1], the following apply:
RFC 2461によれば、[1]、以下が適用されます。
- Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY (1 second).
- ホストが最初の要請を送る前に、それは0とMAX_RTR_SOLICITATION_DELAY（1秒）の間のランダムな時間の送信を遅延させるべきです。
- Furthermore, any RA sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 seconds).
- さらに、ルータ要請に応答して送信されたRAは、0とMAX_RA_DELAY_TIME（0.5秒）の間のランダムな時間だけ遅延させなければなりません。
The DNA working group has been chartered to define an improved scheme for detecting IPv6 network attachment. In this section, we define the goals that any such solution should aim to fulfill.
DNAワーキンググループは、IPv6ネットワーク接続を検出するための改良されたスキームを定義するために結成されました。このセクションでは、どのような解決策を満たすために目指すべき目標を定義します。
DNA solutions should correctly determine whether a link change has occurred. Additionally, they should be sufficiently fast so that there would be no or at most minimal service disruption. They should neither flood the link with related signaling nor introduce new security holes.
DNAソリューションは、正しくリンク変更が生じたかどうかを決定する必要があります。何か、せいぜい最小限のサービスの中断はないであろうように、また、彼らは十分に高速である必要があります。彼らは、関連するシグナリングとのリンクをあふれさせることも、新しいセキュリティホールを導入すべきでもありません。
When defining new solutions, it is necessary to investigate the usage of available tools, Neighbor Solicitation/Neighbor Advertisement messages, RS/RA messages, link-layer event notifications [6], and other features. This will allow precise description of procedures for efficient DNA Schemes.
新しいソリューションを定義するとき、利用可能なツール、近隣要請/近隣広告メッセージ、RS / RAメッセージ、リンク層イベント通知[6]、およびその他の機能の使用状況を調査する必要があります。これは、効率的なDNAスキームの手順の正確な記述を可能にします。
G1 DNA schemes should detect the identity of the currently attached link to ascertain the validity of the existing IP configuration. They should recognize and determine whether a link change has occurred and initiate the process of acquiring a new configuration if necessary.
G1 DNAスキームは、既存のIP設定の妥当性を確認するために現在接続されているリンクのアイデンティティを検出する必要があります。彼らは認識して、リンクの変更が発生したかどうかを判断し、必要に応じて新しいコンフィギュレーションを取得する処理を開始する必要があります。
G2 DNA schemes should detect the identity of an attached link with minimal latency lest there should be service disruption.
サービスの中断があるはずないようG2 DNAスキームは、最小の待ち時間が取り付けられたリンクのIDを検出しなければなりません。
G3 If a host has not changed a link, DNA schemes should not falsely assume a link change, and an IP configuration change should not occur.
G3ホストがリンクを変更していない場合は、DNAのスキームは、誤ってリンク変更を想定してはならない、とIPの構成変更が発生しません。
G4 DNA schemes should not cause undue signaling on a link.
G4 DNAスキームは、リンクに過度のシグナリングが発生することはありません。
G5 DNA schemes should make use of existing signaling mechanisms where available.
G5 DNAスキームが使用可能な既存のシグナル伝達機構を利用する必要があります。
G6 DNA schemes should make use of signaling within the link (particularly link-local scope messages), because communication off-link may not be achievable in the case of a link change.
オフ・リンク通信リンクの変更の場合には達成できない可能性があるため、G6 DNA方式は、リンク（特にリンクローカルスコープのメッセージ）内シグナリングを利用するべきです。
G7 DNA schemes should be compatible with security schemes such as Secure Neighbor Discovery [3].
G7 DNA方式は、セキュア近隣探索などのセキュリティ方式[3]と適合性であるべきです。
G8 DNA schemes should not introduce new security vulnerabilities. The node supporting DNA schemes should not expose itself or other nodes on a link to additional man-in-the-middle, identity-revealing, or denial-of-service attacks.
G8 DNAスキームは、新しいセキュリティの脆弱性を導入してはなりません。ノード支持DNAスキームは、追加のman-in-the-middle、アイデンティティ現出、またはサービス拒否攻撃へのリンクを、それ自体または他のノードを公開しないでください。
G9 Nodes (such as routers or hosts) that support DNA schemes should work appropriately with unmodified nodes that do not.
DNAスキームをサポートする（例えばルータまたはホストなど）G9ノードはない未修飾ノードと適切に動作するはずです。
G10 Hosts, especially in wireless environments, may perceive routers reachable on different links. DNA schemes should take into consideration the case where a host is attached to more than one link at the same time.
特に無線環境でのG10のホストは、異なるリンク上の到達可能なルータを認識することがあります。 DNA手法を考慮にホストが同時に複数のリンクに接続されている場合を取る必要があります。
The DNA process is intimately related to the Neighbor Discovery protocol [1] and its trust model and threats have much in common with those presented in RFC 3756 [5]. Nodes connected over wireless interfaces may be particularly susceptible to jamming, monitoring, and packet-insertion attacks.
DNAプロセスは、近隣探索プロトコルに密接に関連している[1]とその信頼モデルと脅威[5] RFC 3756に提示されたものと共通点が多いです。無線インタフェースを介して接続されたノードがジャミング、モニタリング、およびパケット挿入攻撃に対して特に感受性であり得ます。
With unsecured DNA schemes, it is inadvisable for a host to adjust its security based on which network it believes it is attached to. For example, it would be inappropriate for a host to disable its personal firewall because it believed that it had connected to a home network.
ホストはそれが接続されていると考えているネットワークに基づいてセキュリティを調整するための無担保DNAスキームで、それはお勧めできません。それは、ホームネットワークに接続されていたことを信じているので、例えばそれは、そのパーソナルファイアウォールを無効にするホストのために不適切です。
Even in the case where authoritative information (routing and prefix state) are advertised, wireless network attackers may still prevent soliciting nodes from receiving packets. This may cause unnecessary IP configuration change in some devices. Such attacks may be used to make a host preferentially select a particular configuration or network access.
信頼できる情報（ルーティングおよびプレフィックス状態）が通知される場合であっても、無線ネットワークの攻撃者は依然としてパケットを受信ノードから勧誘防止することができます。これは、一部のデバイスでは、不要なIP構成の変更が発生することがあります。このような攻撃は、ホストが優先的に特定の構成やネットワークへのアクセスを選択するために使用することができます。
Devices receiving confirmations of reachability (for example, from upper-layer protocols) should be aware that unless these indications are sufficiently authenticated, reachability may falsely be asserted by an attacker. Similarly, even if such reachability tests are known to originate from a trusted source, they should be ignored for reachability confirmation if the packets are not fresh or have been replayed. This may reduce the effective window for attackers replaying otherwise authentic data.
到達可能性の確認を受信する装置は、（例えば、上位層プロトコルからの）これらの指示を十分に認証されない限り、到達可能性を誤って攻撃者によってアサートされてもよいことに注意すべきです。そのような到達可能性テストは信頼できるソースから発生することが知られている場合でも、パケットが新鮮ではないか、再生された場合は同様に、彼らが到達可能性確認のために無視されるべきです。これは、そうでない場合は、本物のデータを再生する攻撃者のための効果的なウィンドウを減らすことができます。
It may be dangerous to receive link-change notifications from the link layer and network layer, if they are received from devices that are insufficiently authenticated. In particular, notifications that authentication has completed at the link layer may not imply that a security relationship is available at the network layer. Additional authentication may be required at the network layer to justify modification of IP configuration.
彼らが十分に認証されているデバイスから受信している場合は、リンク層とネットワーク層からリンク変更通知を受信するのは危険かもしれません。特に、認証はリンク層で完了した通知は、セキュリティの関係はネットワーク層で利用可能であることを意味するものではないかもしれません。追加の認証は、IP設定の変更を正当化するために、ネットワーク層で必要になることがあります。
Erik Nordmark has contributed significantly to work predating this document. Also Ed Remmell's comments on the inconsistency of RA information were most illuminating. The authors wish to express our appreciation to Pekka Nikander for valuable feedback. We gratefully acknowledge the generous assistance we received from Shubhranshu Singh for clarifying the structure of the arguments. Thanks to Brett Pentland, Nick Moore, Youn-Hee Han, JaeHoon Kim, Alper Yegin, Jim Bound, and Jari Arkko for their contributions to this document.
エリックNordmarkとは、この文書をより以前の仕事に大きく貢献してきました。また、RA情報の矛盾にエドRemmellのコメントは、ほとんどの照明されました。著者は、貴重なフィードバックのためのペッカNikanderに感謝の意を表したいです。我々は感謝し、我々は、引数の構造を明確にするためShubhranshuシンから受信した寛大な支援を認めます。このドキュメントへの貢献のためのブレット・ペントランド、ニック・ムーア、ユン・喜漢、JaeHoonキム、アルパースYegin、ジム・バウンド、及びヤリArkkoに感謝します。
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[1] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 2461、1998年12月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[2]のようにして、J.とM.古城、 "モビリティ関連用語"、RFC 3753、2004年6月。
[3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[3] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikanderを、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[4]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[5] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[5] Nikander、P.、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、RFC 3756、2004年5月。
[6] Yegin, A., "Link-layer Event Notifications for Detecting Network Attachments", work in progress, July 2005.
[6] Yegin、A.、「検出ネットワーク添付ファイルのリンク層イベント通知」、進行中の作業、2005年7月。
[7] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", work in progress, June 2005.
[7] Aboba、B.、 "検出するネットワーク接続IPv4の（DNA）"、進行中の作業2005年6月。
Authors' Addresses
著者のアドレス
JinHyeock Choi Samsung AIT Communication & N/W Lab P.O.Box 111 Suwon 440-600 KOREA
JinHyeockチェ・サムスンAITコミュニケーション＆N / WラボP.O.Box 111水原440から600 KOREA
Phone: +82 31 280 9233 EMail: jinchoe@samsung.com
電話：+82 31 280 9233 Eメール：jinchoe@samsung.com
Greg Daley CTIE Monash University Centre for Telecommunications and Information Engineering Monash University Clayton 3800 Victoria Australia
電気通信のためのグレッグデイリーCTIEモナッシュ大学センター情報工学モナッシュ大学クレイトン3800ビクトリアオーストラリア
Phone: +61 3 9905 4655 EMail: greg.daley@eng.monash.edu.au
電話：+61 3 9905 4655 Eメール：greg.daley@eng.monash.edu.au
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。