IPv6 可集聚全球單播地址格式

備忘錄狀態：

ThisdocumentspecifiesanInternetstandardstrackprotocolforthe
Internetcommunity,andrequestsdiscussionandsuggestionsfor
improvements.Pleaserefertothecurrenteditionofthe"Internet
OfficialProtocolStandards"(STD1)forthestandardizationstate
andstatusofthisprotocol.Distributionofthismemoisunlimited.

版權注意：

Copyright(C)TheInternetSociety(1998).AllRightsReserved.

目錄

IPv6可集聚全球單播地址格式 1
1. 引論 2
2.IPv6地址概述 2
3.IPv6可集聚全球單播地址格式 2
3.1可集聚全球單播地址結構 3
3.2頂級集聚標識符 4
3.3保留字段 4
3.4下一級集聚標識符 4
3.5站點級集聚標識符 5
3.6接口ID 6
4.技術動機 6
致謝 7
參考文獻 7
安全性考慮 8

1. 引論
本文定義了可用于Internet上的IPv6可集聚全球單播地址格式。本文定義的地址
格式與IPv6協議【IPv6】以及“IPv6尋址體系結構”【ARCH】是一致的。它的設
計是為了推進規?？缮炜s的Internet選路。
本文件取代了RFC2073(基于供應商的IPv6單播地址格式)。RFC2073成為了歷史文
件?？杉廴騿尾サ刂犯袷绞菍FC2073某些方面的改進。主要的改變包括刪去了對路
由集聚、EUI-64接口標識符的支持，對供應商和交換局集聚的支持，公共和站點拓撲的
分割以及新集聚術語等所不需要的注冊位。
2.IPv6地址概述
IPv6地址是為接口和接口組指定的128位標識符。有三類地址：單播、任意點播和
組播。本文專門定義單播地址類。
在本文中，地址內的字段，賦予如“子網”這樣的專門名字。當名字與其后的名詞“標
識符”一起使用時(如“子網標識符”)，被稱為名字字段的內容。當名字與名詞“前綴”一
起用時(如“子網前綴”)，則表示包括本字段在內的所有左邊的尋址位。
IPv6單播地址的設計使Internet選路系統在不需要了解IPv6地址內部結構的
情況下，在任意位邊界上，使用一個最長的前綴匹配“算法”，就可作出包的轉發決定。IP
v6地址的結構是為指派和分配用的。唯一的例外就是要在單播和組播地址之間加以區別。
IPv6地址的特定類型由地址的前幾位指出。包含這前幾位的可變長度字段叫做格式
前綴(FP)。
本文為可集聚全球單播地址定義地址格式，其格式前綴為001(二進制)。其他格式前
綴也可以采用同樣的地址格式，只要這些格式前綴是標識IPv6單播地址的。只是本文只
定義了這種格式前綴而已。
3.IPv6可集聚全球單播地址格式
本文為IPv6可集聚全球地址格式的分配定義一種地址格式。作者相信這地址格式會
廣泛用于連到Internet的IPv6節點。設計該地址格式時，考慮到既支持當前基于供應
商的集聚，也支持新的基于交換局的集聚。其組合既允許直接連接到供應商的站點能高效率
地選路集聚，也允許連接到交換局的站點能高效率地選路集聚。站點可以選擇連接到兩者中
的任一個集聚實體。
當該地址格式的目的是支持基于交換局的集聚(除了當前基于提供商的集聚外)時，它的
總體路由集聚特性與交換局無關。只有用基于供應商的集聚，才能提供效率高的路由集聚。
可集聚地址安排成一個三層次的分級結構：
·公用拓撲。
·站點拓撲。
·接口標識符。
公用拓撲是提供公用Internet傳送服務的供應商和交換局群體。站點拓撲是本地的
特定站點或組織，它不提供到本站點以外節點的公用傳送服務。接口標識符是標識鏈路上的
接口。
____________________________
--+/\+--------------+/\+----------
(P1)+----+(P3)+----+
+\______________/||----+\______________/+--||--
|+--|X1|+|X2|
|______________/||-+______________/||--
+/\++-+--+\/\++----+
(P2)/\+(P4)
--+\______________//\\______________/
|/\||
|/|||
|/|||
_|__/__|__|__|_
/\/\/\/\/\
(S.A)(S.B)(P5)(P6)(S.C)
\___/\___/\___/\___/\___/
|/\
_|__/_\___
/\/\+-/\
(S.D)(S.E)(S.F)
\___/\___/\___/

