[要約] RFC 2373は、IPv6アドレッシングアーキテクチャに関する標準化文書であり、IPv6アドレスの構造と使用方法を定義しています。このRFCの目的は、IPv6のアドレッシングに関する一貫性と効率性を確保することです。
Network Working Group R. Hinden
Request for Comments: 2373 Nokia
Obsoletes: 1884 S. Deering
Category: Standards Track Cisco Systems
July 1998
IP Version 6 Addressing Architecture
IPバージョン6のアドレス指定アーキテクチャ
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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. 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.................................................2
2. IPv6 Addressing..............................................2
2.1 Addressing Model.........................................3
2.2 Text Representation of Addresses.........................3
2.3 Text Representation of Address Prefixes..................5
2.4 Address Type Representation..............................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 IPv6 Addresses with Embedded IPv4 Addresses.........10
2.5.5 NSAP Addresses......................................10
2.5.6 IPX Addresses.......................................10
2.5.7 Aggregatable Global Unicast Addresses...............11
2.5.8 Local-use IPv6 Unicast Addresses....................11
2.6 Anycast Addresses.......................................12
2.6.1 Required Anycast Address............................13
2.7 Multicast Addresses.....................................14
2.7.1 Pre-Defined Multicast Addresses.....................15
2.7.2 Assignment of New IPv6 Multicast Addresses..........17
2.8 A Node's Required Addresses.............................17
3. Security Considerations.....................................18
APPENDIX A: Creating EUI-64 based Interface Identifiers........19
APPENDIX B: ABNF Description of Text Representations...........22
APPENDIX C: CHANGES FROM RFC-1884..............................23
REFERENCES.....................................................24
AUTHORS' ADDRESSES.............................................25
FULL COPYRIGHT STATEMENT.......................................26
This specification defines the addressing architecture of the IP Version 6 protocol. It includes a detailed description of the currently defined address formats for IPv6 [IPV6].
この仕様は、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, and Sue Thomson.
著者は、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の貢献に謝意を表します。 、グレッグ・ミンシャル、トーマス・ナーテン、エリック・ノードマーク、ヤコフ・レクター、ビル・シンプソン、スー・トムソン。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC 2119]で説明されているように解釈されます。
IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces. There are three types of addresses:
IPv6アドレスは、インターフェイスおよびインターフェイスのセットの128ビットの識別子です。アドレスには次の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).
エニーキャスト：インターフェースのセットの識別子（通常は異なるノードに属します）。エニーキャストアドレスに送信されたパケットは、そのアドレスで識別されるインターフェイスの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 "subscriber". When this name is used with the term "ID" for identifier after the name (e.g., "subscriber ID"), it refers to the contents of the named field. When it is used with the term "prefix" (e.g. "subscriber prefix") it refers to all of the address up to and including this field.
このドキュメントでは、アドレスのフィールドに「subscriber」などの特定の名前を付けています。この名前が、名前の後にある識別子として「ID」という用語と共に使用される場合（たとえば、「サブスクライバーID」）、名前付きフィールドの内容を参照します。 「プレフィックス」（「サブスクライバープレフィックス」など）という用語を使用する場合は、このフィールドまでのすべてのアドレスを指します。
In IPv6, all zeros and all ones are legal values for any field, unless specifically excluded. Specifically, prefixes may contain zero-valued fields or end in zeros.
IPv6では、特に除外されていない限り、すべてのゼロとすべての1はどのフィールドでも有効な値です。具体的には、プレフィックスにはゼロ値のフィールドが含まれるか、ゼロで終わる場合があります。
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 be assigned 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アドレスを割り当てることもできます。 link-scopeより大きいスコープを持つユニキャストアドレスは、非隣接ノードとの間のIPv6パケットの発信元または宛先として使用されないインターフェイスには必要ありません。これは、ポイントツーポイントインターフェイスに便利な場合があります。このアドレス指定モデルには1つの例外があります。
An 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. Examples:
1. 推奨される形式はx：x：x：x：x：x：x：xで、「x」はアドレスの8つの16ビット部分の16進値です。例：
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. The use of "::" indicates multiple groups of 16-bits of zeros. The "::" can only appear once in an address. The "::" can also be used to compress the leading and/or trailing zeros in an address.
2. 特定のスタイルのIPv6アドレスを割り当てるいくつかの方法により、アドレスにゼロビットの長い文字列が含まれることがよくあります。ゼロビットを含むアドレスの書き込みを容易にするために、ゼロを圧縮する特別な構文を使用できます。 「::」の使用は、ゼロの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
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：ddddです。ここで、「x」は6つの高次16-の16進値です。アドレスのビット部分、および「d」は、アドレスの4つの下位8ビット部分（標準IPv4表現）の10進値です。例：
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
：：１３。１。６８。３
::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. An IPv6 address prefix is represented by the notation:
IPv6アドレスプレフィックスのテキスト表現は、IPv4アドレスプレフィックスが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.
prefix-lengthは、アドレスの左端の連続するビットの何個がプレフィックスを構成するかを指定する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
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::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:
ノードアドレスとそのノードアドレスのプレフィックス（たとえば、ノードのサブネットプレフィックス）の両方を書き込む場合、次のように2つを組み合わせることができます。
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 specific type of an IPv6 address is indicated by the leading bits in the address. The variable-length field comprising these leading bits is called the Format Prefix (FP). The initial allocation of these prefixes is as follows:
IPv6アドレスの特定のタイプは、アドレスの先頭ビットで示されます。これらの先行ビットを構成する可変長フィールドは、フォーマットプレフィックス（FP）と呼ばれます。これらのプレフィックスの初期割り当ては次のとおりです。
Allocation Prefix Fraction of
(binary) Address Space
----------------------------------- -------- -------------
Reserved 0000 0000 1/256
Unassigned 0000 0001 1/256
Reserved for NSAP Allocation 0000 001 1/128 Reserved for IPX Allocation 0000 010 1/128
NSAP割り当て用に予約済み0000 001 1/128 IPX割り当て用に予約済み0000 010 1/128
Unassigned 0000 011 1/128 Unassigned 0000 1 1/32 Unassigned 0001 1/16
未割り当て0000 011 1/128未割り当て0000 1 1/32未割り当て0001 1/16
Aggregatable Global Unicast Addresses 001 1/8 Unassigned 010 1/8 Unassigned 011 1/8 Unassigned 100 1/8 Unassigned 101 1/8 Unassigned 110 1/8
集約可能なグローバルユニキャストアドレス001 1/8未割り当て010 1/8未割り当て011 1/8未割り当て100 1/8未割り当て101 1/8未割り当て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
未割り当て1110 1/16未割り当て1111 0 1/32未割り当て1111 10 1/64未割り当て1111110 1/128未割り当て1111 1110 0 1/512
Link-Local Unicast Addresses 1111 1110 10 1/1024 Site-Local Unicast Addresses 1111 1110 11 1/1024
リンクローカルユニキャストアドレス1111 1110 10 1/1024サイトローカルユニキャストアドレス1111 1110 11 1/1024
Multicast Addresses 1111 1111 1/256
マルチキャストアドレス1111 1111 1/256
Notes:
ノート：
(1) The "unspecified address" (see section 2.5.2), the loopback address (see section 2.5.3), and the IPv6 Addresses with Embedded IPv4 Addresses (see section 2.5.4), are assigned out of the 0000 0000 format prefix space.
（1）「未指定アドレス」（セクション2.5.2を参照）、ループバックアドレス（セクション2.5.3を参照）、およびIPv4アドレスが埋め込まれたIPv6アドレス（セクション2.5.4を参照）は、0000 0000から割り当てられます。プレフィックススペースをフォーマットします。
(2) The format prefixes 001 through 111, except for Multicast Addresses (1111 1111), are all required to have to have 64-bit interface identifiers in EUI-64 format. See section 2.5.1 for definitions.
（2）マルチキャストアドレス（1111 1111）を除いて、フォーマットプレフィックス001〜111はすべて、EUI-64フォーマットの64ビットインターフェイス識別子を持つ必要があります。定義については、セクション2.5.1を参照してください。
This allocation supports the direct allocation of aggregation addresses, local use addresses, and multicast addresses. Space is reserved for NSAP addresses and IPX addresses. The remainder of the address space is unassigned for future use. This can be used for expansion of existing use (e.g., additional aggregatable addresses, etc.) or new uses (e.g., separate locators and identifiers). Fifteen percent of the address space is initially allocated. The remaining 85% is reserved for future use.
この割り当ては、集約アドレス、ローカル使用アドレス、およびマルチキャストアドレスの直接割り当てをサポートしています。スペースはNSAPアドレスとIPXアドレス用に予約されています。アドレス空間の残りの部分は、将来の使用のために割り当てられていません。これは、既存の用途（たとえば、追加の集約可能なアドレスなど）または新しい用途（たとえば、個別のロケーターと識別子）の拡張に使用できます。アドレス空間の15％が最初に割り当てられます。残りの85％は将来の使用のために予約されています。
Unicast addresses are distinguished from multicast addresses by the value of the high-order octet of the addresses: a value of FF (11111111) identifies an address as a multicast address; any other value identifies an address as a unicast address. Anycast addresses are taken from the unicast address space, and are not syntactically distinguishable from unicast addresses.
ユニキャストアドレスは、アドレスの上位オクテットの値によってマルチキャストアドレスと区別されます。値FF（11111111）は、アドレスをマルチキャストアドレスとして識別します。その他の値は、アドレスをユニキャストアドレスとして識別します。エニーキャストアドレスは、ユニキャストアドレス空間から取得され、構文的にはユニキャストアドレスと区別できません。
IPv6 unicast addresses are aggregatable with contiguous bit-wise masks similar to IPv4 addresses under Class-less Interdomain Routing [CIDR].
IPv6ユニキャストアドレスは、クラスレスドメイン間ルーティング[CIDR]のIPv4アドレスと同様に、連続するビット単位のマスクで集約できます。
There are several forms of unicast address assignment in IPv6, including the global aggregatable global unicast address, the NSAP address, the IPX hierarchical address, the site-local address, the link-local address, and the IPv4-capable host address. Additional address types can be defined in the future.
IPv6には、グローバル集約可能なグローバルユニキャストアドレス、NSAPアドレス、IPX階層アドレス、サイトローカルアドレス、リンクローカルアドレス、IPv4対応ホストアドレスなど、いくつかの形式のユニキャストアドレス割り当てがあります。今後、追加のアドレスタイプを定義できます。
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 bits | 128-n bits |
+------------------------------------------------+----------------+
| subnet prefix | interface ID |
+------------------------------------------------+----------------+
Still more sophisticated hosts may be aware of other hierarchical boundaries in the unicast address. 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 on that link. They may also be unique over a broader scope. In many cases an interface's identifier will be the same as that interface's link-layer address. The same interface identifier may be used on multiple interfaces on a single node.
IPv6ユニキャストアドレスのインターフェイス識別子は、リンク上のインターフェイスを識別するために使用されます。それらはそのリンク上で一意である必要があります。それらはまた、より広い範囲にわたって一意である可能性があります。多くの場合、インターフェイスの識別子はそのインターフェイスのリンク層アドレスと同じになります。単一ノード上の複数のインターフェースで同じインターフェース識別子を使用できます。
Note that the use of the same interface identifier on multiple interfaces of a single node does not affect the interface identifier's global uniqueness or each IPv6 addresses global uniqueness created using that interface identifier.
単一ノードの複数のインターフェースで同じインターフェース識別子を使用しても、インターフェース識別子のグローバルな一意性、またはそのインターフェース識別子を使用して作成された各IPv6アドレスのグローバルな一意性には影響しません。
In a number of the format prefixes (see section 2.4) Interface IDs are required to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI64]. EUI-64 based Interface identifiers may have global scope when a global token is available (e.g., IEEE 48bit MAC) or may have local scope where a global token is not available (e.g., serial links, tunnel end-points, etc.). It is required that the "u" bit (universal/local bit in IEEE EUI-64 terminology) be inverted when forming the interface identifier from the EUI-64. 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 EUI-64 identifier are as follows:
多くのフォーマットプレフィックス（セクション2.4を参照）では、インターフェースIDは64ビット長で、IEEE EUI-64フォーマット[EUI64]で構成する必要があります。 EUI-64ベースのインターフェース識別子は、グローバルトークンが利用可能な場合（IEEE 48ビットMACなど）にグローバルスコープを持つ場合と、グローバルトークンが利用できない場合（シリアルリンク、トンネルエンドポイントなど）にローカルスコープを持つ場合があります。 EUI-64からインターフェースIDを形成するときは、「u」ビット（IEEE EUI-64用語ではユニバーサル/ローカルビット）を反転させる必要があります。 「u」ビットはグローバルスコープを示すために1に設定され、ローカルスコープを示すためにゼロ（0）に設定されます。 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 EUI-64 based Interface Identifiers" provides examples on the creation of different EUI-64 based interface identifiers.
インターネット標準ビット順で記述されます。「u」はユニバーサル/ローカルビット、「g」は個人/グループビット、「c」はcompany_idのビットです。付録A：「EUI-64ベースのインターフェイス識別子の作成」では、さまざまなEUI-64ベースのインターフェイス識別子の作成例を示します。
The motivation for inverting the "u" bit when forming the interface identifier is to make it easy for system administrators to hand configure local scope 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 IEEE EUI-64 identifier is to allow development of future technology that can take advantage of interface identifiers with global scope.
IEEE 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 over Ethernet」[ETHER]、「IPv6 over FDDI」[FDDI]などの適切な「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.
未指定のアドレスは、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 may be thought of as being associated with a virtual interface (e.g., the loopback interface).
ユニキャストアドレス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.
ループバックアドレスは、単一ノードの外部に送信されるIPv6パケットの送信元アドレスとして使用しないでください。ループバックの宛先アドレスを持つIPv6パケットは、単一ノードの外部に送信してはならず、IPv6ルーターによって転送してはなりません。
The IPv6 transition mechanisms [TRAN] include a technique for hosts and routers to dynamically tunnel IPv6 packets over IPv4 routing infrastructure. IPv6 nodes that utilize this technique are assigned special IPv6 unicast addresses that carry an 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 |
+--------------------------------------+----+---------------------+
A second type of IPv6 address which holds an embedded IPv4 address is also defined. This address is used to represent the addresses of IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. This type of address is termed an "IPv4-mapped IPv6 address" and has the format:
埋め込まれたIPv4アドレスを保持する2番目のタイプのIPv6アドレスも定義されます。このアドレスは、IPv4のみのノード（IPv6をサポートしていない*）のアドレスをIPv6アドレスとして表すために使用されます。このタイプのアドレスは「IPv4マッピングIPv6アドレス」と呼ばれ、次の形式になります。
| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|FFFF| IPv4 address |
+--------------------------------------+----+---------------------+
This mapping of NSAP address into IPv6 addresses is defined in [NSAP]. This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. However, it also defines a set of mechanisms for the support of OSI NSAP addressing in an IPv6 network. These mechanisms are the ones that must be used if such support is required. This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required.
このNSAPアドレスのIPv6アドレスへのマッピングは、[NSAP]で定義されています。このドキュメントでは、OSI NSAPアドレス指定計画を計画または展開し、IPv6への展開または移行を希望するネットワーク実装者が、ニーズを満たすためにネイティブIPv6アドレス指定計画を再設計することを推奨しています。ただし、IPv6ネットワークでOSI NSAPアドレッシングをサポートするための一連のメカニズムも定義しています。これらのメカニズムは、そのようなサポートが必要な場合に使用する必要があるメカニズムです。このドキュメントでは、必要に応じて、OSIアドレス形式内のIPv6アドレスのマッピングも定義しています。
This mapping of IPX address into IPv6 addresses is as follows:
このIPXアドレスのIPv6アドレスへのマッピングは次のとおりです。
| 7 | 121 bits |
+-------+---------------------------------------------------------+
|0000010| to be defined |
+-------+---------------------------------------------------------+
The draft definition, motivation, and usage are under study.
ドラフトの定義、動機、および使用法は現在検討中です。
The global aggregatable global unicast address is defined in [AGGR]. This address format is designed to support both the current provider based aggregation and a new type of aggregation called exchanges. The combination will allow efficient routing aggregation for both sites which connect directly to providers and who connect to exchanges. Sites will have the choice to connect to either type of aggregation point.
グローバルな集約可能なグローバルユニキャストアドレスは、[AGGR]で定義されています。このアドレス形式は、現在のプロバイダーベースの集約と、エクスチェンジと呼ばれる新しいタイプの集約の両方をサポートするように設計されています。この組み合わせにより、プロバイダーに直接接続するサイトとエクスチェンジに接続するサイトの両方で効率的なルーティング集約が可能になります。サイトは、どちらのタイプの集約ポイントに接続するかを選択できます。
The IPv6 aggregatable global unicast address format is as follows:
IPv6集約可能グローバルユニキャストアドレス形式は次のとおりです。
| 3| 13 | 8 | 24 | 16 | 64 bits |
+--+-----+---+--------+--------+--------------------------------+
|FP| TLA |RES| NLA | SLA | Interface ID |
| | ID | | ID | ID | |
+--+-----+---+--------+--------+--------------------------------+
Where
ただし
001 Format Prefix (3 bit) for Aggregatable Global Unicast Addresses TLA ID Top-Level Aggregation Identifier RES Reserved for future use NLA ID Next-Level Aggregation Identifier SLA ID Site-Level Aggregation Identifier INTERFACE ID Interface Identifier
001フォーマットプレフィックス（3ビット）集約可能なグローバルユニキャストアドレスTLA IDトップレベル集約識別子RES将来の使用のために予約済みNLA ID次レベル集約識別子SLA IDサイトレベル集約識別子INTERFACE IDインターフェイス識別子
The contents, field sizes, and assignment rules are defined in [AGGR].
内容、フィールドサイズ、および割り当てルールは、[AGGR]で定義されています。
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は単一のサイトで使用するためのものです。リンクローカルアドレスの形式は次のとおりです。
| 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 auto-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 | 38 bits | 16 bits | 64 bits |
+----------+-------------+-----------+----------------------------+
|1111111011| 0 | 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.
サイトローカルアドレスは、グローバルプレフィックスを必要とせずに、サイト内のアドレス指定に使用されるように設計されています。
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 address prefix P that identifies the topological region in which all interfaces belonging to that anycast address reside. Within the region identified by P, each member of the anycast set must be advertised 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 advertisement 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 advertised 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 aggregation or sequence of aggregations. 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.
エニーキャストアドレスの予想される用途の1つは、インターネットサービスを提供する組織に属するルーターのセットを識別することです。このようなアドレスをIPv6ルーティングヘッダーの中間アドレスとして使用して、特定の集約または集約のシーケンスを介してパケットを配信できます。他のいくつかの可能な用途は、特定のサブネットに接続されたルーターのセット、または特定のルーティングドメインへのエントリを提供するルーターのセットを識別することです。
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 agreed upon for those problems, the following restrictions are imposed on IPv6 anycast addresses:
インターネットエニーキャストアドレスの広範囲で恣意的な使用の経験はほとんどなく、完全な一般性[ANYCST]で使用した場合のいくつかの既知の合併症と危険性があります。より多くの経験が得られ、それらの問題に対する解決策が合意されるまで、IPv6エニーキャストアドレスには次の制限が課されます。
o An anycast address must not be used as the source address of an IPv6 packet.
o エニーキャストアドレスは、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 エニーキャストアドレスはIPv6ホストに割り当てないでください。つまり、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 which they have interfaces.
サブネットルーターのエニーキャストアドレスに送信されたパケットは、サブネット上の1つのルーターに配信されます。すべてのルーターは、インターフェースを持っているサブネットのサブネットルーターエニーキャストアドレスをサポートする必要があります。
The subnet-router anycast address is intended to be used for applications where a node needs to communicate with one of a set of routers on a remote subnet. For example when a mobile host needs to communicate with one of the mobile agents on its "home" subnet.
サブネットルーターエニーキャストアドレスは、ノードがリモートサブネット上のルーターセットの1つと通信する必要があるアプリケーションで使用することを目的としています。たとえば、モバイルホストが「ホーム」サブネット上のモバイルエージェントの1つと通信する必要がある場合。
An IPv6 multicast address is an identifier for a group of nodes. A node 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 |
+--------+----+----+---------------------------------------------+
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 global internet numbering authority.
T = 0は、グローバルインターネット番号付け機関によって割り当てられた、永続的に割り当てられた（「既知の」）マルチキャストアドレスを示します。
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 node-local scope 2 link-local scope 3 (unassigned) 4 (unassigned) 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予約済み
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（16進数）の永続的なマルチキャストアドレスが割り当てられている場合、次のようになります。
FF01:0:0:0:0:0:0:101 means all NTP servers on 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 at 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パケットの送信元アドレスとして使用したり、ルーティングヘッダーに表示したりしないでください。
The following well-known multicast addresses are pre-defined:
次の既知のマルチキャストアドレスが事前定義されています。
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 (node-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
The above multicast addresses identify the group of all IPv6 routers, within scope 1 (node-local), 2 (link-local), or 5 (site-local).
上記のマルチキャストアドレスは、スコープ1（ノードローカル）、2（リンクローカル）、または5（サイトローカル）内のすべてのIPv6ルーターのグループを識別します。
Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX
The above multicast address is computed as a function of a node's
unicast and anycast addresses. The solicited-node multicast address
is formed by taking the low-order 24 bits of the 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 the associated Solicited-Node multicast addresses for every unicast and anycast address it is assigned.
ノードは、割り当てられているすべてのユニキャストおよびエニーキャストアドレスについて、関連する要請ノードマルチキャストアドレスを計算して結合する必要があります。
The current approach [ETHER] to map IPv6 multicast addresses into IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 multicast address and uses it to create a MAC address. Note that Token Ring networks are handled differently. This is defined in [TOKEN]. Group ID's less than or equal to 32 bits will generate unique MAC addresses. Due to this new IPv6 multicast addresses should be assigned so that the group identifier is always in the low order 32 bits as shown in the following:
IPv6マルチキャストアドレスをIEEE 802 MACアドレスにマップする現在のアプローチ[ETHER]は、IPv6マルチキャストアドレスの下位32ビットを取り、それを使用してMACアドレスを作成します。トークンリングネットワークは異なる方法で処理されることに注意してください。これは[TOKEN]で定義されています。グループIDが32ビット以下の場合、一意のMACアドレスが生成されます。この新しいIPv6マルチキャストアドレスのため、次のように、グループ識別子が常に下位32ビットになるように割り当てる必要があります。
| 8 | 4 | 4 | 80 bits | 32 bits |
+------ -+----+----+---------------------------+-----------------+
|11111111|flgs|scop| reserved must be zero | group ID |
+--------+----+----+---------------------------+-----------------+
While this limits the number of permanent IPv6 multicast groups to 2^32 this is unlikely to be a limitation in the future. If it becomes necessary to exceed this limit in the future multicast will still work but the processing will be sightly slower.
これにより、永続的なIPv6マルチキャストグループの数が2 ^ 32に制限されますが、これは将来の制限とはなりそうにありません。今後この制限を超える必要が生じた場合でもマルチキャストは機能しますが、処理は少し遅くなります。
Additional IPv6 multicast addresses are defined and registered by the IANA [MASGN].
追加のIPv6マルチキャストアドレスは、IANA [MASGN]によって定義および登録されます。
A host is required to recognize the following addresses as identifying itself:
ホストは、次のアドレスを自身を識別するものとして認識する必要があります。
o Its Link-Local Address for each interface o Assigned Unicast Addresses o Loopback Address o All-Nodes Multicast Addresses o Solicited-Node Multicast Address for each of its assigned unicast and anycast addresses o Multicast Addresses of all other groups to which the host belongs.
o 各インターフェイスのリンクローカルアドレスo割り当てられたユニキャストアドレスoループバックアドレス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 the interfaces it is
configured to act as a router on.
o All other Anycast addresses with which the router has been
configured.
o All-Routers Multicast Addresses
o Multicast Addresses of all other groups to which the router
belongs.
The only address prefixes which should be predefined in an implementation are the:
実装で事前定義する必要がある唯一のアドレスプレフィックスは次のとおりです。
o Unspecified Address o Loopback Address o Multicast Prefix (FF) o Local-Use Prefixes (Link-Local and Site-Local) o Pre-Defined Multicast Addresses o IPv4-Compatible Prefixes
o 未指定アドレスoループバックアドレスoマルチキャストプレフィックス（FF）oローカル使用プレフィックス（リンクローカルおよびサイトローカル）o事前定義されたマルチキャストアドレスo IPv4互換プレフィックス
Implementations should assume all other addresses are unicast unless specifically configured (e.g., anycast addresses).
実装では、特に構成されていない限り、他のすべてのアドレスがユニキャストであると想定する必要があります（エニーキャストアドレスなど）。
IPv6 addressing documents do not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined in [AUTH].
IPv6アドレス指定ドキュメントは、インターネットインフラストラクチャのセキュリティに直接影響を与えません。 IPv6パケットの認証は[AUTH]で定義されています。
APPENDIX A : Creating EUI-64 based Interface Identifiers
--------------------------------------------------------
Depending on the characteristics of a specific link or node there are a number of approaches for creating EUI-64 based interface identifiers. This appendix describes some of these approaches.
特定のリンクまたはノードの特性に応じて、EUI-64ベースのインターフェース識別子を作成するための多くのアプローチがあります。この付録では、これらのアプローチのいくつかについて説明します。
Links or Nodes with EUI-64 Identifiers
EUI-64識別子を持つリンクまたはノード
The only change needed to transform an EUI-64 identifier to an interface identifier is to invert the "u" (universal/local) bit. For example, a globally unique EUI-64 identifier of the form:
EUI-64識別子をインターフェイス識別子に変換するために必要な唯一の変更は、「u」（ユニバーサル/ローカル）ビットを反転することです。たとえば、次の形式のグローバルに一意の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インターフェースIDは次の形式になります。
|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 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 MAC with global scope:
[EUI64]は、IEEE 48ビットMAC識別子からEUI-64識別子を作成する方法を定義しています。これは、48ビットMACの中央（company_idとベンダー提供のIDの間）に、16進数の値が0xFFおよび0xFEの2つのオクテットを挿入するためのものです。たとえば、グローバルスコープの48ビット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:
|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 should use them to create interface identifiers due to their availability and uniqueness properties.
IEEE 802 48ビットMACアドレスが（インターフェースまたはノード上で）使用可能な場合、実装はそれらの可用性と一意性の特性のため、それらを使用してインターフェース識別子を作成する必要があります。
Links with Non-Global Identifiers
非グローバル識別子とのリンク
There are a number of types of links that, while multi-access, do not have globally unique link identifiers. Examples include LocalTalk and Arcnet. The method to create an EUI-64 formatted 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:
マルチアクセスではありますが、グローバルに一意のリンク識別子を持たないリンクのタイプがいくつかあります。例としては、LocalTalkやArcnetがあります。 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 for the link.
組み込みIDのタイプがないリンクがいくつかあります。これらの最も一般的なものは、シリアルリンクと設定されたトンネルです。リンクに固有のインターフェースIDを選択する必要があります。
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. To use this approach no other interface connecting the same node to the same link may use the same identifier.
リンクで組み込みの識別子を使用できない場合、推奨されるアプローチは、別のインターフェイスまたはノード自体に割り当てられているインターフェイスからのグローバルインターフェイス識別子を使用することです。このアプローチを使用するには、同じノードを同じリンクに接続する他のインターフェースが同じ識別子を使用することはできません。
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 on the link. There are many possible approaches to select a link-unique interface identifier. They include:
リンクで使用できるグローバルインターフェイス識別子がない場合、実装はローカルスコープインターフェイス識別子を作成する必要があります。唯一の要件は、リンク上で一意であることです。リンク固有のインターフェイス識別子を選択するには、多くの可能なアプローチがあります。以下が含まれます：
Manual Configuration Generated Random Number Node Serial Number (or other node-specific token)
手動構成で生成された乱数ノードのシリアル番号（または他のノード固有のトークン）
The link-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 over <link>」仕様で定義されています。衝突検出アルゴリズムは、自動アルゴリズムの一部として実装することを強くお勧めします。
APPENDIX B: ABNF Description of Text Representations
----------------------------------------------------
This appendix defines the text representation of IPv6 addresses and prefixes in Augmented BNF [ABNF] for reference purposes.
この付録では、参考のために、拡張BNF [ABNF]のIPv6アドレスとプレフィックスのテキスト表現を定義します。
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6prefix = hexpart "/" 1*2DIGIT
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
APPENDIX C: CHANGES FROM RFC-1884
---------------------------------
The following changes were made from RFC-1884 "IP Version 6 Addressing Architecture":
RFC-1884「IPバージョン6アドレッシングアーキテクチャ」から次の変更が行われました。
- Added an appendix providing a ABNF description of text representations. - Clarification that link unique identifiers not change after reboot or other interface reconfigurations. - Clarification of Address Model based on comments. - Changed aggregation format terminology to be consistent with aggregation draft. - Added text to allow interface identifier to be used on more than one interface on same node. - Added rules for defining new multicast addresses. - Added appendix describing procedures for creating EUI-64 based interface ID's. - Added notation for defining IPv6 prefixes. - Changed solicited node multicast definition to use a longer prefix. - Added site scope all routers multicast address. - Defined Aggregatable Global Unicast Addresses to use "001" Format Prefix. - Changed "010" (Provider-Based Unicast) and "100" (Reserved for Geographic) Format Prefixes to Unassigned. - Added section on Interface ID definition for unicast addresses. Requires use of EUI-64 in range of format prefixes and rules for setting global/local scope bit in EUI-64. - Updated NSAP text to reflect working in RFC1888. - Removed protocol specific IPv6 multicast addresses (e.g., DHCP) and referenced the IANA definitions. - Removed section "Unicast Address Example". Had become OBE. - Added new and updated references. - Minor text clarifications and improvements.
- テキスト表現のABNF記述を提供する付録を追加しました。 -一意の識別子をリンクすることの明確化は、再起動または他のインターフェイスの再構成後に変更されません。 -コメントに基づくアドレスモデルの明確化。 -集計形式の用語を集計ドラフトと一致するように変更しました。 -同じノードの複数のインターフェースでインターフェース識別子を使用できるようにするテキストを追加しました。 -新しいマルチキャストアドレスを定義するためのルールが追加されました。 -EUI-64ベースのインターフェースIDを作成する手順を説明する付録を追加。 -IPv6プレフィックスを定義するための表記を追加。 -要請ノードマルチキャスト定義を変更して、より長いプレフィックスを使用するようにしました。 -すべてのルーターのマルチキャストアドレスにサイトスコープを追加しました。 -「001」形式のプレフィックスを使用するように定義された集約可能なグローバルユニキャストアドレス。 -「010」（プロバイダーベースのユニキャスト）および「100」（地理用に予約）の形式のプレフィックスを未割り当てに変更しました。 -ユニキャストアドレスのインターフェイスID定義に関するセクションを追加。 EUI-64でグローバル/ローカルスコープビットを設定するには、フォーマットプレフィックスとルールの範囲でEUI-64を使用する必要があります。 -RFC1888での作業を反映するようにNSAPテキストを更新しました。 -プロトコル固有のIPv6マルチキャストアドレス（DHCPなど）を削除し、IANA定義を参照しました。 -「ユニキャストアドレスの例」セクションを削除。 OBEになっていた。 -新しい参照と更新された参照を追加しました。 -マイナーテキストの説明と改善。
REFERENCES
参考文献
[ABNF] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 2234、1997年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、「An Aggregatable Global Unicast Address Format」、RFC 2374、1998年7月。
[AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[AUTH] Atkinson、R。、「IP Authentication Header」、RFC 1826、1995年8月。
[ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[ANYCST] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycasting Service」、RFC 1546、1993年11月。
[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、「Classless Inter-Domain Routing（CIDR）：an Address Assignment and Aggregation Strategy」、RFC 1519、1993年9月。
[ETHER] Crawford, M., "Transmission of IPv6 Pacekts over Ethernet Networks", Work in Progress.
[ETHER] Crawford、M。、「IPv6 Pacekts over Ethernet Networks over Transmission」、Work in Progress。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997.
[EUI64] IEEE、「64ビットグローバル識別子（EUI-64）登録局のガイドライン」、http：//standards.ieee.org/db/oui/tutorials/EUI64.html、1997年3月。
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", Work in Progress.
[FDDI]クロフォードM。、「FDDIネットワークを介したIPv6パケットの送信」、作業中。
[IPV6] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[IPV6] Deering、S。、およびR. Hinden、編集者、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 1883、1995年12月。
[MASGN] Hinden, R., and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[MASGN] Hinden、R。、および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]バウンド、J。、カーペンター、B。、ハリントン、D。、ホールズワース、J。、およびA.ロイド、「OSI NSAPs and IPv6」、RFC 1888、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[TOKEN] Thomas, S., "Transmission of IPv6 Packets over Token Ring Networks", Work in Progress.
[トークン] Thomas、S。、「トークンリングネットワーク上でのIPv6パケットの送信」、進行中。
[TRAN] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1993, April 1996.
[TRAN] Gilligan、R。、およびE. Nordmark、「IPv6ホストおよびルーターの移行メカニズム」、RFC 1993、1996年4月。
AUTHORS' ADDRESSES
著者のアドレス
Robert M. Hinden Nokia 232 Java Drive Sunnyvale, CA 94089 USA
ロバート・M Hindon Nokia 232 Java Drive Sunnyvale、CA 94089彼
Phone: +1 408 990-2004
Fax: +1 408 743-5677
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
Fax: +1 408 527-8254
EMail: deering@cisco.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。