ipv6 tutorial: mobility 主講人 : 國立東華大學電機系趙涵捷教授 online why ipv6...

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 Ma

sk) 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 1883-1887 綜合 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 Header20 Octets+Options : 13 fields, include 3 flag bits

0 bits 84 16 31

Ver IHL Total Length

Identifier Flags Fragment Offset

32 bit Source Address

32 bit Destination Address

24

Service Type

Options and Padding

Time to Live Header ChecksumProtocol

RemovedChanged

Header 比較 --IPv6 Header40 Octets, 8 fields

0 31

Version Class Flow Label

Payload Length Next Header Hop Limit

128 bit Source Address

128 bit Destination Address

4 12 2416

Differences between IPv4 and IPv6

Feature IPv4 IPv6

Source and destination address

32 bits 128 bits

IPSec Optional required

Payload identification for QoS in the header

No identification Using Flow label field

Fragmentation Both router and the sending hosts

Only supported at the sending hosts

Checksum of header included Not included

Resolve address to a link layer address

broadcast ARP request

Multicast Neighbor Solicitation message

Differences between IPv4 and IPv6(Cont.)

Feature IPv4 IPv6

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

Broadcast Link-local scope all-nodes multicast

address

Payload identification for QoS in the header

No identification Using Flow label field

Configure address Manually or DHCP autoconfiguration

Map hosts name to addresses

A AAAA

Manage local subnet group membership

(IGMP) Multicast Listener Discovery (MLD)

IPv6 定址架構

128 bits long. Fixed size 2128 = 3.4×1038 addresses => 6.65×1023

addresses per m2 of earth surface If assigned at the rate of 106/s, it would

take 20 years Allows multiple interfaces per host Allows multiple addresses per interface

IPv6 -- 定址模式 (一 )

Link-LocalSite-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 Next LevelNext Level

Site 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

/128/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 nu

mber 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:211.72.211.1 or ::211.

72.211.1 IPv4 位址表示方式

211.72.211.1

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 範圍 APNIC 2001:0200::/23 ARIN 2001:0400::/23 RIPE NCC 2001:0600::/23

6Bone 3FFE::/16 6to4 tunnels 2002::/16 APNIC 之 IPv6 申請

http://www.apnic.net/apnic-bin/ipv6-subtla-request.pl

IPv6 -- 定址模式 ( 七 ) Address Type Prefixes

Address type Binary prefix

IPv4-compatible 0000...0 (96 zero bits)

global unicast 001

link-local unicast 1111 1110 10

site-local unicast1111 1110 11

multicast 1111 1111

all other prefixes reserved (approx. 7/8ths of total) anycast addresses allocated from unicast prefixes

Global Unicast Addresses

sitetopology(16 bits)

interfaceidentifier(64 bits)

publictopology(45 bits)

interface IDSLA*NLA*TLA001

TLA = Top-Level AggregatorNLA* = 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 的 0.0.0.0 意義相同

loopback address 0:0:0:0:0:0:0:1 與 IPv4 的 127.0.0.1 意義相同

Link-Local 及 Site-Local 位址

Link-local addresses for use during auto-configuration and when no routers are present:

FE80Site-local addresses for independence from changes of TLA / NLA*:

FEC0

1111111010 0 interface ID

1111111011 0 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 expand

ed 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

定址空間Allocation Space Prefix (binary) Fraction of

Address Space Reserved 0000 0000 1/256 Unassigned 0000 0001 1/256 Reserved for NSAP Allocation 0000 001 1/128 Reserved for IPX Allocation 0000 010 1/128 Unassigned 0000 011 1/128 Unassigned 0000 1 1/32 Unassigned 0001 1/16 Unassigned 001 1/8 Provider -Based Unicast Address 010 1/8 Unassigned 011 1/8 Reserved for Geographic -Based Unicast Addresses

100 1/8

Unassigned 101 1/8 Unassigned 110 1/8 Unassigned 1110 1/16 Unassigned 1111 0 1/32 Unassigned 1111 10 1/64 Unassigned 1111 110 1/128 Unassigned 1111 1110 0 1/512 Link Local Use Addresses 1111 1110 10 1/1024 Site Local Use Addresses 1111 1110 11 1/1024 Multicast Addresses 1111 1111 1/256

