第 8 章 IP 基礎與定址

本章提要 8-1 IP 基礎 8-2 擷取封包 8-3 IP 封包的傳送模式 8-4 IP 位址表示法 8-5 IP 位址的等級 8-6 子網路 (Subnet) 8-7 無等級的 IP 位址 8-8 網路位址轉譯 (NAT)

前言 從本章開始, 將以 4 章的篇幅 (第 8~11 章) 來介紹網路層的協定。 網路層負責在網路系統之間傳送訊息, 亦即將訊息從來源端傳送到目的端。網路層的主要功能如下： 定址 (Addressing)：賦予網路裝置名稱或位址的機制。 路由 (Routing)：決定封包在數個網路之間的傳送路徑。

前言 網路層中有不少是大家耳熟能詳的協定, 例如：TCP/IP 的 IP (Internet Protocol),Netware 的 IPX (Internetwork Packet Exchange) 等等。至於其他通訊協定, 也都會實作網路層的功能。 接著, 我們便以大家最常見的 IP 為範例, 說明網路層的功能。本章首先介紹 IP 的基礎與 IP 定址, 第 10 章介紹 ARP 與 ICMP 兩個輔助 IP 的協定, 第 11 章則是介紹 IP 路由。

8-1 IP 基礎 Internet Protocol (IP, 網際網路協定) 是整個 TCP/IP 協定組合的運作核心, 也是構成網際網路的基礎。 IP 位於 DoD 模型的網路層 (相當於 OSI 模型的網路層), 對上可載送傳輸層各種協定的封包, 例如：TCP 封包、UDP 封包等等；對下可將 IP 封包放到鏈結層,透過乙太網路、記號環網路等各種技術來傳送。

IP 基礎 IP 所提供的服務大致可歸納為兩項： IP 封包的傳送 IP 封包的切割與重組 以下我們將分別說明這兩項服務。

8-1-1 傳送 IP 封包 IP 是負責網路之間訊息傳送的協定, 可將 IP 封包從來源裝置 (例如：您的電腦) 傳送到目的裝置 (例如：教育部的 WWW 伺服器)。要達成這樣的目的, IP 必須依賴以下兩種機制：IP 定址與 IP 路由。

IP 定址 IP 規定網路上所有的裝置都必須有一個獨一無二的 IP 位址 (IP Address) 以資識別。就好比是郵件上都必須註明收件人地址, 郵差才能將郵件送達。同理, 每個 IP 封包都會記載目的裝置的 IP 位址, 封包才能正確地送達目的地。

IP 定址 除了讓每個網路裝置都有一個 IP 位址外, 相關單位在分配 IP 位址時也會考慮分佈的合理性, 儘量將連續的 IP 位址集合在一起, 以方便 IP 封包的傳遞。這就好比當您找到 『忠孝東路一段 100 號』 時, 您可以推測 101 號、102 號必然在鄰近的區域, 而不會是位於幾公里之外。

IP 定址 在現實生活中, 政府相關單位會統籌分配地址的事宜, 包括道路的命名、門牌號碼的分配等等。同樣地, 全球也有類似的機構, 負責分配 IP 位址。此機構的最高單位為 ICANN (Internet Corporation for Assigned Names and Numbers), 網址為 http://www.icann.org/。

IP 定址 ICANN 會依地區與國家, 授權給公正的單位來執行分配 IP 位址的工作。在台灣是由 TWNIC (Taiwan Network Information Center, 財團法人臺灣網路資訊中心) 所負責, 網址為 http://www.twnic.net/。TWNIC 依照分配管理辦法, 將 IP位址分配給學術網路、各家 ISP (Internet Service Provider, 網際網路服務供應廠商) 等等。個人或公司行號若需要 IP 位址, 必須向 ISP 申請, 因為 TWNIC 並不受理個別的申請案件。

同一裝置可以擁有多個 IP 位址嗎？ 所有使用 IP 的網路裝置, 至少都必須有一個獨一無二的 IP 位址。換言之, 您可以指派多個『獨一無二的 IP 位址』 給同一個網路裝置, 但是同一個 IP 位址卻不能重覆指派給兩個 (或以上) 網路裝置。

同一裝置可以擁有多個 IP 位址嗎？ 若要讓網路裝置具有多個 IP 位址, 在實作上必須有作業系統的支援。例如：Windows NT/2000/XP/2003、Unix/Linux 便可指派 (Binding) 多個 IP 位址給同一張網路卡；相反地, 在Windows 95/98 等系統, 便不支援這樣的功能。

IP 路由 網際網路可視為由許多個網路連結成的大型網路。若要在網際網路中傳送 IP封包, 除了確保網路上每個裝置都有一個獨一無二的 IP 位址外, 網路之間還必須有傳送的機制, 才能將 IP 封包透過一個個的網路, 送達目的地。此種傳送機制稱為 IP 路由 (IP Routing)。

IP 路由

IP 路由 如上圖所示, 每個網路透過路由器 (Router) 相互連接。路由器的功能是為 IP封包選擇傳送的路徑。換言之, IP 封包必須靠沿途各路由器的通力合作, 才能到達目的地。請讀者特別注意, 在 IP 路由的過程中, 是由路由器負責選擇路徑, 至於IP 封包則是處於被動的狀態。

非連接式的傳送特性 前文所介紹的 IP 位址與 IP 路由, 都是傳送 IP 封包的基礎。此外, IP 封包傳送時還有一項很重要的特性, 即是使用非連接式 (Connectionless) 的傳送方式。非連接式的傳送方式大意是指傳送 IP 封包時, 來源與目的裝置雙方毋須事先建立連線, 即可將 IP 封包送達。

