第一章 IPv6 簡介 Not every flower can represent love, but roses did it Not every tree can stand thirst, but cactus did it Not every protocol can fit the future, but IPv6 did it. IPv6, the standard of the Internet Future.
章節目錄 網路的趨勢與發展 網路的基本協定 :OSI 與 TCP/IP IP 的角色 IP 的演進 IPv6 的特徵 IPv6 標準化狀況 IPv6 的基本架構 參考文獻
網路的趨勢與發展 Moore s Law: 平均每 18 個月晶片的容量會成長一倍, 而成本卻減少一倍 New Moore s Law - 光纖定律 : 網際網路頻寬每九個月就會增加一倍的容量 而成本降低一半
全球 DNS 有註冊的主機數量 18000 16000 14000 12000 20 2001 2000 1999 1998 1997 1996 1995 1994 1993 8000 10000 6000 4000 2000 0 2002
Internet 起源 1969 年, 美國國防部 (DoD) 開立的美國國防部高等研究計劃局 (ARPA) 建立 ARPANet 1973 年, 全錄公司帕洛亞托研究中心 (PARC), 成功發展出乙太網路 (Ethernet) 1986 年, 美國國家科學基金會根據原先 ARPANet 使用的 TCP/IP 通訊協定, 建立了 NSFNet 1991 年, 國家科學基金會正式宣佈開放於商業用途使用 1993 年, WWW 介面問世
台灣的網際網路發展 1986 年, 幾所國立大學院校之相同廠牌的電腦主機加以電信局的數據線路連接, 形成 IFNET 與 UNINET 兩個網路 教育部電算中心與台灣 IBM 公司 教學研究資訊服務 合作計畫, 連線到台大等十五個學校, 發展至後來建立的 TANet 1987 年, 連線日本 BITNET 國際學術網路, 透過與日本東京理科大學 (SUT) 與全世界 BITNET 節點互傳訊息
台灣的網際網路發展 1989 年, 教育部電算中心研擬 大學高速學術網路 (TANet) 取代 BITNET, 以 FDDI 網路為骨幹架構, 各校內以 Ethernet 形成校園區域網路, 架構於各主要大學之間 1990 年, 校際之間網路通訊協定採 TCP/IP 標準, 將此命名為台灣學術網路 以 Internet 架構之 9.6kbps 專線串接校際 1991 年,TANet T1 骨幹開始運作,12 月以 64kbps 接通美國美國普林斯頓大學 JvNCnet, 並可直接連通美國國家科學基金會網路 (NSFNET) 骨幹, 正式開啟了我國 Internet 的時代
IPv6 的發展 1992 年,IETF 之 IPv4 的 Address 空間不足的問題開始被檢討 1994 年, 下一代的網際網路協定開始被提案, CATNIP (Common Architecture for the Internet),TUBA (TCP/IP with Bigger Addresses),SIPP (Simple Internet Protocol Plus) 三個提案中出線 1995 年,SIPP 被更名為 IPv6,IPv6 的規範將被 RFC1752(The Recommendation for the IP Next Generation Protocol) 公開
IPv6 的發展 1998 年,IPv6 之位址架構與通訊協定之規範分別在 RFC2373 (IP Version 6 Addressing Architecture) 與 RFC2460(Internet Protocol Version 6(IPv6) Specification) 公開 1999 年, 全球第一個業界團體 ( 共有 42 個單位加盟 ) 成立了 IPv6 Forum ARIN 將全球第一個之 IPv6 Prefix:2001:400::/35 授予給 ESnet 2002 年, 全球各區域性的 Internet Registry RIR(Regional Internet Registries) 實施新的 IPv6 Address Allocation and Assignment Global Policy
網路的基本協定 :OSI 與 TCP/IP 網際網路的目的是讓電腦能互相溝通 正如人與人相互對話一樣, 只懂中文的人是無法跟只懂英文的人對談的, 因此, 要達成此目的有一必要條件 : 讓電腦說共同的語言 這樣的語言我們稱之為電腦的通訊協定 (Protocol)
OSI 模型 1980 年國際標準組織 ISO(International Organization for Standardization) 制定了 OSI (Open System Interconnection) 的基本模型 網路架構模型分成 7 層 ( 7-Layer Reference Model) 這種堆疊式的多層模型即稱作協定堆疊 (protocol stack)
OSI 協定堆疊
OSI 模型層與層間的關係
DoD 模型 當初為了 ARPANet 實驗計畫開發出來的模型, 又稱之為 ARPANet 模型 TCP/IP 是依此建立出來的, 又有人稱之他為 TCP/IP 模型 先成為公認準則後, 才正式成為標準文件 (RFC: Request For Comments) 的一部分, 因此也被稱為通信協定的 The Fact Standard d
DoD D 模型層與層間的關係
兩種模型與實際協定對照圖
IP 的角色 網路的門牌號碼 :IP, 位於網路堆疊的中心位置, 兼容不同的網路介面, 對 Transport Protocol 或 Application 提供統一的通訊方式
IP 位址分配的組織 以紐約的 IANA 為中心, 其下再依區域分成四個區域註冊中心 (Regional Internet Registries), 歐洲地區 :RIPE NCC(Réseaux IP Européens Network Coordination Centre) 北美地區 : ARIN(American Registry for Internet t Numbers) 亞太地區 : APNIC(Asia Pacific Network Information Centre) 拉丁美洲 :LACNIC(Latin American and Caribbean IP address Regional Registry)
IPv4 位址的分配類別 類網路主機最多主機可分配的別位址位址數量組織數 A 8 位元 24 位元 16,777,, 214 128 B 16 位元 16 位元 65,534534 16,384 C 24 位元 8 位元 254 2,097,152
Class-ful IPv4 Address bits 0 1 2 3 4 8 16 24 31 Class A 0 Network Host 1.0.0.0 to 127.255.255.25 Class B 1 0 Network Host 128.0.0.0 to 191.255.255.25 Class C 1 1 0 Network Host 192.0.0.0 to 223.255.255.25 Class D 1 1 1 0 Multicast address 224.0.0.0 to 239.255.255.25 Class E 1 1 1 1 Reserved 240.0.0.0 to 255.255.255.25
IP 路由 決定要經過何種路徑能到達 IP 位址所表示的目的地的架構 Datagram (per packet) Hop by Hop 參照路徑表
IP 的演進 1981 年 9 月,RFC791 制定了 Version 4 (IPv4) 的版本, 從誕生迄今大約經過了 20 年的時間 在這段期間電腦的技術有很大的進步, 出現了各式各樣在當初設計 IPv4 時所未被設想到的使用型態 網路的急速普及化, 也使得現在的網路規模遠超過設計當初的預期
IPv4 的 20 年 1981 年 9 月,RFC791 規定 IPv4 未被設想到的使用型態 - 可移動的節點網路的急速普及化 - 網路規模遠超過設計當初的預期 1990 年代前期,IETF 開始檢討以下的 3 個問題 今後網路發展的預測及仰賴 IPv4 所能維持的極限 IPv4 的延續策略設計新的 IP 及策定轉移計畫
IP 位址數的不足 IPv4 的極限 類別基礎的 IP 位址分配方法, 類別 C 的 IP 位址是以最後 8 位元為網路大小, 真正單位所需要的 IP 位址數跟實際上所分配到的 IP 位址數會有所差距, 造成位址分配較沒有彈性 路由表太大接續上的網路數量增加的話, 路由表也會跟著變大解決的方法 CIDR NAT IPv6
CIDR 廢止 IP 分類方式, 讓一單位可被分配幾個連續的類別 C 位址 (subnet 大小不一定的 8 的倍數, 而是可變動的 ) 加入維持路徑表大小的技術, 利用路由彙整方式來維持路由表的大小遭遇困難 : 匯集的網路都必須是集中在附近的 各地域 國家 沿著 Nt Network 的接續構造來分割區塊進而作分配 這跟目前實際依組織分配, 散佈全球的 IP 規劃是大不相同的, 也使得實際達成的可能性微乎其微
NAT Network Address Translation 只對出入閘道分配真實位址, 內部的主機則採用私有位址的方式 以閘道器來做轉換 遭遇問題 : 沒有真實位址, 無法達成 P2P 通信 安全性問題 效能不彰
朝向 IPv6 IPv4 的各式延續策略, 讓 IP 的短缺暫時脫離了窘境, 然而, 這些方法終究會到達極限 新一代的 IP 協定的考量 相符於 IPv4 於目前協定堆疊中的流程 基本的動作相同更單純化的 Protocol 解決至目前為止的問題點 位址空間的不足 Multicast Mobile 更容易運用 Plug and Play Security 可以因應後續長時間的發展容易擴充新功能 容易自 IPv4 轉移
IPv6 的發展 最初被稱為下一代 IP(IPng: IP The Next Generation) 的協定 CATNIP TUBA 與 SIPP 三種協定, 是最被任認可的版本 IETF 最後決定採用 SIPP 1995 年 SIPP 被更名為 IPv6
IPv5? Internet 的版本序號是由 IANA 管理 第五版被 RFC1190(Experimental Internet Stream Protocol, Version 2(ST-Ⅱ)) 歸為實驗型行的 Protocol 新的 IP 版本就成了第六版版本序號 :7 8 9 及 15 都已被預約了, 沒被預約的只有 10~14 14 因此當下一次再有 IP 的下一版本要提出時, 應該是用第十版了
IPv6 的特徵 提供新的定址方式 可擴充新的通信協定
位址空間的擴充 版本位元數位址數量 IPv4 32 4,294,967,296 個 IPv6 128 340,282,366,920,938,463,463,3 74,607,431,768,211,456 個 ( 3.4x10 38 )
Why not > 128 bits? 考慮到 IP 標頭處理所造成的浪費 協定標頭長度 MTU 標頭浪費 IPv4 20bytes 576bytes 3.5% IPv6 40bytes 1,280bytes 3.1% 位址空間擴充了, 但標頭浪費卻幾乎不變, 可以判斷這樣的位址長為 128bits 是妥當的
標頭的簡化 刪除了許多 IPv4 的欄位 標頭長度識別子 (Identifier) 分段位移 (Fragmentation Offset) 檢查碼 (Checksum) 服務類別 (Type of Service) 減輕網路中路由器的負擔 IPv6 的基本標頭從可變長度變更成固定長度取消路由器對封包的分割處理刪除 Checksum 機制
可擴充協定標準 IPv4 使用 Option 欄位, 但只限於這一個標頭 IPv6 除基本標頭外, 可再加上一或多個延伸標頭來形成 IPv6 Basic 標頭 + Extension 標頭 (s) + Data
其他特徵 即插即用 DHCPv6 Statefull 自動設定 Stateless 自動設定 可並存於原有 IPv4 的環境下進行通信強化的安全性 內建 IPsec 更好的品質管控 (QoS)
IPv6 標準化狀況
IETF 公開的標準 首先提案 :1995 年 12 月 RFC1883(Internet Protocol, Version6(IPv6) Specification) 目前的標準規範 :1998 年 12 月 RFC2460(Internet Protocol, Version6(IPv6) Specification) 位址的分配方式 : 2003 年 4 月 RFC3513(Internet Protocol Version 6 (IPv6) Addressing Architecture)
IPv6 的基本架構 IPv4 vs. IPv6
IPv4 Packet 傳送架構
Local Network 標頭 Ethernet DIX Frame vs. IEEE802.3 Frame
IPv4 傳送架構欄位 IPv4 標頭 ( 包含 Option) 相當於 OSI 參考模型中第 3 層的協定, 是 TCP/IP 最重要的 部分 不含 Option 時, 標頭長度為 20Byte 包含 Option 時, 即為可變長度 TCP/UDP 標頭 相當於 OSI 參考模型的第 4 層 (Transport 層 ) 之 Protocol, TCP 不含 Option 時其標頭長度為 20Byte, 包含 Option 時, 則為可變長度 使用 UDP 時, 標頭長度為 8Byte Application Data 上三層中各式的 Service 所產生的資料 Local Network Layer Tailer 對應於 Local Network 標頭 也就是說, 附加於 Local Network Protocol 之 Packet 的最尾端, 與 OSI 參考模型的第 1 層及第 2 層 ( 物理層及 Data Link 層 ) 相對應 以 Ethernet 而言,Tailer 為附有 4Byte 之 FCS (Frame Check Sequence) 的資料, 可確認 Frame 有無正常運作
IPv6 Packet 傳送架構 與 IPv4 不同處
IPv4 Header RFC791(Internet Protocol DARPA Internet Program Protocol Specification) 於 IPv6 取消或變更的欄位
IPv4 Header 欄位 Version (4 bits) 表示 Internet Protocol 的版本號碼 IPv4 為 0100 IHL:Internet t Header Length (4 bits) 表示 IP 標頭長度的欄位 每 32 Bits(4Bytes) 為一個單位 TOS:Type of Service (8 bits) 指定 IP Service 品質需求的欄位 但因定義不明確導致相互運用不便, 實際上不太被廣泛使用 Total Length (16 bits) 以 Byte 為單位表示封包的總長度, 這個長度包含 IP 標頭及資料
IPv4 Header 欄位 Identification (16 bits) 記錄被分割 (Fragment) 的封包, 重新組合時的參考資料 Flags (3 bits) 這個旗標的最後一個位元是在記錄經分割的封包之後是否還有其他封包存在 Fragment Offset (13 bits) 表示被分割的資料, 在 Datagram 中的原始位置 Time of Live (8 bits) 記錄封包可以在網路內停留的最長秒數 實際的運用是以通過路由器的台數 (Hop Count) 來計算的
IPv4 Header 欄位 Protocol (8 bits) 顯示 IP 的上層 (TCP 或 UDP 等 ) 協定的代碼 Header Checksum (16 bits) 用來檢查標頭內是否有錯誤用的 Source Address (32 bits) 封包來源的 IPv4 位址 Destination Address (32 bits) 封包目的地的 IPv4 位址
IPv4 Header 欄位 Option ( 可變長度 ) 包含加密等種種附加的服務功能參數都包含在此欄位 Padding ( 可變長度 ) 此欄位的功用為, 使用 Option 時, 當 Option 欄位資料的大小不為 32 Bits 的整數倍時, 以 0 填滿, 是其成為 32 Bits 的整數倍
IPv6 Header
Flow Label A flow: a sequence of packets which the source desires special handling (by hop-by-hop option or control protocol) identified by combination of source address and non-zero flow label(randomly and uniformly chosen), as a hash key used by router. All packets belonging to the same flow must have the same source address, destination address, priority, it and flow label The router may cache the information of next-hop interface, decide how to queue the packet based on its priority, etc Maximum lifetime of a flow must be specified.
Traffic Class The 8-bit Traffic Class field in the IPv6 header is available for use by originating i i nodes and/or forwarding routers to identify and distinguish between different classes or priorities i i of IPv6 packets. E.g., used as the codepoint in differentiated services General requirements Service interface must provide a means for upper-layer protocol to supply the value of traffic class Value of traffic class can be changed by source, forwarder, receiver An upper-layer protocol should not assume the value of traffic class in a received packet has not been changed.
IPv6 Header 欄位 Version (4 bits) 表示 Internet Protocol 的版本號碼 IPv6 即為 0110 Traffic Class (8 Bits) 表示封包的類別或優先度 這個欄位與 IPv4 之 "Service Type" 提供相同的功能 Flow Label (20 Bit) 顯示封包所屬的 Flow 編號 在不支援 Flow Label 欄位的機能的主機或路由器上, 會使用其預設值 0 Payload Length (16 Bit) 以無號整數表示在 IPv6 基本標頭之後剩下的封包長度, 以 Byte 為單位計算
IPv6 Header 欄位 Next Header (8 bits) 值 (10 進位 ) 下一個標頭的種類 0 Hop By Hop Option Header 6 TCP 17 UDP 41 Capsule IPv6 Header 43 Routing Header 44 Fragment Header 46 Resource Reservation Protocol 50 Security Payload Capsule Header (RFC2406) 51 Authentication Header (RFC2402) 58 ICMPv6 59 No Next Header 60 Destination Option Header
IPv6 Header 欄位 Hop Limit (8 bits) 以無號數表示 IPv6 封包被捨棄之前最多可經過的 節點數 Source Address (128 bits) 封包來源的 IPv6 位址 Destination Address (128 bits) 封包目的地的 IPv6 位址 一般來說, 會設定為最終目的地的位址, 但若延伸標頭中有 Routing Header 存在時, 則不設定最終目的地, 而是設定於 Source Routing List 所記錄的下一個 Route Interface 的位址
Option 的功能 並不是所有的 IPv6 封包都需使用延伸標頭 : 當遇到沒有支援的延伸標頭時, 回覆給對方 ICMP Parameter Problem Message (Type=1, Code=1), 將封包捨棄 有延伸標頭, 但附有延伸標頭的 Option 不被支援時, 對 Option 編號要求錯誤處理
IPv6 封包延伸標頭的例子
延伸標頭完全實作的標準 Hop By Hop Option Header(RFC2460) Routing Header (Type 0) (RFC2460) Fragment Header(RFC2460) Destination Option Header(RFC2460) Authentication Header (RFC2402) Security Payload Capsule (ESP: Encapsulating Security Payload) Header (RFC2406)
延伸標頭出現的順序 IPv6 header Hop-by-Hop Options header Destination Options header Routing header Fragment header Authentication header Encapsulating Security Payload header Destination Options header
Hop By Hop Option Header Next Header (8 bits) 顯示緊接於 Hop By Hop Option 標頭之後連續標頭的種類 Hdr Ext Len (Header Extension Length) (b Bits) 以無號數來表示 Hop By Hop Option 標頭的長度, 以 8 Bytes 為單位 這個長度沒有包含 Hop By Hop Option 標頭最初的 8 Bytes Options ( 可變長度 ) 含一個以上以 TLV (Type-Length-Valve) 方式編碼的選項
Routing Header Next Header (8 bits) 顯示緊接於 Routing Header 之後連續標頭的種類 Hdr Ext Len (Header Extension Length) (8 bits) 以無號數來表示 Hop By Hop Option 標頭的長度, 以 8 bytes 為單位 Routing Type (8 bits) 表示特定的路由型態 Segments Left (8 bits) 以無號數來表示來表示剩餘 Segment 數, 也就是顯示出到達最終目的地必通過之路徑的 Segment 數 Type-Specific Data ( 可變長度 ) 此欄位的內容與型式由指定的 Routing Type 決定
Source Routing (Routing Type=0) LSRR (Loose Source and Record Route) 對於路徑上的 Segment, 會傳達已傳送位址後下一個目的地位址不緊鄰也可以的訊息 SSRR (Strict Source and Record Route) 對於路徑上的 Segment, 會傳達已傳送位址後下一個目的地位址非緊鄰不可的訊息
Type 0 routing header Routing Header For unicast packet only Source places the destination address at the last position of the address list in the routing header Destination address in the IPv6 header is the first (next) desired router on the path The routing header will not be examined until the packet reaches the node identified in the IPv6 header Processing the routing header For strict route, if the first address in the address list is not directly connected, discard the packet Otherwise, swap the destination address of the IPv6 header with address[hdr_ext_len/2-seg_left], decrease the segment left field
Source Routing 的例子
Routing Header Example Source: S, Destination: D Intermediates: I1, I2, I3 As the packet travels from S to I1 Source address = S Destination=I1 Segment left = 3 Address[1]=I2 Address[2]=I3 Address[3]=D As the packet travels from I1 to I2 Source address = S Hdr Ext Len = 6 Destination = I2 Segment lft left = 2 Address[1]=I1 Address[2]=I3 Hdr Ext Len = 6 (in units of 64 bits) Address[3]=D
Routing Header Example As the packet travels from I2 to I3 Source address = S Hdr Ext Len = 6 (in units of 64 bits) Destination=I3 Segment left = 1 Address[1]=I1 Address[2]=I2 Address[3]=D As the packet ttravels from I3 to D Source address = S Hdr Ext Len = 6 Destination = D Segment left = 0 Address[1]=I1 Address[2]=I2 Address[3]=I3
Fragment Header Next Header (8 bits) 顯示緊接於 Fragment 標頭之後連續標頭的種類 Reserved (8 bits) 為被保留之欄位 傳送時為 0, 接收時則忽略掉 Fragment Offset (13 bits) 無符號整數 相對於原始標頭之分割部分的起點, 跟隨在此標頭之後的資料偏移值, 以 8bytes 為單位 M Flag (1 bit) M Flag = 1 尚有 Fragment M Flag = 0 最終的 Fragment Identification (32 bits) 原本附加於各 Fragment 之識別子, 可於 Packet 再構成時使用
Fragmentation Example IPv6 Header Fragment 1 Data Fragment 2 Data Fragment 3 Data (a) Original packet IPv6 Header Fragment Header Fragment 1 Data IPv6 Header Fragment Header Fragment 2 Data IPv6 Header Fragment Header Fragment 3 Data (b) Fragments
Packet Size Issue MTU of every link must >= 1280 bytes Use Path MTU Discovery to discover MTU greater than 1280 bytes A node need to accept a fragmented packet that is as large as 1500 octets
Reassembly Unfragmentable part of the reassembled packet consists of all headers up to the fragment header The next header in the unfragmentable part is replaced by the next header field of the first fragment s fragment theader Payload length computation PL.org = PL.first - FL.first - 8 + (8*FO.last) + FL.last PL: payload py FL: fragment length FO: fragment offset Header length up to routing header
Destination Options Header Next Header (8 bits) 顯示緊接於 Destination Options Header 之後連續標頭的種類 Hdr Ext Len (Header Extension Length) (8 bits) 以無號數來表示 Destination Options Header 的長度, 以 8 bytes 為單位 這個長度沒有包含 Destination Options Header 最初的 8 bytes Options ( 可變長度 ) 此欄位包含一個以上的 TLV (Type-Length-Valve) 編碼的 Option 選項
No Next Header 下一個標頭欄位值為 59 時, 即表示下一個延伸標頭不存在
認證標頭
認證標頭 Next Header (8 bits) 顯示緊接於認證標頭之後連續標頭的種類 Payload Length (8 bits) 認證標頭的長度, 以 4 Bytes(32 bits) 單位表示 這個長度沒有包含認證標頭最初的 8 bytes Reserved (16 bits) 為被保留之欄位 傳送時為 0, 接收時則忽略掉
認證標頭 Security Parameter Index(SPI) (32 bits) 這個欄位值 (SPI 值 ) 以 32 bits 的值將此 Dt Datagram 之 Security Association(SA) 指定出來 Sequence Number (32 bits) 這個欄位為無號數計數器, 是用於防止 SA Replay(anti- replay Protection) 用的 Authentication Data (32 bits 倍數的可變長度 ) 這個欄位值為以 32 bits 的整數倍之可變長度, 包含為了檢查此封包的安全性之 Integrity Check Valve 值 (ICV) 無法成為 32 bits 的整數倍時, 用 Padding 來填補
Security Payload Capsule Header
Security Payload Capsule Header SPI:Security Parameters Index (32 bits) 這個欄位以任意之 32 bits 的值將此 Dt Datagram 之 Security Association SA 指示出來之識別子 Sequence Number (32 bits) 這個欄位為無號數計數器, 是用於防止 SA Replay(antireplay Protection) 用的 Payload Data ( 可變長度 ) 這個欄位值為以 32 bits 的整數倍之可變長, 包含下一個標頭所顯示之 Data 此 Filed 是必要的 Padding ( 可變長 0~255 bytes) 這個欄位是被加密所使用 Payload Data 以加密演算法需要之 Block Size 的倍數被填入
Security Payload Capsule Header Padding Length (8 bits) 計算前一個 Pddi Padding 的長度, 以 byte 為單位 數值範圍是 0~225,0 則表示沒有 Padding byte 此欄位是必要的 Next Header (8 bits) 顯示緊接於 Security Payload Capsule Header 之後連續標頭的種類 Authentication Data (32 bits 倍數的可變長度 ) 這個欄位值為以 32 bits 的整數倍之可變長度, 包含為了檢查自此 ESP Packet 減去認證標頭後計算之 Packet 的安全性之 Integrity Check Valve 值 (ICV) 無法成為 32 bits 的整數倍時, 用 Padding 來填補
參考文獻 [1]Internet Software Consortium: http://www.isc.org/ [2] Internet Assigned Numbers Authority: http://www.iana.org/ [3] Internet Engineering Task Force: http://www.ietf.org/ [4] Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. RFC1519. V. Fuller, T. Li, J. Yu, K. Varadhan. September 1993. [5] Traditional IP Network Address Translator (Traditional NAT). RFC3022. P. Srisuresh, K. Egevang. January 2001. [6] Internet t Protocol, Version 6 (IPv6) Specification. RFC2460. S. Deering, R. Hinden
參考文獻 [7] Neighbor Discovery for IP Version 6 (IPv6). RFC2461. T. Narten, E. Nordmark, W. Simpson. December 1998. [8] IPv6 Stateless Address Autoconfiguration. RFC2462. S. Thomson, T. Narten. December 1998. [9] Internet t Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC2463. A. Conta, S. Deering. December 1998. [10] IP Authentication Header. RFC2402. S. Kent, R. Atkinson. November 1998. [11] IP Encapsulating Security Payload (ESP). RFC2406. S. Kent, R. Atkinson. November 1998.