中国电信下一代互联网认证系统技术规范.docx

中国电信下一代互联网
认证系统技术规范

（修改稿）

中国电信股份有限公司上海研究院
二零一一年五月

目 录
1 编制说明 1
1.1 范围 1
1.2 引用标准 1
1.3 定义、术语和缩写 2
1.3.1 定义 2
1.3.2 术语和缩写 2
2 认证系统概述 3
2.1 认证系统的定位 3
2.2 认证系统的功能和业务组成 4
3 认证系统对IPv6协议的支持的总述 5
4 认证授权部分对IPv6的扩充 6
4.1 功能扩充 6
4.2 数据格式定义 6
4.3 L2TP隧道 7
4.4 PROXY 7
4.5 IPv6相关共有RADIUS属性 8
4.6 IPv6私有属性扩展 11
5 计费采集部分对IPv6的扩充 13
6 认证系统用户在线信息表要求 13
7 周边系统接口 13
7.1 与服务开通系统的接口 14
7.2 与网络设备的接口 14
7.3 与计费系统的接口 14
8 AAA系统IPv6过渡技术支持 15
8.1 概述 15
8.1.1 IPv6过渡技术中认证与地址溯源概述 15
8.1.2 过渡技术的四种地址溯源方案 16
8.2 AAA系统溯源改造总体要求 17
8.3 功能要求 18
8.3.1 静态映射表生成功能 18
8.3.2 动态映射关系获取功能 19
8.3.3 地址池选择功能 19
8.4 接口要求 20
8.4.1 与网管系统接口 20
8.4.2 与外部溯源请求系统接口 20
8.4.3 与Log服务器接口 22
9 性能与可靠性要求 23
9.1 AAA系统基本性能要求 23
9.2 可靠性要求 24
10 附：用户认证流程 24
10.1 本地BRAS接入认证流程 24
10.2 L2TP隧道方式接入认证流程 26
10.3 认证系统用户在线信息维护示例 27

1 编制说明
1.1 范围
本技术规范以RFC文档为依据，针对中国电信下一代互联网试点实际情况和具体要求，对下一代互联网IPv6城域网中认证系统的定义、网络定位、业务支持流程等进行了说明，对在系统中支持IPv6协议的功能提出了规定，包括认证、授权、计费等相关部分对IPv6协议属性支持的具体要求。
本文件不对中国电信现有的认证系统进行规范，仅针对下一代互联网（IPv6）技术中涉及到的用户接入认证系统进行规范。本技术规范适用于中国电信认证系统支持IPv6功能的研制开发工作。
在本规范中：
（1）必须：表示该条目是本规范必须。违反这样的要求是原则性错误。
（2）必须实现：表示该要求必须实现，但不要求缺省使能。
（3）不允许（不可以）：表示该条目绝对禁止。
（4）应当（建议）：表示在某些特定条件下存在忽视该条目的理由，但是忽视或违反该条目时必须仔细衡量。
（5）应当（建议）实现：与应当（建议）类似，实现时不必要缺省使能。
（6）不应当（不建议）：表示在某些特定条件存在所描述行为可接受或有效的理由，但实现该行为时必须仔细衡量。
（7）可以：表示该条目确实可选。
1.2 引用标准
下列标准包含的条文，通过在本标准中引用而构成为本标准的条文。本标准出版时，所示版本均为有效。所有标准都会被修订，使用本标准的各方应探讨，使用下列标准最新版本的可能性。
RFC 2865/2318
RADIUS协议（认证）
RFC 2866/2319
RADIUS协议（计费）
RFC 2867
RADIUS协议（隧道协议的计费）
RFC 2868
RADIUS协议（隧道协议的认证）
RFC 2869
RADIUS协议扩展
RFC 3162
RADIUS和IPv6
RFC 3575
IANA对RADIUS的考虑
RFC 5176/3576
RADIUS动态认证扩展
RFC 3579
RADIUS支持可扩展的认证协议（EAP）
RFC 4818
RADIUS属性－Delegated-IPv6-Prefix
RFC 5080
一般RADIUS执行问题和建议

