IPv6

出自Local Chinese Wikipedia
(重新導向自SLAAC
跳至導覽 跳至搜尋

網際協定第6版(英語:Internet Protocol version 6,縮寫:IPv6)是網際協定的最新版本,用作網際網路的協定。用它來取代IPv4主要是為了解決IPv4位址枯竭問題,同時它也在其他方面對於IPv4有許多改進。

IPv6於1998推出,設計目的是取代IPv4,然而長期以來IPv4在網際網路流量中仍佔據主要地位,IPv6的使用增長緩慢。

2026年3月28日,通過IPv6使用Google服務的使用者百分率首次達到50%。[1]同期,Cloudflare的統計數字顯示,網際網路的整體用量有40%來自IPv6。[2]

背景與目標[編輯]

現今的網際網路發展蓬勃,截至2018年1月,全球上網人數已達40.21億,IPv4僅能提供約42.9億個IP位置。雖然目前的網路位址轉換無類別域間路由等技術可延緩網路位置匱乏之現象,但為求解決根本問題,從1990年開始,網際網路工程工作小組開始規劃IPv4的下一代協定,除要解決即將遇到的IP位址短缺問題外,還要發展更多的擴充功能,為此IETF小組建立IPng,以讓後續工作順利進行。1994年,各IPng領域的代表們於多倫多舉辦的IETF會議中,正式提議IPv6發展計劃,該提議直到同年的11月17日才被認可,並於1996年8月10日成為IETF的草案標準,最終IPv6在1998年12月由網際網路工程工作小組以網際網路標準規範(RFC 2460,在2017年7月被RFC 8200替代)的方式正式公佈。

IPv6的計劃是建立未來網際網路擴充的基礎,其目標是取代IPv4,雖然IPv6在1994年就已被IETF指定作為IPv4的下一代標準,由於早期的路由器、防火牆、企業的企業資源計劃系統及相關應用程式皆須改寫,所以在世界範圍內使用IPv6部署的公眾網與IPv4相比還非常的少[3][4],技術上仍以雙架構並存居多。預計在2025年以前IPv4仍會被支援,以便給新協定的修正留下足夠的時間。

與IPv4比較[編輯]

在Internet上,資料以分組的形式傳輸。IPv6定義了一種新的分組格式,目的是為了最小化路由器處理的訊息標頭[5][6]。由於IPv4訊息和IPv6訊息標頭有很大不同,因此這兩種協定無法互操作。但是在大多數情況下,IPv6僅僅是對IPv4的一種保守擴展。除了嵌入了網際網路位址的那些應用協定(如FTPNTPv3,新位址格式可能會與當前協定的語法衝突)以外,大多數傳輸層和應用層協定幾乎不怎麼需要修改就可以在IPv6上運行。

無狀態位址自動組態(SLAAC)[編輯]

當連接到IPv6網路上時,IPv6主機可以使用鄰居發現協定對自身進行自動組態。當第一次連接到網路上時,主機傳送一個鏈路本地路由器請求(solicitation)多播請求來取得組態參數。路由器使用包含Internet層組態參數的路由器宣告(advertisement)報文進行回應[7]

在不適合使用IPv6無狀態位址自動組態的場景下,網路可以使用有狀態組態(DHCPv6)或者使用靜態方法手動組態。

IPv6編碼[編輯]

IPv6具有比IPv4大得多的編碼位址空間。IPv6採用128位元的位址,而IPv4使用的是32位元。理論上,新增的位址空間支援2128(約3.4×1038)個位址。不過,實際可分配的公共位址數目遠少於理論值,因為網際網路服務提供者最多只能指定IPv6位址中的64位元網路前綴,而非像IPv4一樣分配完整長度的IP位址。

IPv6位址分為多個不同種類,其中全域單播位址(Global Unicast Address)相當於IPv4的公共位址。

全域單播位址的一般格式
長度 3 (固定為001) 45 (長度可變) 16 (長度可變) 64
欄位 首碼 全球路由前綴 子網ID 介面ID / 主機位址

由於IPv6的全球單播位址採用固定的64位元網路前綴及64位元主機位址,所以每個子網可連接的裝置數量為264(43億×43億)個,在實際應用上相當於無限大。主機位址通常根據48位元的MAC位址自動生成,稱為64位元擴展唯一標識(Extended Unique Identifier-64),簡稱EUI-64。

截止2026年,網際網路工程任務組只分配了001作為全球單播位址的首碼,佔IPv6位址空間1/8。IANA保留了約85%位址供未來使用。[8]

十六進制表達示時,IP位址的最高有效位必定為2或3。

  • 2000:: (0010...)
  • 3000:: (0011...)

2001年9月,網際網路工程任務組網路架構委員會建議在一般情況下為家庭使用者及企業使用者提供/48網路,預留16位元供企業內部建立子網。[9]每間企業最多可建立65536個子網。扣除3位首碼後,可分發的全球路由前綴有45位元長度,約為35萬億個。不過,統一為所有使用者預留16位元子網ID的建議一直備受爭議,家庭使用者及中小企業顯然不需要6萬多個子網。

2011年3月,網際網路工程任務組發佈新指引,建議網際網路服務提供者為家庭使用者預留的子網ID可減少到8位元長度,以節省8位元IP位址空間。[10]部分ISP只為使用者預留4位元子網ID,甚至不預留子網段。若ISP指派64位元全球路由前綴,使用者可使用NAT66分割子網。

網路位址轉換是目前減緩IPv4位址耗盡最有效的方式,而IPv6的位址消除了對它的依賴。從IPv4到IPv6最顯著的變化就是網路位址的長度。RFC 2373和RFC 2374定義的IPv6位址有128位元長;IPv6位址的表達形式一般採用32個十六進制數。

IPv6格式[編輯]

IPv6二進位制下為128位元長度,以16位元為一組,每組以冒號「:」隔開,可以分為8組,每組以4位十六進制方式表示。例如:2001:0db8:86a3:08d3:1319:8a2e:0370:7344 是一個合法的IPv6位址。類似於IPv4的點分十進制,同樣也存在點分十六進制的寫法,將8組16位元十六進制位址的冒號去除後,每位以點號「.」分組,例如:2001:0db8:85a3:08d3:1319:8a2e:0370:7344則記為2.0.0.1.0.d.b.8.8.5.a.3.0.8.d.3.1.3.1.9.8.a.2.e.0.3.7.0.7.3.4.4,其倒序寫法用於ip6.arpa子域名記錄IPv6位址與域名的對映。

同時IPv6在某些條件下可以省略:

  1. 每項數字前導的0可以省略,省略後前導數字仍是0則繼續,例如下組IPv6是等價的。
    2001:0db8:02de:0000:0000:0000:0000:0e13
    2001:db8:2de:0000:0000:0000:0000:e13
    2001:db8:2de:000:000:000:000:e13
    2001:db8:2de:00:00:00:00:e13
    2001:db8:2de:0:0:0:0:e13
  2. 可以用雙冒號「::」表示一組0或多組連續的0,但只能出現一次:
    1. 如果四組數字都是零,可以被省略。遵照以上省略規則,下面這兩組IPv6都是相等的。
      • 2001:db8:2de:0:0:0:0:e13
      2001:db8:2de::e13
      • 2001:0db8:0000:0000:0000:0000:1428:57ab
      2001:0db8:0000:0000:0000::1428:57ab
      2001:0db8:0:0:0:0:1428:57ab
      2001:0db8:0::0:1428:57ab
      2001:0db8::1428:57ab
    2. 2001::25de::cade 是非法的,因為雙冒號出現了兩次。它有可能是下種情形之一,造成無法推斷。
      • 2001:0000:0000:0000:0000:25de:0000:cade
      • 2001:0000:0000:0000:25de:0000:0000:cade
      • 2001:0000:0000:25de:0000:0000:0000:cade
      • 2001:0000:25de:0000:0000:0000:0000:cade
    3. 如果這個位址實際上是IPv4的位址,後32位元可以用IPv4的點分十進制方式表示;因此::ffff:192.168.89.9 相等於::ffff:c0a8:5909。這種位址格式叫做IPv4對映位址。

由於同一非全域位址可能在同一範圍的多個區域中使用(例如,在兩條獨立的物理鏈路中使用鏈路本地位址 fe80::1),而且一個節點可能連接到同一範圍的不同區域的介面(例如,一個路由器通常有多個介面連接到不同的鏈路)。IPv6新增了區域ID(Zone ID)加以區分,或稱範疇ID(Scope ID)。範疇ID僅用於本地連結,使用百分號追加在位址後面。其內容特定於作業系統,例如Windows使用數字 fe80::2%3 ,Linux使用網卡名字 fe80::2%eth0 。[11]在URI中使用時,百分號需要進行編碼,例如 fe80::a%en1 應顯示為 http://[fe80::a%25en1] 。[12]

IPv6位址的分類[編輯]

IPv6位址可分為三種:[13]

單播(unicast)位址
單播位址標示一個網路介面。協定會把送往位址的封包送往給其介面。IPv6的單播位址可以有一個代表特殊位址名字的範疇,如鏈路本地位址(link local address)和唯一區域位址(ULA,unique local address)。單播位址包括可聚類的全球單播位址(位址範圍為16進位:2000~3fff 開頭)、鏈路本地位址(位址為fe80開頭)等。
任播(anycast)位址
任播像是Unicast(單點傳播)與Broadcast(多點廣播)的綜合。單點廣播在來源和目的地間直接進行通訊;多點廣播存在於單一來源和多個目的地進行通訊。
而Anycast則在以上兩者之間,它像多點廣播(Broadcast)一樣,會有一組接收節點的位址列表,但指定為Anycast的封包,只會傳送給距離最近或傳送成本最低(根據路由表來判斷)的其中一個接收位址,當該接收位址收到封包並進行回應,且加入後續的傳輸。該接收列表的其他節點,會知道某個節點位址已經回應了,它們就不再加入後續的傳輸作業。
以目前的應用為例,Anycast位址只能分配給中間裝置(如路由器、三層交換機等),不能分配給終端裝置(手機、電腦等),而且不能作為傳送端的位址。
多播(multicast)位址
多播位址也稱組播位址。多播位址也被指定到一群不同的介面,送到多播位址的封包會被傳送到所有的位址。多播位址由皆為一的位元組起始,亦即:它們的前置為FF00::/8。其第二個位元組的最後四個位元用以標明"範疇"。
一般有node-local(0x1)、link-local(0x2)、site-local(0x5)、organization-local(0x8)和global(0xE)。多播位址中的最低112位元會組成多播群組識別碼,不過因為傳統方法是從MAC位址產生,故只有群組識別碼中的最低32位元有使用。定義過的群組識別碼有用於所有節點的多播位址0x1和用於所有路由器的0x2。
另一個多播群組的位址為"solicited-node多播位址",是由前置FF02::1:FF00:0/104和剩餘的群組識別碼(最低24位元)所組成。這些位址允許經由鄰居發現協定(NDP,Neighbor Discovery Protocol)來解譯連結層位址,因而不用干擾到在區網內的所有節點。

特殊位址[編輯]

IANA維護官方的IPv6位址空間列表[14]。全域的單播位址的分配可在各個區域網際網路註冊管理機構或 GRH DFP 頁面找到[15]

IPv6中有些位址是有特殊含義的:

未指定位址
  • ::/128-所有位元皆為零的位址稱作未指定位址。這個位址不可指定給某個網路介面,並且只有在主機尚未知道其來源IP時,才會用於軟體中。路由器不可轉送包含未指定位址的封包。
鏈路本地位址
  • ::1/128-是一種單播繞回位址。如果一個應用程式將封包送到此位址,IPv6堆疊會轉送這些封包繞回到同樣的虛擬介面(相當於IPv4中的127.0.0.1/8)。
  • fe80::/10-這些鏈路本地位址指明,這些位址只在區域連線中是合法的,這有點類似於IPv4中的169.254.0.0/16
唯一區域位址英語Unique_local_address
  • fc00::/7-唯一區域位址(ULA,unique local address)只可用於本地通訊,類似於IPv4專用網路位址10.0.0.0/8、172.16.0.0/12和192.168.0.0/16。這定義在RFC 4193中,是用來取代站點本地位域。這位址包含一個40位元的偽隨機數,以減少當網站合併或封包誤傳到網路時碰撞的風險。這些位址除了只能用於區域外,還具備全域性的範疇,這點違反了唯一區域位域所取代的站點本地位址的定義。
多播位址
  • ff00::/8-這個前置表明定義在"IP Version 6 Addressing Architecture"(RFC 4291)中的多播位址[16]。其中,有些位址已用於指定特殊協定,如ff0X::101對應所有區域的NTP伺服器(RFC 2375)。
請求節點多播位址(Solicited-node multicast address)
  • ff02::1:FFXX:XXXX-XX:XXXX為相對應的單播或任播位址中的三個最低的位元組。
IPv4轉譯位址
ORCHID
  • 2001:10::/28-ORCHID (Overlay Routable Cryptographic Hash Identifiers)(RFC 4843)。這些是不可遶送的IPv6位址,用於加密雜湊識別。
檔案
  • 2001:db8::/32-這前置用於檔案(RFC 3849)。這些位址應用於IPV6位址的範例中,或描述網路架構。
遭捨棄或刪除的用法
  • ::/96-這個前置曾用於IPv4相容位址,現已刪除。
  • fec0::/10-這個站點本地前置指明這位址只在組織內合法。它已在2004年9月的RFC3879中捨棄,並且新系統不應該支援這類型的位址。

IPv6封包[編輯]

File:Ipv6 header.svg
IPv6封包的架構說明

IPv6封包由兩個主要部分組成:頭部和負載。

包頭是包的前320位元,並且包含有源和目的位址,協定版本,通訊類別(8位元,包優先級),流標記(20位元,QoS服務品質控制),分組長度(16位元),下一個頭部(用於入棧解碼,類似IPv4中的協定號),和跳段數限制(8位元,生存時間,相當於IPv4中的TTL)。後面是負載。MTU至少1280位元組長,在常見的乙太網路環境中為1500位元組。負載在標準模式下最大可為65535位元組,如果擴充報頭設定了「jumbo payload」選項,則長度值被置為0。

IPv6曾有兩個有著細微差別的版本;在 RFC 1883 中定義的原始版本(現在廢棄)和 RFC 2460 中描述的現在提議的標準版本。兩者主要在「通訊類別」這個選項上有所不同,它的位數由4位元變為了8位元。其他的區別都是微不足道的。

由於分片(Fragmentation)只在IPv6的主機中處理,而IPv6也要求實現「MTU路徑發現」來避免封包需要被中間裝置分片,所以IPv4頭涉及分片的欄位從IPv6基本頭移出至專用的分片擴充報頭中。

在IPv6中,可選項都被從標準頭部中移出並在協定欄位中指定,類似於IPv4的協定欄位功能。

IPv6和域名系統[編輯]

IPv6位址在域名系統中為執行正向解析表示為AAAA記錄(所謂4A記錄,類似地,IPv4表示為A記錄(A record));反向解析在ip6.arpa(原先是ip6.int)下進行,在這裡位址空間為半位元組16進制數字格式。這種模式在RFC 3596給與了定義。

AAAA模式是IPv6結構設計時的兩種提議之一。另外一種正向解析為A6記錄。也有一些其他的創新像二進制串標籤和DNAME記錄等。RFC 2874和它的一些參照中定義了這種模式。

AAAA模式只是IPv6域名系統的簡單概括,A6模式使域名系統中檢查更全面,也因此更複雜:

  • A6記錄允許一個IPv6位址在分散於多個記錄中,或許在不同的區域;舉例來說,這就在原則上允許網路的快速重編號。
  • 使用域名系統記錄委派位址被DNAME記錄(類似於現有的CNAME,不過是重新命名整棵樹)所取代。
  • 一種新的叫做位元標籤的類型被引入,主要用於反向解析。

2002年8月的RFC 3363中對AAAA模式給予了有效的標準化(在RFC 3364有對於兩種模式優缺點的更深入的討論)。

IPv6部署與應用[編輯]

2004年7月時ICANN聲稱網際網路的根域名伺服器已經經過改進以同時支援IPv6和IPv4。[17]

缺點:

  • 需要在整個網際網路和它所連接到的裝置上建立對IPv6的支援
  • 從IPv4訪問時的轉換過程中,在閘道器路由器(IPv6<-->IPv4)還是需要一個IPv4位址和一些NAT(=共享的IP位址),增加了它的複雜性,還意味著IPv6許諾的巨大的空間位址不能夠立刻被有效的使用。
  • 遺留的結構問題,例如在對IPv6 multihoming支援上一致性的匱乏。

工作:

部署進度:

  • 截至2011年,全球通過IPv6第二階段認證的產品共644項,美國位居首共264種產品通過階段認證,次為日本計143項,台灣居第三,共115項完成階段認證,中國大陸居四,共68件產品通過階段認證[18]

網路層安全[編輯]

網際網路安全協定(Internet Protocol Security,即IPsec)原本為IPv6開發,但是在IPv4中已經大量部署。IPsec最初是IPv6協定的強制要求[19],但後來改為可選項。[20]

轉換機制[編輯]

在IPv6完全取代IPv4前,需要一些轉換機制[21]使得只支援IPv6的主機可以連絡IPv4服務,並且允許孤立的IPv6主機及網路可以藉由IPv4設施連絡IPv6網際網路。

在IPv6主機和路由器與IPv4系統共存的時期時,RFC2893頁面存檔備份,存於網際網路檔案館)和RFC2185頁面存檔備份,存於網際網路檔案館)定義了轉換機制。這些技術,有時一起稱作簡單網際網路轉換(SIT,Simple Internet Transition)。[22]包含:

  • 運作於主機和路由器之間的雙堆疊IP實作
  • 將IPv4嵌入IPv6位址
  • IPv6立於IPv4之上的穿隧機制
  • IPv4/IPv6報頭轉換