正如上面圖所表示的可集聚地址格式，其目的是支持長途供應商(如圖中P1、P2、P
3、P4)，交換局(如圖中X1和X2)，多級供應商(如圖中P5和P6)和用戶(如圖中S.x)。
交換局(不像目前的NAPs、FIXes等)將分配IPv6地址。連接到這些交換局的組織，
也要從一個或多個長途供應商那里預訂(直接、間接地通過交換局等)長途服務。這樣做可使
尋址與長途轉運供應商無關。這使得在改換長途供應商時，無需給它們的組織重新編號。組
織也能成為多家的，也就是通過交換局連到一個以上的長途供應商，而不需要從每個長途供
應商處獲得地址前綴。用于此類供應商的選擇及移植性的機制不在本文中討論。
3.1可集聚全球單播地址結構
可集聚全球單播地址格式表示如下：

|3|13|8|24|16|64bits|
+--+-----+---+--------+--------+--------------------------------+
|FP|TLA|RES|NLA|SLA|InterfaceID|
||ID||ID|ID||
+--+-----+---+--------+--------+--------------------------------+

<--PublicTopology--->Site
<-------->
Topology
<------InterfaceIdentifier----->

其中，FP為格式前綴(001)；TLAID為頂級集聚標識符；RES保留為將來用；NLA
ID為下一級集聚標識符；SLAID為站點級集聚標識符；INTERFACEID為接口標識符；
下面分別給出IPv6可集聚全球單播地址格式的每一部分的說明。
3.2頂級集聚標識符
頂級集聚標識符(TLAID)是選路分級結構中的最高級。非默認路由器必須為每個激活的
TLAID保留一個路由表項，同時也許還有為TLAID提供選路信息的附加項。附加項的目
的是為它們的特定拓撲優先選路，但是所有級的選路拓撲，必須使提供給非默認路由表的附
加項數量最少。
這樣的尋址格式支持8192(213)個TLAID。要增加TLAID的數量可以向右擴展TL
A字段到保留字段，或者在另外的格式前綴上使用此格式。
關系分配TLAID的議題，超出了本文范圍，將在正在進行準備的文件中說明。
3.3保留字段
保留字段留作將來用，當前必須置成0。
保留字段可留作TLA和NLA字段擴展時用。見第4節的討論。
3.4下一級集聚標識符
下一級集聚標識符被得到一個TLAID的機構用來創建尋址分級結構和標識站點。該機
構可以指定NLAID字段的前n位，用來創建適合于它的網絡的尋址分級結構。該字段的
其余部分用來標識它愿為之服務的站點。表示如下：

|n|24-n位|16|64位|
+-----+--------------------+--------+-----------------+
|NLA1|站點ID|SLAID|接口ID|
+-----+--------------------+--------+-----------------+

每個得到一個TLAID的機構可以有24位NLAID空間。NLAID空間使每個機構能
夠為相當于目前IPv4Internet能夠支持的總網絡數幾乎一樣多的組織提供服務。
得到TLAID的機構，也支持他們自己站點ID空間中的NLAID。這就允許得到TLA
ID的機構，能給提供公用傳送服務的機構提供服務，也能給不提供公用傳送服務的機構提
供服務。得到NLAID的機構，也可以選擇用他們的站點ID空間去支持其他的NLAID。
這種情況表示如下：
|n|24-n位|16|64位|
+-----+--------------------+--------+-----------------+
|NLA1|站點ID|SLAID|接口ID|
+-----+--------------------+--------+-----------------+

|m|24-n-m|16|64位|
+-----+--------------+--------+-----------------+
|NLA2|站點ID|SLAID|接口ID|
+-----+--------------+--------+-----------------+