Routing in IPv6

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

NGTRANSNGTRANS

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/IPv6IPv4/IPv6

DualStack

DualStack

IPv6IPv6

IPv4IPv4

DualStack

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

IPv4IPv4

RFC 1933

RFC 3056

RFC 3053

IPv4IPv4IPv6IPv6 IPv6IPv6

IPv6 IPv66over4

6to4

IPv4IPv4IPv6IPv6

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


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


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

IPv6IPv6 IPv4IPv4NATPT

SIIT

IPv4 Apps

BITS

IPv6 Stack

IPv4 Apps

BITS

IPv6 Stack

IPv6Host IPv6 IPv4

IPv4Host

Socks-GatewayTCPUDP-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

SIIT

Pool of IPv4 addresses

IPv4 network

IPv6 host IPv4 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(IPv4IPv6)

V4 address pool

NAT-PT

DNS-ALG

IPv6 host

IPv4Host

IPv6 DNS

IPv4 DNS

Address allocation and create address mapping

A6 A

140.114.78.58ipv4.cs.nthu.edu.tw

3FFE:3600:B::2ipv6.cs.nthu.edu.tw

3FFE:3600:B::3ipv6DNS.cs.nthu.edu.tw

140.114.78.1ipv4DNS.cs.nthu.edu.tw

(1)

(2)(3)

(7) (8)

(5)

(4) (6)A6 A

140.114.78.51140.114.78.52140.114.78.53140.114.78.54140.114.78.55

:::

IPv4 address pool 3FFE:3600:B::2 <-> 140.114.78.51

::::

IPv6 <-> IPv4 Address Mapping Table IPv4 Host think it’s

communicating with 140.114.78.51

IPv6 Host think it’s communicating with 3FFE:3600:b::140.114.78.58

Final Result

NAT-PT operations with DNS-ALG(IPv6IPv4)

V4 address pool

NAT-PT

DNS-ALG

IPv6 host

IPv4Host

IPv6 DNS

IPv4 DNS

Address allocation(get IPv6 prefix)

A6 A

140.114.78.58ipv4.cs.nthu.edu.tw

3FFE:3600:B::2ipv6.cs.nthu.edu.tw

3FFE:3600:B::3ipv6DNS.cs.nthu.edu.tw

140.114.78.1ipv4DNS.cs.nthu.edu.tw

(1)

(2) (3)

(8)

(7) (9)

(5)

(4)(6) A6 A

140.114.78.51140.114.78.52140.114.78.53140.114.78.54140.114.78.55

:::

3FFE:3600:B::2 <-> 140.114.78.51::::

IPv6 <-> IPv4 Address Mapping Table IPv6 Host think it’s

communicating with 3FFE:3600:b::140.114.78.58

IPv4 Host think it’s communicating with 140.114.78.51

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-ALGDNS-ALG

有無 DNS-ALG 之比較

　這是假設從 v6 網路到 v4 網路的狀況，其實 v4 到 v6 是一樣的狀況，只是 IPv4 和 IPv6 角色反過來。

有有 DNS-ALGDNS-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 V4 node 產生產生 FTP session FTP session 的情況的情況

FTP-ALG Support

第一種方法： FTP-ALG 不改變 EPRT 和 EPSV ，而只是轉換 <net-prt><net-addr><tcp-port> 成 NAT-PT 或 NAPT-PT 所指定的 IPv4 相對應資訊。但在這種方法下，IPv4 端的 FTP application 必須 upgrade to support EPRT and EPSV 。

第二種方法： FTP-ALG 把 EPRT 和 EPSV 分別轉換成 PORT 和 PASV 。同時也對 <net-prt><net-addr><tcp-port> 這幾個參數做轉換。好處是 IPv4 端的 FTP 不需upgrade 。壞處是， FTP-ALG 無法對 EPSV<space>ALL 這個指令做對應的轉換，這個情況下， IPv4 端的 FTP app 會傳回 error 。

由由 V6 node V6 node 產生產生 FTP session 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 之 C

oA 透過 Tunneling 將封包包裝後再送至 FA ， FA收到後，解通道封包後，將原封包轉送至MN 。

