YD/T 2415-2012.Technical requirements of multihoming shim protocol for IPv6.
1范围
YD/T 2415规定了基于shim6的IPv6站点多归属的技术要求,规定了shim6的特征，设计目标和操作原理,包括消息格式，协议处理规则，以及如何在两个通信节点间检测到失败，同时还规定了一个探测协议。如果一个失败发生了且能找到另一对可操作的接口和(或)地址，使用该探测协议可用于选择相同的节点之间的另一对可操作的接口和(或)地址。
YD/T 2415适用于支持IPv6站点多归属协议的主机和网络设备。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
IETF RFC3972加密生成地址 (Cryptographically Generated Addresses)
IETF RFC3484 IPv6地址缺省选择方法(Default Address Selection for Intermet Protocol version 6)
IETF RFC4086用于安全的随机性需求 (Randomness Requirements for Security)
IETF RFC4218 IPv6多归属方案面对的威胁(Threats Relating to IPv6 Multihoming Solutions)
IETF RFC4861 IPv6邻居 协议(Neighbor Discovery for IP version 6)
IETF RFC4862 IPv5无状态地址 自动配置(IPv6 Stateless Address Autoconfiguration)
IETF RFC5535哈希基地址(Hash-Based Addresses)
3术语、定义和缩略语:
下列术语、定义和缩略语适用于本文件。
3.1. 术语和定义

