IPv6 Tutorial: Mobility 主講人 : 國立東華大學電機系趙涵捷教授

Online Why Ipv6 Addressing Routing Transition Mobile IPv4 Mobile IPv6 Mobile IPv6 --Dynamic Home Agent Address Discovery Mobile IPv6 Security--Return Routability Mobile IPv4 vs. Mobile IPv6 IPv6 Networks in Taiwan 6NDHU Current Researches

Why IPv6

IPv4 所面臨的問題 IPv4 位址的消耗之問題  IPv4 定址方式 IPv4 定址 Subnetting 可變長度子網路遮罩 (VLSM-Variable Length Subnet Mask)  IPv4 位址不足的處理方式 CIDR NAT  IPv4 定址架構相關技術之 RFC  亞太地區 IPv4 目前使用狀況 Routing Table 成長遽增的問題  Routing Table 介紹  Routing Table 成長所造成的各項問題

IPng project 為什麼需要新的 IP 位址架構  IPv4 位址使用量供不需求  對於未來網際網路架構需調整 RFC 1287 Towards the Future Internet Architecture 未來網際網路架構所提出的新方案 --RFC 1454 IPng 後來的選擇 —IPv6

IPng 後來的選擇 1996 討論與支持 IPv6 之建議書誕生  RFC 綜合 TUBA 及 SIPP 提出 IPv6 目前幾個主要 IPv6 之 RFC 如下  Specification (RFC2460)  Neighbour Discovery (RFC2461)  ICMPv6 (RFC2463)  IPv6 Addresses (RFC2373/4/5)  RIP (RFC2080)  BGP (RFC2545)  IGMPv6 (RFC2710)  OSPF (RFC2740)  Router Alert (RFC2711)  Jumbograms (RFC2675)  Autoconfiguration (RFC2462)

Addressing

Header 比較 --IPv4 Header 20 Octets+Options : 13 fields, include 3 flag bits 0 bits VerIHLTotal Length IdentifierFlagsFragment Offset 32 bit Source Address 32 bit Destination Address 24 Service Type Options and Padding Time to Live Header Checksum Protocol RemovedChanged

Header 比較 --IPv6 Header 40 Octets, 8 fields 031 VersionClassFlow Label Payload LengthNext HeaderHop Limit 128 bit Source Address 128 bit Destination Address

Differences between IPv4 and IPv6 FeatureIPv4IPv6 Source and destination address 32 bits128 bits IPSecOptionalrequired Payload identification for QoS in the header No identificationUsing Flow label field FragmentationBoth router and the sending hosts Only supported at the sending hosts Checksum of header includedNot included Resolve address to a link layer address broadcast ARP request Multicast Neighbor Solicitation message

Differences between IPv4 and IPv6(Cont.) FeatureIPv4IPv6 Determine the address of the best default gateway ICMP Router Discovery(optional) ICMPv6 Router Solicitation and Router Advertisement (required) Send traffic to all nodes on a subnet BroadcastLink-local scope all- nodes multicast address Payload identification for QoS in the header No identificationUsing Flow label field Configure addressManually or DHCPautoconfiguration Map hosts name to addresses AAAAA Manage local subnet group membership (IGMP)Multicast Listener Discovery (MLD)

IPv6 定址架構 128 bits long. Fixed size = 3.4×10 38 addresses => 6.65×10 23 addresses per m 2 of earth surface If assigned at the rate of 10 6 /  s, it would take 20 years Allows multiple interfaces per host Allows multiple addresses per interface

IPv6 -- 定址模式 ( 一 ) Link-Local Site-LocalGlobal  Addresses are assigned to interfaces No change from IPv4 Model  Interface ‘expected’ to have multiple addresses  Addresses have scope Link Local Site Local Global  Addresses have lifetime Valid and Preferred lifetime

IPv6 -- 定址模式 ( 二 ) Top Level Next Level Site Level Public Topology (Transit providers, ISPs & Exchanges) Site Topology (LAN) & Interface ID (link)

IPv6 -- 定址模式 ( 三 ) LAN addressing Subnet prefix + MAC address = /128 /128 SUBNET PREFIX /64 /128

IPv6 -- 定址模式 ( 四 ) 位址表示方式 Address syntax  Hexadecimal values of eight 16 bit fields X:X:X:X:X:X:X:X (X=16 bit number, eg: A2FE) 16 bit number is converted to a 4 digit hexadecimal number IPv6 位址表示方式  Preferred form: 1080:0:FF:0:8:800:200C:417A  Compressed form:FF01:0:0:0:0:0:0:43 becomes FF01::43  IPv4-compatible:0:0:0:0:0:0: or :: IPv4 位址表示方式 

IPv6 -- 定址模式 ( 五 ) 位址類型 Unicast  Address of a single interface  Delivery to single interface Multicast  Address of a set of interfaces  Delivery to all interfaces in the set Anycast  Address of a set of interfaces  Delivery to a single interface in the set No more broadcast addresses

IPv6 -- 定址模式 ( 六 ) IPv6 位址範圍 各個 RIR 的 IPv6 範圍  APNIC2001:0200::/23  ARIN2001:0400::/23  RIPE NCC2001:0600::/23 6Bone3FFE::/16 6to4 tunnels2002::/16 APNIC 之 IPv6 申請 

IPv6 -- 定址模式 ( 七 ) Address Type Prefixes Address type Binary prefix IPv4-compatible (96 zero bits) global unicast001 link-local unicast site-local unicast multicast all other prefixes reserved (approx. 7/8ths of total) anycast addresses allocated from unicast prefixes

Global Unicast Addresses site topology (16 bits) interface identifier (64 bits) public topology (45 bits) interface IDSLA*NLA*TLA 001 TLA = Top-Level Aggregator NLA* = Next-Level Aggregator(s) SLA* = Site-Level Aggregator(s) all subfields variable-length, non-self-encoding (like CIDR) TLAs may be assigned to providers or exchanges

特殊 Unicast 位址 unspecified address  0:0:0:0:0:0:0:0  與 IPv4 的 意義相同 loopback address  0:0:0:0:0:0:0:1  與 IPv4 的 意義相同

Link-Local 及 Site-Local 位址 Link-local addresses for use during auto- configuration and when no routers are present: FE80 Site-local addresses for independence from changes of TLA / NLA*: FEC interface ID interface IDSLA*

