RFC1219 日本語訳

1219 On the assignment of subnet numbers. P.F. Tsuchiya. April 1 1991. (Format: TXT=30609 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                        P. Tsuchiya
Request for Comments: 1219                                      Bellcore
                                                              April 1991

Tsuchiyaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 1219 Bellcore1991年4月

                  On the Assignment of Subnet Numbers

サブネット番号の課題に関して

Status Of This Memo

このメモの状態

   This memo suggests a new procedure for assigning subnet numbers.  Use
   of this assignment technique within a network would be a purely local
   matter, and would not effect other networks.  Therefore, the use of
   these procedures is entirely discretionary.

このメモはサブネット番号を割り当てるための新しい手順を示します。 ネットワークの中のこの課題のテクニックの使用は、純粋にローカルの問題であるだろう、他のネットワークに作用しないでしょう。 したがって、これらの手順の使用は完全に任意です。

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

Overview

概観

   RFC-950 [2] specifies a procedure for subnetting Internet addresses
   using a bit-mask.  While RFC-950 allows the "ones" in the subnet mask
   to be non-contiguous, RFC-950 recommends that 1) they be contiguous,
   and 2) that they occupy the most significant bits of the "host" part
   of the internet address.

RFC-950[2]はアドレス使用が少しマスクをかけるサブネッティングインターネットに手順を指定します。 RFC-950が、サブネットマスクの「もの」が非隣接であることを許容しますが、RFC-950がその1つを)推薦する、隣接である、そして、それらがインターネットアドレスの「ホスト」部分を最も多くの重要なビット占領する2)。

   RFC-950 did not specify whether different subnets of the same network
   may have different masks.  This ambiguity was unfortunate, as it
   resulted in development of routing protocols that do not support
   different masks; see e.g., RIP [6].  The Gateway Requirements RFC [7]
   settled the issue in favor of allowing different masks, and therefore
   future routing protocols may be expected to support this feature;
   OSPF [3] is an example.

RFC-950は、同じネットワークの異なったサブネットには異なったマスクがあるかもしれないかどうか指定しませんでした。 異なったマスクを支えないルーティング・プロトコルの開発をもたらしたので、このあいまいさは不幸でした。 例えばRIP[6]を見てください。 異なったマスクを許容することを支持してゲートウェイRequirements RFC[7]は問題に決着をつけました、そして、したがって、将来のルーティング・プロトコルがこの特徴を支持すると予想されるかもしれません。 OSPF[3]は例です。

   The network administrator must of course determine the mask for each
   subnet.  This involves making an estimate of how many hosts each
   subnet is expected to have.  As it is often impossible to predict how
   large each subnet will grow, inefficient choices are often made, with
   some subnets under-utilized, and others possibly requiring
   renumbering because of exceeded capacity.

ネットワーク管理者は各サブネットのためにもちろんマスクを決定しなければなりません。 これは、各サブネットには何人のホストがいると予想されるかに関する見積りをすることを伴います。 各サブネットがどれくらい大きく成長するかを予測するのがしばしば不可能であるので、しばしば効率の悪い選択をします、サブネットが下で利用したいくつか、およびことによると超えられている容量のために番号を付け替えるのを必要とする他のものと共に。

   This memo specifies a procedure for assigning subnet numbers that
   eliminates the need to estimate subnet size.  Essentially, host bits
   (mask = 0) are assigned from the least significant bit working
   towards the most, and subnet bits (mask = 1) are assigned from the
   most significant bit working towards the least.  As subnets grow,
   more host bits are assigned.  As the number of subnets grows, more
   subnet bits are assigned.  While this process does sometimes result

このメモはサブネット番号を割り当てるためのサブネットがサイズであると見積もる必要性を排除する手順を指定します。 本質的には、ホストビット(マスク=0)は大部分に向かって働いている最下位ビットから割り当てられます、そして、サブネットビット(マスク=1)は最少をめざして努力する最も重要なビットから割り当てられます。 サブネットが成長するとき、より多くのホストビットが割り当てられます。 サブネットの数が成長するとき、より多くのサブネットビットが割り当てられます。 この過程は時々結果として生じますが

Tsuchiya                                                        [Page 1]

RFC 1219          On the Assignment of Subnet Numbers         April 1991

サブネット数の1991年4月の課題でのTsuchiya[1ページ]RFC1219

   in new subnet masks, no host ever need change addresses.

新しいサブネットマスクでは、どんなホストもアドレスを変える必要はありません。

   This technique is not new, but it is also not widely known, and even
   less widely implemented.  With the development of new routing
   protocols such as OSPF, it is possible to take full advantage of this
   technique.  The purpose of this memo, then, is to make this technique
   widely known, and to specify it exactly.

このテクニックは新しくはありませんが、それは、また、広く知られないで、また広くそれほど実行されてさえいません。 OSPFなどの新しいルーティング・プロトコルの開発では、このテクニックを最大限に利用するのは可能です。 このメモの目的は、次に、広くこのテクニックを明らかにして、まさにそれを指定することです。

   This memo requires no changes to existing Internet standards.  It
   does, however, require that the intra-domain routing protocol handle
   multiple different subnet masks.

このメモは既存のインターネット標準への変化を全く必要としません。 しかしながら、それは、イントラドメインルーティング・プロトコルが複数の異なったサブネットマスクを扱うのを必要とします。

Acknowledgments

承認

   The author would like to thank Phil Karn, Charles Lynn, Jeff Mogul,
   and Charles Wolverton for their helpful suggestions.  Special thanks
   go to Joel Halpern for his painstaking debugging of the detailed
   specification and the examples.

作者は彼らの役立つ提案についてフィルKarn、チャールズリン、ジェフ・ムガール人、およびチャールズ・ウォルバートンに感謝したがっています。 特別な感謝は彼の仕様詳細と例の勤勉なデバッグのためにジョエル・アルペルンのものになります。

1.  Motivation

1. 動機

   The Subnetting standard, RFC-950, specifies that the Host part of the
   formally 2-level Internet address can be divided into two fields,
   Subnet and Host.  This gives the Internet address a third level of
   hierarchy, and the concomitant firewalls and savings in routing
   overhead.  It also introduces increased inefficiency in the
   allocation of addresses.

Subnetting規格(RFC-950)は、正式に2レベルのインターネット・アドレスのHost部分を2つの分野、Subnet、およびHostに分割できると指定します。 これはルーティングオーバーヘッドにおける第3のレベルの階層構造、並立しているファイアウォール、および貯蓄をインターネット・アドレスに与えます。 また、それはアドレスの配分における増加する非能率を導入します。

   This inefficiency arises from the fact that the network administrator
   typically over-estimates the size (number of hosts) of any single
   subnetwork, in order to prevent future re-addressing of subnets.  It
   may also occur if the routing protocol being used does not handle
   different length subnets, and the administrator must therefore give
   every subnet an amount of space equivalent to that received by the
   largest subnet. (This RFC does not help in the latter case, as the
   technique herein requires different length subnets.)