ICS35.100.30
中华人民共和国通信行业标准
YD/T2415-2012
基于shim6的IPv6站点多归属技术要求Technical requirements of multihoming shim protocol for IPv62012-12-28发布
2013-03-01实施
中华人民共和国工业和信息化部发布前言·
1范围
2规范性引用文件
3术语、定义和缩略语
3.1术语和定义
3.2缩略语·
shim6协议综述·
概述·
4.2shim子层的位置
4.3总体操作
4.4上下文标签
4.5上下文分叉
4.6API扩展.
shim6安全
4.8shim控制报文的概述..
4.9扩展头顺序
5报文格式
5.1概述：
5.2共同的shim6报文格式…
5.3shim6净荷扩展头格式
5.4共同的shim6控制头.
5.511报文格式.
5.6R1报文格式-
5.7I2报文格式.·
5.8R2报文格式..
5.9R1bis报文格式..·
I2bis报文格式
更新请求报文格式
更新确认报文格式
保活（Keepalive）报文格式
探测（Probe）报文格式·
出错报文格式·
选项格式·
建筑321---标准查询下载网
YD/T2415-2012
YD/T2415-2012
6台主机的概念模型
6.1概述
6.2概念数据结构·
6.3上下文的状态机状态
建立ULID对的上下文.
概述·
上下文标签的惟一性
定位符验证
普通上下文的建立
同时的上下文建立
上下文恢复
上下文的混淆
发送11消息
重传11消息
接收1消息
发送R1消息·
接收R1消息和发送I2消息·
重传2消息
接收I2消息
发送R2消息·
对上下文混淆的匹配·
接收R2消息·
发送R1bis消息·
7.19接收R1bis消息和发送I2bis消息·7.20重传I2bis消息
接收I2bis消息和发送R2消息..
处理ICMP出错消息
9ULID对上下文的拆除.·
更新对端
发送更新请求消息.
10.3重传更新请求消息
当重传时出现更加新的信息
接收更新请求消息·
10.6接收更新请求确认消息·
发送ULP净荷
概述·
11.2在一次交换后发送ULP净荷
接收分组
12.1概述
12.2接收没有扩展头的净荷
12.3接收shim6净荷扩展头：
12.4接收shim控制消息
12.5上下文查找
13初始联系
失败检测以及定位符探测
14.1概述
14.2失败检测以及定位符探测协议概览14.3协议行为
15‘协议常量
16其他地方的影响
16.1拥塞控制考虑
16.2中间设备(Middle-Boxes)考虑16.3操作和管理考虑…·
16.4其他方面的考虑
16.5失败检测以及定位符探测的操作考虑17安全考虑…
17.2与IPSec交互·
17.3其他的威胁·
17.4失败检测以及定位符探测安全考虑·18IANA考虑
参考文献
建筑321---标准查询下载网
YD/T2415-2012
YD/T2415-2012
本标准按照按照GB/T1.1—2009给出的规则起草。本标准技术内容与IETFRFC5533（shim6:Level3MultihomingShimProtocolforIPv6）和IETFRFC5534（FailureDetection andLocatorPairExplorationProtocolforIPv6Multihoming）保持-致，对应关系如下：
一第3章术语分别来自IETFRFC55332.1和IETFRFC55343；一第4章中，4.2对应于IETFRFC55331.6，4.3对应于IETFRFC55334，4.4～4.9分别对应于IETFRFC55334.1~4.6;
一第5章对应于IETFRFC55335，其中5.13和5.14分别增加了IETFRFC55345.1和5.2的内容，5.16i中增加IETFRFC55345.3的内容作为5.16.9；-第6章～第13章对应于IETFRFC55336～13：一第14章中，14,1对应于IETFRFC55341，14.2对应于IETFRFC55344，14.3对应于IETFRFC55346；-第15章对应于IETFRFC553314，增加了IETFRFC55347的内容：一第16章对应于IETFRFC553315，增加了IETFRFC55349作为16.5：第17章对应于IETFRFC553316，增加了IETFRFC55348作为17.4；一第18章对应于IETFRFC553317。本标准由中国通信标准化协会提出并归口。本标准起草单位：华为技术有限公司、工业和信息化部电信研究院、清华大学。本标准起草人：崔勇、董江、郭大勇。IV
1范围
基于shim6的IPv6站点多归属技术要求YD/T2415-2012
本标准规定了基于shim6的IPv6站点多归属的技术要求，规定了shim6的特征，设计目标和操作原理，包括消息格式，协议处理规则，以及如何在两个通信节点间检测到失败，同时还规定了一个探测协议。如果一个失败发生了且能找到另一对可操作的接口和（或）地址，使用该探测协议可用于选择相同的节：点之间的另一对可操作的接口和（或）地址。本标准适用于支持IPv6站点多归属协议的主机和网络设备。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。IETFRFC3972加密生成地址（CryptographicallyGenerated Addresses）IETFRFC3484IPv6地址缺省选择方法（DefaultAddressSelectionforInternetProtocolversion6）IETFRFC4086用于安全的随机性需求（RandomnessRequirementsforSecurity）IETFRFC4218IPv6多归属方案面对的威胁（ThreatsRelatingtoIPv6MultihomingSolutions）IETFRFC4861IPv6邻居协议（NeighborDiscoveryforIPversion6）IETFRFC4862IPv5无状态地址自动配置（IPv6StatelessAddressAutoconfiguration）IETFRFC5535哈希基地址（Hash-BasedAddresses）3术语、定义和缩略语
下列术语、定义和缩略语适用于本文件。3.1·术语和定义
上层协议Upper-LayerProtocol
在IP层之上的协议。传输层协议，例如TCP和UDP；控制协议，例如ICMP；路由协议，例如OSPF：还有通过IP进行“隧道”（即封装）的网络层或低层协议，比如网络分组交换(IPX)，AppleTalk，或IP它本身。
接口Interface
一个节点对一个链接的连接处。3.1.3
地址Address
一个IP层的名字，既包含了拓扑的含义，又表示为对一个接口的惟一标识符。长度为128bits。本标准仅在既不表示定位符又不表示标识符的时候使用“地址”这一术语。1
建筑321--—标准查询下载网
YD/T2415-2012
定位符Locator
一个IP层的一个接口或一组接口的拓扑名字。长为128bits。数据包穿越网络时定位符装载于IP的地址字段。
标识符Identifier
IP层端点提供的一个IP层的名字。传输端点名字是传输协议的功能，并且其应包括IP标识符加上一个端口号。
注：本标准并没有定义一个新的格式的P层标识符，而是仍把P地址的标识和定位两重语义进行分离。3.1.6
上层标识符Upper-Layerldentifier被上层协议所使用，用作与对端进行通信，实际上是一个IP地址。长为128bits。ULID是用于伪头部校验和的计算以及ULP中连接的标识。为了确保负载扩展，对同一主机的不同通信（例如，不同的连接）或许要使用不同的ULID。
由于ULID只是节点的IP定位符/地址中的一个，故不必一个独立的命名空间和分配机制。3.1.7
地址域AddressField
在IPv6头部中的源和目的地址域。如目前IPv6中所定义的，这些域中装载着“地址”。如果标识符和定位符分离开了，对于在网络中的分组这些域将包含定位符。3.1.8
域名全称FullyQualifiedDomainName主机的域名全称。
ULID对上下文ULID-PairContext由多归属shim在一对上层标识符之间维护的状态。该上下文由以下几部分定义：一个用于通信双方的上下文标签(contexttag)，一个ULID对，以及一个分叉实例标识符(forked instanceidentifier)，具体含义在下面有描述。
上下文标签ContextTag
上下文的每个端点都会为该上下文分配一个上下文标签。这是用于惟一关联收到的控制分组以及属于该上下文的shim6净荷扩展头。3.1.11
当前定位符对CurrentLocatorPair上下文的每个端点都有一个当前定位符对，用于向对端发送分组。但两个端点可能使用不同的当前定位符对。
默认上下文 Default Context
YD/T2415-2012
在发送端，shim使用ULID对（由ULP传下来的）来查找该对的上下文。因此一般情况下，一个主机的一个ULID对最多能有一个上下文，称之为“默认上下文”。3.1.13
上下文分叉ContextForking
一种机制，使得那些知道有多个定位符的ULPs来对同一ULID对使用不同的上下文，这样就使得相同的ULID可以对不同的通信使用不同的定位符对。上下文分又使得同一ULID对产生的不仅是默认上下文。
分叉实例标识符ForkedInstanceIdentifier为了能够处理上下文分叉的情况，一个上下文由一个ULID对和一个分叉的上下文标识符来定义。默认的上下文FI值为0。
初始联系InitialContact
当ULP决定通过发送和接收ULP分组来与对端发起通信时，用来描述shim之前的通信。通常，这不会引起shim中的操作，因为shim能够延迟上下文的建立，直到一些任意的、靠后的机会出现。3.1.16
基于哈希的地址Hash-BasedAddressesIETFRFC5535定义的一种IPv6格式的地址，其接口ID是来自所有分配到主机的前缀的加密哈希。3.1.17
加密生成地址CryptographicallyGeneratedAddressesIETFRFC3972定义的一种IPv6格式的地址，其接口ID是来自公有键的加密哈希。3.1.18
CGA参数数据结构CGAParameterDataStructure一种CGA和HBA交互的消息，为了通知对端接口ID是如何计算的。（参见[2]和[3]）。3.1.19
可用的地址AvailableAddresses如果下面所有条件都满足了则称一个地址为可用的：该地址已经分配给该节点的一个接口；一分配给该地址的前缀的有效生存时间还没有过期。注：有效生存时间参见IETFRFC4861的第4.6.2小节[27]。在IETFRFC4862中该地址是不确定的。换句话说，该地址分配完成后通信能够开始。注：按最佳化重复地址侦测(DAD）（参见[26]）的观点，这明确的使得一个地址成为最优，尽管只要有替代者，执行可能更喜欢使用其他地址。
该地址是一个全球单播或惟一的本地地址（参见[13]）。即它不是一个IPv6站点本地或链路本地地址。
根据链路本地地址，该节点不能确定所给的地址在哪个链路有用。该地址和接口是否允许使用由主管部门的政策决定。3
建筑321---标准查询下载网
YD/T2415-2012
对可用地址的发现和监管的机制已经超出了shim6的范围。shim6的执行一定要能够使用IPv6邻居发现（参见[27]）、地址自动配置（参见[28]）以及DHCP（参见[25]）（当应用了DHCP）所提供的信息。这些信息包括新地址的可达性以及存在的地址的状态改变（例如当一个地址变得无效）。3.1.20
本地的可使用地址LocallyOperationalAddresses当一个可用地址的用处被认为可能是本地的则被称作本地可用地址。换句话说，当接口启用，适合这个地址的一个默认路由（如果需要）是可达的，且对该地址没有其他的信息点成为无用的。对本地可用地址的发现和监管的机制超出了shim6协议的范围。shim6的执行一定要能够使用IPv6邻居发现（参见[27]）所提供的信息。一些执行也可能使用附加的、链路层的特定机制。注1：在确定一个地址是可用的这一问题中，有一部分是确保在经过了链路层连接性改变，我们仍能链接到相同的IP子网。类如[32]的机制可用作确保这一点。注2：理论上说，如果存在合适的协议，节点也有可能知道对一个特定的源前缀的路由失败。已经制定了在这方面的一些协议（例如[29]和[34]），但都还没成为标准。3.1.21
可用地址对OperationalAddressPairs一对本地可用地址被称为单向可用地址对，当分组使用第一个地址作为源地址而使用第二个地址作为目的地址来发送到目的端。
shim6的执行必须支持通过使用确切可达性测试和强制双向通信（FBD）来发现可用地址对，这将在本标准的后面描述。shim6的未来的扩展可能定义其他的机制。这种机制的一些观点如下，但没有在本标准中完全描述：
一来自上层协议主动反馈。例如，TCP能告诉P层它正在取得进展。在某些情况下，这和当上层提供双向连接（参见[27]）的信息时能避免IPv6邻居不可达探测是相似的。在单向连接的情况下，该上层协议使用另一个地址对返回回应，但表明该发送的报文使用的是收到的第一个地址对。一来自上层协议的被动反馈。可以想象上层协议提供了对多归属层问题的一个说明。例如，TCF可说明在路劲中有阻塞或缺乏连接因为它没有得到ACK。一ICMP出错报文。鉴于欺骗ICMP报文的缓解，但应当注意不要盲目相信这些。一种方法是使用ICMP出错报文仅作为一个示意，用于示意实行一个确切的可达性测试或把一个地址对移到要被探测的地址对表的较低位置，但不要在没有问题指示时使用这些报文打断正在进行的通信。注：当这一ICMP报文验证在实行时情形可能不一样，如Gont在[33]所解释的。这些验证能确保（几乎）只有路径耦合攻击者可以伪造该报文。
主地址对PrimaryAddressPair
主地址对是由上层协议使用shim6层交互时使用的地址组成的。使用主地址对意味着该通信和常规的非shim6的通信是兼容的，且不需要上下文标签在。3.1.23
当前地址对CurrentAddressPair4
YD/T2415-2012
shim6需要避免在多路径上同时发送属于相同传输连接的分组。这是因为传输协议一般使用的拥塞控制是基于单路径的概念的。尽管路由也可以引进路径的变化以及传输协议有方法来处理这些，但频繁的变化会引起问题。
注1：IETFRFC5533发布时，在多路径上的有效拥塞控制仍是一个研究话题。shim6并没有试着去同时使用多路径。注2：流控制传输协议(SCTP)以及未来的多路径传输协议有可能需要与shim6交互，最少要确保它们不会出乎意料的使用shim6。
由于这些原因，有必要选择一个特定的地址对作为当前地址对，一直要用到出现问题，至少在同一段上。
理论上为不同的传输段或shim6上下文支持多个当前地址对是可能的。但本标准尚不支持。注：当前地址对不需要在任何时候都可操作。如果没有流发送，我们可能不知道当前的地址对是否可操作。不过假设先前工作的地址对也能为新通信继续可操作是有意义的。3.2缩略语
下列缩略语适用于本文件：
4shim6协议综述
4.1概述
Cryptographically Generated AddressesFullyQualifiedDomainName
ForkedInstanceIdentifier
Hash-Based Addresses
Parameter Data Structure
Upper-LayerIdentifier
Upper-Layer Protocol
加密生成地址
域名全称
分叉实例标识符
基于哈希的地址
参数数据结构
上层标识符
上层协议
本标准定义了shim6协议，该协议是在第三层插入了一个shim子层，这样IPv6便可使用多归属技术，使之具有故障切换和负载均衡的特性（参见[10]），而不用考虑多归属的站点是否有一个在全球IPv6路由表里申明的IPv6 PI地址前缀。在站点中的主机若拥有多个IPv6PA地址前缀则可以使用在本标准中定义的shim6协议来与对端主机建立状态，该状态可以在前一定位符对失效的时候来切换到另一对不同的定位符对上从而达到故障切换的目的。shim6协议是一个站点级的多归属解决方案，即它允许一个有多连接连接到Internet的站点，在其中某些连接中断的情况下，仍能保持已经存在的通信不中断。但是shim6的处理是在主机端来实现的，而不是在整个站点范围内的机制上。4.2shim子层的位置此内容来自标准下载网
本标准是在IP层中添加了多归属的shim子层，即在ULPs之下以使ULP具有独立性，如图1所示。多归属的shim子层的行为像是和扩展头相关，这个扩展头可以放置在分组中任意的与路由相关的头部之后（例如逐跳选项）。但是当定位符对就是ULID对的时候，在扩展头中没有需要装载的数据，此时为空。让分片报头在多归属shim层之上使得重组更为健壮，因为会有打破的多路径路由会导致使用不同的路径，因此有可能不同的源定位符会用于不同的分片。因此多归属的shim子层放置在IP端系统层（负责分片和重组）和P路由子层（选择下一跳和接口，用于发送数据包）之间。5
建筑321-—标准查询下载网
YD/T2415-2012
传输层协议
IP端系统子层
shim子层
IP\路由子层
图1协议栈
应用和上层协议使用由shim6子层提供的由不同定位符映射而来的ULIDs。shim6子层维护着一种状态，称之为ULID对的上下文，每一ULID对（即这种状态应用于所有的ULID对的ULID连接）都要执行这种映射。该映射持续的作用在发送方和接收方，这样ULPs所见的分组好像是通过ULIDs来进行端到端的发送的。即使分组传输会通过在IP地址域包含定位符的网络，即使那些定位符或许会被传送shim6子层改动，这一特性也会得到维持。这一上下文环境状态在每一远端ULID上得以维护，即在每一个对端主机上，而不是在任何更细的粒度上。特别地，该上下文环境状态独立于ULPs以及任何ULP的连接。但这一分叉的能力可使得知道shim6的ULPs对一个ULID对一次使用不止一个定位符对。如图2所示的持续映射的结果使它对ULPs没有任何影响。特别地，它对伪头部校验和以及连接标识都没有影响。
发送端A
sre ULID(A)-LI(A)
dst ULID(B)-L1(B)
多归属shim
SreL2(A)
dstL3(B)
路由器云
图2使用改变的定位符来映射
接收端B
srec ULID(A)-L1(A)
dstULID(B)-L1(B)
多归属shim
Sre L2(A)
dst L3(B)
从概念上讲，可以认为这种方法好像使ULIDs和定位符在每一数据包中都存在，就好像一个头部压缩机制的应用，这使得一且压缩状态建立好了，就不需要在分组中载入ULIDs了。为了使接收者重新创建一个具有正确ULIDs的分组，有必要在数据包中包含一些“压缩标记”。这有助于在分组中的定位符对不足以惟一确定上下文时，指明使用正确的上下文来进行解压缩。在shim6层和其他的协议之间会有各种不同类型的交互。那些交互会被这些方面影响：在其他的协议中使用这些地址，以及shim6对这些使用的映射的影响。注：[18]中详细分析了不同协议间的交互，包括流控制传输协议（SCTP），移动IP（MIP），和主机标识协议（HIP）。此外，一些应用程序可能需要与shim6子层更为丰富的互动。为了达到这一要求，已定义了一个API（参见[22]）来允许更多的控制和信息交互，以用于那些需要它的应用。4.3总体操作
shim6协议可以在几个情况下运行，下面进行说明：6
YD/T2415-2012
—主机A上的一个应用程序想要通过一些上层协议来与主机B上的应用通信。这导致了主机A上的ULP向主机B发送分组。我们称之为初始联系。假设IP地址是由默认地址选择（参见[6]）以及它的扩展（参见[8]）来决定的，在这个时候shim还不会有任何动作。Shim的上下文建立能够被延退到晚些再开始。
一些在A或B（或两者）上的启发动作会决定开支shim6的代价是否值得，使用shim6会使得主机到主机的通信健壮而不会出现定位符失败。例如，这种启发可能是超过了50个的分组收发，或是当激发分组交换时计时器超时。这就会导致shim的初始的4次上下文建立交互。该启发是为了避免当只有很少的分组在两台主机间交换时还进行shim的上下文建立。作为该交互的结果，A和B双方都会知道一个对端定位符的列表。如果上下文建立交互失败，发起端就会知道对端不支持shim6，并且会继续使用标准的（非shim6的）规范。
一一对上层协议的分组来说，通信在没有任何改变中继续。特别地，上层协议的分组中不会加入shim6的扩展头，因为上层标识符对和定位符对是相同的。另外，可能会在shim子层之间为了（不）可达探测而进行消息的交互。
一一在某些时刻，可能会出现一些失败。取决于可达性检测的方法，可能会有一些来自上层协议的建议，或者是shim的（不）可达性检测可能会发现存在一些问题。在这个时候，通信的一方或双方需要探测不同的可替代的定位符对，直到找到一对，然后选择使用那个定位符对。一旦找到了一对可替代的定位符对，shim将重写发送的分组，并使用shim6净荷扩展头来标记该分组，在其中包含了接收方的上下文标记。接收者将使用该上下文标记来找到上下文状态，它会在分组传送给ULP之前指明将哪个地址填入IPv6头。结果就是，尽管IP的路由体系结构使用的是不同的定位符来发送的，从ULP的角度来看，分组端到端传送没有发生修改。一Shim的（不）可达性探测将会像监管初始的定位符对一样去监管新的定位符对，这样随后发生的失败将会被检测到。
除了基于端到端观测的失败检测外，个端点仍可能知道一个或多个它的定位符无法工作。例如，网络接口可能已经失效（在第二层），或是一个IPv6地址或许已经被弃用。在这些情况下，主机能够告知对端尝试这些地址是没有意义的。这引发了一些与错误处理相似的东西，并且必须要找到新的可用的定位符对。该协议也能够表述其他形式的定位符的优先符。在任意优先符中的改变都能够告知对方，这将使对端记住新的优先符。在优先符中的改变或许会随意的使得对端想要使用一个不同的定位符对。在这种情况下，对端在一次失败后遵守相同的定位符选择规程（例如通过验证使用替代的定位符使得它的对端确实还可达）。
一当shim认为该上下文状态不再会使用时，它便会对该状态进行垃圾回收；状态回收之前没有必要与对端主机进行协调。当已没有该上下文状态时，会有一个已定义的恢复消息用于标识，这可用于发现和恢复过早的垃圾回收，以及发现和恢复对端的状态丢失（由于碰撞或重启）。注：shim6中ULP的分组能够完全不作修改的被装载，只要ULID对仍是定位符对。当选择了不同的定位符对时，该分组就会通过shim6扩展头来“加标签”，这样接收者仍能够决定该上下文属于谁。这是在（扩展）头被端点子层和ULPs处理之前，由包含8byte的shim6扩展头来完成的。如果过了一段时间初始的ULIDs又被选为有效的定位符对，通过shim6的扩展头来标记分组就没有必要了。7
建筑321---标准查询下载网
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。