6. MN送至外部之封包可以直接遞送﹔若拜訪網路有做封包過濾(Packet Filtering) ，則可以透過 FA轉送至 HA再行傳送到 CN 。

7. MN返回原網路，傳送解除註冊動作，封包路由回原 MN 。

Mobile IPv4 : Concepts

HA

Foreign NetworkInternet

CN

Home Network

FA

Agent Advertisement

Mobile Node

Agent Advertisement

HA


CN

Home Network

FA

Mobile Node

Registration Request

Registration Reply

Reply Reg-Req

Relay Reg-Req



HA


CN

Home Network

FA

Mobile Node

Registration Request

Registration Reply


HA


CN

Home Network

FA

Mobile Node


HA


CN

Home Network

FA

Mobile Node

Tunneling


HA


CN

Home Network

FA

Mobile Node

※ MN 送至外部之封包可以直接遞送


HA


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 之下，會收到新網域中 Rou

ter 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 ，可以直接溝通。


HA

Home Network

Foreign Network

Internet

CN

Mobile Node

IP Header PayLoad

S： CN’s IP

D：MN’s Home Address

IP Header PayLoad

S：MN’s Home Address

D： CN’s IP


HAForeign Network

Internet

CN

Home Network

Binding Update

Binding Ack

Mobile Node

PayLoadIP Header Mobilty Header

MH=5


MH=6S ： Home Agent’s address

D ： MN’s CoA

S ： MN’s CoA

D ： Home Agent’s address


HAForeign Network

Internet

CN

Home Network

Mobile Node

IP Header PayLoad

S： CN’s IP

D：MN’s Home Address

Ｓ： :Home Agent’s address

D ： MN’s COA

New IP Header Old IP Header PayLoad

Tunneled packets

Ｓ： :CN’s IP

D ： MN’s Home Address

HA

Internet

CN

Home Network

Mobile Node


Binding Update

Binding Ack


MH=5


MH=6S ： CN’s IP

D ： MN’s CoA

S ： MN’s CoA

D ： CN’s IP

HA

Internet

CN

Home Network

Mobile Node


S：MN’s COA

D： CN’s IP

PayLoadIP Header HA DestOpt

(includes MN’s Home Address)

S： CN’s IP

D：MN’s COA

PayLoadIP Header Routing 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


MH=1

Parameters:

+home init cookie

Home Test Init

Care-of Test Init


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



MH=3

Parameters:

+Home Init Cookie

+Home Keygen Token

+Home Nonce Index

Home Test

Care-of Test


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


Binding Update protected

by the shared key


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=3Message 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

HoTIHoT

CoTI

CoT

Binding Update

Im ; Init messgae

Tm ; Test messageTbu ; Binding Update

Return Routability Procedure(con.t)

Mobile node Home 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 messageBinding update

Rr(1)Rr(2)

Mobile IPv4 vs IPv6

Mobile IP 與 Mobile IPv6 的比較 Mobile IPv6取消了 Mobile IP中， Foreign Ag

ent 存在的必要性，將功能融入路由器中。由於 IPv6位址豐富，與點對點安全 (End to End Security) 的重要性，因此取消 Foreign Agent CoA的設計，僅支援 Colocated CoA。

簡化 Mobile IP信息。路由最佳化與平緩換手 (Smooth Handover) 為必

要支援項目。 IPv6 封包增加了 Mobility Header 選項。　　

Mobile IPv4 vs IPv6 詳細比較表Compared Items Mobile IPv4 Mobile IPv6

Foreign Agent YES NO

Care-of address FA or CCoA CCoA only

Obtaining Care-of address By FA or DHCPv4 IPv6 stateless and stateful mechanisms

Route Optimization Option Mandatory

Packet tunnel during route optimization

Require packet tunneling between MN and CN

Forward packets with no tunneling

HA involves route optimization

YES NO

MIP messages format ICMP and UDP packets IP headers and ICMP packets

MIP messages Reg. Req, Bing Update, … Reduced and allow piggybacked in header

Smooth hand-over Option Mandatory

Reverse tunneling Solve ingress filtering No 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 Taiwan NICI IPv6 Steering CommitteeNICI IPv6 Steering Committee

