この文書はRFC3904の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group C. Huitema
Request for Comments: 3904 Microsoft
Category: Informational R. Austein
ISC
S. Satapati
Cisco Systems, Inc.
R. van der Pol
NLnet Labs
September 2004
Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks
非管理のネットワークのためのＩＰｖ６移行メカニズムの評価
Status of this Memo
この文書の状態
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
このメモはインターネット共同体のための情報を供給します。これはインター
ネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
Abstract
要約
This document analyzes issues involved in the transition of
"unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically
correspond to home networks or small office networks. A companion
paper analyzes out the requirements for mechanisms needed in various
transition scenarios of these networks to IPv6. Starting from this
analysis, we evaluate the suitability of mechanisms that have already
been specified, proposed, or deployed.
この文書はＩＰｖ４からＩＰｖ６への「非管理ネットワーク」の移行に関係
している事項を分析します。非管理ネットワークが典型的にホームネットワー
クあるいは小さいオフィスのネットワークに対応します。関連文書が、ネッ
トワークをＩＰｖ６に移行する種々なシナリオで必要なメカニズムの要求条
件を分析しました。この分析から始めて、我々はすでに指定や提案や配置さ
れたメカニズムの適合性を評価します。
Table of Contents:
目次：
1. Introduction
1. はじめに
2. Evaluation of Tunneling Solutions
2. トンネル解決策の評価
2.1. Comparing Automatic and Configured Solutions
2.1. 自動と設定の解決策の比較
2.1.1. Path Optimization in Automatic Tunnels
2.1.1. 自動トンネルでのパス最適化
2.1.2. Automatic Tunnels and Relays
2.1.2. 自動トンネルとリレー
2.1.3. The Risk of Several Parallel IPv6 Internets
2.1.3. いくつかの平行ＩＰｖ６インターネットの危険性
2.1.4. Lifespan of Transition Technologies
2.1.4. 移行技術の寿命
2.2. Cost and Benefits of NAT Traversal
2.2. ＮＡＴ横断のコストと利益
2.2.1. Cost of NAT Traversal
2.2.1. ＮＡＴ横断のコスト
2.2.2. Types of NAT
2.2.2. ＮＡＴ種別
2.2.3. Reuse of Existing Mechanisms
2.2.3. 既存のメカニズムの再利用
2.3. Development of Transition Mechanisms
2.3. 移行メカニズムの開発
3. Meeting Case A Requirements
3. 事例Ａの必要条件を満たすこと
3.1. Evaluation of Connectivity Mechanisms
3.1. 接続性メカニズムの評価
3.2. Security Considerations in Case A
3.2. 事例Ａでのセキュリティの考察
4. Meeting Case B Requirements
4. 事例Ｂの必要条件を満たすこと
4.1. Connectivity
4.1. 接続性
4.1.1. Extending a Subnet to Span Multiple Links
4.1.1. サブネットを多数の橋渡しリンクに拡張
4.1.2. Explicit Prefix Delegation
4.1.2. 明白なプレフィックス委任
4.1.3. Recommendation
4.1.3. 推薦
4.2. Communication Between IPv4-only and IPv6-capable Nodes
4.2. ＩＰｖ４のみとＩＰｖ６対応のノードの間の通信
4.3. Resolution of Names to IPv6 Addresses
4.3. 名前からＩＰｖ６アドレスへの解決
4.3.1. Provisioning the Address of a DNS Resolver
4.3.1. ＤＮＳリゾルバアドレスを供給すること
4.3.2. Publishing IPv6 Addresses to the Internet
4.3.2. インターネットにＩＰｖ６アドレスを公開すること
4.3.3. Resolving the IPv6 Addresses of Local Hosts
4.3.3. ローカルホストのＩＰｖ６アドレスの解決
4.3.4. Recommendations for Name Resolution
4.3.4. 名前解決のための推薦
4.4. Security Considerations in Case B
4.4. 事例Ｂでのセキュリティの考察
5. Meeting Case C Requirements
5. 事例Ｃの必要条件を満たすこと
5.1. Connectivity
5.1. 接続性
6. Meeting the Case D Requirements
6. 事例Ｄの必要条件を満たすこと
6.1. IPv6 Addressing Requirements
6.1. ＩＰｖ６アドレス必要条件
6.2. IPv4 Connectivity Requirements
6.2. ＩＰｖ４接続性必要条件
6.3. Naming Requirements
6.3. 名前の必要条件
7. Recommendations
7. 推薦
8. Security Considerations
8. セキュリティの考察
9. Acknowledgements
9. 謝辞
10. References
10. 参考文献
11. Authors' Addresses
11. 著者のアドレス
12. Full Copyright Statement
12. 著作権表示全文
1. Introduction
1. はじめに
This document analyzes the issues involved in the transition from
IPv4 to IPv6 [IPV6]. In a companion paper [UNMANREQ] we defined the
"unmanaged networks", which typically correspond to home networks or
small office networks, and the requirements for transition mechanisms
in various scenarios of transition to IPv6.
この文書はＩＰｖ４からＩＰｖ６への移行[IPV6]に関係している事柄を分析
します。関連文書[UNMANREQ]で我々は、典型的にホームネットワークあるい
は小さいオフィスネットワークに対応する、「非管理ネットワーク」と移行
の種々なシナリオのＩＰｖ６移行メカニズムの必要条件を定義します。
The requirements for unmanaged networks are expressed by analyzing
four classes of applications: local, client, peer to peer, and
servers, and are considering four cases of deployment. These are:
非管理ネットワークの必要条件は４種類のアプリケーションを分析すること
で表されます：ローカル、クライアント、ピア対ピア、そしてサーバ、そし
て４つの展開を考慮しています。これらは以下です：。
A) a gateway which does not provide IPv6 at all;
A) まったくＩＰｖ６を供給しないゲートウェイ；
B) a dual-stack gateway connected to a dual-stack ISP;
B) デュアルスタックＩＳＰに接続したデュアルスタックゲートウェイ；
C) a dual-stack gateway connected to an IPv4-only ISP; and
C) ＩＰｖ４のみのＩＳＰに接続したデュアルスタックゲートウェイ；そ
して
D) a gateway connected to an IPv6-only ISP.
D) ＩＰｖ６のみのＩＳＰに接続したゲートウェイ。
During the transition phase from IPv4 to IPv6 there will be IPv4-
only, dual-stack, or IPv6-only nodes. In this document, we make the
hypothesis that the IPv6-only nodes do not need to communicate with
IPv4-only nodes; devices that want to communicate with both IPv4 and
IPv6 nodes are expected to implement both IPv4 and IPv6, i.e., be
dual-stack.
ＩＰｖ４からＩＰｖ６への移行段階の間に、ＩＰｖ４のみとデュアルスタッ
クとＩＰｖ６のみのノードがあるでしょう。この文書で、我々はＩＰｖ６の
みのノードがＩＰｖ４のみのノードと通信する必要がないという仮説を作り
ます；ＩＰｖ４とＩＰｖ６ノードの両方と通信をすることを望む装置がＩＰ
ｖ４とＩＰｖ６の両方を実装する、すなわちデュアルスタックが期待されま
す。
The issues involved are described in the next sections. This
analysis outlines two types of requirements: connectivity
requirements, i.e., how to ensure that nodes can exchange IP packets,
and naming requirements, i.e., how to ensure that nodes can resolve
each-other's names. The connectivity requirements often require
tunneling solutions. We devote the first section of this memo to an
evaluation of various tunneling solutions.
関連する問題は次章で記述されます。この分析は必要条件の２つの種類を概
説します：接続性必要条件、すなわち、ノードがＩＰパケットを交換するこ
とができることを保証する方法と命名必要条件を、すなわち、ノードがお互
いの名前を変換することができることを保証する方法。接続性必要条件はし
ばしばトンネル解決策を必要とします。我々は種々なトンネル解決策の評価
のためにこの文章の最初の章を捧げます。
2. Evaluation of Tunneling Solutions
2. トンネル解決策の評価
In the case A and case C scenarios described in [UNMANREQ], the
unmanaged network cannot obtain IPv6 service, at least natively, from
its ISP. In these cases, the IPv6 service will have to be provided
through some form of tunnel. There have been multiple proposals on
different ways to tunnel IPv6 through an IPv4 service. We believe
that these proposals can be categorized according to two important
properties:
[UNMANREQ]で記述した事例Ａと事例Ｃのシナリオで、非管理ネットワークは
ＩＳＰから、少なくともネイティブＩＰｖ６サービスを得ることができませ
ん。これらの場合、ＩＰｖ６サービスはあるトンネル設定を通して供給され
なければならないでしょう。ＩＰｖ４サービスを通してのトンネルＩＰｖ６
の異なる多数の提案がありました。我々はこれらの提案が２つの重要な特性
に従って分類できると信じます：
* Is the deployment automatic, or does it require explicit
configuration or service provisioning?
* 設定は自動的か、あるいは明示的な設定やサービス供給を必要としますか？
* Does the proposal allow for the traversal of a NAT?
* 提案はＮＡＴ横断を考慮しますか？
These two questions divide the solution space into four broad
classes. Each of these classes has specific advantages and risks,
which we will now develop.
これらの２つの質問は解決策を４つの種類に分けます。これらの種類のそれ
ぞれが特定の利点と危険性を持ち、そしてこれを我々が今発展させるでしょ
う。
2.1. Comparing Automatic and Configured Solutions
2.1. 自動と設定の解決策の比較
It is possible to broadly classify tunneling solutions as either
"automatic" or "configured". In an automatic solution, a host or a
router builds an IPv6 address or an IPv6 prefix by combining a pre-
defined prefix with some local attribute, such as a local IPv4
address [6TO4] or the combination of an address and a port number
[TEREDO]. Another typical and very important characteristic of an
automatic solution is they aim to work with a minimal amount of
support or infrastructure for IPv6 in the local or remote ISPs.
「自動」と「設定」にトンネル解決策を分類することは可能です。自動的な
解決策で、ホストあるいはルータが前もって定義された接頭辞と何かのロー
カルな属性、例えばローカルＩＰｖ４アドレス[6TO4]やアドレスやポート番
号の組合わせ[TEREDO]、でＩＰｖ６アドレスや属性を構築します。自動設定
解決策の他の典型的で重要な特徴は、これらがローカルや遠隔ＩＳＰでのＩ
Ｐｖ６のために最小量の支持あるいは基盤で働くことを目指すということで
す。
In a configured solution, a host or a router identifies itself to a
tunneling service to set up a "configured tunnel" with an explicitly
defined "tunnel router". The amount of actual configuration may vary
from manually configured static tunnels to dynamic tunnel services
requiring only the configuration of a "tunnel broker", or even a
completely automatic discovery of the tunnel router.
設定解決策で、ホストあるいはルータが明示的に定義された「トンネルルー
タ」による「設定トンネル」の設定でトンネルサービス自身を識別します。
実際の設定量は手作業で配置された静的トンネルと、「トンネルブローカ」
の設定する動的トンネルサービスと、トンネルルータの自動探索で変わるか
もしれません。
Configured tunnels have many advantages over automatic tunnels. The
client is explicitly identified and can obtain a stable IPv6 address.
The service provider is also well identified and can be held
responsible for the quality of the service. It is possible to route
multicast packets over the established tunnel. There is a clear
address delegation path, which enables easy support for reverse DNS
lookups.
設定されたトンネルが自動的なトンネルより多くの利点を持っています。ク
ライアントは明示的に識別され、そして安定したＩＰｖ６アドレスを得るこ
とができます。サービスプロバイダは同じく明確に識別され、そしてサービ
スの品質に関して責任があると考えることができます。確立されたトンネル
上でマルチキャストパケットの転送は可能です。明確なアドレス委任パスが
あり、これは逆ＤＮＳ検索に対する容易なサポートを可能にします。
Automatic tunnels generally cannot provide the same level of service.
The IPv6 address is only as stable as the underlying IPv4 address,
the quality of service depends on relays operated by third parties,
there is typically no support for multicast, and there is often no
easy way to support reverse DNS lookups (although some workarounds
are probably possible). However, automatic tunnels have other
advantages. They are obviously easier to configure, since there is
no need for an explicit relation with a tunnel service. They may
also be more efficient in some cases, as they allow for "path
optimization".
自動的なトンネルは一般に同じレベルのサービスを供給できません。ＩＰｖ
６アドレスは基礎となるＩＰｖ４アドレスと同程度に安定なだけです、サー
ビスの品質は第三者によって操作された中継器に依存します、典型的にマル
チキャストに対するサポートがありません、そしてしばしば、（ある回避策
が恐らく可能であるけれども）、逆のＤＮＳ検索をサポートする容易な方法
がありません。しかしながら、自動的なトンネルが他の利点を持っています。
これらは明らかに、トンネルサービスと明示的な関係を持つ必要がないから、
配置がより容易です。これらは、「パス最適化」が可能なように割り当てら
れる場合には、より効率的であるかもしれません。
2.1.1. Path Optimization in Automatic Tunnels
2.1.1. 自動トンネルでのパス最適化
In automatic tunnels like [TEREDO] and [6TO4], the bulk of the
traffic between two nodes using the same technology is exchanged on a
direct path between the endpoints, using the IPv4 services to which
the endpoints already subscribe. By contrast, the configured tunnel
servers carry all the traffic exchanged by the tunnel client.
[TEREDO]と[6TO4]のような自動トンネルで、同じ技術を使っている２つのノー
ドの間のトラフィックの大部分は、終端がすでに受信しているＩＰｖ４サー
ビスを使って、終端への直接のパス上で交換されます。これと対照的に、設
定されたトンネルサーバはトンネルクライアントによって交換されたすべて
のトラフィックを運びます。
Path optimization is not a big issue if the tunnel server is close to
the client on the natural path between the client and its peers.
However, if the tunnel server is operated by a third party, this
third party will have to bear the cost of provisioning the bandwidth
used by the client. The associated costs can be significant.
パス最適化は、もしトンネルサーバがクライアントとそのピアの間の自然の
パス上でクライアントに近いなら、大きい問題ではありません。しかしなが
ら、もしトンネルサーバが第三者によって操作されるなら、この第三者はバ
ンド幅を供給するコストがクライアントに使われるのを我慢しなければなら
ないでしょう。関連したコストは重要であり得ます。
These costs are largely absent when the tunnels are configured by the
same ISP that provides the IPv4 service. The ISP can place the
tunnel end-points close to the client, i.e., mostly on the direct
path between the client and its peers.
これらのコストは、トンネルがＩＰｖ４サービスを供給するのと同じＩＳＰ
によって配置される時、主に無視されます。ＩＳＰはトンネル末端をクライ
アントに近く、つまりたいていはクライアントとそのピアの間の直接のパス
上に、置くことができます。
2.1.2. Automatic Tunnels and Relays
2.1.2. 自動トンネルとリレー
The economics arguments related to path optimization favor either
configured tunnels provided by the local ISP or automatic tunneling
regardless of the co-operation of ISPs. However, automatic solutions
require that relays be configured throughout the Internet. If a host
that obtained connectivity through an automatic tunnel service wants
to communicate with a "native" host or with a host using a configured
tunnel, it will need to use a relay service, and someone will have to
provide and pay for that service. We cannot escape economic
considerations for the deployment of these relays.
あるいはパス最適化と関係する経済的議論は、ローカルＩＳＰの供給する設
定トンネルか、ＩＳＰの協力なしの自動トンネルのどちらかを贔屓にします。
しかしながら、自動解決策はリレーがインターネットに配置されることを要
求します。もし自動トンネルサービスを通して接続性を得たホストが「ネイ
ティブ」ホストあるいは設定トンネルを使っているホストと通信を望むなら、
それはリレーサービスを使う必要があるでしょう、そして誰かが供給して、
そしてそのサービスに対して支払わなければならないでしょう。我々はこれ
らのリレーの配置に対する経済上の考慮から逃れることができません。
It is desirable to locate these relays close to the "native host".
During the transition period, the native ISPs have an interest in
providing a relay service for use by their native subscribers. Their
subscribers will enjoy better connectivity, and will therefore be
happier. Providing the service does not result in much extra
bandwidth requirement: the packets are exchanged between the local
subscribers and the Internet; they are simply using a v6-v4 path
instead of a v6-v6 path. (The native ISPs do not have an incentive
to provide relays for general use; they are expected to restrict
access to these relays to their customers.)
これらの「ネイティブホスト」に近いリレーの場所を突き止めることは望ま
しいです。移行期間に、ネイティブＩＳＰは彼らのネイティブ加入者の使用
するリレーサービスを提供することに対しての興味を持っています。彼らの
加入者はより良い接続性を楽しむでしょう、そして従ってもっと幸せである
でしょう。サービスを供給することはたくさんの余分のバンド幅の必要条件
をもたらしません：パケットはローカル加入者とインターネットの間で交換
されます；それらはＶ６ - Ｖ６パスの代わりにただＶ６ - Ｖ４パスを使っ
ています。（ネイティブＩＳＰは一般的な使用するリレーを提供する理由が
ありません；彼らは彼らの顧客だけにリレーのアクセスを制限することを期
待します。）
We should note however that different automatic tunneling techniques
have different deployment conditions.
我々はしかしながら異なる自動設定トンネル技術が異なる配置状態を持つこ
とを指摘するべきです。
2.1.3. The Risk of Several Parallel IPv6 Internets
2.1.3. いくつかの平行ＩＰｖ６インターネットの危険性
In an early deployment of the Teredo service by Microsoft, the relays
are provided by the native (or 6to4) hosts themselves. The native or
6to4 hosts are de-facto "multi-homed" to native and Teredo hosts,
although they never publish a Teredo address in the DNS or otherwise.
When a native host communicates with a Teredo host, the first packets
are exchanged through the native interface and relayed by the Teredo
server, while the subsequent packets are tunneled "end-to-end" over
IPv4 and UDP. This enables deployment of Teredo without having to
field an infrastructure of relays in the network.
マイクロソフトによる初期のＴｅｒｅｄｏサービスで、リレーはネイティブ
（あるいは６ｔｏ４）ホスト自身で供給されました。ネイティブあるいは６
ｔｏ４ホストは、ネイティブとＴｅｒｅｄｏホストへの事実上の「マルチホー
ム」で、それらはＤＮＳやその他でＴｅｒｅｄｏアドレスを公開することは
ありません。ネイティブのホストがＴｅｒｅｄｏホストと通信するとき、最
初のパケットはネイティブインターフェースを通して交換され、Ｔｅｒｅｄ
ｏサーバに中継され、続くパケットはＩＰｖ４上のＵＤＰで「エンドエンド」
トンネルされます。これはネットワークのリレーインフラに応対せずにＴｅ
ｒｅｄｏの配置を可能にします。
This type of solution carries the implicit risk of developing two
parallel IPv6 Internets, one native and one using Teredo: in order to
communicate with a Teredo-only host, a native IPv6 host has to
implement a Teredo interface. The Teredo implementations try to
mitigate this risk by always preferring native paths when available,
but a true mitigation requires that native hosts do not have to
implement the transition technology. This requires cooperation from
the IPv6 ISP, who will have to support the relays. An IPv6 ISP that
really wants to isolate its customers from the Teredo technology can
do that by providing native connectivity and a Teredo relay. The
ISP's customers will not need to implement their own relay.
この種の解決策は、１つはネイティブで１つはＴｅｒａｄｏを使う、２つの
ＩＰｖ６インターネットの暗黙の危険性があります：Ｔｅｒｅｄｏのみのホ
ストと通信するためには、ネイティブＩＰｖ６ホストはＴｅｒｅｄｏインター
フェースを実装しなければなりません。Ｔｅｒｅｄｏ実装は、利用可能であ
る時、常にネイティブパスを優先することでこの危険性を和らげようとしま
すが、本当の緩和はネイティブホストが移行技術を実装しなくてもよいこと
を要求します。これはリレーをサポートするＩＰｖ６のＩＳＰの協力を必要
とします。本当にＴｅｒｅｄｏ技術からその顧客を離すことを望むＩＰｖ６
のＩＳＰはネイティブの接続性とＴｅｒｅｄｏリレーを供給することによっ
てこれをできます。ＩＳＰの顧客は自身のリレーを実行する必要がないでしょ
う。
Communication between 6to4 networks and native networks uses a
different structure. There are two relays, one for each direction of
communication. The native host sends its packets through the nearest
6to4 router, i.e., the closest router advertising the 2002::/16
prefix through the IPv6 routing tables; the 6to4 network sends its
packet through a 6to4 relay that is either explicitly configured or
discovered through the 6to4 anycast address 192.88.99.1
[6TO4ANYCAST]. The experience so far is that simple 6to4 routers are
easy to deploy, but 6to4 relays are scarce. If there are too few
relays, these relays will create a bottleneck. The communications
between 6to4 and native networks will be slower than the direct
communications between 6to4 hosts. This will create an incentive for
native hosts to somehow "multi-home" to 6to4, de facto creating two
parallel Internets, 6to4 and native. This risk will only be
mitigated if there is a sufficient deployment of 6to4 relays.
６ｔｏ４ネットワークとネイティブネットワークの間の通信は異なった構造
を使います。通信のそれぞれの方向のために２つのリレーがあります。ネイ
ティブホストはそのパケットを最も近くの６ｔｏ４ルータに送ります、すな
わち、ＩＰｖ６ルーティングテーブルで2002::/16プレフィックスを広告して
いる最も近いルータに送ります；６ｔｏ４ネットワークはそのパケットを明
示的に設定されるか６ｔｏ４エニキャストアドレス192.88.99.1 [6TO4ANYCAST]
で発見される６ｔｏ４リレーを通して送ります。経験的に、これまでのとこ
ろ単純な６ｔｏ４ルータの設置は容易ですが、しかし６ｔｏ４リレーは不足
しています。もし余りにも少ない数のリレーりかないなら、これらのリレー
はボトルネックを作るでしょう。６ｔｏ４とネイティブネットワークの間の
通信は６ｔｏ４ホスト間に直接メッセージより遅いでしょう。これはネイティ
ブホストが６ｔｏ４と何かの「マルチホーム」をする誘引となり、事実上、
６ｔｏ４とネイティブの２つの平行したインターネットを作るでしょう。こ
の危険性は、もし６ｔｏ４リレーの十分な配置があるなら、和らげられるで
しょう。
The configured tunnel solutions do not carry this type of risk.
設定トンネル解決策はこのタイプの危険性を伴いません。
2.1.4. Lifespan of Transition Technologies
2.1.4. 移行技術の寿命
A related issue is the lifespan of the transition solutions. Since
automatic tunneling technologies enable an automatic deployment,
there is a risk that some hosts never migrate out of the transition.
The risk is arguably less for explicit tunnels: the ISPs who provide
the tunnels have an incentive to replace them with a native solution
as soon as possible.
関連した問題は移行解決の寿命です。自動設定トンネル技術が自動的な配置
を可能にするので、あるホストが移行状態から抜けない危険性があります。
危険性は明示的なトンネルではより低いです：トンネルを供給するＩＳＰは
できるだけ早くそれらをネイティブの解決策に置き換える誘因を持っていま
す。
Many implementations of automatic transition technologies incorporate
an "implicit sunset" mechanism: the hosts will not configure a
transition technology address if they have native connectivity; the
address selection mechanisms will prefer native addresses when
available. The transition technologies will stop being used
eventually, when native connectivity has been deployed everywhere.
However, the "implicit sunset" mechanism does not provide any hard
guarantee that transition will be complete at a certain date.
自動移行技術の多くの実装が「暗黙の終了」メカニズムを含みます：ホスト
は、もしネイティブの接続性を持つなら、移行技術アドレスを設定しないで
しょう、アドレス選択メカニズムは、利用可能である時、ネイティブアドレ
スの方を優先します。移行技術は結局は使われるのをやめるでしょう、そし
てその時ネイティブの接続性がどこでも働きます。しかしながら、「暗黙の
終了」メカニズムは移行がある日付に完了するという厳しい保証を供給しま
せん。
Yet, the support of transition technologies has a cost for the entire
network: native IPv6 ISPS have to support relays in order to provide
good performance and avoid the "parallel Internet" syndrome. These
costs may be acceptable during an initial deployment phase, but they
can certainly not be supported for an indefinite period. The
"implicit sunset" mechanisms may not be sufficient to guarantee a
finite lifespan of the transition.
それでも、移行技術のサポートは全部のネットワークのコストがあります：
ネイティブのＩＰｖ６のＩＳＰが良い性能を供給し、そして「平行インター
ネット」症を避けるためにリレーをサポートしなければなりません。これら
のコストは最初の配置段階の間に受容できるかもしれませんが、これらは確
実に不明確な時期の間にサポートされることができません。「暗黙の終了」
機構は移行の有限の寿命を保証することに十分ではないかもしれません。
2.2. Cost and Benefits of NAT Traversal
2.2. ＮＡＴ横断のコストと利益
During the transition, some hosts will be located behind IPv4 NATs.
In order to participate in the transition, these hosts will have to
use a tunneling mechanism designed to traverse NAT.
移行の間に、あるホストがＩＰｖ４ＮＡＴの後ろに位置するでしょう。移行
に参加するために、これらのホストはトンネルメカニズムがＮＡＴを越える
よう意図されなければならないでしょう。
We may ask whether NAT traversal should be a generic property of any
transition technology, or whether it makes sense to develop two types
of technologies, some "NAT capable" and some not. An important
question is also which kinds of NAT boxes one should be able to
traverse. One should probably also consider whether it is necessary
to build an IPv6 specific NAT traversal mechanism, or whether it is
possible to combine an existing IPv4 NAT traversal mechanism with
some form of IPv6 in IPv4 tunneling. There are many IPv4 NAT
traversal mechanisms; thus one may ask whether these need re-
invention, especially when they are already complex.
我々はＮＡＴ横断がすべての移行技術に対する一般特性を持つべきであるか
どうか、ある「ＮＡＴ対応」か否かの２種類の技術の開発の意味があるかど
うか、尋ねるかもしれません。重要な質問は、どの種類のＮＡＴ箱を横断可
能であるべきであるかです。恐らくＩＰｖ６特定のＮＡＴ横断メカニズムを
作ることが必要かどうか、あるいはＩＰｖ４トンネルで既存のＩＰｖ４ＮＡ
Ｔ横断メカニズムをあるＩＰｖ６の形式と一緒にすることは可能であるかど
うか考えるべきです。多くのＩＰｖ４ＮＡＴ横断メカニズムがあります；そ
れで、特にこれらがすでに複雑である時、これらの再発明を必要とするかど
うか尋ねてもよいです。
A related question is whether the NAT traversal technology should use
automatic tunnels or configured tunnels. We saw in the previous
section that one can argue both sides of this issue. In fact, there
are already deployed automatic and configured solutions, so the
reality is that we will probably see both.
関連した質問はＮＡＴ横断技術が自動的なトンネルあるいは設定されたトン
ネルを使うべきであるかどうかです。我々は前の章でこの問題の両側を議論
することができるのを見ました。実際、すでに動作する自動と設定の解決策
があります、それで我々が恐らく両方ともを見るのが現実です。
2.2.1. Cost of NAT Traversal
2.2.1. ＮＡＴ横断のコスト
NAT traversal technologies generally involve encapsulating IPv6
packets inside a transport protocol that is known to traverse NAT,
such as UDP or TCP. These transport technologies require
significantly more overhead than the simple tunneling over IPv4 used
in 6to4 or in IPv6 in IPv4 tunnels. For example, solutions based on
UDP require the frequent transmission of "keep alive" packets to
maintain a "mapping" in the NAT; solutions based on TCP may not
require such a mechanism, but they incur the risk of "head of queue
blocking", which may translate in poor performance. Given the
difference in performance, it makes sense to consider two types of
transition technologies, some capable of traversing NAT and some
aiming at the best performance.
ＮＡＴ横断技術が一般に、ＵＤＰやＴＣＰのような、ＮＡＴを横断すること
を知られている輸送プロトコルの中にＩＰｖ６パケットをカプセル化するこ
とを伴います。これらの輸送技術は、６ｔｏ４やＩＰｖ４上のＩＰｖ６トン
ネルで使われるＩＰｖ４上の単純なトンネルが より際立って多くのコストを
必要とします。例えば、ＵＤＰに基づいた解決策でＮＡＴが「対応関係」を
維持するために「生存確認」パケットの頻繁な送信を必要とします；ＴＣＰ
に基づいた解決策がこのようなメカニズムを必要としないかもしれませんが、
低い性能の翻訳するかもしれない「先頭キューブロック」の危険性がありま
す（訳注：head of queue blockingは、入キューの先頭のパケットが出回線
の輻輳により出力されず、その結果、空き回線へ行くパケットの出力が邪魔
される現象らしいです）。能力差を別にして、２種類の移行技術、ＮＡＴ横
断が可能なものと、最良性能を目指すもの、が考えられます。
2.2.2. Types of NAT
2.2.2. ＮＡＴ種別
There are many kinds of NAT on the market. Different models
implement different strategies for address and port allocations, and
different types of timers. It is desirable to find solutions that
cover "almost all" models of NAT.
多くの種類の市場に出ているＮＡＴがあります。モデル毎に、アドレスとポー
トの割り当てや、タイマで、異なる戦略を取ります。ＮＡＴの「ほとんどす
べて」モデルをカバーする解決策を見いだすことは望ましいです。
A configured tunnel solution will generally make fewer hypotheses on
the behavior of the NAT than an automatic solution. The configured
solutions only need to establish a connection between an internal
node and a server; this communication pattern is supported by pretty
much all NAT configurations. The variability will come from the type
of transport protocols that the NAT supports, especially when the NAT
also implements "firewall" functions. Some models will allow
establishment of a single "protocol 41" tunnel, while some may
prevent this type of transmission. Some models will allow UDP
transmission, while other may only allow TCP, or possibly HTTP.
設定トンネル解決策は一般にＮＡＴ行動に関して自動的な解決策より前提が
少ないでしょう。設定解決策は内部ノードとサーバ間にただ接続を確立する
必要があるだけです；この通信パターンはほとんどのＮＡＴ設定に対応しま
す。食い違いは、特にＮＡＴが「ファイアウォール」機能を実行する時、Ｎ
ＡＴがサポートする輸送プロトコルの種類から起こるでしょう。あるモデル
がひとつの「プロトコル４１」トンネルの設立を許し、他方、別のモデルが
この種類の伝達を妨げてもよいです。あるモデルがＵＤＰ送信を許し、他方
がただＴＣＰ、あるいはＨＴＴＰだけを許す事でもよいです。
The automatic solutions have to rely on a "lowest common denominator"
that is likely to be accepted by most models of NAT. In practice,
this common denominator is UDP. UDP based NAT traversal is required
by many applications, e.g., networked games or voice over IP. The
experience shows that most recent "home routers" are designed to
support these applications. In some edge cases, the automatic
solutions will require explicit configuration of a port in the home
router, using the so-called "DMZ" functions; however, these functions
are hard to use in an "unmanaged network" scenario.
自動的な解決策はたいていのＮＡＴのモデルによって受け入れられる可能性
が高い「最小共通項」に頼らなければなりません。実際は、この共通因子は
ＵＤＰです。ＵＤＰを基礎とするＮＡＴ横断はＩＰ上の多くのアプリケーショ
ン、例えば、ネットワークで結ばれたゲームや声によって必要とされます。
経験的に、たいていの最近の「ホームルータ」がこれらのアプリケーション
のサポートを支持するよう意図されてることが示されます。あるエッジの場
合で、自動的な解決策は、いわゆる「非武装地帯」機能を使って、ホームルー
タでのポートの明示的な設定を必要とするでしょう；しかしながら、これら
の機能は「非管理ネットワーク」シナリオきで使うことが難しいです。
2.2.3. Reuse of Existing Mechanisms
2.2.3. 既存のメカニズムの再利用
NAT traversal is not a problem for IPv6 alone. Many IPv4
applications have developed solutions, or kludges, to enable
communication across a NAT.
ＮＡＴ横断はＩＰｖ６だけのための問題ではありません。多くのＩＰｖ４ア
プリケーションがＮＡＴを越えた通信を可能にする解決策、あるいはクラッ
ジ、を開発しました。
Virtual Private Networks are established by installing tunnels
between VPN clients and VPN servers. These tunnels are designed
today to carry IPv4, but in many cases could easily carry IPv6. For
example, the proposed IETF standard, L2TP, includes a PPP layer that
can encapsulate IPv6 as well as IPv4. Several NAT models are
explicitly designed to pass VPN traffic, and several VPN solutions
have special provisions to traverse NAT. When we study the
establishment of configured tunnels through NAT, it makes a lot of
sense to consider existing VPN solutions.
仮想のプライベートのネットワークはＶＰＮクライアントとＶＰＮサーバ間
にトンネルを設置することによって確立されます。これらのトンネルは今日
ＩＰｖ４を運ぶよう意図されますが、多くの場合容易にＩＰｖ６を運ぶこと
ができました。例えば、提案ＩＥＴＦ標準、Ｌ２ＴＰは、ＩＰｖ４と同様、
ＩＰｖ６をカプセル化できるＰＰＰ層を含みます。いくつかのＮＡＴモデル
が明示的にＶＰＮトラフィックを通過するよう意図されます、そしていくつ
かのＶＰＮ解決策がＮＡＴを横断する特別な準備を持っています。我々がＮ
ＡＴを通通過する設定トンネルの設立を考える時、既存のＶＰＮ解決策を考
えると役に立ちます。
[STUN] is a protocol designed to facilitate the establishment of UDP
associations through NAT, by letting nodes behind NAT discover their
"external" address. The same function is required for automatic
tunneling through NAT, and one could consider reusing the STUN
specification as part of an automatic tunneling solution. However,
the automatic solutions also require a mechanism of bubbles to
establish the initial path through a NAT. This mechanism is not
present in STUN. It is not clear that a combination of STUN and a
bubble mechanism would have a technical advantage over a solution
specifically designed for automatic tunneling through NAT.
[STUN]は、ＮＡＴの後ろのノードが「外部」アドレスを発見する事で、ＮＡ
Ｔを通過するＵＤＰ連携の設立を意図するプロトコルです。同じ機能はＮＡ
Ｔを通過する自動設定トンネルのために必要で、自動設定トンネル解決策の
一部としてＳＴＵＮ仕様を再利用することを考えることができます。しかし
ながら、自動的な解決策はＮＡＴを通して最初のパスを確立する泡メカニズ
ムも要求します。このメカニズムはＳＴＵＮで存在していません。ＳＴＵＮ
と泡メカニズムの組合せが、特にＮＡＴを通過する自動設定トンネルのため
に設計された解決策の中で、技術的な利点を持つかどうかは明確ではありま
せん。
2.3. Development of Transition Mechanisms
2.3. 移行メカニズムの開発
The previous sections make the case for the development of four
transition mechanism, covering the following 4 configurations:
前の章は、次の４つの形式をカバーし、４つの移行メカニズムの開発に対し
て賛成します：
- Configured tunnel over IPv4 in the absence of NAT;
- ＮＡＴなしの、ＩＰｖ４上の設定トンネル；
- Automatic tunnel over IPv4 in the absence of NAT;
- ＮＡＴなしの、ＩＰｖ４上の自動トンネル；
- Configured tunnel across a NAT;
- ＮＡＴを越えた設定トンネル；
- Automatic tunnel across a NAT.
- ＮＡＴを超えた自動トンネル。
Teredo is an example of an already designed solution for automatic
tunnels across a NAT; 6to4 is an example of a solution for automatic
tunnels over IPv4 in the absence of NAT.
ＴｅｒｅｄｏはＮＡＴを超える自動トンネルのすでに設計された解決策の例
です；６ｔｏ４はＮＡＴなしでのＩＰｖ４上の自動トンネルの解決策の例で
す。
All solutions should be designed to meet generic requirements such as
security, scalability, support for reverse name lookup, or simple
management. In particular, automatic tunneling solutions may need to
be augmented with a special purpose reverse DNS lookup mechanism,
while configured tunnel solutions would benefit from an automatic
service configuration mechanism.
すべての解決策はセキュリティや、スケーラビリティや、逆名前検索や、単
純な管理に対するサポートのような、一般的な必要条件を満たすよう意図さ
れるべきです。特に、自動設定トンネル解決策で特別な目的の逆ＤＮＳ検索
メカニズムの拡張が必要があるかもしれず、他方設定トンネル解決策が自動
サービス設定機構から利益を得るでしょう。
3. Meeting Case A Requirements
3. 事例Ａの必要条件を満たすこと
In case A, isolated hosts need to acquire some form of connectivity.
In this section, we first evaluate how mechanisms already defined or
being worked on in the IETF meet this requirement. We then consider
the "remaining holes" and recommend specific developments.
事例Ａで、孤立ホストがある接続性の形式を獲得する必要があります。この
章で、我々は最初に、すでに定義されたメカニズムやＩＥＴＦで取組み中の
メカニズムがこの必要条件を満たすかを評価します。我々はそれから「残り
の穴」を考慮して、そして特定の開発を勧めます。
3.1. Evaluation of Connectivity Mechanisms
3.1. 接続性メカニズムの評価
In case A, IPv6 capable hosts seek IPv6 connectivity in order to
communicate with applications in the global IPv6 Internet. The
connectivity requirement can be met using either configured tunnels
or automatic tunnels.
事例Ａで、ＩＰｖ６対応のホストがグローバルＩＰｖ６インターネットでア
プリケーションと通信するためにＩＰｖ６接続性を求めます。接続性の必要
条件は設定トンネルあるいは自動トンネルを使って満たすことができます。
If the host is located behind a NAT, the tunneling technology should
be designed to traverse NAT; tunneling technologies that do not
support NAT traversal can obviously be used if the host is not
located behind a NAT.
もしホストがＮＡＴの後ろに位置しているなら、トンネル技術はＮＡＴを通
過するよう意図されるべきです；ＮＡＴ横断をサポートしないトンネル技術
は、明らかに、ホストがＮＡＴの後ろに位置していない場合に使うことがで
きます。
When the local ISP is willing to provide a configured tunnel
solution, we should make it easy for the host in case A to use it.
The requirements for such a service will be presented in another
document.
ローカルＩＳＰが設定トンネル解決策を供給する時、事例Ａのホストがそれ
を使うことを容易にするべきです。このようなサービスのための必要条件は
他の文書で提出されるでしょう。
An automatic solution like Teredo appears to be a good fit for
providing IPv6 connectivity to hosts behind NAT, in case A of IPv6
deployment. The service is designed for minimizing the cost of
deploying the server, which matches the requirement of minimizing the
cost of the "supporting infrastructure".
Ｔｅｒｅｄｏのような自動的な解決策が、ＩＰｖ６展開の事例Ａで、ＮＡＴ
の後ろのホストにＩＰｖ６接続性を供給することに対して良いように思われ
ます。サービスはサーバを設置するコストを最小にするように設計され、こ
れは「サポートインフラ」のコストを最小にする必要条件と一致します。
3.2. Security Considerations in Case A
3.2. 事例Ａでのセキュリティの考察
A characteristic of case A is that an isolated host acquires global
IPv6 connectivity, using either Teredo or an alternative tunneling
mechanism. If no precaution is taken, there is a risk of exposing to
the global Internet some applications and services that are only
expected to serve local hosts, e.g., those located behind the NAT
when a NAT is present. Developers and administrators should make
sure that the global IPv6 connectivity is restricted to only those
applications that are expressly designed for global Internet
connectivity. The users should be able to configure which
applications get IPv6 connectivity to the Internet and which should
not.
事例Ａの特徴は孤立ホストが、Ｔｅｒｅｄｏあるいは代わりのトンネルメカ
ニズムを使い、グローバルなＩＰｖ６接続性を獲得するということです。も
し用心しないと、あるローカルホストだけをを期待するアプリケーションや
サービス、例えば、ＮＡＴが存在している時ＮＡＴの後ろにあるようなのを、
グローバルインターネットにさらす危険性があります。開発者と管理者がグ
ローバルＩＰｖ６接続性がただ特別グローバルインターネット接続性のため
に設計されるそれらのアプリケーションだけに制限されることを確かにする
べきです。ユーザはどのアプリケーションがインターネットへのＩＰｖ６接
続性を得るべきで、どれが得ないべきか、設定できるべきです。
Any solution to the NAT traversal problem is likely to involve
relays. There are concerns that improperly designed protocols or
improperly managed relays could open new avenues for attacks against
Internet services. This issue should be addressed and mitigated in
the design of the NAT traversal protocols and in the deployment
guides for relays.
どんなＮＡＴ横断問題に対する解決策もリレーを巻き込む可能性が高いです。
インターネットサービスに対して不適当に設計されたプロトコルあるいは不
適当に管理されたリレーが攻撃への新しい道を開くことになる懸念がありま
す。この問題はＮＡＴ横断プロトコルの設計とリレーの配置ガイドラインで
扱われて軽減されるべきです。
4. Meeting Case B Requirements
4. 事例Ｂの必要条件を満たすこと
In case B, we assume that the gateway and the ISP are both dual-
stack. The hosts on the local network may be IPv4-only, dual-stack,
or IPv6-only. The main requirements are: prefix delegation and name
resolution. We also study the potential need for communication
between IPv4 and IPv6 hosts, and conclude that a dual-stack approach
is preferable.
事例Ｂで、我々はゲートウェイとＩＳＰが共に二重スタックであると想定し
ます。ローカルネットワーク上のホストはＩＰｖ４のみかデュアルスタック
かＩＰｖ６のみかもしれません。主な必要条件は以下です：プレフィックス
委任と名前解決。我々はＩＰｖ４とＩＰｖ６ホスト間でも通信の可能性があ
る必要を調査し、そしてデュアルスタックアプローチが望ましいと結論しま
す。
4.1. Connectivity
4.1. 接続性
The gateway must be able to acquire an IPv6 prefix, delegated by the
ISP. This can be done through explicit prefix delegation (e.g.,
[DHCPV6, PREFIXDHCPV6]), or if the ISP is advertising a /64 prefix on
the link, such a link can be extended by the use of an ND proxy or a
bridge.
ゲートウェイはＩＳＰによって委任されるＩＰｖ６プレフィックスを獲得で
きなければなりません。これは明白なプレフィックス委任を通してできます
（例えば[DHCPV6, PREFIXDHCPV6]）、あるいはもしＩＳＰがリンク上で/64プ
レフィックスの広告をしているなら、このようなリンクはＮＤプロクシある
いはブリッジの使用によって拡張ができます。
An ND proxy can also be used to extend a /64 prefix to multiple
physical links of different properties (e.g., an Ethernet and a PPP
link).
ＮＤプロクシが/64プレフィックスを異なる特性の多数の物理的なリンクにの
拡張するのに使用できます（例えば、イーサネットとＰＰＰリンク）。
4.1.1. Extending a Subnet to Span Multiple Links
4.1.1. サブネットを多数の橋渡しリンクに拡張
A /64 subnet can be extended to span multiple physical links using a
bridge or ND proxy. Bridges can be used when bridging multiple
similar media (mainly, Ethernet segments). On the other hand, an ND
proxy must be used if a /64 prefix has to be shared across media
(e.g., an upstream PPP link and a downstream Ethernet), or if an
interface cannot be put into promiscuous mode (e.g., an upstream
wireless link).
/64サブネットがブリッジあるいはＮＤプロクシを使って多数の物理的なリン
クを橋渡しするように拡張できます。ブリッジが多数の類似のメディア間の
橋渡しで使用できます（主に、イーサネットセグメント）。他方、ＮＤプロ
キシは、/64プレフィックスがメディア（例えば、上流ＰＰＰリンクと下流イー
サネット）を越えて共有する場合や、インタフェースが混在モード（例えば、
上流に無線リンク）にできないなら、使われなくてはなりません。
Extending a single subnet to span from the ISP to all of the
unmanaged network is not recommended, and prefix delegation should be
used when available. However, sometimes it is unavoidable. In
addition, sometimes it's necessary to extend a subnet in the
unmanaged network, at the "customer-side" of the gateway, and
changing the topology using routing might require too much expertise.
ＩＳＰから非管理ネットのすべてまでひとつのサブネットを拡張するのは推
薦されません、そして利用可能なら、プレフィックス委任が使われるべきで
す。しかしながら、時々それは不可避です。加えて、時々非管理ネットワー
クで、ゲートウェイの「顧客側」で、サブネットを拡張することが必要です、
そしてルーティングを使ってトポロジーを変えることは多くの専門的知識を
必要とするかもしれません。
The ND proxy method results in the sharing of the same prefix over
several links, a procedure generally known as "multi-link subnet".
This sharing has effects on neighbor discovery protocols, and
possibly also on other protocols such as LLMNR [LLMNR] that rely on
"link local multicast". These effects need to be carefully studied.
ＮＤプロキシの方法はいくつかのリンク上で、一般に「マルチリンクサブネッ
ト」として知られている手順で、同じプレフィックスの共有をもたらします。
この共有は、近隣探索プロトコルや、「リンクローカルマルチキャスト」に
依存するＬＬＭＮＲ［LLMNR］のような他のプロトコルに多分同じく効果を持
ちます。これらの効果は慎重に故意である必要があります。
4.1.2. Explicit Prefix Delegation
4.1.2. 明白なプレフィックス委任
Several networks have already started using an explicit prefix
delegation mechanism using DHCPv6. In this mechanism, the gateway
uses a DHCP request to obtain an adequate prefix from a DHCP server
managed by the Internet Service Provider. The DHCP request is
expected to carry proper identification of the gateway, which enables
the ISP to implement prefix delegation policies. It is expected that
the ISP assigns a /48 to the customer. The gateway should
automatically assign /64s out of this /48 to its internal links.
いくつかのネットワークですでにＤＨＣＰｖ６を使う明白なプレフィックス
委任機構を使い始めました。このメカニズムで、ゲートウェイはインターネッ
ト・サービスプロバイダによって管理されたＤＨＣＰサーバーから適切なプ
レフィックスを得るＤＨＣＰ要請を使います。ＤＨＣＰ要請はゲートウェイ
の適切な身元確認を伴うことを期待され、そしてこれはＩＳＰにプレフィッ
クス委任ポリシを実行することができるようにします。ＩＳＰが顧客に/48を
割り当てると思われます。ゲートウェイは内部リンクにこの/48から自動的に
/64を割り当てるべきです。
DHCP is insecure unless authentication is used. This may be a
particular problem if the link between gateway and ISP is shared by
multiple subscribers. DHCP specification includes authentication
options, but the operational procedures for managing the keys and
methods for sharing the required information between the customer and
the ISP are unclear. To be secure in such an environment in
practice, the practical details of managing the DHCP authentication
need to be analyzed.
ＤＨＣＰは、認証が使われないなら、安全でありません。これは、もしゲー
トウェイとＩＳＰ間のリンクが多数の加入者によって共有されるなら、特定
の問題であるかもしれません。ＤＨＣＰ仕様書が認証オプションを含みます
が、鍵を管理する運用手順と顧客とＩＳＰで必要な情報を共有する方法は不
明確です。実際はこのような環境で安全であるために、ＤＨＣＰ認証を管理
する実際的な詳細は分析される必要があります。
4.1.3. Recommendation
4.1.3. 推薦
The ND proxy and DHCP methods appear to have complementary domains of
application. ND proxy is a simple method that corresponds well to
the "informal sharing" of a link, while explicit delegation provides
strong administrative control. Both methods require development:
specify the interaction with neighbor discovery for ND proxy; provide
security guidelines for explicit delegation.
ＮＤプロキシとＤＨＣＰの方法はアプリケーションの補足的な範囲を持つよ
うに思われます。ＮＤプロキシは上手にリンクの「非公式共有」に対応する
単純な方法であり、他方明白な委任は強い管理上の制御を供給します。両方
の方法が開発を必要とします：ＮＤプロキシのための近隣探索での相互作用
を指定してください；明白な委任にセキュリティのガイドラインを提供して
ください。
4.2. Communication Between IPv4-only and IPv6-capable Nodes
4.2. ＩＰｖ４のみとＩＰｖ６対応のノードの間の通信
During the transition phase from IPv4 to IPv6, there will be IPv4-
only, dual-stack, and IPv6-only nodes. In theory, there may be a
need to provide some interconnection services so that IPv4-only and
IPv6-only hosts can communicate. However, it is hard to develop a
translation service that does not have unwanted side effects on the
efficiency or the security of communications. As a consequence, the
authors recommend that, if a device requires communication with
IPv4-only hosts, this device implements an IPv4 stack. The only
devices that should have IPv6-only connectivity are those that are
intended to only communicate with IPv6 hosts.
ＩＰｖ４からＩＰｖ６への移行段階の間に、ＩＰｖ４のみとデュアルスタッ
クとＩＰｖ６のみのノードがあるでしょう。理論上、ＩＰｖ４のみとＩＰｖ
６のみのホストが通信できるように、ある相互接続のサービスを供給する必
要があるかもしれません。しかしながら、効率あるいは通信のセキュリティ
上で望まれない副作用を持たない翻訳サービスを発展させることは難しいで
す。結果として、著者は、もし装置がＩＰｖ４のみのホストと通信を必要と
するなら、この装置がＩＰｖ４スタックを実装することを勧めます。ＩＰｖ
６のみの接続性を持つ唯一の装置は、ＩＰｖ６ホストと通信するだけを意図
されるものたちです。
4.3. Resolution of Names to IPv6 Addresses
4.3. 名前からＩＰｖ６アドレスへの解決
There are three types of name resolution services that should be
provided in case B: local IPv6 capable hosts must be able to obtain
the IPv6 addresses of correspondent hosts on the Internet, they
should be able to publish their address if they want to be accessed
from the Internet, and they should be able to obtain the IPv6 address
of other local IPv6 hosts. These three problems are described in the
next sections. Operational considerations and issues with IPv6 DNS
are analyzed in [DNSOPV6].
事例Ｂで供給されるべき名前解決サービスに３つの種類があります：ローカ
ルＩＰｖ６対応ホストはインターネット上の通信相手ホストのＩＰｖ６アド
レスを得ることができなければなりません、もしインターネットからアクセ
スされることを望むなら、アドレスを公開可能であるべきです、そして他の
ローカルなＩＰｖ６ホストのＩＰｖ６アドレスを得ることが可能であるべき
です。これらの３つの問題は次の章で記述されます。運用上の考慮とＩＰｖ
６ＤＮＳに関する問題が[DNSOPV6]で分析されます。
4.3.1. Provisioning the Address of a DNS Resolver
4.3.1. ＤＮＳリゾルバアドレスを供給すること
In an unmanaged environment, IPv4 hosts usually obtain the address of
the local DNS resolver through DHCPv4; the DHCPv4 service is
generally provided by the gateway. The gateway will also use DHCPv4
to obtain the address of a suitable resolver from the local Internet
service provider.
非管理な環境で、ＩＰｖ４ホストが通常ＤＨＣＰｖ４を通してローカルなＤ
ＮＳリゾルバのアドレスを得ます；ＤＨＣＰｖ４サービスは一般にゲートウェ
イによって供給されます。ゲートウェイはローカルなインターネット・サー
ビスプロバイダから適当なリゾルバのアドレスを得るために同じくＤＨＣＰ
ｖ４を使うでしょう。
The DHCPv4 solution will suffice in practice for the gateway and also
for the dual-stack hosts. There is evidence that DNS servers
accessed over IPv4 can serve arbitrary DNS records, including AAAA
records.
ＤＨＣＰｖ４解決策はゲートウェイとデュアルスタックホストで実際に十分
であるでしょう。ＩＰｖ４上でアクセスされたＤＮＳサーバが、ＡＡＡＡレ
コードを含む任意のＤＮＳレコードをサポートすることができるという証拠
があります。
Just using DHCPv4 will not be an adequate solution for IPv6-only
local hosts. The DHCP working group has defined how to use
(stateless) DHCPv6 to obtain the address of the DNS server
[DNSDHCPV6]. DHCPv6 and several other possibilities are being looked
at in the DNSOP Working Group.
ＤＨＣＰｖ４を使うことはＩＰｖ６のみのローカルホストのための適切な解
決策ではないでしょう。ＤＨＣＰ作業班はＤＮＳサーバのアドレスを得るた
めに（ステートレス）ＤＨＣＰｖ６を使う方法を定義しました[DNSDHCPV6]。
ＤＨＣＰｖ６といくつかの他の可能性はＤＮＳＯＰ作業班で見られています。
4.3.2. Publishing IPv6 Addresses to the Internet
4.3.2. インターネットにＩＰｖ６アドレスを公開すること
IPv6 capable hosts may be willing to provide services accessible from
the global Internet. They will thus need to publish their address in
a server that is publicly available. IPv4 hosts in unmanaged
networks have a similar problem today, which they solve using one of
three possible solutions:
ＩＰｖ６対応ホストはグローバルインターネットからアクセス可能なサービ
スを供給するかもしれません。それで公的に利用可能なサーバでそれらのア
ドレスを公開する必要があるでしょう。非管理ネットワークでのＩＰｖ４ホ
ストは今日類似の問題を持ち、そして３つの可能な解決の１つを使って解決
します：
* Manual configuration of a stable address in a DNS server;
* ＤＮＳサーバでの安定したアドレスの手動設定；
* Dynamic configuration using the standard dynamic DNS protocol;
* 標準動的ＤＮＳプロトコルを使う動的設定；
* Dynamic configuration using an ad hoc protocol.
* 特別なプロトコルを使う動的設定。
Manual configuration of stable addresses is not satisfactory in an
unmanaged IPv6 network: the prefix allocated to the gateway may or
may not be stable, and in any case, copying long hexadecimal strings
through a manual procedure is error prone.
安定したアドレスの手動設定は非管理なＩＰｖ６ネットワークで十分ではあ
りません：ゲートウェイに割当てられたプレフィックスは安定しているかも
しれないし、そうでないかもしれません、そしてどんな場合ででも、手動の
手順を通して長い１６進数文字列をコピーすることは間違う傾向があります。
Dynamic configuration using the same type of ad hoc protocols that
are common today is indeed possible, but the IETF should encourage
the use of standard solutions based on Dynamic DNS (DDNS).
アドホックなプロトコルと同様な動的設定は、今日、実際に本当に可能です
が、ＩＥＴＦは動的ＤＮＳ（ＤＤＮＳ）に基づいた標準解決策の使用を奨励
するべきです。
4.3.3. Resolving the IPv6 Addresses of Local Hosts
4.3.3. ローカルホストのＩＰｖ６アドレスの解決
There are two possible ways of resolving the IPv6 addresses of local
hosts: one may either publish the IPv6 addresses in a DNS server for
the local domain, or one may use a peer-to-peer address resolution
protocol such as LLMNR.
ローカルホストのＩＰｖ６アドレスを解決する２つの可能な方法があります：
１つはローカルドメインのＤＮＳサーバであるいはＩＰｖ６アドレスを公開
することで、他はＬＬＭＮＲのような１対１のアドレス解決プロトコルを使
う事です。
When a DNS server is used, this server could in theory be located
anywhere on the Internet. There is however a very strong argument
for using a local server, which will remain reachable even if the
network connectivity is down.
ＤＮＳサーバが使われる時、このサーバは理論上インターネット上のどこで
も位置し得ます。しかしながら、ローカルなサーバを使うことに非常に強い
根拠があり、これはたとえネットワーク接続性が停止ししているとしても、
通信可能なままでいるでしょう。
The use of a local server requires that IPv6 capable hosts discover
this server, as explained in 4.3.1, and then that they use a protocol
such as DDNS to publish their IPv6 addresses to this server. In
practice, the DNS address discovered in 4.3.1 will often be the
address of the gateway itself, and the local server will thus be the
gateway.
ローカルなサーバの使用は、４.３.１で説明したように、ＩＰｖ６対応ホス
トがこのサーバを見つけ、次にこのサーバにＩＰｖ６アドレスを公表するた
めにＤＤＮＳのようなプロトコルを使うことを要求します。実際は、４.３.１
で発見されたＤＮＳアドレスはしばしばゲートウェイ自身のアドレスで、そ
れでローカルサーバはゲートウェイであるでしょう。
An alternative to using a local server is LLMNR, which uses a
multicast mechanism to resolve DNS requests. LLMNR does not require
any service from the gateway, and also does not require that hosts
use DDNS. An important problem is that some networks only have
limited support for multicast transmission, for example, multicast
transmission on 802.11 network is error prone. However, unmanaged
networks also use multicast for neighbor discovery [NEIGHBOR]; the
requirements of ND and LLMNR are similar; if a link technology
supports use of ND, it can also enable use of LLMNR.
ローカルサーバを使うことに対する別案はＬＬＭＮＲで、これはＤＮＳリク
エストを解決するためにマルチキャストメカニズムを使います。ＬＬＭＮＲ
はゲートウェイサービスを必要とせず、同じくホストがＤＤＮＳを使うこと
を要求しません。重要な問題は若干のネットワークがマルチキャスト伝達に
対するサポートを制限するということです、例えば、８０２.１１ネットワー
ク上のマルチキャスト伝達がエラーの傾向があります。しかしながら、非管
理ネットワークが同じく近隣探索のためにマルチキャストを使います
[NEIGHBOR]；ＮＤとＬＬＭＮＲの必要条件は類似です、もしリンク技術がＮ
Ｄの使用をサポートするなら、それは同じくＬＬＭＮＲの使用を可能にする
ことができます。
4.3.4. Recommendations for Name Resolution
4.3.4. 名前解決のための推薦
The IETF should quickly provide a recommended procedure for
provisioning the DNS resolver in IPv6-only hosts.
ＩＥＴＦは速くＩＰｖ６のみのホストにＤＮＳリゾルバを供給する推薦され
た手順を供給するべきです。
The most plausible candidate for local name resolution appears to be
LLMNR; the IETF should quickly proceed to the standardization of that
protocol.
ローカルな名前導出のための最もよい候補はＬＬＭＮＲであるように思われ
ます；ＩＥＴＦはそのプロトコルの標準化に速く進むべきです。
4.4. Security Considerations in Case B
4.4. 事例Ｂでのセキュリティの考察
The case B solutions provide global IPv6 connectivity to the local
hosts. Removing the limit to connectivity imposed by NAT is both a
feature and a risk. Implementations should carefully limit global
IPv6 connectivity to only those applications that are specifically
designed to operate on the global Internet. Local applications, for
example, could be restricted to only use link-local addresses, or
addresses whose most significant bits match the prefix of the local
subnet, e.g., a prefix advertised as "on link" in a local router
advertisement. There is a debate as to whether such restrictions
should be "per-site" or "per-link", but this is not a serious issue
when an unmanaged network is composed of a single link.
事例Ｂの解決策はローカルホストにグローバルなＩＰｖ６接続性を供給しま
す。ＮＡＴによって課されて接続性の限界を取り除くことは特徴と危険の両
方です。実装が慎重に、グローバルインターネットで動作するよう意図され
るアプリケーションだけに、グローバルＩＰｖ６接続性を制限するべきです。
ローカルアプリケーションは、例えば、リンクローカルアドレスや上位ビッ
トがローカルサブネットのプレフィックス、つまりルータ広告で「リンク上」
広告されたもの、に一致するアドレスに制限されるべきです。このような制
限が「サイト毎」か「リンク毎」かについて議論がありますが、しかしこれ
は非管理ネットワークがひとつのリンクで構成されている時に、重大な問題
ではありません。
5. Meeting Case C Requirements
5. 事例Ｃの必要条件を満たすこと
Case C is very similar to case B, the difference being that the ISP
is not dual-stack. The gateway must thus use some form of tunneling
mechanism to obtain IPv6 connectivity, and an address prefix.
事例Ｃは事例Ｂととても似ていて、相違はＩＳＰがデュアルスタックではな
いということです。ゲートウェイはＩＰｖ６接続性とアドレスプレフィック
スを得るために何かのトンネルメカニズム形式を使わなくてはなりません。
A simplified form of case B is a single host with a global IPv4
address, i.e., with a direct connection to the IPv4 Internet. This
host will be able to use the same tunneling mechanisms as a gateway.
事例Ｂの単純化された形式はグローバルなＩＰｖ４アドレスを持っている１
つのホスト、すなわち、ＩＰｖ４インターネットへの直接接続です。このホ
ストは同じトンネルメカニズムをゲートウェイとして用いることが可能であ
るでしょう。
5.1. Connectivity
5.1. 接続性
Connectivity in case C requires some form of tunneling of IPv6 over
IPv4. The various tunneling solutions are discussed in section 2.
事例Ｃの接続性は、何らかの形式のＩＰｖ４上のＩＰｖ６のトンネルの形式
を必要とします。種々のトンネル解決策は２章で論じられます。
The requirements of case C can be solved by an automatic tunneling
mechanism such as 6to4 [6TO4]. An alternative may be the use of a
configured tunnels mechanism [TUNNELS], but as the local ISP is not
IPv6-enabled, this may not be feasible. The practical conclusion of
our analysis is that "upgraded gateways" will probably support the
6to4 technology, and will have an optional configuration option for
"configured tunnels".
事例Ｃの要求条件は６ｔｏ４[6TO4]のような自動設定トンネルメカニズムに
よって解くことができます。代替案は設定トンネルメカニズム[TUNNELS]の使
用であるかもしれません、しかしローカルＩＳＰはＩＰｖ６対応可能でない
から、これは実行可能ではないかもしれません。我々の分析の現実的な結論
は「更新されたゲートウェイ」が恐らく６ｔｏ４技術をサポートするでしょ
う、そして「設定トンネル」のための任意利用の設定選択肢を持つであろう
ということです。
The tunnel broker technology should be augmented to include support
for some form of automatic configuration.
トンネルブローカ技術はある自動設定形式に対するサポートを含むために拡
大するべきです。
Due to concerns with potential overload of public 6to4 relays, the
6to4 implementations should include a configuration option that
allows the user to take advantage of specific relays.
公共の６ｔｏ４リレーの過負荷の可能性の懸念のために、６ｔｏ４実装はユー
ザに特定のリレーを利用することを許す設定選択肢を含むべきです。
6. Meeting the Case D Requirements
6. 事例Ｄの必要条件を満たすこと
In case D, the ISP only provides IPv6 services.
事例Ｄで、ＩＳＰはただＩＰｖ６サービスを供給するだけです。
6.1. IPv6 Addressing Requirements
6.1. ＩＰｖ６アドレス必要条件
We expect IPv6 addressing in case D to proceed similarly to case B,
i.e., use either an ND proxy or explicit prefix delegation through
DHCPv6 to provision an IPv6 prefix on the gateway.
我々は事例ＤのＩＰｖ６アドレスは事例Ｂと同様と期待します、すなわち、
ゲートウェイにＩＰｖ６プレフィックスに供給するためにＮＤプロキシやＤ
ＨＣＰｖ６による明白なプレフィックス委任のどちらかを使います。
6.2. IPv4 Connectivity Requirements
6.2. ＩＰｖ４接続性必要条件
Local IPv4 capable hosts may still want to access IPv4-only services.
The proper way to do this for dual-stack nodes in the unmanaged
network is to develop a form of "IPv4 over IPv6" tunneling. There
are no standardized solutions and the IETF has devoted very little
effort to this issue, although there is ongoing work with [DSTM] and
[TSP]. A solution needs to be standardized. The standardization
will have to cover configuration issues, i.e., how to provision the
IPv4 capable hosts with the address of the local IPv4 tunnel servers.
ローカルＩＰｖ４対応ホストはまだＩＰｖ４のみのサービスにアクセスする
ことを望むかもしれません。非管理ネットワークでデュアルスタックノード
のためにこれをする適切な方法は「ＩＰｖ６上のＩＰｖ４」トンネル形式を
開発する事です。標準化された解決策がなく、そしてＩＥＴＦは進行中の仕
事が[DSTM]と[TSP]にあるけれども、この問題に極めて少ししか努力を捧げま
せんでした。解決策が標準化されている必要があります。標準化は設定問題、
すなわち、ローカルＩＰｖ４トンネルサーバのアドレスをＩＰｖ４ホストに
供給する方法を含まなければならないでしょう。
6.3. Naming Requirements
6.3. 名前の必要条件
Naming requirements are similar to case B, with one difference: the
gateway cannot expect to use DHCPv4 to obtain the address of the DNS
resolver recommended by the ISP.
名前の必要条件は１つを除いて事例Ｂと同様です：ゲートウェイはＩＳＰに
よって勧められたＤＮＳリゾルバのアドレスを得るためにＤＨＣＰｖ４を使
うことを期待できません。
7. Recommendations
7. 推薦
After a careful analysis of the possible solutions, we can list a set
of recommendations for the V6OPS working group:
可能な解決策の注意深い分析の後に、我々はＶ６ＯＰＳ作業班のために推薦
をリストアップできます：
1. To meet case A and case C requirements, we need to develop, or
continue to develop, four types of tunneling technologies:
automatic tunnels without NAT traversal such as [6TO4],
automatic tunnels with NAT traversal such as [TEREDO],
configured tunnels without NAT traversal such as [TUNNELS,
TSP], and configured tunnels with NAT traversal.
1. 事例Ａと事例Ｃの必要条件に一致するために、我々が４種類のトンネ
ルを開発あるいは開発し続ける必要があります：[6TO4]のようなＮＡ
Ｔ通過がない自動トンネル、[TEREDO]のようなＮＡＴ通過をのトンネ
ル、[TUNNELS, TSP]のようなＮＡＴ通過無しの設定トンネル、そして
ＮＡＴ通過の設定トンネルです。
2. To facilitate the use of configured tunnels, we need a
standardized way for hosts or gateways to discover the tunnel
server or tunnel broker that may have been configured by the
local ISP.
2. 設定トンネルの使用を容易にするために、我々はローカルＩＳＰによっ
て構成を設定されるかもしれないサーバかトンネルブローカを発見す
る、ホストやゲートウェイのための標準化された方法を必要とします。
3. To meet case B "informal prefix sharing" requirements, we would
need a standardized way to perform "ND proxy", possibly as part
of a "multi-link subnet" specification. (The explicit prefix
delegation can be accomplished through [PREFIXDHCPV6].)
3. 事例Ｂの「非公式プレフィックス共有」の必要条件を満たすために、
我々は、多分「マルチリンクサブネット」仕様の一部として、「ＮＤ
プロキシ」を実行する標準化された方法を必要とするでしょう。（明
白なプレフィックス委任は完全に達成され得ます[PREFIXDHCPV6]。）
4. To meet case B naming requirements, we need to proceed with the
standardization of LLMNR. (The provisioning of DNS parameters
can be accomplished through [DNSDHCPV6].)
4. 事例Ｂの名前の必要条件を満たすために、我々はＬＬＭＮＲの標準化
を続ける必要があります。（ＤＮＳパラメータを供給することは完全
に達成され得ます[DNSDHCPV6]。）
5. To meet case D IPv4 connectivity requirement, we need to
standardize an IPv4 over IPv6 tunneling mechanism, as well as
the associated configuration services.
5. 事例ＤのＩＰｖ４接続性の必要条件を満たすために、我々は、関連す
る設定サービスと共に、ＩＰｖ６上のＩＰｖ４トンネルメカニズムの
標準化の必要があります。
8. Security Considerations
8. セキュリティの考察
This memo describes the general requirements for transition
mechanisms. Specific security issues should be studied and addressed
during the development of the specific mechanisms.
この文書は移行メカニズムのための一般的な必要条件を記述します。特定の
セキュリティ問題が研究されて、特定のメカニズムの開発の間に扱われるべ
きです。
When hosts which have been behind a NAT are exposed to IPv6, the
security assumptions may change radically. This is mentioned in
sections 3.2 and 4.4. One way to cope with that is to have a default
firewall with a NAT-like access configuration; however, any such
firewall configuration should allow for easy authorization of those
applications that actually need global connectivity. One might also
restrict applications which can benefit from global IPv6 connectivity
on the nodes.
ＮＡＴの後ろにあったホストがＩＰｖ６で暴露される時、セキュリティの仮
定は根本的に変化するかもしれません。これは３.２章と４.４章で言及され
ます。これにうまく対処する一つの方法は、ＮＡＴのようなアクセス形状の
デフォルトファイアウォールを持つことです；しかしながら、このようなファ
イアウォール設定は実際にグローバルな接続性を必要とするアプリケーショ
ンの容易な認証を考慮するべきです。同じくノード上でグローバルＩＰｖ６
接続性を得ることができるアプリケーションを限定するかもしれません。
Security policies should be consistent between IPv4 and IPv6. A
policy which prevents use of v6 while allowing v4 will discourage
migration to v6 without significantly improving security. Developers
and administrators should make sure that global Internet connectivity
through either IPv4 or IPv6 is restricted to only those applications
that are expressly designed for global Internet connectivity.
セキュリティポリシはＩＰｖ４とＩＰｖ６の間で整合するべきです。Ｖ４を
許しながらＶ６の使用を妨げるポリシはセキュリティを改善せずにＶ６移行
を思いとどまらせるでしょう。開発者と管理者はＩＰｖ４あるいはＩＰｖ６
を通してのグローバルなインターネット接続性が、特別にグローバルインター
ネット接続性のために設計されるアプリケーションだけに制限されることを
確かにするべきです。
Several transition technologies require relays. There are concerns
that improperly designed protocols or improperly managed relays could
open new avenues for attacks against Internet services. This issue
should be addressed and mitigated in the design of the transition
technologies and in the deployment guides for relays.
いくつかの移行技術がリレーを必要とします。インターネットサービスに対
して不適当に設計されたプロトコルあるいは不適当に管理されたリレーが攻
撃への新しい道を開くという懸念があります。この問題は、移行技術の構想
やリレーの配置ガイドで取り上げて沈静させるべきです。
9. Acknowledgements
9. 謝辞
This memo has benefited from the comments of Margaret Wasserman,
Pekka Savola, Chirayu Patel, Tony Hain, Marc Blanchet, Ralph Droms,
Bill Sommerfeld, and Fred Templin. Tim Chown provided a lot of the
analysis for the tunneling requirements work.
この文書Margaret WassermanとPekka SavolaとChirayu PatelとTony Hainと
Marc BlanchetとRalph DromsとBill SommerfeldとFred Templinのコメントか
ら利益を得ました。Tim Chownはトンネル必要条件の仕事の分析の多くを提供
しました。
10. References
10. 参考文献
10.1. Normative References
10.1. 参照する参考文献
[UNMANREQ] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol, "Unmanaged Networks IPv6 Transition Scenarios",
RFC 3750, April 2004.
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[NEIGHBOR] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", RFC 3056, February 2001.
[6TO4ANYCAST] Huitema, C., "An Anycast Prefix for 6to4 Relay
Routers", RFC 3068, June 2001.
[TUNNELS] Durand, A., Fasano, P., Guardini, I., and D. Lento,
"IPv6 Tunnel Broker", RFC 3053, January 2001.
[DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[DNSDHCPV6] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[PREFIXDHCPV6] Troan, O. and R. Droms, "IPv6 Prefix Options for
Dynamic Host Configuration Protocol (DHCP) version 6",
RFC 3633, December 2003.
10.2. Informative References
10.2. 有益な参考文献
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R.
Mahy, "STUN - Simple Traversal of User Datagram
Protocol (UDP) Through Network Address Translators
(NATs)", RFC 3489, March 2003.
[DNSOPV6] Durand, A., Ihren, J., and P. Savola. "Operational
Considerations and Issues with IPv6 DNS", Work in
Progress.
[LLMNR] Esibov, L., Aboba, B., and D. Thaler, "Linklocal
Multicast Name Resolution (LLMNR)", Work in Progress.
[TSP] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel
Setup Protocol(TSP)", Work in Progress.
[DSTM] Bound, J., "Dual Stack Transition Mechanism", Work in
Progress.
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", Work in Progress.
11. Authors' Addresses
11. 著者のアドレス
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: huitema@microsoft.com
Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
EMail: sra@isc.org
Suresh Satapati
Cisco Systems, Inc.
San Jose, CA 95134
USA
EMail: satapati@cisco.com
Ronald van der Pol
NLnet Labs
Kruislaan 419
1098 VA Amsterdam
NL
EMail: Ronald.vanderPol@nlnetlabs.nl
12. Full Copyright Statement
12. 著作権表示全文
Copyright (C) The Internet Society (2004).
著作権（Ｃ）インターネット学会（２００４）。
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/iprにあるＩＥＴＦオンラインＩＰＲ
貯蔵庫で得られます。
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。