IPv6通过ATM网络

备忘录：
本文档为整个因特网指定了一个标准跟踪协议，并为其改进展提供了一些讨论和建议。请参
考最新版的"Internet官方协议标准"(STD1)来获得本协议的标准化程度和状态。本备忘录的
传播不受任何限制。
版权声明：
Copyright(C)TheInternetSociety(1999).AllRightsReserved.
摘要：
本文档《Ipv6通过非广播多通路（NBMA）网络》是ION工作组的结构文档之一。它提供
了怎样应用Ipv6通过NBMA结构到异步传输模式（ATM）网络的具体资料。该结构答应常
规的Ipv6临近计算机发现协议的主机-分机操作，同时也支持已建立的短程ATM传送路径
以及通过行政治理配置的点到点PVC的操作。
目录
1.绪论 2
2.规范术语 3
3.PVC环境 3
3.1系统设定数据封装格式 3
3.2选择性空封装 3
3.3PPP封装 4
3.4PVC环境下MTU 4
3.5PVC环境下的接口令牌格式 4
4.SVC环境 4
4.1SVC非凡代码点 4
4.1.1SVC环境下的ATM适配层封装 4
4.1.2单点传送数据封装 4
4.1.3多点传送数据封装 5
4.1.4选择性空封装 5
4.1.5MARS控制信息 5
4.1.6NHRP控制信息 6
4.1.7临近计算机协议消息 6
4.2UNI3.0/3.1信号发布（SVC模式） 7
5.接口令牌 7
5.1基于ESI值的接口令牌 7
5.2基于48位MAC值的接口令牌 8
5.3基于EUI-64值的接口令牌 8
5.4基于当地E.164地址的接口令牌 8
5.5无唯一标识符节点 8
5.6单一接口的多逻辑链接 8
6.结论和公开发行 9
7.安全考虑 9
感谢： 9
作者联系方式： 9
参考书目： 10
FullCopyrightStatement 11
1.绪论
本文档《Ipv6通过NBMA网络》规范是ION工作组对ATM的具体说明文档。至于术语和
结构的描述这里将不再重复。
ATM可提供点到点的PVC服务，或者更加灵活的点到点和点到多点的SVC服务，本文档
涵盖了ATM的这些应用。
一个最低限度符合标准的Ipv6/ATM驱动应至少能支持PVC模式的操作。而一个Ipv6/ATM
驱动支持完全的SVC模式同时也将支持PVC模式的操作。
2.规范术语
本文档中，"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT","SHOULD",
"SHOULDNOT","RECOMMENDED","MAY",以及"OPTIONAL"等要害词的含义请参阅
RFC2119文档。
3.PVC环境
当ATM网络用于PVC模式时，每一条PVC将精确的连接两个节点且临近计算机发现和其
他的Ipv6的非凡功能将受到限制。Ipv6/ATM接口在每一条链路上只有一个邻居接口。既然
在一单一的ATM标准的操作中不能进行多点传送和广播操作，因而MARS和NHRP协议
不再必须。动态的发现的传送捷径不被支持。
接下来的章节提供关于封装，MTU和链接令牌产生的具体资料。
PVC链路的这种应用既不授权也不阻止在临近计算机发现协议中扩展名的使用，这可由
PVC连接中的任一普通使用而发现。
既然ATM网络中PVC链接不使用链路层的地址，那么任何的网络指导消息中都不能包含
链路层的地址操作。一旦在某一网络指导消息中出现链路层地址操作，那么该操作将被忽略。
一最低限度符合标准的Ipv6/ATM驱动将应至少能支持PVC模式操作。这种单一执行PVC
的结构并不要求支持任何的SVC模式操作。
3.1系统设定数据封装格式
下面内容可参考RFC1483文档[2]，AAL5为默认的适配层服务协议，（LLC/SNAP）封装为
系统设定的适用于通过点到点的PVC链路的数据的封装。如[1]中所定义，系统默认的Ipv6
的数据封装格式为：
[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6packet]
(LLC)(OUI)(PID)
3.2选择性空封装
Ipv6/ATM驱动有可能也支持空封装作为一项可配置操作。当空封装被激活，Ipv6数据直接
通过到ALL5层。PVC链路的两端应同时配置使用空封装。PVC不会被除Ipv6以外的其他
协议所用到。
3.3PPP封装
本规范文档不包含Ipv6通过PPP和PPP通过ALL5的虚拟电路的串联。
3.4PVC环境下MTU
默认的PVC链路的IPMTU长度为9180字节。具体说明参看[7]。其他的IPMTU值也可
能被应用。
3.5PVC环境下的接口令牌格式
当ATM网络用于PVC模式时，接口令牌应当用第5节中所记述的方法产生。在PVC链路
的两个节点之间接口令牌必须是唯一的。
4.SVC环境
4.1SVC非凡代码点
4.1.1SVC环境下的ATM适配层封装
下面可参考RFC1483原文。ALL5为默认的适配层服务协议，（LLC/SNAP）封装为系统设
定的适用于通过SVC链路的单点传送和多点传送数据的封装。
4.1.2单点传送数据封装
如[1]中所定义，默认的Ipv6单点传送数据封装为：
[0xAA-AA-03][0x00-00-00][0x86-DD][IPv6packet]
(LLC)(OUI)(PID)
4.1.3多点传送数据封装
如[1]中所定义，默认的Ipv6多点传送数据封装为：
[0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6packet]
(LLC)(OUI)(PID)(marsencaps)
IPv6/ATM驱动的群体成员ID需要记录在pkt$cmi段的2个8位字节优先传送。
4.1.4选择性空封装
IPv6/ATM驱动也可能支持空封装做为一项可配置操作。空封装只能被用作从一个IPv6/ATM
驱动传送IPv6包到另一个。空封装不能被用在在IPv6/ATM驱动和当地MARS之间的点到
点SVC操作。
假如空封装被激活，IPv6包直接被传送到AAL5层。在呼叫建立阶段，SVC的两端口必须
同意使用空封装。使用IPv6以外的协议SVC将不可利用。
假如在路由器之间的数据SVC中有空封装，则中间路由的NHRP通信必须利用一独立平行
的SVC。
当IPv6/ATM和MARS/NHRP/ND一起使用时（参见[1]），不鼓励使用空封装。
4.1.5MARS控制信息
MARS控制信息（在MARS和MARS客户端之间）的封装如RFC2022[3]中所示：
[0xAA-AA-03][0x00-00-5E][0x00-03][MARScontrolmessage]
(LLC)(OUI)(PID)
要害控制字段值如下：
mar$afn段保持为0x0F（ATM地址）
mar$pro段应为0x86DD（IPv6）
mar$op.version段保持为0x00（MARS）
mar$spln和mar$tpln段为0（空消息）或16（全IPv6协议地址）
ATM地址如何保存沿用了RFC2022[3]中的方法。
4.1.6NHRP控制信息
NHRP控制信息的封装如RFC2332[4]：
[0xAA-AA-03][0x00-00-5E][0x00-03][NHRPcontrolmessage]
(LLC)(OUI)(PID)
要害字段的值如下：
ar$afn段保持0x0F（ATM地址）
ar$pro段应为0x86DD（IPv6）
ar$op.version段保持0x01（NHRP）
ar$spln和ar$tpln段为0（空消息）或16（全IPv6协议地址）
ATM地址如何保存沿用了RFC2022[3]中的方法。
4.1.7临近计算机协议消息
[1]中5.2节描述了ND链路层地址选项。对于IPv6/ATM驱动，子字段需按如下方法编码：
[NTL]定义ATM数值的类型和长度，紧接为[STL]字段。格式如下：
76543210
+-+-+-+-+-+-+-+-+
0xlength
+-+-+-+-+-+-+-+-+
第一有效位保留并需至为零。第二有效位（x）是一个ATM数值是否在其中的标志：
ATM论坛AESA格式（x=0）.
本地的E.164格式（x=1）.
末端的6位为一无符号整数指出8位字节段中关联的ATM地址段的长度。
[STL]格式同[NTL]段。假如其存在，则定义子地址段的长度。假如其不存在则这个8位字
节段必须全为零。假如子地址存在则将为AESA格式，所以标记x应为零。
[NBMANumber]是一个包含面向链路层ATM地址的变长字段。它总是存在的。
[NBMASubaddress]是一个包含面向链路层ATM子地址的变长字段。它可能存在，也可能
不存在。当它不存在的时候，选项于[NBMANumber]（或者其他为填满8位队列的附加字
节）之后结束。
[NBMANumber]段和[NBMASubaddress]段中8位字节的顺序于它们用在MARS和NHRP
控制消息中时相同。
4.2UNI3.0/3.1信号发布（SVC模式）
当一个IPv6节点向另一个IPv6节点发出一条呼叫，必须遵循[6][7]中的程序。如[7]中所记
述，默认的LL算法上的IPMTU长度为9180字节。
注重：当[7]中的程序仍然应用到ATM上的IPv6时，节点和路由使用IPv6路径MTU发现
[8]胜于IPv4MTU发现。另外，当IPv6节点不需要实现路径MTU发现时，IPv6/ATM节点
将应实现它。所以，既然IPv6节点将为每一个VC协商一适当的MTU，当两节点没有接收
到过大的以至触发路径MTU发现的数据包时路径MTU将不被触发。当节点中的通讯通过
一个或多个路由时，路径MTU发现将按传统网络的方法来使用。
5.接口令牌
对于无论PVC或是SVC模式操作，按[1]中5.1节所要求的必须使用下列方法产生接口令牌。
5.1基于ESI值的接口令牌
当潜在的ATM接口被ATM末端系统地址（AESA）识别出时，接口令牌可能由AESA中的
ESI和SEL值构成。如下：
[0x00][ESI][SEL]
[0x00]是一个总设为0的8位字段。
注重：这个和EUI-64的全局/局部标志位相应的位总是置0表明这不地址不是一全局唯
一的IPv6接口令牌。
[ESI]是一6个8位字节字段。
该段总包含6个8位字节的ESI值，AESA以此寻IPv6/ATM的接口地址。
[SEL]为一个8位字节
该段总包含6个8位字节的SEL值，AESA以此寻IPv6/ATM的接口地址。
5.2基于48位MAC值的接口令牌
当潜在的ATMNIC驱动已读取一或多ATMNIC特有的48位MAC值，IPv6/ATM接口可
应用这些值建立一特定的接口令牌，如[10]中所述。
5.3基于EUI-64值的接口令牌
当潜在的ATMNIC驱动已读取一或多ATMNIC特有的64位EUI-64值，IPv6/ATM接口可
应用这些值，反置全局/局部标识符，建立一特定的接口令牌。
当EUI-64值用于IPv6接口令牌，从NIC读取的字节串中唯一答应改动为倒置全局/局部标
识位。
5.4基于当地E.164地址的接口令牌
当一接口应用当地E.164地址时，E.164值可用于产生接口令牌如下：
[D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]
[D14]：一单一的8位字节包含半8位字节表示最重要的E.164数位左移4位到8位字节中
最重要的4位。低四位必须置0。注重EUI-64全局/局部标识符置0表示这是一个全局特定
IPv6接口令牌。
[D13D12]：一单一的8位字节包含半8位字节表示次重要的E.164数位[D13]左移4位到8
位字节中最重要的4位，第三重要的半8字节在8位字节中最次要的4位中。
[D11D10]-[D1D0]：每一个均包含两个E.164数位的8位字节组，两个E.164数位中，其一
在最重要的4位字节中，另一在最次要的4位字节中。
5.5无唯一标识符节点
假如接口令牌的产生中没有用到MAC,EUI-64,AESA或E.164值，则接口令牌的产生必须按
照[10]中附录A所述。
5.6单一接口的多逻辑链接
一个单一的ATM接口可能于一个普通AESA前缀中的不同SEL段相关联，或者一组完全独
立的ESI可能被当地ATM注册用于交换建立特定AESA域。
识别每一个逻辑ATM接口至少须知它们的ESI+SEL组合。
如[1]中5.1.2节对虚拟主机的描述，虚拟主机需要从64位数值队列中选择一个可应用到ATM
NIC的不同的接口令牌。每一台虚拟主机必须实现IPv6/ATM接口按下面的方式：不可存在
两台或两台以上的虚拟主机向同一LL终止通告同一接口令牌。（为了顺应这一要求，可选
择不同的SEL值或（和）ESI值。）
6.结论和公开发行
本文档《Ipv6通过NBMA网络》规范是ION工作组对ATM的具体说明文档。它具体说明
了定态配置PVC和动态制订SVC操作模式的码点。
Therearenomajoropenissues.CommentstotheIONmailinglistaresolicited(ion@nexen.com).
7.安全考虑
本提议不引入任何新的安全机制，故所有当前的IPv6安全机构的运行无需针对ATM加以修
正。这包含临近计算机发现协议的确认和加密，如IPv6数据包的交换。
感谢：
最初的IPv6/ATM著作由G.Armitage在受雇于Bellcore期间完成。第四节借鉴了MAtt
Crawford的备忘录《IPv6通过以太网》。
这里作者要对KazuhikoYamamoto,KenjiroCho,YoshinobuInoue,HiroshiEsaki,Yoshifumi
Atarashi,AtsushiHagiwara等对实际PVC实现所做出的贡献表示感谢。
作者联系方式：
GrenvilleArmitage
BellLaboratories,LUCentTechnologies
101CrawfordsCornerRoad
Holmdel,NJ07733
USA
EMail:gja@lucent.com

