Autoconfiguration for IP Networking: Enabling Local Communication 翻譯

IP網絡自動配置：實現本地通信

Erik Guttman
Sun Microsystems, Germany

如果一個因特網協議套件的主機實現可以完全自我配置的話那就太完美了。這樣就能讓整個套件實現在ROM中或者固件化，這能簡化無磁盤的工作站，對於苦惱的局域網管理員和系統廠商來說是一個非常棒的禮物。但我們當前並沒有實現它；事實上，連接近都沒有。— RFC 1122。

IP主機和網絡基礎設施自古以來就難以配置—需要網絡服務並依賴技術精湛的網絡管理員—但新興的網絡協議承諾其能使得主機在不用預先配置以及不需要網絡服務的情況下建立IP網絡。甚至對於計算資源有限的簡易設備，不管它被接入哪裏，都將能夠使用標準協議進行通信。當前IETF的標準化工作，如Zeroconf工作組的工作，致力於使這種形式的聯網更簡單和便宜。

那些永久連接到一個受管理的網絡的主機通常會被網絡管理員賦予靜態的網絡配置。其他連到受管理網絡(例如企業局域網或撥入帳戶)的主機則使用動態網絡配置。在這些情況下，所有必要的參數都由一個網絡配置服務授予主機，網絡配置服務本身需要配置。在許多情況下—如臨時會議、受管理網絡配置失敗或者網絡服務故障—我們很想建立一個IP網絡，但是管理它可能會不切實際甚至不可能。在這些情況下，自動的網絡參數配置對於主機是很有價值的。IETF Zeroconf WG的真正目標是實現兩個或多個計算設備間經由IP的直接通信。在這個教程中，我給出了零配置聯網(Zero Configuration Networking)的背景、當前狀態和未來展望。

零配置聯網

自動配置的參數與靜態和動態配置分配的參數具有不同的屬性。它們是短暫的；它們很可能每次獲得時都不一樣並且任何時刻都可能改變。自動配置的主機會主動地參與分配和維護它們的配置參數，這些參數只具有本地意義。網絡服務的自治意味着主機必須配置網絡。

直接比較來說，一般的IP配置是持久的(特別是對於服務器)，或起碼是穩定的。IP協議套件致力於實現可擴展性，尤其是在配置方面。地址和名字通常有全局意義，這已被證明對實現因特網增長十分必要。但是，獲取和管理全球地址和名字需要許多管理工作。這些過程並不是完全自動化的，並且很可能永遠不是。

拋開這些差異，基本的零配置網絡協議實際上只意味着對支持IP的設備的較低層進行修改。(小貼士“IP主機分層”中介紹了討論自動配置所需的術語)。

現有的基於網絡的應用程序將在不修改增強的網絡服務和使用標準接口的應用程序層的情況下工作。事實上，用戶甚至都不應該意識到網絡服務層是被自動而不是靜態或動態配置的。

在IPv4和IPv6下，四個功能將受益於零配置聯網。不需要修改現有接口，零配置協議就將增強名字到地址轉換(在應用層)和IP接口配置(在網絡層)。之前IP主機沒有的功能將引入新的接口：應用層的服務發現和網絡層的多播地址分配。

這些額外的服務不會影響現有的應用。他們將“獲得提升”，通過提供因特網協議套件一直缺席，但在蘋果、微軟和Novell的專屬網絡協議套件中擁有的額外特性。(見小貼士“早期的自動配置工作”)。這些專屬協議僅僅因它們易於配置的特性而繼續被使用。採用新興的零配置協議標準將使我們淘汰專屬網絡—向更廣泛的支持前進一步。甚至網絡設備廠商也一直同意說專屬網絡協議已經快要壽終正寢了，應該被替換爲IP標準。

由於擴展性和需要降低對現有網絡的影響，零配置協議對於整個網絡的影響必須受到限制。零配置協議的算法通常使用多播。在實踐中，這些協議被限制於單條網絡鏈路(就是指，沒有路由器來轉發這些協議消息)或者一個網絡集合中(路由器被配置爲邊界，協議消息不會發出邊界)。

定義一種方法

IETF零配置協議標準化的那些工作(當前在Zeroconf、服務定位協議、DNS擴展和IPNG工作組)被認爲是克服人工配置與自動化運作間差異的兩個主要方法。

