IPv6背景下运营商用户溯源方案的探讨

程 烨，王 洁，谢 磊

（1.华信邮电咨询设计研究院有限公司 杭州310014；2.中国电信股份有限公司浙江分公司 杭州310001）

1 引言

国际及区域IP地址分配组织IANA、APNIC的可分配IPv4公有地址在2011年已经分配完毕，国内运营商及分支机构IPv4公有地址预计将在2012年底开始陆续使用殆尽。为了保证业务可持续发展，运营商将根据不同的场景在IP城域网内部署IPv4向IPv6的演进方案，如DS-Lite、NAT444等，相应城域网内用户侧IPv6、IPv4私有、IPv4公有地址可能同时并存，是否能够提供有效、合规的用户溯源解决方案将是相关方案落地以及IPv6商用与否的关键。

本文将结合监管当局及运营商溯源要求，对运营商IP城域网内3类主流溯源方案及部署方式进行探讨。

2 溯源需求及运营商用户溯源现状

2.1 溯源简介

溯源通常是指寻找网络事件发起者的相关信息，通常用于网络攻击、非法内容传播时对发起者的查找，将溯源追踪信息关联到管理实体的注册信息，从而定位到具体人或单位。

（1）政府溯源需求

国家颁布相关政策要求针对恶意攻击行为（DDoS)、互联网非法、庸俗内容的传播进行监控，如国务院及相关部门相继公布了《互联网信息服务管理办法》、《互联网IP地址备案管理办法》等监管法规。

（2）运营商溯源需求

运营商在应对DDoS攻击及非法内容的传播等事件上遭受着较大的公众舆论压力和政策监管压力，需具备相应的技术、管理等手段对其进行及时的发现和准确详细的分析，并提供相应的原始记录信息来分析、取证和定位最终攻击、传播的来源。此外，运营商还可通过用户溯源来满足用户行为分析、增值业务开放等的运营需求。

综上所述，溯源主要分为基于网络安全应对的溯源和基于监管运营需求的溯源两大类，前者可以通过引入IP溯源技术（包括入方向过滤、数据分组标记、iTrace、日志记录及链路测试等）以及部署DDoS攻击溯源系统、信息内容安全系统等安全类平台予以应对；后者则需要通过改造业务控制层设备及AAA、网管等系统或引入log日志系统等对用户实现精确溯源，本文聚焦于后者，关注基于监管运营需求的溯源方案的实现及部署。

2.2 运营商用户溯源实现

对于IP城域网内用户溯源，国家信息安全监管要求较为明确，即要求实时或准实时根据指定的IP地址（如访问非法网站等的IP）来追溯相应的用户信息，一般可以由运营商侧相应的认证计费后台系统通过镜像或分光将相应的用户信息数据分组（如账户、源IP地址等）导出至监管当局后台关联分析，以实现互联网管控追溯。对于运营商侧用户溯源具体实现而言，则涉及IP城域网各层面设备及认证计费后台系统的联动协同，从而能够实现用户的溯源。

以某运营商IP城域网内用户溯源为例，简单说明实现过程。

首先，宽带接入设备（DSLAM、交换机、PON等）基于用户和业务分别标识PVC、VLAN及SVLAN，由直挂业务控制点的交换机最终标识VLAN（专线用户）或SVLAN（公众用户），BRAS识别并提取双层VLAN信息，以统一的NAS-PORT-ID属性通过RADIUS属性报文向RADIUS服务上报端口信息（包 括 NAS_IP、port、sub port、port_type、SVLAN ID-VLAN ID等），BRAS与 AAA、CRM等配合实现对接入用户的精确化绑定。

其次，AAA形成并保存用户数据表(含IP地址、账号等信息)，溯源查询系统基于公有IPv4源地址对AAA发起查询，由AAA负责查找IPv4源地址和对应的用户ID，从而实现用户溯源。

以上主要为固网分配公有IPv4地址的用户溯源实现的简介，对于移动网分配私有IPv4地址的用户则一般由运营商自行建设日志系统（记录并保存私、公有IP地址、账号等关联信息表）来实现用户溯源，本文不再赘述。

