この文書はRFC3068の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group C. Huitema
Request for Comments: 3068 Microsoft
Category: Standards Track June 2001
An Anycast Prefix for 6to4 Relay Routers
６to４リレールーターのためのエニキャストプレフィックス
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 introduces a "6to4 anycast address" in order to simplify
the configuration of 6to4 routers. It also defines how this address
will be used by 6to4 relay routers, how the corresponding "6to4
anycast prefix" will be advertised in the IGP and in the EGP. The
memo documents the reservation by IANA (Internet Assigned Numbers
Authority) of the "6to4 relay anycast prefix."
このメモは６to４ルーターの設定を単純化するための「６to４エニキャスト
アドレス」を紹介します。またどのようにこのアドレスが６to４リレールー
ターによって使われるか、どのように対応する「６to４エニキャストプレ
フィックス」がＩＧＰやＥＧＰで広告されるか定義します。このメモは
「６to４リレーエニキャストプレフィックス」のためのＩＡＮＡ（インター
ネット番号割当当局）による予約を文書化します。
1 Introduction
1 はじめに
According to [RFC3056], there are two deployment options for a 6to4
routing domain, depending on whether or not the domain is using an
IPv6 exterior routing protocol. If a routing protocol is used, then
the 6to4 routers acquire routes to all existing IPv6 networks through
the combination of EGP and IGP. If 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. This second case is
typically used by small networks; for these networks, finding and
configuring the default route is in practice a significant hurdle.
In addition, even when the managers of these networks find an
available route, this route often points to a router on the other
side of the Internet, leading to very poor performance.
［RFC3056］によれば、ドメインがＩＰｖ６外部ルーティングプロトコルを
使っているかどうかによって、６to４ルーティングドメインのための２つの
配置オプションがあります。もしルーティングプロトコルが使われるなら、
６to４ルーターはＥＧＰとＩＧＰの組合せによりすべての既存のＩＰｖ６
ネットワークへの経路を獲得します。もしＩＰｖ６外部ルーティングプロト
コルが使われないなら、それぞれ所定のリレールーターを使う６to４ ルー
ターはデフォルトＩＰｖ６経路がリレールーターを指し示すようにします。
この２番目のケースは典型的に小さいネットワークによって使われます；こ
れらのネットワークのために、デフォルトルートを見いだし構成を設定する
ことは実際は重要な障害です。さらにこれらのネットワークの管理者が利用
可能な径路を見つけた時さえ、この径路はしばしばインターネットの他の方
向を示し、性能を著しく悪化させます。
The operation of 6to4 routers requires either that the routers
participate in IPv6 inter-domain routing, or that the routers be
provisioned with a default route. This memo proposes a standard
method to define the default route. It introduces the IANA assigned
"6to4 Relay anycast prefix" from which 6to4 packets will be
automatically routed to the nearest available router. It allows the
managers of the 6to4 relay routers to control the sources authorized
to use their resource. It makes it easy to set up a large number of
6to4 relay routers, thus enabling scalability.
６to４ルーターの運用は、ルーターＩＰｖ６ドメイン間ルーチングへの参加
か、ルータにデフォルトルートが供給されることのいずれかを必要とします。
このメモはデフォルトルートを定義する標準方法を提案します。それは最も
近くの利用可能なルーターに６to４パケットが自動的に導く、ＩＡＮＡで割
り当てられた「６to４リレーエニキャストプレフィックス」を導入します。
これは６to４リレールータの管理者に、リソースが使える利用者のコントロー
ルを許します。これは多数の６to４リレールータの準備を容易にし、スケー
ラブルにします。
2 Definitions
2 定義
This memo uses the definitions introduced in [RFC3056], in particular
the definition of a 6to4 router and a 6to4 Relay Router. It adds the
definition of the 6to4 Relay anycast prefix, 6to4 Relay anycast
address, 6to4 IPv6 relay anycast address, and Equivalent IPv4 unicast
address.
このメモは[RFC3056]で紹介された定義を使います、特に６to４ルーターの定
義と６to４中継ルーターです。これは６to４リレーエニキャストプレフィッ
クスと、６to４リレーエニキャストアドレスと、６to４ＩＰｖ６リレーエニ
キャストアドレスと、等価ＩＰｖ４ユニキャストアドレスの定義を加えます。
2.1 6to4 router (or 6to4 border router)
2.1 ６to４ルーター（あるいは６to４境界ルータ）
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４疑似インタフェースをサポートするＩＰｖ６ルータ。これは通常ＩＰ
ｖ６サイトと広域ＩＰｖ４ネットワーク間の境界ルータです。
2.2 6to4 Relay Router
2.2 ６to４リレールータ
A 6to4 router configured to support transit routing between 6to4
addresses and native IPv6 addresses.
６to４アドレスとネイティブのＩＰｖ６アドレスの間の中継ルーティングを
サポートするように設定された６to４ルータ。
2.3 6to4 Relay anycast prefix
2.3 ６to４リレーエニキャストプレフィックス
An IPv4 address prefix used to advertise an IPv4 route to an
available 6to4 Relay Router, as defined in this memo.
このメモで定義されるように、利用可能な６to４リレールータにＩＰｖ４
ルートを広告するために使わうＩＰｖ４アドレスプレフィックス。
The value of this prefix is 192.88.99.0/24
このプレフィックスの値は192.88.99.0/24です。
2.4 6to4 Relay anycast address
2.4 ６to４リレーエニキャストアドレス
An IPv4 address used to reach the nearest 6to4 Relay Router, as
defined in this memo.
このメモで定義されるように、最も近くの６to４ リレールータに届くため
に使われるＩＰｖ４アドレス。
The address corresponds to host number 1 in the 6to4 Relay anycast
prefix, 192.88.99.1.
アドレスは６to４リレーエニキャストプレフィックスのホストナンバー１
に対応します、つまり192.88.99.1。
2.5 6to4 IPv6 relay anycast address
2.5 ６to４ＩＰｖ６リレーエニキャストアドレス
The IPv6 address derived from the 6to4 Relay anycast address
according to the rules defined in 6to4, using a null prefix and a
null host identifier.
６to４の規則によりヌルプレフィックスとヌルホスト識別子を使って６to４
リレーエニキャストアドレスから生じたＩＰｖ６アドレス
The value of the address is "2002:c058:6301::".
アドレスの値は"2002:c058:6301::"です。
2.6 Equivalent IPv4 unicast address
2.6 等価ＩＰｖ４ユニキャストアドレス
A regular IPv4 address associated with a specific 6to4 Relay Router.
Packets sent to that address are treated by the 6to4 Relay Router as
if they had been sent to the 6to4 Relay anycast address.
特定の６to４リレールータと関連する通常のＩＰｖ４アドレス。このアドレ
スに送られたパケットは、これを６to４リレーエニキャストアドレスに送っ
たかのように、６to４リレールータに扱われます。
3 Model, requirements
3 モデルと必要条件
Operation of 6to4 routers in domains that don't run an IPv6 EGP
requires that these routers be configured with a default route to the
IPv6 Internet. This route will be expressed as a 6to4 address. The
packets bound to this route will be encapsulated in IPv4 whose source
will be an IPv4 address associated to the 6to4 router, and whose
destination will be the IPv4 address that is extracted from the
default route. We want to arrive at a model of operation in which
the configuration is automatic.
ＩＰｖ６ＥＧＰを動かさないドメインでの６to４ルータのオペレーションは
これらのルーターがＩＰｖ６インターネットのデフォルトルートで構成を設
定されることを要求します。このルートは６to４アドレスとして表されるで
しょう。この経路に入るパケットがＩＰｖ４にカプセル化され、そのソース
が６to４ルーターに関連づけられるＩＰｖ４アドレスで、その宛先がデフォ
ルトルートから抽出されるＩＰｖ４アドレスでしょう。我々は自動的に設定
できる運用モデルに到達することを望みます。
It should also be easy to set up a large number of 6to4 relay
routers, in order to cope with the demand. The discovery of the
nearest relay router should be automatic; if a router fails, the
traffic should be automatically redirected to the nearest available
router. The managers of the 6to4 relay routers should be able to
control the sources authorized to use their resource.
多数の６to４リレールータを設置し、要求をうまく対処することが容易であ
るべきです。最も近くのリレールータの発見は自動的であるべきです；もし
ルータが故障するなら、トラフィックは最も近くの利用可能なルータに自動
的にリダイレクトされるべきです。６to４リレールータの管理者ははリソー
スを使う権限を与えられたソースをコントロール可能であるべきです。
Anycast routing is known to cause operational issues: since the
sending 6to4 router does not directly identify the specific 6to4
relay router to which it forwards the packets, it is hard to identify
the responsible router in case of failure, in particular when the
failure is transient or intermittent. Anycast solutions must thus
include adequate monitoring of the routers performing the service, in
order to promptly detect and correct failures, and also adequate
fault isolation procedures, in order to find out the responsible
element when needed, e.g., following a user's complaint.
エニキャストルーティングが運用上の問題を起こすことを知られています：
送信６to４ルータが直接パケットを転送する特定の６to４リレールータを識
別しないので、故障がある場合、特に短期的か断続的故障の場合に、問題が
あるルーターを識別することが難しいです。エニキャスト解決がそれで、即
時検出と障害修理と適切な障害分離をするため、例えばユーザの苦情から問
題のある要素を見つけだすため、サービスを行っているルーターを即座のモ
ニターすることを含まなくてはなりません。
4 Description of the solution
4 解決の記述
4.1 Default route in the 6to4 routers
4.1 ６to４ルータのデフォルトルート
The 6to4 routers are configured with the default IPv6 route (::/0)
pointing to the 6to4 IPv6 anycast address.
６to４ルータはデフォルトＩＰｖ６ルート(::/0)が６to４ＩＰｖ６エニキャ
ストアドレスを指し示す状態で、構成を設定されます。
4.2 Behavior of 6to4 relay routers
4.2 ６to４リレールータの行動
The 6to4 relay routers that follow the specification of this memo
shall advertise the 6to4 anycast prefix, using the IGP of their IPv4
autonomous system, as if it where a connection to an external
network.
このメモの仕様に従う６to４リレールーターは、外部ネットワークに接続す
る場合のように、ＩＰｖ４自律システムのＩＧＰを使って、 ６to４エニキャ
ストプレフィックスを広告するべきです。
The 6to4 relay routers that advertise the 6to4 anycast prefix will
receive packets bound to the 6to4 anycast address. They will relay
these packets to the IPv6 Internet, as specified in [RFC3056].
６to４エニキャストプレフィックスを広告する６to４リレールーターは６to
４エニキャストアドレスに制約されたパケットを受け取るでしょう。それら
は、［RFC3056］で指定されるように、ＩＰｖ６インターネットにこれらのパ
ケットを中継するでしょう。
Each 6to4 relay router that advertise the 6to4 anycast prefix MUST
also provide an equivalent IPv4 unicast address. Packets sent to
that unicast address will follow the same processing path as packets
sent to the anycast address, i.e., be relayed to the IPv6 Internet.
６to４エニキャストプレフィックスを広告する各６to４ リレールータがが等
しいＩＰｖ４ユニキャストアドレスを供給しなくてはなりません。そのユニ
キャストアドレスに送られたパケットが、パケットをエニキャストアドレス
に送ったのと同じ処理パスに従うでしょう、すなわちＩＰｖ６インターネッ
トに中継されます。
4.3 Interaction with the EGP
4.3 ＥＧＰとの相互作用
If the managers of an IPv4 autonomous domain that includes 6to4 relay
routers want to make these routers available to neighbor ASes, they
will advertise reachability of the 6to4 anycast prefix. When this
advertisement is done using BGP, the initial AS path must contain the
AS number of the announcing AS. The AS path should also include an
indication of the actual router providing the service; there is a
suggestion to perform this function by documenting the router's
equivalent IPv4 address in the BGP aggregator attribute of the path;
further work is needed on this point.
もし６to４リレールーターを含むＩＰｖ４自律ドメインの管理者がこれらの
近隣ASに入手可能なルーターを作ることを望むなら、それらは６to４エニ
キャストプレフィックスの可到達性を広告するでしょう。この広告がＢＧＰ
を使ってされる時、最初のＡＳパスは広告するＡＳのＡＳ番号を含んでいな
くてはなりません。ＡＳパスはサービスを供給している実際のルーターの表
示を含むべきです；パスのＢＧＰ集約属性にルーターのＩＰｖ４アドレスを
含めてこの機能を実装するべき提案があります；将来の仕事がこの点で必要
とされます。
The path to the 6to4 anycast prefix may be propagated using standard
EGP procedures. The whole v6 network will appear to v4 as a single
multi-homed network, with multiple access points scattered over the
whole Internet.
６to４エニキャストプレフィックスへのパスは標準ＥＧＰ手順を使って伝え
られるかもしれません。v６ネットワーク全体はインターネット全体の上に、
多数のアクセスポイントがちりぢりであるという状態で、 v４上のマルチ
ホームネットワークとして現われるでしょう。
4.4 Monitoring of the 6to4 relay routers
4.4 ６to４リレールーターのモニタリング
Any 6to4 relay router corresponding to this specification must
include a monitoring function, to check that the 6to4 relay function
is operational. The router must stop injecting the route leading to
the 6to4 anycast prefix immediately if it detects that the relay
function is not operational.
どんなこの仕様書に対応している６to４リレールーターでも６to４リレー機
能が稼動中か調べるために、モニタリング機能を含まなくてはなりません。
ルーターは、もしリレー機能が稼動していないことを感じ取るなら、６to４
エニキャストプレフィックスの経路の注入をやめなくてはなりません。
The equivalent IPv4 address may be used to check remotely that a
specific router is operational, e.g., by tunneling a test IPv6 packet
through the router's equivalent unicast IPv4 address. When a domain
deploys several 6to4 relay routers, it is possible to build a
centralized monitoring function by using the list of equivalent IPv4
addresses of these routers.
等価ＩＰｖ４アドレスは特定のルータが稼動中か遠隔確認に使われます、つ
まり、ルーターの等価ユニキャストＩＰｖ４アドレスを通してＩＰｖ６パケッ
トをトンネルさせます。ドメインがいくつかの６to４リレールーターを実装
する時、これらのルーターで等しいＩＰｖ４アドレスのリストを使うことで
中央集権化されたモニタリング機能を構築することは可能です。
4.5 Fault isolation
4.5 障害分離
When an error is reported, e.g., by a user, the domain manager should
be able to find the specific 6to4 relay router that is causing the
problem. The first step of fault isolation is to retrieve the
equivalent unicast IPv4 address of the router used by the user. If
the router is located within the domain, this information will have
to be retrieved from the IGP tables. If the service is obtained
through a peering agreement with another domain, the information will
be retrieved from the EGP data, e.g., the BGP path attributes.
例えばユーザーによってエラーが報告される時、ドメイン管理者は問題を起
こしている特定の６to４リレールーターを見つける事が可能であるべきです。
障害分離の最初の手順はユーザーによって使われたルーターの等価ユニキャ
ストＩＰｖ４アドレスを調べることです。もしルーターがドメインの中に位
置しているなら、この情報はＩＧＰテーブルか探さなければならないでしょ
う。もしサービスが他のドメインとのピア協定を通して得られるなら、情報
はＥＧＰデータ、例えば、ＢＧＰパス属性から得られるでしょう。
The second step is obviously to perform connectivity tests using the
equivalent unicast IPv4 address.
２番目のステップは明らで、等価ユニキャストＩＰｖ４アドレスを使ってい
る接続性テストを行うことです。
5 Discussion of the solution
5 解決の議論
The initial surfacing of the proposal in the NGTRANS working group
helped us discover a number of issues, such as scaling concerns, the
size of the address prefix, the need for an AS number, and concerns
about risking to stay too long in a transition state.
NGTRANSワークグループでの提案の最初は、我々が多くの問題、例えばスケー
ルの問題や、アドレスプレフィックスの大きさや、自律システム番号の必要
数や、以降状態が長く続くことや、を発見しました。
5.1 Does it scale ?
5.1 これはスケールするか？
With the proposed scheme, it is easy to first deploy a small number
of relay routers, which will carry the limited 6to4 traffic during
the initial phases of IPv6 deployment. The routes to these routers
will be propagated according to standard peering agreements.
提言された案で、最初に小数のリレールーターを配置することは容易である、
そしてこれはＩＰｖ６展開初期段階の限定された ６to４ トラフィックを運
ぶでしょう。これらのルーターへのルートは標準的なピア協定に従って普及
させられるでしょう。
As the demand for IPv6 increases, we expect that more ISPs will
deploy 6to4 relay routers. Standard IPv4 routing procedures will
direct the traffic to the nearest relay router, assuring good
performance.
ＩＰｖ６に対する要求が増加するにつれて、もっと多くのＩＳＰが６to４リ
レールーターを設置すると思います。標準ＩＰｖ４ルーティング手順が、良
いパフォーマンスを保証し、トラフィックを最も近くのリレールーターに
向けるでしょう。
5.2 Discovery and failover
5.2 発見と障害回復
The 6to4 routers send packets bound to the v6 Internet by tunneling
them to the 6to4 anycast address. These packets will reach the
closest 6to4 relay router provided by their ISP, or by the closest
ISP according to inter-domain routing.
６to４ルーター送信パケットはv６インターネットにトンネルを堀ることによっ
て６to４エニキャストアドレスへそれらを拘束します。これらのパケットは
ドメイン間のルーティングに従ってそれらのＩＳＰや、最も近いＩＳＰに供
給された最も近い６to４リレールーターに届くでしょう。
The routes to the relay routers will be propagated according to
standard IPv4 routing rules. This ensures automatic discovery.
リレールーターへのルートは標準ＩＰｖ４ルーティング規則に従って普及さ
れるでしょう。これは自動的発見を保証します。
If a 6to4 relay router somehow breaks, or loses connectivity to the
v6 Internet, it will cease to advertise reachability of the 6to4
anycast prefix. At that point, the local IGP will automatically
compute a route towards the "next best" 6to4 relay router. We expect
that adequate monitoring tools will be used to guarantee timely
discovery of connectivity losses.
もし６to４リレールーターが壊れるか、v６インターネットの接続性を失うな
ら、６to４エニキャストプレフィックスの可到達性の広告をやめるでしょう。
その時点で、ローカルＩＧＰは「次の最良の」６to４リレールーターに向かっ
て自動的にルートを計算するでしょう。我々は適切なモニタリングツールが
接続性損失のタイムリーな発見を保証するために使われると思います。
5.3 Access control
5.3 アクセス制御
Only those ASes that run 6to4 relay routers and are willing to
provide access to the v6 network announce a path to the 6to4 anycast
prefix. They can use the existing structure of peering and transit
agreements to control to whom they are willing to provide service,
and possibly to charge for the service.
６to４リレールーターを動かし、v６ネットワークへのアクセスを供給するＡ
Ｓだけが６to４エニキャストプレフィックスのパスを発表します。誰にサー
ビスを供給するかやサービスの変更を制御するために、ピアリングや中継協
定を使うことができます。
5.4 Why do we need a large prefix?
5.4 なぜ我々は大きいプレフィックスを必要としますか？
In theory, a single IP address, a.k.a. a /32 prefix, would be
sufficient: all IGPs, and even BGP, can carry routes that are
arbitrarily specific. In practice, however, such routes are almost
guaranteed not to work.
理論上、ひとつのＩＰアドレス、a.k.a.a/32プレフィックスで十分であるで
しょう：すべてのＩＧＰと多分ＢＧＰで特定の経路が運べます。実際は、し
かしながら、このような経路はほとんど作動しないことが保証されます。
The size of the routing table is of great concern for the managers of
Internet "default free" networks: they don't want to waste a routing
entry, which is an important resource, for the sole benefit of a
small number of Internet nodes. Many have put in place filters that
automatically drop the routes that are too specific; most of these
filters are expressed as a function of the length of the address
prefix, such as "my network will not accept advertisements for a
network that is smaller than a /24." The actual limit may vary from
network to network, and also over time.
ルーティングテーブルの大きさはインターネット「デフォルトフリー」ネッ
トワークの管理で重要です：小数のインターネットノードの利益のために、
重要なリソースであるルーティング項目を浪費することを望みません。多く
が自動的にあまりにも特定された経路を落とすフィルターを適所に設置しま
した；これらのフィルターの大部分がアドレスプレフィックスの長さについ
て、「私のネットワークは/24以下の広告を受け入れない」といった関数で
表わされます。 実際の限界はネットワークとネットワークの間や、長い時間
で変化するかもしれません。
It could indeed be argued that using a large network is a waste of
the precious addressing resource. However, this is a waste for the
good cause of actually moving to IPv6, i.e., providing a real relief
to the address exhaustion problem.
大きいネットワークを使うことは貴重なアドレスリソースを浪費すると論じ
られることができました。しかしながら、これは実際にＩＰｖ６に動くため
のよい事のために浪費です、すなわち、アドレス極度の枯渇問題に真の軽減
を供給します。
5.5 Do we need a specific AS number?
5.5 特定の自律システム番号を必要とするか？
A first version of this memo suggested the use of a specific AS
number to designate a virtual AS containing all the 6to4 relay
routers. The rationale was to facilitate the registration of the
access point in databases such as the RADB routing registry [RADB].
Further analysis has shown that this was not required for practical
operation.
このメモの最初のバージョンはすべての６to４リレールーターを含む仮想の
自律システムを指定する特定の自律システム番号使用を提案しました。理由
はRADBルーティング登記所［RADB］のようなデータベースでアクセスポイン
トの登録を容易にためでした。さらなる分析でこれが実際の運用に必要ない
事を示しました。
5.6 Will this slow down the move to IPv6 ?
5.6 これはＩＰｖ６に動きの速度を遅くするでしょうか？
Some have expressed a concern that, while the assignment of an
anycast address to 6to4 access routers would make life a bit easier,
it would also tend to leave things in a transition state in
perpetuity. In fact, we believe that the opposite is true.
ある人たちが６to４アクセスルーターへのエニキャストアドレスの割当てが
生活を少しより楽にするが、以降状態を永久にする傾向があるだろうと表現
しました。実際は逆であると、我々は信じます。
A condition for easy migration out of the "tunnelling" state is that
it be easy to have connectivity to the "real" IPv6 network; this
means that people trust that opting for a real IPv6 address will not
somehow result in lower performances. So the anycast proposal
actually ensures that we don't stay in a perpetual transition.
「トンネル」状態からの容易な移住の条件は「本当の」ＩＰｖ６ネットワー
クへの接続性を持つために容易であるということです；これは人々がＩＰｖ
６アドレスを選ぶことが低い能力をもたらさないでことを確信することを意
味します。それでエニキャスト提案は実際は永久の移行状態にないことを保
証します。
6 Future Work
6 将来の仕事
Using a default route to reach the IPv6 Internet has a potential
drawback: the chosen relay may not be on the most direct path to the
target v6 address. In fact, one might argue that, in the early phase
of deployment, a relay close to the 6to4 site would probably not be
the site's ISP or the native destination's ISP...it would probably be
some third party ISP's relay which would be used for transit and may
have lousy connectivity. Using the relay closest to the native
destination would more closely match the v4 route, and quite possibly
provide a higher degree of reliability. A potential way to deal with
this issue is to use a "redirection" procedure, by which the 6to4
router learns the most appropriate route for a specific destination.
This is left for further study.
ＩＰｖ６インターネットに達するためにデフォルトルートを使うことは潜在
的な欠点を持っています：選ばれたリレーは目標v６アドレスの直接のパス
上にないかもしれません。実際、移行の早いフェーズに、６to４サイトに近
いリレーが恐らくサイトのＩＳＰかネイティブの宛先のＩＳＰではないであ
ろうと論ずるかもしれません．．．これは恐らく通過のために使われ、そし
てひどい接続性を持っているかもしれないサードパーティーＩＳＰのリレー
であるでしょう。ネイティブの目的地に最も近いリレーを使うことはv４ルー
トをいっそう近づけ、そしてできる限りより高度の信頼性を供給するでしょ
う。この問題を扱う可能性がある方法は、６to４ルーターが特定の宛先に対
する最も適切なルートを学ぶ「リダイレクト」手順です。これは今後の研究
です。
The practical operation of the 6to4 relay routers requires the
development of monitoring and testing tools, and the elaboration of
gradual management practices. While this document provides general
guidelines for the design of tools and practice, we expect that the
actual deployment will be guided by operational experience.
６to４ リレールーターの実際の運用はモニターとテストの道具を開発し、
丹念な段階的管理練習を必要とします。この文書が道具と実装のデザイン
の一般的なガイドラインを提供するが、実際の実装が操作の経験を導くと
思います。
7 Security Considerations
7 セキュリティの考察
The generic security risks of 6to4 tunneling and the appropriate
protections are discussed in [RFC3056]. The anycast technique
introduces an additional risk, that a rogue router or a rogue AS
would introduce a bogus route to the 6to4 anycast prefix, and thus
divert the traffic. IPv4 network managers have to guarantee the
integrity of their routing to the 6to4 anycast prefix in much the
same way that they guarantee the integrity of the generic v4 routing.
６to４トンネルの一般的な危険性とと適切な保護は［RFC3056］で論じられま
す。エニキャストテクニックは追加の危険をもたらします、いたずらなルー
ターやいたずらな自律システムが６to４エニキャストプレフィックスのにせ
のルートを紹介し、トラフィックの流れを変える可能性です。ＩＰｖ４ネッ
トワーク管理者が、一般的な v４ ルーティングの完全性を保証する同じ方法
で、６to４エニキャストプレフィックスの経路を決める方法の完全性を保証
しなければなりません。
8 IANA Considerations
8 ＩＡＮＡの考慮
The purpose of this memo is to document the allocation by IANA of an
IPv4 prefix dedicated to the 6to4 gateways to the native v6 Internet;
there is no need for any recurring assignment.
このメモの目的は６to４ゲートウェイからネイティブv６インターネット専用
のＩＰｖ４プレフィックスのＩＡＮＡの割り当てを文書化することです；さ
らなる割当ての必要がありません。
9. Intellectual Property
9. 知的財産
The following notice is copied from RFC 2026 [Bradner, 1996], Section
10.4, and describes the position of the IETF concerning intellectual
property claims made against this document.
次の通知はRFC 2026[Bradner, 1996]の１０.４章からコピーされ、この文書
に対してされた知的財産権問題に関してＩＥＴＦの立場を記述します。
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 other 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 implementers 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.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかＩＥＴＦ専務に情報を伝えてください。
10 Acknowledgements
10 謝辞
The discussion presented here was triggered by a note that Brad
Huntting sent to the NGTRANS and IPNG working groups. The note
revived previous informal discussions, for which we have to
acknowledge the members of the NGTRANS and IPNG working groups, in
particular Scott Bradner, Randy Bush, Brian Carpenter, Steve Deering,
Bob Fink, Tony Hain, Bill Manning, Keith Moore, Andrew Partan and
Dave Thaler.
ここで提出された論議はBrad HunttingがNGTRANSとIPNGワークグループに
送ったメモによって引き起こされました。メモは、我々がNGTRANSとIPNGワー
クグループのメンバー、特にScott BradnerとRandy BushとBrian Carpenter
とSteve DeeringとBob FinkとTony HainとBill ManningとKeith Mooreと
Andrew PartanとDave Thalerに感謝しなければならない、以前の非公式の論
議を復活させました。
11 References
11 参考文献
[RFC3056] Carpenter, B. and K. Moore "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[RADB] Introducing the RADB. Merit Networks,
http://www.radb.net/docs/intro.html.
12 Author's Address
12 著者のアドレス
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: huitema@microsoft.com
13 Full Copyright Statement
13 著作権表示全文
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。