Interface IDs Lowest-order 64-bit field of unicast address may be assigned in several different ways:  auto-configured from a 64-bit EUI-64, or expanded from a 48-bit MAC address (e.g., Ethernet address)  auto-generated pseudo-random number (to address privacy concerns)  assigned via DHCP  manually configured  possibly other methods in the future

定址空間

Routing in IPv6

As in IPv4, IPv6 supports IGP and EGP routing protocols:  IGP for within an autonomous system are RIPng (RFC 2080) OSPFv3 (RFC 2740) Integrated IS-ISv6 (draft-ietf-isis-ipv6-02.txt)  EGP for peering between autonomous systems MP-BGP4 (RFC 2858 and RFC 2545) IPv6 still uses the longest-prefix match routing algorithm

Routing in IPv6 RIPng(Distance-Vector Algorithm)  RIPv2, supports split-horizon with poisoned reverse  RFC2080 i/IS-ISv6  Shared IGP for IPv4 & IPv6  Route from A to B same for IPv4 & IPv6  Separate SPF may provide SIN routing OSPFv3  « Ships in the Night » routing  Need to run OSPFv2 for IPv4  Route from A to B may differ for IPv4 & IPv6

Routing in IPv6 BGP4+  Added IPv6 address-family  Added IPv6 transport  Runs within the same process - only one AS supported  All generic BGP functionality works as for IPv4  Added functionality to route-maps and prefix- lists

From Daniel G. Waddington et al.

IPv4/IPv6 Transition

Transition between IPv4 & IPv6 NGTRANS Translator Dual Stack Tunneling

Basic Transition Approaches  Dual Stack and Tunneling  Dual Stack - system completely supports IPv6  Tunneling - IPv6 packets are encapsulated for transmission over existing IPv4 infrastructure  Translation  IPv6 packets are translated into IPv4 packets and vice versa  Header information is preserved as much as possible

Dual Stack RFC 1933 NGTRANS draft : Draft-ietf-ngtrans-dstm-07.txt IPv4/IPv6 Dual Stack Dual Stack IPv6 IPv4 Dual Stack AIIH (DHCPv6, DNS)

Dual Stack Mechanisms  Simple dual stack  Both IPv4 and IPv6 are directly supported  Dual Stack Transition Mechanism  Temporary IPv4 addresses are assigned when communicating with an IPv4-only host.  Cooperation between DNS and DHCPv6  Dynamic Tunnel Interface encapsulates the IPv4 packets

Tunneling IPv4 RFC 1933 RFC 3056 RFC 3053 IPv4 IPv6 6over4 6to4 IPv4 IPv6 IPv4/ IPv6 Tunnel Broker

Tunneling Mechanisms  Configured tunnels  Connects IPv6 hosts or networks over an existing IPv4 infrastructure  Generally used between sites exchanging traffic regularly  Automatic tunnels  Tunnel is created then removed after use  Requires IPv4 compatible addresses

Tunneling Mechanisms  Tunnel Broker  Allows web-based setup of a tunnel  Connects an isolated host to IPv6 net of provider operating the tunnel broker  6 over 4  Allows isolated IPv6 hosts to communicate over an IPv4 infrastructure without explicit tunnels  Uses IPv4 multicast to enable Neighbor Discovery

Tunneling Mechanisms  6 to 4  Allows communication of isolated IPv6 domains over an IPv4 infrastructure  Minimal manual configuration  Uses globally unique prefix comprised of the unique 6to4 TLA and the globally unique IPv4 address of the exit router.

Translator RFC 2765 ； RFC 2766 RFC 2767 RFC 3089 ； RFC 3142 IPv6 IPv4 NATPT SIIT IPv4 Apps BITS IPv6 Stack IPv4 Apps BITS IPv6 Stack IPv6 Host IPv6IPv4 Host Socks-Gateway TCPUDP-Relay

SIIT Suitable for use when IPv6 side has no IPv4, for instance, for embedded systems with stack on chip. Ipv6 side uses special, “translatable” addresses, which preserve TCP/UDP checksum value Translatable source address is received by the IPv6 node from a shared pool ; translatable destination address is made from IPv4 DNS entry Options are not translated Multicast is not translated Authentication headers cannot be translated because of fragment identifier Stateless translation is not a full-services transition scenario, but it covers common traffic such as mail and web

SIIT

IPv4 network Pool of IPv4 addresses SIIT IPv6 host IPv4 host Using SIIT for a signal IPv6-only subnet

SIIT Pool of IPv4 addresses IPv4 network IPv6 hostIPv4 host Dual network Using SIIT for an IPv6-only or dual cloud which contains some IPv6-only hosts as well as IPv4 hosts

NAT-PT operations with DNS-ALG (IPv4  IPv6) V4 address pool NAT-PT DNS-ALG IPv6 host IPv4 Host IPv6 DNS IPv4 DNS Address allocation and create address mapping A6A ipv4.cs.nthu.edu.tw 3FFE:3600:B::2 ipv6.cs.nthu.edu.tw 3FFE:3600:B::3 ipv6DNS.cs.nthu.edu.tw ipv4DNS.cs.nthu.edu.tw (1) (2)(3) (7)(8) (5) (4)(6) A6A : IPv4 address pool 3FFE:3600:B:: : IPv6 IPv4 Address Mapping Table IPv4 Host think it ’ s communicating with IPv6 Host think it ’ s communicating with 3FFE:3600:b:: Final Result

NAT-PT operations with DNS-ALG (IPv6  IPv4) V4 address pool NAT-PT DNS-ALG IPv6 host IPv4 Host IPv6 DNS IPv4 DNS Address allocation(get IPv6 prefix) A6A ipv4.cs.nthu.edu.tw 3FFE:3600:B::2 ipv6.cs.nthu.edu.tw 3FFE:3600:B::3 ipv6DNS.cs.nthu.edu.tw ipv4DNS.cs.nthu.edu.tw (1) (2)(3) (8) (7)(9) (5) (4)(6)A6A : 3FFE:3600:B:: : IPv6 IPv4 Address Mapping Table IPv6 Host think it ’ s communicating with 3FFE:3600:b:: IPv4 Host think it ’ s communicating with Final Result