許多轉換機制使用穿隧來把IPv6交通包封在IPv4網路中。這個解決方案並不完美,可能會增加延時以及引起路徑最大傳輸單元發現(Path MTU Discovery)的問題,[23]它並不總能執行,因為過時的網路裝置可能不支援IPv6。有線電視基礎上的Internet訪問就是一個例子。在現代的有線電視網路中,光纖同軸混合網(HFC)的核心(比如大型核心路由器)是有可能支援IPv6的。然而,其他網路裝置(比如一個線纜數據機終端系統(CMTS))以及使用者裝置(如線纜數據機)會需要軟體更新或硬體更新來支援IPv6。這意味著線纜網路業者必須調整適應穿隧直至主幹裝置支援內部雙堆疊。

雙堆疊[編輯]

雙堆疊(Dual IP stack implementation)是將IPv6視為一種IPv4的延伸,以共享程式碼的方式去實作網路堆疊,其可以同時支援IPv4和IPv6,如此是相對較為容易的。如此的實作稱為「雙堆疊」,並且,一個實作雙堆疊的主機稱為「雙堆疊主機」。這步驟描述於RFC 4213。

目前大部分IPv6的實現使用雙堆疊。一些早期實驗性實作使用獨立的IPv4和IPv6堆疊。

穿隧[編輯]