非連接式的傳送特性 亦即, 來源裝置完全不用理會目的裝置的狀態, 而只是單純的將 IP 封包逐一送出即了事。至於目的裝置是否收到每個封包、是否收到正確的封包等等, 則是由上層的協定 (例如：TCP) 來負責檢查。 這就好像以平信來傳送信件時, 寄件人只負責將信件投入郵筒。

非連接式的傳送特性 至於後續狀況, 例如：收信人是不是真的能拿到這封信, 則非平信遞送的責任。寄信人若要確認信件是否送達, 必須自行以電話、傳真等其他聯絡方式來確認。 使用非連接式的好處就是將過程簡單化, 可提高傳輸的效率。此外, 由於 IP 封包必須透過 IP 路由的機制, 在一個個路由器之間傳遞, 非連接式的傳送方式較易在此種機制中運作。

非連接式的傳送特性 相對於非連接式的傳送方式, 也有連接式 (Connection-Oriented) 的傳送方式, 也就是來源與目的裝置雙方必須先建立連線, 才能進一步傳輸資料。TCP 即是使用連接式的傳送方式。我們會在第 11 章說明這種傳送方式。

8-1-2 切割與重組 IP 封包 IP 必須將封包放到鏈結層傳送。每一種鏈結層的技術都會有所謂的最大傳輸單位 (Maximum Transmission Unit, MTU), 亦即該種技術所能傳輸的最大承載資料 (Payload) 長度。

切割與重組 IP 封包 IP 封包在傳送過程中, 可能會經過許多個使用不同技術的網路。假設 IP 封包是從ATM (Asynchronous Transfer Mode, 非同步傳輸) 網路所發出, 原始長度為 9180 Bytes,若 IP 路由途中經過乙太網路, 便會面臨封包太大, 無法在乙太網路上傳輸的障礙。

切割與重組 IP 封包 為了解決此問題, 路由器必須有 IP 封包切割與重組 (Fragmentation &Reassembly) 的機制, 將過長的封包加以切割, 以便能在最大傳輸單位較小的網路上傳輸。切割後的 IP 封包, 會由目的裝置重組, 恢復成原來 IP 封包的模樣。

8-1-3 IP 封包的結構 IP 在傳送資料的基本單位當然是 IP 封包。IP 封包主要是由兩部份所組成： IP 表頭 (Header)：記錄有關 IP 位址、路由、封包識別等資訊。 IP Payload：載送上層協定 (例如：TCP、UDP 等) 的封包。

IP 表頭 IP 表頭包含了下列欄位：

IP 表頭 以下為 IP 表頭中較為重要的資訊：

IP 表頭 目的位址 (Destination Address) 來源位址 (Source Address) IP 表頭記錄了目的端的 IP 位址。在後續路由過程中, 必須藉由此項資訊, 才能將 IP 封包傳送到目的端, 因此可說是 IP 表頭中最重要的資訊。 來源位址 (Source Address) 記錄了來源端的 IP 位址。目的端收到 IP 封包後, 若必須回覆時, 會用到此項資訊。

IP 表頭 上層協定 (Protocol) IP 封包識別碼 (Identification) 用來記錄上層所使用的協定, 亦即 IP Payload 中所載送的是何種協定的資料。目的端收到此 IP 封包後, 才知道要將之送到何種上層協定 (例如：TCP、UDP等)。 IP 封包識別碼 (Identification) IP 封包識別碼是由來源端決定, 並按照 IP 封包發出的順序遞增 1。例如：第 1個 IP 封包的識別碼若為 2001, 第 2 個 IP 封包則是 2002, 第 3 個 IP 封包則是2003...依此類推。

IP 表頭 由於在 IP 路由的過程中, 每個 IP 封包所走的路徑可能不一樣, 因此, 到達目的裝置的先後順序可能與出發時的順序略有不同。此時, 目的裝置便可利用 IP 封包的識別碼, 判斷 IP 封包原來的順序。此外, 識別碼在 IP 封包的切割與重組中, 也扮演了重要的角色。 切割與重組相關資訊 IP 封包在傳送過程中, 可能會進行切割的動作, 然後再由目的端將之重組。而所有與切割、重組相關的資訊, 都記錄在 IP 表頭中。

IP 表頭 存活時間 (Time to Live, TTL) IP 路由的過程必須靠沿途所有路由器通力合作才能完成。但是網際網路上這麼多路由器, 難免會有意外發生, 而使得 IP 封包在眾多路由器之間『流浪』, 永遠都到不了目的裝置。為了避免 IP 封包在浩翰網海中永世不得超生, 因此在 IP表頭中記錄了存活時間, 限制 IP 封包在路由器之間傳送的次數。

IP 表頭 當來源裝置送出 IP 封包時, 會設定存活時間初始值。例如：Windows 2000/XP 預設為 128。當 IP 封包每經過一部路由器時, 路由器便會將 IP 表頭中的存活時間減 1。以 Windows 2000/XP 所發出的 IP 封包為例, 經過第 1 部路由器時存活時間會變為 127, 經過第 2 部路由器時存活時間會變為 126...依此類推。當路由器收到存活時間為 1 的 IP 封包時, 便直接將之丟棄, 不會再傳送出去。

8-2 擷取封包 在本章以及第 10、12、13、14 章中, 我們會用 NetAnalyzer , 實際擷取封包, 一一剖析每個欄位的意義與內容, 驗證各章介紹的理論。 接下來, 就利用 NetAnalyzer 擷取 IP 封包, 看看 IP 表頭欄位的內容。

8-2-1 環境設定 擷取環境是由以下兩部電腦所組成： 首先從 B 電腦以 FTP 工具程式 (Windows 作業系統內建) 連上 A 電腦 FTPServer, 並開始傳送檔案。在檔案傳送的過程中, 從 B 電腦擷取 IP 封包。

8-2-2 檢視封包內容

