RFC936 日本語訳

Network Working Group                                  Michael J. Karels
Request for Comments: 936                                    UC Berkeley
                                                           February 1985

ネットワークワーキンググループマイケルJ.Karelsはコメントのために以下を要求します。 936 UCバークレー1985年2月

               Another Internet Subnet Addressing Scheme

別のインターネットサブネットアドレシング体系

Status of this Memo

この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

序論

   There have been several proposals for schemes to allow the use of a
   single Internet network number to refer to a collection of physical
   networks under common administration which are reachable from the
   rest of the Internet by a common route.  Such schemes allow a
   simplified view of an otherwise complicated topology from hosts and
   gateways outside of this collection.  They allow the complexity of
   the number and  type of these networks, and routing to them, to be
   localized.  Additions and changes in configuration thus cause no
   detectable change, and no interruption of service, due to slow
   propagation of routing and other information outside of the local
   environment.  These schemes also simplify the administration of the
   network, as changes do not require allocation of new network numbers
   for each new cable installed.  The motivation for explicit or
   implicit subnets, several of the alternatives, and descriptions of
   existing implementations of this type have been described in detail
   [1,2].  This proposal discusses an alternative scheme, one that has
   been in use at the University of California, Berkeley since
   April 1984.

ただ一つのインターネットネットワーク・ナンバーの使用が体系で一般的な管理の下における一般的なルートによるインターネットの残りによって届いている物理ネットワークの収集を参照できるといういくつかの提案がありました。 そのような体系はこの収集の外にホストとゲートウェイからそうでなければ、複雑なトポロジーの簡易型の視点を許容します。 彼らは、ローカライズされるために数の複雑さを許容して、これらのネットワーク、およびルーティングをそれらにタイプします。 その結果、構成における追加と変化は地方の環境の外でルーティングと他の情報の遅い伝播による検出可能な変化がなく、および停電を全く引き起こしません。 また、これらの体系はネットワークの管理を簡素化します、変化がインストールされたそれぞれの新しいケーブルの新しいネットワーク・ナンバーの配分を必要としないとき。 明白であるか暗黙のサブネットに関する動機、いくつかの代替手段、およびこのタイプの既存の実装の記述は詳細[1、2]に説明されます。 この提案は代替の体系(1984年4月以来カリフォルニア大学バークレイ校で使用中であるもの)について議論します。

Subnet Addressing at Berkeley

バークレーのサブネットアドレシング

   As in the proposal by Jeff Mogul in RFC-917, the Berkeley subnet
   addressing utilizes encoding of the host part of the Internet
   address.  Hosts and gateways on the local network are able to
   determine the subnet number from each local address, and then route
   local packets based on the subnet number.  Logically, the collection
   of subnets appears to external sites to be a single, homogenous
   network.  Internally, however, each subnet is distinguished from the
   others and from other networks, and internal routing decisions are
   based on the subnet rather than the network number.

