Network Working Group S. Deering
Request for Comments: 4007 Cisco Systems
Category: Standards Track B. Haberman
Johns Hopkins Univ
T. Jinmei
Toshiba
E. Nordmark
Sun Microsystems
B. Zill
Microsoft
March 2005
IPv6 Scoped Address Architecture
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses.
このドキュメントは、異なるスコープのIPv6アドレスのアーキテクチャ特性、予想される動作、テキスト表現、および使用法を指定します。 IPv6ワーキンググループの決定によると、このドキュメントでは、ユニキャストサイトローカルアドレスの構文と使用を意図的に避けています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Terminology . . . . . . . . . . . . . . . . . . . . . 3
4. Address Scope . . . . . . . . . . . . . . . . . . . . . . . 3
5. Scope Zones . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Zone Indices . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Sending Packets . . . . . . . . . . . . . . . . . . . . . . 11
8. Receiving Packets . . . . . . . . . . . . . . . . . . . . . 11
9. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. Textual Representation . . . . . . . . . . . . . . . . . . . 15
11.1. Non-Global Addresses . . . . . . . . . . . . . . . . 15
11.2. The <zone_id> Part. . . . . . . . . . . . . . . . . . 15
11.3. Examples. . . . . . . . . . . . . . . . . . . . . . . 17
11.4. Usage Examples. . . . . . . . . . . . . . . . . . . . 17
11.5. Related API . . . . . . . . . . . . . . . . . . . . . 18
11.6. Omitting Zone Indices . . . . . . . . . . . . . . . . 18
11.7. Combinations of Delimiter Characters. . . . . . . . . 18
12. Security Considerations . . . . . . . . . . . . . . . . . . 19
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
15.1. Normative References . . . . . . . . . . . . . . . . . 20
15.2. Informative References . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 24
Internet Protocol version 6 includes support for addresses of different "scope"; that is, both global and non-global (e.g., link-local) addresses. Although non-global addressing has been introduced operationally in the IPv4 Internet, both in the use of private address space ("net 10", etc.) and with administratively scoped multicast addresses, the design of IPv6 formally incorporates the notion of address scope into its base architecture. This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes.
インターネットプロトコルバージョン6には、異なる「スコープ」のアドレスのサポートが含まれています。 つまり、グローバルアドレスと非グローバルアドレス（リンクローカルなど）の両方です。 非グローバルアドレス指定は、プライベートアドレススペース（「ネット10」など）の使用と管理スコープのマルチキャストアドレスの両方で、IPv4インターネットで運用上導入されましたが、IPv6の設計では、アドレススコープの概念を正式に取り入れています その基本アーキテクチャ。 このドキュメントは、異なるスコープのIPv6アドレスのアーキテクチャ特性、予想される動作、テキスト表現、および使用法を指定します。
Though the current address architecture specification [1] defines unicast site-local addresses, the IPv6 working group decided to deprecate the syntax and the usage [5] and is now investigating other forms of local IPv6 addressing. The usage of any new forms of local addresses will be documented elsewhere in the future. Thus, this document intentionally focuses on link-local and multicast scopes only.
現在のアドレスアーキテクチャ仕様[1]はユニキャストサイトローカルアドレスを定義していますが、IPv6ワーキンググループは構文と使用法を廃止することを決定し[5]、現在ローカルIPv6アドレッシングの他の形式を調査しています。 ローカルアドレスの新しい形式の使用法は、将来のどこかで文書化されます。 したがって、このドキュメントでは、リンクローカルスコープとマルチキャストスコープのみに意図的に焦点を当てています。
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 [2].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は [2]で説明されているように解釈されます。
The terms link, interface, node, host, and router are defined in [3]. The definitions of unicast address scopes (link-local and global) and multicast address scopes (interface-local, link-local, etc.) are contained in [1].
リンク、インターフェース、ノード、ホスト、およびルーターという用語は、[3]で定義されています。 ユニキャストアドレススコープ（リンクローカルおよびグローバル）およびマルチキャストアドレススコープ（インターフェイスローカル、リンクローカルなど）の定義は[1]に含まれています。
Every IPv6 address other than the unspecified address has a specific scope; that is, a topological span within which the address may be used as a unique identifier for an interface or set of interfaces. The scope of an address is encoded as part of the address, as specified in [1].
指定されていないアドレス以外のすべてのIPv6アドレスには、特定のスコープがあります。 つまり、アドレスがインターフェイスまたはインターフェイスのセットの一意の識別子として使用されるトポロジスパンです。 [1]で指定されているように、アドレスの範囲はアドレスの一部としてエンコードされます。
For unicast addresses, this document discusses two defined scopes:
ユニキャストアドレスの場合、このドキュメントでは2つの定義されたスコープについて説明します。
o Link-local scope, for uniquely identifying interfaces within (i.e., attached to) a single link only.
oリンクローカルスコープ。単一のリンク内でのみ（つまり、接続されている）インターフェイスを一意に識別します。
o Global scope, for uniquely identifying interfaces anywhere in the Internet.
oインターネットの任意の場所でインターフェイスを一意に識別するためのグローバルスコープ。
The IPv6 unicast loopback address, ::1, is treated as having link-local scope within an imaginary link to which a virtual "loopback interface" is attached.
IPv6ユニキャストループバックアドレス:: 1は、仮想「ループバックインターフェイス」が接続されている仮想リンク内にリンクローカルスコープを持つものとして扱われます。
The unspecified address, ::, is a special case. It does not have any scope because it must never be assigned to any node according to [1]. Note, however, that an implementation might use an implementation dependent semantics for the unspecified address and may want to allow the unspecified address to have specific scopes. For example, implementations often use the unspecified address to represent "any" address in APIs. In this case, implementations may regard the unspecified address with a given particular scope as representing the notion of "any address in the scope". This document does not prohibit such a usage, as long as it is limited within the implementation.
指定されていないアドレス::は、特殊なケースです。 [1]に従ってどのノードにも割り当ててはならないため、スコープはありません。 ただし、実装では、指定されていないアドレスに対して実装依存のセマンティクスを使用する場合があり、指定されていないアドレスに特定のスコープを許可する場合があります。 たとえば、実装では、未指定のアドレスを使用して、APIの「任意の」アドレスを表すことがよくあります。 この場合、実装は、特定のスコープを持つ未指定のアドレスを「スコープ内の任意のアドレス」の概念を表すものと見なす場合があります。 このドキュメントでは、実装内で制限されている限り、このような使用を禁止していません。
[1] defines IPv6 addresses with embedded IPv4 addresses as being part of global addresses. Thus, those addresses have global scope, with regard to the IPv6 scoped address architecture. However, an implementation may use those addresses as if they had other scopes for convenience. For instance, [6] assigns link-local scope to IPv4 auto-configured link-local addresses (the addresses from the prefix 169.254.0.0/16 [7]) and converts those addresses into IPv4-mapped IPv6 addresses in order to perform destination address selection among IPv4 and IPv6 addresses. This would implicitly mean that the IPv4-mapped IPv6 addresses equivalent to the IPv4 auto-configuration link-local addresses have link-local scope. This document does not preclude such a usage, as long as it is limited within the implementation.
[1]は、グローバルアドレスの一部であるIPv4アドレスが埋め込まれたIPv6アドレスを定義します。 したがって、これらのアドレスには、IPv6スコープアドレスアーキテクチャに関してグローバルスコープがあります。 ただし、実装では、便宜上、他のスコープがあるかのようにこれらのアドレスを使用できます。 たとえば、[6]は、リンクローカルスコープをIPv4自動構成リンクローカルアドレス（プレフィックス169.254.0.0/16 [7]のアドレス）に割り当て、宛先を実行するためにそれらのアドレスをIPv4-mapped IPv6アドレスに変換します。 IPv4およびIPv6アドレスからのアドレス選択。 これは、IPv4自動構成リンクローカルアドレスに相当するIPv4マップIPv6アドレスがリンクローカルスコープを持つことを暗黙的に意味します。 このドキュメントは、実装内で制限されている限り、そのような使用法を排除しません。
Anycast addresses [1] are allocated from the unicast address space and have the same scope properties as unicast addresses. All statements in this document regarding unicast apply equally to anycast.
エニーキャストアドレス[1]は、ユニキャストアドレス空間から割り当てられ、ユニキャストアドレスと同じスコーププロパティを持ちます。 ユニキャストに関するこのドキュメントのすべての記述は、エニーキャストにも等しく適用されます。
For multicast addresses, there are fourteen possible scopes, ranging from interface-local to global (including link-local). The interface-local scope spans a single interface only; a multicast address of interface-local scope is useful only for loopback delivery of multicasts within a single node; for example, as a form of inter-process communication within a computer. Unlike the unicast loopback address, interface-local multicast addresses may be assigned to any interface.
マルチキャストアドレスの場合、インターフェイスローカルからグローバル（リンクローカルを含む）まで、14のスコープが考えられます。 インターフェイスローカルスコープは、単一のインターフェイスのみに及びます。 インターフェイスローカルスコープのマルチキャストアドレスは、単一ノード内のマルチキャストのループバック配信にのみ役立ちます。 たとえば、コンピューター内のプロセス間通信の形式として。 ユニキャストループバックアドレスとは異なり、インターフェイスローカルマルチキャストアドレスは任意のインターフェイスに割り当てることができます。
There is a size relationship among scopes:
スコープ間にはサイズの関係があります。
o For unicast scopes, link-local is a smaller scope than global.
oユニキャストスコープの場合、リンクローカルはグローバルよりも小さいスコープです。
o For multicast scopes, scopes with lesser values in the "scop" subfield of the multicast address (Section 2.7 of [1]) are smaller than scopes with greater values, with interface-local being the smallest and global being the largest.
oマルチキャストスコープの場合、マルチキャストアドレスの「scop」サブフィールドの値が小さいスコープ（[1]のセクション2.7）は、値が大きいスコープよりも小さく、インターフェイスローカルが最小でグローバルが最大です。
However, two scopes of different size may cover the exact same region of topology. For example, a (multicast) site may consist of a single link, in which both link-local and site-local scope effectively cover the same topological span.
ただし、サイズの異なる2つのスコープがトポロジのまったく同じ領域をカバーする場合があります。 たとえば、（マルチキャスト）サイトは単一のリンクで構成され、リンクローカルとサイトローカルの両方のスコープが同じトポロジスパンを効果的にカバーします。
A scope zone, or simply a zone, is a connected region of topology of a given scope. For example, the set of links connected by routers within a particular (multicast) site, and the interfaces attached to those links, comprise a single zone of multicast site-local scope.
スコープゾーン、または単にゾーンは、特定のスコープのトポロジの接続された領域です。 たとえば、特定の（マルチキャスト）サイト内のルーターによって接続されたリンクのセット、およびそれらのリンクに接続されたインターフェイスは、マルチキャストサイトローカルスコープの単一ゾーンを構成します。
Note that a zone is a particular instance of a topological region (e.g., Alice's site or Bob's site), whereas a scope is the size of a topological region (e.g., a site or a link).
ゾーンはトポロジ領域（たとえば、アリスのサイトまたはボブのサイト）の特定のインスタンスであり、スコープはトポロジ領域のサイズ（たとえば、サイトまたはリンク）であることに注意してください。
The zone to which a particular non-global address pertains is not encoded in the address itself but determined by context, such as the interface from which it is sent or received. Thus, addresses of a given (non-global) scope may be re-used in different zones of that scope. For example, two different physical links may each contain a node with the link-local address fe80::1.
特定の非グローバルアドレスが関係するゾーンは、アドレス自体でエンコードされませんが、送信元または受信元のインターフェイスなどのコンテキストによって決定されます。 したがって、特定の（非グローバル）スコープのアドレスは、そのスコープの異なるゾーンで再利用できます。 たとえば、2つの異なる物理リンクにはそれぞれ、リンクローカルアドレスfe80 :: 1のノードが含まれる場合があります。
Zones of the different scopes are instantiated as follows:
さまざまなスコープのゾーンは、次のようにインスタンス化されます。
o Each interface on a node comprises a single zone of interface-local scope (for multicast only).
oノード上の各インターフェイスは、インターフェイスローカルスコープの単一ゾーンで構成されます（マルチキャストのみ）。
o Each link and the interfaces attached to that link comprise a single zone of link-local scope (for both unicast and multicast).
o各リンクと、そのリンクに接続されたインターフェイスは、リンクローカルスコープの単一ゾーンを構成します（ユニキャストとマルチキャストの両方）。
o There is a single zone of global scope (for both unicast and multicast) comprising all the links and interfaces in the Internet.
oインターネット内のすべてのリンクとインターフェイスを含むグローバルスコープの単一ゾーン（ユニキャストとマルチキャストの両方）があります。
o The boundaries of zones of a scope other than interface-local, link-local, and global must be defined and configured by network administrators.
oインターフェイスローカル、リンクローカル、およびグローバル以外のスコープのゾーンの境界は、ネットワーク管理者が定義および構成する必要があります。
Zone boundaries are relatively static features, not changing in response to short-term changes in topology. Thus, the requirement that the topology within a zone be "connected" is intended to include links and interfaces that may only be occasionally connected. For example, a residential node or network that obtains Internet access by dial-up to an employer's (multicast) site may be treated as part of the employer's (multicast) site-local zone even when the dial-up link is disconnected. Similarly, a failure of a router, interface, or link that causes a zone to become partitioned does not split that zone into multiple zones. Rather, the different partitions are still considered to belong to the same zone.
ゾーン境界は比較的静的な機能であり、トポロジの短期的な変更に応じて変更されることはありません。 したがって、ゾーン内のトポロジが「接続」されるという要件は、たまにしか接続されない可能性のあるリンクとインターフェイスを含めることを意図しています。 たとえば、雇用者の（マルチキャスト）サイトへのダイヤルアップによってインターネットアクセスを取得する住宅のノードまたはネットワークは、ダイヤルアップリンクが切断されている場合でも、雇用者の（マルチキャスト）サイトローカルゾーンの一部として扱われます。 同様に、ゾーンがパーティション化される原因となるルーター、インターフェイス、またはリンクの障害は、そのゾーンを複数のゾーンに分割しません。 むしろ、異なるパーティションは同じゾーンに属していると見なされます。
Zones have the following additional properties:
ゾーンには、次の追加のプロパティがあります。
o Zone boundaries cut through nodes, not links. (Note that the global zone has no boundary, and the boundary of an interface-local zone encloses just a single interface.)
oリンクではなくノードを通過するゾーン境界。 （大域ゾーンには境界がなく、インターフェースローカルゾーンの境界は単一のインターフェースのみを囲むことに注意してください。）
o Zones of the same scope cannot overlap; i.e., they can have no links or interfaces in common.
o同じスコープのゾーンは重複できません。 つまり、共通のリンクやインターフェースを持たないようにすることができます。
o A zone of a given scope (less than global) falls completely within zones of larger scope. That is, a smaller scope zone cannot include more topology than would any larger scope zone with which it shares any links or interfaces.
o与えられたスコープ（グローバル未満）のゾーンは、より大きなスコープのゾーンに完全に含まれます。 つまり、小さいスコープゾーンには、リンクまたはインターフェイスを共有する大きなスコープゾーンよりも多くのトポロジを含めることはできません。
o Each zone is required to be "convex" from a routing perspective; i.e., packets sent from one interface to any other in the same zone are never routed outside the zone. Note, however, that if a zone contains a tunneled link (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer network of the tunnel can be located outside the zone without breaking the convexity property.
o各ゾーンは、ルーティングの観点から「凸」である必要があります。 つまり、1つのインターフェイスから同じゾーン内の他のインターフェイスに送信されるパケットは、ゾーンの外部にルーティングされることはありません。 ただし、ゾーンにトンネルリンク（たとえば、IPv6-over-IPv6トンネルリンク[8]）が含まれる場合、トンネルの下位層ネットワークは、コンベクシティプロパティを壊さずにゾーンの外側に配置できることに注意してください。
Each interface belongs to exactly one zone of each possible scope. Note that this means that an interface belongs to a scope zone regardless of what kind of unicast address the interface has or of which multicast groups the node joins on the interface.
各インターフェイスは、可能な各スコープの1つのゾーンに属します。 これは、インターフェイスがどの種類のユニキャストアドレスを持っているか、またはノードがインターフェイスに参加するマルチキャストグループに関係なく、インターフェイスがスコープゾーンに属することを意味することに注意してください。
Because the same non-global address may be in use in more than one zone of the same scope (e.g., the use of link-local address fe80::1 in two separate physical links) and a node may have interfaces attached to different zones of the same scope (e.g., a router normally has multiple interfaces attached to different links), a node requires an internal means to identify to which zone a non-global address belongs. This is accomplished by assigning, within the node, a distinct "zone index" to each zone of the same scope to which that node is attached, and by allowing all internal uses of an address to be qualified by a zone index.
同じ非グローバルアドレスが同じスコープの複数のゾーンで使用されている可能性があるため（たとえば、2つの個別の物理リンクでのリンクローカルアドレスfe80 :: 1の使用）、ノードが異なるゾーンに接続されたインターフェイスを持っている可能性があるため 同じスコープ（たとえば、ルーターは通常、異なるリンクに接続された複数のインターフェースを持っています）の場合、ノードは非グローバルアドレスが属するゾーンを識別する内部手段を必要とします。 これは、ノード内で、そのノードが接続されている同じスコープの各ゾーンに個別の「ゾーンインデックス」を割り当て、アドレスのすべての内部使用をゾーンインデックスで修飾できるようにすることで実現されます。
The assignment of zone indices is illustrated in the example in the figure below:
ゾーンインデックスの割り当ては、次の図の例に示されています。
---------------------------------------------------------------
| a node |
| |
| |
| |
| |
| |
| |
| /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ |
| |
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
---------------------------------------------------------------
: | | | |
: | | | |
: | | | |
(imaginary ================= a point- a
loopback an Ethernet to-point tunnel
link) link
Figure 1: Zone Indices Example
図1：ゾーンインデックスの例
This example node has five interfaces:
この例のノードには5つのインターフェースがあります。
A loopback interface to the imaginary loopback link (a phantom link that goes nowhere).
架空のループバックリンク（どこにも行かないファントムリンク）へのループバックインターフェイス。
Two interfaces to the same Ethernet link.
同じイーサネットリンクへの2つのインターフェイス。
An interface to a point-to-point link.
ポイントツーポイントリンクへのインターフェイス。
A tunnel interface (e.g., the abstract endpoint of an IPv6-over-IPv6 tunnel [8], presumably established over either the Ethernet or the point-to-point link).
トンネルインターフェース（たとえば、IPv6 over IPv6トンネルの抽象的なエンドポイント[8]。おそらくイーサネットまたはポイントツーポイントリンクのいずれかで確立されます）。
It is thus attached to five interface-local zones, identified by the interface indices 1 through 5.
したがって、インターフェイスインデックス1〜5で識別される5つのインターフェイスローカルゾーンに接続されます。
Because the two Ethernet interfaces are attached to the same link, the node is only attached to four link-local zones, identified by link indices 1 through 4. Also note that even if the tunnel interface is established over the Ethernet, the tunnel link gets its own link index, which is different from the index of the Ethernet link zone.
2つのイーサネットインターフェイスは同じリンクに接続されるため、ノードはリンクインデックス1〜4で識別される4つのリンクローカルゾーンにのみ接続されます。また、イーサネット上でトンネルインターフェイスが確立されても、 イーサネットリンクゾーンのインデックスとは異なる独自のリンクインデックス。
Each zone index of a particular scope should contain enough information to indicate the scope, so that all indices of all scopes are unique within the node and zone indices themselves can be used for a dedicated purpose. Usage of the index to identify an entry in the Management Information Base (MIB) is an example of the dedicated purpose. The actual representation to encode the scope is implementation dependent and is out of scope of this document. Within this document, indices are simply represented in a format such as "link index 2" for readability.
特定のスコープの各ゾーンインデックスには、スコープを示すのに十分な情報が含まれている必要があります。これにより、すべてのスコープのすべてのインデックスがノード内で一意であり、ゾーンインデックス自体を専用の目的に使用できます。 管理情報ベース（MIB）のエントリを識別するためのインデックスの使用は、専用の目的の例です。 スコープをエンコードする実際の表現は実装依存であり、このドキュメントの範囲外です。 このドキュメントでは、インデックスは読みやすくするために「リンクインデックス2」などの形式で単純に表されています。
The zone indices are strictly local to the node. For example, the node on the other end of the point-to-point link may well use entirely different interface and link index values for that link.
ゾーンインデックスは、ノードに対して厳密にローカルです。 たとえば、ポイントツーポイントリンクのもう一方の端にあるノードは、そのリンクに対してまったく異なるインターフェイスとリンクインデックス値を使用する場合があります。
An implementation should also support the concept of a "default" zone for each scope. And, when supported, the index value zero at each scope SHOULD be reserved to mean "use the default zone". Unlike other zone indices, the default index does not contain any scope, and the scope is determined by the address that the default index accompanies. An implementation may additionally define a separate default zone for each scope. Those default indices can also be used as the zone qualifier for an address for which the node is attached to only one zone; e.g., when using global addresses.
実装では、各スコープの「デフォルト」ゾーンの概念もサポートする必要があります。 また、サポートされている場合、各スコープのインデックス値ゼロは、「デフォルトゾーンを使用する」ことを意味するために予約する必要があります。 他のゾーンインデックスとは異なり、デフォルトインデックスにはスコープが含まれておらず、スコープはデフォルトインデックスに付随するアドレスによって決定されます。 実装では、スコープごとに個別のデフォルトゾーンを追加で定義できます。 これらのデフォルトインデックスは、ノードが1つのゾーンのみに接続されているアドレスのゾーン修飾子としても使用できます。 たとえば、グローバルアドレスを使用する場合。
At present, there is no way for a node to automatically determine which of its interfaces belong to the same zones; e.g., the same link or the same multicast scope zone larger than interface. In the future, protocols may be developed to determine that information. In the absence of such protocols, an implementation must provide a means for manual assignment and/or reassignment of zone indices. Furthermore, to avoid performing manual configuration in most cases, an implementation should, by default, initially assign zone indices only as follows:
現時点では、ノードがどのインターフェイスが同じゾーンに属しているかを自動的に判断する方法はありません。 たとえば、インターフェイスよりも大きい同じリンクまたは同じマルチキャストスコープゾーン。 将来、その情報を決定するためのプロトコルが開発される可能性があります。 そのようなプロトコルがない場合、実装は、ゾーンインデックスの手動割り当ておよび/または再割り当ての手段を提供する必要があります。 さらに、ほとんどの場合、手動構成の実行を回避するために、実装では、デフォルトで次のようにのみゾーンインデックスを最初に割り当てる必要があります。
o A unique interface index for each interface.
o各インターフェイスの一意のインターフェイスインデックス。
o A unique link index for each interface.
o各インターフェイスの一意のリンクインデックス。
Then manual configuration would only be necessary for the less common cases of nodes with multiple interfaces to a single link or of those with interfaces to zones of different (multicast-only) scopes.
次に、手動リンクは、単一リンクへの複数のインターフェイスを持つノードや、異なる（マルチキャストのみ）スコープのゾーンへのインターフェイスを持つノードのあまり一般的でない場合にのみ必要になります。
Thus, the default zone index assignments for the example node from Figure 1 would be as illustrated in Figure 2, below. Manual configuration would then be required to, for example, assign the same link index to the two Ethernet interfaces, as shown in Figure 1.
したがって、図1のノード例に対するデフォルトのゾーンインデックスの割り当ては、以下の図2のようになります。 図1に示すように、たとえば、2つのイーサネットインターフェイスに同じリンクインデックスを割り当てるには、手動構成が必要になります。
---------------------------------------------------------------
| a node |
| |
| |
| |
| |
| |
| /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ |
| |
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
---------------------------------------------------------------
: | | | |
: | | | |
: | | | |
(imaginary ================= a point- a
loopback an Ethernet to-point tunnel
link) link
Figure 2: Example of Default Zone Indices
図2：デフォルトゾーンインデックスの例
As well as initially assigning zone indices, as specified above, an implementation should automatically select a default zone for each scope for which there is more than one choice, to be used whenever an address is specified without a zone index (or with a zone index of zero). For instance, in the example shown in Figure 2, the implementation might automatically select intf2 and link2 as the default zones for each of those two scopes. (One possible selection algorithm is to choose the first zone that includes an interface other than the loopback interface as the default for each scope.) A means must also be provided to assign the default zone for a scope manually, overriding any automatic assignment.
上記で指定したように、ゾーンインデックスを最初に割り当てるだけでなく、実装は、ゾーンインデックスなしで（またはゾーンインデックス付きで）アドレスが指定された場合に使用される、複数の選択肢がある各スコープのデフォルトゾーンを自動的に選択する必要があります ゼロ）。 たとえば、図2に示す例では、実装はこれら2つのスコープそれぞれのデフォルトゾーンとしてintf2とlink2を自動的に選択します。 （可能な選択アルゴリズムの1つは、各スコープのデフォルトとしてループバックインターフェイス以外のインターフェイスを含む最初のゾーンを選択することです。）自動割り当てを無効にして、スコープのデフォルトゾーンを手動で割り当てる手段も提供する必要があります。
The unicast loopback address, ::1, may not be assigned to any interface other than the loopback interface. Therefore, it is recommended that, whenever ::1 is specified without a zone index or with the default zone index, it be interpreted as belonging to the loopback link-local zone, regardless of which link-local zone has been selected as the default. If this is done, then for nodes with only a single non-loopback interface (e.g., a single Ethernet interface), the common case, link-local addresses need not be qualified with a zone index. The unqualified address ::1 would always refer to the link-local zone containing the loopback interface. All other unqualified link-local addresses would refer to the link-local zone containing the non-loopback interface (as long as the default link-local zone was set to be the zone containing the non-loopback interface).
ユニキャストループバックアドレス:: 1は、ループバックインターフェイス以外のインターフェイスに割り当てることはできません。 したがって、ゾーンインデックスなしで、またはデフォルトゾーンインデックスを使用して:: 1が指定されている場合は、デフォルトとして選択されているリンクローカルゾーンに関係なく、ループバックリンクローカルゾーンに属すると解釈されることをお勧めします 。 これが行われる場合、一般的なケースである単一の非ループバックインターフェイス（たとえば、単一のイーサネットインターフェイス）のみを持つノードの場合、リンクローカルアドレスはゾーンインデックスで修飾する必要はありません。 非修飾アドレス:: 1は、常にループバックインターフェイスを含むリンクローカルゾーンを参照します。 他のすべての非修飾リンクローカルアドレスは、非ループバックインターフェイスを含むリンクローカルゾーンを参照します（デフォルトのリンクローカルゾーンが非ループバックインターフェイスを含むゾーンに設定されている場合）。
Because of the requirement that a zone of a given scope fall completely within zones of larger scope (see Section 5, above), two interfaces assigned to different zones of scope S must also be assigned to different zones of all scopes smaller than S. Thus, the manual assignment of distinct zone indices for one scope may require the automatic assignment of distinct zone indices for smaller scopes. For example, suppose that distinct multicast site-local indices 1 and 2 are manually assigned in Figure 1 and that site 1 contains links 1, 2, and 3, but site 2 only contains link 4. This configuration would cause the automatic creation of corresponding admin-local (i.e., multicast "scop" value 4) indices 1 and 2, because admin-local scope is smaller than site-local scope.
特定のスコープのゾーンは、より大きなスコープのゾーン内に完全に収まる必要があるため（上記のセクション5を参照）、スコープSの異なるゾーンに割り当てられた2つのインターフェイスも、Sより小さいすべてのスコープの異なるゾーンに割り当てる必要があります。 、1つのスコープに個別のゾーンインデックスを手動で割り当てるには、小さいスコープに個別のゾーンインデックスを自動的に割り当てる必要があります。 たとえば、図1で個別のマルチキャストサイトローカルインデックス1および2が手動で割り当てられ、サイト1にリンク1、2、および3が含まれるが、サイト2にはリンク4のみが含まれると想定します。 管理ローカルスコープはサイトローカルスコープよりも小さいため、管理ローカル（つまり、マルチキャスト "scop"値4）インデックス1および2。
With the above considerations, the complete set of zone indices for our example node from Figure 1, with the additional configurations here, is shown in Figure 3, below.
上記の考慮事項により、図1のサンプルノードのゾーンインデックスの完全なセットと、ここに追加の構成が、図3に示されています。
---------------------------------------------------------------
| a node |
| |
| |
| |
| |
| |
| /--------------------site1--------------------\ /--site2--\ |
| |
| /-------------------admin1--------------------\ /-admin2--\ |
| |
| /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ |
| |
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
---------------------------------------------------------------
: | | | |
: | | | |
: | | | |
(imaginary ================= a point- a
loopback an Ethernet to-point tunnel
link) link
Figure 3: Complete Zone Indices Example
図3：完全なゾーンインデックスの例
Although the above examples show the zones being assigned index values sequentially for each scope, starting at one, the zone index values are arbitrary. An implementation may label a zone with any value it chooses, as long as the index value of each zone of all scopes is unique within the node. Zero SHOULD be reserved to represent the default zone. Implementations choosing to follow the recommended basic API [10] will want to restrict their index values
上記の例では、各スコープに対してインデックス値が順番に割り当てられているゾーンを示していますが、ゾーンインデックス値は任意です。 実装は、すべてのスコープの各ゾーンのインデックス値がノード内で一意である限り、選択した値でゾーンにラベルを付けることができます。 デフォルトのゾーンを表すために、ゼロを予約する必要があります。 推奨される基本API [10]に従うことを選択した実装では、インデックス値を制限する必要があります。
to those that can be represented by the sin6_scope_id field of the sockaddr_in6 structure.
sockaddr_in6構造体のsin6_scope_idフィールドで表すことができるものに。
When an upper-layer protocol sends a packet to a non-global destination address, it must have a means of identifying the intended zone to the IPv6 layer for cases in which the node is attached to more than one zone of the destination address's scope.
上位層プロトコルがパケットを非グローバル宛先アドレスに送信する場合、ノードが宛先アドレスのスコープの複数のゾーンに接続されている場合に、IPv6レイヤーに対して目的のゾーンを識別する手段が必要です。
Although identification of an outgoing interface is sufficient to identify an intended zone (because each interface is attached to no more than one zone of each scope), in many cases that is more specific than desired. For example, when sending to a link-local unicast address from a node that has more than one interface to the intended link (an unusual configuration), the upper layer protocol may not care which of those interfaces is used for the transmission. Rather, it would prefer to leave that choice to the routing function in the IP layer. Thus, the upper-layer requires the ability to specify a zone index, when sending to a non-global, non-loopback destination address.
発信インターフェイスの識別は目的のゾーンを識別するのに十分ですが（各インターフェイスは各スコープの1つのゾーンにしか接続されていないため）、多くの場合、それは必要以上に具体的です。 たとえば、目的のリンクへのインターフェイスが複数あるノードからリンクローカルユニキャストアドレスに送信する場合（異常な構成）、上位層プロトコルは、これらのインターフェイスのどれが送信に使用されるかを気にしません。 むしろ、その選択をIP層のルーティング機能に任せたいと思うでしょう。 したがって、非グローバルで非ループバックの宛先アドレスに送信する場合、上位層にはゾーンインデックスを指定する機能が必要です。
When an upper-layer protocol receives a packet containing a non-global source or destination address, the zone to which that address pertains can be determined from the arrival interface, because the arrival interface can be attached to only one zone of the same scope as that of the address under consideration. However, it is recommended that the IP layer convey to the upper layer the correct zone indices for the arriving source and destination addresses, in addition to the arrival interface identifier.
上位層プロトコルが非グローバルの送信元または宛先アドレスを含むパケットを受信すると、そのアドレスが属するゾーンは、到着インターフェースから決定できます。これは、到着インターフェースは、同じスコープの1つのゾーンにしか接続できないためです。 検討中のアドレスのもの。 ただし、IP層は、到着インターフェイス識別子に加えて、到着する送信元および宛先アドレスの正しいゾーンインデックスを上位層に伝達することをお勧めします。
When a router receives a packet addressed to a node other than itself, it must take the zone of the destination and source addresses into account as follows:
ルーターは、自分以外のノードにアドレス指定されたパケットを受信すると、次のように宛先および送信元アドレスのゾーンを考慮する必要があります。
o The zone of the destination address is determined by the scope of the address and arrival interface of the packet. The next-hop interface is chosen by looking up the destination address in a (conceptual) routing table specific to that zone (see Section 10). That routing table is restricted to refer to interfaces belonging to that zone.
o宛先アドレスのゾーンは、アドレスの範囲とパケットの到着インターフェースによって決定されます。 ネクストホップインターフェイスは、そのゾーンに固有の（概念的な）ルーティングテーブルで宛先アドレスを検索することにより選択されます（セクション10を参照）。 そのルーティングテーブルは、そのゾーンに属するインターフェイスを参照するように制限されています。
o After the next-hop interface is chosen, the zone of the source address is considered. As with the destination address, the zone of the source address is determined by the scope of the address and arrival interface of the packet. If transmitting the packet on the chosen next-hop interface would cause the packet to leave the zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded. Additionally, if the packet's destination address is a unicast address, an ICMP Destination Unreachable message [4] with Code 2 ("beyond scope of source address") is sent to the source of the original packet. Note that Code 2 is currently left as unassigned in [4], but the IANA will re-assign the value for the new purpose, and [4] will be revised with this change.
oネクストホップインターフェイスが選択された後、送信元アドレスのゾーンが考慮されます。 宛先アドレスと同様に、送信元アドレスのゾーンは、アドレスの範囲とパケットの到着インターフェイスによって決定されます。 選択したネクストホップインターフェイスでパケットを送信すると、パケットが送信元アドレスのゾーンを離れる場合、つまり送信元アドレスのスコープのゾーン境界を越える場合、パケットは破棄されます。 さらに、パケットの宛先アドレスがユニキャストアドレスである場合、コード2（「ソースアドレスの範囲外」）を持つICMP宛先到達不能メッセージ[4]が元のパケットのソースに送信されます。 現在、コード2は[4]で未割り当てのままですが、IANAは新しい目的のために値を再割り当てし、[4]はこの変更に伴い改訂されることに注意してください。
Note that even if unicast site-local addresses are deprecated, the above procedure still applies to link-local addresses. Thus, if a router receives a packet with a link-local destination address that is not one of the router's own link-local addresses on the arrival link, the router is expected to try to forward the packet to the destination on that link (subject to successful determination of the destination's link-layer address via the Neighbor Discovery protocol [9]). The forwarded packet may be transmitted back through the arrival interface, or through any other interface attached to the same link.
ユニキャストサイトローカルアドレスが廃止された場合でも、上記の手順はリンクローカルアドレスに適用されることに注意してください。 したがって、ルーターが到着リンク上のルーター自身のリンクローカルアドレスの1つではないリンクローカル宛先アドレスを持つパケットを受信した場合、ルーターはそのリンク上の宛先にパケットを転送しようとすることが期待されます（対象 近隣探索プロトコル[9]を介した宛先のリンク層アドレスの決定に成功するまで）。 転送されたパケットは、到着インターフェイスを介して、または同じリンクに接続されている他のインターフェイスを介して送り返されます。
A node that receives a packet addressed to itself and containing a Routing Header with more than zero Segments Left (Section 4.4 of [3]) first checks the scope of the next address in the Routing Header. If the scope of the next address is smaller than the scope of the original destination address, the node MUST discard the packet. Otherwise, it swaps the original destination address with the next address in the Routing Header. Then the above forwarding rules apply as follows:
自身宛のパケットを受信し、残りのセグメントがゼロを超えるルーティングヘッダー（[3]のセクション4.4）を含むノードは、ルーティングヘッダーの次のアドレスのスコープを最初にチェックします。 次のアドレスのスコープが元の宛先アドレスのスコープより小さい場合、ノードはパケットを破棄しなければなりません。 それ以外の場合は、元の宛先アドレスをルーティングヘッダーの次のアドレスと交換します。 次に、上記の転送ルールが次のように適用されます。
o The zone of the new destination address is determined by the scope of the next address and the arrival interface of the packet. The next-hop interface is chosen as per the first bullet of the rules above.
o新しい宛先アドレスのゾーンは、次のアドレスのスコープとパケットの到着インターフェイスによって決定されます。 ネクストホップインターフェイスは、上記のルールの最初の箇条書きに従って選択されます。
o After the next-hop interface is chosen, the zone of the source address is considered as per the second bullet of the rules above.
oネクストホップインターフェイスが選択された後、送信元アドレスのゾーンは、上記のルールの2番目の箇条書きに従って考慮されます。
This check about the scope of the next address ensures that when a packet arrives at its final destination, if that destination is link-local, then the receiving node can know that the packet originated on-link. This will help the receiving node send a "response" packet with the final destination of the received packet as the source address without breaking its source zone.
次のアドレスのスコープに関するこのチェックにより、パケットが最終的な宛先に到着したときに、その宛先がリンクローカルであれば、受信ノードはパケットがリンク上で発生したことを知ることができます。 これにより、受信ノードは、ソースゾーンを壊すことなく、受信パケットの最終宛先を送信元アドレスとして「応答」パケットを送信できます。
Note that it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary in the previously used next address field. For example, consider a case in which a link-border node (e.g., a router) receives a packet with the destination being a link-local address, and the source address a global address. If the packet contains a Routing Header where the next address is a global address, the next-hop interface to the global address may belong to a different link than that of the original destination. This is allowed because the scope of the next address is not smaller than the scope of the original destination.
一般的にはお勧めできませんが、ルーティングヘッダーを使用して、以前に使用した次のアドレスフィールドの関連するゾーン境界を越えて非グローバルアドレスを伝達することができます。 たとえば、リンク境界ノード（ルーターなど）がパケットを受信し、宛先がリンクローカルアドレスであり、ソースアドレスがグローバルアドレスである場合を考えます。 次のアドレスがグローバルアドレスであるルーティングヘッダーがパケットに含まれる場合、グローバルアドレスへのネクストホップインターフェイスは、元の宛先のリンクとは異なるリンクに属する場合があります。 次のアドレスのスコープが元の宛先のスコープより小さくないため、これは許可されます。
Note that as unicast site-local addresses are deprecated, and link-local addresses do not need routing, the discussion in this section only applies to multicast scoped routing.
ユニキャストサイトローカルアドレスは非推奨であり、リンクローカルアドレスはルーティングを必要としないため、このセクションの説明はマルチキャストスコープルーティングにのみ適用されることに注意してください。
When a routing protocol determines that it is operating on a zone boundary, it MUST protect inter-zone integrity and maintain intra-zone connectivity.
ルーティングプロトコルがゾーン境界で動作していると判断した場合、ゾーン間整合性を保護し、ゾーン内接続を維持する必要があります。
To maintain connectivity, the routing protocol must be able to create forwarding information for the global groups and for all the scoped groups for each of its attached zones. The most straightforward way of doing this is to create (conceptual) forwarding tables for each specific zone.
接続を維持するには、ルーティングプロトコルが、グローバルグループと、接続されている各ゾーンのすべてのスコープグループの転送情報を作成できる必要があります。 これを行う最も簡単な方法は、特定のゾーンごとに（概念的な）転送テーブルを作成することです。
To protect inter-zone integrity, routers must be selective in the group information shared with neighboring routers. Routers routinely exchange routing information with neighboring routers. When a router is transmitting this routing information, it must not include any information about zones other than the zones assigned to the interface used to transmit the information.
ゾーン間整合性を保護するには、ルーターは隣接ルーターと共有されるグループ情報で選択的でなければなりません。 ルーターは、近隣ルーターと定期的にルーティング情報を交換します。 ルーターがこのルーティング情報を送信する場合、情報の送信に使用されるインターフェイスに割り当てられたゾーン以外のゾーンに関する情報を含めてはなりません。
* *
* *
* =========== Organization X *
* | | *
* | | *
+-*----|-------|------+ *
| * intf1 intf2 | *
| * | *
| * intf3 --- *
| * | *
| ***********************************
| |
| Router |
| |
********************** **********************
| * * |
Org. Y --- intf4 * * intf5 --- Org. Z
| * * |
********************** **********************
+---------------------+
Figure 4: Multi-Organization Multicast Router
図4：マルチ組織マルチキャストルーター
As an example, the router in Figure 4 must exchange routing information on five interfaces. The information exchanged is as follows (for simplicity, multicast scopes smaller or larger than the organization scope except global are not considered here):
例として、図4のルーターは5つのインターフェイスでルーティング情報を交換する必要があります。 交換される情報は次のとおりです（簡単にするために、グローバルを除く組織スコープよりも小さいまたは大きいマルチキャストスコープはここでは考慮されません）。
o Interface 1 * All global groups * All organization groups learned from Interfaces 1, 2, and 3
oインターフェース1 *すべてのグローバルグループ*インターフェース1、2、および3から学習したすべての組織グループ
o Interface 2 * All global groups * All organization groups learned from Interfaces 1, 2, and 3
oインターフェイス2 *すべてのグローバルグループ*インターフェイス1、2、および3から学習したすべての組織グループ
o Interface 3 * All global groups * All organization groups learned from Interfaces 1, 2, and 3
oインターフェイス3 *すべてのグローバルグループ*インターフェイス1、2、および3から学習したすべての組織グループ
o Interface 4 * All global groups * All organization groups learned from Interface 4
oインターフェース4 *すべてのグローバルグループ*インターフェース4から学習したすべての組織グループ
o Interface 5 * All global groups * All organization groups learned from Interface 5
oインターフェース5 *すべてのグローバルグループ*インターフェース5から学習したすべての組織グループ
By imposing route exchange rules, zone integrity is maintained by keeping all zone-specific routing information contained within the zone.
ルート交換ルールを課すことにより、ゾーン内に含まれるすべてのゾーン固有のルーティング情報を保持することにより、ゾーンの整合性が維持されます。
As already mentioned, to specify an IPv6 non-global address without ambiguity, an intended scope zone should be specified as well. As a common notation to specify the scope zone, an implementation SHOULD support the following format:
既に述べたように、あいまいさのないIPv6非グローバルアドレスを指定するには、目的のスコープゾーンも指定する必要があります。 スコープゾーンを指定する一般的な表記法として、実装は次の形式をサポートする必要があります。
<address>%<zone_id>
<アドレス>％<zone_id>
where
どこ
<address> is a literal IPv6 address,
<address>はリテラルIPv6アドレスです。
<zone_id> is a string identifying the zone of the address, and
<zone_id>は、アドレスのゾーンを識別する文字列です。
`%' is a delimiter character to distinguish between <address> and <zone_id>.
`％ 'は、<address>と<zone_id>を区別するための区切り文字です。
The following subsections describe detailed definitions, concrete examples, and additional notes of the format.
次のサブセクションでは、形式の詳細な定義、具体例、および追加の注意事項について説明します。
The format applies to all kinds of unicast and multicast addresses of non-global scope except the unspecified address, which does not have a scope. The format is meaningless and should not be used for global addresses. The loopback address belongs to the trivial link; i.e., the link attached to the loopback interface. Thus the format should not be used for the loopback address, either. This document does not specify the usage of the format when the <address> is the unspecified address, as the address does not have a scope. This document, however, does not prohibit an implementation from using the format for those special addresses for implementation dependent purposes.
この形式は、スコープを持たない未指定アドレスを除く、非グローバルスコープのすべての種類のユニキャストおよびマルチキャストアドレスに適用されます。 この形式は無意味であり、グローバルアドレスには使用しないでください。 ループバックアドレスは単純なリンクに属します。 つまり、ループバックインターフェイスに接続されたリンク。 したがって、この形式はループバックアドレスにも使用しないでください。 アドレスにはスコープがないため、このドキュメントでは、<address>が未指定のアドレスである場合の形式の使用法を指定していません。 ただし、このドキュメントでは、実装が実装に依存する目的でこれらの特別なアドレスにフォーマットを使用することを禁止していません。
In the textual representation, the <zone_id> part should be able to identify a particular zone of the address's scope. Although a zone index is expected to contain enough information to determine the scope and to be unique among all scopes as described in Section 6, the <zone_id> part of this format does not have to contain the scope. This is because the <address> part should specify the appropriate scope. This also means that the <zone_id> part does not have to be unique among all scopes.
テキスト表現では、<zone_id>部分はアドレス範囲の特定のゾーンを識別できる必要があります。 セクション6で説明されているように、ゾーンインデックスにはスコープを決定し、すべてのスコープ間で一意になるのに十分な情報が含まれていることが期待されますが、この形式の<zone_id>部分にはスコープを含める必要はありません。 これは、<address>部分で適切なスコープを指定する必要があるためです。 これは、<zone_id>部分がすべてのスコープで一意である必要がないことも意味します。
With this loosened property, an implementation can use a convenient representation as <zone_id>. For example, to represent link index 2, the implementation can simply use "2" as <zone_id>, which would be more readable than other representations that contain the "link" scope.
この緩いプロパティを使用すると、実装は<zone_id>として便利な表現を使用できます。 たとえば、リンクインデックス2を表すために、実装は単に「2」を<zone_id>として使用できます。これは、「link」スコープを含む他の表現より読みやすくなります。
When an implementation interprets the format, it should construct the "full" zone index, which contains the scope, from the <zone_id> part and the scope specified by the <address> part. (Remember that a zone index itself should contain the scope, as specified in Section 6.)
実装が形式を解釈するとき、<zone_id>部分と<address>部分で指定された範囲からスコープを含む「フル」ゾーンインデックスを構築する必要があります。 （セクション6で指定されているように、ゾーンインデックス自体にスコープを含める必要があることに注意してください。）
An implementation SHOULD support at least numerical indices that are non-negative decimal integers as <zone_id>. The default zone index, which should typically be 0 (see Section 6), is included in the integers. When <zone_id> is the default, the delimiter characters "%" and <zone_id> can be omitted. Similarly, if a textual representation of an IPv6 address is given without a zone index, it should be interpreted as <address>%<default ID>, where <default ID> is the default zone index of the scope that <address> has.
実装は、少なくとも<zone_id>として負でない10進整数である数値インデックスをサポートする必要があります。 通常は0でなければならないデフォルトのゾーンインデックス（セクション6を参照）が整数に含まれています。 <zone_id>がデフォルトの場合、区切り文字「％」および<zone_id>は省略できます。 同様に、IPv6アドレスのテキスト表現がゾーンインデックスなしで指定される場合、<アドレス>％<デフォルトID>として解釈される必要があります。ここで、<デフォルトID>は<アドレス>が持つスコープのデフォルトゾーンインデックスです。
An implementation MAY support other kinds of non-null strings as <zone_id>. However, the strings must not conflict with the delimiter character. The precise format and semantics of additional strings is implementation dependent.
実装は、<zone_id>として他の種類の非null文字列をサポートする場合があります。 ただし、文字列は区切り文字と競合してはなりません。 追加の文字列の正確な形式とセマンティクスは実装に依存します。
One possible candidate for these strings would be interface names, as interfaces uniquely disambiguate any scopes. In particular, interface names can be used as "default identifiers" for interfaces and links, because by default there is a one-to-one mapping between interfaces and each of those scopes as described in Section 6.
インターフェイスはスコープを一意に明確にするため、これらの文字列の候補の1つはインターフェイス名です。 特に、インターフェイス名は、インターフェイスとリンクの「デフォルト識別子」として使用できます。これは、デフォルトでは、セクション6で説明されているように、インターフェイスとそれらの各スコープとの間に1対1のマッピングがあるためです
An implementation could also use interface names as <zone_id> for scopes larger than links, but there might be some confusion in this use. For example, when more than one interface belongs to the same (multicast) site, a user would be confused about which interface should be used. Also, a mapping function from an address to a name would encounter the same kind of problem when it prints an address with an interface name as a zone index. This document does not specify how these cases should be treated and leaves it implementation dependent.
実装では、リンクよりも大きいスコープのインターフェイス名を<zone_id>として使用することもできますが、この使用には混乱が生じる可能性があります。 たとえば、複数のインターフェースが同じ（マルチキャスト）サイトに属している場合、ユーザーはどのインターフェースを使用すべきかについて混乱します。 また、アドレスから名前へのマッピング関数では、ゾーンインデックスとしてインターフェイス名を使用してアドレスを出力するときに、同じ種類の問題が発生します。 このドキュメントでは、これらのケースの処理方法を指定せず、実装に依存します。
It cannot be assumed that indices are common across all nodes in a zone (see Section 6). Hence, the format MUST be used only within a node and MUST NOT be sent on the wire unless every node that interprets the format agrees on the semantics.
ゾーン内のすべてのノードでインデックスが共通であると想定することはできません（セクション6を参照）。 したがって、フォーマットはノード内でのみ使用する必要があり、フォーマットを解釈するすべてのノードがセマンティクスに同意しない限り、ワイヤ上で送信してはなりません。
The following addresses
次のアドレス
fe80::1234 (on the 1st link of the node)
ff02::5678 (on the 5th link of the node)
ff08::9abc (on the 10th organization of the node)
would be represented as follows:
次のように表されます。
fe80::1234%1
ff02::5678%5
ff08::9abc%10
(Here we assume a natural translation from a zone index to the <zone_id> part, where the Nth zone of any scope is translated into "N".)
（ここでは、ゾーンインデックスから<zone_id>部分への自然な変換を想定しています。ここでは、任意のスコープのN番目のゾーンが「N」に変換されます。）
If we use interface names as <zone_id>, those addresses could also be represented as follows:
インターフェイス名を<zone_id>として使用する場合、これらのアドレスは次のように表すこともできます。
fe80::1234%ne0
ff02::5678%pvc1.3
ff08::9abc%interface10
where the interface "ne0" belongs to the 1st link, "pvc1.3" belongs to the 5th link, and "interface10" belongs to the 10th organization.
ここで、インターフェイス「ne0」は1番目のリンクに属し、「pvc1.3」は5番目のリンクに属し、「interface10」は10番目の組織に属します。
Applications that are supposed to be used in end hosts such as telnet, ftp, and ssh may not explicitly support the notion of address scope, especially of link-local addresses. However, an expert user (e.g., a network administrator) sometimes has to give even link-local addresses to such applications.
telnet、ftp、sshなどのエンドホストで使用されることになっているアプリケーションは、アドレススコープ、特にリンクローカルアドレスの概念を明示的にサポートしていない場合があります。 ただし、熟練したユーザー（ネットワーク管理者など）は、そのようなアプリケーションにリンクローカルアドレスさえも与えなければならない場合があります。
Here is a concrete example. Consider a multi-linked router called "R1" that has at least two point-to-point interfaces (links). Each of the interfaces is connected to another router, "R2" and "R3", respectively. Also assume that the point-to-point interfaces have link-local addresses only.
以下に具体例を示します。 少なくとも2つのポイントツーポイントインターフェイス（リンク）を持つ「R1」と呼ばれるマルチリンクルーターを検討してください。 各インターフェイスは、別のルーター「R2」と「R3」にそれぞれ接続されています。 また、ポイントツーポイントインターフェイスにはリンクローカルアドレスのみがあると想定します。
Now suppose that the routing system on R2 hangs up and has to be reinvoked. In this situation, we may not be able to use a global address of R2, because this is routing trouble and we cannot expect to have enough routes for global reachability to R2.
ここで、R2のルーティングシステムがハングアップし、再起動する必要があるとします。 この状況では、R2のグローバルアドレスを使用できない場合があります。これはルーティングの問題であり、R2へのグローバルな到達可能性に十分なルートがあるとは考えられないためです。
Hence, we have to login R1 first and then try to login R2 by using link-local addresses. In this case, we have to give the link-local address of R2 to, for example, telnet. Here we assume the address is fe80::2.
したがって、最初にR1にログインしてから、リンクローカルアドレスを使用してR2にログインする必要があります。 この場合、R2のリンクローカルアドレスを、たとえばtelnetに提供する必要があります。 ここでは、アドレスがfe80 :: 2であると想定しています。
Note that we cannot just type
入力することはできないことに注意してください
% telnet fe80::2
％telnet fe80 :: 2
here, since R1 has more than one link and hence the telnet command cannot detect which link it should try to use for connecting. Instead, we should type the link-local address with the link index as follows:
ここでは、R1に複数のリンクがあるため、telnetコマンドは接続に使用するリンクを検出できません。 代わりに、リンクローカルアドレスとリンクインデックスを次のように入力する必要があります。
% telnet fe80::2%3
％telnet fe80 :: 2％3
where "3" after the delimiter character `%' corresponds to the link index of the point-to-point link.
ここで、区切り文字「％」の後の「3」は、ポイントツーポイントリンクのリンクインデックスに対応します。
An extension to the recommended basic API defines how the format for non-global addresses should be treated in library functions that translate a nodename to an address, or vice versa [11].
推奨される基本APIの拡張は、ノード名をアドレスに、またはその逆に変換するライブラリ関数で非グローバルアドレスの形式をどのように処理するかを定義します[11]。
The format defined in this document does not intend to invalidate the original format for non-global addresses; that is, the format without the zone index portion. As described in Section 6, in some common cases with the notion of the default zone index, there can be no ambiguity about scope zones. In such an environment, the implementation can omit the "%<zone_id>" part. As a result, it can act as though it did not support the extended format at all.
このドキュメントで定義されている形式は、非グローバルアドレスの元の形式を無効にすることを意図していません。 つまり、ゾーンインデックス部分のない形式です。 セクション6で説明したように、デフォルトゾーンインデックスの概念のある一般的なケースでは、スコープゾーンについてあいまいさはありません。 このような環境では、実装は「％<zone_id>」部分を省略できます。 その結果、拡張フォーマットをまったくサポートしていないかのように動作できます。
There are other kinds of delimiter characters defined for IPv6 addresses. In this subsection, we describe how they should be combined with the format for non-global addresses.
IPv6アドレスには、他の種類の区切り文字が定義されています。 このサブセクションでは、それらを非グローバルアドレスの形式と組み合わせる方法を説明します。
The IPv6 addressing architecture [1] also defines the syntax of IPv6 prefixes. If the address portion of a prefix is non-global and its scope zone should be disambiguated, the address portion SHOULD be in the format. For example, a link-local prefix fe80::/64 on the second link can be represented as follows:
IPv6アドレッシングアーキテクチャ[1]は、IPv6プレフィックスの構文も定義します。 プレフィックスのアドレス部分が非グローバルであり、そのスコープゾーンを明確にする必要がある場合、アドレス部分は次の形式である必要があります。 たとえば、2番目のリンクのリンクローカルプレフィックスfe80 :: / 64は、次のように表すことができます。
fe80::%2/64
fe80 ::％2/64
In this combination, it is important to place the zone index portion before the prefix length when we consider parsing the format by a name-to-address library function [11]. That is, we can first separate the address with the zone index from the prefix length, and just pass the former to the library function.
この組み合わせでは、名前からアドレスへのライブラリ関数[11]による形式の解析を検討する際に、プレフィックス長の前にゾーンインデックス部分を配置することが重要です。 つまり、最初にアドレスをゾーンインデックスでプレフィックス長から分離し、前者をライブラリ関数に渡すだけです。
The preferred format for literal IPv6 addresses in URLs is also defined [12]. When a user types the preferred format for an IPv6 non-global address whose zone should be explicitly specified, the user could use the format for the non-global address combined with the preferred format.
URLのリテラルIPv6アドレスの優先形式も定義されています[12]。 ゾーンを明示的に指定する必要があるIPv6非グローバルアドレスの優先形式をユーザーが入力すると、ユーザーは非グローバルアドレスの形式を優先形式と組み合わせて使用できます。
However, the typed URL is often sent on the wire, and it would cause confusion if an application did not strip the <zone_id> portion before sending. Note that the applications should not need to care about which kind of addresses they're using, much less parse or strip out the <zone_id> portion of the address.
ただし、入力されたURLは多くの場合、ネットワーク上で送信されるため、アプリケーションが送信前に<zone_id>部分を削除しなかった場合、混乱が生じます。 アプリケーションは、使用しているアドレスの種類を気にする必要がないことに注意してください。アドレスの<zone_id>部分を解析したり、削除したりする必要はありません。
Also, the format for non-global addresses might conflict with the URI syntax [13], since the syntax defines the delimiter character (`%') as the escape character. This conflict would require, for example, that the <zone_id> part for zone 1 with the delimiter be represented as '%251'. It also means that we could not simply copy a non-escaped format from other sources as input to the URI parser. Additionally, if the URI parser does not convert the escaped format before passing it to a name-to-address library, the conversion will fail. All these issues would decrease the benefit of the textual representation described in this section.
また、非グローバルアドレスの形式は、URI構文[13]と競合する可能性があります。これは、構文が区切り文字（ '％'）をエスケープ文字として定義しているためです。 この競合では、たとえば、区切り文字を持つゾーン1の<zone_id>部分を「％251」として表す必要があります。 また、URIパーサーへの入力として、エスケープされていない形式を他のソースから単純にコピーできないことも意味します。 さらに、URIパーサーがエスケープされた形式を名前からアドレスへのライブラリーに渡す前に変換しない場合、変換は失敗します。 これらの問題はすべて、このセクションで説明するテキスト表現の利点を減らします。
Hence, this document does not specify how the format for non-global addresses should be combined with the preferred format for literal IPv6 addresses. In any case, it is recommended to use an FQDN instead of a literal IPv6 address in a URL, whenever an FQDN is available.
したがって、このドキュメントでは、非グローバルアドレスの形式をリテラルIPv6アドレスの優先形式と組み合わせる方法を指定していません。 いずれの場合でも、FQDNが使用可能な場合は常に、URLでリテラルIPv6アドレスの代わりにFQDNを使用することをお勧めします。
A limited scope address without a zone index has security implications and cannot be used for some security contexts. For example, a link-local address cannot be used in a traffic selector of a security association established by Internet Key Exchange (IKE) when the IKE messages are carried over global addresses. Also, a link-local address without a zone index cannot be used in access control lists.
ゾーンインデックスのない制限されたスコープアドレスは、セキュリティに影響するため、一部のセキュリティコンテキストでは使用できません。 たとえば、リンクローカルアドレスは、IKEメッセージがグローバルアドレスを介して伝送される場合、Internet Key Exchange（IKE）によって確立されたセキュリティアソシエーションのトラフィックセレクタで使用できません。 また、ゾーンインデックスのないリンクローカルアドレスは、アクセス制御リストで使用できません。
The routing section of this document specifies a set of guidelines whereby routers can prevent zone-specific information from leaking out of each zone. If, for example, multicast site boundary routers allow site routing information to be forwarded outside of the site, the integrity of the site could be compromised.
このドキュメントのルーティングセクションでは、ルーターがゾーン固有の情報が各ゾーンから漏洩するのを防ぐことができる一連のガイドラインを指定しています。 たとえば、マルチキャストサイト境界ルーターがサイトルーティング情報のサイト外への転送を許可すると、サイトの整合性が損なわれる可能性があります。
Since the use of the textual representation of non-global addresses is restricted to use within a single node, it does not create a security vulnerability from outside the node. However, a malicious node might send a packet that contains a textual IPv6 non-global address with a zone index, intending to deceive the receiving node about the zone of the non-global address. Thus, an implementation should be careful when it receives packets that contain textual non-global addresses as data.
非グローバルアドレスのテキスト表現の使用は、単一ノード内での使用に制限されているため、ノード外からのセキュリティ脆弱性は作成されません。 ただし、悪意のあるノードは、ゾーンインデックス付きのテキストIPv6非グローバルアドレスを含むパケットを送信し、非グローバルアドレスのゾーンについて受信ノードをだまそうとする可能性があります。 したがって、実装は、テキストの非グローバルアドレスをデータとして含むパケットを受信する場合は注意が必要です。
This document is a combination of several separate efforts. Atsushi Onoe took a significant role in one of them and deeply contributed to the content of Section 11 as a co-author of a separate proposal.
このドキュメントは、いくつかの個別の取り組みの組み合わせです。 尾上篤はそのうちの1人で重要な役割を果たし、別の提案の共著者としてセクション11の内容に深く貢献しました。
Many members of the IPv6 working group provided useful comments and feedback on this document. In particular, Margaret Wasserman and Bob Hinden led the working group to make a consensus on IPv6 local addressing. Richard Draves proposed an additional rule to process Routing header containing scoped addresses. Dave Thaler and Francis Dupont gave valuable suggestions to define semantics of zone indices in terms of related API. Pekka Savola reviewed a version of the document very carefully and made detailed comments about serious problems. Steve Bellovin, Ted Hardie, Bert Wijnen, and Timothy Gleeson reviewed and helped improve the document during the preparation for publication.
IPv6ワーキンググループの多くのメンバーが、このドキュメントに関する有用なコメントとフィードバックを提供しました。 特に、マーガレットワッサーマンとボブヒンデンはワーキンググループを率いて、IPv6ローカルアドレッシングに関するコンセンサスを作成しました。 Richard Dravesは、スコープアドレスを含むルーティングヘッダーを処理するための追加ルールを提案しました。 Dave ThalerとFrancis Dupontは、関連するAPIに関してゾーンインデックスのセマンティクスを定義するための貴重な提案をしました。 Pekka Savolaは、ドキュメントのバージョンを非常に慎重にレビューし、深刻な問題について詳細なコメントを作成しました。 Steve Bellovin、Ted Hardie、Bert Wijnen、およびTimothy Gleesonは、公開の準備中にドキュメントのレビューと改善を支援しました。
[1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[1] Hinden、R。、およびS. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[3] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[4] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[4] Conta、A。、およびS. Deering、「インターネットプロトコルバージョン6（IPv6）仕様用のインターネット制御メッセージプロトコル（ICMPv6）」、RFC 2463、1998年12月。
[5] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[5] Huitema、C。、およびB. Carpenter、「非推奨サイトのローカルアドレス」、RFC 3879、2004年9月。
[6] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[6] Draves、R.、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[7] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of Link-Local IPv4 Addresses", Work in Progress.
[7] Cheshire、S.、Aboba、B。、およびE. Guttman、「リンクローカルIPv4アドレスの動的構成」、Work in Progress。
[8] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[8] Conta、A。、およびS. Deering、「IPv6仕様における一般的なパケットトンネリング」、RFC 2473、1998年12月。
[9] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[9] Narten、T.、Nordmark、E。、およびW. Simpson、「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年12月。
[10] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[10] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「IPv6の基本的なソケットインターフェイス拡張」、RFC 3493、2003年2月。
[11] Gilligan, R., "Scoped Address Extensions to the IPv6 Basic Socket API", Work in Progress, July 2002.
[11] Gilligan、R。、「IPv6 Basic Socket APIのスコープアドレス拡張」、Work in Progress、2002年7月。
[12] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[12] Hinden、R.、Carpenter、B。、およびL. Masinter、「URLのリテラルIPv6アドレスの形式」、RFC 2732、1999年12月。
[13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005.
[13]バーナーズ・リー、T。、フィールディング、R。、およびL.マスインター、「Uniform Resource Identifiers（URI）：Generic Syntax」、RFC 3986、2005年1月。
Authors' Addresses
著者のアドレス
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
Brian Haberman Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA
ブライアンハーバーマンジョンズホプキンス大学応用物理学研究所11100ジョンズホプキンスロードローレル、MD 20723-6099米国
Phone: +1-443-778-1319 EMail: brian@innovationslab.net
電話：+ 1-443-778-1319電子メール：brian@innovationslab.net
Tatuya Jinmei Corporate Research & Development Center, Toshiba Corporation 1 Komukai Toshiba-cho, Saiwai-ku Kawasaki-shi, Kanagawa 212-8582 Japan
東芝東芝研究開発センタータツヤ神明〒212-8582神奈川県川崎市幸区小向東芝町1
Phone: +81-44-549-2230 Fax: +81-44-520-1841 EMail: jinmei@isl.rdc.toshiba.co.jp
電話：044-549-2230ファックス：044-520-1841電子メール：jinmei@isl.rdc.toshiba.co.jp
Erik Nordmark 17 Network Circle Menlo Park, CA 94025 USA
Erik Nordmark 17 Network Circle Menlo Park、CA 94025 USA
Phone: +1 650 786 2921 Fax: +1 650 786 5896 EMail: Erik.Nordmark@sun.com
電話：+1 650 786 2921ファックス：+1 650 786 5896電子メール：Erik.Nordmark@sun.com
Brian D. Zill Microsoft Research One Microsoft Way Redmond, WA 98052-6399 USA
ブライアンD.ジルマイクロソフトリサーチワンマイクロソフトウェイレドモンド、ワシントン州98052-6399アメリカ
Phone: +1-425-703-3568 Fax: +1-425-936-7329 EMail: bzill@microsoft.com
電話：+ 1-425-703-3568ファックス：+ 1-425-936-7329電子メール：bzill@microsoft.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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.
この文書は、BCP 78に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。
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.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
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は、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/ipr）から。
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のietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。