本備忘錄狀態
本文具體說明了因特網間交流的因特網標準的路徑協議，和改進的要求討論和建議。請
參考當前版本的“官方網絡協議標準（InternetOfficialPRotocolStandards）”一書，
此書標準化了這一協議的規定和地位。此備忘錄的貢獻是有限的。

版權申明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

摘要

Thisdocumentspecifiesipv4compatibilitymechanismsthatcanbe
implementedbyIPv6hostsandrouters.Thesemechanismsinclude
providingcompleteimplementationsofbothversionsoftheInternet
Protocol(IPv4andIPv6),andtunnelingIPv6packetsoverIPv4
routinginfrastrUCtures.TheyaredesignedtoallowIPv6nodesto
maintaincompletecompatibilitywithIPv4,whichshouldgreatly
simplifythedeploymentofIPv6intheInternet,andfacilitatethe
eventualtransitionoftheentireInternettoIPv6.Thisdocument
obsoletesRFC1933.


目錄
1.簡介 3
1.1.術語 3
1.2.本文的結構 4
2.雙重IP層的治理 5
2.1.地址配置 5
2.2.DNS 5
2.3.在DNS里廣告地址 6
3.一般的通道機制 6
3.1.封裝 7
3.2.MTU傳輸和分片 8
3.3.跳線限制 9
3.4.處理IPv4ICMP錯誤 9
3.5.IPv4報頭組成 10
3.6.解壓縮 10
3.7.連接本地 11
3.8.在通道上的鄰居發現 12
4.配置的通道 12
4.1.缺省配置的通道 12
4.2.使用IPv4"任意點傳送地址"的缺省配置的通道 12
4.3.入口過濾 13
5.自動傳輸 13
5.1.IPv4兼容地址格式 13
5.2.IPv4兼容地址的配置 13
5.3.自動傳輸治理 14
5.4.使用缺省配置的通道 14
5.5.源地址選擇 14
5.6.入口過濾 15
6.謝意表達 15
7.安全方面的考慮 15
9.參考書 16
10.從1933年起的RFC變化 17
11.版權申明 19
Acknowledgement 19


1.簡介
IPv6轉換成功的要害是與大型IPv4主機和路由器的基本安裝的兼容性。當配置IPv6保
持與IPv4的兼容性將使IPv6網間的轉換任務富有流線型。這種規范定義了IPv6的主機和
路由器實現和IPv4的主機和路由器的兼容的機制設置。
在本文中的機制設計被IPv6的主機和路由器所使用需要用IPv4的主機的面對面操作和
利用IPv4的路由器的下部構造組織。我們期望在網間的大多數節點將長時間可能甚至是無
限期的需要這種兼容。
然而，IPv6可以在某些環境下使用而不需要跟IPv4協同工作。IPv6節點的設計成可以
被在不需要IPv4甚至是它的組件的環境下被使用。

以下包括轉換機制的具體說明：
—雙重IP層：一種完全為兩個網絡協議提供支持的技術——IPv4和IPv6——在主機和
路由器中。
—配置基于IPv4的IPv6的通道：點對點通道由在IPv4數據包頭里壓縮IPv6的包來通
過IPv4路由的下部組織運輸組成。
—IPv6地址與IPv4的兼容性：一個IPv6的地址格式的使用包含了IPv4的地址。
—基于IPv4的IPv6的自動的通道：一個轉換機制用IPv4的兼容地址在IPv4的網絡上
自動的傳輸IPv6的信息包。

轉換機在本文中被定義為一個“轉換工具箱”的一部分——技術的逐漸積累使得執行者
和使用者輕松地使用轉換。工具在需要的時候被用。工具和場所決定了什么技術適合他們的
非凡需要。本文定義了轉換機制的最初核心裝置，但是這些并非期望僅僅是可用的工具。附
加的轉換和兼容機期望在將來能被開發出來，到時會寫一篇文章重新定義他們。

1.1.術語
下面的術語將在本文中被使用：
節點類型
IPv4的專有節點：
一臺主機或是路由器僅僅實現IPv4。IPv4的專有節點并不能理解IPv6。在轉換開始前
安裝基本的現有IPv4主機和路由器是IPv4的專有節點。
IPv6/IPv4節點：
主機和路由器實現IPv4和IPv6。
IPv6的專有節點：
一臺主機或路由器僅僅實現IPv6，并不實現IPv4。IPv6專有節點在此的運行并不標明
地址。
IPv6的節點：
任意的主機和路由器實現IPv6。IPv6/IPv4和IPv6的專有節點都是IPv6的節點。
IPv4的節點：
任意的主機和路由器實現IPv4。IPv6/IPv4和IPv6的專有節點都是IPv4的節點。

IPv6的地址類型
與IPv4兼容的IPv6地址：
一個IPv6地址的高序96位的前綴是0:0:0:0:0:0，一個IPv4地址在低序32位。
IPv4的兼容地址被執行自動通道的IPv6/IPv4節點所使用。
IPv6的自帶地址：
剩余的IPv6的地址空間。一個IPv6的地址具有一個不是0:0:0:0:0:0的前綴。

