RFC1971 日本語訳
1971 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. August 1996. (Format: TXT=56890 bytes) (Obsoleted by RFC2462) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Thomson
Request for Comments: 1971 Bellcore
Category: Standards Track T. Narten
IBM
August 1996
コメントを求めるワーキンググループS.トムソンの要求をネットワークでつないでください: 1971年のBellcoreカテゴリ: 標準化過程T.Narten IBM1996年8月
IPv6 Stateless Address Autoconfiguration
IPv6の状態がないアドレス自動構成
Status of this Memo
この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 creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere.
このドキュメントはIPバージョン6のインタフェースを自動構成する方法を決めるホストが見て取るステップを指定します。 自動構成プロセスは、リンクローカルアドレスを作成して、リンクの上にユニークさについて確かめるのを含んでいます、どんな情報が自動構成されるべきであるかを(アドレス、他の情報、または両方)決定して、アドレスの場合で、状態がないメカニズム、statefulメカニズム、または両方を通してそれらを得るべきであるか否かに関係なく。 このドキュメントは、リンクローカルアドレス、状態がないアドレス自動構成でサイト地方の、そして、グローバルなアドレスを作るためのプロセス、およびDuplicate Address Detection手順を生成するためにプロセスを定義します。 statefulプロトコルを使用する自動構成の詳細はほかの場所で指定されます。
Table of Contents
目次
1. INTRODUCTION............................................. 2
2. TERMINOLOGY.............................................. 4
2.1. Requirements........................................ 7
3. DESIGN GOALS............................................. 8
4. PROTOCOL OVERVIEW........................................ 9
4.1. Site Renumbering.................................... 11
5. PROTOCOL SPECIFICATION................................... 11
5.1. Node Configuration Variables........................ 12
5.2. Autoconfiguration-Related Variables................. 12
5.3. Creation of Link-Local Addresses.................... 13
5.4. Duplicate Address Detection......................... 13
5.4.1. Message Validation............................. 15
5.4.2. Sending Neighbor Solicitation Messages......... 15
5.4.3. Receiving Neighbor Solicitation Messages....... 15
1. 序論… 2 2. 用語… 4 2.1. 要件… 7 3. 目標を設計してください… 8 4. 概要について議定書の中で述べてください… 9 4.1. サイトの番号を付け替えること… 11 5. 仕様を議定書の中で述べてください… 11 5.1. ノード構成変数… 12 5.2. 自動構成関連の変数… 12 5.3. リンクローカルのアドレスの作成… 13 5.4. アドレス検出をコピーしてください… 13 5.4.1. メッセージ合法化… 15 5.4.2. 隣人懇願にメッセージを送ります… 15 5.4.3. 隣人懇願メッセージを受け取ります… 15
Thomson & Narten Standards Track [Page 1] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[1ページ]RFC1971IPv6
5.4.4. Receiving Neighbor Advertisement Messages...... 16
5.4.5. When Duplicate Address Detection Fails......... 16
5.5. Creation of Global and Site-Local Addresses......... 17
5.5.1. Soliciting Router Advertisements............... 17
5.5.2. Absence of Router Advertisements............... 17
5.5.3. Router Advertisement Processing................ 17
5.5.4. Address Lifetime Expiry........................ 19
5.6. Configuration Consistency........................... 19
SECURITY CONSIDERATIONS...................................... 19
REFERENCES................................................... 20
AUTHORS' ADDRESSES........................................... 21
APPENDIX: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION. 22
5.4.4. 隣人広告メッセージを受け取ります… 16 5.4.5. 写しアドレス検出が失敗すると… 16 5.5. グローバルでサイトローカルのアドレスの作成… 17 5.5.1. ルータ通知に請求します… 17 5.5.2. ルータ通知の欠如… 17 5.5.3. ルータ通知処理… 17 5.5.4. 生涯満期を扱ってください… 19 5.6. 構成の一貫性… 19 セキュリティ問題… 19の参照箇所… 20人の作者のアドレス… 21付録: ループバック抑圧と写しは検出を扱います。 22
1. INTRODUCTION
1. 序論
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere.
このドキュメントはIPバージョン6のインタフェースを自動構成する方法を決めるホストが見て取るステップを指定します。 自動構成プロセスは、リンクローカルアドレスを作成して、リンクの上にユニークさについて確かめるのを含んでいます、どんな情報が自動構成されるべきであるかを(アドレス、他の情報、または両方)決定して、アドレスの場合で、状態がないメカニズム、statefulメカニズム、または両方を通してそれらを得るべきであるか否かに関係なく。 このドキュメントは、リンクローカルアドレス、状態がないアドレス自動構成でサイト地方の、そして、グローバルなアドレスを作るためのプロセス、およびDuplicate Address Detection手順を生成するためにプロセスを定義します。 statefulプロトコルを使用する自動構成の詳細はほかの場所で指定されます。
IPv6 defines both a stateful and stateless address autoconfiguration mechanism. Stateless autoconfiguration 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 token" 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はstatefulであって状態がないアドレス自動構成メカニズムを定義します。 ルータの最小量(もしあれば)の構成を必要としますが、状態がない自動構成はホストを手動の構成がない、どんな追加サーバも必要としません。 状態がないメカニズムで、ホストはそれ自身のアドレスが局所的に利用可能な情報の組み合わせを使用して、ルータによって広告に掲載された情報であると生成することができます。 ルータはリンクに関連しているサブネットを特定する接頭語の広告を出します、ホストがサブネットで唯一インタフェースを特定する「インタフェーストークン」を生成しますが。 アドレスは、2を結合することによって、形成されます。 ルータがないとき、ホストはリンクローカルのアドレスを作ることができるだけです。 しかしながら、リンクローカルのアドレスは同じリンクに添付されたノードの中にコミュニケーションを許容するのに十分です。
In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a server. Servers maintain a database that keeps track of which addresses have been assigned to which hosts. The stateful autoconfiguration protocol allows hosts to obtain addresses, other configuration information or both from a server. Stateless and stateful autoconfiguration complement each other. For example, a host
stateful自動構成モデルでは、ホストはサーバからインターフェース・アドレス、そして/または、設定情報とパラメタを得ます。サーバはどのホストにアドレスを割り当ててある道を保つデータベースを維持します。 ホストはstateful自動構成プロトコルでサーバからアドレス、他の設定情報または両方を得ることができます。状態がなくてstatefulな自動構成は互いの補足となります。 例えば、ホスト
Thomson & Narten Standards Track [Page 2] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[2ページ]RFC1971IPv6
can use stateless autoconfiguration to configure its own addresses, but use stateful autoconfiguration to obtain other information. Stateful autoconfiguration is described in [DHCPv6].
それ自身のアドレスを構成するのに状態がない自動構成を使用できますが、stateful自動構成を使用して、他の情報を得てください。 Stateful自動構成は[DHCPv6]で説明されます。
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. The stateful approach is used when a site requires tighter control over exact address assignments. Both stateful and stateless address autoconfiguration may be used simultaneously. The site administrator specifies which type of autoconfiguration to use through the setting of appropriate fields in Router Advertisement messages [DISCOVERY].
サイトは特にホストが使用する正確な送付先に関係がないとき、状態がないアプローチが使用されています、彼らがユニークであり、適切に発送可能する限り。 サイトが正確な送付先課題の、よりきついコントロールを必要とするとき、statefulアプローチは使用されています。 statefulものと同様に状態がないアドレス自動構成は同時に、使用されるかもしれません。 サイトの管理者は、Router Advertisementメッセージ[ディスカバリー]で適切な分野の設定を通してどのタイプの自動構成を使用するかを指定します。
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 in a deprecated state, the use of an address 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接続の始まり)は都合のよいアドレスを使用するべきです。 推奨しないアドレスは、単にそれを使用しているアプリケーションで使用されるべきであり、サービスの崩壊なしで別のアドレスに切り替わるのに苦労するでしょう。
To insure 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, independent of whether they are obtained via stateless or stateful autoconfiguration. This document defines the Duplicate Address Detection algorithm.
すべての構成されたアドレスが与えられたリンクで特有である傾向があることを保障するために、それらをインタフェースに割り当てる前に、ノードは「写しアドレス検出」アルゴリズムをアドレスに実行します。 Duplicate Address Detectionアルゴリズムはすべてのアドレスに実行されます、状態がないかstatefulな自動構成でそれらを得るかどうかの如何にかかわらず。 このドキュメントは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手順を通過すると予想されます。
Thomson & Narten Standards Track [Page 3] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[3ページ]RFC1971IPv6
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.
リンクしてください--ノードがすなわち、リンクレイヤ、IPのすぐ下の層で交信できる通信機器か媒体。 例はEthernets(簡単であるかブリッジしている)です。 PPPはリンクします。 X.25、Frame Relay、またはATMネットワーク。 そして、インターネット(より高い)層はIPv4かIPv6自身の上のトンネルなどのように「トンネルを堀ります」。
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
マルチキャストアドレス--1セットのインタフェース(異なったノードに通常属す)のための識別子。 マルチキャストアドレスに送られたパケットはすべてのインタフェースに提供されます。
Thomson & Narten Standards Track [Page 4] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[4ページ]RFC1971IPv6
identified by that address.
そのアドレスで、特定されます。
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 [ADDR-ARCH].
anycastアドレス--1セットのインタフェース(異なったノードに通常属す)のための識別子。 anycastアドレスに送られたパケットはそのアドレス(ルーティング・プロトコルの距離の基準に従った“nearest"1)によって特定されたインタフェースの1つに提供されます。 [ADDR-アーチ]を見てください。
solicited-node multicast address
- a multicast address to which Neighbor Solicitation
messages are sent. The algorithm for computing the
address is given in [DISCOVERY].
請求されたノードマルチキャストアドレス--Neighbor Solicitationメッセージが送られるマルチキャストアドレス。 [ディスカバリー]でアドレスを計算するためのアルゴリズムを与えます。
link-layer address
- a link-layer identifier for an interface. Examples
include IEEE 802 addresses for Ethernet links and E.164
addresses for ISDN links.
リンクレイヤアドレス--インタフェースのためのリンクレイヤ識別子。 例はイーサネットリンクへのIEEE802アドレスとISDNリンクへのE.164アドレスを含んでいます。
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.
リンクローカルアドレス--隣接しているノードに達するのに使用できるリンクだけ範囲を持っているアドレスは同じリンクに付きました。 すべてのインタフェースには、リンクローカルのユニキャストアドレスがあります。
site-local address
- an address having scope that is limited to the local
site.
サイトローカルアドレス--ローカル・サイトに制限される範囲を持っているアドレス。
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 & Narten Standards Track [Page 5] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[5ページ]RFC1971IPv6
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 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.
有効なアドレス--都合のよいか推奨しないアドレス。 有効なアドレスはパケットのソースか送付先アドレスとして見えるかもしれません、そして、インターネットルーティングシステムが有効なアドレスに送られたパケットを提供すると予想されます。
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 later 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 then or equal to the preferred
lifetime. When the valid lifetime expires, the address
becomes invalid.
有効な生涯--アドレスが有効な州(すなわち、無効にするまでの時間)に残っている時間の長さ。 有効な寿命は、都合のよい生涯と次に、より優れているか、または等しいに違いありません。 有効な寿命が期限が切れると、アドレスは無効になります。
interface token
- a link-dependent identifier for an interface that is
(at least) unique per link. Stateless address
autoconfiguration combines an interface token with a
トークンを連結してください--リンク単位で(少なくとも)ユニークなインタフェースのためのリンク依存する識別子。 状態がないアドレス自動構成はインタフェーストークンをaに結合します。
Thomson & Narten Standards Track [Page 6] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[6ページ]RFC1971IPv6
prefix to form an address. From address
autoconfiguration's perspective, an interface token is
a bit string of known length. The exact length of an
interface token 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., [IPv6-ETHER]). In many
cases, the token will be the same as the interface's
link-layer address.
フォームへアドレスを前に置いてください。 アドレス自動構成の見解から、インタフェーストークンは知られている長さのしばらくストリングです。 インタフェーストークンとそれが作成される方法の正確な長さは特定のリンク型(例えば、[IPv6-ETHER])でIPのトランスミッションに関連する問題をカバーする別々のリンク型特定のドキュメントで定義されます。 多くの場合、トークンはインタフェースのリンクレイヤアドレスと同じになるでしょう。
2.1. Requirements
2.1. 要件
Throughout this document, the words that are used to define the significance of the particular requirements are capitalized. These words are:
このドキュメント中では、特定の要件の意味を定義するのに使用される単語は大文字で書かれます。 これらの単語は以下の通りです。
MUST
This word or the adjective "REQUIRED" means that the item is an
absolute requirement of this specification.
「必要である」というThis単語か形容詞が、項目がこの仕様に関する絶対条件であることを意味しなければなりません。
MUST NOT
This phrase means the item is an absolute prohibition of this
specification.
Thisは手段を言葉で表してはいけません。項目はこの仕様の絶対禁止です。
SHOULD
This word or the adjective "RECOMMENDED" means that there may exist
valid reasons in particular circumstances to ignore this item, but
the full implications should be understood and the case carefully
weighed before choosing a different course.
SHOULD This単語か形容詞がこの項目を無視する特定の事情の正当な理由を存在するかもしれない手段に「推薦しました」が、完全な含意は、理解されていて異なったコースを選ぶ前に慎重に熟慮されたケースであるべきです。
SHOULD NOT
This phrase means that there may exist valid reasons in particular
circumstances when the listed behavior is acceptable or even
useful, but the full implications should be understood and the case
carefully weighed before implementing any behavior described with
this label.
SHOULD NOT Thisはこのラベルで説明されたどんな振舞いも実装する前にいつ記載された振舞いが許容できるか、または役に立ちさえしますが、完全な含意が理解されるべきであるか、そして、この件が慎重に熟慮した特定の事情の正当な理由が存在するかもしれない手段を言葉で表します。
MAY
This word or the adjective "OPTIONAL" means that this item is truly
optional. One vendor may choose to include the item because a
particular marketplace requires it or because it enhances the
product, for example, another vendor may omit the same item.
この項目は、This単語か形容詞的「任意」の手段ですが、本当に、任意の状態でそうするかもしれません。 1つのベンダーが、特定の市場がそれを必要とするか、または製品を高めるので項目を含んでいるのを選ぶかもしれません、例えば、別のベンダーは同じ項目を忘れるかもしれません。
Thomson & Narten Standards Track [Page 7] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[7ページ]RFC1971IPv6
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 token"). In the simplest case, an interface token
consists of the interface's link-layer address. An interface token
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 stateful 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 its interface token to the link-local
prefix.
o 単一のリンクに取り付けられた1セットのマシンから成る小さいサイトは交信するための前提条件としてstatefulサーバかルータを存在に要求するべきではありません。 プラグアンドプレイコミュニケーションはリンクローカルのアドレスの使用で達成されます。 リンクローカルのアドレスには、1セットのノードが付く(単一)の共有されたリンクを特定するよく知られる接頭語があります。 ホストは、リンクローカルの接頭語にインタフェーストークンを追加することによって、リンクローカルアドレスを形成します。
o A large site with multiple networks and routers should not require
the presence of a stateful address configuration server. In order
to generate site-local or 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 複数のネットワークとルータがある大きいサイトはstatefulアドレス構成サーバを存在に要求するべきではありません。サイト地方の、または、グローバルなアドレスを作るために、ホストはそれらが付くサブネットを特定する接頭語を決定しなければなりません。 ルータはアクティブな接頭語のセットをリンクに記載するオプションを含んでいる周期的な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 period during which both
a new address and the one being phased out work simultaneously.
o アドレス構成はサイトのマシンの優雅な番号を付け替えることを容易にするべきです。 新しいネットワークサービスプロバイダーに切り替わるとき、例えば、サイトはノードのすべてに番号を付け替えさせたがっているかもしれません。 番号を付け替えることはインタフェースへのアドレスの賃貸借契約と同じインタフェースへの複数のアドレスの課題で達成されます。 寿命がサイトが古い接頭語を段階的に廃止するメカニズムを提供するリース。 インタフェースへの複数のアドレスの課題は新しいアドレスと段階的に廃止されるものの両方が同時に働いている過渡期に備えます。
o System administrators need the ability to specify whether stateless
autoconfiguration, stateful autoconfiguration, or both should be
used. Router Advertisements include flags specifying which
mechanisms a host should use.
o システム管理者は状態がない自動構成、stateful自動構成、または両方が使用されるべきであるかどうか指定する能力を必要とします。 ルータAdvertisementsはホストがどのメカニズムを使用するべきであるかを指定する旗を含んでいます。
Thomson & Narten Standards Track [Page 8] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[8ページ]RFC1971IPv6
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 the interface's token to the well- known link-local prefix.
このセクションはインタフェースがそれ自体を自動構成するとき行われる典型的なステップの概要を提供します。 マルチキャストできるインタフェースが例えば、システム起動の間可能にされるとき、自動構成は、マルチキャストできるリンクだけに実行されて、始まります。 ノード(ホストとルータの両方)は、リンクローカルアドレスをインタフェースに生成することによって、自動構成プロセスを開始します。 リンクローカルアドレスは、よく知られているリンクローカルの接頭語にインタフェースのトークンを追加することによって、形成されます。
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 token that overrides the default token in such a way that the autoconfiguration mechanism can then be applied using the new (presumably unique) interface token. 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 it 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 should do. If no routers are present, stateful autoconfiguration should be invoked.
自動構成の次のフェーズは、Router Advertisementを入手するか、またはどんなルータも存在していないことを決定することを伴います。 ルータが存在していると、それらはホストがどういう自動構成をするべきであるかを指定するRouter Advertisementsを送るでしょう。 どんなルータも存在していないなら、stateful自動構成は呼び出されるべきです。
Routers send Router Advertisements periodically, but the delay between successive advertisements will generally be longer than a host performing autoconfiguration will want to wait [DISCOVERY]. To obtain an advertisement quickly, a host sends one or more Router
ルータが定期的にRouter Advertisementsを送りますが、一般に、連続した広告の間の遅れはホスト実行自動構成が[ディスカバリー]を待ちたくなるよりさらに長くなるでしょう。 すぐに広告を得るために、ホストは1Routerを送ります。
Thomson & Narten Standards Track [Page 9] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[9ページ]RFC1971IPv6
Solicitations to the all-routers multicast group. Router Advertisements contain two flags indicating what type of stateful autoconfiguration (if any) should be performed. A "managed address configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain addresses. An "other stateful configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain additional information (excluding addresses).
オールルータマルチキャストへの懇願は分類されます。 ルータAdvertisementsはどんなタイプのstateful自動構成(もしあれば)が実行されるべきであるかを示す2個の旗を含んでいます。 「管理されたアドレス構成」旗は、ホストがアドレスを得るのにstateful自動構成を使用するべきであるかどうかを示します。 「他のstateful構成」旗は、ホストが追加情報(アドレスを除いた)を得るのにstateful自動構成を使用するべきであるかどうかを示します。
Router Advertisements also contain zero or more Prefix Information options that contain information used by stateless address autoconfiguration to generate site-local and global addresses. It should be noted that the stateless and stateful address autoconfiguration fields in Router Advertisements are processed independently of one another, and a host may use both stateful and stateless address autoconfiguration 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情報オプションを含んでいます。 Router Advertisementsの状態がなくてstatefulなアドレス自動構成分野がお互いの如何にかかわらず処理されて、ホストが同時にstatefulものと同様に状態がないアドレス自動構成を使用するかもしれないことに注意されるべきです。 「自動アドレス構成旗」という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を生成するので、ホストは絶えず新しい広告を受け取るでしょう。 ホストは前の広告に受け取られた情報を加えて、リフレッシュして、上で説明されるように各広告に含まれた情報を処理します。
For safety, all addresses must be tested for uniqueness prior to their assignment to an interface. In the case of addresses created through stateless autoconfig, however, the uniqueness of an address is determined primarily by the portion of the address formed from an interface token. Thus, if a node has already verified the uniqueness of a link-local address, additional addresses created from the same interface token need not be tested individually. In contrast, all addresses obtained manually or via stateful address autoconfiguration should be tested for uniqueness individually. 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.
安全において、彼らの課題の前にユニークさがないかどうかすべてのアドレスをインタフェースにテストしなければなりません。 しかしながら、状態がないautoconfigを通して作成されたアドレスの場合では、アドレスのユニークさは主としてインタフェーストークンから形成されたアドレスの部分のそばで決定しています。 したがって、ノードが既にリンクローカルアドレスのユニークさについて確かめたなら、同じインタフェーストークンから作成された追加アドレスは個別にテストされる必要はありません。 対照的に、手動かstatefulアドレス自動構成で得られたすべてのアドレスがユニークさがないかどうか個別にテストされるべきです。 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ステップをするなら、自動構成を完成するのに必要である合計時はかなり長い場合があります。
Thomson & Narten Standards Track [Page 10] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[10ページ]RFC1971IPv6
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 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.
アドレス賃貸借契約は、ホストでインタフェースに割り当てられたタイムアウトアドレスにメカニズムを提供することによって、サイトの番号を付け替えることを容易にします。 現在のところ、TCPなどの上側の層のプロトコルは接続がオープンである間、エンドポイントアドレスを変えるサポートを全く提供しません。 エンドポイントアドレスが無効になるなら、既存の接続は中断しています、そして、無効のアドレスへのすべてのコミュニケーションが失敗します。 アプリケーションがトランスポート・プロトコルとして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.
詳細なアドレス選択規則はこのドキュメントの範囲を超えています。
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を実行します。
Thomson & Narten Standards Track [Page 11] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[11ページ]RFC1971IPv6
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 interface:
ノードは、以下の自動構成関連の変数がそれぞれのマルチキャストインタフェースのためのシステム管理で構成されるのを許容しなければなりません:
DupAddrDetectTransmits
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を実行している間、発信しました。 ゼロの値は、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., [IPv6-ETHER]).
デフォルト: 特定のリンク型(例えば、[IPv6-ETHER])でIPのトランスミッションに関連する問題をカバーするドキュメントのリンク型の特定の値によってくつがえされるかもしれないのを除いた1。
Autoconfiguration also assumes the presence of the variable RetransTimer as defined in [DISCOVERY]. 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.
また、自動構成は[ディスカバリー]で定義されるように可変RetransTimerの存在を仮定します。 自動構成目的として、RetransTimerはDuplicate Address Detectionの間に実行された連続したNeighbor Solicitationトランスミッションの間の遅れを指定します(DupAddrDetectTransmitsが1歳以上であるなら)、Duplicate Address Detectionプロセスを終わらせる前に最後のNeighbor Solicitationを送った後にノードが待つ時と同様に。
5.2. Autoconfiguration-Related Variables
5.2. 自動構成関連の変数
A host maintains a number of data structures and flags related to autoconfiguration. In the following, we present conceptual variables and show how they are used to perform autoconfiguration. The specific variables are used for demonstration purposes only, and an implementation is not required to have them, so long as its external behavior is consistent with that described in this document.
ホストは自動構成に関連する多くのデータ構造と旗を維持します。 以下では、私たちは、概念的な変数を提示して、それらが自動構成を実行するのにどう使用されるかを示しています。 特定の変数はデモンストレーションの目的だけに使用されます、そして、実装はそれらを持つのに必要ではありません、外部の振舞いが本書では説明されるそれと一致している限り。
Beyond the formation of a link-local address and using Duplicate Address Detection, how routers (auto)configure their interfaces is beyond the scope of this document.
リンクローカルアドレスとDuplicate Address Detectionを使用する構成を超えて、ルータ(自動)がどうそれらのインタフェースを構成するかはこのドキュメントの範囲を超えています。
Hosts maintain the following variables on a per-interface basis:
ホストは1インタフェースあたり1個のベースで以下の変数を維持します:
ManagedFlag Copied from the M flag field (i.e., the "managed
address configuration" flag) of the most recently
received Router Advertisement message. The flag
indicates whether or not addresses are to be
MからのManagedFlag Copiedは最も最近受信されたRouter Advertisementメッセージの分野(すなわち、「管理されたアドレス構成」旗)に旗を揚げさせます。 旗は、表示のためにアドレスがそうであるかどうかを示します。
Thomson & Narten Standards Track [Page 12] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[12ページ]RFC1971IPv6
configured using the stateful autoconfiguration
mechanism. It starts out in a FALSE state.
stateful自動構成メカニズムを使用することで、構成されます。 それはFALSE状態で始めます。
OtherConfigFlag Copied from the O flag field (i.e., the "other
stateful configuration" flag) of the most recently
received Router Advertisement message. The flag
indicates whether or not information other than
addresses are to be obtained using the stateful
autoconfiguration mechanism. It starts out in a
FALSE state.
大部分のO旗の分野(すなわち、「他のstateful構成」旗)からのOtherConfigFlag Copiedは最近、Router Advertisementメッセージを受け取りました。 旗は、アドレス以外の情報がstateful自動構成メカニズムを使用することで得られるかどうかことであることを示します。 それはFALSE状態で始めます。
A host also 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.
- インタフェースは初めて、リンクに付きます。
- The interface becomes enabled by system management after having
been administratively disabled.
- インタフェースは行政上無効にされた後に、システム管理で可能にされるようになります。
A link-local address is formed by prepending the well-known link- local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the interface token. If the interface token has a length of N bits, the interface token replaces the right-most N zero bits of the link-local prefix. If the interface token is more than 118 bits in length, autoconfiguration fails and manual configuration is required.
リンクローカルアドレスはよく知られるリンク地方の接頭語FE80をprependingすることによって、形成されます:、:0 インタフェーストークンへの[ADDR-ARCH。](適切な長さの) インタフェーストークンにNビットの長さがあるなら、インタフェーストークンはリンクローカルの接頭語のN最も権利ゼロ・ビットを置き換えます。 インタフェーストークンは長さが118ビット以上であるなら、自動構成が失敗します、そして、手動の構成が必要です。
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 unicast addresses prior to assigning them to an interface whose DupAddrDetectTransmits variable is greater than zero. Duplicate Address Detection takes place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration.
DupAddrDetectTransmits変数がゼロ以上であるインタフェースにそれらを割り当てる前に、ユニキャストアドレスに写しAddress Detectionを実行しなければなりません。 写しAddress Detectionはすべてのユニキャストアドレスで行われます、statefulを通してそれらを得るかどうかにかかわらず、状態がないか手動の構成。
Thomson & Narten Standards Track [Page 13] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[13ページ]RFC1971IPv6
(Duplicate Address Detection MUST NOT be performed on anycast addresses.) Each individual unicast address SHOULD be tested for uniqueness. However, when stateless address autoconfiguration is used, address uniqueness is determined solely by the interface token, assuming that subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same token, either all addresses or none of them will be duplicates). Thus, for a set of addresses formed from the same interface token, it is sufficient to check that the link-local address generated from the token is unique on the link. In such cases, the link-local address MUST be tested for uniqueness before any of the other addresses formed from the token can be assigned to an interface.
(anycastアドレスに写しAddress Detectionを実行してはいけません。) それぞれの個々のユニキャストはSHOULDを扱います。ユニークさがないかどうかテストされます。 しかしながら、状態がないアドレス自動構成が使用されているとき、アドレスのユニークさは唯一インタフェーストークンで決定します、サブネット接頭語が正しく割り当てられると仮定して(すなわち、インタフェースのアドレスのすべてが同じトークンから生成されると、それらのすべてのアドレスかいずれのどちらかも写しにならないでしょう)。 したがって、同じインタフェーストークンから形成された1セットのアドレスでは、トークンから生成されたリンクローカルアドレスがリンクでユニークであることをチェックするのが十分です。 そのような場合、トークンから形成された他のアドレスのどれかをインタフェースに割り当てることができる前にユニークさがないかどうかリンクローカルアドレスをテストしなければなりません。
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 token, a new token 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.
写しAddress Detection Procedureが適用されているアドレスは手順が一時的になるまで一時的であると言われています。首尾よく完成されます。 一時的なアドレスは伝統的な意味で「インタフェースに割り当てられる」と考えられません。 すなわち、インタフェースは、Target Address分野で一時的なアドレスを含むNeighbor SolicitationとAdvertisementメッセージを受け入れなければなりませんが、アドレスがTarget Addressマッチを割り当てたそれらからインタフェースまでそのようなパケットを異なって処理します。 一時的なアドレスに扱われた他のパケットは静かに捨てられるべきです。
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接続のリセットのような可能な否定的結果をもたらして。
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,
以下の小区分はノードがアドレスsのユニークさについて確かめるために実行する特異的な試験について説明します。 DupAddrDetectTransmits Neighbor Solicitationsを送ったミリセカンドと同じくらいの後にテストのいずれもRetransTimerの中に写しアドレスの存在を示さないなら、アドレスはユニークであると考えられます。 かつて、アドレスは特有であることを決定しています。
Thomson & Narten Standards Track [Page 14] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[14ページ]RFC1971IPv6
it may be assigned to an interface.
それはインタフェースに割り当てられるかもしれません。
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 [DISCOVERY]. A solicitation that passes these validity checks is called a valid solicitation or valid 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 insures that the node receives Neighbor Advertisements from other nodes already using the address; the latter insures that two nodes attempting to use the same address simultaneously 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 the first message to be sent from an interface after interface (re)initialization, the node should delay sending the message by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. 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. 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 while delaying transmission of the initial Neighbor Solicitation.
Neighbor Solicitationがインタフェース(re)初期化の後にインタフェースから送られるべき最初のメッセージであるなら、ノードは、_[ディスカバリー]の指定されるとしてのSOLICITATION_DELAYを0とマックス_RTRの間の無作為の遅れによるメッセージに送るのを遅らせるはずです。 これは、多くのノードが同時に停電などの後のようにリンクで始動するとき、混雑を軽減するのに役立って、1つ以上のノードが同時に同じアドレスを請おうとしているとき、競合条件を避けるのを助けるかもしれません。 Duplicate Address Detectionアルゴリズムの丈夫さを改良するために、インタフェースは受信されなければなりませんでした、そして、プロセスデータグラムは初期のNeighbor Solicitationのトランスミッションを遅らせている間、一時的なアドレスのオールノードマルチキャストアドレスか請求されたノードマルチキャストアドレスに発信しました。
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 the target address is tentative or not. If the target address is not tentative (i.e., it is assigned to the receiving interface), the solicitation is processed as described in [DISCOVERY]. 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
インタフェースに関する有効なNeighbor Solicitationメッセージを受け取り次第、ノードの振舞いはあて先アドレスが一時的であるかどうかよります。 あて先アドレスが一時的でないなら(すなわち、それは受信インタフェースに割り当てられます)、懇願は[ディスカバリー]で説明されるように処理されます。 あて先アドレスが一時的であり、ソースアドレスがユニキャストアドレスであるなら、懇願の送付者はアドレス解決を目標に実行しています。 懇願は静かに無視されるべきです。 さもなければ、処理は以下で説明されるように行われます。 コネ
Thomson & Narten Standards Track [Page 15] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[15ページ]RFC1971IPv6
all cases, a node MUST NOT respond to a Neighbor Solicitation for a tentative address.
すべてのケース、ノードは一時的なアドレスのために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を実行するノードから来ています。 懇願が別のノードから来ているなら、一時的なアドレスを写しであり、使用するべきではありません(どちらかのノードで)。 懇願がノード自体から来ているなら(ノードが逆マルチキャストパケットを輪にするので)、懇願は写しアドレスの存在を示しません。
Implementor'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 the Appendix for further discussion.
作成者の注意: 多くのインタフェースが上側の層が選択的にマルチキャストパケットのループを可能にして、無効にする方法を提供します。 そのような施設がどう実装されるかに関する詳細は、Duplicate Address Detectionが正しく働いているのを防ぐかもしれません。 さらなる議論に関してAppendixを見てください。
The following tests identify conditions under which a tentative address is not unique:
以下のテストは一時的なアドレスがユニークでない状態を特定します:
- If a Neighbor Solicitation for a tentative address is received
prior to having sent one, 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 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 loopback 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. If the target address is assigned to the receiving interface, the solicitation is processed as described in [DISCOVERY]. If the target address is tentative, the tentative address is not unique.
インタフェースに関する有効なNeighbor Advertisementメッセージを受け取り次第、ノードの振舞いは、あて先アドレスが一時的であるかどうかよるか、またはインタフェースに割り当てられたユニキャストかanycastアドレスに合っています。 あて先アドレスが受信インタフェースに割り当てられるなら、懇願は[ディスカバリー]で説明されるように処理されます。 あて先アドレスが一時的であるなら、一時的なアドレスはユニークではありません。
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. If the address is a link-local address
上で説明されるように写しであることを決定している一時的なアドレス、インタフェースに割り当てられてはいけなくて、ノードSHOULDはシステム管理誤りを登録します。 アドレスがリンクローカルアドレスであるなら
Thomson & Narten Standards Track [Page 16] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[16ページ]RFC1971IPv6
formed from an interface token, the interface SHOULD be disabled.
トークン、インタフェースSHOULDを連結してください。形成する、無効にされます。
5.5. Creation of Global and Site-Local Addresses
5.5. グローバルでサイトローカルのアドレスの作成
Global and site-local addresses are formed by appending an interface token to a prefix of appropriate length. Prefixes are obtained from Prefix Information options contained in Router Advertisements. Creation of global and site-local addresses and configuration of other parameters as described in this section SHOULD be locally configurable. However, the processing described below MUST be enabled by default.
グローバルでサイトローカルのアドレスは、適切な長さの接頭語にインタフェーストークンを追加することによって、形成されます。 Router Advertisementsに含まれたPrefix情報オプションから接頭語を得ます。 グローバルでサイトローカルのアドレスの作成とこのセクションSHOULDの説明されるとしての他のパラメタの構成は局所的にそうです。構成可能。 しかしながら、デフォルトで以下で説明された処理を可能にしなければなりません。
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 [DISCOVERY].
定期的にオールノードマルチキャストアドレスにルータAdvertisementsを送ります。 すぐに広告を得るために、ホストは[ディスカバリー]で説明されるようにRouter Solicitationsを出します。
5.5.2. Absence of Router Advertisements
5.5.2. ルータ通知の欠如
If a link has no routers, a host MUST attempt to use stateful autoconfiguration to obtain addresses and other configuration information. An implementation MAY provide a way to disable the invocation of stateful autoconfiguration in this case, but the default SHOULD be enabled. 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 [DISCOVERY].
リンクにルータが全くないなら、ホストは、アドレスと他の設定情報を得るのにstateful自動構成を使用するのを試みなければなりません。 実装はstatefulの実施がこの場合、自動構成ですが、デフォルトがSHOULDであると無効にする方法を提供するかもしれません。可能にされます。 自動構成の見解から、[ディスカバリー]で説明されるようにRouter Solicitationsの少ない数を送った後にRouter Advertisementsを全く受け取らないなら、リンクにはルータが全くありません。
5.5.3. Router Advertisement Processing
5.5.3. ルータ通知処理
On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), a host copies the value of the advertisement's M bit into ManagedFlag. If the value of ManagedFlag changes from FALSE to TRUE, the host should invoke the stateful address autoconfiguration protocol, requesting address information. If the value of the ManagedFlag changes from TRUE to FALSE, the host should terminate the stateful address autoconfiguration protocol (i.e., stop requesting addresses and ignore subsequent responses to in-progress transactions). If the value of the flag stays unchanged, no special action takes place. In particular, a host MUST NOT reinvoke stateful address configuration if it is already participating in the stateful protocol as a result of an earlier advertisement.
有効なRouter Advertisement([ディスカバリー]で定義されるように)を受け取り次第、ホストは広告Mのビットの価値をManagedFlagにコピーします。 ManagedFlagの値がFALSEからTRUEに変化するなら、ホストはstatefulアドレス自動構成プロトコルを呼び出すべきです、アドレス情報を要求して。 ManagedFlagの値がTRUEからFALSEに変化するなら、ホストはstatefulアドレス自動構成プロトコルを終えるべきです(すなわち、アドレスを要求するのを止めてください、そして、進行中のトランザクションへのその後の応答を無視してください)。 旗の値が変わりがない状態で残っているなら、どんな特別な動きも行われません。 特に、ホストは以前の広告の結果、既にstatefulプロトコルに参加しているならreinvoke statefulが構成を扱うNOTがそうしなければなりません。
An advertisement's O flag field is processed in an analogous manner. A host copies the value of the O flag into OtherConfigFlag. If the value of OtherConfigFlag changes from FALSE to TRUE, the host should invoke the stateful autoconfiguration protocol, requesting
広告Oの旗の分野は類似の方法で処理されます。 ホストはO旗の値をOtherConfigFlagにコピーします。 OtherConfigFlagの値がFALSEからTRUEに変化するなら、ホストはstateful自動構成プロトコル、要求を呼び出すべきです。
Thomson & Narten Standards Track [Page 17] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[17ページ]RFC1971IPv6
information (excluding addresses). If the value of the OtherConfigFlag changes from TRUE to FALSE, any activity related to stateful autoconfiguration for parameters other than addresses should be halted. If the value of the flag stays unchanged, no special action takes place. In particular, a host MUST NOT reinvoke stateful configuration if it is already participating in the stateful protocol as a result of an earlier advertisement.
情報(アドレスを除いた)。 OtherConfigFlagの値がTRUEからFALSEに変化するなら、アドレス以外のパラメタのためのstateful自動構成に関連するどんな活動も止められるべきです。 旗の値が変わりがない状態で残っているなら、どんな特別な動きも行われません。 reinvoke stateful構成ではなく、特定のaホストがそうしなければならないコネがそれであるなら以前の広告の結果、既にstatefulプロトコルに参加しています。
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 advertised prefix matches the prefix of an autoconfigured
address (i.e., obtained via stateless or stateful address
autoconfiguration) in the list of addresses associated with the
interface, set the preferred timer to that of the option's preferred
lifetime, and set the valid lifetime to that of the option's valid
lifetime.
d) 広告を出している接頭語がインタフェースに関連している住所録で自動構成されたアドレスの接頭語に合っているなら(すなわち、状態がないかstatefulなアドレス自動構成で、得ます)、オプションの都合のよい生涯のものに都合のよいタイマを設定してください、そして、オプションの有効な生涯のものへの有効な生涯を決めてください。
e) If the prefix advertised does not match the prefix of an address
already in the list, then form an address (and add it to the list)
by appending the interface token to the prefix as follows:
e) 広告に掲載された接頭語が既にリストのアドレスの接頭語に合っていないなら、インタフェーストークンを以下の接頭語に追加することによって、アドレス(それをリストに追加する)を形成してください:
| 128 - N bits | N bits |
+---------------------------------------+------------------------+
| link prefix | interface token |
+----------------------------------------------------------------+
| 128--Nビット| Nビット| +---------------------------------------+------------------------+ | リンク接頭語| インタフェーストークン| +----------------------------------------------------------------+
If the sum of the prefix length and interface token 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. It is the responsibility of the system administrator to insure
that the lengths of prefixes contained in Router Advertisements are
consistent with the length of interface tokens for that link type.
接頭語の長さとインタフェーストークンの長さの合計が128ビットと等しくないなら、Prefix情報オプションを無視しなければなりません。 実装はこの場合システム管理誤りを登録したがっているかもしれません。 そのリンク型にとって、Router Advertisementsに含まれた接頭語の長さがインタフェーストークンの長さと一致しているのを保障するのは、システム管理者の責任です。
In those cases where a site requires the use of longer prefixes than
can be accommodated by the interface token, stateful
autoconfiguration can be used.
サイトがインタフェーストークンで設備することができるより長い接頭語の使用を必要とするそれらの場合では、stateful自動構成を使用できます。
Thomson & Narten Standards Track [Page 18] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[18ページ]RFC1971IPv6
If an address is formed successfully, 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.
アドレスが首尾よく形成されるなら、ホストはインタフェースに割り当てられた住所録にそれを追加します、Prefix情報オプションから都合のよくて有効な生涯値を初期化して。
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 in new communications if an alternate (non-deprecated) address is available and has sufficient scope. The IP layer MUST continue to accept datagrams destined to a deprecated address since a deprecated address is still a valid address for the interface. An implementation MAY prevent any new communication from using a deprecated address, but system management MUST have the ability to disable such a facility.
都合のよい寿命が期限が切れると、都合のよいアドレスは推奨しなくなります。 SHOULDが続けている推奨しないアドレスがソースアドレスとして既存のコミュニケーションで使用されて、SHOULD NOTだけが代替の(非推奨しない)アドレスが利用可能であるなら新しいコミュニケーションで使用されて、十分な範囲を持っています。 IP層は、それでも、推奨しないアドレスがインタフェースへの有効なアドレスであるので推奨しないアドレスに運命づけられたデータグラムを受け入れ続けなければなりません。 実装は、どんな新しいコミュニケーションも推奨しないアドレスを使用するのを防ぐかもしれませんが、システム管理には、そのような施設を無効にする能力がなければなりません。
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.
有効な寿命が期限が切れると、アドレス(そして、インタフェースとの協会)は無効になります。 無効のアドレスを、ソースアドレスとして送信するコミュニケーションで使用してはいけなくて、目的地として受信インタフェースで認識してはいけません。
Note that if a Prefix Information option is received with a preferred lifetime of zero, any addresses generated from that prefix are immediately deprecated. Similarly, if both the advertised deprecated and valid lifetimes are zero, any addresses generated from that prefix become invalid immediately.
ゼロの都合のよい生涯でPrefix情報オプションを受け取るなら、その接頭語から作られたどんなアドレスもすぐに推奨しないことに注意してください。 同様に、両方の広告を出している推奨しなくて有効な寿命がゼロであるなら、その接頭語から作られたどんなアドレスもすぐに、無効になります。
5.6. Configuration Consistency
5.6. 構成の一貫性
It is possible for hosts to obtain address information using both stateless and stateful protocols 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 the stateful autoconfiguration protocol. 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 the stateless and stateful protocols. If inconsistent information is learned from different sources, the most recently obtained values always have precedence over information learned earlier.
ホストがアドレス情報を得るのは、両方が同時に可能にされるかもしれないので状態がないものと同様にstatefulなプロトコルを使用することで可能です。 また、MTUサイズやホップ限界などの他の設定パラメータの値がRouter Advertisementsとstateful自動構成プロトコルの両方から学習されるのも、可能です。 同じ設定情報が複数のソースによって提供されるなら、この情報の値は一貫しているべきです。 しかしながら、複数のソースから受け取られた情報が矛盾しているなら、それは致命的な誤りであると考えられません。 ホストは状態がなくてstatefulなプロトコルで受け取られたすべての情報の組合を受け入れます。 矛盾した情報がさまざまな原因から学習されるなら、最も最近得られた値で、より早くいつも情報の上の先行について学習します。
SECURITY CONSIDERATIONS
セキュリティ問題
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
状態がないアドレス自動構成で、ホストをネットワークに接続して、アドレスを構成して、今までに登録しないで他のノードとコミュニケートし始めるか、またはそれ自体を認証し始めます。
Thomson & Narten Standards Track [Page 19] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[19ページ]RFC1971IPv6
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 Duplicate Address Detection opens up the possibility of denial of service attacks. Any node can respond to Neighbor Solicitations for a tentative address, causing the other node to reject the address as a duplicate. This attack is similar to other attacks involving the spoofing of Neighbor Discovery messages and can be addressed by requiring that Neighbor Discovery packets be authenticated [RFC1826].
Duplicate Address Detectionの使用はサービス不能攻撃の可能性を開けます。 どんなノードも一時的なアドレスのためにNeighbor Solicitationsに応じることができます、もう片方のノードが写しとしてアドレスを拒絶することを引き起こして。 この攻撃は、Neighborディスカバリーメッセージのスプーフィングにかかわる他の攻撃と同様であり、Neighborディスカバリーパケットが認証されるのを[RFC1826]必要とすることによって、扱うことができます。
REFERENCES
参照
[RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, August
1995.
[RFC1826] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、1995年8月。
[IPv6-ETHER] Crawford, M., "A Method for the Transmission of IPv6
Packets over Ethernet Networks", RFC 1972, August 1996.
[IPv6-エーテル] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッションのためのメソッド」、RFC1972、1996年8月。
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[ADDR-ARCH] Hinden, R., and S. Deering, "Internet Protocol Version
(IPv6) Addressing Architecture", RFC 1884, December 1995.
[ADDR-アーチ] Hinden、R.、およびS.デアリング、「インターネットプロトコルバージョン(IPv6)アドレッシング体系」、RFC1884、1995年12月。
[DHCPv6] Work in Progress.
[DHCPv6]は進行中で働いています。
[DISCOVERY] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996.
[発見]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC1970、1996年8月。
Acknowledgements
承認
The authors would like to thank the members of both the IPNG and ADDRCONF working groups for their input. In particular, thanks to Jim Bound, Steve Deering, and Erik Nordmark.
作者は彼らの入力のためのIPNGとADDRCONFワーキンググループの両方のメンバーに感謝したがっています。 特に、ジムBound、スティーブ・デアリングとエリックNordmarkをありがとうございます。
Thomson & Narten Standards Track [Page 20] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[20ページ]RFC1971IPv6
AUTHORS' ADDRESSES
作者のアドレス
Susan Thomson Bellcore 445 South Street Morristown, NJ 07960 USA
スーザントムソンBellcore445の南通りニュージャージー07960モリスタウン(米国)
Phone: +1 201-829-4514 EMail: set@thumper.bellcore.com
以下に電話をしてください。 +1 201-829-4514 メールしてください: set@thumper.bellcore.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@vnet.ibm.com
以下に電話をしてください。 +1 7798年の919 254メール: narten@vnet.ibm.com
Thomson & Narten Standards Track [Page 21] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[21ページ]RFC1971IPv6
APPENDIX: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION
付録: ループバック抑圧と写しアドレス検出
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 token 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 by simply 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. 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つの可能なソフトウェアヒューリスティックはリンクレイヤソースアドレスが受信インタフェースのものと同じであるどんな容認されたパケットも捨てることです。 残念ながら、また、その評価基準の使用は、同じリンクレイヤアドレスを使用することで別のノードによって送られたすべてのパケットを捨てることをもたらします。 写しAddress Detectionはこの様に容認されたパケットをフィルターにかけるインタフェースで失敗するでしょう:
o If a node performing Duplicate Address Detection discards received
packets having the same source link-layer address as the receiving
interface, it will also discard packets from other nodes also using
the same link-layer address, including Neighbor Advertisement and
Neighbor Solicitation messages required to make Duplicate Address
Detection work correctly. This particular problem can be avoided
o また、Duplicate Address Detection破棄を実行するノードが受信インタフェースと同じソースリンクレイヤアドレスを持っているパケットを受けたなら、他のノードからまた、同じリンクレイヤアドレスを使用することでパケットを捨てるでしょう、Duplicate Address Detectionを正しく働かせるのに必要であるNeighbor AdvertisementとNeighbor Solicitationメッセージを含んでいて。 この特定の問題を避けることができます。
Thomson & Narten Standards Track [Page 22] RFC 1971 IPv6 Stateless Address Autoconfiguration August 1996
アドレス自動構成1996年8月に状態がないトムソンとNarten標準化過程[22ページ]RFC1971IPv6
by temporarily disabling the software suppression of loopbacks
while a node performs Duplicate Address Detection.
ノードがDuplicate Address Detectionを実行している間、ソフトウェアがループバックの抑圧であると一時無効にすることによって。
o If a node that is already using a particular IP address discards
received packets having the same link-layer source address as the
interface, it will also discard Duplicate Address Detection-related
Neighbor Solicitation messages sent by another node also using 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 interfaces.
したがって、単にソースリンクレイヤアドレスがインタフェースと同じであるので、2つのインタフェースが同じリンクレイヤアドレスを使用していて、実装にはインタフェースのマルチキャストループバック意味論の良い理解がなければならなくて、インタフェースが捨てられることができない場合で正しくDuplicate Address Detectionを実行するのはパケットを受けました。
Thomson & Narten Standards Track [Page 23]
トムソンとNarten標準化過程[23ページ]
一覧
スポンサーリンク
