RFC1681 日本語訳
1681 On Many Addresses per Host. S. Bellovin. August 1994. (Format: TXT=11964 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Bellovin Request for Comments: 1681 AT&T Bell Laboratories Category: Informational August 1994
Bellovinがコメントのために要求するワーキンググループS.をネットワークでつないでください: 大西洋標準時1681とTベル研究所カテゴリ: 情報の1994年8月
On Many Addresses per Host
多くの1ホストあたりのアドレスに関して
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.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。
Overview and Rational
概要的で合理的です。
Currently, most hosts have only one address. With comparatively rare exceptions, hosts as hosts -- as opposed to hosts acting as routers or PPP servers -- are single-homed. Our address space calculations reflect this; we are assuming that we can estimate the size of the address space by counting hosts. But this may be a serious error. I suggest that that model may -- and should -- change.
現在、ほとんどのホストには、1つのアドレスしかありません。 ルータかPPPサーバとして務めているホストと対照的にホストがいるので、比較的まれな例外と共に、ホストはシングル家へ帰りました。 私たちのアドレス空間計算はこれを反映します。 私たちは、ホストを数えることによってアドレス空間のサイズを見積もることができると思っています。 しかし、これは重大な誤りであるかもしれません。 私は、そのモデルが変化して、変化するべきであると示唆します。
For the ideas outlined below, I do not claim that multiple addresses per host is the only or even necessarily the best way to accomplish the goal. I do claim that my ideas are at the very least plausible, and that I expect that many of them will be tried.
以下に概説されていて、複数の1ホストあたりのアドレスがクレームでないのにもかかわらずの、私がするという考えには、ずっと目標を達成するのは必ず最も良くさえあります。 私は私の考えが少なくとももっともらしく、それらの多くが試みられると予想すると主張します。
Encoding Services
サービスをコード化します。
More and more often, services are being encoded in the host name. One can fetch files from ftp.research.att.com, look up an IP address on ns.uu.net, synchronize clocks from ntp.udel.edu, etc. Should this practice be generalized to the IP address domain?
ますますしばしば、サービスはホスト名でコード化されています。 1つは、ftp.research.att.comからファイルをとって来て、ns.uu.netでIPアドレスを調べて、ntp.udel.eduから時計を連動させることができますなど。 この習慣はIPアドレスドメインに一般化されるべきですか?
In some cases it would be a very good idea. Certain services need to be configured by IP address; they are either used when the DNS is being bootstrapped (such as in glue records and root server cache records), or when its unavailable (i.e., when booting after a power hit, and the local name servers are slower to reboot than their diskless clients.
いくつかの場合、それは非常に良い考えでしょう。 あるサービスは、IPアドレスによって構成される必要があります。 DNSが独力で進まれるとき(接着剤記録やルートサーバーキャッシュ記録などの)、それらは使用されて、すなわち、パワーの後にブートするときには当たって、それがいつ入手できないかは遅いです。(地方名サーバはリブートするのが彼らのディスクレスクライアントより遅いです。
Bellovin [Page 1] RFC 1681 On Many Addresses per Host August 1994
多くのホスト1994年8月あたりのアドレスのBellovin[1ページ]RFC1681
Security is another reason, in some cases. Address-based authentication is bad enough; relying on the name service adds another layer of risk. An attacker can go after the DNS, in that case. A risk-averse system manager might prefer to avoid the extra exposure, instead granting privileges (i.e., rlogin or NFS) by address instead of name. But that, of course, leads to all the usual headaches when the location of the service changes. If the address for the service could be held constant, there would be much more freedom to move it to another machine. One way to do that is by assigning the serving host a secondary address.
セキュリティはいくつかのケースの中の別の理由です。 アドレスベースの認証は十分悪いです。 サービスという名前を当てにすると、別の層の危険は加えます。 攻撃者はその場合DNSを追いかけることができます。 リスクを嫌うシステム・マネージャは、付加的な暴露を避けるのを好むかもしれません、代わりに、名前の代わりにアドレスで、特権(すなわち、rloginかNFS)を与えて。 しかし、サービスの位置が変化するとき、それはもちろんすべての普通の頭痛に通じます。 サービスのためのアドレスを一定であるとして保持できるなら、それを別のマシンに動かすずっと多くの自由があるでしょうに。 それをする1つの方法はセカンダリアドレスを給仕のホストに割り当てることです。
A related notion comes from the need to offer different views of a service from a single host. For example, research.att.com has long offered two distinct FTP archives, with slightly different access policies. It would be nice if both could live on the same machine, without asking the user community to learn new protocols or custom port numbers.
関連する概念は独身のホストと異なったサービスの意見を提供する必要性から来ます。 例えば、research.att.comは長い間、わずかに異なったアクセス方針で2個の異なったFTPアーカイブを提供しています。 両方が同じマシンで生きることができるなら、良いでしょうに、新しいプロトコルかカスタムポートナンバーを学ぶようにユーザーコミュニティに頼まない。
Archie is an even better example. There are three principal ways to use Archie: use a special protocol, and hence a special application program, on a dedicated port and host that is probably named archie.foo.bar; telnet to archie.foo.bar and go through an extra and gratuitous login as archie, or telnet to some special port on archie.foo.bar. The latter two are examples of using a standard protocol (telnet) to offer a different service. Neither alternative is very convenient.
アーチーはさらに良い例です。 アーチーを使用する3つの主要な方法があります: たぶんarchie.foo.barと命名されていた状態で特別なプロトコルを使用して、したがって、専用ポートとホストに関する特別なアプリケーション・プログラムを使用してください。 archieとしての付加的で無料のログインによるarchie.foo.barと碁へのtelnet、またはarchie.foo.barの上のいくらかの特別なポートへのtelnet。 後者の2は異なったサービスを提供するのに標準プロトコル(telnet)を使用する例です。 どちらの選択肢もそれほど便利ではありません。
It would be better if archie.foo.bar provided the Archie service, while host.foo.bar provided a login prompt. Again -- an easy way to do this is to assign the host a separate IP address for its extra service.
archie.foo.barがアーチーサービスを提供するなら、より良いでしょうにが、host.foo.barはログインプロンプトを提供しました。 一方、これをする簡単な方法は追加サービスのための別々のIPアドレスをホストに割り当てることです。
Note that there are security advantages here, too. A firewall could be configured to allow access to the address associated with the Archie server, but not the other addresses on that host. That would provide a high degree of safety, assuming, of course, that the other servers on that host were bound to its primary addresses, and not the exposed address.
ここのセキュリティ上の利点もあることに注意してください。 そのホストに関する他のアドレスではなく、アーチーサーバに関連しているアドレスへのアクセスを許すためにファイアウォールを構成できました。 それは高い安全度を提供するでしょう、もちろんそのホストの上の他のサーバが暴露しているアドレスではなく、そのプライマリアドレスに縛られたと仮定して。
Another way to implement this concept would be to extend the DNS, to return port number information as well as IP addresses. Thus, netlib.att.com might return 192.20.225.3/221. But that would necessitate changing every FTP client program, a daunting task.
この概念を実装する別の方法はIPアドレスと同様にポートナンバー情報を返すためにDNSを広げるだろうことです。 したがって、netlib.att.comは192.20に.225.3/に221を返すかもしれません。 しかし、それは、あらゆるFTPクライアントプログラム、困難な仕事を変えるのを必要とするでしょう。
We could also look on this as the extension of the MX concept. MX records are very valuable, but they apply only to mail, and they don't supply port numbers. Again, changing this would require massive client program changes.
また、私たちは、これをMX概念の拡大と見なすことができました。 メールだけに適用します、そして、MX記録は非常に貴重ですが、それらはポートナンバーを供給しません。 一方、これを変えるのは大規模なクライアントプログラム変化を必要とするでしょう。
Bellovin [Page 2] RFC 1681 On Many Addresses per Host August 1994
多くのホスト1994年8月あたりのアドレスのBellovin[2ページ]RFC1681
Accounting and Billing
会計と支払い
For better or worse, some parts of the Internet are moving towards usage-sensitive charging. At least four charging schemes seem possible; doubtless, the marketeers in charge of such things can and will come up with more.
のるかそるか、インターネットのいくつかの地域が用法敏感な充電に近づいています。 少なくとも4つの充電体系が可能に思えます。 そのようなもの担当の市場商人は、確かに、思いつくことができて、以上を思いつくでしょう。
The first is the traditional "pay as you go" approach. Each host is responsible for its own packets. Of course, that means that in a typical conversation, both parties pay -- and the providers of free FTP archives will end up paying dearly for their beneficence. That leads to our second model: caller pays. Other people might want to make collect calls, much as is done on the telephone today. Finally, there might be the equivalent of American "900" numbers: the caller pays a premium to the server.
1番目は「現金で支払ってください」という伝統的なアプローチです。 それぞれのホストはそれ自身のパケットに責任があります。 もちろん、それは典型的な会話では、双方が支払うことを意味します、そして、無料のFTPアーカイブのプロバイダーは結局、彼らの善行のために多大の犠牲を払うでしょう。 それは私たちの2番目のモデルに通じます: 訪問者は支払います。 他の人々は今日電話の上でするようにコレクトコールをしたがっているかもしれません。 最終的に、「900」アメリカの番号の同等物があるかもしれません: 訪問者はプレミアムをサーバに支払います。
This is not at all far-fetched; UUNET already has a 900 number for anonymous uucp clients. No need to register in advance; just dial in, and let the phone company act as your agent.
これは全くこじつけではありません。 UUNETには、匿名のuucpクライアントの900番号が既にあります。 あらかじめ登録する必要性がありません。 ただ直通電話にかけてください、そして、エージェントとして電話会社法をさせてください。
Given all these schemes, it is vital that the caller and recipient know in advance who will pay. It is not acceptable for users to learn, only after the fact, that they have incurred a cost. We could envision use of IP options, but again, that would preclude use of today's standard clients.
これらのすべての体系を考えて、訪問者と受取人が、あらかじめだれが支払うかを知っているのは、重大です。 ユーザが、事実の後にだけ彼らが費用を被ったことを学ぶのは、許容できません。 私たちはIPオプションの使用を思い描くことができましたが、一方、それは今日の標準のクライアントの使用を排除するでしょう。
It is not sufficient to present a message at connection time warning of the charges. Many interactions do not provide a hook for user interaction. And there are security concerns -- suppose that someone puts up a gopher server that redirects a caller to some pay-to-play address, without displaying the required warning. A scam? Sure -- but it's already happened with the phone network, and I see no reason to think that the Internet will be far behind.
充電に関する接続時間警告でメッセージを提示するのは十分ではありません。 多くの相互作用はユーザ相互作用にフックを提供しません。 そして、安全上の配慮があります--だれかが何らかのプレーする賃金アドレスに訪問者を向け直すリスサーバを提供すると仮定してください、必要な警告を表示しないで。 詐欺? 勿論--それは電話ネットワークと共に既に起こりました、そして、私はインターネットが遠いと考える後ろの理由が全くわかりません。
My suggestion, of course, is to encode the charge algorithm in the destination address (and perhaps in the DNS name space as well). The bits themselves would determine who pays. Organizational border routers could implement policies on pay services; the anonymous workstations in a dorm computer lab wouldn't be allowed to call collect.
私の提案はもちろん送付先アドレス(そして恐らくまた、スペースというDNS名で)の充電アルゴリズムをコード化することです。 ビット自体は、だれが支払うかを決定するでしょう。 組織的な境界ルータは有料サービスに関する政策を実施するかもしれません。 寮のコンピュータ室の匿名のワークステーションは料金先方払いに呼ぶことができないでしょう。
An extension of this scheme would use a comparatively large number of bits, letting the address act not just as a policy indicator, but also as an index to a charge algorithm table.
この体系の拡大は比較的多くのビットを使用するでしょう、アドレスが方針インディケータとして機能するだけではなく、インデックスとしても充電アルゴリズムテーブルに機能して。
Bellovin [Page 3] RFC 1681 On Many Addresses per Host August 1994
多くのホスト1994年8月あたりのアドレスのBellovin[3ページ]RFC1681
Addresses per User
1ユーザあたりのアドレス
It may be useful to assign each user on a host a separate IP address, for the duration of the login session. This has a number of advantages.
ホストの上の各ユーザに別々のIPアドレスを割り当てるのは役に立つかもしれません、ログインセッションの持続時間のために。 これには、多くの利点があります。
The first ties in with the charging scheme given above. Usage- sensitive accounting today is done by routers, and they have no notion of who is using the hosts. If each user had a separate IP address, we could continue to gather the accounting data at the router. The host would simply have to record the address assignments; billing could be done offline.
充電体系と共に上に与えることにおける最初の結びつき。 ルータで今日の用法の敏感な会計をします、そして、それらには、だれがホストを使用するかに関する考えが全くありません。 各ユーザに別々のIPアドレスがあるなら、私たちは、ルータで会計データを集め続けることができるでしょうに。 ホストは単にアドレス課題を記録しなければならないでしょう。 支払いがオフラインでできました。
Similarly, different classes of users could have different forms of addresses. Those with hard-money accounts might have some bits set in the address that would allow for access to costly services. The border routers could make this sort of distinction, using today's technology.
同様に、異なったクラスのユーザは異なったフォームのアドレスを持つことができました。 兌換紙幣の口座があるもので、高価なサービスへのアクセスを考慮するアドレスに数ビットを設定するかもしれません。 境界ルータは今日の技術を使用して、この種類の区別をするかもしれません。
An IP address per user also fits in well with encryption. There is a lot of attention today focused on network-layer encryption. But that provides host-level granularity of protection, which is sometimes insufficient. Transport-layer encryptors provide finer-grained protection, but does the Internet need two different low-level encryption schemes? If each user had a separate IP address -- and perhaps had it only on hosts that cared about such matters -- we could provide user-level protection and accounability, with the same infrastructure used to support host-level accountability.
また、1ユーザあたり1つのIPアドレスが暗号化とよく合っています。 今日ネットワーク層暗号化に焦点を合わせられている多くの注意があります。 しかし、それは保護のホストレベル粒状を提供します。(保護は時々不十分です)。 トランスポート層暗号化する人は、よりきめ細かに粒状の保護を提供しますが、インターネットは2つの異なった低レベルである暗号化体系を必要としますか? 各ユーザが別々のIPアドレスを持っていて、恐らくそのような件を心配したホストだけの上にそれを持っているなら、私たちはユーザレベルの保護とaccounabilityを提供できるでしょうに、同じインフラストラクチャがホストレベル責任をサポートするのに使用されている状態で。
Low-Grade Mobility
下級の移動性
There are several schemes under discussion for mobile IP hosts. These are aimed at a fairly general model of hosts moving anywhere. While that is important, there is also some need for limited mobility, within a subnet. This could be used for load-balancing. A mail relay that had just been asked to send a large message to a huge mailing list could offload some of its IP addresses to its peers. That would divert future incoming messages without invalidating thousands of cached MX records and their associated IP addresses. Similarly, servers for low-speed X terminals could reside on different physical machines, all the while not disturbing sessions in progress.
いくつかの体系がモバイルIPホストのために議論であります。 これらはどこでも移行するホストのかなり一般的なモデルを対象にします。 それは重要ですが、また、サブネットの中に限られた移動性の何らかの必要があります。 ロードバランシングにこれを使用できました。 大きいメッセージを膨大なメーリングリストに送るようにちょうど頼まれたメール中継はIPアドレスのいくつかを同輩へ積み下ろすかもしれません。 何千ものキャッシュされたMX記録とそれらの関連IPアドレスを無効にしないで、それは将来の入力メッセージを紛らすでしょう。 同様に、ずっと進行中のセッションを擾乱しないで、低速Xターミナルのためのサーバは異なった物理的なマシンの上にあることができました。
Merging Subnets
サブネットを合併します。
There has long been some need to merge subnets. Sometimes this is due to organizational changes; other times, people have installed bridges when routers would have been a more appropriate choice. Some
長く、サブネットを合併する何らかの必要がありました。 時々、これは組織変動のためです。 ルータが、より適切な選択であっただろうというときに、他の回であり、人々はブリッジをインストールしました。 いくつか
Bellovin [Page 4] RFC 1681 On Many Addresses per Host August 1994
多くのホスト1994年8月あたりのアドレスのBellovin[4ページ]RFC1681
hosts need to live on both logical networks at once, to avoid an extra hop through a router. It would be useful to be able to assign them such addresses.
ホストは、すぐに、両方の論理的なネットワークで生活して、ルータを通して付加的なホップを避ける必要があります。 そのようなアドレスをそれらに割り当てることができるのは役に立つでしょう。
How Many Addresses Do We Need?
私たちはいくつのアドレスを必要としますか?
Assuming that some of these ideas bear fruit, how many addresses do we need, per host?
これらの考えのいくつかが実を結ぶと仮定して、私たちはホスト単位でいくつのアドレスを必要としますか?
Most of these schemes are fairly cheap. Few people would offer more than a handful of distinct service views per system. But the address-per-user notion could be quite costly. We also have to account for address mask assignment policies. In many of today's networks, enough bits of host address have to be allocated to allow for the largest subnet in an organization. Even if we assume that IPng's routing protocols will be smarter about such things, foresight in address allocation will be needed to allow headroom for some networks to grow, while still maintaining a contiguous netmask. This in turn will contribute to sparse utilization of the address space. Accordingly, I recommend that we allow for 2^6, and perhaps as many as 2^8, extra addresses per host, to leave room for the ideas presented here.
これらの体系の大部分はかなり安いです。 一握りの1システムあたりの異なったサービス視点以上を提供する人々は少ないでしょう。 しかし、1ユーザあたりのアドレス概念はかなり高価であるかもしれません。 また、私たちはアドレスマスク課題方針を説明しなければなりません。 今日のネットワークの多くでは、組織で最も大きいサブネットを考慮するためにホスト・アドレスの十分なビットを割り当てなければなりません。 私たちが、IPngのルーティング・プロトコルがそのようなものに関して、より賢くなると思っても、アドレス配分における先見が、いくつかのネットワークが成長する空間を許容するのにまだ隣接のネットマスクを維持している間、必要でしょう。 これは順番にアドレス空間のまばらな利用に貢献するでしょう。 それに従って、私たちが2^6、および最大恐らく2^8を考慮することを勧めます、1ホストあたりの付加的なアドレス、考えの余地がここに提示した休暇に。
I should note that the idea of encoding the service in the transport address bears some relation to OSI's model. That similarity should not, of course, invalidate the idea.
私は、輸送アドレスにおけるサービスをコード化するという考えがOSIのモデルとの何らかの関係を持っていることに注意するべきです。 その類似性はもちろん考えを無効にするべきではありません。
Acknowledgements
承認
Some of these ideas were derived from conversations with Matt Blaze.
マットBlazeとの会話からこれらの考えのいくつかを得ました。
Security Considerations
セキュリティ問題
Security issues are discussed throughout this memo.
このメモ中で安全保障問題について議論します。
Author's Address
作者のアドレス
Steven M. Bellovin Software Engineering Research Department AT&T Bell Laboratories 600 Mountain Avenue Murray Hill, NJ 07974, USA
マリー・ヒル、スティーブンM.Bellovinソフトウェア工学調査部AT&Tベル研究所600山のAvenueニュージャージー 07974、米国
Phone: +1 908-582-5886 Fax: +1 908-582-3063 EMail: smb@research.att.com
以下に電話をしてください。 +1 908-582-5886Fax: +1 908-582-3063 メールしてください: smb@research.att.com
Bellovin [Page 5]
Bellovin[5ページ]
一覧
スポンサーリンク