轉換中使用的技術
基于IPv4的IPv6的通道：
由于有在IPv4包里壓縮IP6的技術以至于他們可以通過IPv4路由部件來傳送信息包。
配置通道：
在IPv4通道的終端地址那兒的基于IPv4的IPv6通道由在壓縮節點上的配置信息決定。
通道既可以是單向性的也可以是雙向性的。雙向性配置的通道是作為虛擬的點對點連接來運
轉。
自動化的通道：
在IPv4通道的終端地址那兒的基于IPv4的IPv6通道是由來自包含在被傳輸的IPv6包
的IPv4兼容的終端地址決定。
IPv4多點傳送通道：
在IPv4通道的終端地址那兒的基于IPv4的IPv6通道是利用網絡鄰居來決定的。不像
配置的通道不需要任何的地址配置，也不像自動的通道不需要使用IPv4兼容的地址。然而，
機制采用IPv4的下部組織機構來支持IPv4的多點傳送。在[3]中已經具體說明這里就不進一
步討論了。
其它的轉換機制包括其它的通道機制不在本文的討論之列，在此就不具體說明了。

IPv6/IPv4的節點治理方式
IPv6專有的治理：
一個IPv6/IPv4的節點有它的IPv6的可用堆棧和IPv4的禁用堆棧。
IPv4專有的治理：
一個IPv6/IPv4的節點有它的IPv4的可用堆棧和IPv6的禁用堆棧。
IPv4/IPv6治理：
一個兩者都有可用堆棧的IPv6/IPv4的節點。
出現在本文中的要害字：MUST,MUSTNOT,REQUIRED,SHALL,SHALL
NOT,SHOULD,SHOUKDNOT,RECOMMENDED,MAY,OPTIONAL在[16]中已經說明了。

1.2.本文的結構
本文下面的部分是按以下形式組織的：
——第二部分討論IPv6/IPv4節點的雙重IP層的節點治理。
——第三部分討論在基于IPv4的IPv6通道技術的一般機制的使用。
——第四部分討論配置的通道。
——第五部分討論自動通道和跟IPv4兼容的IPv6的地址格式。

2.雙重IP層的治理
對IPv6節點的最直接方式是通過提供一個完全的IPv4工具保持與專有的IPv4的兼容。
提供一個完全的IPv4和IPv6工具的IPv6節點叫做IPv6/IPv4節點。IPv6/IPv4節點有發送和
接收IPv4和IPv6的包的能力。他們能直接的利用IPv4包的IPv4節點來操作，也可以直接
的利用IPv6的包的IPv6節點來操作。
即使一個節點可能被預備用于支持兩者的協議，但其中一個的堆棧可能由于治理的原因
而無效。因此IPv6/IPv4的節點可能在下面三種模式中的一種中操作：
——他們的IPv4堆棧可用而IPv6堆棧禁用。
——他們的IPv6堆棧可用而IPv4堆棧禁用。
——兩者堆棧都可用。
IPv6堆棧禁用的IPv6/IPv4節點就像IPv4專有節點地操作一樣。類似的，IPv4堆棧禁用的
IPv6/IPv4節點就像IPv6專有節點地操作一樣。IPv6/IPv4節點的MAY操作提供了IPv4或
IPv6堆棧從可用轉換成禁用的功能。
雙重IP層技術可用在與在第3、4、5部分中說明的基于IPv4的IPv6通道技術的連接
也可不用。支持通道的一個IPv6/IPv4節點的MAY操作可以僅僅支持配置通道，或是支持
配置的和自動的通道。因此以下是三種可能的通道支持方式：
——IPv6/IPv4節點不執行通道。
——IPv6/IPv4節點僅僅執行配置通道。
——IPv6/IPv4節點執行配置通道和自動通道。

2.1.地址配置
因為IPv6/IPv4支持兩者協議，所以他們的節點應該用IPv4和IPv6的地址來配置。
IPv6/IPv4的節點用IPv4的機制來滿足他們IPv4的地址，而IPv6的協議機制來滿足他們IPv6
自帶地址。在5.2部分描述了一個使用IPv4協議機制來滿足他們的IPv6與IPv4兼容的地址
的機制，此機制IPv6/IPv4節點支持自動通道的MAY要害字。
2.2.DNS
DNS是一種主機名和IP地址之間相互轉換的機制。一個名為"A6"的新的資源記錄類型
已經為用來支持一個名為"AAAA"的更早記錄的IPv6地址所定義。由于IPv6/IPv4節點必須
能夠用IPv6和IPv4的節點直接操作，所以他們必須提供和用IPv6"A6"和"AAAA"記錄一樣
的IPv4"A"記錄的庫處理能力的解決辦法。
DNS在IPv6/IPv4節點上庫解決方法上的MUST要害字能夠處理A6/AAAA和A記錄。
然而，當一個查詢定位支持IPv6地址的一個A6/AAAA記錄和一個支持IPv4地址的紀錄時，
庫解決方法中的MAY要害字為了改變用來和那個節點連接的IP包副本過濾或按序結果返
回請求。在過濾術語中，庫解決方法有三種可供選擇：
——僅僅返回IPv6地址到請求。
——僅僅返回IPv4地址到請求。
——把兩者都返回。
假如它僅返回IPv6地址，請求將用IPv6和節點連接。假如僅返回IPv4地址，請求將用IPv4
和節點連接。假如兩者都返回，請求將選擇用哪個地址，因此也就要選擇用哪個IP協議。
假如他兩者都返回，解決方法選擇MAY要害字來安排地址——是IPv6優先，或是IPv4
優先。由于大多數的請求盡量使他們被解決者能按照順序返回，這就能影響IP副本請求的
優先選擇。
過濾結果或DNS結果按序是明確執行的。IPv6/IPv4節點的MAY要害字提供了配置方
針用來控制被解決者過濾或是按序返回的地址，或是都留給請求來解決。一個MUST的執
行答應請求來控制是否發生過濾。