RFC-917のジェフ・ムガール人による提案のように、バークレーサブネットアドレシングはインターネット・アドレスのホスト部分のコード化を利用します。 企業内情報通信網のホストとゲートウェイは、各ローカルアドレスからサブネット番号を決定して、次に、サブネット番号に基づく地方のパケットを発送できます。 論理的に、サブネットの収集は単一の、そして、均質のネットワークである外部のサイトに現れます。 しかしながら、本質的に、各サブネットは他のものと他のネットワークと区別されます、そして、内部のルーティング決定はネットワーク・ナンバーよりむしろサブネットに基づいています。

   The encoding of subnet addresses is similar to that proposed in
   RFC-917.  In decomposing an Internet address into the network and
   host parts, the algorithm is modified if the network is "local", that
   is, if the network is a directly-connected network under local
   administrative control.  (Networks are marked as local or non-local

サブネットアドレスのコード化はRFC-917で提案されたそれと同様です。 ネットワークとホストの部品にインターネット・アドレスを分解する際に、ネットワークが「地方である」なら、アルゴリズムは変更されています、すなわち、ネットワークが地方の運営管理コントロールの下で直接接続されたネットワークであるなら。 (ネットワークは地方か非地方としてマークされます。

Karels                                                          [Page 1]

Karels[1ページ]

RFC 936                                                    February 1985
Another Internet Subnet Addressing Scheme

RFC936 1985年2月 別のインターネットサブネットアドレシング体系

   at the time each network interface's address is set at boot time.)
   For local addresses, the host part is examined for a subnet number.
   Local addresses may be on the main network, or they may be on a
   subnet.  The high-order bit of the host number is used to distinguish
   between subnets and the main net.  If the high-order bit of the host
   field is set, then the remainder of the high-order byte of the host
   part is taken to be the subnet number.  If the high-order bit is
   clear, then the address is interpreted in the normal fashion.  For
   Class A networks, using 8-bit subnet fields, this allows a network
   with up to 127 subnets, each of 65535 hosts maximum, and a main net
   with 2^23 hosts.  Class B nets may include 127 subnets, each of up to
   255 hosts, and 32767 hosts on the main net.  Class C networks are not
   currently included in this scheme. They might be reasonably be added,
   using four bits of the host part for a subnet desgination and four
   bits for the host, allowing 8 subnets of 15 hosts and 126 hosts on
   the main net.

当時、各ネットワーク・インターフェースのアドレスはブート時間で設定されます。) ローカルのアドレスにおいて、ホスト部分はサブネット番号がないかどうか調べられます。 ローカルのアドレスが主なネットワークにあるかもしれませんか、またはそれらはサブネットにあるかもしれません。 ホスト番号の高位のビットは、サブネットと身網を見分けるのに使用されます。 ホスト分野の高位のビットを設定するなら、サブネット番号になるようにホスト部分の高位バイトの残りを取ります。 高位のビットが明確であるなら、アドレスは正常なファッションで解釈されます。 Class Aネットワークのために、8ビットのサブネット分野を使用して、これは最大127サブネットがあるネットワーク、ホスト65535人の各人に最大、および23が接待する2^がある身網を許容します。 クラスBネットは127サブネット、ホスト最大255人の各人、および身網の32767人のホストを含むかもしれません。 クラスCネットワークは現在、この体系に含まれていません。 それらは、合理的に加えられて、サブネットのためのホスト部分の4ビットをdesginationと4ビット使用するかもしれませんホストのために、身網の15人のホストと126人のホストの8サブネットを許容して。

   The current implementation does not use subnet numbers separately
   from the network field, but instead treats the subnet field as an
   extension of the network field.  Functions that previously returned
   the network number from an address now return a network or
   network-subnetwork number.  Conveniently, Class A subnets are
   distinguishable from Class B networks, although each is a 16-bit
   quantity, and Class B subnets are disjoint with Class C network
   numbers.  The net result is that subnets appear to be separate,
   independent networks with their own routing entries within the
   network, but outside of the network, they are invisible.  There is no
   current facility at Berkeley for broadcasting on the logical network;
   broadcasting may be done on each subnet that uses harware capable of
   broadcast.

現在の実装は、別々にネットワーク分野からサブネット番号を使用しませんが、代わりにネットワーク分野の拡大としてサブネット分野を扱います。 今や以前にアドレスからネットワーク・ナンバーを返した機能がネットワークかネットワークサブネットワーク番号を返します。 便利に、Class AサブネットはClass Bネットワークから区別可能です、それぞれが16ビットの量ですがClass Bサブネットはそうです。Class Cネットワーク・ナンバーで、ばらばらになってください。 最終結果はサブネットがネットワークの中にそれら自身のルーティングエントリーがある別々の、そして、独立しているネットワークであるように見えますが、ネットワークの外では、それらが目に見えないということです。 どんな現在の施設も論理的なネットワークで放送するためのバークレーにありません。 放送ができるharwareを使用する各サブネットで放送するかもしれません。

Discussion

議論

   There have been several earlier proposals for methods of allowing
   several physical networks to share an Internet network designation,
   and to provide routing within this logical network.  RFC-917 proposes
   a means for encoding the host part of each local address such that
   the hosts, or the gateways connecting them, are able to determine the
   physical network for the host.  The current proposal is most similar
   to that scheme; the differences are discussed in detail below.

いくつかの以前の提案がいくつかの物理ネットワークがインターネット網名称を共有して、この論理的なネットワークの中でルーティングを提供するのを許容するメソッドのためにありました。 RFC-917がそれぞれのローカルアドレスのホスト部分をコード化するための手段を提案するので、ホスト、またはそれらを接続するゲートウェイがホストのために物理ネットワークを決定できます。 現在の提案はその体系と最も同様です。 以下で詳細に違いについて議論します。

   Another proposal (RFC-925) involves the use of intelligent gateways
   to perform routing for unmodified hosts, using an Address Resolution
   Protocol (ARP) [2].  This has the advantage of placing all
   modifications in the gateways, but is likely to require additional
   routing protocols and caching mechanisms in the gateways in order to
   avoid excessive broadcasts for address resolution.  A modification of

別の提案(RFC-925)は変更されていないホストのためにルーティングを実行するために知的なゲートウェイの使用にかかわります、Address Resolutionプロトコル(ARP)[2]を使用して。 これが、すべての変更をゲートウェイに置く利点を持っていますが、アドレス解決のための過度の放送を避けるのにゲートウェイで追加ルーティング・プロトコルとメカニズムをキャッシュするのが必要でありそうです。 変更

Karels                                                          [Page 2]

Karels[2ページ]

RFC 936                                                    February 1985
Another Internet Subnet Addressing Scheme

RFC936 1985年2月 別のインターネットサブネットアドレシング体系

   this method is to perform encoding of subnets within host addresses
   by convention to simplify the routing in the gateways, without
   modifying host software to recognize these subnet addresses.  These
   techniques were not considered for use at Berkeley, because all
   packet forwarding was being done by multi- homed hosts, all of which
   ran the same software as the singly-homed hosts (4.2BSD Unix).

このメソッドはゲートウェイでルーティングを簡素化するためにコンベンションによるホスト・アドレスの中でサブネットのコード化を実行することです、これらのサブネットアドレスを認識するようにホストソフトウェアを変更しないで。 これらのテクニックはバークレーでの使用のために考えられませんでした、すべてのパケット推進でしていたのでマルチ、家へ帰り、ホスト、単独で家へ帰る、ホスト(4.2BSD Unix)。そのすべてが同じソフトウェアを動かしました。

   The most recent proposal, RFC-932 [3], provides subnetting by
   encoding the network part of the Internet address rather than the
   host part.  Ordinary hosts need not know of this convention,
   eliminating the need for modification to host software.  Gateways
   would be able to take advantage of this encoding to compress the
   routing information for the collection of networks into a single
   entry.  Unfortunately, implementation of that scheme would require a
   fairly concerted transition by the gateways of the Internet, or the
   transition period would be likely to overflow the routing tables in
   the existing gateways.  All of the hosts on the larger networks would
   be forced to change addresses from their current Class A or B
   addresses to "B 1/2" addresses.  There are a limited number (4096) of
   blocks of Class C addresses available using this encoding.  The
   number of universities and other organizations having already
   implemented subnets or contemplating their installation argues for a
   more extensible scheme, as well as one that can be implemented more
   quickly.

最新の提案(RFC-932[3])は、ホスト部分よりむしろインターネット・アドレスのネットワーク部分をコード化することによって、サブネッティングを提供します。 変更がソフトウェアをホスティングする必要性を排除して、普通のホストはこのコンベンションを知る必要はありません。 ゲートウェイは、ネットワークの収集のためのルーティング情報を単一のエントリーに圧縮するのにこのコード化を利用できるでしょう。 残念ながら、その体系の実装がインターネットのゲートウェイのそばでかなり協定している変遷を必要とするだろうか、または過渡期は既存のゲートウェイで経路指定テーブルからはみ出しそうでしょう。 より大きいネットワークのホストは皆、やむを得ずアドレスをそれらの現在のClass AかBアドレスから「B1/2インチアドレス」に変えるでしょう。 そこでは、限られた数(4096)のブロックのClass Cアドレスが、このコード化を使用することで入手できますか? 大学と有がサブネットであると既に実装した他の組織か彼らのインストールを熟考する数は、より広げることができる体系について賛成の議論をします、よりはやく実装することができるものと同様に。

   The current proposal is most similar to that of RFC-917; indeed, the
   two implementations are nearly compatible.  There are two differences
   of significance.  First, the use of a bit to distinguish subnetted
   addresses from non-subnetted addresses allows both smaller subnets
   and a larger (physical or logical) main network.  Half of the host
   addresses within a Class A or B network are reserved for use in
   subnets, the other half are available for the primary net.  This may
   useful when using a hardware medium that is capable of supporting
   large numbers of hosts or for transparent subnetting (e.g. using
   ARP-based bridges).  The corresponding disadvantage is that fewer
   subnets may be supported.  The allocation of bits between the subnet
   number and the host field could be adjusted, but for Class B
   networks, neither is excessively large.  Given the limited address
   space of the current Internet addressing, this is a difficult choice.

現在の提案はRFC-917のものと最も同様です。 本当に、2つの実装がほとんど互換性があります。 意味の2つの違いがあります。 まず最初に、しばらくの非「副-網で覆」われたアドレスと「副-網で覆」われたアドレスを区別するために使用は、より小さいサブネットと、より大きい(物理的であるか論理的な)主なネットワークの両方を許容します。 Class AかBネットワークの中の半分のホスト・アドレスはサブネットにおける使用のために予約されて、もう片方の半分はプライマリネットに利用可能です。 これは役に立つかもしれません。多くのホストをサポートすることができるハードウェア媒体を使用するか、見え透いたサブネッティング(例えば、ARPベースのブリッジを使用する)の役に立ちます。 対応する不都合は、より少ないサブネットがサポートされるかもしれないということです。 サブネット番号とホスト分野の間のビットの配分を調整できましたが、Class Bネットワークにおいて、どちらも過度に大きくはありません。 現在のインターネットアドレシングの限られたアドレス空間を考えて、これは難しい選択です。

   The second difference is that the width of the subnet field is fixed
   in advance.  This simplifies the already-too-complicated code to
   interpret Internet addresses, and avoids the bootstrap problem. If
   the subnet field width is to be determined dynamically, some fraction
   of the hosts on a network must be prepared to specify this value, and
   the situation will be unworkable if one of these hosts does not make
   the correct choice or none are accessible when other machines come

2番目の違いはサブネット分野の幅があらかじめ固定されているということです。 これが簡素化する、既にまた、複雑にされて、インターネット・アドレスを解釈するのをコード化してください、避ける、問題を独力で進んでください。 サブネット欄の幅がダイナミックに断固とすることであり、この値を指定するようにネットワークのホストのある部分を準備しなければならなくて、他のマシンが来るとき、これらのホストのひとりが正しい選択をしないか、またはなにもアクセスしやすくないなら状況が「非-実行可能」になるなら

Karels                                                          [Page 3]

Karels[3ページ]

RFC 936                                                    February 1985
Another Internet Subnet Addressing Scheme

RFC936 1985年2月 別のインターネットサブネットアドレシング体系

   up.  Also, the recovery procedure proposed by RFC-917 seems
   unnecessarily complicated and liable to fail.  Dynamic discovery of
   this value depends on another modification as well, the addition of a
   new ICMP request.  The alternatives are to specify the field size as
   a standard, or to require each implementation to be configurable in
   advance (e.g with a system compilation option or the use of a system
   patch installed when a host is initially installed.  The use of a
   standard field width seems preferable, and an 8-bit field allows the
   most efficient implementations on most architectures.  For Class C
   nets, a 4-bit field seems the only choice for a standard division.

上がる。 また、RFC-917によって提案されたリカバリ手順は失敗するのにおいて不必要に複雑で傾向があるように思えます。 この価値のダイナミックな発見は良い別の同じくらい変更、新しいICMP要求の追加によります。 ホストが初めはインストールされるとき、システム編集オプションかシステムパッチの使用があるgはインストールされました。標準の欄の幅の使用は望ましく見えます、そして、8ビットの分野はほとんどのアーキテクチャで最も効率的な実装を許容します。選択肢が規格として分野サイズを指定するか、またはそれぞれの実装があらかじめ構成可能であることが必要であることである、(e. Class Cネットに関して、4ビットの分野は標準の分割のために唯一の選択に見えます。

References

参照

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

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

   [2]  J. Postel, "Multi-LAN Address Resolution", RFC-925, USC-ISI,
   October 1984

[2] J.ポステル、「マルチLANアドレス解決」、RFC-925、USC-ISI、1984年10月

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

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

Karels                                                          [Page 4]

Karels[4ページ]