RFC1627 日本語訳
1627 Network 10 Considered Harmful (Some Practices Shouldn't beCodified). E. Lear, E. Fair, D. Crocker, T. Kessler. July 1994. (Format: TXT=18823 bytes) (Obsoleted by RFC1918) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group E. Lear Request for Comments: 1627 Silicon Graphics, Inc. Category: Informational E. Fair Apple Computer, Inc. D. Crocker Silicon Graphics, Inc. T. Kessler Sun Microsystems, Inc. July 1994
コメントを求めるワーキンググループE.リア要求をネットワークでつないでください: 1627年のシリコングラフィックスカテゴリ: 情報の晴れているE.の医者シリコングラフィックスT.ケスラーサン・マイクロシステムズ・インクアップル・コンピューターInc.D.1994年7月
Network 10 Considered Harmful (Some Practices Shouldn't be Codified)
有害であると考えられたネットワーク10(いくらかのPractices Shouldn、Codifiedでない、)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
SUMMARY
概要
Re-use of Internet addresses for private IP networks is the topic of the recent RFC 1597 [1]. It reserves a set of IP network numbers, for (re-)use by any number of organizations, so long as those networks are not routed outside any single, private IP network. RFC 1597 departs from the basic architectural rule that IP addresses must be globally unique, and it does so without having had the benefit of the usual, public review and approval by the IETF or IAB. This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored.
インターネット・アドレスのプライベートアイピーネットワークの再使用は最近のRFC1597[1]の話題です。 それが1セットのIPネットワーク・ナンバーを予約する、(再、)、いろいろな組織で、それらのネットワークがどんなシングル(プライベートアイピーネットワーク)の外でも発送されない限り、使用します。 RFC1597はIPアドレスがグローバルにユニークでなければならなく、IETFかIABによる普通の利益を持っていた、公開レビュー、および承認なしでそうするという基本的な建築規則から出発します。 このドキュメントはユニークなアドレス空間を維持するための議論を言い直します。 インターネットアーキテクチャに関する心配とIETF手順と同様に操作は調査されます。
INTRODUCTION
序論
Growth in use of Internet technology and in attachments to the Internet have taken us to the point that we now are in danger of running out of unassigned IP network numbers. Initially, numbers were formally assigned only when a network was about to be attached to the Internet. This caused difficulties when initial use of IP substantially preceded the decision and permission to attach to the Internet. In particular, re-numbering was painful. The lesson that we learned was that every IP address ought to be globally unique, independent of its attachment to the Internet. This makes it possible for any two network entities to communicate, no matter where either might be located. This model is the result of a decades-long evolution, through which the community realized how painful it can be to convert a network of computers to use an assigned number after
インターネット技術の使用とインターネットへの付属における成長は私たちには割り当てられなかったIPネットワーク・ナンバーを使い果たすという危険が現在あるというポイントに私たちを連れて行きました。 ネットワークが初めはインターネットに付けられようとしていたときだけ、数は正式に割り当てられました。 IPの初期の使用が実質的に決定とインターネットに付く許可に先行したとき、これは困難を引き起こしました。 再付番は特に、苦痛でした。 私たちが学んだというレッスンはあらゆるIPアドレスがグローバルにユニークであるべきであるということでした、インターネットへの付属の如何にかかわらず。 これで、どちらかがどこに位置するかもしれなくても、どんな2つのネットワーク実体も交信するのが可能になります。 このモデルは長さ何10年間もの発展の結果です、共同体が、どれに規定番号を使用するためにコンピュータのネットワークを変換するのがどれくらい苦痛である場合があるかをわかったか後を通して
Lear, Fair, Crocker & Kessler [Page 1] RFC 1627 Network 10 Considered Harmful July 1994
1627年のネットワーク10が有害な1994年7月に考えたリア、フェア、クロッカー、およびケスラー[1ページ]RFC
using random or default addresses found on computers just out of the box. RFC 1597 abrogates this model without benefit of general IETF community discussion and consensus, leaving policy and operational questions unasked and unanswered.
コンピュータでちょうど創造的に見つけられた無作為であるかデフォルトアドレスを使用します。 RFC1597は一般的なIETF共同体議論とコンセンサスの利益なしでこのモデルを廃棄します、方針と操作上の質問を問われていなくて、答えがない状態でおいて。
KEEP OUR EYES ON THE PRIZE: AN ARCHITECTURAL GOAL AND VIOLATION
賞を見守ってください: 建築目標と違反
A common -- if not universal -- ideal for the future of IP is for every system to be globally accessible, given the proper security mechanisms. Whether such systems comprise toasters, light switches, utility power poles, field medical equipment, or the classic examples of "computers", our current model of assignment is to ensure that they can interoperate.
IPの未来の一般的であるか普遍的な理想はあらゆるシステムがグローバルにアクセスしやすいことです、適切なセキュリティー対策を考えて。そのようなシステムが「コンピュータ」に関するトースター、電灯のスイッチ、ユーティリティ電柱、分野医療機器、または典型例を包括するか否かに関係なく、私たちの課題の現在のモデルは、彼らが共同利用できるのを保証することになっています。
In order for such a model to work there must exist a globally unique addressing system. A common complaint throughout the community is that the existing security in host software does not allow for every (or even many) hosts in a corporate environment to have direct IP access. When this problem is addressed through proper privacy and authentication standards, non-unique IP addresses will become a bottleneck to easy deployment if the recommendations in RFC 1597 are followed.
そのようなモデルが扱うように、グローバルにユニークなアドレス指定方式は存在しなければなりません。 共同体中の一般的な苦情がホストソフトウェアにおける既存のセキュリティがそうしないということである、許容、あらゆる、持っている企業社会における(または、多くさえ)ホストはIPアクセサリーを指示します。 この問題が適切なプライバシーと認証規格を通して扱われるとき、RFC1597の推薦が続かれているなら、非固有のIPアドレスは簡単な展開へのボトルネックになるでしょう。
The IP version 4 (IPv4) address space will be exhausted. The question is simply: when?
IPバージョン4(IPv4)アドレス空間は消耗するでしょう。 質問は単に以下の通りです。 いつですか?
If we assert that all IP addresses must be unique globally, connected or not, then we will run out of IP address space soon.
すべてのIPアドレスがグローバルにユニークでなければならないと断言するなら、接続されていて、私たちはすぐ、IPアドレス空間を使い果たすつもりです。
If we assert that only IP addresses used on the world-wide Internet need to be globally unique, then we will run out of IP address space later.
世界的なインターネットで使用されるIPアドレスだけが、グローバルに特有である必要であると断言するなら、私たちは後でIPアドレス空間を使い果たすつもりです。
It is absolutely key to keep the Internet community's attention focused on the efforts toward IP next generation (IPng), so that we may transcend the limitations of IPv4. RFC 1597 produces apparent relief from IPv4 address space exhaustion by masking those networks that are not connecting to the Internet, today. However, this apparent relief will likely produce two results: complacency on the large part of the community that does not take the long term view, and a very sudden IP address space exhaustion at some later date.
取り組みにインターネットコミュニティの注意の焦点を合わせIP次の世代(IPng)に向かって続けるのは絶対に主要です、私たちがIPv4の限界を超えることができるように。 RFC1597はIPv4アドレス空間疲労困憊からインターネットに接続していないそれらのネットワークにマスクをかけることによって、見かけの救援を起こします、今日。 しかしながら、この見かけの救援はおそらく2つの結果を生むでしょう: 長期意見を取らない共同体のかなりの部分、およびいつかの後の期日の非常に突然のIPアドレス空間疲労困憊での無頓着。
Prior to IPng deployment, it is important to preserve all the semantics that make both the Internet and Internet technology so very valuable for interoperability. Apple Computer, IBM, and Motorola could not collaborate as easily as they have to produce the PowerPC without uniquely assigned IP addresses. The same can be said of the Silicon Graphics merger with MIPS. There are many, many more examples
IPng展開の前に、インターネットとインターネットの両方をしたがって、相互運用性に、非常に有益な技術にするすべての意味論を保存するのは重要です。 アップル・コンピューター、IBM、およびモトローラは彼らが唯一割り当てられたIPアドレスなしでパワーPCを生産しなければならないほど容易に共同できませんでした。 MIPSへのシリコングラフィックスの合併について同じくらい言うことができます。多くの、より多くの例があります。
Lear, Fair, Crocker & Kessler [Page 2] RFC 1627 Network 10 Considered Harmful July 1994
1627年のネットワーク10が有害な1994年7月に考えたリア、フェア、クロッカー、およびケスラー[2ページ]RFC
that can be cited.
それを引用できます。
It should be noted that a scheme similar to RFC 1597 can be implemented at the time that we actually run out of assignable IPv4 address space; it simply requires that those organizations which have been assigned addresses but are not yet connected to the Internet return their addresses to IANA. It is important that the IAB (and IANA as its agent) reassert their ownership of the IP address space now, to preclude challenges to this type of reassignment.
私たちが実際にassignable IPv4アドレス空間を使い果たす時にRFC1597と同様の体系を実装することができることに注意されるべきです。 それは、割り当てられたアドレスでしたが、まだインターネットに接続されていないそれらの組織がそれらのアドレスをIANAに返すのを単に必要とします。 IAB(そして、エージェントとしてのIANA)が現在このタイプの再割当てへの挑戦を排除するためにそれらのIPアドレス空間の所有権を重ねて主張させるのは、重要です。
OPERATIONAL ISSUES
操作上の問題
RFC 1597 Implementations
RFC1597実装
Methods are needed to ensure that the remaining addresses are allocated and used frugally. Due to the current problems, Internet service providers have made it increasingly difficult for organizations to acquire public IP network numbers. Private networks have always had the option of using addresses not assigned to them by appropriate authorities. We do not know how many such networks exist, because by their nature they do not interact with the global Internet. By using a random address, a company must take some care to ensure it is able to route to the properly registered owner of that network.
メソッドが、残っているアドレスが質素に割り当てられて、使用されるのを保証するのに必要です。 現在の問題のため、インターネット接続サービス業者で、組織が公共のIPネットワーク・ナンバーを取得するのがますます難しくなりました。 私設のネットワークには、適切な当局によってそれらに割り当てられなかったアドレスを使用するオプションがいつもありました。 私たちは、そのような何ネットワークが存在するのを知りません、世界的なインターネットと対話しないので。 無作為のアドレスを使用することによって、会社はそのネットワークの適切に登録された所有者に発送できるのを保証する何らかの注意を払わなければなりません。
RFC 1597 proposes to solve the routing problem by assigning numbers that will never be used outside of private environments. Using such standard numbers introduces a potential for clashes in another way. If two private networks follow RFC 1597 and then later wish to communicate with each other, one will have to renumber. The same problem occurs if a private network wishes to become public. The likely cost of renumbering is linear to the number of hosts on a network. Thus, a large company with 10,000 hosts on a network could incur considerable expense if it either merged with another company or joined the Internet in such a way as to allow all hosts to directly access the outside network.
RFC1597は、個人的な環境の外で決して使用されない数を割り当てることによってルーティング問題を解決するよう提案します。 そのような標準の数を使用すると、衝突の可能性は別の方法的に導入されます。 2つの私設のネットワークがRFC1597に続いて、次に、後で互いにコミュニケートしたいなら、意志が番号を付け替えさせなければならない1つです。 私設のネットワークが公共になりたいなら、同じ問題は起こります。 番号を付け替えることのありそうな費用はネットワークでホストの数に直線的です。 したがって、すべてのホストが直接外のネットワークにアクセスするのを許容するほど、別の会社と合併するか、またはインターネットをそのような方法で接合するなら、1万人のホストがネットワークの一員であることでの大企業はかなりの費用を被ることができるでしょうに。
The probability of address clashes occurring over time approach 100% with RFC 1597. Picking a random network number reduces the chances of having to renumber hosts, but introduces the routing problems described above. Best of all, retrieving assigned numbers from the appropriate authority in the first place eliminates both existing and potential address conflicts at the cost of using a part of the address space.
アドレスの確率は、RFC1597と共に時間アプローチの上に100%起こりながら、衝突します。 無作為のネットワーク・ナンバーを選ぶと、ホストに番号を付け替えさせなければならないという可能性が小さくされますが、上で説明されたルーティング問題は紹介されます。 第一に適切な権威から規定番号を検索すると、存在と潜在的アドレス闘争の両方がアドレス空間の一部を使用する費用で最もよく、排除されます。
Apple Computer once believed that none of its internal systems would ever speak IP directly to the outside world, and as such, network operations picked IP class A network 90 out of thin air to use.
アップル・コンピューターは、一度内部のシステムのいずれも直接外の世界にIPを話さないと信じていました、そして、そういうものとして、ネットワーク操作は使用する薄い空気からIPのクラスAにネットワーク90を選びました。
Lear, Fair, Crocker & Kessler [Page 3] RFC 1627 Network 10 Considered Harmful July 1994
1627年のネットワーク10が有害な1994年7月に考えたリア、フェア、クロッカー、およびケスラー[3ページ]RFC
Apple is only now recovering from this error, having renumbered some 5,000 hosts to provide them with "desktop" Internet access. Unless the Internet community reaffirms its commitment to a globally unique address space, we condemn many thousands of organizations to similar pain when they too attempt to answer the call of the global Internet.
アップルは、「デスクトップ」インターネット・アクセスを彼らに提供するためにおよそ5,000人のホストに番号を付け替えさせたので、現在、この誤りから克服されているだけです。 それらも、世界的なインターネットの呼び出しに答えるのを試みるとき、インターネットコミュニティがグローバルにユニークなアドレス空間の委任を再び断言しない場合、私たちは何千もの組織を同様の痛みに非難します。
Another timely example of problems caused by RFC 1597 is Sun's use of Internet multicasting. Sun selectively relays specific multicast conferences. This has the effect of making many hosts at Sun visible to the Internet, even though they are not addressable via IP unicast routing. If they had non-global addresses this would not work at all. It is not possible to predict which machines need global addresses in advance. Silicon Graphics has a similar configuration, as is likely for others, as well.
RFC1597によって引き起こされた問題の別のタイムリーな例はSunのインターネットマルチキャスティングの使用です。 Sunは選択的に特定のマルチキャスト会議をリレーします。 これには、インターネットに目に見えるSunで多くのホストを作るという効果があります、彼らはIPユニキャストルーティングでアドレス可能ではありませんが。 彼らに非グローバルなアドレスがあるなら、これは全く働いていないでしょうに。 どのマシンがあらかじめグローバルなアドレスを必要とするかを予測するのは可能ではありません。 シリコングラフィックスには、そのままな同様の構成がまた、他のもののためにおそらくあります。
Some might argue that assigning numbers to use for private networks will prevent accidental leaks from occurring through some sort of convention a'la Martian packets. While the proposal attempts to create a standard for "private" address use, there is absolutely no way to ensure that other addresses are not also used.
或るものは、私設のネットワークに使用する数を割り当てるのが、偶然の漏出がある種のコンベンションのa'laの火星のパケットを通して起こるのを防ぐと主張するかもしれません。 提案は、「個人的な」アドレス使用の規格を作成するのを試みますが、また、他のアドレスが使用されないのを保証する方法が全く絶対にありません。
Hence, the "standard" becomes nothing but a misleading heuristic. In fact, it is essential that routers to the global Internet advertise networks based only on explicit permission, rather than refusing to advertise others based on implicit prohibition, as supported by the policy formally created in RFC 1597.
したがって、「規格」は紛らわしいヒューリスティックだけになります。 事実上、世界的なインターネットへのルータが暗黙の禁止に基づく他のものの広告を出すのを拒否するよりむしろ明白な許可だけに基づくネットワークの広告を出すのは、不可欠です、RFC1597で正式に作成された方針でサポートされるように。
Security Issues
安全保障問題
Administrators will have a hard time spotting unauthorized networks, when their network has been breached (either intentionally or unintentionally) because the other networks might have the same numbers as those normally in the routing tables. More over, an inadvertent connection could possibly have a double whammy effect of partitioning two operational networks.
管理者は、権限のないネットワークを見つけるのに苦労するでしょう、他のネットワークが経路指定テーブルに通常それらと同じ数を持っているかもしれないのでそれらのネットワークが破られたとき(故意にか何気ない)。 不注意な接続は2つの操作上のネットワークを仕切るというダブルパンチ効果をより持つことができました。
It is worth emphasizing that IP providers should filter out all but authorized networks. Such a practice would not only prevent accidents but also enhance the security of the Internet by reducing the potential number of points of attack.
IPプロバイダーがほとんど認可されたネットワークを無視するべきであると強調する価値があります。 そのような習慣は、事故を防ぐだけではなく、ポイントの攻撃の潜在的数を減少させることによって、インターネットのセキュリティを高めもするでしょう。
Internet multicasting adds a new dimension to security. In some cases it may possible to allow multicasting through firewalls that completely restrict unicast routing. Otherwise unconnected networks might well need unique addresses, as illustrated in the example above.
インターネットマルチキャスティングは新しい寸法をセキュリティに加えます。 いくつかの場合、それは可能であるかもしれません。ユニキャストルーティングを完全に制限するファイアウォールにマルチキャスティングの通ることを許すのにおいて、可能です。 そうでなければ、無関係のネットワークはたぶん上記の例で例証されるようにユニークなアドレスを必要とするでしょう。
Lear, Fair, Crocker & Kessler [Page 4] RFC 1627 Network 10 Considered Harmful July 1994
1627年のネットワーク10が有害な1994年7月に考えたリア、フェア、クロッカー、およびケスラー[4ページ]RFC
Problems with Examples
例に関する問題
RFC 1597 gives several examples of IP networks that need not have globally unique address spaces. Each of those cases is plausible, but that does not make it legitimate to ENCOURAGE non-uniqueness of the addresses. In fact, it is equally plausible that globally unique IP addresses will be required, for every one of the scenarios described in RFC 1597:
RFC1597はグローバルにユニークなアドレス空間を持つ必要はないIPネットワークに関するいくつかの例を出します。 それぞれのそれらのケースはもっともらしいのですが、それで、それはアドレスのENCOURAGE非のユニークさに正統になりません。 事実上、グローバルにユニークなIPアドレスが必要であるのは、等しくもっともらしいです、RFC1597で説明されたシナリオの皆のために:
- Airport displays are public information and multicasting beyond the airport might be useful.
- 空港ディスプレイは公開情報です、そして、空港を超えたマルチキャスティングは役に立つかもしれません。
- An organization's machines which, today, do not need global connectivity might need it tomorrow. Further, merging organizations creates havoc when the addresses collide.
- 組織のものはどれを機械加工するか、そして、グローバルな接続性がそうするかもしれない必要性は明日、今日、それを必要としませんか? さらに、組織を合併すると、アドレスが衝突すると、大破壊は作成されます。
- Current use of firewalls is an artifact of limitations in the technology. Let's fix the problem, not the symptom.
- ファイアウォールの現在の使用は技術における制限の人工物です。 兆候ではなく、問題を修正しましょう。
- Inter-organization private links do not generate benefit from being any more correct in guessing which machines want to interact than is true for general Internet access.
- 相互組織の個人的なリンクは、どのマシンが相互作用したがっているかを推測するのにおいてそれ以上正しいので、一般的なインターネット・アクセスに本当であるほど利益を生成しません。
This is another point that warrants repetition: the belief that administrators can predict which machines will need Internet access is quite simply wrong. We need to reduce or eliminate the penalties associated with that error, in order to encourage as much Internet connectivity as operational policies and technical security permit. RFC 1597 works very much against this goal.
これは反復を保証するもう1ポイントです: 管理者が、どのマシンがインターネット・アクセスを必要とするかを予測できるという信念は全く単に間違っています。 私たちは、その誤りに関連している刑罰を下げるか、または排除する必要があります、運用政策と技術的なセキュリティが可能にするとき同じくらい多くのインターネットの接続性を奨励するために。 RFC1597はこの目標にたいへん不利に働きます。
Problems With "Advantages" And More Disadvantages
「利点」と、より多くの損失に関する問題
RFC 1597 claims that Classless Inter-Domain Routing (CIDR) will require enterprises to renumber their networks. In the general case, this will only involve those networks that are routed outside of enterprises. Since RFC 1597 addresses private enterprise networks, this argument does not apply.
RFC1597は、Classless Inter-ドメインルート設定(CIDR)が、企業がそれらのネットワークに番号を付け替えさせるのを必要とすると主張します。 一般的な場合では、これは企業の外に発送されるそれらのネットワークにかかわるだけでしょう。 RFC1597が私企業ネットワークに演説するので、この議論は適用されません。
The authors mention that DCHP-based tools [2] might help network number transition. However, it is observed that by and large such tools are currently only "potential" in nature.
作者は、DCHPベースのツール[2]がネットワーク・ナンバー変遷を助けるかもしれないと言及します。 しかしながら、概して、そのようなツールが現在現実に「潜在的であるだけである」と述べられます。
Additionally, with the onslaught of ISDN, slip, and PPP in host implementations, the potential for a workstation to become a router inadvertently has never been greater. Use of a common set of addresses for private networks virtually assures administrators of having their networks partitioned, if they do not take care to carefully control modem connections.
さらに、ホスト導入における、ISDN、メモ用紙、およびPPPの猛攻撃で、ワークステーションがうっかりルータになる可能性は一度もより大きかったことがありません。 一般的なアドレスの私設のネットワークの使用は実際には彼らのネットワークを仕切らせるのを管理者に保証します、慎重にモデム接続を監督するために注意しないなら。
Lear, Fair, Crocker & Kessler [Page 5] RFC 1627 Network 10 Considered Harmful July 1994
1627年のネットワーク10が有害な1994年7月に考えたリア、フェア、クロッカー、およびケスラー[5ページ]RFC
Finally, RFC 1597 implies that it may be simple to change a host's IP address. For a variety of reasons this may not be the case, and it is not the norm today. For example, a host may be well known within a network. It may have long standing services such as NFS, which would cause problems for clients were its address changed. A host may have software licenses locked by IP address. Thus, migrating a host from private to global addressing may prove difficult. At the very least, one should be careful about addressing well known hosts.
最終的に、RFC1597は、ホストのIPアドレスを変えるのが簡単であるかもしれないことを含意します。 さまざまな理由で、これはそうでないかもしれません、そして、今日、それは標準ではありません。 例えば、ホストはネットワークの中で顔が広いかもしれません。 それには、NFSなどの長年のサービスがあるかもしれなくて、アドレスを変えるなら、どれがクライアントのために問題を起こすでしょうか? ホストはIPアドレスでソフトウェアライセンスをロックさせるかもしれません。 したがって、個人的なアドレシングからグローバルなアドレシングまでのホストは、難しいと判明して、移行するかもしれません。 顔が広いホストに演説することに関して少なくとも、慎重であるはずです。
POLICY ISSUES
政策問題
IANA Has Overstepped Their Mandate
IANAは彼らの命令を踏み越えました。
For many years, IANA has followed an assignment policy based on the expectation of Internet connectivity for ALL assignees. As such it serves to encourage interconnectivity. IANA assignment of the network numbers listed in RFC 1597 serves to formally authorize behavior contrary to this accepted practice. Further, this change was effected without benefit of community review and approval.
何年間も、IANAはすべての指定代理人へのインターネットの接続性への期待に基づく課題方針に従っています。 そういうものとして、それは、相互接続性を奨励するのに役立ちます。 RFC1597に記載されたネットワーク・ナンバーのIANA課題は、この慣例とは逆に正式に振舞いを認可するのに役立ちます。 さらに、この変化は共同体レビューと承認の恩恵なしで作用しました。
RFC 1597 specifies a new operational requirement explicitly: network service providers must filter the IANA assigned network numbers listed in RFC 1597 from their routing tables. This address space allocation is permanently removed from being used on the Internet.
RFC1597は明らかに新しい操作上の要件を指定します: ネットワークサービスプロバイダーはRFC1597にそれらの経路指定テーブルから記載されたネットワーク・ナンバーが割り当てられたIANAをフィルターにかけなければなりません。 永久に、インターネットで使用されるのからこのアドレス空間配分を取り除きます。
As we read RFC 1601 [3], this action is not within the purview of IANA, which should only be assigning numbers within the current standards and axioms that underlie the Internet. IP network numbers are assigned uniquely under the assumption that they will be used on the Internet at some future date. Such assignments violate that axiom, and constitute an architectural change to the Internet. RFC 1602 [4] and RFC 1310 [5] also contain identical wording to this effect in the section that describes IANA.
私たちがRFC1601[3]を読むとき、IANAの範囲の中にこの動作はありません。範囲はインターネットの基礎となる現在の規格と原理で中数を割り当てているだけであるはずです。 IPネットワーク・ナンバーは唯一それらがいつかの将来の期日のインターネットで使用されるという仮定で割り当てられます。 そのような課題は、その原理に違反して、インターネットへの建築変化を構成します。 また、RFC1602[4]とRFC1310[5]はこの趣旨でIANAについて説明するセクションに同じ言葉遣いを含んでいます。
While RFC 1597 contains a view worthy of public debate, it is not ready for formal authorization. Hence, we strongly encourage IANA to withdraw its IP address assignments documented by RFC 1597 forthwith.
RFC1597は立会演説にふさわしい眺めを含んでいますが、それは正式認可の準備ができていません。 したがって、私たちは、IANAが直ちにRFC1597によって記録されたIPアドレス課題を引き下がらせるよう強く奨励します。
The IAB should review the address assignment policies and procedures that compose IANA's mandate, and reaffirm the commitment to a globally unique IP address space.
IABはIANAの命令を構成するアドレス課題方針と手順を見直して、グローバルにユニークなIPアドレス空間の委任を再び断言するはずです。
COMMENTS AND CONCLUSIONS
コメントと結論
The Internet technology and service is predicated on a global address space. Members of the Internet community have already experienced and understood the problems and pains associated with uncoordinated private network number assignments. In effect the proposal attempts
インターネット技術とサービスはグローバルアドレススペースで叙述されます。 インターネットコミュニティのメンバーは、既に非調整された個人的なネットワーク・ナンバー課題に関連している問題と苦心を経験して、理解しました。 事実上、提案試み
Lear, Fair, Crocker & Kessler [Page 6] RFC 1627 Network 10 Considered Harmful July 1994
1627年のネットワーク10が有害な1994年7月に考えたリア、フェア、クロッカー、およびケスラー[6ページ]RFC
to codify uncoordinated behavior and alter the accepted Internet addressing model. Hence, it needs to be considered much more thoroughly.
非調整された振舞いを成文化して、受け入れられたインターネットアドレシングを変更するには、モデル化してください。 したがって、それは、はるかに徹底的に考えられる必要があります。
RFC 1597 gives the illusion of remedying a problem, by creating formal structure to a long-standing informal practice. In fact, the structure distracts us from the need to solve these very real problems and does not even provide substantive aid in the near-term.
RFC1597は長年の非公式の習慣にホルマール構造を作成することによって問題を改善する幻想を与えます。 事実上、構造は、これらの非常に本当の問題を解決する必要性から私たちをそらして、短期間実質的な援助を提供さえしません。
In the past we have all dreaded the idea of having any part of the address space re-used. Numerous luminaries have both written and spoke at length, explaining why it is we want direct connections from one host to another. Before straying from the current architectural path, we as a community should revisit the reasoning behind the preaching of unique addressing. While RFC 1597 attempts to change this model, its costs and limitations for enterprises can be enormous, both in the short and long term.
過去に、私たちは皆、アドレス空間のどんな部分も再使用させるという考えを恐れました。 多数の発光体は、書いて、十分話しました、なぜ私たちが、ダイレクト1人のホストから別のホストまでの接続が欲しいと思うということであるかを説明して。 現在の建築経路からはぐれる前に、共同体としての私たちはユニークなアドレシングの説教の後ろで推理を再訪させるべきです。 RFC1597が、このモデルを変えるのを試みる間、企業のためのそのコストと制限は莫大である場合があります、長・短期で両方の、。
REFERENCES
参照
[1] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", T.J. Watson Research Center, IBM Corp., Chrysler Corp., RIPE NCC, RFC 1597, March 1994.
[1] Rekhter、Y.、マスコウィッツ、B.、Karrenberg、D.、およびG.deグルートは「個人的なインターネットのための配分を記述します」、T.J.ワトソン研究所、IBM社、クライスラー社、RIPE NCC、RFC1597、1994年3月。
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, Bucknell University, October 1993.
[2]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC1541、Bucknell大学、1993年10月。
[3] Huitema, C., "Charter of the Internet Architecture Board (IAB)", RFC 1601, IAB, March 1994.
[3]Huitema、C.、「インターネット・アーキテクチャ委員会(IAB)の憲章」、RFC1601、IAB、1994年3月。
[4] Internet Architecture Board, Internet Engineering Steering Group, "The Internet Standards Process -- Revision 2", IAB, IESG, RFC 1602, March 1994.
[4] インターネット・アーキテクチャ委員会、インターネット工学運営グループ、「インターネット規格は処理されます--改正2インチ、IAB、IESG、RFC1602、1994年3月。」
[5] Internet Activities Board, "The Internet Standards Process", RFC 1310, IAB, March 1992.
[5] インターネット活動板、「インターネット標準化過程」、RFC1310、IAB、1992年3月。
[6] Internet Activities Board, "Summary of Internet Architecture Discussion", Notes available from ISI, [ftp.isi.edu: pub/IAB/IABmins.jan91Arch.txt], IAB, January 1991.
[6] インターネットActivities Board、「インターネット構造議論の概要」、ISIから利用可能なNotes、[ftp.isi.edu: パブ/IAB/IABmins.jan91Arch.txt]、IAB、1991年1月。
SECURITY CONSIDERATIONS
セキュリティ問題
See the section, "Security Issues".
セクション、「安全保障問題」を見てください。
Lear, Fair, Crocker & Kessler [Page 7] RFC 1627 Network 10 Considered Harmful July 1994
1627年のネットワーク10が有害な1994年7月に考えたリア、フェア、クロッカー、およびケスラー[7ページ]RFC
AUTHORS' ADDRESSES
作者のアドレス
Eliot Lear Silicon Graphics, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94043-1389
エリオットリア・シリコングラフィックス2011N.海岸線Blvd. マウンテンビュー、カリフォルニア94043-1389
Phone: +1 415 390 2414 EMail: lear@sgi.com
以下に電話をしてください。 +1 2414年の415 390メール: lear@sgi.com
Erik Fair Apple Computer, Inc. 1 Infinite Loop Cupertino, CA 95014
エリック・公正なアップル・コンピューターInc.1無限ループカルパチーノ、カリフォルニア 95014
Phone: +1 408 974 1779 EMail: fair@apple.com
以下に電話をしてください。 +1 1779年の408 974メール: fair@apple.com
Dave Crocker Silicon Graphics, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94043-1389
デーヴ・医者シリコングラフィックス2011N.海岸線Blvd. マウンテンビュー、カリフォルニア94043-1389
Phone: +1 415 390 1804 EMail: dcrocker@sgi.com
以下に電話をしてください。 +1 1804年の415 390メール: dcrocker@sgi.com
Thomas Kessler Sun Microsystems Inc. Mail Stop MTV05-44 2550 Garcia Ave. Mountain View, CA 94043
トーマスケスラーサン・マイクロシステムズメール停止MTV05-44 2550ガルシアAve。 マウンテンビュー、カリフォルニア 94043
Phone: +1 415 336 3145 EMail: kessler@eng.sun.com
以下に電話をしてください。 +1 3145年の415 336メール: kessler@eng.sun.com
Lear, Fair, Crocker & Kessler [Page 8]
リア、フェア、クロッカー、およびケスラー[8ページ]
一覧
スポンサーリンク