1.3 定义、术语和缩写
1.3.1 定义
认证系统：为IP网络中的接入用户提供认证、授权、和计费服务的系统。
1.3.2 术语和缩写
AAA
Authentication，Authorization & Accounting （认证、授权和计费）
BRAS
Broadband Remote Access Server （宽带接入服务器）
CHAP
Challenge-handshake Authentication Protocol （握手认证协议）
DHCP
Dynamic Host Configuration Protocol （动态主机配置协议）
DSLAM
Digital Subscriber Line Access Multiplexer （数字用户线接入复用器）
IPoE
IP over Ethernet
IPv6
Internet Protocol Version 6 （互联网协议第6版）
IPv6CP
IP Control Protocol（IPv6控制协议）
L2TP
Layer 2 Tunnelling Protocol （第二层隧道协议）
LAC
L2TP Access Concentrator （L2TP访问集中器）
LAN
Local Area Network（局域网）
LCP
Link Control Protocol（链路控制协议）
LNS
L2TP Network Server（L2TP网络服务器）
MAC
Media Access Control（介质访问控制）
MIB
Management Information Base（管理信息库）
NAT-PT
Network Address Translate + Protocol Translation（网络地址翻译/协议翻译）
PAP
Password Authentication Protocol （密码认证协议）
PPPoE
PPP Over Ethernet
RADIUS
Remote Authorization Dial In User Service （远程认证拨号用户服务）
SNMP
Simple Network Management Protocol （简单网络管理协议）
TCP
Transmission Control Protocol（传输控制协议）
UDP
User Datagram Protocol（用户数据报协议）
VPN
Virtual Private Network （虚拟专用网）
DS-Lite
Dual stack-Lite
NAT444
Natwork address translate 444

2 认证系统概述
2.1 认证系统的定位
在中国电信IP城域网中，认证/计费服务器一般处于城域骨干网的核心层，通过网络与接入网关的认证端口建立IP连接，为用户接入网络提供认证、授权、和计费服务。
典型的网络拓扑如图1所示：

图1、认证系统在网络中的定位

2.2 认证系统的功能和业务组成
认证系统主要功能为：提供用户接入中国电信IP网络时，对用户的身份的验证，包括用户帐号与密码的匹配关系，用户接入的线路认证、用户接入的次数验证等；在用户通过身份认证之后，为用户的当前接入配置适当的权限，包括用户接入的带宽等模板信息；在用户上线过程中和下线之后记录用户使用的计费原始信息，并生成原始话单。
同时，认证系统需要在用户上线过程中维持用户在线信息表，并可对其它系统提供查询接口。
认证系统组成：中国电信IP网认证系统由认证服务器、业务逻辑处理服务器和数据库服务器、接口服务器组成，各组成部分的功能描述如下：
认证服务器：完成认证Radius协议/Diameter协议的解析,以及相关协议流程的支持；
业务逻辑处理服务器：完成用户接入身份的验证，授权功能的实现和计费信息的采集，并实现用户在线信息的维护；
数据库服务器：存储用户的信息，包括身份信息、业务信息及其它相关信息；
接口服务器：实现认证系统与其它周边系统的接口，例如：开户接口。
3 认证系统对IPv6协议的支持的总述
本文件不对中国电信现有的认证系统进行规范，仅针对认证系统对下一代互联网（IPv6）的支持进行规范。在IP认证系统中扩充对IPv6协议的支持，主要包括2方面的内容：
（1） IP认证系统中对用户提供IPv6服务时，所增加的相关属性、统计等；
（2） IP认证系统本身的IPv6化，包括系统本身支持IPv6协议栈，各服务器之间，及Client/Server之间传递的报文也用IPv6协议传送。
鉴于目前大部分设备都只支持IPv4协议，认证系统本身传递报文时要确认对方的协议栈，在具体实施时可能引起混乱，因此建议系统的IPv6进程分为2阶段进行。
（1） 现阶段以IPv4访问为主，所传递的报文内容包含了所需的IPv6属性。
（2） 将来对IPv6的支持成熟后，增加系统本身的IPv6化，包括系统管理、系统间报文的传递等内容。
要求认证系统必须支持RFC 3162所规定的6个RADIUS属性和RFC4818规定的1个属性，以支持对IPv6的认证和授权。
系统必须区分普通IPv4用户、纯IPv6用户及双栈用户6种用户，公网、私网、双栈、V6
，不同用户采用由IT支撑系统在开户或修改用户信息时设置用户属性标识的方式实现，该属性标识由IT支撑系统在开户或账户修改时随接口指令传送给认证系统，认证系统将该标识存放在用户信息数据库中，在用户接入认证时通过该字段判断用户是IPv4用户或双栈用户或纯IPv6用户。
用户帐号名可以采用任何符合中国电信帐号规范的帐号形式，帐号后缀可以根据业务需要定义任意形式的后缀，供特殊业务（如：VPDN）或帐号漫游使用（如：WLAN属于漫游
全国漫游）。

