RFC932 日本語訳

Network Working Group                                     David D. Clark
Request for Comments: 932                                       MIT, LCS
                                                            January 1985

コメントを求めるワーキンググループデヴィッドD.クラークの要求をネットワークでつないでください: 932 MIT、LCS1985年1月

                     A SUBNETWORK ADDRESSING SCHEME

サブネットワークアドレシング体系

STATUS OF THIS MEMO

このメモの状態

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。

INTRODUCTION

序論

   Several recent RFCs have discussed the need for a "subnet" structure
   within the internet addressing scheme, and have proposed strategies
   for "subnetwork" addressing and routing.  In particular, Jeff Mogul
   in his RFC-917, "Internet Subnets", describes an addressing scheme in
   which a variable number of the leading bits of the host portion of
   the address are used to identify the subnet.  The drawback to this
   scheme is that it is necessary to modify the host implementation in
   order to implement it.  While the modification is a simple one, it is
   necessary to retrofit it into all implementations, including those
   which are already in the field. (See RFC-917 by Mogul for various
   alternative approaches to this problem, such as using Address
   Resolution Protocol.)

数個の最近のRFCsがインターネットアドレシング体系の中で「サブネット」構造の必要性について議論して、「サブネットワーク」アドレシングとルーティングのために戦略を提案しました。 特に、「インターネットサブネット」という彼のRFC-917のジェフ・ムガール人はアドレスのホスト部分の主なビットの可変数がサブネットを特定するのに使用されるアドレシング体系について説明します。 この体系への欠点はホスト導入を変更するのがそれを実装するのに必要であるということです。 変更は簡単なものですが、すべての実装にそれを改装するのが必要です、その分野に既にあるものを含んでいて。 (ムガール人はAddress Resolutionプロトコルを使用などなどのこの問題への様々な代替的アプローチに関してRFC-917を見てください。)

   This RFC proposes an alternative addressing scheme for subnets which,
   in most cases, requires no modification to host software whatsoever.
   The drawbacks of this scheme are that the total number of subnets in
   any one network are limited, and that modification is required to all
   gateways.

このRFCはサブネットの多くの場合、全くソフトウェアをホスティングするために変更を全く必要としない代替のアドレシング体系を提案します。この体系の欠点はどんなネットワークでも、サブネットの総数が限られていて、変更がすべてのゲートウェイに必要であるということです。

THE PROPOSAL

提案

   In this scheme, the individual subnets of a network are numbered
   using Class C addresses.  Since it is necessary with this scheme that
   a Class C address used to number a subnet be distinguishable from a
   Class C address used to number an isolated network, we will reserve
   for subnetworks the upper half of the Class C address space, in other
   words all those Class C addresses for which the high order bit is on.
   When a network is to be organized as a series of subnetworks, a block
   of these reserved Class C addresses will be assigned to that network,
   specifically a block of 256 addresses having the two first bytes
   identical.  Thus, the various subnetworks of a network are
   distinguished by the third byte of the Internet address.  (This
   addressing scheme implies the limitation that there can only be 256
   subnetworks in a net.  If more networks are required, two blocks will
   have to be allocated, and the total viewed as two separate networks.)

この体系では、ネットワークの個々のサブネットは、Class Cアドレスを使用することで番号付です。 サブネットに付番するのに使用されるClass Cアドレスが孤立しているネットワークに付番するのに使用されるClass Cアドレスから区別可能であることがこの体系によって必要であるので、私たちはサブネットワークのためにClass Cアドレス空間(言い換えれば、高位のビットがオンであるそれらのすべてのClass Cアドレス)の上半分を予約するつもりです。 ネットワークが一連のサブネットワークとして組織化されることになっているとき、これらの予約されたClass Cアドレスの1ブロックがそのネットワーク(明確に2/1バイトを同じにする256のアドレスのブロック)に配属されるでしょう。 したがって、ネットワークの様々なサブネットワークはインターネット・アドレスの3番目のバイトによって区別されます。 (この扱っている体系は制限を含意します。ネットには256のサブネットワークしかあることができません。 より多くのネットワークが必要であるなら、2ブロックが、割り当てて2がネットワークを切り離すので見られた合計にならなければならないでしょう。)

