この文書はRFC3068の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                         C. Huitema
Request for Comments: 3068                                     Microsoft
Category: Standards Track                                      June 2001


                An Anycast Prefix for 6to4 Relay Routers
           6to4リレールーターのためのエニキャストプレフィックス

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.
   この文書はインターネット共同体のためのインターネット標準化作業中のプ
   ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
   態とこのプロトコル状態は「インターネット公式プロトコル標準」(STD
   1)の現在の版を参照してください。このメモの配布は無制限です。

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."
   このメモは6to4ルーターの設定を単純化するための「6to4エニキャスト
   アドレス」を紹介します。またどのようにこのアドレスが6to4リレールー
   ターによって使われるか、どのように対応する「6to4エニキャストプレ
   フィックス」がIGPやEGPで広告されるか定義します。このメモは
   「6to4リレーエニキャストプレフィックス」のためのIANA(インター
   ネット番号割当当局)による予約を文書化します。

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]によれば、ドメインがIPv6外部ルーティングプロトコルを
   使っているかどうかによって、6to4ルーティングドメインのための2つの
   配置オプションがあります。もしルーティングプロトコルが使われるなら、
   6to4ルーターはEGPとIGPの組合せによりすべての既存のIPv6
   ネットワークへの経路を獲得します。もしIPv6外部ルーティングプロト
   コルが使われないなら、それぞれ所定のリレールーターを使う6to4 ルー
   ターはデフォルトIPv6経路がリレールーターを指し示すようにします。
   この2番目のケースは典型的に小さいネットワークによって使われます;こ
   れらのネットワークのために、デフォルトルートを見いだし構成を設定する
   ことは実際は重要な障害です。さらにこれらのネットワークの管理者が利用
   可能な径路を見つけた時さえ、この径路はしばしばインターネットの他の方
   向を示し、性能を著しく悪化させます。

   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.
   6to4ルーターの運用は、ルーターIPv6ドメイン間ルーチングへの参加
   か、ルータにデフォルトルートが供給されることのいずれかを必要とします。
   このメモはデフォルトルートを定義する標準方法を提案します。それは最も
   近くの利用可能なルーターに6to4パケットが自動的に導く、IANAで割
   り当てられた「6to4リレーエニキャストプレフィックス」を導入します。
   これは6to4リレールータの管理者に、リソースが使える利用者のコントロー
   ルを許します。これは多数の6to4リレールータの準備を容易にし、スケー
   ラブルにします。

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]で紹介された定義を使います、特に6to4ルーターの定
   義と6to4中継ルーターです。これは6to4リレーエニキャストプレフィッ
   クスと、6to4リレーエニキャストアドレスと、6to4IPv6リレーエニ
   キャストアドレスと、等価IPv4ユニキャストアドレスの定義を加えます。

2.1 6to4 router (or 6to4 border router)
2.1 6to4ルーター(あるいは6to4境界ルータ)

   An IPv6 router supporting a 6to4 pseudo-interface.  It is normally
   the border router between an IPv6 site and a wide-area IPv4 network.
   6to4疑似インタフェースをサポートするIPv6ルータ。これは通常IP
   v6サイトと広域IPv4ネットワーク間の境界ルータです。

2.2 6to4 Relay Router
2.2 6to4リレールータ

   A 6to4 router configured to support transit routing between 6to4
   addresses and native IPv6 addresses.
   6to4アドレスとネイティブのIPv6アドレスの間の中継ルーティングを
   サポートするように設定された6to4ルータ。

2.3 6to4 Relay anycast prefix
2.3 6to4リレーエニキャストプレフィックス

   An IPv4 address prefix used to advertise an IPv4  route to an
   available 6to4 Relay Router, as defined in this memo.
   このメモで定義されるように、利用可能な6to4リレールータにIPv4
   ルートを広告するために使わうIPv4アドレスプレフィックス。

   The value of this prefix is 192.88.99.0/24
   このプレフィックスの値は192.88.99.0/24です。

