この文書はRFC4135の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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).
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.
ホストが新しいリンクレイヤ接続を確立するとき、インターネット接続性の
ために正当なＩＰ設定を持つかもしれません、あるいはしないかもしれませ
ん。ホストはリンク変更を調べるかもしれません（すなわち、リンク変更が
起こったかどうか決定するかもしれません）、そして結果に基づいて自動的
にＩＰ設定がまだ有効かどうか決めることができます。リンク識別子検出の
間に、もしＩＰサブネットが変化した場合、ホストは新しいＩＰ設定を始め
るために必要な情報を集めるかもしれません。このメモで、この手順はネッ
トワーク接続検出（ＤＮＡ）と呼ばれます。ＤＮＡ体系は正確で、十分に高
速で、安全で、信号が限定されているべきです。
Table of Contents
目次
1. Introduction
1. はじめに
2. Problems in Detecting Network Attachment
2. ネットワーク接続検出の問題
2.1. Wireless Link Properties
2.1. 無線リンクの特性
2.2. Link Identity Detection with a Single RA
2.2. 単一ＲＡでのリンク識別子発見
2.3. Delays
2.3. 遅延
3. Goals for Detecting Network Attachment
3. ネットワーク接続検出の目標
3.1. Goals List
3.1. 目標リスト
4. Security Considerations
4. セキュリティの考察
5. Acknowledgements
5. 謝辞
6. References
6. 参考文献
6.1. Normative References
6.1. 参照する参考文献
6.2. Informative References
6.2. 有益な参考文献
Authors' Addresses
著者のアドレス
Full Copyright Statement
著作権表示全文
1. Introduction
1. はじめに
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.
ホストが新しいリンクレイヤ接続を確立したとき、設定に使われるパケット
を含め、リンク上であるＩＰｖ６パケットの送受信ができます。他方、パケッ
トをリンク外の宛先と交換可能であるときだけ、ホストはインターネット接
続性を持ちます。
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.
リンクレイヤ接続が確立されるか、あるいは再確立されるとき、ホストは既
存のＩＰ設定がインターネット接続性のためにまだ有効であるかどうか知ら
ないかもしれません。ホストが接続点を変えたとき、サブネットの変更が起
こったかもしれません。
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.
既存の設定の状況を調べるために、ホストが「リンク変更」が起こったかど
うか調べるかもしれません。この文書で、用語「リンク」はＲＦＣ２４６１
[1]で定義される通りです。ＲＦＣ３７５３[2]で［定義したように、「リン
ク」の概念は「サブネット」の概念とまったく同じではありません。例えば、
リンク上に複数のサブネットがあるかもしれず、リンクに接続したホストは
リンク上の複数のサブネットの一部であるかもしれません。
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.
今日、リンク変更はＩＰ設定変更を必要とします。ホストは同じリンクに残
留していると感じ取るときは、通常、そのＩＰ設定がまだ有効であると想定
することができます。さもなければ、既存の設定は無効で、新しい設定が獲
得されなくてはなりません。従って、ＩＰ設定の有効性を調べるために必要
なのは、ホストがリンク変更を調べることです。
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.
リンク変更を調べる過程で、リンクプレフィックスの様な、ホストが新しい
ＩＰ設定のための必要なある情報を集めるかもしれません。それで、ＩＰサ
ブネット変更が起こったとき、ホストはすぐに新しいＩＰ設定を得る処理を
始めることができます。これはハンドオフの遅れを減らし、信号を最小にす
るかもしれません。
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 schemes are typically run per interface. When a host has
multiple interfaces, the host separately checks for link changes on
each interface.
ＤＮＡは一般にインタフェース毎に行なわれます。ホストが多数のインタ
フェースを持つとき、ホストはそれぞれのインタフェース上で個別にリンク
変更を調べます。
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.
ＤＮＡ過程が実際のＩＰ設定手順を含まないことを指摘することは重要です。
例えば、ＤＨＣＰに関して、ＤＮＡ過程はホストがＤＨＣＰサーバから若干
の設定情報を手に入れる必要があると決定するかもしれません。しかしなが
ら、ＤＨＣＰサーバから実際に情報を検索する過程はＤＮＡの範囲を越えて
います。
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].
明示的を言われない限り、この文書はＩＰｖ６の見地のみからＤＮＡ手順を
考察します。それで、用語「ＩＰ」は、デフォルトで、ＩＰｖ６を意味する
と理解されるはずです。ＩＰｖ４の場合についてはのために[7]を参照してく
ださい。
2. Problems in Detecting Network Attachment
2. ネットワーク接続検出の問題
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.
多くの問題がＤＮＡを複雑にします。最初に、無線接続は有線接続ほど明快
ではありません。第二に、１つのルータ広告（ＲＡ）メッセージだけでリン
ク変更を示すことは難しいです。第三に、現在のルータ探索仕様は、要請さ
れたＲＡを返す前にルータが０〜．５秒のランダム遅延を指定します。この
遅れは重要であり得て、サービス中断をもたらすかもしれません。
2.1. Wireless Link Properties
2.1. 無線リンクの特性
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.
有線環境と異なり、無線リンクを構成するものは時間と空間で変化します。
無線リンクが明確な境界線を持ちません。これはホストが同時に複数の
（８０２.１１）アクセスポイントのエリア内にいるという事実で示されるか
もしれません。さらに、無線リンクの接続性は非常に不安定で、そしてこれ
はリンク識別子検出を難しくするかもしれません。例えば、ホストはリンク
変化を調べるのに時間がかかります。もしホストが２つのリンク間を行った
り来たりして、十分長い間時間特定のリンクに滞在しないなら、ＤＮＡ手順
を完了することができません。
2.2. Link Identity Detection with a Single RA
2.2. 単一ＲＡでのリンク識別子発見
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.
通常、ホストはＲＡメッセージからＩＰ設定に必要な情報を手に入れます。
現在の定義[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.
リンク識別子を検出するために、ホストが、ルータアドレスあるいはプレ
フィックスのような、ＲＡの情報をローカルに保存された情報と比較するか
もしれません。
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.
ホストは受信したルータアドレスをリンク変更を調べるために使うかもしれ
ません。しかしながら、ＲＡのソースアドレスフィールドのルータアドレス
はリンクローカルの範囲ので、その一意さはリンク外で保証されていません。
もし異なるリンク上の２つの異なるルータインタフェースが同じリンクロー
カルアドレスを持つ事がたまたま起きるなら、ホストはＲＡメッセージのルー
タアドレスを検査することでリンクを移動した事を感じ取ることができませ
ん。
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.
リンクに割り当てられたすべてのグローバルプレフィックスの集合でリンク
を識別する事ができます。ホストはＲＡから入手したプレフィックスを現在
保管しているものと比較するかもしれません。しかし、望まれていないＲＡ
メッセージは便利さのためにあるプレフィックスを省略することができます
[1]、そしてホストが確実にリンク上のすべてのプレフィックスを獲得して維
持することは容易ではありません。そのために、ＲＡでの既知プレフィック
スの欠如や、未知プレフィックスの存在は、リンク変更の保障になりません.
2.3. Delays
2.3. 遅延
The following issues cause DNA delay that may result in communication
disruption.
次の問題はＤＮＡを遅延させ、通信中断をもたらすかもしれません。
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.
ヒントはリンクの変化が起こったかもしれないという表示です。このヒント
自身はリンク変更を確認しません、しかし現在接続されているリンクの正体
を検出するために適切なＤＮＡ手順が始まります。
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]、デフォルトルータからのＲＡ、ある
いは新しいＲＡの受信の欠如です。同じくヒントを受け取る時間も変化します。
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.
新しいリンクレイヤ接続がされるとすぐに、リンクレイヤは連結通知をＩＰ
レイヤに送るかもしれません。ホストがリンク変更の可能性として新しいリ
ンクレイヤ接続をヒントと解釈するかもしれません。リンクレイヤサポート
で、ホストがほとんど直ちにこのようなヒントを受け取ることができます。
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.
モバイルＩＰｖ６[4]がヒントのためにＲＡ間隔タイマのタイムアウトの使用
を明確にします。ホストが周期的なＲＡのモニタリングを保持して、その欠
如をヒントと解釈します。何個のＲＡの欠如をヒントと解釈するかのポリシ
を実装するかもしれません。それで、遅延はルータ広告間隔に依存します。
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.
上記のような体系がなければ、ホストがリンク変更の可能性を検出するため
に、新しいルータから新しいＲＡを受信しなければなりません。発見時間は
ルータ広告周期に依存します。
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.
周期的ＲＡ送信パケットはMinRtrAdvInterval からMaxRtrAdvInterval秒の間
のランダムな間隔で送られます。ネットワーク接続は新しいリンク上の広告
時間と無関係なので、ホストが平均で半分の間隔で受信する事を期待されま
す。近隣探索[1]広告レートから、これはおよそ１.７５秒です。
2) Random delay execution for RS/RA exchange
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.
ルータ要請とルータ広告メッセージはルータ探索のために使われます。[1]に
よれば、ホストがＲＳを送る前に、そしてルータがＲＡを返す前に、ランダ
ム時間待つことは時々必要です。
According to RFC 2461 [1], the following apply:
ＲＦＣ２４６１[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).
- ホストが最初の要請を送る前に、０からMAX_RTR_SOLICITATION_DELAY
（１秒）の間のランダム時間、送信を遅らせるべきです。
- 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).
- さらに、ルータ要請に応えて送られるＲＡは０からMAX_RA_DELAY_TIME
（０.５秒）の間のランダム時間、遅らせなくてはなりません。
3. Goals for Detecting Network Attachment
3. ネットワーク接続検出の目標
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 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.
ＤＮＡ解決策が正確にリンクの変化が起こったかどうか決定するべきです。
さらに、サービス中断がないか最小であるように、これらは十分に高速であ
るべきです。これらはリンクを関連した信号で溢れさせたり、新しいセキュ
リティーホールを導入しするべきではありません。
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.
新しい解決を定義するとき、利用可能な手段、近隣要請/近隣広告メッセー
ジ、ＲＳ/ＲＡメッセージ、リンクレイヤイベント通知[6]と他の使用法の特
徴を調査することは必要です。これは効率的なＤＮＡ体系の手順の正確な記
述を許すでしょう。
3.1. Goals List
3.1. 目標リスト
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 ＤＮＡ体系が既存のＩＰ設定の有効性を確認するために現在接続されて
いるリンクの正体を検出するべきです。これはリンクの変化が起こった
かどうかを認識し、決定し、もし必要であるなら、新しい設定を獲得す
る処理を始めるべきです。
G2 DNA schemes should detect the identity of an attached link with
minimal latency lest there should be service disruption.
G2 サービス中断がないように、 ＤＮＡ体系が最小の反応時間で接続リンク
の正体を検出するべきです。
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 がもしホストがリンクを変えないなら、ＤＮＡ体系が間違ってリンク変
更を想定し、ＩＰ設定変更を起こすべきではありません。
G4 DNA schemes should not cause undue signaling on a link.
G4 ＤＮＡ体系がリンクの上で過度の信号を起こすべきではありません。
G5 DNA schemes should make use of existing signaling mechanisms
where available.
G5 利用可能である場合は、 ＤＮＡ体系が既存の信号メカニズムを利用する
べきです。
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 ＤＮＡ体系がリンク内で信号を送ることを利用するべきです（特にリン
クローカル範囲メッセージ）、なぜならリンク外通信はリンク変更に関
しては達成可能でないかもしれないからです。
G7 DNA schemes should be compatible with security schemes such as
Secure Neighbor Discovery [3].
G7 ＤＮＡ体系は安全な近隣探索[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 ＤＮＡ体系が新しいセキュリティの弱点を導入するべきではありません。
ＤＮＡ体系をサポートしているノードは、自分自身やリンク上の他ノー
ドを、中間者攻撃やサービス妨害攻撃に、新たのさらすべきではありま
せん。
G9 Nodes (such as routers or hosts) that support DNA schemes should
work appropriately with unmodified nodes that do not.
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 ホストは、特に無線の環境で、異なるリンク上の到達可能なルータを認
知するかもしれません。ＤＮＡ体系がホストが同時に複数のリンクに接
続する場合を考慮に入れるべきです。
4. Security Considerations
4. セキュリティの考察
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.
ＤＮＡ処理は親密に近隣探索プロトコル[1]と関係があります、そしてその信
頼モデルと脅威は共通で、ＲＦＣで３７５６[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.
安全でないＤＮＡ体系で、ホストがどのネットワークに接続したと信じるか
に基づくセキュリティ調整は勧められません。例えば、ホストがホームネッ
トワークに接続しているとと信じたから、ホストがパーソナルファイアウォー
ルを停止することは不適当であるでしょう。
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.
正式な情報（ルーティングとプレフィックス状態）が広告した場合でも、無
線ネットワーク攻撃者が要請ノードのパケットを受信を阻止するかもしれま
せん。これはある装置で不必要なＩＰ設定の変化を起こすかもしれません。
このような攻撃は、ホストに特定の設定やアクセスネットワークを選択させ
るために使われるかもしれません。
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.
もし不十分に認証される装置からの受信であれば、リンク層とネットワーク
層からリンク変更通知を受け取ることは危険であるかもしれません。特に、
リンク層で認証が完了した通知が、ネットワーク層のセキュリティ関係を利
用可能であることを意味しないかもしれません。追加の認証がネットワーク
層でＩＰ設定の修正を正当化するために必要かもしれません。
5. Acknowledgements
5. 謝辞
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はこの文書に先行した活動に際立って貢献しました。同じく
ＲＡ情報の不整合についてEd Remmellのコメントは最も解明的でした。著者
は貴重なフィードバックのためにPekka Nikanderに感謝します。議論の構造
を明確にすることに対して我々がShubhranshu Singhから受け取った寛大な援
助に感謝します。この文書への貢献について、Brett PentlandとNick Moore
とYoun-Hee HanとJaeHoon KimとAlper YeginとJim BoundとJari Arkkoに感謝
します。
6. References
6. 参考文献
6.1. Normative References
6.1. 参照する参考文献
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
6.2. Informative References
6.2. 有益な参考文献
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[6] Yegin, A., "Link-layer Event Notifications for Detecting Network
Attachments", work in progress, July 2005.
[7] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", work in
progress, June 2005.
Authors' Addresses
著者のアドレス
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
Phone: +61 3 9905 4655
EMail: greg.daley@eng.monash.edu.au
Full Copyright Statement
著作権表示全文
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.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。