穿隧(Tunneling)是另一個用來連結IPv4與IPv6的機制。為了連通IPv6網際網路,一個孤立主機或網路需要使用現存IPv4的基礎設施來攜帶IPv6封包。這可由將IPv6封包裝入IPv4封包的穿隧協定來完成,實際上就是將IPv4當成IPv6的連結層。

IP協定號碼的41號用來標示將IPv6資料訊框直接裝入IPv4封包。IPv6亦能加入UDP封包,如為了跨過一些會阻擋協定41流量的路由器或NAT裝置。其它流行的封裝機制則有AYIYAGRE

自動穿隧[編輯]

自動穿隧(Automatic tunneling)指路由設施自動決定穿隧端點的技術。RFC 3056建議使用6to4穿隧技術來自動穿隧,其會使用41協定來封裝。[24]穿隧端點是由遠端知名的IPv4任播位址所決定,並在本地端嵌入IPv4位元址資訊到IPv6中。現今6to4是廣泛佈署的。

Teredo是使用UDP封裝的穿隧技術,據稱可跨越多個NAT裝置。[25]Teredo並非廣泛用於佈署的,但一個實驗性版本的Teredo已安裝於Windows XP SP2 IPv6堆疊中。IPv6,包含6to4穿隧和Teredo穿隧,在Windows Vista中預設是啟動的。[26]許多Unix系統只支援原生的6to4,但Teredo可由如Miredoo的第三方軟體來提供。

