RFC1918 私有網絡地址分配
組織：中國互動出版網（http://www.china-pub.com/）RFC 文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook
組織：中國互動出版網（http://www.china-pub.com/）
RFC 文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail ：ouyang@china-pub.com
譯者：李蘇萍（szlisp szlisp@sina.com）
譯文發(fā)布時間：2001-4-9
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業(yè)用途自由轉載，但必須保留本文檔的翻譯及版權信息。
Network Working Group Y. Rekhter Request for Comments: 1918 Cisco Systems Obsoletes: 1627, 1597 B. Moskowitz BCP: 5 Chrysler Corp. Category: Best Current Practice D. Karrenberg RIPE NCC G. J. de Groot RIPE NCC E. Lear Silicon Graphics, Inc. February 1996 RFC1918 私有網絡地址分配
(RFC1918 Address Allocation for Private Internets)
本備忘錄狀態(tài)
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
目錄
1. 介紹 2
2. 動力，目的 2
3. 私有地址空間 3
4. 使用私有地址空間的利弊 4
5. 操作考慮 4
6. 安全考慮 5
7．總結 5
8．感謝 5
參考 6
作者地址： 6
1. 介紹
在本文檔中，企業(yè)表示一個自治地操作一個使用TCP/IP協(xié)議網絡的實體，特別地，該實體要決定該網絡的尋址方案和地址分配。
,該文檔描述了私有網絡的地址分配。該分配允許一個企業(yè)內的所有主機之間以及不同企業(yè)內的所有公開主機之間在網絡所有層次上的連接。
2. 動力，目的
隨著TCP/IP技術在包括Internet 網本身以外的世界范圍內的擴散，越來越多沒有連接到Internet 網絡上的企業(yè)使用該技術。這些企業(yè)只是使用該技術的尋址能力用于企業(yè)內部通信，而沒有打算與其他企業(yè)或是Internet 網絡直接相連。
Internet 網絡的發(fā)展出乎任何人的預料。持續(xù)的指數級增長不斷引起新的挑戰(zhàn)。其中一個挑戰(zhàn)是來自Internet 社區(qū)內部的關注：全球唯一的地址空間將被耗盡。一個與此不同，且更為迫切的關注是： 路由負荷的數量將超過ISP （Internet Service Provider ）的能力。社區(qū)內正在努力試圖找到一個關于這些問題的長期解決方案。同時，有必要再次探討地址分配過程極其對Internet 路由系統(tǒng)造成的影響。
為容納路由負荷的增長，一個Internet 服務提供商從地址注冊組織獲得一個地址塊，然后根據每個客戶的要求將塊內的地址分配給客戶。這個過程造成的結果是：到許多客戶的路由將會被聚合起來, 對其他服務提供商呈現(xiàn)為一個單一的路由。為了讓路由聚合有效，Internet 服務提供商鼓勵加入其網絡的客戶使用提供商的地址塊，然后重新為其計算機設定地址。這樣的鼓勵也許在將來會成為一種要求。
考慮當前Internet 的大小以及它的增長速度，通過從地址注冊組織獲得全球唯一的IP 地址，某個組織一旦連接到Internet 網絡上，該組織就具有Internet 范圍內的 IP 連接，這樣的假設不再現(xiàn)實。相反，很可能是這樣：當一個組織想要連接到Internet 上以獲得Internet 范圍內的IP 連接，該組織需要對它所有的公開主機（需要Internet 范圍IP 連接的主機）進行地址轉換（renumber ）, 而不管該組織原先使用的地址是否是全局唯一的。
典型地，一般所有使用TCP/IP協(xié)議的所有主機都被分配一個全局唯一地址。為了延長IPv4地址空間的生命周期，地址注冊請求審查將比任何以往時候都更為嚴格，使得申請更多地址空間難度增大。
在企業(yè)內部使用IP 的主機可以分為三類：
第一類：企業(yè)內的主機不需要訪問其他企業(yè)內的主機或Internet; 這類主機可以使用企業(yè)內沒有多義的但在企業(yè)之間可能會有多義的IP 地址。
第二類：主機需要訪問外部有限的服務（例如 E-mail, FTP,網絡新聞，遠程登陸等），這些服務可由中介網關來處理（例如應用層網關）。對于這類中的許多主機而言，不受限制的外部訪問（通過IP 連接）也許是不必要的，從安全角度考慮，也是不合適的。正如第一類主機那樣，該類主機可使用在企業(yè)內部無多義而在企業(yè)之間可能有多義的IP 地址。
第三類： 主機需要企業(yè)外部網絡層的訪問（假設在通過IP 連接的方式下）；這最后一類主機需要全局無多義的IP 地址。
我們將第一、第二類中的主機稱作“私有的”，將第三類主機稱作“公開的”。
對于大多數內部主機，許多應用只要求企業(yè)內部的連接，而不需要與企業(yè)外的連接。在比較大的企業(yè)，很容易識別出一大堆使用TCP/IP協(xié)議但是不需要與外部企業(yè)建立網絡層連接的主機。 下面是一些例子，這些例子中外部連接可能不需要。
------一個大型機場，通過TCP/IP網絡來顯示不同航班的到達和離開。很顯然，這些顯示不必被其他網絡直接訪問到。
------大型機構，如銀行，連鎖店正轉向使用TCP/IP 來構建其內部通信。大量的本地工作站，如 收銀機, 取錢機和在辦公室的設備很少需要與外部的連接。
------處于安全考慮，許多企業(yè)使用應用層網關來將內部網絡與外部網絡連通。內部網絡通常不能直接訪問Internet ，這樣僅有一個或更多個網關在Internet 上是可見的。在這種情況下，內部網絡可以使用非唯一的IP 地址。
,------內部網絡的路由器接口通常不必被外部企業(yè)直接訪問。
3. 私有地址空間
因特網域名分配組織IANA 組織（Internet Assigned Numbers Authority）保留了以下三個IP 地址塊用于私有網絡。
10.0.0.0 - 10.255.255.255 (10/8比特前綴)
172.16.0.0 - 172.31.255.255 (172.16/12比特前綴)
192.168.0.0 - 192.168.255.255 (192.168/16比特前綴)
我們把第一塊稱為“24-比特塊”，第二塊稱為“20-比特塊”，第三塊稱為“16-比特塊”注意（在前面的CIDR 記號中），第一塊地址就是一個A 類網絡號，第二塊地址是16個連續(xù)的B 類網絡號集合，第三塊地址是256個連續(xù)的C 類網絡號集合。
一個決定使用該文檔中定義的IP 地址空間的企業(yè)不需要與IANA 組織或Internet 地址注冊組織進行協(xié)商。這樣，該地址空間可以被許多企業(yè)使用。私有地址空間中的地址僅在一個企業(yè)內部或在一組選擇在該空間協(xié)同通信的企業(yè)內部保證唯一，這樣他們可以在自己擁有的私有網絡內部實現(xiàn)通信。
以前，任意一個需要使用全局唯一地址的企業(yè)必須向Internet 注冊機構提出申請。上述定義的私有地址空間中的地址塊將不會被Internet 注冊機構分配給一個申請用于外部連接的IP 地址的企業(yè)。
要使用私有地址，企業(yè)要決定在可預見的時期內哪些主機不需要與外部建立網絡層連接，從而將這些主機歸類為“私有的”。這類主機將使用上述定義的私有地址。私有主機能與企業(yè)內的所有其他主機通信，包括“公開的”和“私有的”的主機。但它們和企業(yè)外部的任何主機都沒有IP 連接。盡管如此，它們仍然能通過中介網關（如應用層網關）訪問外部服務。
其他的主機將被歸類為“公開的”，這些公開主機必須使用由Internet 注冊機構分配的全局唯一的地址空間。公開主機可以與企業(yè)內部的其他公開主機和私有主機通信，它們可以具有與企業(yè)外部公開主機之間的IP 連接。公開主機與其他企業(yè)內部的私有主機之間沒有連接。 將私有主機轉為公開主機或是相反的操作涉及到IP 地址的轉換，DNS 中相關記錄的改變和在其他主機上用IP 地址來標志該主機的配置文件的改變。
因為私有地址沒有全局意義，因此在企業(yè)之間的鏈路上沒有必要傳播私有網絡的路由信息。源或目的地址為私有地址的包也不應該在這樣的鏈路上被轉發(fā)。網絡中不使用私有地址的路由器，尤其是那些屬于ISP 的路由器，期望被設置為拒絕（過濾）關于私有地址的路由信息。如果一個路由器接收到這樣的信息，拒絕操作不應該被視為路由協(xié)議錯誤。
對于這樣的地址的非直接參考應該被包含在企業(yè)內部。關于這樣的參考，一個突出的例子是DNS 中的 Resource 記錄（Resource records ） 和其他有關內部私有地址的信息。特別的（In particular ）,ISP 應該采取措施防止這樣的泄露。
4. 使用私有地址空間的利弊
普遍地，對于Internet 來說，使用私有地址空間一個明顯的好處就是在不必要使用全局地址的地方使用私有地址，從而保存了全局唯一地址空間。
企業(yè)同樣從使用私有地址空間中獲益不菲： 具有比使用全局唯一地址池時有更多的地址空間支配權使得他們在進行網絡設計時有很大的靈活性。這使得操作和管理地址分配方案及擴展路徑更為容易和便利。
由于各方面的原因，Internet 上已經遇到這樣的情形：沒有連接到Internet 上的某個企業(yè)使用了不是IANA 分配的地址空間。在某些情況下，這個地址空間已經被分配給了其他企業(yè)。如果這樣一個企業(yè)以后要連接到Inernet 上，這將產生很多嚴重的問題，因為IP 路由在地址具有多義性的時候不能進行正常的操作。盡管在理論上，ISP 應該通過路由過濾防備此類錯誤，
,但實際上往往不會這樣做。使用私有地址空間為這樣的企業(yè)提供了一種安全的選擇，能夠在企業(yè)需要連接到Internet 的時候避免產生沖突。
使用私有地址空間的一個主要缺陷是，它也許實際上減少了企業(yè)訪問Internet 的靈活性。一旦一個企業(yè)決定使用私有地址，為了能讓部分主機具有與Internet 之間IP 連接的能力，他也要承擔部分主機地址轉換的任務。通常地址轉換的代價可以用需要從私有地址轉換為公開地址的主機數目來衡量。正如我們上面討論的那樣，即使一個網絡使用的是全局唯一地址，為了獲得Internet 范圍的IP 地址的連接能力，它也可能仍然需要進行地址轉換。
使用私有地址空間的另一個缺陷是：將幾個私有網絡合并成一個私有網絡時，它也可能需要進行地址轉換。回顧第二部分列出的例子，我們注意到公司有合并的趨勢。如果這些企業(yè)在合并前各自使用私有地址構造自己的私有網絡，當這些私有網絡合并成一個私有網絡時，合并后的私有網絡地址不一定唯一。結果是，具有不唯一地址的主機需要重新分配地址。
地址轉換的代價可以通過開發(fā)和便于轉換的開發(fā)工具來減輕（例如 DHCP）. 當決定是否要采用私有地址時，我們建議咨詢計算機和軟件廠商是否能獲得這類相應的工具。 一個單獨的IETF 組織正在致力于完成描述地址轉換過程和要求的所有文檔。
5. 操作考慮
一種可能的策略是先設計網絡中的私有部分，給所有內部鏈接分配私有地址空間。然后在需要的位置安排公開子網，設計外部連接。
這種設計不必是永久固定的。如果以后一組主機（一臺或多臺）要求改變它們的地位（從私有到公開，或是相反），通過轉換涉及到的主機的地址，在必要的時候改變其物理連接即可完成。如果需要，在某些事先可以預見的位置，建議為公開子網和私有子網配置不同的物理介質，從而方便這樣的改變。為了避免主要的網絡破壞，建議將主機按照相似的物理連接要求分組，放置在不同的子網內。
如果能設計一個合適的子網方案，并且該方案能夠得到相關設備的支持，建議使用24-比特塊私有地址空間（A 類網絡），采用便于擴展的制作尋址方案。如果使用子網是個問題，那么可以采用16-比特（C 類網絡）或20-比特（B 類網絡）地址塊。
有人可能被慫恿為同一物理介質同時分配公開的和私有的地址。如果這是可能的話，這種設計存在著不可知的危險。（注意，這種危險和使用私有地址空間無關，而是由于在一個普通數字鏈路子網上多個IP 子網的存在引起的）。我們建議在處理該領域時要特別注意。
強烈建議連接企業(yè)到外部網絡的路由器在鏈路的兩端安裝合適的包和路由過濾，以便防止包和路由信息的泄露。一個企業(yè)應該從入站的路由信息中過濾掉任何私有網絡，從而保護它自己不陷入路由歧義的境遇，這種境遇在如果到私有網絡地址空間的路由指向了企業(yè)外部時會發(fā)生。 有這樣的可能，兩個站點，協(xié)作使用私有地址空間，通過一個公開網絡彼此通信。為了這樣做，他們必須使用一些方法，在公開網絡邊界上進行封裝，從而保持他們的私有地址的私有性。 如果兩個（或更多個）組織遵循本文規(guī)定的地址分配方案，以后希望建立彼此之間的IP 連接時，這時就會有地址唯一性被打破的危險。為減小這樣的冒險，強烈建議使用私有IP 地址的組織在為其內部分配子塊時，隨機地從保留的私有地址池中選取IP 地址。
如果一個企業(yè)使用私有地址空間，或混合使用私有地址和公開地址空間，企業(yè)外部的DNS 客戶端不應該看到企業(yè)使用的私有地址，因為這些地址將會是多義的。一個確保此實現(xiàn)的方法是為每個既包含使用公開地址的主機，又包含使用私有地址的主機的DNS 域運行兩個權威服務器。一個服務器對公開地址空間可見，它僅包含企業(yè)地址中公開地址能訪問到的子網。另一個服務器僅能被私有網絡訪問，它包含所有的數據集合，包括私有地址和能訪問私有網絡的公開地址。為了保證一致性，每個服務器應該用相同的數據來配置，配置中，公開可見域僅包含一個過濾后的版本。提供這些功能在一定程度上有附加的復雜性
6. 安全考慮
,安全主題在本備忘錄中不討論。
7．總結
使用上述方案，許多大型企業(yè)只需要全局IP 地址空間中相對較少的地址塊。Internet 從保存全局唯一地址空間獲得好處，這將有效地延長IP 地址空間的生命周期。通過提供一個相對較大的私有地址空間，企業(yè)從增加的靈活性中得到好處。但是，企業(yè)網絡連接性隨時間發(fā)生變化時，使用私有地址要求一個組織為企業(yè)網絡中的部分或所有主機轉換地址。
8．感謝
感謝以下各位審議此文并給出建設性意見。
Tony Bates (MCI), Jordan Becker (ANS), Hans- Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks), Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence), Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet Software Consortium) 。
參考
[RFC1466] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, Merit Network, Inc., May 1993.
[RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
作者地址：
Yakov Rekhter
Cisco systems
170 West Tasman Drive
San Jose, CA, USA
Phone: 1 914 528 0090
Fax: 1 408 526-4952
EMail: yakov@cisco.com
Robert G Moskowitz
Chrysler Corporation
CIMS: 424-73-00
25999 Lawrence Ave
Center Line, MI 48015
Phone: 1 810 758 8212
Fax: 1 810 758 8173
,EMail: rgm3@is.chrysler.com
Daniel Karrenberg
RIPE Network Coordination Centre Kruislaan 409
1098 SJ Amsterdam, the Netherlands Phone: 31 20 592 5065
Fax: 31 20 592 5090
EMail: Daniel.Karrenberg@ripe.net
Geert Jan de Groot
RIPE Network Coordination Centre Kruislaan 409
1098 SJ Amsterdam, the Netherlands Phone: 31 20 592 5065
Fax: 31 20 592 5090
EMail: GeertJan.deGroot@ripe.net
Eliot Lear
Mail Stop 15-730
Silicon Graphics, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA 94043-1389
Phone: 1 415 960 1980
Fax: 1 415 961 9584
EMail: lear@sgi.com
Steve Gonczi
Network Engines, Inc.
25 Dan Road Canton, MA 02021-2817 Phone: 781-332-1165
EMail: steve.gonczi@networkengines.com
Ted Lemon
950 Charter Street
Redwood City, CA 94043
EMail: ted.lemon@nominum.com
Rob Stevens
Join Systems, Inc.
1032 Elwell Ct Ste 243 Palo Alto CA 94203
,Phone: (650)-968-4470
EMail: robs@join.com
RFC1918 Address Allocation for Private Internets RFC1918 私有網絡地址分配
1
RFC 文檔中文翻譯計劃