本备忘录的状态
本文档讲述了一种Internet社区的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
子网任意传送地址结构如下：
64bits57bits7bits
+---------------------------------+------------------+------------+
子网前缀1111110111...111anycastID
+---------------------------------+------------------+------------+
接口标识符
对于其它的IPv6地址类型（也就是，前缀跟上面列出不同的地址），接口标识符长度不
是EUI-64格式，长度也可能不是64位；这些地址类型保留的任意传送地址结构如下：
n位121-n位7位
+---------------------------------+------------------+------------+
子网前缀1111111...111111anycastID
+---------------------------------+------------------+------------+
接口标识符
这里的子网前缀包含除了接口标识符意外的所有字段。保留的子网内任意传送地址中的
接口标识符由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位的接口标识符。格式如下：
01133446
05612783
+----------------+----------------+----------------+----------------+
1111110111111111111111111111111111111111111111111111111111111110
+----------------+----------------+----------------+----------------+
^^^^^^^^
+---全体/本地位任意传送标识号---+-----+
其它的IPv6地址类型，接口标识符长度可能不是64字节而且也不是EUI-64格式。在
这个例子中，假定接口标识符的长度为64位，使得与上面的比较能够清除一些（虽然长度
不是64字节的也是同样的结构）。这样保留的移动IPv6家乡代理子网任意传送地址包含64
位的子网前缀，然后是64位的接口标识符。格式如下：
01133446
05612783
+----------------+----------------+----------------+----------------+
1111111111111111111111111111111111111111111111111111111111111110
+----------------+----------------+----------------+----------------+
^^^^^^^
任意传送标识号---+-----+


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
InternetSocietyoritssuccessorsorassigns.

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