この文書はRFC3056の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
※pngイメージが４つ入ってるので、コピーする際は忘れずに
Network Working Group B. Carpenter
Request for Comments: 3056 K. Moore
Category: Standards Track February 2001
Connection of IPv6 Domains via IPv4 Clouds
ＩＰｖ４網を経由してのＩＰｖ６ドメインの接続
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
概要
This memo specifies an optional interim mechanism for IPv6 sites to
communicate with each other over the IPv4 network without explicit
tunnel setup, and for them to communicate with native IPv6 domains
via relay routers. Effectively it treats the wide area IPv4 network
as a unicast point-to-point link layer. The mechanism is intended as
a start-up transition tool used during the period of co-existence of
IPv4 and IPv6. It is not intended as a permanent solution.
このメモは、明白なトンネルセットアップ無しでＩＰｖ４ネットワークを通
して相互に通信するＩＰｖ６サイトと、リレールーターによってネイティブ
ＩＰｖ６ドメインと通信するＩＰｖ６サイトのために、任意利用の仮機構を
指定します。これは効率的に広域ＩＰｖ４ネットワークをユニキャストのポ
イントポイントリンク層として取り扱います。この機構はＩＰｖ４とＩＰｖ
６の共存の時期の初期移行ツールとして意図します。これは永久の解と意図
されません。
The document defines a method for assigning an interim unique IPv6
address prefix to any site that currently has at least one globally
unique IPv4 address, and specifies an encapsulation mechanism for
transmitting IPv6 packets using such a prefix over the global IPv4
network.
文書は現在少なくとも１つのグローバルにユニークなＩＰｖ４アドレスを持っ
ているどんなサイトにでも仮のユニークなＩＰｖ６アドレスプレフィックス
を割り当てる方法を定義し、グローバルなＩＰｖ４ネットワーク上でこのよ
うなプレフィックスを使ってＩＰｖ６パケットを伝達するカプセル化メカニ
ズムを指定します。
The motivation for this method is to allow isolated IPv6 domains or
hosts, attached to an IPv4 network which has no native IPv6 support,
to communicate with other such IPv6 domains or hosts with minimal
manual configuration, before they can obtain natuve IPv6
connectivity. It incidentally provides an interim globally unique
IPv6 address prefix to any site with at least one globally unique
IPv4 address, even if combined with an IPv4 Network Address
Translator (NAT).
この方法の動機は、ネイティブＩＰｖ６をサポートしないＩＰｖ４ネット
ワークにつながった孤立しているＩＰｖ６ドメインやホストがネイティブ
ＩＰｖ６接続を得ることができる前に、最小の手動設定で他のＩＰｖ６ド
メインやホストと通信できるようにすることです。これは、ついでに少な
くとも１つのグローバルユニークＩＰｖ４アドレスを持つサイトに、たと
えＩＰｖ４ネットワークアドレス翻訳者（ＮＡＴ）があっても、仮のグロー
バルユニークＩＰｖ６アドレスプレフィックスを供給します。
Table of Contents
目次
1. Introduction
1. はじめに
1.1. Terminology
1.1. 用語
2. IPv6 Prefix Allocation
2. ＩＰｖ６プレフィックス割当
2.1 Address Selection
2.1 アドレス選択
3. Encapsulation in IPv4
3. ＩＰｖ４でのカプセル化
3.1. Link-Local Address and NUD
3.1. リンクローカルアドレスと近隣非接続発見
4. Maximum Transmission Unit
4. 最大伝達単位
5. Unicast scenarios, scaling, and transition to normal prefixes
5. ユニキャストのシナリオ、スケーリング、標準プレフィックスへの移行
5.1 Simple scenario - all sites work the same
5.1 の単純なシナリオ−すべてのサイトが同時に動作
5.2 Mixed scenario with relay to native IPv6
5.2 ネイティブＩＰｖ６へのリレーを持つ混在シナリオ
5.2.1 Variant scenario with ISP relay
5.2.1 ＩＳＰリレーの異なるシナリオ
5.2.2 Summary of relay router configuration
5.2.2 リレールーター設定の要約
5.2.2.1. BGP4+ not used
5.2.2.1. BGP4+を使わない
5.2.2.2. BGP4+ used
5.2.2.2. BGP4+を使う
5.2.2.3. Relay router scaling
5.2.2.3. リレールーターのスケール
5.2.3 Unwilling to relay
5.2.3 好ましくないリレー
5.3 Sending and decapsulation rules
5.3 送信とカプセル解除の規則
5.4 Variant scenario with tunnel to IPv6 space
5.4 ＩＰｖ６空間へのトンネルの異なるシナリオ
5.5 Fragmented Scenarios
5.5 分割シナリオ
5.6 Multihoming
5.6 マルチホーム
5.7 Transition Considerations
5.7 移行の考察
5.8 Coexistence with firewall, NAT or RSIP
5.8 ファイアウォールとＮＡＴとＲＳＩＰの共存
5.9 Usage within Intranets
5.9 イントラネット中での使用。
5.10 Summary of impact on routing
5.10 ルーティングの上の影響の要約
5.11. Routing loop prevention
5.11. 経路ループ防止
6. Multicast and Anycast
6. マルチキャストとエニキャスト
7. ICMP messages
7. ICMP メッセージ
8. IANA Considerations
8. ＩＡＮＡの考察
9. Security Considerations
9. セキュリティの考察。
Acknowledgements
謝辞
References
参考文献
Authors' Addresses
著者のアドレス
Intellectual Property
知的所有権
Full Copyright Statement
著作権表示全文
1. Introduction
1. はじめに
This memo specifies an optional interim mechanism for IPv6 sites to
communicate with each other over the IPv4 network without explicit
tunnel setup, and for them to communicate with native IPv6 domains
via relay routers. Effectively it treats the wide area IPv4 network
as a unicast point-to-point link layer. The mechanism is intended as
a start-up transition tool used during the period of co-existence of
IPv4 and IPv6. It is not intended as a permanent solution.
このメモは、明白なトンネルセットアップ無しでＩＰｖ４ネットワークを通
して相互に通信するＩＰｖ６サイトと、リレールーターによってネイティブ
ＩＰｖ６ドメインと通信するＩＰｖ６サイトのために、任意利用の仮機構を
指定します。これは効率的に広域ＩＰｖ４ネットワークをユニキャストのポ
イントポイントリンク層として取り扱います。この機構はＩＰｖ４とＩＰｖ
６の共存の時期の初期移行ツールとして意図します。これは永久の解と意図
されません。
The document defines a method for assigning an interim unique IPv6
address prefix to any site that currently has at least one globally
unique IPv4 address, and specifies an encapsulation mechanism for
transmitting IPv6 packets using such a prefix over the global IPv4
network. It also describes scenarios for using such prefixes during
the co-existence phase of IPv4 to IPv6 transition. Note that these
scenarios are only part of the total picture of transition to IPv6.
Also note that this is considered to be an interim solution and that
sites should migrate when possible to native IPv6 prefixes and native
IPv6 connectivity. This will be possible as soon as the site's ISP
offers native IPv6 connectivity.
文書は現在少なくとも１つのグローバルにユニークなＩＰｖ４アドレスを持っ
ているどんなサイトにでも仮のユニークなＩＰｖ６アドレスプレフィックス
を割り当てる方法を定義し、グローバルなＩＰｖ４ネットワーク上でこのよ
うなプレフィックスを使ってＩＰｖ６パケットを伝達するカプセル化メカニ
ズムを指定します。これはＩＰｖ４からＩＰｖ６への共存移行時期の間にこ
のようなプレフィックスを使うシナリオを記述します。これらのシナリオが
ＩＰｖ６への移行の完全な絵の一部に過ぎないことを注意を払ってください。
この解決が仮の解決と考えられ、ネイティブＩＰｖ６プレフィックスとネイ
ティブＩＰｖ６接続が可能になったら速やかに移行すべきことに注意してく
ださい。これは、サイトのＩＳＰがネイティブＩＰｖ６接続を提供するとす
ぐに可能になるでしょう。
The basic mechanism described in the present document, which applies
to sites rather than individual hosts, will scale indefinitely by
limiting the number of sites served by a given relay router (see
Section 5.2). It will introduce no new entries in the IPv4 routing
table, and exactly one new entry in the native IPv6 routing table
(see Section 5.10).
この文書で記述する基本的なメカニズムは個別ホストではなくサイトに適用
され、リレールータの提供するサイトの数の制限してスケールします（５.２
章参照）。これはＩＰｖ４ルーティングテーブルの中の新しい項目を作らず、
ネイティブＩＰｖ６ルーティングテーブルに１つの新しい項目を追加します
（５.１０章参照）。
Although the mechanism is specified for an IPv6 site, it can equally
be applied to an individual IPv6 host or very small site, as long as
it has at least one globally unique IPv4 address. However, the
latter case raises serious scaling issues which are the subject of
further study [SCALE].
ＩＰｖ６サイトにメカニズムが指定されるが、これは、少なくとも１つのグ
ローバルにユニークなＩＰｖ４アドレスを持つ、個別のＩＰｖ６ホストや非
常に小さいサイトに適用されます。しかし、後者はスケールの問題があり、
これは研究課題です[SCALE]。
The motivation for this method is to allow isolated IPv6 sites or
hosts, attached to a wide area network which has no native IPv6
support, to communicate with other such IPv6 domains or hosts with
minimal manual configuration.
この方法の動機は、ネイティブＩＰｖ６をサポートしない広域ネットワー
クにつながった孤立しているＩＰｖ６ドメインやホストが、最小の手動設
定で他のＩＰｖ６ドメインやホストと通信できるようにすることです。
IPv6 sites or hosts connected using this method do not require IPv4-
compatible IPv6 addresses [MECH] or configured tunnels. In this way
IPv6 gains considerable independence of the underlying wide area
network and can step over many hops of IPv4 subnets. The abbreviated
name of this mechanism is 6to4 (not to be confused with [6OVER4]).
The 6to4 mechanism is typically implemented almost entirely in border
routers, without specific host modifications except a suggested
address selection default. Only a modest amount of router
configuration is required.
この方法を使うＩＰｖ６サイトやホストはＩＰｖ４コンパチブルＩＰｖ６ア
ドレス[MECH]やトンネル設定が必要ありません。この方法でＩＰｖ６は基礎
の広域ネットワークから独立になり、ＩＰｖ４サブネットの多くのホップを
通ることが出来ます。このメカニズムの省略名は（[6OVER4]と混同されない
ために）６to４です。６to４ メカニズムは、示唆されたアドレス選択デフォ
ルト以外はホスト修正無しで、典型的にほぼ完全に境界ルータに実装されま
す。ただ適度な量のルーター設定だけが必要です。
Sections 2 to 4 of this document specify the 6to4 scheme technically.
Section 5 discusses some, but not all, usage scenarios, including
routing aspects, for 6to4 sites. Scenarios for isolated 6to4 hosts
are not discussed in this document. Sections 6 to 9 discuss other
general considerations.
この文書の２章から４章が技術的に６to４案を指定します。５章が、６to４
サイトのルーティング条件を含めて、ある使い方のシナリオを論じます。孤
立６to４ホストのシナリオがこの文書で論じられません。６章から９章まで
が他の一般的な考察を論じます。
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 [RFC2119].
この文章のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
[RFC2119]で記述されるように解釈します。
1.1. Terminology
1.1. 用語
The terminology of [IPV6] applies to this document.
[IPV6]の専門用語はこの文書に当てはまります。
6to4 pseudo-interface:
6to4 encapsulation of IPv6 packets inside IPv4 packets occurs
at a point that is logically equivalent to an IPv6 interface,
with the link layer being the IPv4 unicast network. This point
is referred to as a pseudo-interface. Some implementors may
treat it exactly like any other interface and others may treat
it like a tunnel end-point.
６to４疑似インタフェース：
リンクレイヤがＩＰｖ４ユニキャストネットワークであるという状態
で、ＩＰｖ４パケット中のＩＰｖ６パケットの６to４カプセル化が、
論理的にＩＰｖ６インタフェースと等しい場所で起こります。この場
所を疑似インタフェースと言います。実装がこれを他のインタフェー
ス同様に扱っても、トンネル終端のように扱ってもよいです。
6to4 prefix:
an IPv6 prefix constructed according to the rule in Section 2
below.
６to４プレフィックス：
２章の規則に従って作られたＩＰｖ６プレフィックス。
6to4 address: an IPv6 address constructed using a 6to4 prefix.
６to４アドレス：
６to４プレフィックスを使って組み立てられたＩＰｖ６アドレス。
Native IPv6 address: an IPv6 address constructed using another type
of prefix than 6to4.
ネイティブＩＰｖ６アドレス：
６to４でないタイプのプレフィックスを使って組み立てられたＩＰｖ６
アドレス。
6to4 router (or 6to4 border router):
an IPv6 router supporting a 6to4 pseudo-interface. It is
normally the border router between an IPv6 site and a wide-area
IPv4 network.
６to４ルーター（６to４境界ルータ）：
６to４疑似インタフェースをサポートしているＩＰｖ６ルーター。こ
れはＩＰｖ６サイトと広域ＩＰｖ４ネットワークの間の通常境界ルー
タです。
6to4 host:
an IPv6 host which happens to have at least one 6to4 address.
In all other respects it is a standard IPv6 host.
６to４ホスト：
少なくとも１つの６to４アドレスを持つＩＰｖ６ホスト。他のすべて
の点でこれは標準ＩＰｖ６ホストです。
Note: an IPv6 node may in some cases use a 6to4 address for a
configured tunnel. Such a node may function as an IPv6 host using a
6to4 address on its configured tunnel interface, and it may also
serve as a IPv6 router for other hosts via a 6to4 pseudo-interface,
but these are distinct functions.
ノート：ＩＰｖ６ノードがある場合には設定されたトンネルで６to４アドレ
スを使うかもしれません。このようなノードは、設定されたトンネルインター
フェース上の６to４アドレスを使うＩＰｖ６ホストとして動作し、６to４疑
似インタフェースによって他のホストのためのＩＰｖ６ルーターの役をする
かもしれませんが、これらは別の機能です。
6to4 site:
a site running IPv6 internally using 6to4 addresses, therefore
containing at least one 6to4 host and at least one 6to4 router.
６to４サイト：
６to４アドレスを内部で使いＩＰｖ６を動作させるサイト、従って少
なくとも１つの６to４ホストと少なくとも１つの６to４ルーターを含
みます。
Relay router:
a 6to4 router configured to support transit routing between
6to4 addresses and native IPv6 addresses.
リレールーター：
６to４アドレスとネイティブＩＰｖ６アドレス間の転送ルーティング
をサポートするように設定された６to４ルーター。
6to4 exterior routing domain:
a routing domain interconnecting a set of 6to4 routers and
relay routers. It is distinct from an IPv6 site's interior
routing domain, and distinct from all native IPv6 exterior
routing domains.
６to４外部ルーティングドメイン：
６to４ルーターとリレールーターの集まりを相互に結び付けるルーティ
ングドメイン。これはＩＰｖ６サイトの内部のルーティングドメイン
と異なり、すべてのネイティブのＩＰｖ６外部ルーティングドメイン
とも異なります。
2. IPv6 Prefix Allocation
2. ＩＰｖ６プレフィックス割当
Suppose that a subscriber site has at least one valid, globally
unique 32-bit IPv4 address, referred to in this document as V4ADDR.
This address MUST be duly allocated to the site by an address
registry (possibly via a service provider) and it MUST NOT be a
private address [RFC 1918].
加入者サイトは、この文書ではV4ADDRと記す、少なくとも１つの正当でグロー
バルにユニークな３２ビットのＩＰｖ４アドレスを持つと考えます。このア
ドレスは（多分サービスプロバイダを通して）正当にアドレスレジストリか
らサイトに割り当てられなくてはならず(MUST)、これはプライベートのアド
レス[RFC 1918]であってはなりません(MUST NOT)。
The IANA has permanently assigned one 13-bit IPv6 Top Level
Aggregator (TLA) identifier under the IPv6 Format Prefix 001 [AARCH,
AGGR] for the 6to4 scheme.Its numeric value is 0x0002, i.e., it is
2002::/16 when expressed as an IPv6 address prefix.
ＩＡＮＡはＩＰｖ６フォーマットプレフィックス００１[AARCH, AGGR]下に
６to４案のために１３ビットのＩＰｖ６最上位集約（ＴＬＡ）識別子を永久
に割り当てました。その数の値は0x0002で、ＩＰｖ６アドレスプレフィック
スとして表される時は2002::/16です。
The subscriber site is then deemed to have the following IPv6 address
prefix, without any further assignment procedures being necessary:
それで、加入者サイトは次のＩＰｖ６アドレスプレフィックスをこれ以上の
割当て手順無しで持っているとみなされます：
Prefix length: 48 bits
Format prefix: 001
TLA value: 0x0002
NLA value: V4ADDR
This is illustrated as follows:
これは次のように図示できます：
| 3 | 13 | 32 | 16 | 64 bits |
+---+------+-----------+--------+--------------------------------+
|FP | TLA | V4ADDR | SLA ID | Interface ID |
|001|0x0002| | | |
+---+------+-----------+--------+--------------------------------+
Thus, this prefix has exactly the same format as normal /48 prefixes
assigned according to [AGGR]. It can be abbreviated as
2002:V4ADDR::/48. Within the subscriber site it can be used exactly
like any other valid IPv6 prefix, e.g., for automated address
assignment and discovery according to the normal mechanisms such as
[CONF, DISC], for native IPv6 routing, or for the "6over4" mechanism
[6OVER4].
このプレフィックスは[AGGR]が割当てたのと正確に同じ通常の/48プレフィッ
クスのフォーマットを持っています。これは2002:V4ADDR::/48と省略され得
ます。加入者サイトの中でこのプレフィックスは他の効力があるＩＰｖ６プ
レフィックス同様に使えます、例えば、[CONF, DISC]のような標準的機構に
よる自動化アドレス割り当てや探索、ネイティブＩＰｖ６ルーティング、
[6OVER4]の"6over4"メカニズム。
Note that if the IPv4 address is assigned dynamically, the
corresponding IPv6 prefix will also be dynamic in nature, with the
same lifetime.
もしＩＰｖ４アドレスがダイナミックに割り当てられるなら、対応するＩＰ
ｖ６プレフィックスが同じ寿命で同じくダイナミックであることに注意して
ください。
2.1 Address Selection
2.1 アドレス選択
To ensure the correct operation of 6to4 in complex topologies, source
and destination address selection must be appropriately implemented.
If the source IPv6 host sending a packet has at least one 2002::
address assigned to it, and if the set of IPv6 addresses returned by
the DNS for the destination host contains at least one 2002::
address, then the source host must make an appropriate choice of the
source and destination addresses to be used. The mechanisms for
address selection in general are under study at the time of writing
[SELECT]. Subject to those general mechanisms, the principle that
will normally allow correct operation of 6to4 is this:
複雑なトポロジーで ６to４ の正しい運用を保証するために、ソースと宛先
アドレス選択が適切に実行されなくてはなりません。もしパケットを送って
いるソースＩＰｖ６ホストが少なくとも１つの2002::アドレスを持っていて、
そしてもしＤＮＳの返す宛先ホストのＩＰｖ６アドレス集合に少なくとも１
つの2002::が含んでいるなら、ソースホストはソースアドレスと宛先アドレ
スの適切な選択をしなければなりません。一般的なアドレス選択のメカニズ
ムは[SELECT]を書いた時点で研究中です。一般的なメカニズムに従って、通
常の６to４の正しい運用の原則は以下です：
If one host has only a 6to4 address, and the other one has both a
6to4 and a native IPv6 address, then the 6to4 address should be used
for both.
もし１つのホストが６to４アドレスだけを持ってい、他が６to４とネイティ
ブのＩＰｖ６アドレスの両方を持っているなら、６to４アドレスが両方で使
われるべきです。
If both hosts have a 6to4 address and a native IPv6 address, then
either the 6to4 address should be used for both, or the native IPv6
address should be used for both. The choice should be configurable.
The default configuration should be native IPv6 for both.
もし両方のホストが６to４アドレスとネイティブＩＰｖ６アドレスの両方を
持つなら、６to４アドレスを両方で使うか、ネイティブＩＰｖ６アドレスが
両方で使われるかの、どちらかです。どちらにするかは設定可能であるべき
です。デフォルト設定は両方ともネイティブＩＰｖ６を使うことです。
3. Encapsulation in IPv4
3. ＩＰｖ４でのカプセル化
IPv6 packets from a 6to4 site are encapsulated in IPv4 packets when
they leave the site via its external IPv4 connection. Note that the
IPv4 interface that is carrying the 6to4 traffic is notionally
equivalent to an IPv6 interface, and is referred to below as a
pseudo-interface, although this phrase is not intended to define an
implementation technique. V4ADDR MUST be configured on the IPv4
interface.
６to４サイトからのＩＰｖ６パケットが、外部のＩＰｖ４接続を通してサイ
トを去る時、ＩＰｖ４パケットでカプセル化されます。６to４トラフィック
を伴うＩＰｖ４インタフェースが概念的にＩＰｖ６インタフェースと等しく、
以下で擬似インターフェースということに注意してください、この句が実装
技術を定義するように意図されていません。V4ADDRがＩＰｖ４インタフェー
ス上で設定されてなくてはなりません(MUST)。
IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4
protocol type of 41, the same as has been assigned [MECH] for IPv6
packets that are tunneled inside of IPv4 frames. The IPv4 header
contains the Destination and Source IPv4 addresses. One or both of
these will be identical to the V4ADDR field of an IPv6 prefix formed
as specified above (see section 5 for more details). The IPv4 packet
body contains the IPv6 header and payload.
ＩＰｖ６パケットがＩＰｖ４パケット［ RFC ７９１］で転送され、ＩＰｖ４
プロトコルタイプが[MECH]でIPv6パケットに割当てられたのと同じ４１で、
ＩＰｖ４フレーム内にトンネルします。ＩＰｖ４ヘッダーは宛先とソースＩ
Ｐｖ４アドレスを含んでいます。一方か両方かのＩＰｖ４アドレスが、上で
指定したＩＰｖ６プレフィックスのV4ADDRフィールドと同じです（詳細は５
章参照）。ＩＰｖ４パケットの本体はＩＰｖ６ヘッダーとペイロードを含ん
でいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol 41 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 header and payload ... /
+-------+-------+-------+-------+-------+------+------+
The IPv4 Time to Live will be set as normal [RFC 791], as will the
encapsulated IPv6 hop limit [IPv6]. Other considerations are as
described in Section 4.1.2 of [MECH].
ＩＰｖ４の生存時間は通常どおり設定し[RFC 791]、カプセル化される
ＩＰｖ６のホップ限界も同じです。他の考慮が[MECH]の４.１.２章で記
述されます。
3.1. Link-Local Address and NUD
3.1. リンクローカルアドレスと近隣非接続発見
The link-local address of a 6to4 pseudo-interface performing 6to4
encapsulation would, if needed, be formed as described in Section 3.7
of [MECH]. However, no scenario is known in which such an address
would be useful, since a peer 6to4 gateway cannot determine the
appropriate link-layer (IPv4) address to send to.
６to４ カプセル化を行っている６to４疑似インタフェースのリンクローカル
アドレスは、もし必要なら、[MECH]の３.７章で記述されるように、生成され
るでしょう。しかしピア６to４ ゲートウェイが送信すべき適切なリンクレイ
ヤ（ＩＰｖ４）アドレスを決定することができないので、このようなアドレ
スが有用となるシナリオが知られていません。
Neighbor Unreachability Detection (NUD) is handled as described in
Section 3.8 of [MECH].
近隣非接続発見（NUD）は[MECH]の３.８章で記述されるように扱われます。
4. Maximum Transmission Unit
4. 最大伝達単位
MTU size considerations are as described for tunnels in [MECH].
ＭＴＵサイズが[MECH]のトンネルで記述されたとおりです。
If the IPv6 MTU size proves to be too large for some intermediate
IPv4 subnet, IPv4 fragmentation will ensue. While undesirable, this
is not necessarily disastrous, unless the fragments are delivered to
different IPv4 destinations due to some form of IPv4 anycast. The
IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulating
IPv4 header.
もし中継ＩＰｖ４サブネットにとってＩＰｖ６のＭＴＵサイズがあまりにも
大きいことが分かるなら、ＩＰｖ４パケット分割が行われるでしょう。これ
は望ましくないですが、分割パケットがＩＰｖ４エニキャスト形式のために
異なるＩＰｖ４の宛先に配達されない限り、必ずしも悲惨ではありません。
ＩＰｖ４の「分解不可」ビットはカプセル化ＩＰｖ４ヘッダーでセットされ
るべきではありません(SHOULD NOT)。
5. Unicast scenarios, scaling, and transition to normal prefixes
5. ユニキャストのシナリオ、スケーリング、標準プレフィックスへの移行
5.1 Simple scenario - all sites work the same
5.1 の単純なシナリオ−すべてのサイトが同時に動作
The simplest deployment scenario for 6to4 is to use it between a
number of sites, each of which has at least one connection to a
shared IPv4 Internet. This could be the global Internet, or it could
be a corporate IP network. In the case of the global Internet, there
is no requirement that the sites all connect to the same Internet
service provider. The only requirement is that any of the sites is
able to send IPv4 packets with protocol type 41 to any of the others.
By definition, each site has an IPv6 prefix in the format defined in
Section 2. It will therefore create DNS records for these addresses.
For example, site A which owns IPv4 address 192.1.2.3 will create DNS
records with the IPv6 prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48
(i.e., 2002:c001:0203::/48). Site B which owns address 9.254.253.252
will create DNS records with the IPv6 prefix
{FP=001,TLA=0x0002,NLA=9.254.253.252}/48 (i.e., 2002:09fe:fdfc::/48).
６to４の最も単純な展開シナリオが多くのサイトで使われるはずで、各サイ
トは共有されたＩＰｖ４インターネットに少なくとも１つの接続を持ってい
ます。これはグローバルなインターネットか、企業のＩＰネットワークでしょ
う。グローバルインターネットの場合、サイトがすべて同じインターネット
・サービスプロバイダに接続する必要はありません。唯一の必要条件はサイ
トがプロトコルタイプ４１で他にＩＰｖ４パケットを送ることが可能である
ということです。定義により、各サイトが２章で定義されたフォーマットで
ＩＰｖ６プレフィックスを持ちます。従ってそれはこれらのアドレスのＤＮ
Ｓレコードを作るでしょう。例えば、ＩＰアドレス192.1.2.3のサイトＡは、
ＩＰｖ６プレフィックス{FP=001,TLA=0x0002,NLA=192.1.2.3}/48（つまり、
2002:c001:0203::/48）のＤＮＳレコードを作るでしょう。ＩＰアドレス
9.254.253.252のサイトＢは、ＩＰｖ６プレフィックス{FP=001,TLA=0x0002,
NLA=9.254.253.252}/48（つまり、2002:09fe:fdfc::/48）のＤＮＳレコード
を作るでしょう。
When an IPv6 host on site B queries the DNS entry for a host on site
A, or otherwise obtains its address, it obtains an address with the
prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48 and whatever SLA and
Interface ID applies. The converse applies when a host on site A
queries the DNS for a host on site B. IPv6 packets are formed and
transmitted in the normal way within both sites.
サイトＢのＩＰｖ６ホストがサイトＡのホストのＤＮＳ項目を照会するか、
あるいはそのアドレスを得る時、これはプレフィックス{FP=001,TLA=0x0002,
NLA=192.1.2.3}/48で、ＳＬＡとインタフェース識別子は何でも適用可能です。
サイトＡのホストがサイトＢのホストのＤＮＳを問い合わせる時、逆も言え
ます。ＩＰｖ６パケットが生成され、両方のサイトで標準的な方法で送信さ
れます。
Within a 6to4 site, addresses with the 2002::/16 prefix, apart from those with the local 2002:V4ADDR::/48 prefix, will be handled like any other non-local IPv6 address, i.e., by a default or explicit route towards the 6to4 border router. ６to４サイト内で、ローカルプレフィックス2002:V4ADDR::/48を除く、プレ フィックス2002::/16のアドレスは、他のローカルでないＩＰｖ６アドレス 同様に扱われまる、すなわち、デフォルトか明示的なルートにで６to４境界 ルータに向かいます。 When an outgoing packet reaches the 6to4 router, it is encapsulated as defined in Section 3, according to the additional sending rule defined in Section 5.3. Incoming packets are decapsulated according to the additional decapsulation rule defined in Section 5.3. The additional sending and decapsulation rules are the only changes to IPv6 forwarding, and they occur only at border routers. No IPv4 routing information is imported into IPv6 routing (nor vice versa). 外向パケットが６to４ルーターに届く時、５.３章で定義した追加の送信規 則により、セクション３で定義されるカプセル化が行われます。入りパケッ トのカプセルは、５.３章で定義した追加のカプセルを解く規則により、解 かれます。追加の送信とカプセルを解く規則は唯一のＩＰｖ６転送に対する 変更で、これらは境界ルータにおいてだけ起こります。ＩＰｖ４ルーティン グ情報がＩＰｖ６ルーティングの中に入れられません（逆も同様です）。 In this scenario, any number of 6to4 sites can interoperate with no tunnel configuration, and no special requirements from the IPv4 service. All that is required is the appropriate DNS entries and the additional sending and decapsulation rules configured in the 6to4 router. This router SHOULD also generate the appropriate IPv6 prefix announcements [CONF, DISC]. このシナリオで、 多数の６to４サイトがトンネル設定とＩＰｖ４サービスの 特別な条件なしで、相互運用できます。必要とされるすべては適切なＤＮＳ 項目と、６to４ルーターで設定される追加の送信とカプセルを解く規則です。 このルーターは同じく適切なＩＰｖ６プレフィックス広告[CONF, DISC]を生 成するべきです(SHOULD)。 Although site A and site B will each need to run IPv6 routing internally, they do not need to run an IPv6 exterior routing protocol in this simple scenario; IPv4 exterior routing does the job for them. サイトＡとサイトＢがそれぞれ内部でＩＰｖ６ルーティングを行う必要があ るだろうが、この単純なシナリオでＩＰｖ６の外部ルーティングプロトコル を動作する必要がなく、ＩＰｖ４外部ルーティングがその仕事をします。 It is RECOMMENDED that in any case each site should use only one IPv4 address per 6to4 router, and that should be the address assigned to the external interface of the 6to4 router. Single-homed sites therefore SHOULD use only one IPv4 address for 6to4 routing. Multi- homed sites are discussed briefly in section 5.6. どんな場合でも各サイトが６to４ルーター毎に１つのＩＰｖ４アドレスだけ を使うべきでことが勧められ(RECOMMENDED)、これは６to４ルーターの外部の インタフェースに割り当てられるアドレスであるべきです。従ってシングル ホームサイトが６to４ ルーティングにただ１つのＩＰｖ４アドレスを使うべ きです(SHOULD)。マルチホームサイトは５.６章で手短かに論じられます。 Because of the lack of configuration, and the distributed deployment model, there are believed to be no particular scaling issues with the basic 6to4 mechanism apart from encapsulation overhead. Specifically, it introduces no new entries in IPv4 routing tables. 設定がなく分散展開モデルであるため、カプセル化オーバーヘッドを別とし て基本的な６to４メカニズムに特定のスケールの問題がないと信じられます。 特に、これはＩＰｖ４ルーティングテーブルに新しい項目を必要としません。 5.2 Mixed scenario with relay to native IPv6 5.2 ネイティブＩＰｖ６へのリレーを持つ混在シナリオ During the transition to IPv6 we can expect some sites to fit the model just described (isolated sites whose only connectivity is the IPv4 Internet), whereas others will be part of larger islands of native or tunneled IPv6 using normal IPv6 TLA address space. The 6to4 sites will need connectivity to these native IPv6 islands and vice versa. In the 6to4 model, this connectivity is accomplished by IPv6 routers which possess both 6to4 and native IPv6 addresses. Although they behave essentially as standard IPv6 routers, for the purposes of this document they are referred to as relay routers to distinguish them from routers supporting only 6to4, or only native IPv6. ＩＰｖ６への移行の間に、あるサイトがちょうど記述されたモデルに合うこ とを期待することができる（ＩＰｖ４インターネットだけでつながっている 孤立サイト）が、他は標準ＩＰｖ６ＴＬＡアドレス空間を使うネイティブか トンネルのＩＰｖ６の大きな孤島の一部かもしれません。６to４サイトはこ れらネイティブのＩＰｖ６島に接続を必要とし、逆も同様です。６to４モデ ルで、この接続は６to４とネイティブＩＰｖ６アドレスの両方を所有するＩ Ｐｖ６ルーターによって達成されます。それらが本質的に標準ＩＰｖ６ルー ターとして振る舞うが、この文書では、６to４だけをサポートしているルー ターやネイティブＩＰｖ６だけのルータと区別するため、リレールーターと 言います。 There must be at least one router acting as a relay between the 6to4 domain and a given native IPv6 domain. There is nothing special about it; it is simply a normal router which happens to have at least one logical 6to4 pseudo-interface and at least one other IPv6 interface. Since it is a 6to4 router, it implements the additional sending and decapsulation rules defined in Section 5.3. ６to４ドメインとネイティブＩＰｖ６ドメインの間でリレーの役を務めてい る少なくとも１つのルーターがあるに違いありません。これについて特別な 事はありません；これは標準的なルータで、たまたま少なくとも１つの論理 的な６to４疑似インタフェースと少なくとも１つの他のＩＰｖ６インタフェー スを持っています。これは６to４ルーターなので、５.３章で定義された追加 の送信とカプセルを解く規則を実行します。 We now have three distinct classes of routing domain to consider: 考慮すべき３つのルーティングドメインのクラスがあります： 1. the internal IPv6 routing domain of each 6to4 site; 1. 各６to４サイトの内部のＩＰｖ６ルーティングドメイン； 2. an exterior IPv6 routing domain interconnecting a given set of 6to4 border routers, including relay routers, among themselves, i.e., a 6to4 exterior routing domain; 2. リレールーターを含めて、６to４境界ルータを相互につなぐ、外部 ＩＰｖ６ルーティングドメイン、すなわち、 ６to４外部ルーティ ングドメイン； 3. the exterior IPv6 routing domain of each native IPv6 island. 3. 各のネイティブＩＰｖ６島の外部ＩＰｖ６ルーティングドメイン。 1. The internal routing domain of a 6to4 site behaves as described in section 5.1. 1. ６to４サイトの内部のルーティングドメインは、５.１章で記述されるよ うに、作用します。 2. There are two deployment options for a 6to4 exterior routing domain: 2. ６to４外部ルーティングドメインは２つの展開オプションがあります： 2.1 No IPv6 exterior routing protocol is used. The 6to4 routers using a given relay router each have a default IPv6 route pointing to the relay router. The relay router MAY apply source address based filters to accept traffic only from specific 6to4 routers. 2.1 ＩＰｖ６外部ルーティングプロトコルが使われません。あるリレールー ターを使う６to４ ルーターはデフォルトＩＰｖ６ルートがリレールーターを 示すようにします。リレールーターは特定の６to４ ルーターからだけトラ フィックを受け入れるため、ソースアドレスベースのフィルターを適用して もよいです(MAY)。 2.2 An IPv6 exterior routing protocol is used. The set of 6to4 routers using a given relay router obtain native IPv6 routes from the relay router using a routing protocol such as BGP4+ [RFC 2283, BGP4+]. The relay router will advertise whatever native IPv6 routing prefixes are appropriate on its 6to4 pseudo-interface. These prefixes will indicate the regions of native IPv6 topology that the relay router is willing to relay to. Their choice is a matter of routing policy. It is necessary for network operators to carefully consider desirable traffic patterns and topology when choosing the scope of such routing advertisements. The relay router will establish BGP peering only with specific 6to4 routers whose traffic it is willing to accept. 2.2 ＩＰｖ６外部ルーティングプロトコルが使われます。あるリレールー ターを使う６to４ルーターはBGP4+ [RFC 2283, BGP4+]のようなルーティン グプロトコルを使ってリレールーターからネイティブのＩＰｖ６ルートを得 ます。リレールーターはその６to４疑似インタフェース上で適切なネイティ ブＩＰｖ６ルーティングプレフィックスを広告するでしょう。これらのプレ フィックスはリレールーターが転送したいネイティブＩＰｖ６トポロジーの 地域を示すでしょう。それらの選択はルーティング方針の問題です。ネット ワークオペレーターが、このようなルーティング広告の範囲を選択する時、 慎重に望ましいトラヒックパターンとトポロジーを考慮することが必要です。 リレールーターは、トラフィックを受け入れてもよい特定の６to４ルーター とだけBGPピアリングを確立するでしょう。 Although this solution is more complex, it provides effective policy control, i.e., BGP4+ policy determines which 6to4 routers are able to use which relay router. この方法はより複雑であるが、効率的なポリシー制御を供給します、すなわ ちBGP4+ポリシーががどの６to４ルーターがどのリレールーターを使うことが 可能か決定します。 3. A relay router MUST advertise a route to 2002::/16 into the native IPv6 exterior routing domain. It is a matter of routing policy how far this routing advertisement of 2002::/16 is propagated in the native IPv6 routing system. Since there will in general be multiple relay routers advertising it, network operators will require to filter it in a managed way. Incorrect policy in this area will lead to potential unreachability or to perverse traffic patterns. 3. リレールーターがネイティブＩＰｖ６外部ルーティングドメインに 2002::/16の経路を広告しなくてはなりません(MUST)。これはネイティブＩＰ ｖ６ルーティングシステムでどのくらい遠くまでこの2002::/16ルーティング 広告をするかは、ルーティングポリシーの問題です。多数のリレールーター が一般にあるだろうから、ネットワークオペレーターが管理手段でそれをフィ ルターする必要があります。このエリアの正しくないポリシーがトラヒック を遮断する、変質的なトラヒックパターンを導く可能性があります。 6to4 prefixes more specific than 2002::/16 must not be propagated in native IPv6 routing, to prevent pollution of the IPv6 routing table by elements of the IPv4 routing table. Therefore, a 6to4 site which also has a native IPv6 connection MUST NOT advertise its 2002::/48 routing prefix on that connection, and all native IPv6 network operators MUST filter out and discard any 2002:: routing prefix advertisements longer than /16. 2002::/16より細かい６to４プレフィックスは、ＩＰｖ４ルーティングテーブ ルの要素によってＩＰｖ６ルーティングテーブルが汚染するのを妨げるため に、ネイティブのＩＰｖ６ルーティングで伝えられてはなりません。それ故 に、ネイティブＩＰｖ６接続を持っている６to４サイトがその接続上で 2002::/48ルーティングプレフィックスを広告してはなりません(MUST NOT)、 そしてネイティブＩＰｖ６ネットワークオペレーターは/16より長い2002:: ルーティングプレフィックスを抜き出して捨てなければなりません(MUST)。 Sites which have at least one native IPv6 connection, in addition to a 6to4 connection, will therefore have at least one IPv6 prefix which is not a 2002:: prefix. Such sites' DNS entries will reflect this and DNS lookups will return multiple addresses. If two such sites need to interoperate, whether the 6to4 route or the native route will be used depends on IPv6 address selection by the individual hosts (or even applications). 従って少なくとも１つのネイティブＩＰｖ６接続を持つサイトが、６to４接 続のほかに、 2002::ではない少なくとも１つのＩＰｖ６プレフィックスを持 ちます。このようなサイトのＤＮＳ項目はこれを反映し、ＤＮＳ検索が多数 のアドレスを返すでしょう。もし２つのこのようなサイトが相互運用する必 要があるなら、６to４ルートとネイティブルートのどちらが使われるか個別 ホスト（あるいはアプリケーション）のＩＰｖ６アドレス選択に頼ります。 Now consider again the example of the previous section. Suppose an IPv6 host on site B queries the DNS entry for a host on site A, and the DNS returns multiple IPv6 addresses with different prefixes. 再び前の章の例を考えます。サイトＢ上のＩＰｖ６ホストがサイトＡのホス トのＤＮＳ項目を照会するとすれば、ＤＮＳは異なったプレフィックスの多 数のＩＰｖ６アドレスを返します。
If the host picks the 6to4 prefix according to some rule for multiple
prefixes, it will simply send packets to an IPv6 address formed with
the prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48. It is essential
that they are sourced from the prefix
{FP=001,TLA=0x0002,NLA=9.254.253.252}/48 for two-way connectivity to
be possible. The address selection mechanism of Section 2.1 will
ensure this.
もしホストがマルチプレフィックスの規則によって６to４プレフィックスを
選ぶなら、ホストはプレフィックス{FP=001,TLA=0x0002,NLA=192.1.2.3}/48
で生成されたＩＰｖ６アドレスにパケットを送るでしょう。双方向接続を可
能にするため、プレフィックス{FP=001,TLA=0x0002,NLA=9.254.253.252}/48
をソースにすることは不可欠です。２.１章のアドレス選択機構はこれを保証
するでしょう。
5.2.1 Variant scenario with ISP relay
5.2.1 ＩＳＰリレーの異なるシナリオ
The previous scenario assumes that the relay router is provided by a
cooperative 6to4 user site. A variant of this is for an Internet
Service Provider, that already offers native IPv6 connectivity, to
operate a relay router. Technically this is no different from the
previous scenario; site B is simply an internal 6to4 site of the ISP,
possibly containing only one system, i.e., the relay router itself.
前のシナリオはリレールーターが協力的な６to４ユーザーサイトによって供
給されると想定します。これの変形が、ネイティブＩＰｖ６接続性を提供し
ているインターネット・サービスプロバイダによる、リレールーター運用で
す。技術的にこれは前のシナリオと異なりません；サイトＢはＩＳＰの単純
な内部６to４ サイトで、ＩＳＰできる限りただ１つのシステムすなわちリ
レールーターそれ自身だけを含んでいます。
5.2.2 Summary of relay router configuration
5.2.2 リレールーター設定の要約
A relay router participates in IPv6 unicast routing protocols on its
native IPv6 interface and may do so on its 6to4 pseudo-interface, but
these are independent routing domains with separate policies, even if
the same protocol, probably BGP4+, is used in both cases.
リレールーターが、ネイティブＩＰｖ６インタフェース上でＩＰｖ６ユニキャ
ストルーティングプロトコルに参加し、６to４疑似インタフェース上でも参
加してかまいませんが、これらは、たとえ同じプロトコル、恐らくBGP4+が両
方の場合に使われるとしても、別のポリシーを持っている独立のルーティン
グドメインです。
A relay router also participates in IPv4 unicast routing protocols on
its IPv4 interface used to support 6to4, but this is not further
discussed here.
リレールーターが同じく６to４をサポートするためにＩＰｖ４インタフェー
ス上でＩＰｖ４ユニキャストルーティングプロトコルに参加しますが、ここ
では詳細を述べません。
On its native IPv6 interface, the relay router MUST advertise a route
to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix
on that interface. Routing policy within the native IPv6 routing
domain determines the scope of that advertisement, thereby limiting
the visibility of the relay router in that domain.
ネイティブＩＰｖ６インタフェース上で、リレールーターは2002::/16の経路
を広告しなくてはなりません(MUST)。これは2002::ルーティングプレフィッ
クスのより長い経路を広告してはなりません(MUST NOT)。ネイティブのＩＰ
ｖ６ルーティングドメインのルーティングポリシーが広告の範囲を制限し、
そのドメインのリレールーターの利用可能性を決定します。
IPv6 packets received by the relay router whose next hop IPv6 address
matches 2002::/16 will be routed to its 6to4 pseudo-interface and
treated according to the sending rule of Section 5.1.
リレールーターが受取るパケットで、次の転送先ＩＰｖ６アドレスが
2002::/16にＩＰｖ６パケットは、６to４疑似インタフェースに経路を決めら
れ、５.１章の送信規則に従って扱われるでしょう。
5.2.2.1. BGP4+ not used
5.2.2.1. BGP4+を使わない
If BGP4+ is not deployed in the 6to4 exterior routing domain (option
2.1 of Section 5.2), the relay router will be configured to accept
and relay all IPv6 traffic only from its client 6to4 sites. Each
6to4 router served by the relay router will be configured with a
default IPv6 route to the relay router (for example, Site A's default
IPv6 route ::/0 would point to the relay router's address under
prefix 2002:09fe:fdfc::/48).
もしBGP4+が６to４外部ルーティングドメインで設定されないなら（５.２章
のオプション２.１）、リレールーターはクライアント６to４サイトだけから
のすべてＩＰｖ６トラフィックを受け容れて中継するように設定されるでしょ
う。それぞれのリレールーターに対する６to４ルーターが、デフォルトＩＰ
ｖ６ルートをリレールーターにするように構成を設定されるであろう（例え
ば、サイトＡのデフォルトＩＰｖ６経路::/0はプレフィックス
2002:09fe:fdfc::/48下のリレールーターのアドレスを指し示すでしょう）。
5.2.2.2. BGP4+ used
5.2.2.2. BGP4+を使う
If BGP4+ is deployed in the 6to4 exterior routing domain (option 2.2
of Section 5.2), the relay router advertises IPv6 native routing
prefixes on its 6to4 pseudo-interface, peering only with the 6to4
routers that it serves. (An alternative is that these routes could
be advertised along with IPv4 routes using BGP4 over IPv4, rather
than by running a separate BGP4+ session.) The specific routes
advertised depend on applicable routing policy, but they must be
chosen from among those reachable through the relay router's native
IPv6 interface. In the simplest case, a default route to the whole
IPv6 address space could be advertised. When multiple relay routers
are in use, more specific routing prefixes would be advertised
according to the desired routing policy. The usage of BGP4+ is
completely standard so is not discussed further in this document.
もしBGP4+が６to４外部ルーティングドメインで設定されるなら（５.２章の
オプション２.２）、リレールーターは６to４疑似インタフェース上でＩＰｖ
６ネイティブのルーティングプレフィックスを広告し、サポートする６to４
ルーターとだけピアリングします。（代案は、別のBGP4+セッションを動かす
のではなく、これらの経路をＩＰｖ４上のBGP4でＩＰｖ４経路と共に広告す
る事です。）広告された経路の広告は適用可能なルーティングポリシーに依
存しますが、それらはリレールーターのネイティブＩＰｖ６インタフェース
を通して通信可能な中から選ばれなくてはなりません。最も単純な場合、Ｉ
Ｐｖ６アドレス空間全体へのデフォルトルートが広告できます。多数のリレー
ルーターが使用中である時、特定のルーティングプレフィックスが望ましい
ルーティングポリシーに従って広告されるでしょう。BGP4+の使い方は完全に
標準的で、この文書でさらに論じられません。
5.2.2.3. Relay router scaling
5.2.2.3. リレールーターのスケール
Relay routers introduce the potential for scaling issues. In general
a relay router should not attempt to serve more sites than any other
transit router, allowing for the encapsulation overhead.
リレールーターがスケール問題をもたらす可能性があります。一般にリレー
ルーターは、カプセル化オーバーヘッドを考慮すると、他の転送ルーターよ
り多くのサイトをサポートしようと試みるべきではありません。
5.2.3 Unwilling to relay
5.2.3 好ましくないリレー
It may arise that a site has a router with both 6to4 pseudo-
interfaces and native IPv6 interfaces, but is unwilling to act as a
relay router. Such a site MUST NOT advertise any 2002:: routing
prefix into the native IPv6 domain and MUST NOT advertise any native
IPv6 routing prefixes or a default IPv6 route into the 6to4 domain.
Within the 6to4 domain it will behave exactly as in the basic 6to4
scenario of Section 5.1.
サイトが６to４疑似インタフェースとネイティブＩＰｖ６インタフェースの
両方を持つルーターを持っているが、リレールーターの役を務めることを好
まないことがあるかもしれません。このようなサイトはネイティブのＩＰｖ
６ドメインの中へ2002::を広告してはならず(MUST NOT)、６to４ドメインの
中にネイティブのＩＰｖ６ルーティングプレフィックスやデフォルトＩＰｖ
６ルートを広告てはなりません(MUST NOT)。６to４ドメイン内で、これは正
確に５.１章の基本的な６to４シナリオのように作用するでしょう。
5.3 Sending and decapsulation rules
5.3 送信とカプセル解除の規則
The only change to standard IPv6 forwarding is that every 6to4 router
(and only 6to4 routers) MUST implement the following additional
sending and decapsulation rules.
唯一の標準ＩＰｖ６転送に対する変更はすべての６to４ルーターが（そして
６to４ルーターだけが）次の追加の送信とカプセル解除規則を実行しなくて
はならないということです(MUST)。
In the sending rule, "next hop" refers to the next IPv6 node that the
packet will be sent to, which is not necessarily the final
destination, but rather the next IPv6 neighbor indicated by normal
IPv6 routing mechanisms. If the final destination is a 6to4 address,
it will be considered as the next hop for the purpose of this rule.
If the final destination is not a 6to4 address, and is not local, the
next hop indicated by routing will be the 6to4 address of a relay
router.
送信規則で、「次の転送先」がパケットが送られる次のＩＰｖ６ノードで、
必ずしも標準的なＩＰｖ６ルーティングメカニズムで示される最終の宛先で
はなく、どちらかと言うと次のＩＰｖ６近隣です。もし最終の宛先が６to４
アドレスであるなら、６to４アドレスがこの規則の目的の次の転送先に関連
するでしょう。もし最終の宛先が６to４ アドレスでなく、ローカルもない
なら、ルーティングの示す次の転送先はリレールーターの６to４アドレスで
しょう。
ADDITIONAL SENDING RULE for 6to4 routers
６to４ルーターの追加送信規則
if the next hop IPv6 address for an IPv6 packet
does match the prefix 2002::/16, and
does not match any prefix of the local site
then
apply any security checks (see Section 8);
encapsulate the packet in IPv4 as in Section 3,
with IPv4 destination address = the NLA value V4ADDR
extracted from the next hop IPv6 address;
queue the packet for IPv4 forwarding.
訳注：RFC誤植情報によると上記"Section 8"は"Section 9"の誤りだそうです
if ＩＰｖ６パケットの次の転送先ＩＰｖ６アドレスが
プレフィックス2002::/16と一致し、
ローカルなサイトプレフィックスに一致しないなら
then
セキュリティ検査を適用する（９章参照）；。
３章のようにIPｖ４パケット内にカプセル化します、
IPv4宛先アドレス＝次の転送先のＩＰｖ６アドレスから
抽出したＮＬＡ値V4ADDRです；。
ＩＰｖ４転送のためパケットを待ち行列に入れます。
A simple decapsulation rule for incoming IPv4 packets with protocol
type 41 MUST be implemented:
プロトコルタイプ４１の入力ＩＰｖ４パケットのために単純なカプセル解除
規則を実行しなければなりません(MUST)：
ADDITIONAL DECAPSULATION RULE for 6to4 routers
６to４ルーターの追加のカプセル解除規則
apply any security checks (see Section 8);
remove the IPv4 header;
submit the packet to local IPv6 routing.
訳注：RFC誤植情報によると上記"Section 8"は"Section 9"の誤りだそうです
セキュリティ検査を適用します（９章参照）；
ＩＰｖ４ヘッダーを取り去ります；
パケットをローカルＩＰｖ６ルーティングに従って処理します。
5.4 Variant scenario with tunnel to IPv6 space
5.4 ＩＰｖ６空間へのトンネルの異なるシナリオ
A 6to4 site which has no IPv6 connections to the "native" IPv6
Internet can acquire effective connectivity to the v6 Internet via a
"configured tunnel" (using the terminology in [MECH]) to a
cooperating router which does have IPv6 access, but which does not
need to be a 6to4 router. Such tunnels could be autoconfigured using
an IPv4 anycast address, but this is outside of the scope of this
document. Alternatively a tunnel broker can be used. This scenario
would be suitable for a small user-managed site.
「ネイティブ」ＩＰｖ６インターネットにＩＰｖ６接続を持っていない６to
４サイトが、ＩＰｖ６アクセスを持つが６to４ ルーターである必要がない協
力ルーターへの、「設定されたトンネル」によってｖ６インターネットに効
果的な接続性を獲得することができます（[MECH]で技術を使う）。このよう
なトンネルはＩＰｖ４エニキャストアドレスを使って自動設定ができますが、
これはこの文書の範囲の外です。代わりにトンネルブローカを使うことがで
きます。このシナリオは小さいユーザーによって管理されたサイトに適する
でしょう。
These mechanisms are not described in detail in this document.
これらのメカニズムはこの文書で詳細を記述しません。
5.5 Fragmented Scenarios
5.5 分割シナリオ
If there are multiple relay routers between native IPv6 and the 6to4
world, different parts of the 6to4 world will be served by different
relays. The only complexity that this introduces is in the scoping
of 2002::/16 routing advertisements within the native IPv6 world.
Like any BGP4+ advertisements, their scope must be correctly defined
by routing policy to ensure that traffic to 2002::/16 follows the
intended paths.
もしネイティブＩＰｖ６と６to４界の間に多数のリレールーターがあるなら、
６to４界の異なった部分が異なったリレーによって果たされるでしょう。こ
れによる唯一の複雑さはネイティブＩＰｖ６界の中で2002::/16経路広告の範
囲です。BGP4+広告のように、2002::/16へのトラフィックが正確に意図的な
パスに従う事を保証する様に、広告範囲をルーティングポリシーで定義しな
くてはなりません。
If there are multiple IPv6 stubs all interconnected by 6to4 through
the global IPv4 Internet, this is a simple generalization of the
basic scenarios of sections 5.1. and 5.2 and no new issues arise.
This is shown in the following figure. Subject to consistent
configuration of routing advertisements, there are no known issues
with this scenario.
もしグローバルなＩＰｖ４インターネットを通してすべて６to４によって相
互に結び付けられた多数のＩＰｖ６末端があるなら、これは５.１章.と５.２
章の基本的なシナリオの単純な一般論で、新しい問題が起こりません。これ
は次の図で示せます。ルーティング広告の一貫した設定に従って、このシナ
リオに既知の問題がありません。
ＡＳ１とＡＳ２の両方が2002::/16を広告するが、一方だけがＡＳ３に届きます。
If multiple IPv6 stubs are interconnected through multiple, disjoint
IPv4 networks (i.e., a fragmented IPv4 world) then the 6to4 world is
also fragmented; this is the one scenario that must be avoided. It
is illustrated below to show why it does not work, since the
2002::/16 advertisement from Relay1 will be invisible to Relay2, and
vice versa. Sites A and B therefore have no connectivity to sites C
and D.
もし多数のＩＰｖ６末端が多数の、共通要素を持たないＩＰｖ４ネットワーク（すなわち、断片的なＩＰｖ４界）を通して相互につながるなら、６to４界は同じく断片的です、これは避けなければならないシナリオです。Relay１からの2002::/16広告がRelay２に見えず逆もそうなのでこれが動作しない事を以下に示します。従ってサイトＡとＢがサイトＣとＤに接続していません。
ＡＳ１とＡＳ２の両方が2002::/16を広告しますが、ＡとＢがサイトがＣとＤにつながりません。 5.6 Multihoming 5.6 マルチホーム Sites which are multihomed on IPv4 MAY extend the 6to4 scenario by using a 2002:: prefix for each IPv4 border router, thereby obtaining a simple form of IPv6 multihoming by using multiple simultaneous IPv6 prefixes and multiple simultaneous relay routers. ＩＰｖ４上でマルチホームするサイトが各ＩＰｖ４境界ルータの2002::プレ フィックスを使うことで６to４シナリオを拡張するかもしれません(MAY)、そ れによって、多数のＩＰｖ６プレフィックスと多数のリレールーターを使う ことによってＩＰｖ６マルチホームの単純な形式を得ます。 5.7 Transition Considerations 5.7 移行の考察 If the above rules for routing advertisements and address selection are followed, then a site can migrate from using 6to4 to using native IPv6 connections over a long period of co-existence, with no need to stop 6to4 until it has ceased to be used. The stages involved are もしルーティング広告とアドレス選択の上記の規則に従うなら、サイトは ６to４の使用からネイティブＩＰｖ６接続の使用に移行でき、、６to４を使 うのをやめるまで６to４を止める必要がないので長期間の両者の共存があり ます。手順は以下の通りです。 1. Run IPv6 on site using any suitable implementation. True native IPv6, [6OVER4], or tunnels are all acceptable. 1. 適当な実装を使ってＩＰｖ６を動作させます。ネイティブＩＰｖ６や、 [6OVER4]や、トンネルがすべて受容できます。 2. Configure a border router (or router plus IPv4 NAT) connected to the external IPv4 network to support 6to4, including advertising the appropriate 2002:: routing prefix locally. Configure IPv6 DNS entries using this prefix. At this point the 6to4 mechanism is automatically available, and the site has obtained a "free" IPv6 prefix. 2. ６to４をサポートするために外部のＩＰｖ４ネットワークと接続した境界 ルーター（あるいはルーターとＩＰｖ４ＮＡＴ）を、適切な 2002::ルーティ ングプレフィックスを広告することを含め、設定します。このプレフィック スを使ってＩＰｖ６のＤＮＳ項目を設定します。この時点で６to４ メカニズ ムは自動的に利用可能で、サイトは「ただの」ＩＰｖ６プレフィックスを得 ました。 3. Identify a 6to4 relay router willing to relay the site's traffic to the native IPv6 world. This could either be at another cooperative 6to4 site, or an ISP service. If no exterior routing protocol is in use in the 6to4 exterior routing domain, the site's 6to4 router will be configured with a default IPv6 route pointing to that relay router's 6to4 address. If an exterior routing protocol such as BGP4+ is in use, the site's 6to4 router will be configured to establish appropriate BGP peerings. 3. サイトトラヒックをネイティブＩＰｖ６界に伝える６to４ リレールータ を識別してください。これは他の協力的な６to４サイトや、ＩＳＰサービス です。もし外部ルーティングプロトコルが６to４外部ルーティングドメイン で使用中ではないなら、サイトの６to４ルーターはデフォルトＩＰｖ６ルー トがそのリレールーターの６to４アドレスを指し示す状態で、構成を設定さ れるでしょう。もしBGP4+のような外部ルーティングプロトコルが使用中なら、 サイトの６to４ルーターは適切なBGPピアリングを確立するように設定される でしょう。 4. When native external IPv6 connectivity becomes available, add a second (native) IPv6 prefix to both the border router configuration and the DNS configuration. At this point, an address selection rule will determine when 6to4 and when native IPv6 will be used. 4. ネイティブの外部ＩＰｖ６接続が利用可能になる時、境界ルータ設定とＤ ＮＳ設定の両方に２番目の（ネイティブ）ＩＰｖ６プレフィックスを加えて ください。この時点で、アドレス選択規則が６to４とネイティブのＩＰｖ６ のどちらをいつ使うか決定するでしょう。 5. When 6to4 usage is determined to have ceased (which may be several years later), remove the 6to4 configuration. 5. ６to４の使用停止を決めた時（数年後かもしれない）、６to４設定を削除 する。 5.8 Coexistence with firewall, NAT or RSIP 5.8 ファイアウォールとＮＡＴとＲＳＩＰの共存 The 6to4 mechanisms appear to be unaffected by the presence of a firewall at the border router. ６to４機構は境界ルータのファイアウォールの存在に影響されないように思 われます。 If the site concerned has very limited global IPv4 address space, and is running an IPv4 network address translator (NAT), all of the above mechanisms remain valid. The NAT box must also contain a fully functional IPv6 router including the 6to4 mechanism. The address used for V4ADDR will simply be a globally unique IPv4 address allocated to the NAT. In the example of Section 5.1 above, the 6to4 routers would also be the sites' IPv4 NATs, which would own the globally unique IPv4 addresses 192.1.2.3 and 9.254.253.252. もし接続サイトが非常に限定されたグローバルＩＰｖ４アドレス空間を持ち、 ＩＰｖ４ネットワークアドレス翻訳（ＮＡＴ）を動作させているなら、上記 メカニズムのすべてが正当なままです。ＮＡＴボックスは６to４メカニズム を含めて完全に機能的なＩＰｖ６ルーターを含んでいなくてはなりません。 V4ADDRに使われるアドレスは単純にＮＡＴに割り当てたグローバルユニーク ＩＰｖ４アドレスでしょう。上記５.１章の例で、６to４ルーターは同時にサ イトのＩＰｖ４ＮＡＴで、グローバルユニークＩＰｖ４アドレス192.1.2.3と 9.254.253.252を持ちます。 Combining a 6to4 router with an IPv4 NAT in this way offers the site concerned a globally unique IPv6 /48 prefix, automatically, behind the IPv4 address of the NAT. Thus every host behind the NAT can become an IPv6 host with no need for additional address space allocation, and no intervention by the Internet service provider. No address translation is needed by these IPv6 hosts. このように６to４ルータとＩＰｖ４ＮＡＴを一緒にすると、自動的にＮＡＴ のＩＰｖ４アドレスの背後のサイトにグローバルユニークＩＰｖ６の/48プレ フィックスを提供します。これですべてのＮＡＴの背後のホストがインター ネットサービスプロバイダの仲介なく、追加のアドレス空間割当てなしに、 ＩＰｖ６ホストになることができます。アドレス翻訳がこれらのＩＰｖ６ホ ストに必要ありません。 A more complex situation arises if a host is more than one NAT hop away from the globally unique IPv4 address space, since only the outermost NAT has a unique IPv4 address. All IPv6 hosts in this situation must use addresses derived from the 2002: prefix constructed from the global IPv4 address of the outermost NAT. The IPv4 addresses of the inner NATs are not globally unique and play no part in the 6to4 mechanism, and 6to4 encapsulation and decapsulation can only take place at the outermost NAT. いっそう複雑な状態は、もしホストが２つ以上のＮＡＴによりグローバルユ ニークＩＰｖ４アドレスから離れて、最も外側のＮＡＴだけがユニークなＩ Ｐｖ４アドレスを持っているいる場合です。すべてのこの状態のＩＰｖ６ホ ストは最も外側のＮＡＴのグローバルＩＰｖ４アドレスから作られた2002:: プレフィックスから得られるアドレスを使わなくてはなりません。内側のＮ ＡＴののＩＰｖ４アドレスはグローバルにユニークでなはなく、６to４メカ ニズムで役立たず、６to４カプセル化とカプセル解除は最も外側のＮＡＴで だけ起きます。 The Realm-Specific IP (RSIP) mechanism [RSIP] can also co-exist with 6to4. If a 6to4 border router is combined with an RSIP border router, it can support IPv6 hosts using 6to4 addresses, IPv4 hosts using RSIP, or dual stack hosts using both. The RSIP function provides fine-grained management of dynamic global IPv4 address allocation and the 6to4 function provides a stable IPv6 global address to each host. As with NAT, the IPv4 address used to construct the site's 2002: prefix will be one of the global addresses of the RSIP border router. 領域特定ＩＰ（RSIP）メカニズム[RSIP]は６to４と共存できます。もし６to ４境界ルータがRSIP境界ルータと一緒にされるなら、これは６to４アドレス を使っているＩＰｖ６ホスト、RSIPを使っているＩＰｖ４ホスト、あるいは 両方を使っているデュアルスタックホストをサポートできます。RSIP機能は ダイナミックなグローバルＩＰｖ４アドレス割当てのきめが細かい管理を供 給します、そして６to４機能はそれぞれのホストに安定したＩＰｖ６グロー バルなアドレスを供給します。ＮＡＴと同じように、サイトの2002::プレ フィックスを組み立てに使われたＩＰｖ４アドレスは、RSIP境界ルータのグ ローバルなアドレスの１つであるでしょう。 5.9 Usage within Intranets 5.9 イントラネット中での使用。 There is nothing to stop the above scenario being deployed within a private corporate network as part of its internal transition to IPv6; the corporate IPv4 backbone would serve as the virtual link layer for individual corporate sites using 2002:: prefixes. The V4ADDR MUST be a duly allocated global IPv4 address, which MUST be unique within the private network. The Intranet thereby obtains globally unique IPv6 addresses even if it is internally using private IPv4 addresses [RFC 1918]. その内部の一部がＩＰｖ６に移行する時、企業のプライベートネットワーク 内で上記シナリオが動くのを止める何もありません；企業のＩＰｖ４のバッ クボーンは企業の個別のサイトが2002::プレフィックスを使うことに関して 仮想のリンクレイヤの役をするでしょう。V4ADDRは正当に割り当てられたグ ローバルＩＰｖ４アドレスで(MUST)、これはプライベートネットワーク内で ユニークであるに違いありません(MUST)。イントラネットは、たとえそれが 内部でプライベートＩＰｖ４アドレス[RFC 1918]を使っているとしても、こ れによってグローバルユニークＩＰｖ６アドレスを得ます。 5.10 Summary of impact on routing 5.10 ルーティングの上の影響の要約 IGP (site) routing will treat the local site's 2002::/48 prefix exactly like a native IPv6 site prefix assigned to the local site. There will also be an IGP route to the generic 2002::/16 prefix, which will be a route to the site's 6to4 router, unless this is handled as a default route. IGP（サイト）ルーティングが、ローカルサイトに割り当てたネイティブＩＰ ｖ６サイトプレフィックス同様に、正確にローカルサイトの2002::/48プレ フィックスを扱うでしょう。一般的な2002::/16プレフィックスはIGP経路と 同じで、これがデフォルトルートと扱われないなら、サイトの６to４ルーター への経路でしょう。 EGP (i.e., BGP) routing will include advertisements for the 2002::/16 prefix from relay routers into the native IPv6 domain, whose scope is limited by routing policy. This is the only non-native IPv6 prefix advertised by BGP. ＥＧＰ（すなわちＢＧＰ）ルーティングがネイティブＩＰｖ６ドメインの中 にリレールーターからの2002::/16プレフィックスの広告を含み、その範囲は ルーティングポリシーによって制限されます。これはＢＧＰによって広告さ れる唯一の非ネイティブＩＰｖ６プレフィックスです。 It will be necessary for 6to4 routers to obtain routes to relay routers in order to access the native IPv6 domain. In the simplest case there will be a manually configured default IPv6 route to a relay router's address under the prefix {FP=001,TLA=0x0002,NLA=V4ADDR}/48, where V4ADDR is the IPv4 address of the relay router. Such a route could be used to establish a BGP session for the exchange of additional IPv6 routes. ネイティブＩＰｖ６ドメインにアクセスするためにリレールーターへの経路 を得ることが６to４ルーターに必要です。最も単純な場合に、V4ADDRをリレー ルーターのＩＰｖ４アドレスとした場合、プレフィックス {FP=001,TLA=0x0002,NLA=V4ADDR}/48下のリレールーターアドレスへのデフォ ルトＩＰｖ６ルートが手作業で設定されるでしょう。このようなルートは追 加のＩＰｖ６ルートの交換のためのBGPセッションを確立するために使うこと ができます。 By construction, unicast IPv6 traffic within a 6to4 domain will follow exactly the same path as unicast IPv4 traffic. 構成によって、６to４ドメイン内のユニキャストＩＰｖ６トラフィックが正 確にユニキャストＩＰｖ４トラフィックと同じパスに従うでしょう。 5.11. Routing loop prevention 5.11. 経路ループ防止 Since 6to4 has no impact on IPv4 routing, it cannot induce routing loops in IPv4. Since 2002: prefixes behave exactly like standard IPv6 prefixes, they will not create any new mechanisms for routing loops in IPv6 unless misconfigured. One very dangerous misconfiguration would be an announcement of the 2002::/16 prefix into a 6to4 exterior routing domain, since this would attract all 6to4 traffic into the site making the announcement. Its 6to4 router would then resend non-local 6to4 traffic back out, forming a loop. ６to４がＩＰｖ４ルーティングに影響を持っていないので、ＩＰｖ４ルーティ ングループを誘発することがありません。2002::プレフィックスが正確に標 準ＩＰｖ６プレフィックスのように振る舞い、設定誤りがなければ、ＩＰｖ ６で経路ループを生成しないでしょう。１つの非常に危険な設定誤りは、 2002::/16プレフィックスを６to４外部ルーティングドメイン内に広告する事 で、これは広告しているサイトにすべての６to４トラフィックを引き付ける でしょう。その６to４ルータはそれから、外に非ローカル６to４トラフィッ クを再送し、ループを生じます。 The 2002::/16 routing prefix may be legitimately advertised into the native IPv6 routing domain by a relay router, and into an IPv6 site's local IPv6 routing domain; hence there is a risk of misconfiguration causing it to be advertised into a 6to4 exterior routing domain. 2002::/16経路プレフィックスは合法的にリレールーターによってネイティブ ＩＰｖ６ルーティングドメインとＩＰｖ６サイトのローカルＩＰｖ６ルーティ ングドメインに広告されるかもしれません；それ故６to４外部ルーティング ドメインにこれを広告する設定誤りの危険があります。 To summarize, the 2002::/16 prefix MUST NOT be advertised to a 6to4 exterior routing domain. 要約すると2002::/16プレフィックスは６to４外部ルーティングドメインで広 告されてはなりません(MUST NOT)。 6. Multicast and Anycast 6. マルチキャストとエニキャスト It is not possible to assume the general availability of wide-area IPv4 multicast, so (unlike [6OVER4]) the 6to4 mechanism must assume only unicast capability in its underlying IPv4 carrier network. An IPv6 multicast routing protocol is needed [MULTI]. 広域ＩＰｖ４マルチキャストが一般的に利用可能とは考えられず、それで （[6OVER4]と異なり）６to４メカニズムはＩＰｖ４ネットワークでユニキャ スト能力だけを仮定しなくてはなりません。ＩＰｖ６マルチキャストルー ティングプロトコルが必要です[MULTI]。 The allocated anycast address space [ANYCAST] is compatible with 2002:: prefixes, i.e., anycast addresses formed with such prefixes may be used inside a 6to4 site. 割り当てられたエニキャストアドレス空間[ANYCAST]は2002::と両立できま す、すなわち、このようなプレフィックスで作られたエニキャストアドレ スが６to４サイト内で使われるかもしれません。 7. ICMP messages 7. ICMP メッセージ ICMP "unreachable" and other messages returned by the IPv4 routing system will be returned to the 6to4 router that generated a encapsulated 2002:: packet. However, this router will often be unable to return an ICMPv6 message to the originating IPv6 node, due to the lack of sufficient information in the "unreachable" message. This means that the IPv4 network will appear as an undiagnosable link layer for IPv6 operational purposes. Other considerations are as described in Section 4.1.3 of [MECH]. ＩＰｖ４ルーティングシステムの返した「到達不可能」や他のＩＣＭＰメッ セージはカプセル化した2002::パケットを生成した６to４ルーターに返され るでしょう。しかし、「到達不可能」メッセージに十分な情報がないため、 このルーターがＩＣＭＰｖ６メッセージを出発点のＩＰｖ６ノードに返すこ とがしばしば不可能でしょう。これはＩＰｖ４ネットワークがＩＰｖ６運用 の目的で診断不可能なリンク層と見えることを意味します。他の考察が [MECH]の４.１.３章で記述される通りです。 8. IANA Considerations 8. ＩＡＮＡの考察 No assignments by the IANA are required beyond the special TLA value 0x0002 already assigned. 特別なＴＬＡ値０x０００２以外、ＩＡＮＡによる割り当てを必要としません。 9. Security Considerations 9. セキュリティの考察。 Implementors should be aware that, in addition to possible attacks against IPv6, security attacks against IPv4 must also be considered. Use of IP security at both IPv4 and IPv6 levels should nevertheless be avoided, for efficiency reasons. For example, if IPv6 is running encrypted, encryption of IPv4 would be redundant except if traffic analysis is felt to be a threat. If IPv6 is running authenticated, then authentication of IPv4 will add little. Conversely, IPv4 security will not protect IPv6 traffic once it leaves the 6to4 domain. Therefore, implementing IPv6 security is required even if IPv4 security is available. 実装者は、ＩＰｖ６で可能な攻撃のほかに、ＩＰｖ４でのセキュリティ攻撃 を考慮すべき事に気づくべきです。ＩＰｖ４とＩＰｖ６レベルの両方でのＩ Ｐセキュリティの使用は、効率化のため、避けられるべきです。例えば、も しＩＰｖ６が暗号化されてるなら、ＩＰｖ４の暗号化が、トラフィック分析 が脅威と感じられる場合を除いて、重複するでしょう。もしＩＰｖ６が認証 されてるなら、ＩＰｖ４の認証がわずかな意味しかないでしょう。逆に、Ｉ Ｐｖ４セキュリティが、６to４ドメインを抜けると、ＩＰｖ６トラフィック を守らないでしょう。それ故、たとえＩＰｖ４セキュリティが利用可能でも、 ＩＰｖ６セキュリティ管理を実行することが必要です。 By default, 6to4 traffic will be accepted and decapsulated from any source from which regular IPv4 traffic is accepted. If this is for any reason felt to be a security risk (for example, if IPv6 spoofing is felt to be more likely than IPv4 spoofing), then additional source address based packet filtering could be applied. A possible plausibility check is whether the encapsulating IPv4 address is consistent with the encapsulated 2002:: address. If this check is applied, exceptions to it must be configured to admit traffic from relay routers (Section 5). 2002:: traffic must also be excepted from checks applied to prevent spoofing of "6 over 4" traffic [6OVER4]. デフォルトで、通常のＩＰｖ４トラフィックが受け入れられるどんなソース からも６to４トラフィックが受け入れられ、カプセル解除されるでしょう。 もしこれが危険と感じられる理由なら（例えば、もしＩＰｖ６スプーフがＩ Ｐｖ４スプーフよりいっそうありそうと感じられるなら）、追加のソースア ドレスによるパケットフィルターを適用できます。可能なもっともらしさの チェックは、カプセル化ＩＰｖ４アドレスが2002::アドレスと一致するかど うかです。もしこのチェックが適用されられるなら、リレールーターからの トラフィックを収容できるように、チェックの例外を設定しなければなりま せん（５章）。2002::トラフィックが、"6 over 4"トラフィック[6OVER4]の スプーフを妨げるために行うチェックから除外されなくてはなりません。 In any case, any 6to4 traffic whose source or destination address embeds a V4ADDR which is not in the format of a global unicast address MUST be silently discarded by both encapsulators and decapsulators. Specifically, this means that IPv4 addresses defined in [RFC 1918], broadcast, subnet broadcast, multicast and loopback addresses are unacceptable. いずれの場合でも、ソースか宛先アドレスにグローバルユニキャストアドレ スフォーマットでないV4ADDRを埋め込む６to４トラフィックでも静かにカプ セル化とカプセル解除の両方によって捨てられなくてはなりません(MUST)。 特にＩＰｖ４アドレスが、[RFC 1918]で定義したこの手段や、ブロードキャ ストや、サブネットブロードキャストや、マルチキャストや、ループバック アドレスは受け入れられません。 Acknowledgements 謝辞 The basic idea presented above is probably not original, and we have had invaluable comments from Magnus Ahltorp, Harald Alvestrand, Jim Bound, Scott Bradner, Randy Bush, Matt Crawford, Richard Draves, Jun-ichiro itojun Hagino, Joel Halpern, Tony Hain, Andy Hazeltine, Bob Hinden, Geoff Huston, Perry Metzger, Thomas Narten, Erik Nordmark, Markku Savela, Ole Troan, Sowmini Varadhan, members of the Compaq IPv6 engineering team, and other members of the NGTRANS working group. Some text has been copied from [6OVER4]. George Tsirtsis kindly drafted two of the diagrams. 上に提出された基本的な考えは恐らくオリジナルではなく、我々はMagnus AhltorpとHarald AlvestrandとJim BoundとScott BradnerとRandy Bushと Matt CrawfordとRichard DravesとJun-ichiro itojun HaginoとJoel Halpern とTony HainとAndy HazeltineとBob HindenとGeoff HustonとPerry Metzger とThomas NartenとErik NordmarkとMarkku SavelaとOle Troanと Sowmini VaradhanとコンパックＩＰｖ６エンジニアリングチームのメンバー とNGTRANSワーキンググループの他のメンバーから貴重なコメントをもらいま した。いくらかの文は[6OVER4]からコピーしました。George Tsirtsisは親切 に図の２つを立案しました。 References 参考文献 [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [AGGR] Hinden., R, O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998. [API] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. [BGP4+] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999. [CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [6OVER4] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [ANYCAST] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", Work in Progress. [MULTI] Thaler, D., "Support for Multicast over 6to4 Networks", Work in Progress. [SCALE] Hain, T., "6to4-relay discovery and scaling", Work in Progress. [SELECT] Draves, R., "Default Address Selection for IPv6", Work in Progress. [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [RSIP] Borella, M., Grabelsky, D., Lo, J. and K. Tuniguchi, "Realm Specific IP: Protocol Specification", Work in Progress. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998. Authors' Addresses 著者のアドレス Brian E. Carpenter IBM iCAIR, Suite 150 1890 Maple Avenue Evanston IL 60201, USA EMail: brian@icair.org Keith Moore UT Computer Science Department 1122 Volunteer Blvd, Ste 203 Knoxville, TN 37996-3450 USA EMail: moore@cs.utk.edu Intellectual Property 知的所有権 The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. この文書に記述された実装や技術に関して主張される知的財産や他の権利の 正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不 可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を 認識する調査をしたとは述べません。ＩＥＴＦ標準手続きと標準関連文書で の権利に関しての手順の情報はBCP-11を見てください。出版に利用する権利 の利用可能性とライセンスの保証の利用可能性か、あるいはこの仕様書の実 装者や利用者のこの様な所有権の一般的ライセンスや許可を得る試みの結果 はＩＥＴＦ事務局で得られます。 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求 めます。どうかＩＥＴＦ専務に情報を伝えてください。 Full Copyright Statement 著作権表示全文 Copyright (C) The Internet Society (2001). All Rights Reserved. 著作権（Ｃ）インターネット学会（２００１）。すべての権利は保留される。 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、 この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装 を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出 版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ ンターネット標準を開発する目的で必要な場合以外は、インターネット学会 や他のインターネット組織は著作権表示や参照を削除されるような変更がで きません、インターネット標準を開発する場合はインターネット標準化プロ セスで定義された著作権の手順に従われます。 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 上に与えられた限定された許可は永久で、インターネット学会やその後継者 や譲渡者によって無効にされません。 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. この文書とここに含む情報は無保証で供給され、そしてインターネット学会 とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情 報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で ある事の保障を含め、すべての保証を拒否します。 Acknowledgement 謝辞 Funding for the RFC Editor function is currently provided by the Internet Society. ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって 供給されます。