R&D TeamsR&D Teams

NTHUNTHUNDHUNDHU NCTUNCTU

NTUNTUNCKUNCKU

NKNUNKNU CCUCCU

NTUSTNTUSTCHTTLCHTTL

NBEN Backbone

IPv6 backbone of NBEN Now

TWAREN Project (December 2003)

Objectives

Production Network Provide fundamental connection around academi

c 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

NSYSUNCTU

TAIPEIASCC

HSINCHU

TAICHUNG

TAINAN

PRODUCTION NETWORK

NTHU

NCTU

NCU

NTU

NCHU

NDHU

CCU

NCKU

NSYSUNCTU

TAIPEIASCC

HSINCHU

TAICHUNG

TAINAN

OPTICAL NETWORK

NTHU

NCTU

NCU

NTU

NCHU

NDHU

CCU

NCKU

NSYSUNCTU

TAIPEIASCC

HSINCHU

TAICHUNG

TAINAN

RESEARCH NETWORK

Concepts

壤外：利用 Native IPv6 connect 透過 NBEN

與上面單位交換利用 Tunnel IPv6 connect 透過 TANet 連接其他單位

安內：建立全校性 IPv6 網路環境

6NDHUStage 1

NCHC

NCHC

Juniper M5

FE

NativeIPv6GbE

6NDHU

NCHC

NCHC

Juniper M5

NativeIPv6GB

Ethernet

Stage 2IPv6 Router

FE FE FE FE

FE

6NDHU

NCHC

NCHC

Juniper M5

NativeIPv6GB

Ethernet

Internetv6

Networks

Internetv6

Networks

TunnelIPv6

FE FE FE FE

Stage3

IPv6 Router

Hinetv6

Network

Hinetv6

Network

Native IPv6Frame Relay

FE

6NDHU

NCHC

NCHC

Juniper M5

NativeIPv6GB

Ethernet

Internetv6

Networks

Internetv6

Networks

TunnelIPv6

FE FE FE FE

IPv6 Router

Hinetv6

Network

Hinetv6

Network

Native IPv6Frame Relay

Stage 4

FE

Internet

IPv6 Site

Internet

IPv6 Site

NDHU IPv6 Peering Outside

HinetHinetAS3462

3FFE:101::/322001:238::/35

HinetHinetAS3462

3FFE:101::/322001:238::/35

CHTTLCHTTLAS17715

3FFE:3600::/24

CHTTLCHTTLAS17715

3FFE:3600::/24

ASNetASNetAS9264

3FFE:3600:18::/48 2001:288:3B0::/44

3FFE:4001::/32

ASNetASNetAS9264

3FFE:3600:18::/48 2001:288:3B0::/44

3FFE:4001::/32

MOECCMOECCAS1659

2001:288::/35

MOECCMOECCAS1659

2001:288::/35

NDHU NDHU GigaPoPGigaPoP

AS177113FFE:3600:0001::/482001:288:0380::/44

CCUCCUCCUCCU

NCHCNCHCAS9681

3FFE:3600:2000:800::/543FFE:3600:1B::/48

NTHUNTHUNTHUNTHU

6BONE6BONE

NBEN (Native IPv6)

TANet (Tunnel IPv6)

RIPng

BGP

BGP

BGP

BGP

BGP

RIPng

RIPng

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 802.11 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. 663-674, December 2003.

1. 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 IEEE802.11. 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 Vehicul

ar Technology, November 2003.

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 1726] Technical Criteria for

Choosing IP The Next Generation (IPng).

[RFC 1752] The Recommendation for the IP Next Generation Protocol.

[RFC 1809] Using the Flow Label Field in IPv6.

[RFC 1881] IPv6 Address Allocation Management.

[RFC 1887] An Architecture for IPv6 Unicast Address Allocation.

[RFC 1888] OSI NSAPs and IPv6. [RFC 1981] Path MTU Discovery for IP

version 6. [RFC 2126] ISO Transport Service on

top of TCP (ITOT). [RFC 2170] Application REQuested IP

over ATM (AREQUIPA).

[RFC 2185] Routing Aspects Of IPv6 Transition.

[RFC 2292] Advanced Sockets API for IPv6.

