APNIC文摘—位址意義演變(上)

本APNIC文摘原標題為Address semantics,由Geoff Huston撰文。

本文由APNIC首席科學家Geoff Huston撰文,從「位址」的意義談起,隨著網際網路技術及架構的發展進化,逐步探討IP位址的功能、相關技術和意義的演變。

在不同通訊系統中,無論是寄信時信封上的地址,撥打電話的電話號碼,或是在網際網路中傳送封包需要的IP,縱使形式或指稱不同,但這些其實都是所謂的「位址」。

位址(address)通常包含3種元素,分別是身份識別(identity)、位置(location)和可聯絡性(reachability)。

身份識別和「獨特性」密不可分。理論上,正常運作的網路系統應指派專屬的單一位址給所有使用者;若否,則必須額外想方設法,解決多個實體使用同一位址可能衍生的衝突。以電話為例,一個號碼最好只能連通一支電話。

IP位址在網際網路的架構中的角色類似電話號碼,但IP位址並非用來識別「電腦」,而是電腦連接網路的接口。也就是說,如果一臺電腦有多個連網接點,則這個電腦也會擁有多筆IP位址。

然而,只知道某個實體存在(有身份),卻不知道它位於網路中的什麼位置,在網路運作上等於沒有用。也因此,大部分的位址系統都會賦予每筆位址「識別身份」和「標示位置」至少兩種性質。

以電話號碼為例,國際電話號碼通用格式E.164可以用來標示號碼所在的國家及地區。IP位址系統類似但更簡化,位址只分成網路和主機兩部分。同一網路中所有主機的IP位址會使用同樣的前綴,主機位址則各自不同。IPv4容許自訂前綴長度,IPv6則有更嚴謹的格式規定。從這角度而言,每筆IP位址都是網路識別碼和主機識別碼的串連,同時具有識別身份和標示位置的功用。

最後,位址當然必須包含某種「可聯絡」的資訊,用來協助網路中的其中一點連接另外一點。

在傳統的IP位址架構中,一筆IP位址必須能同時用來識別身份、標示位置,並提供網路要把封包傳送到哪裡的相關資訊。這種同一位址負擔多重角色的設計,有人認為是讓網路平臺得以極高成本效益運作的關鍵,也有人指出這是「意義過載」的典型案例,容易導致同一物件必須執行的某項功能,反而妨礙到另一項功能。

位址作為身份識別碼更深層的意義,在於位址和裝置之間因此具有獨一無二的連結。這在過去大型電腦盛行的年代很合理,但隨著客製化個人電腦成為主流,加上越來越多個人行動裝置進入網際網路,這樣的設計很快顯得不堪負荷。事實上,作者指出,位址系統的設計缺陷早在1980年代,網際網路商業化的時候就出現了。

回顧網際網路發展,作者更進一步點出,從撥接網路邁向大眾化開始,IP位址的意義就已逐漸轉變。在撥接網路時代,使用者是透過撥打電話建立網路連線;線路另一端的服務供應商驗證使用者的登入資訊後,才會指派IP位址,在連線時間內,使用者都將利用這個指派IP位址上網。

這種作法是以「分時」(time-sharing)概念使用IP位址,使用者只在連網期間暫時使用獲指派的IP位址。接著出現了網路位址轉譯(network address translation,NAT)技術,以連接埠為基礎,讓多個本地裝置共享IP位址。

分時共享IP和NAT的技術,都在網際網路模型中引入間歇連線裝置的概念。這些裝置只有需要時才會連網,當然不能視為服務主機。於是,我們開始將連網裝置分成「客戶端」和「伺服器」兩種類別,客戶端需要時才連接伺服器,不必無時無刻連網,自然也不需除了連線登入帳密外的永久性網路識別身份(如IP位址)。

在這些IP共享技術流行的同時,IPv4位址也逐漸枯竭,IPv6因此誕生。

上述IP共享技術和IPv6之間最大的差異,在於前者只是被動新增的片面解方,後者則是IETF領導的組織力量,試圖預測未來業界需求,並提出滿足這些需求的技術方案。另一方面,驅動業界的兩大因素則分別是無止盡擴張、難以追趕的消費者需求,以及業者始終最重視的,如何降低服務成本。

作者特別指出,他不認為IPv4位址耗竭是NAT被大幅採用的主要原因;在NAT下,ISP只需發給客戶端一筆IP位址,而由NAT轉換共享的多筆私人IP位址都由客戶端自行管理。對ISP而言,需要管理的IP位址越少就越省成本,換句話說,NAT盛行單純是因為這樣最省錢。

總結而言,在網際網路發展的進程中,分時作法和NAT技術雖然起到改變IP位址意義的作用,但這並非因為業界有什麼先知灼見而刻意規劃執行的後果,只是在缺乏規範的市場中,生意人為了省錢而出現的慣例做法。

延續此篇,下一篇作者將檢視與IP共享技術截然不同的IPv6,並進一步剖析網際網路近年來的發展,可能如何再度促成IP位址意義和功能的變化。

*台灣網路資訊中心(TWNIC)與亞太網路資訊中心(APNIC)合作,定期精選APNIC Blog文章翻譯摘要,提供中心部落格讀者了解目前亞太地區網路發展之最新趨勢。原文標題為Address semantics

回到頂端