RFC4007 日本語訳
4007 IPv6 Scoped Address Architecture. S. Deering, B. Haberman, T.Jinmei, E. Nordmark, B. Zill. March 2005. (Format: TXT=53555 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループS.デアリングの要求をネットワークでつないでください: 4007年のシスコシステムズカテゴリ: 2005年の標準化過程B.ハーバーマンのジョーンズホプキンUniv T.Jinmei東芝のE.Nordmarkサン・マイクロシステムズB.Zillマイクロソフト行進
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).
Copyright(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ワーキンググループにおける決定によると、このドキュメントは故意にユニキャストのサイトローカルのアドレスの構文と用法を避けます。
Deering, et al. Standards Track [Page 1] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[1ページ]RFC4007IPv6
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 定義. . . . . . . . . . . . . . . . . . . . . . . . 3 3。 基本的な用語. . . . . . . . . . . . . . . . . . . . . 3 4。 範囲. . . . . . . . . . . . . . . . . . . . . . . 3 5を記述してください。 範囲ゾーン. . . . . . . . . . . . . . . . . . . . . . . . 4 6。 ゾーンインデックスリスト. . . . . . . . . . . . . . . . . . . . . . . . 6 7。 パケット. . . . . . . . . . . . . . . . . . . . . . 11 8を送ります。 パケット. . . . . . . . . . . . . . . . . . . . . 11 9を受けます。 推進. . . . . . . . . . . . . . . . . . . . . . . . . 11 10。 ルート設定. . . . . . . . . . . . . . . . . . . . . . . . . . 13 11。 原文の表現. . . . . . . . . . . . . . . . . . . 15 11.1。 非グローバルなアドレス. . . . . . . . . . . . . . . . 15 11.2。 <ゾーン_イド>一部。 . . . . . . . . . . . . . . . . . 15 11.3. 例。 . . . . . . . . . . . . . . . . . . . . . . 17 11.4. 使用例。 . . . . . . . . . . . . . . . . . . . 17 11.5. 関連API. . . . . . . . . . . . . . . . . . . . . 18 11.6。 ゾーンインデックスリスト. . . . . . . . . . . . . . . . 18 11.7を省略します。 デリミタキャラクターの組み合わせ。 . . . . . . . . 18 12. セキュリティ問題. . . . . . . . . . . . . . . . . . 19 13。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . 20 14。 承認. . . . . . . . . . . . . . . . . . . . . . 20 15。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 20 15.1。 引用規格. . . . . . . . . . . . . . . . . 20 15.2。 有益な参照. . . . . . . . . . . . . . . . 21作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 22の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . 24
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インターネットで非グローバルなアドレシングを操作上導入しましたが、個人的の使用における両方がスペースを記述する、(「ネットの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
現在のアドレス体系仕様[1]はユニキャストのサイトローカルのアドレスを定義しますが、IPv6ワーキンググループは、構文と用法[5]を非難すると決めて、現在、他のフォームのローカルのIPv6アドレシングを調査しています。 どんな新しいフォームの使用法
Deering, et al. Standards Track [Page 2] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[2ページ]RFC4007IPv6
local addresses will be documented elsewhere in the future. Thus, this document intentionally focuses on link-local and multicast scopes only.
ローカルのアドレスは将来、ほかの場所に記録されるでしょう。 したがって、このドキュメントは故意にリンク地方とマルチキャスト範囲だけに焦点を合わせます。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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の「any」のアドレスを表すのにしばしば不特定のアドレスを使用します。 この場合、実現は、与えられた特定の範囲で不特定のアドレスを「範囲のどんなアドレスも」の概念を表すと見なすかもしれません。 それが実現の中で制限される限り、このドキュメントはそのような用法を禁止しません。
Deering, et al. Standards Track [Page 3] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[3ページ]RFC4007IPv6
[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に関して構造を記述してください。 しかしながら、まるでそれらには便宜のための他の範囲があるかのように実現はそれらのアドレスを使用するかもしれません。 例えば、IPv4への[6]案配リンクローカル範囲はリンクローカルのアドレスを自動構成しました。(IPv4によって写像されたIPv6へのそれらのアドレスが目的地を実行するために演説する接頭語169.254.0人の.0/16[7])と転向者からのアドレスは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.
Anycastアドレス[1]は、ユニキャストアドレス空間から割り当てられて、ユニキャストアドレスと同じ範囲資産を持っています。 本書ではユニキャストに関するすべての声明が等しくanycastに適用されます。
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つの範囲がトポロジーの全く同じ領域をカバーするかもしれません。 例えば、(マルチキャスト)サイトは単一のリンクから成るかもしれません。そこでは、事実上、リンク地方の、そして、サイト地方の両方の範囲が同じ位相的な長さをカバーします。
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.
範囲ゾーン、または単にゾーンが与えられた範囲のトポロジーの接続領域です。 例えば、特定の(マルチキャスト)サイトの中でルータによって接続されたリンクのセット、およびそれらのリンクに取り付けられたインタフェースはマルチキャストのサイト地方の範囲のただ一つのゾーンを包括します。
Deering, et al. Standards Track [Page 4] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[4ページ]RFC4007IPv6
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 同じ範囲のゾーンは重なることができません。 すなわち、それらはどんなリンクもインタフェースも共通であることができません。
Deering, et al. Standards Track [Page 5] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[5ページ]RFC4007IPv6
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.
同じ非グローバルアドレスが同じ範囲(例えば、リンクローカルアドレスfe80の使用: : 2個の別々の物理的なリンクの1)の1つ以上のゾーンで使用中であるかもしれなく、ノードで同じ範囲の異なったゾーンにインタフェースを付けるかもしれないので(例えば、ルータで、通常、複数のインタフェースを異なったリンクに付けます)、ノードは非グローバルアドレスがどのゾーンに属するかを特定する内部の手段を必要とします。 ノードの中でそのノードが付けている同じ範囲の各ゾーンに異なった「ゾーンインデックス」を割り当てて、アドレスのすべての内部の用途がゾーンインデックスによって資格があるのを許容することによって、これは達成されます。
Deering, et al. Standards Track [Page 6] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[6ページ]RFC4007IPv6
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
--------------------------------------------------------------- | ノード| | | | | | | | | | | | | | /--link1--\/--------link2--------\/--link3--\/--link4--\| | | | /--intf1--\/--intf2--\/--intf3--\/--intf4--\/--intf5--\| --------------------------------------------------------------- : | | | | : | | | | : | | | | (ポイントへのイーサネットトンネルがリンクするポイントa想像する=========ループバック) リンク
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つのリンクローカルのゾーンにしか添付されません。 また、トンネルのインタフェースがイーサネットの上で設置されても、トンネルのリンクがそれ自身の連環指数を得ることに注意してください。(連環指数はイーサネットリンクゾーンのインデックスと異なっています)。
Deering, et al. Standards Track [Page 7] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[7ページ]RFC4007IPv6
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.
特定の範囲のそれぞれのゾーンインデックスは範囲を示すことができるくらいの情報を含むべきです、すべての範囲のすべてのインデックスリストがノードの中でユニークであり、ひたむきな目的にゾーンインデックスリスト自体は使用できるように。 Management Information基地(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.
その時、手動の構成が単に異なった(マルチキャスト唯一の)範囲のゾーンへのインタフェースがある単一のリンクへの複数のインタフェースがあるノードかそれらの、より少ないよくある例に必要でしょう。
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に示されるように。
Deering, et al. Standards Track [Page 8] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[8ページ]RFC4007IPv6
---------------------------------------------------------------
| a node |
| |
| |
| |
| |
| |
| /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ |
| |
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
---------------------------------------------------------------
: | | | |
: | | | |
: | | | |
(imaginary ================= a point- a
loopback an Ethernet to-point tunnel
link) link
--------------------------------------------------------------- | ノード| | | | | | | | | | | | /--link1--\/--link2--\/--link3--\/--link4--\/--link5--\| | | | /--intf1--\/--intf2--\/--intf3--\/--intf4--\/--intf5--\| --------------------------------------------------------------- : | | | | : | | | | : | | | | (ポイントへのイーサネットトンネルがリンクするポイントa想像する=========ループバック) リンク
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.
初めは上で指定されるとしてゾーンインデックスリストを割り当てることと同様に、実現は自動的にアドレスがゾーンインデックス(またはゼロのゾーンインデックスで)なしで指定されるときはいつも、使用されるために1つ以上の選択がある各範囲にデフォルトゾーンを選択するべきです。 例えば、図2の例では、実現は自動的にintf2を選択するかもしれません、そして、それぞれのそれらの2のデフォルトゾーンとしての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はいつもループバックインタフェースを含むリンクローカルのゾーンを示すでしょう。 他のすべての資格のないリンクローカルのアドレスが非ループバックインタフェースを含むリンクローカルのゾーンを示すでしょう(長くデフォルトとしてのリンクローカルのゾーンが非ループバックインタフェースを含むゾーンであるように設定されたとき)。
Deering, et al. Standards Track [Page 9] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[9ページ]RFC4007IPv6
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.Thusより小さいすべての範囲の異なったゾーンに割り当てなければならなくて、1つの範囲への異なったゾーンインデックスリストの手動の課題は異なったゾーンインデックスリストの自動課題をより小さい範囲に必要とするかもしれません。 例えば、異なったマルチキャストサイトローカルのインデックスリスト1と2が図1で手動で割り当てられて、サイト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
--------------------------------------------------------------- | ノード| | | | | | | | | | | | /--------------------site1--------------------\/--site2--\| | | | /-------------------admin1--------------------\/-admin2--\| | | | /--link1--\/--------link2--------\/--link3--\/--link4--\| | | | /--intf1--\/--intf2--\/--intf3--\/--intf4--\/--intf5--\| --------------------------------------------------------------- : | | | | : | | | | : | | | | (ポイントへのイーサネットトンネルがリンクするポイントa想像する=========ループバック) リンク
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
上記の例は、ゾーンはインデックス値を1から各範囲に連続して割り当てられるのを示しますが、ゾーンインデックス値は任意です。 実装はそれが選ぶどんな値でもゾーンをラベルするかもしれません、すべての範囲のそれぞれのゾーンのインデックス値がノードの中でユニークである限り。 SHOULDのゼロを合わせてください。デフォルトゾーンを表すために、予約されます。 お勧めの基本的なAPI[10]に続くのを選ぶ実装はそれらのインデックス値を制限したくなるでしょう。
Deering, et al. Standards Track [Page 10] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[10ページ]RFC4007IPv6
to those that can be represented by the sin6_scope_id field of the sockaddr_in6 structure.
sockaddr_in6構造のsin6_範囲_イド分野で表すことができるものに。
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.
上側の層のプロトコルが非グローバルな送付先アドレスにパケットを送るとき、それには、ノードが送付先アドレスsの範囲の1つ以上のゾーンに添付される場合のために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つ未満のゾーンに付けられているので)、多くの場合、それは望まれているより特定です。 1つ以上のインタフェースを持っているノードから意図しているリンク(珍しい構成)までリンクローカルのユニキャストアドレスに発信するとき、例えば、上側の層のプロトコルは気にかけられないかもしれません(トランスミッションにそれらのインタフェースについて使用されます)。 むしろ、それは、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を見てください)。 その経路指定テーブルは、そのゾーンに属すインタフェースについて言及するために制限されます。
Deering, et al. Standards Track [Page 11] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[11ページ]RFC4007IPv6
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 次のホップインタフェースが選ばれた後に、ソースアドレスのゾーンは考えられます。 送付先アドレスのように、ソースアドレスのゾーンはパケットのアドレスと到着インタフェースの範囲のそばで決定しています。 選ばれた次のホップの上でパケットを伝えるなら、パケットはインタフェースでソースアドレスの範囲のゾーン境界をすなわち、ソースアドレスのゾーン、十字に残して、次に、パケットは捨てられます。 さらに、パケットの送付先アドレスがユニキャストアドレスであるなら、Code2(「ソースアドレスの範囲」の)があるICMP Destination Unreachableメッセージ[4]をオリジナルのパケットの源に送ります。 Code2が現在、[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つでないリンクローカルの送付先アドレスでパケットを受けるなら、ルータがそのリンクの上の目的地にパケットを送ろうとすると予想されます。(目的地のリンクレイヤのうまくいっている決断を条件として、Neighborを通してディスカバリーがプロトコル[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:
パケットを受けるノードは、ゼロ以上があるHeaderがSegments Leftであるとそれ自体とルート設定を含むのに扱いました。([3])のセクション4.4は最初に、ルート設定Headerの次のアドレスの範囲をチェックします。 次のアドレスの範囲がオリジナルの送付先アドレスの範囲より小さいなら、ノードはパケットを捨てなければなりません。 さもなければ、それはルート設定Headerにおける次のアドレスでオリジナルの送付先アドレスを交換します。 次に、上の推進規則は以下の通り適用されます:
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
次のアドレスの範囲の周りのこのチェックが、パケットが最終的な目的地に到着するとき、その目的地がリンク地方であるなら受信ノードがそれを知ることができるのを確実にする、パケット
Deering, et al. Standards Track [Page 12] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[12ページ]RFC4007IPv6
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.
それが次の以前中古のアドレス・フィールドの関連ゾーン境界の向こう側に非グローバルアドレスを伝えるのにルート設定Headerを使用するために可能であって、もっとも、一般に、勧められないことに注意してください。 例えば、リンク境界ノード(例えば、ルータ)がリンクローカルアドレスである目的地でパケットを受ける場合、およびソースアドレスがグローバルアドレスであると考えてください。 パケットが次のアドレスがグローバルアドレスであるルート設定Headerを含んでいるなら、グローバルアドレスへの次のホップインタフェースは元の目的地のものと異なったリンクに属すかもしれません。 次のアドレスの範囲が元の目的地の範囲ほど小さくないので、これは許容されています。
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.
ルーティング・プロトコルが、ゾーン境界を作動させていることを決定すると、それは、相互ゾーン保全を保護して、イントラゾーンの接続性を維持しなければなりません。
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.
相互ゾーン保全を保護するために、ルータは隣接しているルータと共有されたグループ情報で選択していなければなりません。 ルータはきまりきって隣接しているルータとルーティング情報を交換します。 ルータがこのルーティング情報を伝えているとき、それは情報を伝えるのに使用されるインタフェースに割り当てられたゾーン以外のゾーンの少しの情報も含んではいけません。
Deering, et al. Standards Track [Page 13] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[13ページ]RFC4007IPv6
* *
* *
* =========== Organization X *
* | | *
* | | *
+-*----|-------|------+ *
| * intf1 intf2 | *
| * | *
| * intf3 --- *
| * | *
| ***********************************
| |
| Router |
| |
********************** **********************
| * * |
Org. Y --- intf4 * * intf5 --- Org. Z
| * * |
********************** **********************
+---------------------+
* * * * * =========== 組織X**| | * * | | * +-*----|-------|------+ * | * intf1 intf2| * | * | * | * intf3--- * | * | * | *********************************** | | | ルータ| | | ********************** ********************** | * * | 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*はすべて、すべての組織グループがInterfaces1、2、および3から学んだグローバルなグループ*です。
o Interface 2
* All global groups
* All organization groups learned from Interfaces 1, 2, and 3
o インタフェース2*はすべて、すべての組織グループがInterfaces1、2、および3から学んだグローバルなグループ*です。
o Interface 3
* All global groups
* All organization groups learned from Interfaces 1, 2, and 3
o インタフェース3*はすべて、すべての組織グループがInterfaces1、2、および3から学んだグローバルなグループ*です。
o Interface 4
* All global groups
* All organization groups learned from Interface 4
o インタフェース4*はすべて、すべての組織グループがInterface4から学んだグローバルなグループ*です。
o Interface 5
* All global groups
* All organization groups learned from Interface 5
o インタフェース5*はすべて、すべての組織グループがInterface5から学んだグローバルなグループ*です。
Deering, et al. Standards Track [Page 14] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[14ページ]RFC4007IPv6
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,
<アドレス>は文字通りのIPv6アドレスです。
<zone_id> is a string identifying the zone of the address, and
そして<ゾーン_イド>がアドレスのゾーンを特定するストリングである。
`%' is a delimiter character to distinguish between <address> and
<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.
不特定のアドレスを除いて、形式はすべての種類のユニキャストと非グローバルな範囲のマルチキャストアドレスに適用されます。(それは、範囲を持っていません)。 形式を無意味であり、グローバルなアドレスに使用するべきではありません。 ループバックアドレスは些細なリンクに属します。 すなわち、リンクはループバックインタフェースに付きました。 したがって、ループバックアドレスに形式を使用するべきではありません。 <アドレス>が不特定のアドレスであるときに、このドキュメントは形式の用法を指定しません、アドレスに範囲がないとき。 しかしながら、このドキュメントは特別なそれらのための形式が実装のために依存する目的を扱う使用から実装を禁じません。
11.2. The <zone_id> Part
11.2. <ゾーン_イド>一部
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.
原文の表現では、<ゾーン_イド>一部がアドレスsの範囲の特定のゾーンを特定できるべきです。 範囲を決定できるくらいの情報を保管して、ゾーンインデックスがセクション6で説明されるようにすべての範囲の中で特有であることが期待されますが、この形式の<ゾーン_イド>一部分が範囲を含む必要はありません。 これは<アドレスの>一部が適切な範囲を指定するべきであるからです。 また、これは、<ゾーン_イド>一部がすべての範囲の中で特有である必要はないことを意味します。
Deering, et al. Standards Track [Page 15] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[15ページ]RFC4007IPv6
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.
この緩められた特性で、実装は<ゾーン_イド>として便利な表現を使用できます。 例えば、連環指数2を表すために、実装は単に「「リンク」範囲を含む他の表現より読み込み可能であるだろうという<ゾーン_イド>としての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.)
実装が形式を解釈するとき、「完全な」ゾーンインデックスを構成するべきです、<ゾーン_イド>一部と<アドレスの>一部によって指定された範囲から。(インデックスは範囲を含みます)。 (セクション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.
SHOULDが<ゾーン_イド>として少なくとも非負の10進整数である数字のインデックスリストをサポートする実装。 デフォルトゾーンインデックス(通常、0であるべきである(セクション6を見る))は整数に含まれています。 <ゾーン_イド>がデフォルトと、デリミタキャラクタ「%」と<ゾーン_イドであるときに、>を省略できます。 同様に、ゾーンインデックスなしで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.
実装は<ゾーン_イド>として他の種類の非ヌルストリングを支えるかもしれません。 しかしながら、ストリングはデリミタキャラクタと衝突してはいけません。 追加ストリングの正確な形式と意味論は実装に依存しています。
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人の可能な候補がインタフェース名でしょう。 特に、インタフェースとリンクに「デフォルト識別子」としてインタフェース名を使用できます、インタフェースとそれぞれのそれらの範囲の間には、1〜1つのマッピングがデフォルトでセクション6で説明されるようにあるので。
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.
また、実装はリンクより大きい範囲に<ゾーン_イド>としてインタフェース名を使用するかもしれませんが、この使用における何らかの混乱があるかもしれません。 1つ以上のインタフェースが同じ(マルチキャスト)サイトに属すとき、例えば、どのインタフェースが使用されるべきであるかに関してユーザは混乱するでしょう。 また、ゾーンインデックスとしてインタフェース名でアドレスを印刷するとき、アドレスから名前までのマッピング機能は同じ種類の問題に行きあたるでしょう。 このドキュメントは、これらのケースがどう扱われるべきであるかを指定しないで、それを実装に依存していた状態でおきます。
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を見てください)思うことができません。 したがって、形式を解釈するあらゆるノードが意味論に同意するというわけではないなら、形式をノードだけの中で使用しなければならなくて、ワイヤに送ってはいけません。
Deering, et al. Standards Track [Page 16] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[16ページ]RFC4007IPv6
11.3. Examples
11.3. 例
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)
fe80:、:1234(ノードの最初のリンクの)ff02:、:5678(ノードの5番目のリンクの)ff08:、:9abc(ノードの10番目の組織での)
would be represented as follows:
以下の通り表されるでしょう:
fe80::1234%1
ff02::5678%5
ff08::9abc%10
fe80:、:1234%の1ff02:、:5678%の5ff08:、: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".)
(ここで、私たちは自然なゾーンインデックスからどんな範囲のNthゾーンも「N」に翻訳される<ゾーン_イド>一部までの翻訳を仮定します。)
If we use interface names as <zone_id>, those addresses could also be represented as follows:
また、私たちが<ゾーン_イド>としてインタフェース名を使用するなら、それらのアドレスは以下の通り表されるかもしれません:
fe80::1234%ne0
ff02::5678%pvc1.3
ff08::9abc%interface10
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"が最初のリンクに属すか、「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に持っていることを期待できないので。
Deering, et al. Standards Track [Page 17] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[17ページ]RFC4007IPv6
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に1つ以上があるので、リンクしてください。そうすれば、したがって、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インチはリンクする」ところ。
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への拡大は非グローバルなアドレスのための形式がどう扱われて、aを翻訳するライブラリ関数では[11]に逆もまた同様にアドレスにnodenameされているということであるべきであるかを定義します。
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、デフォルトゾーンインデックスの概念があるいくつかのよくある例で説明されるように、範囲ゾーンに関してあいまいさが全くあるはずがありません。 」 %<は_イド>を区分します。「そのような環境で、実装が省略されることができる、」 部分。 その結果、それはまるで全く拡張フォーマットをサポートしないかのように行動できます。
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:
また、アーキテクチャが[1]であると扱うIPv6はIPv6接頭語の構文を定義します。 接頭語のアドレスの部分が非グローバルであるか、そして、範囲ゾーンはあいまいさを除かれるべきであり、アドレスの部分SHOULDは形式においてそうです。 例えば、リンク地方の接頭語fe80:、:以下の通り2番目のリンクの/64を表すことができます:
fe80::%2/64
fe80:、:%2/64
Deering, et al. Standards Track [Page 18] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[18ページ]RFC4007IPv6
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.
また、IPv6がURLで扱うリテラルのための都合のよい書式は定義されます。[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をワイヤに送ります、そして、アプリケーションが発信する前に<ゾーン_イド>部分を剥取らないなら、それは混乱を引き起こすでしょうに。 アプリケーションがそれらが使用しているアドレスのどの種類を心配する必要はないはずであるかに注意してください、まして、アドレスの<ゾーン_イド>部分を分析するか、または取り除いてください。
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への<ゾーン_イド>一部が'%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アドレスのための都合のよい形式に結合されるべきであるかを指定しません。 どのような場合でも、URLの文字通りのIPv6アドレスの代わりにFQDNを使用するのはお勧めです、FQDNが利用可能であるときはいつも。
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
このドキュメントのルーティング部はルータがゾーン特殊情報が各ゾーンから漏れるのを防ぐことができるマニュアルを指定します。 例えば、マルチキャストであるなら、境界ルータを位置させてください。
Deering, et al. Standards Track [Page 19] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[19ページ]RFC4007IPv6
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を含むパケットを送るかもしれません、非グローバルアドレスのゾーンに関する受信ノードをごまかすつもりであり。 データとして原文の非グローバルなアドレスを含むパケットを受けるとき、したがって、実装は慎重であるはずです。
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.
このドキュメントはいくつかの別々の取り組みの組み合わせです。 尾上篤は、それらの1つで重要な役割を取って、別々の提案の共著者として深くセクション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ワーキンググループの多くのメンバーがこのドキュメントの役に立つコメントとフィードバックを提供しました。 特に、マーガレット・ワッサーマンとボブHindenは、ワーキンググループがIPv6に関するコンセンサスをローカルのアドレシングにするように導きました。 リチャードDravesは、見られたアドレスを含むルート設定ヘッダーを処理するために付則を提案しました。 デーヴThalerとフランシス・デュポンは、関連するAPIに関してゾーンインデックスリストの意味論を定義するために貴重な提案を与えました。 ペッカSavolaは非常に慎重にドキュメントのバージョンを見直して、深刻な問題に関して詳細なコメントをしました。スティーブBellovin、テッド・ハーディー、バートWijnen、およびティモシー・グリーソンは、論評して、公表のための準備の間、ドキュメントを改良するのを助けました。
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.
[1]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[3] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[4] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[4] コンタ、A.、およびS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC2463、1998年12月。
Deering, et al. Standards Track [Page 20] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[20ページ]RFC4007IPv6
15.2. Informative References
15.2. 有益な参照
[5] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[5] Huitema、C.、およびB.は2004年9月に「サイトのローカルのアドレスを非難すること」でのRFC3879の大工仕事をします。
[6] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[6]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
[7] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration
of Link-Local IPv4 Addresses", Work in Progress.
[7] チェーシャー州、S.、Aboba、B.、およびE.Guttman、「リンクローカルのIPv4アドレスの動的設定」が進行中で働いています。
[8] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[8] コンタとA.とS.デアリング、「IPv6仕様による一般的なパケットトンネリング」、RFC2473、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.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、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] ギリガンとR.とトムソンとS.とバウンドとJ.とマッキャン、J.とW.スティーブンス、「IPv6"、RFC3493、2003年2月のための基本的なソケットインタフェース拡大。」
[11] Gilligan, R., "Scoped Address Extensions to the IPv6 Basic
Socket API", Work in Progress, July 2002.
[11] ギリガン、R.、「IPv6の基本的なソケットAPIへの見られたアドレス拡大」が進歩、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.、大工、B.、およびL.Masinter、「URLの文字通りのIPv6アドレスのための形式」、RFC2732、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.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC3986、2005年1月。
Deering, et al. Standards Track [Page 21] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[21ページ]RFC4007IPv6
Authors' Addresses
作者のアドレス
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
西タスマン・DriveスティーブンE.デアリングシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)
Brian Haberman Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA
ブライアンハーバーマンジョーンズ・ホプキンス大学応用物理研究所11100のジョーンズ・ホプキン・Road MD20723-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
Tatuya Jinmeiの法人の研究開発センター、東芝1Komukai東芝町、幸区川崎市、日本神奈川212-8582
Phone: +81-44-549-2230 Fax: +81-44-520-1841 EMail: jinmei@isl.rdc.toshiba.co.jp
以下に電話をしてください。 +81-44-549-2230 Fax: +81-44-520-1841 メールしてください: jinmei@isl.rdc.toshiba.co.jp
Erik Nordmark 17 Network Circle Menlo Park, CA 94025 USA
エリックNordmark17ネットワーク円のカリフォルニア94025メンローパーク(米国)
Phone: +1 650 786 2921 Fax: +1 650 786 5896 EMail: Erik.Nordmark@sun.com
以下に電話をしてください。 +1 650 786、2921Fax: +1 5896年の650 786メール: Erik.Nordmark@sun.com
Deering, et al. Standards Track [Page 22] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[22ページ]RFC4007IPv6
Brian D. Zill Microsoft Research One Microsoft Way Redmond, WA 98052-6399 USA
ブライアンのD.Zillマイクロソフト研究1マイクロソフト道ワシントン98052-6399レッドモンド(米国)
Phone: +1-425-703-3568 Fax: +1-425-936-7329 EMail: bzill@microsoft.com
以下に電話をしてください。 +1-425-703-3568 Fax: +1-425-936-7329 メールしてください: bzill@microsoft.com
Deering, et al. Standards Track [Page 23] RFC 4007 IPv6 Scoped Address Architecture March 2005
デアリング、他 2005年のアドレス体系行進のときに見られた標準化過程[23ページ]RFC4007IPv6
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Deering, et al. Standards Track [Page 24]
デアリング、他 標準化過程[24ページ]
一覧
スポンサーリンク
