运营商在部署IPv6网络和业务中需要关注的问题
运营商在部署IPv6网络和业务中需要关注的问题
摘要：本文基于作者在IPv6部署实践中的经验，针对有线宽带业务用户接入上网流程中的各个环节涉及到的PPP、NDP/SLAAC、DHCP和Radius所面临的问题进行论述，并提出了相关的解决方案建议。
关键词：业务，有线宽带，认证，授权，计费
作者：胡捷，中国电信股份有限公司北京研究院，高级工程师
由于全球IPv4地址即将耗尽，运营商必须尽快采取措施解决因地址不足对用户和业务发展的影响。目前看来，采用IPv6地址替代IPv4，是一种一劳永逸的方法。但是网络和用户在向IPv6迁移过程中需要解决技术、管理和业务等诸多层面的问题，还涉及到全球大的产业环境是否具备、政府是否愿意进行推动等各种因素。所有这些因素都将制约迁移和过渡是否顺利，而且我们还要清楚地看到，过渡阶段会是一个长期持续的时期，绝不会一蹴而就，否则会对用户的使用感受产生冲击。
抛开政策环境、产业现状等外界因素，本文重点关注在工程部署阶段，运营商目前遇到的问题和解决思路。首先，作为国内电信运营商，地址问题是最紧迫的问题，2012年各省公司将陆续出现地址枯竭的情况，采用应对措施已刻不容缓。我们的策略是首先关注运营商提供的业务中，哪一类是消耗地址最多的业务？从这个环节入手将会以最小的代价解决最多的问题。目前中国电信有线宽带用户数量达几千万，而且每年以10%左右的幅度递增，成为消耗IPv4地址最多的业务，因此必须尽快将用户过渡到以IPv6承载的方式中。这其中涉及到应用软件、操作系统、硬件终端、网络、应用及业务平台等几个环节构成的一个完整产业链。
产业链的其他环节暂且不表，作为运营商，唯一可控的是网络，首先必须把自己内部的事情做好，才有可能推动整个产业链整体向前发展。经过了近两年的现网部署，我们发现在网络环节，IPv6仍有部分问题亟待解决。首先从有线宽带用户上网的端到端流程入手进行分析：
用户通过PC或者家庭网关发起PPP虚拟拨号，经过城域网BRAS终结PPP，并将LCP 中的用户名和密码封装在Radius Access-request报文中送至AAA，认证通过后返回Access-accept报文到BRAS，继而BRAS为用户分配地址和其他上网参数，用户开始上网。BRAS将用户地址信息通过Accounting-request报文上送AAA，并统计上网时长和流量，为计费提供原始数据。
这个环节中我们遇到如下问题：
1．需要明确IPv6环境下，用户上网的商业模式问题。IPv4时代，上网主体是PC 终端，早期运营商默认用户开户只有一台PC上网，为开户用户提供一对用户
名和密码即可。后来用户家庭中逐步出现多台电脑，以及包括互联网收音机、
互联网电视机、IPAD，WIFI手机等终端，这些都有上网需求。解决的途径有两
种，一是运营商为每种上网设备提供单独的用户名和密码，为每类上网设备或
上网个体单独收费，或者为一个开户用户打包销售宽带产品，允许同时有两个
或者四个终端上网，具体做法往往是根据用户的资费，允许这个用户同时发起
两个或四个PPP Session。后来由于路由型家庭网关的普及，用户完全可以通过
家庭网关发起PPP拨号，家庭中的所有上网设备可以通过家庭网关作为统一的
出口，实现互联网连接。在IPv4时代，运营商是否认可家庭网关上网，而不再
对内部上网终端数量进行限制，是个很纠结的问题。但是目前的技术手段，对
用户进行数量控制的代价很大。在IPv6时代，家庭网络的概念从一开始就是
V6为我们描绘的应用蓝图，甚至上网设备已经扩展到冰箱、空掉、洗衣机、汽
车等一切你能想象到的电子设备。运营商如何应对商业模式的改变，是一个亟
待研究的课题。
2．PPP协议及相关问题。在IPv4时代，用户上网的所有参数，在PPP协议的NCP 提供全部解决方案。首先PPP的LCP阶段实现用户上网认证，认证通过后进入
PPP的NCP阶段，协商上网需要的终端地址、DNS地址和缺省网关地址，此时
PC终端往往默认开启了DHCPv4 Client进程，但是不会对地址分配起到决定作
用（BRAS侧没有配置DHCPv4 Server，不会响应客户端的discovery和request
请求）。这些参数信息往往在BRAS本地进行配置。V6环境下，最新的PPP标
准RFC5072仅仅建议通过PPP的NCP（IPv6CP）协商Interface-ID，不做其他
额外工作。这个Interface-ID的目的是用来创建终端的Link-local地址用，即后
64位采用NCP协商的ID，前64位采用FE80：：/64。真正上网所需的家庭网
关W AN口/128地址需要通过RFC4861/4862建议的NDP/SLAAC方式或者根据
RA报文M=0置位采用RFC3315建议的Option 5实现有状态DHCPv6方式获得
（同时还要发起RFC3646建议的Option 23实现DNS申请）。此外，家庭网关
还要发起RFC3633建议的Option 26实现Prefix家庭网络的网段地址申请。所
有这些情况，与运营商在IPv4环境下的运维经验产生了很大区别。V6时代，
伴随PPP虚拟拨号以后，终端需要继续通过NDP/SLAAC以及DHCPv6三种协
议的先后启用、交互、协商，才能确保IPv6用户正常上网！导致运营商对支持
V6的家庭网关要提供详细的设备技术指标，对已经部署的BRAS要进行全面升
级才得以支持V6环境下的这些新要求，同时还要考虑如何从BRAS分配IPv6
地址参数过渡到在网络中部署独立的DHCPv6服务器！
3．Radius协议及相关问题。V4环境下，BRAS同时作为PPP Server和Radius Client，Radius协议负责将LCP送来的用户名和密码封装在Code=1的Radius Access-request报文的Attribute 1和Attribute 2/3中上送AAA，经过认证、授权
后AAA返回Code=2的Access-accept报文，BRAS通过PPP的NCP成功为用
户分配了上网参数后，继续发送Code=4的Accounting-request报文，其中一个
Attribute=8的属性（Framed-IP-address，RFC2865）将用户地址信息上送AAA，另一个Attribute=40的属性（Acct-Status-Type，RFC2866）的Value=1表明是一
个计费开始报文，AAA负责将用户名/密码/地址信息进行规整，提供用户在线
信息的关联。用户上网过程中，BRAS继续发送Accounting-request报文到AAA，其中包含Attribute=42/43/47/48的属性（RFC2866）和Attribute=52/53的属性
（RFC2869）用户统计用户上网流量，为计费系统提供原始数据。V6环境下，经过现网试验，情况有些变化。
a)由于双栈用户的地址分配方式不同，导致双栈用户获得V4和V6地址的时间
不一样，在PPPv4中，NCP一旦协商成功，进入“Up”状态，就会触发BRAS
发送Accounting-request报文；V6环境下，NCP仅协商Interface-ID，进入“Up”
状态后无法上送用户的/128地址信息，AAA无法针对具体的IPv6地址信息判
断用户是否上线，因为无法为IPv6用户统计时长，需要通过RA报文下发/64
前缀，或者通过有状态DHCPv6为用户分配了/128接口地址后，才能发送
Accouting-start报文，此时导致的一个现实问题就是，AAA获得同一个用户的
V4和V6地址信息不同步，上网开始时间如何确定？通过查询，目前IETF还
没有完善的解决措施和建议。我们在现网部署中采用了临时解决方案，即首先
获得一个协议栈地址后，发送Accounting-start（Code=4，Attribute=40，Value=1）
报文通知AAA开始计费，几秒钟后获得另一协议栈的地址后，通过
Accounting-Interim-Update报文（Code=4，Attribute=40，Value=3）上送AAA，
此方式虽然不能满足将双栈协议地址信息同时上送AAA的问题，但至少可以
为AAA提供双栈协议与同一个用户的对应关系，在内存中创建用户在线信息
表，满足溯源要求。曾经想到的解决方案是修改BRAS的Radius实现，在获
得第一个协议栈地址后，先Hold一段时间，待第二个协议栈也“Up”了，再
将两个地址信息封装在同一个Accountig-request报文中上送，但是经过分析，
此解决方案有缺陷（一台BRAS下的用户属性有多种，既有双栈用户，也有
单栈用户，BRAS无法区分一个用户发起PPP后具体是双栈还是单栈用户；此
外，即使是双栈用户，应该允许用户某次上网只拨通单栈）。
b)其实这里有必要提到一个更加细节的问题，就是截止到目前Radius协议中没
有一个公有属性提供对/128地址的上送，我们是通过Attribute=97的
Framed-IPv6-Prefix属性（RFC3162）来实现的（认为Prefix的长度为128），
但是在具体的触发方式上，IETF也没有明确，在SLAAC的RA报文通告出去
后，即使终端自行创建了/128地址，对BRAS来说是无状态的，无法探知终
端具体的/128地址，此时BRAS是无法发送/128地址信息的；在有状态DHCPv6
情况下，BRAS应在在DHCPv6 Reply后触发。
c)Radius协议中目前没有公有属性提供针对IPv6的流量统计。现有的流量统计
属性都是针对一个用户PPP Session中的所有流量。双栈环境下，PPP中有两
个NCP（IPCP和IPv6CP），如果运营商需要根据不同协议栈的流量使用情况
提供不同的计费策略，目前通过公有属性还无法支持。应急措施是采用VSA。
d)Radius为用户认证通过后，AAA本身支持鉴权，可以识别用户是双栈还是单
栈，但是目前没有公有属性下发到BRAS以确保BRAS能够感知用户属性，
从而为不同属性的用户实现不同的地址分配策略。具体来说就是，对于一个
V4-only用户，如果终端操作系统是Win7，发起PPP拨号后用户默认也会发
起IPv6CP协商，由于BRAS无法判断用户是否是合法V6用户，没有机制拒
绝为终端分配V6地址。目前只能通过私有属性来下发到BRAS，采用Profile
ID的方式，调用BRAS本地生效的Profile，为V4-only用户只分配V4地址。
以上介绍的就是我们在V6部署过程中发现的问题，这里只是针对有线宽带业务，例举了一部分涉及到协议、我们采用变通方式可以解决的问题。所有这些问题只能在生产网络中去实践才能发现。通过在IETF查询相关文档，中国电信在V6网络和业务开展领域发现的问题，很多是业界首次，我们一直致力于在IETF提出问题并寻求解决方案（draft-hu-pppext-ipv6cp-requirements-01：PPPv6 Problem statement and requirements；draft-hu-pppext-ipv6cp-extensions-01：PPP IPv6 Control Protocol Extensions；draft-hu-v6ops-radius-issues-ipv6-01：RADIUS issues in IPv6 deployments）。我们相信，真正彻底、完善的解决，必须通过IETF走标准化的道路，才能促成整个产业界的推进。
胡捷：曾参与中国电信CN2技术方案制定和中国电信城域网优化方案制定。目前关注下一代互联网部署现网试验的总体技术方案编制，涉及骨干网、城域网、移动分组域、IP/IT支撑系统的全方位升级过渡策略实施，以及有线宽带、无线宽带、VPN、IDC和中国电信自营业务的引入策略制定。
身份证号码：110108************
电话：189********
通信地址：北京市西城区西直门内大街118号708房间
单位：中国电信股份有限公司北京研究院
邮编：100035