RFC4291 日本語訳
4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. February 2006. (Format: TXT=52897 bytes) (Obsoletes RFC3513) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Hinden
Request for Comments: 4291 Nokia
Obsoletes: 3513 S. Deering
Category: Standards Track Cisco Systems
February 2006
Hindenがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4291 ノキアは以下を時代遅れにします。 3513秒間デアリングカテゴリ: 標準化過程シスコシステムズ2006年2月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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ノードの必要なアドレスを含んでいます。
This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture".
「IPバージョン6はアーキテクチャを扱っ」て、このドキュメントがRFC3513を時代遅れにします。
Hinden Standards Track [Page 1] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[1ページ]RFC4291IPv6
Table of Contents
目次
1. Introduction ....................................................2
2. IPv6 Addressing .................................................2
2.1. Addressing Model ...........................................3
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 ..........................................6
2.5.1. Interface Identifiers ...............................7
2.5.2. The Unspecified Address .............................9
2.5.3. The Loopback Address ................................9
2.5.4. Global Unicast Addresses ............................9
2.5.5. IPv6 Addresses with Embedded IPv4 Addresses ........10
2.5.6. Link-Local IPv6 Unicast Addresses ..................11
2.5.7. Site-Local IPv6 Unicast Addresses ..................11
2.6. Anycast Addresses .........................................12
2.6.1. Required Anycast Address ...........................12
2.7. Multicast Addresses .......................................13
2.7.1. Pre-Defined Multicast Addresses ....................15
2.8. A Node's Required Addresses ...............................17
3. Security Considerations ........................................18
4. IANA Considerations ............................................18
5. Acknowledgements ...............................................18
6. References .....................................................18
6.1. Normative References ......................................18
6.2. Informative References ....................................18
Appendix A: Creating Modified EUI-64 Format Interface Identifiers .20
Appendix B: Changes from RFC 3513 .................................22
1. 序論…2 2. IPv6アドレシング…2 2.1. モデルに演説します…3 2.2. アドレスのテキスト表現…4 2.3. アドレス接頭語のテキスト表現…5 2.4. タイプ確認を扱ってください…6 2.5. ユニキャストアドレス…6 2.5.1. 識別子を連結してください…7 2.5.2. 不特定のアドレス…9 2.5.3. ループバックアドレス…9 2.5.4. グローバルなユニキャストアドレス…9 2.5.5. IPv6は埋め込まれたIPv4と共にアドレスを扱います…10 2.5.6. リンクローカルのIPv6ユニキャストアドレス…11 2.5.7. サイトローカルのIPv6ユニキャストアドレス…11 2.6. Anycastアドレス…12 2.6.1. Anycastアドレスを必要とします…12 2.7. マルチキャストアドレス…13 2.7.1. マルチキャストアドレスを事前に定義します…15 2.8. ノードの必要なアドレス…17 3. セキュリティ問題…18 4. IANA問題…18 5. 承認…18 6. 参照…18 6.1. 標準の参照…18 6.2. 有益な参照…18 付録A: 作成はEUI-64形式インタフェース識別子.20付録Bを変更しました: RFC3513からの変化…22
1. Introduction
1. 序論
This specification defines the addressing architecture of the IP Version 6 protocol. It includes the basic formats for the various types of IPv6 addresses (unicast, anycast, and multicast).
この仕様はIPバージョン6プロトコルのアドレッシング体系を定義します。 それは様々なタイプのIPv6アドレス(ユニキャスト、anycast、およびマルチキャスト)のための基本形式を含んでいます。
2. IPv6 Addressing
2. IPv6アドレシング
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アドレスはインタフェース(「インタフェース」が[IPV6]のセクション2で定義されるようにそこにある)のインタフェースとセットのための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.
ユニキャスト: 単一のインタフェースのための識別子。 ユニキャストアドレスに送られたパケットはそのアドレスによって特定されたインタフェースに提供されます。
Hinden Standards Track [Page 2] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[2ページ]RFC4291IPv6
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: 1セットのインタフェース(異なったノードに通常属す)のための識別子。 anycastアドレスに送られたパケットはそのアドレス(ルーティング・プロトコルの距離の基準に従った“nearest"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.
マルチキャスト: 1セットのインタフェース(異なったノードに通常属す)のための識別子。 マルチキャストアドレスに送られたパケットはそのアドレスによって特定されたすべてのインタフェースに提供されます。
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では、明確に除かれない場合、すべてのゼロとすべての1つがどんな分野への正当な値です。 明確に、無評価された分野は、接頭語で含むかもしれなくて、終わります。
2.1. Addressing Model
2.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 have multiple IPv6 addresses of any type (unicast, anycast, and multicast) or scope. Unicast addresses with a 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つのLinkローカルのユニキャストアドレスを持つのに必要です(追加必要なアドレスに関してセクション2.8を見てください)。 また、単一のインタフェースには、どんなタイプ(ユニキャスト、anycast、およびマルチキャスト)や範囲の複数の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つのインタフェースとして複数の物理インターフェースを扱うなら、ユニキャストアドレスかユニキャストアドレスのセットが複数の物理インターフェースに割り当てられるかもしれません。 これは複数の物理インターフェースにわたる負荷分割法の役に立ちます。
Hinden Standards Track [Page 3] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[3ページ]RFC4291IPv6
Currently, IPv6 continues the IPv4 model in that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link.
サブネット接頭語が1個のリンクに関連しているので、現在、IPv6はIPv4モデルを続けています。 複数のサブネット接頭語が同じリンクに割り当てられるかもしれません。
2.2. Text Representation of Addresses
2.2. アドレスのテキスト表現
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 one to
four hexadecimal digits of the eight 16-bit pieces of the address.
Examples:
1. 好まれた形はx:x:x:x:x:x:x: x、どこです。'xのものは8つのアドレスの1〜4つの16進数字です'。 例:
ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
ABCD: EF01:2345:6789:ABCD:EF01:2345:6789
2001:DB8:0:0:8:800:200C:417A
2001:DB8: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 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.
2. あるスタイルのIPv6アドレスを割り当てるいくつかのメソッドのために、アドレスがゼロ・ビットのロング・ストリングを含むのは、一般的でしょう。 ゼロを含むアドレスを書くのを何ビットも、より簡単にして、特別な構文は、ゼロを圧縮するために利用可能です。 「使用、」、:、:、」 ゼロの16ビットの1つ以上のグループを示します。 「The」、:、:、」 アドレスに一度載ることができるだけです。 「The」、:、:、」 また、アドレスで主であるか引きずっているゼロを圧縮するのに使用できます。
For example, the following addresses
例えば、以下のアドレス
2001:DB8: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 address
2001 : DB8:、8:800:200、0:0:C: 417A aユニキャストアドレスFF01:、0:、0:0:0、:、0:0:101、マルチキャストアドレス、0:0:、0:0:0、:、0:0:1、ループバックアドレス、0:0:、0:0:0、:、0:0:0、不特定のアドレス
may be represented as
表されるかもしれません。
2001:DB8::8:800:200C:417A a unicast address
FF01::101 a multicast address
::1 the loopback address
:: the unspecified address
2001 : DB8:、:8:800:200C: 417A aユニキャストアドレスFF01:、:1マルチキャストあたり101は以下を扱います:1 ループバックアドレス:、: 不特定のアドレス
3. An alternative form that is sometimes more convenient when dealing
with a mixed environment of IPv4 and IPv6 nodes is
x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
the six high-order 16-bit pieces of the address, and the 'd's are
3. そして、IPv4とIPv6ノードの複雑な環境に対処するとき時々より便利な選択方式が'x'がアドレスの16ビットの6高位つの16進値であるx:x:x:x:x:x:d.d.d.dである、そうしただろう、'
Hinden Standards Track [Page 4] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[4ページ]RFC4291IPv6
the decimal values of the four low-order 8-bit pieces of the
address (standard IPv4 representation). Examples:
アドレス(標準のIPv4表現)の8ビットの下位の4つのデシマル値。 例:
0:0:0:0:0:0:13.1.68.3
0:0:0:0:0:0:13.1.68.3
0:0:0:0:0:FFFF:129.144.52.38
0:0:0:0:0:FFFF: 129.144 .52、.38
or in compressed form:
または、圧縮されるところでは、形成してください:
::13.1.68.3
::13.1.68.3
::FFFF:129.144.52.38
::FFFF: 129.144 .52、.38
2.3. Text Representation of Address Prefixes
2.3. アドレス接頭語のテキスト表現
The text representation of IPv6 address prefixes is similar to the way IPv4 address prefixes are written in Classless Inter-Domain Routing (CIDR) notation [CIDR]. An IPv6 address prefix is represented by the notation:
IPv6アドレス接頭語のテキスト表現はClassless Inter-ドメインルート設定(CIDR)記法[CIDR]でIPv4アドレス接頭語が書かれている方法と同様です。 IPv6アドレス接頭語は記法で表されます:
ipv6-address/prefix-length
接頭語ipv6-アドレス/長さ
where
どこ
ipv6-address is an IPv6 address in any of the notations listed
in Section 2.2.
ipv6-アドレスはIPv6アドレスですセクション2.2に記載された記法のどんなも。
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 20010DB80000CD3 (hexadecimal):
例えば、↓これは60ビットの接頭語20010DB80000CD3(16進)の法的な表現です:
2001:0DB8:0000:CD30:0000:0000:0000:0000/60
2001:0DB8::CD30:0:0:0:0/60
2001:0DB8:0:CD30::/60
2001:0DB8:0000:CD30:0000:0000:0000:0000/60 2001:0DB8:、:CD30: 0:0:0:0/60 2001:0DB8:0:CD30:、:/60
The following are NOT legal representations of the above prefix:
↓これは上の接頭語の法的な表現ではありません:
2001:0DB8:0:CD3/60 may drop leading zeros, but not trailing
zeros, within any 16-bit chunk of the address
2001: 0DB8:0:CD3/60はアドレスのどんな16ビットの塊の中でも末尾のゼロではなく、先行ゼロを下げるかもしれません。
2001:0DB8::CD30/60 address to left of "/" expands to
2001:0DB8:0000:0000:0000:0000:0000:CD30
2001 : 0DB8:、:「」 /の左へのCD30/60アドレス」は: 0DB8を2001に広げます:、0000:0000:0000、0000:0000:: CD30
2001:0DB8::CD3/60 address to left of "/" expands to
2001:0DB8:0000:0000:0000:0000:0000:0CD3
2001 : 0DB8:、:「」 /の左へのCD3/60アドレス」は: 0DB8を2001に広げます:、0000:0000:0000、0000:0000:: 0CD3
Hinden Standards Track [Page 5] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[5ページ]RFC4291IPv6
When writing both a node address and a prefix of that node address (e.g., the node's subnet prefix), the two can be combined as follows:
ノードアドレスとそのノードアドレスの接頭語の両方(例えば、ノードのサブネット接頭語)を書くとき、以下の通り2を結合できます:
the node address 2001:0DB8:0:CD30:123:4567:89AB:CDEF
and its subnet number 2001:0DB8:0:CD30::/60
ノードアドレス2001: 0DB8:0:CD30: 123:4567:89AB: サブネットNo.2001: CDEFと0DB8:0:CD30:、:/60
can be abbreviated as 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60
2001:0DB8:0:CD30:123:4567:89AB: CDEF/60を簡略化できます。
2.4. Address Type Identification
2.4. アドレスタイプ確認
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
Global Unicast (everything else)
アドレスタイプBinary接頭語IPv6記法セクション------------ ------------- ------------- ------- 不特定の00…0 (128ビット):、:/128 2.5.2ループバック00…1 (128ビット):、:1/128 2.5.3 マルチキャスト11111111FF00:、:/8 2.7リンクローカルユニキャスト1111111010FE80:、:/10 2.5の.6のグローバルなユニキャスト(他の何もかも)
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 that contain embedded IPv4 addresses (for the purposes of IPv4-IPv6 interoperation) are described in Section 2.5.5.
Global Unicastアドレスの一般形式はセクション2.5.4で説明されます。 埋め込まれたIPv4アドレス(IPv4-IPv6 interoperationの目的のための)を含むGlobal Unicastアドレスの何らかの専用血液型亜型がセクション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.
将来の仕様は他の目的のためにGlobal Unicastスペースの1つ以上のサブ範囲を再定義するかもしれませんが、それが起こるまで、実装はGlobal Unicastアドレスとして上で記載された接頭語のいずれからも始まらないすべてのアドレスを扱わなければなりません。
2.5. Unicast Addresses
2.5. ユニキャストアドレス
IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing.
IPv6ユニキャストアドレスは、任意のビット-長さの接頭語で「集合-可能」であって、IPv4アドレスとClassless Inter-ドメインルート設定で同様です。
There are several types of unicast addresses in IPv6, in particular, Global Unicast, site-local unicast (deprecated, see Section 2.5.7), and Link-Local unicast. There are also some special-purpose subtypes of Global Unicast, such as IPv6 addresses with embedded IPv4 addresses. Additional address types or subtypes can be defined in the future.
特にIPv6、Global Unicast、サイト地方のユニキャスト(推奨しないです、セクション2.5.7を見る)、およびLink地方のユニキャストにはいくつかのタイプのユニキャストアドレスがあります。 あります、また、IPv6などのGlobal Unicastの何らかの専用血液型亜型が埋め込まれたIPv4と共にアドレスを扱います。 将来、追加アドレスタイプか血液型亜型を定義できます。
Hinden Standards Track [Page 6] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[6ページ]RFC4291IPv6
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 | +-----------------------------------------------------------------+
| 128ビット| +-----------------------------------------------------------------+ | ノードアドレス| +-----------------------------------------------------------------+
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のための異価を持っているかもしれません)。
| n bits | 128-n bits | +-------------------------------+---------------------------------+ | subnet prefix | interface ID | +-------------------------------+---------------------------------+
| nビット| 128-nビット| +-------------------------------+---------------------------------+ | サブネット接頭語| インタフェース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つ以上に関する知識があるでしょう。 ルータがルーティング階層構造でどんな位置を保持するかによって、知られている境界はルータからルータまで異なるでしょう。
Except for the knowledge of the subnet boundary discussed in the previous paragraphs, nodes should not make any assumptions about the structure of an IPv6 address.
前のパラグラフで議論したサブネット境界に関する知識以外に、ノードはIPv6アドレスの構造に関する少しの仮定もするはずがありません。
2.5.1. Interface Identifiers
2.5.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 local scope interface identifier and a Link-Local address may be created with a universal scope interface identifier.
インタフェース識別子のユニークさがIPv6アドレスのユニークさから独立していることに注意してください。 例えば、Global Unicastアドレスはローカルの範囲インタフェース識別子で作成されるかもしれません、そして、Link-ローカルアドレスは普遍的な範囲インタフェース識別子で作成されるかもしれません。
Hinden Standards Track [Page 7] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[7ページ]RFC4291IPv6
For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format.
2進の値000から始まるもの以外のすべてのユニキャストアドレスにおいて、Interface IDが、長さ64ビットであり、Modified EUI-64形式で組み立てられるのに必要です。
Modified EUI-64 format-based interface identifiers may have universal scope when derived from a universal 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) or where global tokens are undesirable (e.g., temporary tokens for privacy [PRIV]).
変更されたEUI-64形式ベースのインタフェース識別子は、普遍的なトークン(例えば、IEEE802の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 universal 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用語の普遍的であるか地方のビット)を逆にすることによって、形成されます。 結果として起こるModified EUI-64形式では、1つ(1)に「u」ビットが普遍的な範囲を示すように設定されて、それが地方の範囲を示すために(0)のゼロに合うように設定されます。 IEEE EUI-64識別子のバイナリーにおける最初の3つの八重奏は以下の通りです:
0 0 0 1 1 2
|0 7 8 5 6 3|
+----+----+----+----+----+----+
|cccc|ccug|cccc|cccc|cccc|cccc|
+----+----+----+----+----+----+
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" is 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.
「g」が「u」が普遍的であるか地方のビットであることの個人/グループビットと、「c」であるとインターネット標準ビットオーダーに書かれているのは、会社_イドのビットです。 「変更されたEUI-64形式インタフェース識別子を作成し」て、付録AはModified 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 the case for serial links and tunnel end-points, for example. 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 0:0:0:1, 0:0:0:2, etc.
インタフェース識別子を形成するとき「u」ビットを逆にすることに関する動機はハードウェアトークンが利用可能でないときにシステム管理者が手で非グローバルな識別子を構成するのを簡単にすることです。 これは連続のリンクと例えば、トンネルエンドポイントのためのケースであると予想されます。 はるかに簡単の代わりになど代替手段がこれらが行ったことであることがあるだろう、フォームがあるように0:1、0200:0:0:2、0200:0:0:1、0:0:0:2、0:0:など
IPv6 nodes are not required to validate that interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique.
IPv6ノードはそのインタフェースを有効にするのが必要でないことで、普遍的に設定された「u」ビットがある変更されたEUI-64トークンで作成された識別子がユニークであるということです。
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 universal scope.
Modified EUI-64形式IDにおける普遍的であるか地方のビットの使用は普遍的な範囲でインタフェース識別子を利用できる未来の技術の開発を許すことです。
Hinden Standards Track [Page 8] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[8ページ]RFC4291IPv6
The details of forming interface identifiers are defined in the appropriate "IPv6 over <link>" specification, such as "IPv6 over Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI].
形成インタフェース識別子の詳細は適切な「<リンク>の上のIPv6」仕様に基づき定義されます、「イーサネットの上のIPv6」[ETHER]や、「FDDIの上のIPv6」[FDDI]などのように。
2.5.2. The Unspecified Address
2.5.2. 不特定のアドレス
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パケットのSource Address分野にもあります。
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パケットを決して進めてはいけません。
2.5.3. The Loopback Address
2.5.3. ループバックアドレス
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 must not be assigned to any physical interface. It is treated as having Link-Local scope, and may be thought of as the Link-Local unicast address of a virtual interface (typically called the "loopback interface") to an imaginary link that goes nowhere.
ユニキャストアドレス、0:0:、0:0:0、:、0:0:1、ループバックアドレスと呼ばれます。 それはノードによって使用されて、IPv6パケットをそれ自体に送るかもしれません。 どんな物理インターフェースにもそれを割り当ててはいけません。 それは、Link地方の範囲を持っているとして扱われて、仮想インターフェース(通常「ループバックインタフェース」と呼ばれる)のLinkローカルのユニキャストアドレスとしてどこにも行かない想像するリンクに考えられるかもしれません。
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 a destination address of loopback must be dropped.
ソースアドレスとしてただ一つのノードの外に送られるIPv6パケットでループバックアドレスを使用してはいけません。 ループバックの送付先アドレスがあるIPv6パケットをただ一つのノードの外に決して送ってはいけなくて、IPv6ルータは決して送ってはいけません。 ループバックの送付先アドレスとのインタフェースに受け取られたパケットを下げなければなりません。
2.5.4. Global Unicast Addresses
2.5.4. グローバルなユニキャストアドレス
The general format for IPv6 Global Unicast addresses is as follows:
IPv6 Global Unicastアドレスのための一般形式は以下の通りです:
| n bits | m bits | 128-n-m bits | +------------------------+-----------+----------------------------+ | global routing prefix | subnet ID | interface ID | +------------------------+-----------+----------------------------+
| nビット| mビット| 128-n-mビット| +------------------------+-----------+----------------------------+ | グローバルなルーティング接頭語| サブネットID| インタフェース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で定義されるようにあります。
Hinden Standards Track [Page 9] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[9ページ]RFC4291IPv6
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.
2進の000から始まるもの以外のすべてのGlobal Unicastアドレスには、セクション2.5.1で説明されるようにフォーマットされた64ビットのインタフェースID分野(すなわち、n+m=64)があります。 2進の000から始まるグローバルなUnicastアドレスがインタフェース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. 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 [GLOBAL].
2進の000から始まるGlobal Unicastアドレスに関する例は埋め込まれたIPv4アドレスがセクション2.5.5で説明されているIPv6アドレスです。 [GLOBAL]で000(したがって、64ビットのインタフェースID分野を持っていて)以外の2進の値から始まるグローバルなアドレスに関する例は見つけることができます。
2.5.5. IPv6 Addresses with Embedded IPv4 Addresses
2.5.5. IPv6は埋め込まれたIPv4と共にアドレスを扱います。
Two types of IPv6 addresses are defined that carry an IPv4 address in the low-order 32 bits of the address. These are the "IPv4-Compatible IPv6 address" and the "IPv4-mapped IPv6 address".
アドレスの下位の32ビットのIPv4アドレスを載せる2つのタイプのIPv6アドレスが定義されます。 これらは、「IPv4コンパチブルIPv6アドレス」と「IPv4によって写像されたIPv6アドレス」です。
2.5.5.1. IPv4-Compatible IPv6 Address
2.5.5.1. IPv4コンパチブルIPv6アドレス
The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6 transition. The format of the "IPv4-Compatible IPv6 address" is as follows:
「IPv4コンパチブルIPv6アドレス」は、IPv6変遷を助けるために定義されました。 「IPv4コンパチブルIPv6アドレス」の形式は以下の通りです:
| 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+
| 80ビット| 16 | 32ビット| +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4アドレス| +--------------------------------------+----+---------------------+
Note: The IPv4 address used in the "IPv4-Compatible IPv6 address" must be a globally-unique IPv4 unicast address.
以下に注意してください。 「IPv4コンパチブルIPv6アドレス」で使用されるIPv4アドレスはグローバルにユニークなIPv4ユニキャストアドレスであるに違いありません。
The "IPv4-Compatible IPv6 address" is now deprecated because the current IPv6 transition mechanisms no longer use these addresses. New or updated implementations are not required to support this address type.
現在のIPv6変遷メカニズムがもうこれらのアドレスを使用しないので、「IPv4コンパチブルIPv6アドレス」は現在、推奨しないです。 新しいかアップデートされた実装は、このアドレスがタイプであるとサポートするのに必要ではありません。
2.5.5.2. IPv4-Mapped IPv6 Address
2.5.5.2. IPv4によって写像されたIPv6アドレス
A second type of IPv6 address that holds an embedded IPv4 address is defined. This address type is used to represent the addresses of IPv4 nodes as IPv6 addresses. The format of the "IPv4-mapped IPv6 address" is as follows:
埋め込まれたIPv4アドレスを保持する2番目のタイプのIPv6アドレスが定義されます。 このアドレスタイプは、IPv6アドレスとしてIPv4ノードのアドレスを表すのに使用されます。 「IPv4によって写像されたIPv6アドレス」の形式は以下の通りです:
Hinden Standards Track [Page 10] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[10ページ]RFC4291IPv6
| 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+
| 80ビット| 16 | 32ビット| +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4アドレス| +--------------------------------------+----+---------------------+
See [RFC4038] for background on the usage of the "IPv4-mapped IPv6 address".
「IPv4によって写像されたIPv6アドレス」の用法でバックグラウンドに関して[RFC4038]を見てください。
2.5.6. Link-Local IPv6 Unicast Addresses
2.5.6. リンクローカルのIPv6ユニキャストアドレス
Link-Local addresses are for use on a single link. Link-Local addresses have the following format:
リンクローカルのアドレスは単一のリンクにおける使用のためのものです。 リンクローカルのアドレスには、以下の形式があります:
| 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+
| 10 | | ビット| 54ビット| 64ビット| +----------+-------------------------+----------------------------+ |1111111010| 0 | インタフェースID| +----------+-------------------------+----------------------------+
Link-Local addresses are designed to be used for addressing on a single link for purposes such as automatic address configuration, neighbor discovery, or when no routers are present.
リンクローカルのアドレスは、自動アドレス構成、隣人発見などの目的かそれともどんなルータもいつ存在していないか間、アドレシングに単一のリンクの上に使用されるように設計されています。
Routers must not forward any packets with Link-Local source or destination addresses to other links.
ルータはLink-地元筋か送付先アドレスがあるどんなパケットも他のリンクに送ってはいけません。
2.5.7. Site-Local IPv6 Unicast Addresses
2.5.7. サイトローカルのIPv6ユニキャストアドレス
Site-Local addresses were originally designed to be used for addressing inside of a site without the need for a global prefix. Site-local addresses are now deprecated as defined in [SLDEP].
サイトローカルのアドレスは、元々、グローバルな接頭語の必要性なしでサイトの内部を扱うのに使用されるように設計されました。 サイトローカルのアドレスは現在、[SLDEP]で定義されるように推奨しないです。
Site-Local addresses have the following format:
サイトローカルのアドレスには、以下の形式があります:
| 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111011| subnet ID | interface ID | +----------+-------------------------+----------------------------+
| 10 | | ビット| 54ビット| 64ビット| +----------+-------------------------+----------------------------+ |1111111011| サブネットID| インタフェースID| +----------+-------------------------+----------------------------+
The special behavior of this prefix defined in [RFC3513] must no longer be supported in new implementations (i.e., new implementations must treat this prefix as Global Unicast).
もう新しい実装で[RFC3513]で定義されたこの接頭語の特別な振舞いをサポートしてはいけません(すなわち、新しい実装はこの接頭語をGlobal Unicastとして扱わなければなりません)。
Existing implementations and deployments may continue to use this prefix.
既存の実装と展開は、この接頭語を使用し続けるかもしれません。
Hinden Standards Track [Page 11] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[11ページ]RFC4291IPv6
2.6. Anycast Addresses
2.6. Anycastアドレス
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アドレスが1つ以上のインタフェースに割り当てられるアドレス(異なったノードに通常属して)である、特性で、パケットがanycastアドレスに発信したのはそのアドレスを持っている“nearest"インタフェースに発送されます、ルーティング・プロトコルの距離の基準に従って。
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アドレスはユニキャストアドレスからシンタクス上区別がつきません。 ユニキャストアドレスが1つ以上のインタフェースに割り当てられて、その結果、それを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アドレスのためにも、そのanycastアドレスに属すすべてのインタフェースが住んでいる位相的な領域を特定するそのアドレスの最も長い接頭語Pがあります。 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.
最悪の場合には、1つのanycastセットの接頭語Pがヌル接頭語であるかもしれないというメモ、すなわち、セットのメンバーには、どんな位相的な場所もないかもしれません。 その場合、別々のルーティングエントリーとして全体のインターネット中でanycastアドレスを維持しなければなりません。そのような「グローバルな」anycastセットがいくつに支えられるかもしれないかに関してインターネットは厳しいスケーリング限界を提示します。 したがって、グローバルな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アドレスの使用が組織提供インターネットのサービスに属すルータのセットを特定することであると予想しました。 パケットがサービスプロバイダーの特定のサービスプロバイダーか系列で提供されることを引き起こすのに中間的アドレスとして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.
ある他の可能な用途は特定のサブネットに付けられたルータのセット、または特定の経路ドメインにエントリーを提供するルータのセットを特定することです。
2.6.1. Required Anycast Address
2.6.1. 必要なAnycastアドレス
The Subnet-Router anycast address is predefined. Its format is as follows:
Subnet-ルータanycastアドレスは事前に定義されます。 形式は以下の通りです:
Hinden Standards Track [Page 12] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[12ページ]RFC4291IPv6
| n bits | 128-n bits | +------------------------------------------------+----------------+ | subnet prefix | 00000000000000 | +------------------------------------------------+----------------+
| nビット| 128-nビット| +------------------------------------------------+----------------+ | サブネット接頭語| 00000000000000 | +------------------------------------------------+----------------+
The "subnet prefix" in an anycast address is the prefix that 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.
Subnet-ルータanycastアドレスに送られたパケットはサブネットで1つのルータに提供されるでしょう。 すべてのルータが、Subnet-ルータがそれらがインタフェースを持っているサブネットのための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.
ノードがルータのセットのどれかとコミュニケートする必要があるアプリケーションにSubnet-ルータanycastアドレスが使用されることを意図します。
2.7. Multicast Addresses
2.7. マルチキャストアドレス
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 | +--------+----+----+---------------------------------------------+
| 8 | 4 | 4 | 112ビット| +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| グループID| +--------+----+----+---------------------------------------------+
binary 11111111 at the start of the address identifies the address
as being a multicast address.
アドレスの始めの2進の11111111はマルチキャストアドレスであるとしてアドレスを特定します。
+-+-+-+-+
flgs is a set of 4 flags: |0|R|P|T|
+-+-+-+-+
+++++flgsは4個の旗のセットです: |0|R|P|T| +-+-+-+-+
The high-order flag is reserved, and must be initialized to 0.
高位旗を予約されていて、0に初期化しなければなりません。
T = 0 indicates a permanently-assigned ("well-known") multicast
address, assigned by the Internet Assigned Numbers Authority
(IANA).
T=0はインターネットAssigned民数記Authority(IANA)によって割り当てられた永久に割り当てられた(「よく知られる」)マルチキャストアドレスを示します。
T = 1 indicates a non-permanently-assigned ("transient" or
"dynamically" assigned) multicast address.
T=1は非永久に割り当てられた(「一時的である」か「ダイナミックに」割り当てられた)マルチキャストアドレスを示します。
Hinden Standards Track [Page 13] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[13ページ]RFC4291IPv6
The P flag's definition and usage can be found in [RFC3306].
[RFC3306]でP旗の定義と用法を見つけることができます。
The R flag's definition and usage can be found in [RFC3956].
[RFC3956]でR旗の定義と用法を見つけることができます。
scop is a 4-bit multicast scope value used to limit the scope of
the multicast group. The values are as follows:
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 (割り当てられません)B(割り当てられない)C(割り当てられない)D(割り当てられない)E Global範囲Fあたり9(割り当てられない)のOrganization地方の範囲が予約した1予約されたInterface地方の範囲2のLink地方の範囲3予約された4Admin地方の範囲5のSite地方の範囲6(割り当てられません)7(割り当てられない)8
Interface-Local scope spans only a single interface on a node
and is useful only for loopback transmission of multicast.
インタフェース地方の範囲は、ノードの上で単一のインタフェースだけにかかっていて、マルチキャストのループバック送信だけの役に立ちます。
Link-Local multicast scope spans the same topological region as
the corresponding unicast scope.
リンク地方のマルチキャスト範囲は対応するユニキャスト範囲と同じ位相的な領域にかかっています。
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.
アドミン地方の範囲はすなわち、行政上構成されたか、物理的な接続性から自動的に派生しなかったか、または他であるに違いない最も小さい範囲です、非マルチキャスト関連の構成。
Site-Local scope is intended to span a single site.
サイト地方の範囲がただ一つのサイトにかかることを意図します。
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. Additional definitions of the
multicast group ID field structure are provided in [RFC3306].
グループIDは与えられた範囲の中で永久的であるか一時的なマルチキャストグループを特定します。 マルチキャストグループID磁場構造の追加定義を[RFC3306]に提供します。
Hinden Standards Track [Page 14] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[14ページ]RFC4291IPv6
The "meaning" of a permanently-assigned multicast address is independent of the scope value. For example, if the "NTP servers group" is assigned a permanent multicast address with a group ID of 101 (hex), then
永久に割り当てられたマルチキャストアドレスの「意味」は範囲価値から独立しています。 例えば、永久的なマルチキャストが「NTPサーバグループ」に割り当てられるなら、グループと共に101(魔法をかける)のIDを扱ってください、そして
FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
(i.e., the same node) as the sender.
FF01:、0:、0:0:0、:、0:0:101、送付者として同じインタフェースのすべてのNTPサーバ(すなわち、同じノード)を意味します。
FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
sender.
FF02:、0:、0:0:0、:、0:0:101、送付者と同じリンクの上のすべてのNTPサーバを意味します。
FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the
sender.
FF05:、0:、0:0:0、:、0:0:101、送付者と同じサイトのすべてのNTPサーバを意味します。
FF0E:0:0:0:0:0:0:101 means all NTP servers in the Internet.
FF0E:、0:、0:0:0、:、0:0:101、インターネットのすべてのNTPサーバを意味します。
Non-permanently-assigned multicast addresses are meaningful only within a given scope. For example, a group identified by the non- permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one site bears no relationship to a group using the same address at a different site, nor to a non-permanent group using the same group ID with a different scope, nor to a permanent group with the same group ID.
非永久に割り当てられたマルチキャストアドレスは与えられた範囲だけの中で重要です。 例えば、非永久的で、サイト地方のマルチキャストによって特定されたグループはFF15を扱います:、0:、0:0:0、:、0:0:101、サイトは、1時に同じグループIDと共に異なった範囲と、永久的なグループへの同じグループIDを使用しながら、異なったサイトにおいて非永久的なグループに同じアドレスを使用することでグループとの関係を全く産出しません。
Multicast addresses must not be used as source addresses in IPv6 packets or appear in any Routing header.
マルチキャストアドレスは、ソースアドレスとしてIPv6パケットで使用されてはいけませんし、またどんなルート設定ヘッダーにも現れてはいけません。
Routers must not forward any multicast packets beyond of the scope indicated by the scop field in the destination multicast address.
ルータは送付先マルチキャストアドレスのscop分野によって示された範囲について向こうのどんなマルチキャストパケットも進めてはいけません。
Nodes must not originate a packet to a multicast address whose scop field contains the reserved value 0; if such a packet is received, it must be silently dropped. Nodes should not originate a packet to a multicast address whose scop field contains the reserved value F; if such a packet is sent or received, it must be treated the same as packets destined to a global (scop E) multicast address.
ノードはscop分野が予約された値0を含むマルチキャストアドレスにパケットを溯源してはいけません。 そのようなパケットが受け取られているなら、静かにそれを下げなければなりません。 ノードはscop分野が予約された値Fを含むマルチキャストアドレスにパケットを溯源するはずがありません。 そのようなパケットを送るか、または受け取るなら、同じようにグローバルな(scop E)マルチキャストアドレスに運命づけられたパケットとしてそれを扱わなければなりません。
2.7.1. Pre-Defined Multicast Addresses
2.7.1. 事前に定義されたマルチキャストアドレス
The following well-known multicast addresses are pre-defined. The group IDs defined in this section are defined for explicit scope values.
以下のよく知られるマルチキャストアドレスは事前に定義されます。 このセクションで定義されたグループIDは明白な範囲値のために定義されます。
Use of these group IDs for any other scope values, with the T flag equal to 0, is not allowed.
0と等しいT旗で、これらのグループIDのいかなる他の範囲値の使用も許されていません。
Hinden Standards Track [Page 15] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[15ページ]RFC4291IPv6
Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0
FF01:0:0:0:0:0:0:0
FF02:0:0:0:0:0:0:0
FF03:0:0:0:0:0:0:0
FF04:0:0:0:0:0:0:0
FF05:0:0:0:0:0:0:0
FF06:0:0:0:0:0:0:0
FF07:0:0:0:0:0:0:0
FF08:0:0:0:0:0:0:0
FF09:0:0:0:0:0:0:0
FF0A:0:0:0:0:0:0:0
FF0B:0:0:0:0:0:0:0
FF0C:0:0:0:0:0:0:0
FF0D:0:0:0:0:0:0:0
FF0E:0:0:0:0:0:0:0
FF0F:0:0:0:0:0:0:0
予約されたマルチキャストアドレス: FF00:0:0:0:0:0:0:0 FF01:0:0:0:0:0:0:0 FF02:0:0:0:0:0:0:0 FF03:0:0:0:0:0:0:0 FF04:0:0:0:0:0:0:0 FF05:0:0:0:0:0:0:0 FF06:0:0:0:0:0:0:0 FF07:0:0:0:0:0:0:0 FF08:0:0:0:0:0:0:0 FF09:0:0:0:0:0:0:0 FF0A:0:0:0:0:0:0:0 FF0B:0:0:0:0:0:0:0 FF0C:0:0:0:0:0:0:0 FF0D:0:0:0:0:0:0:0 FF0E:0:0:0:0:0:0:0 FF0F:0:0:0:0:0:0:0
The above multicast addresses are reserved and shall never be assigned to any multicast group.
上のマルチキャストアドレスは、予約されていて、どんなマルチキャストグループにも決して配属されないものとします。
All Nodes Addresses: FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1
すべてのノードアドレス: FF01:、0:、0:0:0、:、0:0:1、FF02:、0:、0:0:0、:、0:0:1
The above multicast addresses identify the group of all IPv6 nodes, within scope 1 (interface-local) or 2 (link-local).
上のマルチキャストアドレスは範囲1(インタフェース地方の)か2(リンク地方の)の中ですべてのIPv6ノードのグループを特定します。
All Routers Addresses: FF01:0:0:0:0:0:0:2
FF02:0:0:0:0:0:0:2
FF05:0:0:0:0:0:0:2
すべてのルータアドレス: 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
請求されたノードアドレス: 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
請求されたノードマルチキャストアドレスはノードのユニキャストとanycastアドレスの機能として計算されます。 Solicited-ノードマルチキャストアドレスはアドレス(ユニキャストかanycast)の下位の24ビット取って、それらのビットを接頭語FF02に追加することによって、形成されます:、0:0:1 0:0::FF00、:、:範囲でマルチキャストアドレスをもたらす/104
FF02:0:0:0:0:1:FF00:0000
FF02: 0:0:0:0:1:FF00:0000
to
to
FF02:0:0:0:0:1:FFFF:FFFF
FF02: 0:0:0:0:1:FFFF:FFFF
Hinden Standards Track [Page 16] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[16ページ]RFC4291IPv6
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に対応するSolicited-ノードマルチキャストアドレス:、:01:800:200E: 8C6CはFF02です:、:1:FF0E:8C6C。 その結果、ビット(例えば、異なった集合に関連している複数の高位接頭語による)が同じSolicited-ノードアドレスに写像する高位だけにおいて異なるIPv6アドレス、ノードは接合して、マルチキャストアドレスの数を減少させなければなりません。
A node is required to compute and join (on the appropriate interface) the associated Solicited-Node multicast addresses for all unicast and anycast addresses that have been configured for the node's interfaces (manually or automatically).
ノードが、ノードのインタフェース(手動か自動的である)に構成されたすべてのユニキャストとanycastアドレスのための関連Solicited-ノードマルチキャストアドレスを計算して、接合すること(適切なインタフェースで)に必要です。
2.8. A Node's Required Addresses
2.8. ノードの必要なアドレス
A host is required to recognize the following addresses as identifying itself:
ホストがそれ自体を特定すると以下のアドレスを認識するのに必要です:
o Its required Link-Local address for each interface.
o 各インタフェースへの必要なLink-ローカルアドレス。
o Any additional Unicast and Anycast addresses that have been
configured for the node's interfaces (manually or
automatically).
o ノードのインタフェース(手動か自動的である)に構成されたどんな追加UnicastとAnycastアドレス。
o The loopback address.
o ループバックアドレス。
o The All-Nodes multicast addresses defined in Section 2.7.1.
o セクション2.7.1で定義されたAll-ノードマルチキャストアドレス。
o The Solicited-Node multicast address for each of its unicast and
anycast addresses.
o それぞれのユニキャストとanycastアドレスのためのSolicited-ノードマルチキャストアドレス。
o Multicast addresses of all other groups to which the node
belongs.
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 Anycastがすべてのために扱うルータとして機能するのが構成されているSubnet-ルータは連結します。
o All other Anycast addresses with which the router has been
configured.
o ルータが構成された他のすべてのAnycastアドレス。
o The All-Routers multicast addresses defined in Section 2.7.1.
o セクション2.7.1で定義されたAll-ルータマルチキャストアドレス。
Hinden Standards Track [Page 17] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[17ページ]RFC4291IPv6
3. Security Considerations
3. セキュリティ問題
IPv6 addressing documents do not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined in [AUTH].
ドキュメントを扱うIPv6がインターネット基盤セキュリティに少しの直接的な衝撃も持っていません。 IPv6パケットの認証は[AUTH]で定義されます。
4. IANA Considerations
4. IANA問題
The "IPv4-Compatible IPv6 address" is deprecated by this document. The IANA should continue to list the address block containing these addresses at http://www.iana.org/assignments/ipv6-address-space as "Reserved by IETF" and not reassign it for any other purpose. For example:
「IPv4コンパチブルIPv6アドレス」はこのドキュメントで推奨しないです。 IANAは「IETFによって予約される」ように http://www.iana.org/assignments/ipv6-address-space にこれらのアドレスを含むあて先ブロックをリストアップして、いかなる他の目的のためにもそれを再選任しなく続けているはずです。 例えば:
0000::/8 Reserved by IETF [RFC3513] [1]
0000::IETF[RFC3513]によって予約された/8[1]
The IANA has added the following note and link to this address block.
IANAは以下の注意とリンクをこのあて先ブロックに追加しました。
[5] 0000::/96 was previously defined as the "IPv4-Compatible IPv6
address" prefix. This definition has been deprecated by RFC
4291.
[5] 0000::/96は以前に、「IPv4コンパチブルIPv6アドレス」接頭語と定義されました。 この定義はRFC4291で推奨しないです。
The IANA has updated the references for the IPv6 Address Architecture in the IANA registries accordingly.
IANAはそれに従って、IANA登録のIPv6 Address Architectureの参照をアップデートしました。
5. Acknowledgements
5. 承認
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, Larry Masinter, Jun-ichiro Itojun Hagino, Tatuya Jinmei, Suresh Krishnan, and Mahmood Ali.
作者はポール・フランシス、スコット・ブラドナー、ジムBound、ブライアンCarpenter、マット・クロフォード、デボラEstrin、ロジャーFajman、ボブFink、ピーター・フォード、ボブ・ギリガン、ドミトリー・ハスキン、トムHarsch、クリスチャンのHuitema、トニー・李、グレッグMinshall、トーマスNarten、エリックNordmark、ヤコフRekhter、ビル・シンプソン、スー・トムソン、マルックSavela、ラリーMasinter、6月-ichiro Itojun Hagino、Tatuya Jinmei、Sureshクリシュナン、およびMahmoodアリの貢献を承諾したがっています。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
6.2. Informative References
6.2. 有益な参照
[AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[AUTH] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
Hinden Standards Track [Page 18] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[18ページ]RFC4291IPv6
[CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[CIDR] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[エーテル] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、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] クロフォード、M.、「FDDIネットワークの上のIPv6パケットのトランスミッション」、RFC2467、1998年12月。
[GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[グローバルな] HindenとR.とデアリング、S.とE.Nordmark、「IPv6のグローバルなユニキャストアドレス形式」、RFC3587、2003年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"での状態がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2005.
[RFC3513]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2005年4月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC3306] ハーバーマンとB.とD.ターレル、「ユニキャスト接頭語ベースのIPv6マルチキャストアドレス」、RFC3306、2002年8月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point
(RP) Address in an IPv6 Multicast Address", RFC 3956,
November 2004.
[RFC3956] Savola、P.、およびB.ハーバーマン、「ランデブーポイント(RP)を埋め込んで、IPv6でマルチキャストアドレスを扱ってください」、RFC3956、2004年11月。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition", RFC 4038,
March 2005.
[RFC4038]はよじ登ります、M K.、商館、Y-G.、Hagino、J.、Savola、P.とE.カストロ、「IPv6変遷のアプリケーション局面」RFC4038、2005年3月。
[SLDEP] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[SLDEP] Huitema、C.、およびB.は2004年9月に「サイトのローカルのアドレスを非難すること」でのRFC3879の大工仕事をします。
Hinden Standards Track [Page 19] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[19ページ]RFC4291IPv6
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.
特定のリンクかノードの特性によって、Modified 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. An example is a globally unique IEEE EUI-64 identifier of the form:
IEEE EUI-64識別子をインタフェース識別子に変えるのに必要である唯一の変化が「u」(普遍的であるか地方)のビットを逆にすることになっています。 例はフォームのグローバルにユニークなIEEE EUI-64識別子です:
|0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+
|0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+
where "c" is the bits of the assigned company_id, "0" is the value of the universal/local bit to indicate universal scope, "g" is individual/group bit, and "m" is the bits of the manufacturer- selected extension identifier. The IPv6 interface identifier would be of the form:
「c」が割り当てられた会社_イドのビットであり、「0インチは普遍的な範囲を示す普遍的であるか地方のビットの価値です、そして、「g」は個人/グループビットです、そして、「m」はメーカーの選択された拡大識別子のビットである」ところ。 IPv6インタフェース識別子はフォームのものでしょう:
|0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+
|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 MACs
IEEE802の48ビットのMACsとのリンクかノード
[EUI64] defines a method to create an IEEE EUI-64 identifier from an IEEE 48-bit MAC identifier. This is to insert two octets, with hexadecimal values of 0xFF and 0xFE (see the Note at the end of appendix), in the middle of the 48-bit MAC (between the company_id and vendor-supplied id). An example is the 48-bit IEEE MAC with Global scope:
[EUI64]はIEEEの48ビットのMAC識別子からIEEE EUI-64識別子を作成するメソッドを定義します。 これは0xFFと0xFEの16進値で2つの八重奏を挿入する(付録の端でNoteを見る)ためのものです、48ビットのMAC(会社_イドとベンダーによって供給されたイドの間の)の中央で。 例はGlobal範囲がある48ビットのIEEE MACです:
|0 1|1 3|3 4| |0 5|6 1|2 7| +----------------+----------------+----------------+ |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+
|0 1|1 3|3 4| |0 5|6 1|2 7| +----------------+----------------+----------------+ |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+
Hinden Standards Track [Page 20] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[20ページ]RFC4291IPv6
where "c" is 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" is the bits of the manufacturer- selected extension identifier. The interface identifier would be of the form:
「c」が割り当てられた会社_イドのビットであり、「0インチはグローバルな範囲を示す普遍的であるか地方のビットの価値です、そして、「g」は個人/グループビットです、そして、「m」はメーカーの選択された拡大識別子のビットである」ところ。 インタフェース識別子はフォームのものでしょう:
|0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+
|0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+
When IEEE 802 48-bit 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.
IEEE802の48ビットのMACアドレスが利用可能であるときに(インタフェースかノードの)、実装は、それらの有用性とユニークさの特性のためインタフェース識別子を作成するのにそれらを使用するかもしれません。
Links with Other Kinds of Identifiers
他の種類に関する識別子とのリンク
There are a number of types of links that have link-layer interface identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples include LocalTalk and Arcnet. The method to create a 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 EUI-64以外のリンクレイヤインタフェース識別子かIEEE802の48ビットのMACsを持っている多くのタイプのリンクがあります。 例はLocalTalkとArcnetを含んでいます。 Modified EUI-64形式IDを作成するメソッドがリンク識別子(例えば、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| +----------------+----------------+----------------+----------------+
|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 that are unique within a subnet prefix must be chosen.
どんなタイプの内蔵の識別子も持っていない多くのリンクがあります。 最も一般的なこれらは、連続のリンクと構成されたトンネルです。 サブネット接頭語の中でユニークなインタフェース識別子を選ばなければなりません。
When no built-in identifier is available on a link, the preferred approach is to use a universal interface identifier from another interface or one that 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.
どんな内蔵の識別子もリンクで利用可能でないときに、好ましい方法は別のインタフェースか割り当てられるものからノード自体まで普遍的なインタフェース識別子を使用することです。 このアプローチを使用するとき、同じサブネット接頭語に同じノードを接続する他のどんなインタフェースも同じ識別子を使用してはいけません。
Hinden Standards Track [Page 21] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[21ページ]RFC4291IPv6
If there is no universal 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 the following:
リンクの上に使用に利用可能などんな普遍的なインタフェース識別子もなければ、実装は、地方の範囲インタフェース識別子を作成する必要があります。 唯一の要件はそれがサブネット接頭語の中でユニークであるということです。 aを選択するために多くの可能なアプローチがある、サブネット接頭語ユニークである、インタフェース識別子。 これらは以下を含んでいます:
Manual Configuration
Node Serial Number
Other Node-Specific Token
手動の構成ノード通し番号他のノード特有のトークン
The subnet-prefix-unique interface identifier should be generated in a manner such 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」仕様に基づき定義されます。 衝突検出アルゴリズムがどんな自動アルゴリズムの一部としても実装されることが強く勧められます。
Note: [EUI-64] actually defines 0xFF and 0xFF as the bits to be
inserted to create an IEEE EUI-64 identifier from an IEEE MAC-
48 identifier. The 0xFF and 0xFE values are used when starting
with an IEEE EUI-48 identifier. The incorrect value was used
in earlier versions of the specification due to a
misunderstanding about the differences between IEEE MAC-48 and
EUI-48 identifiers.
以下に注意してください。 [EUI-64]は、IEEE MAC48識別子からIEEE EUI-64識別子を作成するために挿入されるために実際に0xFFと0xFFをビットと定義します。 IEEE EUI-48識別子から始まるとき、0xFFと0xFE値は使用されています。 不正確な値はIEEE MAC-48とEUI-48識別子の違いに関する誤解のため仕様の以前のバージョンで使用されました。
This document purposely continues the use of 0xFF and 0xFE
because it meets the requirements for IPv6 interface
identifiers (i.e., that they must be unique on the link), IEEE
EUI-48 and MAC-48 identifiers are syntactically equivalent, and
that it doesn't cause any problems in practice.
このドキュメントがIPv6インタフェース識別子のために条件を満たすのでわざわざ0xFFと0xFEの使用を続けている、(すなわち、彼らはリンクでユニークであるに違いありません)、IEEE EUI-48とMAC-48識別子はシンタクス上同等であり、それは実際にはどんな問題も引き起こしません。
Appendix B: Changes from RFC 3513
付録B: RFC3513からの変化
The following changes were made from RFC 3513, "IP Version 6 Addressing Architecture":
「IPバージョン6はアーキテクチャを扱っ」て、以下の変更はRFC3513から行われました:
o The restrictions on using IPv6 anycast addresses were removed
because there is now sufficient experience with the use of anycast
addresses, the issues are not specific to IPv6, and the GROW
working group is working in this area.
o 現在、anycastアドレスの使用には十分な経験があるので、IPv6 anycastアドレスを使用するときの制限を取り除きました、そして、問題はIPv6に特定ではありません、そして、GROWワーキンググループはこの領域で働いています。
o Deprecated the Site-Local unicast prefix. Changes include the
following:
o 推奨しなさ、Siteローカルのユニキャスト接頭語。 変化は以下を含んでいます:
Hinden Standards Track [Page 22] RFC 4291 IPv6 Addressing Architecture February 2006
アーキテクチャ2月が2006であると扱うHinden標準化過程[22ページ]RFC4291IPv6
- Removed Site-Local from special list of prefixes in Section
2.4.
- セクション2.4の接頭語の特別なリストからSite地方で、取り外しました。
- Split section titled "Local-use IPv6 Unicast Addresses" into
two sections, "Link-Local IPv6 Unicast Addresses" and "Site-
Local IPv6 Unicast Addresses".
- 分裂部分は2つのセクションへの「地方の使用IPv6ユニキャストアドレス」、「リンクローカルのIPv6ユニキャストアドレス」、および「サイトのローカルのIPv6ユニキャストアドレス」を題をつけました。
- Added text to new section describing Site-Local deprecation.
- Site地方の不賛成について説明する新しいセクションにテキストを追加しました。
o Changes to resolve issues raised in IAB response to Robert Elz
appeal. Changes include the following:
o ロバートElzへのIAB応答で提起された問題を解決する変化は上告されます。 変化は以下を含んでいます:
- Added clarification to Section 2.5 that nodes should make no
assumptions about the structure of an IPv6 address.
- ノードがIPv6アドレスの構造に関する仮定を全くするはずがないセクション2.5に明確化を追加しました。
- Changed the text in Section 2.5.1 and Appendix A to refer to
the Modified EUI-64 format interface identifiers with the "u"
bit set to one (1) as universal.
- 「u」ビットがある識別子が普遍的であるとして1つ(1)に設定するModified EUI-64形式インタフェースについて言及するためにセクション2.5.1とAppendix Aのテキストを変えました。
- Added clarification to Section 2.5.1 that IPv6 nodes are not
required to validate that interface identifiers created in
Modified EUI-64 format with the "u" bit set to one are unique.
- IPv6ノードがセクション2.5.1への明確化ですが、加えられて、そのインタフェースを有効にするのが必要でないことで、1つに設定された「u」ビットでModified EUI-64形式で作成された識別子はユニークです。
o Changed the reference indicated in Section 2.5.4 "Global Unicast
Addresses" to RFC 3587.
o セクション2.5.4「グローバルなユニキャストアドレス」でRFC3587に示された参照を変えました。
o Removed mention of NSAP addresses in examples.
o 例における、NSAPアドレスの言及を取り除きました。
o Clarified that the "x" in the textual representation can be one to
four digits.
o はっきりさせられて、その原文の「x」表現は1〜4ケタであるかもしれません。
o Deprecated the "IPv6 Compatible Address" because it is not being
used in the IPv6 transition mechanisms.
o それがIPv6変遷メカニズムで使用されていないので、「IPv6コンパチブルアドレス」を非難しました。
o Added the "R" and "P" flags to Section 2.7 on multicast addresses,
and pointers to the documents that define them.
o 「R」と「P」旗がマルチキャストアドレスのセクション2.7に追加されて、ポインタはそれらを定義するドキュメントに追加されました。
o Editorial changes.
o 社説は変化します。
Hinden Standards Track [Page 23] RFC 4291 IPv6 Addressing Architecture February 2006
2006年2月に構造を記述するHinden標準化過程[23ページ]RFC4291IPv6
Authors' Addresses
作者のアドレス
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
ロバートM.Hindenノキア313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 625-2004 EMail: bob.hinden@nokia.com
以下に電話をしてください。 +1 650 625-2004 メールしてください: bob.hinden@nokia.com
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
西タスマン・DriveスティーブンE.デアリングシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)
Hinden Standards Track [Page 24] RFC 4291 IPv6 Addressing Architecture February 2006
2006年2月に構造を記述するHinden標準化過程[24ページ]RFC4291IPv6
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Hinden Standards Track [Page 25]
Hinden標準化過程[25ページ]
一覧
スポンサーリンク
