YD/T 2934-2015
基本信息
标准号： YD/T 2934-2015
中文名称：端口控制协议(PCP)技术要求
标准类别：通信行业标准(YD)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：12361820
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YD/T 2934-2015.Technical specification for port control protocol (PCP).
1范围
YD/T 2934规定了端口控制协议的技术要求，包括端口控制协议的概述、原理和安全考虑等。
YD/T 2934适用于使用网络地址翻译(NAT) 的应用场景。
2缩略语
下列缩略语适用于本文件。
B4 Basic Bridging BroadBand 基本桥接宽带功能单元
CPE customer premises equipment 用户驻地设备
CGN Carrier-Grade NAT 运营级NAT
DS-Lite Dual-Stack Lite 轻型双栈方案
EDF Endpoint-Dependent Filter 端点相关过滤
3概述
3.1场景描述
端口控制协议(PCP)提供了-种NATs和防火墙上动态创建映射条目从而转发入向包的机制，PCP协议是和地址族无关的协议。它是NAT-PMT的扩展，可以满足IPv6 和大规模网络地址转换(large-scale NAT)的需要。PCP协议可以应用在NATs (NAT44/NAT444/NAT64/CGN) 设备和防火墙上。
图1所示是DS-lite CGN中的一种应用场景。
4 PCP原理和处理流程
4.1 PCP原理
PCP是一种基于UDP的请求/响应(RequestResponse)类的协议，但是不是严格的一个请求紧跟着一个响应的格式。例如，PCP Client发出的请求流可能因为包丢失等原因没有触发响应流; PCPServer发出的响应流可能因为Server配置修改主动发送响应流,而非响应之前的请求流。所以，PCP协议是两种相反方向上的相对独立的消息流。
1范围
YD/T 2934规定了端口控制协议的技术要求，包括端口控制协议的概述、原理和安全考虑等。
YD/T 2934适用于使用网络地址翻译(NAT) 的应用场景。
2缩略语
下列缩略语适用于本文件。
B4 Basic Bridging BroadBand 基本桥接宽带功能单元
CPE customer premises equipment 用户驻地设备
CGN Carrier-Grade NAT 运营级NAT
DS-Lite Dual-Stack Lite 轻型双栈方案
EDF Endpoint-Dependent Filter 端点相关过滤
3概述
3.1场景描述
端口控制协议(PCP)提供了-种NATs和防火墙上动态创建映射条目从而转发入向包的机制，PCP协议是和地址族无关的协议。它是NAT-PMT的扩展，可以满足IPv6 和大规模网络地址转换(large-scale NAT)的需要。PCP协议可以应用在NATs (NAT44/NAT444/NAT64/CGN) 设备和防火墙上。
图1所示是DS-lite CGN中的一种应用场景。
4 PCP原理和处理流程
4.1 PCP原理
PCP是一种基于UDP的请求/响应(RequestResponse)类的协议，但是不是严格的一个请求紧跟着一个响应的格式。例如，PCP Client发出的请求流可能因为包丢失等原因没有触发响应流; PCPServer发出的响应流可能因为Server配置修改主动发送响应流,而非响应之前的请求流。所以，PCP协议是两种相反方向上的相对独立的消息流。
标准图片预览
标准内容
ICS33.040.40
中华人民共和国通信行业标准
YD/T2934-2015
端口控制协议（PCP）技术要求
Technical specification for port control protocol (PCP)2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前
范围·
缩略语·
3概述
3.1场景概述·
3.2PCPServer和NAT/防火墙之间的关系..4PCP原理和处理流程
4.1PCP原理·
4.2通用Request和Response消息头结构.4.3PCP处理流程·
4.4版本协商
4.5MAP和PEEROpcodes介绍
4.6MAPOpcode操作码.
4.7PEEROpcode
4.8MAPOpcode和PEEROpcode的选项options*5安全考忠·
概述·
简单威胁模型
高级威胁模型
YD/T2934-2015
YD/T2934-2015
本标准按照GB/T1.1-2009规则起草。前言
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任，本标准由中国通信标准化协会提出并归口。标准起草单位：中国电信集团公司、中兴通讯股份有限公司。标准主要起草人：孙琼、孟伟、王翠。1范围
端口控制协议（PCP）技术要求
YD/T2934-2015
本标准规定了端口控制协议的技术要求，包括端口控制协议的概述、原理和安全考虑等。本标准适用于使用网络地址翻译（NAT）的应用场景。2缩略语
下列缩略语适用于本文件。
DS-Lite
NAT-PMT
NAT444
3概述
3.1场景描述
Basic Bridging BroadBand
customerpremisesequipment
Carrier-Grade NAT
Dual-Stack Lite
Endpoint-Dependent Filter
Endpoint-Dependent Mapping
Endpoint-IndependentFilter
Endpoint-Independent MappingNetworkAddressTranslation
NATPath MTU
NATIPv4 to IPv4
Carrier NAT
NATIPv6toIPv4
PeertoPeer
Port Control Protocal
基本桥接宽带功能单元
用户驻地设备
运营级NAT
轻型双栈方案
端点相关过滤
端点相关映射
端点无关过滤
端点无关映射
网络地址翻译
NAT映射表
网络地址翻译IPv4到IPv4
运营级NAT
网络地址翻译IPv6到IPv4
点对点
端口控制协议
端口控制协议（PCP）提供了一种NATs和防火墙上动态创建映射条目从而转发入向包的机制，PCP协议是和地址族无关的协议。它是NAT-PMT的扩展，可以满足IPv6和大规模网络地址转换（large-ScaleNAT）的需要。PCP协议可以应用在NATs（NAT44/NAT444/NAT64/CGN）设备和防火墙上。
图1所示是DS-liteCGN中的一种应用场景。YD/T2934-2015
4In6Tunnel
DS-Lite CGN
IPv4网络
INTERNALIPINTERNAI.PORT EXTERNALIPEXTERNALPROT
153.1.1.1
图1DS-liteCGN中的应用场景
服务器10.1.1.2位于一个内网中，外部用户如果访问该服务器不能使用私网地址访问。在CGN设备设置一个内部地址、端口和外部地址、端口的映射表，把外部地址和外部端口提供给外部用户，则用户可以通过提供的外部地址和外部端口访问位于内网中的服务器。通常，这个映射表是通过手动配置的方式创建，PCP协议则提供了种动态创建映射表的机制。服务器或者CPE作为PCP客户端（PCPclient），CGN作为PCP服务器端（PCPserVer），PCPclient向PCPserver发送请求消息去创建、重建或者删除PCP映射，PCPserver向PCPclient发送响应消息返回PCPserver上生成的映射或者失败消息。图2所示为PCP创建、更新、删除过程。PCPelient
PCPclient
PCPclient
Requcst (create)
response (mapping/error)
Request (recreate)
esponse(mapping/error)
Request (delete)
esponse (mapping/error)
PCPserver
PCPserver
PCPserver
图2PCP创建，更新、删除过程
PCP除了上述场景外，基于PCPclient和sever的交互过程，通过PCP的扩展，还有着非常广泛的应用场景。
YD/T2934-2015
在NAT应用中，B4或CGN设备可以通过PCP扩展消息来向外部地址资源服务器获取和回收释放公网地址或端口，用于进行公网地址和端口的转换。外部地址资源服务器（即PCP服务器端）对该请求消息做出响应，对地址或端口进行分配或回收。例如在轻量级4over6技术中，B4设备进行NAT转换并进行会话的维护，B4作为PCP客户端，并通过PCP的MAPREQUEST报文向PCP服务器获取公网地址和端口范围等信息。在NAT64应用中，当IPv6主机需要获取IPv6前缀来合成远端IPv4主机所转换的IPv6地址时，IPv6主机作为PCP客户端，NAT设备作为服务器，通过PCP的MAPREQUEST报文，即可将IPv6前缴（Prefix64）放在选项中带给PCP客户端也就是IPv6主机，3.2PCPServer和NAT/防火墙之间的关系PCPServer用来接收、处理和响应PCP请求。PCPServer功能一般叠加在NAT或者防火墙设备上，如图3所示。当然，PCPServer也可以是独立于NAT或者防火墙的设备，但是此时，PCPServer和NAT或者防火墙之间需要有某种协议来交互映射信息。不管是叠加场景还是独立场景，对于PCPClient来说没什么区别。
INAT orfirewallI
I PcP client I--+
PCP server
图3使能PCP的NAT或者防火墙设备4PCP原理和处理流程
4.1PCP原理
+---
PCP是一种基于UDP的请求/响应（Request/Response）类的协议，但是不是严格的一个请求紧跟着一个响应的格式。例如，PCPClient发出的请求流可能因为包丢失等原因没有触发响应流；PCPServer发出的响应流可能因为Server配置修改主动发送响应流，而非响应之前的请求流。所以，PCP协议是两种相反方向上的相对独立的消息流。一种是PCPClient向PCPServer发送的请求流，即PCPClient希望PCPServer上映射条目的状态：一种是PCPServer向PCPClient发送的响应流，即通知PCPClient在PCPServer上真实映射条目的状态：两种消息流轻度关联。当PCPClient发起PCP请求创建消息，PCPServer判断该消息的合法性，处理该请求消息，创建映射条目，并根据实际情况发送响应消息给PCPClient。当PCPClient发起PCP请求重新创建的消息，PCPServer判断该消息的合法性，处理该请求消息，重新创建映射条目，并根据实际情况发送响应消息给PCPClient。当PCPClient发起PCP请求删除消息，PCPServer判断该消息的合法性，处理该请求消息，删除相应映射条目或所有映射条目，并根据实际情况发送响应消息给PCPClient。当PCPClient发起PCP请求，并等待重传时间T，如果T1时间内没有收到来自PCPServer的响应时，PCPClient会重新发送请求消息（retransmission），并设置等待时间翻倍为T1*2。这个过程再重复三次，并且每次的重传时间都翻倍。当第四次后，还没有收到响应，则终止请求过程。3
YD/T2934-2015
即PCPClient在呈指数级递增的时间间隔内等待来自PCPServer的响应，如果没有响应，继续发送重传直至终止请求：具体重传时间算法在后续章节中规定。当PCPClient收到来自PCPServer的响应时，会保留该映射条目并设置该条目的生命时间，当到了1/2至5/8生命时间时，PCPClient会向PCPServer发起续租（renewal），如果没有收到来自PCPServer的响应，则在3/4至3/4+1/16生命周期时再次发起续租，如果仍然没有收到，则在7/8至7/8+1/32生命周期时再次发起续租，以此类推，PCPClient在呈指数级递减的时间上发送续租消息直至生命时间结束，这个过程的限制是，续租请求的间隔必须大于4s。具体续租时间算法在后续章节中规定。
对于PCPServer来说重传消息和续租消息是一模一样的，都标识了Client希望创建映射以及维持映射生命时间。
4.2通用Request和Response消息头结构4.2.1概述
所有的PCP消息都是UDP报文，最大报文长度为1024字节。PCP消息包含Request消息头或者Response消息头，每个消息头中包括一个操作码Opcode，Opcode包含相关的Opcode-specific信息以及相关的option信息。下面分别介绍通用的Request和Response消息头结构，PCPClient和PCPServer的处理流程、以及两种主要的Opcodes应用。4.2.2通用Request和Response消息头结构所有的请求消息使用如图4所示头结构。0
01234567890123456789012345678901IVersion=2IRl
Opcode
Reserved
Requested Lifetime (32bit)
PCPClient'sIPAddress(128bit)：
(optional)Opcode-specific information(optional)PCPOptions
图4通用Request消息头格式
图4中各字段描述如下：
YD/T2934-2015
Version：version2，这个字段用于PCPClient和PCPServer之间的版本协商：R：o表示Request，1表示Response：一Opcode：7bit，用于标识是MAPOpcode还是PEEROpcode：一Reserved：16bit预留字段：发送的时候该字段必须为O，接收时忽略不处理该字段：一RequestLifetime：32bit整型，单位是秒，范围为0～232-1s，用于标识映射条目的生命时间：一PCPClient'sIPAddresS：PCP请求报文中IP头中的源IPv4地址或IPv6地址，IPv4在这里标识为IPv4-mappedIPv6地址，该字段用来检测Client和Server之间是否经过NAT；一Opcode-specificinformation：对应Opcode的payload数据：长度由操作码Opcode来决定；PCPOptions：对应该操作码Opcode的有效option，可能有0个、1个或者多个。4.2.3Response消息头结构
所有的响应消息使用如图5所示的头结构。0
01234567890123456789012345678901Version = 2 IRl
图5中各字段描述如下：
Opcode
Reserved
Lifetime (32bit)
EpochTime(32bit)
Reserved (96bit)
Result Code
(optional)Opcode-specific responsedata(optional)Options
通用Response消息头结构
-Version：version2，这个字段用于PCPClient和PCPServer之间的版本协商；-R：0表示Request，1表示Response；所有的Response报文都必须为1，且由Server发送；-Opcode：7bit，直接从Request消息对应的字段拷贝过来：-Reserved：8bit预留字段：发送的时候该字段必须为O，接收时忽略不处理该字段：-ResultCode：8bit响应的结果码，具体见4.2.5；-Lifetime：32bit整型，单位是s，范围为0～232-1s：在表示错误的response中，该字段用来标识PCPClient上次和再次收到错误response之间的时间间隔，在成功的response中，该字段用于标识创建映射条目的生命时间：
YD/T2934-2015
Epochtime：由PCPServer设置的Epoch时间，错误的response和成功的response中都包含该字段，具体见4.3.5；
Reserved：96bit预留字段，如果Server成功解析Request消息，这个字段必须置O；如果Server未成功解析Request消息，PCPServer拷贝Request消息中PCPClient'sIPAddress字段的后96bit到该字段作为响应；
Opcode-specificinformation：对应Opcode的payload数据：长度由操作码Opcode来决定：一PCPOptions：对应该操作码Opcode的有效option，可能有0个、1个或者多个。4.2.4Options选项
Option是PCPOpcode的扩展部分，其主要的Type-Length-Value格式如下图6所示。0
01234567890123456789012345678901Option Code
图6中各字段描述如下：
Reserved
(optional) data
Option Length
图6Option头结构
OptionCode：8bit，其最高有效位置0标识了该option是强制的，最高有效位置1标识了该option是是可选的：bZxz.net
-Reserved：8bit，发送的时候该字段必须为O，接收时忽略不处理该字段；-OptionLength：16bit，标识后续data部分的长度，以8位字节为单位；OptionLength可以为O；当OptionLength不为0时，必须是4字节的倍数，不够4字节的后续以0填充：-data：Option的数据部分：
-如果PCP请求消息中包括多个options，PCPServer收到报文时，必须按照顺序逐个处理每个option；PCPClient必须保证Server有足够的空间来响应这个请求消息，且Server响应消息不超过1024bit，如果响应消息超过1024bit，Server会响应一个错误消息：当PCPServer在处理请求消息中的某个option时发生错误，PCPServer会发送一个相应的错误响应消息：比如，当某个只允许出现一次的option在请求消息中出现了两次，PCPServer必须发送响应报文携带MALFORMED_OPTION结果码给PCPClient：当PCPServer接收到无效的option（如PCPoptionLength比UDP包长还长），PCPServer必须发送响应报文携带MALFORMEDOPTION结果码给PCPClient：当PCPServer发现响应消息超过1024bit，PCPServer必须发送响应报文携带MALFORMEDREQUEST结果码给PCPClient：-所有成功解析并处理的option都包含在成功的响应消息中；所有没有成功解析或处理的option都包含在错误的响应消息中；一对于不同的Opcode有不同的有效选项：-THIRDPARTYOption在MAPOpcode和PEEROpcode中都有效：-FILTEROption只在MAPOpcode中有效：6
-PREFERFAILUREOption只在MAPOpcode中有效。4.2.5ResultCodes结果码
YD/T2934-2015
ResultCodes结果码枚举见下，只有0表示成功响应，其他都表示错误响应；当PCPServer在处理请求消息过程中遇到多个错误，PCPServer应该使用最有代表性的错误码返回。每个错误的结果码划分为长生命时间的错误（longlifetimeerror）或短生命时间的错误（shortlifetimeerror），长生命时间宜为30min，短生命时间宜为30s。oSUCCESS：成功。
1UPSUPPVERSION：不支持的协议版本，属于长生命时间错误。2NOTAUTHORIZED：PCPClient没有使能该请求操作，或者PCPClient请求的操作PCPServer因为安全策略等原因没办法执行，属于长生命时间错误。3MALFORMED_REQUEST：PCPSerVer不能成功解析该请求消息，属于长生命时间错误。4UNSUPP_OPCODE：不支持的Opcode，属于长生命时间错误。5UNSUPP_OPTION：不支持的Option，仅出现在某个option要求强制处理而Server不支持时，属于长生命时间错误。
6MAIFORMED_OPTION：畸形的选项，如出现多次，或者无效长度等，属于长生命时间错误。
7NETWORKFAILURE：PCPServer正遭遇某种类型的网络故障，比如没有获取到外部IP地址等，属于短生命时间错误。8NORESOURCES：当前PCPServer上没有足够的资源完PCPClient请求的操作，比如，缺乏CPU资源或内存，或者其他临时性的状况：也许过段时间再发起相同的请求PCPServer能正确处理；这种属于系统性的错误，不同于USEREX_QUOTA，属于短生命时间错误。9UNSUPP_PROTOCAL：不支持的协议，属于长生命时间错误。10USEREXQUOTA：试图创建一个新的映射条目但是超过了用户的端口配额，属于短生命时间错误。
11CANNOTPROVIDEEXTERNAL：PCPSerVer无法提供PCPClient建议的外部地址或者外部端口，这个错误限于处理PEER请求、带有PREFERFAILUREOption的MAP请求或者SCTP协议的MAP请求；属于哪种类型的生命时间错误依赖于发生故障的原因。12ADDRESSMISMATCH：请求报文中的源IP地址和PCPClient\sIPAddress不匹配，属于长生命时间的错误。
13EXCESSIVEREMOTEPEERS：PCPSerVer无法创建过滤条目，只限于处理携带有FILTEROption的MAP请求，属于长生命时间错误。4.3PCP处理流程
4.3.1PCPClient产生和发送Request消息PCPClient发送第一个请求消息之前，需要先发现PCPServer。发现PCPServer有以下几个步骤：
-如果PCPServer已配置，例如，通过配置文件或者DHCP下发；则直接添加到PCPServer列表：否则
YD/T2934-2015
-选择缺省路由添加到PCPServer列表：如果PCPClient既有IPv4地址又有IPv6地址，则选择IPv4缺省路由作为IPv4PCPServer创建IPv4映射，选择IPv6缺省路由作为IPv6PCPServer创建IPv6映射。
本标准中暂时只支持一个PCPServer地址。有了PCPServer地址，PCPClient就可以发起PCP请求。
PCP消息封装在UDP中，PCPServer必须在PCPPort端口号上监听PCP请求。每个PCP请求都会产生一个PCP响应，所以PCP不用运行在一个可靠传输协议之上。图7所示是封装在以太顿中的PCP报文格式。
Ethheader
rDPheader
IPheader
PCP header(opcode)
payload
PCPpayload
options(optional)
图7以太顿中的PCP报文格式
一个内部主机上可以有多个PCPClients，每个Client发起请求时使用不同的端口号，端口号是随机产生的，具体详见IETFRFC60564.3.2PCPClient重传Request消息PCPClient需要保证请求消息的正确传送。当PCPClient在期望时间内没有收到来自PCPServer的响应消息，PCPClient必须重传这个请求消息，直到收到期望的响应消息。PCPClient重传机制介绍如下，其中包括变量如下：RT：Retransmissiontimeout，重传时间。IRT：Initialretransmissiontimeout，初始化重传时间，可以为3s。MRC：Maximumretransmissioncount，最大重传次数，可以为0（0表示没有最大值）。MRT：Maximumretransmissiontime，最大重传时间，可以为1024s。MRD：Maximumretransmissionduration，最大重传持续时间，可以为0（o表示没有最大值）。RAND：Randomizationfactor，随机因子。每次请求消息发送或重传，PCPClient设置RT时间如下规则，如果在等待了RT时间内仍然没有收到来自PCPServer的响应消息，则重新计算RT值并重传请求消息。为了减少消息重传导致的消息同步，每次RT的计算都包含一个随机因子RAND，RAND的取值范围为一0.1~+0.1。每个PCPClient在需要消息重传时都会随机选择一个RAND重新计算其各自的重传时间RT。
RT的初始化值如下：
RT=IRT+RANDXIRT
下一次的重传时间基于上次的重传时间，计算规则如下：RT=2XRTprev+RAND X RTprev
最大重传时间MRT定义了重传时间RT的上限值，如果MRT值为0，则表示没有最大重传时间，一直重传：当MRT值不为O，当RT>最大重传时间MRT时，RT=MRT+RANDXMRT
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国通信行业标准
YD/T2934-2015
端口控制协议（PCP）技术要求
Technical specification for port control protocol (PCP)2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前
范围·
缩略语·
3概述
3.1场景概述·
3.2PCPServer和NAT/防火墙之间的关系..4PCP原理和处理流程
4.1PCP原理·
4.2通用Request和Response消息头结构.4.3PCP处理流程·
4.4版本协商
4.5MAP和PEEROpcodes介绍
4.6MAPOpcode操作码.
4.7PEEROpcode
4.8MAPOpcode和PEEROpcode的选项options*5安全考忠·
概述·
简单威胁模型
高级威胁模型
YD/T2934-2015
YD/T2934-2015
本标准按照GB/T1.1-2009规则起草。前言
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任，本标准由中国通信标准化协会提出并归口。标准起草单位：中国电信集团公司、中兴通讯股份有限公司。标准主要起草人：孙琼、孟伟、王翠。1范围
端口控制协议（PCP）技术要求
YD/T2934-2015
本标准规定了端口控制协议的技术要求，包括端口控制协议的概述、原理和安全考虑等。本标准适用于使用网络地址翻译（NAT）的应用场景。2缩略语
下列缩略语适用于本文件。
DS-Lite
NAT-PMT
NAT444
3概述
3.1场景描述
Basic Bridging BroadBand
customerpremisesequipment
Carrier-Grade NAT
Dual-Stack Lite
Endpoint-Dependent Filter
Endpoint-Dependent Mapping
Endpoint-IndependentFilter
Endpoint-Independent MappingNetworkAddressTranslation
NATPath MTU
NATIPv4 to IPv4
Carrier NAT
NATIPv6toIPv4
PeertoPeer
Port Control Protocal
基本桥接宽带功能单元
用户驻地设备
运营级NAT
轻型双栈方案
端点相关过滤
端点相关映射
端点无关过滤
端点无关映射
网络地址翻译
NAT映射表
网络地址翻译IPv4到IPv4
运营级NAT
网络地址翻译IPv6到IPv4
点对点
端口控制协议
端口控制协议（PCP）提供了一种NATs和防火墙上动态创建映射条目从而转发入向包的机制，PCP协议是和地址族无关的协议。它是NAT-PMT的扩展，可以满足IPv6和大规模网络地址转换（large-ScaleNAT）的需要。PCP协议可以应用在NATs（NAT44/NAT444/NAT64/CGN）设备和防火墙上。
图1所示是DS-liteCGN中的一种应用场景。YD/T2934-2015
4In6Tunnel
DS-Lite CGN
IPv4网络
INTERNALIPINTERNAI.PORT EXTERNALIPEXTERNALPROT
153.1.1.1
图1DS-liteCGN中的应用场景
服务器10.1.1.2位于一个内网中，外部用户如果访问该服务器不能使用私网地址访问。在CGN设备设置一个内部地址、端口和外部地址、端口的映射表，把外部地址和外部端口提供给外部用户，则用户可以通过提供的外部地址和外部端口访问位于内网中的服务器。通常，这个映射表是通过手动配置的方式创建，PCP协议则提供了种动态创建映射表的机制。服务器或者CPE作为PCP客户端（PCPclient），CGN作为PCP服务器端（PCPserVer），PCPclient向PCPserver发送请求消息去创建、重建或者删除PCP映射，PCPserver向PCPclient发送响应消息返回PCPserver上生成的映射或者失败消息。图2所示为PCP创建、更新、删除过程。PCPelient
PCPclient
PCPclient
Requcst (create)
response (mapping/error)
Request (recreate)
esponse(mapping/error)
Request (delete)
esponse (mapping/error)
PCPserver
PCPserver
PCPserver
图2PCP创建，更新、删除过程
PCP除了上述场景外，基于PCPclient和sever的交互过程，通过PCP的扩展，还有着非常广泛的应用场景。
YD/T2934-2015
在NAT应用中，B4或CGN设备可以通过PCP扩展消息来向外部地址资源服务器获取和回收释放公网地址或端口，用于进行公网地址和端口的转换。外部地址资源服务器（即PCP服务器端）对该请求消息做出响应，对地址或端口进行分配或回收。例如在轻量级4over6技术中，B4设备进行NAT转换并进行会话的维护，B4作为PCP客户端，并通过PCP的MAPREQUEST报文向PCP服务器获取公网地址和端口范围等信息。在NAT64应用中，当IPv6主机需要获取IPv6前缀来合成远端IPv4主机所转换的IPv6地址时，IPv6主机作为PCP客户端，NAT设备作为服务器，通过PCP的MAPREQUEST报文，即可将IPv6前缴（Prefix64）放在选项中带给PCP客户端也就是IPv6主机，3.2PCPServer和NAT/防火墙之间的关系PCPServer用来接收、处理和响应PCP请求。PCPServer功能一般叠加在NAT或者防火墙设备上，如图3所示。当然，PCPServer也可以是独立于NAT或者防火墙的设备，但是此时，PCPServer和NAT或者防火墙之间需要有某种协议来交互映射信息。不管是叠加场景还是独立场景，对于PCPClient来说没什么区别。
INAT orfirewallI
I PcP client I-
PCP server
图3使能PCP的NAT或者防火墙设备4PCP原理和处理流程
4.1PCP原理
+---
PCP是一种基于UDP的请求/响应（Request/Response）类的协议，但是不是严格的一个请求紧跟着一个响应的格式。例如，PCPClient发出的请求流可能因为包丢失等原因没有触发响应流；PCPServer发出的响应流可能因为Server配置修改主动发送响应流，而非响应之前的请求流。所以，PCP协议是两种相反方向上的相对独立的消息流。一种是PCPClient向PCPServer发送的请求流，即PCPClient希望PCPServer上映射条目的状态：一种是PCPServer向PCPClient发送的响应流，即通知PCPClient在PCPServer上真实映射条目的状态：两种消息流轻度关联。当PCPClient发起PCP请求创建消息，PCPServer判断该消息的合法性，处理该请求消息，创建映射条目，并根据实际情况发送响应消息给PCPClient。当PCPClient发起PCP请求重新创建的消息，PCPServer判断该消息的合法性，处理该请求消息，重新创建映射条目，并根据实际情况发送响应消息给PCPClient。当PCPClient发起PCP请求删除消息，PCPServer判断该消息的合法性，处理该请求消息，删除相应映射条目或所有映射条目，并根据实际情况发送响应消息给PCPClient。当PCPClient发起PCP请求，并等待重传时间T，如果T1时间内没有收到来自PCPServer的响应时，PCPClient会重新发送请求消息（retransmission），并设置等待时间翻倍为T1*2。这个过程再重复三次，并且每次的重传时间都翻倍。当第四次后，还没有收到响应，则终止请求过程。3
YD/T2934-2015
即PCPClient在呈指数级递增的时间间隔内等待来自PCPServer的响应，如果没有响应，继续发送重传直至终止请求：具体重传时间算法在后续章节中规定。当PCPClient收到来自PCPServer的响应时，会保留该映射条目并设置该条目的生命时间，当到了1/2至5/8生命时间时，PCPClient会向PCPServer发起续租（renewal），如果没有收到来自PCPServer的响应，则在3/4至3/4+1/16生命周期时再次发起续租，如果仍然没有收到，则在7/8至7/8+1/32生命周期时再次发起续租，以此类推，PCPClient在呈指数级递减的时间上发送续租消息直至生命时间结束，这个过程的限制是，续租请求的间隔必须大于4s。具体续租时间算法在后续章节中规定。
对于PCPServer来说重传消息和续租消息是一模一样的，都标识了Client希望创建映射以及维持映射生命时间。
4.2通用Request和Response消息头结构4.2.1概述
所有的PCP消息都是UDP报文，最大报文长度为1024字节。PCP消息包含Request消息头或者Response消息头，每个消息头中包括一个操作码Opcode，Opcode包含相关的Opcode-specific信息以及相关的option信息。下面分别介绍通用的Request和Response消息头结构，PCPClient和PCPServer的处理流程、以及两种主要的Opcodes应用。4.2.2通用Request和Response消息头结构所有的请求消息使用如图4所示头结构。0
01234567890123456789012345678901IVersion=2IRl
Opcode
Reserved
Requested Lifetime (32bit)
PCPClient'sIPAddress(128bit)：
(optional)Opcode-specific information(optional)PCPOptions
图4通用Request消息头格式
图4中各字段描述如下：
YD/T2934-2015
Version：version2，这个字段用于PCPClient和PCPServer之间的版本协商：R：o表示Request，1表示Response：一Opcode：7bit，用于标识是MAPOpcode还是PEEROpcode：一Reserved：16bit预留字段：发送的时候该字段必须为O，接收时忽略不处理该字段：一RequestLifetime：32bit整型，单位是秒，范围为0～232-1s，用于标识映射条目的生命时间：一PCPClient'sIPAddresS：PCP请求报文中IP头中的源IPv4地址或IPv6地址，IPv4在这里标识为IPv4-mappedIPv6地址，该字段用来检测Client和Server之间是否经过NAT；一Opcode-specificinformation：对应Opcode的payload数据：长度由操作码Opcode来决定；PCPOptions：对应该操作码Opcode的有效option，可能有0个、1个或者多个。4.2.3Response消息头结构
所有的响应消息使用如图5所示的头结构。0
01234567890123456789012345678901Version = 2 IRl
图5中各字段描述如下：
Opcode
Reserved
Lifetime (32bit)
EpochTime(32bit)
Reserved (96bit)
Result Code
(optional)Opcode-specific responsedata(optional)Options
通用Response消息头结构
-Version：version2，这个字段用于PCPClient和PCPServer之间的版本协商；-R：0表示Request，1表示Response；所有的Response报文都必须为1，且由Server发送；-Opcode：7bit，直接从Request消息对应的字段拷贝过来：-Reserved：8bit预留字段：发送的时候该字段必须为O，接收时忽略不处理该字段：-ResultCode：8bit响应的结果码，具体见4.2.5；-Lifetime：32bit整型，单位是s，范围为0～232-1s：在表示错误的response中，该字段用来标识PCPClient上次和再次收到错误response之间的时间间隔，在成功的response中，该字段用于标识创建映射条目的生命时间：
YD/T2934-2015
Epochtime：由PCPServer设置的Epoch时间，错误的response和成功的response中都包含该字段，具体见4.3.5；
Reserved：96bit预留字段，如果Server成功解析Request消息，这个字段必须置O；如果Server未成功解析Request消息，PCPServer拷贝Request消息中PCPClient'sIPAddress字段的后96bit到该字段作为响应；
Opcode-specificinformation：对应Opcode的payload数据：长度由操作码Opcode来决定：一PCPOptions：对应该操作码Opcode的有效option，可能有0个、1个或者多个。4.2.4Options选项
Option是PCPOpcode的扩展部分，其主要的Type-Length-Value格式如下图6所示。0
01234567890123456789012345678901Option Code
图6中各字段描述如下：
Reserved
(optional) data
Option Length
图6Option头结构
OptionCode：8bit，其最高有效位置0标识了该option是强制的，最高有效位置1标识了该option是是可选的：bZxz.net
-Reserved：8bit，发送的时候该字段必须为O，接收时忽略不处理该字段；-OptionLength：16bit，标识后续data部分的长度，以8位字节为单位；OptionLength可以为O；当OptionLength不为0时，必须是4字节的倍数，不够4字节的后续以0填充：-data：Option的数据部分：
-如果PCP请求消息中包括多个options，PCPServer收到报文时，必须按照顺序逐个处理每个option；PCPClient必须保证Server有足够的空间来响应这个请求消息，且Server响应消息不超过1024bit，如果响应消息超过1024bit，Server会响应一个错误消息：当PCPServer在处理请求消息中的某个option时发生错误，PCPServer会发送一个相应的错误响应消息：比如，当某个只允许出现一次的option在请求消息中出现了两次，PCPServer必须发送响应报文携带MALFORMED_OPTION结果码给PCPClient：当PCPServer接收到无效的option（如PCPoptionLength比UDP包长还长），PCPServer必须发送响应报文携带MALFORMEDOPTION结果码给PCPClient：当PCPServer发现响应消息超过1024bit，PCPServer必须发送响应报文携带MALFORMEDREQUEST结果码给PCPClient：-所有成功解析并处理的option都包含在成功的响应消息中；所有没有成功解析或处理的option都包含在错误的响应消息中；一对于不同的Opcode有不同的有效选项：-THIRDPARTYOption在MAPOpcode和PEEROpcode中都有效：-FILTEROption只在MAPOpcode中有效：6
-PREFERFAILUREOption只在MAPOpcode中有效。4.2.5ResultCodes结果码
YD/T2934-2015
ResultCodes结果码枚举见下，只有0表示成功响应，其他都表示错误响应；当PCPServer在处理请求消息过程中遇到多个错误，PCPServer应该使用最有代表性的错误码返回。每个错误的结果码划分为长生命时间的错误（longlifetimeerror）或短生命时间的错误（shortlifetimeerror），长生命时间宜为30min，短生命时间宜为30s。oSUCCESS：成功。
1UPSUPPVERSION：不支持的协议版本，属于长生命时间错误。2NOTAUTHORIZED：PCPClient没有使能该请求操作，或者PCPClient请求的操作PCPServer因为安全策略等原因没办法执行，属于长生命时间错误。3MALFORMED_REQUEST：PCPSerVer不能成功解析该请求消息，属于长生命时间错误。4UNSUPP_OPCODE：不支持的Opcode，属于长生命时间错误。5UNSUPP_OPTION：不支持的Option，仅出现在某个option要求强制处理而Server不支持时，属于长生命时间错误。
6MAIFORMED_OPTION：畸形的选项，如出现多次，或者无效长度等，属于长生命时间错误。
7NETWORKFAILURE：PCPServer正遭遇某种类型的网络故障，比如没有获取到外部IP地址等，属于短生命时间错误。8NORESOURCES：当前PCPServer上没有足够的资源完PCPClient请求的操作，比如，缺乏CPU资源或内存，或者其他临时性的状况：也许过段时间再发起相同的请求PCPServer能正确处理；这种属于系统性的错误，不同于USEREX_QUOTA，属于短生命时间错误。9UNSUPP_PROTOCAL：不支持的协议，属于长生命时间错误。10USEREXQUOTA：试图创建一个新的映射条目但是超过了用户的端口配额，属于短生命时间错误。
11CANNOTPROVIDEEXTERNAL：PCPSerVer无法提供PCPClient建议的外部地址或者外部端口，这个错误限于处理PEER请求、带有PREFERFAILUREOption的MAP请求或者SCTP协议的MAP请求；属于哪种类型的生命时间错误依赖于发生故障的原因。12ADDRESSMISMATCH：请求报文中的源IP地址和PCPClient\sIPAddress不匹配，属于长生命时间的错误。
13EXCESSIVEREMOTEPEERS：PCPSerVer无法创建过滤条目，只限于处理携带有FILTEROption的MAP请求，属于长生命时间错误。4.3PCP处理流程
4.3.1PCPClient产生和发送Request消息PCPClient发送第一个请求消息之前，需要先发现PCPServer。发现PCPServer有以下几个步骤：
-如果PCPServer已配置，例如，通过配置文件或者DHCP下发；则直接添加到PCPServer列表：否则
YD/T2934-2015
-选择缺省路由添加到PCPServer列表：如果PCPClient既有IPv4地址又有IPv6地址，则选择IPv4缺省路由作为IPv4PCPServer创建IPv4映射，选择IPv6缺省路由作为IPv6PCPServer创建IPv6映射。
本标准中暂时只支持一个PCPServer地址。有了PCPServer地址，PCPClient就可以发起PCP请求。
PCP消息封装在UDP中，PCPServer必须在PCPPort端口号上监听PCP请求。每个PCP请求都会产生一个PCP响应，所以PCP不用运行在一个可靠传输协议之上。图7所示是封装在以太顿中的PCP报文格式。
Ethheader
rDPheader
IPheader
PCP header(opcode)
payload
PCPpayload
options(optional)
图7以太顿中的PCP报文格式
一个内部主机上可以有多个PCPClients，每个Client发起请求时使用不同的端口号，端口号是随机产生的，具体详见IETFRFC60564.3.2PCPClient重传Request消息PCPClient需要保证请求消息的正确传送。当PCPClient在期望时间内没有收到来自PCPServer的响应消息，PCPClient必须重传这个请求消息，直到收到期望的响应消息。PCPClient重传机制介绍如下，其中包括变量如下：RT：Retransmissiontimeout，重传时间。IRT：Initialretransmissiontimeout，初始化重传时间，可以为3s。MRC：Maximumretransmissioncount，最大重传次数，可以为0（0表示没有最大值）。MRT：Maximumretransmissiontime，最大重传时间，可以为1024s。MRD：Maximumretransmissionduration，最大重传持续时间，可以为0（o表示没有最大值）。RAND：Randomizationfactor，随机因子。每次请求消息发送或重传，PCPClient设置RT时间如下规则，如果在等待了RT时间内仍然没有收到来自PCPServer的响应消息，则重新计算RT值并重传请求消息。为了减少消息重传导致的消息同步，每次RT的计算都包含一个随机因子RAND，RAND的取值范围为一0.1~+0.1。每个PCPClient在需要消息重传时都会随机选择一个RAND重新计算其各自的重传时间RT。
RT的初始化值如下：
RT=IRT+RANDXIRT
下一次的重传时间基于上次的重传时间，计算规则如下：RT=2XRTprev+RAND X RTprev
最大重传时间MRT定义了重传时间RT的上限值，如果MRT值为0，则表示没有最大重传时间，一直重传：当MRT值不为O，当RT>最大重传时间MRT时，RT=MRT+RANDXMRT
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。