Clark                                                           [Page 1]

クラーク[1ページ]

RFC 932                                                     January 1985
A Subnetwork Addressing Scheme

サブネットワークアドレシング体系あたりのRFC932 1985年1月

   The gateways and hosts attached to this subnetted network use these
   addresses as ordinary Class C addresses.  Thus, no modification to
   any host software is required for hosts attached to a subnetwork.

ゲートウェイとホストは普通のClass Cアドレスとしてこのサブネット化したネットワーク使用にこれらのアドレスを添付しました。 したがって、どんなホストソフトウェアへの変更も全くサブネットワークに付けられたホストに必要ではありません。

   For gateways not directly attached to the subnetted network, it is an
   unacceptable burden to separately store the routing information to
   each of the subnets. The goal of any subnet addressing scheme is to
   provide a strategy by which distant gateways can store routing
   information for the network as a whole.  In this scheme, since the
   first two bytes of the address is the same for every subnet in the
   network, those first two bytes can be stored and manipulated as if
   they are a single Class B address by a distant gateway. These
   addresses, which can be used either as a Class B or Class C address
   as appropriate, have been informally called Class "B 1/2" addresses.

直接サブネット化したネットワークに取り付けられなかったゲートウェイに関しては、別々にそれぞれのサブネットとしてルーティング情報を保存するのは、容認できない負担です。 どんなサブネットアドレシング体系の目標も遠方のゲートウェイが全体でネットワークのためのルーティング情報を保存できる戦略を提供することです。 この体系では、ネットワークにおけるあらゆるサブネットに、アドレスの最初の2バイトが同じであるので、まるでそれらが遠方のゲートウェイのそばのただ一つのClass Bアドレスであるかのようにそれらの最初の2バイトを保存して、操ることができます。 これらのアドレス(Class BかClass Cアドレスとして適宜使用できる)は非公式にClass「B1/2インチアドレス」と呼ばれました。

   In more detail, a gateway would treat Class C addresses as follows
   under the scheme.  First, test to see whether the high order bit of
   the address is on.  If not, the address is an ordinary Class C
   address and should be treated as such.

さらに詳細に、ゲートウェイは体系の下で以下のClass Cアドレスを扱うでしょう。 まず最初に、テストして、アドレスの高位のビットがオンであるかどうか確認してください。 まして、アドレスは、普通のClass Cアドレスであり、そういうものとして扱われるべきです。

   If the bit is on, this Class C address identifies a subnet of a
   network.  Test to see if this gateway is attached to that network.
   If so, treat the address as an ordinary Class C address.

ビットがオンであるなら、このClass Cアドレスはネットワークのサブネットを特定します。 テストして、このゲートウェイがそのネットワークに取り付けられるかどうかを見てください。 そうだとすれば、普通のClass Cアドレスとしてアドレスを扱ってください。

   If the gateway is not attached to the network containing that
   subnetwork, discard the third byte of the Class C address and treat
   the resulting two bytes as a Class B address.  Note that there can be
   no conflict between this two-byte pattern and an ordinary Class B
   address, because the first bits of this address are not those of a
   valid Class B address, but rather those of a Class C address.

ゲートウェイがそのサブネットワークを含むネットワークに取り付けられないなら、Class Cアドレスの3番目のバイトを捨ててください、そして、Class Bアドレスとして結果として起こる2バイトを扱ってください。 この2バイトのパターンと普通のClass Bアドレスとの闘争が全くあるはずがないことに注意してください、このアドレスの最初のビットが有効なClass Bアドレスのものではなく、むしろClass Cアドレスのものであるので。

OPTIMIZATIONS

最適化

   If a network grows to more than 256 subnetworks, it will be necessary
   to design two distinct blocks of special Class C addresses, and to
   view this aggregate as two separate networks.  However, the gateways
   of these two networks can, by proper design, run a joint routing
   algorithm which maintains optimal routes between the two halves, even
   if they are connected together by a number of gateways.