第一個策略要求在本地和全局配置間進行轉換，從1998年起就在面向消費者的操作系統軟件上進行探索了。這個策略暗示，主機只要缺失全局配置，就將支持自動的配置。這兩種模式是互斥的，要進行動態配置服務需要從自動（本地）配置轉換爲動態（全局）配置。

這種轉換策略的一個例子是蘋果和微軟的桌面操作系統採用的網絡接口自動配置協議。這個(IETF還沒有標準化的)協議使得一個主機能簡單地從一個預留範圍內選擇一個未分配的IP地址。然後主機會嘗試從網絡上通過動態主機配置協議DHCP獲取(全局)IP配置參數。主機週期性地提交DHCP請求，如果網絡上存在一個可達的DHCP服務器的話那這最終會成功。一旦一個DHCP服務器答覆了，並提供了IP配置參數，這參數就會替換自動配置的那個。

這個機制對於採用了常見的客戶端-服務器協議的客戶端來說可以很好的工作，因爲極少會使用長期鏈接。即使連接失敗，單個網絡應用程序操作也會導致明顯的事務(transactions)。如果客戶端主機進行了網絡重配置，應用程序會簡單地建立一條新的鏈接。

然而，如果一個服務器配置修改了，恢復起來就沒那麼容易了：如果他們不能找到服務器，客戶端應用程序就會停止工作。帶有動態地址的服務器只能通過一個動態服務發現協議來定位，並且當前極少基於IP的應用採用服務發現。

服務器地址的重配置可能會搞崩服務器軟件，服務器軟件典型地會綁定到一個(極可能不可變的)地址以接收進入的消息。另外，當一個服務器經由DHCP進行重配置時，它再也不能與還沒重配置的客戶端進行通信。反之，如果DHCP配置了客戶端系統，而沒能配置服務器(比如DHCP服務器不可達)，帶有全局參數的客戶端將無法與服務器通信，這時服務器仍然只有本地自動的配置。

最終，一些及其簡單的設備也許會只支持本地IP配置，無法與通過DHCP配置的主機進行通信。比如，可以開發非常廉價的應用來實現遠程監控服務，客戶端將只需要本地IP配置來跟這些設備通信，除非有額外的網絡基礎設施。

由於發現了IP配置轉換帶來的問題，Zeroconf工作組不鼓勵這個轉換的方法。主機應當要不單獨使用自動配置，要不動態或靜態配置。兩臺連接到同個網絡的實現零配置協議的主機不管是否有DHCP或者其他服務器，都將能夠通信。他們將只需要在衝突時重配置它們的地址(或可能是名字)。

新興的解決方案

Zeroconf工作組已經定義了零配置聯網協議區的四條需求。爲獲得進一步解釋和詳細信息，請參閱草案需求文檔。當前，IETF已經推出或者不久就將推出以下幾個標準。

地址自動配置

首個協議區是地址自動配置。爲了讓一個IP棧傳送IP消息，每個通信終端(源和目標)都需要一個在地址作用域內唯一的IP地址。比如，一個本地鏈路地址會被配置爲鏈路上唯一。地址自動配置的需求包括允許一個主機：

• 使用唯一的地址配置它的接口；
• 確定使用哪一個子網掩碼(子網掩碼用於標識網絡地址，並且使得IP協議棧能確定是否它可以直接傳輸一個數據報)；
• 探測重複的地址分配；以及
• 處理衝突。

當前的Ipv4本地鏈路自動配置規範先後兼容蘋果Macintosh和微軟Windows操作系統軟件，除了一個例外：它推薦維護自動配置的地址(即使一個接口也被配置了全局IPv4地址)而不是從本地轉換爲全局。當前的規範還包括一些指南，有助於爲具有多個啓用IP接口的主機消除本地鏈路尋址的歧義。IPv6的本地鏈路自動配置是IETF的一個草案標準。

圖1中每個設備的每個接口都可以獲得和維護一個唯一分配的地址。主機1和主機2共享一個無線鏈路，在其上，A和B的地址是不同的。主機2、3和4共享一個有線鏈路，其上，地址C、D和E是唯一的。

爲了降低混亂，主機2不會分配與其所連接的任何鏈接上分配的鏈接本地地址衝突的地址。主機2不會試圖在有線鏈路上分配地址A，因爲A已經分配在無線鏈路上了。由於主機2無法控制其他主機，如主機1和3，地址A可能會和地址D一樣。這種情況可能會給主機2帶來歧義。這使得擁有多個接口的主機的本地鏈路地址的自動配置變得更加複雜。

