RFC4862 日本語訳
4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten,T. Jinmei. September 2007. (Format: TXT=72482 bytes) (Obsoletes RFC2462) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Thomson
Request for Comments: 4862 Cisco
Obsoletes: 2462 T. Narten
Category: Standards Track IBM
T. Jinmei
Toshiba
September 2007
コメントを求めるワーキンググループS.トムソンの要求をネットワークでつないでください: 4862年のコクチマスは以下を時代遅れにします。 2462年のT.Nartenカテゴリ: 標準化過程IBM T.Jinmei東芝2007年9月
IPv6 Stateless Address Autoconfiguration
IPv6の状態がないアドレス自動構成
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link.
このドキュメントはIPバージョン6のインタフェースを自動構成する方法を決めるホストが見て取るステップを指定します。 自動構成プロセスは、リンクローカルアドレスを生成するのを含んでいます、リンクに関するアドレスのユニークさについて確かめるために状態がないアドレス自動構成、およびDuplicate Address Detection手順でグローバルなアドレスを作って。
Thomson, et al. Standards Track [Page 1] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[1ページ]RFC4862IPv6
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Site Renumbering . . . . . . . . . . . . . . . . . . . . . 9
5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 10
5.1. Node Configuration Variables . . . . . . . . . . . . . . . 10
5.2. Autoconfiguration-Related Structures . . . . . . . . . . . 11
5.3. Creation of Link-Local Addresses . . . . . . . . . . . . . 11
5.4. Duplicate Address Detection . . . . . . . . . . . . . . . 12
5.4.1. Message Validation . . . . . . . . . . . . . . . . . . 14
5.4.2. Sending Neighbor Solicitation Messages . . . . . . . . 14
5.4.3. Receiving Neighbor Solicitation Messages . . . . . . . 15
5.4.4. Receiving Neighbor Advertisement Messages . . . . . . 16
5.4.5. When Duplicate Address Detection Fails . . . . . . . . 17
5.5. Creation of Global Addresses . . . . . . . . . . . . . . . 17
5.5.1. Soliciting Router Advertisements . . . . . . . . . . . 18
5.5.2. Absence of Router Advertisements . . . . . . . . . . . 18
5.5.3. Router Advertisement Processing . . . . . . . . . . . 18
5.5.4. Address Lifetime Expiry . . . . . . . . . . . . . . . 20
5.6. Configuration Consistency . . . . . . . . . . . . . . . . 21
5.7. Retaining Configured Addresses for Stability . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Loopback Suppression and Duplicate Address
Detection . . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Changes since RFC 1971 . . . . . . . . . . . . . . . 26
Appendix C. Changes since RFC 2462 . . . . . . . . . . . . . . . 27
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1。 要件. . . . . . . . . . . . . . . . . . . . . . . 7 3。 目標. . . . . . . . . . . . . . . . . . . . . . . . . 7 4を設計してください。 概要. . . . . . . . . . . . . . . . . . . . . . 8 4.1について議定書の中で述べてください。 サイトの番号を付け替え. . . . . . . . . . . . . . . . . . . . . 9 5ること。 仕様. . . . . . . . . . . . . . . . . . . . 10 5.1を議定書の中で述べてください。 ノード構成変数. . . . . . . . . . . . . . . 10 5.2。 自動構成関連の構造. . . . . . . . . . . 11 5.3。 リンクローカルのアドレス. . . . . . . . . . . . . 11 5.4の作成。 アドレス検出. . . . . . . . . . . . . . . 12 5.4.1をコピーしてください。 メッセージ合法化. . . . . . . . . . . . . . . . . . 14 5.4.2。 隣人懇願メッセージ. . . . . . . . 14 5.4.3を送ります。 隣人懇願メッセージ. . . . . . . 15 5.4.4を受け取ります。 隣人広告メッセージ. . . . . . 16 5.4.5を受け取ります。 写しアドレス検出が.175.5に失敗すると。 グローバルの作成は.1に.175.5を扱います。 ルータ通知. . . . . . . . . . . 18 5.5.2に請求します。 ルータ通知. . . . . . . . . . . 18 5.5.3の欠如。 ルータ通知処理. . . . . . . . . . . 18 5.5.4。 生涯満期. . . . . . . . . . . . . . . 20 5.6を扱ってください。 構成の一貫性. . . . . . . . . . . . . . . . 21 5.7。 保有は安定性. . . . . . . 22 6のためのアドレスを構成しました。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 22 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 23 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 23 8.2。 RFC2462.27以来RFC1971.26付録C.が変化して以来の有益な参照. . . . . . . . . . . . . . . . . . 23付録A.ループバック抑圧と写しアドレス検出. . . . . . . . . . . . . . . . . . . . . . 25付録B.変化
Thomson, et al. Standards Track [Page 2] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[2ページ]RFC4862IPv6
1. Introduction
1. 序論
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 (IPv6). The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link.
このドキュメントはIPバージョン6(IPv6)でインタフェースを自動構成する方法を決めるホストが見て取るステップを指定します。 自動構成プロセスは、リンクローカルアドレスを生成するのを含んでいます、リンクに関するアドレスのユニークさについて確かめるために状態がないアドレス自動構成、およびDuplicate Address Detection手順でグローバルなアドレスを作って。
The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link.
ルータの最小量(もしあれば)の構成を必要としますが、IPv6の状態がない自動構成メカニズムはホストを手動の構成がない、どんな追加サーバも必要としません。 状態がないメカニズムで、ホストはそれ自身のアドレスが局所的に利用可能な情報の組み合わせを使用して、ルータによって広告に掲載された情報であると生成することができます。 ルータはリンクに関連しているサブネットを特定する接頭語の広告を出します、ホストがサブネットで唯一インタフェースを特定する「インタフェース識別子」を生成しますが。 アドレスは、2を結合することによって、形成されます。 ルータがないとき、ホストはリンクローカルのアドレスを作ることができるだけです。 しかしながら、リンクローカルのアドレスは同じリンクに添付されたノードの中にコミュニケーションを許容するのに十分です。
The stateless approach is used when a site is not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable. On the other hand, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is used when a site requires tighter control over exact address assignments. Both stateless address autoconfiguration and DHCPv6 may be used simultaneously.
サイトは特にホストが使用する正確な送付先に関係がないとき、状態がないアプローチが使用されています、彼らがユニークであり、適切に発送可能する限り。 他方では、サイトが正確な送付先課題の、よりきついコントロールを必要とするとき、IPv6(DHCPv6)[RFC3315]のためのDynamic Host Configuration Protocolは使用されています。 状態がないアドレス自動構成とDHCPv6の両方が同時に、使用されるかもしれません。
IPv6 addresses are leased to an interface for a fixed (possibly infinite) length of time. Each address has an associated lifetime that indicates how long the address is bound to an interface. When a lifetime expires, the binding (and address) become invalid and the address may be reassigned to another interface elsewhere in the Internet. To handle the expiration of address bindings gracefully, an address goes through two distinct phases while assigned to an interface. Initially, an address is "preferred", meaning that its use in arbitrary communication is unrestricted. Later, an address becomes "deprecated" in anticipation that its current interface binding will become invalid. While an address is in a deprecated state, its use is discouraged, but not strictly forbidden. New communication (e.g., the opening of a new TCP connection) should use a preferred address when possible. A deprecated address should be used only by applications that have been using it and would have difficulty switching to another address without a service disruption.
IPv6アドレスは固定された(ことによると無限の)長さの時にインタフェースに賃貸されます。 各アドレスには、アドレスがどれくらい長い間インタフェースに制限されているかを示す関連寿命があります。 寿命が期限が切れると、結合(そして、アドレス)は無効になります、そして、アドレスはインターネットのほかの場所で別のインタフェースに再選任されるかもしれません。 優雅にアドレス結合の満了を扱うために、アドレスはインタフェースに割り当てられている間、2つの異なったフェーズに直面しています。 初めは、任意のコミュニケーションにおける使用が無制限であることを意味して、アドレスは「好まれます」。 その後、アドレスは現在のインタフェースが付く場合無効になる予期で「推奨しなく」なります。 アドレスが推奨しない状態にある間、使用は、がっかりしていますが、厳密に禁じられません。 可能であるときに、新しいコミュニケーション(例えば、新しいTCP接続の始まり)は都合のよいアドレスを使用するべきです。 推奨しないアドレスは、単にそれを使用しているアプリケーションで使用されるべきであり、サービスの崩壊なしで別のアドレスに切り替わるのに苦労するでしょう。
Thomson, et al. Standards Track [Page 3] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[3ページ]RFC4862IPv6
To ensure that all configured addresses are likely to be unique on a given link, nodes run a "duplicate address detection" algorithm on addresses before assigning them to an interface. The Duplicate Address Detection algorithm is performed on all addresses, independently of whether they are obtained via stateless autoconfiguration or DHCPv6. This document defines the Duplicate Address Detection algorithm.
すべての構成されたアドレスが与えられたリンクで特有である傾向があることを保証するために、それらをインタフェースに割り当てる前に、ノードは「写しアドレス検出」アルゴリズムをアドレスに実行します。 Duplicate Address Detectionアルゴリズムはすべてのアドレスに実行されます、状態がない自動構成かDHCPv6を通してそれらを得るかどうかの如何にかかわらず。 このドキュメントはDuplicate Address Detectionアルゴリズムを定義します。
The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means. However, it is expected that routers will generate link-local addresses using the mechanism described in this document. In addition, routers are expected to successfully pass the Duplicate Address Detection procedure described in this document on all addresses prior to assigning them to an interface.
本書では指定された自動構成プロセスはルータではなく、ホストだけに適用されます。 ホスト自動構成がルータによって広告に掲載された情報を使用するので、ルータは、ある他の手段で構成される必要があるでしょう。 しかしながら、ルータが本書では説明されたメカニズムを使用することでリンクローカルのアドレスを作ると予想されます。 さらに、ルータが首尾よくそれらをインタフェースに割り当てる前に本書ではすべてのアドレスで説明されたDuplicate Address Detection手順を通過すると予想されます。
Section 2 provides definitions for terminology used throughout this document. Section 3 describes the design goals that lead to the current autoconfiguration procedure. Section 4 provides an overview of the protocol, while Section 5 describes the protocol in detail.
セクション2はこのドキュメント中で使用される用語のための定義を提供します。 セクション3は現在の自動構成手順につながるデザイン目標について説明します。 セクション4はプロトコルの概要を提供しますが、セクション5は詳細にプロトコルについて説明します。
2. Terminology
2. 用語
IP - Internet Protocol Version 6. The terms IPv4 and IPv6 are used
only in contexts where necessary to avoid ambiguity.
IP--インターネットプロトコルバージョン6。 用語のIPv4とIPv6はあいまいさを避けるのに必要であるところで文脈だけで使用されます。
node - a device that implements IP.
ノード--IPを実装するデバイス。
router - a node that forwards IP packets not explicitly addressed to
itself.
ルータ--明らかにそれ自体に扱われなかったIPパケットを進めるノード。
host - any node that is not a router.
ホスト--ルータでないどんなノード。
upper layer - a protocol layer immediately above IP. Examples are
transport protocols such as TCP and UDP, control protocols such as
ICMP, routing protocols such as OSPF, and Internet or lower-layer
protocols being "tunneled" over (i.e., encapsulated in) IP such as
IPX, AppleTalk, or IP itself.
上側の層--IPのすぐ上のプロトコル層。 例はTCPやUDP、制御プロトコルなどのICMP、ルーティング・プロトコルなどのOSPFやインターネットやIPX、AppleTalkなどの(すなわち、要約されます)IP、またはIPの上でそれ自体で「トンネルを堀られる」下位層プロトコルなどのトランスポート・プロトコルです。
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately below
IP. Examples are Ethernets (simple or bridged); PPP links; X.25,
Frame Relay, or ATM networks; and Internet (or higher) layer
"tunnels", such as tunnels over IPv4 or IPv6 itself. The protocol
described in this document will be used on all types of links
unless specified otherwise in the link-type-specific document
describing how to operate IP on the link in line with [RFC4861].
リンクしてください--ノードがすなわち、リンクレイヤ、IPのすぐ下の層で交信できる通信機器か媒体。 例はEthernets(簡単であるかブリッジしている)です。 PPPはリンクします。 X.25、Frame Relay、またはATMネットワーク。 そして、インターネット(より高い)層はIPv4かIPv6自身の上のトンネルなどのように「トンネルを堀ります」。 別の方法で[RFC4861]に沿ったリンクでIPを経営する方法を説明するリンクタイプ詳細ドキュメントで指定されないと、本書では説明されたプロトコルはすべてのタイプのリンクの上に使用されるでしょう。
Thomson, et al. Standards Track [Page 4] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[4ページ]RFC4862IPv6
interface - a node's attachment to a link.
連結してください--リンクへのノードの付属。
packet - an IP header plus payload.
パケット--IPヘッダーとペイロード。
address - an IP-layer identifier for an interface or a set of
interfaces.
アドレス--インタフェースかインタフェースのセットのためのIP-層の識別子。
unicast address - an identifier for a single interface. A packet
sent to a unicast address is delivered to the interface identified
by that address.
ユニキャストアドレス--単一のインタフェースのための識別子。 ユニキャストアドレスに送られたパケットはそのアドレスによって特定されたインタフェースに提供されます。
multicast address - an identifier for a set of interfaces (typically
belonging to different nodes). A packet sent to a multicast
address is delivered to all interfaces identified by that address.
マルチキャストアドレス--1セットのインタフェース(異なったノードに通常属す)のための識別子。 マルチキャストアドレスに送られたパケットはそのアドレスによって特定されたすべてのインタフェースに提供されます。
anycast address - an identifier for a set of interfaces (typically
belonging to different nodes). A packet sent to an anycast
address is delivered to one of the interfaces identified by that
address (the "nearest" one, according to the routing protocol's
measure of distance). See [RFC4291].
anycastアドレス--1セットのインタフェース(異なったノードに通常属す)のための識別子。 anycastアドレスに送られたパケットはそのアドレス(ルーティング・プロトコルの距離の基準に従った“nearest"1)によって特定されたインタフェースの1つに提供されます。 [RFC4291]を見てください。
solicited-node multicast address - a multicast address to which
Neighbor Solicitation messages are sent. The algorithm for
computing the address is given in [RFC4291].
請求されたノードマルチキャストアドレス--Neighbor Solicitationメッセージが送られるマルチキャストアドレス。 [RFC4291]でアドレスを計算するためのアルゴリズムを与えます。
link-layer address - a link-layer identifier for an interface.
Examples include IEEE 802 addresses for Ethernet links and E.164
addresses for Integrated Services Digital Network (ISDN) links.
リンクレイヤアドレス--インタフェースのためのリンクレイヤ識別子。 例はイーサネットリンクへのIEEE802アドレスを含んでいます、そして、E.164はIntegrated ServicesのためにDigitalがNetwork(ISDN)リンクであると扱います。
link-local address - an address having link-only scope that can be
used to reach neighboring nodes attached to the same link. All
interfaces have a link-local unicast address.
リンクローカルアドレス--隣接しているノードに達するのに使用できるリンクだけ範囲を持っているアドレスは同じリンクに付きました。 すべてのインタフェースには、リンクローカルのユニキャストアドレスがあります。
global address - an address with unlimited scope.
グローバルアドレス--無制限な範囲があるアドレス。
communication - any packet exchange among nodes that requires that
the address of each node used in the exchange remain the same for
the duration of the packet exchange. Examples are a TCP
connection or a UDP request-response.
コミュニケーション--ノードの中の交換に使用されるそれぞれのノードのアドレスがパケット交換の持続時間に同じままで残っているのを必要とするどんなパケット交換。 例は、TCP接続かUDP要求応答です。
tentative address - an address whose uniqueness on a link is being
verified, prior to its assignment to an interface. A tentative
address is not considered assigned to an interface in the usual
sense. An interface discards received packets addressed to a
tentative address, but accepts Neighbor Discovery packets related
to Duplicate Address Detection for the tentative address.
一時的なアドレス--リンクのユニークさが課題の前にインタフェースに確かめられる予定であるアドレス。 一時的なアドレスは普通の意味におけるインタフェースに割り当てられると考えられません。 インタフェースは、一時的なアドレスに扱われた容認されたパケットを捨てますが、一時的なアドレスのためにDuplicate Address Detectionに関連するNeighborディスカバリーパケットを受け入れます。
Thomson, et al. Standards Track [Page 5] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[5ページ]RFC4862IPv6
preferred address - an address assigned to an interface whose use by
upper-layer protocols is unrestricted. Preferred addresses may be
used as the source (or destination) address of packets sent from
(or to) the interface.
都合のよいアドレス--上側の層のプロトコルによる使用が無制限であるインタフェースに割り当てられたアドレス。 パケットのソース(または、目的地)アドレスが(or to)からインタフェースを送ったので、都合のよいアドレスは使用されるかもしれません。
deprecated address - An address assigned to an interface whose use
is discouraged, but not forbidden. A deprecated address should no
longer be used as a source address in new communications, but
packets sent from or to deprecated addresses are delivered as
expected. A deprecated address may continue to be used as a
source address in communications where switching to a preferred
address causes hardship to a specific upper-layer activity (e.g.,
an existing TCP connection).
推奨しないアドレス--使用ががっかりしていますが、禁じられないインタフェースに割り当てられたアドレス。 もうソースアドレスとして新しいコミュニケーションで推奨しないアドレスを使用するべきではありませんが、予想されるようにアドレス、または、推奨しないアドレスに送られたパケットを提供します。 推奨しないアドレスは、コミュニケーションのソースアドレスが都合のよいアドレスに切り替わるところで特定の上側の層の活動(例えば、既存のTCP接続)に苦労を引き起こすので使用され続けるかもしれません。
valid address - a preferred or deprecated address. A valid address
may appear as the source or destination address of a packet, and
the Internet routing system is expected to deliver packets sent to
a valid address to their intended recipients.
有効なアドレス--都合のよいか推奨しないアドレス。 有効なアドレスはパケットのソースか送付先アドレスとして見えるかもしれません、そして、インターネット・ルーティングシステムが有効なアドレスに送られたパケットを彼らの意図している受取人に提供すると予想されます。
invalid address - an address that is not assigned to any interface.
A valid address becomes invalid when its valid lifetime expires.
Invalid addresses should not appear as the destination or source
address of a packet. In the former case, the Internet routing
system will be unable to deliver the packet; in the latter case,
the recipient of the packet will be unable to respond to it.
無効のアドレス--どんなインタフェースにも割り当てられないアドレス。 有効な寿命が期限が切れると、有効なアドレスは無効になります。 無効のアドレスはパケットの目的地かソースアドレスとして現れるべきではありません。 前の場合では、インターネット・ルーティングシステムはパケットを提供できないでしょう。 後者の場合では、パケットの受取人はそれに応じることができないでしょう。
preferred lifetime - the length of time that a valid address is
preferred (i.e., the time until deprecation). When the preferred
lifetime expires, the address becomes deprecated.
都合のよい生涯--有効なアドレスが好まれる時間(すなわち、不賛成までの時間)の長さ。 都合のよい寿命が期限が切れると、アドレスは推奨しなくなります。
valid lifetime - the length of time an address remains in the valid
state (i.e., the time until invalidation). The valid lifetime
must be greater than or equal to the preferred lifetime. When the
valid lifetime expires, the address becomes invalid.
有効な生涯--アドレスが有効な州(すなわち、無効にするまでの時間)に残っている時間の長さ。 有効な寿命はそう以上であるに違いありません。都合のよい生涯。 有効な寿命が期限が切れると、アドレスは無効になります。
interface identifier - a link-dependent identifier for an interface
that is (at least) unique per link [RFC4291]. Stateless address
autoconfiguration combines an interface identifier with a prefix
to form an address. From address autoconfiguration's perspective,
an interface identifier is a bit string of known length. The
exact length of an interface identifier and the way it is created
is defined in a separate link-type specific document that covers
issues related to the transmission of IP over a particular link
type (e.g., [RFC2464]). Note that the address architecture
[RFC4291] also defines the length of the interface identifiers for
some set of addresses, but the two sets of definitions must be
consistent. In many cases, the identifier will be derived from
the interface's link-layer address.
識別子を連結してください--リンク[RFC4291]単位で(少なくとも)ユニークなインタフェースのためのリンク依存する識別子。 状態がないアドレス自動構成は、アドレスを形成するためにインタフェース識別子を接頭語に結合します。 アドレス自動構成の見解から、インタフェース識別子は知られている長さのしばらくストリングです。 インタフェース識別子とそれが作成される方法の正確な長さは特定のリンク型(例えば、[RFC2464])でIPのトランスミッションに関連する問題をカバーする別々のリンク型特定のドキュメントで定義されます。 また、アドレス体系[RFC4291]が何らかのセットのアドレスのためのインタフェース識別子の長さを定義しますが、2セットの定義が一貫しているに違いないことに注意してください。 多くの場合、インタフェースのリンクレイヤアドレスから識別子を得るでしょう。
Thomson, et al. Standards Track [Page 6] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[6ページ]RFC4862IPv6
2.1. Requirements
2.1. 要件
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
キーワードが解釈しなければならない、本書では現れるとき、[RFC2119]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
Note that this document intentionally limits the use of the keywords to the protocol specification (Section 5).
このドキュメントが故意にキーワードの使用をプロトコル仕様(セクション5)に制限することに注意してください。
3. Design Goals
3. デザイン目標
Stateless autoconfiguration is designed with the following goals in mind:
状態がない自動構成は以下の目標で念頭に設計されています:
o Manual configuration of individual machines before connecting them
to the network should not be required. Consequently, a mechanism
is needed that allows a host to obtain or create unique addresses
for each of its interfaces. Address autoconfiguration assumes
that each interface can provide a unique identifier for that
interface (i.e., an "interface identifier"). In the simplest
case, an interface identifier consists of the interface's link-
layer address. An interface identifier can be combined with a
prefix to form an address.
o それらをネットワークに接続する前の個々のマシンの手動の構成を必要とするべきではありません。 その結果、ホストがそれぞれのインタフェースへのユニークなアドレスを得るか、または作成するメカニズムが、必要です。 アドレス自動構成は、各インタフェースがそのインタフェース(すなわち、「インタフェース識別子」)のためのユニークな識別子を提供できると仮定します。 最も簡単な場合では、インタフェース識別子はインタフェースリンクの層のアドレスから成ります。 アドレスを形成するためにインタフェース識別子を接頭語に結合できます。
o Small sites consisting of a set of machines attached to a single
link should not require the presence of a DHCPv6 server or router
as a prerequisite for communicating. Plug-and-play communication
is achieved through the use of link-local addresses. Link-local
addresses have a well-known prefix that identifies the (single)
shared link to which a set of nodes attach. A host forms a link-
local address by appending an interface identifier to the link-
local prefix.
o 単一のリンクに取り付けられた1セットのマシンから成る小さいサイトは交信するための前提条件としてDHCPv6サーバかルータを存在に要求するべきではありません。 プラグアンドプレイコミュニケーションはリンクローカルのアドレスの使用で達成されます。 リンクローカルのアドレスには、1セットのノードが付く(単一)の共有されたリンクを特定するよく知られる接頭語があります。 ホストは、リンクのローカルの接頭語にインタフェース識別子を追加することによって、リンクローカルアドレスを形成します。
o A large site with multiple networks and routers should not require
the presence of a DHCPv6 server for address configuration. In
order to generate global addresses, hosts must determine the
prefixes that identify the subnets to which they attach. Routers
generate periodic Router Advertisements that include options
listing the set of active prefixes on a link.
o 複数のネットワークとルータがある大きいサイトはアドレス構成のためにDHCPv6サーバを存在に要求するべきではありません。 グローバルなアドレスを作るために、ホストはそれらが付くサブネットを特定する接頭語を決定しなければなりません。 ルータはアクティブな接頭語のセットをリンクに記載するオプションを含んでいる周期的なRouter Advertisementsを生成します。
o Address configuration should facilitate the graceful renumbering
of a site's machines. For example, a site may wish to renumber
all of its nodes when it switches to a new network service
provider. Renumbering is achieved through the leasing of
addresses to interfaces and the assignment of multiple addresses
to the same interface. Lease lifetimes provide the mechanism
through which a site phases out old prefixes. The assignment of
multiple addresses to an interface provides for a transition
o アドレス構成はサイトのマシンの優雅な番号を付け替えることを容易にするべきです。 新しいネットワークサービスプロバイダーに切り替わるとき、例えば、サイトはノードのすべてに番号を付け替えさせたがっているかもしれません。 番号を付け替えることはインタフェースへのアドレスの賃貸借契約と同じインタフェースへの複数のアドレスの課題で達成されます。 寿命がサイトが古い接頭語を段階的に廃止するメカニズムを提供するリース。 インタフェースへの複数のアドレスの課題は変遷に備えます。
Thomson, et al. Standards Track [Page 7] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[7ページ]RFC4862IPv6
period during which both a new address and the one being phased
out work simultaneously.
新しいアドレスと段階的に廃止されるものの両方が同時に働いている期間。
4. Protocol Overview
4. プロトコル概要
This section provides an overview of the typical steps that take place when an interface autoconfigures itself. Autoconfiguration is performed only on multicast-capable links and begins when a multicast-capable interface is enabled, e.g., during system startup. Nodes (both hosts and routers) begin the autoconfiguration process by generating a link-local address for the interface. A link-local address is formed by appending an identifier of the interface to the well-known link-local prefix [RFC4291].
このセクションはインタフェースがそれ自体を自動構成するとき行われる典型的なステップの概要を提供します。 マルチキャストできるインタフェースが例えば、システム起動の間可能にされるとき、自動構成は、マルチキャストできるリンクだけに実行されて、始まります。 ノード(ホストとルータの両方)は、リンクローカルアドレスをインタフェースに生成することによって、自動構成プロセスを開始します。 リンクローカルアドレスは、よく知られるリンクローカルの接頭語[RFC4291]にインタフェースに関する識別子を追加することによって、形成されます。
Before the link-local address can be assigned to an interface and used, however, a node must attempt to verify that this "tentative" address is not already in use by another node on the link. Specifically, it sends a Neighbor Solicitation message containing the tentative address as the target. If another node is already using that address, it will return a Neighbor Advertisement saying so. If another node is also attempting to use the same address, it will send a Neighbor Solicitation for the target as well. The exact number of times the Neighbor Solicitation is (re)transmitted and the delay time between consecutive solicitations is link-specific and may be set by system management.
しかしながら、リンクローカルアドレスをインタフェースに割り当てて、使用できる前に、ノードは、この「一時的な」アドレスがリンクの上の別のノードで既に使用中でないことを確かめるのを試みなければなりません。 明確に、それは目標として一時的なアドレスを含むNeighbor Solicitationメッセージを送ります。 別のノードが既にそのアドレスを使用していると、それはそのように言うNeighbor Advertisementを返すでしょう。 また、別のノードが、同じアドレスを使用するのを試みていると、それはまた、目標のためにNeighbor Solicitationを送るでしょう。 回Neighbor Solicitationが(re)であるのはっきりした数が伝わって、連続した懇願の間の遅延時間は、リンク特有であり、システム管理で設定されるかもしれません。
If a node determines that its tentative link-local address is not unique, autoconfiguration stops and manual configuration of the interface is required. To simplify recovery in this case, it should be possible for an administrator to supply an alternate interface identifier that overrides the default identifier in such a way that the autoconfiguration mechanism can then be applied using the new (presumably unique) interface identifier. Alternatively, link-local and other addresses will need to be configured manually.
ノードが、一時的なリンクローカルアドレスがユニークでないことを決定するなら、インタフェースの自動構成停止と手動の構成が必要です。 この場合回復を簡素化するために、管理者が次に、新しい(おそらくユニークな)インタフェース識別子を使用することで自動構成メカニズムを適用できるような方法でデフォルト識別子に優越する代替のインタフェース識別子を提供するのは、可能であるべきです。 あるいはまた、リンク地方の、そして、他のアドレスは、手動で構成される必要があるでしょう。
Once a node ascertains that its tentative link-local address is unique, it assigns the address to the interface. At this point, the node has IP-level connectivity with neighboring nodes. The remaining autoconfiguration steps are performed only by hosts; the (auto)configuration of routers is beyond the scope of this document.
ノードが、一時的なリンクローカルアドレスがユニークであることをいったん確かめると、それはアドレスをインタフェースに割り当てます。 ここに、ノードには、隣接しているノードのIP-レベルの接続性があります。 残っている自動構成ステップは単にホストによって実行されます。 ルータの(自動)の構成はこのドキュメントの範囲を超えています。
The next phase of autoconfiguration involves obtaining a Router Advertisement or determining that no routers are present. If routers are present, they will send Router Advertisements that specify what sort of autoconfiguration a host can do. Note that the DHCPv6 service for address configuration may still be available even if no routers are present.
自動構成の次のフェーズは、Router Advertisementを入手するか、またはどんなルータも存在していないことを決定することを伴います。 ルータが存在していると、それらはホストがどういう自動構成ができるかを指定するRouter Advertisementsを送るでしょう。 どんなルータも存在していなくてもアドレス構成のためのDHCPv6サービスがまだ利用可能であるかもしれないことに注意してください。
Thomson, et al. Standards Track [Page 8] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[8ページ]RFC4862IPv6
Routers send Router Advertisements periodically, but the delay between successive advertisements will generally be longer than a host performing autoconfiguration will want to wait [RFC4861]. To obtain an advertisement quickly, a host sends one or more Router Solicitations to the all-routers multicast group.
ルータが定期的にRouter Advertisementsを送りますが、一般に、連続した広告の間の遅れはホスト実行自動構成が待ちたくなるより[RFC4861]さらに長くなるでしょう。 すぐに広告を得るために、ホストはオールルータマルチキャストグループに1Router Solicitationsを送ります。
Router Advertisements also contain zero or more Prefix Information options that contain information used by stateless address autoconfiguration to generate global addresses. It should be noted that a host may use both stateless address autoconfiguration and DHCPv6 simultaneously. One Prefix Information option field, the "autonomous address-configuration flag", indicates whether or not the option even applies to stateless autoconfiguration. If it does, additional option fields contain a subnet prefix, together with lifetime values, indicating how long addresses created from the prefix remain preferred and valid.
また、ルータAdvertisementsはゼロか状態がないアドレス自動構成によって使用される、グローバルなアドレスを作る情報を含むより多くのPrefix情報オプションを含んでいます。 ホストが同時に状態がないアドレス自動構成とDHCPv6の両方を使用するかもしれないことに注意されるべきです。 「自動アドレス構成旗」という1つのPrefix情報オプション・フィールドが、オプションが状態がない自動構成に適用さえされるかどうかを示します。 そうするなら、追加オプション・フィールドはサブネット接頭語を含んでいます、生涯値と共に、接頭語から作成されたアドレスがどれくらい長い間有効なままで都合のよくて、残っているかを示して。
Because routers generate Router Advertisements periodically, hosts will continually receive new advertisements. Hosts process the information contained in each advertisement as described above, adding to and refreshing information received in previous advertisements.
ルータが定期的にRouter Advertisementsを生成するので、ホストは絶えず新しい広告を受け取るでしょう。 ホストは前の広告に受け取られた情報を加えて、リフレッシュして、上で説明されるように各広告に含まれた情報を処理します。
By default, all addresses should be tested for uniqueness prior to their assignment to an interface for safety. The test should individually be performed on all addresses obtained manually, via stateless address autoconfiguration, or via DHCPv6. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag.
デフォルトで、すべてのアドレスが彼らの課題の前に安全のためにユニークさがないかどうかインタフェースにテストされるべきです。 テストは個別に状態がないアドレス自動構成の近く、または、DHCPv6を通して手動で得られたすべてのアドレスに実行されるべきです。 Duplicate Address Detectionを実行するオーバーヘッドが利益より重いと信じているサイトに対応するために、1インタフェースあたり1個の構成旗の管理設定を通してDuplicate Address Detectionの使用を無効にすることができます。
To speed the autoconfiguration process, a host may generate its link- local address (and verify its uniqueness) in parallel with waiting for a Router Advertisement. Because a router may delay responding to a Router Solicitation for a few seconds, the total time needed to complete autoconfiguration can be significantly longer if the two steps are done serially.
自動構成プロセスを促進するために、Router Advertisementを待つことと平行してホストはリンクローカルアドレス(ユニークさについて確かめる)を生成するかもしれません。 ルータが、数秒間、Router Solicitationに応じるのを遅らせるかもしれないので、順次2ステップをするなら、自動構成を完成するのに必要である合計時はかなり長い場合があります。
4.1. Site Renumbering
4.1. サイトの番号を付け替えること
Address leasing facilitates site renumbering by providing a mechanism to time-out addresses assigned to interfaces in hosts. At present, upper-layer protocols such as TCP provide no support for changing end-point addresses while a connection is open. If an end-point address becomes invalid, existing connections break and all
アドレス賃貸借契約は、ホストでインタフェースに割り当てられたタイムアウトアドレスにメカニズムを提供することによって、サイトの番号を付け替えることを容易にします。 現在のところ、TCPなどの上側の層のプロトコルは接続がオープンである間、エンドポイントアドレスを変えるサポートを全く提供しません。 エンドポイントアドレスが無効の、そして、既存の接続中断とすべてになるなら
Thomson, et al. Standards Track [Page 9] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[9ページ]RFC4862IPv6
communication to the invalid address fails. Even when applications use UDP as a transport protocol, addresses must generally remain the same during a packet exchange.
無効のアドレスへのコミュニケーションは失敗します。 アプリケーションがトランスポート・プロトコルとしてUDPを使用さえするとき、一般に、アドレスはパケット交換の間、同じままで残らなければなりません。
Dividing valid addresses into preferred and deprecated categories provides a way of indicating to upper layers that a valid address may become invalid shortly and that future communication using the address will fail, should the address's valid lifetime expire before communication ends. To avoid this scenario, higher layers should use a preferred address (assuming one of sufficient scope exists) to increase the likelihood that an address will remain valid for the duration of the communication. It is up to system administrators to set appropriate prefix lifetimes in order to minimize the impact of failed communication when renumbering takes place. The deprecation period should be long enough that most, if not all, communications are using the new address at the time an address becomes invalid.
有効なアドレスを都合のよくて推奨しないカテゴリに分割すると、有効なアドレスがまもなく、無効になるかもしれなくて、アドレスを使用する将来のコミュニケーションが失敗するのを上側の層に示す方法は提供されます、コミュニケーションが終わる前にアドレスsの有効な寿命が期限が切れるなら。 このシナリオを避けるなら、より高い層は、アドレスがコミュニケーションの持続時間に有効なままで残る可能性を広げるのに、都合のよいアドレス(十分な範囲について1つを仮定するのは存在している)を使用するはずです。 適切な状態でセットするのは、システム管理者次第です。番号を付け替えることが行われる失敗したコミュニケーションの影響を最小にするために生涯を前に置いてください。 不賛成の期間はアドレスが無効になるときコミュニケーションがすべてでないなら、新しいアドレスを最も使用しているほど長いはずです。
The IP layer is expected to provide a means for upper layers (including applications) to select the most appropriate source address given a particular destination and possibly other constraints. An application may choose to select the source address itself before starting a new communication or may leave the address unspecified, in which case, the upper networking layers will use the mechanism provided by the IP layer to choose a suitable address on the application's behalf.
特定の目的地とことによると他の規制を考えて、IP層が上側の層(アプリケーションを含んでいる)が選択する中でソースアドレス最も適切である手段を提供すると予想されます。 アプリケーションは、新しいコミュニケーションを始める前にソースアドレス自体を選択するのを選ぶか、または不特定の状態でアドレスを出るかもしれません、その場合、上側のネットワーク層がアプリケーションに代わって適当なアドレスを選ぶためにIP層で提供されたメカニズムを使用するでしょう。
Detailed address selection rules are beyond the scope of this document and are described in [RFC3484].
詳細なアドレス選択規則は、このドキュメントの範囲を超えていて、[RFC3484]で説明されます。
5. Protocol Specification
5. プロトコル仕様
Autoconfiguration is performed on a per-interface basis on multicast- capable interfaces. For multihomed hosts, autoconfiguration is performed independently on each interface. Autoconfiguration applies primarily to hosts, with two exceptions. Routers are expected to generate a link-local address using the procedure outlined below. In addition, routers perform Duplicate Address Detection on all addresses prior to assigning them to an interface.
自動構成はマルチキャストのできるインタフェースの1インタフェースあたり1個のベースに実行されます。 「マルチ-家へ帰」っているホストに関しては、自動構成は独自に各インタフェースに実行されます。 自動構成は主としてホストに2つの例外で適用されます。 ルータが以下に概説された手順を用いることでリンクローカルアドレスを生成すると予想されます。 さらに、それらをインタフェースに割り当てる前に、ルータはすべてのアドレスにDuplicate Address Detectionを実行します。
5.1. Node Configuration Variables
5.1. ノード構成変数
A node MUST allow the following autoconfiguration-related variable to be configured by system management for each multicast-capable interface:
ノードは、以下の自動構成関連の変数がそれぞれのマルチキャストできるインタフェースのためのシステム管理で構成されるのを許容しなければなりません:
Thomson, et al. Standards Track [Page 10] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[10ページ]RFC4862IPv6
DupAddrDetectTransmits The number of consecutive Neighbor
Solicitation messages sent while performing Duplicate Address
Detection on a tentative address. A value of zero indicates that
Duplicate Address Detection is not performed on tentative
addresses. A value of one indicates a single transmission with no
follow-up retransmissions.
連続したNeighbor Solicitationメッセージの数が一時的なアドレスにDuplicate Address Detectionを実行している間に送ったDupAddrDetectTransmits。 ゼロの値は、Duplicate Address Detectionが一時的なアドレスに実行されないのを示します。 1の値は追跡している「再-トランスミッション」なしでただ一つのトランスミッションを示します。
Default: 1, but may be overridden by a link-type specific value in
the document that covers issues related to the transmission of IP
over a particular link type (e.g., [RFC2464]).
デフォルト: 特定のリンク型(例えば、[RFC2464])でIPのトランスミッションに関連する問題をカバーするドキュメントのリンク型の特定の値によってくつがえされるかもしれないのを除いた1。
Autoconfiguration also assumes the presence of the variable
RetransTimer as defined in [RFC4861]. For autoconfiguration
purposes, RetransTimer specifies the delay between consecutive
Neighbor Solicitation transmissions performed during Duplicate
Address Detection (if DupAddrDetectTransmits is greater than 1),
as well as the time a node waits after sending the last Neighbor
Solicitation before ending the Duplicate Address Detection
process.
また、自動構成は[RFC4861]で定義されるように可変RetransTimerの存在を仮定します。 自動構成目的として、RetransTimerはDuplicate Address Detectionの間に実行された連続したNeighbor Solicitationトランスミッションの間の遅れを指定します(DupAddrDetectTransmitsが1歳以上であるなら)、Duplicate Address Detectionプロセスを終わらせる前に最後のNeighbor Solicitationを送った後にノードが待つ時と同様に。
5.2. Autoconfiguration-Related Structures
5.2. 自動構成関連の構造
Beyond the formation of a link-local address and use of Duplicate Address Detection, how routers (auto)configure their interfaces is beyond the scope of this document.
リンクローカルアドレスの構成とDuplicate Address Detectionの使用を超えて、ルータ(自動)がどうそれらのインタフェースを構成するかはこのドキュメントの範囲を超えています。
A host maintains a list of addresses together with their corresponding lifetimes. The address list contains both autoconfigured addresses and those configured manually.
ホストは彼らの対応する生涯と共に住所録を維持します。 住所録は自動構成されたアドレスと手動で構成されたものの両方を含んでいます。
5.3. Creation of Link-Local Addresses
5.3. リンクローカルのアドレスの作成
A node forms a link-local address whenever an interface becomes enabled. An interface may become enabled after any of the following events:
インタフェースが可能にされるようになるときはいつも、ノードはリンクローカルアドレスを形成します。 インタフェースは以下のイベントのどれかの後に可能にされるようになるかもしれません:
- The interface is initialized at system startup time.
- インタフェースはシステム起動時に初期化されます。
- The interface is reinitialized after a temporary interface failure
or after being temporarily disabled by system management.
- インタフェースは一時的なインタフェース失敗の後かシステム管理で一時無効にされた後に、再初期化されます。
- The interface attaches to a link for the first time. This
includes the case where the attached link is dynamically changed
due to a change of the access point of wireless networks.
- インタフェースは初めて、リンクに付きます。 これは付属リンクがワイヤレス・ネットワークのアクセスポイントの変化のためダイナミックに変えられるケースを含んでいます。
Thomson, et al. Standards Track [Page 11] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[11ページ]RFC4862IPv6
- The interface becomes enabled by system management after having
been administratively disabled.
- インタフェースは行政上無効にされた後に、システム管理で可能にされるようになります。
A link-local address is formed by combining the well-known link-local prefix FE80::0 [RFC4291] (of appropriate length) with an interface identifier as follows:
リンクローカルアドレスはよく知られるリンク地方の接頭語FE80を結合することによって、形成されます:、:0 [RFC4291] (適切な長さの) インタフェース識別子は以下の通りで:
1. The left-most 'prefix length' bits of the address are those of
the link-local prefix.
1. アドレスの最も左の'接頭語の長さ'ビットはリンクローカルの接頭語のものです。
2. The bits in the address to the right of the link-local prefix are
set to all zeroes.
2. リンクローカルの接頭語の右へのアドレスのビットはすべてのゼロに設定されます。
3. If the length of the interface identifier is N bits, the right-
most N bits of the address are replaced by the interface
identifier.
3. インタフェース識別子の長さがNビットであるなら、権利アドレスのほとんどのNビットをインタフェース識別子に取り替えます。
If the sum of the link-local prefix length and N is larger than 128, autoconfiguration fails and manual configuration is required. The length of the interface identifier is defined in a separate link- type-specific document, which should also be consistent with the address architecture [RFC4291] (see Section 2). These documents will carefully define the length so that link-local addresses can be autoconfigured on the link.
リンクローカルの接頭語長さとNの合計が128より大きいなら、自動構成は失敗します、そして、手動の構成が必要です。 インタフェース識別子の長さは別々のリンクタイプ特有のドキュメントで定義されます(セクション2を見てください)。(また、それも、アドレス体系[RFC4291]と一致しているべきです)。 これらのドキュメントは、リンクの上にリンクローカルのアドレスを自動構成できるように慎重に長さを定義するでしょう。
A link-local address has an infinite preferred and valid lifetime; it is never timed out.
リンクローカルアドレスには、無限の都合のよくて有効な寿命があります。 それは外で決して調節されていません。
5.4. Duplicate Address Detection
5.4. アドレス検出をコピーしてください。
Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of whether they are obtained through stateless autoconfiguration, DHCPv6, or manual configuration, with the following exceptions:
それらをインタフェースに割り当てる前にすべてのユニキャストアドレスに写しAddress Detectionを実行しなければなりません、状態がない自動構成、DHCPv6、または手動の構成を通してそれらを得るかどうかにかかわらず、以下の例外で:
- An interface whose DupAddrDetectTransmits variable is set to zero
does not perform Duplicate Address Detection.
- 合わせてくださいDupAddrDetectTransmits変数が設定されるゼロインタフェースはDuplicate Address Detectionを実行しません。
- Duplicate Address Detection MUST NOT be performed on anycast
addresses (note that anycast addresses cannot syntactically be
distinguished from unicast addresses).
- anycastアドレスに写しAddress Detectionを実行してはいけません(ユニキャストアドレスとanycastアドレスをシンタクス上区別できないことに注意してください)。
- Each individual unicast address SHOULD be tested for uniqueness.
Note that there are implementations deployed that only perform
Duplicate Address Detection for the link-local address and skip
the test for the global address that uses the same interface
identifier as that of the link-local address. Whereas this
document does not invalidate such implementations, this kind of
- それぞれの個々のユニキャストはSHOULDを扱います。ユニークさがないかどうかテストされます。 リンクローカルアドレスのためにDuplicate Address Detectionを実行するだけであり、リンクローカルアドレスのものと同じインタフェース識別子を使用するグローバルアドレスのためにテストをサボる配布された実装があることに注意してください。 ところが、このドキュメントはそのような実装、この種類を無効にしません。
Thomson, et al. Standards Track [Page 12] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[12ページ]RFC4862IPv6
"optimization" is NOT RECOMMENDED, and new implementations MUST
NOT do that optimization. This optimization came from the
assumption that all of an interface's addresses are generated from
the same identifier. However, the assumption does actually not
stand; new types of addresses have been introduced where the
interface identifiers are not necessarily the same for all unicast
addresses on a single interface [RFC4941] [RFC3972]. Requiring
that Duplicate Address Detection be performed for all unicast
addresses will make the algorithm robust for the current and
future special interface identifiers.
「最適化」はNOT RECOMMENDEDです、そして、新しい実装はその最適化をしてはいけません。 この最適化はインタフェースのアドレスのすべてが同じ識別子から生成されるという仮定から来ました。 しかしながら、仮定は実際にどんなスタンドもしません。 新しいタイプのアドレスは単一のインタフェース[RFC4941][RFC3972]に関するすべてのユニキャストアドレスには、インタフェース識別子が必ず同じであるというわけではないところで紹介されました。 Duplicate Address Detectionがすべてのユニキャストアドレスのために実行されるのが必要であるのに、アルゴリズムは現在の、そして、将来の特別なインタフェース識別子に強健になるでしょう。
The procedure for detecting duplicate addresses uses Neighbor Solicitation and Advertisement messages as described below. If a duplicate address is discovered during the procedure, the address cannot be assigned to the interface. If the address is derived from an interface identifier, a new identifier will need to be assigned to the interface, or all IP addresses for the interface will need to be manually configured. Note that the method for detecting duplicates is not completely reliable, and it is possible that duplicate addresses will still exist (e.g., if the link was partitioned while Duplicate Address Detection was performed).
写しアドレスを検出するための手順は以下で説明されるようにNeighbor SolicitationとAdvertisementメッセージを使用します。 写しアドレスが手順の間、発見されるなら、アドレスをインタフェースに割り当てることができません。 インタフェース識別子からアドレスを得ると、新しい識別子が、インタフェースに割り当てられる必要があるだろうか、またはインタフェースへのすべてのIPアドレスが、手動で構成される必要があるでしょう。 写しを検出するためのメソッドが完全に信頼できるというわけではなくて、それでも、写しアドレスが存在するのが(例えば、Duplicate Address Detectionが実行されましたが、リンクが仕切られたなら)、可能であることに注意してください。
An address on which the Duplicate Address Detection procedure is applied is said to be tentative until the procedure has completed successfully. A tentative address is not considered "assigned to an interface" in the traditional sense. That is, the interface must accept Neighbor Solicitation and Advertisement messages containing the tentative address in the Target Address field, but processes such packets differently from those whose Target Address matches an address assigned to the interface. Other packets addressed to the tentative address should be silently discarded. Note that the "other packets" include Neighbor Solicitation and Advertisement messages that have the tentative (i.e., unicast) address as the IP destination address and contain the tentative address in the Target Address field. Such a case should not happen in normal operation, though, since these messages are multicasted in the Duplicate Address Detection procedure.
Duplicate Address Detection手順が適用されているアドレスは手順が一時的になるまで一時的であると言われています。首尾よく完成されます。 一時的なアドレスは伝統的な意味で「インタフェースに割り当てられる」と考えられません。 すなわち、インタフェースは、Target Address分野で一時的なアドレスを含むNeighbor SolicitationとAdvertisementメッセージを受け入れなければなりませんが、アドレスがTarget Addressマッチを割り当てたそれらからインタフェースまでそのようなパケットを異なって処理します。 一時的なアドレスに扱われた他のパケットは静かに捨てられるべきです。 「他のパケット」が受信者IPアドレスとして一時的な(すなわち、ユニキャスト)アドレスを持っていて、Target Address分野に一時的なアドレスを保管しているNeighbor SolicitationとAdvertisementメッセージを含んでいることに注意してください。 もっとも、これらのメッセージがDuplicate Address Detection手順でmulticastedされるので、そのような場合は通常の操作で起こるべきではありません。
It should also be noted that Duplicate Address Detection must be performed prior to assigning an address to an interface in order to prevent multiple nodes from using the same address simultaneously. If a node begins using an address in parallel with Duplicate Address Detection, and another node is already using the address, the node performing Duplicate Address Detection will erroneously process traffic intended for the other node, resulting in such possible negative consequences as the resetting of open TCP connections.
また、複数のノードが同時に同じアドレスを使用するのを防ぐためにアドレスをインタフェースに割り当てる前にDuplicate Address Detectionを実行しなければならないことに注意されるべきです。 ノードがDuplicate Address Detectionと平行してアドレスを使用し始めて、別のノードが既にアドレスを使用していると、Duplicate Address Detectionを実行するノードは誤ってもう片方のノードのために意図するトラフィックを処理するでしょう、オープンなTCP接続のリセットのような可能な否定的結果をもたらして。
Thomson, et al. Standards Track [Page 13] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[13ページ]RFC4862IPv6
The following subsections describe specific tests a node performs to verify an address's uniqueness. An address is considered unique if none of the tests indicate the presence of a duplicate address within RetransTimer milliseconds after having sent DupAddrDetectTransmits Neighbor Solicitations. Once an address is determined to be unique, it may be assigned to an interface.
以下の小区分はノードがアドレスsのユニークさについて確かめるために実行する特異的な試験について説明します。 DupAddrDetectTransmits Neighbor Solicitationsを送ったミリセカンドと同じくらいの後にテストのいずれもRetransTimerの中に写しアドレスの存在を示さないなら、アドレスはユニークであると考えられます。 アドレスがいったん特有であることを決定するようになると、それはインタフェースに割り当てられるかもしれません。
5.4.1. Message Validation
5.4.1. メッセージ合法化
A node MUST silently discard any Neighbor Solicitation or Advertisement message that does not pass the validity checks specified in [RFC4861]. A Neighbor Solicitation or Advertisement message that passes these validity checks is called a valid solicitation or valid advertisement, respectively.
ノードは静かに[RFC4861]で指定されたバリディティチェックを通過しないどんなNeighbor SolicitationやAdvertisementメッセージも捨てなければなりません。 これらのバリディティチェックを通過するNeighbor SolicitationかAdvertisementメッセージがそれぞれ有効な懇願か有効な広告と呼ばれます。
5.4.2. Sending Neighbor Solicitation Messages
5.4.2. 送付隣人懇願メッセージ
Before sending a Neighbor Solicitation, an interface MUST join the all-nodes multicast address and the solicited-node multicast address of the tentative address. The former ensures that the node receives Neighbor Advertisements from other nodes already using the address; the latter ensures that two nodes attempting to use the same address simultaneously should detect each other's presence.
Neighbor Solicitationを送る前に、インタフェースはオールノードマルチキャストアドレスと一時的なアドレスの請求されたノードマルチキャストアドレスを接合しなければなりません。 前者は、ノードが他のノードから既にアドレスを使用することでNeighbor Advertisementsを受けるのを確実にします。 後者は、同時に同じアドレスを使用するのを試みる2つのノードが互いの存在を検出するはずであるのを確実にします。
To check an address, a node sends DupAddrDetectTransmits Neighbor Solicitations, each separated by RetransTimer milliseconds. The solicitation's Target Address is set to the address being checked, the IP source is set to the unspecified address, and the IP destination is set to the solicited-node multicast address of the target address.
アドレスをチェックするために、ノードはDupAddrDetectTransmits Neighbor Solicitations、RetransTimerミリセカンドと同じくらい切り離されたそれぞれを送ります。 懇願のTarget Addressはチェックされるアドレスに用意ができています、そして、IPソースは不特定のアドレスに用意ができています、そして、IPの目的地はあて先アドレスの請求されたノードマルチキャストアドレスに設定されます。
If the Neighbor Solicitation is going to be the first message sent from an interface after interface (re)initialization, the node SHOULD delay joining the solicited-node multicast address by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in [RFC4861]. This serves to alleviate congestion when many nodes start up on the link at the same time, such as after a power failure, and may help to avoid race conditions when more than one node is trying to solicit for the same address at the same time.
Neighbor Solicitationが行く予定であるなら、インタフェース(re)初期化の後にインタフェースから送られた、最初のメッセージ、ノードSHOULD遅れに、なるように、請求されたノードマルチキャストを接合して、0とマックス_の間で無作為の遅れでRTR_SOLICITATION_が指定されるとして[RFC4861]のDELAYであると扱ってください。 これは、多くのノードが同時に停電などの後のようにリンクで始動するとき、混雑を軽減するのに役立って、1つ以上のノードが同時に同じアドレスを請おうとしているとき、競合条件を避けるのを助けるかもしれません。
Even if the Neighbor Solicitation is not going to be the first message sent, the node SHOULD delay joining the solicited-node multicast address by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY if the address being checked is configured by a router advertisement message sent to a multicast address. The delay will avoid similar congestion when multiple nodes are going to configure addresses by receiving the same single multicast router advertisement.
_チェックされるアドレスがルータ通知メッセージによって構成され、Neighbor Solicitationが行く予定でなくても、0とマックス_RTRの間の無作為の遅れで請求されたノードマルチキャストアドレスを接合して、SOLICITATION_DELAYは、最初のメッセージが発信しました、ノードSHOULD遅れということになるようにマルチキャストアドレスに発信しました。 複数のノードが同じただ一つのマルチキャストルータ通知を受け取ることによってアドレスを構成するだろうというとき、遅れは同様の混雑を避けるでしょう。
Thomson, et al. Standards Track [Page 14] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[14ページ]RFC4862IPv6
Note that when a node joins a multicast address, it typically sends a Multicast Listener Discovery (MLD) report message [RFC2710] [RFC3810] for the multicast address. In the case of Duplicate Address Detection, the MLD report message is required in order to inform MLD- snooping switches, rather than routers, to forward multicast packets. In the above description, the delay for joining the multicast address thus means delaying transmission of the corresponding MLD report message. Since the MLD specifications do not request a random delay to avoid race conditions, just delaying Neighbor Solicitation would cause congestion by the MLD report messages. The congestion would then prevent the MLD-snooping switches from working correctly and, as a result, prevent Duplicate Address Detection from working. The requirement to include the delay for the MLD report in this case avoids this scenario. [RFC3590] also talks about some interaction issues between Duplicate Address Detection and MLD, and specifies which source address should be used for the MLD report in this case.
ノードがマルチキャストアドレスを接合するとき、マルチキャストアドレスへのMulticast Listenerディスカバリー(MLD)レポートメッセージ[RFC2710][RFC3810]を通常送ることに注意してください。 Duplicate Address Detectionの場合では、MLDレポートメッセージが、マルチキャストパケットを進めるためにルータよりむしろスイッチについて詮索しながらMLDに知らせるのに必要です。 上の記述では、その結果、マルチキャストアドレスを接合するための遅れは、対応するMLDレポートメッセージの伝達を遅らせることを意味します。 MLD仕様が、競合条件を避けるよう無作為の遅れに要求しないので、ただNeighbor Solicitationを遅らせると、混雑はMLDレポートメッセージによって引き起こされるでしょう。 混雑は、次に、MLD-詮索スイッチが正しく働くのを防いで、Duplicate Address Detectionが働いているのをその結果防ぐでしょう。 MLDレポートのための遅れを含んでいるという要件はこの場合このシナリオを避けます。 [RFC3590]は、また、Duplicate Address DetectionとMLDの間のいくつかの相互作用問題に関して話して、この場合どのソースアドレスがMLDレポートに使用されるべきであるかを指定します。
In order to improve the robustness of the Duplicate Address Detection algorithm, an interface MUST receive and process datagrams sent to the all-nodes multicast address or solicited-node multicast address of the tentative address during the delay period. This does not necessarily conflict with the requirement that joining the multicast group be delayed. In fact, in some cases it is possible for a node to start listening to the group during the delay period before MLD report transmission. It should be noted, however, that in some link- layer environments, particularly with MLD-snooping switches, no multicast reception will be available until the MLD report is sent.
Duplicate Address Detectionアルゴリズムの丈夫さを改良するために、インタフェースは受信されなければなりませんでした、そして、プロセスデータグラムは遅れの期間、一時的なアドレスのオールノードマルチキャストアドレスか請求されたノードマルチキャストアドレスに発信しました。 これは必ず、マルチキャストグループに加わるのが遅れるという要件と衝突するというわけではありません。 事実上、いくつかの場合、MLDがトランスミッションを報告する前にノードが遅れの期間、グループを聞き始めるのは、可能です。 しかしながら、いくつかのリンク層の環境と、特にMLD-詮索スイッチで、どんなマルチキャストレセプションも利用可能にならないことにMLDレポートを送るまで注意されるべきです。
5.4.3. Receiving Neighbor Solicitation Messages
5.4.3. 隣人懇願メッセージを受け取ります。
On receipt of a valid Neighbor Solicitation message on an interface, node behavior depends on whether or not the target address is tentative. If the target address is not tentative (i.e., it is assigned to the receiving interface), the solicitation is processed as described in [RFC4861]. If the target address is tentative, and the source address is a unicast address, the solicitation's sender is performing address resolution on the target; the solicitation should be silently ignored. Otherwise, processing takes place as described below. In all cases, a node MUST NOT respond to a Neighbor Solicitation for a tentative address.
インタフェースに関する有効なNeighbor Solicitationメッセージを受け取り次第、ノードの振舞いはあて先アドレスが一時的であるかどうかよります。 あて先アドレスが一時的でないなら(すなわち、それは受信インタフェースに割り当てられます)、懇願は[RFC4861]で説明されるように処理されます。 あて先アドレスが一時的であり、ソースアドレスがユニキャストアドレスであるなら、懇願の送付者はアドレス解決を目標に実行しています。 懇願は静かに無視されるべきです。 さもなければ、処理は以下で説明されるように行われます。 すべての場合では、ノードは一時的なアドレスのためにNeighbor Solicitationに応じてはいけません。
If the source address of the Neighbor Solicitation is the unspecified address, the solicitation is from a node performing Duplicate Address Detection. If the solicitation is from another node, the tentative address is a duplicate and should not be used (by either node). If the solicitation is from the node itself (because the node loops back multicast packets), the solicitation does not indicate the presence of a duplicate address.
Neighbor Solicitationのソースアドレスが不特定のアドレスであるなら、懇願はDuplicate Address Detectionを実行するノードから来ています。 懇願が別のノードから来ているなら、一時的なアドレスを写しであり、使用するべきではありません(どちらかのノードで)。 懇願がノード自体から来ているなら(ノードが逆マルチキャストパケットを輪にするので)、懇願は写しアドレスの存在を示しません。
Thomson, et al. Standards Track [Page 15] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[15ページ]RFC4862IPv6
Implementer's Note: many interfaces provide a way for upper layers to selectively enable and disable the looping back of multicast packets. The details of how such a facility is implemented may prevent Duplicate Address Detection from working correctly. See Appendix A for further discussion.
Implementerの注意: 多くのインタフェースが上側の層が選択的にマルチキャストパケットのループを可能にして、無効にする方法を提供します。 そのような施設がどう実装されるかに関する詳細は、Duplicate Address Detectionが正しく働いているのを防ぐかもしれません。 さらなる議論に関してAppendix Aを見てください。
The following tests identify conditions under which a tentative address is not unique:
以下のテストは一時的なアドレスがユニークでない状態を特定します:
- If a Neighbor Solicitation for a tentative address is received
before one is sent, the tentative address is a duplicate. This
condition occurs when two nodes run Duplicate Address Detection
simultaneously, but transmit initial solicitations at different
times (e.g., by selecting different random delay values before
joining the solicited-node multicast address and transmitting an
initial solicitation).
- 1つを送る前に一時的なアドレスのためのNeighbor Solicitationが受け取られているなら、一時的なアドレスは写しです。 2つのノードが同時にDuplicate Address Detectionを実行するとき、この状態は現れますが、いろいろな時間(例えば、請求されたノードマルチキャストアドレスを接合して、初期の懇願を伝える前に異なった無作為の遅れ値を選択するのによる)に初期の懇願を伝えてください。
- If the actual number of Neighbor Solicitations received exceeds
the number expected based on the loopback semantics (e.g., the
interface does not loop back the packet, yet one or more
solicitations was received), the tentative address is a duplicate.
This condition occurs when two nodes run Duplicate Address
Detection simultaneously and transmit solicitations at roughly the
same time.
- 受け取られたNeighbor Solicitationsの実数がループバック意味論に基づいて予想された数を超えているなら(例えば、インタフェースはパケットを輪にし返しません、しかし、1つ以上の懇願を受けました)、一時的なアドレスは写しです。 2つのノードが同時に、Duplicate Address Detectionを実行して、およそ同時に懇願を伝えるとき、この状態は現れます。
5.4.4. Receiving Neighbor Advertisement Messages
5.4.4. 隣人広告メッセージを受け取ります。
On receipt of a valid Neighbor Advertisement message on an interface, node behavior depends on whether the target address is tentative or matches a unicast or anycast address assigned to the interface:
インタフェースに関する有効なNeighbor Advertisementメッセージを受け取り次第、ノードの振舞いは、あて先アドレスが一時的であるかどうかよるか、またはインタフェースに割り当てられたユニキャストかanycastアドレスに合っています:
1. If the target address is tentative, the tentative address is not
unique.
1. あて先アドレスが一時的であるなら、一時的なアドレスはユニークではありません。
2. If the target address matches a unicast address assigned to the
receiving interface, it would possibly indicate that the address
is a duplicate but it has not been detected by the Duplicate
Address Detection procedure (recall that Duplicate Address
Detection is not completely reliable). How to handle such a case
is beyond the scope of this document.
2. あて先アドレスが受信インタフェースに割り当てられたユニキャストアドレスに合っているなら、アドレスが写しであることをことによると示すでしょうが、それはDuplicate Address Detection手順によって検出されていません(Duplicate Address Detectionが完全に信頼できるというわけではないと思い出してください)。 どうそのような場合を扱うかはこのドキュメントの範囲を超えています。
3. Otherwise, the advertisement is processed as described in
[RFC4861].
3. さもなければ、広告は[RFC4861]で説明されるように処理されます。
Thomson, et al. Standards Track [Page 16] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[16ページ]RFC4862IPv6
5.4.5. When Duplicate Address Detection Fails
5.4.5. 写しアドレス検出が失敗する場合
A tentative address that is determined to be a duplicate as described above MUST NOT be assigned to an interface, and the node SHOULD log a system management error.
上で説明されるように写しであることを決定している一時的なアドレスをインタフェースに割り当ててはいけません、そして、ノードSHOULDはシステム管理誤りを登録します。
If the address is a link-local address formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP operation on the interface SHOULD be disabled. By disabling IP operation, the node will then:
アドレスがインタフェース識別子から形成されたリンクローカルアドレスであるなら、ハードウェア・アドレスに基づいて無効にされてください。(例えば、イーサネットインタフェースへのEUI-64)、IP操作はハードウェア・アドレスによって唯一インタフェースSHOULDに割り当てられるべきです。 IP操作を無効にすることによって、ノードはそしてそうするでしょう:
- not send any IP packets from the interface,
- インタフェースからあらゆるIPパケットを送ってください。
- silently drop any IP packets received on the interface, and
- そして静かにインタフェースに受け取られたあらゆるIPパケットを下げてください。
- not forward any IP packets to the interface (when acting as a
router or processing a packet with a Routing header).
- インタフェース(ルータとして機能するか、またはルート設定ヘッダーと共にパケットを処理するとき)にどんなIPパケットも送りません。
In this case, the IP address duplication probably means duplicate hardware addresses are in use, and trying to recover from it by configuring another IP address will not result in a usable network. In fact, it probably makes things worse by creating problems that are harder to diagnose than just disabling network operation on the interface; the user will see a partially working network where some things work, and other things do not.
この場合、IPアドレス複製は、たぶん写しハードウェアアドレスが使用中であることを意味します、そして、それから別のIPアドレスを構成することによって回復しようとするのは使用可能なネットワークをもたらさないでしょう。 事実上、たぶん、インタフェースでただネットワーク操作を無効にするより診断しにくい問題を生じさせることによって、事態をより悪くします。 ユーザはいくつかのものが働いていて、他のものが働いていない部分的に働くネットワークを見るでしょう。
On the other hand, if the duplicate link-local address is not formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned, IP operation on the interface MAY be continued.
他方では、写しリンクローカルアドレスが唯一割り当てられるべきであるハードウェア・アドレスに基づくインタフェース識別子から形成されないなら、インタフェースにおけるIP操作は続けられるかもしれません。
Note: as specified in Section 2, "IP" means "IPv6" in the above description. While the background rationale about hardware address is independent of particular network protocols, its effect on other protocols is beyond the scope of this document.
以下に注意してください。 セクション2で指定されるように、「IP」は「上の記述におけるIPv6"」を意味します。 ハードウェア・アドレスに関するバックグラウンド原理は特定のネットワーク・プロトコルから独立していますが、他のプロトコルへの効果はこのドキュメントの範囲を超えています。
5.5. Creation of Global Addresses
5.5. グローバルなアドレスの作成
Global addresses are formed by appending an interface identifier to a prefix of appropriate length. Prefixes are obtained from Prefix Information options contained in Router Advertisements. Creation of global addresses as described in this section SHOULD be locally configurable. However, the processing described below MUST be enabled by default.
グローバルなアドレスは、適切な長さの接頭語にインタフェース識別子を追加することによって、形成されます。 Router Advertisementsに含まれたPrefix情報オプションから接頭語を得ます。 グローバルの作成は説明されるとしてこのセクションでSHOULDを扱います。局所的に構成可能であってください。 しかしながら、デフォルトで以下で説明された処理を可能にしなければなりません。
Thomson, et al. Standards Track [Page 17] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[17ページ]RFC4862IPv6
5.5.1. Soliciting Router Advertisements
5.5.1. ルータ通知に請求します。
Router Advertisements are sent periodically to the all-nodes multicast address. To obtain an advertisement quickly, a host sends out Router Solicitations as described in [RFC4861].
定期的にオールノードマルチキャストアドレスにルータAdvertisementsを送ります。 すぐに広告を得るために、ホストは[RFC4861]で説明されるようにRouter Solicitationsを出します。
5.5.2. Absence of Router Advertisements
5.5.2. ルータ通知の欠如
Even if a link has no routers, the DHCPv6 service to obtain addresses may still be available, and hosts may want to use the service. From the perspective of autoconfiguration, a link has no routers if no Router Advertisements are received after having sent a small number of Router Solicitations as described in [RFC4861].
リンクにルータが全くなくても、アドレスを得るDHCPv6サービスはまだ利用可能であるかもしれません、そして、ホストはサービスを利用したがっているかもしれません。 自動構成の見解から、[RFC4861]で説明されるようにRouter Solicitationsの少ない数を送った後にRouter Advertisementsを全く受け取らないなら、リンクにはルータが全くありません。
Note that it is possible that there is no router on the link in this sense, but there is a node that has the ability to forward packets. In this case, the forwarding node's address must be manually configured in hosts to be able to send packets off-link, since the only mechanism to configure the default router's address automatically is the one using Router Advertisements.
この意味で、リンクの上にルータが全くないのが、可能であることに注意しなさい、ただし、パケットを進める能力を持っているノードがあります。 この場合、パケットオフリンクを送ることができるようにホストで手動で推進ノードのアドレスを構成しなければなりません、自動的にデフォルトルータのアドレスを構成する唯一のメカニズムがRouter Advertisementsを使用するものであるので。
5.5.3. Router Advertisement Processing
5.5.3. ルータ通知処理
For each Prefix-Information option in the Router Advertisement:
Router AdvertisementのそれぞれのPrefix-情報オプションのために:
a) If the Autonomous flag is not set, silently ignore the Prefix
Information option.
a) Autonomous旗が設定されないなら、静かにPrefix情報オプションを無視してください。
b) If the prefix is the link-local prefix, silently ignore the
Prefix Information option.
b) 接頭語がリンクローカルの接頭語であるなら、静かにPrefix情報オプションを無視してください。
c) If the preferred lifetime is greater than the valid lifetime,
silently ignore the Prefix Information option. A node MAY wish to
log a system management error in this case.
c) 都合のよい寿命が有効な生涯より大きいなら、静かにPrefix情報オプションを無視してください。 ノードはこの場合システム管理誤りを登録したがっているかもしれません。
d) If the prefix advertised is not equal to the prefix of an
address configured by stateless autoconfiguration already in the
list of addresses associated with the interface (where "equal"
means the two prefix lengths are the same and the first prefix-
length bits of the prefixes are identical), and if the Valid
Lifetime is not 0, form an address (and add it to the list) by
combining the advertised prefix with an interface identifier of
the link as follows:
d) 広告に掲載された接頭語がインタフェース(「同輩」が2つの接頭語の長さが同じであり、接頭語の最初接頭語の長さのビットが同じであることを意味するところ)に関連している住所録において状態がない自動構成によって既に構成されたアドレスの接頭語と等しくなく、またValid Lifetimeが0歳でないなら、リンクのインタフェース識別子は以下の通りで広告を出している接頭語を結合することによって、アドレス(それをリストに追加する)を形成してください:
| 128 - N bits | N bits |
+---------------------------------------+------------------------+
| link prefix | interface identifier |
+----------------------------------------------------------------+
| 128--Nビット| Nビット| +---------------------------------------+------------------------+ | リンク接頭語| インタフェース識別子| +----------------------------------------------------------------+
Thomson, et al. Standards Track [Page 18] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[18ページ]RFC4862IPv6
If the sum of the prefix length and interface identifier length
does not equal 128 bits, the Prefix Information option MUST be
ignored. An implementation MAY wish to log a system management
error in this case. The length of the interface identifier is
defined in a separate link-type specific document, which should
also be consistent with the address architecture [RFC4291] (see
Section 2).
接頭語の長さとインタフェース識別子の長さの合計が128ビットと等しくないなら、Prefix情報オプションを無視しなければなりません。 実装はこの場合システム管理誤りを登録したがっているかもしれません。 インタフェース識別子の長さは別々のリンク型特定のドキュメントで定義されます(セクション2を見てください)。(また、それも、アドレス体系[RFC4291]と一致しているべきです)。
It is the responsibility of the system administrator to ensure
that the lengths of prefixes contained in Router Advertisements
are consistent with the length of interface identifiers for that
link type. It should be noted, however, that this does not mean
the advertised prefix length is meaningless. In fact, the
advertised length has non-trivial meaning for on-link
determination in [RFC4861] where the sum of the prefix length and
the interface identifier length may not be equal to 128. Thus, it
should be safe to validate the advertised prefix length here, in
order to detect and avoid a configuration error specifying an
invalid prefix length in the context of address autoconfiguration.
そのリンク型にとって、Router Advertisementsに含まれた接頭語の長さがインタフェース識別子の長さと一致しているのを保証するのは、システム管理者の責任です。 しかしながら、これが、広告を出している接頭語の長さが無意味であることを意味しないことに注意されるべきです。 事実上、広告を出している長さは接頭語の長さとインタフェース識別子の長さの合計が128と等しくないかもしれない[RFC4861]にリンクにおける決断のための重要な意味を持っています。 したがって、ここで広告を出している接頭語の長さを有効にするのは安全であるべきです、アドレス自動構成の文脈の無効の接頭語の長さを指定する構成誤りを検出して、避けるために。
Note that a future revision of the address architecture [RFC4291]
and a future link-type-specific document, which will still be
consistent with each other, could potentially allow for an
interface identifier of length other than the value defined in the
current documents. Thus, an implementation should not assume a
particular constant. Rather, it should expect any lengths of
interface identifiers.
[RFC4291]と将来のリンクタイプ詳細ドキュメント(まだ互いと一致している)が値以外の長さに関するインタフェース識別子のために潜在的に許容できたアドレス体系の今後の改正が中で現在のドキュメントを定義したことに注意してください。 したがって、実装は特定の定数を仮定するべきではありません。 むしろ、それはどんな長さに関するインタフェース識別子も予想するべきです。
If an address is formed successfully and the address is not yet in
the list, the host adds it to the list of addresses assigned to
the interface, initializing its preferred and valid lifetime
values from the Prefix Information option. Note that the check
against the prefix performed at the beginning of this step cannot
always detect the address conflict in the list. It could be
possible that an address already in the list, configured either
manually or by DHCPv6, happens to be identical to the newly
created address, whereas such a case should be atypical.
アドレスが首尾よく形成されて、アドレスがまだリストにないなら、ホストはインタフェースに割り当てられた住所録にそれを追加します、Prefix情報オプションから都合のよくて有効な生涯値を初期化して。 このステップの始めに実行された接頭語に対するチェックがいつもリストにおけるアドレス闘争を検出できるというわけではないことに注意してください。 既にリストの手動かDHCPv6によって構成されたアドレスがたまたま新たに作成されたアドレスと同じであるのが、可能であるかもしれませんが、そのような場合は非定型的であるべきです。
e) If the advertised prefix is equal to the prefix of an address
configured by stateless autoconfiguration in the list, the
preferred lifetime of the address is reset to the Preferred
Lifetime in the received advertisement. The specific action to
perform for the valid lifetime of the address depends on the Valid
Lifetime in the received advertisement and the remaining time to
the valid lifetime expiration of the previously autoconfigured
address. We call the remaining time "RemainingLifetime" in the
following discussion:
e) 広告を出している接頭語がリストでの状態がない自動構成によって構成されたアドレスの接頭語と等しいなら、アドレスの都合のよい寿命は受け取られていている広告におけるPreferred Lifetimeにリセットされます。 アドレスの有効な生涯実行する特定の動作は以前に自動構成されたアドレスの有効な生涯満了への受け取られていている広告と残っている時間でValid Lifetimeによります。 私たちは、以下の議論で残っている時間を"RemainingLifetime"と呼びます:
Thomson, et al. Standards Track [Page 19] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[19ページ]RFC4862IPv6
1. If the received Valid Lifetime is greater than 2 hours or
greater than RemainingLifetime, set the valid lifetime of the
corresponding address to the advertised Valid Lifetime.
1. 容認されたValid LifetimeがRemainingLifetimeより2時間以上であるなら、対応するアドレスの有効な生涯を広告を出しているValid Lifetimeに決めてください。
2. If RemainingLifetime is less than or equal to 2 hours, ignore
the Prefix Information option with regards to the valid
lifetime, unless the Router Advertisement from which this
option was obtained has been authenticated (e.g., via Secure
Neighbor Discovery [RFC3971]). If the Router Advertisement
was authenticated, the valid lifetime of the corresponding
address should be set to the Valid Lifetime in the received
option.
2. RemainingLifetimeが2時間以下であるなら、有効な生涯まであいさつによるPrefix情報オプションを無視してください、このオプションが得られたRouter Advertisementが認証されていない場合(例えば、Secure Neighborディスカバリー[RFC3971]で)。 Router Advertisementが認証されるなら、対応するアドレスの有効な寿命は容認されたオプションでValid Lifetimeに決められるでしょうに。
3. Otherwise, reset the valid lifetime of the corresponding
address to 2 hours.
3. さもなければ、2時間まで対応するアドレスの有効な生涯をリセットしてください。
The above rules address a specific denial-of-service attack in
which a bogus advertisement could contain prefixes with very small
Valid Lifetimes. Without the above rules, a single
unauthenticated advertisement containing bogus Prefix Information
options with short Valid Lifetimes could cause all of a node's
addresses to expire prematurely. The above rules ensure that
legitimate advertisements (which are sent periodically) will
"cancel" the short Valid Lifetimes before they actually take
effect.
上の規則は、非常に小さいValid Lifetimesと共に特定のサービスの否認がにせの広告が接頭語を含むことができた攻撃であると扱います。 上の規則がなければ、シングルはノードのアドレスのすべてが早まって短いValid Lifetimesと共ににせのPrefix情報オプションを含むのに吐き出すことができた広告を非認証しました。 上の規則は、彼らが実際に効く前に正統の広告(定期的に送られる)が短いValid Lifetimesを「取り消すこと」を確実にします。
Note that the preferred lifetime of the corresponding address is
always reset to the Preferred Lifetime in the received Prefix
Information option, regardless of whether the valid lifetime is
also reset or ignored. The difference comes from the fact that
the possible attack for the preferred lifetime is relatively
minor. Additionally, it is even undesirable to ignore the
preferred lifetime when a valid administrator wants to deprecate a
particular address by sending a short preferred lifetime (and the
valid lifetime is ignored by accident).
有効な寿命がまた、リセットされるか、または無視されることにかかわらず対応するアドレスの都合のよい寿命が容認されたPrefix情報オプションでPreferred Lifetimeにいつもリセットされることに注意してください。 違いは都合のよい生涯のための可能な攻撃が比較的小さい方であるという事実から来ます。 さらに、有効な管理者が短い都合のよい生涯を送ることによって特定のアドレスを非難したがっているときの(有効な寿命は偶然に無視されます)都合のよい生涯を無視するのは望ましくありませんさえある。
5.5.4. Address Lifetime Expiry
5.5.4. アドレス生涯満期
A preferred address becomes deprecated when its preferred lifetime expires. A deprecated address SHOULD continue to be used as a source address in existing communications, but SHOULD NOT be used to initiate new communications if an alternate (non-deprecated) address of sufficient scope can easily be used instead.
都合のよい寿命が期限が切れると、都合のよいアドレスは推奨しなくなります。 推奨しないアドレスSHOULDは、しかし、既存のコミュニケーション、SHOULD NOTのソースアドレスとして使用され続けています。新しいコミュニケーションを開始するために、代わりに容易に十分な範囲の代替の(非推奨しない)アドレスを使用できるなら、使用されます。
Note that the feasibility of initiating new communication using a non-deprecated address may be an application-specific decision, as only the application may have knowledge about whether the (now) deprecated address was (or still is) in use by the application. For
非推奨しないアドレスを使用することで新しいコミュニケーションを開始することに関する実現の可能性がアプリケーション特有の決定であるかもしれないことに注意してください、(現在)推奨しないアドレスがアプリケーションで使用中であったかに関して(または、まだ、あります)アプリケーションだけが心得があるとき。 for
Thomson, et al. Standards Track [Page 20] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[20ページ]RFC4862IPv6
example, if an application explicitly specifies that the protocol stack use a deprecated address as a source address, the protocol stack must accept that; the application might request it because that IP address is used in higher-level communication and there might be a requirement that the multiple connections in such a grouping use the same pair of IP addresses.
例、アプリケーションが、プロトコル・スタックがソースアドレスとして推奨しないアドレスを使用すると明らかに指定するなら、プロトコル・スタックはそれを受け入れなければなりません。 そのIPアドレスが、よりハイレベルのコミュニケーションで使用されて、そのような組分けにおける複数の接続がIPアドレスの同じ組を使用するという要件があるかもしれないので、アプリケーションはそれを要求するかもしれません。
IP and higher layers (e.g., TCP, UDP) MUST continue to accept and process datagrams destined to a deprecated address as normal since a deprecated address is still a valid address for the interface. In the case of TCP, this means TCP SYN segments sent to a deprecated address are responded to using the deprecated address as a source address in the corresponding SYN-ACK (if the connection would otherwise be allowed).
IPと、より高い層(例えば、TCP、UDP)は、受け入れ続けなければなりません、そして、プロセスデータグラムは、それでも、推奨しないアドレスがインタフェースへの有効なアドレスであるので、正常な推奨しない同じくらいアドレスに運命づけられました。 TCPの場合では、これは、推奨しないアドレスに送られたTCP SYNセグメントが対応するSYN-ACKのソースアドレスとして推奨しないアドレスを使用すると反応することを(接続が別の方法で許されているなら)意味します。
An implementation MAY prevent any new communication from using a deprecated address, but system management MUST have the ability to disable such a facility, and the facility MUST be disabled by default.
システム管理には、そのような施設を無効にする能力がなければなりません、そして、実装は、どんな新しいコミュニケーションも推奨しないアドレスを使用するのを防ぐかもしれませんが、デフォルトで施設を無効にしなければなりません。
Other subtle cases should also be noted about source address selection. For example, the above description does not clarify which address should be used between a deprecated, smaller-scope address and a non-deprecated, sufficient scope address. The details of the address selection including this case are described in [RFC3484] and are beyond the scope of this document.
また、他の微妙なケースはソースアドレス選択に関して注意されるべきです。 例えば、上の記述は、どのアドレスが推奨しないアドレスと、より小さい範囲アドレスと、非推奨しなくて、十分な範囲アドレスの間で使用されるべきであるかをはっきりさせません。 本件を含むアドレス選択の詳細は、[RFC3484]で説明されて、このドキュメントの範囲を超えています。
An address (and its association with an interface) becomes invalid when its valid lifetime expires. An invalid address MUST NOT be used as a source address in outgoing communications and MUST NOT be recognized as a destination on a receiving interface.
有効な寿命が期限が切れると、アドレス(そして、インタフェースとの協会)は無効になります。 無効のアドレスを、ソースアドレスとして送信するコミュニケーションで使用してはいけなくて、目的地として受信インタフェースで認識してはいけません。
5.6. Configuration Consistency
5.6. 構成の一貫性
It is possible for hosts to obtain address information using both stateless autoconfiguration and DHCPv6 since both may be enabled at the same time. It is also possible that the values of other configuration parameters, such as MTU size and hop limit, will be learned from both Router Advertisements and DHCPv6. If the same configuration information is provided by multiple sources, the value of this information should be consistent. However, it is not considered a fatal error if information received from multiple sources is inconsistent. Hosts accept the union of all information received via Neighbor Discovery and DHCPv6.
ホストが両方が同時に可能にされるかもしれないので状態がない自動構成とDHCPv6の両方を使用するアドレス情報を得るのは、可能です。 また、MTUサイズやホップ限界などの他の設定パラメータの値がRouter AdvertisementsとDHCPv6の両方から学習されるのも、可能です。 同じ設定情報が複数のソースによって提供されるなら、この情報の値は一貫しているべきです。 しかしながら、複数のソースから受け取られた情報が矛盾しているなら、それは致命的な誤りであると考えられません。 ホストはNeighborディスカバリーとDHCPv6を通して受け取られたすべての情報の組合を受け入れます。
If inconsistent information is learned from different sources, an implementation may want to give information learned securely precedence over information learned without protection. For
矛盾した情報がさまざまな原因から学習されるなら、実装はしっかりと学習されて、情報の上の先行が保護なしで学んだという情報を教えたがっているかもしれません。 for
Thomson, et al. Standards Track [Page 21] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[21ページ]RFC4862IPv6
instance, Section 8 of [RFC3971] discusses how to deal with information learned through Secure Neighbor Discovery conflicting with information learned through plain Neighbor Discovery. The same discussion can apply to the preference between information learned through plain Neighbor Discovery and information learned via secured DHCPv6, and so on.
インスタンス、[RFC3971]のセクション8は明瞭なNeighborディスカバリーを通して学習される情報と闘争しながらSecure Neighborディスカバリーを通して学習された情報に対処する方法について議論します。 明瞭なNeighborディスカバリーを通して学習された情報と機密保護しているDHCPv6を通して学習された情報の間などに同じ議論は好みに適用できます。
In any case, if there is no security difference, the most recently obtained values SHOULD have precedence over information learned earlier.
どのような場合でも、セキュリティ差が全くなければ、大部分は最近、より早く情報学術的にSHOULDが先行を持っている値を得ました。
5.7. Retaining Configured Addresses for Stability
5.7. 安定性のための保有の構成されたアドレス
An implementation that has stable storage may want to retain addresses in the storage when the addresses were acquired using stateless address autoconfiguration. Assuming the lifetimes used are reasonable, this technique implies that a temporary outage (less than the valid lifetime) of a router will never result in losing a global address of the node even if the node were to reboot. When this technique is used, it should also be noted that the expiration times of the preferred and valid lifetimes must be retained, in order to prevent the use of an address after it has become deprecated or invalid.
状態がないアドレス自動構成を使用することでアドレスを習得したとき、安定貯蔵を持っている実装はストレージにおけるアドレスを保有したがっているかもしれません。 費やされた寿命が妥当であると仮定して、このテクニックは、ルータの一時的な供給停止(有効な生涯よりそれほど)がノードがリブートすることであったならノードのグローバルアドレスを失うのに決して結果として生じないのを含意します。 また、このテクニックが使用されているとき、都合のよくて有効な生涯の満了倍を保有しなければならないことに注意されるべきです、推奨しないか無効になった後にアドレスの使用を防ぐために。
Further details on this kind of extension are beyond the scope of this document.
この種類の拡大に関する詳細はこのドキュメントの範囲を超えています。
6. Security Considerations
6. セキュリティ問題
Stateless address autoconfiguration allows a host to connect to a network, configure an address, and start communicating with other nodes without ever registering or authenticating itself with the local site. Although this allows unauthorized users to connect to and use a network, the threat is inherently present in the Internet architecture. Any node with a physical attachment to a network can generate an address (using a variety of ad hoc techniques) that provides connectivity.
状態がないアドレス自動構成で、ローカル・サイトでそれ自体を登録するか、または認証しないで、ホストをネットワークに接続して、アドレスを構成して、他のノードとコミュニケートし始めます。 権限のないユーザは、これで、ネットワークを接続して、使用しますが、脅威は本来インターネットアーキテクチャで存在しています。 ネットワークへの物理的な付属のどんなノードも接続性を提供するアドレス(さまざまな臨時のテクニックを使用する)を作ることができます。
The use of stateless address autoconfiguration and Duplicate Address Detection opens up the possibility of several denial-of-service attacks. For example, any node can respond to Neighbor Solicitations for a tentative address, causing the other node to reject the address as a duplicate. A separate document [RFC3756] discusses details about these attacks, which can be addressed with the Secure Neighbor Discovery protocol [RFC3971]. It should also be noted that [RFC3756] points out that the use of IP security is not always feasible depending on network environments.
状態がないアドレスの自動構成とDuplicate Address Detectionの使用はいくつかのサービス不能攻撃の可能性を開けます。 例えば、どんなノードも一時的なアドレスのためにNeighbor Solicitationsに応じることができます、もう片方のノードが写しとしてアドレスを拒絶することを引き起こして。 別々のドキュメント[RFC3756]はこれらの攻撃に関する詳細について議論します。(Secure Neighborディスカバリープロトコル[RFC3971]で攻撃を扱うことができます)。 また、[RFC3756]が、ネットワーク環境によって、IPセキュリティの使用がいつも可能であるというわけではないと指摘することに注意されるべきです。
Thomson, et al. Standards Track [Page 22] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[22ページ]RFC4862IPv6
7. Acknowledgements
7. 承認
Thomas Narten and Susan Thompson were the authors of RFCs 1971 and 2462. For this revision of the RFC, Tatuya Jinmei was the sole editor.
トーマスNartenとスーザントンプソンはRFCs1971と2462年の作者でした。 RFCのこの改正のために、Tatuya Jinmeiは唯一のエディタでした。
The authors of RFC 2461 would like to thank the members of both the IPNG (which is now IPV6) and ADDRCONF working groups for their input. In particular, thanks to Jim Bound, Steve Deering, Richard Draves, and Erik Nordmark. Thanks also goes to John Gilmore for alerting the WG of the "0 Lifetime Prefix Advertisement" denial-of-service attack vulnerability; this document incorporates changes that address this vulnerability.
RFC2461の作者はIPNG(現在、IPV6である)と彼らの入力のためのADDRCONFワーキンググループの両方のメンバーに感謝したがっています。 特に、ジムBound、スティーブ・デアリング、リチャードDraves、およびエリックNordmarkをありがとうございます。 また、感謝は「0生涯接頭語広告」サービス不能攻撃脆弱性のWGを警告するためにジョン・ギルモアのものになります。 このドキュメントはこの脆弱性を扱う変化を取り入れます。
A number of people have contributed to identifying issues with RFC 2461 and to proposing resolutions to the issues as reflected in this version of the document. In addition to those listed above, the contributors include Jari Arkko, James Carlson, Brian E. Carpenter, Gregory Daley, Elwyn Davies, Ralph Droms, Jun-ichiro Itojun Hagino, Christian Huitema, Suresh Krishnan, Soohong Daniel Park, Markku Savela, Pekka Savola, Hemant Singh, Bernie Volz, Margaret Wasserman, and Vlad Yasevich.
多くの人々がドキュメントのこのバージョンに反映されるようにRFC2461と問題を同一視することと、そして、問題に解決を提案することに貢献しました。 上に記載されたものに加えて、貢献者はヤリArkko、ジェームス・カールソン、ブライアンE.Carpenter、グレゴリー・デイリー、Elwynデイヴィース、ラルフDroms、6月-ichiro Itojun Hagino、クリスチャンのHuitema、Sureshクリシュナン、SoohongダニエルPark、マルックSavela、ペッカSavola、Hemantシン、バーニー・フォルツ、マーガレット・ワッサーマン、およびヴラドYasevichを入れます。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[RFC2464] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4861] Narten、T.、Nordmark、E.、シンプソン、W.、およびH.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。
8.2. Informative References
8.2. 有益な参照
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
Thomson, et al. Standards Track [Page 23] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[23ページ]RFC4862IPv6
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R.、およびS.クリシュナン、「IPv6"、RFC4941、2007年9月の状態がないアドレス自動構成のためのプライバシー拡大。」
[RFC3972] Aura, T., "Cryptographically Generated Addresses
(CGA)", RFC 3972, March 2005.
[RFC3972] 香気、T.、「アドレス(CGA)であると暗号で生成された」RFC3972、2005年3月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC2710] デアリング、S.、フェナー、W.、およびB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
そして、[RFC3810]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[RFC3590] Haberman, B., "Source Address Selection for the
Multicast Listener Discovery (MLD) Protocol", RFC 3590,
September 2003.
[RFC3590]ハーバーマン、B.、「マルチキャストリスナー発見(MLD)プロトコルのためのソースアドレス選択」、RFC3590、2003年9月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
March 2005.
[RFC3971] ArkkoとJ.とケンフとJ.とZill、B.とP.Nikander、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, May 2004.
[RFC3756] Nikander、P.、ケンフ、J.、およびE.Nordmark、「IPv6隣人発見(ノースダコタ)信頼モデルと脅威」(RFC3756)は2004がそうするかもしれません。
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[IEEE802.11] IEEE, "Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", ANSI/IEEE
STd 802.11, August 1999.
[IEEE802.11]IEEE、「ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様」、ANSI/IEEE STd802.11、1999年8月。
Thomson, et al. Standards Track [Page 24] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[24ページ]RFC4862IPv6
Appendix A. Loopback Suppression and Duplicate Address Detection
付録A.ループバック抑圧と写しアドレス検出
Determining whether a received multicast solicitation was looped back to the sender or actually came from another node is implementation- dependent. A problematic case occurs when two interfaces attached to the same link happen to have the same identifier and link-layer address, and they both send out packets with identical contents at roughly the same time (e.g., Neighbor Solicitations for a tentative address as part of Duplicate Address Detection messages). Although a receiver will receive both packets, it cannot determine which packet was looped back and which packet came from the other node simply by comparing packet contents (i.e., the contents are identical). In this particular case, it is not necessary to know precisely which packet was looped back and which was sent by another node; if one receives more solicitations than were sent, the tentative address is a duplicate. However, the situation may not always be this straightforward.
容認されたマルチキャスト懇願が送付者に輪にして戻られたか、または実際に別のノードから来たかを決定するのは実装に依存しています。 同じリンクに付けられた2つのインタフェースがたまたま同じ識別子とリンクレイヤアドレスを持っていると、問題の多いケースは現れます、そして、それらの両方がおよそ同時(例えば、Duplicate Address Detectionメッセージの一部としての一時的なアドレスのためのNeighbor Solicitations)に同じコンテンツがあるパケットを出します。 受信機は両方のパケットを受けるでしょうが、それはどのパケットが輪にし返されたか、そして、どのパケットがもう片方のノードから単にパケットコンテンツを比較することによって来たかを決定できません(すなわち、内容は同じです)。 この場合は、どのパケットが輪にし返されたか、そして、どれが別のノードによって送られたかを正確に知るのは必要ではありません。 1つが送ったより多くの懇願を受けるなら、一時的なアドレスは写しです。 しかしながら、これが簡単であったなら、状況はいつもそうするかもしれないというわけではありません。
The IPv4 multicast specification [RFC1112] recommends that the service interface provide a way for an upper-layer protocol to inhibit local delivery of packets sent to a multicast group that the sending host is a member of. Some applications know that there will be no other group members on the same host, and suppressing loopback prevents them from having to receive (and discard) the packets they themselves send out. A straightforward way to implement this facility is to disable loopback at the hardware level (if supported by the hardware), with packets looped back (if requested) by software. On interfaces in which the hardware itself suppresses loopbacks, a node running Duplicate Address Detection simply counts the number of Neighbor Solicitations received for a tentative address and compares them with the number expected. If there is a mismatch, the tentative address is a duplicate.
仕様[RFC1112]が推薦するサービスインタフェースが上側の層のプロトコルがマルチキャストグループに送られた地方のパケットの配信を抑制する送付ホストがそうである方法をメンバーに提供するIPv4マルチキャスト。 いくつかのアプリケーションが、他のグループのメンバーが全く同じホストの上にいないのを知っています、そして、ループバックを抑圧するのは自分達がそれら自体が出すパケットを受けなければならないのを(捨ててください)防ぎます。 この施設を実装する簡単な方法はハードウェアレベルでループバックを無効にする(ハードウェアによってサポートされるなら)ことです、パケットが逆(要求されるなら)でソフトウェアによって輪にされている状態で。 ハードウェア自体がループバックを抑圧するインタフェースでは、単にDuplicate Address Detectionを実行するノードは、一時的なアドレスのために受け取られたNeighbor Solicitationsの数を数えて、予想される数と彼らを比較します。 ミスマッチがあれば、一時的なアドレスは写しです。
In those cases where the hardware cannot suppress loopbacks, however, one possible software heuristic to filter out unwanted loopbacks is to discard any received packet whose link-layer source address is the same as the receiving interface's. There is even a link-layer specification that requires that any such packets be discarded [IEEE802.11]. Unfortunately, use of that criteria also results in the discarding of all packets sent by another node using the same link-layer address. Duplicate Address Detection will fail on interfaces that filter received packets in this manner:
しかしながら、ハードウェアがループバックを抑圧できないそれらの場合では、求められていないループバックを無視する1つの可能なソフトウェアヒューリスティックはリンクレイヤソースアドレスが受信インタフェースのものと同じであるどんな容認されたパケットも捨てることです。 どんなそのようなパケットも捨てられるのを必要とするリンクレイヤ仕様[IEEE802.11]さえあります。 残念ながら、また、その評価基準の使用は、同じリンクレイヤアドレスを使用することで別のノードによって送られたすべてのパケットを捨てることをもたらします。 写しAddress Detectionはこの様に容認されたパケットをフィルターにかけるインタフェースで失敗するでしょう:
o If a node performing Duplicate Address Detection discards received
packets that have the same source link-layer address as the
receiving interface, it will also discard packets from other nodes
that also use the same link-layer address, including Neighbor
Advertisement and Neighbor Solicitation messages required to make
o また、Duplicate Address Detection破棄を実行するノードが受信インタフェースと同じソースリンクレイヤアドレスを持っているパケットを受けたなら、また、同じリンクレイヤアドレスを使用する他のノードからパケットを捨てるでしょう、作るのに必要なNeighbor AdvertisementとNeighbor Solicitationメッセージを含んでいて
Thomson, et al. Standards Track [Page 25] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[25ページ]RFC4862IPv6
Duplicate Address Detection work correctly. This particular
problem can be avoided by temporarily disabling the software
suppression of loopbacks while a node performs Duplicate Address
Detection, if it is possible to disable the suppression.
正しくAddress Detection仕事をコピーしてください。 ノードがDuplicate Address Detectionを実行している間、ソフトウェアがループバックの抑圧であると一時無効にすることによって、この特定の問題を避けることができます、抑圧を無効にするのが可能であるなら。
o If a node that is already using a particular IP address discards
received packets that have the same link-layer source address as
the interface, it will also discard Duplicate Address Detection-
related Neighbor Solicitation messages sent by another node that
also use the same link-layer address. Consequently, Duplicate
Address Detection will fail, and the other node will configure a
non-unique address. Since it is generally impossible to know when
another node is performing Duplicate Address Detection, this
scenario can be avoided only if software suppression of loopback
is permanently disabled.
o また、既に特定のIPアドレスを使用しているノードがインタフェースと同じリンクレイヤソースアドレスを持っている容認されたパケットを捨てると、それはまた、同じリンクレイヤアドレスを使用する別のノードによって送られたDuplicate Address Detectionの関連するNeighbor Solicitationメッセージを捨てるでしょう。 その結果、Duplicate Address Detectionは失敗するでしょう、そして、もう片方のノードは非ユニークなアドレスを構成するでしょう。 別のノードがいつDuplicate Address Detectionを実行しているかを知るのが一般に不可能であるので、ループバックのソフトウェア抑圧が永久に無効にされる場合にだけ、このシナリオを避けることができます。
Thus, to perform Duplicate Address Detection correctly in the case where two interfaces are using the same link-layer address, an implementation must have a good understanding of the interface's multicast loopback semantics, and the interface cannot discard received packets simply because the source link-layer address is the same as the interface's. It should also be noted that a link-layer specification can conflict with the condition necessary to make Duplicate Address Detection work.
したがって、単にソースリンクレイヤアドレスがインタフェースのものと同じであるので、2つのインタフェースが同じリンクレイヤアドレスを使用していて、実装にはインタフェースのマルチキャストループバック意味論の良い理解がなければならなくて、インタフェースが捨てられることができない場合で正しくDuplicate Address Detectionを実行するのはパケットを受けました。 また、リンクレイヤ仕様がDuplicate Address Detectionを働かせるのに必要な状態と衝突できることに注意されるべきです。
Appendix B. Changes since RFC 1971
RFC1971以来の付録B.変化
o Changed document to use term "interface identifier" rather than
"interface token" for consistency with other IPv6 documents.
o 一貫性に他のIPv6ドキュメントで「インタフェーストークン」よりむしろ「インタフェース識別子」という用語を使用するためにドキュメントを変えました。
o Clarified definition of deprecated address to make clear it is OK
to continue sending to or from deprecated addresses.
o それを明らかにする推奨しないアドレスのはっきりさせられた定義は、アドレス、または、推奨しないアドレスから発信し続けるためにOKです。
o Added rules to Section 5.5.3 Router Advertisement processing to
address potential denial-of-service attack when prefixes are
advertised with very short Lifetimes.
o 接頭語が非常に短いLifetimesと共に広告に掲載されているとき、潜在的サービス不能攻撃を扱うためにセクション5.5.3Router Advertisement処理に規則を加えました。
o Clarified wording in Section 5.5.4 to make clear that all upper
layer protocols must process (i.e., send and receive) packets sent
to deprecated addresses.
o すべての上側の層のプロトコルがパケットを処理しなければならないことを(すなわち、発信して、受信します)明らかにするセクション5.5.4におけるはっきりさせられた言葉遣いは推奨しないアドレスに発信しました。
Thomson, et al. Standards Track [Page 26] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[26ページ]RFC4862IPv6
Appendix C. Changes since RFC 2462
RFC2462以来の付録C.変化
Major changes that can affect existing implementations:
既存の実装に影響できる大きな変化:
o Specified that a node performing Duplicate Address Detection delay
joining the solicited-node multicast group, not just delay sending
Neighbor Solicitations, explaining the detailed reason.
o 詳細な理由について説明して、Duplicate Address Detectionを実行するノードが、Neighbor Solicitationsを送りながら遅れだけではなく、請求されたノードマルチキャストグループに加わるのを遅らせると指定しました。
o Added a requirement for a random delay before sending Neighbor
Solicitations for Duplicate Address Detection if the address being
checked is configured by a multicasted Router Advertisements.
o チェックされるアドレスがmulticasted Router Advertisementsによって構成されるならDuplicate Address DetectionのためにNeighbor Solicitationsを送る前に、無作為の遅れのための要件を加えました。
o Clarified that on failure of Duplicate Address Detection, IP
network operation should be disabled and that the rule should
apply when the hardware address is supposed to be unique.
o Duplicate Address Detection、ネットワーク操作が無効にされるべきであり、ハードウェア・アドレスが特有であるべきであるときに規則が当てはまるべきであるIPの失敗でそれをはっきりさせました。
Major clarifications:
主要な明確化:
o Clarified how the length of interface identifiers should be
determined, described the relationship with the prefix length
advertised in Router Advertisements, and avoided using a
particular length hard-coded in this document.
o インタフェース識別子の長さがどう決定しているべきであるかをはっきりさせて、Router Advertisementsに接頭語の長さの広告を出していて関係について説明して、特定の長さを使用するのをこのドキュメントで一生懸命コード化されていた状態で避けました。
o Clarified the processing of received neighbor advertisements while
performing Duplicate Address Detection.
o Duplicate Address Detectionを実行している間、受け取られていている隣人広告の処理をはっきりさせました。
o Removed the text regarding the M and O flags, considering the
maturity of implementations and operational experiences.
ManagedFlag and OtherConfigFlag were removed accordingly. (Note
that this change does not mean the use of these flags is
deprecated.)
o 実装と運用経験の円熟を考える場合、MとO旗に関するテキストを取り除きました。 ManagedFlagとOtherConfigFlagはそれに従って、取り外されました。 (この変化が、これらの旗の使用が推奨しないことを意味しないことに注意してください。)
o Avoided the wording of "stateful configuration", which is known to
be quite confusing, and simply used "DHCPv6" wherever appropriate.
o 全く紛らわしいのが知られて、単に使用される「stateful構成」の言葉遣いを避ける、「DHCPv6"、適切であるどこ」
o Recommended to perform Duplicate Address Detection for all unicast
addresses more strongly, considering a variety of different
interface identifiers, while keeping care of existing
implementations.
o 既存の実装の注意を保っている間、さまざまな異なったインタフェース識別子を考える場合、すべてのユニキャストアドレスのために、より強くDuplicate Address Detectionを実行することが勧められます。
o Clarified wording in Section 5.5.4 to make clear that a deprecated
address specified by an application can be used for any
communication.
o どんなコミュニケーションにも明らかにする推奨しないアドレスがアプリケーションで指定したセクション5.5.4におけるはっきりさせられた言葉遣いを使用できます。
o Clarified the prefix check described in Section 5.5.3 using more
appropriate terms and that the check is done against the prefixes
of addresses configured by stateless autoconfiguration.
o はっきりさせられて、接頭語チェックは、セクション5.5.3使用で以上が用語を当てて、状態がない自動構成によって構成されたアドレスの接頭語に対してチェックすると説明しました。
Thomson, et al. Standards Track [Page 27] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[27ページ]RFC4862IPv6
o Changed the references to the IP security Authentication Header to
references to RFC 3971 (Secure Neighbor Discovery). Also revised
the Security Considerations section with a reference to RFC 3756.
o IPセキュリティAuthentication Headerの参照をRFC3971(安全なNeighborディスカバリー)の参照に変えました。 また、RFC3756の参照でSecurity Considerations部を改訂しました。
o Added a note when an implementation uses stable storage for
autoconfigured addresses.
o 実装が自動構成されたアドレスに安定貯蔵を使用するとき、注意を加えました。
o Added consideration about preference between inconsistent
information sets, one from a secured source and the other learned
without protection.
o 矛盾した一組の情報の間の好みに関する加えられた考慮、機密保護しているソースからの1つ、およびもう片方が保護なしで学びました。
Other miscellaneous clarifications:
他の種々雑多な明確化:
o Removed references to site-local and revised wording around the
keyword.
o キーワードの周りのサイト地方の、そして、改訂された言葉遣いの参照を取り除きました。
o Removed redundant code in denial-of-service protection in
Section 5.5.3.
o セクション5.5.3におけるサービスの否定保護における冗長符号を取り除きました。
o Clarified that a unicasted Neighbor Solicitation or Advertisement
should be discarded while performing Duplicate Address Detection.
o はっきりさせられて、そのa unicasted Neighbor SolicitationかAdvertisementがDuplicate Address Detectionを実行している間、捨てられるべきです。
o Noted in Section 5.3 that an interface can be considered as
becoming enabled when a wireless access point changes.
o インタフェースをみなすことができるワイヤレス・アクセスポイントが変化すると可能にされるようになるセクション5.3では、有名です。
Thomson, et al. Standards Track [Page 28] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[28ページ]RFC4862IPv6
Authors' Addresses
作者のアドレス
Susan Thomson Cisco Systems
スーザントムソンシスコシステムズ
EMail: sethomso@cisco.com
メール: sethomso@cisco.com
Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA
トーマスNarten IBM社のP.O. Box12195リサーチトライアングル公園、NC27709-2195米国
Phone: +1 919-254-7798 EMail: narten@us.ibm.com
以下に電話をしてください。 +1 919-254-7798 メールしてください: narten@us.ibm.com
Tatuya Jinmei Corporate Research & Development Center, Toshiba Corporation 1 Komukai Toshiba-cho, Saiwai-ku Kawasaki-shi, Kanagawa 212-8582 Japan
Tatuya Jinmeiの法人の研究開発センター、東芝1Komukai東芝町、幸区川崎市、日本神奈川212-8582
Phone: +81 44-549-2230 EMail: jinmei@isl.rdc.toshiba.co.jp
以下に電話をしてください。 +81 44-549-2230 メールしてください: jinmei@isl.rdc.toshiba.co.jp
Thomson, et al. Standards Track [Page 29] RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007
トムソン、他 アドレス自動構成2007年9月に状態がない標準化過程[29ページ]RFC4862IPv6
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Thomson, et al. Standards Track [Page 30]
トムソン、他 標準化過程[30ページ]
一覧
スポンサーリンク
