|
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協議依存)
|
|
|