圖 1.IP地址自動配置。每個共享的有線或無線鏈路上的主機地址(A到E)都是唯一的。

名稱到地址轉換

第二個零配置協議區是名稱到地址轉換(name-to-address translation)。IP應用程序典型地通過名稱而不是地址來標識網絡上的終端。當一個終端的地址改變時，這帶來了運行上的穩定性，因爲它的名字沒有變。零配置協議的名稱到地址轉換需要機制以：

• 獲得與一個名字相關聯的IP地址，以及
• 確定與一個IP地址相關聯的名字。

後一個特性有助於未來與客戶端的通信，並使得服務器能生成人類可讀的日誌信息。

本地鏈路多播DNS是在IPv4和IPv6上本地解析名字用的，其使用DNS協議但不需要一個專用DNS服務器。還可以使用節點信息詢問協議(node information query protocol)在IPv6上進行名字到地址轉換。

圖2闡述了使用多播DNS進行名字到地址解析的過程。一個客戶端應用程序請求對應於名字“Sally”的地址，名字到地址的翻譯可以通過提交DNS請求到一個公知的多播IP地址實現。每個主機都監聽這些請求，如果多播DNS請求的名字和自身配置的名字吻合的話則進行答覆。

圖2. 多播DNS協議交互。客戶端通過提交一條請求到一個公知多播地址並等待答覆，而從叫做“Sally”的主機處獲得了IP地址。

服務發現

第三個零配置協議區是服務發現。客戶端應該要在沒有預先配置和網絡上沒有任何管理員配置的管理服務(如目錄)的情況下發現網絡上的服務。另外，服務發現協議不得造成廣播風暴或過分行爲。(一些現存的服務發現協議—最明顯的是IPX協議套件的服務廣告協議—需要過分的網絡資源。)

一些服務是很含糊的，如通用的Web代理、DNS服務器或SMTP中繼；這是說，任何這類的服務器都會執行完全一樣的功能。另一些服務則很明確，每個服務器實例都是獨特的，如不重複數據庫、文件服務器或支持IP的打印機。能分辨後一類服務器的能力讓客戶端能發現它需要的服務器，而不是發現所有它能夠通信的服務器(其中大部分對其沒有用)。

IETF已經爲在IP網絡上發現服務的需求標準化了兩個機制。服務定位協議(SLP)V2使用管理作用域的多播，因爲它被設計來擴展單個管理域（通常包括整個站點，如校園或企業網絡）。大部分其他的零配置協議被定義爲用在本地鏈路多播上。SLP提供基於服務類型和服務屬性的服務發現，所以客戶端可以通過指定需要的特性來發現一個特定的服務器。SLP被定義於使用在IPv4和IPv6上。我在早先的IC文章中更詳細的討論了SLP。

第二個IETF服務發現機制是DNS SRV資源記錄，它使得客戶端能通過DNS查閱服務。客戶端指定要查閱的服務類型、傳輸協議和域名。對這個詢問的答覆會提供符合請求的主機的清單。

圖3闡述了使用SLPv2的服務發現。客戶端應用程序請求服務“Bar”的位置，包括需求的服務類型和服務屬性。SLPv2用戶代理代表客戶端多播這個需求。如果SLPv2服務代理正在廣告的服務符合請求的話，它就會響應一個服務答覆。

圖3. 使用SLPv2進行服務發現。一個客戶端應用請求服務“Bar”的位置，如果SLPv2服務代理正在廣告的服務符合請求的話，它就會響應一個服務答覆。

多播地址分配

工作組指出的第四個協議區是多播地址分配。一些基於多播的應用程序需要獲得一個唯一的多播地址以避免其他應用程序(或基於同個應用的會話)與它們衝突。多播地址衝突可能導致應用程序故障，機理類似兩臺主機配置同樣的IP地址：來自兩個不同會話的通信可能被傳遞到不正確的目的地。

Zeroconf多播地址分配協議(ZMAAP)支持應用：

• 分配唯一地址並一直維護；
• 阻止重分配被分配過的地址；以及
• 在發生多播分配衝突時被通知。