Dual Stack Transition Mechanism What is it for?  DSTM assures communication between IPv4 applications in IPv6 only networks and the rest of the Internet. IPv6 only IPv4 only ?

Application Layer Gateway ALG 是對應於特定應用程式的代理人，用來 讓 V6 node 可以和 V4 node 互相溝通。有些應 用程式會把網路位址存在封包的 payload 中， 可是 NAT-PT 本身並無法得知 payload 裡存的 是什麼。 ALG 可以協助 NAT-PT 來達到這個 功能。

有無 DNS-ALG 之比較 在沒有 DNS-ALG 的情況下， NAT-PT 只能做到 v6 建立連線到 v4 ， v4 無法透過 NAT-PT 向 v6 建 立連線。  沒有 DNS-ALG

有無 DNS-ALG 之比較 這是假設從 v6 網路到 v4 網路的狀況，其實 v4 到 v6 是一樣的狀況，只是 IPv4 和 IPv6 角色反 過來。  有 DNS-ALG

Ｗ hy???  V4 之所以需要透過 NAT-PT 向 v6 建立連線需 要 DNS-ALG 的協助，是因為一開始， v4 node 並不知道 NAT-PT 會給 v6 node 替代的 v4 address 是什麼。所以得利用 namelookup 來取得該 v6 node 對應的 v4 address mapping ，以建立連線。

FTP-ALG Support FTP control message 中會攜帶 IP address 以 及 TCP port 資訊， FTP-ALG 可以支援 NAT- PT 使得 FTP 在 application level 的轉換沒有問 題。在 RFC2428 中建議利用 EPRT 和 EPSV 兩 個指令分別替代 PORT 和 PASV 指令。

FTP-ALG Support V4 node 可能有 implement EPRT 和 EPSV 也可能沒有。 如果 V4 node 利用 PORT 和 PASV 送出 FTPSession Request 的話， FTP-ALG 會將指令分別轉換成 EPRT 和 EPSV 。 由 V4 node 產生 FTP session 的情況

FTP-ALG Support  第一種方法： FTP-ALG 不改變 EPRT 和 EPSV ，而只是 轉換 成 NAT-PT 或 NAPT-PT 所指定的 IPv4 相對應資訊。但在這種方法下， IPv4 端的 FTP application 必須 upgrade to support EPRT and EPSV 。  第二種方法： FTP-ALG 把 EPRT 和 EPSV 分別轉換成 PORT 和 PASV 。同時也對 這幾個參數做轉換。好處是 IPv4 端的 FTP 不需 upgrade 。壞處是， FTP-ALG 無法對 EPSV ALL 這個指令做對應的轉換，這個情 況下， IPv4 端的 FTP app 會傳回 error 。 由 V6 node 產生 FTP session 的情況

From Daniel G. Waddington et al.

From Mallik Tatipamula et al.

Mobile IPv4

Mobile IP 特性 對於應用與傳輸層協定以及 router 而言， mobile IP 具 有透明性 (transparency) 。 Mobile IP 可與 IPv4 互相運作， mobile host 位址分派式 與一般 host 的分派方式並無差異，不需特殊的定址方 式。 Mobile IP 可廣泛地適用在整個 Internet 上。 Mobile IP 所有的訊息都經過安全認證，可防止任意 host 假扮 mobile host 。 IETF (Internet Engineering Task Force) 為克服原始 IP 定 址模式對 host 移動時的限制，設計出「行動 IP 」 (mobile IP) ，可允許 host 保留原來的位址，且 router 不需使用 host-specific routing 。 Mobile IP 具有下列特性：

Mobile IP 應用發展與趨勢性 無線區域網路產品或無線網路擷取網路 (Radio Access Network) 產 品： WLAN, HYPPER LAN, 或是其他無線區域網路之擷取網路設 備，未來將不僅提供無線存取能力，在基地台間漫遊也將成為這 些設備必備的功能之一。因此結合 Mobile IP 與無線區域網路如 Access Point 和 Access Router 已成為市場可見之產品，預期未來的 無線網路設備將包括 Mobile IP 功能。 無線通訊網路設備：包括 3GPP 及 3GPP2 都提供 Mobile IP 的服務， 也都有相關標準文件的規範。因此諸如 GPRS, UMTS, cdma2000 等網路設備也將具備 Mobile IP 功能以支援行動台的網際網路漫遊 能力。 使用者設備之行動 IP 支援： Mobile IP 需要更動使用者設備，隨著 應用與發展成形，行動使用者設備也將內建 Mobile IP 協定堆疊， 可能的手持式產品除具漫遊能力標準筆記型電腦， PDA 之外，智 慧型手機，手機設備，單模 (Single-Mode) 或多模 (Multi-mode) 手 機都將具備 Mobile IP 功能。

Mobile IP 的運作流程 1. MN 在原網路收到來自 HA 廣播之 Agent Advertisement 信息，得知 所在網路為原網路及 HA 位址。 2. MN 移至其他網路，同時收到 FA 廣播之 Agent Advertisement 信息， 得知已移至其他網路，同時得知 FA 位址。 3. MN 透過 FA 轉送註冊信息給 HA ，並告知 HA 其 CoA 。 4. HA 廣播 Proxy ARP 信息至原網路所有節點，告知目前 MN 的封包 需交由 HA 轉送。 5. CN 傳送至原網路的封包將路由至 HA ， HA 查表得知 MN 之 CoA 透過 Tunneling 將封包包裝後再送至 FA ， FA 收到後，解通道封包 後，將原封包轉送至 MN 。 6. MN 送至外部之封包可以直接遞送﹔若拜訪網路有做封包過濾 (Packet Filtering) ，則可以透過 FA 轉送至 HA 再行傳送到 CN 。 7. MN 返回原網路，傳送解除註冊動作，封包路由回原 MN 。

Mobile IPv4 : Concepts HA Foreign Network Internet CN Home Network FA Agent Advertisement Mobile Node Agent Advertisement

HA Foreign Network Internet CN Home Network FA Mobile Node Registration Request Registration Reply Reply Reg-Req Relay Reg-Req Mobile IPv4 : Concepts

HA Foreign Network Internet CN Home Network FA Mobile Node Registration Request Registration Reply

Mobile IPv4 : Concepts HA Foreign Network Internet CN Home Network FA Mobile Node

