RFC1715 日本語訳

Network Working Group                                         C. Huitema
Request for Comments:  1715                                        INRIA
Category: Informational                                    November 1994

Huitemaがコメントのために要求するワーキンググループC.をネットワークでつないでください: 1715年のINRIAカテゴリ: 情報の1994年11月

             The H Ratio for Address Assignment Efficiency

アドレス課題効率のためのH比

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 author and/or the sipp@sunroof.eng.sun.com mailing
   list.

RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 作者、そして/または、 sipp@sunroof.eng.sun.com メーリングリストにコメントを提出するべきです。

Table of Contents

目次

   1.   Efficiency of address assignment . . . . . . . . . . . . . . 1
   2.   Estimating reasonable values for the ratio H . . . . . . . . 2
   3.   Evaluating proposed address plans. . . . . . . . . . . . . . 3
   4.   Security Considerations . . . . . . . . . . . . . . . . . .  4
   5.   Author's Address . . . . . . . . . . . . . . . . . . . . . . 4

1. アドレス課題. . . . . . . . . . . . . . 1 2の効率。 妥当な推計は比率のためにH. . . . . . . . 2 3を評価します。 評価はアドレスプランを提案しました。 . . . . . . . . . . . . . 3 4. セキュリティ問題. . . . . . . . . . . . . . . . . . 4 5。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 4

1. Efficiency of address assignment

1. アドレス課題の効率

   A substantial part of the "IPng" debate was devoted to the choice of
   an address size. A recurring concept was that of "assignment
   efficiency", which most people involved in the discussion expressed
   as a the ratio of the effective number of systems in the network over
   the theoretical maximum. For example, the 32 bits IP addressing plan
   could in theory number over 7 billions of systems; as of today, we
   have about 3.5 millions of addresses reported in the DNS, which would
   translate in an efficiency of 0.05%.

"IPng"討論のかなりの部分がアドレスサイズの選択にささげられました。 再発概念はほとんどの人々が中でかかわった「課題効率」では議論がaとして理論上の最大の上にネットワークにおける、システムの有効な数の比率を表したということでした。 例えば、32ビットのIPアドレシングプランは理論上10億台のNo.より多くの7システムをそうすることができました。 今日現在、私たちはDNSでアドレスのおよそ3.5の数百万を報告させます。(DNSは0.05%の効率で翻訳するでしょう)。

Huitema                                                         [Page 1]

RFC 1715                        H Ratio                    November 1994

1715時間のHuitema[1ページ]RFC比率1994年11月

   But this classic evaluation is misleading, as it does not take into
   account the number of hierarchical elements. IP addresses, for
   example, have at least three degrees of hierarchy: network, subnet
   and host.  In order to remove these dependencies, I propose to use a
   logarithmic scale for the efficiency ratio:

しかし、階層的な要素の数を考慮に入れないとき、この古典的な評価は紛らわしいです。 IPアドレスには、例えば、少なくとも3段階の階層構造があります: ネットワーク、サブネット、およびホスト。 これらの依存を取り除くために、私は、効率比に対数目盛を使用するよう提案します:

                             log (number of objects)
                         H = -----------------------
                                  available bits

ログ(物の数)H=----------------------- 有効なビット

   The ratio H is not too dependent of the number of hierarchical
   levels. Suppose for example that we have the choice between two
   levels, encoded on 8 bits each, and one single level, encoded in 16
   bits. We will obtain the same efficiency if we allocate in average
   100 elements at each 8 bits level, or simply 10000 elements in the
   single 16 bits level.

比率Hは階層レベルの数でそれほど依存していません。 例えば、私たちがそれぞれ、および1つのただ一つのレベルが16ビットでコード化した8ビットの上でコード化された2つのレベルの間に選択を持っていると仮定してください。 平均した100の要素に各8ビットでレベル、または単に16ビットのただ一つのレベルの10000の要素を割り当てるなら、私たちは同じ効率を得るつもりです。

   Note that I use base 10 logs in what follows, because they are easier
   to compute mentally. When it comes to large numbers, people tend to
   use "powers of 10", as in "IPng should be capable of numbering 1 E+15
   systems". It follows from this choice of units that H varies between
   0 and a theoretical maximum of 0.30103 (log base 10 of 2).