PeterSchulter
BrightTigerTechnologies
125NagogPark
Acton,MA01720
EMail:paschulter@acm.org

MarkusJork
EuropeanAppliedResearchCenter
DigitalEquipmentGmbH
CECKarlsruhe
Vincenz-Priessnitz-Str.1
D-76131Karlsruhe
Germany
EMail:jork@kar.dec.com
参考书目：
[1]Armitage,G.,Schulter,P.,Jork,M.andG.Harter,"IPv6over
Non-BroadcastMultipleAccess(NBMA)networks",RFC2491,January
1999.
[2]Heinanen,J.,"MultiprotocolEncapsulationoverATMAdaption
Layer5",RFC1483,July1993.
[3]Armitage,G.,"SupportforMulticastoverUNI3.1basedATM
Networks",RFC2022,November1996.
[4]Luciani,J.,Katz,D.,Piscitello,D.,Cole,B.andN.Doraswamy,
"NBMANextHopResolutionProtocol(NHRP)",RFC2332,April1998.
[5]"64-BitGlobalIdentifierFormatTutorial",
http://standards.ieee.org/db/oui/tutorials/EUI64.Html.
[6]Perez,M.,Liaw,F.,Mankin,A.,Hoffman,E.,Grossman,D.andA.
Malis,"ATMSignallingSupportforIPoverATM",RFC1755,
February1995.
[7]Atkinson,R.,"DefaultIPMTUforuseoverATMAAL5",RFC1626,
May1994.
[8]McCann,J.,Deering,S.andJ.Mogul,"PathMTUDiscoveryforIP
version6",RFC1981,August1996.
[9]ATMForum,"ATMUserNetworkInterface(UNI)Specification
Version3.1",ISBN0-13-393828-X,PrenticeHall,Englewood
Cliffs,NJ,June1995.
[10]Hinden,B.andS.Deering,"IPVersion6Addressing
Architecture",RFC2373,July1998.
[11]Narten,T.,Nordmark,E.andW.Simpson,"NeighborDiscoveryfor
IPVersion6(IPv6)",RFC2461,December1998.
FullCopyrightStatement
Copyright(C)TheInternetSociety(1999).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.