[要約] RFC 3750は、IPv6移行シナリオにおける非管理ネットワークに関するガイドラインです。その目的は、非管理ネットワークでのIPv6移行の異なるシナリオを提供し、ネットワーク管理者に役立つ情報を提供することです。
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
管理されていないネットワークIPv6トランジションシナリオ
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.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
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.
このドキュメントでは、IPv6遷移メカニズムが管理されていないネットワークで使用されるシナリオを定義します。これらのメカニズムの適合性を評価するには、これらのメカニズムを使用する必要があるシナリオを定義する必要があります。特定の範囲の1つは、「管理されていないネットワーク」です。これは、通常、家庭または小規模のオフィスネットワークに対応しています。シナリオは単一のサブネットに固有のものであり、ゲートウェイとインターネットサービスプロバイダー（ISP）によってサポートされるIP接続の観点から定義されています。最初に、ローカル、クライアント、ピアツーピア、サーバーの4つのクラスのアプリケーションの一般的な要件を調べます。次に、各シナリオについて、IPv4からIPv6へのアプリケーションのスムーズな移行のニーズを分析することにより、移行要件を推測します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Local Applications . . . . . . . . . . . . . . . . . . . 5
3.2. Client Applications. . . . . . . . . . . . . . . . . . . 5
3.3. Peer-to-Peer Applications. . . . . . . . . . . . . . . . 5
3.4. Server Applications. . . . . . . . . . . . . . . . . . . 5
4. Application Requirements of an IPv6 Unmanaged Network. . . . . 6
4.1. Requirements of Local Applications . . . . . . . . . . . 6
4.2. Requirements of Client Applications. . . . . . . . . . . 7
4.2.1. Privacy Requirement of Client Applications . . . 7
4.3. Requirements of Peer-to-Peer Applications. . . . . . . . 8
4.4. Requirements of Server Applications. . . . . . . . . . . 9
5. Stages of IPv6 Deployment. . . . . . . . . . . . . . . . . . . 9
5.1. Case A, Host Deployment of IPv6 Applications . . . . . . 10
5.1.1. Application Support in Case A. . . . . . . . . . 10
5.1.2. Addresses and Connectivity in Case A . . . . . . 11
5.1.3. Naming Services in Case A. . . . . . . . . . . . 12
5.2. Case B, IPv6 Connectivity with Provider Support. . . . . 12
5.2.1. Application Support in Case B. . . . . . . . . . 12
5.2.2. Addresses and Connectivity in Case B . . . . . . 13
5.2.3. Naming Services in Case B. . . . . . . . . . . . 14
5.3. Case C, IPv6 Connectivity without Provider Support . . . 14
5.3.1. Application Support in Case C. . . . . . . . . . 15
5.3.2. Addresses and Connectivity in Case C . . . . . . 15
5.3.3. Naming Services in Case C. . . . . . . . . . . . 15
5.4. Case D, ISP Stops Providing Native IPv4 Connectivity . . 15
5.4.1. Application Support in Case D. . . . . . . . . . 16
5.4.2. Addresses and Connectivity in Case D . . . . . . 16
5.4.3. Naming Services in Case D. . . . . . . . . . . . 17
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References. . . . . . . . . . . . . . . . . . . 18
8.2. Informative References. . . . . . . . . . . . . . . . . . 18
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
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.
IPv4 [RFC791]からIPv6 [RFC2460]への遷移メカニズムの適合性を評価するには、これらのメカニズムを使用する必要がある環境または範囲を定義する必要があります。特定の範囲の1つは、「管理されていないネットワーク」です。これは、通常、ホームネットワークまたは小規模なオフィスネットワークに対応しています。
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.
このドキュメントは、さまざまな移行シナリオによってもたらされる要件を研究し、4つのメインセクションに編成されています。セクション2では、検討中のトポロジーを定義します。セクション3では、ローカルアプリケーション、クライアントアプリケーション、ピアツーピアアプリケーション、サーバーアプリケーションなど、管理されていないネットワークについて考慮する4つのクラスのアプリケーションを紹介します。セクション4では、これらの4つのクラスのアプリケーションの要件について説明します。セクション5では、これらの要件がIPv6展開中に遭遇する4つの構成にどのように変換されるかを分析します。IPv6を提供しないゲートウェイ、デュアルスタックISPに接続されたデュアルスタックゲートウェイ、IPv4のみのISPに接続されたデュアルスタックゲートウェイ、およびIPv6-IPv6のみのISPに接続された登録ゲートウェイ。これらの4つの構成は確かに可能な構成の網羅的なリストではありませんが、それらは管理されていないネットワークの共通のケースを表すと考えています。
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:
典型的な管理されていないネットワークは、単一のインターネットサービスプロバイダー（ISP）接続を介してインターネットに接続された単一のサブネットで構成されています。いくつかのホストがサブネットに接続されている場合があります。
+------+
| 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.
サブネットとISPアクセスリンクの間には、NATおよびファイアウォール関数を実行する場合と実行しない場合があるゲートウェイがあります。ゲートウェイがNAT関数[RFC3022]を実行すると、一般にローカルホスト[RFC1918]にプライベートIPv4アドレスを割り当てます。この構成の重要なポイントは、通常、ゲートウェイが「管理」されていないことです。ほとんどの場合、いくつかの静的ポリシーを組み込んだ単純な「アプライアンス」です。ISPによってゲートウェイが調達および構成されている多くのケースがあります。
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.
2つのゲートウェイを後ろに見つけるケースもあることに注意してください。1つはISPによって管理され、もう1つは管理されていないネットワークの所有者によって追加されています。それらのほとんどが何らかの管理を必要とするか、ユーザーによって追加されたゲートウェイがL2スイッチとして機能する可能性があるため、このメモではカバーされていません。
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.
管理されていないネットワークとISP間のアクセスリンクは、静的、永続的な接続、またはダイヤルアップまたはISDNラインなどの動的接続のいずれかです。
In a degenerate case, an unmanaged network might consist of a single host, directly connected to an ISP.
退化した場合、管理されていないネットワークは、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.
「ゲートウェイ」がレイヤー2ブリッジに置き換えられる場合があります。このような展開では、ホストはISPサービスに直接アクセスできます。長い開発を避けるために、これらのケースをゲートウェイが存在しないかのように、つまり、各ホストが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.
管理されていないネットワークの定義は、複数のサブネットで構成されるネットワークを明示的に除外しています。一部のホームネットワークと中小企業ネットワークには複数のサブネットが含まれていることを容易に認めますが、テクノロジーの現在の状態では、これらの複数のサブネットネットワークは「管理されていません」。一部の有能な管理者はルーターを明示的に構成する必要があります。したがって、当社は、そのような有能なオペレーターが予想されない単一のサブネットネットワークに集中します。
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).
ユーザーは、ローカル、クライアント、サーバー、ピアツーピアの4種類のアプリケーションで、管理されていないネットワークサービスを使用または使用する場合があります。これらのアプリケーションは、今日のネットワークで簡単に実行される場合とできない場合があります（一部の場合はそうでないものもあります）。
"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.
ローカルアプリケーションは、GatewayがNATまたはファイアウォール機能を実行する場合でも、IPv4の無管理ネットワークで効果的に機能します。実際、ゲートウェイでのファイアウォールサービスは、インターネットユーザーによる干渉からローカルアプリケーションを隔離するため、多くの場合、望ましいとみなされます。
"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.
「クライアントアプリケーション」とは、管理されていないネットワーク上のクライアントとリモートロケーションのサーバーを含むものです。典型的な例は、管理されていないネットワーク内のクライアントからWebサーバーにアクセスするか、管理されていないネットワークの外側のサーバーの助けを借りて電子メールを読み取り、送信することです。
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.
クライアントアプリケーションは、GatewayがNATまたはファイアウォール機能を実行する場合でも、IPv4の無管理ネットワークで正しく機能する傾向があります。これらの翻訳およびファイアウォール機能は、クライアントアプリケーションを有効にするために正確に設計されています。
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.
「ピアツーピア」アプリケーションには、実際に2種類の「ピアツーピア」アプリケーションがあります。これは、管理されていないネットワークのホストのみを含むものと、管理されていないネットワーク上の1つ以上のホストと、管理されていないネットワーク外の1つ以上のホストを含むものです。前者はセクション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.
ピアツーピアアプリケーションは、多くの場合、管理されていないIPv4ネットワークではうまく機能しません。アプリケーション開発者は、多くの場合、「リレーサーバー」の助けを求めて、実際にはピアツーピア接続を連続したクライアント/サーバー接続のペアに再構築する必要があります。
"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.
「サーバーアプリケーション」には、ネットワーク外の他の関係者が使用するために、管理されていないネットワークでサーバーを実行することが含まれます。典型的な例は、管理されていないネットワーク内のホストの1つでWebサーバーまたは電子メールサーバーを実行することです。
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.
ほとんどの管理されていないIPv4ネットワークにこれらのサーバーを展開するには、NATまたはファイアウォール[RFC2993]の特別なプログラミングが必要であり、NATが少数のグローバルIPアドレスのみを公開し、「ポート翻訳」に依存する場合、より複雑です。NATが正確に1つのグローバルIPアドレスを管理し、「ポート翻訳」に依存している一般的なケースでは、特定の外部ポートは1つの内部サーバーでのみ使用できます。
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.
サーバーの展開には通常、各サーバーに安定したDNS名を提供し、グローバルIPv4アドレスをその名前に関連付ける必要があります。これは、アドレスがサーバー自体のアドレスであろうと、ファイアウォールまたはNATとして機能するルーターのアドレスであろうと。DNSの更新は管理タスクであるため、管理されていないネットワークの範囲外にあります。一方、ターゲットサーバーのアドレスを渡すために、帯域外の手法（インスタントメッセージシステムへのカットアンドパストなど）を使用することもできます。
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.
IPv6に移行する際、さまざまなアプリケーションの要件を満たす必要があります。これは、次の方法で要約できます。IPv4でうまく機能したアプリケーションは、移行中にうまく機能し続ける必要があります。IPv6を使用して、現在IPv4ネットワークに展開するのが難しい新しいアプリケーションを展開することができるはずです。また、これらのIPv6アプリケーションの展開はシンプルで簡単に管理できる必要がありますが、ソリューションも堅牢で安全である必要があります。
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.
IPv6のマネージドネットワークのアプリケーション要件は、接続、命名、セキュリティの3つの一般的なカテゴリに分類されます。接続性の問題には、IPv6アドレスの提供とその品質が含まれます。ホストにはグローバルアドレスが必要ですか？これらのアドレスが安定している場合、またはより正確には、これらのアドレスの予想される寿命は何ですか？命名の問題には、ホストの名前の管理が含まれます。ホストはDNS名を必要としますか？セキュリティの問題には、接続性への制限、プライバシーの懸念、および一般的に言えば、アプリケーションのセキュリティが含まれます。
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].
ローカルアプリケーションは通常、アドホックネーミングシステムを使用します。これらのシステムの多くは独自です。標準システムの例は、サービスロケーションプロトコル（SLP）[RFC2608]です。
The security of local applications will usually be enhanced if these applications can be effectively isolated from the global Internet.
これらのアプリケーションをグローバルインターネットから効果的に分離できる場合、ローカルアプリケーションのセキュリティは通常強化されます。
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.
クライアントアプリケーションにはグローバル接続が必要です。IPv6ネットワークでは、クライアントがグローバルIPv6アドレスを使用することを期待します。これは、クライアントサーバーセッションの期間中は安定したままでなければなりません。
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.
クライアントアプリケーションは通常、ドメイン名システムを使用してサーバーを見つけます。IPv6ネットワークでは、クライアントはDNSリゾルバーを見つけることができる必要があります。
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.
多くのサーバーは、クライアントのIPアドレスに関連付けられたDNS名を検索しようとします。IPv4ネットワークでは、このIPアドレスは多くの場合、インターネットサービスプロバイダーによってゲートウェイに割り当てられ、対応するPTRレコードはISPによって維持されます。多くの場合、これらのPTRレコードは、IPv4アドレスからアルゴリズム的な方法で導出されている、おかしなものです。それらに含まれる主な情報は、ISPのドメイン名です。IPv6ネットワークで同等の関数を提供すべきかどうかは不明です。
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.
IPv6ネットワークサービスをクライアントのプライバシーを強化するために設計すべきかどうか、特にRFC 3041 [RFC3041]のサポートが必要かどうかは議論の余地があります。RFC 3041では、ホストがホスト識別子がランダム化されるIPv6アドレスを選択できます。これは、IPv6アドレスとホスト識別子を使用して、デバイスの所有者のインターネット接続を追跡できないように設計されています。
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.
多くの人は、アドレスのホスト識別子部分をランダム化することは半分しかないことを観察しています。管理されていないネットワークアドレスのプレフィックスが一定のままである場合、無作為化は、管理されていないネットワーク内のホストが特定の接続、たとえば両親と比較して特定の接続を採用します。これにより、そのような接続のプライバシー評価は、NATが静的IPv4アドレスを管理する管理されていないネットワークから発信されるIPv4接続と同等に配置されます。どちらの場合も、IPv4アドレスまたはIPv6プレフィックスを使用して、接続が発生した特定のホームなど、管理されていないネットワークを識別できます。
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.
アドレスのランダム化は、プライバシーを保証するのに十分ではありません。使用法は、アプリケーションレベルの「Cookie」からデータマイニングやトラフィック分析を含む複雑な手法まで、他のさまざまな手段で追跡できます。しかし、悪い状況を悪化させるべきではありません。プライバシーに対する他の攻撃は可能かもしれませんが、これはIPv6アドレスを介した追加の追跡を可能にする理由ではありません。
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.
ホスト識別子のランダム化にはいくつかのコストがあります。ホストの住所管理はホストにとってより複雑であり、逆DNSサービスの提供はより困難であり、ゲートウェイは近隣アドレスのより大きなキャッシュを維持する必要がある場合があります。ただし、既存の実装からの経験は、これらのコストが圧倒的ではないことを示しています。限られた利点を考えると、すべてのホストがプライバシーアドレスを使用することを要求することは不合理です。ただし、コストが限られていることを考えると、すべての管理されていないネットワークが、そうすることを選択したホストによるプライバシーアドレスの使用を許可することを要求することは合理的です。
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.
ピアツーピアアプリケーションには、グローバルな接続が必要です。IPv6ネットワークでは、ピアがグローバルIPv6アドレスを使用することを期待します。これは、ピアツーピアセッションの期間中は安定したままでなければなりません。
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.
ピアツーピアアプリケーションのセキュリティには複数の側面があり、その多くはランデブーシステムのセキュリティに関連しています。ピアがIPv6アドレスを安全に交換できると仮定した場合、主なセキュリティ要件は、第三者による干渉なしにピア間でデータを安全に交換する能力です。
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人によるプライベートな会話は、2つの保証を取得できる場合、多くの個人が「IPv6のみの」モデルを検討する意思があることを示唆しています。
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) IPv4からの回帰、つまり、IPv4を使用してピアツーピアアプリケーションに参加できるすべての顧客にもIPv6が到達できるという回帰がないこと。
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) IPv6は、少なくともいくつかの困難な問題のソリューションを提供します。たとえば、IPv4 NATの後ろにあるピアがピアツーピアアプリケーションに参加できるようにします。
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.
人気のあるピアツーピアアプリケーションにIPv6接続を必要とすることで、エコノミストが「ネットワーク効果」と呼ぶものを作成し、IPv6の展開を大幅に高速化できます。
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.
サーバーアプリケーションにはグローバル接続が必要です。これは、IPv6ネットワークでグローバルアドレスを意味します。NATを使用したIPv4ネットワークでは、サーバーが提供する各サービスに対して、NATを設定する必要があります。そのサービスに送信されたサーバーにサービスを提供するサーバーに転送するように構成する必要があります。
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".
サーバーアプリケーションは通常、DNSのサーバーのアドレスの公開に依存しています。これにより、サーバーに「グローバルDNS名」でプロビジョニングされる必要があります。
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.
サーバーのアドレスが変更された場合、サーバーのDNSエントリは、できればリアルタイムで更新する必要があります。実際には、DNSの更新は遅くなる可能性があります。これは、IPv6アドレスが安定したままであれば、サーバーアプリケーションが展開される可能性が高いことを意味します。
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.
サーバーアプリケーションのセキュリティは、主にサーバーの正確性と、担保効果がないことに依存します。インターネット上でサーバーを開くと、同じホストの他のサービスへのリモートアクセスが可能になると、多くのインシデントが発生します。
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.
IPv6の展開は、展開がほとんどまたはまったくない初期状態から、IPv4インフラストラクチャを廃止する可能性のある最終段階に進むことを期待しています。このプロセスは長年にわたって伸びると予想しています。また、さまざまな関係者が異なるペースでIPv6を展開するため、同期しないと予想されます。
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.
ある程度明確にするために、管理されていないネットワークの移行に関与する3つのエンティティ（ISP（おそらくISP消費者前提機器（CPE）を含む）、ホームゲートウェイ、ホスト（コンピューターとアプライアンス）を区別します。それぞれがIPv4-のみ、IPv4とIPv6の両方、またはIPv6のみをサポートできます。それは私たちに27の可能性を与えます。最も重要なケースについて説明します。すべての場合において、ホストはIPv4のみ、デュアルスタック、および（おそらく）IPv6のみのホストの組み合わせであると仮定します。
The cases we will consider are:
私たちが考慮するケースは次のとおりです。
A) a gateway that does not provide IPv6 at all; B) a dual-stack gateway connected to a dual stack ISP; C) a dual stack gateway connected to an IPV4-only ISP; and D) a gateway connected to an IPv6-only ISP
a）IPv6をまったく提供しないゲートウェイ。b）デュアルスタックISPに接続されたデュアルスタックゲートウェイ。c）IPv4のみのISPに接続されたデュアルスタックゲートウェイ。およびd）IPv6のみのISPに接続されたゲートウェイ
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.
これらのケースのほとんどで、ゲートウェイにはNATが含まれていると仮定します。これは常にそうであるとは限らないことを認識していますが、それに対処しなければならないことは十分に一般的であることを提出します。さらに、これらのケースの非ナットバリアントは、この同じ一連のケースにかなり密接にマッピングされると考えています。実際、3つの非ナットバリアントを考慮することができます。直接接続されたホスト。橋として機能するゲートウェイ。NAT以外のIPルーターとして機能するゲートウェイ。
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.
直接接続されたホストのケースは、事実上、ケースB、C、およびDのバリエーションであり、ホストはゲートウェイで使用可能なすべてのソリューションを使用できます：ケースB ISPがデュアルスタックの場合、ISPがIPv4のみを提供する場合はケースCISPがIPv6接続のみを提供する場合、接続性、およびケースD。
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.
ゲートウェイが橋である場合、ホストは事実上、ISPに直接接続されており、すべての実用的な問題のために、直接接続されたホストとして動作します。
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.
ゲートウェイがIPルーターであるが、NATではない場合は、ケースA、B、C、およびDの分析で小さなバリアントとして扱われます。
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.
この場合、ゲートウェイはIPv6を提供しません。ISPはIPv6を提供する場合と提供しない場合がありますが、これは、アップグレードされていないゲートウェイがホストがISPサービスを使用することを妨げるため、関連性がありません。一部のホストは、IPv6を必要とするアプリケーションを実行するか、IPv6でより適切に動作するためにIPv6接続を取得しようとします。この場合、ホストはIPv6遷移メカニズムを単独で処理する必要があります。
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.
このケースには、ゲートウェイによって実装されたサービスの種類に応じて、2つのバリエーションがあります。多くの場合、ゲートウェイはIPv6の展開に対する直接的な障害ですが、何らかの形のブリッジモードCPEであるか、プレーン（フィルタリングもNATもいない）であるゲートウェイは、実際にはこのカテゴリに分類されません。
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.
ケースAの焦点は、非管理されていないネットワーク上のホストとネットワーク外の一部のIPv6のみのホスト間の通信を有効にすることです。
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.
近い将来の主な焦点、つまりIPv6の早期採用者のための焦点は、ピアツーピアアプリケーションです。ただし、IPv6の展開が進むにつれて、一部のネットワークがIPv6のみのサービスを展開している状況を見つける可能性があります。
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.
ローカルアプリケーションはケースAの主要な焦点ではありません。この段階では、管理されていないネットワーク内のすべてのクライアントがIPv4のみまたはデュアルスタックサポートのいずれかを期待しています。ローカルアプリケーションは、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.
サーバーアプリケーションもケースAの主要な焦点ではありません。サーバーアプリケーションにはDNSサポートが必要です。これは、NATの後ろにあるクライアントのためにエンジニアリングするのが困難です。これは、この場合に存在する可能性があります。また、サーバーアプリケーションは現在、主にIPv4クライアントに対応しています。IPv6のみのサーバーを設置することは、それほど魅力的ではありません。
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.
対照的に、ピアツーピアアプリケーションはおそらく魅力的で展開しやすいです。ピアツーピアネットワークの一部として調整された方法で展開されます。つまり、ホストはすべての形態のIPv6アップグレードを受け取ることができます。多くの場合、独自の命名インフラストラクチャを提供します。その場合、DNSサービスに依存していません。
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.
5.1.1では、AがピアツーピアおよびクライアントIPv6アプリケーションを使用したい場合、ホストにIPv6接続を展開する可能性が高いことがわかりました。これらのアプリケーションでは、すべての参加ノードが何らかの形のIPv6接続、つまり少なくとも1つのグローバルに到達可能なIPv6アドレスを取得する必要があります。
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.
ローカルゲートウェイがローカルホストにグローバルIPv4アドレスを提供する場合、これらのホストはケースCで説明されているメカニズム、「プロバイダーサポートなしのIPv6接続」を個別に行使できます。ローカルゲートウェイがNAT機能を実装する場合、別のタイプのメカニズムが必要です。NATの後ろのピアへの接続を提供するメカニズムは、展開しやすく、軽量でなければなりません。TCPまたはTCP上のトンネルは、タイムアウトや再送信の場合にパフォーマンスが低下する可能性があるため、TCPまたは好ましくはUDPのいずれかを簡単に通過できるプロトコル上のトンネルを伴う必要があります。サーバーが必要な場合、これらのサーバーは、実際には、ピアツーピアネットワークまたはIPv6ベースのサービスの「サポートインフラストラクチャ」の一部として展開する必要があります。経済的現実は、これらのサーバーを実行するコストが可能な限り低くなることを意味します。
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.
IPv6展開のこのフェーズでは、管理されていないドメインのホストが既存のゲートウェイを介してIPv4を介してDNSサービスにアクセスできます。DNSリゾルバーは、IPv4のみを実装しても、AAAAレコードを提供することになっています。したがって、ローカルホストは、IPv6のみのサーバーのIPv6アドレスを取得できる必要があります。
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.
ゲートウェイがアップグレードされていない場合、逆ルックアップを管理していないネットワークでホストを提供することは困難です。これは、クライアントアプリケーションにとって潜在的な問題です。一部のサーバーは、クライアントの接続を受け入れることの一部として逆検索を必要とし、対応する名前の直接ルックアップがクライアントのIPv6アドレスと一致する必要がある場合があります。したがって、リバースルックアップソリューションを提供するか、IPv6サーバーが逆検索を必要としないことを確認する必要があります。
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.
この場合、ISPとゲートウェイはどちらもデュアルスタックです。ゲートウェイは、ISPへのネイティブIPv6接続を使用し、ISPによって割り当てられたIPv6プレフィックスを使用できます。
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.
ISPとゲートウェイがデュアルスタックの場合、クライアントアプリケーション、ピアツーピアアプリケーション、およびサーバーアプリケーションをすべて管理していないネットワークで簡単に有効にできます。
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.
管理されていないネットワークには、IPv4のみ、IPv6のみ、デュアルスタックの3種類のホストが含まれると予想されます。明らかに、デュアルスタックホストはIPv4ホストまたはIPv6のみのホストのみと簡単に対話できますが、IPv4のみのホストとIPv6のみのホストは、何らかの翻訳サービスを実行することなく通信できません。私たちの分析は、管理されていないネットワークがそのような翻訳サービスを提供する必要はないはずだと結論付けています。
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.
翻訳サービスを提供するための議論は、それらの可用性がIPv6のみのデバイスの展開、したがってIPv6への移行を加速するということです。ただし、これは、これらの翻訳サービスの可用性がIPv6を提供する圧力を減らし、IPv4のみのデバイスをフィールドに継続するだけであると主張できるため、疑わしい議論です。IPv6接続を提供する残りの圧力は、翻訳された交換とネイティブの相互接続の間の「サービス品質」の違いにすぎません。
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.
翻訳サービスに対する議論は、管理されていないネットワークにデュアルスタックソリューションをインストールすることの比較的容易さと比較して、これらのサービスをすべてのアプリケーションに提供することの難しさです。翻訳サービスは、HTTPプロキシなどのアプリケーションリレー、またはNAT-PT [RFC2766]などのネットワークレベルサービスによって提供できます。アプリケーションリレーはいくつかの運用上の問題を引き起こします。まず、すべてのアプリケーションのリレーを開発する必要があります。第二に、ホストにリレーのアドレスをプロビジョニングするには、管理インフラストラクチャを開発する必要があります。さらに、リレーを選択的に使用したい場合、たとえば直接接続が利用できない場合にのみ、アプリケーションを変更する必要がある場合があります。ネットワークレベルの翻訳は同様の問題をもたらします。実際には、プロトコル内のIPアドレスへの参照を書き直す「アプリケーションレイヤーゲートウェイ」によってネットワークレベルのアクションを補完する必要があります。あらゆる種類の一般化された翻訳を非常に問題とすること。ホストは、翻訳サービスを使用するためにパラメーター化する必要があり、適切なアルゴリズムを設計するために、DNSリクエストをいつ翻訳するかを決定することは非常に困難であることが証明されています。
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.
ネットワーク内の翻訳サービスがより実用的で堅牢であると仮定していません。新しいデバイスの市場要件がIPv4ホストとIPv6ホストの両方と対話する必要がある場合、これらのデバイスのメーカーがデュアルスタック機能を使用してプログラムすることを期待する場合があります。特に、パーソナルコンピューターなどの汎用システムが効果的にデュアルスタックであると予想しています。IPv6のみをサポートできると予想される唯一のデバイスは、IPv4のみのシステムとの相互操作を必要としない特定のアプリケーション向けに設計されたデバイスです。また、管理されていないネットワークでIPv4接続とIPv6接続の両方を提供することは特に難しくありません。IPXなどの他のプロトコルと並行して、管理されていないネットワークでIPv4を使用した経験がかなりあります。
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:
ケースBでは、アップグレードされたゲートウェイがIPv6ルーターとして機能します。おそらくNATを使用して、IPv4接続を提供し続けます。ローカルネットワーク内のノードは通常、取得します。
- IPv4 addresses (from or via the gateway), - IPv6 link local addresses, and - IPv6 global addresses.
- IPv4アドレス（Gatewayからまたは介して）、-ipv6リンクローカルアドレス、および-ipv6グローバルアドレス。
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.
一部のネットワークでは、NATは使用されず、ローカルホストは実際にグローバルIPv4アドレスを取得します。グローバルIPv4アドレスの可用性が遷移メカニズムに追加の複雑さをもたらさないため、これについて詳しく説明しません。
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].
このシナリオを有効にするために、ゲートウェイはメカニズムを使用してISPからグローバルIPv6アドレスプレフィックスを取得し、このアドレスのプレフィックスを管理されていないネットワークのホストに宣伝する必要があります。コンパニオンメモ[評価]でいくつかのソリューションが評価されます。
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.
ケースBでは、管理されていないドメインのホストがゲートウェイを介してDNSサービスにアクセスできます。GatewayとISPは両方ともIPv4とIPv6をサポートするため、これらのサービスは、IPv4のみのホストがIPv4のみを使用して、IPv6のみのホストを使用してIPv6のみのホスト、およびどちらを使用してデュアルスタックホストがアクセスできる場合があります。現在、IPv4ホストは通常、DHCPを使用してローカルDNSリゾルバーのIPv4アドレスを発見します。IPv6のみのホストがDNSリゾルバーのIPv6アドレスを発見する方法がなければなりません。
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].
ローカルホストの名前をIPv4またはIPv6アドレスに解決する方法が必要です。構成ファイルで自動構成IPv6アドレスを入力することは実用的ではありません。これは、ローカルサービスにおけるIPv6アドレスの何らかの動的登録、または動的アドレス発見メカニズムのいずれかを意味します。可能なソリューションは、評価ドラフト[評価]で比較されます。
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.
管理されていないネットワークでサーバーアプリケーションをサポートするための要件は、DNS内のローカルサーバーのIPv6アドレスを公開するための要件を意味します。ドメイン名の代表団を含む複数のソリューションがあります。効率的な逆ルックアップ関数を提供する場合、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リクエストへの応答は、リクエストが輸送されるプロトコルに依存しないでください。デュアルスタックホストは、IPv4またはIPv6を使用してローカルリゾルバーに連絡することができます。IPv4またはIPv6の選択はランダムであり、応答はランダムイベントに依存してはなりません。
DNS transition issues in a dual IPv4/IPv6 network are discussed in [DNSOPV6].
デュアルIPv4/IPv6ネットワークのDNS遷移問題は、[DNSOPV6]で説明されています。
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.
この場合、ゲートウェイはデュアルスタックですが、ISPはデュアルスタックです。ゲートウェイはアップグレードされており、IPv4とIPv6の両方の接続性をホストに提供しています。ISPはまだISP接続を提供していないため、IPv6接続のISPに依存することはできません。
Application support in case C should be identical to that of case B.
ケースCがケースBと同一である必要がある場合のアプリケーションサポート
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:
アップグレードされたゲートウェイは、IPv6ルーターとして動作します。おそらくNATを使用して、IPv4接続を提供し続けます。ローカルネットワーク内のノードは取得します。
- IPv4 addresses (from or via the gateway), - IPv6 link local addresses, - IPv6 global addresses.
- IPv4アドレス（Gatewayからまたは介して）、-ipv6リンクローカルアドレス、-ipv6グローバルアドレス。
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.
IPv4のみのインフラストラクチャの上に即時のIPv6接続をもたらす方法は2つあります。たとえば、6to4テクノロジー[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.
ローカルホストが実際にグローバルIPv4アドレスを取得する場合があります。このシナリオは、移行テクノロジーの使用をより難しく、またはより複雑にしないため、このシナリオについては説明しません。ケースAは、ホストがIPv6接続を個別に取得する方法をすでに調べています。
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.
ケースCのローカルネーミング要件は、ケースBのローカルネーミング要件と同一であり、ドメイン名の委任と逆ルックアップクエリの管理という2つの違いがあります。
A delegation of some domain name is required in order to publish the IPv6 addresses of servers in the DNS.
DNS内のサーバーのIPv6アドレスを公開するには、一部のドメイン名の委任が必要です。
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.
Gatewayが6to4などの動的メカニズムを使用して、IPv6 ISPとは無関係にプレフィックスを取得する場合、逆ルックアップクエリを処理するための特定のメカニズムが必要です。
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.
この場合、ISPはIPv6のみであるため、ゲートウェイはIPv4接続を失い、IPv6のみのサービスプロバイダーに直面しています。ゲートウェイ自体はデュアルスタックであり、管理されていないネットワークにはIPv4のみ、IPv6のみ、デュアルスタックホストが含まれます。インターネット上の非管理ネットワークとIPv4ホストのホスト間の相互作用には、ISPによるいくつかのプロトコルサービスの提供が必要になります。
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.
遷移のこの段階では、IPv6ホストは他のIPv6ホストとのあらゆる種類のアプリケーションに参加できます。管理されていないネットワークのIPv4ホストは、IPv4またはデュアルスタックローカルホストを使用してローカルアプリケーションを実行できます。
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.
ケースBのように、IPv6のみのホストは、ローカルまたはリモートのIPv4のみのホストと対話しないと想定します。ただし、IPv4のみのホストとデュアルスタックホストは、インターネットで利用可能なIPv4サービスと対話することを望んでいると仮定する必要があります。そうすることができないと、IPv6のみのプロバイダーが他のインターネットサービスプロバイダーと比較して大きな商業不利益に配置されます。
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.
ISPは、IPv4アプリケーションへのアクセスを備えた管理されていないネットワーク内のホストを提供できる3つの方法があります。アプリケーションリレーのセットを使用して、アドレス翻訳サービスを提供すること、またはIPv4-over-IPV6トンネルを提供することにより。私たちの分析は、トンネルサービスが非常に望ましいと思われると結論付けています。
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.
ケースB：すべてのアプリケーションにリレーを提供し、これらのリレーのアドレスをホストにプロビジョニングする方法を開発し、アプリケーションを変更してそれらがのみを変更するために、アプリケーションゲートウェイアプローチの欠点について既に述べました。必要に応じてリレーを使用してください。また、IPv6のみのISPでは、アプリケーションリレーはIPv6でのみアクセスできるため、「レガシー」IPv4のみのホストからアクセスできないことがわかります。したがって、アプリケーションリレーアプローチはあまり魅力的ではありません。
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.
IPv6とIPv4の間でネットワークアドレスとプロトコル翻訳サービスを提供すると、多くの欠点もあります。ケースBと同様に、プロトコル内のIPアドレスへの参照を書き換える「アプリケーションレイヤーゲートウェイ」で補完する必要があります。ホストは、翻訳サービスを使用するためにパラメーター化する必要がある場合があり、DNSの問題を解決する必要があります。ネットワークレベルのプロトコル翻訳サービスはあまり望ましいとは思われません。
The preferable alternative to application relays and network address translation is the provision of an IPv4-over-IPv6 service.
アプリケーションリレーとネットワークアドレスの変換に代わる好ましい代替品は、IPv4-over-IPV6サービスの提供です。
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.
ISPは、IPv6プレフィックスを管理されていないネットワークに割り当てるため、ホストにはグローバルIPv6アドレスがあり、グローバルIPv6接続に使用します。これには、ケースCで調査されたように、IPv6アドレスプレフィックスの委任が必要です。
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.
IPv4ホストとデュアルスタックがリモートIPv4サービスへのアクセシビリティを有効にするには、ISPは、何らかの形のIPv4-over-IPV6トンネリングを使用して、少なくとも1つのIPv4アドレスをゲートウェイに提供する必要があります。そのようなアドレスが提供されると、ゲートウェイは効果的にデュアルスタック接続を取得します。管理されていないネットワーク内のホストの場合、これはケースBまたはCで得られたIPv4接続と区別できません。
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.
IPv4接続の損失は、命名サービスの提供に直接影響を与えます。多くのIPv4マネージネットワークでは、ホストは通常、DHCPサービスを通じてローカルゲートウェイからDNS構成パラメーターを取得します。ケースDで同じ動作モードが必要な場合、ゲートウェイはDNSリゾルバーのアドレスと他のDNSパラメーターでプロビジョニングする必要があり、このプロビジョニングはIPv6メカニズムを使用する必要があります。別の結果は、ゲートウェイ内のDNSサービスがIPv6接続を使用してクエリを解決できることです。ローカルホストがDNS解像度を自律的に実行すると、同じ制限があります。
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.
表面的には、これは、ローカルホストがAAAAレコードに文書化されたIPv6アドレスからドメインサーバーにアクセスできる場合にのみ名前を解決できることを示しているようです。ただし、DNSサービスは、「IPv6ホストがアクセスしたIPv4サーバー」の1つのケースにすぎません。IPv4接続サービスを介してクエリを送信して、IPv4のみのサーバーに到達することができるはずです。
The gateway should be able to act as a recursive DNS name server for the remaining IPv4 only hosts.
ゲートウェイは、残りのIPv4ホストのみの再帰DNS名サーバーとして機能することができるはずです。
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.
- ローカルアプリケーションがローカルでのみ使用されること - クライアントのプライバシーの保護 - ピアツーピア接続が認可されたピアによってのみ使用されるという要件 - IPv6アクセスに使用されるIPv4のトンネルプロトコルを安全に設計する要件使用 - トランジションシナリオをサポートするインフラストラクチャのサーバーが、乱用に対して脆弱ではないように設計されることを設計します。
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.
現在IPv4ネットワークで使用されているセキュリティソリューションには、ゲートウェイでのファイアウォール機能、アプリケーションの認証および認証機能、IPセキュリティ、輸送層のセキュリティおよびアプリケーション固有のサービス、およびホストベースのセキュリティ製品が提供する暗号化と認証サービスの組み合わせが含まれます。アンチウイルスソフトウェアやホストファイアウォールなど。IPv6の非管理ネットワークでのこれらのツールの適用性は、別のドキュメントで研究されます。
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.
この文書は、IETF V6OPSワーキンググループのメンバーのコメントと、Chris Fischer、Tony Hain、Kurt Erik Lindqvist、Erik Nordmark、Pekka Savola、Margaret Wassermanによる広範なレビューから恩恵を受けています。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[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.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、De Groot、G。J.およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年6月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3022] Srisuresh, P. and K. Egevang. "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang。「従来のIPネットワークアドレス翻訳者（従来のNAT）」、RFC 3022、2001年1月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、T。、「Natの建築的意味」、RFC 2993、2000年11月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten、T。およびR. Draves、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766] Tsirtsis、G。およびP. Srisuresh、「ネットワークアドレス翻訳 - プロトコル翻訳（NAT -PT）」、RFC 2766、2000年2月。
[DNSOPV6] Durand, A., Ihren, J. and P. Savola, "Operational Considerations and Issues with IPv6 DNS", Work in Progress.
[DNSOPV6] Durand、A.、Ihren、J。およびP. Savola、「IPv6 DNSの運用上の考慮事項と問題」は、進行中の作業。
[DNSINADDR] Senie, D., "Requiring DNS IN-ADDR Mapping", Work in Progress.
[Dnsinaddr] Senie、D。、「ADDR内マッピングを必要とする」、進行中の作業。
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
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
ロブオーストインインターネットシステムコンソーシアム950チャーターストリートレッドウッドシティ、カリフォルニア94063 USA
EMail: sra@isc.org
Suresh Satapati Cisco Systems, Inc. San Jose, CA 95134 USA
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
Ronald van der pol nlnet labs Kruislaan 419 1098 Va Amsterdam NL
EMail: Ronald.vanderPol@nlnetlabs.nl
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.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。
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.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78および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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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は、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。