2.4 6to4 Relay anycast address
2.4 6to4リレーエニキャストアドレス

   An IPv4 address used to reach the nearest 6to4 Relay Router, as
   defined in this memo.
   このメモで定義されるように、最も近くの6to4 リレールータに届くため
   に使われるIPv4アドレス。

   The address corresponds to host number 1 in the 6to4 Relay anycast
   prefix, 192.88.99.1.
   アドレスは6to4リレーエニキャストプレフィックスのホストナンバー1
   に対応します、つまり192.88.99.1。

2.5 6to4 IPv6 relay anycast address
2.5 6to4IPv6リレーエニキャストアドレス

   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.
   6to4の規則によりヌルプレフィックスとヌルホスト識別子を使って6to4
   リレーエニキャストアドレスから生じたIPv6アドレス

   The value of the address is "2002:c058:6301::".
   アドレスの値は"2002:c058:6301::"です。

2.6 Equivalent IPv4 unicast address
2.6 等価IPv4ユニキャストアドレス

   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.
   特定の6to4リレールータと関連する通常のIPv4アドレス。このアドレ
   スに送られたパケットは、これを6to4リレーエニキャストアドレスに送っ
   たかのように、6to4リレールータに扱われます。

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.
   IPv6EGPを動かさないドメインでの6to4ルータのオペレーションは
   これらのルーターがIPv6インターネットのデフォルトルートで構成を設
   定されることを要求します。このルートは6to4アドレスとして表されるで
   しょう。この経路に入るパケットがIPv4にカプセル化され、そのソース
   が6to4ルーターに関連づけられるIPv4アドレスで、その宛先がデフォ
   ルトルートから抽出されるIPv4アドレスでしょう。我々は自動的に設定
   できる運用モデルに到達することを望みます。

   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.
   多数の6to4リレールータを設置し、要求をうまく対処することが容易であ
   るべきです。最も近くのリレールータの発見は自動的であるべきです;もし
   ルータが故障するなら、トラフィックは最も近くの利用可能なルータに自動
   的にリダイレクトされるべきです。6to4リレールータの管理者ははリソー
   スを使う権限を与えられたソースをコントロール可能であるべきです。

   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.
   エニキャストルーティングが運用上の問題を起こすことを知られています:
   送信6to4ルータが直接パケットを転送する特定の6to4リレールータを識
   別しないので、故障がある場合、特に短期的か断続的故障の場合に、問題が
   あるルーターを識別することが難しいです。エニキャスト解決がそれで、即
   時検出と障害修理と適切な障害分離をするため、例えばユーザの苦情から問
   題のある要素を見つけだすため、サービスを行っているルーターを即座のモ
   ニターすることを含まなくてはなりません。

4 Description of the solution
4 解決の記述

4.1 Default route in the 6to4 routers
4.1  6to4ルータのデフォルトルート

   The 6to4 routers are configured with the default IPv6 route (::/0)
   pointing to the 6to4 IPv6 anycast address.
   6to4ルータはデフォルトIPv6ルート(::/0)が6to4IPv6エニキャ
   ストアドレスを指し示す状態で、構成を設定されます。

4.2 Behavior of 6to4 relay routers
4.2 6to4リレールータの行動

   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.
   このメモの仕様に従う6to4リレールーターは、外部ネットワークに接続す
   る場合のように、IPv4自律システムのIGPを使って、 6to4エニキャ
   ストプレフィックスを広告するべきです。

   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].
   6to4エニキャストプレフィックスを広告する6to4リレールーターは6to
   4エニキャストアドレスに制約されたパケットを受け取るでしょう。それら
   は、[RFC3056]で指定されるように、IPv6インターネットにこれらのパ
   ケットを中継するでしょう。

   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.
   6to4エニキャストプレフィックスを広告する各6to4 リレールータがが等
   しいIPv4ユニキャストアドレスを供給しなくてはなりません。そのユニ
   キャストアドレスに送られたパケットが、パケットをエニキャストアドレス
   に送ったのと同じ処理パスに従うでしょう、すなわちIPv6インターネッ
   トに中継されます。