4 认证授权部分对IPv6的扩充
4.1 功能扩充
为支持对IPv6用户的认证、授权，系统必须支持以下功能。
认证系统在用户业务属性中增加标识支持IPv6功能，识别用户是IPv4单栈、双栈或IPv6单栈接入。
认证系统必须对用户加以区分，标识用户为普通IPv4用户、纯IPv6用户、及双栈用户。
服务开通系统为IPv6用户（或双栈用户）开户后，将IPv6的用户信息传送给认证系统。认证系统必须能接收和识别IPv6用户信息。
认证系统必须扩充RADIUS属性，支持RFC 3162所规定的6个RADIUS属性和RFC4818规定的1个属性。
认证方式，应支持PAP、CHAP等认证方式。
在用户认证完成，用户上线过程中需要记录用户的在线信息，其中包括用户的IPv6地址。需要支持在用户上线过程中接入服务器产生的中间计费包中的IPv6相关信息，如用户IPv6地址和当前IPv6使用的流量等。
在用户下线时，记录用户的下线时间，并支持在用户下线计费包中的IPv6相关Radius属性，如用户IPv6地址、用户IPv6使用流量等。
考虑到用户的使用习惯，用户登录时如果没带域名做如下处理：双栈用户如果没带域名登录，按普通IPv4用户处理给用户分配何种地址？依据什么？
；纯IPv6用户登录时没写域名，按用户名错误处理。其他写错域名时，按与VPN用户同等处理。

4.2 数据格式定义
为支持IPv6功能，认证服务器需要增加相关的数据类型，主要包括以下数据类型，但不限于这几种类型。
（1）IPv6地址（IPv6 Address）：IPv6地址为128比特以16字节数据格式表示。
（2）IPv6地址前缀（IPv6 Prefix）：IPv6地址前缀由2部分组成。第一部分为地址前缀（Prefix），数据形式为0－128比特，以16字节表示，第二部分为前缀的长度（Length），格式为1字节，取值范围为0－128。
（3）IPv6接口ID（IPv6 Interface ID）：64比特，以8字节数据格式表示。
（4）IP用户类型：标志用户的IP类型，有普通IPv4用户、双栈用户、纯IPv6用户3种类型。格式规定为1字节，取值定义：0为普通用户，1为双栈用户，2为纯IPv6用户。
4.3 L2TP隧道
在VPN企业用户表中定义支持IPv6功能BRAS的域名，地址，隧道密码等参数。当需要支持双栈或纯IPv6的用户在不支持IPv6的BRAS设备接入网络时，可以动态或静态提供L2TP隧道接入支持IPv6的LNS设备参数，为用户建立IPv6的PPPoE连接。认证系统需要支持LNS参数的列表，以实现负载均衡或其它功能。
认证流程中，在RADIUS属性解析中增加相关IPv6属性解析。根据IPV6地址生成IPV6格式的地址字符串以及根据IPv6地址字符串生成IPV6地址。
用户通过隧道上网时，在LAC和LNS中都会发送计费账单，需要排除LAC的账单。
4.4 PROXY
一般PROXY RADIUS同时具有PROXY和SERVER的角色，因此要求PROXY RADIUS必须具有和RADIUS服务器相同的功能。
能把从接入服务器发送的带有IPv6相关属性的报文转发到RADIUS服务器。
能把RADIUS服务器回应的带有IPv6属性的报文转发给接入服务器。
PROXY不允许过滤任何IPv6相关的Radius属性。
接入服务器与PROXY之间的传送协议可采用IPv4或IPv6，PROXY与RADIUS服务器之间的传送协议也可采用IPv4或IPv6，二段传送协议是独立的，并不要求两者保持一致。
4.5 IPv6相关公共RADIUS属性
认证系统必须扩充RADIUS属性，支持RFC 3162所规定的6个RADIUS属性和RFC4818规定的1个属性。
1、NAS-IPv6-Address。属性号95，报文长度18，Address为16字节IPv6地址，是请求认证的用户所使用的接入服务器的IPv6地址。是由接入服务器在Access-Request报文中发送给RADIUS服务器的。其报文格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type
Length
Address
Address（续）
Address（续）
Address（续）
Address（续）