Mobile IPv4 : Concepts HA Foreign Network Internet CN Home Network FA Mobile Node Tunneling

Mobile IPv4 : Concepts HA Foreign Network Internet CN Home Network FA Mobile Node ※ MN 送至外部之封包可以直接遞送

Mobile IPv4 : Concepts HA Foreign Network Internet CN Home Network FA Mobile Node ※ 若拜訪網路有作 ingress filtering ， 則可以透過 FA 轉送至 HA 再行傳送 到 CN

Mobile IPv6

Mobility Header 之前 在擁有 Mobility Header 之前 (Draft 第 15 版前 ) ， 許多功能都是定義在 Destination Options 的 Options 裡： 在第 15 版裡 Binding Update Option ： Option type=128 Binding Acknowledgment Option ： Option type=7

Mobility Header 選項 IPv6 封包增加了 Mobility Header 選項 。 封包格式

Mobility Header 選項 Payload Proto:8-bit selector, 和 Next Heaer 相同，用以指 明下一個 Header 。 Header Len:8-bit unsigned integer, 除了前 8 個 byte 外的 Mobility Header 長度。 MH Type:8-bit selector, 用來識別各種特殊的 Mobility 訊息，用來決定 Message Data 的型態。 Reserved:8bit, 留做將來用。 Checksum:16bit unsigned integer, 用 “pseudo-header” 的 方式。 Message Data: 它的內容由 M Ｈ Type 來決定。

Binding Update Message MH Type=5 Message Data: A:Acknowledge H:Home Registration L:Link-Local Address Compatibility K:Key Management Mobility Capability

Binding Acknowledgement Message MH Type=6 Message Data: K:Key Management Mobility Capability

Mobility Options Option Type:8bit,Option 的類型, 同時也決定了 Option Data 的格式。 Option Length:8-bit unsigned integer, 除了 Option Type 和 Option Length 外的 Mobility Options 長度。 Option Data: 它的格式會隨著 Option Type 來定。

Mobile IPv6 運作流程 1. 當 MN 從 Router A 移動到 Router B 之下，會收到新網域中 Router B 所發出來的 RA ，因為此 RA 中所帶的 Network Prefix 與原來不 相同，所以 MN 會察覺到已經到了新網域，而自動設定其 COA 。 2. COA 可以說是 MN 目前所在的資訊，在取得 COA 後， MN 會送出 Binding Update 封包給 HA ，在 Binding Update 中會帶有 CoA Option 。 3. 當 HA 收到 BU 時會更新其 Binding Cache Entry 並且會回覆給 MN 一個 Binding Ack 。 4. 而此時當 CN 要傳送封包給 MN 時，會透過 HA ，利用 Tunnel 轉 送封包給 MN 。 5. 當 MN 收到由 HA 轉送來的封包後， MN 知道尚有 CN 尚未更新其 Binding Cache Entry ，此時 MN 將對 CN 發送出 Binding Update 。 6. 而 CN 將更新其 Binding Cache Entry ，並回覆 Binding ACK 給 MN 。 7. 在此之後， CN 和 MN 將不需再透過 HA ，可以直接溝通。

Mobile IPv6 : Concepts HA Home Network Foreign Network Internet CN Mobile Node IP HeaderPayLoad S ： CN’s IP D ： MN’s Home Address IP HeaderPayLoad S ： MN’s Home Address D ： CN’s IP

Mobile IPv6 : Concepts HA Foreign Network Internet CN Home Network Binding Update Binding Ack Mobile Node PayLoadIP HeaderMobilty Header MH=5 PayLoadIP HeaderMobilty Header MH=6 S ： Home Agent’s address D ： MN’s CoA S ： MN’s CoA D ： Home Agent’s address

Mobile IPv6 : Concepts HA Foreign Network Internet CN Home Network Mobile Node IP HeaderPayLoad S ： CN’s IP D ： MN’s Home Address Ｓ： :Home Agent’s address D ： MN’s COA New IP HeaderOld IP HeaderPayLoad Tunneled packets Ｓ： :CN’s IP D ： MN’s Home Address

HA Internet CN Home Network Mobile Node Mobile IPv6 : Concepts Binding Update Binding Ack PayLoadIP HeaderMobilty Header MH=5 PayLoadIP HeaderMobilty Header MH=6 S ： CN’s IP D ： MN’s CoA S ： MN’s CoA D ： CN’s IP

HA Internet CN Home Network Mobile Node Mobile IPv6 : Concepts S ： MN’s COA D ： CN’s IP PayLoadIP HeaderHA DestOpt (includes MN’s Home Address) S ： CN’s IP D ： MN’s COA PayLoadIP HeaderRouting Header (includes MN’s Home Address)

Mobile IPv6 -- Dynamic Home Agent Address Discovery

Dynamic Home Agent Address Discovery allows a mobile node to dynamically discover the IP address of a home agent on its home link, even when the mobile node is away from home.

Dynamic Home Agent Address Discovery

Mobile IPv6 Security-- Return Routability

HA Internet CN Home Network Mobile Node Return Routability:Step1 PayLoadIP HeaderMobilty Header MH=1 Parameters: +home init cookie Home Test Init Care-of Test Init PayLoadIP HeaderMobilty Header MH=2 Parameters: +Care-of Init Cookie MN requests tokens by sending: Home Test Init(HoTI) Message Care-of Test Init(CoTI) Message

HA Internet CN Home Network Mobile Node Return Routability:Step2 PayLoadIP HeaderMobilty Header MH=3 Parameters: +Home Init Cookie +Home Keygen Token +Home Nonce Index Home Test Care-of Test PayLoadIP HeaderMobilty Header MH=4 Parameters: +Care-of Init Cookie +Care-of Keygen Token +Care-of Nonce Index CN sends tokens to MN by sending: Home Test (HoT) Message Care-of Test (CoT) Message

HA Internet CN Home Network Mobile Node Return Routability:Step3 Binding Update protected by the shared key PayLoadIP HeaderMobilty Header MH=5 Shared Key = SHA1(home keygen token | care-of keygen token) MN and CN generate the shared key from the tokens MN signs a BU message with the key, CN verifies the BU message with the key

Return Routability--Home Test Init(HoTI) MH Type=1 Message Data:

Return Routability-Care-of Test Init(CoTI) MH Type=2 Message Data:

