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的下一代互聯網將迎來快速、健康發展的春天。