4.3 Interaction with the EGP
4.3 EGPとの相互作用

   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.
   もし6to4リレールーターを含むIPv4自律ドメインの管理者がこれらの
   近隣ASに入手可能なルーターを作ることを望むなら、それらは6to4エニ
   キャストプレフィックスの可到達性を広告するでしょう。この広告がBGP
   を使ってされる時、最初のASパスは広告するASのAS番号を含んでいな
   くてはなりません。ASパスはサービスを供給している実際のルーターの表
   示を含むべきです;パスのBGP集約属性にルーターのIPv4アドレスを
   含めてこの機能を実装するべき提案があります;将来の仕事がこの点で必要
   とされます。

   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.
   6to4エニキャストプレフィックスへのパスは標準EGP手順を使って伝え
   られるかもしれません。v6ネットワーク全体はインターネット全体の上に、
   多数のアクセスポイントがちりぢりであるという状態で、 v4上のマルチ
   ホームネットワークとして現われるでしょう。

4.4 Monitoring of the 6to4 relay routers
4.4 6to4リレールーターのモニタリング

   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.
   どんなこの仕様書に対応している6to4リレールーターでも6to4リレー機
   能が稼動中か調べるために、モニタリング機能を含まなくてはなりません。
   ルーターは、もしリレー機能が稼動していないことを感じ取るなら、6to4
   エニキャストプレフィックスの経路の注入をやめなくてはなりません。

   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.
   等価IPv4アドレスは特定のルータが稼動中か遠隔確認に使われます、つ
   まり、ルーターの等価ユニキャストIPv4アドレスを通してIPv6パケッ
   トをトンネルさせます。ドメインがいくつかの6to4リレールーターを実装
   する時、これらのルーターで等しいIPv4アドレスのリストを使うことで
   中央集権化されたモニタリング機能を構築することは可能です。

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.
   例えばユーザーによってエラーが報告される時、ドメイン管理者は問題を起
   こしている特定の6to4リレールーターを見つける事が可能であるべきです。
   障害分離の最初の手順はユーザーによって使われたルーターの等価ユニキャ
   ストIPv4アドレスを調べることです。もしルーターがドメインの中に位
   置しているなら、この情報はIGPテーブルか探さなければならないでしょ
   う。もしサービスが他のドメインとのピア協定を通して得られるなら、情報
   はEGPデータ、例えば、BGPパス属性から得られるでしょう。

   The second step is obviously to perform connectivity tests using the
   equivalent unicast IPv4 address.
   2番目のステップは明らで、等価ユニキャストIPv4アドレスを使ってい
   る接続性テストを行うことです。

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.
   提言された案で、最初に小数のリレールーターを配置することは容易である、
   そしてこれはIPv6展開初期段階の限定された 6to4 トラフィックを運
   ぶでしょう。これらのルーターへのルートは標準的なピア協定に従って普及
   させられるでしょう。

   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.
   IPv6に対する要求が増加するにつれて、もっと多くのISPが6to4リ
   レールーターを設置すると思います。標準IPv4ルーティング手順が、良
   いパフォーマンスを保証し、トラフィックを最も近くのリレールーターに
   向けるでしょう。

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.
   6to4ルーター送信パケットはv6インターネットにトンネルを堀ることによっ
   て6to4エニキャストアドレスへそれらを拘束します。これらのパケットは
   ドメイン間のルーティングに従ってそれらのISPや、最も近いISPに供
   給された最も近い6to4リレールーターに届くでしょう。

   The routes to the relay routers will be propagated according to
   standard IPv4 routing rules.  This ensures automatic discovery.
   リレールーターへのルートは標準IPv4ルーティング規則に従って普及さ
   れるでしょう。これは自動的発見を保証します。

   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.
   もし6to4リレールーターが壊れるか、v6インターネットの接続性を失うな
   ら、6to4エニキャストプレフィックスの可到達性の広告をやめるでしょう。
   その時点で、ローカルIGPは「次の最良の」6to4リレールーターに向かっ
   て自動的にルートを計算するでしょう。我々は適切なモニタリングツールが
   接続性損失のタイムリーな発見を保証するために使われると思います。

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.
   6to4リレールーターを動かし、v6ネットワークへのアクセスを供給するA
   Sだけが6to4エニキャストプレフィックスのパスを発表します。誰にサー
   ビスを供給するかやサービスの変更を制御するために、ピアリングや中継協
   定を使うことができます。

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.
   理論上、ひとつのIPアドレス、a.k.a.a/32プレフィックスで十分であるで
   しょう:すべてのIGPと多分BGPで特定の経路が運べます。実際は、し
   かしながら、このような経路はほとんど作動しないことが保証されます。

   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.
   大きいネットワークを使うことは貴重なアドレスリソースを浪費すると論じ
   られることができました。しかしながら、これは実際にIPv6に動くため
   のよい事のために浪費です、すなわち、アドレス極度の枯渇問題に真の軽減
   を供給します。

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.
   このメモの最初のバージョンはすべての6to4リレールーターを含む仮想の
   自律システムを指定する特定の自律システム番号使用を提案しました。理由
   はRADBルーティング登記所[RADB]のようなデータベースでアクセスポイン
   トの登録を容易にためでした。さらなる分析でこれが実際の運用に必要ない
   事を示しました。

