IPv6保留的子網任意傳送地址

本備忘錄的狀態
本文檔講述了一種Inte.net社區的Internet標準跟蹤協議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準化
程度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright(C)TheInternetSociety(1999).AllRightsReserved.
摘要
IPv6協議地址結構定義了一種任意傳送地址，這個IP地址被分配給一個或者多個網絡
接口（典型的來說，這些接口屬于不同的結點），這樣發送給這個IP的分組就會按照地址距
離量協議傳送到所有具有這個IP地址的網絡接口中最近的一個。本文檔定義了一些帶有子
網前綴的任意傳送地址，并且列出了這些保留的子網任意傳送地址的初始分配。
目錄
摘要 1
1． 簡介 2
2． 保留的子網任意傳送地址格式 2
3． 保留的子網任意傳送地址列表 3
4． 舉例 3
5． IANA考慮 4
6． 安全問題 4
7．參考資料 4
8．作者聯系方法 5
9．版權說明 5

1． 簡介
IPv6定義了一種新類型的IP地址：任意傳送地址，允許分組被路由到具有某個IP地址
的所有節點中的其中隨便一個。這個任意傳送地址可能被分配給一個或者多個網絡接口（典
型的來說，這些接口屬于不同的結點），這樣發送給這個IP的分組就會按照地址距離量協議
傳送到所有具有這個IP地址的網絡接口中最近的一個。
任意傳送地址的使用仍在不斷的發展，但是這些地址提供了很多潛在的重要服務[5,6]。
例如，一個傳送地址可以用來允許節點訪問提供某種已知服務的服務器集合中的一個服務
器，而不需要在每個節點手工配置服務器列表。
IPv6為子網內所有的具有子網前綴的路由器定義了一個必須的子網路由器任意傳送地
址，而且允許其它的任意傳送地址取自單投地址空間。本文檔定義了另外的一些帶有子網前
綴的任意傳送地址集，并且列出了這些保留的子網任意傳送地址的初始分配。
這個文檔中出現的關鍵詞"MUST","MUSTNOT","REQUIRED","SHALL","SHALL
NOT","SHOULD","SHOULDNOT","RECOMMENDED","MAY",and"OPTIONAL"的詳
細含義，請參閱RFC2119[1]。
2． 保留的子網任意傳送地址格式
在每個子網內，接口標識符的最高128位被保留作為子網任意傳送地址。
保留的子網任意傳送地址結構取決于由地址前綴表明的在子網內使用的IPv6地址類
型。確切的來說，IPv6地址類型需要64位的EUI-64格式的接口標識符，在所有保留的任
意傳送地址中全體/本地位必須設為0（本地），用來表明接口標識符在全球并不是唯一的。
這種類型的IPv6地址目前被指定位具有001到111前綴的，除了多播地址（11111111）[3]。
確切的來說，IPv6地址類型需要64位的EUI-64格式的接口標識符，這些保留的IPv6
子網任意傳送地址結構如下：
|64bits|57bits|7bits|
+---------------------------------+------------------+------------+
|子網前綴|1111110111...111|anycastID|
+---------------------------------+------------------+------------+
|接口標識符|
對于其它的IPv6地址類型（也就是，前綴跟上面列出不同的地址），接口標識符長度不
是EUI-64格式，長度也可能不是64位；這些地址類型保留的任意傳送地址結構如下：
|n位|121-n位|7位|
+---------------------------------+------------------+------------+
|子網前綴|1111111...111111|anycastID|
+---------------------------------+------------------+------------+
|接口標識符|
這里的子網前綴包含除了接口標識符意外的所有字段。保留的子網內任意傳送地址中的
接口標識符由7位的任意傳送標識號，其它位置（高字節位置）1而形成（anycastID）；然
而對于EUI-64格式的接口標識符，全體/本地位必須置為0。任意傳送標識號標識了子網內
所有保留的任意創送地址中一個確定的任意傳送地址。
在子網地址中保留高位（而不是低位）的目的是避免和目前使用的一些正式或者非正式
的低位數字格式地址相沖突。例如，這些低位數字格式地址通常在點對點鏈接節點，隧道終
點中使用，另外還有當網絡接口的硬件令牌不能得到時手工配置單傳送地址，甚至手工配置
一個連接中路由器的靜態地址，都需要使用低位數字格式地址。只保留了128位給任意傳送
標識號（而不是可能的128位）的意思是說由于只允許子網與接口標識符的分界與字節邊界
對其，在IPv6地址中接口標識符最小的尺寸是8位（包括子網單投地址空間以及保留的子
網任意傳送地址）。
對于所有的IPv6任意傳送地址，這些保留的子網任意傳送地址是在IPv6單投地址空間
中分配的。在本文檔中定義的所有保留任意傳送地址，在帶有任何子網前綴，所有連接中都
是保留的。它們不能再作為單投地址分配給網絡接口。