2.3 IPv6背景下溯源面临的挑战

2011年底，我国政府明确了未来发展下一代互联网的路线图和主要目标，提出2013年底开展IPv6小规模商用试点，2014年至2015年开展大规模部署和商用。这一利好消息极大推动IPv6产业链的成长与发展，运营商IPv6试点及商用进程得到进一步提速。

随着运营商IP城域网主流IPv6演进方案，如DS-Lite、NAT444等的部署，由于不同方案的关键网元如CGN、AFTR等设备形态的多样性及部署层面的差异、用户侧地址种类复杂 （IPv4私有地址、IPv4公有地址、IPv6地址）等因素，用户溯源难度加大。现有溯源方案暂只能支持溯源至某用户IPv4公有地址、某一对多私有地址用户接入网关侧WAN端口的IPv4公有地址，不能很好地实现IPv6背景下各类IP地址、端口号与用户账号等信息的关联绑定，不足以支撑“精确溯源、落地至户”的监管要求，亟需基于技术演进及方案部署实际考虑引入合适的溯源方案，保证基于IPv6下一代互联网发展初期就进入合规有序的发展轨道。

3 运营商用户溯源方案

基于溯源网元组成、溯源流程及机制的差异，目前运营商IP城域网中主要存在Syslog方案、RADIUS动态上报方案、静态映射关系算法方案3类溯源解决方案。

3.1 方案一：Syslog日志方案

该方案日志系统可分为日志采集处理模块和查询模块（可合一或者分别独立设置），通过Syslog协议（端口号514）承载NAT444/AFTR网关设备吐出的标准log日志信息 （可由用户每次接入或下线的session触发），在Syslog服务器上保存公私有地址、端口号等信息的映射关系表，AAA中保存IPv4公有地址、IPv6地址等信息记录表，若查询IPv6地址，可直接查询AAA获得；若查询IPv4公有地址，则AAA首先发起向Syslog服务器的请求，查询IPv4源地址、源端口与IPv6源地址的对应关系，再在AAA本地查找与IPv6源地址对应的用户ID，完成溯源。其中BRAS及AAA应支持IPv6相关RADIUS属性的拓展，NAT444/AFTR网关设备应支持标准Syslog日志的生成。用户溯源方案如图1所示。

该方案适用性较好，在运营商网络上已有类似方案部署（解决IPv4私有地址用户溯源问题），需新增日志服务器（一般独立设置，与AAA及AFTR相关设备配合共同实现用户溯源），但不需要对网管系统进行改造，相应的溯源流程基本不变。

以部署DS-Lite过渡技术方案（B4为DS-Lite硬终端或软终端模块；AFTR为DS-Lite网关设备，可以板卡内嵌或独立设备旁挂在城域网设备上）的IP城域网为例，相应的用户溯源交互流程如图2所示。

其他方案的溯源交互流程与上类似，主要在于交互的网元、交互的内容有所差异，不再赘述。

3.2 方案二：RADIUS动态上报方案

该方案主要通过BRAS与AAA 系统的RADIUS协议交互在AAA形成统一的地址映射表 （记录在线用户信息，包括账号、私有IPv4地址、公有IPv4地址+端口块、IPv6地址等），其中BRAS需通过改造支持RADIUS属性拓展（增加相关IPv6属性）来完成用户地址映射信息的上报，AAA需改造支持Radius属性拓展及映射表增加新属性字段，同时升级与业务平台的查询接口，以便实现在线查询及离线查询。RADIUS动态上报方案如图3所示。

RADIUS属性拓展至少包括两部分。

第一部分：支持RFC 3162和RFC 4818规定的7个IPv6 属 性 ， 如 N AS-IPv6-Address、Framed-Interface-Id、Framed-IPv6-Prefix、Login-IPv6-Host、Framed-IPv6-Route、Framed-IPv6-Pool、Delegated-IPv6-Prefix。

