☰

サブネットは常に連続した 1 ですか?

tag-icon • tag-icon networking ip subnet
サブネットは常に連続した 1 ですか?

サブネット マスクの基本的な前提は理解しています。たとえば、255.255.255.0。しかし、私が見たサブネットの例はすべて (左から右に) 連続した 1 (HI ビット) でした。たとえば、255.255.0.0( /16) は次のオクテットに変換されます。

11111111 . 11111111 . 00000000 . 00000000

私信じるこれらのビットしなければならないサブネット化の目的は、ホスト ID と利用可能なデバイス ID の範囲を導出することであるため、連続している必要があります。しかし、次のようなサブネット マスクが存在する可能性はあるのでしょうか255.17.255.0。

11111111 . 00010001 . 11111111 . 00000000
  • このようなことは起こり得るでしょうか? それとも、連続した 1 がないサブネットは存在できないのでしょうか? もしそうなら、なぜでしょうか?
  • そうでなければ、これが可能である場合、なぜそうするのでしょうか（具体的な例をいくつか挙げてください）？

答え1

セクション3.1では、RFCクラスレスドメイン間ルーティングで許可されるマスクを示します。ルーティングが適切に機能するには、ビットが連続している必要があります。

また、論理的に考えると、奇妙なランダムなネットワーク マスクを使用するのは実際には意味がありません。

答え2

はい、簡単に考えれば、サブネット マスクは常に先頭が 1 になります。サブネット サイズ インジケータのバイナリ表現の先頭が 1 でない場合、サブネット サイズ インジケータは、最新の標準では適切な「サブネット マスク」ではないと言えます。

RFC 1219以前のRFC 950では非連続ビットが許可されていると述べられています。実際、RFC 950 ページ 15（セクション3）には明らかに「非連続サブネットビットを示す」例があります。しかし、そのようなサブネットをCIDR表記に変換する方法はありません。CIDRスタイルの表記は、IPv6が（少なくともRFC 1884 ページ 7、セクション 2.4 の最初の文) のため、非連続ビットは IPv6 ネットワークでは広くサポートされませんでした。RFC 1219の方法で、「サブネットビット（マスク= 1）は最上位ビットから最下位ビットに向かって割り当てられる」と規定されています。（RFC 4632 セクション 3.1Sami の回答で言及されている は、CIDR 表記法について議論する公式標準を指しています。

RFC 1878 ページ 2を除くすべての IPv4 サブネットの標準の「サブネット マスク」表記を示します/0。

しかし、私はサミの答えをもう少し詳しく説明し、「なぜ」を調べてみようと思います（質問で求められていたように、具体的な例を挙げて）。

一部のプロフェッショナルグレードの Cisco 機器は、ビットを反転する「ワイルドカード マスク」と呼ばれるものをサポートしています。そのため、通常のサブネットは と呼ばれるもので表すことができます00000000.00000000.00000000.11111111。

Cisco のワイルドカード マスクでは、すべてのゼロが最初に来なければならないというルールはありませんでした。したがって、 を使用できます00000000.00000000.00000000.11111110。

こうすると、偶数番号の IP アドレスだけを含むグループが作成されます。

これは実際に知っておくべき重要なことでした。なぜなら、シスコのトレーニングでこの内容がカバーされており、シスコのプロフェッショナル認定試験のプロセスでこのようなことが質問される可能性があるからです。

しかし、それはほとんど役に立たなかったと思います。偶数アドレスまたは奇数アドレスを使用してネットワークを半分に分割する代わりに、半分の大きさの通常のサブネットを作成して、小さいアドレスと大きいアドレスを使用してネットワークを半分に分割するだけで済みます。

連続していないビットを持つワイルドカード マスクはあまり役に立たず、扱いが難しくなる可能性があります。サブネット マスク ビットを 1 に設定する目的は、そのビットがデバイスがどのサブネットにあるかを識別するのに役立つということです。これらのビットをアドレスの先頭にきれいにグループ化するのではなく、アドレス全体に分散させる強い理由はありません。その結果、これらのタイプのマスクをサポートすることは、実質的なメリットがないまま複雑さが増すだけでした。