|o|24-n-m-o|16|64位|
+-----+--------+--------+-----------------+
|NLA3|站點ID|SLAID|接口ID|
+-----+--------+--------+-----------------+

對一個特定的TLAID，設計NLAID位的安排，留給負責該TLAID的機構去做。同
樣，設計下一級NLAID位的安排，由前面一級NLAID負責。在此建議分配NLA地址
空間的機構用類似于[RFC2050]中的“慢啟動”分配過程。
設計NLAID分配計劃，要在選路集聚效率和靈活性之間進行權衡。創建分級結構允
許較大集聚數，從而使得路由表較小。平面NLAID的分配能使分配容易和連接靈活，但
使得路由表較大。
3.5站點級集聚標識符
SLAID字段被單個機構用來創建他自己的本地尋址分級結構與標識子網。除了每個機
構有一個數量很大的子網以外，類似于IPv4中的子網。16位的SLAID字段支持65535
個單個子網。
機構可以選擇他們的SLAID為平面路由(如在SLA標識符之間不創建任何邏輯關系，
這會使得路由表較大)，或者在SLAID字段中，創建一個兩級或多級分級結構(使路由表較
小)。后一種情況表示如下：

|n|16-n|64位|
+-----+------------+-------------------------------------+
|SLA1|子網|接口ID|
+-----+------------+-------------------------------------+

|m|16-n-m|64位|
+----+-------+-------------------------------------+
|SLA2|子網|接口ID|
+----+-------+-------------------------------------+

構成SLAID字段所選擇的方法，由個別機構負責。
在這種地址格式下支持的子網數，除了最大的機構之外，對其他所有機構應該是足夠的。
對于需要更多子網的組織，可以和它獲得Internet服務的機構商量，以獲得附加的站點
標識符，從而用來創建更多的子網。
3.6接口ID
接口標識符用來標識一條鏈路上的接口。對鏈路來說，應該是唯一的。也可以在一個更
寬的范圍內是唯一的。許多情況下，一個接口標識符與接口的鏈路層地址相同，或者根據接
口的鏈路層地址而得的。用在可集聚全球單播地址格式中的接口標識符要求64位長，并能
構成IEEEEUI-64格式[EUI-64]。這些標識符，當全球令牌(如IEEE48位MAC)可
用時，具有全球范圍意義；當全球令牌不可用時(如串行鏈路、隧道終點等)，則只具有本地
范圍意義。u位(在IEEEEUI-64術語中稱為全球/本地位)在EUI-64標識符中必須根據
[ARCH]的規定，正確地置位以指示是全球還是本地范圍。
創建基于EUI-64接口標識符的過程定義見[ARCH]。形成接口標識符的細節，規
定在相應的IPv6over<link>技術規范中，諸如IPv6overEthernet【ETHER】，IPv6overFDDI
【FDDI】等。
4.技術動機
在可集聚的地址格式中，字段長度的設計選擇需要滿足許多技術需求。這些將在下面段
落中介紹。
頂級集聚標識符的長度是13位?？捎?192個TLAID。選擇這樣的長度，可使In
ternet上頂級路由器的非默認路由表，能在當前的選路技術且合理地留有余量的情況下，
保持有限的范圍。
因為非默認路由器為優化TLA內部路徑和TLA之間的路徑，還要含有大量的長的
前綴，所以保留余量是重要的。
重要的議題不僅是非默認選路表的長度問題，還有拓撲的復雜性決定了當計算一個轉發
表時，路由器必須考察非默認路由的拷貝數。當前IPv4的實踐是通常一個前綴要通過不
同的路徑通告15次。
Internet拓撲的復雜性將來還可能增加。重要的是IPv6非默認選路應支持更大的
復雜性以及巨大的Internet。
應該提出的是，在寫作本文時(1998年春)，作者作了一個比較，IPv4非默認路由
表包含大約50000個前綴，表示可能支持大于8192個的路由?，F在爭論的問題是在當前
的選路技術下，是否IPv4目前支持的前綴數已經足夠多了。一些需要認真考慮的議題是
路由穩定性以及供應商不支持所有頂級前綴的情況。技術上要求挑選TLAID的長度，在考
慮合理余量的情況下，低于IPv4所具有的。
選擇TLAID字段為13位是出于工程的綜合考慮。位數太少將不足以支持足夠的頂級
組織，位數太多將會超過合理協調的能力。為了處理前面所提到的議題，用當前的選路技術
考慮一個合理的余量是合適的。
如果將來選路技術改進到在非默認路由表中能支持大量的頂級路由，那么如何加大TL
A標識符，就有兩種選擇：第一種是擴大TLAID字段占用保留字數，這將使TLAID數大
約增加二百萬個；第二種途徑是為這樣的地址格式分配另一個格式前綴(FP)?；蛘邔⑦@兩
種途徑組合，使TLAID數量大大地增加。
保留字段的長度為8位，是為了使TLAID字段和NLAID字段有大的增長余地。
下一級集聚標識符的長度為24位。如果用平面結構的話，可容納大約1600萬個NLA
ID。如果分級使用的話，合成起來大致等效于IPv4的地址空間(假定平均網絡規模為25
4個接口)。如果NLAID將來需要更多的空間，那么可以將NLAID擴展到保留字段來協
調。
站點級集聚標識符字段的長度是16位。每個站點可支持65535個子網。本字段長度
的設計目標，對除了最大組織以外的所有組織是足夠的。對于需要更多子網的組織，可以和
它獲得Internet服務的機構商量，以得到附加的站點標識符，從而用來創建更多的子網。
站點集聚標識符字段是固定長度，這是為了強制標識特定站點的所有前綴，具有同樣的
長度(即48位)。這樣會方便站點在拓撲中的移動(如變更ISP以及接到多個ISP的多家
站點)。
接口標識符字段為64位。選擇這個長度是為了滿足[ARCH]中指定的需求，以支持
基于EUI-64接口標識符。
致謝
作者對ThomasNarten,BobFink,MattCrawford,AllisonMankin,JimBound,
ChristianHuitema,ScottBradner,BrianCarpenter,JohnStewart和DanielKarrenberg的評論和
建設性意見表示衷心的謝意。
參考文獻
[ALLOC]IABandIESG,"IPv6AddressAllocationManagement",
RFC1881,December1995.