檢視封包內容 以下為 IP 封包表頭的說明。請讀者注意, 網路監視器已解讀大部份欄位的資訊, 以較易閱讀的方式呈現出來。 Version：4 代表此 IP 封包所使用的版本為 IPv4。 Header Length：IP 表頭的長度為 20 Bytes。 Total Length：IP 封包的總長度。 Identification：此 IP 封包的識別碼。

檢視封包內容 此為 Don't Fragment 欄位。1 代表傳送過程中不可切割。 此為 More Fragments 欄位。因為是未經切割的 IP 封包, 因此為 0。 因未經切割, 所以 Fragment Offset 為 0。 Red Hat Linux 8.1 預設的 Time to Live 為 64。 記錄 Transport 層所用的協定。FTP 使用的是 TCP 協定。

檢視封包內容 這是錯誤檢查碼。每個 IP 封包可能會有不同的錯誤檢查碼。 IP 封包來源裝置的 IP 位址, 亦即 A 電腦的 IP 位址。 IP 封包目的裝置的位址, 亦即 B 電腦的 IP 位址。

8-3 IP 封包的傳送模式 在傳送 IP 封包時, 一定會指明來源位址與目的位址。來源位址當然只有一個, 但是目的位址卻可能代表單一或多部裝置。 依據目的位址的不同, 可區分為 3 種傳送模式：單點傳送、廣播傳送, 以及多點傳送。

8-3-1 單點傳送 (Unicast) 一對一的傳送模式。在此模式下, 來源端所發出的 IP 封包, 其 IP 表頭中的目的位址代表單一目的裝置, 因此只有該一裝置會處理此 IP 封包。在網際網路上傳送的封包, 絕大多數都是單點傳送的 IP 封包。

8-3-2 廣播傳送 (Broadcast) 一對多的傳送模式。在此模式下, 來源裝置所發出的 IP 封包, 其 IP 表頭中的目的位址代表某一網路, 而非單一裝置, 因此該網路內的所有裝置都會收到、並處理此類 IP 廣播封包。由於此一特性, 廣播封包必須小心使用, 否則稍有不慎, 便會波及該網路內的全部裝置。

廣播傳送 (Broadcast) 由於某些協定必須透過廣播來運作, 例如：ARP (第 10 章會說明), 因此區域網路內不可避免會有廣播封包。

8-3-3 多點傳送 (Multicast) 多點傳送是一種介於單點傳送與廣播傳送之間的傳送方式。多點傳送也是屬於一對多的傳送方式, 但是它與廣播傳送有很大的不同。廣播傳送必定會傳送至某一個網路內的所有裝置, 但是多點傳送卻可以將封包傳送給『一群』指定的裝置。亦即, 多點傳送的 IP 封包, 其 IP 表頭中的目的位址代表的是一群裝置。凡是屬於這一群的裝置都會收到此一多點傳送封包。

多點傳送 (Multicast)

多點傳送 (Multicast) 假設我們現在必須傳送一份資料給網路上 10 部指定的裝置。如果使用單點傳送的方式, 必須重複執行 10 次傳送的動作才能達成目的, 不僅沒有效率, 且浪費網路頻寬。如果使用廣播傳送的方式, 則指定網路中的所有 (例如 20 部) 電腦都會收到、且必須處理這些廣播傳送封包, 換言之, 會影響到其他不相干的電腦。 這時候, 如果使用多點傳送, 便能避免單點傳送與廣播傳送的問題。

多點傳送 (Multicast) 多點傳送非常適合傳送一些即時共享的資訊給一群人, 例如：即時股價、多媒體影音資訊等等。不過, 雖然在同一個網路內進行多點傳送沒有技術上的問題, 但若要透過網際網路, 則沿途的路由器必須都支援相關的協定才行。這也是多點傳送所面臨的瓶頸。

8-4 IP 位址表示法 IP 位址本質上是一個長度為 32 Bits 的二進位數字, 看起來就是一長串的 0 或 1： 這樣一長串的二進位數字, 對於一般人來說, 不要說記下來, 連複誦或抄寫都很困難。為了方便起見, 一般使用下列方式來轉換這一長串的 0/1 數字：

IP 位址表示法 首先以 8 Bits 為單位, 將 32 Bits 的 IP 位址分成 4 段： 將各段的二進位數字轉換成十進位數字, 再以 『.』 隔開以利閱讀：

IPv4 與 IPv6 目前網際網路上通用的 IP 版本為第 4 版, 稱為 IPv4。IPv4 的 IP 位址是由 32 Bits 組成, 理論上會有 232 = 4294967296 (將近 43 億個) 種組合。這個數字雖然很大, 但是現實世界對於 IP 位址的需求卻是永無止境。在可預見的將來, 32 Bits 長度的 IP 位址勢必將不敷使用。

IPv4 與 IPv6 為了解決這個問題, 專家們開始研究、設計下一版的 IP 規格―IPv6 (第 6 版的 IP)。IPv6 的 IP 位址是由 128 Bits 所組成, 2128 可說是天文數字, 可提供非常充裕的 IP 位址空間。 關於 IPv6 的深入解析, 請參第 9 章。

8-5 IP 位址的等級 當初在設計 IP 時, 著眼於路由與管理上的需求, 因此制定了 IP 位址的等級 (Class)。雖然這種規劃方式在後來面臨了位址不足的問題, 因而做了許多變更, 但是, 了解 IP 位址等級的來龍去脈, 仍然是深入整個協定的不二法門。

8-5-1 IP 位址的結構 IP 位址是用來識別網路上的裝置, 不過 IP 路由的架構並非以個別的裝置為基本單位, 而是以網路為基礎 (後續會再說明這個觀念)。換言之, IP 位址必須能記載裝置所屬之網路。為了達成此目的, IP 位址是由網路位址與主機位址兩部份所組成：