這些需求和地址自動配置裏的不一樣，因爲多播地址是一個共享資源。在許多情況下，跨網絡存在的不同進程需要共享分配控制。第二個和第三個ZMAAP需求使得任何進程能延長一個會話以及發現會話是否仍然有效。

滿足需求的推薦協議規範的當前版本可以在Zeroconf工作組頁面上找到。

加密Zeroconf協議

專屬自動配置協議不提供加密它們基礎操作的機制。AppleTalk、IPX和NetBIOS網絡加密機制爲應用程序提供面向用戶和組羣的訪問控制，但是自動的配置協議(地址分配、名字解析和服務發現)仍然是未加密的。這使得這些協議套件很簡單，但是也使它們易受攻擊。

自動配置可以很危險。如果沒使用合適的加密機制，能訪問一個局域網的任何人都可以輕易破壞那使用的零配置協議。隨着無線網絡技術的部署和共享網絡跨圖像纜、供電纜和其他住宅接入媒體的擴展，未授權訪問越來越可能了。

由於與零配置網絡的基本目的相悖，不能自動地配置加密，但這對於管理者來說仍然很簡單。Zeroconf工作組已經指出了一個需求集以確保使用零配置協議的操作會和使用相關配置過的IETF協議一樣安全。已經討論了簡單地配置IP主機來加密操作的特別機制，但是還沒有推出推薦規範。

進一步發展的一個重要領域是對自動配置網絡的安全遠程訪問。許多家居網絡產品已經提供了在私有網絡上遠程監控設備的專用解決方案。也許建立一個標準網關機制來讓遠程網絡上的主機訪問本地配置過的設備會十分有用。未來還需要對建立簡單地管理和互用性機制以配置設備組中的加密參數進行研究。

網絡管理

由於零配置協議允許主機同時被自動配置和被管理，網絡管理員可能會面臨一些問題。

• 使用本地分配地址和名字的IP主機只能在單個局域網上訪問。這與被配置爲更大作用域的地址的主機反差，如全球唯一IP地址，其(理想情況下)可以被任意因特網上的網絡訪問(忽略防火牆這些細節)。
• 現今的管理員希望網絡通信被限制於它們配置和控制的主機。在未來，許多在單條鏈路上的通信可能是處於完全使用本地參數的設備間的—有時在從不獲得受管理分配的參數的設備間。
• 在沒有DHCP的網絡上，用戶預期管理員會通過配置分配來啓用聯網。在用戶習慣了自動配置的網絡後，就不會這樣了。
• 用戶將會想要在網絡上的任意位置訪問本地鏈路配置的服務。這將需要對服務額外的配置或者應用層網關、代理或一個更復雜的策略，這策略涉及遠程訪問僅本地鏈路服務所在的網絡。

零配置協議將很可能通過減少設置和運行IP主機本地通信時的問題，簡化網絡管理。同時，主機潛在地將會有兩種配置(本地和全局)，這將導致複雜的情況。我在其他地方進一步探討了零配置網絡的許多體系結構問題。

對未來的展望

IETF不久就將發佈零配置協議需求規範和新興標準跟蹤協議。這預示着簡單可互用IP設備的發展以及局域網穩定性和可用性的增強。

同樣討論了創建一個profile來指定符合主機實現的零配置協議集。受到IP主機需求規範的啓發，這個方法將激勵廠商實現單個協議集合。IETF通常會避免推薦或要求特定協議(幾乎所有的IETF標準都被分類爲可選)。IP主機需求被髮布來描述先期經驗而不是指定未來的解決方案。因此，還不是很確定Zeroconf工作組是否將製作profile文檔。

如我之前提到的，加密機制將需要額外的探索，並且將很可能產生新的網絡管理挑戰，但是IETF零配置協議不久就將發佈；實際上，許多已經在那了。

參考文獻