Return Routability-Home Test(HoT) home keygen token := First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0))) MH Type=3 Message Data:

Return Routability-Care-of Test(CoT) MH Type=4 Message Data: care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1)))

Return Routability Procedure CN MN HA HoTI HoT CoTI CoT Binding Update Im ; Init messgae Tm ; Test message Tbu ; Binding Update

Return Routability Procedure(con.t) Mobile nodeHome agent Correspondent node Hmoe Test(HoT) Care-of Test(CoT) Home Test Init(HoTI) Care-of Test Init(CoTI)

Home Test Init&Care-of Test Init Home Test Init *Source Address = home address * Destination Address = correspondent * Parameters: + home init cookie Care-of Test Init *Source Address = care-of address * Destination Address = correspondent * Parameters: + care-of init cookie

Home Test & Care-of Test Home Test * Source Address = correspondent * Destination Address = home address * Parameters: + home init cookie + home keygen token + home nonce index home keygen token := First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0))) Care-of Test * Source Address = correspondent * Destination Address = care-of address * Parameters: + care-of init cookie + care-of keygen token + care-of nonce index care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1)))

Basic Key Exchange Procedure HDR,SA MN CN HDR, KE,Ni HDR*,IDii,HASH_I message(1) message(2) message(3) message(4) message(5) message(6) HDR,SA HDR, KE,Nr HDR*,IDii,HASH_R Msg1; message(1) Test Init message Test message Binding update Rr(1) Rr(2)

Mobile IPv4 vs IPv6

Mobile IP 與 Mobile IPv6 的比較 Mobile IPv6 取消了 Mobile IP 中， Foreign Agent 存在的必要性，將功能融入路由器中。 由於 IPv6 位址豐富，與點對點安全 (End to End Security) 的重要性，因此取消 Foreign Agent CoA 的設計，僅支援 Colocated CoA 。 簡化 Mobile IP 信息。 路由最佳化與平緩換手 (Smooth Handover) 為必 要支援項目。 IPv6 封包增加了 Mobility Header 選項 。

Mobile IPv4 vs IPv6 詳細比較表 Compared ItemsMobile IPv4Mobile IPv6 Foreign AgentYESNO Care-of addressFA or CCoACCoA only Obtaining Care-of addressBy FA or DHCPv4IPv6 stateless and stateful mechanisms Route OptimizationOptionMandatory Packet tunnel during route optimization Require packet tunneling between MN and CN Forward packets with no tunneling HA involves route optimization YESNO MIP messages formatICMP and UDP packetsIP headers and ICMP packets MIP messagesReg. Req, Bing Update, …Reduced and allow piggybacked in header Smooth hand-overOptionMandatory Reverse tunnelingSolve ingress filteringNo ingress filtering problem

IPv6 Network in Taiwan

IPv6 address ready backbone Commercial  TWIX  CHTTL  6REN  TTN  ASNet -> Japan NSPIXP-6  TANet  Hinet 6BONE Testing  NBEN -> (CHTTL) -> 6BONE

Cooperative Teams Taiwan NICI IPv6 Steering Committee R&D Teams NTHU NDHU NCTU NTUNCKU NKNU CCU NTUSTCHTTL

NBEN Backbone

IPv6 backbone of NBEN Now

TWAREN Project (December 2003)

Objectives Production Network  Provide fundamental connection around academic network Optical Network  Provide layer one interconnection Research Network  Provide advance services (e.g. IPv6, MPLS, Multicast, etc.), research testbed, and pilot projects

NTHU NCTU NCU NTU NCHU NDHU CCU NCKU NSYSU NCTU TAIPEI ASCC HSINCHU TAICHUNG TAINAN PRODUCTION NETWORK

NTHU NCTU NCU NTU NCHU NDHU CCU NCKU NSYSU NCTU TAIPEI ASCC HSINCHU TAICHUNG TAINAN OPTICAL NETWORK

NTHU NCTU NCU NTU NCHU NDHU CCU NCKU NSYSU NCTU TAIPEI ASCC HSINCHU TAICHUNG TAINAN RESEARCH NETWORK

6NDHU

Concepts 壤外：  利用 Native IPv6 connect 透過 NBEN 與 上面單位交換  利用 Tunnel IPv6 connect 透過 TANet 連 接其他單位 安內：  建立全校性 IPv6 網路環境

6NDHU

Stage 1 NCHC Juniper M5 FE Native IPv6 GbE

6NDHU NCHC Juniper M5 Native IPv6 GB Ethernet Stage 2 IPv6 Router FE

6NDHU NCHC Juniper M5 Native IPv6 GB Ethernet Internet v6 Network s Internet v6 Network s Tunnel IPv6 FE Stage3 IPv6 Router Hinet v6 Network Hinet v6 Network Native IPv6 Frame Relay FE

6NDHU NCHC Juniper M5 Native IPv6 GB Ethernet Internet v6 Network s Internet v6 Network s Tunnel IPv6 FE IPv6 Router Hinet v6 Network Hinet v6 Network Native IPv6 Frame Relay Stage 4 FE

Internet IPv6 Site Internet IPv6 Site NDHU IPv6 Peering Outside Hinet AS3462 3FFE:101::/ :238::/35Hinet AS3462 3FFE:101::/ :238::/35 CHTTL AS FFE:3600::/24CHTTL AS FFE:3600::/24 ASNet AS9264 3FFE:3600:18::/ :288:3B0::/44 3FFE:4001::/32ASNet AS9264 3FFE:3600:18::/ :288:3B0::/44 3FFE:4001::/32 MOECC AS :288::/35MOECC AS :288::/35 NDHUGigaPoP AS FFE:3600:0001::/ :288:0380::/44 CCUCCU NCHC AS9681 3FFE:3600:2000:800::/54 3FFE:3600:1B::/48 NTHUNTHU 6BONE NBEN (Native IPv6)TANet (Tunnel IPv6) RIPng BGP RIPng

Current Researches

“Optimized Smooth Handoff in Mobility IP” by C. E. Perkins In this research, the authors propose further strategies that are compatible with route optimization and a security model for Mobile IPv4. First, foreign agent buffer packets are made for a mobile node and sent to its' new location when it leaves. Second, hierarchical foreign agent management reduces the administrative overhead of frequent local handoffs using an extension of the Mobile IP registration process. The security can be maintained. They also use buffering with duplicate packet elimination techniques to minimize the number of lost packets in the location updates. In addition, hierarchical Foreign Agent management is used to reduce the overhead from frequent handoffs.

