RFC2956 日本語訳
2956 Overview of 1999 IAB Network Layer Workshop. M. Kaat. October 2000. (Format: TXT=36830 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Kaat Request for Comments: 2956 SURFnet ExpertiseCentrum bv Category: Informational October 2000
Kaatがコメントのために要求するワーキンググループM.をネットワークでつないでください: 2956SURFnet ExpertiseCentrum bv Category: 情報の2000年10月
Overview of 1999 IAB Network Layer Workshop
1999IABネットワーク層ワークショップの概要
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
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日にユトレヒト(オランダ)のSURFnetによってホスティングされたインターネットNetwork Layerアーキテクチャのインターネット・アーキテクチャ委員会によって開かれたワークショップの概要(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 2 2。 結論と観測. . . . . . . . . . . . . . . 3 2.1透明。 . . . . . . . . . . . . . . . . . . . . . 3 2.2 NAT(ルート設定が発行するアドレス空間. . . . . . . . . . . . . 5 2.5におけるアプリケーションレベルゲートウェイとファイアウォール. . . . . . 4 2.3識別とアドレシング. . . . . . . . . . . . . 4 2.4観測)。 . . . . . . . . . . . . . . . . . . . . 5 移動性における2.6の観測。 . . . . . . . . . . . . . . . 6 2.7DNS冊。 . . . . . . . . . . . . . . . . . . . . . . 7 2.8 NATとRSIP。 . . . . . . . . . . . . . . . . . . . . . 7 2.9 ナット、RSIP、およびIPv6。 . . . . . . . . . . . . . . . . . . 8 IPv6における2.10の観測。 . . . . . . . . . . . . . . . . . 9 3. 推薦。 . . . . . . . . . . . . . . . . . . . . . 10 RSIPにおける名前空間.103.2の推薦の3.1の推薦。 . . . . . . . . . . . . . . . . 10 IPv6における3.3の推薦。 . . . . . . . . . . . . . . . . 10 IPsec. . . . . . . . . . . . . . . . 11における3.4の推薦
Kaat Informational [Page 1] RFC 2956 1999 IAB Network Layer Workshop October 2000
[1ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
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
ルート設定.123.7の推薦の推薦が申込み次第層にするDNS. . . . . . . . . . . . . . . . . 11 3.6における3.5の推薦とAPI。 . . . . . 12 4. セキュリティ問題。 . . . . . . . . . . . . . . . . . 12の参照箇所。 . . . . . . . . . . . . . . . . . . . . . . . . . 13 付録A.関係者。 . . . . . . . . . . . . . . . . . . 15作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . 15 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
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)はインターネットNetwork Layerのアーキテクチャでワークショップを開きました。 通常、Network LayerはIP層と呼ばれます。 ワークショップの目標は様々な現在、配布しているか、将来のメカニズムと技術がインターネットの継続成長と用法に持っているかもしれないNetwork Layerと影響力の現状について議論することでした。
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展開と変遷の状態は、IPv6が透明を終わらせるインターネットo Endの採用されたo Globallyユニークなアドレスと、32ビット・アドレス減少o Globalの接続性とまたは可到達性o Fragmentationでなく、それの進行性消失がoがArchitectureであると扱う際に識別と位置のメカニズム(ナット、RSIP)o Separationを共有するアドレスの終わりのセキュリティo Complicationsと現在のルーティングシステムのスケーリングへのo Endであるといけないので、o Alternative技術的戦略を発行します。
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への例えば、完全な移行、NATデバイスの使用によるネットワークのある区分、IPv6の重要な展開がなく、およびIPv4アドレス空間の増強された分割だけにおけるIPv6展開がありました。
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デバイスの展開などのネットワーク層の状態に大きい影響力を持つことができました)。
Kaat Informational [Page 2] RFC 2956 1999 IAB Network Layer Workshop October 2000
[2ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
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 Globalの接続性と可到達性を終わらせるために終わりのセキュリティo Deploymentを終わらせる終わりの展開は新しいアプリケーションoがItであると配布するのは新しいホストとネットワークをインターネットに接続するのがたやすく、簡単であるはずであるということであるべきであるというo Itであることが支持されて、ことであるべきです。(「働いてください、そして、確認してください」)
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.
このドキュメントはワークショップでされた結論と推薦状をまとめます。 すべての関係者が声明のすべてに同意したというわけではなくて、だれかそれらに皆、同意したかどうかは、明確でなかったことに注意されるべきです。 しかしながら、された推薦状は関係者の中で強いコンセンサスに基づいています。
2. Conclusions and Observations
2. 結論と観測
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で、これらの結論は説明されるでしょう。
2.1 Transparency
2.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セキュリティを終わらせるために終わりの展開に厳しい影響を与えます。
Kaat Informational [Page 3] RFC 2956 1999 IAB Network Layer Workshop October 2000
[3ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
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).
断片化の別の結果は「分裂DNS」か「2顔のDNS」の展開(セクション2.7を見る)です。(それは、与えられたFQDNとIPv4アドレスとの通信が長期の間もう普遍的であって、安定していないことを意味します)。
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]でさらに探検されます。
2.2 NAT, Application Level Gateways & Firewalls
2.2 NAT、アプリケーションレベルゲートウェイ、およびファイアウォール
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(ネットワークAddress Translation)、Application Level Gateways、およびファイアウォールの展開がネットワーク透明の損失をもたらすのを示しました。 それぞれのそれらは、透明を終わらせるために終わりの仮定を妨げるので、あるアプリケーションと非互換です。 すなわち、IPアドレスであり、セットアップするのに使用されて、接続は、NATが終点識別子としてサーバ、ピアツーピアコミュニケーション、および「いつもオンな」ホストに設定を特に複雑にして、グローバルにあいまいであって、安定していません。([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、アプリケーションレベルゲートウェイ、およびファイアウォールは、また、それぞれどちらかの本当の利点があるのでますます広く配布されるか、または知覚されています。 増強された展開はネットワーク透明のさらなる衰退を引き起こします、そして、これは新しいアプリケーションの展開を抑制します。 多くの新しいアプリケーションが、専門化しているApplication Level Gateways(ALGs)がNATデバイスに加えられるのを必要とするでしょう、NATデバイスを貫くとき、それらのアプリケーションが正しく動作する前に。 しかしながら、いくつかのアプリケーションはNATで有効にALGがあっても作動できません。
2.3 Identification and Addressing
2.3 識別とアドレシング
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はノードのアイデンティティの意味論を混ぜます。 複数のアドレス空間にネットワークを切り離すメカニズムの展開はただ一つのIPアドレスで唯一ホストを特定できるという仮定を破ります。 それ以外に、ホストは、ネットワークで別の場所に移行しますが、彼らのアイデンティティを同じに保ちたがっているかもしれません。 ホストのアイデンティティと位置の間の分化の不足は現在のアーキテクチャの多くの問題を引き起こします。
Kaat Informational [Page 4] RFC 2956 1999 IAB Network Layer Workshop October 2000
[4ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
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.
ノードロケータとノードのアイデンティティを切り離すのが理論上の根拠で望ましいかもしれないと結論づけられました。 IPsecに、これは特に本当です、IPアドレスが暗号で保護される識別子として使用されて(交通機関で)、したがって、輸送の間、変わりがあってはいけないので。 しかしながら、アイデンティティと位置のそのような分離は、短期間ソリューションとして利用可能でなく、平らなプロトコルを輸送するためにたぶん釣り銭がいるでしょう。 しかしながら、IPsecの現在の仕様はIPアドレスよりある他の識別子を使用に許容します。
2.4 Observations on Address Space
2.4 アドレス空間における観測
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アドレス空間を得ることができないという疑問が全くありません。 これは一部RegionalインターネットRegistries(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はこれらの境界で重要な複雑さと考えられます。 人々がNATsをファイアウォールに間違えているので、それはセキュリティ機能としてしばしば知覚されます。
2.5 Routing Issues
2.5 ルート設定問題
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
多くの関心が現在のルーティングシステムのスケーリングに関して高められました。 現在の技術で、使用できる接頭語の数は記憶容量、ルックアップ時間、またはある他の要素でというよりむしろ一点に集めるルーティング・アルゴリズムに取る時までに限られています。 限界は未知ですが、数10万の接頭語の注文にはそれがあるという非常に不明瞭な正当性に関する何らかの思惑があります。 そのうえ、また、現在のルーティングシステムの計算の経路指定テーブルのコンピュータの荷重、わざわざ、そして、それがネットワークの向こう側にルーティングアップデートを広げる丈夫さ、およびセキュリティは切迫した課題です。 唯一の知られているアドレシング
Kaat Informational [Page 5] RFC 2956 1999 IAB Network Layer Workshop October 2000
[5ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
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人のバックボーンオペレータには、インターネットワーク全体のルーティングの集合時間頃に、フェイルオーバーの間、関心があります。このオペレータは現在の集合時間が1分間の半分の注文にはあって、ことによるとより悪くなると信じています。 ルーティング共同体の他のものは、集合時間が最新号であると信じていませんでした。 或るもの(リアルタイムのアプリケーション(例えば、電話)がサブ2番目の集合を必要とすると信じている)はそのようなアプリケーションのときに30秒の集合時間の含意に関して心配しています。
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ルーティングがないかどうか、この提案([5])のGSE/8+8提案とIPNG WG分析はIESGによってまだ調べられています。 この提案を配布可能にすることができたか否かに関係なく、コンセンサスが全くワークショップにありません。
2.6 Observations on Mobility
2.6 移動性における観測
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ワークショップがこの話題に関して計画されているとき、詳細に移動性について議論しませんでした。
Kaat Informational [Page 6] RFC 2956 1999 IAB Network Layer Workshop October 2000
[6ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
2.7 DNS issues
2.7 DNS問題
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 Application Levelゲートウェイ([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の展開、または、より一般に別々の名前空間の存在で、終点識別子としてのFully Qualified Domain Names(FQDNs)の使用は、より複雑になります。
2.8 NAT and RSIP
2.8 NATとRSIP
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
分野特有のIP(RSIP)(IPv4との使用のためのメカニズム)はIETF NAT WGの仕事項目です。 それはIPv4のためのネットワーク・アドレスに代替手段として意図している(または補数として)翻訳(NAT)ですが、他の用途は可能です(例えば、終わりがファイアウォールの向こう側のトラフィックを終わらせるのを許容します)。 それはNATと同様です、それでローカルアドレスドメイン('分野'と呼ばれる)の多くのホストの中の少ない数の外部のIPv4アドレスを共有するので。 しかしながら、それはホストが異なった外部的に目に見えるIPv4アドレスが地元の分野の外でそれらについて言及するのに使用されて、それらであることを知っているという点においてNATと異なっています。
Kaat Informational [Page 7] RFC 2956 1999 IAB Network Layer Workshop October 2000
[7ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
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]).
それらの一時的な外部アドレスが何であるかを知ってください。 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.
彼らはNATsへのRSIPの追加で伝統的なNAT([12])で動作できないいくつかのアプリケーションをサポートすることができるかもしれませんが、RSIPクライアントとして機能するのが、ホストが変更されるのを必要とします。 RSIP意識しているのに作られている必要があるどんな層-3プロトコルも、それはホストのTCP/IPスタックへの変化を必要として、変更されていて(例えば、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の完全に用意ができていたモデルが全くそのようなコアなしでありません。 したがって、IPv4アドレス空間が最終的に消耗している(セクション2.4を見てください)ときはいつも、NATとRSIPは不確実な未来に面しています。 したがって、また、複雑さがグローバルにユニークなアドレスの不足で引き起こしたより長い期間、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の組み合わせは多くの場合、働くように思えます。 NAT問題のいくつかを取り除くことと同様に、RSIPが特定の新しい問題を紹介するかどうかが、決定するために残っています。
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を見てください)。
2.9 NAT, RSIP and IPv6
2.9 ナット、RSIP、およびIPv6
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がサポートする付加の影響
Kaat Informational [Page 8] RFC 2956 1999 IAB Network Layer Workshop October 2000
[8ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
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サポートを加えるより少ないです。 また、6to4([15])はIPv6トラフィックが既存のIPv4ルーティングインフラストラクチャの上に通過されるのを許容するでしょうそして、RSIPが自動トンネリング([14])などのテクニックが必要があります、そして、ルーティングインフラストラクチャへの変化が全く必要がなくて。 RSIPは主にIPv4の寿命を伸ばすためのツールですが、それはIPv6への変遷のためのバリケードではありません。 IPv6のものの後ろにRSIPの開発があります、そして、RSIPへの、より多くの研究が、RSIPの問題が何であるだろうかを決定するのに必要です。
2.10 Observations on IPv6
2.10 IPv6における観測
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問題によってしたようにIPv4における依存のためのすべてのRFCsを通した検索をするべきです、そして、問題を見つけるなら、それらを決議しなければなりません。 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.
それには、はるかに操作上簡単になる可能性がIPv4の番号を付け替えるよりあります、そして、現実的に、IPv6の番号を付け替えるのは、言及された依存で、本当に、自動でなく、瞬時に起こるはずがありませんが、これは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接続(旧住所(es)を使用する)が番号を付け替えることの向こう側に維持されるべきであるかどうかということです。 これで、事態ははるかに複雑になるでしょう、そして、通常、古くて新しいアドレスが長い間重なるのが見通されます。
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).
実際には番号を付け替えることがどれくらいの頻度で行われるだろうか、そして、またはそれがどれくらい自動である場合があるかに関するコンセンサスが全くありませんでした。 番号を付け替える(多分小さいサイトだけへの)にはそれほど多くない経験があります。
Kaat Informational [Page 9] RFC 2956 1999 IAB Network Layer Workshop October 2000
[9ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
3. Recommendations
3. 推薦
3.1 Recommendation on Namespace
3.1 名前空間における推薦
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)と何という名前空間も [上のポイントの出力によります] そうするべきである。
3.2 Recommendations on RSIP
3.2 RSIPにおける推薦
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はおもしろい考えですが、それはさらなる気品と研究を必要とします。 NATと同様に、それは終わりのネットワークモデルに終わりを切り出しません、RSIPホストには一時的なグローバルアドレスの形式知があるので。 したがって、RSIPはNATの問題のいくつかを解決できました。 しかしながら、このとき主流の指示としてそれを推薦するのは時期尚早です。
It is recommended that the IETF should actively work on RSIP, develop the details and study the issues.
IETFが活発にRSIPに働いて、詳細を開発して、問題を研究するはずであるのは、お勧めです。
3.3 Recommendations on IPv6
3.3 IPv6における推薦
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変遷のための出発点であるかもしれません。
Kaat Informational [Page 10] RFC 2956 1999 IAB Network Layer Workshop October 2000
[10ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
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.
またNATとRSIPが使用されているIPv4の特定のメカニズムに関する基本概念である間、IPv4があるので、IPv6(RSIPのためのNATのための太平洋標準時のNAT、SIIT、およびAIIHの)、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.
IPv4のためのNATとRSIPを配備させるIPv6への変遷のために、正確な含意はよく理解されていません。 IPv6への変遷、NATを使用するIPv4ドメインでの使用のための戦略とIPv4のための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.
3.3.3 8+8/GSE提案の草稿分析をIESGが評価して、受け入れるべきであるか、または拒絶するべきです、不穏な進行中のIPv6展開仕事なしで。 IESGは彼らの評価に終点名前空間パネル(セクション3.1を見る)との連絡を含む広い専門的技術を使用するはずです。
3.4 Recommendations on IPsec
3.4 IPsecにおける推薦
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仕様はいくつかの異なったIdentityタイプ(例えば、Domain Name、 User@Domain Name)の使用を支持します。 IETFはIPsecとの非アドレスIdentitiesの実現と展開を促進するはずです。 私たちは、IPsecの中で2進の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.
Secure DNS Extensions([8])の遍在している展開がアドレスベースのIdentityタイプなしでIPsec(IKEを含んでいる)の広範囲の展開を容易にするよう強く奨励されるべきです。
3.5 Recommendations on DNS
3.5 DNSにおける推薦
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の急速な展開は操作上の共同体に推薦されます。
Kaat Informational [Page 11] RFC 2956 1999 IAB Network Layer Workshop October 2000
[11ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
3.6 Recommendations on Routing
3.6 ルート設定の推薦
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.
スケーラブルなルーティングメカニズムを作成する計画を記述しながら知られているだけであるのは位相的に集められたアドレスによります(サイトがいつに番号を付け替えさせるかを必要とします)。グローバルなトポロジー変化におけるそれらの位置。 したがって、ルーティングIPv6に、推薦3.3.1は重大です。
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ルート設定Research Groupで続くべきであることを勧めます。
3.7 Recommendations on Application layer and APIs
3.7 Application層とAPIにおける推薦
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.
したがって、IETFプロトコル、および第三者アプリケーションがIPアドレスのどんな明白な認識も避けるのは、元々RFC1900[3]で推薦されるようにお勧めです、プロトコルかアプリケーションの効率的な操作がそのような認識がないとき可能であるときに。 いくつかのアプリケーションとサービスが、IPアドレスを意識しているのが必要であり続けるかもしれません。 私たちにはインターネットへの一定のアドレス空間がもう一度あるまで、そのようなアプリケーションとサービスは、必ずdeployabilityを制限した、そして/または、NATsで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.
また、私たちはすべてのネットワーク層の依存から抽象化を提供するためにAPIを一般化するためのIETFでの努力を推薦します、恐らくセクション3.1の名前空間研究のサイド効果として。
4. Security Considerations
4. セキュリティ問題
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でカバーされています。
Kaat Informational [Page 12] RFC 2956 1999 IAB Network Layer Workshop October 2000
[12ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
References
参照
[1] Carpenter, B., "Internet Transparency", RFC 2775, February
2000.
[1] 大工、B.、「インターネット透明」、RFC2775、2000年2月。
[2] Hain, T., "Architectural Implications of NAT", Work in
Progress.
[2] ハイン、T.、「NATの建築含意」が進行中で働いています。
[3] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.
[3]大工、B.、およびY.Rekhter、「番号を付け替えるのは仕事を必要とである」RFC1900、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.バーコウィッツ、「番号を付け替える概観をネットワークでつないでください」 「私はなぜそれととにかくそれであるものが欲しいでしょうか?」、RFC2071、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、「IPv6アドレス集合を支持して、番号を付け替えることへのDNS拡張子」、RFC2874、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.とA.ヘファーナン、「Network Address Translators(DNS_ALG)へのDNS拡張子」RFC2694(1999年9月)。
[8] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[8] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、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.K.Tuniguchi、「分野の特定のIP:」 「プロトコル仕様」、処理中の作業。
[10] M. Borella, J. Lo, D. Grabelsky, G. Montenegro "Realm Specific
IP: Framework", Work in Progress.
[10]M.Borella、見よ、D.Grabelsky、J.G.モンテネグロ、「分野の特定のIP:」 「枠組み」、処理中の作業。
[11] G. Montenegro, M. Borella, "RSIP Support for End-to-end IPsec",
Work in Progress.
[11] G.モンテネグロ、「終わりから終わりへのIPsecのRSIPサポート」というM.Borellaは進行中で働いています。
[12] M. Holdrege, P. Srisuresh, "Protocol Complications with the IP
Network Address Translator", Work in Progress.
[12] P.Srisuresh、「IPネットワークアドレス変換機構とのプロトコル複雑さ」というM.Holdregeは進行中で働いています。
[13] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[13]TsirtsisとG.とP.Srisuresh、「アドレス変換をネットワークでつないでください--翻訳(太平洋標準時のNAT)について議定書の中で述べてください」、RFC2766、2000年2月。
Kaat Informational [Page 13] RFC 2956 1999 IAB Network Layer Workshop October 2000
[13ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
[14] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, August 2000.
[14] ギリガンとR.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC2893、2000年8月。
[15] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4
Clouds", Work in Progress.
[15] B.大工、K.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、ProgressのWork。
Kaat Informational [Page 14] RFC 2956 1999 IAB Network Layer Workshop October 2000
[14ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
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 はアトキンソン・ rja@corp.home.net ロブ・Austein sra@hactrn.net スティーブ・Bellovin smb@research.att.com ランディ・ブッシュ・ randy@psg.com ブライアン・E大工 brian@hursley.ibm.com Vintサーフ・ vcerf@MCI.NET クリスマスのChiappa jnc@lcs.mit.edu マット・クロフォード crawdad@fnal.gov ロバートElz kre@munnari.OZ.AU トニーハイン tonyhain@microsoft.com マットHoldrege matt@ipverse.com エリックHuizer huizer@cs.utwente.nl ジェフヒューストン gih@telstra.net ヴァンジェーコブソン van@cisco.com Marijke Kaat Marijke.Kaat@surfnet を走らせました; nlダニエルKarrenberg Daniel.Karrenberg@ripe.net ジョンKlensin klensin@jck.comピーターLothberg 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 ヤコフRekhter yakov@cisco.com ビルゾンマーフェルト sommerfeld@alum.mit.edu バートWijnen wijnen@vnet.ibm.com Lixiaチャン 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私書箱19115 3501DCユトレヒトオランダ
Phone: +31 30 230 5305 Fax: +31 30 230 5329 EMail: Marijke.Kaat@surfnet.nl
以下に電話をしてください。 +31 30 230 5305Fax: +31 30 230 5329はメールされます: Marijke.Kaat@surfnet.nl
Kaat Informational [Page 15] RFC 2956 1999 IAB Network Layer Workshop October 2000
[15ページ]RFC2956 1999IABネットワーク層ワークショップ2000年10月の情報のKaat
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Kaat Informational [Page 16]
Kaat情報です。[16ページ]
一覧
スポンサーリンク
