RFC940 日本語訳

Network Working Group                                               GADS
Request for Comments: 940 
                                                              April 1985

ネットワークワーキンググループ突き棒はコメントのために以下を要求します。 940 1985年4月

           Toward an Internet Standard Scheme for Subnetting

サブネッティングのインターネットの標準の体系に向かって

STATUS OF THIS MEMO

このメモの状態

   This RFC discusses standardizing the protocol used in subnetted
   environments in the ARPA-Internet.  Distribution of this memo is
   unlimited.

このRFCは、ARPA-インターネットの「副-網で覆」われた環境で使用されるプロトコルを標準化するのを議論します。 このメモの分配は無制限です。

   The author of this RFC is the Gateway Algorithms and Data Structures
   (GADS) Task Force, chaired by David L. Mills.

このRFCの作者はデヴィッド・L.ミルズによってまとめられたゲートウェイAlgorithmsとData Structures(GADS)タスクForceです。

INTRODUCTION

序論

   Several sites now contain a complex of local links connected to the
   Internet via a gateway.  The details of the internal connectivity are
   of little interest to the rest of the Internet.

いくつかのサイトが現在、ゲートウェイを通してインターネットに接続された地方のリンクの複合体を含みます。 内部の接続性の詳細はインターネットの残りへのわずかの関心のものです。

   One way of organizing these local complexes of links is to use the
   same strategy as the Internet uses to organize networks, that is, to
   declare each link to be an entity (like a network) and to
   interconnect the links with devices that perform routing functions
   (like gateways).  This general scheme is called subnetting, the
   individual links are called subnets, and the connecting devices are
   called subgateways (or bridges, or gateways).

リンクのこれらのローカルの複合体を組織化する1つの方法がネットワークを組織化するのにインターネット用途と同じ戦略を使用することであり、すなわち、各リンクが実体(ネットワークのような)であり、ルーティングを実行するデバイスとのリンクとインタコネクトすると宣言するのが機能します(ゲートウェイのように)。 この一般的な体系はサブネッティングと呼ばれます、そして、個々のリンクはサブネットと呼ばれます、そして、接続デバイスは「副-門」(または、ブリッジ、またはゲートウェイ)と呼ばれます。

   All hosts in the Internet must make a decision when sending a
   datagram, that is, they must answer the question "Is this datagram
   addressed to a host on a directly connected network, or must it be
   sent to a gateway?".  In a subnetted environment, this question is
   extended to "Is this datagram addressed to a host on a directly
   connected subnet, or must it be sent to a (sub)gateway?".  Let us
   call answering this question "making the routing decision".

データグラムを送るとき、インターネットのすべてのホストが決定しなければならなくて、すなわち、彼らは「直接接続されたネットワークでこのデータグラムをホストに扱いますか、またはそれをゲートウェイに送らなければなりませんか?」という質問に答えなければなりません。 「副-網で覆」われた環境で、この質問は「直接接続されたサブネットでこのデータグラムをホストに扱いますか、または(潜水艦)ゲートウェイにそれを送らなければなりませんか?」に広げられます。 この質問に答えるのを「ルーティング決定をします。」と呼びましょう。

   Because the hosts used in a subnetted environment must implement in
   their IP or network interface software procedures for making the
   routing decision, and because such hosts may be acquired from various
   sources, it is important that a standard subnetting scheme be
   identified so that different suppliers can provide compatible hosts
   (that is, hosts compatible with the complexes at different sites and
   each other).  Without a designated standard for a subnetting scheme
   suppliers can not create compatible hosts.

「副-網で覆」われた環境で使用されるホストが、彼らのIPかネットワーク・インターフェースでソフトウェアがルーティング決定をするための手順であると実装しなければならなくて、様々なソースからそのようなホストを取得するかもしれないので、異なった供給者がコンパチブルホスト(すなわち、異なったサイトの複合体とのコンパチブルホストと互い)を提供できるように標準のサブネッティング体系が特定されるのは、重要です。 サブネッティングの指定された規格がなければ、体系供給者はコンパチブルホストを創造できません。

   The potential problem is that if different subnetting schemes are
   developed by different suppliers a customer that installs hosts from
   two or more suppliers may find that they do not work together.

