[要約] RFC 4135は、IPv6ネットワークへの接続を検出するための目標を定義しています。要約すると、IPv6ネットワークへの接続を自動的に検出し、適切なアクションを実行することが目的です。
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
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).
Copyright（c）The Internet Society（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構成がまだ有効かどうかを自動的に決定できます。リンクIDの検出中、ホストは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）は、ホストが適切な情報を収集し、現在添付されているリンクのIDを検出するプロセスであり、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〜.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）アクセスポイントのカバレッジエリア内に同時にある可能性があるという事実によって説明できます。さらに、ワイヤレスリンクの接続性は非常に揮発性である可能性があり、リンクIDの検出が難しくなる可能性があります。たとえば、ホストがリンクの変更をチェックするには時間がかかります。ホストPingが2つのリンクの間でPing-Pongを使用し、特定のリンクで十分に長く留まらない場合、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構成に必要な情報を取得します。現在の定義[1]に基づいて、ホストが単一のRAを受け取ったときにリンクの変更をチェックすることは困難です。
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.
リンクに割り当てられたすべてのグローバルプレフィックスのセットは、リンクIDを表すことができます。ホストは、着信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.
ヒントは、リンクの変更が発生した可能性があることを示しています。このヒント自体はリンクの変更を確認しませんが、現在添付されているリンクのIDを検出するための適切な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の監視を続け、それらの欠如をヒントとして解釈します。それをヒントとして解釈するために必要な不足しているRAの数を決定するための独自のポリシーを実装する場合があります。したがって、遅延はルーター広告間隔に依存します。
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ビーコンは、Minrtradvintervalからmaxrtradvintervalの秒間にランダムに異なる間隔内でパケットを送信します。ネットワークの添付ファイルは新しいリンクの広告時間とは無関係であるため、ホストは平均して間隔の途中で到着すると予想されます。これは、近隣発見[1]広告レートで約1.75秒です。
2) Random delay execution for RS/RA exchange
2) RS/RA交換のランダム遅延実行
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.
ルーターの勧誘とルーターの広告メッセージは、ルーターの発見に使用されます。[1]によると、ホストがRSを送信する前にランダムな時間を待つ必要がある場合があり、RAで返信する前にルーターが待機する必要があります。
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_SOLITITION_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構成の有効性を確認するために、現在添付されているリンクのIDを検出する必要があります。リンクの変更が発生したかどうかを認識して決定する必要があり、必要に応じて新しい構成を取得するプロセスを開始する必要があります。
G2 DNA schemes should detect the identity of an attached link with minimal latency lest there should be service disruption.
G2 DNAスキームは、サービスの混乱がある必要がないように、最小限のレイテンシで接続されたリンクのアイデンティティを検出する必要があります。
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スキームは、Secure Neighbor Discovery [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スキームをサポートするノードは、追加の中間者、アイデンティティを改革する、またはサービス拒否攻撃へのリンクでそれ自体または他のノードを公開してはなりません。
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]に密接に関連しており、その信頼モデルと脅威はRFC 3756 [5]に提示されたものと多くの共通点があります。ワイヤレスインターフェイスで接続されているノードは、ジャミング、監視、およびパケット挿入攻撃の影響を特に受けやすい場合があります。
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.
Erik Nordmarkは、このドキュメントの前に作業に大きく貢献しています。また、RA情報の矛盾に関するEd Remmellのコメントは、最も照らされていました。著者は、貴重なフィードバックについてPekka Nikanderに感謝の気持ちを表明したいと考えています。議論の構造を明確にしたことで、シュブランシュ・シンから受けた寛大な支援に感謝します。ブレット・ペントランド、ニック・ムーア、ヤング・ヒー・ハン、ジェフーン・キム、アルパー・イギン、ジム・バウンド、ジャリ・アークコに感謝します。
[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. Simpson、「IPバージョン6の近隣発見（IPv6）」、RFC 2461、1998年12月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[2] Mather、J。およびM. Kojo、「Mobility関連用語」、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.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[4] Johnson、D.、Perkins、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.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trustモデルと脅威」、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 Choi Samsung Ait Communication＆n/w lab p.o.box 111 Suwon 440-600 Korea
Phone: +82 31 280 9233
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。