正文
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協議依存）
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協議依存）
評論
目前還沒有任何評論
登錄後才可評論.