5.6 Will this slow down the move to IPv6 ?
5.6 これはIPv6に動きの速度を遅くするでしょうか?

   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.
   ある人たちが6to4アクセスルーターへのエニキャストアドレスの割当てが
   生活を少しより楽にするが、以降状態を永久にする傾向があるだろうと表現
   しました。実際は逆であると、我々は信じます。

   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.
   「トンネル」状態からの容易な移住の条件は「本当の」IPv6ネットワー
   クへの接続性を持つために容易であるということです;これは人々がIPv
   6アドレスを選ぶことが低い能力をもたらさないでことを確信することを意
   味します。それでエニキャスト提案は実際は永久の移行状態にないことを保
   証します。

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.
   IPv6インターネットに達するためにデフォルトルートを使うことは潜在
   的な欠点を持っています:選ばれたリレーは目標v6アドレスの直接のパス
   上にないかもしれません。実際、移行の早いフェーズに、6to4サイトに近
   いリレーが恐らくサイトのISPかネイティブの宛先のISPではないであ
   ろうと論ずるかもしれません...これは恐らく通過のために使われ、そし
   てひどい接続性を持っているかもしれないサードパーティーISPのリレー
   であるでしょう。ネイティブの目的地に最も近いリレーを使うことはv4ルー
   トをいっそう近づけ、そしてできる限りより高度の信頼性を供給するでしょ
   う。この問題を扱う可能性がある方法は、6to4ルーターが特定の宛先に対
   する最も適切なルートを学ぶ「リダイレクト」手順です。これは今後の研究
   です。

   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.
   6to4 リレールーターの実際の運用はモニターとテストの道具を開発し、
   丹念な段階的管理練習を必要とします。この文書が道具と実装のデザイン
   の一般的なガイドラインを提供するが、実際の実装が操作の経験を導くと
   思います。

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.
   6to4トンネルの一般的な危険性とと適切な保護は[RFC3056]で論じられま
   す。エニキャストテクニックは追加の危険をもたらします、いたずらなルー
   ターやいたずらな自律システムが6to4エニキャストプレフィックスのにせ
   のルートを紹介し、トラフィックの流れを変える可能性です。IPv4ネッ
   トワーク管理者が、一般的な v4 ルーティングの完全性を保証する同じ方法
   で、6to4エニキャストプレフィックスの経路を決める方法の完全性を保証
   しなければなりません。

8 IANA Considerations
8 IANAの考慮

   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.
   このメモの目的は6to4ゲートウェイからネイティブv6インターネット専用
   のIPv4プレフィックスのIANAの割り当てを文書化することです;さ
   らなる割当ての必要がありません。

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]の10.4章からコピーされ、この文書
   に対してされた知的財産権問題に関してIETFの立場を記述します。

   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.
   この文書に記述された実装や技術に関して主張される知的財産や他の権利の
   正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
   可能かの範囲について、IETFは何の立場もとりません;この様な権利を
   認識する調査をしたとは述べません。IETF標準手続きと標準関連文書で
   の権利に関しての手順の情報はBCP-11を見てください。出版に利用する権利
   の利用可能性とライセンスの保証の利用可能性か、あるいはこの仕様書の実
   装者や利用者のこの様な所有権の一般的ライセンスや許可を得る試みの結果
   はIETF事務局で得られます。

   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.
   IETFは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
   バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
   めます。どうかIETF専務に情報を伝えてください。

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.
   著作権(C)インターネット学会(2001)。すべての権利は保留される。

   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.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So