[要約] RFC 3513はIPv6のアドレッシングアーキテクチャに関する規格であり、IPv6アドレスの構造と割り当て方法を定義しています。このRFCの目的は、IPv6のアドレス空間を効果的に利用し、インターネットの成長に対応するためのアドレッシングシステムを提供することです。
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
インターネットプロトコルバージョン6（IPv6）アーキテクチャへの対処
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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ユニキャストアドレスの定義、Anycastアドレス、マルチキャストアドレス、および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アドレス（Unicast、Anycast、Multicast）の基本形式が含まれています。
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.
著者は、ポール・フランシス、スコット・ブラッドナー、ジム・バウンド、ブライアン・カーペンター、マット・クロフォード、デボラ・エストリン、ロジャー・ファイマン、ボブ・フィンク、ピーター・フォード、ボブ・ギリガン、ディミトリー・ハスキン、トム・ハーシュ、クリスチャン・フイテマ、トニー・リー・リー・リー・リー・リー・リー・リー・リー・リー・リーの貢献に賛成したいと思います。、グレッグ・ミンシャル、トーマス・ナルテン、エリック・ノードマーク、ヤコフ・レクター、ビル・シンプソン、スー・トムソン、マークク・サヴェラ、ラリー・マシンター。
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).
Anycast：一連のインターフェイスの識別子（通常、異なるノードに属する）。Anycastアドレスに送信されたパケットは、そのアドレスによって識別されたインターフェイスの1つ（ルーティングプロトコルの距離の尺度に従って」に識別されるインターフェイスの1つに配信されます。
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を参照）。単一のインターフェイスには、あらゆるタイプ（Unicast、Anycast、およびMulticast）またはスコープの複数の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.
実装がインターネット層に表示するときに複数の物理インターフェイスを1つのインターフェイスとして扱う場合、ユニキャストアドレスまたはユニキャストアドレスのセットを複数の物理インターフェイスに割り当てることができます。これは、複数の物理インターフェイス上の負荷共有に役立ちます。
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です。ここで、 'xはアドレスの8つの16ビットピースの16進数です。
Examples:
例：
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
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.).
主要なゼロを個々のフィールドに記述する必要はありませんが、すべてのフィールドに少なくとも1つの数値が必要である必要があります（2で説明されている場合を除く）。
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つ以上のグループを示します。「::」はアドレスに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
may be represented as:
として表される場合があります：
1080::8:800:200C:417A a unicast address
FF01::101 a multicast address
::1 the loopback address
:: the unspecified addresses
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：d.d.d.dであり、ここで、 'xは6つの高次16-の16進数です。アドレスのビットピース、および「D」は、アドレスの4つの低次8ビットピース（標準IPv4表現）の小数値です。例：
0:0:0:0:0:0:13.1.68.3
0:0:0:0:0:FFFF:129.144.52.38
or in compressed form:
または圧縮形式：
::13.1.68.3
:: 13.1.68.3
::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-Address/Prefix-Length
where
ただし
ipv6-address is an IPv6 address in any of the notations listed in section 2.2.
IPv6-Addressは、セクション2.2にリストされている表記のいずれかのIPv6アドレスです。
prefix-length is a decimal value specifying how many of the leftmost contiguous bits of the address comprise the prefix.
プレフィックスレングスは、アドレスの左端の隣接するビットの数がプレフィックスを構成するものを指定する小数値です。
For example, the following are legal representations of the 60-bit prefix 12AB00000000CD3 (hexadecimal):
たとえば、以下は60ビットのプレフィックス12ABAB00000000CD3（16進数）の法定代理人です。
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
12AB::CD3/60 address to left of "/" expands to
12AB:0000:0000:0000:0000:000:0000:0CD3
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:
ノードアドレスとそのノードアドレスのプレフィックス（ノードのサブネットプレフィックスなど）の両方を書き込むと、次のように組み合わせることができます。
the node address 12AB:0:0:CD30:123:4567:89AB:CDEF
and its subnet number 12AB:0:0:CD30::/60
can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
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.
Anycastアドレスは、（任意の範囲の）ユニキャストアドレススペースから取得され、ユニキャストアドレスと構文的に区別できません。
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アドレスを含むグローバルユニキャストアドレスのいくつかの特別な目的サブタイプ（IPv4-IPV6相互操作の目的のため）については、セクション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アドレスと同様の任意のビット長のプレフィックスが総合的です。
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、特にグローバルユニキャスト、サイトローカルユニキャスト、およびLink-Local Unicastには、いくつかのタイプのユニキャストアドレスがあります。また、埋め込まれたIPv4アドレスまたはエンコードされたNSAPアドレスを備えたIPv6アドレスなど、グローバルユニキャストの特別な目的サブタイプもあります。追加のアドレスタイプまたはサブタイプは、将来定義できます。
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:
わずかに洗練されたホスト（まだかなり単純な）は、添付されているリンクのサブネットプレフィックス（es）をさらに認識している場合があります。
| 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]).
修正されたEUI-64形式ベースのインターフェイス識別子は、グローバルトークン（たとえば、IEEE 802 48ビットMACまたはIEEE EUI-64識別子[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 Interface Identifiers" provides examples on the creation of Modified EUI-64 format based interface identifiers.
「u」はユニバーサル/ローカルビット、「g」は個別/グループビット、「c」はcompany_idのビットです。付録A：「変更されたEUI-64形式のインターフェイス識別子の作成」では、修正された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」ビットを反転させる動機は、システム管理者がハードウェアトークンが使用できないときに非グロバル識別子を簡単に設定できるようにすることです。これは、シリアルリンク、トンネルエンドポイントなどの場合に予想されます。代替案は、これらが0200：0：0：1、0200：0：0：2などの形式であることでした。はるかにシンプルな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オーバー」[エーテル]、「FDDI上のIPv6」などの適切な「IPv6 over <link>」仕様で定義されています。
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は、不特定のアドレスと呼ばれます。ノードに割り当てられないでください。アドレスがないことを示します。その使用の1つの例は、初期化ホストから送信された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：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で定義されています。.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.
Binary 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で説明されている埋め込みIPv4アドレスを備えたIPv6アドレスと、[NSAP]で指定されたエンコードされたNSAPアドレスを含むIPv6アドレスを備えた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アドレスを保持する2番目のタイプのIPv6アドレスも定義されています。このアドレスタイプは、IPv6アドレスとしてIPv4ノードのアドレスを表すために使用されます。このタイプのアドレスは「IPv4-Mapped 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つのタイプがあります。これらはLink-LocalとSite-Localです。Link-Localは単一のリンクで使用するためであり、サイトローカルは単一のサイトで使用します。Link-Localアドレスには、次の形式があります。
| 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.
Link-Localアドレスは、自動アドレス構成、近隣発見、またはルーターが存在しない場合、単一のリンクでアドレス指定するために使用されるように設計されています。
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アドレスは、ルーティングに従って、Anycastアドレスに送信されたパケットが「最寄りの」インターフェイスを持つ「最寄りの」インターフェイスにルーティングされるプロパティとともに、複数のインターフェイス（通常は異なるノードに属する）に割り当てられるアドレスです。プロトコルの距離の測定。
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.
Anycastアドレスは、定義されたユニキャストアドレス形式のいずれかを使用して、ユニキャストアドレススペースから割り当てられます。したがって、Anycastアドレスは、ユニキャストアドレスと構文的に区別できません。ユニキャストアドレスが複数のインターフェイスに割り当てられて、それをAnycastアドレスに変換する場合、アドレスが割り当てられるノードを明示的に構成する必要があります。
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.
割り当てられたAnycastアドレスには、そのアドレスの最長のプレフィックスPがあり、そのanycastアドレスに属するすべてのインターフェイスが存在するトポロジ領域を識別します。Pで識別された領域内で、Anycastアドレスは、ルーティングシステムの個別のエントリとして維持する必要があります（一般に「ホストルート」と呼ばれます）。Pによって識別された領域の外で、Anycastアドレスは、プレフィックス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.
最悪の場合、AnycastセットのプレフィックスPはnullプレフィックスである可能性があることに注意してください。つまり、セットのメンバーにはトポロジーの局所性がない場合があります。その場合、Anycastアドレスは、インターネット全体全体で個別のルーティングエントリとして維持される必要があります。これは、このような「グローバルな」Anycastセットの数に厳しいスケーリングの制限を提供します。したがって、Global Anycastセットのサポートは利用できないか、非常に制限されている可能性があります。
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.
Anycastアドレスの予想される使用の1つは、インターネットサービスを提供する組織に属するルーターのセットを特定することです。このようなアドレスは、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.
インターネットAnycastアドレスの広範なarbitrary意的な使用に関する経験はほとんどなく、完全な一般性[AnyCST]でそれらを使用する場合、いくつかの既知の合併症と危険があります。より多くの経験が得られ、ソリューションが指定されるまで、次の制限がIPv6 Anycastアドレスに課されます。OAnycastアドレスは、IPv6パケットのソースアドレスとして使用してはなりません。
o An anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only.
o AnycastアドレスをIPv6ホストに割り当ててはなりません。つまり、IPv6ルーターのみに割り当てることができます。
The Subnet-Router anycast address is predefined. Its format is as follows:
サブネットルーターのAnycastアドレスは事前に定義されています。その形式は次のとおりです。
| 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.
Anycastアドレスの「サブネットプレフィックス」は、特定のリンクを識別するプレフィックスです。このAnycastアドレスは、ゼロに設定されたインターフェイス識別子とのリンク上のインターフェイスのユニキャストアドレスと構文的に同じです。
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.
サブネットルーターに送信されたパケットは、サブネットの1つのルーターに配信されます。すべてのルーターは、インターフェイスがあるサブネットのサブネットルーターAnycastアドレスをサポートする必要があります。
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.
サブネットルーターのAnyCastアドレスは、ノードがルーターのセットのいずれかと通信する必要があるアプリケーションに使用することを目的としています。
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.
アドレスの開始時のバイナリ11111111は、アドレスがマルチキャストアドレスであると識別します。
+-+-+-+-+
flgs is a set of 4 flags: |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は、インターネットに割り当てられた番号当局（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 Admin-Local Scope 5 Site-Local Scope 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.
Link-LocalおよびSite-Local Multicast 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.
Admin-Local Scopeは、管理的に構成する必要がある最小の範囲です。つまり、物理的な接続やその他の非マルチキャスト関連の構成から自動的に導出されません。
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サーバーグループ」に、グループIDが101（六角）の永続的なマルチキャストアドレスが割り当てられている場合、次のとおりです。
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：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：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：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：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.
ノードは、スコップフィールドに予約値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.
Tフラグが0に等しく、他のスコープ値にこれらのグループ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
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
The above multicast addresses identify the group of all IPv6 nodes, within scope 1 (interface-local) or 2 (link-local).
上記のマルチキャストアドレスは、スコープ1（インターフェイスローカル）または2（Link-Local）内のすべての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
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
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
FF02:0:0:0:0:1:FF00:0000
to
にへのまでに対してにとって
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.
[適切なインターフェイスに）計算して結合するためにノードが必要です。これが割り当てられているすべてのユニキャストアドレスとAnycastアドレスの関連付けられたノードマルチキャストアドレスが必要です。
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ノードのインターフェイスに対して構成されている追加のユニキャストおよびAnycastアドレス（手動または自動）。oループバックアドレス。oセクション2.7.1で定義されているAll-Nodesマルチキャストアドレス。oユニキャストおよびAnycastアドレスのそれぞれの勧誘されたノードマルチキャストアドレス。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 ルーターとして機能するように構成されているすべてのインターフェイスのサブネットルーターANYCASTアドレス。oルーターが構成されている他のすべてのAnycastアドレス。oセクション2.7.1で定義されているオールルーターのマルチキャストアドレス。
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. 「不特定のアドレス」、「ループバックアドレス」、および埋め込まれたIPv4アドレスを備えたIPv6アドレスは、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ユニキャストアドレススペースの割り当てをバイナリ値001から始まるアドレスの範囲に制限する必要があります。、そして現時点ではIANAによって割り当てられない。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9 , RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[Anycst] Partridge、C.、Mendez、T。and W. Milliken、「Host Anycasting Service」、RFC 1546、1993年11月。
[AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[Auth] Kent、S。およびR. Atkinson、「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.、O'Dell、M。、およびS. Deering、「集計可能なグローバルユニキャストアドレス形式」、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] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「クラスレスインタードメインルーティング（CIDR）：住所割り当てと集約戦略」、RFC 1519、1993年9月。
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[Ether] Crawford、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ビットグローバル識別子（EUI-64）登録局のガイドライン」、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] Crawford、M。、「FDDIネットワーク上のIPv6パケットの送信」、RFC 2467、1998年12月。
[MASGN] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[Masgn] Hinden、R。and S. Deering、「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] Bound、J.、Carpenter、B.、Harrington、D.、Houldsworth、J。and A. Lloyd、 "Osi nsaps and 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のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[TOKEN] Crawford, M., Narten, T. and S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC 2470, December 1998.
[トークン] Crawford、M.、Narten、T。、およびS. Thomas、「トークンリングネットワーク上のIPv6パケットの送信」、RFC 2470、1998年12月。
[TRAN] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[Tran] Gilligan、R。およびE. Nordmark、「IPv6ホストとルーターの遷移メカニズム」、RFC 2893、2000年8月。
APPENDIX A: Creating Modified EUI-64 format Interface Identifiers
付録A：修正されたEUI-64形式のインターフェイス識別子の作成
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」（ユニバーサル/ローカル）ビットを反転することです。たとえば、フォームのグローバルに一意のIEEEEUI-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
IEEE 802 48ビットMacを使用したリンクまたはノード
[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 48Bit MAC識別子からIEEE EUI-64識別子を作成する方法を定義します。これは、48ビットMACの中央（Company_idとベンダーの提供IDの間）の中央に、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 48bit 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とArcnetが含まれます。変更されたEUI-64形式識別子を作成する方法は、リンク識別子（たとえば、LocalTalk 8ビットノード識別子）を取得し、左に塗りつぶすことです。たとえば、Hexadecimal値0x4fのローカルトーク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.
組み込みの識別子の種類がないリンクがいくつかあります。これらの中で最も一般的なのは、シリアルリンクと構成されたトンネルです。サブネット-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.
リンクで組み込みの識別子が使用できない場合、優先アプローチは、別のインターフェイスまたはノード自体に割り当てられたインターフェイスからグローバルインターフェイス識別子を使用することです。このアプローチを使用する場合、同じノードを同じサブネット-Prefixに接続する他のインターフェイスは同じ識別子を使用できません。
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:
リンクで使用できるグローバルインターフェイス識別子がない場合、ローカルスコープインターフェイス識別子を作成するために実装が必要です。唯一の要件は、サブネットプレフィックス内で一意であることです。Subnet-Prefix-Uniqueインターフェイス識別子を選択するための多くのアプローチがあります。これらには以下が含まれます：
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.
サブネット-Prefix-Uniqueインターフェイス識別子は、ノードの再起動後、またはノードからインターフェイスが追加または削除された場合に変更されない方法で生成する必要があります。
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 over <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つ以上のグループを表す "::"を許可します。 - インターフェイス識別子の一意の要件を、一意のリンクからサブネットプレフィックス内の一意に変更しました。また、同じインターフェイス識別子がリンク上の異なるマシンに割り当てられないという推奨事項を追加しました。-Site-Localフォーマットを変更して、サブネットIDフィールド54ビットを長くし、38ビットゼロのフィールドを削除します。-Multicast SCOP値とルールの説明を追加して、予約されたSCOP値0を処理するためのルール0.-改訂されたセクション2.4および2.5.6は、異なるアドレスタイプの識別方法を簡素化および明確にします。これは、実装がグローバルユニキャスト形式のプレフィックスに関する知識を構築しないことを保証するために行われました。変更は次のとおりです。O削除されたフォーマットプレフィックス（FP）用語oグローバルユニキャストの例外と、他のすべてをグローバルユニキャストとして識別するシングルエントリのみを含むアドレスタイプの改訂されたリスト。oセクション2.4の主要部分であるため、セクション2.5.6から定義されたプレフィックスの例外のリストを削除しました。-IPV6の「修正されたEUI-64形式」識別子とIEEE EUI-64識別子を区別するためのEUI-64識別子に関連する明確なテキスト。 - グローバルユニキャストアドレスのセクションとNSAPアドレスをグローバルユニキャストアドレスの単一のセクションに組み合わせ、グローバルユニキャスト形式を一般化し、[AGGR]と[NSAP]を例として引用しました。 - 並べ替えられたセクション2.5.4および2.5.5。 - 削除されたセクション2.7.2新しいIPv6マルチキャストアドレスの割り当ては、他の場所で再定義されているためです。-IANA IPv6アドレスの割り当てを更新し、NSAPおよびAGGRの割り当てを文書化するIANA IPv6のアドレスを更新するIANA考慮事項セクションを追加しました。 - 「IPv4互換IPv6アドレス」がグローバルIPv4ユニキャストアドレスを使用する必要があるという明確化を追加しました。 - 規範的および非規範的なセクションへの分割された参照。-2.5.1セクション2.5.1に[Priv]への参照が追加されました - ルーターがマルチキャストアドレスに示されているスコープの外側にマルチキャストパケットを転送してはならないという明確化を追加しました。 - 不特定のアドレスのソースアドレスでパケットを転送してはならないという明確化を追加しました。-Reuterは、ループバックの宛先アドレスを備えたインターフェイスで受信したパケットをドロップする必要があるという明確化を追加しました。-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アドレス用に予約されているアドレスブロックを削除しました。 - マルチキャストスコープの変更：oスコープ値1の名前を「ノードローカル」から「インターフェイス - ローカル」に変更しましたo「管理者」と定義されたスコープ値4 - RFC1933および更新された参照への参照を修正しました。 - テキストを明確にし、より一貫性のあるものにするための多くの小さな変更。
Authors' Addresses
著者のアドレス
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
ロバートM.ヒンデンノキア313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
Phone: +1 650 625-2004
EMail: hinden@iprg.nokia.com
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Stephen E. Deering Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706 USA
Phone: +1 408 527-8213
EMail: deering@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。