ISATAP[27]藉由將IPv4位元址對應到IPv6的鏈路本地位址,從而將IPv4網路視為一種虛擬的IPv6區域連線。不像6to4和Teredo是站點間的穿隧機制,ISATAP是一種站點內機制,意味著它是用來設計提供在一個組織內節點之間的IPv6連接性。

組態穿隧(6in4)[編輯]

組態穿隧中,如6in4穿隧隧,穿隧端點是要明確組態過的,可以是藉由管理員手動或作業系統的組態機制,或者藉由如tunnel broker等的自動服務。[28]組態穿隧通常比自動穿隧更容易去除錯,故建議用於大型且良好管理的網路。

組態穿隧在IPv4穿隧上,使用網際協定中號碼的41號。

用於只支援IPv6主機的代理和轉譯[編輯]

區域網際網路註冊管理機構耗盡所有可使用的IPv4位元址後,非常有可能使新加入網際網路的主機只具有IPv6連接能力。對這些須要向後相容以能存取IPv4資源的客戶端,須要佈署合適的轉換機制。

一種轉換技術是使用雙堆疊的應用層代理,如網頁代理伺服器。

一些對於應用程式無法得知但在其低層使用類NAT轉換技術也曾被提出。但因為一般應用層協定所要求的能力其應用太廣,其中大部分都被認定在實際上太不可靠,並且被認為應刪除。