2.3.在DNS里廣告地址
在傳輸時使用DNS會發生一些限制。大多數是明顯的但為了完全在此被規定。
值得注重的是對一個節點的A6/AAAA記錄不應該被加到DNS除非以下的條件都滿足：
1）地址在節點上被賦給了接口。
2）地址在接口上被配置。
3）連向IPv6基礎部件的接口在一個連接上。
假如一個IPv6的節點被從IPv6的視圖中隔開約束#3將意味著在DNS里不應該有一個地址。
這種操作主要是在當其它的雙重堆棧節點試圖去連接被隔開的雙重堆棧節點。在DNS
里沒有IPv6地址因此前面的情況就不會試圖用IPv6連接而是直接轉向了IPv4。


然而，這并不能很好的運行當被隔離的節點試圖去確立連接時。即使在NDS里沒有IPv6
的地址但它為前面的記錄找到A6/AAAA記錄。由于被隔離的節點有IPv6地址至少被賦給
一個接口它將會試著用IPv6去連接。假如它沒有到6bone的路徑那這樣的連接將會失敗。
很典型的，這就意味著當TCP超時時會耽擱一些時間。TCP規范里說明了ICMP不能到達
的信息可能是由于路由的暫時性因此他們不應該立即終止TCP的連接。這就意味著一般TCP
超時的應用。一旦TCP超時應用將有希望試圖使在DNS里的IPv4地址基于一個記錄，但
是這將是非常慢的。
上面的建議中暗含了一種可能性，假如一個是IPv6在一個沒有IPv6基礎部件的連接的
節點上，并且選擇了為那個節點加A6/AAAA記錄到DNS，那外部的IPv6節點可能看到這
些A6/AAAA記錄并且將可能使用IPv6試圖到達那個節點，這就因為不可到達性將遭受耽
擱或連接失敗。因此建議不但按照建議而且要謹慎的用將不會受外部通道耽擱或連接失敗的
影響去做。
在將來當一個站點或節點去掉IPv4的支持時上面的建議應用到當一個節點從DNS刪
除。

3.一般的通道機制
在大多數配置的關中，隨著時間的推移IPv6路由下部基礎組織將被建立。當IPv6下部
基礎組織被配置，現有的IPv4下部基礎組織能保持運行，并且可用作執行IPv6的傳輸。通
道提供了一種利用現有的IPv4路由下部基礎組織來執行IPv6的傳輸的方法。
IPv6/IPv4主機和路由器能通過在IPv4包里壓縮IPv6數據包在IPv4路由的拓撲區域上
傳輸IPv6數據包。傳輸能被用在各種各樣的方式中：

——路由器到路由器。IPv6/IPv4路由器通過IPv4的下部基礎組織連接能夠在兩者之間傳輸
IPv6的數據包。在這種情況下，通道橫跨IPv6包走的端到端路徑的一部分。

——主機到路由器。IPv6/IPv4主機能傳輸IPv6包到一個中介的IPv6/IPv4路由器，者通過
一個IPv4的下部基礎組織是可是實現的。這種類型的傳輸跨越包的端到端傳輸路徑的第一
部分。

——主機到主機。IPv6/IPv4主機通過一個IPv4的下部基礎組織相互連接能在他們間傳輸
IPv6的數據包。在這種情況下，傳輸跨越了數據包走的端到端路徑的全部。

——路由器到主機。IPv6/IPv4路由器能傳輸IPv6包到他們的IPv6/IPv4主機的目的地。這
種傳輸僅僅跨越了端到端路徑的最后部分。
通道技術通常根據由壓縮節點決定在通道末端的節點地址的機制分類。在上面列舉的路
由器到路由器和主機到路由器兩種通道技術中IPv6數據包被傳輸到一個路由器。這種類型
通道的終點是一個中介路由器，這個路由器負責解壓縮IPv6包和傳輸它到它的最后目的地。
當傳輸到一個路由器，通道終端和被傳輸包的終點是不同的。因此在被傳輸的IPv6包的地
址不能提供傳輸端點的IPv4地址。反而，通道的端點地址必須由在執行傳輸的節點上的配
置信息來決定。我們使用"配置通道"這一術語來描述端點被明確配置的通道類型。
在后面的主機對主機和路由器對主機兩種傳輸方法中IPv6包被直接傳輸到最后的終
點。在這種情況下，IPv6包和壓縮的IPv4包頭的終端地址確定同樣的節點！這種事實能被
在IPv6最后地址的編碼信息被開發答應壓縮節點來自動決定傳輸終點的IPv4地址。自動通
道使用這種技術，利用一個有IPv4地址嵌入的非凡的IPv6地址格式來答應傳輸節點自動的
得到IPv4的端點地址。這就排除了對配置通道端點地址的明確需要，大大簡化了配置。
自動的和配置的兩種通道技術在他們怎樣決定同到端點地址上是根本不同的。大多數基
本的機制是一樣的：
——通道的入口節點創建一個壓縮的IPv4包頭和傳輸壓縮包。
——通道的出口節點接收壓縮包，根據需要重新組合，去掉包頭信息，更新IPv6包頭信息，
并且處理接收到的IPv6包。


——為了處理傳輸到通道里的IPv6包，壓縮節點的MAY要害字需要為每個參數為通道的
MTU的通道記錄維持軟件狀態信息。由于傳輸數量可能變得非常大每臺主機和路由器都可
能被使用，當不用時這種狀態信息將被緩存和拋棄。
接下來的這部分討論用于兩種通道類型的一般的機制。后面部分討論怎樣為自動的和配
置的通道決定傳輸端點地址。