2、Framed-Interface-Id。属性号96，报文长度10，Interface-Id为8字节IPv6接口ID，是IPv6CP协商后的接口ID，用以指示为用户配置的IPv6接口ID。该属性可用于Access-Accept报文中。如果该ID在IPv6CP过程中已协商成功，则由接入服务器通过Access-Request报文发送给RADIUS服务器，RADIUS应采用该接口ID值。其报文格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type
Length
Interface-Id
Interface-Id（续）
Interface-Id（续）

3、Framed-IPv6-Prefix。属性号97，报文长度4－20，Reserved固定为0，Prefix-Length按比特为单位指示Prefix的长度。Prefix为0－128比特的IPv6地址前缀，超出Prefix-Length以外的比特位用0填充。该属性可用于Access-Accept报文中，并且可出现多次。该属性可用于Access-Request报文中，请求RADIUS服务器采用该前缀值，RADIUS服务器可以认同采用该值，但不是必须使用该值。不必发送带有相同前缀的Framed-IPv6-Route属性。其报文格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type
Length
Reserved
Prefix-Length
Prefix
Prefix（续）
Prefix（续）
Prefix（续）

4、Login-IPv6-Host。属性号98，报文长度18，Address为16字节IPv6地址，是允许访问服务器的主机的IPv6地址。当包含Login-Service属性时，指示用以连接用户的系统。该属性可用于Access-Accept报文中，也可用于Access-Request报文中，请求接入服务器希望连接的主机，RADIUS服务器可以认同采用该值，但不是必须使用该值。其报文格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type
Length
Address
Address（续）
Address（续）
Address（续）
Address（续）

其中，Address为全1时，接入服务器应允许用户选择连接的地址或用户名。Address为全0时，由接入服务器选择连接到用户的主机。其他值为接入服务器连接的用户的地址。

5、Framed-IPv6-Route。属性号99，报文长度大于3，Text字段表明IPv6的路由信息。该属性提供了在接入服务器上配置的路由信息，该属性用于Access-Accept报文中，并且可出现多次。报文格式如下：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
Type
Length
Text…
其中，Text为1或多个字节，其内容与实现相关，是一个可识别的字符串，而且不能影响协议的正常运行。对IPv6路由，其形式应包含目标地址前缀、一个斜线（/）后跟十进制的前缀长度、一个空格、网关地址、一个空格、一或多个metric。

6、Framed-IPv6-Pool。属性号100，报文长度大于3，String字段表明接入服务器给用户分配的IPv6地址前缀的前缀池的名字。如果接入服务器不支持多个前缀池，则忽略该属性。其报文格式如下：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
Type
Length
String…

7、Delegated-IPv6-Prefix。属性号123，报文长度4－20，Reserved固定为0，Prefix-Length按比特为单位指示授权的IPv6前缀的长度。本属性用于用户为其用户网络分配IPv6地址所用的IPv6地址前缀。该属性可用于Access-Accept报文中，并且可出现多次。该属性可用于Access-Request报文中，请求RADIUS服务器采用该前缀值，RADIUS服务器可以认同采用该值，但不是必须使用该值。其报文格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type
Length
Reserved
Prefix-Length
Prefix
Prefix（续）
Prefix（续）
Prefix（续）
Prefix为0－128比特的IPv6地址前缀，超出Prefix-Length以外的比特位用0填充。

表1列出了以上属性可能在哪种报文中出现的情况：
表1、IPv6相关Radius属性列表
Request
Accept
Reject
Challenge
Accounting Request
# Attribute
0-1
0
0
0
0-1
95 NAS-IPv6-Address
0-1
0-1
0
0
0-1
96 Framed-Interface-Id
0+
0+
0
0
0+
97 Framed-IPv6-Prefix
0+
0+
0
0
0+
98 Login-IPv6-Host
0
0+
0
0
0+
99 Framed-IPv6-Route
0
0-1
0
0
0-1
100 Framed-IPv6-Pool
0+
0+
0
0
0+
123 Delegated-IPv6-Prefix
上表中各条目的含义如下:
0 该属性不出现；
0+ 可出现0到多个该属性的条目；
0-1 可出现0或1个该属性的条目；
1 该属性出现1次；
1+ 可出现1到多个该属性的条目。

