組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃(http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail：ouyang@china-pub.com
譯者：劉偉娜（superwinner   starfield@xanet.edu.cn）
譯文發布時間：2001－5－7
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。

向IPng 過渡和其他考慮的白皮書
(RFC 1671 IPng White Paper on Transition and Other Considerations)

備忘錄狀態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.
摘要
本文是響應RFC 1550 而向IETF IPng 領域提交的文件。本文的發布并不意味著I P n 
g 領域接受文中所表達的任何思想。評議請提交給b i g - i n t e r n e t @ m u n n a r i . o z . a 
u 郵件列表。
總結
本白皮書在所選領域勾畫了I P n g 某些通用需求。下面表示的是逐級過渡的需求：
(1) 在網絡的每級和每層實現互通。
(2) 包頭轉換被認為是有害的。
(3) 共存。
(4) IPv4 到I P n g 地址映射。
(5) 雙棧主機。
(6) 域名系統( D N S )。
(7) 智能雙棧代碼。
(8) 智能管理工具。
接受某些關于物理和邏輯組播的論點，并建議需要一個I P n g 在AT M 上運行的模型。
最后，本文建議的策略選路、計費和安全防火墻等需求，需要所有I P n g 包攜帶所涉及事
務處理類型的蹤跡，以及它們的源和目的地址。
過渡和發展
顯然過渡需要幾年的時間，同時網絡中的每個站點不得不決定它自己的階段過渡計劃。
只有那些最小的站點可能在I S P 的壓力下，考慮一步到位(“標志日”)的過渡。此外，一
旦決定采用I P n g ，那么I n t e r n e t 和所有用I n t e r n e t 協議集的專用網在下一十年(或
更長)的活動，將受到I P n g 發展的強大影響。用戶站點注視著決策，是否和他們過去所看
到的在改變程序設計語言或操作系統時所用的同樣方法來改變I P v 4 。向I P n g 轉變可能
不是必然的結果。他們主要擔心是，改變是否能使成本和影響生產的風險減到最低。
這樣的擔心立刻對I P n g 過渡和發展的模型產生了強大的約束。這些約束中的某些列
在下面，并對每種約束賦予簡短的解釋。
術語“I P v 4 主機”是一個和今天的主機運行同樣內容，而沒有維護版本及配置改變
的主機。“I P n g 主機”是一個運行I P 新版本，經過重新配置的主機。它類似于路由器。
1.	網絡的每級和每層實現互通
這是主要約束。計算機系統、路由器和應用軟件廠商肯定不會協調他們產品的發布日期。
用戶將繼續運行他們的老設備和軟件。因此，I P v 4 和I P n g 主機和路由器的任何組合必
須能互通(即加入到U D P 和T C P 會話中)。一個I P v 4 包必須能找到從任何I P v 4 主機
到其他任何I P v 4 或I P n g 主機的路徑，反之亦然，穿過I P v 4 和I P n g 路由器的混合
路徑，I P v 4 主機無需修改。I P v 4路由器無需修改可與I P n g 路由器互通。另外，一個
“明白”I P v 4 但還“不明白”I P n g 的應用軟件包必須能在運行I P v 4 的計算機系統上
運行，并和I P n g 主機通信。例如，歐洲的一個老P C機應該可訪問美國的N I C 服務器，
即使N I C 服務器運行的是I P n g ，且北美的選路機制只是部分地變換過。或者某個公司
某個部門的一個C 類網絡應該保持對運行I P n g 的公司服務器完全的訪問，盡管C 類網
絡內部什么也沒有改變。
(并不要求一個只能在I P v 4 上運行的應用程序到一個I P n g 主機上運行。因此，我們
承認某些主機一直要等到所有它們的應用程序是I P n g 兼容后才能升級。換句話說，我們
承認某種程度上A P I 要改變。然而，即使這樣的放松，還是有爭議的，甚至有些廠商要求
在I P n g 主機上嚴格保持IPv4 API 。)
2. 包頭轉換被認為是有害的
該作者相信在任何過渡情況下，要求I P v 4 和I P n g 間動態包頭轉換將會造成幾乎是
不可克服的實際困難：
(1) 可以認為I P n g 功能將是I P v 4 功能的一個超集。然而，協議間的成功轉換要求
被轉換的兩個協議的功能事實上應該相同。為此，應用需要知道它們什么時候通過
IPng API 和設在網絡中某處的轉換器與I P v 4 主機互通，以便只用I P v 4 功能。
這是不現實的約束。
(2) 轉換器的管理對大的站點而言是完全行不通的，除非轉換機制是完全隱蔽和自動
的。特別是任何轉換機制要求為每個主機中的表格(如D N S 表或路由器表)人工地
保持專門標志以指示需要轉換，這樣做是完全不可能進行管理的。在一個有幾千臺
運行多種操作系統的主機的站點上，主機在不同軟件版本上前進或后退，使得繼續
用這種方法來不斷跟蹤所需要的這些標志的狀態是不可能的。整個I n t e r n e t 的
多樣化，將會導致混亂、復合的失效模式和困難的診斷。特別是不可能遵守( 1 )的
約束。
實踐中為了避免混亂，對轉換所需要的知識、所涉及的站點將決不泄漏，并且如果
還沒有這樣的知識的話，當需要時，應用程序不能將其本身限制在I P v 4 功能上。
為了避免混淆，此處所討論的包頭轉換和地址轉換( N AT )不是同一件事。本文不
討論地址轉換。本文不詳細處理性能議題，但轉換的另一個明顯缺點是帶來必然的
開銷。
3. 共存
I n t e r n e t 基礎設施(不論是公用的還是專用的)必須允許I P v 4 和I P n g 在同一路由
器和同一物理路徑上共存。
為了在不要求主機步調一致地更新，及不使用轉換器的情況下，網絡基礎設施能更新至
I P n g ，共存是必須的。
值得注意的是，這種需求并不強制使用有關公共的或是分離的方法來進行選路。作為共
存機制，也不排斥使用封裝。
4. IPv4 到I P n g 地址映射
人們必須明白過渡期間會遇到什么問題。雖然I P n g 地址的自動配置可能是所期望的
目的，如果在給定的站點上，I P v 4 和I P n g 地址之間有一個可選的簡單映射，那么過渡
的管理就會大大簡化。
因此，I P n g 地址空間應包含I P v 4 地址的映射，這樣(如果一個站點或服務供應商愿
意做的話)一個系統的I P v 4 地址能機械地被轉換成I P n g 地址，大多數傾向于加一個前
綴。對每個站點而言，前綴不一定是相同的，可能至少是服務供應商指定的。
這并不意味著這種地址映射會用作動態轉換(雖然有可能是)，或將I P v 4 選路嵌入I P n 
g 選路內(雖然有可能是)。主要目的是簡化網絡運行者的過渡規劃。
順便指出，這樣的需求實際上沒有假設I P v 4 地址是全球唯一的。在建立I P v 4 和I P 
n g 選路域與分級之間的關系上也沒有太多幫助。沒有理由設想它們之間是1 ：1 對應關系。
5. 雙棧主機
無轉換的逐步過渡是很難想象的，除非大部分主機同時能運行I P n g 和I P v 4 。如果
A 想和B( I P n g 主機)以及和C ( I P v 4 主機)交談，于是A 或者B 必須能運行I P v 4 和
I P n g 兩者。換句話說，所有運行I P n g 主機必須仍能運行I P v 4 。只能運行I P n g 的
主機在過渡期間是不允許的。
這樣的需求并不意味著I P n g 主機真的有兩種完全分離的I P 實現(雙棧和雙A P I )，
但是表現出好像是分離的。封裝是兼容的(即兩個棧中的一個可為另一個封裝包)。
顯然，對雙棧主機的管理，由于上面提到的地址映射而簡化了。除了I P v 4 地址以外，
只有站點前綴必須配置(人工或動態地)。
在雙棧主機中，即使IPng API 和IPv4 API 是作為一個單個實體實現的，但在邏輯上是
可區別的。應用程序將從A P I 得知它們在用I P n g 還是I P v 4 。
6. DNS
雙棧要求隱含了D N S 必須給I P n g 主機回答I P v 4 和I P n g 兩者的地址，或將兩
者編碼在一起的單個回答。
如果在D N S 中，一個主機附屬于一個I P n g 地址，但該主機實際上還沒有運行I P n 
g ，尤如在I P n g 空間中出現一個黑洞—見下一點。
7. 智能雙棧代碼
雙棧代碼可從D N S 得到兩個地址，用哪一個呢？多年的過渡期間I n t e r n e t 將包含
黑洞。例如，從I P n g 主機A 到I P n g 主機B 路上某處有時(不可預測)會遇到只運行I P 
v 4 的路由器，它將丟棄I P n g 包。同樣，D N S 的狀態也不一定與現實是一致的。D N S 
聲稱知道I P n g 地址的主機可能在一特別的時刻并沒有運行I P n g ，因此到那個主機的I P 
n g 包在傳遞時將被丟棄。知道一個主機具有I P v 4 和I P n g 兩種地址并沒有給出有關黑
洞的信息。對此必須有一種解決方案，這方案不能依賴于人工保持的信息。(如果這個不解
決，雙棧方法是不會好于轉換方法的。)
8. 智能管理工具
過渡期間需要一整套管理工具。為什么I P n g 路由不同于I P v 4 路由？如果要轉換的
話，該發生在何處？何處有黑洞？(宇宙學家喜歡同樣的工具。)今天的主機是否真正有I P n 
g 能力？
組播
眾所周知，I P n g 必須支持組播應用，體系結構上一個明顯的規則是：不論是L A N 還
是WA N 線路，組播包不應在同一線路上經過兩次。如果做不到這點，則意味著同時組播
的事務處理最大數量會減半。
L A N 上的I P v 4 的一個負面特征是：輕率地使用物理廣播包，諸如A R P (各種非I E 
T F 盲目模仿者)協議。在大的L A N 上，這將導致一系列不希望有的后果(經常是由于差的
產品或差的用戶，而不是協議設計本身造成的。)如有可能的話，體系結構上明顯的規則是
改用單播(或最壞情況，用組播)來代替物理廣播。
ATM
網絡工業界正在AT M 上大量投資。沒有I P n g 提案似乎是可取的(從獲得管理部門批
準的意義上)，除非它是“AT M 兼容”的，也就是要有一個如何運行在AT M 網絡上清晰
的模型。雖然不馬上需要一個像RFC 1577 那樣十分詳細的文件，但必須顯示該基本模型是
能工作的。
類似的論點同樣可用于X . 2 5 、幀中繼、S M D S 等，但AT M 是當前呼聲最高的。
策略選路與計費
遺憾的是，這不能被忽略，許多人對此感興趣。基金代理希望業務流流經提供基金的線
路，且在以后他們要知道有多少業務流。計費信息也可用作網絡規劃和反向付費的根據。
所以I P n g 及它的選路過程允許根據詳細的源和目的地址來指定業務流的途徑。(作為
一個例子，從M I T 物理系輸出的業務流和任何其他系輸出的業務流可能通過不同的路由到
C E R N 。)
滿足該需求的一個簡單途徑是堅持I P n g 必須支持基于供應商的尋址和選路方案。
業務流的計費要求同樣的詳細程度(甚至更詳細，例如f t p 的業務流是多少，w w w 的
業務流又是多少)。
兩者都需要花費時間和金錢，并且不僅影響I P 層，所以I P n g 不該回避它們。
安全性考慮
公司網絡運行者和校園網絡運行者曾受到過好幾次安全問題的困擾，他們對待此事比許
多協議專家更認真。實際上，許多公司網絡運行者希望在向I P n g 過渡中，作為一個比其
他任何議題更為緊迫的議題，安全性能得以改善。
因為I P n g 估計是一個數據報協議，限制了它為端到端的安全性所能做的工作，I P n g 
必須允許路由器中有比I P v 4 更有效的防火墻。特別需要基于源和目的地址以及事務處理
類型的高效的業務流阻擋。
看來需要同樣的特征允許策略選路和詳細計費來改善防火墻的安全性。討論這些特征的
細節超出了本文范圍，但是看來不大可能在邊界路由器中限制實現細節。為了檢查有害的業
務流，允許基于策略的源選路和/或允許詳細計費，包必須攜帶某些三重驗證的蹤跡(源、目
的地、事務處理)。可能所有I P n g 可以在每個包中以某種格式攜帶源和目的地的標識符，
但是標識事務處理的類型或甚至于個別的事務處理，是一個額外需求。
聲明和致謝
以下是個人觀點，未必代表我老板的觀點。
近幾年來，CERN已經通過三個網絡的過渡(由John Gamble 解決的I P v 4 重編號，由Mike 
Gerard解決的Apple Talk從階段I 向階段I I 的過渡，以及由Denise Heagerty 解決的DECnet 
階段I V向DECnet /OSI 選路的過渡)。如果沒有從他們那兒獲取知識，我是不能寫出這個文
件的。我也從許多人，特別是從I P n g 董事會的各個成員的討論或作品中，獲益非淺。多
位董事會成員及波音公司的Bruce L Hutfless 提出了意義幫助闡明本文。不過意見是我本
人的，并非董事會全體成員的共同意見。
RFC 1671 IPng White Paper on Transition and Other Considerations 
向IPng 過渡和其他考慮的白皮書
1

1
RFC文檔中文翻譯計劃