この文書はRFC3750の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group C. Huitema
Request for Comments: 3750 Microsoft
Category: Informational R. Austein
ISC
S. Satapati
Cisco Systems, Inc.
R. van der Pol
NLnet Labs
April 2004
Unmanaged Networks IPv6 Transition Scenarios
非管理ネットワークＩＰｖ６移行シナリオ
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). All Rights Reserved.
Abstract
概要
This document defines the scenarios in which IPv6 transition
mechanisms are to be used in unmanaged networks. In order to
evaluate the suitability of these mechanisms, we need to define the
scenarios in which these mechanisms have to be used. One specific
scope is the "unmanaged network", which typically corresponds to a
home or small office network. The scenarios are specific to a single
subnet, and are defined in terms of IP connectivity supported by the
gateway and the Internet Service Provider (ISP). We first examine
the generic requirements of four classes of applications: local,
client, peer to peer and server. Then, for each scenario, we infer
transition requirements by analyzing the needs for smooth migration
of applications from IPv4 to IPv6.
この文書は非管理ネットワークでＩＰｖ６移行メカニズムが使われるシナリ
オを定義します。これらのメカニズムの適合性を評価するために、我々はこ
れらのメカニズムが使われなければならないシナリオを定義する必要があり
ます。１つの特定の範囲は「非管理ネットワーク」で、これは典型的に家や
小さいオフィスネットワークに対応します。シナリオはひとつのサブネット
に固有で、ゲートウェイとインターネット・サービスプロバイダ（ＩＳＰ）
によってサポートされるＩＰ接続性に関して定義されます。我々は最初にア
プリケーションの４つのクラスの一般的な必要条件を調べます：ローカル、
クライアント、ピア対ピア、サーバ。それから、それぞれのシナリオで、我
々はＩＰｖ４からＩＰｖ６にアプリケーションの滑らかな移行の必要性を分
析することで、移行要求条件を推論します。
Table of Contents
目次
1. Introduction
1. はじめに
2. Topology
2. トポロジー
3. Applications
3. アプリケーション
3.1. Local Applications
3.1. ローカルアプリケーション
3.2. Client Applications
3.2. クライアントアプリケーション
3.3. Peer-to-Peer Applications
3.3. ピア対ピアアプリケーション
3.4. Server Applications
3.4. サーバアプリケーション
4. Application Requirements of an IPv6 Unmanaged Network
4. ＩＰｖ６非管理ネットワークのアプリケーション必要条件
4.1. Requirements of Local Applications
4.1. ローカルアプリケーションの必要条件
4.2. Requirements of Client Applications
4.2. クライアントアプリケーションの必要条件
4.2.1. Privacy Requirement of Client Applications
4.2.1. クライアントアプリケーションのプライバシー必要条件
4.3. Requirements of Peer-to-Peer Applications
4.3. ピア対ピアのアプリケーションの必要条件
4.4. Requirements of Server Applications
4.4. サーバアプリケーションの必要条件
5. Stages of IPv6 Deployment
5. ＩＰｖ６展開の段階
5.1. Case A, Host Deployment of IPv6 Applications
5.1. 事例Ａ、ＩＰｖ６アプリケーションのホスト実装
5.1.1. Application Support in Case A
5.1.1. 事例Ａでのアプリケーションサポート
5.1.2. Addresses and Connectivity in Case A
5.1.2. 事例Ａのアドレスと接続性
5.1.3. Naming Services in Case A
5.1.3. 事例Ａの名前サービス
5.2. Case B, IPv6 Connectivity with Provider Support
5.2. 事例Ｂ、プロバイダサポートのＩＰｖ６接続性
5.2.1. Application Support in Case B
5.2.1. 事例Ｂでのアプリケーションサポート
5.2.2. Addresses and Connectivity in Case B
5.2.2. 事例Ｂのアドレスと接続性
5.2.3. Naming Services in Case B
5.2.3. 事例Ｂの名前サービス
5.3. Case C, IPv6 Connectivity without Provider Support
5.3. 事例Ｃ、プロバイダサポートがないＩＰｖ６接続性
5.3.1. Application Support in Case C
5.3.1. 事例Ｃでのアプリケーションサポート
5.3.2. Addresses and Connectivity in Case C
5.3.2. 事例Ｃのアドレスと接続性
5.3.3. Naming Services in Case C
5.3.3. 事例Ｃの名前サービス
5.4. Case D, ISP Stops Providing Native IPv4 Connectivity
5.4. 事例Ｄ、ＩＳＰがネイティブのＩＰｖ４接続性を供給をやめる
5.4.1. Application Support in Case D
5.4.1. 事例Ｄのアプリケーションサポート
5.4.2. Addresses and Connectivity in Case D
5.4.2. 事例Ｄでのアドレスと接続性
5.4.3. Naming Services in Case D
5.4.3. 事例Ｄの名前サービス
6. Security Considerations
6. セキュリティの考察
7. Acknowledgements
7. 謝辞
8. References
8. 参考文献
8.1. Normative References
8.1. 参照する参考文献
8.2. Informative References
8.2. 有益な参考文献
9. Authors' Addresses
9. 著者のアドレス
10. Full Copyright Statement
10. 著作権表示全文
1. Introduction
1. はじめに
In order to evaluate the suitability of transition mechanisms from
IPv4 [RFC791] to IPv6 [RFC2460], we need to define the environment or
scope in which these mechanisms have to be used. One specific scope
is the "unmanaged networks", which typically correspond to home
networks or small office networks.
ＩＰｖ４[RFC791]からＩＰｖ６[RFC2460]への移行メカニズムの適合性を評価
するために、我々はこれらのメカニズムが使われなければならない環境ある
いは範囲を定義する必要があります。１つの特定の範囲は「非管理ネットワー
ク」で、これは典型的に家庭ネットワークや小さいオフィスネットワークに
対応します。
This document studies the requirement posed by various transition
scenarios, and is organized in to four main sections. Section 2
defines the topology that we are considering. Section 3 presents the
four classes of applications that we consider for unmanaged networks:
local applications, client applications, peer-to-peer applications,
and server applications. Section 4 studies the requirements of these
four classes of applications. Section 5 analyses how these
requirements translate into four configurations that we expect to
encounter during IPv6 deployment: gateways which do not provide IPv6,
dual-stack gateways connected to dual-stack ISPs, dual-stack gateways
connected to IPv4-only ISPs, and IPv6-capable gateways connected to
IPv6-only ISPs. While these four configurations are certainly not an
exhaustive list of possible configurations, we believe that they
represent the common cases for unmanaged networks.
この文書は様々な移行シナリオで提出される必要条件を調べ、そして４つの
主な章に組織化します。２章で我々が考えているトポロジーを定義します。
３章で、我々が非管理ネットワークに関して考えるアプリケーションの４つ
のクラスを提示します：ローカルアプリケーション、クライアントアプリケー
ション、ピア対ピアアプリケーション、サーバアプリケーション。４章がこ
れらのアプリケーションの４つのクラスの必要条件を調査します。５章は、
これらの必要条件を、我々がＩＰｖ６展開の際に遭遇することを予期する、
４つの設定に翻訳する方法を、分析します：ＩＰｖ６を供給しないゲート
ウェイ、デュアルスタックＩＳＰに接続したデュアルスタックゲートウェイ、
ＩＰｖ４のみのＩＳＰに接続したデュアルスタックゲートウェイ、ＩＰｖ６
のみのＩＳＰに接続したＩＰｖ６対応のゲートウェイ。これらの４つの設定
は可能な設定の徹底的なリストではないが、我々はこれらが非管理ネットワー
クの一般的事例を表すと信じます。
2. Topology
2. トポロジー
The typical unmanaged network is composed of a single subnet,
connected to the Internet through a single Internet Service Provider
(ISP) connection. Several hosts may be connected to the subnet:
典型的な非管理ネットワークは、ひとつのサブネットで、ひとつのインター
ネット・サービスプロバイダ（ＩＳＰ）接続を通してインターネットに接続
しています。いくつかのホストがサブネットに接続しているかもしれません：
+------+
| Host +--+
+------+ |
|
+------+ |
| Host +--+ +--------------
+------+ | |
: +-----+
: +---------+ | |
+--+ Gateway +------| ISP | Internet
: +---------+ | |
: +-----+
+------+ | |
| Host +--+ +--------------
+------+ |
|
+------+ |
| Host +--+
+------+
Between the subnet and the ISP access link is a gateway, which may or
may not perform NAT and firewall functions. When the gateway
performs NAT functions [RFC3022], it generally allocates private IPv4
addresses to the local hosts [RFC1918]. A key point of this
configuration is that the gateway is typically not "managed". In
most cases, it is a simple "appliance" that incorporates some static
policies. There are many cases in which the gateway is procured and
configured by the ISP.
サブネットとＩＳＰ間のアクセスリンクはゲートウェイで、これはＮＡＴと
ファイアウォール機能を実行してもよいです。ゲートウェイがＮＡＴ機能
[RFC3022]を実行する時、これは一般にローカルホストにプライベートのＩＰ
ｖ４アドレス[RFC1918]を割り当てます。この設定の要点はゲートウェイが一
般に「管理されない」ということです。たいていの場合、ある静的なポリシ
を含む単純な「器具」です。ＩＳＰがゲートウェイを斡旋し構成を設定する
多くの場合があります。
Note that there are also some cases in which we find two gateways
back to back, one managed by the ISP and the other added by the owner
of the unmanaged network. They are not covered in this memo because
most of them either require some management, or the gateway added by
the user can function as an L2 switch.
２つのゲートウェイ、一方はＩＳＰによって管理され、一方は非管理ネット
ワークの所有者が追加した、が後ろで繋がっている場合もしばしばあること
に注意してください。この場合なんらかの管理が必要なことが多いか、ユー
ザの追加した機能がＬ２スイッチである場合がほとんどなので、この文書で
はこれに対応していません。
The access link between the unmanaged network and the ISP might be
either a static, permanent connection or a dynamic connection such as
a dial-up or ISDN line.
非管理ネットワークとＩＳＰ間のアクセスリンクは静的か、永久接続か、ダ
イアルアップやＩＳＤＮ回線のような動的接続かもしれません。
In a degenerate case, an unmanaged network might consist of a single
host, directly connected to an ISP.
極端な場合、非管理ネットワークが、直接ＩＳＰに接続した一つのホストか
ら成り立つかもしれません。
There are some cases in which the "gateway" is replaced by a layer-2
bridge. In such deployments, the hosts have direct access to the ISP
service. In order to avoid lengthy developments, we will treat these
cases as if the gateway was not present, i.e., as if each host was
connected directly to the ISP.
「ゲートウェイ」が２層ブリッジで置き換えられるいくつかの場合がありま
す。このような配置で、ホストはＩＳＰサービスに直接アクセスを持ちます。
長い開発期間を避けるために、我々はこれをゲートウェイが存在していない、
すなわち、それぞれのホストが直接ＩＳＰに接続しているかのように、これ
らの事例を扱うでしょう。
Our definition of unmanaged networks explicitly exclude networks
composed of multiple subnets. We will readily admit that some home
networks and some small business networks contain multiple subnets,
but in the current state of the technology, these multiple subnet
networks are not "unmanaged": some competent administrator has to
explicitly configure the routers. We will thus concentrate on single
subnet networks, where no such competent operator is expected.
我々の非管理ネットワークの定義は、明示的に、多数のサブネットで構成さ
れたネットワークを除外します。我々はあるホームネットワークとある中小
企業ネットワークが多数のサブネットを含んでいることを認めますが、現在
の技術の水準で、これらの多数のサブネットネットワークは「非管理」では
ありません：有能な管理者が明示的にルータの構成を設定します。我々はそ
れでひとつのサブネットネットワークだけを考え、そしてここでは有能なオ
ペレータを期待しません。
3. Applications
3. アプリケーション
Users may use or wish to use the unmanaged network services in four
types of applications: local, client, servers and peer-to-peers.
These applications may or may not run easily on today's networks
(some do, some don't).
ユーザが４種類のアプリケーションで非管理ネットワークを使うか使いたい
と望むかもしれません：ローカル、クライアント、サーバ、ピア対ピア。こ
れらのアプリケーションは今日のネットワーク上で容易に動作するかもしれ
ません（いくつかはそうで、いくつかはそうでありません）。
3.1. Local Applications
3.1. ローカルアプリケーション
"Local applications" are only meant to involve the hosts that are
part of the unmanaged network. Typical examples would be file
sharing or printer sharing.
「ローカルアプリケーション」はホストと非管理ネットワークの一部が関係
します。典型的な例はファイル共有やプリンタ共有です。
Local applications work effectively in IPv4 unmanaged networks, even
when the gateway performs NAT or firewall functions. In fact,
firewall services at the gateway are often deemed desirable, as they
isolate the local applications from interference by Internet users.
ゲートウェイがＮＡＴやファイアウォール機能を行っても、ローカルアプリ
ケーションが効率的にＩＰｖ４非管理ネットワークで働きます。実際、ゲー
トウェイにおいてのファイアウォールサービスは、インターネットユーザの
干渉からローカルアプリケーションを隔離するので、しばしば望ましいとみ
なされます。
3.2. Client Applications
3.2. クライアントアプリケーション
"Client applications" are those that involve a client on the
unmanaged network and a server at a remote location. Typical
examples would be accessing a web server from a client inside the
unmanaged network, or reading and sending e-mail with the help of a
server outside the unmanaged network.
「クライアントアプリケーション」は非管理ネットワークのクライアントと、
遠隔地のサーバが関係します。典型的な例は非管理ネットワーク内のクライ
アントからのウェブサーバアクセスや、非管理ネットワーク外のサーバの助
けを借りた電子メールの送受信です。
Client applications tend to work correctly in IPv4 unmanaged
networks, even when the gateway performs NAT or firewall functions:
these translation and firewall functions are designed precisely to
enable client applications.
ゲートウェイがＮＡＴやファイアウォールを動作させても、クライアントア
プリケーションはＩＰｖ４非管理ネットワークで正確に動作する傾向があり
ます：これらの翻訳とファイアウォール機能が正確にクライアントアプリケー
ションを利用可能にするよう意図されます。
3.3. Peer-to-Peer Applications
3.3. ピア対ピアアプリケーション
There are really two kinds of "peer-to-peer" applications: ones which
only involve hosts on the unmanaged network, and ones which involve
both one or more hosts on the unmanaged network and one or more hosts
outside the unmanaged network. We will only consider the latter kind
of peer-to-peer applications, since the former can be considered a
subset of the kind of local applications discussed in section 3.1.
「ピア対ピア」アプリケーションに２つの種類があります：１つは非管理ネッ
トワーク上のホストだけが関係し、もう１つは非管理ネットワーク上のホス
トと非管理ネットワーク外のホストが関係します。前者が３.１章で論じられ
たローカルアプリケーションの一種とと思われるので、我々はピア対ピアア
プリケーションの後の種類だけを考えます。
Peer-to-peer applications often don't work well in unmanaged IPv4
networks. Application developers often have to enlist the help of a
"relay server", in effect restructuring the peer-to-peer connection
into a pair of back-to-back client/server connections.
ピア対ピアアプリケーションがしばしば非管理ＩＰｖ４ネットワークで上手
に働きません。アプリケーション開発者がしばしば、２つのクライアント／
サーバ接続内に、ピア対ピア接続を構成する、「リレーサーバ」の助けを求
めます。
3.4. Server Applications
3.4. サーバアプリケーション
"Server applications" involve running a server in the unmanaged
network for use by other parties outside the network. Typical
examples would be running a web server or an e-mail server on one of
the hosts inside the unmanaged network.
「サーバアプリケーション」はネットワーク外の者が使う非管理ネットワー
クのサーバが関係します。典型的な例は非管理ネットワーク内のホスト上で
動作するウェブサーバや電子メールサーバです。
Deploying these servers in most unmanaged IPv4 networks requires some
special programming of the NAT or firewall [RFC2993], and is more
complex when the NAT only publishes a small number of global IP
addresses and relies on "port translation". In the common case in
which the NAT manages exactly one global IP address and relies on
"port translation", a given external port can only be used by one
internal server.
たいていの非管理ＩＰｖ４ネットワークでこれらのサーバを配置するには、
ＮＡＴやファイアウォールの特別なプログラミングを必要とし[RFC2993]、そ
してＮＡＴが小数のグローバルＩＰアドレスだけを使用して「ポート翻訳」
に依存する時は、より複雑です。ＮＡＴが正確に１つのグローバルアドレス
を管理し、「ポート翻訳」に依存する、一般的な場合、特定の外部のポート
がただ１つの内部のサーバにだけ使えるだけです。
Deploying servers usually requires providing each server with a
stable DNS name, and associating a global IPv4 address with that
name, whether the address be that of the server itself or that of the
router acting as a firewall or NAT. Since updating DNS is a
management task, it falls somewhat outside the scope of an unmanaged
network. On the other hand, it is also possible to use out-of-band
techniques (such as cut-and-paste into an instant message system) to
pass around the address of the target server.
通常サーバを運用するには、アドレスがサーバ自身のものか、ファイアウォー
ルやＮＡＴの役を務めるルータのであるか否かにかかわらず、それぞれのサー
バに安定したＤＮＳ名を提供とし、グローバルなＩＰｖ４アドレスをその名
前と結び付けることを必要とします。ＤＮＳを更新することは管理者の仕事
であるので、これは非管理ネットワークの範囲外でいくらか問題あります。
他方、目標サーバのアドレスを渡すためにアウトバンドの方法を使うことが
可能です（インスタントメッセージシステムのカット＆ペーストなど）。
4. Application Requirements of an IPv6 Unmanaged Network
4. ＩＰｖ６非管理ネットワークのアプリケーション必要条件
As we transition to IPv6, we must meet the requirements of the
various applications, which we can summarize in the following way:
applications that worked well with IPv4 should continue working well
during the transition; it should be possible to use IPv6 to deploy
new applications that are currently hard to deploy in IPv4 networks;
and the deployment of these IPv6 applications should be simple and
easy to manage, but the solutions should also be robust and secure.
ＩＰｖ６に移行する時、次の様に要約できる種々なアプリケーションの必要
条件に出会います：ＩＰｖ４で上手く働いたアプリケーションは移行の間も
上手に働き続けるべきです；現在ＩＰｖ４ネットワークで実装することが難
しい新しいアプリケーションを実装するためにＩＰｖ６を使うことは可能で
あるべきです；そしてこれらのＩＰｖ６アプリケーションの配置は簡単で、
管理が容易であるべきですが、解決策は強固で安全であるべきです。
The application requirements for IPv6 Unmanaged Networks fall into
three general categories: connectivity, naming, and security.
Connectivity issues include the provision of IPv6 addresses and their
quality: do hosts need global addresses, should these addresses be
stable or, more precisely, what should the expected lifetimes of
these addresses be? Naming issues include the management of names
for the hosts: do hosts need DNS names, and is inverse name
resolution [DNSINADDR] a requirement? Security issues include
possible restriction to connectivity, privacy concerns and, generally
speaking, the security of the applications.
ＩＰｖ６非管理ネットワークのアプリケーション必要条件は３つの一般的な
カテゴリーに分類されます：接続性、命名、セキュリティ。接続性問題はＩ
Ｐｖ６アドレスの準備と品質を含みます：グローバルなアドレスを必要とす
るホストはアドレスが安定しているべきか、あるいは、より正確に、これら
のアドレスの期待された寿命がどれだけか？命名問題はホストの名前の管理
を含みます：ホストがＤＮＳ名を必要とするか、そして名前逆引き
[DNSINADDR]は必要条件か？セキュリティ問題は接続の制限の可能性、プラ
イバシの懸念、一般的対話、アプリケーションのセキュリティ対話を含みま
す。
4.1. Requirements of Local Applications
4.1. ローカルアプリケーションの必要条件
Local applications require local connectivity. They must continue to
work even if the unmanaged network is isolated from the Internet.
ローカルアプリケーションがローカルな接続性を必要とします。これらは、
たとえ非管理ネットワークがインターネットから隔離されていても、働き続
けなくてはなりません。
Local applications typically use ad hoc naming systems. Many of
these systems are proprietary; an example of a standard system is the
service location protocol (SLP) [RFC2608].
ローカルアプリケーションが一般に一時的な命名システムを使います。これ
らのシステムの多くが独占です；標準システムの例はサービス場所プロトコ
ル（ＳＬＰ）[RFC2608]です。
The security of local applications will usually be enhanced if these
applications can be effectively isolated from the global Internet.
ローカルアプリケーションのセキュリティは、通常、もしこれらのアプリケー
ションが効率的にグローバルインターネットから隔離され得るなら、拡張さ
れるでしょう。
4.2. Requirements of Client Applications
4.2. クライアントアプリケーションの必要条件
Client applications require global connectivity. In an IPv6 network,
we would expect the client to use a global IPv6 address, which will
have to remain stable for the duration of the client-server session.
クライアントアプリケーションがグローバルな接続性を必要とします。ＩＰ
ｖ６ネットワークで、我々はクライアントがグローバルなＩＰｖ６アドレス
を使うことを期待しますが、これはクライアントサーバセッションで常に安
定していなければならないでしょう。
Client applications typically use the domain name system to locate
servers. In an IPv6 network, the client must be able to locate a DNS
resolver.
クライアントアプリケーションが一般にサーバの場所を突き止めるドメイン
名システムを使います。ＩＰｖ６ネットワークで、クライアントはＤＮＳリ
ゾルバの場所を突き止めることができなければなりません。
Many servers try to look up a DNS name associated with the IP address
of the client. In an IPv4 network, this IP address will often be
allocated by the Internet service provider to the gateway, and the
corresponding PTR record will be maintained by the ISP. In many
cases, these PTR records are perfunctory, derived in an algorithmic
fashion from the IPv4 address; the main information that they contain
is the domain name of the ISP. Whether or not an equivalent function
should be provided in an IPv6 network is unclear.
多くのサーバがクライアントのＩＰアドレスと結び付いたＤＮＳ名を検索し
ようとします。ＩＰｖ４ネットワークで、このＩＰアドレスは、しばしば、
インターネット・サービスプロバイダによってゲートウェイに割り当てられ
るでしょう、そして対応するＰＴＲレコードはＩＳＰが保守するでしょう。
多くの場合、これらのＰＴＲレコードはいいかげんで、ＩＰｖ４アドレスか
ら規則的に得られています；それらが含んでいる主な情報はＩＳＰのドメイ
ン名です。等価な機能が供給されるべきかどうかはＩＰｖ６ネットワークで
不明確です。
4.2.1. Privacy Requirement of Client Applications
4.2.1. クライアントアプリケーションのプライバシー必要条件
It is debatable whether the IPv6 networking service should be
engineered to enhance the privacy of the clients, and specifically
whether support for RFC 3041 [RFC3041] should be required. RFC 3041
enables hosts to pick IPv6 addresses in which the host identifier is
randomized; this was designed to make sure that the IPv6 addresses
and the host identifier cannot be used to track the Internet
connections of a device's owner.
ＩＰｖ６ネットワーキングサービスがクライアントのプライバシーを拡張す
るべきかどうか、特にＲＦＣ３０４１[RFC3041]に対するサポートが必要と
されるべきかは議論中です。ＲＦＣ３０４１はホストがホスト識別子をラン
ダムなＩＰｖ６アドレスから選ぶことができるようにします；これは装置の
所有者のインターネット接続を追跡するためにＩＰｖ６アドレスとホスト識
別子が使えないことを確実にするよう意図されました。
Many observe that randomizing the host identifier portion of the
address is only a half measure. If the unmanaged network address
prefix remains constant, the randomization only hides which host in
the unmanaged network originates a given connection, e.g., the
children's computer versus their parents'. This would place the
privacy rating of such connections on a par with that of IPv4
connections originating from an unmanaged network in which a NAT
manages a static IPv4 address; in both cases, the IPv4 address or the
IPv6 prefix can be used to identify the unmanaged network, e.g., the
specific home from which the connection originated.
多く人がアドレスのホスト識別子部をランダム化するのは不十分な策に過ぎ
ないと述べます。もし非管理ネットワークアドレスプレフィックスが変わら
なければ、ランダム化は非管理ネットワークでどのホストが接続をしたか、
例えば、子供と親のコンピュータ、を隠すだけです。これはＮＡＴが静的Ｉ
Ｐｖ４アドレスを管理してる時の、非管理ネットワークからのＩＰｖ４接続
での、このような接続のプライバシー評価を思い出すでしょう；両方の場合
に、ＩＰｖ４アドレスあるいはＩＰｖ６プレフィックスが非管理ネットワー
クの識別に使えます、つまり特定の家から接続があったとわかります。
However, randomization of the host identifier does provide benefits.
First, if some of the hosts in the unmanaged network are mobile, the
randomization destroys any correlation between the addresses used at
various locations: the addresses alone could not be used to determine
whether a given connection originates from the same laptop moving
from work to home, or used on the road. Second, the randomization
removes any information that could be extracted from a hardwired host
identifier; for example, it will prevent outsiders from correlating a
serial number with a specific brand of expensive electronic
equipment, and to use this information for planning marketing
campaigns or possibly burglary attempts.
しかしながら、ホスト識別子のランダム化は利点があります。最初に、もし
非管理ネットワークでのホストの一部がモバイルであるなら、ランダム化は
種々な場所で使われたアドレスの間の相互関係を破壊します：アドレスだけ
で、特定の接続が同じラップトップに関するものか決定することができませ
ん。第二に、ランダム化は物理的に設定されたホスト識別子の情報を排除し
ます；例えば、これは部外者が特定の高価なブランドのシリアル番号の相関
を取り、この情報をマーケティングキャンペーンや窃盗計画に使うのを阻止
するでしょう。
Randomization of the addresses is not sufficient to guarantee
privacy. Usage can be tracked by a variety of other means, from
application level "cookies" to complex techniques involving data
mining and traffic analysis. However, we should not make a bad
situation worse. Other attacks to privacy may be possible, but this
is not a reason to enable additional tracking through IPv6 addresses.
アドレスのランダム化はプライバシーを保証することに十分ではありません。
利用状況は、アプリケーションレベル「クッキー」からデータマイニングと
トラフィック分析を伴う複雑な技術まで、テクニックまで、いろいろな他の
手段によって追跡できます。しかしながら、我々は良くない状態をもっと悪
くするべきではありません。プライバシーへの他の攻撃が可能であるかもし
れませんが、これはＩＰｖ６アドレスを利用した追跡の可能性を追加する理
由ではありません。
Randomization of the host identifier has some costs: the address
management in hosts is more complex for the hosts, reverse DNS
services are harder to provide, and the gateway may have to maintain
a larger cache of neighbor addresses; however, experience from
existing implementation shows that these costs are not overwhelming.
Given the limited benefits, it would be unreasonable to require that
all hosts use privacy addresses; however, given the limited costs, it
is reasonable to require that all unmanaged networks allow use of
privacy addresses by those hosts that choose to do so.
ホスト識別子のランダム化はコストを増やします：ホストでのアドレス管理
はホストでより複雑で、ＤＮＳ逆引きの供給はより難しく、ゲートウェイは
近隣アドレスのより大きいキャッシュを維持しなければならないかもしれま
せん；しかしながら、既存の実装の経験はこれらのコストは重大でないこと
を示します。限定された利点という条件で、すべてのホストがプライバシー
アドレスを使うことを要求することは不当であるでしょう；しかしながら、
限定されたコストという条件で、すべての非管理ネットワークはホストが使
いたいならホストがプライバシーアドレスの使用を許すように要求すること
が合理的です。
4.3. Requirements of Peer-to-Peer Applications
4.3. ピア対ピアのアプリケーションの必要条件
Peer-to-peer applications require global connectivity. In an IPv6
network, we would expect the peers to use a global IPv6 address,
which will have to remain stable for the duration of the peer-to-peer
session.
ピア対ピアのアプリケーションがグローバルな接続性を必要とします。ＩＰ
ｖ６ネットワークで、我々はピアがグローバルＩＰｖ６アドレスを使うこと
を期待し、そしてアドレスはピア対ピアのセッションの間に安定していなけ
ればならないでしょう。
There are multiple aspects to the security of peer-to-peer
applications, many of which relate to the security of the rendezvous
system. If we assume that the peers have been able to safely
exchange their IPv6 addresses, the main security requirement is the
capability to safely exchange data between the peers without
interference by third parties.
ピア対ピアアプリケーションのセキュリティに多数の局面があり、そしてそ
の多くは集合システムのセキュリティに関連しています。もし相手と安全に
ＩＰｖ６アドレスを交換することが可能であると想定するなら、主なセキュ
リティ必要条件は第三者の干渉なしで当事者間で安全にデータを交換する能
力です。
Private conversations by one of the authors with developers of peer-
to-peer applications suggest that many individuals would be willing
to consider an "IPv6-only" model if they can get two guarantees:
ピア対ピアアプリケーションの開発者と著者の１人による私的会話は、もし
２つの保証を得ることができるなら、多くの個人が「ＩＰｖ６のみ」モデル
を考えているのを示唆しました：
1) That there is no regression from IPv4, i.e., that all customers
who could participate in a peer-to-peer application using IPv4 can
also be reached by IPv6.
1) ＩＰｖ４からの後退はありません、すなわち、ＩＰｖ４でピア対ピアア
プリケーションに関係する顧客が、ＩＰｖ６でもつうしんできます。
2) That IPv6 provides a solution for at least some of their hard
problems, e.g., enabling peers located behind an IPv4 NAT to
participate in a peer-to-peer application.
2) そのＩＰｖ６は少なくとも難しい問題のいくつかに解決を提供します、
例えば、ＩＰｖ４のＮＡＴの背後のピアが、ピア対ピアアプリケーショ
ンへ参加できます。
Requiring IPv6 connectivity for a popular peer-to-peer application
could create what economists refer to as a "network effect", which in
turn could significantly speed up the deployment of IPv6.
主要なピア対ピアアプリケーションでＩＰｖ６接続性を要求とすることは、
経済学者の言う「ネットワーク効果」を生成し、これはＰｖ６の展開を速
めることができます。
4.4. Requirements of Server Applications
4.4. サーバアプリケーションの必要条件
Server applications require global connectivity, which in an IPv6
network implies global addresses. In an IPv4 network utilizing a
NAT, for each service provided by a server, the NAT has to be
configured to forward packets sent to that service to the server that
offers the service.
サーバアプリケーションがグローバルな接続性を必要とし、これはＩＰｖ６
ネットワークでグローバルアドレスを暗示します。ＮＡＴを利用しているＩ
Ｐｖ４ネットワークで、それぞれのサーバで供給されたサービスのために、
ＮＡＴはそのサービスに送られたパケットをサービスを供給するサーバに転
送するように設定されなければなりません。
Server applications normally rely on the publication of the server's
address in the DNS. This, in turn, requires that the server be
provisioned with a "global DNS name".
サーバアプリケーションが通常ＤＮＳでのサーバのアドレスの公開に依存し
ます。これは、言い換えると、サーバが「グローバルＤＮＳ名」で供給され
ることを要求します。
The DNS entries for the server will have to be updated, preferably in
real time, if the server's address changes. In practice, updating
the DNS can be slow, which implies that server applications will have
a better chance of being deployed if the IPv6 addresses remain
stable.
サーバのＤＮＳ項目は、もしサーバアドレスが変化するなら、なるべくリア
ルタイムで更新されなければならないでしょう。実際は、ＤＮＳ更新は遅く
あり得て、これはもしＩＰｖ６アドレスが安定していれば、サーバアプリケー
ションの配置のより良いチャンスをがあることを意味します。
The security of server applications depends mostly on the correctness
of the server, and also on the absence of collateral effects: many
incidents occur when the opening of a server on the Internet
inadvertently enables remote access to some other services on the
same host.
サーバアプリケーションのセキュリティは、たいていサーバの正当性と、追
加の副次効果の欠如に依存します：多くの事件は、インターネット上のサー
バが愚かにも同じホストの他のサービスの遠隔アクセスを可能にする時に、
起こります。
5. Stages of IPv6 Deployment
5. ＩＰｖ６展開の段階
We expect the deployment of IPv6 to proceed from an initial state in
which there is little or no deployment, to a final stage in which we
might retire the IPv4 infrastructure. We expect this process to
stretch over many years; we also expect it to not be synchronized, as
different parties involved will deploy IPv6 at different paces.
我々はＩＰｖ６の展開が、わずかしかあるいは全然配置がない最初の状態か
ら、ＩＰｖ４インフラを引退させるかもしれない最終の段階に進むことを期
待します。我々は何年もにわたるこの手順を予想します；我々は、関係者が
異なるペースでＩＰｖ６を配置するし、これが同期しないと予想します。
In order to get some clarity, we distinguish three entities involved
in the transition of an unmanaged network: the ISP (possibly
including ISP consumer premise equipment (CPE)), the home gateway,
and the hosts (computers and appliances). Each can support IPv4-
only, both IPv4 and IPv6, or IPv6-only. That gives us 27
possibilities. We describe the most important cases. We will assume
that in all cases the hosts are a combination of IPv4-only, dual
stack, and (perhaps) IPv6-only hosts.
ある明快さを得るために、我々は非管理ネットワークの移行に関係していて
３つの参加者を識別します：ＩＳＰ（多分、ＩＳＰ顧客構内装置を含む）、
ホームゲートウェイ、ホスト（コンピュータと器具）。それぞれがＩＰｖ４
のみ、ＩＰｖ４とＩＰｖ６両方、ＩＰｖ６のみがありえます。それは我々に
２７の可能性があります。我々は最も重要な場合を記述します。我々は例外
なく全ての場合に、ホストがＩＰｖ４のみとデュアルスタックとＩＰｖ６の
みの組合せであると想定するでしょう。
The cases we will consider are:
我々が考える事例は以下です：
A) a gateway that 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) ＩＰｖ６のみのＩＳＰに接続したゲートウェイ
In most of these cases, we will assume that the gateway includes a
NAT: we realize that this is not always the case, but we submit that
it is common enough that we have to deal with it; furthermore, we
believe that the non-NAT variants of these cases map fairly closely
to this same set of cases. In fact, we can consider three non-NAT
variants: directly connected host; gateway acting as a bridge; and
gateway acting as a non-NAT IP router.
これらの場合の大部分で、我々はゲートウェイにＮＡＴを含むと想定するで
しょう：我々はこれが全てではないと知っていますが、これを我々が扱えば
十分と言います；さらに、これらの非ＮＡＴの場合は、この場合にほとんど
対応すると信じます。実際、我々は３つの非ＮＡＴの種類を考えれます：直
接接続ホスト；ブリッジの役を務めているゲートウェイ；非ナットＩＰルー
タの役を務めているゲートウェイ。
The cases of directly connected hosts are, in effect, variants of
cases B, C, and D, in which the host can use all solutions available
to gateways: case B if the ISP is dual stack, case C if the ISP only
provides IPv4 connectivity, and case D if the ISP only provides IPv6
connectivity.
直接接続されたホストの場合は、実質的に、ＢとＣとＤの、ホストがすべて
のゲートウェイで利用可能な解決策の全てを使うことができる、変形です：
もしＩＳＰがデュアルスタックであるなら事例Ｂで、もしＩＳＰがただＩＰ
ｖ４接続性を供給するだけなら事例Ｃで、ＩＳＰがただＩＰｖ６接続性を供
給するだけなら事例Ｄです。
In the cases where the gateway is a bridge, the hosts are, in effect,
directly connected to the ISP, and for all practical matter, behave
as directly connected hosts.
ゲートウェイがブリッジの場合、実質的にホストじゃ直接ＩＳＰに接続され
る場合で、そしてすべての実際の問題で、直接接続ホストとして振る舞いま
す。
The case where the gateway is an IP router but not a NAT will be
treated as small variants in the analysis of case A, B, C, and D.
ゲートウェイがＩＰルータでＮＡＴでない場合、事例Ａ、Ｂ、Ｃ、Ｄの解析
で小さい変形として取り扱わるでしょう。
5.1. Case A, Host Deployment of IPv6 Applications
5.1. 事例Ａ、ＩＰｖ６アプリケーションのホスト実装
In this case, the gateway doesn't provide IPv6; the ISP may or may
not provide IPv6, but this is not relevant since the non-upgraded
gateway would prevent the hosts from using the ISP service. Some
hosts will try to get IPv6 connectivity in order to run applications
that require IPv6, or work better with IPv6. The hosts, in this
case, will have to handle the IPv6 transition mechanisms on their
own.
この場合、ゲートウェイはＩＰｖ６を供給しません；ＩＳＰはＩＰｖ６を供
給するかもしれませんが、更新されていないゲートウェイがホストがＩＳＰ
サービスを使うのを妨害するであろうから、関係ありません。あるホストが
ＩＰｖ６を必要とするかＩＰｖ６でより適切に動作するアプリケーションを
走らせるかもしれません。ホストは、この場合、自身でＩＰｖ６移行メカニ
ズムを処理しなければならないでしょう。
There are two variations of this case, depending on the type of
service implemented by the gateway. In many cases, the gateway is a
direct obstacle to the deployment of IPv6, but a gateway which is
some form of bridge-mode CPE or which is a plain (neither filtering
nor NAT) router does not really fall into this category.
ゲートウェイに実装されたサービスのタイプに依存して事例に２つの種類が
あります。多くの場合、ゲートウェイはＩＰｖ６の配置の直接の障害ですが、
あるブリッジモードＣＰＥ形式や、純粋なルータ（フィルタもＮＡＴもない）
は、この範囲に分類されません。
5.1.1. Application Support in Case A
5.1.1. 事例Ａでのアプリケーションサポート
The focus of Case A is to enable communication between a host on the
unmanaged network and some IPv6-only hosts outside of the network.
事例Ａの焦点は、非管理ネットワークのホストと、ネットワーク外のあるＩ
Ｐｖ６のみのホストの間の通信を可能にすることです。
The primary focus in the immediate future, i.e., for the early
adopters of IPv6, will be peer-to-peer applications. However, as
IPv6 deployment progresses, we will likely find a situation where
some networks have IPv6-only services deployed, at which point we
would like case A client applications to be able to access those
services.
近未来、つまり初期のＩＰｖ６の採用者、の主要な焦点はピア対ピアアプリ
ケーションです。しかしながら、ＩＰｖ６展開が進行するにつれて、我々は
多分あるネットワークでＩＰｖ６のみのサービスが配置される状態を見いだ
すでしょう、そしてその時点で我々は事例Ａクライアントアプリケーション
がそれらのサービスにアクセスすることが可能であることを好むでしょう。
Local applications are not a primary focus of Case A. At this stage,
we expect all clients in the unmanaged network to have either IPv4
only or dual stack support. Local applications can continue working
using IPv4.
ローカルアプリケーションは事例Ａの主要な焦点ではありません。この段階
で、我々はすべての非管理ネットワークのクライアントがＩＰｖ４のみかデュ
アルスタックを持つことを期待します。ローカルアプリケーションがＩＰｖ
４を使って動き続けることができます。
Server applications are also not a primary focus of Case A. Server
applications require DNS support, which is difficult to engineer for
clients located behind a NAT, which is likely to be present in this
case. Besides, server applications presently cater mostly to IPv4
clients; putting up an IPv6-only server is not very attractive.
サーバアプリケーションは同じく事例Ａの主要な焦点ではありません。サー
バアプリケーションはＤＮＳサポートが必要で、これはＮＡＴの背後にある
クライアントが利用するのは難しく、この場合ＮＡＴが存在している可能性
が高いです。その上、サーバアプリケーションが現在たいていＩＰｖ４クラ
イアントに提供されています；ＩＰｖ６のみのサーバを建てることは非常に
魅力的ではありません。
In contrast, peer-to-peer applications are probably both attractive
and easy to deploy: they are deployed in a coordinated fashion as
part of a peer-to-peer network, which means that hosts can all
receive some form of an IPv6 upgrade; they often provide their own
naming infrastructure, in which case they are not dependent on DNS
services.
それと対照的に、ピア対ピアのアプリケーションは恐らく魅力的で実装が容
易です：これらはピア対ピアネットワークの一部として協調形式で配置され
ます、つまりホストがすべてあるＩＰｖ６更新形式を受けることができるこ
とを意味します；これらはしばしば自身の命名インフラを供給し、そしてこ
の場合ＤＮＳサービスに依存していません。
5.1.2. Addresses and Connectivity in Case A
5.1.2. 事例Ａのアドレスと接続性
We saw in 5.1.1 that the likely motivation for deployment of IPv6
connectivity in hosts in case A is a desire to use peer-to-peer and
client IPv6 applications. These applications require that all
participating nodes get some form of IPv6 connectivity, i.e., at
least one globally reachable IPv6 address.
我々は５.１.１で事例ＡでホストがＩＰｖ６接続性を求める有望な動機とし
て、「ピア対ピア」とクライアントＩＰｖ６アプリケーションを使うのを望
む場合とみました。これらのアプリケーションはすべての参加しているノー
ドがなんらかのＩＰｖ６接続性、すなわち、少なくとも１つのグローバルに
到達可能なＩＰｖ６アドレスを得ることを要求します。
If the local gateway provides global IPv4 addresses to the local
hosts, then these hosts can individually exercise the mechanisms
described in case C, "IPv6 connectivity without provider support."
If the local gateway implements a NAT function, another type of
mechanism is needed. The mechanism to provide connectivity to peers
behind NAT should be easy to deploy, and light weight; it will have
to involve tunneling over a protocol that can easily traverse NAT,
either TCP or preferably UDP, as tunneling over TCP can result in
poor performance in cases of time-outs and retransmissions. If
servers are needed, these servers will, in practice, have to be
deployed as part of the "support infrastructure" for the peer-to-peer
network or for an IPv6-based service; economic reality implies that
the cost of running these servers should be as low as possible.
もしローカルゲートウェイがローカルホストにグローバルなＩＰｖ４アドレ
スを供給するなら、これらのホストは個々に事例Ｃで記述された、「プロバ
イダサポートがないＩＰｖ６接続性」メカニズムを実行できます。もしロー
カルゲートウェイがＮＡＴ機能を実装するなら、他のタイプのメカニズムが
必要とされます。ＮＡＴの背後のピアに接続性を供給するメカニズムは、設
置が容易で軽いべきです；これはＴＣＰかＵＤＰなどのＮＡＴの通過が容易
なプロトコルを伴います、ＴＣＰ上のトンネルはタイムアウトや再送や低い
性能をもたらすので。もしサーバが必要なら、これらのサーバは、実際は、
ピア対ピアネットワークあるいはＩＰｖ６ベースサービスの「インフラ」の
一部として実装されなければならないでしょう；経済の現実はこれらのサー
バを走らせることのコストが可能な限り低くあるべきであることを意味しま
す。
5.1.3. Naming Services in Case A
5.1.3. 事例Ａの名前サービス
At this phase of IPv6 deployment, hosts in the unmanaged domain have
access to DNS services over IPv4 through the existing gateway. DNS
resolvers are supposed to serve AAAA records, even if they only
implement IPv4; the local hosts should thus be able to obtain the
IPv6 addresses of IPv6-only servers.
このＩＰｖ６展開段階で、非管理ドメインのホストが既存のゲートウェイを
通してＩＰｖ４上のＤＮＳサービスにアクセスを持ちます。ＤＮＳリゾルバ
は、たとえＩＰｖ４を実行することだけでも、ＡＡＡＡレコードをサポート
することになっています；ローカルホストはそれでＩＰｖ６のみのサーバの
ＩＰｖ６アドレスを得ることが可能であるべきです。
Reverse lookup is difficult to provide for hosts on the unmanaged
network if the gateway is not upgraded. This is a potential issue
for client applications. Some servers require a reverse lookup as
part of accepting a client's connection, and may require that the
direct lookup of the corresponding name matches the IPv6 address of
the client. There is thus a requirement to provide either a reverse
lookup solution, or to make sure that IPv6 servers do not require
reverse lookup.
もしゲートウェイが更新されないなら、非管理ネットワーク上のホストの逆
検索は提供することが難しいです。これはクライアントアプリケーションの
潜在的問題です。あるサーバがクライアント接続を受け入れるために逆検索
を必要とし、そして対応する名前の直接の検索がクライアントのＩＰｖ６ア
ドレスに一致することを要求してもよいです。それで逆検索解決策を用意す
るか、ＩＰｖ６サーバが逆検索を必要としないことを確実にするかが、必要
条件です。
5.2. Case B, IPv6 Connectivity with Provider Support
5.2. 事例Ｂ、プロバイダサポートのＩＰｖ６接続性
In this case, the ISP and gateway are both dual stack. The gateway
can use native IPv6 connectivity to the ISP and can use an IPv6
prefix allocated by the ISP.
この場合、ＩＳＰとゲートウェイは共にデュアルスタックです。ゲートウェ
イはＩＳＰとネイティブのＩＰｖ６接続性を使うことができ、そしてＩＳＰ
によって割り当てられたＩＰｖ６プレフィックスを使うことができます。
5.2.1. Application Support in Case B
5.2.1. 事例Ｂでのアプリケーションサポート
If the ISP and the gateway are dual-stack, client applications,
peer-to-peer applications, and server applications can all be enabled
easily on the unmanaged network.
もしＩＳＰとゲートウェイがデュアルスタックであるなら、クライアントア
プリケーションとピア対ピアアプリケーションとサーバーアプリケーション
がすべて非管理ネットワーク上で容易に使用可能であり得ます。
We expect the unmanaged network to include three kinds of hosts:
IPv4 only, IPv6-only, and dual stack. Obviously, dual stack hosts
can interact easily with either IPv4 only hosts or IPv6-only hosts,
but an IPv4 only host and an IPv6-only host cannot communicate
without a third party performing some kind of translation service.
Our analysis concludes that unmanaged networks should not have to
provide such translation services.
我々は非管理ネットワークが３種類のホストを含むことを予想します：ＩＰ
ｖ４のみとＩＰｖ６のみとデュアルスタック。明らかに、デュアルスタック
ホストが容易にＩＰｖ４のみのホストやＩＰｖ６のみのホストと通信可能で
すが、ＩＰｖ４のみのホストとＩＰｖ６のみのホストは何らかの変換を行う
第３者の存在なしに通信できません。我々の分析は非管理ネットワークがこ
のような翻訳サービスを供給するべきでないと結論します。
The argument for providing translation services is that their
availability would accelerate the deployment of IPv6-only devices,
and thus the transition to IPv6. This is, however, a dubious
argument since it can also be argued that the availability of these
translation services will reduce the pressure to provide IPv6 at all,
and to just continue fielding IPv4-only devices. The remaining
pressure to provide IPv6 connectivity would just be the difference in
"quality of service" between a translated exchange and a native
interconnect.
翻訳サービスを供給するための議論は、それらの有効性がＩＰｖ６のみの装
置をの展開、すなわちＩＰｖ６移行を速めるでしょう。これは、これらの翻
訳サービスの有効性がＩＰｖ６を供給する圧力を減らし、ＩＰｖ４のみの装
置を残し続けるので、疑わしい議論です。ＩＰｖ６接続性を供給する残りの
圧力は、翻訳交換と直接接続の「サービス品質」の差であるでしょう。
The argument against translation service is the difficulty of
providing these services for all applications, compared to the
relative ease of installing dual stack solutions in an unmanaged
network. Translation services can be provided either by application
relays, such as HTTP proxies, or by network level services, such as
NAT-PT [RFC2766]. Application relays pose several operational
problems: first, one must develop relays for all applications;
second, one must develop a management infrastructure to provision the
host with the addresses of the relays; in addition, the application
may have to be modified if one wants to use the relay selectively,
e.g., only when direct connection is not available. Network level
translation poses similar problems: in practice, network level
actions must be complemented by "application layer gateways" that
will rewrite references to IP addresses in the protocol, and while
these relays are not necessary for every application, they are
necessary for enough applications to make any sort of generalized
translation quite problematic; hosts may need to be parameterized to
use the translation service, and designing the right algorithm to
decide when to translate DNS requests has proven very difficult.
翻訳サービスに対しての議論は、非管理ネットワークにデュアルスタック解
決策を導入することに対する相対的な比較としての、すべてのアプリケーショ
ンのためにこれらのサービスを供給することについての困難です。翻訳サー
ビスは、ＨＴＴＰプロキシのようなアプリケーションリレーや、ＮＡＴ−Ｐ
Ｔ[RFC2766]のようなネットワークレベルサービスによって供給できます。ア
プリケーションリレーがいくつかの運用上の問題を提出します：最初に、誰
かがすべてのアプリケーションのためにリレーを開発しなくてはなりません；
第二に、誰かがリレーのアドレスをホストに供給する管理インフラを開発し
なくてはなりません；加えて、もし、例えばただダイレクト接続は利用可能
でないとき使うなど、選択的にリレーを使うことを望むならアプリケーショ
ンを修正しなければなりません。ネットワークレベル翻訳が類似の問題を提
出します：実際は、ネットワークレベル動作がプロトコルでのＩＰアドレス
参照を書き直す「アプリケーションレイヤゲートウェイ」で補完されなけれ
ばなりません、そしてこれらのリレーがすべてのアプリケーションで必要で
はないが、どんな一般的翻訳も問題が多いのでアプリケーションの数だけリ
レーが必要です；ホストは翻訳サービスを使うためのパラメータが必要かも
しれません、そしていつＤＮＳ要求を翻訳するべきかを決める正しいアルゴ
リズムを設計することは非常に難しいと分かりました。
Not assuming translation services in the network appears to be both
more practical and more robust. If the market requirement for a new
device requires that it interact with both IPv4 and IPv6 hosts, we
may expect the manufacturers of these devices to program them with a
dual stack capability; in particular, we expect general purpose
systems, such as personal computers, to be effectively dual-stack.
The only devices that are expected to be capable of only supporting
IPv6 are those designed for specific applications, which do not
require interoperation with IPv4-only systems. We also observe that
providing both IPv4 and IPv6 connectivity in an unmanaged network is
not particularly difficult: we have a fair amount of experience using
IPv4 in unmanaged networks in parallel with other protocols, such as
IPX.
ネットワークで翻訳サービスがないことはより現実的で強固なように思われ
ます。もし新しい装置のための市場条件が、ＩＰｖ４とＩＰｖ６ホスト両方
の通信を要求するなら、我々はこれらの装置の製造業者がデュアルスタック
能力をプログラムすることを期待するかもしれません；特に、我々は、パー
ソナル・コンピュータのような汎用システムが効率的にデュアルスタックで
あることを期待します。ただＩＰｖ６のサポートだけが予想される唯一のデ
バイスは特定のアプリケーションのために設計されるもので、これはＩＰｖ
４のみのシステムとの相互運用を必要としません。我々は同じく非管理ネッ
トワークでＩＰｖ４とＩＰｖ６の接続性の両方を供給することは特に難しく
ありません：我々の十分な経験で、非管理ネットワークで、ＩＰＸのような
他のプロトコルと平行してＩＰｖ４を使っていると述べます。
5.2.2. Addresses and Connectivity in Case B
5.2.2. 事例Ｂのアドレスと接続性
In Case B, the upgraded gateway will act as an IPv6 router; it will
continue providing the IPv4 connectivity, perhaps using NAT. Nodes
in the local network will typically obtain:
事例Ｂで、更新されたゲートウェイはＩＰｖ６ルータの役を務めるでしょう；
これはＩＰｖ４接続性を供給し、多分ＮＡＴを使い続けるでしょう。ローカ
ルネットワークのノードが典型的に獲得するでしょう：
- IPv4 addresses (from or via the gateway),
- ＩＰｖ４アドレス（ゲートウェイから）、
- IPv6 link local addresses, and
- ＩＰｖ６リンクローカルアドレス、そして
- IPv6 global addresses.
- ＩＰｖ６グローバルアドレス。
In some networks, NAT will not be in use and the local hosts will
actually obtain global IPv4 addresses. We will not elaborate on
this, as the availability of global IPv4 addresses does not bring any
additional complexity to the transition mechanisms.
あるネットワークで、ＮＡＴは使用していないでしょう、そしてローカルホ
ストは実際にグローバルＩＰｖ４アドレスを得るでしょう。我々は、グロー
バルＩＰｖ４アドレスの有効性が追加の複雑さを移行メカニズムにもたらさ
ないから、これを詳述しないでしょう。
To enable this scenario, the gateway needs to use a mechanism to
obtain a global IPv6 address prefix from the ISP, and advertise this
address prefix to the hosts in the unmanaged network; several
solutions will be assessed in a companion memo [EVAL].
このシナリオを可能にするために、ゲートウェイはＩＳＰからグローバルＩ
Ｐｖ６アドレスプレフィックスを得て、非管理ネットワークのホストにこの
アドレスプレフィックスを広告するメカニズムを使う必要があります；いく
つかの解決策が関連文書[EVAL]で評価されるでしょう。
5.2.3. Naming Services in Case B
5.2.3. 事例Ｂの名前サービス
In case B, hosts in the unmanaged domain have access to DNS services
through the gateway. As the gateway and the ISP both support IPv4
and IPv6, these services may be accessible by the IPv4-only hosts
using IPv4, by the IPv6-only hosts using IPv6, and by the dual stack
hosts using either. Currently, IPv4 only hosts usually discover the
IPv4 address of the local DNS resolver using DHCP; there must be a
way for IPv6-only hosts to discover the IPv6 address of the DNS
resolver.
事例Ｂで、非管理ドメインのホストがゲートウェイを通してＤＮＳサービス
にアクセスを持ちます。ゲートウェイとＩＳＰがＩＰｖ４とＩＰｖ６の両方
ををサポートします、これらのサービスはＩＰｖ４のみのホストはＩＰｖ４
でアクセスでき、ＩＰｖ６のみのノードはＩＰｖ６でアクセスでき、デュア
ルスタックホストはどちらでもアクセスできるます。現在、ＩＰｖ４だけの
ホストは通常ＤＨＣＰを使用してローカルＤＮＳリゾルバを発見します；Ｉ
Ｐｖ６のみのホストがＤＮＳリゾルバのＩＰｖ６アドレスを発見する方法が
あるに違いありません。
There must be a way to resolve the name of local hosts to their IPv4
or IPv6 addresses. Typing auto-configured IPv6 addresses in a
configuration file is impractical; this implies either some form of
dynamic registration of IPv6 addresses in the local service, or a
dynamic address discovery mechanism. Possible solutions will be
compared in the evaluation draft [EVAL].
ローカルホストの名前をＩＰｖ４あるいはＩＰｖ６アドレスに変換する方法
があるに違いありません。設定ファイルに自動設定ＩＰｖ６アドレスを記入
することは非実用的です；これはローカルサービスのＩＰｖ６アドレスの動
的登録の形式、あるいは動的アドレス探索機構の存在を暗示します。可能な
解決策は評価ドラフト[EVAL]で比較されるでしょう。
The requirement to support server applications in the unmanaged
network implies a requirement to publish the IPv6 addresses of local
servers in the DNS. There are multiple solutions, including domain
name delegation. If efficient reverse lookup functions are to be
provided, delegation of a fraction of the ip6.arpa tree is also
required.
非管理ネットワークでサーバアプリケーションをサポートする必要条件は、
ＤＮＳでローカルサーバのＩＰｖ６アドレスを公開する必要条件を暗示しま
す。ドメイン名委任を含めて、多数の解決策があります。もし効率的な逆検
索機能が供給されるなら、ip6.arpa木の一部の委任が同じく必要とされます。
The response to a DNS request should not depend on the protocol by
which the request is transported: dual-stack hosts may use either
IPv4 or IPv6 to contact the local resolver, the choice of IPv4 or
IPv6 may be random, and the value of the response should not depend
on a random event.
ＤＮＳリクエストに対する回答はリクエストが送られるプロトコルに依存す
るべきではありません：デュアルスタックホストがローカルリゾルバと連絡
を取るためにＩＰｖ４とＩＰｖ６のどちらを使ってもよいです、ＩＰｖ４か
ＩＰｖ６の選択はランダムであるかもしれません、そして回答の値はランダ
ムイベントに依存するべきではありません。
DNS transition issues in a dual IPv4/IPv6 network are discussed in
[DNSOPV6].
二重ＩＰｖ４／ＩＰｖ６ネットワークでのＤＮＳ移行問題が[DNSOPV6]で論じ
られます。
5.3. Case C, IPv6 Connectivity without Provider Support
5.3. 事例Ｃ、プロバイダサポートがないＩＰｖ６接続性
In this case, the gateway is dual stack, but the ISP is not. The
gateway has been upgraded and offers both IPv4 and IPv6 connectivity
to hosts. It cannot rely on the ISP for IPv6 connectivity, because
the ISP does not yet offer ISP connectivity.
この場合、ゲートウェイはデュアルスタックですが、ＩＳＰはそうではあり
ません。ゲートウェイは更新され、そしてホストにＩＰｖ４とＩＰｖ６の両
方の接続性を提供します。これはＩＰｖ６接続性をＩＳＰに依存できません、
なぜならＩＳＰはまだＩＳＰ接続性を提供しませんから。
5.3.1. Application Support in Case C
5.3.1. 事例Ｃでのアプリケーションサポート
Application support in case C should be identical to that of case B.
事例Ｃのアプリケーションサポートが事例Ｂのそれとまったく同じであるべ
きす。
5.3.2. Addresses and Connectivity in Case C
5.3.2. 事例Ｃのアドレスと接続性
The upgraded gateway will behave as an IPv6 router; it will continue
providing the IPv4 connectivity, perhaps using NAT. Nodes in the
local network will obtain:
更新されたゲートウェイはＩＰｖ６ルータとして振る舞うでしょう；これは
ＩＰｖ４接続性を供給し、多分ＮＡＴを使い続けるでしょう。ローカルなネッ
トワークでのノードが以下を得るでしょう：
- IPv4 addresses (from or via the gateway),
- ＩＰｖ４アドレス（ゲートウェイから）、
- IPv6 link local addresses,
- ＩＰｖ６リンクローカルアドレス、
- IPv6 global addresses.
- ＩＰｖ６グローバルアドレス
There are two ways to bring immediate IPv6 connectivity on top of an
IPv4 only infrastructure: automatic tunnels, e.g., provided by the
6TO4 technology [RFC3056], or configured tunnels. Both technologies
have advantages and limitations, which will be studied in another
document.
ＩＰｖ４だけのインフラ上に直接のＩＰｖ６接続性を得る２つの方法があり
ます：自動トンネル、例えば、６TO４技術[RFC3056]の供給、あるいはトン
ネル設定。両方の技術が利点と限界を持ち、これは他の文書で調査されるで
しょう。
There will be some cases where the local hosts actually obtain global
IPv4 addresses. We will not discuss this scenario, as it does not
make the use of transition technology harder, or more complex. Case
A has already examined how hosts could obtain IPv6 connectivity
individually.
ローカルなホストが実際にグローバルＩＰｖ４アドレスを得るいくつかの場
合があるでしょう。我々は、これが移行技術の使用をより難しくするかより
複雑にしないので、このシナリオを論じないでしょう。事例Ａで既にどのよ
うにホストが個々にＩＰｖ６接続性を得ることができるか調べました。
5.3.3. Naming Services in Case C
5.3.3. 事例Ｃの名前サービス
The local naming requirements in case C are identical to the local
naming requirements of case B, with two differences: delegation of
domain names, and management of reverse lookup queries.
事例Ｃのローカル名の必要条件は、２つの違い以外は、事例Ｂの名前必要条
件とまったく同じです：ドメイン名の委任と逆引き要求の管理。
A delegation of some domain name is required in order to publish the
IPv6 addresses of servers in the DNS.
あるドメイン名の委任はＤＮＳでサーバのＩＰｖ６アドレスを公開するため
に必要とされます。
A specific mechanism for handling reverse lookup queries will be
required if the gateway uses a dynamic mechanism, such as 6to4, to
obtain a prefix independently of any IPv6 ISP.
もしゲートウェイがＩＰｖ６のＩＳＰと独立なプレフィックスを得るために
6to4のような動的機構を使うなら、逆検索の問合せを処理するための特定の
メカニズムが必要とされるでしょう。
5.4. Case D, ISP Stops Providing Native IPv4 Connectivity
5.4. 事例Ｄ、ＩＳＰがネイティブのＩＰｖ４接続性を供給をやめる
In this case, the ISP is IPv6-only, so the gateway loses IPv4
connectivity, and is faced with an IPv6-only service provider. The
gateway itself is dual stack, and the unmanaged network includes IPv4
only, IPv6-only, and dual stack hosts. Any interaction between hosts
in the unmanaged network and IPv4 hosts on the Internet will require
the provision of some inter-protocol services by the ISP.
この場合、ＩＳＰはＩＰｖ６のみです、それでゲートウェイはＩＰｖ４接続
性を失い、ＩＰｖ６のみのサービスプロバイダに直面しています。ゲートウェ
イ自身はデュアルスタックで、非管理ネットワークはＩＰｖ４のみとＩＰｖ
６のみとデュアルスタックホストを含みます。非管理ネットワーク内のホス
トとインターネットのＩＰｖ４ホストのどんな対話もＩＳＰの何らかのプロ
トコル間サービスの準備を必要とするでしょう。
5.4.1. Application Support in Case D
5.4.1. 事例Ｄのアプリケーションサポート
At this phase of the transition, IPv6 hosts can participate in all
types of applications with other IPv6 hosts. IPv4 hosts in the
unmanaged network will be able to perform local applications with
IPv4 or dual stack local hosts.
この移行のフェーズにおいて、ＩＰｖ６ホストが他のＩＰｖ６ホストとあら
ゆるタイプのアプリケーションに参加することができます。非管理ネットワー
クのＩＰｖ４ホストはＩＰｖ４あるいはデュアルスタックローカルホストと
ローカルなアプリケーションを実行することが可能であるでしょう。
As in case B, we will assume that IPv6-only hosts will not interact
with IPv4-only hosts, either local or remote. We must however assume
that IPv4-only hosts and dual stack hosts will want to interact with
IPv4 services available on the Internet: the inability to do so would
place the IPv6-only provider at a great commercial disadvantage
compared to other Internet service providers.
事例Ｂのように、我々はＩＰｖ６のみのホストが、ローカルか遠距離化に関
わらず、ＩＰｖ４のみのホストと通信しないと想定するでしょう。しかしな
がらＩＰｖ４のみのホストとデュアルスタックホストがインターネット上に
利用可能なＩＰｖ４サービスと通信を望むと想定します：そうしなければ他
のインターネット・サービスプロバイダと比較して、ＩＰｖ６のみのプロバ
イダは、商売上の大きな不利になります。
There are three possible ways that an ISP can provide hosts in the
unmanaged network with access to IPv4 applications: by using a set of
application relays, by providing an address translation service, or
by providing IPv4-over-IPv6 tunnels. Our analysis concludes that a
tunnel service seems to be vastly preferable.
ＩＰｖ４アプリケーションにアクセスする非管理ネットワーク内のホストを
ＩＳＰが供給する３つの方法があります：アプリケーションリレーのセット
を使うことで、アドレス翻訳サービスを供給することで、ＩＰｖ６上のＩＰ
ｖ４トンネルを供給することで。我々の分析はトンネルサービスが非常に望
ましいように思われると結論します。
We already mentioned the drawbacks of the application gateway
approach when analyzing case B: it is necessary to provide relays for
all applications, to develop a way to provision the hosts with the
addresses of these relays, and to modify the applications so that
they will only use the relays when needed. We also observe that in
an IPv6-only ISP, the application relays would only be accessible
over IPv6, and would thus not be accessible by the "legacy" IPv4-only
hosts. The application relay approach is thus not very attractive.
我々は、事例Ｂを分析する時、すでにアプリケーション・ゲートウェイ方式
の欠点を言いました：すべてのアプリケーションにリレーを提供して、これ
らのリレーアドレスをホストに供給する方法を開発し、必要な時だけリレー
を使うようにアプリケーションを修正することは必要です。我々は同じくＩ
Ｐｖ６のみのＩＳＰで、アプリケーションリレーがＩＰｖ６でのみアクセス
可能であろうから、「旧式」なＩＰｖ４のみのホストでアクセスできないで
しょう。アプリケーションリレーの方法は非常に魅力的ではありません。
Providing a network address and protocol translation service between
IPv6 and IPv4 would also have many drawbacks. As in case B, it will
have to be complemented by "application layer gateways" that will
rewrite references to IP addresses in the protocol; hosts may need to
be parameterized to use the translation service, and we would have to
solve DNS issues. The network level protocol translation service
doesn't appear to be very desirable.
ＩＰｖ６とＩＰｖ４の間のネットワークアドレスとプロトコル翻訳サービス
を供給することは同じく多くの欠点を持つでしょう。事例Ｂのように、これ
はプロトコルのＩＰアドレス参照を書き直すだろうから「アプリケーション
レイヤゲートウェイ」で補完されなければならないでしょう；ホストが翻訳
サービスを使うためにパラメータ化されている必要があるかもしれず、そし
て我々はＤＮＳ問題を解かなければならないでしょう。ネットワークレベル
プロトコル翻訳サービスは非常に望ましいように思われません。
The preferable alternative to application relays and network address
translation is the provision of an IPv4-over-IPv6 service.
アプリケーションリレーとネットワークアドレス翻訳に対する望ましい選択
肢はＩＰｖ６上のＩＰｖ４サービスの準備です。
5.4.2. Addresses and Connectivity in Case D
5.4.2. 事例Ｄでのアドレスと接続性
The ISP assigns an IPv6 prefix to the unmanaged network, so hosts
have a global IPv6 address and use it for global IPv6 connectivity.
This will require delegation of an IPv6 address prefix, as
investigated in case C.
ＩＳＰはＩＰｖ６プレフィックスを非管理ネットワークに割り当てます、そ
れでホストグローバルなＩＰｖ６アドレスを持ち、そしてグローバルなＩＰ
ｖ６接続性のためにこれを使います。これは、事例Ｃで調査したように、Ｉ
Ｐｖ６アドレスプレフィックスの委任を必要とするでしょう。
To enable IPv4 hosts and dual stack hosts accessibility to remote
IPv4 services, the ISP must provide the gateway with at least one
IPv4 address, using some form of IPv4-over-IPv6 tunneling. Once such
addresses have been provided, the gateway effectively acquires dual-
stack connectivity; for hosts inside the unmanaged network, this will
be indistinguishable from the IPv4 connectivity obtained in case B or
C.
ＩＰｖ４ホストとデュアルスタックホストから遠隔ＩＰｖ４へのアクセス性
を確保するために、ＩＳＰは少なくとも１つのＩＰｖ４アドレスをゲートウェ
イに提供し、ある形式ＩＰｖ６上のＩＰｖ４トンネルを使わなければなりま
せん。このようなアドレスが供給された途端に、ゲートウェイは効率的にデュ
アルスタック接続性を獲得します；非管理ネットワーク内のホストにとって、
これは事例Ｂや事例Ｃで得られたＩＰｖ４接続性と区別できないでしょう。
5.4.3. Naming Services in Case D
5.4.3. 事例Ｄの名前サービス
The loss of IPv4 connectivity has a direct impact on the provision of
naming services. In many IPv4 unmanaged networks, hosts obtain their
DNS configuration parameters from the local gateway, typically
through the DHCP service. If the same mode of operation is desired
in case D, the gateway will have to be provisioned with the address
of a DNS resolver and with other DNS parameters, and this
provisioning will have to use IPv6 mechanisms. Another consequence
is that the DNS service in the gateway will only be able to use IPv6
connectivity to resolve queries; if local hosts perform DNS
resolution autonomously, they will have the same restriction.
ＩＰｖ４接続性の損失は名前サービスの準備に直接の影響を持ちます。多く
のＩＰｖ４非管理ネットワークで、ホストがローカルゲートウェイから、一
般にＤＨＣＰサービスを通して、ＤＮＳ設定パラメータを得ます。もし事例
Ｄでオペレーション様式が望まれるなら、ゲートウェイはＤＮＳリゾルバの
アドレスでと他のＤＮＳパラメータを供給しなければならないでしょう、そ
してこの供給にはＩＰｖ６メカニズムを使わなければならないでしょう。も
う１つの帰結がゲートウェイでのＤＮＳサービスが質問を解決するためにＩ
Ｐｖ６接続性を使うことだけが可能であろうということです；もしローカル
ホストが独立してＤＮＳ解決を行うなら、それらは同じ制限を持つでしょう。
On the surface, this seems to indicate that the local hosts will only
be able to resolve names if the domain servers are accessible through
an IPv6 address documented in an AAAA record. However, the DNS
services are just one case of "IPv4 servers accessed by IPv6 hosts":
it should be possible to simply send queries through the IPv4
connectivity services to reach the IPv4 only servers.
表面上これは、もしドメインサーバがＡＡＡＡレコードで記述されたＩＰｖ
６アドレスを通してアクセス可能な場合だけ、ローカルホストが名前変換を
可能であるであろうことを示すように、思われます。しかしながら、ＤＮＳ
サービスは「ＩＰｖ６ホストのアクセスするＩＰｖ４サーバ」の１つの事例
です：ＩＰｖ４と通信を取るＩＰｖ４接続性サービスを通して問合せをサー
バに送ることは可能であるべきです。
The gateway should be able to act as a recursive DNS name server for
the remaining IPv4 only hosts.
ゲートウェイは残りのＩＰｖ４ホストのために再帰ＤＮＳネームサーバの役
を務めることが可能であるべきです。
6. Security Considerations
6. セキュリティの考察
Security considerations are discussed as part of the applications'
requirements. They include:
セキュリティの考察がアプリケーションの必要条件の一部として論じられま
す。これは以下を含みます：
- the guarantee that local applications are only used locally,
- ローカルアプリケーションがローカルにだけ使われるという保証、
- the protection of the privacy of clients
- クライアントのプライバシーの保護
- the requirement that peer-to-peer connections are only used by
authorized peers
- ピア対ピア接続が認証された相手者によってだけ使われるという必要条件
- the requirement that tunneling protocols used for IPv6 access over
IPv4 be designed for secure use
- セキュリティが高い用途のために設計されたＩＰｖ４上のＩＰｖ６アクセ
スに使うトンネルプロトコルの必要条件
- the related requirement that servers in the infrastructure
supporting transition scenarios be designed so as to not be
vulnerable to abuse.
- 移行シナリオを支援しているインフラの中のサーバが乱用の被害をうけや
すくないように設計されるという関連した必要条件
The security solutions currently used in IPv4 networks include a
combination of firewall functions in the gateway, authentication and
authorization functions in the applications, encryption and
authentication services provided by IP security, Transport Layer
Security and application specific services, and host-based security
products, such as anti-virus software and host firewalls. The
applicability of these tools in IPv6 unmanaged networks will be
studied in a another document.
現在ＩＰｖ４ネットワークで使われたセキュリティ解決策は、ゲートウェイ
のファイアウォール機能と、アプリケーションの認証と認可機能と、ＩＰセ
キュリティが供給する暗号化と認証サービスと、トランスポートレイヤセキュ
リティとアプリケーション固有サービスと、対ウイルスソフトウェアとホス
トファイアウォールのようなホストベースのセキュリティ商品の組合せを含
みます。ＩＰｖ６非管理ネットワークへのこれらのツールの適用性は他の文
書で研究されるでしょう。
7. Acknowledgements
7. 謝辞
This document has benefited from the comments of the members of the
IETF V6OPS working group, and from extensive reviews by Chris
Fischer, Tony Hain, Kurt Erik Lindqvist, Erik Nordmark, Pekka Savola,
and Margaret Wasserman.
この文書はＩＥＴＦ V６ＯＰＳ作業班のメンバのコメントと、Chris Fischer
とTony HainとKurt Erik LindqvistとErik NordmarkとPekka Savolaと
Margaret Wassermanによる広範囲のレビューから利益を得ました。
8. References
8. 参考文献
8.1. Normative References
8.1. 参照する参考文献
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
8.2. Informative References
8.2. 有益な参考文献
[EVAL] Evaluation of Transition Mechanisms for Unmanaged
Networks, Work in Progress.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J. and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day,
"Service Location Protocol, Version 2", RFC 2608, June
1999.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3022] Srisuresh, P. and K. Egevang. "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[DNSOPV6] Durand, A., Ihren, J. and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", Work in
Progress.
[DNSINADDR] Senie, D., "Requiring DNS IN-ADDR Mapping", Work in
Progress.
9. Authors' Addresses
9. 著者のアドレス
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
10. Full Copyright Statement
10. 著作権表示全文
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/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。