この非能率はネットワーク管理者がどんな単一のサブネットワークのサイズ(ホストの数)も通常過大評価するという事実から起こります、サブネットの将来の再アドレシングを防ぐために。 また、使用されるルーティング・プロトコルが異なった長さのサブネットを扱わないなら、それは起こるかもしれません、そして、したがって、管理者は最も大きいサブネットによって受け取られたそれに同等なスペースの合計をあらゆるサブネットに与えなければなりません。 (テクニックがここに異なった長さのサブネットを必要とするとき、このRFCは後者の場合で助けません。)

   The administrative hassle associated with changing the subnet
   structure of a network can be considerable.  For instance, consider
   the following case.  A network has three subnets A, B, and C.  Assume
   that the lowest significant byte is the host part, and the next byte
   is the subnet part (that is, the mask is 255.255.255.0).  Assume
   further that A has subnet 1.0, B has subnet 2.0, and C has subnet
   3.0.

ネットワークのサブネット構造を変えると関連している管理苦労は無視できない場合があります。 例えば、以下のケースを考えてください。 すなわち、マスクはそうです。ネットワークが最も低い重要なバイトがホスト部分であり、次のバイトが部分である3サブネットA、B、およびC.Assumeを持っている、サブネット部分、(255.255 .255 .0)。 Bには、サブネット2.0があります、そして、Aにはサブネット1.0があるとさらに仮定してください、そして、Cはサブネット3.0を持っています。

   Now, assume that B grows beyond its allocation of 254 hosts.
   Ideally, we would like to simply change B's mask without changing any
   of the host addresses in B.  However, the subnets numerically above

今度は、Bが254人のホストの配分を超えて成長すると仮定してください。 理想的に、B.Howeverのホスト・アドレスのいずれも変えないで、単にビーズマスクを変えたいと思います、数の上で上のサブネット

Tsuchiya                                                        [Page 2]

RFC 1219          On the Assignment of Subnet Numbers         April 1991

サブネット数の1991年4月の課題でのTsuchiya[2ページ]RFC1219

   and below B are already taken by A and C.  (If say 3.0 was not taken
   by C, B's mask could be changed from 255.0 (ff00) to 254.0 (fe00).
   In this case, all of B's existing addresses would still match the new
   subnet.  Indeed, if non-contiguous masks were in use, it might be
   possible for B to find some other mask bit to change to 0.  However,
   non-contiguous masks are generally not in favor, as they impose
   limitations on certain forwarding table lookup algorithms.  Indeed,
   RFC-950 discourages their use.)

そして、以下のBは既にAとCでかかります。Bがしかしながら、0に変化するようにある他のマスク・ビットを見つけるように、一般に、非隣接のマスクは賛成していません、ある推進索表アルゴリズムに制限を課すとき。たとえば3.0がCで取られないなら、ビーズマスクは255.0(ff00)から254.0(fe00)に変わることができるでしょうに。(本当に、RFC-950が彼らの使用に水をさしているのは、この場合ビーズの既存のアドレスのすべてがまだ新しいサブネットに合っているだろう、本当に、非隣接のマスクが使用中であったなら可能であるかもしれません。)

   So, the choices available to the network administrator are to 1) form
   two subnets out of the existing one, or 2) renumber the subnet so
   that the subnet ends up with a smaller (fewer 1's) mask.  Choice 1
   can either be accomplished physically or logically.  Physically
   forming two subnets requires partitioning the subnet and inserting a
   gateway between the two partitions.  For obvious reasons, this is not
   a desirable course of action.  Logically forming two subnets can be
   done by simply assigning another subnet number (say 4.0) to the same
   subnet, and assigning host addresses under the new subnet.  The
   result of this logical partition is that the hosts with different
   subnet numbers will not recognize that the others are on the same
   subnet, and will send packets to the default gateway rather than
   directly to the host.  In fact, this is not such a bad solution,
   because assuming that the gateway is capable of recognizing multiple
   subnet numbers on the same subnet, the gateway will simply send the
   host an ICMP Redirect [4], and subsequent packets will go directly to
   the host [1] (this may not work correctly on all hosts).

既存のものから2つのサブネットを形成するか、またはしたがって、1には)ネットワーク管理者にとって、利用可能な選択があります。2は、)サブネットが、より小さい(より数1)マスクで終わるように、サブネットに番号を付け替えさせます。 選択1を物理的か論理的に実行できます。 物理的に2つのサブネットを形成するのは、2つのパーティションの間にサブネットを仕切って、ゲートウェイを挿入するのを必要とします。 明白な理由によって、これは望ましい行動ではありません。 単に、別のサブネット番号(4.0を言う)を同じサブネットに割り当てて、新しいサブネットの下でホスト・アドレスを割り当てることによって、2つのサブネットを論理的に形成できます。 この論理的なパーティションの結果は異なったサブネット番号をもっているホストが他のものが同じサブネットにいると認めないで、直接ホストにというよりむしろデフォルトゲートウェイにパケットを送るということです。 事実上、これはそのように悪い解決策ではありません、ゲートウェイが同じサブネットの複数のサブネット番号を認識できると仮定する場合、ゲートウェイが単にICMP Redirect[4]をホストに送って、その後のパケットが直接ホスト[1]のものになるので(これは正しくすべてのホストに働かないかもしれません)。

   If, however, neither choice is acceptable or possible, then the
   network administrator must assign a new subnet number to B, thus
   renumbering the existing hosts, modifying the Domain Name System
   entries, and changing any other configuration files that have
   hardwired addresses for hosts in subnet B.

しかしながら、どちらの選択も許容できるか、または可能でないなら、ネットワーク管理者は新しいサブネット番号をBに割り当てなければなりません、その結果、既存のホストに番号を付け替えさせます、ホストのためにサブネットBでドメインネームシステムエントリーを変更して、アドレスを配線したいかなる他の構成ファイルも変えて。

2. A More Flexible and Efficient Technique for Assigning Subnet Numbers

2. サブネット番号を割り当てるための、よりフレキシブルで効率的なテクニック

   In order to help explain the new technique, we shall show what is
   wrong with what is currently done now.  Currently, most subnets are
   assigned by splitting the host part of the address in two fields; the
   subnet field and the host field.  Mask bits are one for subnet field
   bits, and 0 for host field bits.  (In all of our addresses, the least
   significant bit (LSB) is on the right, the most significant bit (MSB)
   is on the left.)