潜在的な問題は異なったサブネッティング体系が異なった供給者によって開発されるなら2人以上の供給者からホストをインストールする顧客が、彼らが一緒に働いていないのがわかるかもしれないということです。

GADS                                                            [Page 1]

突き棒[1ページ]

RFC 940                                                       April 1985
Toward an Internet Standard Scheme for Subnetting

サブネッティングのインターネットの標準の体系に向かったRFC940 1985年4月

   This topic has been discussed in a set of RFCs [1,2,3,4] and in a
   flurry of messages in the Gateway Algorithms and Data Structures Task
   Force.  It is strongly suggested that if subnetting is used at all,
   it be according this new standard scheme.

RFCs[1、2、3、4]の1セットとゲートウェイAlgorithmsとData Structures Task Forceのメッセージの突風でこの話題について議論しました。 サブネッティングが少しでも使用されるなら、それがこの新しい標準の体系使用されると強く示唆されます。

APPROACH

アプローチ

   An Internet address currently consists of a two-layer hierarchy, a
   'network' and a per-network 'rest' field.  This subnet scheme adds an
   optional 'subnet' layer and field.

インターネット・アドレスは現在、2層の階層構造、'ネットワーク'、および1ネットワークあたり1つの'休息'分野から成ります。 このサブネット体系は任意の'サブネット'層と分野を加えます。

   The subnet field is created by stealing some bits from the rest (or
   host) field of the address.  The details of the subnet field are site
   specific.  All three classes (A, B, and C) of networks may be
   subnetted.

サブネット分野は、アドレスの休息(または、ホスト)分野から数ビット盗むことによって、作成されます。 サブネット分野の詳細はサイト特有です。 すべての3つのクラス(A、B、およびC)のネットワークは「副-網で覆」われるかもしれません。

   The use of subnets is an optional local decision.  The fact that a
   network has subnets is invisible outside that network, and the change
   is local and can be instituted at a site without any global Internet
   perturbations.  A complex of links is assigned a single IP network
   number, and outside that complex it appears as a single network with
   that number.  Only inside does local structure appear.

サブネットの使用は任意のローカルの決定です。 ネットワークにはサブネットがあるという事実がそのネットワークの外で目に見えなく、変化は、地方であり、サイトに少しも世界的なインターネット摂動なしで設けることができます。 ただ一つのIPネットワーク・ナンバーはリンクの複合体に配属されます、そして、その複合体の外では、それはその数と共にただ一つのネットワークとして現れます。 ローカルの構造は中に現れるだけです。

   However, while the decision to use subnets at a site is optional, any
   IP implementation which may possibly be used in a potentially
   subnetted environment, should provide for subnet field configuration
   as described above.  Such an implementation will function properly in
   environments with or without subnetting.  On the other hand,
   implementations lacking this provision will not function in a
   subnetted environment, and are thus potentially less useful.

しかしながら、サイトでサブネットを使用するという決定が任意である間のことによると潜在的に「副-網で覆」われた環境で使用されるどんなIP実装も上で説明されるようにサブネット分野構成に備えるべきです。 サブネッティングのあるなしにかかわらずそのような実装は環境で適切に機能するでしょう。 他方では、この支給を欠いている実装は、「副-網で覆」われた環境で機能しないで、またその結果、潜在的にそれほど役に立ちません。

   This specifications is not intended to require a particular
   implementation technique inside the host, but rather to define the
   external behavior of the host in a subnetted environment.  It does
   not specify how routing is done or the details of host construction.
   Note that gateways are hosts, too.

ホストの中で特定の実装のテクニックを必要とすることを意図するのではなく、この仕様は、むしろ「副-網で覆」われた環境でホストの外部の振舞いを定義するために意図します。 それはルーティングがしていてどうホスト工事の詳細であるかを指定しません。 また、ゲートウェイがホストであることに注意してください。

   However, it seems easiest to explain the approach by describing one
   possible host implementation.