IP 位址的結構 網路位址 (Network ID) 網路位址位於 IP 位址的前段, 可用來識別所屬的網路。當組織或企業申請 IP位址時, 所分配到的通常並非個別零散的 IP 位址, 而是取得一個獨一無二、以資識別的網路位址。 同一網路上的所有裝置, 都會有相同的網路位址。IP 路由便是依據 IP 位址的網路位址, 決定要將 IP 封包送至哪個網路。

IP 位址的結構 主機位址 (Host ID) 主機位址位於 IP 位址的後段, 可用來識別網路上個別的裝置。同一網路上的裝置都會有相同的網路位址, 而各裝置之間則是以主機位址來區別。

IP 位址的結構 那麼網路位址與主機位址的長度該如何分配呢？我們可以算算看, 如果網路位址的長度較長, 例如：24 Bits, 那麼主機位址便只有 8 Bits, 亦即此一網路位址下共有 28 = 256 個主機位址可資運用, 可分配給 256 部裝置使用。如果網路位址的長度較短, 例如：16 Bits, 那麼主機位址便有 16 Bits, 亦即此一網路位址下共有 216= 65536 個主機位址可資運用, 可分配給 65536 部裝置使用。

IP 位址的結構 由於各個網路的規模大小不一, 大型的網路應該使用較短的網路位址, 以便能使用較多的主機位址；反之, 較小的網路則應該使用較長的網路位址。為了符合不同網路規模的需求, IP 在設計時便依據網路位址的長度, 劃分出 IP 位址等級。

8-5-2 3 種常見的位址等級 當初在設計 IP 時, 著眼於路由與管理上的需求, 因此制定了 5 種 IP 位址的等級 (Class)。不過, 一般最常用到的便是 Class A、B、C 這三種等級的 IP 位址。 這三種等級分別使用不同長度的網路位址, 因此適用於大、中、小型網路。IP 位址的管理機構可根據申請者的網路規模, 決定要賦予何種等級。

Class A 網路位址的長度為 8 Bits, 最左邊的 Bit (稱為前導位元) 必須為 0。Class A的網路位址可從 00000000 (二進位) 至 01111111 (二進位), 總共有 27 = 128 個。

Class A 由於 Class A 的網路位址長度為 8 Bits, 因此主機位址長度為 32-8 = 24 Bits,亦即每個 Class A 網路可運用的主機位址有 224 = 16777216 個 (一千六百多萬)。大部分 Class A 的 IP 位址, 都已經分配給當初參與 ARPAnet (Internet 的前身) 實驗的政府機關、學術單位、企業和非營利組織, 例如：美國國防部、麻省理工學驗和惠普 (HP) 公司。因此, 一般公司行號, 甚至是國家, 都無法申請到 Class A的 IP 位址。

Class B 網路位址的長度為 16 Bits, 最左邊的 2 Bits 為前導位元, 必須為 10 (這是指 2 進位的 10), 因此 Class B 的 IP 位址必然介於 128.0.0.0 與191.255.255.255 之間。每個 Class B 網路可資運用的主機位址有 216 = 65536 個, 通常用來分配給一些大企業或 ISP 使用。

Class C 網路位址的長度為 24 Bits, 最左邊的 3 Bits 為前導位元, 必須為 110 (這是指 2 進位的 110), 因此 Class C 的 IP 位址必然介於192.0.0.0 與 223.255.255.255 之間。每個 Class C 網路可資運用的主機位址有 28= 256 個, 通常用來分配給一些小型企業。

小結 下圖將 Class A、B、C 並列, 方便讀者比較：

小結 從 IP 位址的前導位元, 便可判斷出所屬網路的等級, 進而得知網路位址與主機位址為何。 例如：某主機 IP 位址為 168.95.1.84。我們從第 1 個數字『168』便可判斷此為 Class B 的 IP 位址。因此, 該 IP 位址的前 16 Bits 為網路位址, 後 16 Bits 為主機位址。 依據企業或單位的實際需求, 可分配 Class A、B、C 三種等級的網路位址, 讓 IP 位址的分配更有效率。

8-5-3 特殊的 IP 位址 IP 位址的數量只是數學上各種排列組合的總量。在實際應用上, 有些網路位址與主機位址會有特別的用途, 因此在分配或管理 IP 位址時, 要特別留意這些限制。底下是這些特殊 IP 位址的說明： 主機位址全為 0 用來代表『這個網路』 (This network), 以 Class C 為例, 203.74.205.0 用來代表該 Class C 的網路。

特殊的 IP 位址 主機位址全為 1 代表網路中的全部裝置, 因此也就是『廣播』的意思。以 ClassC 為例, 假設某一網路的網路位址為 203.74.205.0, 若網路中有一部電腦送出203.74.205.255 的封包, 即代表這是對 203.74.205.0 這個網路的廣播封包, 所有位於該網路上的裝置都會收到並處裡此封包。事實上, 只要沿途的路由器支援, 位於其他網路的裝置, 也可傳送此類廣播封包給 203.74.205.0 這個網路中的所有裝置。

特殊的 IP 位址 若網路位址與主機位址皆為 1, 亦即 255.255.255.255, 稱為 『Limited』 或『Local』 廣播封包。此種廣播的範圍僅限於所在的區域網路。亦即, 只有同一網路位址上的裝置可收到此種廣播。

特殊的 IP 位址 Class A 的最後 1 個網路位址 (也就是除了前導位元外, 其餘的網路位址位元皆設為 1) 代表 『Loopback』 位址。換句話說, Class A 的 127.X.Y.Z 整段 IP 位址皆可作為 Loopback 位址, 其中以 127.0.0.1 最常被使用。 Loopback 位址主要用來測試本機電腦上的 TCP/IP 之用。當 IP 封包目的端為 Loopback 位址時, IP 封包不會送到實體的網路上, 而是送給系統的 Loopback 驅動程式來處理。

