1,大企业、自治体网络的特征
1)有专门的网络管理部门
2)最终用户数比较多
3)组织内有Intranet存在
4)对内、对外提供Web和Email服务
5)对IT投资/回报率有很强的要求
6)通过严格的policy对网络安全进行管理
7)对网络的可用性要求高(设备冗余和定期更换)
2,迁移之前的考虑
1)基本思路
- 建立与当前的IPv4对等的IPv6网络(目前阶段,现存的IPv4网络能继续使用)
- 既存的应用系统在既存的IPv4上保持运行,新的应用在新的IPv6上测试和运行
2)迁移方法
- 尽可能小范围的试行展开(双协议栈);已展开的IPv6子网可通过隧道技术进行连接
- 定期设备更换或有新需求(导入新设备)时,再徐徐扩展IPv6的范围
3)安全性的考虑
- 确保安全为前提
- 缓和模式:设置与IPv4的防火墙同级别的Policy,对IPv6的应用逐个的审查,最低限度的开放端口
- 严格模式:禁止IPv4与IPv6之间的通讯(IPv6独立运行)
4)迁移流程
- 阶段置换型:分阶段逐步替换现有网络设备
- 独立融合型:建立新的独立IPv6,然后与现有IPv4融合、或逐渐淘汰旧的IPv4
5)大企业新阶段导入IPv6的可能的理由
- 长期规划中的先行计划
- 新规应用导入(VOIP等)的要求
- IPv6产品开发的环境要求
- 企业形象的要求等
3,基本要素
1) ISP接入回线
- Tunnel方式(对现存IPv4的影响最小,适合于IPv6体验)
- Dual Protocol 方式(目前的推荐方式)
- Native方式(DNS、SNMP等IPv6对应完备之后,才能正式采用?)
2) 路由器
- 大中型路由器已全部支持IPv6
- 小型路由器的进展意外地缓慢(成本?)
3) 防火墙
- 包过滤功能的IPv6对应已经完成
- 但P2P、IPsec、Tunneling、Multicasting等功能的对应需要确认
4) DNS服务器
- BIND的话,只需升级版本就可以支持IPv6
- 采用双协议栈技术的话,不需要考虑IPv6的DNS请求报文的响应
5) 其他的应用服务
- 主要的Web、Mail服务器程序都已经支持IPv6(病毒检查等外接模块需单独确认)
- 网络管理服务,MIB已对应IPv6,但SNMP只支持IPv4(2006年)
6) PC/PDA
- 主流的OS已全部支持IPv6
7) IPv6全局地址的取得
- 可以从ISP处取得,一般为/48
- 大规模的企业,可以向RIR(如日本的APNIC)申请/32
参照
http://www.v6pc.jp/jp/wg/remoteSWG/index.html 8) IPv6地址设计
- /48对大多数企业而言,已经足够大
- 设计的原则: 简单高效(容易分辨)/充分考虑组织变更和扩大/考虑与组织地理位置匹配的构成
- 与IPv4的不同:IPv4设计时需要充分考虑子网内的终端数来设计;而IPv6由于地址空间足够大,可以采用简单的方法、一律16Bit(可容纳65535台终端)的方式来设计。
9) 路由协议
- 初期导入时,静态路由就可以了
- 规模扩大时,考虑RIPng/OSPFv3
- 假设有可能导入流媒体应用,需要考虑支持MultiCasting的PIM-SM等路由协议。
10) 其他协议
- Translater(协议转换器),实现IPv4终端与IPv6终端的通信(NAT-PT/TRT方式)
- Tunnel(隧道)
-- 6to4主机 :在有IPv4全局地址的主机、和ISP的中继router之间建立隧道
-- 6to4路由器:拥有1个IPv4全局地址和1个IPv6的子网,和ISP的中继router之间建立隧道
-- ISATAP主机:位于Lan内部,无全局地址,与ISATAP网关之间建立隧道
-- ISATAP路由器:拥有1个IPv4全局地址和内接IPv4的子网,对外和ISP的中继router之间建立6to4隧道,对内与主机建立ISATAP隧道。
11) DMZ的IPv6
- WEB服务器(例)
-- Apache2.0以上,可直接升级到IPv6,也可先并存,再取代
-- 大规模系统(负载均衡系统):
a, IPv6的流量经过协议转换至IPv4后,作为IPv4负载均衡的一分支处理
b, IPv6流量不做负载均衡,直接交给新的IPv6 WEB服务器处理
c, 升级负载均衡系统支持IPv6,与原IPv4系统并存
4,新应用系统导入引起的IPv6迁移
1) 原则:双协议栈环境对应+开发者考量(非IP协议依存)