备忘录状态：
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】是一致的。它的设
计是为了推进规模可伸缩的Internet选路。
本文件取代了RFC2073(基于供给商的IPv6单播地址格式)。RFC2073成为了历史文
件。可集聚全球单播地址格式是对RFC2073某些方面的改进。主要的改变包括删去了对路
由集聚、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可集聚全球单播地址结构
可集聚全球单播地址格式表示如下：
3138241664bits
+--+-----+---+--------+--------+--------------------------------+
FPTLARESNLASLAInterfaceID
IDIDID
+--+-----+---+--------+--------+--------------------------------+
<--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位，用来创建适合于它的网络的寻址分级结构。该字段的
其余部分用来标识它愿为之服务的站点。表示如下：
n24-n位1664位
+-----+--------------------+--------+-----------------+
NLA1站点IDSLAID接口ID
+-----+--------------------+--------+-----------------+
每个得到一个TLAID的机构可以有24位NLAID空间。NLAID空间使每个机构能
够为相当于目前IPv4Internet能够支持的总网络数几乎一样多的组织提供服务。
得到TLAID的机构，也支持他们自己站点ID空间中的NLAID。这就答应得到TLA
ID的机构，能给提供公用传送服务的机构提供服务，也能给不提供公用传送服务的机构提
供服务。得到NLAID的机构，也可以选择用他们的站点ID空间去支持其他的NLAID。
这种情况表示如下：
n24-n位1664位
+-----+--------------------+--------+-----------------+
NLA1站点IDSLAID接口ID
+-----+--------------------+--------+-----------------+
m24-n-m1664位
+-----+--------------+--------+-----------------+
NLA2站点IDSLAID接口ID
+-----+--------------+--------+-----------------+
o24-n-m-o1664位
+-----+--------+--------+-----------------+
NLA3站点IDSLAID接口ID
+-----+--------+--------+-----------------+
对一个特定的TLAID，设计NLAID位的安排，留给负责该TLAID的机构去做。同
样，设计下一级NLAID位的安排，由前面一级NLAID负责。在此建议分配NLA地址
空间的机构用类似于[RFC2050]中的“慢启动”分配过程。
设计NLAID分配计划，要在选路集聚效率和灵活性之间进行权衡。创建分级结构允
许较大集聚数，从而使得路由表较小。平面NLAID的分配能使分配轻易和连接灵活，但
使得路由表较大。
3.5站点级集聚标识符
SLAID字段被单个机构用来创建他自己的本地寻址分级结构与标识子网。除了每个机
构有一个数量很大的子网以外，类似于IPv4中的子网。16位的SLAID字段支持65535
个单个子网。
机构可以选择他们的SLAID为平面路由(如在SLA标识符之间不创建任何逻辑关系，
这会使得路由表较大)，或者在SLAID字段中，创建一个两级或多级分级结构(使路由表较
小)。后一种情况表示如下：
n16-n64位
+-----+------------+-------------------------------------+
SLA1子网接口ID
+-----+------------+-------------------------------------+
m16-n-m64位
+----+-------+-------------------------------------+
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位。可有8192个TLAID。选择这样的长度，可使In
ternet上顶级路由器的非默认路由表，能在当前的选路技术且合理地留有余量的情况下，
保持有限的范围。
因为非默认路由器为优化TLA内部路径和TLA之间的路径，还要含有大量的长的
前缀，所以保留余量是重要的。
重要的议题不仅是非默认选路表的长度问题，还有拓扑的复杂性决定了当计算一个转发
表时，路由器必须考察非默认路由的拷贝数。当前IPv4的实践是通常一个前缀要通过不
同的路径通告15次。
Internet拓扑的复杂性将来还可能增加。重要的是IPv6非默认选路应支持更大的
复杂性以及巨大的Internet。
应该提出的是，在写作本文时(1998年春)，作者作了一个比较，IPv4非默认路由
表包含大约50000个前缀，表示可能支持大于8192个的路由。现在争论的问题是在当前
的选路技术下，是否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
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