4.6 IPv6私有属性扩展
中国电信Radius私有属性（Vendor属性26）扩展如表2所示：
表2、Radius私有属性扩展无厂家支持
表
子属性名
子属性号
最大长度
类型
说明
备注
中国电信Vendor扩展：Vendor-ID标志为20942
USER-ADDRESS-TYPE
120
4
Integer
指明用户接入的地址类型
目前有6种定义：
0——公网IPv4用户；
1——私网IPv4用户；
2——公网双栈用户；
3——私网双栈用户；
4——DS-Lite用户；
5——纯IPv6用户
USER-ADDRESS-LOG
121
253
String
存放各种CGN地址转换日志信息
该字段包含映射时间，公网地址、起始端口号、终止端口号、用户地址，各字段采用“；”分割。
例举格式为：
映射时间（YY/MM/DD/HH/MM/SS）；公网地址（IPv4地址）；起始端口号；终止端口号；用户地址（可以是IPv4或IPv6地址）

5 计费采集部分对IPv6的扩充
计费采集部分与认证授权部分相同。服务开通系统为IPv6用户（或双栈用户）开户后，将IPv6的用户信息传送给计费采集系统。该系统必须能接收和识别IPv6用户信息。
计费采集系统必须对用户加以区分，标识用户为普通IPv4用户、纯IPv6用户、及双栈用户。
当用户发起呼叫连接时，计费采集系统必须能识别是不同类型的用户。
原始话单在本地处理时，应区分不同类型的的用户标识。
传递给计费系统的详单应区分不同类型的用户标识。
用户通过隧道上网时，在LAC和LNS中都会发送计费账单，需要排除LAC的账单。

6 认证系统用户在线信息表要求
认证系统必须在用户接入时判断用户的接入类型（如纯公网IPv4、私网IPv4、公网双栈、私网双栈、DS-Lite、纯IPv6），并在用户在线信息表中记录用户上线的IP地址。用户在线IP地址可以由接入服务器发送的上线包、中间计费包、或下线包中的相关IP地址属性提取（IPv6地址为：Framed-IPv6-Prefix、Framed-Interface-Id属性组合而成；IPv4地址为：Framed-IP-Address属性携带）。其中，IPv6地址由前缀和接口地址合成完整的IPv6地址；IPv4地址直接从Radius属性中提取。

7 周边系统接口
认证系统扩充支持IPv6后，与其他系统之间接口也要有相应的扩充，相关系统主要包括：服务开通系统、网络设备、计费系统等。其接口关系图如图2所示：

图2、周边系统接口
7.1 与服务开通系统的接口各地厂家不一样，需进行协商

IPv6用户或双栈用户在服务开通系统开户后，需要把相关的用户名和接入业务标识传递给认证系统，包括认证、计费部分。
7.2 与网络设备的接口
认证系统与网络设备的接口主要是与接入服务器的接口。
认证系统必须能识别接入用户本地的接入服务器是否支持IPv6接入，根据不同情况进行相应的处理。
接入服务器与认证服务器之间传送的RUDIUS报文（包括认证包、上线计费包、中间计费包和下线计费包），必须增加支持RFC3162和RFC4818所规定的RADIUS属性。
7.3 与计费系统的接口
计费采集系统与计费系统之间的接口必须扩充，以支持对IPv6用户或双栈用户的标识。支持在原始话单中传送用户IPv6地址信息和IPv6使用的流量信息。在传送原始单时，原始话单中必须区分公网IPv4用户、私网IPv4用户、公网双栈用户、私网双栈用户、纯IPv6用户、及DS-Lite用户。
8 AAA系统IPv6过渡技术支持
8.1 概述
8.1.1 IPv6过渡技术中认证与地址溯源概述
中国电信认证/计费系统（AAA）位于城域网核心，承担用户的接入认证和产生计费原始信息（话单）。同时，通过AAA系统可以提供用户地址的溯源、反查等功能。传统IPv4网络认证与地址溯源流程如图3所示：