“Low-Latency Handoff for Cellular Data Networks” by Sirnivasan Seshan in UC Berkeley In this research, various methods were examined to allow mobile users to roam without interruption. The handoff protocol that they presented achieved latencies between 8 and 15 ms with no data loss in the common case when handoffs were between base stations that are topologically close to one another. The authors adopted multicasting for fast route updates and intelligent buffering at the base stations to achieve this performance.

“Fast and Scalable Wireless Handoffs in support of Mobile Internet Audio” by Ramon Caceres at UC Berkeley (1998) This research made two main points. First, it argued that a hierarchical mobility management scheme is necessary for latency and scalability reasons in a world of ubiquitous portable devices that communicate over a large wireless network with the Internet. Second, it demonstrated that a simple handoff mechanism at the lowest level of the hierarchy can be made fast and reliable enough to support the stringent demands of interactive audio applications.

“Handoff Enhancement in Mobile IP” at The University of British Columbia, Canada Woo and Leung considered buffering and also proposed a special extension to Mobile IP and the Internet Mobile Host Protocol (IMHP). They proposed a handoff enhanced extension to the route optimized scheme which delivers optimal performance at all handoff rates. The basic idea is to store the incoming packets at the previous FA for a mobile node undergoing a handoff until a new care- of address is authenticated, after which the packets are forwarded to the new FA. Their handoff enhanced scheme minimizes the loss of packets during handoffs.

“Distributing Mobility Agent Hierarchically”, Helsinki University of Technology They presented a distribution of the mobility agent functionalities for foreign agents. The mobile bindings are cached inside the access network and the system protects their use with a session key protocol. This enables secure localized location updates with efficient signaling. When signal-based handoffs are used in wireless environments, the system presented can provide the handoff speeds needed for glitchless multimedia streaming.

“An IPv6-based Location Management Scheme” at The University of British Columbia, Canada This paper introduced a scheme to address that issue by manipulating the inherent client server interaction, which exists in most applications to provide the correspondent node with the current most node binding. They proposed a solution “Enhanced Mobile IPv6” with Redirection Forwarding (EMIPv6-RF). They proposed a mathematical simulation model. This publication has shown that it is possible to reduce mobility management signaling overhead while at the same time achieving satisfactory results in terms of packet routing efficiency to a mobile node.

“IPv6 Flow Handoff In Ad Hoc Wireless Networks Using Mobility Prediction” by UCLA The special differentiation between this research project and others is that it applies to an Ad Hoc wireless network. They proposed a “Flow Oriented Routing Protocol” (FORP) for routing real-time IPv6 flows in a highly mobile ad hoc flow. A new concept, “Multi-hop Handoff”, was introduced to anticipate topological changes and perform rerouting, thus limiting the disruption of a flow due to the changing topology.

“Mobility and QoS support for IPv6-based Real-time Wireless Internet Traffic” by Alcatel, U.S.A The Main issues that must be taken into account for providing smooth real-time RSVP-base services and exploiting the features of IPv6 for mobile nodes were discussed in this paper. A Care-Taker (CT) agent is introduced at the point where the communication takes place on the wireless medium rather than on the stationary-wired medium (mobile interface). The CT plays a crucial role and is intended to reduce the signaling messages that must be transmitted from MN. The proposed scheme intelligently reduces the volume of the signaling messages transmitted by the wireless mobile node leading to a reduction in power consumption.

“IPv6 Mobility Support for “Micro-Cell” networks” by Eid, Nadim at Columbia University, New York The preliminary goal in this project is to investigate the signaling loads and packet delays under different network topologies and mobility characteristics. They attempted to design and implement a micro- cell mobile IP scheme without modifying or extending the existing support provided by IPv6. They addressed two main issues for efficient mobility in a micro-cell environment. One is reduction of the rate of binding updates for the mobile node. The second issue is a dynamic routing scheme that decreases routing latencies and resource consumption. To solve these two problems, they provided two approaches. The first is to solely rely on the functionality of the mobile IPv6 and the second involves implementing new mechanisms inside the micro-cell network in question.

“A Hierarchical Mobility Management Scheme for IPv6” by INRIA In this research, a hierarchical mobility management architecture for IPv6 was presented. They felt that 69% of a user’s mobility is local and a hierarchical scheme that separates micro-mobility from macro- mobility is preferable. In their proposition, local handoffs are managed locally and transparently to a mobile node’s correspondent nodes. This reduces the signaling bandwidth on 69% to 100% by hiding the local mobility while still providing optimal routing and fast transition performance.

“Cellular IP” by Center for Telecom. Columbia University, New York Cellular IP, a new lightweight and robust protocol that is optimized to support local mobility but efficiently interwork with Mobile IP to provide wide area mobility support. They argued that while Mobile IP can efficiently support wide area mobility in the global Internet backbone, local mobility imposes special requirements not taken into account in the design and deployment of Mobile IP. They identified a set of key requirements, namely easy global migration, cheap passive connectivity, flexible handoff support, efficient location management and simple memoryless mobile nodes as motivating factors in their design. Cellular IP maintains a distributed cache for location management and routing purposes. Distributed paging cache coarsely maintains the position of “idle” mobile nodes in a service area.

“Mechanisms and Hierarchical Topology for Fast Handover in Wireless IP Networks” by Stephane, A. et al. This paper propose two mechanisms to handle micromobility and inter-subdomain mobility in a hierarchical topology network. The author evaluated the performance of their proposed protocols and Mobile IP. When mobile device handovers occur within the same domain, called micro mobility, the base station retransmits packets buffered in the old BS to the new BS and forwards them to the mobile device. If inter- subdomain mobility occurs after the mobile device moves into the edge-subdomain, another proposed mechanism would enable multicasting to multicast packets to the two adjacent domains. These two components, multicasting and buffering, are used to minimize service disruption during mobile IP handoffs.