特殊的 IP 位址 在設計 IP 時, 考慮到有些網路雖然使用 TCP/IP 的協定組合, 但不會與網際網路相連。因此, 在 Class A、B、C 中都保留了一些私人 IP 位址(Private IPAddress), 供這類網路自行使用：

特殊的 IP 位址 若 IP 封包的目的位址為私人IP 位址時, 在 ISP 的路由器不會放行此種封包, 因此無法在網際網路上流通。

8-6 子網路 (Subnet) IP 位址等級的設計雖然有許多好處, 但有一個缺點, 便是彈性不足。舉例而言,假設 A 企業分配到 Class B 的 IP 位址, 但若將六萬多部電腦連接在同一個網路中,勢必造成網路效能的低落, 因此在實際上不可行。但是, 若在 Class B 網路中只連接幾十部電腦, 不是會浪費掉許多 IP 位址嗎？

子網路 (Subnet) 解決這個問題的方法, 便是讓企業能自行在內部將網路切割為子網路 (Subnet)。例如：A 企業將分配到的 Class B 網路切割成規模較小的子網路, 再分配給多個實體網路。換言之, 利用子網路能讓原先只有 3 種等級的 IP 位址更加具有彈性。

子網路 (Subnet) 當我們要將現有網路切割為子網路時, 請先釐清『需要多少個子網路』和『每個子網路包含多少部主機』兩個問題。務必在這兩個問題都有了清楚的答案之後, 才可以開始動手實作。

8-6-1 切割為子網路的原理 切割子網路的重點便是讓每個子網路擁有一個獨一無二的子網路位址 (Subnet Address), 以資識別子網路。 由於企業分配到的網路位址是無法變動的, 因此, 如果要切割子網路的話, 必須從主機位址『借用』前面幾個 Bit, 作為子網路位址。原先的網路位址加上子網路位址便可用來識別特定的子網路。

切割為子網路的原理 假設 A 企業申請到 Class B 的 IP 位址如下：

切割為子網路的原理 按照原先等級式 IP 的規劃, 前面 16 Bits 是網路位址, 後面 16 Bits 則是主機位址。若要切割子網路, 必須借用主機位址的前幾個 Bit 作為子網路位址。假設我們現在使用主機位址的前 3 Bits 作為子網路位址：

切割為子網路的原理 子網路位址與原先的網路位址合起來共 19 Bits, 可視為是新的網路位址, 用來識別該子網路。原先 16 Bits 的網路位址當然不可更動, 但是子網路位址卻是可以自行分配。若子網路位址使用了 3 Bits, 則產生了 23 = 8 個子網路：

切割為子網路的原理

切割為子網路的原理 換言之, 從主機位址借用了 3 Bits 之後, 便可以切割出 8 個子網路。當然, 相對地主機位址長度變短後, 所擁有的 IP 位址數量也減少了。以上例而言, 原先 ClassB 可以有 216 = 65536 個可用的主機位址；而分割成 8 個子網路時, 每個子網路僅有 213 = 8192 個可用的主機位址。

切割為子網路的原理 由於子網路位址必須取自於主機位址, 每 『借用』 n 個主機位址的位元, 便會產生 2n 個子網路。因此, 子網路的數目必然是 2 的冪方, 也就是 22、23、24、25 等數目。 下表列出 Class B 網路可能切割子網路的方式：

切割為子網路的原理

切割為子網路的原理 下表列出 Class C 網路可能切割子網路的方式：

切割為子網路的原理 上表只是表示使用多少個位元作為子網路位址時, 可產生的子網路與可分配主機位址的數目。但在實際應用上, 必須記得子網路位址與主機位址不得全為 0 或 1 的原則。所以, 上表中有幾個項目實際上是不可行的：

切割為子網路的原理 不可能使用 1 Bit 作為子網路位址, 因為它只能建立 2 個子網路位址, 扣掉全為0 或 1 的子網路位址, 即沒有可用的子網路。 不能使主機位址只剩下 1 Bit, 因為此時每個子網路只能有 2 個主機位址, 扣掉全為 0 或 1 的主機位址, 就沒有可用的主機位址了。

8-6-2 子網路遮罩 子網路不僅是單純的將 IP 位址加以切割, 其關鍵在於切割後的子網路必須能夠正常地與其他網路相互連接, 也就是在路由過程中仍然能識別這些子網路。此時,便產生了一個問題：無法再利用 IP 位址的前導位元, 來判斷網路位址與主機位址有多少個位元。

子網路遮罩 以上述 A 企業最後所分配到的網路位址為例, 雖然其前導位元仍然為 10, 但是經過子網路切割後,網路位址長度並非 Class B 的 16 Bits, 而是 17、18 個以上的位元。 因此, 勢必要利用其他方法來判斷 IP 位址中哪幾個位元為網路位址, 哪幾個位元為主機位址。子網路遮罩 (Subnet Mask) 正是為了此目的因應而生。以下說明子網路遮罩的特性：

子網路遮罩 子網路遮罩長度為 32 Bits, 與 IP 位址的長度相同。 子網路遮罩必須是由一串連續的 1, 再跟上一串連續的 0 所組成。因此, 子網路遮罩可以是這類的 32 位數字：

子網路遮罩 但不可以是如下的數字： 為了方便閱讀, 子網路遮罩通常也用與 IP 位址相同的十進位來表示。例如： 通常寫作：

子網路遮罩 子網路遮罩必須與 IP 位址配對使用才有意義。單獨的子網路遮罩不具任何意義。當子網路遮罩與 IP 位址一起時, 子網路遮罩的 1 對映至 IP 位址便是代表網路位址位元, 0 對映至 IP 位址便是代表主機位址位元。例如：