[RFC 2373] IP Version 6 Addressing Architecture.

[RFC 2374] An IPv6 Aggregatable Global Unicast Address Format.

[RFC 2375] IPv6 Multicast Address Assignments.

[RFC 2401] Security Architecture for the Internet Protocol.

[RFC 2450] Proposed TLA and NLA Assignment Rules.

[RFC 2452] IP Version 6 Management Information Base for the Transmission Control Protocol.

RFC’s

[RFC 2454] IP Version 6 Management Information Base for the User Datagram Protocol.

[RFC 2460] Internet Protocol, Version 6 (IPv6) Specification.

[RFC 2461] Neighbor Discovery for IP Version 6 (IPv6).

[RFC 2462] IPv6 Stateless Address Autoconfiguration.

[RFC 2464] Transmission of IPv6 Packets over Ethernet Networks.

[RFC 2465] Management Information Base for IP Version 6: Textual Conventions and General Group.

[RFC 2467] Transmission of IPv6 Packets over FDDI Networks.

[RFC 2470] Transmission of IPv6 Packets over Token Ring Networks.

[RFC 2471] IPv6 Testing Address Allocation.

[RFC 2472] IP Version 6 over PPP. [RFC 2473] Generic Packet

Tunneling in IPv6 Specification. [RFC 2474] Definition of the

Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers.

[RFC 2475] An Architecture for Differentiated Services.

[RFC 2491] IPv6 over Non-Broadcast Multiple Access (NBMA) networks.

RFC’s [RFC 2492] IPv6 over ATM Networks. [RFC 2497] Transmission of IPv6

Packets over ARCnet Networks. [RFC 2507] IP Header Compression. [RFC 2508] Compressing

IP/UDP/RTP Headers for Low-Speed Serial Links.

[RFC 2526] Reserved IPv6 Subnet Anycast Addresses.

[RFC 2529] Transmission of IPv6 over IPv4 Domains without Explicit Tunnels.

[RFC 2553] Basic Socket Interface Extensions for IPv6.

[RFC 2590] Transmission of IPv6 Packets over Frame Relay Networks Specification.

[RFC 2675] IPv6 Jumbograms. [RFC 2711] IPv6 Router Alert

Option. [RFC 2732] Format for Literal IPv6

Addresses in URL's. [RFC 2765] Stateless IP/ICMP

Translation Algorithm (SIIT). [RFC 2766] Network Address

Translation - Protocol Translation (NAT-PT).

[RFC 2767] Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS).

[RFC 2780] IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers.

RFC’s

[RFC 2874] DNS Extensions to Support IPv6 Address Aggregation and Renumbering.

[RFC 2893] Transition Mechanisms for IPv6 Hosts and Routers. [RFC 2928] Initial IPv6 Sub-TLA ID Assignments. [RFC 3041] Privacy Extensions for Stateless Address

Autoconfiguration in IPv6 [RFC 3053] IPv6 Tunnel Broker. [RFC 3056] Connection of IPv6 Domains via IPv4 Clouds. [RFC 3111] Service Location Protocol Modifications for IPv6. [RFC 3142] An IPv6-to-IPv4 Transport Relay Translator. [RFC 3146] Transmission of IPv6 Packets over IEEE 1394

Networks. [RFC 3178] IPv6 Multihoming Support at Site Exit Routers.

CALL FOR PAPERSIEEE 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 ChaoCorresponding Guest EditorDept of Electrical EngineeringNational Dong Hwa UniversityNo. 1, University Rd. Sec 2Jyh-Shyue Tsuen, Show-Feng ShiangHualien, Taiwan, R.O. C. [email protected]

http://www.argreenhouse.com/society/J-SAC/Calls/ipv6.html

All contributions must be sent by email 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:

Finally

The longer the upgrade is postponed, the costlier it will be and the more complicated the transition will be !

http://www.ipv6.org.tw http://www.ipv6.ndhu.edu.tw http://v6tb.ndhu.edu.tw http:/6book.ndhu.edu.tw

(compare to Y2K!)

Yv6Yv6

ipv6 tutorial: mobility 主講人 : 國立東華大學電機系趙涵捷教授 online why ipv6...

Documents