子網路總是連續的 1 嗎？

Question 1

第 3.1 節中RFC顯示無類別域間路由中允許的遮罩。這些位元必須是連續的，路由才能正常運作。

此外，從邏輯上思考，擁有奇怪的隨機網路遮罩實際上並沒有意義。

Answer

第 3.1 節中RFC顯示無類別域間路由中允許的遮罩。這些位元必須是連續的，路由才能正常運作。

此外，從邏輯上思考，擁有奇怪的隨機網路遮罩實際上並沒有意義。

Question 2

是的，最簡單的思考方式是子網路遮罩在開始時始終為 1。如果子網路大小指示符在二進位表示形式的開頭沒有 1，那麼我會說子網路大小指示符不是使用現代標準的正確「子網路遮罩」。

RFC 1219指出早期的 RFC 950 允許非連續位元。實際上，RFC 950 第 15 頁（第 3 節）顯然有一個「說明非連續子網路位元」的範例。RFC 1884 第 7 頁，第 2.4 節的第一句），因此 IPv6 網路從未廣泛支援非連續位元。RFC 1219的方法指定「子網路位元（遮罩 = 1）是從最高有效位元指派給最低有效位元的」。RFC 4632 第 3.1 節，Sami 的回答提到的，指向討論 CIDR 表示法的官方標準。

RFC 1878 第 2 頁顯示除之外的所有 IPv4 子網路的標準「子網路遮罩」表示法/0。

然而，我將詳細闡述薩米的答案，研究“為什麼”（用一個具體的例子，正如問題所要求的那樣）...

一些專業級思科設備支援所謂的“通配符掩碼”，它可以反轉位元。因此，一個普通的子網路可以用稱為的東西來表示00000000.00000000.00000000.11111111。

對於思科的通配符掩碼，並沒有規定所有的零都必須在前面。所以你可以使用00000000.00000000.00000000.11111110.

這最終會建立一個包含所有偶數 IP 位址的群組。

這實際上很重要，因為思科的培訓涵蓋了這一點，因此思科專業認證的考試過程可能會問到這樣的事情。

不過，我認為這基本上沒什麼用。您可以使用低編號位址和高編號位址將網路分成兩半，而不是使用偶數位址或奇數位址將網路分成兩半，方法是將正常子網路大小減半。

具有非連續位元的通配符遮罩並不是很有用，並且使用起來可能更具挑戰性。將子網路遮罩位元設為1 的意義在於，該位元有助於識別設備所在的子網路。地址的開頭。結果是支援這些類型的遮罩會增加複雜性，而沒有太多實質的好處。

我猜思科最終同意這種非傳統子網路遮罩沒有意義，因為他們最終放棄了對“通配符遮罩”的支援。 “子網路遮罩” 。

我什至不會嘗試在掩碼中創建一個具有不連續“子網位”的網絡，因為很多軟體會遵循更新的趨勢/標準，並拒絕這樣的網絡設計。即使我使用的是較舊的軟體，我也可能希望我的網路能夠輕鬆修改，以便能夠使用較新的軟體，而無需重新設計網路。因此，連續的「子網路位」是唯一的出路。

如果您在測試中被問到這個問題，我會自信地說所有 1 都必須位於地址的開頭。這就是當今時代任何理智的測試人員都希望大多數學生學習的內容。

Answer

是的，最簡單的思考方式是子網路遮罩在開始時始終為 1。如果子網路大小指示符在二進位表示形式的開頭沒有 1，那麼我會說子網路大小指示符不是使用現代標準的正確「子網路遮罩」。

RFC 1219指出早期的 RFC 950 允許非連續位元。實際上，RFC 950 第 15 頁（第 3 節）顯然有一個「說明非連續子網路位元」的範例。RFC 1884 第 7 頁，第 2.4 節的第一句），因此 IPv6 網路從未廣泛支援非連續位元。RFC 1219的方法指定「子網路位元（遮罩 = 1）是從最高有效位元指派給最低有效位元的」。RFC 4632 第 3.1 節，Sami 的回答提到的，指向討論 CIDR 表示法的官方標準。

RFC 1878 第 2 頁顯示除之外的所有 IPv4 子網路的標準「子網路遮罩」表示法/0。

然而，我將詳細闡述薩米的答案，研究“為什麼”（用一個具體的例子，正如問題所要求的那樣）...

一些專業級思科設備支援所謂的“通配符掩碼”，它可以反轉位元。因此，一個普通的子網路可以用稱為的東西來表示00000000.00000000.00000000.11111111。

對於思科的通配符掩碼，並沒有規定所有的零都必須在前面。所以你可以使用00000000.00000000.00000000.11111110.

這最終會建立一個包含所有偶數 IP 位址的群組。

這實際上很重要，因為思科的培訓涵蓋了這一點，因此思科專業認證的考試過程可能會問到這樣的事情。

不過，我認為這基本上沒什麼用。您可以使用低編號位址和高編號位址將網路分成兩半，而不是使用偶數位址或奇數位址將網路分成兩半，方法是將正常子網路大小減半。

具有非連續位元的通配符遮罩並不是很有用，並且使用起來可能更具挑戰性。將子網路遮罩位元設為1 的意義在於，該位元有助於識別設備所在的子網路。地址的開頭。結果是支援這些類型的遮罩會增加複雜性，而沒有太多實質的好處。

我猜思科最終同意這種非傳統子網路遮罩沒有意義，因為他們最終放棄了對“通配符遮罩”的支援。 “子網路遮罩” 。

我什至不會嘗試在掩碼中創建一個具有不連續“子網位”的網絡，因為很多軟體會遵循更新的趨勢/標準，並拒絕這樣的網絡設計。即使我使用的是較舊的軟體，我也可能希望我的網路能夠輕鬆修改，以便能夠使用較新的軟體，而無需重新設計網路。因此，連續的「子網路位」是唯一的出路。

如果您在測試中被問到這個問題，我會自信地說所有 1 都必須位於地址的開頭。這就是當今時代任何理智的測試人員都希望大多數學生學習的內容。

Question 3

RFC 9502.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 XP SP2 上，這也不再可能了：

然而，Windows 98 克隆 ReactOS 允許設定「奇怪」的網路遮罩：

Answer