3.1.封裝
一個在IPv4里的IPv6數據圖的封裝如下圖所示：
-------------
IPv4
Header
+-------------++-------------+
IPv6IPv6
HeaderHeader
+-------------++-------------+
TransportTransport
Layer===>Layer
HeaderHeader
+-------------++-------------+

~Data~~Data~

+-------------++-------------+
在IPv4里封裝的IPv6

另外增加一個IPv4報頭，壓縮節點不得不處理一些更加復雜的事情：
——決定何時分成片斷何時返回一個ICMP"包太大"的出錯信息給資源。
——怎樣從路由器沿著傳輸路徑作為IPv6ICMP錯誤映射IPv4ICMP錯誤到資源。
那些問題將在下面部分討論。

3.2.MTU傳輸和分片
壓縮節點可以看作是IPv6利用一個非常大的MTU的IPv4作為連接層的壓縮。壓縮節
點將僅僅用來由于包超過了MTU向資源匯報IPv6ICMP"包太大"的錯誤信息。然而，由于
兩點理由使得這種方案的效率是低的：
1）它將導致需要更多的分片。IPv4層的分片要害字SHOULD由于丟失單元比轉發單元更
小而導致的性能問題所以應該盡量避免。
2）在傳輸里發生的任何IPv4的分片將不得不在通道的端點重新組合。因為傳輸在一個路由
器結束，這就將需要附加的寄存器來重新把IPv4片斷組合成完整的IPv6包在包能被傳輸到
前面前。
在通道里的分片能通過壓縮節點通過通道路由IPv4路徑的MTU來減少到最小，利用
IPv4路徑MTU發現協議[8]和記錄的結果路徑MTU。在壓縮節點里的IPv6層能把有一個與
IPv4路徑MTU同等的MTU的連接層看作一個通道，減去壓縮的IPv4包頭的大小。
注重這并不能完全排除在當IPv4路徑MTU將導致一個IPv6MTU比1280bytes少的情
況下IPv4分片。在這樣的情況下IPv6層不得不用一個1280bytesMTU來處理一個連接層并
且壓縮節點為了傳輸1280bytes的IPv6包而不得不用IPv4分片。
壓縮節點能用以下的運算法則來決定何時傳輸一個比用IPv4分片的傳輸路徑MTU大
的IPv6包，何時返回一個IPv6IMCP"包太大"的信息：

If(IPv4pathMTU-20)islessthanorequalto1280
Ifpacketislargerthan1280bytes
SendIPv6ICMP"packettoobig"withMTU=1280.
Droppacket.
Else
EncapsulatebutdonotsettheDon'tFragment
flagintheIPv4header.TheresultingIPv4
packetmightbefragmentedbytheIPv4layeron
theencapsulatingnodeorbysomerouteralong
theIPv4path.
Endif
Else
Ifpacketislargerthan(IPv4pathMTU-20)
SendIPv6ICMP"packettoobig"with
MTU=(IPv4pathMTU-20).
Droppacket.
Else
EncapsulateandsettheDon'tFragmentflag
intheIPv4header.
Endif
Endif
壓縮節點由大量的傳輸時就不可能為所有的傳輸儲存IPv4路徑MTU。像這樣的節點就要在
網絡上花費附加的分片，避免通過傳輸使用IPv4路徑MTU運算法則并用在運算法則上的
連接層MTU來代替IPv4路徑MTU。
在這樣的情況下不分片位的要害字MUST　NOT將在封裝的IPv4包頭里設置。
3.3.跳線限制
作為單一跳線模型的基于IPv4的IPv6通道。這就是說，當一個IPv6包經過通道時IPv6
條線限制就被減少一。單一跳線模型為隱藏一個存在的通道服務。通道對網絡用戶來說是不
透明的，并且對跟蹤路由這樣的網絡診斷工具來說多是不可發覺的。
單一跳線模型通過有壓縮和解壓縮的用來處理當他們將傳輸一個包到其它的數據連接
的IPv6跳線限制的節點被執行。那就是說，當傳輸一個IPv6包時他們就減少一個跳線限制。
封裝的IPv4包頭的TTL在一個依靠方式的執行中被選擇。MAY的執行提供了一個允
許治理員配置IPv4TLL的機制，這在IPTunnelMIB[17]中具體說明了。

3.4.處理IPv4ICMP錯誤
在對封裝包的響應被送到通道里，壓縮節點可能從在通道內部的IPv4路由器收到IPv4
ICMP錯誤信息。這些包被標明指向壓縮節點的地址因為這是壓縮包的IPv4資源。
ICMP"包太大"的出錯信息通過IPv4路徑MTUDiscovery[8]來處理并且在IPv4層里記
錄著導致的路徑MTU。被記錄的路徑MTU被IPv6用來決定是否一個IPv6ICMP"包太大"
出錯已經在3.2中說明的那樣產生。
其它類型的ICMP錯誤信息處理依靠在"錯誤包"里包含了多少信息，那塊區域阻止了封
裝的包因此導致錯誤。
許多老的IPv4路由器僅僅返回數據的8bytes這就超出了出錯的IPv4包的報頭，這對包
含IPv6報頭的地址域來說是不夠的。更先進的IPv4路由器返回足夠的數據，這數據超過包
含整個IPv6報頭的IPv4報頭并且甚至能超出數據。
假如可惡的包包含了足夠的數據，封裝節點MAY吸取了封裝的IPv6包并用它來產生
一個IPv6ICMP信息直接返回到先前的IPv6節點，就像下面所示的：