ネットワークが256以上のサブネットワークまで成長すると、2つの特別なClass異なったCアドレスを設計して、2つの別々のネットワークであるとこの集合をみなすのが必要でしょう。 しかしながら、適切なデザインで、これらの2つのネットワークのゲートウェイは2つの半分の間の最適のルートを維持する共同ルーティング・アルゴリズムを実行できます、それらが多くのゲートウェイによって一緒に接続されても。

   Indeed, in general it is possible for gateways that are not directly
   attached to a subnetworked network to be specially programmed to
   remember the individual Class C addresses, if doing so provides
   greatly improved network efficiency in some particular case.

本当に、一般に、直接「副-ネットワーク」のネットワークに取り付けられないゲートウェイのために特に、そうするならCが扱う個々のClassを覚えているようにプログラムされるのが大いに改良されたネットワーク効率を何らかの特定のケースに供給するのは、可能です。

   It was stated earlier that no modification to the host software is
   necessary to implement this scheme.  There is one case in which a

より早くホストソフトウェアへのどんな変更もこの体系を実装するのに必要でないと述べられました。 あるケースがどのaであるか。

Clark                                                           [Page 2]

クラーク[2ページ]

RFC 932                                                     January 1985
A Subnetwork Addressing Scheme

サブネットワークアドレシング体系あたりのRFC932 1985年1月

   minor modification may prove helpful.  Consider the case of a distant
   host, not immediately attached to this subnetworked network.  That
   host, even though at a distance, will nonetheless maintain separate
   routing entries for each of the distinct subnetwork addresses about
   which it has any knowledge.  For most hosts, storing this information
   for each subnet represents no problem, because most implementations
   do not try to remember routing information about every network
   address in the Internet, but only those addresses that are of current
   interest.  If, however, for some reason the host has a table which
   attempts to remember routing information about every Internet address
   it has ever seen, than that host should be programmed to understand
   the gateway's algorithm for collapsing the addresses of distant
   subnets from three bytes to two.  However, it is not a recommended
   implementation strategy for the host to maintain this degree of
   routing information, so under normal circumstances, the host need not
   be concerned with the C to B conversion.

小さい方の変更は役立っていると判明するかもしれません。 すぐに、この「副-ネットワーク」のネットワークに付くのではなく、冷ややかなホストのケースを考えてください。 離れたままが、そのホストはそれにもかかわらず、それがどんな知識も持っているそれぞれの異なったサブネットワークアドレスのための別々のルーティングエントリーを維持するでしょう。 ほとんどのホストに関しては、各サブネットのためのこの情報を保存するのは問題を全く表しません、ほとんどの実装がインターネットのあらゆるネットワーク・アドレスのルーティング情報、しかし、それらの現在、おもしろいアドレスだけを覚えていようとしないので。 しかしながら、ある理由でホストがテーブルを持っているなら、そのホストであるべきであるよりそれが今までに見たことがあるあらゆるインターネット・アドレスの情報を発送したと思い出すどの試みが3バイトから2まで遠方のサブネットのアドレスを潰すためのゲートウェイのアルゴリズムを理解するようにプログラムされます。 しかしながら、ホストがこの度合いのルーティング情報を保守するのが、お勧めの実装戦略でないので、通常の状況下で、ホストはB変換へのCに関係がある必要はありません。

DRAWBACK

欠点

   The major drawback of this scheme is that any implementation storing
   large tables of addresses must be changed to know the "B 1/2"
   conversion rule. Most importantly, all gateways must be programmed to
   know this rule.  Thus, adoption of this scheme will require a
   scheduled mandatory change by every gateway implementation.  The
   difficulty of organizing this is unknown.

