Network Working Group M. Kaat
Request for Comments: 2956 SURFnet ExpertiseCentrum bv
Category: Informational October 2000
Overview of 1999 IAB Network Layer Workshop
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 (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet. Different technical scenarios for the (foreseeable) future and the impact of external influences were studied. This report lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.
この文書は、ユトレヒトにSURFNETが主催するインターネットネットワーク層アーキテクチャ上で、インターネットアーキテクチャ委員会（IAB）で開催されたワークショップの概要は、オランダで1999年7月7-9にワークショップの目標は、の状態を把握することでしたネットワーク層とインターネットの継続的な成長と使用への影響。 （予見）未来と外部の影響の影響のための様々な技術のシナリオを検討しました。このレポートは、インターネットエンジニアリングタスクフォース（IETF）コミュニティに結論と提言を示しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conclusions and Observations . . . . . . . . . . . . . . . 3
2.1 Transparency. . . . . . . . . . . . . . . . . . . . . . 3
2.2 NAT, Application Level Gateways & Firewalls . . . . . . 4
2.3 Identification and Addressing . . . . . . . . . . . . . 4
2.4 Observations on Address Space . . . . . . . . . . . . . 5
2.5 Routing Issues. . . . . . . . . . . . . . . . . . . . . 5
2.6 Observations on Mobility. . . . . . . . . . . . . . . . 6
2.7 DNS Issues. . . . . . . . . . . . . . . . . . . . . . . 7
2.8 NAT and RSIP. . . . . . . . . . . . . . . . . . . . . . 7
2.9 NAT, RSIP and IPv6. . . . . . . . . . . . . . . . . . . 8
2.10 Observations on IPv6. . . . . . . . . . . . . . . . . . 9
3. Recommendations. . . . . . . . . . . . . . . . . . . . . . 10
3.1 Recommendations on Namespace . . . . . . . . . . . . . . 10
3.2 Recommendations on RSIP. . . . . . . . . . . . . . . . . 10
3.3 Recommendations on IPv6. . . . . . . . . . . . . . . . . 10
3.4 Recommendations on IPsec . . . . . . . . . . . . . . . . 11
3.5 Recommendations on DNS . . . . . . . . . . . . . . . . . 11
3.6 Recommendations on Routing . . . . . . . . . . . . . . . 12
3.7 Recommendations on Application Layer and APIs. . . . . . 12
4. Security Considerations. . . . . . . . . . . . . . . . . . 12
References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Participants. . . . . . . . . . . . . . . . . . . 15
Author's Address. . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
From July 7 to July 9, 1999 the Internet Architecture Board (IAB) held a workshop on the architecture of the Internet Network Layer. The Network Layer is usually referred to as the IP layer. The goal of the workshop was to discuss the current state of the Network Layer and the impact various currently deployed or future mechanisms and technologies might have on the continued growth and usage of the Internet.
7月7日から1999年7月9日にインターネットアーキテクチャ委員会（IAB）はインターネットネットワーク層のアーキテクチャに関するワークショップを開催しました。ネットワーク層は、通常、IP層と呼ばれます。ワークショップの目標は、ネットワーク層の現在の状態を議論するためだったと衝撃の様々な現在展開や将来のメカニズムや技術は、インターネットの継続的な成長と使用上の必要がある場合があります。
The most important issues to be discussed were:
議論するために最も重要な問題は以下の通りでした。
o Status of IPv6 deployment and transition issues o Alternative technical strategies in case IPv6 is not adopted o Globally unique addresses and 32 bit address depletion o Global connectivity and reachability o Fragmentation of the Internet o End to end transparency and the progressive loss thereof o End to end security o Complications of address sharing mechanisms (NAT, RSIP) o Separation of identification and location in addressing o Architecture and scaling of the current routing system
O IPv6が透明性をエンドツーエンドoをインターネットのフラグメンテーションOグローバルコネクティビティおよび到達可能性oをグローバルに一意なアドレスと32ビットのアドレスの枯渇oを採用しない場合の代替技術戦略OのIPv6の展開と移行の問題の状況とEnd Oその進行性の喪失へOアーキテクチャに対処する識別および位置の分離現在のルーティングシステムのスケーリングOアドレス共有機構（NAT、RSIP）の合併症Oエンドセキュリティ
The participants looked into several technical scenarios and discussed the feasibility and probability of the deployment of each scenario. Among the scenarios were for example full migration to IPv6, IPv6 deployment only in certain segments of the network, no significant deployment of IPv6 and increased segmentation of the IPv4 address space due to the use of NAT devices.
参加者は、いくつかの技術的なシナリオに見て、各シナリオの展開の可能性と可能性を議論しました。シナリオのうちのIPv6のみのネットワークの特定のセグメントにおけるIPv6展開に例えば完全な移行のためのIPv6の有意な展開ではなかったとによるNATデバイスの使用にIPv4アドレス空間の分割を増加させました。
Based on the discussion of these scenarios several trends and external influences were identified which could have a large impact on the status of the network layer, such as the deployment of wireless network technologies, mobile networked devices and special purpose IP devices.
これらのシナリオの議論に基づいて、いくつかの傾向と外部の影響は、このような無線ネットワーク技術、モバイルネットワーク機器や特別な目的のIPデバイスの展開として、ネットワーク層の状態に大きな影響を与える可能性が同定されました。
The following technical issues were identified to be important goals:
以下のような技術的な問題は重要な目標であると同定されました：
o Deployment of end to end security o Deployment of end to end transport o Global connectivity and reachability should be maintained o It should be easy to deploy new applications o It should be easy to connect new hosts and networks to the Internet ("plug and ping")
（「プラグおよびpingインターネットに新しいホストとネットワークを接続するために簡単なはずですoを新しいアプリケーションをデプロイするために簡単なはず〇〇グローバルコネクティビティおよび到達可能性oを輸送し、エンドツーエンドの展開Oセキュリティをエンドツーエンドの展開は維持されるべきです「）
By the notion "deployment of end to end transport" it is meant that it is a goal to be able to deploy new applications that span from any host to any other host without intermediaries, and this requires transport protocols with similar span (see also [1]).
概念「輸送をエンドツーエンドの展開」とは、仲介せずに他のホストへの任意のホストからまたがる新しいアプリケーションを展開することができるようにする目標であり、これは同様のスパンでのトランスポートプロトコルが必要であることを意味している（も参照[ 1]）。
This document summarizes the conclusions and recommendations made by the workshop. It should be noted that not all participants agreed with all of the statements, and it was not clear whether anyone agreed with all of them. The recommendations made however are based on strong consensus among the participants.
この文書では、ワークショップで作られた結論と提言をまとめました。ないすべての参加者が文のすべてに同意したことに留意すべきで、誰もがそれらのすべてに同意するかどうかは明らかではなかったです。提言は、しかし、参加者の間で強いコンセンサスに基づいています。
The participants came to a number of conclusions and observations on several of the issues mentioned in section 1. In the following sections 2.1-2.10 these conclusions will be described.
参加者は、これらの結論を説明する以下のセクション2.1から2.10には、セクション1で述べた問題点のいくつかについての結論と観測値の数に来ました。
In the discussions transparency was referred to as the original Internet concept of a single universal logical addressing scheme and the mechanisms by which packets may flow from source to destination essentially unaltered [1]. This traditional end to end transparency has been lost in the current Internet, specifically the assumption that IPv4 addresses are globally unique or invariant is no longer true.
透明度は、単一のユニバーサル論理アドレッシング方式の元インターネットコンセプトとした議論とパケットがソースから宛先に流れることができるメカニズムが本質的に変化していない[1]。透明性を終了するには、この伝統的な終わりには、現在のインターネットではIPv4アドレスは、もはや真であるグローバルに一意または不変であることを、具体的な仮定を失ってきました。
There are multiple causes for the loss of transparency, for example the deployment of network address translation devices, the use of private addresses, firewalls and application level gateways, proxies and caches. These mechanisms increase fragmentation of the network layer, which causes problems for many applications on the Internet. It adds up to complexity in applications design and inhibits the deployment of new applications. In particular, it has a severe effect on the deployment of end to end IP security.
透明性の損失のための複数の原因は、ネットワークアドレス変換デバイスの展開、プライベートアドレス、ファイアウォールやアプリケーションレベルゲートウェイ、プロキシやキャッシュの使用は、たとえば、があります。これらのメカニズムは、インターネット上の多くのアプリケーションで問題が発生するネットワーク層の断片化を増加させます。これは、アプリケーションの設計に複雑につながりますし、新しいアプリケーションの展開を阻害します。特に、それは、IPセキュリティをエンドツーエンドの展開に重大な影響を持っています。
Another consequence of fragmentation is the deployment of "split DNS" or "two faced DNS", which means that the correspondence between a given FQDN and an IPv4 address is no longer universal and stable over long periods (see section 2.7).
断片化の別の結果は、所与のFQDNとIPv4アドレスとの対応関係がもはや長期間（セクション2.7を参照）上普遍的かつ安定であることを意味する「スプリットDNS」または「二直面DNS」の導入です。
End to end transparency will probably not be restored due to the fact that some of the mechanisms have an intrinsic value (e.g. firewalls, caches and proxies) and the loss of transparency may be considered by some as a security feature. It was however concluded that end to end transparency is desirable and an important issue to pursue. Transparency is further explored in [1].
透明性をエンドツーエンドはおそらく機構のいくつかは本質的価値（例えば、ファイアウォール、キャッシュおよびプロキシ）を有するという事実に復元されず、透明性の損失は、セキュリティ機能として、いくつかによって考慮されてもよいです。しかしながら、透明性をエンド・ツー・エンドが望ましいと追求する重要な課題であると結論づけられました。透明度は、さらに[1]で検討されています。
The previous section indicated that the deployment of NAT (Network Address Translation), Application Level Gateways and firewalls causes loss of network transparency. Each of them is incompatible with certain applications because they interfere with the assumption of end to end transparency. NAT especially complicates setting up servers, peer to peer communications and "always-on" hosts as the endpoint identifiers, i.e. IP addresses, used to set up connections are globally ambiguous and not stable (see [2]).
前のセクションでは、NAT（ネットワークアドレス変換）の展開は、アプリケーションレベルゲートウェイとファイアウォールは、ネットワークの透明性の損失の原因となることが示されました。彼らは透明性をエンドツーエンドの仮定を妨げるので、それらのそれぞれは、特定のアプリケーションとの互換性がありません。 NATは、特にサーバをセットアップする複雑、通信及びピアツーピア「常時オン」接続を設定するために使用されるエンドポイント識別子、すなわち、IPアドレス、等のホストが安定グローバル曖昧とされない（参照[2]）。
NAT, application level gateways and firewalls however are being increasingly widely deployed as there are also advantages to each, either real or perceived. Increased deployment causes a further decline of network transparency and this inhibits the deployment of new applications. Many new applications will require specialized Application Level Gateways (ALGs) to be added to NAT devices, before those applications will work correctly when running through a NAT device. However, some applications cannot operate effectively with NAT even with an ALG.
NAT、実際の又は知覚されるいずれかのそれぞれに利点が、また、存在するとしてますます広く展開されているが、アプリケーション・レベル・ゲートウェイおよびファイアウォール。増加の展開は、ネットワークの透明性のさらなる低下を引き起こし、これは、新しいアプリケーションの展開を阻害します。多くの新しいアプリケーションは、NATデバイスを介して実行している場合、それらのアプリケーションが正常に動作する前に、特殊なアプリケーションレベルゲートウェイ（のALG）は、NATデバイスに追加する必要があります。ただし、一部のアプリケーションでもALGとNATを効果的に動作することはできません。
In the original IPv4 network architecture hosts are globally, permanently and uniquely identified by an IPv4 address. Such an IP address is used for identification of the node as well as for locating the node on the network. IPv4 in fact mingles the semantics of node identity with the mechanism used to deliver packets to the node. The deployment of mechanisms that separate the network into multiple address spaces breaks the assumption that a host can be uniquely identified by a single IP address. Besides that, hosts may wish to move to a different location in the network but keep their identity the same. The lack of differentiation between the identity and the location of a host leads to a number of problems in the current architecture.
元のIPv4ネットワークアーキテクチャのホストがグローバルに、恒久的に一意のIPv4アドレスによって識別されます。そのようなIPアドレスは、ノードの識別のために、並びにネットワーク上のノードの位置を特定するために使用されます。実際にはIPv4のノードにパケットを配信するために使用されるメカニズムとノードIDのセマンティクスを混ざっ。複数のアドレス空間にネットワークを分離する機構の配置は、ホストが一意に単一のIPアドレスによって識別することができるという仮定を破ります。それに加えて、ホストは、ネットワーク内の別の場所に移動するが、同じ自分のアイデンティティを維持することを望むかもしれません。アイデンティティとホストの位置との間の分化の欠如は現在のアーキテクチャにおける多くの問題につながります。
Several technologies at this moment use tunneling techniques to overcome the problem or cannot be deployed in the case of separate address spaces. If a node could have some sort of a unique identifier or endpoint name this would help in solving a number of problems.
この時点で、いくつかの技術が問題を克服するために、トンネリング技術を使用するか、別のアドレス空間の場合に展開することはできません。ノードは、一意の識別子またはエンドポイントの名前のいくつかの並べ替えを持っていることができれば、この問題の数を解決する上で役立つだろう。
It was concluded that it may be desirable on theoretical grounds to separate the node identity from the node locator. This is especially true for IPsec, since IP addresses are used (in transport mode) as identifiers which are cryptographically protected and hence MUST remain unchanged during transport. However, such a separation of identity and location will not be available as a near-term solution, and will probably require changes to transport level protocols. However, the current specification of IPsec does allow to use some other identifier than an IP address.
それは、ノードロケータからノードIDを分離するために理論的な根拠に基づいて望ましいかもしれないと結論付けられました。 IPアドレスが暗号で保護され、したがって、輸送中に変化しないままでなければなりません識別子として（トランスポート・モードで）使用されているので、これは、IPsecのために特に当てはまります。しかし、アイデンティティと場所のような分離は、短期的なソリューションとして使用できません、おそらくレベルのプロトコルを輸送するために変更が必要になります。しかし、IPsecの現在の仕様では、IPアドレスではいくつかの他の識別子を使用することができません。
There is a significant risk that a single 32 bit global address space is insufficient for foreseeable needs or desires. The participants' opinions about the time scale over which new IPv4 addresses will still be available for assignment ranged from 2 to 20 years. However, there is no doubt that at the present time, users cannot obtain as much IPv4 address space as they desire. This is partly a result of the current stewardship policies of the Regional Internet Registries (RIRs).
単一の32ビットのグローバルアドレス空間が予見可能なニーズや欲望のために不十分であるという重大なリスクがあります。新しいIPv4のアドレスはまだ割り当てに利用できるようにする時間スケールについての参加者の意見は2年から20年の範囲でした。しかし、彼らが望むよう現時点で、ユーザーが同じくらいのIPv4アドレス空間を得ることができないことは間違いありません。これは、一部の地域インターネットレジストリ（RIRが）の現在のスチュワードシップ政策の結果です。
It was concluded that it ought to be possible for anybody to have global addresses when required or desired. The absence of this inhibits the deployment of some types of applications. It should however be noted that there will always be administrative boundaries, firewalls and intranets, because of the need for security and the implementation of policies. NAT is seen as a significant complication on these boundaries. It is often perceived as a security feature because people are confusing NATs with firewalls.
それが必要か、必要なときに誰もがグローバルアドレスを持っているために可能であるべきと結論されました。これがない場合は、アプリケーションのいくつかの種類の展開を阻害します。しかし常にあるため、セキュリティの必要性と政策の実施により、管理境界、ファイアウォールやイントラネットがあるであろうことに留意すべきです。 NATは、これらの境界上の重大な合併症として見られています。人々はファイアウォールとNATのを混乱しているので、それは多くの場合、セキュリティ機能として知覚されます。
A number of concerns were raised regarding the scaling of the current routing system. With current technology, the number of prefixes that can be used is limited by the time taken for the routing algorithm to converge, rather than by memory size, lookup time, or some other factor. The limit is unknown, but there is some speculation, of extremely unclear validity, that it is on the order of a few hundred thousand prefixes. Besides the computational load of calculating routing tables, the time it takes to distribute routing updates across the network, the robustness and security of the current routing system are also important issues. The only known addressing scheme which produces scalable routing mechanisms depends on topologically aggregated addresses, which requires that sites renumber when their position in the global topology changes. Renumbering remains operationally difficult and expensive ([3], [4]). It is not clear whether the deployment of IPv6 would solve the current routing problems, but it should do so if it makes renumbering easier.
懸念の数は、現在のルーティングシステムのスケーリングに関して提起されました。現在の技術で、使用することができるプレフィクスの数が収束するルーティングアルゴリズムに要する時間だけではなく、メモリサイズ、検索時間、またはいくつかの他の要因によって制限されます。上限は不明であるが、それは千数百プレフィックスのオーダーであることが極めて不明確妥当性のいくつかの憶測は、そこにあります。ルーティングテーブルを計算する計算負荷のほかに、それはネットワーク経由でルーティングアップデートを配布するのにかかる時間は、現在のルーティングシステムの堅牢性とセキュリティも重要な課題です。スケーラブルなルーティングメカニズムを生産する唯一の既知のアドレス指定方式は、ときに、グローバルトポロジの変更で自分の位置のサイトが番号を付け直すことを必要とする、位相幾何学的に集約されたアドレスに依存します。リナンバリングは、操作上困難であり、高価なままである（[3]、[4]）。 IPv6の展開が現在のルーティングの問題を解決するだろうが、それは簡単にリナンバリング行う場合、それはそうすべきかどうかは明らかではありません。
At least one backbone operator has concerns about the convergence time of internetwork-wide routing during a failover. This operator believes that current convergence times are on the order of half a minute, and possibly getting worse. Others in the routing community did not believe that the convergence times are a current issue. Some, who believe that real-time applications (e.g. telephony) require sub-second convergence, are concerned about the implications of convergence times of a half minute on such applications.
少なくとも一つのバックボーンオペレータは、フェイルオーバー時のインターネット全体のルーティングの収束時間を懸念します。この演算子は、現在の収束時間が分半程度であると考えて、そしておそらく悪化します。ルーティングコミュニティの他のものは、収束時間が現在の問題であることを信じていませんでした。リアルタイムアプリケーション（例えば、電話）は、サブセカンド・コンバージェンスを必要とすることを信じるいくつかは、そのようなアプリケーションの半分分の収束時間の影響について懸念しています。
Further research is needed on routing mechanisms that might help palliate the current entropy in the routing tables, and can help reduce the convergence time of routing computations.
さらなる研究がルーティングテーブルに現在のエントロピーを緩和に役立つかもしれない、とルーティング計算の収束時間を短縮することができますルーティングメカニズムに必要とされています。
The workshop discussed global routing in a hypothetical scenario with no distinguished root global address space. Nobody had an idea how to make such a system work. There is currently no well-defined proposal for a new routing system that could solve such a problem.
ワークショップではない区別ルートグローバルアドレス空間と仮想的なシナリオでは、グローバルルーティングについて議論しました。誰がどのようなシステムを機能させるために考えていました。このような問題を解決できる新しいルーティングシステムのための無明確に定義された提案は現在あり。
For IPv6 routing in particular, the GSE/8+8 proposal and IPNG WG analysis of this proposal ([5]) are still being examined by the IESG. There is no consensus in the workshop whether this proposal could be made deployable.
特にIPv6ルーティングのために、この提案のGSE / 8 + 8提案とIPNG WG分析（[5]）依然としてIESGによって検討されています。この提案は、展開作ることができるかどうかのワークショップにはコンセンサスがありません。
Mobility and roaming require a globally unique identifier. This does not have to be an IP address. Mobile nodes must have a widely usable identifier for their location on the network, which is an issue if private IP addresses are used or the IP address is ambiguous (see also section 2.3). Currently tunnels are used to route traffic to a mobile node. Another option would be to maintain state information at intermediate points in the network if changes are made to the packets. This however reduces the flexibility and it breaks the end to end model of the network. Keeping state in the network is usually considered a bad thing. Tunnels on the other hand reduce the MTU size. Mobility was not discussed in detail as a separate IAB workshop is planned on this topic.
モビリティとローミングはグローバル一意識別子が必要です。これは、IPアドレスである必要はありません。モバイルノードがプライベートIPアドレスが使用されるか、またはIPアドレスが曖昧である場合に問題であるネットワーク上の位置、に広く使用可能な識別子を有していなければならない（また、セクション2.3を参照）。現在、トンネルは、モバイルノードにトラフィックをルーティングするために使用されています。別のオプションは、変更がパケットに行われた場合、ネットワーク内の中間点での状態情報を維持するであろう。しかし、これは柔軟性を低減し、それがネットワークのモデルをエンドツーエンドを破ります。ネットワークの状態を維持することは、通常は悪いことと考えられています。一方、トンネルは、MTUサイズを減らします。別のIABワークショップは、このトピックに予定されているようモビリティを詳細に議論されていませんでした。
If IPv6 is widely deployed, the current line of thinking is that site renumbering will be significantly more frequent than today. This will have an impact on DNS updates. It is not clear what the scale of DNS updates might be, but in the most aggressive models it could be millions a day. Deployment of the A6 record type which is defined to map a domain name to an IPv6 address, with the provision for indirection for leading prefix bits, could make this possible ([6]).
IPv6が広く展開されている場合は、思考の現在の行には、そのサイトのリナンバリングは今日よりはるかに頻繁になりますです。これは、DNSの更新に影響を与えます。 DNSアップデートの規模が何であるか明確ではないが、最も積極的なモデルでは、何百万人の日である可能性があります。主要プレフィックスビットに対する間接のための準備と、IPv6アドレスにドメイン名をマップするように定義されたA6レコードタイプの展開、これを可能にすることができた（[6]）。
Another issue is the security aspect of frequent updates, as they would have to been done dynamically. Unless we have fully secured DNS, it could increase security risks. Cached TTL values might introduce problems as the cached records of renumbered hosts will not be updated in time. This will become especially a problem if rapid renumbering is needed.
もう一つの問題は、彼らが動的に行われなければならないだろうと、頻繁に更新のセキュリティ面です。我々は完全にDNSを確保していない限り、それはセキュリティ上のリスクを増加させる可能性があります。番号が付け直さホストのキャッシュされたレコードが時間内に更新されないようにキャッシュされたTTL値は問題を引き起こす可能性があります。急速なリナンバリングが必要な場合、これは特に問題になるだろう。
Another already mentioned issue is the deployment of split DNS (see section 2.1). This concept is widely used in the Intranet model, where the DNS provides different information to inside and outside queries. This does not necessarily depend on whether private addresses are used on the inside, as firewalls and policies may also make this desirable. The use of split DNS seems inevitable as Intranets will remain widely deployed. But operating a split DNS raises a lot of management and administrative issues. As a work around, a DNS Application Level Gateway ([7]) (perhaps as an extension to a NAT device) may be deployed, which intercepts DNS messages and modifies the contents to provide the appropriate answers. This has the disadvantage that it interferes with the use of DNSSEC ([8]).
もうすでに言及した問題は、スプリットDNSの展開である（2.1節を参照してください）。この概念は、広くDNSは、内部及び外部クエリに異なる情報を提供するイントラネットモデルで使用されています。ファイアウォールや政策も、これは望ましいことがあり、これは必ずしも、プライベートアドレスが内部で使用されているかどうかには依存しません。イントラネットは広く展開されたままになりますよう、スプリットDNSを使用することは避けられないようです。しかし、スプリットDNSを操作することは経営と管理上の問題の多くを発生させます。回避策として、DNSアプリケーションレベルゲートウェイ（[7]）（おそらくNATデバイスの拡張など）がDNSメッセージをインターセプトし、適切な回答を提供するために、内容を変更した、展開されてもよいです。これは、DNSSEC（[8]）の使用を妨害するという欠点を有します。
The deployment of split DNS, or more generally the existence of separate name spaces, makes the use of Fully Qualified Domain Names (FQDNs) as endpoint identifiers more complex.
スプリットDNS、またはより一般的には別の名前空間の存在の展開は、エンドポイント識別子として完全修飾ドメイン名（FQDN）の使用がより複雑になります。
Realm-Specific IP (RSIP), a mechanism for use with IPv4, is a work item of the IETF NAT WG. It is intended as an alternative (or as a complement) to network address translation (NAT) for IPv4, but other uses are possible (for example, allowing end to end traffic across firewalls). It is similar to NAT, in that it allows sharing a small number of external IPv4 addresses among a number of hosts in a local address domain (called a 'realm'). However, it differs from NAT in that the hosts know that different externally-visible IPv4 addresses are being used to refer to them outside their local realm, and they know what their temporary external address is. The addresses and other information are obtained from an RSIP server, and the packets are tunneled across the first routing realm ([9], [10]).
レルム固有のIP（RSIP）はIPv4で使用するための機構は、IETF NAT WGのワークアイテムです。これは、IPv4のネットワークアドレス変換（NAT）の代替（または補体など）のようなものではなく、他の用途には、（端部がファイアウォールを介したトラフィックを終了させる、など）が可能であるています。それは（「レルム」と呼ばれる）ローカルアドレスドメイン内のホストの数のうち、外部のIPv4アドレスの小さな数を共有できるように、それは、NATと同様です。しかし、それはホストが異なる外部に見えるIPv4アドレスがローカル領域外でそれらを参照するために使用されていることを知っていることでNATとは異なり、彼らは一時的な外部アドレスが何であるかを知っています。アドレスおよび他の情報は、RSIPサーバから取得され、パケットは、第1のルーティング領域でトンネリングされている（[9]、[10]）。
The difference between NAT and RSIP - that an RSIP client is aware of the fact that it uses an IP address from another address space, while with NAT, neither endpoint is aware that the addresses in the packets are being translated - is significant. Unlike NAT, RSIP has the potential to work with protocols that require IP addresses to remain unmodified between the source and destination. For example, whereas NAT gateways preclude the use of IPsec across them, RSIP servers can allow it [11].
NATとRSIPの違い - RSIPクライアントがNATで、どちらのエンドポイントは、パケット内のアドレスが変換されていることを認識していながら、それは、別のアドレス空間からIPアドレスを使用するという事実を認識していることは - 重要です。 NATとは異なり、RSIPは、IPは、送信元と宛先の間に未修正のままにアドレスを必要とするプロトコルで動作する可能性があります。例えば、NATゲートウェイはそれら間のIPsecの使用を排除する一方で、RSIPサーバは、[11]を許可することができます。
The addition of RSIP to NATs may allow them to support some applications that cannot work with traditional NAT ([12]), but it does require that hosts be modified to act as RSIP clients. It requires changes to the host's TCP/IP stack, any layer-three protocol that needs to be made RSIP-aware will have to be modified (e.g. ICMP) and certain applications may have to be changed. The exact changes needed to host or application software are not quite well known at this moment and further research into RSIP is required.
NATのにRSIPの添加は、彼らが伝統的なNAT（[12]）で動作しないことができるいくつかのアプリケーションをサポートすることを可能にするが、それはホストがRSIPクライアントとして動作するように変更する必要がありません。それはRSIP-認識される必要がある任意のレイヤ3プロトコルを修正しなければならない（例えばICMP）と、特定のアプリケーションを変更する必要がある可能性があり、ホストのTCP / IPスタックへの変更を必要とします。ホストまたはアプリケーションソフトウェアのに必要な正確な変更は、非常によくこの時点で知られていないとRSIPにさらなる研究が必要です。
Both NAT and RSIP assume that the Internet retains a core of global address space with a coherent DNS. There is no fully prepared model for NAT or RSIP without such a core; therefore NAT and RSIP face an uncertain future whenever the IPv4 address space is finally exhausted (see section 2.4). Thus it is also a widely held view that in the longer term the complications caused by the lack of globally unique addresses, in both NAT and RSIP, might be a serious handicap ([1]).
NATとRSIPはどちらもインターネットがコヒーレントDNSでグローバルアドレス空間のコアを保持することを前提としています。 NATまたはRSIPには万全モデルは、コアなしではありません。 IPv4アドレス空間が最終的に排出されるたびので、NATとRSIPは、不確実な将来に直面している（2.4節を参照してください）。したがって、長期的にはグローバルに一意なアドレスの不足に起因する合併症は、NATとRSIPの両方に、深刻なハンディキャップ（[1]）であるかもしれないこと。また、広く支持されている図であります
If optimistic assumptions are made about RSIP (it is still being defined and a number of features have not been implemented yet), the combination of NAT and RSIP seems to work in most cases. Whether RSIP introduces specific new problems, as well as removing some of the NAT issues, remains to be determined.
楽観的な仮定がRSIP（それがまだ定義されていると機能の数はまだ実装されていない）について行われている場合、NATとRSIPの組み合わせが、ほとんどの場合で動作するようです。 RSIPは、NAT問題のいくつかを削除し、特定の新たな問題を紹介するだけでなく、かどうかは、まだ決定されていません。
Both NAT and RSIP may have trouble with the future killer application, especially when this needs QoS features, security and/or multicast. And if it needs peer to peer communication (i.e. there would be no clear distinction between a server and a client) or assumes "always-on" systems, this would probably be complex with both NAT and RSIP (see also section 2.2).
NATとRSIPの両方が、これはQoS機能、セキュリティ、および/またはマルチキャストを必要とする場合は特に、将来のキラーアプリケーションに問題があることがあります。それがコミュニケーションをピア・ツー・ピアを必要とする（すなわち、サーバとクライアントの間には明確な区別はないだろう）、またはシステム「常時オン」を前提とした場合と、これはおそらく、NATとRSIP（もセクション2.2を参照）の両方に複雑になります。
Assuming IPv6 is going to be widely deployed, network address translation techniques could play an important role in the transition process from IPv4 to IPv6 ([13]). The impact of adding RSIP support
IPv6が広く展開されようとしていると仮定すると、ネットワークアドレス変換技術は、IPv4からIPv6への移行の過程で重要な役割を果たしている可能性があり（[13]）。 RSIPサポートを追加することの影響
to hosts is not quite clear at this moment, but it is less than adding IPv6 support since most applications probably don't need to be changed. And RSIP needs no changes to the routing infrastructure, but techniques such as automatic tunneling ([14]) and 6to4 ([15]) would also allow IPv6 traffic to be passed over the existing IPv4 routing infrastructure. While RSIP is principally a tool for extending the life of IPv4, it is not a roadblock for the transition to IPv6. The development of RSIP is behind that of IPv6, and more study into RSIP is required to determine what the issues with RSIP might be.
ホストにこの時点で非常に明確ではないですが、それはほとんどのアプリケーションは、おそらく変更する必要はありませんので、IPv6のサポートを追加するよりも少ないです。そしてRSIPは、ルーティングインフラストラクチャへの変更を必要としない、そのような自動トンネリング（[14]）との6to4（[15]）のような技術はまた、IPv6トラフィックは、既存のIPv4ルーティングインフラストラクチャ上を通過することを可能にします。 RSIPは、主のIPv4の寿命を延ばすためのツールですが、それは、IPv6への移行のためのバリケードではありません。 RSIPの開発は、IPv6の背後にある、とRSIPへのより多くの研究がRSIPの問題が何であるかを判断するために必要とされます。
An important issue in the workshop was whether the deployment of IPv6 is feasible and probable. It was concluded that the transition to IPv6 is plausible modulo certain issues. For example applications need to be ported to IPv6, and production protocol stacks and production IPv6 routers should be released. The core protocols are finished, but other standards need to be pushed forward (e.g. MIBs). A search through all RFCs for dependencies on IPv4 should be made, as was done for the Y2K problem, and if problems are found they must be resolved. As there are serious costs in implementing IPv6 code, good business arguments are needed to promote IPv6.
ワークショップでの重要な問題は、IPv6の展開が可能と考えられるかどうかということでした。これは、IPv6への移行は、もっともらしいモジュロ特定の問題であると結論しました。例えば、アプリケーションは、IPv6に移植する必要があり、生産プロトコルスタックと生産IPv6ルータは解放されなければなりません。コアプロトコルは終了するが、他の規格（例えばMIBの）前方にプッシュする必要があります。 Y2K問題のために行ったようにIPv4の上の依存関係のためにすべてのRFCによる検索は、なされるべきである、との問題が発見された場合、それらを解決する必要があります。 IPv6のコードを実装するに重大なコストがあるので、良いビジネスの引数は、IPv6を推進するために必要とされます。
One important question was whether IPv6 could help solve the current problems in the routing system and make the Internet scale better. It was concluded that "automatic" renumbering is really important when prefixes are to be changed periodically to get the addressing topology and routing optimized. This also means that any IP layer and configuration dependencies in protocols and applications will have to be removed ([3]). One example that was mentioned is the use of IP addresses in the PKI (IKE). There might also be security issues with "automatic" renumbering as DNS records have to be updated dynamically (see also section 2.7).
一つの重要な問題は、IPv6がルーティングシステムの現在の問題を解決し、より良いインターネットの規模を作ることができるかどうかでした。これは、接頭辞が最適化されたアドレッシングトポロジとルーティングを取得するために定期的に変更する場合、「自動」リナンバリングは本当に重要であると結論づけられました。これはまた、任意のIP層とプロトコルおよびアプリケーションで構成依存関係が除去されなければならないことを意味する（[3]）。上述した一例では、PKI（IKE）でIPアドレスを使用することです。 DNSレコードを動的に更新する必要があるとしても、「自動」リナンバリングとセキュリティ上の問題があるかもしれません（また、セクション2.7を参照してください）。
Realistically, because of the dependencies mentioned, IPv6 renumbering cannot be truly automatic or instantaneous, but it has the potential to be much simpler operationally than IPv4 renumbering, and this is critical to market and ISP acceptance of IPv6.
現実的には、理由は述べた依存関係のため、IPv6のリナンバリングは本当に自動または瞬時することはできませんが、それは、IPv4リナンバリングよりもはるかに簡単操作的になる可能性があり、これは市場とIPv6のISP受け入れに重要です。
Another issue is whether existing TCP connections (using the old address(es)) should be maintained across renumbering. This would make things much more complex and it is foreseen that old and new addresses would normally overlap for a long time.
もう一つの問題は、（旧アドレス（複数可）を使用して）既存のTCP接続がリナンバリング渡って維持する必要があるかどうかです。これは、はるかに複雑なものになるだろうし、古いものと新しいアドレスは、通常、長い時間のために重複するであろうと予想されます。
There was no consensus on how often renumbering would take place or how automatic it can be in practice; there is not much experience with renumbering (maybe only for small sites).
リナンバリングが行わだろうか、それが実際に可能か自動頻度にはコンセンサスがありませんでした。 （小規模なサイトの多分のみ）リナンバリングで多くの経験がありません。
The workshop recommends the IAB to appoint a panel to make specific recommendations to the IETF about:
ワークショップは、IETF程度に具体的な提言を行うために、パネルを任命するIABをお勧めします。
i) whether we should encourage more parts of the stack to adopt a
namespace for end to end interactions, so that a) NAT works
'better', and b) we have a little more independence between the
internetwork and transport and above layers;
ii) if so, whether we should have a single system-wide namespace
for this function, or whether it makes more sense to allow
various subsystems to chose the namespace that makes sense for
them;
iii) and also, what namespace(s) [depending on the output of the
point above] that ought to be.
RSIP is an interesting idea, but it needs further refinement and study. It does not break the end to end network model in the same way as NAT, because an RSIP host has explicit knowledge of its temporary global address. Therefore, RSIP could solve some of the issues with NAT. However, it is premature to recommend it as a mainstream direction at this time.
RSIPは面白いアイデアですが、それはさらなる改良と研究が必要です。 RSIPホストが一時グローバルアドレスの明示的な知識を持っているので、NATと同じようにネットワークモデルを端から端まで中断されません。したがって、RSIPは、NATの問題の一部を解決することができます。しかし、現時点で主流の方向として、それをお勧めするのは時期尚早です。
It is recommended that the IETF should actively work on RSIP, develop the details and study the issues.
IETFが積極的に、RSIPで作業内容を開発し、問題点を検討する必要があることをお勧めします。
3.3.1 The current model of TLA-based addressing and routing should be actively pursued. However, straightforward site renumbering using TLA addresses is really needed, should be as nearly automatic as possible, and should be shown to be real and credible by the IPv6 community.
TLAベースのアドレッシングおよびルーティングの現在のモデルは、積極的に追求されるべきである3.3.1。しかし、TLAアドレスを使用してリナンバリング簡単なサイトが本当に必要とされ、可能な限りほぼ自動であるべきであり、IPv6のコミュニティによって現実と信憑性のあることが示されなければなりません。
3.3.2 Network address translation techniques, in addition to their immediate use in pure IPv4 environments, should also be viewed as part of the starting point for migration to IPv6. Also RSIP, if successful, can be a starting point for IPv6 transition.
3.3.2ネットワークアドレス変換技術は、純粋のIPv4環境での彼らの即時の使用に加えて、IPv6への移行のための出発点の一部として表示する必要があります。またRSIPは、成功した場合は、IPv6への移行のための出発点となることができます。
While the basic concepts of the IPv4 specific mechanisms NAT and RSIP are also being used in elements of the proposed migration path to IPv6 (in NAT-PT for NAT, and SIIT and AIIH for RSIP), NAT and RSIP for IPv4 are not directly part of a documented transition path to IPv6.
IPv4の特定のメカニズムNATとRSIPの基本的な概念はまた、IPv6への提案された移動経路の要素に使用されている間に、IPv4のNATとRSIP（NAT用のNAT-PT、およびRSIPためSIITとAIIHに）直接含まれていませんIPv6へ文書遷移パスの。
The exact implications, for transition to IPv6, of having NAT and RSIP for IPv4 deployed, are not well understood. Strategies for transition to IPv6, for use in IPv4 domains using NAT and RSIP for IPv4, should be worked out and documented by the IETF.
IPv6への移行のための正確な意味は、展開IPv4のNATとRSIPを有することが、よく理解されていません。 IPv6への移行のための戦略は、IPv4の使用は、IPv4のNATとRSIPを使用してドメインに対して、働いおよびIETFによって文書化されるべきです。
3.3.3 The draft analysis of the 8+8/GSE proposal should be evaluated by the IESG and accepted or rejected, without disturbing ongoing IPv6 deployment work. The IESG should use broad expertise, including liaison with the endpoint namespace panel (see section 3.1) in their evaluation.
8 + 8 / GSE案の草案3.3.3解析は現在進行中のIPv6導入作業を妨げることなく、IESGによって評価し、承認または拒否されなければなりません。 IESGは、彼らの評価では、エンドポイントの名前空間パネル（セクション3.1を参照）との連携を含め、幅広い専門知識を使用する必要があります。
It is urgent that we implement and deploy IPsec using some other identifier than 32-bit IP addresses (see section 2.3). The current IPsec specifications support the use of several different Identity types (e.g. Domain Name, User@Domain Name). The IETF should promote implementation and deployment of non-address Identities with IPsec. We strongly urge the IETF to completely deprecate the use of the binary 32-bit IP addresses within IPsec, except in certain very limited circumstances, such as router to router tunnels; in particular any IP address dependencies should be eliminated from ISAKMP and IKE.
我々が32ビットのIPアドレス（セクション2.3を参照）よりも、いくつかの他の識別子を使用してIPsecを実装し、展開することが急務です。現在のIPsec仕様は、いくつかの異なるアイデンティティの種類（例えばドメイン名、ドメイン名@ユーザー）の使用をサポートしています。 IETFは、IPsecと非アドレスアイデンティティの実装と展開を促進すべきです。我々は強く完全にそのようなトンネルをルータにルータなどの特定の非常に限られた状況を除いて、IPsecの内のバイナリ32ビットのIPアドレスの使用を廃止するためにIETFを促します。特に、任意のIPアドレスの依存関係は、ISAKMPとIKEから排除されなければなりません。
Ubiquitous deployment of the Secure DNS Extensions ([8]) should be strongly encouraged to facilitate widespread deployment of IPsec (including IKE) without address-based Identity types.
セキュアなDNSの拡張機能（[8]）のユビキタス展開が強くアドレスベースのアイデンティティのタイプなし（IKEを含む）のIPsecの広範な展開を促進するために奨励されるべきです。
Operational stability of DNS is paramount, especially during a transition of the network layer, and both IPv6 and some network address translation techniques place a heavier burden on DNS. It is therefore recommended to the IETF that, except for those changes that are already in progress and will support easier renumbering of networks and improved security, no fundamental changes or additions to the DNS be made for the foreseeable future.
DNSの動作安定性は、特にネットワーク層の遷移中に、最も重要である、とIPv6および一部のネットワークアドレス変換技術の両方がDNSに重い負担をかけます。したがって、すでに進行中であり、ネットワークやセキュリティの向上を簡単に再番号付けをサポートするそれらの変更を除き、DNSへの根本的な変更や追加が予見可能な将来のために作られていないことが、IETFにお勧めします。
In order to encourage widespread deployment of IPsec, rapid deployment of DNSSEC is recommended to the operational community.
IPsecのの広範な展開を促進するためには、DNSSECの迅速な展開を運用コミュニティにお勧めします。
The only known addressing scheme which produces scalable routing mechanisms depends on topologically aggregated addresses, which requires that sites renumber when their position in the global topology changes. Thus recommendation 3.3.1 is vital for routing IPv6.
スケーラブルなルーティングメカニズムを生産する唯一の既知のアドレス指定方式は、ときに、グローバルトポロジの変更で自分の位置のサイトが番号を付け直すことを必要とする、位相幾何学的に集約されたアドレスに依存します。このよう勧告3.3.1は、IPv6のルーティングのために不可欠です。
Although the same argument applies to IPv4, the installed base is simply too large and the PIER working group showed that little can be done to improve renumbering procedures for IPv4. However, NAT and/or RSIP may help.
同じ引数がIPv4に適用されるが、インストールベースは、単に大きすぎると埠頭ワーキンググループは、ほとんどがIPv4の番号を付け替える手続きを改善するために行うことができることを示しました。しかし、NATおよび/またはRSIPは助けることがあります。
In the absence of a new addressing model to replace topological aggregation, and of clear and substantial demand from the user community for a new routing architecture (i.e. path-selection mechanism) there is no reason to start work on standards for a "next generation" routing system in the IETF. Therefore, we recommend that work should continue in the IRTF Routing Research Group.
トポロジカル集約に代わる新たなアドレッシングモデルの、そして新しいルーティングアーキテクチャのユーザーコミュニティから明確かつ実質的な需要（すなわち、パス選択機構）がない場合には、「次の世代」のための標準化の作業を開始する理由はありませんIETFでのルーティングシステム。したがって、我々は仕事がIRTFのルーティング研究グループで継続することをお勧めします。
Most current APIs such as sockets are an obstacle to migration to a new network layer of any kind, since they expose network layer internal details such as addresses.
彼らはそのようなアドレスなどのネットワーク層内部の詳細を公開するので、このようなソケットなどの最新のAPIは、あらゆる種類の新しいネットワーク層への移行への障害です。
It is therefore recommended, as originally recommended in RFC 1900 [3], that IETF protocols, and third-party applications, avoid any explicit awareness of IP addresses, when efficient operation of the protocol or application is feasible in the absence of such awareness. Some applications and services may continue to need to be aware of IP addresses. Until we once again have a uniform address space for the Internet, such applications and services will necessarily have limited deployability, and/or require ALG support in NATs.
元々RFC 1900年に推奨されているようにプロトコルまたはアプリケーションの効率的な動作は、このような意識が存在しない場合に可能である場合したがって、IETFプロトコル、およびサードパーティのアプリケーションは、IPアドレスの明示的な認識を避けること、[3]、推奨されます。一部のアプリケーションやサービスは、IPアドレスを認識する必要がありますし続けることができます。私たちは再び、インターネットのための均一なアドレス空間を持つまでは、このようなアプリケーションやサービスは、必ずしも限定された展開性を持ち、かつ/またはNATの中ALGのサポートが必要になります。
Also we recommend an effort in the IETF to generalize APIs to offer abstraction from all network layer dependencies, perhaps as a side-effect of the namespace study of section 3.1.
また、我々は、おそらくセクション3.1の名前空間の研究の副作用として、すべてのネットワーク層の依存関係から抽象化を提供するためのAPIを一般化するIETFでの努力をお勧めします。
The workshop did not address security as a separate topic, but the role of firewalls, and the desirability of end to end deployment of IPsec, were underlying assumptions. Specific recommendations on security are covered in sections 3.4 and 3.5.
ワークショップでは、別のトピックとしてセキュリティを取り上げますが、ファイアウォールの役割、およびIPsecのエンド展開に最後の望ましさ、前提を根底たしませんでした。セキュリティ上の具体的な提言は、セクション3.4と3.5で説明されています。
References
リファレンス
[1] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[1]大工、B.、 "インターネットの透明性"、RFC 2775、2000年2月。
[2] Hain, T., "Architectural Implications of NAT", Work in Progress.
[2]ハイン、T.、 "NATの建築含意"、ProgressのWork。
[3] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[3]大工、B.およびY. Rekhter、 "リナンバリングは作業が必要"、RFC 1900、1996年2月を。
[4] Ferguson, P and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
[4]ファーガソン、PおよびH.バーコウィッツは、「ネットワークのリナンバリングの概要：なぜ私はそれをしたいだろうし、それはとにかく何ですか？」、RFC 2071、1997年1月。
[5] M. Crawford, A. Mankin, T. Narten, J.W. Stewart, III, L. Zhang, "Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6", Work in Progress.
[5] M.クロフォード、A.マンキン、T. Narten氏、J.W.スチュワート、III、L.チャン、「アドレスに識別子とロケータを分離：IPv6のGSE提案の分析」が進行中で働いています。
[6] Crawford, M., and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[6]クロフォード、M.、およびC.のHuitema、RFC 2874、2000年7月 "DNSの拡張機能は、IPv6アドレスの集約とリナンバリングを支援します"。
[7] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.
[7] Srisuresh、P.、Tsirtsis、G.、Akkiraju、P.およびA. Heffernanのは、RFC 2694、1999年9月の "ネットワークへのDNS拡張は、翻訳者（DNS_ALG）をアドレス"。
[8] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[8]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
[9] M. Borella, D. Grabelsky, J. Lo, K. Tuniguchi "Realm Specific IP: Protocol Specification", Work in Progress.
[9] M.ボレッラ、D. Grabelsky、J.ロー、K. Tuniguchi "レルム特定IP：プロトコル仕様"、ProgressのWork。
[10] M. Borella, J. Lo, D. Grabelsky, G. Montenegro "Realm Specific IP: Framework", Work in Progress.
[10] M.ボレッラ、J.ロー、D. Grabelsky、G.モンテネグロ "レルム特定IP：フレームワーク" は、進行中の作業。
[11] G. Montenegro, M. Borella, "RSIP Support for End-to-end IPsec", Work in Progress.
[11] G.モンテネグロ、M.ボレッラ、 "エンドツーエンドIPsecのRSIPサポート"、ProgressのWork。
[12] M. Holdrege, P. Srisuresh, "Protocol Complications with the IP Network Address Translator", Work in Progress.
[12] M.ホールドレッジ、P. Srisuresh、「IPネットワークアドレス変換とプロトコルの合併症」が進行中で働いています。
[13] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[13] Tsirtsis、G.とP. Srisuresh、 "ネットワークアドレス変換 - プロトコル変換（NAT-PT）"、RFC 2766、2000年2月。
[14] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[14]ギリガン、R.およびE. Nordmarkと、 "IPv6ホストとルータの移行メカニズム"、RFC 2893、2000年8月。
[15] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", Work in Progress.
[15] B.カーペンター、K.ムーア、 "IPv4の雲を介したIPv6ドメインの接続"、ProgressのWork。
Appendix A. Participants
付録A.参加
Harald Alvestrand harald@alvestrand.no Ran Atkinson rja@corp.home.net Rob Austein sra@hactrn.net Steve Bellovin smb@research.att.com Randy Bush randy@psg.com Brian E Carpenter brian@hursley.ibm.com Vint Cerf vcerf@MCI.NET Noel Chiappa jnc@lcs.mit.edu Matt Crawford crawdad@fnal.gov Robert Elz kre@munnari.OZ.AU Tony Hain tonyhain@microsoft.com Matt Holdrege matt@ipverse.com Erik Huizer huizer@cs.utwente.nl Geoff Huston gih@telstra.net Van Jacobson van@cisco.com Marijke Kaat Marijke.Kaat@surfnet.nl Daniel Karrenberg Daniel.Karrenberg@ripe.net John Klensin klensin@jck.com Peter Lothberg roll@Stupi.SE Olivier H. Martin Olivier.Martin@cern.ch Gabriel Montenegro gab@sun.com Keith Moore moore@cs.utk.edu Robert (Bob) Moskowitz rgm@htt-consult.com Philip J. Nesser II pjnesser@nesser.com Kathleen Nichols kmn@cisco.com Erik Nordmark nordmark@eng.sun.com Dave Oran oran@cisco.com Yakov Rekhter yakov@cisco.com Bill Sommerfeld sommerfeld@alum.mit.edu Bert Wijnen wijnen@vnet.ibm.com Lixia Zhang lixia@cs.ucla.edu
ハラルドAlvestrand harald@alvestrand.noは、アトキンソンは、ロブAusteinとsra@hactrn.netスティーブBellovin氏smb@research.att.comランディブッシュはrandy@psg.com rja@corp.home.net蘭ブライアンエド・カーペンターbrian@hursley.ibm.comのVintサーフvcerf@MCI.NETクリスマスChiappa jnc@lcs.mit.eduマット・クロフォードcrawdad@fnal.govロバート・エルツkre@munnari.OZ.AUトニーハインtonyhain@microsoft.comマット・ホールドレッジmatt@ipverse.comエリックhuizer huizer @ CS .utwente.nlジェフ・ヒューストンgih@telstra.net Marijkeヴァンヤコブソンvan@cisco.com Kaat Marijke.Kaat@surfnet.nlダニエルKarrenberg Daniel.Karrenberg@ripe.netジョン・クレンシンklensin@jck.comピーター・ロスバーグroll@Stupi.SEオリヴィエ・H.マーティンOlivier.Martin@cern.chガブリエルモンテネグロgab@sun.comキース・ムーアmoore@cs.utk.eduロバート（ボブ）モスコウィッツrgm@htt-consult.comフィリップJ. Nesser II pjnesser@nesser.comキャスリーンニコルズkmn@cisco.comエリックNordmarkとnordmark@eng.sun.comデイブ・オランoran@cisco.comヤコフ・レックターyakov@cisco.comビルゾンマーフェルトsommerfeld@alum.mit.eduバートWijnen wijnen@vnet.ibm.com LixiaチャンLixia @c s.ucla.edu
Author's Address
著者のアドレス
Marijke Kaat SURFnet ExpertiseCentrum bv P.O. Box 19115 3501 DC Utrecht The Netherlands
Marijke Kaat SURFNET専門知識などの私書箱19115 3501 DCユトレヒトオランダ箱
Phone: +31 30 230 5305 Fax: +31 30 230 5329 EMail: Marijke.Kaat@surfnet.nl
電話：+31 30 230 5305ファックス：+31 30 230 5329 Eメール：Marijke.Kaat@surfnet.nl
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。