图3、IPv4网络认证与地址溯源流程
由于IPv6过渡技术中采用了地址转换技术。因此，需要AAA系统能够提供用户上网过程中，地址转换前后的对应关系，保证用户地址可以溯源。用户地址溯源分为两种，第一种为在线用户地址溯源，要求在用户在线状态下，根据公网IPv4、IPv6地址和端口信息反查用户的帐号信息；第二种为离线用户地址溯源，要求系统能够保存一定时间内的用户上网信息和用户地址转换日志信息，提供反查用户历史上网信息的功能。
地址转换网关是完成过渡技术中地址转换的关键设备，在网络中地址转换网关可以采用集中部署在城域网核心或分布式部署在业务接入点的BRAS/SR设备上。集中式部署与分布式部署的认证和地址溯源流程没有差异。其认证和地址溯源总体流程如图4所示：

图4、过渡技术场景认证与地址溯源总体流程
由于过渡技术中存在地址转换的过程，因此AAA系统需要进行在线状态表项和地址转换关系查询的改造。同时，根据过渡技术部署方案的不同，AAA系统还必须在采用固定地址、端口映射的方式下维护私有地址与公有地址和端口映射关系表，以及在动态映射部署方式下，通过AAA或Log服务器查询动态地址和端口映射关系的接口。

8.1.2 过渡技术的四种地址溯源方案
过渡技术部署方案有地址、端口固定映射部署方式和地址、端口动态映射部署方式两种，针对这两种部署方案，有四种地址溯源方案。方案一：采用由CGN设备在建立端口映射关系集中式？
后，发送syslog日志信息的方式，将端口/端口段映射关系发送到日志服务器，AAA系统在接收溯源请求后，通过syslog服务器查询到动态地址映射关系，从而完成地址溯源；方案二：CGN设备通过Radius报文方式将用户的动态端口映射关系上报到AAA系统，由AAA系统记录到用户在线信息表和原始话单中，当AAA系统接收到溯源请求后，直接查询在线用户信息表或原始话单，返回溯源结果；方案三：CGN设备采用Radius报文方式将用户动态端口映射关系上报到Log服务器，AAA系统在接收溯源请求后，通过syslog服务器查询动态地址映射关系，完成地址溯源；方案四：AAA与CGN通过网管系统下发参数，并执行相同的端口映射生成算法。在地址溯源过程中，CGN与AAA系统之间不需要传递映射关系，直接实现对地址的溯源。
AAA系统必须根据实际部署需要选择支持上述方案1、2、3、4中的一种或多种地址溯源技术。

8.2 AAA系统溯源改造总体要求
AAA系统由认证服务器、数据库、接口服务器组成，改造后的总体架构如图5所示。
图5、AAA系统改造总体架构
在下一代互联网过渡技术应用场景中，应当增加地址溯源服务器设备，该设备具有以下功能：
l 可以实现与网管系统接口，获取地址、端口映射关系。
l 可以实现根据网管指令创建、保存、维护地址、端口映射关系表；
l 可以实现用户在线地址溯源功能和离线地址溯源功能；
应当增加Log服务器设备，用以接受、解析、保存由CGN设备上报的用户动态端口映射关系，该接口的协议必须根据溯源需求在Radius协议和syslog协议之间选择支持。

8.3 功能要求
8.3.1 静态映射表生成功能
AAA系统可以支持静态映射表保存用户地址映射关系的功能。在选择使用该功能时，AAA系统必须提供地址、端口固定映射关系表的创建、维护、重置功能。地址、端口固定映射关系表用来保存用户主机获得的私有IP地址与各种过渡技术转换后的公网地址及端口的映射关系，例如：以图6为例，用户使用分配的私网地址作为源地址访问Web网站，LSN设备根据地址转换表中预先设定的转换关系，将源地址转换成指定的公网地址和规定的端口。为了保证通过公网地址和端口能够反查用户私网地址，做到用户地址溯源，要求 AAA系统中也必须维护与LSN设备上相同的映射关系表。
图6、地址转换示例
AAA系统映射关系表必须包含以下表项：
l 源地址表项：记录分配给用户的终端地址,可以是单个私有IP地址或一个地址段，可以是IPv4私网地址,也可以是分配给用户端设备的IPv6公网地址；
l 公网地址表项：记录对应私网地址的公网地址；
l 端口号表项：记录对应私网地址的一段端口号，端口号范围必须支持调整，默认端口号范围为1000个。
AAA系统映射关系表可选支持表项：
l 网关设备地址：记录该地址转换对应关系驻留的LSN设备IP地址；
l 用户采用的过渡技术种类编号：标识该私有地址段使用的过渡技术种类，如NAT444、DS-Lite等。
AAA系统溯源服务器必须提供网管接口，接收网管的地址表生成相关指令，生成映射表；必须提供对部分表项（可以是一条或多条）的增加、修改、删除、检索等功能；必须提供对整表的备份（导出）、恢复（导入）、删除等功能。
AAA系统可以支持从网管接收一个算法及其相应参数，并自动生成该表的所有表项。