子網路遮罩 代表此 IP 位址的前 21 Bits 為網路位址, 後 11 Bits 為主機位址。路由過程中,便是據此來判斷 IP 位址中網路位址的長度, 以便能將 IP 封包正確地轉送至目的網路。而這也是子網路遮罩最主要的目的。 請讀者注意, 上述 IP 位址與子網路遮罩的組合亦可寫成：

子網路遮罩 『/』前面是正常的 IP 表示法, 『/』後面的數字 21 則代表子網路遮罩中 1 的數目。 原有等級式的網路位址仍然可繼續使用。以 Class C 的 IP 為例： 若不執行子網路切割, 則其子網路遮罩為：

子網路遮罩 換言之, 原先使用 A、B、C 三種等級的網路仍然可繼續使用, 只是必須額外設定對應的子網路遮罩。Class A、B、C 對應的子網路遮罩如下：

8-6-3 子網路切割實例 (一) 子網路切割是相當常見的應用, 以下便以實例說明如何在企業內部切割子網路。 假設 A 企業費了一番功夫終於申請到如下的 Class C IP 位址：

子網路切割實例 (一) A 企業由於業務需求, 內部必須分成 A1、A2、A3、A4 等 4 個獨立的網路。此時便需要利用子網路切割的方式, 建立數個子網路, 以便分配給這 4 個獨立的網路。 首先要決定的是子網路位址的長度。讀者可以查一下前面的資訊, 若子網路位址為 2 Bits, 可形成 4 個子網路, 但是子網路位址不可全為 0 或 1, 因此實際上可用的子網路只有 2 個。

子網路切割實例 (一) 若子網路位址為 3 Bits, 可形成 8 個子網路, 扣除子網路位址全為 0 或 1 的子網路, 因此實際上可用的子網路有 6 個, 足以符合 A 企業的需求。 決定了子網路位址的長度後, 便可以知道新的子網路遮罩, 以及主機位址的長度。由於使用了 3 Bits 作為子網路位址,網路位址變成 24+3 = 27 Bits。因此, 新的子網路遮罩為：

子網路切割實例 (一) 而原先的主機位址有 8 Bits, 但是子網路位址借用了 3 Bits,主機位址只能使用剩下的 5 Bits。因此, 每個子網路可以有 25 = 32 個 可用的主機位址。不過,主機位址不得全為 0 或 1, 所以實際上每個子網路可分配的 IP 位址為 30 個。 A 企業的網管人員接著便必須決定子網路分配的方式。下表將子網路依序分配給 A1-A4 等 4 個網路：

子網路切割實例 (一)

子網路切割實例 (一) 「為什麼第 1 個可用的 IP 位址是 203.74.205.『33』 , 而不是 203.74.205. 『1』 呢？」 別忘了, 現在最右邊 1 個 Byte 的最高 3 個 Bit 已經用來表示子網路, 因為不能用『000』表示子網路, 所以這 3 個 Bit 的最小值是『001』。而剩下用來表示主機位址的 5 個 Bit, 其最小值為『00001』, 兩者結合起來便是 2 進位的『00100001』, 相當於 10 進位的 33。

子網路切割實例 (一) 那麼 203.74.205.1〜203.74.205.32 這些 IP 位址就不能用了嗎？ 是的, 在一般的情形下, 這些位址就等於是被浪費掉了！這也正是使用切割子網路技術的先天缺陷。不過現在有些廠商推出特定型號的路由器, 可以允許使用『000』作為子網路位址。由於這部分牽涉到比較深入的技術, 因此不在本書討論。

子網路切割實例 (一) 接著是最重要的步驟, 關係著子網路是否能正確地運作, 便是必須在 A 企業所有的路由器上設定 A1 、A2 、A3 、A4 等子網路的路由紀錄, 以便在路由器能將 IP 封包正確地傳送到切割後的子網路。 子網路切割至此大功告成。但是, 最後有兩項要請讀者注意：

子網路切割實例 (一) 子網路可再進一步切割成更小的子網路。承上例, 例如：網管人員可以再將 A1網路切割成更小的子網路。方法仍舊是從主機位址借用幾個位元來作為子網路位址。 子網路切割時所作的設定, 都是在企業內部。換言之, 遠端的網路或路由器並不須知道 A 企業內部是如何切割子網路。如此, 可保持網際網路上路由架構的簡單性。

8-6-4 子網路切割實例 (二) 接下來我們將介紹數個子網路切割的練習題, 方便讀者更熟悉子網路的運作。 某台主機的 IP 位址為 192.168.1.134, 子網路遮罩為 255.255.255.248, 則該主機所在的子網路的『網路位址』為何？ 由網路位址第一個數字 192 得知此主機位於 Class C 等級, 我們將最後一個數字改寫為 2 進位：

子網路切割實例 (二) 原 IP 位址第 4 個數字的前 5 個 Bits 用來分割子網路, 故 192.168.1.134 位於10000 這個子網路, 此子網路的網路位址為 192.168.1.128 (2 進位的 10000000 相當於 10 進位的 128)。

子網路切割實例 (二) 假設某個子網路的子網路遮罩為 255.255.255.224, 請判斷 205.64.75.223 是否屬於此子網路裡網路設備可用的 IP 位址？ 從 205.64.75.223 得知此主機位於 Class C 等級, 前 24 Bits 為網路位址, 後 8 Bits 為主機位址。為方便說明, 我們將主機位址與 255.255.255.224 子網路遮罩改寫為 2 進位：

子網路切割實例 (二) 由子網路遮罩可知, 主機位址的前 3 個 Bits 代表子網路位址：

