RFC2462 日本語訳
2462 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. December 1998. (Format: TXT=61210 bytes) (Obsoletes RFC1971) (Obsoleted by RFC4862) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Thomson
Request for Comments: 2462 Bellcore
Obsoletes: 1971 T. Narten
Category: Standards Track IBM
December 1998
コメントを求めるワーキンググループS.トムソンの要求をネットワークでつないでください: 2462 Bellcoreは以下を時代遅れにします。 1971年のT.Nartenカテゴリ: 標準化過程IBM1998年12月
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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........................................ 6
3. DESIGN GOALS............................................. 7
4. PROTOCOL OVERVIEW........................................ 8
4.1. Site Renumbering.................................... 10
5. PROTOCOL SPECIFICATION................................... 10
5.1. Node Configuration Variables........................ 11
5.2. Autoconfiguration-Related Variables................. 11
5.3. Creation of Link-Local Addresses.................... 12
1. 序論… 2 2. 用語… 4 2.1. 要件… 6 3. 目標を設計してください… 7 4. 概要について議定書の中で述べてください… 8 4.1. サイトの番号を付け替えること… 10 5. 仕様を議定書の中で述べてください… 10 5.1. ノード構成変数… 11 5.2. 自動構成関連の変数… 11 5.3. リンクローカルのアドレスの作成… 12
Thomson & Narten Standards Track [Page 1] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[1ページ]RFC2462IPv6
5.4. Duplicate Address Detection......................... 13
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......... 16
5.5. Creation of Global and Site-Local Addresses......... 16
5.5.1. Soliciting Router Advertisements............... 16
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
6. SECURITY CONSIDERATIONS.................................. 20
7. References............................................... 20
8. Acknowledgements and Authors' Addresses.................. 21
9. APPENDIX A: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS
DETECTION.............................................. 22
10. APPENDIX B: CHANGES SINCE RFC 1971....................... 24
11. Full Copyright Statement................................. 25
5.4. アドレス検出をコピーしてください… 13 5.4.1. メッセージ合法化… 14 5.4.2. 隣人懇願にメッセージを送ります… 14 5.4.3. 隣人懇願メッセージを受け取ります… 15 5.4.4. 隣人広告メッセージを受け取ります… 16 5.4.5. 写しアドレス検出が失敗すると… 16 5.5. グローバルでサイトローカルのアドレスの作成… 16 5.5.1. ルータ通知に請求します… 16 5.5.2. ルータ通知の欠如… 17 5.5.3. ルータ通知処理… 17 5.5.4. 生涯満期を扱ってください… 19 5.6. 構成の一貫性… 19 6. セキュリティ問題… 20 7. 参照… 20 8. 承認と作者のアドレス… 21 9. 付録A: ループバック抑圧と写しは検出を扱います… 22 10. 付録B: RFC1971以来の変化… 24 11. 完全な著作権宣言文… 25
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 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はstatefulであって状態がないアドレス自動構成メカニズムを定義します。 ルータの最小量(もしあれば)の構成を必要としますが、状態がない自動構成はホストを手動の構成がない、どんな追加サーバも必要としません。 状態がないメカニズムで、ホストはそれ自身のアドレスが局所的に利用可能な情報の組み合わせを使用して、ルータによって広告に掲載された情報であると生成することができます。 ルータはリンクに関連しているサブネットを特定する接頭語の広告を出します、ホストがサブネットで唯一インタフェースを特定する「インタフェース識別子」を生成しますが。 アドレスは、2を結合することによって、形成されます。 ルータがないとき、ホストはリンクローカルのアドレスを作ることができるだけです。 しかしながら、リンクローカルのアドレスは同じリンクに添付されたノードの中にコミュニケーションを許容するのに十分です。
Thomson & Narten Standards Track [Page 2] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[2ページ]RFC2462IPv6
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 can use stateless autoconfiguration to configure its own addresses, but use stateful autoconfiguration to obtain other information. Stateful autoconfiguration for IPv6 is the subject of future work [DHCPv6].
stateful自動構成モデルでは、ホストはサーバからインターフェース・アドレス、そして/または、設定情報とパラメタを得ます。サーバはどのホストにアドレスを割り当ててある道を保つデータベースを維持します。 ホストはstateful自動構成プロトコルでサーバからアドレス、他の設定情報または両方を得ることができます。状態がなくてstatefulな自動構成は互いの補足となります。 例えば、ホストはそれ自身のアドレスを構成するのに状態がない自動構成を使用できますが、stateful自動構成を使用して、他の情報を得てください。 IPv6のための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アルゴリズムを定義します。
Thomson & Narten Standards Track [Page 3] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[3ページ]RFC2462IPv6
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 are used
only in contexts where necessary to avoid ambiguity.
IP--インターネットプロトコルバージョン6。 IPv4を呼んで、あいまいさを避けるのに必要であるところで文脈だけで使用されます。
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などのトランスポート・プロトコルである、OSPFや、インターネットなどのプロトコルを発送して、ICMPなどのプロトコルを制御するか、または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.
ユニキャストアドレス--単一のインタフェースのための識別子。 ユニキャストアドレスに送られたパケットはそのアドレスによって特定されたインタフェースに提供されます。
Thomson & Narten Standards Track [Page 4] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[4ページ]RFC2462IPv6
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 [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ディスカバリーパケットを受け入れます。
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)からインタフェースを送ったので、都合のよいアドレスは使用されるかもしれません。
Thomson & Narten Standards Track [Page 5] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[5ページ]RFC2462IPv6
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 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 identifier - a link-dependent identifier for an interface
that is (at least) unique per link [ADDR-ARCH]. 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., [IPv6-ETHER]). In many
cases, the identifier will be the same as the interface's link-
layer address.
識別子を連結してください--リンク[ADDR-ARCH]単位で(少なくとも)ユニークなインタフェースのためのリンク依存する識別子。 状態がないアドレス自動構成は、アドレスを形成するためにインタフェース識別子を接頭語に結合します。 アドレス自動構成の見解から、インタフェース識別子は知られている長さのしばらくストリングです。 インタフェース識別子とそれが作成される方法の正確な長さは特定のリンク型(例えば、[IPv6-ETHER])でIPのトランスミッションに関連する問題をカバーする別々のリンク型特定のドキュメントで定義されます。 多くの場合、識別子はインタフェースのものが層のアドレスをリンクするのと同じになるでしょう。
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 [KEYWORDS].
キーワードが解釈しなければならない、本書では現れるとき、[KEYWORDS]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
Thomson & Narten Standards Track [Page 6] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[6ページ]RFC2462IPv6
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 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 identifier 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 7] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[7ページ]RFC2462IPv6
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 identifier 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 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 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 8] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[8ページ]RFC2462IPv6
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 identifier. Thus, if a node has already verified the uniqueness of a link-local address, additional addresses created from the same interface identifier 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 9] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[9ページ]RFC2462IPv6
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 10] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[10ページ]RFC2462IPv6
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個のベースで以下の変数を維持します:
Thomson & Narten Standards Track [Page 11] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[11ページ]RFC2462IPv6
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 configured using the stateful
autoconfiguration mechanism. It starts out in a
FALSE state.
MからのManagedFlag Copiedは最も最近受信されたRouter Advertisementメッセージの分野(すなわち、「管理されたアドレス構成」旗)に旗を揚げさせます。 旗は、アドレスが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 is to be obtained using the
stateful autoconfiguration mechanism. It starts
out in a FALSE state.
大部分のO旗の分野(すなわち、「他のstateful構成」旗)からのOtherConfigFlag Copiedは最近、Router Advertisementメッセージを受け取りました。 旗は、アドレス以外の情報がstateful自動構成メカニズムを使用することで得られるかどうかことであることを示します。 それはFALSE状態で始めます。
In addition, when the value of the ManagedFlag is
TRUE, the value of OtherConfigFlag is implicitely
TRUE as well. It is not a valid configuration for
a host to use stateful address autoconfiguration
to request addresses only, without also accepting
other configuration
information.
ManagedFlagの値がTRUEであるときに、さらに、OtherConfigFlagの値はまた、implicitely TRUEです。 ホストがアドレスだけを要求するのにstatefulアドレス自動構成を使用するのは、有効な構成ではありません、また、他の設定情報を受け入れないで。
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.
- インタフェースは行政上無効にされた後に、システム管理で可能にされるようになります。
Thomson & Narten Standards Track [Page 12] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[12ページ]RFC2462IPv6
A link-local address is formed by prepending the well-known link- local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the interface identifier. If the interface identifier has a length of N bits, the interface identifier replaces the right-most N zero bits of the link-local prefix. If the interface identifier is more than 118 bits in length, autoconfiguration fails and manual configuration is required. Note that interface identifiers will typically be 64-bits long and based on EUI-64 identifiers as described in [ADDR-ARCH].
リンクローカルアドレスはよく知られるリンク地方の接頭語FE80をprependingすることによって、形成されます:、:0 インタフェース識別子への[ADDR-ARCH。](適切な長さの) インタフェース識別子にNビットの長さがあるなら、インタフェース識別子はリンクローカルの接頭語のN最も権利ゼロ・ビットを置き換えます。 インタフェース識別子は長さが118ビット以上であるなら、自動構成が失敗します、そして、手動の構成が必要です。 インタフェース識別子が長いのとEUI-64識別子に基づいて[ADDR-ARCH]で説明されるように通常64ビットになることに注意してください。
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 is performed on unicast addresses prior to assigning them to an interface whose DupAddrDetectTransmits variable is greater than zero. Duplicate Address Detection MUST take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration, with the exception of the following cases:
DupAddrDetectTransmits変数がゼロ以上であるインタフェースにそれらを割り当てる前に、写しAddress Detectionはユニキャストアドレスに実行されます。 写しAddress Detectionはすべてのユニキャストアドレスで行われなければなりません、statefulを通してそれらを得るかどうかにかかわらず、状態がないか手動の構成、以下のケースを除いて:
- Duplicate Address Detection MUST NOT be performed on anycast
addresses.
- anycastアドレスに写しAddress Detectionを実行してはいけません。
- Each individual unicast address SHOULD be tested for uniqueness.
However, when stateless address autoconfiguration is used,
address uniqueness is determined solely by the interface
identifier, assuming that subnet prefixes are assigned correctly
(i.e., if all of an interface's addresses are generated from the
same identifier, either all addresses or none of them will be
duplicates). Thus, for a set of addresses formed from the same
interface identifier, it is sufficient to check that the link-
local address generated from the identifier is unique on the
link. In such cases, the link-local address MUST be tested for
uniqueness, and if no duplicate address is detected, an
implementation MAY choose to skip Duplicate Address Detection
for additional addresses derived from the same interface
identifier.
- それぞれの個々のユニキャストはSHOULDを扱います。ユニークさがないかどうかテストされます。 しかしながら、状態がないアドレス自動構成が使用されているとき、アドレスのユニークさは唯一インタフェース識別子で決定します、サブネット接頭語が正しく割り当てられると仮定して(すなわち、インタフェースのアドレスのすべてが同じ識別子から生成されると、それらのすべてのアドレスかいずれのどちらかも写しにならないでしょう)。 したがって、同じインタフェース識別子から形成された1セットのアドレスでは、識別子から生成されたリンクローカルアドレスがリンクでユニークであることをチェックするのが十分です。 そのような場合、ユニークさがないかどうかリンクローカルアドレスをテストしなければなりません、そして、写しアドレスが全く検出されないなら、実装は同じインタフェース識別子から得られた追加アドレスのために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
写しアドレスを検出するための手順は以下で説明されるようにNeighbor SolicitationとAdvertisementメッセージを使用します。 写しアドレスが手順の間、発見されるなら、アドレスをインタフェースに割り当てることができません。 インタフェース識別子からアドレスを得ると、新しい識別子が、インタフェースに割り当てられる必要があるだろうか、またはインタフェースへのすべてのIPアドレスが、手動で構成される必要があるでしょう。 写しを検出するためのメソッドが完全に信頼できるというわけではなくて、それが可能であることに注意してください、その写し
Thomson & Narten Standards Track [Page 13] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[13ページ]RFC2462IPv6
addresses will still exist (e.g., if the link was partitioned while Duplicate Address Detection was performed).
それでも、アドレスは存在するでしょう(例えば、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, 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 [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,
アドレスをチェックするために、ノードはDupAddrDetectTransmits Neighbor Solicitations、RetransTimerミリセカンドと同じくらい切り離されたそれぞれを送ります。 懇願のTarget Addressはチェックされるアドレスに用意ができています。
Thomson & Narten Standards Track [Page 14] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[14ページ]RFC2462IPv6
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.
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 all cases, a node MUST NOT respond to a Neighbor Solicitation for a tentative address.
インタフェースに関する有効なNeighbor Solicitationメッセージを受け取り次第、ノードの振舞いはあて先アドレスが一時的であるかどうかよります。 あて先アドレスが一時的でないなら(すなわち、それは受信インタフェースに割り当てられます)、懇願は[ディスカバリー]で説明されるように処理されます。 あて先アドレスが一時的であり、ソースアドレスがユニキャストアドレスであるなら、懇願の送付者はアドレス解決を目標に実行しています。 懇願は静かに無視されるべきです。 さもなければ、処理は以下で説明されるように行われます。 すべての場合では、ノードは一時的なアドレスのために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:
以下のテストは一時的なアドレスがユニークでない状態を特定します:
Thomson & Narten Standards Track [Page 15] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[15ページ]RFC2462IPv6
- 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 formed from an interface identifier, the interface SHOULD be disabled.
上で説明されるように写しであることを決定している一時的なアドレス、インタフェースに割り当てられてはいけなくて、ノードSHOULDはシステム管理誤りを登録します。 リンクローカルアドレスはアドレスであるならインタフェース識別子、インタフェースSHOULDから形成されます。無効にされます。
5.5. Creation of Global and Site-Local Addresses
5.5. グローバルでサイトローカルのアドレスの作成
Global and site-local 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 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を出します。
Thomson & Narten Standards Track [Page 16] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[16ページ]RFC2462IPv6
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, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address autoconfiguration protocol, requesting both address information and other information. If the value of the ManagedFlag changes from TRUE to FALSE, the host should continue running the stateful address autoconfiguration, i.e., the change in the value of the ManagedFlag has no effect. 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アドレス自動構成プロトコルを実行していないなら、ホストはstatefulアドレス自動構成プロトコルを呼び出すべきです、アドレス情報と他の情報の両方を要求して。 ManagedFlagの値がTRUEからFALSEに変化するなら、ホストは、statefulアドレス自動構成を実行し続けるべきです、すなわち、ManagedFlagの値における変化が効き目がありません。 旗の値が変わりがない状態で残っているなら、どんな特別な動きも行われません。 特に、ホストは以前の広告の結果、既に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 information (excluding addresses if ManagedFlag is set to FALSE). If the value of the OtherConfigFlag changes from TRUE to FALSE, the host should continue running the stateful address autoconfiguration protocol, i.e., the change in the value of OtherConfigFlag has no effect. 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.
広告Oの旗の分野は類似の方法で処理されます。 ホストはO旗の値をOtherConfigFlagにコピーします。 OtherConfigFlagの値がFALSEからTRUEに変化するなら、ホストはstateful自動構成プロトコルを呼び出すべきです、情報を要求して(ManagedFlagがFALSEに用意ができているならアドレスを除いて)。 OtherConfigFlagの値がTRUEからFALSEに変化するなら、ホストは、statefulアドレス自動構成プロトコルを実行し続けるべきです、すなわち、OtherConfigFlagの値における変化が効き目がありません。 旗の値が変わりがない状態で残っているなら、どんな特別な動きも行われません。 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情報オプションを無視してください。
Thomson & Narten Standards Track [Page 17] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[17ページ]RFC2462IPv6
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 does not match the prefix of an address
already in the list, and the Valid Lifetime is not 0, form an
address (and add it to the list) by combining the advertised
prefix with the link's interface identifier as follows:
d) 広告に掲載された接頭語が既にリストのアドレスの接頭語に合わないで、またValid Lifetimeが0歳でないなら、リンクのインタフェース識別子は以下の通りで広告を出している接頭語を結合することによって、アドレス(それをリストに追加する)を形成してください:
| 128 - N bits | N bits | +---------------------------------------+------------------------+ | link prefix | interface identifier | +----------------------------------------------------------------+
| 128--Nビット| Nビット| +---------------------------------------+------------------------+ | リンク接頭語| インタフェース識別子| +----------------------------------------------------------------+
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. 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
identifiers for that link type. Note that interface identifiers
will typically be 64-bits long and based on EUI-64 identifiers as
described in [ADDR-ARCH].
接頭語の長さとインタフェース識別子の長さの合計が128ビットと等しくないなら、Prefix情報オプションを無視しなければなりません。 実装はこの場合システム管理誤りを登録したがっているかもしれません。 そのリンク型にとって、Router Advertisementsに含まれた接頭語の長さがインタフェース識別子の長さと一致しているのを保障するのは、システム管理者の責任です。 インタフェース識別子が長いのとEUI-64識別子に基づいて[ADDR-ARCH]で説明されるように通常64ビットになることに注意してください。
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情報オプションから都合のよくて有効な生涯値を初期化して。
e) If the advertised prefix matches the prefix of an autoconfigured
address (i.e., one obtained via stateless or stateful address
autoconfiguration) in the list of addresses associated with the
interface, the specific action to perform depends on the Valid
Lifetime in the received advertisement and the Lifetime
associated with the previously autoconfigured address (which we
call StoredLifetime in the discussion that follows):
e) 広告を出している接頭語がインタフェースに関連している住所録の自動構成されたアドレス(すなわち、状態がないかstatefulなアドレス自動構成で得られたもの)の接頭語に合っているなら、実行する特定の動作は受け取られていている広告におけるValid Lifetimeと以前に自動構成されたアドレスに関連しているLifetime(私たちが続く議論でStoredLifetimeと呼ぶ)によります:
1) If the received Lifetime is greater than 2 hours or greater
than StoredLifetime, update the stored Lifetime of the
corresponding address.
1) 容認されたLifetimeがStoredLifetimeより2時間以上であるなら、対応するアドレスの保存されたLifetimeをアップデートしてください。
2) If the StoredLifetime is less than or equal to 2 hours and the
received Lifetime is less than or equal to StoredLifetime,
ignore the prefix, unless the Router Advertisement from which
2) StoredLifetimeが2時間以下であり、容認されたLifetimeが、よりStoredLifetime以下であるなら、接頭語を無視してください、Router Advertisement、どれ
Thomson & Narten Standards Track [Page 18] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[18ページ]RFC2462IPv6
this Prefix Information option was obtained has been
authenticated (e.g., via IPSec [RFC2402]). If the Router
Advertisment was authenticated, the StoredLifetime should be
set to the Lifetime in the received option.
このPrefix情報オプションを得ました。認証しました(例えば、IPSec[RFC2402]を通して)。 Router Advertismentが認証されるなら、StoredLifetimeは容認されたオプションでLifetimeに用意ができているでしょうに。
3) Otherwise, reset the stored Lifetime in the corresponding
address to two hours.
3) さもなければ、対応するアドレスに2時間まで保存されたLifetimeをリセットしてください。
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 Lifetimes could cause all of a node's
addresses to expire prematurely. The above rules insure that
legitimate advertisements (which are sent periodically) will
"cancel" the short lifetimes before they actually take effect.
上の規則は非常に小さいValid Lifetimesと共ににせの広告が接頭語を含むことができたサービス攻撃の部分的否認を扱います。 上の規則がなければ、シングルはノードのアドレスのすべてが早まって短いLifetimesと共ににせの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. IP and higher layers (e.g., TCP, UDP) 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, and the facility MUST be disabled by default.
都合のよい寿命が期限が切れると、都合のよいアドレスは推奨しなくなります。 SHOULDが続けている推奨しないアドレスがソースアドレスとして既存のコミュニケーションで使用されて、SHOULD NOTだけが代替の(非推奨しない)アドレスが利用可能であるなら新しいコミュニケーションで使用されて、十分な範囲を持っています。 IPと、より高い層(例えば、TCP、UDP)は、それでも、推奨しないアドレスがインタフェースへの有効なアドレスであるので推奨しないアドレスに運命づけられたデータグラムを受け入れ続けなければなりません。 システム管理には、そのような施設を無効にする能力がなければなりません、そして、実装は、どんな新しいコミュニケーションも推奨しないアドレスを使用するのを防ぐかもしれませんが、デフォルトで施設を無効にしなければなりません。
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 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なプロトコルを使用することで可能です。 また、MTUサイズやホップ限界などの他の設定パラメータの値がRouter Advertisementsとstateful自動構成プロトコルの両方から学習されるのも、可能です。 同じ設定情報が複数のソースによって提供されるなら、この情報の値は一貫しているべきです。 しかしながら、複数のソースから受け取られた情報が矛盾しているなら、それは致命的な誤りであると考えられません。 そしてホストが状態がなさであることを通して受け取られたすべての情報の組合を受け入れる。
Thomson & Narten Standards Track [Page 19] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[19ページ]RFC2462IPv6
stateful protocols. If inconsistent information is learned different sources, the most recently obtained values always have precedence over information learned earlier.
statefulプロトコル。 矛盾した情報が学識があるさまざまな原因であるなら、最も最近得られた値で、より早くいつも情報の上の先行について学習します。
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 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 [RFC2402].
Duplicate Address Detectionの使用はサービス不能攻撃の可能性を開けます。 どんなノードも一時的なアドレスのためにNeighbor Solicitationsに応じることができます、もう片方のノードが写しとしてアドレスを拒絶することを引き起こして。 この攻撃は、Neighborディスカバリーメッセージのスプーフィングにかかわる他の攻撃と同様であり、Neighborディスカバリーパケットが認証されるのを[RFC2402]必要とすることによって、扱うことができます。
7. References
7. 参照
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[IPv6-ETHER] Crawford, M., "A Method for the Transmission of
IPv6 Packets over Ethernet Networks", RFC 2464,
December 1998.
[IPv6-エーテル] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッションのためのメソッド」、RFC2464、1998年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March
1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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 2373, July 1998
[ADDR-アーチ] HindenとR.とS.デアリング、「インターネットプロトコルバージョン(IPv6)アドレッシング体系」、RFC2373、1998年7月
[DHCPv6] Bound, J. and C. Perkins, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", Work in Progress.
[DHCPv6]はバウンドしていて、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」というJ.とC.パーキンスは進行中で働いています。
Thomson & Narten Standards Track [Page 20] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[20ページ]RFC2462IPv6
[DISCOVERY] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[発見]NartenとT.とNordmarkとE.とW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
8. Acknowledgements
8. 承認
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, 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.
作者は彼らの入力のためのIPNGとADDRCONFワーキンググループの両方のメンバーに感謝したがっています。 特に、ジムBound、スティーブ・デアリング、リチャードDraves、およびエリックNordmarkをありがとうございます。 また、感謝では、サービスの「0生涯接頭語広告」否定のWGを警告するためのジョン・ギルモアに対して、脆弱性を攻撃するように言われています。 このドキュメントはこの脆弱性を扱う変化を取り入れます。
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@raleigh.ibm.com
以下に電話をしてください。 +1 7798年の919 254メール: narten@raleigh.ibm.com
Thomson & Narten Standards Track [Page 21] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[21ページ]RFC2462IPv6
9. APPENDIX A: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION
9. 付録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 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
o また、Duplicate Address Detection破棄を実行するノードが受信インタフェースと同じソースリンクレイヤアドレスを持っているパケットを受けたなら、他のノードからまた、同じリンクレイヤアドレスを使用することでパケットを捨てるでしょう、Duplicate Address Detectionを正しく働かせるのに必要であるNeighbor AdvertisementとNeighbor Solicitationメッセージを含んでいて。 これ
Thomson & Narten Standards Track [Page 22] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[22ページ]RFC2462IPv6
particular problem can be avoided 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] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に状態がないトムソンとNarten標準化過程[23ページ]RFC2462IPv6
10. APPENDIX B: CHANGES SINCE RFC 1971
10. 付録B: RFC1971以来の変化
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 Reworded section 5.4 for clarity (no substantive change).
o 明快(実質的な変化がない)ためにセクション5.4を言い換えました。
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 & Narten Standards Track [Page 24] RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
アドレス自動構成1998年12月に国がないトムソンとNarten標準化過程[24ページ]RFC2462IPv6
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Thomson & Narten Standards Track [Page 25]
トムソンとNarten標準化過程[25ページ]
一覧
スポンサーリンク