1. R. Braden, “Requirements for Internet Hosts—Communication Layers,” IETF RFC 1122, Oct. 1989; available at http://www.rfc-editor.org/rfc/rfc1122.txt.
2. R. Droms, “Dynamic Host Configuration Protocol,” RFC 2131, Mar. 1997; available at http://www.rfc-editor.org/rfc/rfc2131.txt.
3. M. Hattig, “ZeroConf Requirements,” Internet draft, Zeroconf WG, Mar. 2001; work in progress.
4. S. Cheshire and B. Aboba, “Dynamic Configuration of IPv4 Link-local Addresses,” Internet draft, Zeroconf WG, Mar. 2001; work in progress.
5. S. Thomson and T. Narten, “IPv6 Stateless Address Autoconfiguration,” RFC 2462, Dec. 1998; available at http://www.rfc-editor.org/rfc/rfc2462.txt.
6. L. Ebisov et al., “Multicast DNS,” Internet draft, DNSEXT WG, Nov. 2000; work in progress.
7. M. Crawford, “IPv6 Node Information Query,” Internet draft, IPNGWG WG, Aug. 2000; work in progress.
8. E. Guttman et al., “Service Location Protocol, Version 2,” RFC 2608, June 1999; available at http://www.rfc-editor.org/rfc/rfc2608.txt.
9. E. Guttman, “Service Location Protocol Modifications for IPv6,” Internet draft, Svrloc WG, Feb. 2001; work in progress.
10. E. Guttman, “The Service Location Protocol,” IEEE Internet Computing, vol. 3, no. 4, July 2000, pp. 71-80.
11. A. Gulbrandsen et al., “A DNS RR for specifying the location of services (DNS SRV),” RFC 2782, Feb. 2000; available at http://www.rfc-editor.org/rfc/rfc2782.txt.
12. O. Catrina et al., “Zeroconf Multicast Address Configuration Protocol (ZMAAP),” Internet draft, Zeroconf WG, March 2001; work in progress.
13. E. Guttman, “Zero Configuration Networking,” Proc. INET 2000, Internet Society, Reston, VA; available at http://www.isoc.org/inet2000/cdproceedings/3c/3c_3.htm.

小貼士

IP主機層

分層結構是大型穩定可擴展計算平臺的基礎。圖A描述了隨處可見的一個分層架構，通常叫做IP協議棧，用於因特網主機。它粗略地對應OSI七層模型。圖中沒有OSI表示層和會話層。IP應用程序自身實現數據的表示功能。會話特性如協議傳輸間的加密、壓縮或持續性被以ad hoc方式加入多個層。

每個層都通過標準接口爲上層提供服務。如果下層使用同樣的接口提供同樣的功能，服務就能以不同的方式實現；因此，定義在網絡服務層的新機制可以不修改現存應用程序就支持他們。不用修改上層使得采用新因特網技術更加容易。需要更新客戶端應用程序的網絡服務層增強(如e-mail讀取器和Web瀏覽器)不被廣泛採用。

每個層都可以被自動地配置。實踐中，需要越少配置越好，因爲更簡單的技術其工作方式更可預期，並且易於部署。傳輸服務、鏈路控制和媒體訪問層極少需要對因特網主機進行配置。相對地，應用層和網絡服務層幾乎總是需要配置才能工作。

圖 A. 因特網主機分層。零配置協議將實現在因特網協議棧的應用層和網絡服務層

參考文獻

1. A.Tanenbaum, Computer Networks, Second Edition, Prentice-Hall, Englewood Cliffs, N. J., 1989.

早期的自動配置工作

因特網協議套件最初是作爲給研究人員使用和維護的一個網絡的數據通信標準而出現的。他們的設計目標主要是互用性、可擴展性和伸縮性。IP網絡通過(爲命名和尋址等)使用唯一參數和委派管理者的機制實現了增長和全球通信。

與此同時，網絡軟件(和設備)供應商正在開發專屬協議套件，這些套件強調易於使用和易於部署。蘋果的AppleTalk、Novell的IPX和微軟的NetBIOS/SMB的成功源於它們自動精靈地址配置的能力、去中心化的服務發現以及命名功能，這有助於本地通信以及資源，如文件和打印機，的共享。

零配置將橋連這兩個不同協議族的鴻溝。支持IP的主機和應用程序將能夠利用與AppleTalk提供的相似的機制。然而，完全地自動配置因特網是不可能的。零配置協議支持有限規模(功能性定義而不是決對定義)的網絡上的本地通信。當自動配置不夠用了，管理者必須計劃和部署可擴展的配置的網絡。

參考文獻

1. S. Gursharan et al., Inside AppleTalk,Addison-Wesley, Reading, Mass., 1990.
2. IPX RIP and SAP Router Specification, version 1.30, Part Number 107-000029-001, Novell Inc.,LOCATION?,May 1996.
3. SMB File Sharing Protocol Extensions 3.0, version 1.09, Microsoft Networks,Nov. 1989.