马晨昊/MA Chenhao,解冲锋/XIE Chongfeng,郑伟/ZHENG Wei,李聪/LI Cong
(1.中国电信股份有限公司研究院,北京 102209;2.中国电信股份有限公司江苏分公司,江苏 南京,210037)
(1.China Telecom Research Institute, Beijing 102209, China;2.China Telecom Jiangsu Branch, Nanjing 210037, China)
作为新一版互联网网络层协议,IPv6在全球受到越来越多的重视。根据谷歌最新统计,现在全球约有30%的用户开始使用IPv6,其中以欧美发达国家的IPv6发展最为领先。在2016年,IETF就发表声明,要求新的协议制定或协议扩展不要兼容IPv4,而要基于IPv6。在中国,自从2017年底中共中央办公厅和国务院办公厅发布IPv6行动计划发布以来,在运营商和OTT(指互联网公司越过运营商)等产业各界的协作下,中国IPv6发展迅速,分配了IPv6地址的用户数、IPv6活跃用户数和流量增长迅速。与此同时,作为新一代移动通信技术,5G也处于商用化部署的关键期。选择合适的网络协议和最佳功能配置是发展5G的关键。5G和IPv6是构建中国新一代信息基础设施的两项重要技术支柱,它们在新时期的相遇和融合,是信息技术发展的必然。幸运的是,在3GPP标准设计和设备实现上,5G已能良好地支持IPv6协议;但是5G网络引入IPv6协议的技术路线,在3GPP的相关标准中并没有详细和明确的说明。例如,如何发挥IPv6的技术优势来提升网络的综合能力?如何处理IPv6和IPv4的关系?等。5G网络引入IPv6涉及端、管、云等多个环节,如果处理不好,会对未来5G网络甚至互联网的发展产生不利影响。在5G SA部署过程中,是延续传统继续部署双栈,还是破旧立新,直接采用IPv6单栈?针对以上问题,本文中,我们在分析5G网络引入IPv6面临的挑战的基础上,重点介绍和分析了不同的IPv6过渡方案,特别论述了5G SA网络用户面引入IPv6单栈的新型技术方案,并对其组网架构、冗余备份、端口映射和溯源方案做了详细介绍。在以上论述的基础上,提出了运营商选择IPv6演进路线的策略建议。
5G引入IPv6主要涉及3个层面:用户面、控制面和承载面。用户面是与用户数据传输相关的层面,它直接面向用户终端并直接为用户提供接入服务,是IP地址消耗最大的层面;控制面是指核心网设备之间的互连并且进行核心网协议交互的层面;承载面是指城域网、骨干网等用于承载控制面和用户面的网络。每个层面都涉及到IPv6引入,策略上也会有所不同。考虑到篇幅因素,我们主要讨论用户面的IPv6引入问题。5G引入IPv6时,所使用的技术方案原则上不影响5G原有功能和性能,并且尽可能发挥IPv6的技术优势来创建能力更高、成本更低的网络。当前5G引入IPv6的需要考虑如下几个因素:
1)海量多业务承载。5G需要承载的业务更加多样,不仅支持传统的宽带上网业务,还要支持物联网(IoT)、移动边缘计算(MEC)、车用无线通用技术(V2X)等新兴业务,这主要对IP网络层提出IP地址数足够多、连接足够多、业务保持高稳定互通的要求。
2)高性能保障。5G网络性要求更为苛刻,同时4K/8K高清视频、远程医疗、云游戏、远程驾驶、工业控制等增强移动宽带(eMBB)/超可靠低时延通信(URLLC)应用需求也日趋紧迫,它们对网络提出了超低时延、超大带宽的要求。而这些性能需求与网络用户面紧密相关,需要用户面提供高效的数据处理和转发。
3)安全可溯源。由于面向的场景更加多样,5G的连接数将会达到一个较高的数量级,所传递的内容也将更为复杂。出于安全考虑,用户面须提供完善的寻址方案和溯源方案,以确保用户和终端的访问行为可追溯。
目前中国的IPv6部署主要采用双栈方式。网络给用户终端分配和维护IPv4地址和IPv6地址[1],支持IPv6业务和IPv4业务的访问,两种协议逻辑上独立。由于当前IPv4地址极其稀缺,因此移动网络通常给用户分配私有IPv4地址,并在网络中部署支持网络地址转换(NAT)的设备进行公私有地址的转换。随着时间的推移,双栈技术方案也日益暴露其缺点,例如:双栈并没有解决地址不足问题,有些场景下用户的私有地址也发生冲突;此外,双协议栈的维护成本高等。
IPv6单栈方案是以IPv6为基础协议建立的终端编址和业务承载体系。该方案构建在翻译技术的基础上,在终端只有IPv6地址的情况下,支持对IPv6和IPv4业务的访问。该方案的核心是NAT64/DNS64(DNS指域名系统)技术。NAT64[2]是一种有状态的网络地址与协议转换技术,用于IPv6客户端和IPv4业务端传输控制协议(TCP)、用户数据报协议(UDP)、Inernet控制报文协议(ICMP)下的 IPv6与IPv4网络地址和协议转换,实现只拥有IPv6地址的终端发起连接访问IPv4侧网络资源。
在IPv6单栈网络中,终端从网络侧只获得IPv6地址,终端上存在支持IPv6的应用客户端,也存在只支持IPv4的应用客户端。如图1所示,当终端发起连接访问普通IPv6网站或其他服务器时,流量将会匹配IPv6默认路由并直接转发至IPv6路由器处理,正常访问IPv6网络中的资源。
当客户端去访问只支持IPv4协议栈的网站或服务器时,其目的IPv4地址需要由DNS64[3]服务器添加IPv6前缀Pref64来合成IPv6地址。其过程为:终端向支持DNS64的DNS递归服务器发出AAAA类解析请求时,如果权威服务器返回的记录为RCODE=3(名字错误,表示请求中的域不存在),说明该域名对应的服务器为IPv4单栈服务器。此时DNS64继续查询,发出A类请求查询,并获得A类查询结果。DNS64支持将DNS查询信息中的 A记录(IPv4地址)合成到 AAAA记录(IPv6地址)中,即为IPv4 应用服务器的IPv4地址通过添加IPv6前缀Pref64映射成了IPv6地址,并将生成的AAAA类结果返回给客户端。
在有些情况下,IPv4网络侧的IPv4地址没有经过DNS64的处理直接到达IPv6单栈客户端里。此时,支持RFC7050协议[4]的DNS64服务器会把前缀Pref64下发至终端,终端可使用本地合成前缀的方式将目的IPv4地址合并成IPv6地址。
在获得AAAA类的解析结果后的该流量将被路由转发至NAT64路由器上,IPv6与IPv4地址和协议在NAT64上进行合成转换,从而实现访问IPv4网络中的资源。需要补充说明的是,NAT64设备中将IPv4地址合成IPv6地址采用的前缀Pref64与DNS64中采用的合成前缀Pref64是一致的。
结合3GPP的5G标准[5]和IPv6单栈的思路,我们建议的组网方案如图2所示。在IPv6单栈接入的环境下,终端只被分配了IPv6地址。为了支持IPv6单栈终端访问支持IPv4协议的网站或者应用,在5G的用户面功能(UPF)位置部署支持NAT64设备,并在部署的DNS服务器上升级支持DNS64和RFC7050协议,通过IPv4和IPv6翻译实现对于IPv4网站或者应用的访问。对于NAT64和DNS64的部署方式,NAT64的部署可采取分布式、集中式或混合式。我们建议运营商根据实际需求选择具体部署方式。
在实际的部署中NAT64存在两种形态:插卡式NAT64设备和具备NAT64功能的专用设备。它们的部署方案也因此略有不同,具体介绍如下:
1)插卡式NAT64设备。插卡式NAT64方案如图3所示,NAT64板卡插于用户边缘路由器(CE)路由器上。正常状态下,板卡之间负载分担,若一块板卡发生故障,正常板卡承担全部业务。设备的冗余建议采用热备的方式备份,并且配置一致,同步NAT64会话信息,主备切换后用户无感知。在寻址和路由方面,我们建议不同的CE配置不同的IPv4地址池,配置相同的IPv6合成前缀Pref64。在IPv6侧发布相同的IPv6合成前缀Pref64,在IPv4侧由于IPv4地址池不同,因此发布不同的IPv4路由。
2)具备NAT64功能的专用设备。专用设备方案如图4所示,建议将设备侧挂于CE上路由器,设备之间通过接口互联。设备的冗余采用“1+1”的方式,正常状态下两台设备之间负载分担,若一台故障,另一台设备提供冗余。两台设备间通过热备方式备份,并且同步NAT64会话信息,主备切换后用户无感知。在寻址和路由方面和上述方案一样,主备设备配置不同的IPv4地址池和相同的IPv6合成前缀Pref64,相互备份的两台NAT64设备在IPv6侧发布相同的IPv6合成前缀Pref64,在IPv4侧发布不同的路由。
NAT64功能除了用上述的专用硬件方式实现外,也可以采用虚拟化技术来实现。虚拟化NAT64的组网方案和物理设备的功能相同,和其他设备的互连接口也相同;不同之处仅在于NAT64功能在虚拟机上实现,考虑到篇幅,在此不做详述。
图2 5G 独立组网网络架构图
图3 插卡式NAT64/运营商级NAT(CGN)方案
图4 专用的NAT64设备方案
由于IPv4资源稀少,因此在NAT64中用户的IPv6地址和IPv4地址并不是一一对应的。通常情况下,多个用户共享复用单个IPv4地址,此时需要进行地址变换和端口层面的映射,并动态建立映射会话。基于端口级建立映射会话,在溯源系统中需要存储大量的用户连接信息表。这会对NAT64设备、溯源系统以及设备间的交互接口都带来很大的压力。
为了减小溯源日志的数据量,我们建议使用用户动态分配“IPv4地址+端口段”(简称“IPv4端口段”)的方式,即采用用户IPv6地址和IPv4端口段进行动态映射的方式,将映射从端口级提到端口段级。具体方式列举如下。
1)当IPv6终端发起访问IPv4应用的请求时(数据上行):
(1)对于目的IPv6地址,在NAT64中做IPv6和IPv4协议和地址转换,此过程为无状态;
(2)对于IPv6终端的源地址,在收到用户终端发出的首个数据包时,NAT64为源IPv6地址从资源池中动态选取一个可用的IPv4端口段,将源IPv6地址变换为该IPv4端口段所在的IPv4地址,并将该IPv6数据包及后续使用该IPv6地址的数据包的源端口变换为该IPv4端口区间内的端口,利用该端口段在NAT64中建立和维护TCP和UDP的会话映射,在使用完毕后释放该IPv4端口段。
2)当数据流返回时(数据下行):
(1)对于目的IPv4地址,根据NAT64设备中的映射会话将目的地址从IPv4转换成IPv6地址,同时进行端口和协议的转换;
(2) 对 于 源IPv4地 址,在NAT64中添加NAT64的映射前缀Pref64,做IPv4到IPv6地址和协议的转换。
此外,为了支持从IPv4访问IPv6的需求,我们建议NAT64需要同时支持通过手工配置静态映射关系,实现IPv4网络主动发起连接访问IPv6网络。
IPv6单栈对5G网络漫游的影响可以从两个场景来分析:运营商内的省间漫游和出国漫游。对于第一种场景,运营商在各省的网络均具为IPv6单栈配置,因此漫游用户在不改动终端配置的情况下可以使用IPv6单栈省份的环境,此时对于本地路由、回归属路由都没有特别要求;对于第二种情况,如果被访地的运营商网络不是IPv6单栈,此时终端可自动开启双栈模式,这样可以使用非IPv6单栈的网络环境访问互联网。
在5G IPv6单栈环境中,由于NAT64目前采用的是有状态转换方式,在设备的运行过程中,NAT64设备需要实时保持IPv6地址和端口与IPv4地址和端口段间的映射关系。为了支持访问溯源,我们建议将NAT64中映射表同步至日志服务器。
溯源方案如图5所示,在5G IPv6单栈网络中建立地址转换日志系统,其中包括SYSLOG日志服务器、数据采集设备、溯源查询服务器。多个服务器协同实现整个用户溯源的流程,数据采集设备采集用户和访问日志信息,NAT64设备上传用户地址转换记录,两个信息相关联形成可供溯源功能的日志。NAT64地址转换日志系统根据需求对现有系统进行相应扩展,完成用户地址映射信息的SYSLOG方式采集。此外,地址转换系统应能够满足用户级的地址映射信息采集的功能和性能要求。
溯源系统的查询过程就是通过给定的公网地址+端口号、映射关系建立的时间戳等信息来查询用户的源IPv6地址。这个源IPv6地址在IPv6单栈网络中是用户终端的公网IPv6地址。
IPv6单栈是网络发展的国际趋势。微软、谷歌、苹果和思科等支持IPv6单栈的发展,特别是谷歌和苹果等在其iOS和Android终端产品中很早就实现了IPv6单栈的支持,即在给终端分配IPv6单栈地址的情况下,也可完成原有双栈的功能。在运营商方面,T-mobile、Sprint、Reliance Jio、Orange、SK、Telstra和Rogers等在4G时期就已经部署或者试验了IPv6单栈技术;但在中国,对于IPv6单栈技术的规模验证仍然缺乏,因此需要加强规模部署的研究和现网实验。
IPv6单栈方案也可以解决网络中IP地址不足带来的编址问题。在传统网络中,不仅公有IPv4地址被耗尽,而且私有IPv4地址也紧缺,甚至会发生私有地址复用的现象。新兴业务如IoT、V2X和MEC等,对于编址提出了更高的要求,需要采用IPv6来解决编址问题。从双栈演进为IPv6单栈方案,在运维方面简化了网络管理,减少了访问控制列表(ACL)、路由配置和管理工作量。在安全方面,单栈替代双栈,减少协议暴露面,降低了安全风险。终端采用唯一的公有IPv6地址也增强了溯源能力。
在当前激烈的市场竞争中,运营商注重业务的互通性和用户的体验。在设备能力具备及部署合理的前提下,IPv6单栈技术方案可满足运营商这方面的要求。我们建议运营商根据自己的IPv4地址富余量、产业情况、政府政策及终端支持等因素综合考虑来选择路线。下面对IPv6单栈技术与IPv4/IPv6双栈技术的分析对比,具体如表1所示。
图5 日志溯源系统组成示意图
表1 双栈方案和IPv6单栈方案的对比
移动网络只给终端分配IPv6地址。在单IPv6地址的情况下,移动终端不但能支持IPv6单栈业务,也能支持对IPv4/IPv6双栈及IPv4单栈业务的访问,使用户体验不会因为没有IPv4地址而发生变化。需要说明的是,IPv6单栈技术本身不提倡广泛使用NAT64,而是希望实现NAT64转化的流量在总流量中的占比越来越少,而端到端的IPv6流量占比越来越大,因此使OTT的业务向IPv6进一步迁移。本文中,我们对5G引入IPv6的思路进行了探讨,介绍了IPv6单栈下5G的基本技术、组网方案、映射和溯源方案,为5G运营商的IP网络演进技术路线的选择提供参考。5G IPv6单栈化将是网络向IPv6演进的重要一步,除了技术的因素外,OTT企业和运营商各方的协同合作也是最终关键的关键。
致谢
本研究的实验工作得到了国家下一代互联网工程中心李震博士的协助,在此谨致谢意!