+--------------+
IPv4Header
dst=encaps
node
+--------------+
ICMP
Header
--+--------------+
IPv4Header
src=encaps
IPv4node
+--------------+--
PacketIPv6
HeaderOriginalIPv6
in+--------------+Packet-
TransportCanbeusedto
ErrorHeadergeneratean
+--------------+IPv6ICMP
errormessage
~Data~backtothesource.

--+--------------+--

3.5.IPv4報頭組成
當在一個IPv4數據圖里正封裝一個IPv6包時，IPv4包頭區域是按如下所設置：

版本：
4
32位的IP包頭長：
5
服務類型：
0.
總長度：
有效負載長度是IPv6和IPv4報頭的長度加上IPv6報頭。
鑒定：
獨一無二的作為被系統產生的為任何IPv4包傳輸的。
標志：
DF標志的設置在3.2中將具體說明。
MF標志的設置根據分段需要來設置。
分段設置：
根據分段的需要來設置。
周期：
在執行說明方式中設置。
協議：
41
校驗報頭總數：
計算IPv4報頭的校驗總數。
地址資源：
流出的IPv4地址的封裝節點的接口。
目的地地址：
傳輸終點的IPv4地址。
任一IPv6的選擇權被保留在數據包中。

3.6.解壓縮
當一個IPv6/IPv4主機或路由器接收一個IPv4被定址到它自己的IPv4地址之一的數據
圖時，并且協議域的值是41，假如它是按照IPv4標準分段的哪它將重新組合，然后它去掉
IPv4的報并提交IPv6數據圖到它的IPv6層代碼。
解壓縮解點的要害字MUST有能力重新組合一個1300bytes的IPv4包。
下面所示的是解壓縮圖：
+-------------+
IPv4
Header
+-------------++-------------+
IPv6IPv6
HeaderHeader
+-------------++-------------+
TransportTransport
Layer===>Layer
HeaderHeader
+-------------++-------------+

~Data~~Data~

+-------------++-------------+

當解壓縮包時，IPv6的報頭沒有被修改。假如包是被隨后傳到的，它的跳線限制減少
一個。
作為解壓縮的一部分節點要害字SHOULD默認拋棄一個有像一個多點傳送地址的無效
IPv4源地址包，一個廣播地址，0.0.0.0，和127.0.0.1。在一般情況下SHOULD在IPv4源地
址上為火星的過濾器在[18]里和入口過濾器[13]應用規則。
解壓縮的IPv4報頭是被丟棄的。
解壓縮以后節點SHOULD默認丟棄一個有無效IPv6源地址的包。這包括IPv6多點傳
送地址，未定義地址，和返回地址但是是IPv6與IPv4兼容的源地址在此源地址里由一部分
IPv4地址是多點傳送的，廣播地址，0.0.0.0，或127.0.0.1。在一般情況下SHOULD在IPv4
兼容源地址上為火星的過濾器在[18]里和入口過濾器[13]應用規則。
解壓縮節點在解壓縮IPv6包前執行IPv4重組。所有的IPv6選擇權被保留即使是壓縮
的IPv4包是被分段的也一樣。
在IPv6包被解壓縮以后，它幾乎被處理像任一接收的IPv6包一樣。唯一的不同是一個
解壓縮包要害字MUSTNOT被傳輸除非節點已經被明確配置保護給定的IPv4源地址的包。
這種配置在有一個與IPv4源地址配對的配置的通道的例子里能被暗含。這種約束在阻止通
道被用作用來包圍入口過濾器[13]的工具是被需要的。

3.7.連接本地
配置的和自動的通道兩者都是IPv6的接口因此MUST要害字有本地連接地址。本地連
接地址被在通道上執行的路由器協議使用。
接口標記符為像一個接口要害字SHOULD是那種接口的32位IPv4地址，有同樣命令
的字節在他們將要出現在一個IPv4包的報頭中，用零填補一個64位的剩下部分。注
意"universal/local"字節是零，指出接口標記符不是全世界唯一的。當主機有不止一個IPv4
地址在物理接口時，一個這些IPv4地址的治理選擇被確定。
為一個IPv4虛擬接口的IPv6本地連接地址被添加接口標記符而形成，就像上面定義的
那樣，FE80::/64的前綴。

+-------+-------+-------+-------+-------+-------+------+------+
FE80000000000000
+-------+-------+-------+-------+-------+-------+------+------+
00000000IPv4Address
+-------+-------+-------+-------+-------+-------+------+------+
3.8.在通道上的鄰居發現
自動的和單向配置的通道被認為是單向的。因此ND和自動配置地址狀態的唯一方面應
用于這些通道是本地連接地址的構成。
假如一個執行提供了雙向的配置通道它的要害字MUST至少使用NUD對查明的包接收
和回應。像這樣的執行要害字SHOULD也發送NUD查明的包來探測當配置的通道失敗在
能用一個備用的路徑到達目的地的執行點上。注重ND答應NUD的發送路由器到路由器的
連接探測可能被漏掉假如路由器協議有雙向可到達能力。
為了ND的目的自動的和配置的通道在本文中明確說明作為對NOT的假設有一個連接
層地址，即使連接層沒有地址。這就是說ND包的一個發送者。
——SHOULDNOT包括在通道連接上的源連接層地址對象或目標連接層地址對象。
——MUST默認的不處理在通道上的任一接收的SLLA或TLLA對象。