主要的IPv6公告[編輯]

  • 在2003年,日本經濟新聞(在2003年被CNET亞洲機構參照)報告中說日本、中國和韓國聲稱已經決定要在網路技術中尋求領先,將部分參與IPv6的開發並在2005年開始全面採用IPv6[來源請求]
  • ICANN在2004年7月20日發表聲明,稱DNS根伺服器已經建立對應日本(.jp)和韓國(.kr)的頂級域名伺服器的AAAA記錄,序列號為2004072000。對應法國的(.fr)IPv6記錄會再晚一點時間加入。
  • 2011年網際網路協會將6月8日定為世界IPv6日。包括Google、Facebook和雅虎在內的參與者將在當天對他們的主要服務啟用IPv6,以推進網際網路工業加速部署全面IPv6支援[29]
  • 2017年11月26日,中共中央辦公廳國務院辦公廳印發《推進網際網路協定第六版(IPv6)規模部署行動計劃》,要求各地各部門貫徹落實。其中主要目標包括:到2018年末,IPv6活躍使用者數達2億,網際網路使用者中占比不低於20%;到2020年末,IPv6活躍使用者數超過5億,網際網路使用者中占比超過50%,新增網路位址不再使用私有IPv4位址;到2025年末,中國IPv6網路規模、使用者規模、流量規模位居世界第一,網路、應用、終端全面支援IPv6。[30]
  • 根據科技資訊網站cnBeta.com,截至2021年4月8日,中國總共獲得IPv6位址塊數量為59,039個/32(即是每段32位元的IPv6位址數目),目前排名第二的美國擁有57,785個/32。[31]