新しいやり方を説明するのを助けるために、私たちは、現在現在行われることのどこが問題であるかを示すつもりです。 現在、ほとんどのサブネットが2つの分野でアドレスのホスト部分を分けることによって、割り当てられます。 サブネット分野とホスト分野。 マスク・ビットは、サブネット分野ビット1と、ホスト分野ビット0です。 (私たちのアドレスには、全部で、最下位ビット(LSB)が右にあって、最も重要なビット(MSB)が左にあります。)

        MSB                                LSB
        --------------------------------------
       | subnet field    | host field         |
        --------------------------------------

MSB LSB-------------------------------------- | サブネット分野| ホスト分野| --------------------------------------

Tsuchiya                                                        [Page 3]

RFC 1219          On the Assignment of Subnet Numbers         April 1991

サブネット数の1991年4月の課題でのTsuchiya[3ページ]RFC1219

   The subnet field could be different lengths for different size
   subnets.  For instance, say a network had two large subnets and the
   rest small subnets (by large subnet we mean a large number of hosts).
   Then the network administrator might assign two types of addresses:

サブネット分野は異なったサイズサブネットのための異なった長さであるかもしれません。 例えば、ネットワークには2つの大きいサブネットと休息の小さいサブネットがあった(大きいサブネットで、私たちは多くのホストを言っている)と言ってください。 次に、ネットワーク管理者は2つのタイプのアドレスを割り当てるかもしれません:

        --------------------------------------
       | subnet |               host          |  large subnets
        --------------------------------------

-------------------------------------- | サブネット| ホスト| 大きいサブネット--------------------------------------

        --------------------------------------
       |         subnet             |  host   |  small subnets
        --------------------------------------

-------------------------------------- | サブネット| ホスト| 小さいサブネット--------------------------------------

   In this case, the full range of subnet numbers would not be available
   to the small subnets, as the bits in the small subnet that correspond
   to those in the large subnet could not have the same values as those
   in the large subnets.  For instance, say that the large subnets had
   4-bit subnet numbers, and the small subnets had 8-bit subnet numbers.
   If the large subnets had values 0001 and 0010, then subnet numbers in
   the range 00010000 to 00101111 could not be assigned to the small
   subnets, otherwise there will be addresses that would match both
   subnets.

この場合、最大限の範囲のサブネット番号は小さいサブネットに利用可能でないでしょう、小さいサブネットにおける大きいサブネットにおけるそれらに対応するビットが大きいサブネットにおけるそれらと同じ値を持つことができなかったとき。 例えば、大きいサブネットには4ビットのサブネット番号があって、小さいサブネットに8ビットのサブネット番号があったと言ってください。 大きいサブネットに値0001と0010があるなら、範囲00010000〜00101111の当時のサブネット番号を小さいサブネットに割り当てることができないでしょうに。そうでなければ、両方のサブネットに合っているアドレスがあるでしょう。

   In any event, a network administrator will typically assign values to
   the two fields in numerical order.  For example, within a given
   subnet, hosts will be numbered 1, 2, 3, etc.  Within a given network,
   subnets will be numbered 1, 2, 3, etc.  The result is that some
   number of bits on the right side of the subnet and host fields will
   be ones for some hosts and zeros for others, and some number of bits
   on the left side of the subnet and host fields will be zeros for all
   subnets and hosts.  The "all zeros" bits represent room for growth,
   and the "ones and zeros" bits represent bits already consumed by
   growth.

とにかく、ネットワーク管理者は番号順に2つの分野に値を通常割り当てるでしょう。 例えば、与えられたサブネット、ホストの中に、番号付の1、2、3などがあるでしょう。 与えられたネットワークの中では、サブネットは3になるでしょうなど2、番号付の1。 結果はサブネットとホスト分野の右側の何らかの数のビットが他のもののために何人かのホストのためのものとゼロになって、サブネットとホスト分野の左側の何らかの数のビットがすべてのサブネットとホストのためにゼロになるということです。 ビットが表す「すべてのゼロ」は成長、および「ものとゼロ」のために同居します。成長によって消費されて、ビットは既にビットを表します。

        --------------------------------------
       | subnet field    | host field         |
       |-----+-----------+-------+------------|
       |     |           |       |            |
       | 0's | 1's & 0's |  0's  | 1's & 0's  |
          /\                /\
          ||                ||
        subnets can         hosts can grow here
        grow here

-------------------------------------- | サブネット分野| ホスト分野| |-----+-----------+-------+------------| | | | | | | 0| 1と0| 0| 1と0| /\ /\ || || 缶のホストがここで育てることができるサブネットはここで成長します。

   Now, let's assume that the number of hosts in a certain subnet grows
   to the maximum allowed, but that there is still room in the subnet
   field to assign more addresses.  We then have the following:

今、あるサブネットにおける、ホストの数が余地がサブネット分野にまだなかったなら許容された最大に成長して、より多くのアドレスを割り当てると仮定しましょう。 次に、私たちには、以下があります:

Tsuchiya                                                        [Page 4]

RFC 1219          On the Assignment of Subnet Numbers         April 1991

サブネット数の1991年4月の課題でのTsuchiya[4ページ]RFC1219

        --------------------------------------
       | subnet field    | host field         |
       |-----+-----------+--------------------|
       |     |           |                    |
       | 0's | 1's & 0's |     1's & 0's      |

-------------------------------------- | サブネット分野| ホスト分野| |-----+-----------+--------------------| | | | | | 0| 1と0| 1と0|

   While the host field can no longer grow, there is still room in the
   address for growth.  The problem is that because of where the growth
   areas are situated, the remaining growth has been effectively
   reserved for subnets only.

ホスト分野はもう発展できませんが、成長のためのアドレスには余地がまだあります。 問題は成長地域が位置しているところのために、事実上、サブネットだけのために残っている成長を控えてあるということです。

   What should be done instead is to assign subnet numbers so that the
   ones start from the left of the subnet field and work right.  In this
   case we get the following:

代わりにするべきであることは、ものがサブネット分野と仕事権利の左から始めるように、サブネット番号を割り当てることになっています。 この場合、私たちは以下を得ます:

        --------------------------------------
       | subnet field    | host field         |
       |-----------+-------------+------------|
       |           |             |            |
       | 1's & 0's |    0's      | 1's & 0's  |
                         /\
                         ||
                    Both hosts and subnets can
                    grow here

-------------------------------------- | サブネット分野| ホスト分野| |-----------+-------------+------------| | | | | | 1と0| 0| 1と0| /\ || ホストとサブネットの両方がここで成長できます。

   Now, both hosts and subnets individually have considerably more
   growing space than before, although the combined growing space is the
   same.  Since one can rarely predict how many hosts might end up in a
   subnet, or how many subnets there might eventually be, this
   arrangement allows for the maximum flexibility in growth.