しかしながら、1つの可能なホスト導入について説明することによってアプローチについて説明するのは最も簡単に思えます。

      Example Implementation:

例の実装:

         Let us use "subnet" to mean the locally attached transmission
         medium.

局所的に添付のトランスミッション媒体を意味するのに「サブネット」を使用しましょう。

         The key decision to be made is "Is the destination IP address

作られているという重要な決定による「目的地はIPアドレスですか?」

GADS                                                            [Page 2]

突き棒[2ページ]

RFC 940                                                       April 1985
Toward an Internet Standard Scheme for Subnetting

サブネッティングのインターネットの標準の体系に向かったRFC940 1985年4月

         on my subnet or not?".  Once this decision is made the host
         knows to whether to send the datagram directly to the
         destination on the subnet or to send the datagram to a gateway.

「オンである、私のサブネットである、--、」 いったんこの決定をすると、ホストは直接サブネットの目的地にデータグラムを送ること、または、データグラムをゲートウェイに送るかに知っています。

         The host uses a 32-bit mask, along with the host's own IP
         address, to determine whether or not destination IP addresses
         are on its subnet.

ホストは、送付先IPアドレスがサブネットにあるかどうか決定するのにホストの自己のIPアドレスに伴う32ビットのマスクを使用します。

         The mask can be configured at boot time as a static quantity or
         distributed by a protocol that is beyond the scope of this
         memo.

マスクを静的な量としてブート時間で構成するか、またはこのメモの範囲にあるプロトコルは分配できます。

         If the bitwise AND of the mask with the destination IP address
         matches the bitwise AND of the mask with the host's own IP
         address, the destination is assumed on its subnet; if not, the
         destination is assumed on a subnet or network reachable only
         via a gateway.

目的地IPアドレス一致でマスクのANDをbitwiseする、bitwiseして、サブネットでホストの自己のIPアドレスがあるマスク、目的地について想定されます。 そうでなければ、目的地はゲートウェイを通してだけ届いているサブネットかネットワークで想定されます。

            Note: if the mask is all zeros, all destinations will appear
            to be on this subnet; while, if the mask is all ones, only
            the sending host itself will appear to be on this subnet.
            If the mask contains ones in the network field and zeros in
            the rest field, subnets are not in use.

以下に注意してください。 マスクがすべてゼロであるなら、すべての目的地がこのサブネットにあるように見えるでしょう。 送付ホスト自身だけが、マスクがすべてものであるなら、このサブネットにいるように見えるでしょうが。 マスクが休息分野にネットワーク分野とゼロにおけるものを保管しているなら、サブネットは使用中ではありません。

         The above procedure must be treated as a per interface
         procedure for multihomed hosts.

「マルチ-家へ帰」っているホストのためにインタフェース手順あたりのaとして上の手順を扱わなければなりません。

   For further information on background and rationale, see RFC-917,
   "Internet Subnets" [1].

バックグラウンドと原理の詳細に関しては、RFC-917、「インターネットサブネット」[1]を見てください。

REFERENCES

参照

   [1]  Mogul, J., "Internet Subnets", RFC-917, Stanford University,
   October 1984.

[1] ムガール人、J.、「インターネットサブネット」、RFC-917、スタンフォード大学、1984年10月。

   [2]  Postel, J., "Multi-LAN Address Resolution", RFC-925,
   USC/Information Sciences Institute, October 1984.

[2] ポステル、J.、「マルチLANアドレス解決」、RFC-925、科学が1984年10月に設けるUSC/情報。

   [3]  Clark, D., "A Subnetwork Addressing Scheme", RFC-932, MIT LCS,
   January 1985.

[3] クラーク、D.、「サブネットワークアドレシング体系」、RFC-932、MIT LCS、1985年1月。

   [4]  Karels, M., "Another Internet Subnet Addressing Scheme",
   RFC-936, UC Berkeley, February 1985.

[4]Karels、M.、「別のインターネットサブネットアドレシング体系」、RFC-936、UCバークレー1985年2月。

GADS                                                            [Page 3]

突き棒[3ページ]