4.配置的通道
在配置的通道里，傳輸端點地址通過在壓縮節點里的配置信息被決定。壓縮節點必須為
每個通道保存傳輸的端點地址。當一個IPv6的包通過一個通道傳送時，為通道配置了通道
端點地址被作為壓縮的IPv4報頭的目的地地址。
哪個包到通道通常由在壓縮解點上的路由信息來決定。這通常經過一個路由平臺來實
現，路由平臺是通過使用前綴和匹配技術指引包到達基于他們的目的地址。
4.1.缺省配置的通道
IPv6/IPv4主機不是用IPv6路由器來連接數據的，要害字MAY使用一個配置的通道來
到達一個IPv6路由器。這種通道答應主機和剩下的IPv6網間交流。假如一個IPv6/IPv4的
IPv4地址被知道接近IPv6的中樞，這能過被當作通道的端地址使用。這樣的通道可以被作
為一個IPv6"錯誤路由"配置在路由器平臺里。那也就是說，所有的IPv6目的地地址將匹配
路徑并能通過通道。由于像"masklength"這類的缺生路徑是零，它將僅僅被用于由一個更長
的mask和它匹配的目的地而沒有其它路徑的情況。缺省配置的通道能被用于與自動通道的
連接，這將在5.4.中說明。
4.2.使用IPv4"任意點傳送地址"的缺省配置的通道
像一個缺省通道的通道端點地址可能是一個在IPv6中樞邊緣的IPv6/IPv4路由器的IPv4
地址。另一種可能是通道的端點地址是一個IPv4"任一點傳送的地址"。用這種方法，多重的
IPv6/IPv4路由器在邊緣廣播的IPv4可能到達同一IPv4地址。所有的路由器都接收作為他
們自己地址的包，并且將解壓縮IPv6包傳輸到這個地址。當一個IPv6/IPv4節點發送一個壓
縮包到這個地址時，它將被遞交到一個邊緣路由器的其中之一，但是發送的節點將不知道是
哪一個。IPv4路由系統將通常傳送包到最近的路由器。
對一個IPv4"任意傳送地址"使用缺省通道提供了一個高效率的方法因為多重的邊緣路
由器能夠被提供，并且使用普通的IPv4路由可退機制當一個路由器不能工作時傳輸將自動
的轉向另一個路由器。然而，當使用這樣的卻省通道來阻止來自不同路由器的不同IPv4片
斷是必須小心。這也能被其它的壓縮包的避免片斷所阻止或經常被阻止轉向IPv4路由。
4.3.入口過濾
解壓縮節點MUST用來在傳輸解壓縮包前驗證通道源地址時可接收的以次來避免包圍
入口過濾。注重被傳遞到傳輸協議的包在解壓縮節點SHOULDNOT連接到這些校驗。對雙
向的配置通道這被驗證終端通道的源地址是IPv4地址。對單向的配置通道解壓縮節點MUST
用一系列加前綴的IPv4源地址配置的是可接收的。像這一系列的MUST缺省沒有任何的i.e.
入口，節點不得不明確的配置傳輸解壓縮的包在單向配置的通道上接收時。



5.自動傳輸
在自動的傳輸里，通道端點地址是被傳輸的IPv6包的IPv4兼容目的地地址所決定。自
動傳輸答應IPv6/IPv4節點在沒有優先配置通道的IPv4基礎下部組織上交流。
5.1.IPv4兼容地址格式
執行自動傳輸的IPv6/IPv4節點被賦予IPv4兼容地址。一個IPv4兼容地址被一個前綴
都為零的96位數定義，并且在低32位保存一個IPv4地址。IPv4兼容地址的結構如下圖所
示：
96-bits32-bits
+--------------------------------------+--------------+
0:0:0:0:0:0IPv4Address
+--------------------------------------+--------------+
IPv4地址被賦給用來支持自動傳輸的專有的節點。一個節點SHOULD只有在他被預備用來
接收IPv6包時被配置一個IPv4兼容地址從在IPv4里壓縮的地址到IPv4的內含地址。
一個兼容的IPv4地址是全球獨一無二的只要IPv4地址不是來自私有的IPv4地址空間。
一個執行SHOULD的動作就似乎是把IPv4兼容地址賦給節點的自動通道接口，即使執行沒
有用接口的一個概念來執行自動傳輸。因此IPv4兼容地址SHOULDNOT被看作是連向一
個以太網接口的i.e.的工具不應該在一太網上用像NUD的ND機制。不管怎樣的接口應該
用在自動通道接口的壓縮包i.e.來完成。
5.2.IPv4兼容地址的配置
有一個IPv4兼容地址的一個IPv6/IPv4節點用像它的一個IPv6地址一樣的地址，當IPv4
地址包含在低32位作為為另一個接口的IPv4地址。
一個IPv6/IPv4節點MAY需要它的通過IPv4地址配置協議的IPv6與IPv4兼容的地址。
MAY用IPv4地址配置機制來配置任意它的所需的IPv4地址，然后"map"這些地址到一個
IPv6與IPv4兼容的地址里。這種配置模式答應IPv6/IPv4節點"leverage"安裝基本的IPv4地
址配置服務。
非凡的運算法則被一個使用基本的IPv4地址配置協議的IPv4兼容的址所需，如下所示：
1）IPv6/IPv4節點使用標準的IPv4機制或協議來滿足IPv4地址之一的接口。它包括：
——動態的主機配置協議（DHCP）
——BOOTP(TheBootstrapProtocol)
——RARP(TheReverseAddressResolutionProtocol)
——手動配置
——其它能正確產生節點自身IPv4地址的機制
2）節點作為IPv4地址來為接口使用這些地址。
3）節點預先設計了96位前綴0:0:0:0:0:0給32位的IPv4地址這在下一步中需要。結果是節
點的IPv4地址之一的IPv6/IPv4兼容的地址包含在低32位中。節點把它們作為IPv6地址之
一來使用這些地址。
5.3.自動傳輸治理
在自動傳輸中，通道端點地址通過被傳輸包來決定。假如IPv6的目的地地址與IPv4兼
容，那包能通過自動傳輸被發送。假如目的地地址是IPv6自身地址，那包就不能通過自動
通道被發送。
一個路由平臺入口被直接用來自動傳輸。一個執行對96位前綴0:0:0:0:0:0由一個非凡
不動的路由平臺入口。和這個前綴配對的包被一個假冒的接口發送這個接口執行自動傳輸。
由于所有的IPv6/IPv4兼容地址將和這個前綴配對，所有的包將自動傳輸到目的地。
一旦它被傳送到自動通道的模式，IPv6包根據在3部分里描述的那樣不用一個IPv4報
頭來壓縮。壓縮的IPv4報頭的源和目的地址被賦予成如下：
目的地IPv4地址：
IPv6目的地地址的低32位
源IPv4地址
IPv4地址的接口的包總是在壓縮形式通過自動通道模式被發送，即使目的地是在
一個數據連接上。

