Network Working Group R. Hinden
Request for Comments: 3513 Nokia
Obsoletes: 2373 S. Deering
Category: Standards Track Cisco Systems
April 2003
Internet Protocol Version 6 (IPv6) Addressing Architecture
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.
この仕様は、IPバージョン6（IPv6）のプロトコルのアドレス体系を定義します。文書は、IPv6アドレッシングモデル、IPv6アドレスのテキスト表現、IPv6ユニキャストアドレスの定義、エニーキャストアドレス、マルチキャストアドレス、およびIPv6ノードの必要なアドレスを含んでいます。
Table of Contents
目次
1. Introduction.................................................3
2. IPv6 Addressing..............................................3
2.1 Addressing Model.........................................4
2.2 Text Representation of Addresses.........................4
2.3 Text Representation of Address Prefixes..................5
2.4 Address Type Identification..............................6
2.5 Unicast Addresses........................................7
2.5.1 Interface Identifiers..............................8
2.5.2 The Unspecified Address............................9
2.5.3 The Loopback Address...............................9
2.5.4 Global Unicast Addresses..........................10
2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.......10
2.5.6 Local-use IPv6 Unicast Addresses..................11
2.6 Anycast Addresses.......................................12
2.6.1 Required Anycast Address..........................13
2.7 Multicast Addresses.....................................13
2.7.1 Pre-Defined Multicast Addresses...................15
2.8 A Node's Required Addresses.............................17
3. Security Considerations.....................................17
4. IANA Considerations.........................................18
5. References..................................................19
5.1 Normative References....................................19
5.2 Informative References..................................19
APPENDIX A: Creating Modified EUI-64 format Interface IDs......21
APPENDIX B: Changes from RFC-2373..............................24
Authors' Addresses.............................................25
Full Copyright Statement.......................................26
This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. It includes the basic formats for the various types of IPv6 addresses (unicast, anycast, and multicast).
この仕様は、IPバージョン6（IPv6）のプロトコルのアドレス体系を定義します。これは、IPv6アドレス（ユニキャスト、エニーキャスト、およびマルチキャスト）の様々なタイプの基本的なフォーマットを含みます。
The authors would like to acknowledge the contributions of Paul Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, Sue Thomson, Markku Savela, and Larry Masinter.
著者は、ポール・フランシス、スコット・ブラッドナー、ジム・バウンド、ブライアン・カーペンター、マット・クロフォード、デボラ・エストリン、ロジャーFajman、ボブ・フィンク、ピーター・フォード、ボブギリガン、ドミトリーHaskin、トムHarsch、クリスチャンのHuitema、トニー・リーの貢献を認めるしたいと思います、グレッグMinshall、トーマスNarten氏、エリックNordmarkと、ヤコフ・レックター、ビル・シンプソン、スー・トムソン、マルックSavela、およびラリーMasinter。
IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces (where "interface" is as defined in section 2 of [IPV6]). There are three types of addresses:
IPv6アドレスは、インターフェイスとインターフェイスのセットの128ビットの識別子（[IPV6]のセクション2で定義される「インターフェース」がある）です。アドレスの3つのタイプがあります。
Unicast: An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address.
ユニキャスト：単一のインタフェースの識別子。ユニキャストアドレスに送信されたパケットは、そのアドレスによって識別されるインターフェースに送達されます。
Anycast: 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 protocols' measure of distance).
エニーキャスト：（通常、異なるノードに属している）インターフェイスのセットのための識別子。エニーキャストアドレスに送信されたパケットは、（距離のルーティングプロトコル尺度によると、「最も近い」もの）、そのアドレスによって識別されるインターフェイスのいずれかに送達されます。
Multicast: 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.
マルチキャスト：（通常、異なるノードに属している）インターフェイスのセットのための識別子。マルチキャストアドレスに送信されたパケットは、そのアドレスによって識別されるすべてのインタフェースに配信されます。
There are no broadcast addresses in IPv6, their function being superseded by multicast addresses.
IPv6ではブロードキャストアドレス、その機能は、マルチキャストアドレスに取って代わられているがありません。
In this document, fields in addresses are given a specific name, for example "subnet". When this name is used with the term "ID" for identifier after the name (e.g., "subnet ID"), it refers to the contents of the named field. When it is used with the term "prefix" (e.g., "subnet prefix") it refers to all of the address from the left up to and including this field.
この文書では、アドレスのフィールドは、例えば「サブネット」を具体的な名前を与えられています。この名前は、名前の後に識別子のために、用語「ID」（例えば、「サブネットID」）で使用される場合、それは名前のフィールドの内容を参照します。それは用語「プレフィックス」（例えば、「サブネットプレフィックス」）で使用される場合には、最大左このフィールドを含むからのアドレスの全てを指します。
In IPv6, all zeros and all ones are legal values for any field, unless specifically excluded. Specifically, prefixes may contain, or end with, zero-valued fields.
特に除外しない限り、IPv6では、すべてゼロとすべてのものは、任意のフィールドの正当な値です。具体的に、プレフィックスが含まれ、または、ゼロ値のフィールドを終了してもよいです。
IPv6 addresses of all types are assigned to interfaces, not nodes. An IPv6 unicast address refers to a single interface. Since each interface belongs to a single node, any of that node's interfaces' unicast addresses may be used as an identifier for the node.
すべてのタイプのIPv6アドレスはインターフェースではなく、ノードに割り当てられています。 IPv6ユニキャストアドレスは、単一のインタフェースを指します。各インターフェースは、単一のノードに属しているので、そのノードのインタフェースユニキャストアドレスのいずれかが、ノードの識別子として使用することができます。
All interfaces are required to have at least one link-local unicast address (see section 2.8 for additional required addresses). A single interface may also have multiple IPv6 addresses of any type (unicast, anycast, and multicast) or scope. Unicast addresses with scope greater than link-scope are not needed for interfaces that are not used as the origin or destination of any IPv6 packets to or from non-neighbors. This is sometimes convenient for point-to-point interfaces. There is one exception to this addressing model:
すべてのインターフェイスは、少なくとも1つのリンクローカルユニキャストアドレスを（追加の必須アドレスのセクション2.8を参照）が要求されます。単一のインターフェースは、任意のタイプ（ユニキャスト、エニーキャスト、およびマルチキャスト）またはスコープの複数のIPv6アドレスを有していてもよいです。リンクスコープより大きいスコープを持つユニキャストアドレスは、または非隣人から任意のIPv6パケットの発信元または宛先として使用されていないインターフェイスのために必要とされません。これは、ポイントツーポイントインターフェイスの時々便利です。このアドレッシング・モデルには1つ例外があります
A unicast address or a set of unicast addresses may be assigned to multiple physical interfaces if the implementation treats the multiple physical interfaces as one interface when presenting it to the internet layer. This is useful for load-sharing over multiple physical interfaces.
インターネット層にそれを提示するときの実装は一つのインタフェースとして複数の物理インターフェースを扱う場合は、ユニキャストアドレス又はユニキャストアドレスのセットは、複数の物理インタフェースに割り当てられてもよいです。これは、複数の物理インタフェース上に負荷分散するために有用です。
Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link.
現在、IPv6は、サブネットプレフィックスを1つのリンクに関連付けられているIPv4のモデルを続けています。複数のサブネットプレフィックスが同じリンクに割り当ててもよいです。
There are three conventional forms for representing IPv6 addresses as text strings:
テキスト文字列としてのIPv6アドレスを表現するための従来の3つの形式があります。
1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal values of the eight 16-bit pieces of the address.
1.好ましい形態は、X：X：X：X：X：X：X：X「Xはアドレスの8つの16ビット部分の16進数値がどこにありますか。
Examples:
例：
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
FEDC：BA98：7654：3210：FEDC：BA98：3210：7654
1080:0:0:0:8:800:200C:417A
1080：0：0：0：8：800：200C：417A
Note that it is not necessary to write the leading zeros in an individual field, but there must be at least one numeral in every field (except for the case described in 2.).
個々のフィールドに先行ゼロを書き込む必要はないことに留意されたいが、（2で説明した場合を除く）すべてのフィールド内に少なくとも1つの符号が存在しなければなりません。
2. Due to some methods of allocating certain styles of IPv6 addresses, it will be common for addresses to contain long strings of zero bits. In order to make writing addresses containing zero bits easier a special syntax is available to compress the zeros.
アドレスはゼロのビットの長いストリングを含有する2によりIPv6アドレスの特定のスタイルを割り当てるいくつかの方法、それが一般的であろう。簡単に特別な構文をゼロビットを含む書き込みアドレスを作るためにゼロを圧縮することが可能です。
The use of "::" indicates one or more groups of 16 bits of zeros. The "::" can only appear once in an address. The "::" can also be used to compress leading or trailing zeros in an address.
「::」の使用は、ゼロの16ビットの1つまたは複数のグループを示しています。 「::」だけアドレスに一度現れることができます。 「::」は、アドレスに先頭または末尾のゼロを圧縮するために使用することができます。
For example, the following addresses:
たとえば、次のアドレス：
1080:0:0:0:8:800:200C:417A a unicast address FF01:0:0:0:0:0:0:101 a multicast address 0:0:0:0:0:0:0:1 the loopback address 0:0:0:0:0:0:0:0 the unspecified addresses
1080：0：0：0：8：800：200C：417AユニキャストアドレスFF01：0：0：0：0：0：0：101マルチキャストアドレス0：0：0：0：0：0：0： 1ループバックアドレス0：0：0：0：0：0：0：0未指定アドレス
may be represented as:
以下のように表すことができます。
1080::8:800:200C:417A a unicast address FF01::101 a multicast address ::1 the loopback address :: the unspecified addresses
1080 :: 8：800：200C：417AユニキャストアドレスFF01 :: 101マルチキャストアドレス:: 1つのループバックアドレス::未指定アドレス
3. An alternative form that is sometimes more convenient when dealing with a mixed environment of IPv4 and IPv6 nodes is x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of the six high-order 16-bit pieces of the address, and the 'd's are the decimal values of the four low-order 8-bit pieces of the address (standard IPv4 representation). Examples:
3. IPv4およびIPv6ノードが混在する環境を扱う場合、時にはより便利な代替形態がされているX：X：X：X：X：X：DDDD、「Xさんは、6つ上位の16進数の値であります16ビット・アドレスの断片、および「D'sはアドレス（標準IPv4の表現）の4下位8ビット部分の小数値です。例：
0:0:0:0:0:0:13.1.68.3
０：０：０：０：０：０：１３。１。６８。３
0:0:0:0:0:FFFF:129.144.52.38
0：0：0：0：0：FFFF：129.144.52.38
or in compressed form:
または圧縮形式で：
::13.1.68.3
：：１３。１。６８。３
::FFFF:129.144.52.38
:: FFFF：129.144.52.38
The text representation of IPv6 address prefixes is similar to the way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An IPv6 address prefix is represented by the notation:
IPv6アドレスプレフィックスのテキスト表現は、IPv4のプレフィックスが[CIDR] CIDR表記で書かれているアドレスの方法に類似しています。 IPv6アドレスプレフィックスは、表記で表されます。
ipv6-address/prefix-length
IPv6のアドレス/プレフィックス長
where
どこ
ipv6-address is an IPv6 address in any of the notations listed in section 2.2.
IPv6のアドレスは、セクション2.2に記載されている表記法のいずれかでのIPv6アドレスです。
prefix-length is a decimal value specifying how many of the leftmost contiguous bits of the address comprise the prefix.
プレフィックス長は、プレフィックスを含むアドレスの左端の連続するビットの数を指定する10進値です。
For example, the following are legal representations of the 60-bit prefix 12AB00000000CD3 (hexadecimal):
例えば、以下は60ビットのプレフィックス12AB00000000CD3（16進数）の法的表現です。
12AB:0000:0000:CD30:0000:0000:0000:0000/60 12AB::CD30:0:0:0:0/60 12AB:0:0:CD30::/60
12AB：0000：0000：CD30：0000：0000：0000：0000/60 12AB :: CD30：0：0：0：0/60 12AB：0：0：CD30 :: / 60
The following are NOT legal representations of the above prefix:
以下は、上記の接頭辞の法的表現されていません。
12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, within any 16-bit chunk of the address
12AB：0：0 CD3 / 60は、アドレスの任意の16ビットのチャンク内に、先行ゼロを削除するが、ゼロを末尾ないかもしれません
12AB::CD30/60 address to left of "/" expands to 12AB:0000:0000:0000:0000:000:0000:CD30
0000：0000：0000 0000：0000：000 CD30 "/" 12ABに展開の左に12AB :: CD30 / 60アドレス
12AB::CD3/60 address to left of "/" expands to 12AB:0000:0000:0000:0000:000:0000:0CD3
0000：0000：0000：000：0000 0000：0CD3 12AB ::の左側にCD3 / 60アドレスが "/" 12ABに展開します
When writing both a node address and a prefix of that node address (e.g., the node's subnet prefix), the two can combined as follows:
ノードアドレスとそのノードのアドレス（例えば、ノードのサブネットプレフィックス）の接頭辞の両方を記述する場合、以下のように、2つを組み合わせることができます。
the node address 12AB:0:0:CD30:123:4567:89AB:CDEF and its subnet number 12AB:0:0:CD30::/60
ノードアドレス12AB：0：0：CD30：123：4567：89AB：CDEFとそのサブネット番号12AB：0：0：CD30 :: / 60
can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
0：0：CD30：123：4567：89AB：CDEF / 60 12ABと略記することができます
The type of an IPv6 address is identified by the high-order bits of the address, as follows:
次のようにIPv6アドレスのタイプは、アドレスの上位ビットによって識別されます。
Address type Binary prefix IPv6 notation Section
------------ ------------- ------------- -------
Unspecified 00...0 (128 bits) ::/128 2.5.2
Loopback 00...1 (128 bits) ::1/128 2.5.3
Multicast 11111111 FF00::/8 2.7
Link-local unicast 1111111010 FE80::/10 2.5.6
Site-local unicast 1111111011 FEC0::/10 2.5.6
Global unicast (everything else)
Anycast addresses are taken from the unicast address spaces (of any scope) and are not syntactically distinguishable from unicast addresses.
エニーキャストアドレスは、（任意の範囲の）ユニキャストアドレス空間から採取し、ユニキャストアドレスから構文的に区別できるものではありません。
The general format of global unicast addresses is described in section 2.5.4. Some special-purpose subtypes of global unicast addresses which contain embedded IPv4 addresses (for the purposes of IPv4-IPv6 interoperation) are described in section 2.5.5.
グローバルユニキャストアドレスの一般的な形式は、セクション2.5.4に記載されています。 （のIPv4-IPv6の相互運用のために）埋め込まれたIPv4アドレスを含むグローバルユニキャストアドレスの一部専用のサブタイプは、セクション2.5.5に記載されています。
Future specifications may redefine one or more sub-ranges of the global unicast space for other purposes, but unless and until that happens, implementations must treat all addresses that do not start with any of the above-listed prefixes as global unicast addresses.
将来の仕様は、他の目的のためのグローバルユニキャスト・スペースの1つ以上のサブ範囲を再定義するかもしれないが、ないとそれが起こるまで、実装がグローバルユニキャストアドレスとして上記で列挙されたプレフィックスのいずれかで始まらないすべてのアドレスを扱う必要があります。
IPv6 unicast addresses are aggregable with prefixes of arbitrary bit-length similar to IPv4 addresses under Classless Interdomain Routing.
IPv6ユニキャストアドレスは、クラスレスドメイン間ルーティングの下でIPv4アドレスに類似する任意のビット長の接頭辞aggregableあります。
There are several types of unicast addresses in IPv6, in particular global unicast, site-local unicast, and link-local unicast. There are also some special-purpose subtypes of global unicast, such as IPv6 addresses with embedded IPv4 addresses or encoded NSAP addresses. Additional address types or subtypes can be defined in the future.
特にグローバルユニキャスト、サイトローカルユニキャスト、およびリンクローカルユニキャストでのIPv6ユニキャストアドレスにはいくつかの種類があります。 IPv6が埋め込まれたIPv4アドレスまたは符号化されたNSAPアドレスとアドレスのようなグローバルユニキャストのいくつかの特別な目的のサブタイプも存在します。追加のアドレスタイプまたはサブタイプは、将来的に定義することができます。
IPv6 nodes may have considerable or little knowledge of the internal structure of the IPv6 address, depending on the role the node plays (for instance, host versus router). At a minimum, a node may consider that unicast addresses (including its own) have no internal structure:
IPv6ノードは、ロールノード再生（例えば、ホスト対ルータ）に応じて、IPv6アドレスの内部構造のかなりの又は少しの知識を有していてもよいです。最低でも、ノードは、（それ自身を含む）のユニキャストアドレスには内部構造を有していないことを考慮してもよいです。
| 128 bits |
+-----------------------------------------------------------------+
| node address |
+-----------------------------------------------------------------+
A slightly sophisticated host (but still rather simple) may additionally be aware of subnet prefix(es) for the link(s) it is attached to, where different addresses may have different values for n:
わずかに洗練されたホスト（それでもかなり単純）はさらに異なるアドレスがnの異なる値を有していてもよく、それが接続されているリンク（複数可）のサブネットプレフィックス（複数可）を認識することができます。
| n bits | 128-n bits |
+------------------------------------------------+----------------+
| subnet prefix | interface ID |
+------------------------------------------------+----------------+
Though a very simple router may have no knowledge of the internal structure of IPv6 unicast addresses, routers will more generally have knowledge of one or more of the hierarchical boundaries for the operation of routing protocols. The known boundaries will differ from router to router, depending on what positions the router holds in the routing hierarchy.
非常に単純なルータはIPv6ユニキャストアドレスの内部構造の知識がないかもしれないが、ルータは、より一般的には、ルーティングプロトコルの動作のための階層の境界のうちの1つ以上の知識を持っています。知られている境界ルータは、ルーティング階層で保持しているどのような位置に応じて、ルータにルータとは異なります。
Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet prefix. It is recommended that the same interface identifier not be assigned to different nodes on a link. They may also be unique over a broader scope. In some cases an interface's identifier will be derived directly from that interface's link-layer address. The same interface identifier may be used on multiple interfaces on a single node, as long as they are attached to different subnets.
IPv6ユニキャストアドレスのインタフェース識別子は、リンク上のインターフェイスを識別するために使用されます。これらは、サブネットプレフィックス内で一意であることが要求されています。同一のインタフェース識別子は、リンク上の異なるノードに割り当てられないことが推奨されます。彼らはまた、より広い範囲で固有のものとすることができます。いくつかのケースでは、インタフェースの識別子は、そのインターフェイスのリンク層アドレスから直接誘導されます。同じインタフェース識別子は、それらが別のサブネットに接続されている限り、単一のノード上に複数のインタフェース上で使用することができます。
Note that the uniqueness of interface identifiers is independent of the uniqueness of IPv6 addresses. For example, a global unicast address may be created with a non-global scope interface identifier and a site-local address may be created with a global scope interface identifier.
インタフェース識別子のユニークさは、IPv6アドレスの一意性とは無関係であることに注意してください。例えば、グローバルユニキャストアドレスは非グローバルスコープのインタフェース識別子を使用して作成することができ、サイトローカルアドレスは、グローバルスコープのインタフェース識別子を使用して作成されてもよいです。
For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format.
すべてのユニキャストアドレスの場合、バイナリ値000で始まるものを除いて、インタフェースIDは64ビット長であり、かつ変形EUI-64フォーマットに構築する必要があります。
Modified EUI-64 format based Interface identifiers may have global scope when derived from a global token (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a global token is not available (e.g., serial links, tunnel end-points, etc.) or where global tokens are undesirable (e.g., temporary tokens for privacy [PRIV]).
修飾EUI64フォーマットベースのインタフェース識別子は、グローバルトークン（例えば、IEEE 802の48ビットMACまたはIEEE EUI64識別子[EUI64]）に由来する場合、グローバルスコープを有していてもよく、グローバルトークンが利用できないローカルスコープを有することができます（例えば、シリアルリンク、トンネルエンドポイントなど）またはグローバルトークンが（望ましくない場合、例えば、プライバシーのために一時的トークン[PRIV]）。
Modified EUI-64 format interface identifiers are formed by inverting the "u" bit (universal/local bit in IEEE EUI-64 terminology) when forming the interface identifier from IEEE EUI-64 identifiers. In the resulting Modified EUI-64 format the "u" bit is set to one (1) to indicate global scope, and it is set to zero (0) to indicate local scope. The first three octets in binary of an IEEE EUI-64 identifier are as follows:
修飾されたEUI-64フォーマットのインターフェース識別子は、IEEE EUI-64識別子からインタフェース識別子を形成する際に「U」ビット（IEEE EUI-64用語でユニバーサル/ローカルビット）を反転させることによって形成されています。得られた変性EUI-64フォーマットで「U」ビットは、（1）グローバルスコープを示すために1に設定され、ローカルスコープを示すためにゼロ（0）に設定されています。次のようにIEEE EUI-64識別子のバイナリの最初の3つのオクテットは、次のとおり
0 0 0 1 1 2
|0 7 8 5 6 3|
+----+----+----+----+----+----+
|cccc|ccug|cccc|cccc|cccc|cccc|
+----+----+----+----+----+----+
written in Internet standard bit-order , where "u" is the universal/local bit, "g" is the individual/group bit, and "c" are the bits of the company_id. Appendix A: "Creating Modified EUI-64 format
個人/グループビットは、インターネット標準のビット順序、ここで「u」はユニバーサル/ローカルビットであり、「G」である書かれ、そして「c」はのcompany_idのビットです。付録A：「修正EUI-64フォーマットの作成
Interface Identifiers" provides examples on the creation of Modified EUI-64 format based interface identifiers.
インターフェース識別子は、」修飾EUI-64フォーマットベースのインタフェース識別子の作成に例を提供します。
The motivation for inverting the "u" bit when forming an interface identifier is to make it easy for system administrators to hand configure non-global identifiers when hardware tokens are not available. This is expected to be case for serial links, tunnel end-points, etc. The alternative would have been for these to be of the form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2, etc.
インタフェース識別子を形成する際に「U」ビットを反転させるための動機は、それが簡単にハードウェアトークンが利用できないときの非グローバル識別子を設定し、システム管理者が手できるようにすることです。 0：0：1、0200：0：0：2など、代わりにこれは、0200形式のものの代替は、これらのためであったであろう等シリアルリンク、トンネルエンドポイントのためのケースであることが期待されますはるかに簡単な1、2、など
The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with global scope.
変更されたEUI-64フォーマット識別子でユニバーサル/ローカルビットを使用すると、グローバルスコープとのインタフェース識別子を利用することができ、将来の技術の開発を可能にすることです。
The details of forming interface identifiers are defined in the appropriate "IPv6 over <link>" specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
形成インタフェース識別子の詳細は、例えば、「イーサネット上のIPv6」として指定[ETHER]「<リンク>上のIPv6」適切に定義されている、「IPv6のFDDI上」[FDDI]など
The address 0:0:0:0:0:0:0:0 is called the unspecified address. It must never be assigned to any node. It indicates the absence of an address. One example of its use is in the Source Address field of any IPv6 packets sent by an initializing host before it has learned its own address.
アドレス0：0：0：0：0：0：0：0は未指定アドレスと呼ばれています。これは、任意のノードに割り当ててはなりません。これは、アドレスがないことを示します。それは自分自身のアドレスを学習している前に、その使用の一例は、初期化ホストによって送信されたIPv6パケットの送信元アドレスフィールドです。
The unspecified address must not be used as the destination address of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a source address of unspecified must never be forwarded by an IPv6 router.
未指定アドレスは、IPv6パケットの宛先アドレスとして、またはIPv6ルーティングヘッダで使用されてはなりません。未指定の送信元アドレスを持つIPv6パケットは、IPv6ルータによって転送してはなりません。
The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It may be used by a node to send an IPv6 packet to itself. It may never be assigned to any physical interface. It is treated as having link-local scope, and may be thought of as the link-local unicast address of a virtual interface (typically called "the loopback interface") to an imaginary link that goes nowhere.
ユニキャストアドレス0：0：0：0：0：0：0：1は、ループバックアドレスと呼ばれます。それ自体にIPv6パケットを送信するためにノードによって使用されてもよいです。これは、任意の物理インターフェイスに割り当てされない場合があります。これは、リンクローカルスコープを持つものとして扱われ、仮想インターフェイスのリンクローカルユニキャストアドレスがどこにも行かない仮想リンクに（典型的には、「ループバックインターフェース」と呼ばれる）と考えることができます。
The loopback address must not be used as the source address in IPv6 packets that are sent outside of a single node. An IPv6 packet with a destination address of loopback must never be sent outside of a single node and must never be forwarded by an IPv6 router. A packet received on an interface with destination address of loopback must be dropped.
ループバックアドレスは、単一ノードの外に送信されるIPv6パケットのソースアドレスとして使用してはなりません。ループバックの宛先アドレスを持つIPv6パケットは、単一ノードの外に送信してはならないとIPv6ルータによって転送してはなりません。ループバックの宛先アドレスを持つインターフェイスで受信したパケットは廃棄されなければなりません。
The general format for IPv6 global unicast addresses is as follows:
次のようにIPv6グローバルユニキャストアドレスのための一般的な形式は次のとおりです。
| n bits | m bits | 128-n-m bits |
+------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |
+------------------------+-----------+----------------------------+
where the global routing prefix is a (typically hierarchically-structured) value assigned to a site (a cluster of subnets/links), the subnet ID is an identifier of a link within the site, and the interface ID is as defined in section 2.5.1.
グローバルルーティングプレフィックスはサイト（サブネット/リンクのクラスタ）に割り当てられた（典型的には階層構造）の値である場合、サブネットIDは、サイト内のリンクの識別子であり、インタフェースIDは、セクション2.5で定義されています0.1。
All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field.
バイナリ000で始まるもの以外のすべてのグローバルユニキャストアドレスは、セクション2.5.1に記載されるようにフォーマットされた64ビットのインタフェースIDフィールド（すなわち、N + M = 64）を有します。バイナリ000で始まるグローバルユニキャストアドレスは、インタフェースIDフィールドのサイズや構造にはそのような制約を持ちません。
Examples of global unicast addresses that start with binary 000 are the IPv6 address with embedded IPv4 addresses described in section 2.5.5 and the IPv6 address containing encoded NSAP addresses specified in [NSAP]. An example of global addresses starting with a binary value other than 000 (and therefore having a 64-bit interface ID field) can be found in [AGGR].
バイナリ000で始まるグローバルユニキャストアドレスの例は、セクション2.5.5および[NSAP]で指定された符号化されたNSAPアドレスを含むIPv6アドレスで説明埋め込まれたIPv4アドレスとIPv6アドレスです。グローバル000以外のバイナリ値で始まるアドレス（したがって、64ビット・インタフェースIDフィールドを有する）の例は、[AGGR]に見出すことができます。
The IPv6 transition mechanisms [TRAN] include a technique for hosts and routers to dynamically tunnel IPv6 packets over IPv4 routing infrastructure. IPv6 nodes that use this technique are assigned special IPv6 unicast addresses that carry a global IPv4 address in the low-order 32 bits. This type of address is termed an "IPv4- compatible IPv6 address" and has the format:
IPv6移行メカニズム[TRAN]はホストとIPv4ルーティングインフラストラクチャ上を動的にトンネルIPv6パケットをルータにするための技術を含みます。この技術を使用するIPv6ノードは、下位32ビットでグローバルIPv4アドレスを運ぶ特別なIPv6ユニキャストアドレスが割り当てられています。このタイプのアドレスは、「IPv4-互換IPv6アドレス」と呼ばれ、フォーマットを持ってされています。
| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|0000| IPv4 address |
+--------------------------------------+----+---------------------+
Note: The IPv4 address used in the "IPv4-compatible IPv6 address" must be a globally-unique IPv4 unicast address.
注：「IPv4互換IPv6アドレス」で使用されるIPv4アドレスはグローバルにユニークなIPv4ユニキャストアドレスでなければなりません。
A second type of IPv6 address which holds an embedded IPv4 address is also defined. This address type is used to represent the addresses of IPv4 nodes as IPv6 addresses. This type of address is termed an "IPv4-mapped IPv6 address" and has the format:
埋め込まれたIPv4アドレスを保持しているIPv6アドレスの第二のタイプも定義されています。このアドレスタイプは、IPv6アドレスとIPv4ノードのアドレスを表すために使用されます。アドレスのこのタイプは、「IPv4マップIPv6アドレス」と呼ばれ、フォーマットを有しています。
| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|FFFF| IPv4 address |
+--------------------------------------+----+---------------------+
There are two types of local-use unicast addresses defined. These are Link-Local and Site-Local. The Link-Local is for use on a single link and the Site-Local is for use in a single site. Link-Local addresses have the following format:
定義されたローカル使用ユニキャストアドレスの2種類があります。これらは、リンクローカルとサイトローカルです。リンクローカルは単一リンク上で使用するためのもので、サイトローカルは単一のサイトで使用するためのものです。リンクローカルアドレスの形式は次のとおりです。
| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+
Link-Local addresses are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present.
リンクローカルアドレスは、自動アドレス設定、近隣探索、または時にルータが存在しないなどの目的のために、単一リンクのアドレス指定に使うために設計されています。
Routers must not forward any packets with link-local source or destination addresses to other links.
ルータは、他のリンクへのリンクローカル送信元または宛先アドレスを持つすべてのパケットを転送してはなりません。
Site-Local addresses have the following format:
サイトローカルアドレスの形式は次のとおりです。
| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111011| subnet ID | interface ID |
+----------+-------------------------+----------------------------+
Site-local addresses are designed to be used for addressing inside of a site without the need for a global prefix. Although a subnet ID may be up to 54-bits long, it is expected that globally-connected sites will use the same subnet IDs for site-local and global prefixes.
サイトローカルアドレスは、グローバルプレフィックスを必要とせずに、サイトの内部に対処するために使用されるように設計されています。サブネットIDは、長さは最大54ビットであるかもしれないが、グローバルに接続されているサイトは、サイトローカルおよびグローバルプレフィックスに同じサブネットIDを使用することが期待されます。
Routers must not forward any packets with site-local source or destination addresses outside of the site.
ルータは、サイトの外にサイトローカル送信元または宛先アドレスを持つすべてのパケットを転送してはなりません。
An IPv6 anycast address is an address that is assigned to more than one interface (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance.
IPv6エニーキャストアドレスは、ルーティングによれば、エニーキャストアドレスに送信されたパケットは、そのアドレスを有する「最も近い」インタフェースにルーティングされる特性を有する、複数のインターフェース（通常、異なるノードに属する）に割り当てられたアドレスであります距離のプロトコルを測定。
Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats. Thus, anycast addresses are syntactically indistinguishable from unicast addresses. When a unicast address is assigned to more than one interface, thus turning it into an anycast address, the nodes to which the address is assigned must be explicitly configured to know that it is an anycast address.
エニーキャストアドレスは、定義されたユニキャストアドレス形式のいずれかを使用して、ユニキャストアドレス空間から割り当てられます。このように、エニーキャストアドレスはユニキャストアドレスから構文的に区別することはできません。ユニキャストアドレスが複数のインターフェイスに割り当てられている場合、このようにエニーキャストアドレスにそれを回す、アドレスが割り当てられたノードは、明示的にエニーキャストアドレスであることを知るように構成されなければなりません。
For any assigned anycast address, there is a longest prefix P of that address that identifies the topological region in which all interfaces belonging to that anycast address reside. Within the region identified by P, the anycast address must be maintained as a separate entry in the routing system (commonly referred to as a "host route"); outside the region identified by P, the anycast address may be aggregated into the routing entry for prefix P.
任意の割り当てられたエニーキャストアドレスの場合、そのエニーキャストアドレスに属するすべてのインターフェースが存在するトポロジー領域を識別するアドレスの最長プレフィックスPがあります。 Pによって識別された領域内に、エニーキャストアドレスは、（一般に「ホストルート」と呼ばれる）ルーティングシステムにおける別個のエントリとして維持されなければなりません。 Pによって識別された領域の外側に、エニーキャストアドレスは、プレフィックスPのルーティングエントリに集約することができます
Note that in the worst case, the prefix P of an anycast set may be the null prefix, i.e., the members of the set may have no topological locality. In that case, the anycast address must be maintained as a separate routing entry throughout the entire internet, which presents a severe scaling limit on how many such "global" anycast sets may be supported. Therefore, it is expected that support for global anycast sets may be unavailable or very restricted.
最悪の場合には、エニーキャスト集合のプレフィックスPがnullプレフィックス、すなわちあってもよい、セットのメンバーには位相的局所性を有していなくてもよいです。その場合には、エニーキャストアドレスは、このような「グローバル」エニーキャスト・セットをサポートすることができるどのように多くの深刻なスケーリング限界を提示し、インターネット全体を通して別々のルーティングエントリとして維持しなければなりません。したがって、グローバルエニーキャストセットのサポートが利用できないか、非常に制限されることが期待されています。
One expected use of anycast addresses is to identify the set of routers belonging to an organization providing internet service. Such addresses could be used as intermediate addresses in an IPv6 Routing header, to cause a packet to be delivered via a particular service provider or sequence of service providers.
エニーキャストアドレスの一つ予想される使用は、インターネットサービスを提供する組織に属するルータの集合を識別することです。そのようなアドレスは、サービスプロバイダの特定のサービスプロバイダまたは配列を介して配信されるパケットを引き起こすために、IPv6ルーティングヘッダで中間アドレスとして使用することができます。
Some other possible uses are to identify the set of routers attached to a particular subnet, or the set of routers providing entry into a particular routing domain.
いくつかの他の可能な用途は、特定のサブネットに接続ルータの集合、または特定のルーティングドメインへのエントリを提供するルータの集合を識別するためです。
There is little experience with widespread, arbitrary use of internet anycast addresses, and some known complications and hazards when using them in their full generality [ANYCST]. Until more experience has been gained and solutions are specified, the following restrictions are imposed on IPv6 anycast addresses: o An anycast address must not be used as the source address of an IPv6 packet.
彼らの完全な一般[ANYCST]でそれらを使用する際にインターネットエニーキャストアドレス、およびいくつかの既知の合併症や危険性の広範な、任意の使用にはほとんど経験があります。より多くの経験が得られているとソリューションが指定されるまで、次のような制限は、IPv6エニーキャストアドレスに課される：エニーキャストアドレスは、IPv6パケットの送信元アドレスとして使用することはできませんoを。
o An anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only.
エニーキャストアドレスは、IPv6ホストに割り当てることはできませんO、つまり、それだけでIPv6ルータに割り当ててもよいです。
The Subnet-Router anycast address is predefined. Its format is as follows:
サブネットルータエニーキャストアドレスは、あらかじめ定義されています。形式は以下の通りです：
| n bits | 128-n bits |
+------------------------------------------------+----------------+
| subnet prefix | 00000000000000 |
+------------------------------------------------+----------------+
The "subnet prefix" in an anycast address is the prefix which identifies a specific link. This anycast address is syntactically the same as a unicast address for an interface on the link with the interface identifier set to zero.
エニーキャストアドレス内の「サブネットプレフィックスは、」特定のリンクを特定する接頭辞です。このエニーキャストアドレスは、構文的にゼロに設定インタフェース識別子とのリンク上のインタフェースのためのユニキャストアドレスと同じです。
Packets sent to the Subnet-Router anycast address will be delivered to one router on the subnet. All routers are required to support the Subnet-Router anycast addresses for the subnets to which they have interfaces.
サブネットルータエニーキャストアドレスに送信されたパケットは、サブネット上のルータに配信されます。すべてのルータは、それらがインタフェースを持つサブネットのサブネットルータエニーキャストアドレスをサポートするために必要とされています。
The subnet-router anycast address is intended to be used for applications where a node needs to communicate with any one of the set of routers.
サブネットルータエニーキャストアドレスは、ノードがルータのセットのいずれかと通信する必要がある用途に使用されることを意図しています。
An IPv6 multicast address is an identifier for a group of interfaces (typically on different nodes). An interface may belong to any number of multicast groups. Multicast addresses have the following format:
IPv6マルチキャストアドレスは、インタフェース（典型的には異なるノード上の）グループの識別子です。インターフェースは、マルチキャストグループの任意の数に属していてもよいです。マルチキャストアドレスの形式は次のとおりです。
| 8 | 4 | 4 | 112 bits |
+------ -+----+----+---------------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------------+
binary 11111111 at the start of the address identifies the
address as being a multicast address.
+-+-+-+-+ flgs is a set of 4 flags: |0|0|0|T| +-+-+-+-+
+ - + - + - + - + FLGS 4つのフラグのセットです。| 0 | 0 | 0 | T | + - + - + - + - +
The high-order 3 flags are reserved, and must be initialized to 0.
上位3つのフラグは予約されており、0に初期化する必要があります。
T = 0 indicates a permanently-assigned ("well-known") multicast address, assigned by the Internet Assigned Number Authority (IANA).
T = 0は、Internet Assigned Number Authority（IANA）によって割り当てられた永続的に割り当てられた（ "既知"）マルチキャストアドレスを示しています。
T = 1 indicates a non-permanently-assigned ("transient") multicast address.
T = 1は、非永続的に割り当てられ（「一過性」）マルチキャストアドレスを示します。
scop is a 4-bit multicast scope value used to limit the scope of the multicast group. The values are:
SCOPは、マルチキャストグループの範囲を限定するために使用される4ビットのマルチキャストスコープ値です。値は次のとおりです。
0 reserved 1 interface-local scope 2 link-local scope 3 reserved 4 admin-local scope 5 site-local scope 6 (unassigned) 7 (unassigned) 8 organization-local scope 9 (unassigned) A (unassigned) B (unassigned) C (unassigned) D (unassigned) E global scope F reserved
0は1インターフェイスローカルスコープ2リンクローカルスコープ3を保有4管理ローカルスコープ5サイトローカルスコープ6（未割り当て）7（未割り当て）8組織ローカルスコープ9（未割り当て）A（未割り当て）B（未割り当て）C予約しました（未割り当て）D（未割当て）EグローバルスコープF予約
interface-local scope spans only a single interface on a node, and is useful only for loopback transmission of multicast.
インターフェイスローカルスコープは、ノード上の単一のインターフェースに及ぶ、とのみマルチキャストのループバック伝送のために有用です。
link-local and site-local multicast scopes span the same topological regions as the corresponding unicast scopes.
リンクローカルおよびサイトローカルマルチキャストスコープは、対応するユニキャストスコープと同じトポロジー領域にまたがります。
admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration.
管理ローカルスコープは管理、構成、すなわち、自動的に物理的な接続または他の、非マルチキャスト関連の構成に由来しないしなければならない最小の範囲です。
organization-local scope is intended to span multiple sites belonging to a single organization.
組織ローカルスコープは、単一の組織に属する複数のサイトにまたがることを意図しています。
scopes labeled "(unassigned)" are available for administrators to define additional multicast regions.
標識されたスコープは、「（未割り当て）」管理者が追加のマルチキャスト領域を定義するために利用可能です。
group ID identifies the multicast group, either permanent or transient, within the given scope.
グループIDは、所定の範囲内に、永続的または一過性のいずれかで、マルチキャストグループを識別する。
The "meaning" of a permanently-assigned multicast address is independent of the scope value. For example, if the "NTP servers group" is assigned a permanent multicast address with a group ID of 101 (hex), then:
永続的に割り当てられたマルチキャストアドレスの「意味は、」スコープ値とは無関係です。例えば、「NTPサーバ基」次いで、101のグループID（16進数）と永久的なマルチキャストアドレスが割り当てられます。
FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface (i.e., the same node) as the sender.
FF01：0：0：0：0：0：0：101は、送信者と同じインタフェース（すなわち、同じノード）上の全てのNTPサーバを意味します。
FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the sender.
FF02：0：0：0：0：0：0：101は、送信者と同じリンク上のすべてのNTPサーバを意味します。
FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the sender.
FF05：0：0：0：0：0：0：101は、送信者と同じサイト内のすべてのNTPサーバを意味します。
FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
FF0Eは：0：0：0：0：0：0：101は、インターネット内のすべてのNTPサーバを意味します。
Non-permanently-assigned multicast addresses are meaningful only within a given scope. For example, a group identified by the non-permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one site bears no relationship to a group using the same address at a different site, nor to a non-permanent group using the same group ID with different scope, nor to a permanent group with the same group ID.
非永続的に割り当てられたマルチキャストアドレスにのみ与えられた範囲内で意味があります。例えば、非永久的な、サイトローカルマルチキャストアドレスFF15によって識別されたグループ：0：0：0：0：0：0：一箇所101は、異なるサイトで同じアドレスを使用してグループへの関係を負いません異なるスコープと同じグループIDを使用して、非正規群に、また同じグループIDを持つ永久的なグループです。
Multicast addresses must not be used as source addresses in IPv6 packets or appear in any Routing header.
マルチキャストアドレスは、IPv6パケットの送信元アドレスとして使用されるか、または任意のルーティングヘッダに現れてはなりません。
Routers must not forward any multicast packets beyond of the scope indicated by the scop field in the destination multicast address.
ルータは、宛先マルチキャストアドレスにSCOPフィールドで示される範囲を超えてのいずれかのマルチキャストパケットを転送してはなりません。
Nodes must not originate a packet to a multicast address whose scop field contains the reserved value 0; if such a packet is received, it must be silently dropped. Nodes should not originate a packet to a multicast address whose scop field contains the reserved value F; if such a packet is sent or received, it must be treated the same as packets destined to a global (scop E) multicast address.
ノードはSCOPフィールド予約値0が含まれているマルチキャストアドレスにパケットを発信してはなりません。このようなパケットを受信した場合、それは静かに落とさなければなりません。ノードはSCOPフィールドの予約値Fが含まれているマルチキャストアドレスにパケットを発信するべきではありません。そのようなパケットが送信または受信された場合、それはグローバル（SCOP E）マルチキャストアドレス宛てのパケットと同じように扱われなければなりません。
The following well-known multicast addresses are pre-defined. The group ID's defined in this section are defined for explicit scope values.
次のよく知られたマルチキャストアドレスは、事前に定義されています。グループIDのこのセクションで定義され、明示的なスコープ値のために定義されています。
Use of these group IDs for any other scope values, with the T flag equal to 0, is not allowed.
0に等しいTフラグと他のスコープ値のためのこれらのグループIDの使用は、許可されていません。
Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 FF01:0:0:0:0:0:0:0 FF02:0:0:0:0:0:0:0 FF03:0:0:0:0:0:0:0 FF04:0:0:0:0:0:0:0 FF05:0:0:0:0:0:0:0 FF06:0:0:0:0:0:0:0 FF07:0:0:0:0:0:0:0 FF08:0:0:0:0:0:0:0 FF09:0:0:0:0:0:0:0 FF0A:0:0:0:0:0:0:0 FF0B:0:0:0:0:0:0:0 FF0C:0:0:0:0:0:0:0 FF0D:0:0:0:0:0:0:0 FF0E:0:0:0:0:0:0:0 FF0F:0:0:0:0:0:0:0
予約済みマルチキャストアドレス：FF00：0：0：0：0：0：0：0 FF01：0：0：0：0：0：0：0 FF02：0：0：0：0：0：0：0 FF03 ：0：0：0：0：0：0：0 FF04：0：0：0：0：0：0：0 FF05：0：0：0：0：0：0：0 FF06：0：0： 0：0：0：0：0 FF07：0：0：0：0：0：0：0 FF08：0：0：0：0：0：0：0 FF09：0：0：0：0：0 ：0：0 FF0A：0：0：0：0：0：0：0 FF0B：0：0：0：0：0：0：0 FF0C：0：0：0：0：0：0：0 FF0D ：0：0：0：0：0：0：0 FF0E：0：0：0：0：0：0：0 FF0F：0：0：0：0：0：0：0
The above multicast addresses are reserved and shall never be assigned to any multicast group.
上記のマルチキャストアドレスは、予約されており、いずれかのマルチキャストグループに割り当てることはないものとします。
All Nodes Addresses: FF01:0:0:0:0:0:0:1 FF02:0:0:0:0:0:0:1
すべてのアドレスをノード：FF01：0：0：0：0：0：0：1 FF02：0：0：0：0：0：0：1
The above multicast addresses identify the group of all IPv6 nodes, within scope 1 (interface-local) or 2 (link-local).
上記のマルチキャストアドレスは、スコープ1（インターフェイスローカル）または2（リンクローカル）内で、全てのIPv6ノードのグループを識別する。
All Routers Addresses: FF01:0:0:0:0:0:0:2 FF02:0:0:0:0:0:0:2 FF05:0:0:0:0:0:0:2
2 FF05：：すべてのルータアドレス：FF01：0：0：0：0：0：0：2 FF02：0：0：0：0：0：0 0：0：0：0：0：0：2
The above multicast addresses identify the group of all IPv6 routers, within scope 1 (interface-local), 2 (link-local), or 5 (site-local).
上記のマルチキャストアドレスは、スコープ1（インターフェイスローカル）、2（リンクローカル）、または5（サイトローカル）内に、すべてのIPv6ルータのグループを識別する。
Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX
要請ノードアドレス：FF02：0：0：0：0：1：FFXX：XXXX
Solicited-node multicast address are computed as a function of a node's unicast and anycast addresses. A solicited-node multicast address is formed by taking the low-order 24 bits of an address (unicast or anycast) and appending those bits to the prefix FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the range
要請ノードマルチキャストアドレスは、ノードのユニキャストとエニーキャストアドレスの関数として計算されます。 0：0：0：0：1：FF00 :: / 104で得られた要請ノードマルチキャストアドレスは、プレフィックスFF02にこれらのビットをアドレス（ユニキャストまたはエニーキャスト）の下位24ビットを取り、付加することにより形成されています範囲内のマルチキャストアドレス
FF02:0:0:0:0:1:FF00:0000
FF02：0：0：0：0：1：FF00：0000
to
と
FF02:0:0:0:0:1:FFFF:FFFF
FF02：0：0：0：0：1：FFFF：FFFF
For example, the solicited node multicast address corresponding to the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 addresses that differ only in the high-order bits, e.g., due to multiple high-order prefixes associated with different aggregations, will map to the same solicited-node address thereby, reducing the number of multicast addresses a node must join.
たとえば、IPv6アドレス4037 :: 01に対応する要請ノードマルチキャストアドレス：800：200E：8C6CはFF02 :: 1：FF0E：8C6C。異なる集計に関連する複数の上位プレフィックスに、例えば、上位ビットのみが異なるIPv6アドレスは、ノードが参加しなければならないマルチキャストアドレスの数を減らし、それによって同じ要請ノードアドレスにマップされます。
A node is required to compute and join (on the appropriate interface) the associated Solicited-Node multicast addresses for every unicast and anycast address it is assigned.
ノードを計算し、それが割り当てられたすべてのユニキャストおよびエニーキャストアドレスを（適切なインターフェースに）関連する要請ノードマルチキャストアドレスに参加するために必要とされます。
A host is required to recognize the following addresses as identifying itself:
ホストは、それ自体を識別として、以下のアドレスを認識する必要があります。
o Its required Link-Local Address for each interface. o Any additional Unicast and Anycast Addresses that have been configured for the node's interfaces (manually or automatically). o The loopback address. o The All-Nodes Multicast Addresses defined in section 2.7.1. o The Solicited-Node Multicast Address for each of its unicast and anycast addresses. o Multicast Addresses of all other groups to which the node belongs.
各インターフェイスのためのその必要なリンクローカルアドレスO。 Oノードのインタフェース（手動または自動）のために構成されている任意の追加ユニキャストおよびエニーキャストアドレス。ループバックアドレスO。セクション2.7.1で定義されている全ノードマルチキャストアドレスO。そのユニキャストとエニーキャストアドレスごとに、要請ノードマルチキャストアドレスO。ノードが属する全ての他のグループのマルチキャストアドレス、O。
A router is required to recognize all addresses that a host is required to recognize, plus the following addresses as identifying itself:
ルータは、自身を特定するようホストが認識するために必要であることをすべてのアドレスに加えて、以下のアドレスを認識することが必要です。
o The Subnet-Router Anycast Addresses for all interfaces for which it is configured to act as a router. o All other Anycast Addresses with which the router has been configured. o The All-Routers Multicast Addresses defined in section 2.7.1.
Oサブネットのルータエニーキャストは、ルータとして動作するように構成されているすべてのインターフェイスのアドレス。ルータが設定されていると他のすべてのエニーキャストアドレスO。セクション2.7.1で定義されているすべてのルーターマルチキャストアドレスO。
IPv6 addressing documents do not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined in [AUTH].
IPv6のアドレス指定の文書がインターネットインフラストラクチャのセキュリティ上の任意の直接的な影響はありません。 IPv6パケットの認証は[AUTH]で定義されています。
The table and notes at http://www.isi.edu/in-notes/iana/assignments/ipv6-address-space.txt should be replaced with the following:
http://www.isi.edu/in-notes/iana/assignments/ipv6-address-space.txtの表やメモは、次のように置き換えてください。
INTERNET PROTOCOL VERSION 6 ADDRESS SPACE
インターネットプロトコルバージョン6アドレス空間
The initial assignment of IPv6 address space is as follows:
次のようにIPv6アドレス空間の初期割り当ては次のとおりです。
Allocation Prefix Fraction of
(binary) Address Space
----------------------------------- -------- -------------
Unassigned (see Note 1 below) 0000 0000 1/256
Unassigned 0000 0001 1/256
Reserved for NSAP Allocation 0000 001 1/128 [RFC1888]
Unassigned 0000 01 1/64
Unassigned 0000 1 1/32
Unassigned 0001 1/16
Global Unicast 001 1/8 [RFC2374]
Unassigned 010 1/8
Unassigned 011 1/8
Unassigned 100 1/8
Unassigned 101 1/8
Unassigned 110 1/8
Unassigned 1110 1/16
Unassigned 1111 0 1/32
Unassigned 1111 10 1/64
Unassigned 1111 110 1/128
Unassigned 1111 1110 0 1/512
Link-Local Unicast Addresses 1111 1110 10 1/1024
Site-Local Unicast Addresses 1111 1110 11 1/1024
Multicast Addresses 1111 1111 1/256
Notes:
ノート：
1. The "unspecified address", the "loopback address", and the IPv6 Addresses with Embedded IPv4 Addresses are assigned out of the 0000 0000 binary prefix space.
1.「未指定アドレス」、「ループバックアドレス」、およびIPv6は、埋め込まれたIPv4アドレスは0000 0000バイナリプレフィックス空間から割り当てられているとアドレス。
2. For now, IANA should limit its allocation of IPv6 unicast address space to the range of addresses that start with binary value 001. The rest of the global unicast address space (approximately 85% of the IPv6 address space) is reserved for future definition and use, and is not to be assigned by IANA at this time.
2.ここでは、IANAは、グローバルユニキャストアドレス空間（IPv6アドレス空間の約85％）の残りは、将来の定義のために予約されているバイナリ値で始まるアドレス001の範囲にIPv6ユニキャストアドレス空間の割り当てを制限する必要がそして使用しており、この時点でIANAによって割り当てられるようにされていません。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9 , RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[ANYCST]ウズラ、C.、メンデス、T.およびW.ミリケン、 "ホストエニーキャストサービス"、RFC 1546、1993年11月。
[AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AUTH]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[AGGR] HindenとR.、オデル、M.とS.デアリング、 "集約可能グローバルユニキャストアドレス形式"、RFC 2374、1998年7月。
[CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[CIDR]フラー、V.、李、T.、ゆう、J.及びK. Varadhan、 "クラスレスドメイン間ルーティング（CIDR）：アドレス割り当ておよび集約戦略"、RFC 1519、1993年9月。
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[ETHER]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、RFC 2464、1998年12月。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997.
[EUI64] IEEE、 "64ビットのグローバル識別子（EUI64）登録機関のためのガイドライン"、http://standards.ieee.org/regauth/oui/tutorials/EUI64.html、1997年3月。
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.
[FDDI]クロフォード、M.、 "FDDIネットワークの上のIPv6パケットの送信"、RFC 2467、1998年12月。
[MASGN] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[MASGN] HindenとR.とS.デアリング、 "IPv6のマルチキャストアドレスの割り当て"、RFC 2375、1998年7月。
[NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J. and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
[NSAP]バウンド、J.、大工、B.、ハリントン、D.、Houldsworth、J.及びA.ロイド、 "OSIのNSAPとIPv6"、RFC 1888、1996年8月。
[PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[PRIV] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[TOKEN] Crawford, M., Narten, T. and S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC 2470, December 1998.
[TOKEN]クロフォード、M.、Narten氏、T.とS.トーマス、RFC 2470、1998年12月 "トークンリング・ネットワークの上のIPv6パケットのトランスミッション"。
[TRAN] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[TRAN]ギリガン、R.およびE. Nordmarkと、 "IPv6ホストとルータの移行メカニズム"、RFC 2893、2000年8月。
APPENDIX A: Creating Modified EUI-64 format Interface Identifiers
付録A：修正EUI-64形式のインターフェイスIDを作成します
Depending on the characteristics of a specific link or node there are a number of approaches for creating Modified EUI-64 format interface identifiers. This appendix describes some of these approaches.
特定のリンクまたはノードの特性に応じて変形EUI-64フォーマットのインターフェース識別子を作成するための多くの方法があります。この付録では、これらのアプローチのいくつかを説明しています。
Links or Nodes with IEEE EUI-64 Identifiers
IEEE EUI-64識別子を持つリンクまたはノード
The only change needed to transform an IEEE EUI-64 identifier to an interface identifier is to invert the "u" (universal/local) bit. For example, a globally unique IEEE EUI-64 identifier of the form:
インタフェース識別子にIEEE EUI-64識別子を変換するために必要な唯一の変更は、「U」（ユニバーサル/ローカル）ビットを反転させることです。例えば、フォームのグローバルにユニークなIEEE EUI-64識別子：
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
where "c" are the bits of the assigned company_id, "0" is the value of the universal/local bit to indicate global scope, "g" is individual/group bit, and "m" are the bits of the manufacturer-selected extension identifier. The IPv6 interface identifier would be of the form:
「C」は割り当てのcompany_idのビットである場合、「0」は、グローバルスコープを示すためにユニバーサル/ローカルビットの値である「g」は個人/グループビットであり、「M」は、メーカー選択のビットであります拡張識別子。 IPv6インタフェース識別子の形式は次のようになります。
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
The only change is inverting the value of the universal/local bit.
唯一の変更は、ユニバーサル/ローカルビットの値を反転しています。
Links or Nodes with IEEE 802 48 bit MAC's
MAC 48ビットのIEEE 802とのリンクまたはノード
[EUI64] defines a method to create a IEEE EUI-64 identifier from an IEEE 48bit MAC identifier. This is to insert two octets, with hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the company_id and vendor supplied id). For example, the 48 bit IEEE MAC with global scope:
[EUI64] IEEE 48ビットMAC識別子からIEEE EUI64識別子を作成する方法を定義しています。これは、（ID供給のcompany_idとベンダーとの間の）48ビットMACの途中で、は0xFFと0xFEの16進数の値と、2つのオクテットを挿入することです。例えば、48は、グローバルスコープとIEEE MACビット。
|0 1|1 3|3 4|
|0 5|6 1|2 7|
+----------------+----------------+----------------+
|cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+
where "c" are the bits of the assigned company_id, "0" is the value of the universal/local bit to indicate global scope, "g" is individual/group bit, and "m" are the bits of the manufacturer-selected extension identifier. The interface identifier would be of the form:
「C」は割り当てのcompany_idのビットである場合、「0」は、グローバルスコープを示すためにユニバーサル/ローカルビットの値である「g」は個人/グループビットであり、「M」は、メーカー選択のビットであります拡張識別子。インタフェース識別子の形式は次のようになります。
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+----------------+----------------+----------------+----------------+
When IEEE 802 48bit MAC addresses are available (on an interface or a node), an implementation may use them to create interface identifiers due to their availability and uniqueness properties.
IEEE 802個の48ビットMACアドレスが（インターフェースまたはノード上で）利用可能である場合、実装は、それらの利用可能性とユニークな特性に起因するインターフェース識別子を作成するためにそれらを使用することができます。
Links with Other Kinds of Identifiers
識別子の他の種類とのリンク
There are a number of types of links that have link-layer interface identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs. Examples include LocalTalk and Arcnet. The method to create an Modified EUI-64 format identifier is to take the link identifier (e.g., the LocalTalk 8 bit node identifier) and zero fill it to the left. For example, a LocalTalk 8 bit node identifier of hexadecimal value 0x4F results in the following interface identifier:
IEEE EIU-64またはIEEE 802 48ビットのMAC以外のリンク層インターフェース識別子を持つリンクの種類がいくつかあります。例としては、LocalTalkのとアークネットが含まれています。変形EUI-64フォーマット識別子を作成するための方法は、リンク識別子（例えば、のLocalTalk 8ビットノード識別子）と左にゼロ充填を取ることです。例えば、以下のインタフェース識別子16進値0x4F結果のLocalTalk 8ビットノード識別子：
|0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+
|0000000000000000|0000000000000000|0000000000000000|0000000001001111|
+----------------+----------------+----------------+----------------+
Note that this results in the universal/local bit set to "0" to indicate local scope.
これはローカルスコープを示すために「0」に設定ユニバーサル/ローカルビットの結果であることに留意ください。
Links without Identifiers
識別子のないリンク
There are a number of links that do not have any type of built-in identifier. The most common of these are serial links and configured tunnels. Interface identifiers must be chosen that are unique within a subnet-prefix.
内蔵の識別子のいずれかのタイプを持っていないリンクの数があります。これらの最も一般的なのは、シリアルリンクと設定トンネルです。インターフェイス識別子は、サブネットプレフィクス内で一意であることを選択する必要があります。
When no built-in identifier is available on a link the preferred approach is to use a global interface identifier from another interface or one which is assigned to the node itself. When using this approach no other interface connecting the same node to the same subnet-prefix may use the same identifier.
組み込みの識別子がリンク上で利用可能でない場合の好ましいアプローチは、ノード自身に割り当てられている別のインターフェイスまたは1からグローバルインタフェース識別子を使用することです。このアプローチを使用するときに同じサブネットプレフィックスに同じノードを接続する他のインターフェイスが同じ識別子を使用しなくてもよいです。
If there is no global interface identifier available for use on the link the implementation needs to create a local-scope interface identifier. The only requirement is that it be unique within a subnet prefix. There are many possible approaches to select a subnet-prefix-unique interface identifier. These include:
使用のために利用可能なグローバルなインタフェース識別子がリンクの上に存在しない場合、実装はローカルスコープのインタフェース識別子を作成する必要があります。唯一の要件は、サブネットプレフィクス内でユニークであるということです。サブネットプレフィックスユニークなインタフェース識別子を選択するための多くの可能なアプローチがあります。これらは、次のとおりです。
Manual Configuration Node Serial Number Other node-specific token
手動設定ノードシリアル番号その他のノード固有のトークン
The subnet-prefix-unique interface identifier should be generated in a manner that it does not change after a reboot of a node or if interfaces are added or deleted from the node.
サブネットプレフィックスユニークなインタフェース識別子は、ノードの再起動後、またはインタフェースがノードから追加または削除された場合に変化しないように生成されなければなりません。
The selection of the appropriate algorithm is link and implementation dependent. The details on forming interface identifiers are defined in the appropriate "IPv6 over <link>" specification. It is strongly recommended that a collision detection algorithm be implemented as part of any automatic algorithm.
適切なアルゴリズムの選択は、リンクおよび実装依存です。インタフェース識別子を形成する方法の詳細は、適切な「IPv6の上の<link>」仕様で定義されています。強く衝突検出アルゴリズムは、任意の自動アルゴリズムの一部として実装することをお勧めします。
APPENDIX B: Changes from RFC-2373
付録B：RFC-2373からの変更点
The following changes were made from RFC-2373 "IP Version 6 Addressing Architecture":
次の変更は、RFC-2373「IPバージョン6アドレッシング体系」から作られました。
- Clarified text in section 2.2 to allow "::" to represent one or more groups of 16 bits of zeros. - Changed uniqueness requirement of Interface Identifiers from unique on a link to unique within a subnet prefix. Also added a recommendation that the same interface identifier not be assigned to different machines on a link. - Change site-local format to make the subnet ID field 54-bit long and remove the 38-bit zero's field. - Added description of multicast scop values and rules to handle the reserved scop value 0. - Revised sections 2.4 and 2.5.6 to simplify and clarify how different address types are identified. This was done to insure that implementations do not build in any knowledge about global unicast format prefixes. Changes include: o Removed Format Prefix (FP) terminology o Revised list of address types to only include exceptions to global unicast and a singe entry that identifies everything else as Global Unicast. o Removed list of defined prefix exceptions from section 2.5.6 as it is now the main part of section 2.4. - Clarified text relating to EUI-64 identifiers to distinguish between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI-64 identifiers. - Combined the sections on the Global Unicast Addresses and NSAP Addresses into a single section on Global Unicast Addresses, generalized the Global Unicast format, and cited [AGGR] and [NSAP] as examples. - Reordered sections 2.5.4 and 2.5.5. - Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses because this is being redefined elsewhere. - Added an IANA considerations section that updates the IANA IPv6 address allocations and documents the NSAP and AGGR allocations. - Added clarification that the "IPv4-compatible IPv6 address" must use global IPv4 unicast addresses. - Divided references in to normative and non-normative sections. - Added reference to [PRIV] in section 2.5.1 - Added clarification that routers must not forward multicast packets outside of the scope indicated in the multicast address. - Added clarification that routers must not forward packets with source address of the unspecified address. - Added clarification that routers must drop packets received on an interface with destination address of loopback. - Clarified the definition of IPv4-mapped addresses.
- 許可するセクション2.2で明らかにテキスト「::」ゼロの16ビットの1つ以上の基を表します。 - サブネットプレフィクス内で一意にリンク上でユニークからのインターフェイス識別子の一意性要件を変更しました。また、同一のインタフェース識別子は、リンク上の異なるマシンに割り当てられないことを推奨して加えました。 - サブネットIDフィールドは54ビット長にすると38ビットのゼロのフィールドを削除するための変更サイトローカルフォーマット。簡略化し、異なるアドレスタイプが識別される方法を明確にする改訂セクション2.4及び2.5.6 - - 予約SCOP値0を処理するためにマルチキャストSCOP値とルールの追加された説明。これは、実装がグローバルユニキャストフォーマットプレフィックスについての知識を構築していないことを保証するために行われました。変更点は次のとおりにアドレスタイプの改訂リストO削除フォーマットプレフィックス（FP）の用語は、唯一のグローバルユニキャストおよびグローバルユニキャストとして他のすべてを識別し焦がすエントリに対する例外を含めるoを。それが今のセクション2.4の主要部分であるとして、Oセクション2.5.6から定義されたプレフィックス例外のリストを削除しました。 - 明確化テキストは、IPv6の「修正EUI-64フォーマット」の識別子とIEEE EUI-64識別子を区別するためにEUI-64識別子に関連します。 - グローバルユニキャストアドレスにセクションを合わせ、NSAPは、グローバルユニキャストアドレスに単一のセクションにアドレス、グローバルユニキャストフォーマットを一般化し、[AGGR]を引用して、[NSAP]例として。 - 順序変更セクション2.5.4および2.5.5。 - これは別の場所で再定義されているため、新しいIPv6マルチキャストの削除セクション2.7.2割り当てアドレス。 - IANA IPv6アドレスの割り当てを更新し、NSAPとAGGR割り当てを文書化IANAの考慮事項のセクションを追加しました。 - 「IPv4互換IPv6アドレスは」グローバルIPv4ユニキャストアドレスを使用しなければならないことを明確化を追加しました。 - 規範と非標準のセクションに分割参照。 - セクション2.5.1で[PRIV]に追加された参照 - ルータがマルチキャストアドレスで示された範囲の外でマルチキャストパケットを転送してはならないことを追加した明確。 - ルータが未指定アドレスの送信元アドレスを持つパケットを転送してはならない説明を追加しました。 - ルータがループバックの宛先アドレスを持つインターフェイスで受信パケットを廃棄しなければならない説明を追加しました。 - IPv4マップアドレスの定義を明確化。
- Removed the ABNF Description of Text Representations Appendix. - Removed the address block reserved for IPX addresses. - Multicast scope changes: o Changed name of scope value 1 from "node-local" to "interface-local" o Defined scope value 4 as "admin-local" - Corrected reference to RFC1933 and updated references. - Many small changes to clarify and make the text more consistent.
- テキスト表現付録のABNF記述を削除しました。 - IPXアドレスのために予約されたアドレスブロックを削除しました。 - マルチキャストスコープの変更：「ノード・ローカル」から「インターフェースローカル」定義されたスコープ値4 O「管理ローカル」とスコープ値1の変更された名前O - RFC1933、更新参照に補正参照。 - 明確にし、テキストがより一貫性を保つために多くの小さな変化。
Authors' Addresses
著者のアドレス
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
ロバートM. Hindenとノキア313フェアチャイルドドライブマウンテンビュー、CA 94043 USA
Phone: +1 650 625-2004 EMail: hinden@iprg.nokia.com
電話：+1 650 625-2004 Eメール：hinden@iprg.nokia.com
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
スティーブンE.デアリングシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706 USA
Phone: +1 408 527-8213 EMail: deering@cisco.com
電話：+1 408 527-8213 Eメール：deering@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。