金融行业IPv6的改造转型之路探讨？

   根据人行、银监等监指导意见，截至 2019 年底，金融服务机构完成本单位总部及下辖机构门户网站 IPv6 改造工作，并在其首页标识该网站已支持 IPv6 。除有用户权限登录控制的定制应用系统外，门户网站主域名内全部静态页面、动态页面、多媒体资源和第三方应用插件等均支持 IPv6 连接访问；页面链接的全部子域名网站均完成 IPv6 改造。
    IPv6 改造行业示范机构至少选择一个活跃用户规模在本机构内排名前 3 位（含）的移动 APP 应用系统，使其支持 IPv6 连接访问，并在其首页标示该应用已支持 IPv6 。 到 2020 年底，金融服务机构完成所有面向公众服务的互联网应用系统相关软硬件基础设施的升级改造工作，所有软硬件基础设施均支持 IPv6 协议。 金融服务机构所有面向公众服务的互联网应用系统，全部支持 IPv6 连接访问，并保证在 IPv6 和 IPv4 环境下，具备同等的业务连续性保障能力。
    面临问题
    如何保证在国家或监管机构的规定时间内完成全部业务平台的改造，并对外提供 IPv6 服务？
    如何保证在规定时间内完成全部设备的更换，满足双栈要求？
    如何预估开通双栈后原有的设备是否能够满足开通双栈的性能要求？如何保证开通双栈后， IPv4 和 IPv6 互不影响？如何保证 IPv4 与 IPv6 数据的同步？
    使用过渡技术如何保证页面的完整性，网站主域名内全部静态页面、动态页面、多媒体资源和第三方应用插件等的 IPv6 连接访问？
    过渡技术能否支持页面链接的全部子域名网站升级？能否支持本网站引用的外部链接可访问、内容可呈现？能否支持所有面向公众服务的互联网应用系统的 IPv6 连接访问？
    过渡技术如何保证业务系统，包括网络银行、手机银行 APP 等对外服务平台的 IPv6 改造后的业务保障能力？
    如何保证升级后的应用系统能够支持业务系统的密码验证功能（ Ukey) 、能够支持 Http 、 Https 地址溯源、能够支持 IPv4/IPv6 网络切换会话保持？
    过渡技术能否保证网络 IPv6 升级的递进式推进，实现应用系统改造及软硬件基础设施升级相结合，延长原有设备的生命力，从而保护已有网络资源及设备的投资？
    应对策略
    金融行业的 IPv6 改造是一项长期工作，针对目前 IPv6 部署困境，国家提出支持采用网络过渡技术创新方式。要全面、妥善地解决以上普遍存在的问题，建议按照路线图的安排，分步骤、分区域逐步实现对所有系统的 IPv6 改造。
    在过渡初期，通过 NAT64 等技术，在短时间内快速实现业务平台对外提供 IPv6 服务。解决双栈化升级周期长、难度大的业务痛点。
    过渡中期， IPv4 与 IPv6 需要并存很长时间，有计划地改造业务平台软件以及数据库、 Web 服务器等支撑系统，部分对外提供纯 IPv6 服务的系统，也可通过 NAT64 做地址翻译，为 IPv4 用户提供服务，逐步实现全部平台均具备对外提供纯 IPv6 服务的能力，保证 IPv4 与 IPv6 数据的同步性。在过渡期，还有很多 IPv4 应用会出现难以升级，无法升级，或无法找到原厂升级等众多情况，这些无法升级的 IPv4 应用，也可以长期使用 NAT64 技术做转换服务。
    过渡后期，很多应用为开发便利，以单栈 IPv6 开发并发布，也可以将 IPv6 应用翻译成 IPv4, 为留存的 IPv4 用户提供访问服务。

目前来说，主要是全局负载均衡与本地负载均衡厂家在进行配合与测试。

主要是分四个阶段进行：
第一阶段：公网逐步改造，公网逐渐进行IPv6的替换，此时应用交付可以通过NATPT(NAT44/NAT64)可实现将IPv6向IPv4自动切换，首先AD上发布IPv6业务地址，用户内网不做改动，适应运营商骨干网的业务改造。
第二阶段：内网逐步改造，内网逐渐进行IPv6的替换，业务内网并存IPv4和IPv6服务器，此时应用交付可以通过NATPT（NAT44/NAT66）实现IPv4和IPv6的业务转换，可同时兼容内网双栈改造。方便用户将IPv4、IPv6业务逻辑分离，可看出IPv6的业务分布情况和客户端流量等，便于服务器审计
第三阶段：内网改造完成，内网业务系统全面切换到IPv6，此时应用交付可以通过NATPT（NAT46/NAT66）可兼容骨干网上未改造完成的IPv4业务。
第四阶段：内外网完全改造，内网完全完成IPv6的替换，此时应用交付可以通过NATPT（NAT66）实现最终改造完成。

