※ 引述《louk (站內信.第一階段保障)》之銘言： : ※ 引述《cklonger (22)》之銘言： : : 新手提問 : : 手機上被分配的ip是ipv6 : : 當他去連ipv4的網站或服務時(例如透過3G) : : 請問ipv6->ipv4這段是手機處理還是基地台處理 : core network : : 目前手機上這段的主流技術又是什麼 : hmmm... 你可以翻閱ITU的相關規範 : 或是網路上找找會有2010年美國IPv6 會議中,cisco提出的解決方案投片 : http://tinyurl.com/7lz82me : : 此外手機分到的ipv6位址是固定的? : case by case. 看到目前的心得是 IPV6 client 連ipv4服務 目前的關鍵技術是DNS64與NAT64 DNS64與NAT64有兩個商業solution 分別是微軟與cisco提出 Microsoft (Forefront UAG Direct Access) vs. Cisco (CGv6 blade for CRS-1 ) DNS64的關鍵是 把domain name對應的IPV4的ip 換算成ipv6 ip的後半部(32bit) 再加上最長為96bit 的prefix湊成一個ipv6 ip ipv6 client再透過這個造出來的ip和NAT64的gateway 與ipv4的網路服務建立通訊 NAT64原理 根據RFC 6164的內容 在一個ipv6 client與ipv4網路資源建立連接的過程中 NAT64有兩個重要工作 1. 紀錄ipv4 服務之ip與DNS64 產生的ipv6 ip兩者的 mapping 2. NAT64具有兩個interface 分別連接ipv4與ipv6的環境 當ipv6的封包要傳給ipv4的網站時，NAT64根據[RFC6145]修改封包的header 將ipv6封包的header改成ipv4的header，反之亦然 這是某人用open source在ipv6網路環境 實作了DNS4與NAT64的一個lab https://supportforums.cisco.com/thread/2076065 看來這是一個可行的解決方案 只是不知道NAT64 在改封包與mapping的過程中 封包的loss與延遲是如何 嚴不嚴重 不知道有沒有人實測過 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.112.121.185 ※ 編輯: cklonger 來自: 59.112.121.185 (03/06 01:15)