“IDMP-based Fast Handoffs and Paging In IP-Based Cellular Networks” by Misra, A. et al. The Intra-Domain Mobility Management Protocol (IDMP) uses a two-level hierarchy to manage node mobility in future IP-based cellular networks. It is designed to eliminate the Intra-Domain location update delay and the mobility signaling traffic. The Mobility Agent (MA) is similar to the gateway foreign agent (GFA) introduced in the Mobile IP Regional Registration. It provides the MN a stable global care of address and provides the MN a domain wide point for packet redirection. The Subnet Agent (SA) is similar to the foreign agent (FA) in Mobile IP. It provides subnet-specific mobility services. The MN obtains two concurrent care of addresses, LCoA and GCoA. One has local scope and the other has domain-level granularity.

“NeighborCasting: A Fast Handoff Mechanism in Wireless IP Using Neighboring Foreign Agent Information ” by Eunsoo Shim et al. The author in proposed a NeighborCasting mechanism for fast handoff. The NeighborCasting mechanism uses a wired bandwidth between foreign agents to cast information about the neighboring foreign agent to the possible new foreign agent when the mobile node initiates the link layer handoff procedure. This minimizes the handoff latency. This policy executes the layer two and layer three handoff simultaneously to shorten the handoff latency.

“An efficient handoff method to support real-time services in a mobile IP environment ” by Dong-yun Shin et al. This network is composed of several clusters. Each cluster includes a number of foreign agents (FA). One cluster is managed by a Cluster Agent (CA) located in the parent node of the network tree. Two kinds of handoffs are classified, the Local-Handoff (LH), which occurs in a cluster and the General- Handoff (GH), which occurs between clusters. If a handoff occurs within a cluster, the Mobile Host ’ s (MH) registration need not update the MA ’ s cache. Handoff in a cluster can thus shorten the registration path. When a handoff occurs between clusters, an Overlap Agent (OA), located midway between clusters is needed. The OA registers the MH to the neighboring CA before handoff occurs in this OA and pre-contacts the Real time Services path..

“IPv6 flow handoff in ad hoc wireless networks using mobility prediction ” by William Su et al. This research was performed in an ad hoc environment. In an ad hoc network, mobile nodes act as moving routers and the network topology is constantly changing due to node mobility. This research proposes a new protocol, the Flow Oriented Routing Protocol (FORP), for routing real time flows in highly mobile ad hoc wireless networks.

“MADF: a novel approach to add an ad-hoc overlay on a fixed cellular infrastructure ” by Wu, X. et al. The author proposed an architecture called mobile- assisted data forwarding (MADF). In this system, they added an ad-hoc overlay to the fixed cellular infrastructure and used special channels, forwarding channels, to connect users in a hot, and its surrounding cold cells, without going through the hot cell ’ s base station. Data may hop through more than one forwarding agent before a base station receives it. Under a certain delay requirement, the throughput in one cell can be improved.

“Integrated cellular and ad hoc relaying systems: iCAR ” by Hongyi Wu et al. The key device in this architecture is the Ad-hoc relay stations (ARS). A number of Ad-hoc Relay stations are placed at strategic locations. In this architecture, ARS are placed by the system before the system initiation. This system does not needs to implement an ARS discovery algorithm. The ARS is just like an active router. Depending on the ARS system, the traffic load balance between cells is maintained by relaying traffic from on cell to another cell.

“Evaluation of mobile ad-hoc network techniques in a cellular network ” by Wijting, C. S. et al. This study evaluated the performance of some routing protocols, developed for Mobile Ad-hoc Network networks (MANET), i.e., AODV, DSR, DSDV and the Temporal-Ordered Routing algorithm. A MANET is an autonomous system, shown in Figure 18, that has gateways to a fixed network. To enhance the capacity, the author proposes a combination of cellular and ad-hoc networks. The authors discussed the applications for the above MANET protocols and announced that DSR is the best ad-hoc routing protocol when integrating cellular and ad-hoc networks.

“Dynamic Adaptive Routing for Heterogeneous Wireless Network ” by Yi-Zhan Huang et al. The HWN integrates a cellular network with an ad hoc network to enlarge the communications scope for the ad hoc network and improve the throughput for the cellular network. They also proposed a dynamic adaptive routing protocol (DARP) to fit a Heterogeneous Wireless Network.

“Multihop wireless IEEE LANs: a prototype implementation ” by Ying-Dar Lin et al. The multihop wireless network is composed of the traditional single-hop cellular network and an ad-hoc network. This method reduces the number of required base stations and improves the throughput performance. The major component in this architecture is the bridging protocol, BMBP (Base-driven Multilhop Bridging Protocol). The access points and mobile stations use the BMBP to enable multihop routing and roaming.

“An Architecture and Communication Protocol for IPv6 Packet-Based Picocellular Networks” by Han-Chieh Chao et al. Journal on Special Topics in Mobile Networking and Applications, Vol. 8, No. 6, pp , December The top of this hierarchy is rooted at the edge of the access network and defined by the care-of address registered with the home agent. Upon receiving a packet, the “foreign agent” at the top of the hierarchy interacts with a local database to determine which lower level foreign agent is located in the access network in order to forward the packet. 2.It eliminated the buffer in CMIv6 so that the delay time for re-forwarding packets to the current location is smaller. The base station in our design is merely a bridge or switch as defined in IEEE It is not a proprietary base station. 3. An IP multicasting technique is used to support fast handoff. CMIv6 does not rely entirely on multicasting. Even if this function is removed, FHA can still work well.

“A Micro Mobility Mechanism for Smooth Handoffs in an Integrated Ad-Hoc and CellularIPv6 Network under High Speed Movement ” by H. C. Chao et al. to appear in the IEEE Transactions on Vehicular Technology, November The Neighbor Assisted Agent (NAA) is a general mobile node that is located within a neighboring cell that the moving mobile node is ready to move into. Every mobile node in the adjacent cell has a chance to be a NAA only if the candidate mobile node conforms to certain conditions. After the mobile node (MN1) moves into the neighboring cell, the MN1 must notify the CN with a packet containing authentication, or the MN1 must register with the correspondent node (CN) by itself if the confirmation packet coming from the NAA is lost.