子網路切割實例 (二) 由於主機位址不得全為 1, 所以 205.64.75.223 不是 110 子網路裡網路設備可用的IP 位址。 255.255.252.0 這個子網路遮罩最多可將 132.114.0.0 這個網路分割為幾個有效的子網路？每個子網路中最多可以有幾台主機？

子網路切割實例 (二) 由 IP 位址第 1 個數字 132 得知此網路是 Class B 等級, 子網路遮罩藉由第 3 個數字的前 6 個 Bits 用來分割子網路, 所以最多可分割出 26 - 2 = 62 個子網路；主機位址以 8 + 2 = 10 個 Bits 來表示, 所以每個子網路可以有 210 - 2 = 1022 台主機。

子網路切割實例 (二) 在 Class C 等級網路中若至少要分割出 13 個子網路, 則子網路遮罩為何？ 由於全 0 與全 1 的子網路不能使用, 所以子網路遮罩至少須能分割出 13 + 2 =15 個子網路, 24 = 16 > 15 而 23 = 8 < 15, 表示至少須借用 IP 位址最後一個數字的前 4 個 Bits 來分割子網路, 故子網路遮罩為 11111111.11111111.11111111.11110000 (255.255.255.240)。

8-7 無等級的 IP 位址 當初在設計 IP 位址的等級時, 網路環境主要是由大型主機所組成, 主機與網路的總數都相當有限。但隨著個人電腦與網路技術的快速普及, 對於 IP 位址的需求也迅速增加。 3 種等級的 IP 位址分配方式, 很快便產生了一些問題。這其中最嚴重的便是 Class B 的 IP 位址面臨缺貨的危機；但是相對地, Class C 使用的數量則僅是緩慢成長。

無等級的 IP 位址 為了解決這個問題, 便產生了 Classless Inter-Domain Routing (CIDR), 亦即無等級 (Classless) 的 IP 位址劃分方式。

8-7-1 CIDR 原理 其實, Class B 那麼快被耗盡, 有很多位址空間是浪費掉了。 舉例而言, 假設 B 企業需要 1500 個 IP 位址, 由於 Class C 位址只能供 256 個 IP 位址,因此必須分配 Class B 的網路位址給此 B 企業。不過, Class B 其實可提供 65536個 IP 位址, 遠超過 B 企業的需求, 這些多出來的 IP 位址無法再分配給其他企業使用, 因此實際上都浪費掉了。

CIDR 原理 既然 Class B 嚴重不足, 而 Class C 還很充裕, 更重要的是 Class B 實際上有很多 IP 位址是浪費掉了, 那麼要解決這些問題, 自然地便會想到是否可以將數個Class C 的 IP 位址 『合併』 起來, 分配給原先要求申請 Class B 的企業。 以前例而言, 我們只要分配 6 至 7 個 Class C 的 IP 位址給 B 企業, 便可符合其需求, 因而節省下 1 個 Class B 的位址空間。

CIDR 原理 那麼, 要如何才能合併數個 Class C 的 IP 位址呢？ 答案便是使用子網路遮罩來定義較具彈性的網路位址。讀者可能會覺得很訝異, 這不是與子網路切割的原理相同嗎？沒錯, CIDR 又稱為超網路 (Supernet), 與子網路可算是一體的兩面, 兩者其實都是使用相同的觀念與技術, 只是在應用上略有不同, 其觀念差異如下：

CIDR 原理 子網路 (Subnet) 超網路 (Supernet) 利用子網路遮罩重新定義較長的網路位址, 以便將現有的網路加以切割成 2、4、8、16 等 2 冪方數的子網路。 超網路 (Supernet) 利用子網路遮罩重新定義較短的網路位址, 以便將現有 2、4、8、16 等 2 冪方數的網路, 『合併』 成為一個網路。

8-7-2 CIDR 實例 回到 B 企業的例子, 由於 B 企業所須的 1500 個 IP 位址, 數量介於 Class B (可提供 65535 個 IP 位址) 與 Class C (可提供 255 個 IP 位址) 的範圍之間。藉由CIDR 的方式, 我們可以分配一個長度為 21 Bits 的網路位址給 B 企業, 那麼 B 企業可供運用的主機位址將會有 32-21 = 11 Bits, 總共可產生 211 = 2048 個 IP 位址,與 B 企業所需的 1500 個 IP 位址相近。與直接分配 Class B 相比, 節省下許多 IP位址空間。

CIDR 實例 上述方式其實便是將 8 個 Class C 的 IP 位址合併, 再分配給 B 企業。由於合併是透過變更網路位址長度來進行, 因此會有以下的限制： 用來合併的 Class C 的網路位址必然是連續的。 用來合併的 Class C 的網路位址數目必然是 2 的冪方數。 因此, B 企業實際上分配到的可能是如下的 8 個連續 Class C 位址空間：

CIDR 實例

CIDR 實例 這 8 個連續的 Class C 位址可以利用下列方式來表示：

CIDR 實例 雖然 CIDR 原先是為了合併 Class C 位址所設計, 但在實作上可適用於任何的 IP 位址範圍, 例如：ISP 可分配長度為 30 Bits 的網路位址給一些只有兩部電腦的個人公司。

CIDR 實例 由於 CIDR 讓 IP 位址在分配時更具彈性與效率, 因此, 目前皆是以 CIDR 的方式來劃分 IP 位址範圍。 多年前, 許多專家都預測 IPv4 的 32 Bits 位址空間將於西元 2000 年用盡。所幸新的技術不斷誕生, 為 IPv4 爭取更長的壽命。除了子網路、CIDR 等方案外,接著要介紹的網路位址轉譯也是一項節省 IP 位址空間的重要技術。