改造方式主要是2种：
改造方式一：在整个互联网出口边界最外侧进行改造，从运营商引入IPv6出口，增加网站域名对应IPv6地址的域名解析。在出口增加两台负载均衡做IPv6改造,将新增的IPv6线路连接到新增的负载均衡设备上，使用NAT-PT技术将访问业务系统的IPv6报文转换为IPv4报文,保证从负载均衡向内网业务系统方向出去的数据报文全部转换为IPv4的报文,实现的效果是负载均衡设备以上的网络运行IPv6和IPv4双栈,负载均衡以下的设备运行仅IPv4地址.
优点：改造实现简单，只需要出口网络设备和NAT设备（负载均衡）支持双协议栈即可，其他网络设备、安全设备以及业务系统无需调整。
缺点：1.端到端的安全性无法保证，在攻击溯源、流量审计等方面存在较大隐患，难以定位和具体封堵攻击源；
2.原有运行逻辑，业务流程，防护层次被打破，运行监控体系无法发挥效果。

改造方式二：从运营商引入IPv6出口，增加网站域名对应IPv6地址的域名解析。IPv6改造深入至业务边界，在业务负载均衡上配置IPv6虚地址（站点本地地址），在负载均衡设备上进行IPv6虚地址与IPv6实地址（全局单播地址）的一对一映射，在业务负载均衡上同时监听IPv4和IPv6的端口访问请求，通过业务负载均衡将IPv6访问请求转换为IPv4访问请求，发送给对应的业务系统。业务负载均衡设备及以上的网络运行IPv6和IPv4双栈，业务负载均衡设备及以下运行仅IPv4地址。

优点：1.改造实现难度适中，只需要业务负载均衡及以上设备支持双协议栈即可，其他网络设备及业务系统无需调整；

2. 现有运行逻辑，业务流程，防护层次未发生改变，运行监控体系基本有效；
3. 能基本实现端到端的安全性法，在可以进行攻击溯源、流量审计，能够定位和具体封堵攻击源。
   缺点：1.改造难度较方式一略大;
   2.需要评估现网中网络、安全以及负载均衡设备对IPv6的支持情况和性能压力;
4. 需要考虑外网安全设备针对IPv6网络安全防护情况，是否能够达到目前网络安全防护的要求。

占楼

我是谨慎乐观的态度。

目前的顾虑主要在于：

1. 设备的bug，我认为传统IPv4环境中的设备的bug算是经过了比较充分的测试（除了这个用户还有那个用户，总体的装机基数在），换成IPv6，可不好说有多少bug待我们去面对。bug不可怕，可怕的是业务中断的压力。
2. 我们不是试点单位，今年只要网站改造。今年计划用CDN实现转换，CDN服务商解释说DNS部分，运营商会实现4-6的DNS的转换，这部分有点不明白，这个轰轰烈烈的改造，基础设施部分目前有没有权威的解释。IPv4部分么，传统的运营商、网络设备厂商、安全厂商等各有重叠，总之是基本覆盖全了，IPv6部分，看不清一个完整的景象。

这个话题太大了，每一个专题都可以发散出很多细节的讨论来。私以为金融机构在认真研读监管文件，满足监管要求的同时，最重要的是在当下开始在您提及的各个领域认真的做并重视去做IPv6的技术储备，IPv6未来都必须要转型到这里，但是目前技术储备对我们中小银行来说是非常重要的。IPv6绝非改个地址族那么简单，对整个基础架构、应用架构甚至企业IT规划都有深远的影响，如果想当然操之过急铺开来去做，一些不成熟的想法和做法往往会为后期长远的发展带来不利。至于具体的措施，家家有本难念的经，因为基础架构和应用架构的差异，其实能相互借鉴的只是大的方向，我也占个楼，看看其他同僚的观点。

根据监管要求，现在研发新上的应用业务软件、或者原有的业务系统维保以及硬件设备都会要求支持IPv6，早做准备。目前正在规划实施阶段。
计划先对官网进行IPv6改造，从基础设施、操作系统、应用软件全部使用IPv6。然后在逐渐对网银、手机银行、微信银行等电子渠道逐渐进行改造，从互联网计入的负载->Web的负载->应用程序负载->数据库逐步向内改造。
目前交换机是否满足开启双栈的性能要求；同时目前IPv6的地址申请各个运营商目前还没有成熟完备的流程；IPv6地址的管理，需要更多的使用DNS；目前业务应用程序对IPv6的支持还不够全面。