今、ホストとサブネットの両方には、以前よりかなり増加しているスペースが個別にあります、結合した増加しているスペースは同じですが。 人が、めったに何人のホストがサブネットで終わるかもしれないか、または結局、いくつのサブネットがあるかもしれないかを予測できないので、このアレンジメントは成長における最大の柔軟性を考慮します。

   Actually, the previous figure is misleading.  The boundary between
   the host and subnet fields is being shown in the middle of the growth
   area.  However, the boundary could exist anywhere within the growth
   area.  Note that it is the mask itself that determines where the
   boundary is.  Ones in the mask indicate subnet bits, and zeros
   indicate host bits.  We will show later that in fact the boundary
   should lie somewhere in the middle.  Putting it there minimizes the
   number of times that the masks must be changed in hosts.

実際に、前の図は紛らわしいです。 ホストとサブネット分野の間の境界は成長地域の中央に示されています。 しかしながら、境界は成長地域の中でどこでも存在できました。 境界がどこにあるかを決定するのが、マスク自体であることに注意してください。 マスクの人はサブネットビットを示します、そして、ゼロはホストビットを示します。 私たちは、後で事実上、境界が中央のどこかに位置するべきであるのを示すつもりです。 それをそこへ置くと、ホストでマスクを変えなければならないという回の数は最小にされます。

   2.1  Specification of the New Technique

2.1 新しいやり方の仕様

   Having given the appropriate explanatory material, we can now specify
   the procedure for subnet number assignment.  We need the following
   definitions:

適切な説明資料を与えたので、私たちは現在、サブネット数の課題のための手順を指定できます。 私たちは以下の定義を必要とします:

   Host-assigned Bits (h-bits):  These are the bits, contiguous from

ビット(h-ビット)をホストと同じくらい割り当てます: これらは、ビットであって、隣接です。

Tsuchiya                                                        [Page 5]

RFC 1219          On the Assignment of Subnet Numbers         April 1991

サブネット数の1991年4月の課題でのTsuchiya[5ページ]RFC1219

      the right, for which host values, within a given subnet, contain
      both ones and zeros.  Different subnets may have different h-bits.

権利。(ホスト値はその権利のために与えられたサブネットの中にものとゼロの両方を含みます)。 異なったサブネットには、異なったh-ビットがあるかもしれません。

   Subnet-assigned Bits (s-bits):  These are the bits, contiguous from
      the left, which 1) are not h-bits, AND 2) are required to
      distinguish one subnet from another, AND 3) include all bits
      to the left of and including the right-most one.  Notice that
      different subnets may have different s-bits.

ビット(s-ビット)をサブネットで割り当てます: これらは左と、1が)h-ビットでない、どれについてAND2)が別のものと1つのサブネットを区別するのに必要であり、AND3)がすべてのビットを左に含んでいるか、そして、最も権利ものを含んでいるのによる隣接のビットです。 異なったサブネットには異なったs-ビットがあるかもしれないのに注意してください。

   Growth Bits (g-bits):  These are the "all zeros" bits in between
      the h-bits and s-bits.

成長ビット(g-ビット): これらがそう、h-ビットとs-ビットの間のビットを「すべてゼロに合わせます」。

   s-mask:  For a given subnet, the mask whereby all s-bits are one,
      and all g-bits and h-bits are zero.

s-マスク: 与えられたサブネット、すべてのs-ビットが1であるマスク、すべてのg-ビット、およびh-ビットがゼロであるので。

   g-mask:  For a given subnet, the mask whereby all s-bits and g-bits
      are one, and all h-bits are zero.

g-マスク: 与えられたサブネット、すべてのs-ビットとg-ビットが1であるマスク、およびすべてのh-ビットがゼロであるので。

   Subnet Field:  These are the one bits in the subnet mask (as
      defined in RFC-950).  These bits are on the left.  The subnet
      field must at least include all of the s-bits, and may
      additionally include some or all of the g-bits.

サブネット分野: これらはサブネットマスクの1ビット(RFC-950で定義されるように)です。 これらのビットが左にあります。 サブネット分野は、優にs-ビットを少なくとも含まなければならなくて、さらに、g-ビットのいくつかかすべてを含むかもしれません。

   Host Field:  These are the zero bits in the subnet mask.
      These bits are on the right.  The host field must at least
      include all of the h-bits, and may additionally include some
      or all of the g-bits.

分野を接待してください: これらはサブネットマスクのゼロ・ビットです。 これらのビットが右にあります。 ホスト分野は、優にh-ビットを少なくとも含まなければならなくて、さらに、g-ビットのいくつかかすべてを含むかもしれません。

   Mirror-image Counting:  Normal counting, in binary, causes one
      bits to start at the right and work left.  This is how host
      values are assigned.  However, for subnet assignment, we want
      the one bits to start at the left and work right.  This process
      is the mirror image of normal counting, where the MSB is swapped
      with the LSB, the second MSB is swapped with the second LSB, and
      so on.  So, where normal counting is:

鏡像勘定: バイナリーで重要である標準で、1ビットはあと右と仕事のときに始動します。 これはホスト値がどう割り当てられるかということです。 しかしながら、サブネット課題のために、私たちは、1ビットが左と仕事右で始動して欲しいと思います。 この過程はMSBがLSBと共に交換されるところで重要である標準の鏡像です、MSBが第2LSBなどで交換される秒に。 それで、正常であるところでは、勘定は以下の通りです。

                0       (reserved to mean "this host")
               01
               10
              011
              100
              101
              :
              :
        11...1110
        11...1111       (reserved to mean "all hosts")

0 (「このホスト」を意味するために、予約されます)01 10 011 100 101: : 11...1110 11...1111 (「すべてのホスト」を意味するために、予約されます)

      and so on, Mirror-image, or MI counting, is:

そして、Mirror-イメージ、またはMIが重要であることで、などは以下の通りです。

Tsuchiya                                                        [Page 6]

RFC 1219          On the Assignment of Subnet Numbers         April 1991

サブネット数の1991年4月の課題でのTsuchiya[6ページ]RFC1219

        0       (reserved to mean "this subnet")
        10
        01
        110
        001
        101
          :
          :
        011...11
        111...11        (reserved to mean "all subnets")

0 (「このサブネット」を意味するために、予約されます)10 01 110 001 101: : 011...11 111...11 (「すべてのサブネット」を意味するために、予約されます)

      and so on.  If the current MI counting value is, say, 001,
      the "next" MI value is 101, and the "previous" MI value is 11.