8-8 網路位址轉譯 (NAT) 凡是使用 IP 協定的裝置, 都必須指定一個獨特的 IP位址。近年來由於網際網路的日漸普及, IP 位址也逐漸不敷使用。一般公司行號所能申請到的 IP 位址數量有限, 經常有不夠用的情況發生。 為此網路位址轉譯 (Network Address Translation, NAT) 機制應運而生, 它可以解決 IP 位址不足的頭痛問題, 讓許多台電腦可以共用一個合法的 IP 位址。

8-8-1 網路位址轉譯的原理 網路位址轉譯的運作方式如下圖所示：

網路位址轉譯的原理 如上圖所示, 整個區域網路內的電腦 (或稱用戶端) 皆使用私人 IP 位址, 並透過一個合法的 IP 位址與外界連線。 這個合法的 IP 位址可以是透過專線連接的固定式 IP 位址, 或是透過撥接由 ISP 分配的動態 IP 位址：

網路位址轉譯的原理

網路位址轉譯的原理 網路位址轉譯的原理並不難, 當使用私人 IP 位址的電腦對外傳送 IP 封包, 首先會送至具有網路位址轉譯功能的 NAT主機, 並在此將 IP 封包的來源位址, 從私人位址轉為合法的 IP 位址後, 再送到外界。 IP 封包從外界送入時, NAT主機會先判斷封包目的地, 然後將目的位址從合法的 IP 位址轉為私人位址, 再送到區域網路內。

網路位址轉譯的原理

網路位址轉譯的原理 當區域網路內許多部電腦的私人位址都對應到同一個合法 IP 位址時, 網路位址轉譯機制如何判斷那個 IP 封包該送給那一台電腦呢？這主要是藉由用戶端 TCP/UDP 連接埠號碼來判斷。換言之, 只有使用 TCP/UDP 協定的應用程式才能透過網路位址轉譯與外界連線。

網路位址轉譯的原理 我們以向 Internet 上的 Web 伺服器要求網頁資料為例, 說明連接埠在NAT中扮演的腳色：

網路位址轉譯的原理 用戶端向 Web 伺服器要求網頁資料, 其 IP 封包會包含以下的資訊： 目的地 IP 位址 = 203.74.253.1 (Web 伺服器) 來源 IP 位址 = 192.168.0.200 (NAT 用戶端) 目的地連接埠 = 80 (Web 伺服器預設使用的連接埠) 來源連接埠 = 5000 (由用戶端應用程式自行決定使用的連接埠) 經由 IP 路由機制, 此封包會傳送到 NAT 主機。

網路位址轉譯的原理 NAT 主機收到用戶端的要求後, 會使用本機的 NAT 連接埠, 來對應用戶端的 IP 位址與來源連接埠 (本例為 6000, 對應到 192.168.0.200:5000)。根據這個連接埠, 產生如下的新封包： 目的地 IP 位址 = 203.74.253.1 (Web 伺服器) 來源 IP 位址 = 63.192.168.1 (NAT 主機) 目的地連接埠 = 80 來源連接埠 = 6000 (由 NAT 主機自行產生, 用來對應用戶端的 IP 位址)

網路位址轉譯的原理 Web 伺服器傳回網頁資料, 其封包會包含以下的資訊： 目的地 IP 位址 = 63.192.168.1 (NAT 主機) 來源 IP 位址 = 203.74.253.1 (Web 伺服器) 目的地連接埠 = 6000 來源連接埠 = 80

網路位址轉譯的原理 NAT 主機收到傳回的資料後, 發現目的地連接埠 6000 對應到 192.168.0.200這個 IP 位址與 5000 這個連接埠, 於是產生如下的新封包, 傳送到 NAT 用戶端： 目的地 IP 位址 = 192.168.0.200 (NAT 用戶端) 來源 IP 位址 = 203.74.253.1 (Web 伺服器) 目的地連接埠 = 5000 (用戶端應用程式使用的連接埠編號) 來源連接埠 = 80

8-8-2 網路位址轉譯的注意事項 網路位址轉譯雖然解決了 IP 位址不足的問題, 但在使用上仍有其限制： 無法使用某些加密協定 IP 封包經過某些加密協定 (例如 IPSec 詳見 16-9 節) 的加密後, 會令網路位址轉譯機制無法辨識這些加密過的 IP 封包內容, 自然也就無法處理這些封包的轉譯遞送程序。

網路位址轉譯的注意事項 增加伺服器的運算負擔 由於網路位址轉譯必須持續記錄、追蹤 TCP/UDP 連接埠號碼與特定私人 IP 的對應關係, 若許多使用私人 IP 位址的電腦同時連上網路, 會消耗伺服器不少的資源。

網路位址轉譯的注意事項 外界主動存取時, 設定較為複雜 由於 NAT 主機會對出去的封包記下來源位址與連接埠號碼, 所以當網際網路上的電腦回覆時, NAT 主機便能將此回覆封包送到正確的主機與連接埠。 當網際網路上的電腦主動要存取內部網路上的電腦時, 由於沒有記錄可查詢, 所以 NAT 主機無法判斷該將此封包送給誰, 便丟棄此封包。

網路位址轉譯的注意事項 倘若要在內部網路架設伺服器, 就必須在 NAT 主機手動設定轉譯機制。 以 Web 伺服器為例, 假設 Web 伺服器的 IP 位址是 192.168.0.100, 使用 TCP 8080連接埠, 則我們應在 NAT 主機設定：『若收到要與 TCP 80 連接埠建立連線的封包, 一律轉送到192.168.0.100 這部主機的 TCP 8080 連接埠』。這樣便可以讓網際網路上的電腦存取 NAT 環境下的伺服器：

網路位址轉譯的注意事項

網路位址轉譯的注意事項 基本上, 上述的原理適用於所有的 NAT 環境, 然而在實際的設定方式上, 會因為各家產品的限制條件而有差異。