自動傳輸模式MUSTNOT發送IPv4廣播或多點傳送目的地。MUST丟棄所有的IPv6
包到IPv4兼容目的地當內含的IPv4地址被廣播時，多路徑傳送時，沒定義的地址（0.0.0.0）
或是循環地址（127.0.0.1）。注重發送者能告訴是否一個地址是主網的或是子網的地址。
5.4.使用缺省配置的通道
自動傳輸經常使用在和缺省配置的通道技術的連接上。隔離的IPv6/IPv4主機——那些
主機沒有IPv6路由器連接——使用自動傳輸和IPv6/IPv4兼容地址來配置，并且至少有一個
缺省通道對一個路由器。IPv6路由器像執行自動傳輸一樣被配置。這些隔離的主機通過自
動傳輸發送包到IPv4兼容目的地和通過缺省配置的通道發送包到IPv6自身目的地。IPv4兼
容目的地將與96為所有零的前綴配對這已在前面討論，而IPv6自身目的地通過配置的通道
將與缺省的路徑匹配。從IPv6自身目的地回復包時通過一個IPv6/IPv4路由器。更多的例子
在[12]中討論。
5.5.源地址選擇
當一個IPv6/IPv4節點發出一個IPv6包時，它必須選擇源IPv6地址來使用。IPv6/IPv4
節點被配置用來執行自動傳輸可能用全球IPv6自身地址和IPv4兼容地址來配置。選擇用哪
種源地址由返回交通量來決定。假如IPv4兼容地址被選用，返回交通量將不得不通過自動
通道來傳輸，當時假如IPv6自身地址被選用，返回交通量將不必使用自動通道。為了使交
通量盡可能的平衡，建議參考下面的源地址選擇：
目的地是IPv4兼容：
用IPv4兼容源地址和流出接口的IPv4地址結合
目的地是IPv6自身：
用流出接口的IPv6自身地址
假如一個IPv6/IPv4節點沒有全球的IPv6自身地址，但是產生的一個包是到IPv6自身的目
的地，MAY用來將其IPv4兼容地址當作源地址用。
5.6.入口過濾
解壓縮節點MUST在傳輸解壓縮包前校驗壓縮包時可接收的以次來避免包圍入口過濾。
注重包傳輸選擇哪一傳輸協議在解壓縮節點SHOULDNOT上將服從這些校驗。由于自動傳
輸總是壓縮到目的地在一個自動通道上接收的包SHOULDNOT被傳輸。
6.謝意表達
我們將感謝IPng工作組的成員和NextGenerationTransition(ngtrans)工作組成員
對本文的巨大貢獻。非凡感謝JimBound,RossCallon和BobHinden給予的許多幫助和建
議和JohnMoy對IPv4“anycastaddress"缺身通道的技術建議。
7.安全方面的考慮
傳輸沒有引進任何的安全漏洞除了在包圍入口過濾里可能外。這能被阻止通過解壓縮路
由器僅傳送有配置的包，從在接受包里的IPv4源地址接收壓縮包。另外，在自動傳輸情況
下，節點被不傳送的解壓縮包需要由于自動傳輸終止了通道和目的地。
8.作者地址
RobertE.Gilligan
FreeGateCorp
1208E.ArquesAve
Sunnyvale,CA94086
USA

Phone:+1-408-617-1004
Fax:+1-408-617-1010
EMail:gilligan@freegate.com


ErikNordmark
SunMicrosystems,Inc.
901SanAntonioRd.
PaloAlto,CA94303
USA

Phone:+1-650-786-5166
Fax:+1-650-786-5896
EMail:nordmark@eng.sun.com

9.參考書
[1]Croft,W.andJ.Gilmore,"BootstrapProtocol",RFC951,
September1985.

[2]Droms,R.,"DynamicHostConfigurationProtocol",RFC1541,
October1993.

[3]Carpenter,B.andC.Jung,"TransmissionofIPv6overIPv4
DomainswithoutEXPlicitTunnels",RFC2529,March1999.

[4]Deering,S.andR.Hinden,"InternetProtocol,Version6(IPv6)
Specification",RFC2460,December1998.

[5]Thomson,S.andT.Narten,"IPv6StatelessAddress
Autoconfiguration,"RFC2462,December1998.