など。 たとえば、値を数える現在のMIが001であるなら、「次」のMI値は101です、そして、「前」のMI値は11です。

   Now we can specify the algorithm.  We have the following functions:
   Initialize(), AddSubnet(), RemoveSubnet(subnet#), AddHost(subnet#),
   and RemoveHost(subnet#,host#).

今、私たちはアルゴリズムを指定できます。 私たちには、以下の機能があります: ()、AddSubnet()、RemoveSubnet(サブネット#)、AddHost(サブネット#)、およびRemoveHost(サブネット#、ホスト#)を初期化してください。

   Notice that the algorithm is described as though one state machine is
   executing it.  In reality, there may be a root Address Authority
   (RootAA) that assigns subnet numbers (Initialize, AddSubnet, and
   RemoveSubnet), and subnet AA, that assign host numbers within a
   subnet (AddHost and RemoveHost).  While in general the AAs can act
   independently, there are two cases where "coordination" is required
   between the rootAA and a subnetAA.  These are the cases where either
   the rootAA or the subnetAA "grabs" the last growth bit (in the former
   case because another subnet has been added, and in the latter because
   another host has been added).  Since it is impossible for the rootAA
   and a subnetAA to simultaneously grab the last growth bit, either one
   or the other must do it.

まるで1台の州のマシンがそれを実行しているかのようにアルゴリズムが説明されるのに注意してください。 ほんとうは、サブネット番号を割り当てる根のAddress Authority(RootAA)があるかもしれない、(初期化、AddSubnet、およびRemoveSubnet、)、サブネットAA(サブネット(AddHostとRemoveHost)の中のその案配ホスト番号) AAsは一般に単独行動を取ることができますが、2つのケースが「コーディネート」がrootAAとsubnetAAの間で必要であるところにあります。 これらはrootAAかsubnetAAのどちらかが最後の成長ビット(別のホストが加えられて、加えられる、および後者には別のサブネットがあったので前者がケースに入れるコネ)を「つかむ」ケースです。 rootAAとsubnetAAが同時に最後の成長ビットをつかむのが、不可能であるので、どちらかかもう片方がそれをしなければなりません。

   Finally, note that the following C language style notation is used:
        &               bit-wise AND function
        ==              is equal to
        !=              is not equal to
        x-mask(X)       the x-mask of X (where x is s or g)

最終的に、以下のC言語スタイル記法が使用されていることに注意してください: ビット的なAND機能=は=への同輩がXのx-マスクがxマスク(X)と等しくないことであるということです。(xがsかgであるところ)

   Initialize():
      Assign the first subnet value to be 0 (the value reserved to mean
      "this subnet").  This is not assigned to any real subnet.

()を初期化してください: 0である最初のサブネット値(「このサブネット」を意味するために予約された値)を割り当ててください。 これはどんな本当のサブネットにも割り当てられません。

   AddSubnet():
      1.  Find the lowest non-zero (in MI counting) non-assigned subnet
          number S such that (S & g-mask(Y)) != (Y & g-mask(Y)) for all
          existing subnet numbers Y, (Y != S).
      2.  If all bits in S from the rightmost one bit left are ones,
          then label all bits to the left of and including one bit
          position to the right of the rightmost one bit in S to be

AddSubnet(): 1. (Y))=!にgでマスクをかけてください。最も低い非ゼロ(MI勘定における)の非割り当てられたサブネット番号Sにそのようなものを見つけてください、それ、(S、(すべての存在サブネット数のY(Y!=S)のためのYとgマスク(Y))。 2. 残された一番右の1ビットからのSのすべてのビットがものであるなら、1つがSで噛み付いた一番右の右に左へのすべてのビットをラベルして、1つのビット位置を含めてください。

Tsuchiya                                                        [Page 7]

RFC 1219          On the Assignment of Subnet Numbers         April 1991

サブネット数の1991年4月の課題でのTsuchiya[7ページ]RFC1219

          s-bits. Else, label all bits to the left of and including the
          rightmost one bit in S to be s-bits.  This prevents the "all
          ones" value (which is the "all subnets" broadcast address)
          from being assigned to a subnet.  (Since no hosts have been
          added, the rightmost one bit is a subnet bit.)
      3.  Label all other bits in the address to be g-bits.  (By
          address, we mean that part of the IP address not including
          the network number.)
      4.  Set the subnet mask to include at least all s-bits, and
          optionally some g-bits.  The subnet mask must be contiguous.
          (Section 2.2 discusses the pros and cons of choosing a mask.)
      5.  For all existing subnet numbers Y (Y != S):
          51. If (S & s-mask(Y)) == (Y & s-mask(Y)), then:
              511.  Change the leftmost g-bit of Y to an s-bit.  If
                    the rootAA and YAA (the address authority for Y) are
                    separate AAs, then the YAA must be informed of the
                    change of bit status.  If this is the last g-bit,
                    then this change must be coordinated with YAA.
              512.  Expand the subnet mask for all hosts in Y if
                    necessary (that is, if the subnet mask no longer
                    includes all s-bits).

s-ビット。 ほかに、Sで左へのすべてのビットをラベルして、s-ビットになるように一番右の1ビットを含めてください。 これが防ぐ、割り当てられるのからのサブネットへの「すべてのもの」値(放送された「すべてのサブネット」アドレスです)。 (ホストが全く加えられていないので、一番右の1ビットはサブネットビットです。) 3. g-ビットになるようにアドレスを他のすべてのビットをラベルしてください。 (アドレスで、私たちはネットワーク・ナンバーを含まないIPアドレスのその部分を言っています。) 4. サブネットマスクに任意に少なくともすべてのs-ビットを含めるように設定してください。数g-ビット。 サブネットマスクは隣接であるに違いありません。 (セクション2.2はマスクを選ぶ賛否両論について論じます。) 5. すべての既存のサブネット番号Y(Y!はSと等しいです)のために: 51. (Sとsマスク(Y))=、(Yとsマスク(Y))、その時: 511. Yの一番左g-ビットをs-ビットに変えてください。 rootAAとYAA(Yのためのアドレス権威)が別々のAAsであるなら、YAAは噛み付いている状態の変化において知識があるに違いありません。 これが最後のg-ビットであるなら、YAAと共にこの変化を調整しなければなりません。 512. 必要なら、Yのすべてのホストのためにサブネットマスクを広げてください(すなわち、サブネットマスクがもうすべてのs-ビットを含んでいるというわけではないなら)。

   RemoveSubnet(S):
      1.  Consider B to be the bit position of the rightmost s-bit in S.
      2.  Remove S.
      3.  For all existing subnet numbers Y:
          31.  If the bit in position B is not an s-bit, or if the bit
               in bit position B is a one, or if the bit in bit position
               B is a zero and all bits to the left of bit position B
               are ones, then do nothing (skip steps 32 and 33).
          32.  Change the s-bit in position B to a g-bit.
          33.  If for any other existing subnet numbers X
               (X & s-mask(Y)) == (Y & s-mask(Y)), then change the
               g-bit in position B back into an s-bit for Y.  Else,
               inform YAA that of the change of bit status.

RemoveSubnet(S): 1. BがS.2の一番右のs-ビットのビット位置であると考えてください。 S.3を取り除いてください。 すべての既存のサブネット番号Yのために: 31. 位置のBのビットがs-ビットでない、ビット位置Bのビットが1つである、ビット位置Bのビットがゼロであり、またはビット位置Bの左へのすべてのビットがものであるなら、何もしないでください(ステップ32と33をサボってください)。 32. 位置のBでs-ビットをg-ビットに変えてください。 33. Yとsマスク(Y))(当時の位置のBのg-ビットがY.Elseのためにs-ビットに支持する変化)はYAAに知らせます。いかなる他の既存のサブネット番号Xのためにも(Xとsマスク(Y))=、(ビット状態の変化のもの。

   AddHost(S):
      1.  Create an address A consisting of subnet number S concatenated
          with zeros.
      2.  Assign to A the same h-bits, g-bits, and s-bits as the
          other host addresses.
      3.  Find the lowest non-zero (using normal counting) non-assigned
          host number H.
      4.  If all bits from the leftmost one bit to bit position 0 are
          ones, then execute steps 5 and 6 using bit position B equals
          one bit position to the left of the leftmost one bit in H.
          Else, execute steps 5 and 6 with bit position B equals
          the leftmost one bit in H.  This prevents the "all ones" value

AddHost(S): 1. ゼロで連結されたサブネット番号Sから成るアドレスAを作成してください。 2. 他のホスト・アドレスとして同じh-ビット、g-ビット、およびs-ビットをAに割り当ててください。 3. 最も低い非ゼロ(標準を使用するのが数えられて)の非割り当てられたホスト番号にH.4を見つけてください。 すべての一番左1ビットからビット位置0までのビットがものであり、次に、H.ElseでBが1つのビット位置と等しいというビット位置を一番左1ビットの左まで使用するステップ5と6を実行するなら、H.Thisの一番左1ビットが防ぐビット位置B同輩と共にステップ5と6を実行してください、「すべてのもの」は評価します。

Tsuchiya                                                        [Page 8]

RFC 1219          On the Assignment of Subnet Numbers         April 1991

サブネット数の1991年4月の課題でのTsuchiya[8ページ]RFC1219

          (which is the "all hosts" broadcast address) from being
          assigned to a host.
      5.  If bit position B is an s-bit, then the host cannot be added.
          Skip the remaining steps.
      6.  If bit position B is a g-bit:
          61.  Change the g-bit to an h-bit for all hosts in S.  Note
               that if this is the last g-bit, this change must be
               coordinated with the address authority assigning subnet
               numbers (see section 2.2).
          62.  Modify the subnet mask in all hosts if necessary.
      7.  Create a new address A consisting of S concatenated with H
      8.  Assign A to the host.

(放送された「すべてのホスト」アドレスです) 存在から、ホストに割り当てられます。 5. ビット位置Bがs-ビットであるなら、ホストを加えることができません。 残っているステップをサボってください。 6. 噛み付かれるなら、位置のBはg-ビットです: 61. アドレス権威がサブネット番号を割り当てていてこれが最後のg-ビット、この変化であるなら調整しなければならないS.Noteのすべてのホストのためにg-ビットをh-ビットに変えてください(セクション2.2を見てください)。 62. 必要なら、すべてのホストでサブネットマスクを変更してください。 7. H8と共に連結されたSから成る新しいアドレスAを作成してください。 Aをホストに割り当ててください。

   RemoveHost(S,H):
      1.  Remove H.
      2.  If for all remaining host numbers in S, the value of the bit
          position of the leftmost h-bit is zero, and there is a zero in
          at least one of the bit positions to the right of the leftmost
          h-bit, then for all hosts change the leftmost h-bit into a
          g-bit.

RemoveHost(S、H): 1. H.2を取り除いてください。 一番左h-ビットのビット位置の値がSのすべての残っているホスト番号のための、ゼロであり、ゼロが少なくとも一番左h-ビットの右へのビット位置の1つにあれば、すべてのホストに関して、一番左h-ビットをg-ビットに変えてください。

      It is worth noting here that this technique is a 2-level subset of
      the more general n-level kampai addressing [5].  The main
      difference here is that n-level kampai results in non-contiguous
      masks, while 2-level does not.  In the description of kampai
      addressing in [5], g-bits are called a-bits, h-bits are called
      g-bits, and s-bits are called i-bits.

ここでこのテクニックが[5]を記述するより一般的なn-レベルkampaiの2レベルの部分集合であることに注意する価値があります。 ここの主な違いはn-レベルkampaiが非隣接のマスクをもたらしますが、2レベルがそうしないということです。 [5]のkampaiアドレシングの記述では、g-ビットは1ビットであると呼ばれます、そして、h-ビットはg-ビットと呼ばれます、そして、s-ビットはi-ビットと呼ばれます。

   2.2  An Example

2.2 例

   For this example, we assume a class C network, so we will only need
   to work with 8 bits.  We start with 3 subnets, A, B, and C.  Our
   nomenclature is h for h-bit and g for g-bit.  Note that h-bits can be
   one or zero, but g-bits are all zero.  The remaining bits are s-bits,
   but are shown as 1's and 0's according to the subnet number
   assignment.  The space is just to make the addresses and masks easier
   to read.  Finally, we number our bits 0 to 7 from right to left as
   shown below.

この例に関しては、クラスCネットワークを思って、私たちは、8ビットで働く必要があるだけです。 A、B、およびC.Our用語体系は、私たちが3サブネットから始まって、h-ビットhとg-ビットgです。 h-ビットが1かゼロであるかもしれませんが、g-ビットがすべてゼロであることに注意してください。 残っているビットは、s-ビットですが、1とサブネット数の課題に従った0として見せられます。 スペースはまさしくアドレスとマスクを読むのをより簡単にすることです。 最終的に、私たちは左への権利からビットに0〜7に以下に示すように付番します。

        Subnet  Address         Mask
        A       10gg ghhh       1111 0000
        B       01gg ghhh       1111 0000
        C       110g ghhh       1111 0000
            bit 7       bit 0

サブネットAddress Mask A10gg ghhh1111 0000B01gg ghhh1111 0000C110g ghhh1111 0000は7ビット0に噛み付きました。

   We see that each subnet has at most 6 hosts (because of the three h-
   bits).  Notice that we have chosen the masks so that there is room
   for growth in both hosts and subnets without requiring a mask change.

私たちは、各サブネットがほとんどの6人のホスト(3hビットによる)に攻撃するのがわかります。 私たちが成長の余地がホストとサブネットの両方にマスク変化を必要としないであるようにマスクを選んだのに注意してください。

Tsuchiya                                                        [Page 9]

RFC 1219          On the Assignment of Subnet Numbers         April 1991

サブネット数の1991年4月の課題でのTsuchiya[9ページ]RFC1219

   However, we have generally allowed for more growth in subnets than in
   hosts because adding new subnets can cause mask changes in existing
   subnets, while adding new hosts in a subnet only causes that subnet's
   mask to change.

しかしながら、新しいサブネットが新しいホストを加えている間の既存のサブネットにおけるマスク変化を引き起こす場合があると言い足して、そのサブネットのマスクがサブネットで変化するだけであるので、一般に、私たちはサブネットにおけるホストより多くの成長を考慮しました。

   Further, if a subnet's mask must change, but not all hosts are
   reconfigured at the same time, then it is less damaging if the not
   yet reconfigured hosts have too large a mask (too many ones) than if
   they have too small a mask.  This is because with too large a mask, a
   host may think that another host which is in fact on the subnet is on
   another subnet.  In this case, the host will send packets to the
   gateway, and will be redirected to the host.

サブネットのマスクが変化しなければなりませんが、すべてのホストが同時に再構成されるというわけではないならまだ再構成されなかったホストが大き過ぎるマスク(あまりに多くのもの)を持っているならさらに、ダメージが大きくない、それらに小さ過ぎるマスクがあるなら。 これはホストが、大き過ぎるマスクでそうする別のホストが別のサブネットで事実上、サブネットでそうであると考えるかもしれないからです。 この場合、ホストは、パケットをゲートウェイに送って、ホストに向け直されるでしょう。

   However, with too small a mask, a host may think that another host
   which is in fact not on the subnet is on the subnet, and will ARP for
   that host but receive no reply.  (Note that broadcasts may fail if
   all masks do not match.)

しかしながら、小さ過ぎるマスクで、ホストは、事実上、そうする別のホストがサブネットでサブネットでそうでないと考えるかもしれません、そして、それのためのARPは回答を全く接待しますが、受け取らないでしょうか? (すべてのマスクが合っているというわけではないなら放送が失敗するかもしれないことに注意してください。)

   Finally, notice that subnet C requires three s-bits instead of just
   two.  This is because with just two, the subnet address of C could be
   "11" (rather than "110"), which is a broadcast value.  Step 2 of
   AddSubnet checks for this case.

最終的に、サブネットCがちょうど2の代わりに3ビットを必要とするのに注意してください。 これはCのサブネットアドレスがちょうど2による「放送値は何11インチ(「110」よりむしろ)も、どれです」であるかもしれないかからです。 AddSubnetのステップ2はこのような場合チェックします。

   Now, a fourth subnet, D, also with 6 hosts, is added.  We get:

現在、4番目のサブネット(6人のホストをもってもD)は加えられます。 私たちは以下を得ます。

        Subnet  Addr            Mask
        A       10gg ghhh       1111 0000
        B       01gg ghhh       1111 0000
        C       110g ghhh       1111 0000
        D       001g ghhh       1111 0000

サブネットAddr Mask A10gg ghhh1111 0000B01gg ghhh1111 0000C110g ghhh1111 0000D001g ghhh1111 0000

   Notice that none of the original subnets required a change in any of
   their status bits.  This is because, when D compared its subnet
   number with the others (step 5 of AddSubnet(), using the s-mask),
   they were all different.  In other words, a router would be able to
   distinguish an address in D from addresses in A, B, and C.

オリジナルのサブネットのいずれもそれらのステータスビットのどれかにおける変化を必要としなかったのに注意してください。 これはDが他のもの(s-マスクを使用するAddSubnet()のステップ5)とサブネット番号を比べたとき、彼らが皆、異なっていたからです。 言い換えれば、ルータはA、B、およびCでアドレスとDのアドレスを区別できるでしょう。

   Next, a fifth subnet, E, is added.  We get:

次に、5番目のサブネット(E)は加えられます。 私たちは以下を得ます。

        Subnet  Addr            Mask
        A       100g ghhh       1111 0000
        B       01gg ghhh       1111 0000
        C       110g ghhh       1111 0000
        D       001g ghhh       1111 0000
        E       101g ghhh       1111 0000

サブネットAddr Mask A100g ghhh1111 0000B01gg ghhh1111 0000C110g ghhh1111 0000D001g ghhh1111 0000E101g ghhh1111 0000

   Notice that this time, A was forced to change its leftmost g-bit (bit
   5) into an s-bit, because bit 5 is needed to distinguish subnet A

今回Aがやむを得ず、一番左g-ビット(ビット5)をs-ビットに変えたのに注意してください、ビット5がサブネットAを区別するのが必要であるので

Tsuchiya                                                       [Page 10]

RFC 1219          On the Assignment of Subnet Numbers         April 1991

サブネット数の1991年4月の課題でのTsuchiya[10ページ]RFC1219

   from subnet E (step 511 of AddSubnet()).  Changing bit 5 into an s-
   bit prevents hosts from being added to A to the point where bit 5
   would be changed into a one (that is, step 5 of AddHost() would
   fail).

サブネットE、(511AddSubnet())を踏んでください。 sビットへの変化ビット5のために、ホストはビット5が1つに変わる(すなわち、AddHost()のステップ5は失敗するでしょう)ところで肝心のAに加えることができません。

   Notice also that if the masks in A, B, and C were originally set to
   1100.0000, then the addition of E would have caused A's mask to
   change to 1110.0000 (Step 512 of AddSubnet()).

また、A、B、およびCのマスクが元々1100.0000に設定されたならAのマスクがEの添加で1110.0000に変化したのに注意してください。(512AddSubnet())を踏んでください。

   Next, 8 hosts each are added to subnets A and C, thus causing the
   right-most g-bit in each to change to an h-bit.

次に、それぞれ8人のホストがサブネットAとCに加えられます、その結果、中の最も権利g-ビットがそれぞれh-ビットに変化することを引き起こします。

        Subnet  Addr            Mask
        A       100g hhhh       1111 0000
        B       01gg ghhh       1111 0000
        C       110g hhhh       1111 0000
        D       001g ghhh       1111 0000
        E       101g ghhh       1111 0000

サブネットAddr Mask A100g hhhh1111 0000B01gg ghhh1111 0000C110g hhhh1111 0000D001g ghhh1111 0000E101g ghhh1111 0000

   Notice again that no masks have changed.  If the masks for A, B, and
   C were originally set to 1111 1000, then they would have required
   changing (step 62 of AddHost()).

マスクが全く変化していないのにもう一度注意してください。 A、B、およびCマスクが元々1111 1000に設定されたなら、彼らは釣り銭がいたでしょう。(AddHost())のステップ62。

   Next, enough hosts are added to subnet B that all of its remaining
   g-bits become h-bits.

次の、そして、十分なホストはサブネットBに加えられます。優に残っているg-ビットは何h-ビットもなります。

        Subnet  Addr            Mask
        A       100g hhhh       1111 0000
        B       01hh hhhh       1100 0000
        C       110g hhhh       1111 0000
        D       001g ghhh       1111 0000
        E       101g ghhh       1111 0000

サブネットAddr Mask A100g hhhh1111 0000B01hh hhhh1100 0000C110g hhhh1111 0000D001g ghhh1111 0000E101g ghhh1111 0000

   Notice here that the masks in B's subnet had to be changed to
   accommodate the new h-bits (step 62 of AddHost()).  Notice also that
   if the person assigning host addresses for B (B Address Authority, or
   BAA) is different than the person assigning network numbers (RootAA),
   then BAA must coordinate the change of its last g-bit to an h-bit
   with the RootAA.  This allows the RootAA to properly assign
   additional subnet numbers, as in the next step, where we add another
   subnet F:

ここでビーズサブネットにおけるマスクが新しいh-ビットを収容するのが変えられなければならなかったのに注意してください。(AddHost())のステップ62。 また、B(B Address Authority、またはBAA)のためのホスト・アドレスを割り当てる人がネットワーク・ナンバー(RootAA)を割り当てる人と異なるならBAAがRootAAと共に最後のg-ビットのh-ビットへの変化を調整しなければならないのに注意してください。 これで、RootAAは適切に追加サブネット番号を割り当てることができます、次のステップのように:(そこでは、私たちが別のサブネットFを加えます)。

        Subnet  Addr            Mask
        A       100g hhhh       1111 0000
        B       01hh hhhh       1100 0000
        C       110g hhhh       1111 0000
        D       001g ghhh       1111 0000
        E       101g ghhh       1111 0000

サブネットAddr Mask A100g hhhh1111 0000B01hh hhhh1100 0000C110g hhhh1111 0000D001g ghhh1111 0000E101g ghhh1111 0000

Tsuchiya                                                       [Page 11]

RFC 1219          On the Assignment of Subnet Numbers         April 1991

サブネット数の1991年4月の課題でのTsuchiya[11ページ]RFC1219

        F       1110 ghhh       1111 0000

F1110ghhh1111 0000

   Notice that F received subnet number 1110 rather than subnet number
   011 (which is what comes after 101 in MI counting).  The reason is
   that 1) 011 is not distinguishable from B's subnet address using B's
   mask, and 2) we can't increase B's mask to make it distinguishable
   because B has already assigned hosts at bit position 5.  In other
   words, when the comparison of step 1 in AddSubnet() was tried on
   number 011, the two values were equal, and so the next number was
   tried.  In fact, no subnet numbers with 01 in bit positions 7 and 6
   can be assigned (unless B loses hosts).

FがサブネットNo.011(MI勘定で101に続くことです)よりむしろサブネットNo.1110を受け取ったのに注意してください。 理由はその1つです)。 011はビーズサブネットアドレスからビーズマスクを使用することで区別可能ではありません、そして、私たちがビーズマスクを増加させることができない2で、)Bがビット位置5で既にホストを選任したので、それは区別可能になります。 言い換えれば、AddSubnet()でのステップ1の比較がNo.011で試みられたとき2つの値が等しかったので、次の数は試みられました。 事実上、01がビット位置7と6にあるサブネット番号を全く割り当てることができません(Bがホストを失わない場合)。

   Next, subnet E is removed:

