[要約] RFC 2956は、1999年のIABネットワーク層ワークショップの概要を提供しており、ワークショップの目的はネットワーク層の課題と将来の方向性を議論することです。
Network Working Group M. Kaat
Request for Comments: 2956 SURFnet ExpertiseCentrum bv
Category: Informational October 2000
Overview of 1999 IAB Network Layer Workshop
1999年のIABネットワークレイヤーワークショップの概要
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.
Copyright（c）The Internet Society（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.
このドキュメントは、1999年7月7〜9日にオランダのUtrechtのSurfnetがホストするインターネットネットワークレイヤーアーキテクチャでインターネットアーキテクチャボード（IAB）が開催したワークショップの概要です。ワークショップの目標は、その状態を理解することでした。ネットワークレイヤーとインターネットの継続的な成長と使用に対する影響。（予見可能な）将来のさまざまな技術シナリオと外部の影響の影響が研究されました。このレポートには、インターネットエンジニアリングタスクフォース（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.
1999年7月7日から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代替技術戦略IPv6が採用されていない場合oグローバルに一意のアドレスと32ビットアドレスの枯渇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")
o エンドツーエンドのセキュリティOエンドツーエンドの輸送の展開oグローバル接続とリーチビリティを維持する必要があります。新しいアプリケーションを簡単に展開する必要があります。新しいホストとネットワークをインターネットに簡単に接続できます（「プラグとping」））
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.
参加者は、セクション1で述べたいくつかの問題について多くの結論と観察を行いました。次のセクション2.1-2.10では、これらの結論について説明します。
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.
透明性の喪失には、ネットワークアドレス翻訳デバイスの展開、プライベートアドレスの使用、ファイアウォールとアプリケーションレベルのゲートウェイ、プロキシ、キャッシュなど、複数の原因があります。これらのメカニズムは、ネットワークレイヤーの断片化を増加させ、インターネット上の多くのアプリケーションに問題を引き起こします。アプリケーションの設計の複雑さになり、新しいアプリケーションの展開を阻害します。特に、End to End 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).
断片化のもう1つの結果は、「分割DNS」または「2つの対面DNS」の展開です。つまり、特定のFQDNとIPv4アドレスの間の対応は、長期間にわたって普遍的で安定していないことを意味します（セクション2.7を参照）。
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アドレスとしての「常にオン」ホスト、つまり接続のセットアップに使用される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デバイスを実行するときにそれらのアプリケーションが正しく機能する前に、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.
ノードのアイデンティティをノードロケーターから分離することが理論的根拠で望ましいと結論付けられました。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アドレススペースを取得できないことは間違いありません。これは、地域のインターネットレジストリ（RIRS）の現在のスチュワードシップポリシーの一部です。
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.
少なくとも1つのバックボーンオペレーターは、フェールオーバー中のインターネットワーク全体のルーティングの収束時間について懸念があります。このオペレーターは、現在の収束時間は0.5分間であり、おそらく悪化すると考えています。ルーティングコミュニティの他の人々は、収束時間が現在の問題であるとは考えていませんでした。リアルタイムのアプリケーション（テレフォニーなど）にサブセカンドの収束が必要であると考えている人もいますが、このようなアプリケーションでの収束時間の収束時間の影響を懸念しています。
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アップデートのスケールが何であるかは明確ではありませんが、最も積極的なモデルでは1日に数百万人になる可能性があります。ドメイン名を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.
スプリットDNの展開、またはより一般的には個別の名前スペースの存在により、エンドポイント識別子として完全に適格なドメイン名（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]).
IPv4で使用するメカニズムであるRealm固有のIP（RSIP）は、IETF NAT WGの作業項目です。IPv4のネットワークアドレス変換（NAT）の代替（または補数として）として意図されていますが、他の用途が可能です（たとえば、ファイアウォール全体のエンドからエンドのトラフィックを可能にします）。NATに似ています。これにより、ローカルアドレスドメイン（「レル」と呼ばれる）の多くのホスト間で、少数の外部IPv4アドレスを共有できるようになります。ただし、ホストは、異なる外部で検討可能なIPv4アドレスがローカルの領域の外側の外でそれらを参照するために使用されており、一時的な外部アドレスが何であるかを知っていることを知っているという点で、NATとは異なります。アドレスとその他の情報はRSIPサーバーから取得され、パケットは最初のルーティングレルム全体にトンネル化されています（[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クライアントは、別のアドレススペースからIPアドレスを使用しているという事実を認識しているが、NATでは、どちらのエンドポイントもパケット内のアドレスが翻訳されていることを認識していない - は重要であるということです。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クライアントとして機能するようにホストを変更する必要があります。ホストのTCP/IPスタックの変更が必要であり、RSIPアウェアを変更する必要があるレイヤー3つのプロトコルを変更する必要があり（ICMPなど）、特定のアプリケーションを変更する必要があります。ホストまたはアプリケーションソフトウェアに必要な正確な変更は、現時点ではあまり知られておらず、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の完全に準備されたモデルはありません。したがって、NATとRSIPは、IPv4アドレススペースが最終的に使い果たされるたびに不確実な未来に直面しています（セクション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 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が広く展開されると仮定すると、ネットワークアドレスの変換手法は、IPv4からIPv6への遷移プロセスで重要な役割を果たす可能性があります（[13]）。RSIPサポートをホストに追加することの影響は現時点では明確ではありませんが、ほとんどのアプリケーションを変更する必要がないため、IPv6サポートを追加するよりも少ないです。RSIPはルーティングインフラストラクチャに変更を必要としませんが、自動トンネリング（[14]）や6to4（[15]）などの手法では、既存のIPv4ルーティングインフラストラクチャにIPv6トラフィックを渡すことができます。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ルーターをリリースする必要があります。コアプロトコルは終了しますが、他の基準を前進させる必要があります（MIBSなど）。Y2K問題について行われたように、すべてのRFCをIPv4の依存関係に対して検索する必要があります。問題が見つかった場合は、解決する必要があります。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).
重要な疑問の1つは、IPv6がルーティングシステムの現在の問題を解決し、インターネットスケールを改善できるかどうかでした。アドレス指定トポロジとルーティングを最適化するために、接頭辞を定期的に変更する場合、「自動」の変更が非常に重要であると結論付けられました。これはまた、プロトコルとアプリケーションのIPレイヤーと構成の依存関係を削除する必要があることを意味します（[3]）。言及された1つの例は、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:
ワークショップでは、IABにIETFに具体的な推奨事項を作成するためにパネルを任命することを推奨しています。
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.
i）a）natが「より良い」動作するように、端から末尾のインタラクションのために名前空間を採用するようスタックのより多くの部分を奨励する必要があるかどうか、およびb）インターネットと輸送と層の間にもう少し独立している。ii）もしそうなら、この関数にシステム全体の単一の名前空間が必要かどうか、またはさまざまなサブシステムがそれらにとって理にかなっている名前空間を選択できるようにする方が理にかなっているかどうか。iii）およびまた、どんな名前空間（上記のポイントの出力に依存する）があるはずのもの。
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.
3.3.1 TLAベースのアドレス指定とルーティングの現在のモデルを積極的に追求する必要があります。ただし、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への提案された移行パスの要素（NATのNAT-PT、およびRSIPのSIITおよびAIIH）で使用されていますが、IPv4のNATとRSIPは直接的な部分ではありません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を展開することは、よく理解されていません。IPv4にnatとrsipを使用したIPv4ドメインで使用するためのTrasitionのための戦略は、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.
3.3.3 8 8/GSE提案のドラフト分析は、IESGによって評価され、継続的なIPv6展開作業を妨げることなく、受け入れまたは拒否されるべきです。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アドレスよりも他の識別子を使用してIPSECを実装および展開することは緊急です（セクション2.3を参照）。現在のIPSEC仕様は、いくつかの異なるIDタイプ（ドメイン名、ユーザー@ドメイン名など）の使用をサポートしています。IETFは、非アドレスIDの実装と展開をIPSECと促進する必要があります。IETFは、ルーターからルーターのトンネルなどの特定の非常に限られた状況を除き、IPSEC内のバイナリ32ビットIPアドレスの使用を完全に非難することを強く求めます。特に、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]）のユビキタスな展開は、アドレスベースのIDタイプなしでIPSEC（IKEを含む）の広範な展開を促進するために強く推奨されるべきです。
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に重い負担をかけます。したがって、IETFには、すでに進行中の変更を除き、ネットワークの変更やセキュリティの改善をサポートすることを除いて、予見可能な将来のDNSの根本的な変更や追加は行われません。
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に当てはまりますが、インストールされたベースは単純すぎるだけで、Pierワーキンググループは、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 [3]で当初推奨されているように、IETFプロトコルとサードパーティアプリケーションは、そのような認識がない場合に実行可能な場合、IPアドレスの明示的な認識を回避することが推奨されます。一部のアプリケーションとサービスは、引き続きIPアドレスを認識する必要がある場合があります。インターネット用の均一なアドレススペースが再びできるまで、そのようなアプリケーションとサービスには展開性が限られているか、NATでのアルグサポートが必要になります。
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] Hain、T。、「Natの建築的意味」、進行中の作業。
[3] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[3] Carpenter、B。およびY. Rekhter、「Nemonging Needs Work」、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。ナルテン、J.W。Stewart、III、L。Zhang、「住所の識別子とロケーターの分離：IPv6のGSE提案の分析」、進行中の作業。
[6] Crawford, M., and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[6] Crawford、M。、およびC. Huitema、「DNS拡張機能IPv6アドレスの集約と改修」、RFC 2874、2000年7月。
[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。and A. Heffernan、「DNS拡張翻訳者（DNS_ALG）」、RFC 2694、1999年9月。
[8] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[8] EastLake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[9] M. Borella, D. Grabelsky, J. Lo, K. Tuniguchi "Realm Specific IP: Protocol Specification", Work in Progress.
[9] M. Borella、D。Grabelsky、J。Lo、K。Tuniguchi "Realm固有のIP：プロトコル仕様"、進行中の作業。
[10] M. Borella, J. Lo, D. Grabelsky, G. Montenegro "Realm Specific IP: Framework", Work in Progress.
[10] M. Borella、J。Lo、D。Grabelsky、G。Montenegro "Realm固有のIP：フレームワーク"、Work in Progress。
[11] G. Montenegro, M. Borella, "RSIP Support for End-to-end IPsec", Work in Progress.
[11] G.モンテネグロ、M。ボレラ、「エンドツーエンドIPSECのRSIPサポート」、進行中の作業。
[12] M. Holdrege, P. Srisuresh, "Protocol Complications with the IP Network Address Translator", Work in Progress.
[12] M. Holdrege、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] Gilligan、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ドメインの接続」、進行中の作業。
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
Author's Address
著者の連絡先
Marijke Kaat SURFnet ExpertiseCentrum bv P.O. Box 19115 3501 DC Utrecht The Netherlands
Marijke Kaat Surfnet Expertisecentrum Bv P.O.Box 19115 3501 DC Utrecht The Netherlands
Phone: +31 30 230 5305
Fax: +31 30 230 5329
EMail: Marijke.Kaat@surfnet.nl
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。