シスコは最終的に、このような非伝統的なサブネット マスクには意味がないことに同意したようで、最終的には「ワイルドカード マスク」のサポートを中止しました。古い Pix ファイアウォールは「ワイルドカード マスク」をサポートしていますが、新しい ASA ユニットは代わりに標準の「サブネット マスク」を使用します。

多くのソフトウェアが新しいトレンドや標準に従い、そのようなネットワーク設計を拒否するため、マスクに不連続の「サブネット ビット」を持つネットワークを作成しようとは思いません。古いソフトウェアを使用していたとしても、ネットワークを再設計することなく、新しいソフトウェアを使用できるようにネットワークを簡単に変更できるようにしたいでしょう。したがって、連続した「サブネット ビット」が唯一の方法です。

テストでこの質問をされた場合、私は自信を持って、アドレスの先頭にすべての 1 を置く必要があると答えます。これは、今日の時代に、まともなテスト担当者なら誰でも大多数の学生に学んでほしいことだと思います。

答え3

RFC950 の翻訳第2.2章ではこう述べています。

 To support subnets, it is necessary to store one more 32-bit

  quantity, called my_ip_mask.  This is a bit-mask with bits set in
  the fields corresponding to the IP network number, and additional
  bits set corresponding to the subnet number field.

 The code then becomes:

   IF bitwise_and(dg.ip_dest, my_ip_mask)

                               = bitwise_and(my_ip_addr, my_ip_mask)
         THEN
             send_dg_locally(dg, dg.ip_dest)
         ELSE
             send_dg_locally(dg,
                    gateway_to(bitwise_and(dg.ip_dest, my_ip_mask)))

したがって、提案は連続するビットを気にしない単純なビット操作に関するものでした。

1985 年当時、CPU とメモリははるかに制限されていたため、より複雑な操作は時間内に実行できませんでした。

第 3 章ではさらに明確になります。

また、ネットワークでは 3 ビットのサブネット フィールド (01011000) が使用されており、アドレス マスクは 255.255.255.88 です。

ただし、これらの RFC は古くなっているようです。たとえば、Windows 7 SP1 では、このようなサブネット マスクを設定することはできません。

Windows 7 では連続したサブネット マスクが必要です

Windows XP SP2 でも、これは不可能でした。

サブネット マスク Windows XP SP2

ただし、Windows 98 クローンの ReactOS では、「奇妙な」ネットマスクを設定できます。

ReactOS サブネットマスク

答え4

私は@Sami Kuhmonenの回答に同意します:

RFC のセクション 3.1 には、クラスレス ドメイン間ルーティングで許可されるマスクが示されています。ルーティングが適切に機能するには、ビットが連続している必要があります。また、論理的に考えると、奇妙で​​ランダムなネットワーク マスクを使用するのは実際には意味がありません。

ただし、望ましくない、または許可されていない場合でも、連続しない 1 のサブネット マスクを定義することは可能です。その理由は次のとおりです。
ネットワーク ID とホスト ID は、バイナリ演算 AND と XOR を使用して IP アドレスとサブネット マスクから計算されます。その他はすべて無関係です。

数年前に Win 2000 でテストしましたが、うまくいきました。両方のコンピューターのマスクは 255.160.0.0 でした。ルーターのない LAN にあったため、ルーターの動作についてはわかりません (通常、ルーターのマスクは Web インターフェイスでのみ設定でき、拒否されます)。
また、このような「無効な」サブネット マスクをネットワーク設定の対応するフィールドに入力することもできません。GUI はそれを拒否します。ただし、レジストリで直接変更することでごまかすことができます。その後、変更を有効にするには、NIC を再起動するか、無効にして有効にします。
そのすべての目的は、うーん、おそらくありません。

関連情報