次に、サブネットEを取り除きます:

        Subnet  Addr            Mask
        A       10gg hhhh       1111 0000
        B       01hh hhhh       1100 0000
        C       110g hhhh       1111 0000
        D       001g ghhh       1111 0000
        F       1110 ghhh       1111 0000

サブネットAddr Mask A10gg hhhh1111 0000B01hh hhhh1100 0000C110g hhhh1111 0000D001g ghhh1111 0000F1110ghhh1111 0000

   Notice that this caused subnet A to change an s-bit back into a g-
   bit.  This is because the equality of step 33 of RemoveSubnet() did
   not hold true for subnet A with respect to the remaining subnets.

サブネットAがこれでs-ビットのgビットにもとに戻ったのに注意してください。 これはRemoveSubnet()のステップ33の平等が残っているサブネットに関してサブネットAに当てはまらなかったからです。

References

参照

   [1] Braden, R., "Requirements for Internet Hosts -- Communication
       Layers", RFC 1122, USC/Information Sciences Institute, October
       1989.

[1] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、RFC1122、科学が設けるUSC/情報、10月1989日

   [2] Mogul, J., and J. Postel, "Internet Standard Subnetting
       Procedure", RFC 950, USC/Information Sciences Institute, August
       1985.

[2] ムガール人、J.とJ.ポステル、「インターネットの標準のサブネッティング手順」、RFC950、科学が1985年8月に設けるUSC/情報。

   [3] Moy, J., "OSPF Specification", RFC 1131, Proteon, October 1989.