[ARCH]Hinden,R.,"IPVersion6AddressingArchitecture",
RFC2373,July1998.

[AUTH]Atkinson,R.,"IPAuthenticationHeader",RFC1826,August
1995.

[AUTO]Thompson,S.,andT.Narten.,"IPv6StatelessAddress
Autoconfiguration",RFC1971,August1996.

[ETHER]Crawford,M.,"TransmissionofIPv6PacketsoverEthernet
Networks",WorkinProgress.

[EUI64]IEEE,"Guidelinesfor64-bitGlobalIdentifier(EUI-64)
RegistrationAuthority",
http://standards.ieee.org/db/oui/tutorials/EUI64.html,
March1997.

[FDDI]Crawford,M.,"TransmissionofIPv6PacketsoverFDDI
Networks",WorkinProgress.

[IPV6]Deering,S.,andR.Hinden,"InternetProtocol,Version6
(IPv6)Specification",RFC1883,December1995.

[RFC2050]Hubbard,K.,Kosters,M.,Conrad,D.,Karrenberg,D.,
andJ.Postel,"InternetRegistryIPAllocation
Guidelines",BCP12,RFC1466,November1996.

[RFC2119]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,
安全性考慮
IPv6尋址文件對Internet基礎設施安全性無任何直接影響。IPv6包的身份驗證
定義見【AUTH】。


Authors'Addresses

RobertM.Hinden
Nokia
232JavaDrive
Sunnyvale,CA94089
USA

Phone:1408990-2004
EMail:hinden@iprg.nokia.com


MikeO'Dell
UUNETTechnologies,Inc.
3060WilliamsDrive
Fairfax,VA22030
USA

Phone:1703206-5890
EMail:mo@uunet.uu.net


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

Phone:1408527-8213
EMail:deering@cisco.com

FullCopyrightStatement

Copyright(C)TheInternetSociety(1998).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
revokedbytheInternetSocietyoritssuclearcase/" target="_blank" >ccessorsorassigns.

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