8.3.2 动态映射关系获取功能
AAA系统可以支持Radius协议上报的方式从CGN设备获取用户地址/端口动态映射关系，该映射关系上报可以通过Radius协议的上线计费包、中间计费包、下线计费包携带私有属性的方式实现，私有属性的定义详见表2。
AAA系统可以与Log日志服务器交互获取日志服务器上保存的用户地址端口映射关系，AAA系统与Log日志服务器可以采用Web Serice方式，报文格式可以采用XML方式。

8.3.3 地址池选择功能
在接入网关设备上维护有公网地址池和私网地址池，给用户分配地址时可以通过给用户分配私网地址并启用地址转换方式接入用户，也可以直接给用户分配公网地址。AAA系统可以支持根据用户帐号相关业务信息，通过扩展Radius属性（第26号属性，见表2）支持控制网关设备分配用户的地址类型。
AAA系统可根据业务要求，选择实现该功能。

8.4 接口要求
8.4.1 与网管系统接口
与网管系统接口主要实现与网管系统的交互，获取并维护地址、端口映射关系表。接口规范参见《过渡技术的网管技术规范》。名称待定

8.4.2 与外部溯源请求系统接口
溯源接口提供外部系统（有溯源需求的系统）与AAA系统溯源服务器的交互接口，实现用户的在线和离线溯源功能。
在线溯源接口采用指令方式进行交互，接口指令可以采用如下的格式：
l 交互指令由UDP协议封装，并采用XML文本格式记录指令：
l XML标记定义如表3所示：
表3、用户溯源接口XML标记定义表
标记
含义
特定取值定义
备注
<cmd> </cmd>
标记整个指令

<cmd_head> </cmd_head>
指令头信息

含指令时间戳、收/发端标识、指令类型等
<time> </time>
指令时间戳

<from> </from>
指令发端IP地址

<to> </to>
指令收端IP地址

<cmd_type> </cmd_type>
指令类型
查询请求：UserAcquire；
查询响应：UserAcquireRes
查询请求/查询响应
<cmd_body> </cmd_body>
指令体

<IP_address> </IP_address>
IP地址

可以是IPv4或IPv6地址。可以在查询请求中出现，表示公网地址；也可以在查询响应中出现标识用户地址
<port> </port>
端口

<userID> </userID>
用户帐号信息

在线地址溯源示例如下：
1)、查询请求指令：
<cmd>
<cmd_head>
<time>XXXX:XX:XX</time>
<from>XXX.XXX.XXX.XXX</from>
<to>XXX.XXX.XXX.XXX</to>
<cmd_type>UserAcquire</cmd_type>
</cmd_head>
<cmd_body>
<IP_address>XXX.XXX.XXX.XXX</IP_address>
<port>XXXXX</port>
</cmd_body>
</cmd>
2)、查询响应结果：
<cmd>
<cmd_head>
<time>XXXX:XX:XX</time>
<from>XXX.XXX.XXX.XXX</from>
<to>XXX.XXX.XXX.XXX</to>
<cmd_type>UserAcquireRes</cmd_type>
</cmd_head>
<cmd_body>
<IP_address>XXX.XXX.XXX.XXX</IP_address>
<userID>XXXXXXXXXX</userID>
</cmd_body>
</cmd>

离线溯源接口采用文件方式，外部溯源平台可以将溯源指令编辑于文本文件中，并通过FTP方式上传到AAA系统的地址溯源服务器指定目录，地址溯源服务器提供相应的执行指令，在系统中进行查询，并将查询结果以文本文件方式存放到指定的目录中，外部系统可以通过FTP方式将结果文件取出。

8.4.3 与Log服务器接口
与Log服务器接口，实现从Log服务器获取用户动态地址/端口映射关系，其接口可以采用Web Serice接口方式，其传递的信息采用XML格式。可以选用表4的接口定义：
标记
含义
特定取值定义
备注
<cmd> </cmd>
标记整个指令

<cmd_head> </cmd_head>
指令头信息

含指令时间戳、收/发端标识、指令类型等
<time> </t