私が精神的に計算するのが、より簡単であるので続くことにベース10ログを使用することに注意してください。 大きい数のこととなると、人々は使用の傾向があります。「10インチ「IPngは1E+15のシステムに付番できるべきである」ように、動かします」。 ユニットのこの選択から、Hが00.30103(2のログベース10)の理論上の最大の間で異なるということになります。

2. Estimating reasonable values for the ratio H:

2. 妥当な推計は比率のためにHを評価します:

   Indeed, we don't expect to achieve a ratio of 0.3 in practice, and
   the interesting question is to assert the values which can be
   reasonably expected. We can try to evaluate them from existing
   numbering plans. What is especially interesting is to consider the
   moment where the plans broke, i.e. when people were forced to add
   digits to phone number, or to add bits to computer addresses. I have
   a number of such figures handy, e.g.:

本当に、私たちは実際には0.3の比率を達成すると予想しません、そして、面白い質問は合理的に予想できる値について断言することです。 私たちは、プランに付番しながら存在するので、それらを評価しようとすることができます。 プランが壊れたところで特におもしろいことは瞬間を考えることになっています、すなわち、ケタを電話番号に追加するか、または人々がやむを得ずコンピュータアドレスにビットを追加したときに時。 私は例えばそのような多くの数字を便利にします:

   * Adding one digit to all French telephone numbers, moving from 8
     digits to 9, when the number of phones reached a threshold of 1.0
     E+7. The log value is 7, the number of bits was about 27 (1 decimal
     digit is about 3.3 bits). The ratio is thus 0.26

* 電話の数が1.0E+7の敷居に達したとき、8ケタから9まで動いて、すべてのフランスの電話番号への1ケタを加えます。 ログ値が7である、ビットの数はおよそ27(1つの10進数字がおよそ3.3ビットである)でした。 その結果、比率は0.26です。

   * Expending the number of areas in the US telephone system, making it
     effectively 10 digits long, for about 1.0 E+8 subscribers. The log
     value is 8, the number of bits is 33, the ratio is about 0.24

* およそ1.0E+8の加入者のために長い間それを事実上10ケタにして、米国電話の領域の数を費やします。 ログ値が8である、ビットの数が33である、比率はおよそ0.24です。

   * Expending the size of the Internet addresses, from 32 bits to
     something else. There are currently about 3 million hosts on the
     net, for 32 bits. The log of 3.E6 is about 6.5; this gives a ratio
     of 0.20. Indeed, we believe that 32 bits will still be enough for
     some years, e.g. to multiply the number of hosts by 10, in which
     case the ratio would climb to 0.23

* インターネットのサイズを費やすと、32から、ビットは他の何かに記述されます。 およそ300万人のホストが現在、32ビットネットにいます。 3.E6に関するログはおよそ6.5です。 これは0.20の比率を与えます。 本当に、私たちは32ビットが数年間まだ十分になっていると信じています、例えば、その場合、10、比率にホストの数を掛けるのが0.23に登るでしょう。

Huitema                                                         [Page 2]

RFC 1715                        H Ratio                    November 1994

1715時間のHuitema[2ページ]RFC比率1994年11月

   * Expending the size of the SITA 7 characters address. According to
     their documentation, they have about 64000 addressed points in
     their network, scattered in 1200 cities, 180 countries. An upper
     case character provides about 5 bits of addressing, which results
     in an efficiency of 0.14. This is an extreme case, as SITA uses
     fixed length tokens in its hierarchy.

* サイタ7キャラクタアドレスのサイズを費やします。 自分達のドキュメンテーションによると、彼らは1200の都市、180の国に点在する自分達のネットワークで記述されたおよそ64000ポイントを持っています。 大文字キャラクタは0.14の効率をもたらすアドレシングの5ビットに関して提供します。 サイタが階層構造に固定長象徴を使用するとき、これは極端なそうです。

   * The globally-connected physics/space science DECnet (Phase IV)
     stopped growing at about 15K nodes (i.e. new nodes were hidden)
     which in a 16 bit space gives a ratio of 0.26