[6]Crawford,M.,Thomson,S.,andC.Huitema."DNSExtensionsto
SupportIPv6AddressAllocationandRenumbering",RFC2874,July
2000.

[7]Narten,T.,Nordmark,E.andW.Simpson,"NeighborDiscoveryfor
IPVersion6(IPv6)",RFC2461,December1998.

[8]Mogul,J.andS.Deering,"PathMTUDiscovery",RFC1191,
November1990.

[9]Finlayson,R.,Mann,T.,Mogul,J.andM.Theimer,"Reverse
AddressResolutionProtocol",STD38,RFC903,June1984.

[10]Braden,R.,"RequirementsforInternetHosts-Communication
Layers",STD3,RFC1122,October1989.

[11]Kent,C.andJ.Mogul,"FragmentationConsideredHarmful".In
Proc.SIGCOMM'87WorkshoponFrontiersinComputer
CommunicationsTechnology.August1987.

[12]Callon,R.andD.HaSKIN,"RoutingaspectsofIPv6Transition",
RFC2185,September1997.

[13]Ferguson,P.andD.Senie,"NetworkIngressFiltering:Defeating
DenialofServiceAttackswhichemployIPSourceAddress
Spoofing",RFC2267,January1998.

[14]Hinden,R.andS.Deering,"IPVersion6Addressing
Architecture",RFC2373,July1998.
15]Rechter,Y.,Moskowitz,B.,Karrenberg,D.,deGroot,G.J.and
E.Lear,"AddressAllocationforPrivateInternets",BCP5,RFC
1918,February1996.

[16]Bradner,S.,"KeyWordsforuseinRFCstoIndicateRequirement
Levels",BCP14,RFC2119,March1997.

[17]Thaler,D.,"IPTunnelMIB",RFC2667,August1999.

[18]Baker,F.,"RequirementsforIPVersion4Routers",RFC1812,
June1995.

10.從1933年起的RFC變化
Deletedsection3.1.1(IPv4loopbackaddress)inordertoprevent
itfrombeingmis-construedasrequiringrouterstofilterthe
address::127.0.0.1,whichwouldputanothertestinthe
forwardingpathforIPv6routers.

-Deletedsection4.4(DefaultSendingAlgorithm).Thissection
allowednodestosendpacketsin"rawform"toIPv4-compatible
destinationsonthesamedatalink.Implementationexperiencehas
shownthatthisaddscomplexitywhichisnotjustifiedbythe
minimalsavingsinheaderoverhead.

-AddeddefinitionsforOperatingmodesforIPv6/IPv4nodes.

-RevisedDNSsectiontoclarifyresolverfilteringandordering
options.

-Re-wrotethediscussionofIPv4-compatibleaddressestoclarify
thattheyareusedexclusivelyinconjunctionwiththeautomatic
tunnelingmechanism.Re-organizeddocumenttoplacedefinitionof
IPv4-compatibleaddressformatwithdescriptionofautomatic
tunneling.

-Changedtheterm"IPv6-onlyaddress"to"IPv6-nativeaddress"per
currentusage.

-UpdatedtoalgorithmfordeterminingtunnelMTUtoreflectthe
changeintheIPv6minimumMTUfrom576to1280bytes[4].

-Deletedthedefinitionfortheterm"IPv6-in-IPv4encapsulation."
Ithasnotbeenwidelyused.

-RevisedIPv4-compatibleaddressconfigurationsection(5.2)to
recognizemultipleinterfaces.
AddeddiscussionofsourceaddressselectionwhenusingIPv4-
compatibleaddresses.

-Addedsectiononthecombinationofthedefaultconfigured
tunnelingtechniquewithhostsusingautomatictunneling.

-AddedprohibitionagainstautomatictunnelingtoIPv4broadcastor
multicastdestinations.

-Clarifiedthatconfiguredtunnelscanbeunidirectionalor
bidirectional.

-Addeddescriptionofbidirectionalvirtuallinksasanothertype
oftunnels.NodesMUSTrespondtoNUDprobesonsuchlinksand
SHOULDsendNUDprobes.

-Addedreferenceto[16]specificationasanalternativefor
tunnelingoveramulticastcapableIPv4cloud.

-ClarifiedthatIPv4-compatibleaddressesareassignedexclusively
tonodesthatsupportautomatictunnelsi.e.nodesthatcan
receivesuchpackets.

-Addedtextaboutformationoflink-localaddressesanduSEOf
NeighborDiscoveryontunnels.

-Addedrestrictionthatdecapsulatedpacketsnotbeforwarded
unlessthesourceaddressisacceptabletothedecapsulating
router.

-ClarifiedthatdecapsulatingnodesMUSTbecapableofreassembling
anIPv4packetthatis1300bytes(1280bytesplusIPv4header).

-ClarifiedthatwhenusingadefaulttunneltoanIPv4"anycast
address"thenetworkmusteitherhaveanIPv4MTUofleast1300
bytes(toavoidfragmentationofminimumsizeIPv6packets)orbe
configuredtoavoidfrequentchangestoIPv4routingtothe
"anycastaddress"(toavoiddifferentIPv4fragmentsarrivingat
differenttunnelendpoints).

-UsingA6/AAAAinsteadofAAAAtoreferenceIPv6addressrecordsin
theDNS.

-SpecifiedwhentoputIPv6addressesintheDNS.

-AddedreferencetothetunnelmibforTTLspecificationforthe
tunnels.

11.版權申明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

Acknowledgement

FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe
InternetSociety.