參見[編輯]

相關的IETF工作群組[編輯]

  • 6bone:IPv6 Backbone
  • ipng:IP Next Generation (concluded)
  • ipv6:IP Version 6
  • ipv6mib:IPv6 MIB (concluded)
  • multi6:Site Multihoming in IPv6
  • v6ops:IPv6 Operations

參考資料[編輯]

  1. published, Bruno Ferreira. IPv6 usage reaches historic 50% across Google services, matching IPv4 — increased usage eases pressure on the IPv4 address market as 'new' protocol designed in 1998 finally hits its stride. Tom's Hardware. 2026-04-16 [2026-04-18] (English). 
  2. Adoption & Usage Worldwide. [2026-04-18].  已忽略文字「 Cloudflare Radar 」 (幫助)
  3. IPv6 Reports. [2004-12-28]. (原始內容存檔於2005-02-06). 
  4. BGP Analysis Reports. [2004-12-28]. (原始內容存檔於2012-12-23). 
  5. RFC 2460, Internet Protocol, Version 6 (IPv6) Specification, Deering S. Hinden R.(December 1998)
  6. RFC 1726, Technical Criteria for Choosing IP The Next Generation (IPng), Partridge C., Kastenholz F.(December 1994)
  7. RFC 4862, IPv6 Stateless Address Autoconfiguration, Thomson S., Narten T., Jinmei T.(September 2007)
  8. IPv6 Address Space. www.iana.org. 
  9. IAB/IESG Recommendations on IPv6 Address Allocations to Sites. Internet Engineering Task Force. 2001-09. 
  10. Roberts, Rosalea; Huston, Geoff; Narten, Thomas. IPv6 Address Assignment to End Sites. Internet Engineering Task Force. 2011-03. 
  11. RFC 4007, IPv6 Scoped Address Architecture
  12. RFC 6874, Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
  13. RFC 2373 - IP Version 6 Addressing Architecture. [2008-12-27]. (原始內容存檔於2008-12-18). 
  14. Internet Protocol Version 6 Address Space. 2013-02-15 [2013-04-26]. (原始內容存檔於2010-04-16) (English). 
  15. GRH DFP pages. [2017-04-29]. (原始內容存檔於2016-01-05). 
  16. [1][永久失效連結]
  17. Next-generation IPv6 Address Added to the Internet's Root DNS Zone. 2004-06-20 [2013-04-26]. (原始內容存檔於2008-09-06). 
  18. 上千菁英來台打造網路新標準鍾榮峰/台北/中央社. 2011-11-14 [2013-04-26]. (原始內容存檔於2015-01-02). 
  19. RFC 4301, IPv6 Node Requirements", J. Loughney (April 2006)
  20. RFC 6434, "IPv6 Node Requirements", E. Jankiewicz, J. Loughney, T. Narten (December 2011)
  21. IPv6 Transition Mechanism / Tunneling Comparison. [2008-12-27]. (原始內容存檔於2008-11-25). 
  22. Rodriguez, Adolfo; John Gatrell; John Karas; Roland Peschke. Internet transition - Migrating from IPv4 to IPv6. TCP/IP Tutorial and Technical Overview. IBM. 2001-08-06 [2008-08-15]. (原始內容存檔於2008-12-05). These techniques are sometimes collectively termed Simple Internet Transition (SIT). 
  23. IPv6: Dual stack where you can; tunnel where you must. www.networkworld.com. 2007-09-05 [2012-11-27]. (原始內容存檔於2008-05-11). 
  24. RFC 3056: Connection of IPv6 Domains via IPv4 Clouds
  25. RFC 4380: Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
  26. The Windows Vista Developer Story: Application Compatibility Cookbook. [2008-12-27]. (原始內容存檔於2008-04-21). 
  27. RFC 4214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
  28. RFC 3053: IPv6 Tunnel Broker
  29. Internet Society - World IPv6 Day. Internet Society. [2011-06-07]. (原始內容存檔於2011-06-06). 
  30. 中共中央办公厅 国务院办公厅印发《推进互联网协议第六版(IPv6)规模部署行动计划》_中央有关文件_中国政府网. www.gov.cn. [2022-06-02]. (原始內容存檔於2022-04-19). 
  31. 中国IPv6地址数量超美国专家将来一人一IP 监控更容易. RFI - 法國國際廣播電台. 2021-04-23 [2022-08-18]. (原始內容存檔於2022-08-18) (中文(簡體)). 
  • RFC 2460 - Internet Protocol, Version 6 - 現在版本
  • RFC 1883 - Internet Protocol, Version 6 - 舊版本
  • RFC 5214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) - 現在版本取代RFC 4214

外部連結[編輯]

Module:Authority_control第183行Lua錯誤:attempt to index field 'wikibase' (a nil value)