* 16ビットのスペースで0.26の比率を与えるおよそ15Kのノードで成長するのが止められたグローバルに接続された物理学/宇宙科学DECnet(フェーズIV)(すなわち、新しいノードは隠されました)

   * There are about 200 million IEEE 802 nodes in a 46 bit space, which
     gives a ratio of 0.18. That number space, however, is not
     saturated.

* およそ2億IEEE802ノードが46ビットのスペースにあります。(それは、0.18の比率を与えます)。 しかしながら、その数のスペースは飽和していません。

   From these examples, we can assert that the efficiency ratio usually
   lies between 0.14 and 0.26.

これらの例から、私たちは、通常、効率比が0.14〜0.26にあると断言できます。

3. Evaluating proposed address plans

3. 評価はアドレスプランを提案しました。

   Using a reverse computation, we get the following population counts
   in the network:

逆の計算を使用して、私たちはネットワークで以下の人口カウントを得ます:

                    Pessimistic (0.14)     Optimistic (0.26)

悲観的な(0.14)、楽観的(0.26)

      32 bits             3 E+4 (!)           2 E+8
      64 bits             9 E+8               4 E+16
      80 bits           1.6 E+11            2.6 E+27
     128 bits             8 E+17              2 E+33

3 32ビットE+4の(!) 2E+8 64ビット9E+8 4E+16 80ビット1.6E+11 2.6E+27 128ビット8E+17 2E+33

   I guess that the figure explains well why some feel that 64 bits is
   "not enough" while other feel it is "sufficient by a large margin":
   depending of the assignment efficiency, we are either well below the
   target or well above. But there is no question, in my view, that 128
   bits is "more than enough". Even if we presume the lowest efficiency,
   we are still way above the hyperbolic estimate of 1.E+15 Internet
   hosts.

私は、図が、或るものが、なぜ64ビットが他の感じである間「十分でない」と感じるかを「大きな利鞘で、十分な」状態でよく説明すると推測します: 課題効率をよって、私たちはよく目標かよく上のどちらかにいます。 しかし、128ビットが「十二分に十分である」という私の意見には質問が全くありません。 最も低い効率を推定しても、まだずっと1.E+15インターネット・ホストの大げさな見積りより上には私たちがいます。

   It is also interesting to note that if we devote 80 bits to the
   "network" and use 48 bits for "server less autoconfiguration", we can
   number more that E.11 networks in the pessimistic case - it would
   only take an efficiency of 0.15 to reach the E+12 networks hyperbole.

また、「ネットワーク」に80ビットをささげて、「サーバの、より少ない自動構成」に48ビットを使用するなら、私たちはE.11が悲観的な場合でネットワークでつなぐ以上に付番できます--E+12に達するのに0.15の効率を要するだけであることに注意する関心があるのが誇張をネットワークでつなぐということです。

   I guess this explains well why I feel that 128 bits is entirely safe
   for the next 30 year. The level of constraints that we will have to
   incorporate in the address assignment appears very much in line with
   what we know how to do, today.

私は、私が、なぜ128ビットが次の30年間完全に安全であると感じるかがこれでよくわかると推測します。 私たちがアドレス課題で盛込まなければならないという規制のレベルはどのようにがする私たちが知っていることに沿ってたいへん現れます、今日。

Huitema                                                         [Page 3]

RFC 1715                        H Ratio                    November 1994

1715時間のHuitema[3ページ]RFC比率1994年11月

4.  Security Considerations

4. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

5. Author's Address

5. 作者のアドレス

   Christian Huitema
   INRIA, Sophia-Antipolis
   2004 Route des Lucioles
   BP 109
   F-06561 Valbonne Cedex
   France

クリスチャンのHuitema INRIA、2004台のソフィア-Antipolis Route desルシオールBP109F-06561Valbonne Cedexフランス

   Phone: +33 93 65 77 15
   EMail: Christian.Huitema@MIRSA.INRIA.FR

以下に電話をしてください。 +33 93 65 77 15はメールされます: Christian.Huitema@MIRSA.INRIA.FR

Huitema                                                         [Page 4]

Huitema[4ページ]