第二部分：补充若干运营相关的属性，即增加能够区分主机用户或家庭网络用户的用户属性（通过认证判断后下发给BRAS，以便相应分配不同类型的地址）、区分流量类型的流量属性（判断IPv4或IPv6流量，以便分别计费）等。

该方案中较适合采用BRAS插卡 （NAT444或AFTR板卡）分布式部署的城域网，日志服务器及网管服务器无须增加或改造，相应的溯源流程基本不变。

3.3 方案三：静态映射关系算法方案

该方案主要是针对NAT444/AFTR网关 （BRAS/CR插板、独立设备）、AAA及网管进行算法定制化开发，通过网管下发算法至相应网关、AAA服务器等，由各网元基于各自预先配置的算法参数 （包括私有IPv4地址范围、公有IPv4地址范围、端口块大小、端口范围、网关设备ID等）进行本地计算生成相应的IP地址、端口号等的映射关系。各网元改造要求如下。

·NAT444/AFTR网关应改造支持基于用户/Session的端口块分配及标准日志输出，支持算法计算（根据预先配置或Telenet协议远程下发的地址信息参数，计算公、私有地址映射关系，预留NAT资源）。

·BRAS应改造支持算法计算（仅限于BRAS插板部署方式，若NAT444采用集中式部署BRAS无需改造）。

·AAA需要增加维护NAT设备的地址信息参数表和实时计算映射关系两项功能，提供相应的查询接口。

·IP网管应改造支持算法安全可靠 （具有算法校验机制）下发配置或配置脚本。

静态映射关系算法方案如图4所示。该方案适用性较广，不需新增日志服务器，但需要相应网元（如网关、AAA、网管等）设备做相应的改造升级支持定制化的算法，相应的溯源流程基本不变。

4 IPv6背景下用户溯源方案选择及建议

4.1 主要溯源方案比较

3类溯源方案比较见表1。

表1 IP城域网用户溯源主要方案比较

综上所述，Syslog日志方案适应度较好，但涉及新增Syslog网元相应的网络架构需要联动调整，主要难点在于日志系统自身的可靠性及相对复杂的溯源流程，对于IPv4和IPv6地址用户的溯源流程有所差异，需要AAA联动Syslog系统相关信息来完成溯源；RADIUS动态上报方案与现网溯源较为类似，主要难点在于现网BRAS及AAA对于RADIUS扩展属性的支持；静态映射关系算法方案能够适应各类NAT444网关不同部署的IP城域网，可满足近远期各类场景的要求，主要难点在于算法是否科学合理及设备、系统对于算法的支持能力，在算法可靠性、厂商支持度、维护复杂度等方面还有不确定性。

4.2 溯源方案部署建议

尽管IP城域网向IPv6演进存在不同的方案，但溯源方案与演进方案为松耦合关系，不同的演进方案可以选择同一溯源解决方案，也可采用不同的溯源解决方案。

选择及部署溯源方案的关注点可以从方案自身的成熟度、IT特别是AAA等支撑系统的改造难度、部署的难易度等方面来考虑。

基于对3种溯源解决方案的对比分析，在运营商IPv6小规模商用阶段建议优先考虑开发周期短、对IT改造要求较小，能够快速在现网部署的Syslog日志方案，后续随着RADIUS扩展协议、静态映射算法等的成熟以及厂商相应设备的支持可结合各地IP城域网的实际情况引入和部署。

5 结束语

随着国家政策层面下一代互联网发展政策的明确，国内各大运营商IPv6试点及商用进程开始加速，各类演进技术如NAT444/DS-Lite等方案的落地取决于用户溯源方案可行与否，为此在相应方案选择和部署中务必注意用户溯源涉及相关设备、系统的衔接配合，初期可结合设备成熟度选择易于部署、满足监管基本要求的溯源解决方案，后续可随着技术成熟、监管政策明晰逐步进行优化调整和改造。

相信在较好解决IPv6背景下运营商用户溯源的问题后，基于IPv6的下一代互联网将迎来快速、健康发展的春天。