3． 保留的子網任意傳送地址列表
目前，保留的子網任意傳送地址中下面的這些任意傳送標識號被定義：

10進制16進制描述
-----------------------------
1277F保留
1267E移動IPv6家鄉代理任意傳送
0-12500-7D保留
其它任意傳送標識號的將在以后定義。
4． 舉例
為了進一步解釋子網任意傳送地址的結構，本節詳細說明移動IPv6家鄉代理子網任意
傳送的地址結構。在第三節中已經講過，移動IPv6家鄉代理子網任意傳送地址的7位地址
標識符為126（10進制），7E（16進制）。
IPv6地址包含一個格式化的前綴，指明接口標識符長度必須為64位，格式為EUI-64
格式（目前格式化前綴為001到111，除了11111111）。保留的移動IPv6家鄉代理子網任意
傳送地址包含64位的子網前綴，然后是64位的接口標識符。格式如下：
|01|13|34|46|
|05|61|27|83|
+----------------+----------------+----------------+----------------+
|1111110111111111|1111111111111111|1111111111111111|1111111111111110|
+----------------+----------------+----------------+----------------+
^^^^^^^^
+---全體/本地位任意傳送標識號---+-----+
其它的IPv6地址類型，接口標識符長度可能不是64字節而且也不是EUI-64格式。在
這個例子中，假定接口標識符的長度為64位，使得與上面的比較能夠清除一些（雖然長度
不是64字節的也是同樣的結構）。這樣保留的移動IPv6家鄉代理子網任意傳送地址包含64
位的子網前綴，然后是64位的接口標識符。格式如下：
|01|13|34|46|
|05|61|27|83|
+----------------+----------------+----------------+----------------+
|1111111111111111|1111111111111111|1111111111111111|1111111111111110|
+----------------+----------------+----------------+----------------+
^^^^^^^
任意傳送標識號---+-----+


5． IANA考慮
本文檔在IPv6單投地址空間內，每個子網前綴中任意傳送表示號的基礎上，定義了一
系列保留的子網任意傳送地址。隨著需求的增長，新的任意標識號還需要被定義。這樣的任
意傳送標識號應該在所有子網前綴中保留，因此這些任意傳送標識號的分配必須集中管理。
新值的分配應該按照降序來分配，而且需要得到IESG的同意。
6． 安全問題
任何類型的保留任意傳送地址的使用，都只是會允許公開的IP被攻擊。由于指定了某
些服務在某個保留任意傳送地址上，攻擊者可能集中攻擊指定的服務。然而，這樣的攻擊在
每個使用任意傳送地址的每個服務中可以得到很好的處理。
在最初建議了IPv6任意傳送的RFC1547中，也指出了一些使用任意傳送而帶來的安全
問題。

7．參考資料
[1]Bradner,S.,"KeywordsforuseinRFCstoindicaterequirement
levels",BCP14,RFC2119,March1997.

[2]Deering,S.andR.Hinden,"InternetProtocolVersion6(IPv6)
Specification",RFC2460,December1998.

[3]Hinden,R.andS.Deering,"IPVersion6Addressing
Architecture",RFC2373,July1998.

[4]DavidB.JohnsonandCharlesPerkins,"MobilitySupportinIPv6",
WorkinProgress.

[5]SteveKingetal,"TheCaseforIPv6",WorkinProgress.

[6]Partridge,C.,Mendez,T.andW.Milliken,"HostAnycasting
Service",RFC1546,November1993.

8．作者聯系方法
DavidB.Johnson
CarnegieMellonUniversity
ComputerScienceDepartment
5000ForbesAvenue
Pittsburgh,PA15213-3891
USA

Phone:+1412268-7399
Fax:+1412268-5576
EMail:dbj@cs.cmu.edu


StephenE.Deering
CiscoSystems,Inc.
170WestTasmanDrive
SanJose,CA95134-1706
USA

Phone:+1408527-8213
Fax:+1408527-8254
EMail:deering@cisco.com

9．版權說明

Copyright(C)TheInternetSociety(1999).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedtoothers,and
derivativeworksthatcommentonorotherwiseexplainitorassistinitsimplementation
maybeprepared,copied,publishedanddistributed,inwholeorinpart,withoutrestriction
ofanykind,providedthattheabovecopyrightnoticeandthisparagraphareincludedon
allsuchcopiesandderivativeworks.However,thisdocumentitselfmaynotbemodified
inanyway,suchasbyremovingthecopyrightnoticeorreferencestotheInternetSociety
orotherInternetorganizations,exceptasneededforthepurposeofdevelopingInternet
standardsinwhichcasetheproceduresforcopyrightsdefinedintheInternetStandards
processmustbefollowed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotberevokedbythe
InternetSocietyoritssuclearcase/" target="_blank" >ccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan"ASIS"basis
andTHEINTERNETSOCIETYANDTHEINTERNETENGINEERINGTASKFORCE
DISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDINGBUTNOT
LIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATIONHEREIN
WILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.