RFC’s [RFC 1719] A Direction for IPng.RFC 1719 [RFC 1726] Technical Criteria for Choosing IP The Next Generation (IPng).RFC 1726 [RFC 1752] The Recommendation for the IP Next Generation Protocol.RFC 1752 [RFC 1809] Using the Flow Label Field in IPv6.RFC 1809 [RFC 1881] IPv6 Address Allocation Management.RFC 1881 [RFC 1887] An Architecture for IPv6 Unicast Address Allocation.RFC 1887 [RFC 1888] OSI NSAPs and IPv6.RFC 1888 [RFC 1981] Path MTU Discovery for IP version 6.RFC 1981 [RFC 2126] ISO Transport Service on top of TCP (ITOT).RFC 2126 [RFC 2170] Application REQuested IP over ATM (AREQUIPA).RFC 2170 [RFC 2185] Routing Aspects Of IPv6 Transition.RFC 2185 [RFC 2292] Advanced Sockets API for IPv6.RFC 2292 [RFC 2373] IP Version 6 Addressing Architecture.RFC 2373 [RFC 2374] An IPv6 Aggregatable Global Unicast Address Format.RFC 2374 [RFC 2375] IPv6 Multicast Address Assignments.RFC 2375 [RFC 2401] Security Architecture for the Internet Protocol.RFC 2401 [RFC 2450] Proposed TLA and NLA Assignment Rules.RFC 2450 [RFC 2452] IP Version 6 Management Information Base for the Transmission Control Protocol.RFC 2452

RFC’s [RFC 2454] IP Version 6 Management Information Base for the User Datagram Protocol.RFC 2454 [RFC 2460] Internet Protocol, Version 6 (IPv6) Specification.RFC 2460 [RFC 2461] Neighbor Discovery for IP Version 6 (IPv6).RFC 2461 [RFC 2462] IPv6 Stateless Address Autoconfiguration.RFC 2462 [RFC 2464] Transmission of IPv6 Packets over Ethernet Networks.RFC 2464 [RFC 2465] Management Information Base for IP Version 6: Textual Conventions and General Group.RFC 2465 [RFC 2467] Transmission of IPv6 Packets over FDDI Networks.RFC 2467 [RFC 2470] Transmission of IPv6 Packets over Token Ring Networks.RFC 2470 [RFC 2471] IPv6 Testing Address Allocation.RFC 2471 [RFC 2472] IP Version 6 over PPP.RFC 2472 [RFC 2473] Generic Packet Tunneling in IPv6 Specification.RFC 2473 [RFC 2474] Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.RFC 2474 [RFC 2475] An Architecture for Differentiated Services.RFC 2475 [RFC 2491] IPv6 over Non- Broadcast Multiple Access (NBMA) networks.RFC 2491

RFC’s [RFC 2492] IPv6 over ATM Networks.RFC 2492 [RFC 2497] Transmission of IPv6 Packets over ARCnet Networks.RFC 2497 [RFC 2507] IP Header Compression.RFC 2507 [RFC 2508] Compressing IP/UDP/RTP Headers for Low- Speed Serial Links.RFC 2508 [RFC 2526] Reserved IPv6 Subnet Anycast Addresses.RFC 2526 [RFC 2529] Transmission of IPv6 over IPv4 Domains without Explicit Tunnels.RFC 2529 [RFC 2553] Basic Socket Interface Extensions for IPv6.RFC 2553 [RFC 2590] Transmission of IPv6 Packets over Frame Relay Networks Specification.RFC 2590 [RFC 2675] IPv6 Jumbograms.RFC 2675 [RFC 2711] IPv6 Router Alert Option.RFC 2711 [RFC 2732] Format for Literal IPv6 Addresses in URL's. [RFC 2732 [RFC 2765] Stateless IP/ICMP Translation Algorithm (SIIT).RFC 2765 [RFC 2766] Network Address Translation - Protocol Translation (NAT-PT).RFC 2766 [RFC 2767] Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS).RFC 2767 [RFC 2780] IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers.RFC 2780

RFC’s [RFC 2874] DNS Extensions to Support IPv6 Address Aggregation and Renumbering.RFC 2874 [RFC 2893] Transition Mechanisms for IPv6 Hosts and Routers.RFC 2893 [RFC 2928] Initial IPv6 Sub-TLA ID Assignments.RFC 2928 [RFC 3041] Privacy Extensions for Stateless Address Autoconfiguration in IPv6RFC 3041 [RFC 3053] IPv6 Tunnel Broker.RFC 3053 [RFC 3056] Connection of IPv6 Domains via IPv4 Clouds.RFC 3056 [RFC 3111] Service Location Protocol Modifications for IPv6.RFC 3111 [RFC 3142] An IPv6-to-IPv4 Transport Relay Translator.RFC 3142 [RFC 3146] Transmission of IPv6 Packets over IEEE 1394 Networks.RFC 3146 [RFC 3178] IPv6 Multihoming Support at Site Exit Routers.RFC 3178

CALL FOR PAPERS IEEE Journal on Selected Areas in Communications WIRELESS OVERLAY NETWORKS BASED ON MOBILE IPv6 Mobile IPv6 based overlay communication network architecture Mobile IPv6 based management for wireless overlay networks IPv6 based mobile computing applications on overlay networks Mobile IPv6 based overlay networks performance modeling Design and analysis for mobile IPv6 based overlay networks switching algorithms Fault tolerance for mobile IPv6 based mobile computing on overlay networks Distributed databases for mobile IPv6 based overlay networks Ad hoc wireless networks using IPv6 mobility in overly network environments Mobile IPv6 based personal or cellular communications services on overlay networks Secure mobile IPv6 based wireless communications on overlay networks IPv6 based mobile QoS protocol in overlay network environments Alternate security mechanisms, QoS traffic analysis and network loading, interactions between ad hoc networking and return routability

Manuscript Submission:SEPTEMBER 1, 2004 Acceptance Notification:March 1, 2005 Final Manuscript Due:June 1, 2005 Publication:4th Quarter 2005 Han-Chieh Chao Corresponding Guest Editor Dept of Electrical Engineering National Dong Hwa University No. 1, University Rd. Sec 2 Jyh-Shyue Tsuen, Show-Feng Shiang Hualien, Taiwan, R.O. C All contributions must be sent by as.PDF or.PS files to one of the five guest editors listed below, along with a copy to the Corresponding Guest Editor. Authors should follow the IEEE J- SAC manuscript format described in the Information for Authors. There will be one round of reviews and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies:Information for Authors

Finally The longer the upgrade is postponed, the costlier it will be and the more complicated the transition will be ! (compare to Y2K !) Yv6