Re: [討論]ipv4枯竭以後,現有的V4-ip位址如何運用?

看板IPv6作者 (ggg)時間14年前 (2010/07/31 12:18), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串3/3 (看更多)
※ 引述《louk (PTT的人自己玩自己=_=)》之銘言: : 在短時間內(20年)並不會被淘汰 : 目前日本/中國的研究大多在討論 : 未來IPv4終端如何透過DS-lite之類的機制跑在IPv6骨幹網路上 : : 1. v4 router 的硬體不容易被改為 V6 運作, 若硬體為 V4 架構, : : 軟體增添 V6 功能, 則 V6 的性能不足外, 還拖累 V4 運作. : : 若新購置 V6/V4 兩用硬體, 似乎沒必要使用兩用的硬體, 成 : : 本變高, 所以兩用硬體的替換或啟動軟體 V6 的 router 將遲 : : 滯不前, V4 設備仍將長時間存在. : 其實這裡應該是說商用骨幹網路設備,目前大概也逐漸買不到不支援IPv6的 : IPv6也逐漸被硬體所支援 : 對於廠商來說,IPv6是一個新功能(不過價格不一定可以賣得比較貴) : 但是當大家都有,而自己沒有的時候就會失去市場的競爭力 : 目前IPv6主要的問題是大家買回去都不開IPv6功能~XD ======================================================================== 有設備卻不會被打開來用, 主要是沒有客戶需求的壓力, 也就是沒有通稱的 killer application 可造成眾人的驅使. 多一事不如少一事, 沒有V4也能過活, 也就會不 了了之. 現在最大宗的 PC 使用 XP/Vista/Win7 都有 Dual Stack, 當不再發放 V4 address 的時候, Client 端使用動態 V4 ip-address 短期內不會有影響, 新的 server 沒 有 V4 若只用 V6 就受限於 dual stack 的 client 是否相互到得了. 6to4 RD 把使用 automatical tunnel 的 Anycast relay router 改限為 local ISP Scope 的 local-anycast 以限制可使用的 tunnel client 端範圍, 可避免假造 6to4 V6 ip 的來源無法追蹤問題. 而 6to4 對外的 V6 ip-address 可用 ISP 設定的對外 ipv6 prefix 供 native v6 routing 使用以找到有 6to4 tunnel 的 local anycast router, 這使得從 v6 回到 6to4 tunnel 變得容易又有效率. 基本上 6to4 RD 仍然是 6to4 tunnel 但有 anycast relay 的自動功能. 其差別只是 tunnel broker 的設定與相關位置與router結合問題. : : 2. v4 網址 與 v4 router 設備仍有其可用的價值, 所以不應拋棄. : IPv4協定基本上不會被放棄,在20年之內將會逐步隨著設備汰換更新至雙協定設備 : 註:這邊有兩個例子,算是特例吧 : 1.日本之前透過CPE支援6to4或是softwire之類的tunel機制 : 目前已經透過軟體升級的方式支援6RD : 2.法國FreeNet在覺得6RD是一個好想法後,花了一個月實作和Wifi CPE軟體佈署. : : 3.與其使用 V4 NAT, 為何不使用 V6 當 類似NAT 的網址 ? : : a. V4 NAT 是要讓 private-ip node 跟 ipv4 網站來往. 以 V6-ip : : 當 NAT 又如何讓 V6-ip node 與 廣大的 V4 網站來往? : : a-1. 在 client 端使用 軟體方法提供 dual stack v4/v6 兩用 : : 功能並不增加硬體成本. : : a-2. client 端再增加 6to4 tunnel 軟體也同樣不是大負擔. : : a-3. dual stack 與 6to4 tunnel 使得 V4 仍繼續被使用, 對於 : : 新增的 V6 server, 雙堆的client可以利用已有的 V4 網路 : : 銜接特定新增的 V6 server. : : 雙堆的使用使得 ipv6 具備 V4-NAT 使用網站的效果, 還更進一步透 : : 過 6to4 tunnel 也能利用已存在的 V4 網路連上現為孤島的 V6 : : server. : 以前我們做過兩年的宿舍區純IPv6實驗 : 當你使用native-IPv6,你就需要開始思考一個問題"如何提供使用者現有的IPv4服務" : 當年我們是透過natpt...etc來嘗試解決 : 當然也可以透過軟體支援dual stack...etc.. : 但是最簡單的答案"直接提供IPv4/IPv6就好了阿" : 既然本來就已經可以動的,就不要給自己麻煩 : 直接把宿舍區的Router開成雙協定 IPv4NAT/IPv6 RA : 我的印象最深刻的是當使用者連不上BT/GAME.. : 會說"IPv6網路很爛" <--一個不能用的網路當然是爛阿 : 我覺得應該積極部屬雙協定網路 : 提高基礎服務(WWW/DNS/email)以防止真的有人用單獨只有ipv6連上 : 並"期待會有人在IPv6網路上開發出創新的P2P應用" Client 端因為已有自動下載更新, 所以 client 端的 dual stack 自動供應與啟動 已不是問題. server 端在意識到 V4 枯竭就勢必要考慮早做兩用的網站準備. 真正的問題會是像學網 TANET 這種鬆散的 ISP, 要有堪用的兩用 server (如 DNS server) 或 router 必然是零零落落. 像縣網中心與國中小先推 V6-視訊VOIP 就能提供免建大中型交換機的優勢. : : b. 不如 PC 有充份硬體功能支援的小型裝置需要使用雙堆 V4/V6 軟 : : 體嗎? : : b-1.新增的小型裝置當然是可只使用 V6 軟體連接特定用途的 V6 : : server. : : b-2.server 為了服務新增的 user 可以立即升級為雙堆的 V6/V4 : : 通信能力, 也能利用 6to4 tunnel 利用現有的 V4 網路 提供 : : 給新增的 V6 client 使用. : : b-3.假如 6to4 tunnel 隨著 window PC 大量布署. 那些純 V6 的 : : client 端就可從 軟體提供的6to4 relay/router 處銜接6to4 : : tunnel 經由 現存 V4 網站連到 V6 server. : : b-4.假如新增的 V6 server 與 V6 Client 是一種消耗頻寬重的應 : : 用, 那麼各個 6to4 tunnel server 就可提供多管道的 tunnel : : 來擴大供應源與限制管道之負荷超載. : : b-5.由於多處存在的 Window PC, 這種軟體的 dual stack 及 6to4 : : tunnel , 將因數量廣大及分散可用, 使得成本的考量不再成為 : : 障礙. : 最近我正在追蹤的專案是智慧電錶(以台灣來說) : 以一次600萬台的量來算 一個A就可以了(雖然..也有可能是一個A的private IPv4) : 基本上要先說服大家要用IP化到末端節點 : 這牽涉到IP化的好處 : 基本上IP化可以利用到既有的icmp..udp...etc : 更重要是可以引入"廉價的IT設備和開發人員" : 打破傳統工控之高價利基市場(打到這裡有點寒...當初wimax也是這樣說的) : 進一步的催生智慧家庭 : 而採用ipv6或是ipv4的理由... : 如果那個專案是懂IPv6的人,就會放進去當規格 : 如果是不懂的人(連網路都不太懂)..那就希望有IP吧(可能只是工控的ID) : : 上述這件事, 是否已經發生了? 還是這事會因利益衝突或安全考量的藉口 : : 而使之遲滯不通? : 這些理由都來自於不理解. : 在理解的情況下, www.edu.tw 是有支援IPv6的... 水電自動計量有如網路報稅, 省掉的人工處理費用改由使用者透過自動設備與使用 者來分攤, 標準計量裝置當然得由電力公司來提供, 讀取與傳送免不了要一段時間 是能由抄表員在室外就能接取與轉送或蒐集儲存. 用戶想要管理用電量時自然就會 想隨時利用這個計量裝置. 這個裝置是否一定要用 V6 定址顯然不會是重點, 因為現行的方式可以把電表裝在 公共位置供外來查表員抄錄, 短期內能短距讀取數字就夠住戶與抄表員使用, 進一 步的傳送與繳費可以像網路報稅來由用戶處理. 理論上, 只要電力公司的末端電力配送站能記錄送出去的幾家用戶總電量與各家申 報的用電歷史就能預估用戶的每月用電量. V4枯竭, V6 或 V4代用品 就一定會被使用. 但V4顯然還會存活很久. 但V4 有可能如 private IP 一樣被本地化, 世界性的溝通就靠 V6/V4 骨幹. V4上的 tunnel 就是來自 V4 的 private ip 在各地本地化與重覆使用. 如果 V4 大範圍分區重覆使用, V4就被V6再造而再生, 也就不再有枯竭問題, 因虛擬共用而分享化了. 技術問題就是 automatical tunnelling 與 automatical deployment. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.5.76
文章代碼(AID): #1CKwG153 (IPv6)
文章代碼(AID): #1CKwG153 (IPv6)