この文書はRFC4007の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
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 IPv6の範囲付きのアドレス体系 Status of This Memo この文書の状態 This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. この文書はインターネット共同体のためのインターネット標準化中プロトコ ルを指定し、そして改良のために議論と提案を求めます。どうか標準化状態 とこのプロトコルの状況について「インターネット公式プロトコル標準」 (STD1)の最新版を参照してください。このメモの配布は無制限です。 Copyright Notice 著作権表示 Copyright (C) The Internet Society (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 1. はじめに 2. Definitions 2. 定義 3. Basic Terminology 3. 基本的用語 4. Address Scope 4. アドレス範囲 5. Scope Zones 5. 範囲ゾーン 6. Zone Indices 6. ゾーンインデックス 7. Sending Packets 7. パケット送信 8. Receiving Packets 8. パケット受信 9. Forwarding 9. 転送 10. Routing 10. ルーティング 11. Textual Representation 11. テキスト表記 11.1. Non-Global Addresses 11.1. グローバルでないアドレス 11.2. The <zone_id> Part 11.2. <zone_id>部 11.3. Examples 11.3. 例 11.4. Usage Examples 11.4. 使用法例 11.5. Related API 11.5. 関連API 11.6. Omitting Zone Indices 11.6. ゾーンインデックスの省略 11.7. Combinations of Delimiter Characters 11.7. 区切り文字の組み合わせ 12. Security Considerations 12. セキュリティの考察 13. Contributors 13. 貢献者 14. Acknowledgements 14. 謝辞 15. References 15. 参考文献 15.1. Normative References 15.1. 参照する参考文献 15.2. Informative References 15.2. 有益な参考文献 Authors' Addresses 著者のアドレス Full Copyright Statement 著作権表示全文 1. Introduction 1. はじめに 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版が異なる「範囲」のアドレスに対するサポー トを含みます;すなわち、グローバルとグローバルでない(例えば、リンク ローカル)アドレス。グローバルでないアドレスはIPv4インターネット で、プライベートのアドレス空間("net 10"など)や管理範囲マルチキャス トアドレスで、運用上導入されましたが、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アドレスを調査しています。新し い形のローカルアドレスの使用法は将来ほかで文書化されるでしょう。それ で、この文書は意図的にリンクローカルとマルチキャスト範囲に焦点を合わ せます。 2. Definitions 2. 定義 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] で記述されるように解釈します。 3. Basic Terminology 3. 基本的用語 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]に含まれます。 4. Address Scope 4. アドレス範囲 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とIPv6アドレス間で 宛先アドレス選択を実行するためにこれらのアドレスをIPv4マップIPv 6アドレスに変換します。これは暗黙的に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 マルチキャスト範囲で、マルチキャストアドレスの「範囲」フィールド ([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つの範囲がトポロジ的に正確に同じ範囲を 覆うかもしれません。例えば、(マルチキャスト)サイトが単一リンクから なり、リンクローカルとサイトローカル範囲の両方が同じトポロジ範囲かも しれません。 5. Scope Zones 5. 範囲ゾーン 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 ノードのそれぞれのインタフェースが(マルチキャストのみのために)イ ンタフェースローカルな範囲の1つのゾーンを構成します。 o Each link and the interfaces attached to that link comprise a single zone of link-local scope (for both unicast and multicast). o それぞれのリンクとそのリンクとつながっているインタフェースが(ユニ キャストとマルチキャストの両方のために)リンクローカル範囲の1つの ゾーンを構成します。 o There is a single zone of global scope (for both unicast and multicast) comprising all the links and interfaces in the Internet. o インターネットで(ユニキャストとマルチキャスト両方のために)すべて のリンクとインタフェースで構成するグローバルな範囲の1つのゾーンが あります。 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 ゾーン境界線はリンクにではなくノードにあります。(グローバルゾーン が境界線を持たず、そしてインタフェースローカルなゾーンの境界線がた だ1つのインタフェースを含む事に注意してください。) 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上の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つのゾーンに 属します。インタフェースは、どんな種類のユニキャストアドレスを持つか や、ノードがインタフェース上でどのマルチキャストグループに加わるかに 関わらず、範囲ゾーンに属することを意味することに注意してください。 6. Zone Indices 6. ゾーンインデックス 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上の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. 実装がそれぞれの範囲で「デフォルト」ゾーンの概念をサポートするべきで す。そして、サポート時は、それぞれの範囲でゼロのインデックス値は「デ フォルトゾーンを使ってください」ということを意味するために予約される べきです(SHOULD)。他のゾーンインデックスと異なり、デフォルトインデッ クスは範囲を含んでいません、そして範囲はデフォルトインデックスに伴う アドレスによって決定されます。実装がそれぞれの範囲のために個々のデフォ ルトゾーンを定義するかもしれません。それらのデフォルトインデックスは、 ノードが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. それで手動設定は、1つのリンクに多数のインタフェースを持つ、あるいは 異なる(マルチキャストのみの)範囲のゾーンへのインタフェースを持つノー ドの場合といった、一般的でない場合にだけ必要であるでしょう。 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で例証される通りでしょう。それから手動の設定が必要でしょう、例え ば2つのイーサネットインタフェースに図1で示されるのと同じリンクイン デックスを割り当てるでしょう。 --------------------------------------------------------------- | 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に示 された例で、実装は自動的に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つだけの ノード(例えば、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だけを含むと考え てください。この設定は、管理ローカル範囲はサイトローカル範囲より小さ いので、対応する管理者ローカル範囲(すなわち、マルチキャスト「範囲」 値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 to those that can be represented by the sin6_scope_id field of the sockaddr_in6 structure. 上記の例で各範囲のゾーンに1から順にインデックス値を割り当てています が、ゾーンインデックス値は任意です。すべての範囲のそれぞれのゾーンの インデックス値がノード内で一意である限り、実装が選択する任意の値でゾー ンにラベルを付けます。ゼロがデフォルトゾーンを表すために留保されるべ きです(SHOULD)。推薦された基本的なAPI[10]に従うことに決めている実 装はインデックス値をsockaddr_in6構造体のsin6_scope_idフィールドで表 せるものに制限することを望むでしょう。 7. Sending Packets 7. パケット送信 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. (それぞれのインタフェースがそれぞれの範囲の複数のゾーンに接続しない ので)、外向インタフェースの識別子が意図するゾーンを識別するのに十分 であるが、多くの場合これは望ましいというより仕様です。例えば、意図す るリンクに複数のインタフェースを持つノード(異常な設定)からリンクロー カルユニキャストアドレスに送るとき、上位レイヤプロトコルはそれらのイ ンタフェースのどちらが送信のために使われるか気にしないかもしれません。 どちらかと言えば、その選択をIP層のルーティング機能に残すことを好む でしょう。それで、グローバルでない非ループバックの宛先アドレスに送信 をするとき、上位レイヤはゾーンインデックスを指定する能力を必要としま す。 8. Receiving Packets 8. パケット受信 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層が到着しているソースと 宛先アドレスに対し到着インタフェース識別子のほかに、上位レイヤに、正 しいゾーンインデックスを伝えることは勧められます。 9. Forwarding 9. 転送 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]が 元のパケットのソースに送られます。[4]でコード2が割り当てられていな いままであるが、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. たとえユニキャストサイトローカルアドレスが廃止されるとしても、上記手 順がまだリンクローカルアドレスに当てはまることに注意してください。そ れで、もしルータが到着リンクのルータ自身のリンクローカルアドレスでな いリンクローカル宛先アドレスのパケットを受信するなら、ルータはパケッ トをそのリンク上の目的地に転送しようとすることを期待されます(近隣探 索プロトコル[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: 自分自身宛で、1以上の残セグメントのルーティングヘッダ([3]の4.4章) を持つパケットを受信したノードは、ルーティングヘッダの次のアドレスの 範囲を検査します。もし次のアドレスの範囲が元の宛先アドレスの範囲より 小さいなら、ノードはパケットを捨てなくてはなりません(MUST)。さもなけ れば、元の宛先アドレスとルーティングヘッダの次のアドレスを交換します。 それから上記の転送規則は次のように適用されます: 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. 一般に勧められないけれども、、前の次のアドレスフィールドを使ってゾー ン境界線を越えてグローバルでないアドレスを伝えるためルーティングヘッ ダを使うことが、可能であることを指摘します。例えば、リンク境界ノード (例えば、ルータ)が、宛先がリンクローカルアドレスでソースがグローバ ルアドレスの状態のパケットを受信する場合を考慮してください。もしパケッ トが、次のアドレスがグローバルアドレスであるルーティングヘッダを含む なら、グローバルアドレスへの次の転送先インタフェースは元の宛先と異な るリンクに属するかもしれません。次のアドレスの範囲が元の目的地の範囲 より小さくないから、これは許されます。 10. Routing 10. ルーティング 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. ルーティングプロトコルがゾーン境界で動作しているとき、ゾーン間の完全 性を守り、ゾーン内の接続性を維持しなくてはなりません(MUST)。 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 o インタフェース1 * All global groups * すべてのグローバルグループ * All organization groups learned from Interfaces 1, 2, and 3 * インタフェース1と2と3から学んだすべての組織グループ o Interface 2 o インタフェース2 * All global groups * すべてのグローバルグループ * All organization groups learned from Interfaces 1, 2, and 3 * インタフェース1と2と3から学んだすべての組織グループ o Interface 3 o インタフェース3 * All global groups * すべてのグローバルグループ * All organization groups learned from Interfaces 1, 2, and 3 * インタフェース1と2と3から学んだすべての組織グループ o Interface 4 o インタフェース4 * All global groups * すべてのグローバルグループ * All organization groups learned from Interface 4 * インタフェース4から学んだすべての組織グループ o Interface 5 o インタフェース5 * All global groups * すべてのグローバルグループ * All organization groups learned from Interface 5 * インタフェース5から学んだすべての組織グループ By imposing route exchange rules, zone integrity is maintained by keeping all zone-specific routing information contained within the zone. ルート交換規則が課すことにで、すべてのゾーンに固有なルーティング情報 をゾーン内に留める事で、ゾーン完全性が維持されます。 11. Textual Representation 11. テキスト表記 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のグローバルでないアドレ スを指定するために、意図された範囲ゾーンが指定されるべきです。普通の 表記法として範囲ゾーンを指定するために、実装が次のフォーマットをサポー トするべきです(SHOULD): <address>%<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. 次の章は詳細な定義と、具体的な例と、フォーマットの追加の注釈を記述し ます。 11.1. Non-Global Addresses 11.1. グローバルでないアドレス 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>が、アドレスが特定されていないアド レスの場合、範囲がないので、フォーマットの使用法を指定しません しかし ながらこの文書は、実装が実装に依存する目的のためにこれらの特別なアド レスのためのフォーマットを使うことを禁じません。 11.2. The <zone_id> Part 11.2. <zone_id>部 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を表すために、実装は読みやすい "link"範囲を含む他の表現ではなく、<zone_id>としてただ"2"を使うことが できます。 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>は除くことができます。同様に、<default ID>をその <address>の範囲のデフォルトゾーンインデックスとするとき、もしIPv6 アドレスのテキスト表記がゾーンインデックスなしで与えられるなら、 <address>%<default 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>として他の種類の非空白文字列をサポートするかもしれま せん(MAY)。しかしながら、文字列は区切り文字と矛盾してはなりません。 追加の文字列の正確なフォーマットと意味は実装に依存します。 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章参照)。それ故、フォーマットはノード内で使わなくてはならず(MUST)、 そして、フォーマットを翻訳するすべてのノードが意味について合意しない なら、ワイヤ上で送ってはなりません(MUST NOT)。 11.3. Examples 11.3. 例 The following addresses 次のアドレスは fe80::1234 (on the 1st link of the node) (ノードの第1番目のリンクで) ff02::5678 (on the 5th link of the node) (ノードの第5番目のリンクで) ff08::9abc (on the 10th organization of the node) (ノードの第10番目の組織で) 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".) (ここで我々は、任意の範囲のN番目のゾーンが"N"に変換される、ゾーンイ ンデックスから<zone_id>部への自然な翻訳を想定します。) 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番目の組織に属します。 11.4. Usage Examples 11.4. 使用法例 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にログインを試みます。この場合、例えばtelnetに、R2のリンクローカ ルアドレスを与えなければなりません。ここで我々はアドレスがfe80::2であ ると想定します。 Note that we cannot just type 我々が以下のタイプだけではいけないことに注意してください % 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 where "3" after the delimiter character `%' corresponds to the link index of the point-to-point link. 区切り文字`%'の後の"3"がポイント対ポイントリンクのリンクのインデック スに対応します。 11.5. Related API 11.5. 関連API 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]。 11.6. Omitting Zone Indices 11.6. ゾーンインデックスの省略 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>"部を除くことができます。結果として、まったく拡張フォーマッ トをサポートしないかのように振る舞うことができます。 11.7. Combinations of Delimiter Characters 11.7. 区切り文字の組み合わせ 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プレフィックスの構文を定義し ます。もしプレフィックスのアドレス部がグローバルでなく、その範囲ゾー ンのあいまいさがなければ、アドレス部がフォーマットにあるべきです (SHOULD)。例えば、2番目のリンク上のリンクローカルプレフィックス fe80::/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]が区切り文字(`%')をエスケープ文字と定義しますか ら、グローバルでないアドレスのためのフォーマットはURI構文と対立す るかもしれません。この対立は、例えば、区切り文字を持つゾーン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アドレスの好ましいフォーマットと組み合わせられる べきであるか明示しません。いずれにしても、完全指定DNS名が利用可能 であるときはURLで文字のIPv6アドレスを使う代わりに完全指定DNS名 を使うことが推奨されます。 12. Security Considerations 12. セキュリティの考察 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メッセージ がグローバルアドレス上で運ばれるとき、リンクローカルアドレスがインター ネット鍵交換(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. グローバルでないアドレスのテキスト表記の使用が1つのノードの内での使 用に限定されているので、それはノードの外からのセキュリティの弱点を生 成しません。しかしながら、悪意があるノードが、グローバルでないアドレ スのゾーンに関して、受信ノードをだますつもりで、ゾーンインデックスを 含む文字のIPv6のグローバルでないアドレスを含むパケットを送るかも しれません。それで、データとして文字のグローバルでないアドレスを含む パケットを受け取るとき、実装が注意深くあるべきです。 13. Contributors 13. 貢献者 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. この文書はいくつかの個々の努力の組み合わせです。Atsushi Onoeは重要な 役割をして、別個の提案の共著者として深く11章の内容に貢献しました。 14. Acknowledgements 14. 謝辞 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作業部会の多くのメンバがこの文書の上に有用なコメントとフィー ドバックを提供しました。特に、Margaret WassermanとBob Hindenは作業部 会をIPv6ローカルアドレスの意見一致に導きました。Richard Dravesは 範囲アドレスを含むルーティングヘッダの処理の規則を提案しました。 Dave ThalerとFrancis Dupontが、関連したAPIに関してゾーンインデック スの語義を定義する貴重な提案を与えました。Pekka Savolaは非常に慎重に 文書の版を再検討して、そして重大な問題についての詳細なコメントをしま した。Steve BellovinとTed HardieとBert WijnenとTimothy Gleesonは出版 のための準備の間に文書を改善に手を貸しました。 15. References 15. 参考文献 15.1. Normative References 15.1. 参照する参考文献 [1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [4] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. 15.2. Informative References 15.2. 有益な参考文献 [5] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004. [6] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [7] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of Link-Local IPv4 Addresses", Work in Progress. [8] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [9] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [10] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [11] Gilligan, R., "Scoped Address Extensions to the IPv6 Basic Socket API", Work in Progress, July 2002. [12] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999. [13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005. Authors' Addresses 著者のアドレス 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 Phone: +1-443-778-1319 EMail: brian@innovationslab.net Tatuya Jinmei Corporate Research & Development Center, Toshiba Corporation 1 Komukai Toshiba-cho, Saiwai-ku Kawasaki-shi, Kanagawa 212-8582 Japan Phone: +81-44-549-2230 Fax: +81-44-520-1841 EMail: jinmei@isl.rdc.toshiba.co.jp 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 Brian D. Zill Microsoft Research One Microsoft Way Redmond, WA 98052-6399 USA Phone: +1-425-703-3568 Fax: +1-425-936-7329 EMail: 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. この文書は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. この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献 者が代表するか貢献者を後援する組織(もしあれば)とインターネット学会 とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情 報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で ある事の保障を含め、全ての保証を拒否します。 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文書の権利に関する手続 きの情報はBCP78とBCP79を見てください。 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の写しと、利用可能な許可証と、仕様書 の実装者や利用者によってされた一般的な許可書や許可を得るためにされた 試みの結果は、http://www.ietf.org/iprにあるIETFオンライン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-ipr@ietf.orgのIETFに情報を伝えてください。 Acknowledgement 謝辞 Funding for the RFC Editor function is currently provided by the Internet Society. RFCエディタ機能のための資金供給が現在インターネット学会によって 供給されます。