[3]Moy、J.、「OSPF仕様」、RFC1131、Proteon、1989年10月。

   [4] Postel, J., "Internet Control Message Protocol", RFC 792,
       USC/Information Sciences Institute, September 1981.

[4] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、RFC792、科学が1981年9月に設けるUSC/情報。

   [5] Tsuchiya, P., "Efficient and Flexible Hierarchical Address
       Assignment", TM-ARH-018495, Bellcore, February 1991.

[5]Tsuchiya、P.、「効率的でフレキシブルな階層的なアドレス課題」、TM-ARH-018495、Bellcore、1991年2月。

   [6] Hedrick, C., "Routing Information Protocol" RFC 1058, Rutgers
       University, June 1988.

[6] ヘドリック、C.、「ルーティング情報プロトコル」RFC1058、ラトガース大学、1988年6月。

   [7] Braden, R., and J. Postel, "Requirements for Internet Gateways",
       RFC 1009, USC/Information Sciences Institute, June 1987.

[7] ブレーデン、R.とJ.ポステル、「インターネットゲートウェイのための要件」RFC1009、科学が1987年6月に設けるUSC/情報。

Tsuchiya                                                       [Page 12]

RFC 1219          On the Assignment of Subnet Numbers         April 1991

サブネット数の1991年4月の課題でのTsuchiya[12ページ]RFC1219

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

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

Author's Address

作者のアドレス

   Paul F. Tsuchiya
   Bellcore
   435 South St.5 South St.
   MRE 2L-281
   Morristown, NJ 07960

MRE 2L-281モリスタウン、ポールF.Tsuchiya Bellcore435の南St.5南通りニュージャージー 07960

   Phone: 201 829-4484

以下に電話をしてください。 201 829-4484

   EMail: tsuchiya@thumper.bellcore.com

メール: tsuchiya@thumper.bellcore.com

Tsuchiya                                                       [Page 13]

Tsuchiya[13ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

border-colorの既定値とtransparent値に対応する色が#000000になっている

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る