この体系の主要な欠点は「B1/2インチ変換規則」を知るためにアドレスの大きいテーブルを保存するどんな実装も変えなければならないということです。 最も重要に、この規則を知るようにすべてのゲートウェイをプログラムしなければなりません。 したがって、この体系の採用はあらゆるゲートウェイ実装で予定されている義務的な変化を必要とするでしょう。 これを組織化するという困難は未知です。

OTHER VARIATIONS

他の変化

   It is possible to imagine other variations on the patterns of
   collapsing addresses.  For example, 256 Class B addresses could be
   gathered together and collapsed into one Class A address.  However,
   since the first three bits of the resulting Class A address would be
   constrained, this would permit only 32 such subnetted networks to
   exist.  A more interesting alternative would be to permit the
   collapse of Class C addresses into a single Class A address.  It is
   not entirely obvious the best way of organizing the sub-fields of
   this address, but this combination would permit a few very large nets
   of subnets to be assembled within the Internet.

崩れているアドレスのパターンの他の変化を想像するのは可能です。 例えば、1Class Aのアドレスまで256Class Bのアドレスを集めて、潰すことができました。 結果として起こるClass Aアドレスの最初の3ビットは抑制されるでしょう、しかしながら、したがって、これがそのような32人のサブネット化したネットワークだけが存在することを許可するでしょう。 よりおもしろい代替手段はClass Cアドレスの崩壊をただ一つのClass Aアドレスに可能にするだろうことです。 このアドレスのサブ分野を組織化する最も良い方法、この組み合わせだけがサブネットのいくつかの非常に大きいネットがインターネットの中で組み立てられることを許可するのは、完全に明白ではありません。

   The most interesting variation of "B 1/2" addresses is to increase
   the number of bits used to identify the subnet by taking bits from
   the resulting Class B address.  For example, if 10 bits were used to
   identify the subnet (providing 1024 subnets per network), then the
   gateway, when forming the equivalent address, would not only drop the
   third byte but also mask the last two bits of the B address.  Since
   the first three bits of the address are constrained, this would leave
   13 bits for the network number, or 8192 possible subnetworked

「B1/2インチアドレスは結果として起こるクラスBアドレスから何ビットも取ることによってサブネットを特定するのに使用されるビットの数を増強することです」の最もおもしろい変化。 同等なアドレスを形成するとき、例えば、10ビットがサブネット(1ネットワークあたりの1024サブネットを提供する)を特定するのに使用されるなら、ゲートウェイは3番目のバイトを下げるだけではなく、Bアドレスの最後の2ビットにマスクをかけもするでしょうに。 アドレスの最初の3ビットが強制的である、これが13ビットをネットワーク・ナンバーに残すだろうか、または可能な8192が「副-ネットワーク」であったので

Clark                                                           [Page 3]

クラーク[3ページ]

RFC 932                                                     January 1985
A Subnetwork Addressing Scheme

サブネットワークアドレシング体系あたりのRFC932 1985年1月

   networks.  This number is not as large as would be desirable, so it
   is clear that selecting the size of the subnet field is an important
   compromise.

ネットワーク。 この数が望ましいだろうというほど大きくないので、サブネット分野のサイズを選択するのが、重要な感染であることは明確です。

   Danny Cohen has suggested that this scheme should be fully
   generalized so that the boundaries between the network, subnetwork,
   and host field be arbitrarily movable.  The problem in such a
   generalization is to determine how the gateway is to maintain the
   table or algorithm which permits the collapsing of the address to
   occur.  This RFC proposes that, in the short run, only one single
   form of "B 1/2" addresses be implemented as an Internet subnet
   standard.

ダニー・コーエンは、この体系がネットワークと、サブネットワークと、ホスト分野の間の境界が任意にそうである完全に一般化されたそう可動であるべきであると示唆しました。 そのような一般化における問題はゲートウェイがアドレスの微片が起こるのを可能にするテーブルかアルゴリズムを維持することになっている方法を決定することです。 短期的にはあるシングルだけが形成するこのRFCが提案する、「B1/2インチが扱う、インターネットサブネット規格として実装されてください、」

Clark                                                           [Page 4]

クラーク[4ページ]