alvaro agudelo alexander tucker wael kdouh suresh srinivasan

1

Alvaro Agudelo Alexander TuckerWael KdouhSuresh Srinivasan

2

Content

• IPv4 over Stationary Environments• MIPv4 overview• Micro-mobility• Agent Discovery• Registration• Mobile Node Communication• Issues• Low-latency handoffs• Regional Registration• Dynamic HA Assignments• Security

3

• ARP example

• ICMP example

• Message Flow example

4

IPA: 198.100.1.2

N1: 198.100.x.x

A

R1IP=198.100.1.1

Router (R1)

CN

IPB: 198.100.1.3

B

MACB=00:10:b5:78:5b:6c

MACA=00:0b:23:78:c2:11

Internet

MACR1=00:00:0c:07:ac:18

Host A boots:

ARP example

5

IPA: 198.100.1.2

N1: 198.100.x.x

A

R1IP=198.100.1.1

CN

IPB: 198.100.1.3

B

MACB=00:10:b5:78:5b:6c

MACA=00:0b:23:78:c2:11

ARP broadcastfrom A.

Router (R1)

MACR1=00:00:0c:07:ac:18

Internet

ARP broadcast

( arp –a )

ARP cachesUpdated.

IP MAC

IP MAC

198.100.1.2 00:0b:23:78:c2:11

198.100.1.2 00:0b:23:78:c2:11

6

N1: 198.100.x.x

A

R1IP=198.100.1.1

CN

IPB: 198.100.1.3

B

MACB=00:10:b5:78:5b:6c

ARP cacheentries expire

IPA: 198.100.1.2MACA=00:0b:23:78:c2:11

IP MACRouter (R1)

IP MAC

198.100.1.2 00:0b:23:78:c2:11

198.100.1.2 00:0b:23:78:c2:11

MACR1=00:00:0c:07:ac:18

Internet

ARP example

7

B wants to talk to A,but B does nothave an entry on Its ARP cache forIPA

N1: 198.100.x.x

A

R1IP=198.100.1.1

CN

IPB: 198.100.1.3

B

MACB=00:10:b5:78:5b:6c

IPA: 198.100.1.2MACA=00:0b:23:78:c2:11

IP MACRouter (R1)

IP MAC

MACR1=00:00:0c:07:ac:18

Internet

ARP example

8

N1: 198.100.x.x

A

R1IP=198.100.1.1

CN

IPB: 198.100.1.3

B

MACB=00:10:b5:78:5b:6c

ARP requestfrom Bto (ff:ff:ff:ff:ff:ff)(IPA)

IPA: 198.100.1.2MACA=00:0b:23:78:c2:11

Router (R1)

IP MAC198.100.1.3 00:10:b5:78:5b:6c

MACR1=00:00:0c:07:ac:18

IP MAC

IP MAC

ARP request

Internet

9

ARP reply from Ato MACB

N1: 198.100.x.x

A

R1IP=198.100.1.1

CN

IPB: 198.100.1.3

B

MACB=00:10:b5:78:5b:6c

IPA: 198.100.1.2MACA=00:0b:23:78:c2:11

Router (R1)

IP MAC198.100.1.3 00:10:b5:78:5b:6c

MACR1=00:00:0c:07:ac:18

IP MAC

IP MAC

ARP reply

Internet

198.100.1.2 00:0b:23:78:c2:11

10

ARP request

ARP data

FrameHeader Frame Data

Hardware Type=1 (Ethernet)Protocol Address Type=0x0800 (IPv4 Address)Hardware Address Size=6 (MAC address size)Protocol Address Size=4 (IPv4 address size)Operation: 1 (ARP request)Src MAC address: MACB=00:10:b5:78:5b:6cSrc IP address: IPB: 198.100.1.3Dst MAC address: ff:ff:ff:ff:ff:ffDst IP address: IPA: 198.100.1.2

Dst MAC address: ff:ff:ff:ff:ff:ffSrc MAC address: MACB=00:10:b5:78:5b:6cFrame Type=0x0806 (ARP frame)

11

ARP reply

ARP data


Hardware Type=1 (Ethernet)Protocol Address Type=0x0800 (IPv4 Address)Hardware Address Size=6 (MAC address size)Protocol Address Size=4 (IPv4 address size)Operation: 2 (ARP reply)Src MAC address: MACA=00:0b:23:78:c2:11Src IP address: IPA: 198.100.1.2 Dst MAC address: MACB=00:10:b5:78:5b:6c Dst IP address: IPB: 198.100.1.3

Dst MAC address: MACB=00:10:b5:78:5b:6c Src MAC address: MACA=00:0b:23:78:c2:11Frame Type=0x0806 (ARP frame)

12

Before sendingpackets, A needs a defaultrouter

N1: 198.100.x.x

A

R1IP=198.100.1.1

CN

IPB: 198.100.1.3

BIPA: 198.100.1.2

Router (R1)

ICMP example

Internet

IP NextHOP

13

N1: 198.100.x.x

A

R1IP=198.100.1.1

CN

IPB: 198.100.1.3

BIPA: 198.100.1.2

Router (R1)

ICMP Router Advertisement

Internet

Router 1 sendsperiodicallyICMP RouterAdvertisementsTo all-systems multicast Address ( 224.0.0.1 ) or if not supported,to the limited broadcast address( 255.255.255.255 )

14

IPA: 198.100.1.2

N1: 198.100.x.x

A

R1IP=198.100.1.1

Router (R1)

CN

IPB: 198.100.1.3

B

Routing tablesare updated

IP NextHOP

IP NextHOPx 198.100.1.1

x 198.100.1.1

ICMP example

Internet

15

IPA: 198.100.1.2

N1: 198.100.x.x

A

R1IP=198.100.1.1

Router (R1)

CN

IPB: 198.100.1.3

B

Routing entries expire

IP NextHOP


x 198.100.1.1

ICMP example

Internet

16

IPA: 198.100.1.2

N1: 198.100.x.x

A

R1IP=198.100.1.1

Router (R1)

CN

IPB: 198.100.1.3

B

A needs to send packets but thereis no default router(or A just booted andcannot wait for thenext router advertisement)

IP NextHOP

IP NextHOP

ICMP example

Internet

17

IPA: 198.100.1.2

N1: 198.100.x.x

A

R1IP=198.100.1.1

Router (R1)

CN

IPB: 198.100.1.3

B

ICMP Router Solicitation

Internet

A sends anICMP RouterSolicitationto all-routers multicast address ( 224.0.0.2 ) or if not supported,to the limited broadcast address( 255.255.255.255 )

18

IPA: 198.100.1.2

N1: 198.100.x.x

A

R1IP=198.100.1.1

Router (R1)

CN

IPB: 198.100.1.3

B

ICMP example

InternetR1 reads the packet and sends an ICMP Router Advertisement(Unicast)

Routing tableIn A is updated


19

Router Solicitation

ICMPHeader

ICMP Data

Datagram Header Datagram Data


All Routers group

Dst MAC address: ff:ff:ff:ff:ff:ffSrc MAC address: MACA=00:0b:23:78:c2:11Frame Type=0x0800 (IP frame)

Type=10 (Router Solicitation)Code=0

Version=4 (IPv4)TTL=1Protocol=0x01 (ICMP)Src = IPA: 198.100.1.2Dst = 224.0.0.2

20

Router Advertisement

ICMPHeader

ICMP Data



All Systems group

Dst MAC address: ff:ff:ff:ff:ff:ffSrc MAC address: MACR1=00:00:0c:07:ac:18Frame Type=0x0800 (IP frame)

Type=9 (Router Advertisement)Code=0Number of Addresses=1Lifetime=1800 seconds (30min)Router Address 1 = R1IP: 198.100.1.1Preference Level 1 = p1

Version=4 (IPv4)TTL=1Protocol=0x01 (ICMP)Src = R1IP: 198.100.1.1 Dst = 224.0.0.1

21

Router (R1)

Router (R3) Router (R2)

N1: 198.100.x.x

N3: 155.174.x.xN2: 172.16.x.x

Internet

Router (R4)

Src

Dst

Sending datagrams from Src to Dst …

Message Flow example

22

CN

Dst

R3 R2

N3: 155.174.x.xN2: 172.16.x.x

Internet

DstIP: 172.16.2.2

R1

SrcIP: 198.100.1.2

N1: 198.100.x.x

Src

R2IP=172.16.2.1

R4

R3IP=155.174.3.1R4IP=155.174.3.2

R1IP=198.100.1.1

Dst: DstIP: 172.16.2.2 Src: SrcIP : 198.100.1.2


23

CN

Dst

R3 R2

N3: 155.174.x.xN2: 172.16.x.x

Internet

DstIP: 172.16.2.2

R1

SrcIP: 198.100.1.2Dst: DstIP: 172.16.2.2Src: SrcIP : 198.100.1.2

N1: 198.100.x.x

Src

R2IP=172.16.2.1

R4

R3IP=155.174.3.1R4IP=155.174.3.2

R1IP=198.100.1.1


24

CN

Dst

R3 R2

N3: 155.174.x.xN2: 172.16.x.x

Internet

DstIP: 172.16.2.2

N1: 198.100.x.x

R2IP=172.16.2.1

R4

R3IP=155.174.3.1R4IP=155.174.3.2

R1IP=198.100.1.1

Src

R1

SrcIP: 198.100.1.2

Dst: DstIP: 172.16.2.2Src: SrcIP : 198.100.1.2


25

CN

Dst

R3 R2

N3: 155.174.x.xN2: 172.16.x.x

Internet

DstIP: 172.16.2.2

N1: 198.100.x.x

R2IP=172.16.2.1

R4

R3IP=155.174.3.1R4IP=155.174.3.2

R1IP=198.100.1.1

135.157.x.x

Src

R1

SrcIP: 198.100.1.2



26

CN

Dst

R3 R2

N3: 155.174.x.xN2: 172.16.x.x

Internet

DstIP: 172.16.2.2

N1: 198.100.x.x

R2IP=172.16.2.1

R4

R3IP=155.174.3.1R4IP=155.174.3.2

R1IP=198.100.1.1

135.157.x.x

135.209.x.x

Src SrcIP: 198.100.1.2

R1



27

CN

Dst

R3 R2

N3: 155.174.x.xN2: 172.16.x.x

Internet

DstIP: 172.16.2.2

N1: 198.100.x.x

R2IP=172.16.2.1

R4

R3IP=155.174.3.1R4IP=155.174.3.2

R1IP=198.100.1.1

135.157.x.x

135.209.x.x

Src SrcIP: 198.100.1.2

R1

Dst: DstIP: 172.16.2.2 Src: SrcIP : 198.100.1.2


28

CN

Dst

R3 R2

N3: 155.174.x.xN2: 172.16.x.x

Internet

DstIP: 172.16.2.2

N1: 198.100.x.x

R2IP=172.16.2.1

R4

R3IP=155.174.3.1R4IP=155.174.3.2

R1IP=198.100.1.1

135.157.x.x

135.209.x.x

Src SrcIP: 198.100.1.2

R1



29

CN

Dst

R3 R2

N3: 155.174.x.xN2: 172.16.x.x

Internet

DstIP: 172.16.2.2

N1: 198.100.x.x

R2IP=172.16.2.1

R4

R3IP=155.174.3.1R4IP=155.174.3.2

R1IP=198.100.1.1

135.157.x.x

135.209.x.x

Src SrcIP: 198.100.1.2

R1



30

• Terminology

• CCoA example

• FCoA example

31

Protocol Requirements

• When MN changes its link-layer point of attachment to the Internet, it must be able to communicate with other nodes without changing its IP address

• A MN must be able to communicate with other nodes that do not have mobility functions (i.e stationary hosts)

• Use authentication to protect against remote redirection attacks

Goals

• Minimize MN’s power consumption• Minimize the number of administrative messages over MN’s link• Minimize the size of those messages

32

CN

Dst

R3 R2

N3: 155.174.x.xN2: 172.16.x.x

Internet

DstIP: 172.16.2.2

N1: 198.100.x.x

R2IP=172.16.2.1

R4R3IP=155.174.3.1

R4IP=155.174.3.2

R1IP=198.100.1.1

Src SrcIP: 198.100.1.2

R1

Mobile IPv4 example

33

CN

Foreign Agent (FA)

InternetR1

CNIP: 198.100.1.2

Home Network

Care-of Address (CoA): 155.174.3.3

Home Agent (HA)R3

Foreign Network

Mobile Node (MN)

Corresponding Node (CN)

R1IP=198.100.1.1

N3: 155.174.x.xN2: 172.16.x.x

N1: 198.100.x.x

Permanent

TemporalHome Address (HoA): 172.16.2.2

Terminology

34

CN

InternetR1

MN

CoA: 155.174.3.3

FA HA

CN

R3

HAIP=172.16.2.1

R3IP=155.174.3.1

FAIP=155.174.3.2

R1IP=198.100.1.1

N3: 155.174.x.xN2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

HoA: 172.16.2.2

Strategy

35

CN

Internet

MN

HA

R1

CN

R3IP=155.174.3.1

R3

R1IP=198.100.1.1

N3: 155.174.x.xN2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

HAIP=172.16.2.1

Dst: HoA: 172.16.2.2Src: CNIP : 198.100.1.2

Co-located care-of Address

CCoA: 155.174.3.3HoA: 172.16.2.2

CCoA example

36

Dst: HoA: 172.16.2.2Src: CNIP : 198.100.1.2

Dst: CCoA : 155.174.3.3Src: HAIP : 172.16.2.1

CN

Internet

MN

R1

CN

R3IP=155.174.3.1

R3

R1IP=198.100.1.1

N3: 155.174.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

CCoA: 155.174.3.3HoA: 172.16.2.2

CCoA example

Dst: HoA: 172.16.2.2Src: CNIP : 198.100.1.2

HA

N2: 172.16.x.x

HAIP=172.16.2.1

HoA CoA

37

CN

Internet

MN

R1

CN

R3IP=155.174.3.1

R3

R1IP=198.100.1.1

N3: 155.174.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

CCoA: 155.174.3.3HoA: 172.16.2.2

CCoA example

HA

N2: 172.16.x.x

HAIP=172.16.2.1

Dst: CCoA : 155.174.3.3Src: HAIP : 172.16.2.1

Dst: CCoA : 155.174.3.3Src: HAIP : 172.16.2.1

Dst: CCoA : 155.174.3.3Src: HAIP : 172.16.2.1

Protocol ID in IP header:0x04 for IP in IP encapsulation0x37 for Minimal encapsulation0x2F for GRE encapsulation

38

CN

Internet

MN

R1

CN

R3IP=155.174.3.1

R3

R1IP=198.100.1.1

N3: 155.174.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

CCoA: 155.174.3.3HoA: 172.16.2.2

CCoA example

HA

N2: 172.16.x.x

HAIP=172.16.2.1

Dst: HoA: 172.16.2.2Src: CNIP : 198.100.1.2

Dst: CCoA : 155.174.3.3Src: HAIP : 172.16.2.1

39

CN

Internet

MN

R1

CN

R3IP=155.174.3.1

R3

R1IP=198.100.1.1

N3: 155.174.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

CCoA: 155.174.3.3HoA: 172.16.2.2

CCoA example

HA

N2: 172.16.x.x

HAIP=172.16.2.1

Dst: HoA: 172.16.2.2Src: CNIP : 198.100.1.2

40

CN

Internet

MN

HA

R1

CN

R3IP=155.174.3.1

R3

R1IP=198.100.1.1

N3: 155.174.x.xN2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

HAIP=172.16.2.1

Dst: HoA: 172.16.2.2Src: CNIP : 198.100.1.2

CCoA: 155.174.3.2HoA: 172.16.2.2

FCoA exampleForeign Agent care-of Address

FA

FAIP=155.174.3.2

MACMN: 00:08:02:da:4c:2d

41

Dst: HoA: 172.16.2.2Src: CNIP : 198.100.1.2

Dst: FCoA : 155.174.3.2Src: HAIP : 172.16.2.1

CN

Internet

MN

R1

CN

R3IP=155.174.3.1

R3

R1IP=198.100.1.1

N3: 155.174.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

CCoA: 155.174.3.3HoA: 172.16.2.2

FCoA example

Dst: HoA: 172.16.2.2Src: CNIP : 198.100.1.2

HA

N2: 172.16.x.x

HAIP=172.16.2.1

HoA CoA

MACMN: 00:08:02:da:4c:2d

FA

FAIP=155.174.3.2

42

CN

Internet

MN

R1

CN

R3IP=155.174.3.1

R3

R1IP=198.100.1.1

N3: 155.174.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

CCoA: 155.174.3.3HoA: 172.16.2.2

FCoA example

HA

N2: 172.16.x.x

HAIP=172.16.2.1

Dst: FCoA : 155.174.3.2Src: HAIP : 172.16.2.1

FA

FAIP=155.174.3.2

Dst: FCoA : 155.174.3.2Src: HAIP : 172.16.2.1

MACMN: 00:08:02:da:4c:2d

43

CN

Internet

MN

R1

CN

R3IP=155.174.3.1

R3

R1IP=198.100.1.1

N3: 155.174.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

CCoA: 155.174.3.3HoA: 172.16.2.2

FCoA example

HA

N2: 172.16.x.x

HAIP=172.16.2.1

FA

FAIP=155.174.3.2

Dst: FCoA : 155.174.3.2Src: HAIP : 172.16.2.1

MACMN: 00:08:02:da:4c:2d

44

CN

Internet

MN

R1

CN

R3IP=155.174.3.1

R3

R1IP=198.100.1.1

N3: 155.174.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

CCoA: 155.174.3.3HoA: 172.16.2.2

FCoA example

HA

N2: 172.16.x.x

HAIP=172.16.2.1

FA

FAIP=155.174.3.2

Dst: HoA: 172.16.2.2Src: CNIP : 198.100.1.2

Dst: FCoA : 155.174.3.2Src: HAIP : 172.16.2.1

HoA MAC

MACMN: 00:08:02:da:4c:2d

45

CN

Internet

MN

R1

CN

R3IP=155.174.3.1

R3

R1IP=198.100.1.1

N3: 155.174.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

CCoA: 155.174.3.3HoA: 172.16.2.2

FCoA example

HA

N2: 172.16.x.x

HAIP=172.16.2.1FAIP=155.174.3.2

FA

Dst: HoA: 172.16.2.2Src: CNIP : 198.100.1.2

MACMN: 00:08:02:da:4c:2d

46

Mobile IPv4 Characteristics

• Transparency: to applications, transport layer protocols, most routers

• Interoperability with IPv4: no special addressing scheme

• Scalability: mobility across the global Internet

• Security: all messages are authenticated

• Macro mobility: It is suited for long duration moves instead of fast

network transitions (where link-layer handoffs are better).

47

• Wireless Links

• Handoff example

• Operating Rates

48

Cellular technologies offer Micro-Mobility which can handle fast switching between network access points.

Base Station

SGSN

Wireless Links

49

Handoff example

50

A large scale mobile network can be realized by building MIP on top of a cellular technology.

GPRS (2.5 G) : 170 kbpsEDGE (2.5 G) : 384 kbpsWCDMA (3G) : 2 Mbps

Operating rates for other underlying network technologies:

Ethernet (10 Base S, 10 Base 2, 10 Base T) : 10 MbpsFast Ethernet (100 Base T) : 100 MbpsGigabit Ethernet (1000 Base T) : 1 GbpsFDDI : 100 Mbps

Operating rates for wireless links:

Operating Rates

51

• Purpose

• HA discovery

• FA discovery

•Agent Solicitation

•Agent Advertisement

•Agent Advertisement Extensions

•Agent Considerations

52

Purpose

• MN can find out if it is currently connected to its home network or to a foreign network.

• MN can detect that it has moved from one network to another.

• MN can find the FCoA offered by a FA.

53

CN

Internet

MN

HA

R1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

HoA: 172.16.2.2

HAIP=172.16.2.1

R3IP=155.174.3.1

N3: 155.174.x.x

FAIP=155.174.3.2

MN boots , data-link layer bindings are resolved.

FA

HA discovery

MACMN: 00:08:02:da:4c:2d

54

CN

Internet

HA

R1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

HoA: 172.16.2.2

R3IP=155.174.3.1

N3: 155.174.x.x

FAIP=155.174.3.2

MN broadcasts an Agent Solicitation

HAIP=172.16.2.1

MN

FA

HA discovery

MACMN: 00:08:02:da:4c:2d

55

CN

InternetR1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

HoA: 172.16.2.2

R3IP=155.174.3.1

N3: 155.174.x.x

FAIP=155.174.3.2

HA responds with a unicast agent Advertisement

HAIP=172.16.2.1

HA

MN

FA

HA discovery

MACMN: 00:08:02:da:4c:2d

56

CN

Internet

HA

R1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

HoA: 172.16.2.2

R3IP=155.174.3.1

N3: 155.174.x.x

FAIP=155.174.3.2

HA keeps sending multicast agent advertisementsbefore the advertisement lifetime expires.

HAIP=172.16.2.1

MN

FA

HA discovery

MACMN: 00:08:02:da:4c:2d

57

CN

InternetR1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

R3IP=155.174.3.1

N3: 155.174.x.x

FAIP=155.174.3.2

MN moves

HAIP=172.16.2.1

MACMN: 00:08:02:da:4c:2d

HA

MN

HoA: 172.16.2.2

FA

FA discovery

58

CN

InternetR1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

R3IP=155.174.3.1

N3: 155.174.x.x

FAIP=155.174.3.2

Link-layer handoff finishes.Link-layer mechanisms can be used to decide that MN has changed its point of attachment:Agents can be discovered by a link-layer protocol.

HAIP=172.16.2.1

HA

MN

HoA: 172.16.2.2

MACMN: 00:08:02:da:4c:2d

FA

FA discovery

59

CN

InternetR1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

R3IP=155.174.3.1

N3: 155.174.x.x

FAIP=155.174.3.2

MN receives an advertisement from FAMN knows that it moved, so it can register.

HAIP=172.16.2.1

HA

MN

HoA: 172.16.2.2

FA

Case 1HA entry: expiredFA entry: valid

MACMN: 00:08:02:da:4c:2d

60

CN

InternetR1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

R3IP=155.174.3.1

N3: 155.174.x.x

FAIP=155.174.3.2 HAIP=172.16.2.1

HA

MN

MN does not know if it moved. MN can broadcast an Agent Solicitation

FA

HoA: 172.16.2.2

Case 2HA entry: expiredOther Agent entries: expired

MACMN: 00:08:02:da:4c:2d

61

CN

InternetR1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

R3IP=155.174.3.1

N3: 155.174.x.x

FAIP=155.174.3.2 HAIP=172.16.2.1

HA

MN

FCoA: 155.174.3.2

FA responds with a unicast agent Advertisement.MN learns FAIP and MACFA

FA

HoA: 172.16.2.2

Case 2

MACMN: 00:08:02:da:4c:2d

62

CN

InternetR1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

R3IP=155.174.3.1

N3: 155.174.x.x

HAIP=172.16.2.1

HA

MN

There is no Foreign Agent; MN Boots.

HoA: 172.16.2.2

Case 3

A DHCP server in Network 3 can assign an available IP address from the database.

CCoA: 155.174.3.3MACMN: 00:08:02:da:4c:2d

63

ICMPHeader

ICMP Data



Dst MAC address: ff:ff:ff:ff:ff:ffSrc MAC address: MACMN

Frame Type=0x0800 (IP frame)

Type=10 (Router Solicitation)Code=0

Version=4 (IPv4)TTL=1Protocol=0x01 (ICMP)Src = IPMN: 198.100.1.2Dst = 224.0.0.11

Router Solicitation

Agent Solicitation

All Agents group

Must be one

64

Agent Advertisement

ICMPHeader

ICMP Data



All Systems group

Dst MAC address: ff:ff:ff:ff:ff:ffSrc MAC address: MACFA


Type=9 (Router Advertisement)Code=0, 16 (0common traffic)Number of Addresses=1Lifetime in secondsRouter Address 1 = R3IP:155.174.3.1Preference Level 1 = p1

Version=4 (IPv4)TTL=1Protocol=0x01 (ICMP)Src = FAIP: 155.174.3.2 Dst = 224.0.0.1

Mobility AgentAdvertisementExtension

Prefix-LengthsExtension

One-bytePadding

65

TYPE(16) SEQUENCE NUM

CARE-OF ADDRESSES

0 168 3124

LENGTH

LIFETIME CODE RESERVED

Mobility Agent Advertisement Extension

LENGTH size in octets without TYPE and LENGTH fields

SEQUENCE NUM count of advertisements to help recipient know about lost messages. Range: [0,256]

Registration LIFETIME maximum time to accept registrations or 0xffff for infinity

CODE: RBHFMGrT R – Registration required (CCoA not allowed) B – Busy (do not send registrations) H – Home Agent F – Foreign Agent M – I receive tunneled datagrams with Minimal encapsulation G – I receive tunneled datagrams with Generic Routing Encapsulation r – zero T – Foreign Agent supports reverse Tunneling

Foreign-Agent specific

66

Agent Advertisement Extensions

ICMPHeader ICMP Data

Mobility AgentAdvertisementExtension

Prefix-LengthsExtension

One-bytePadding

Type=16Length=…Sequence=1Registration Lifetime=0xffffCode=RBHFMGrTCare-of Address: FCoA: 155.174.3.2 = FAIP.

Type=9 (Router Advertisement)Code=0, 16 (0common traffic)Number of Addresses=1Lifetime in secondsRouter Address 1 = R3IP:155.174.3.1Preference Level 1 = p1

Type=19 (Prefix-Length Extension)Length= …Prefix Length 1=16

To make ICMP Header even.

67

Agent Considerations

• A mobility agent must choose a maximum rate for agent advertisements in order to save network bandwidth.

• The mobile agent that receives an agent solicitation must not validate the source IP address.

• Through configuration changes, a mobility agent may send agent advertisements only when receiving an Agent solicitation.

• If the home network is a virtual network, the home agent will not send advertisements. The mobile nodes with this home network are treated as being away from home.

68

• Purpose

• Registration Request

• Registration Reply

• Registration Message Format

• Registration Extensions

69

Purpose

• When visiting a Foreign Network, the MN can request forwarding services from HA.

• MN can inform the HA of their current care-of address.• MN can renew a registration that will expire soon.• MN can deregister when it returns home.• MN can discover its home address.• MN can maintain simultaneous registrations.• MN can deregister specific COAs.

70

CN

InternetR1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

R3IP=155.174.3.1

N3: 155.174.x.x

FAIP=155.174.3.2 HAIP=172.16.2.1

HA

MN

Registration request from MN to FAFA learns HoA and MACMN

FA

FCoA: 155.174.3.2HoA: 172.16.2.2

MACMN: 00:08:02:da:4c:2d

Registration Request

71

CN

InternetR1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

R3IP=155.174.3.1

HAIP=172.16.2.1

HA

MN

Registration request from FA to HA

FA

FAIP=155.174.3.2

N3: 155.174.x.x

FCoA: 155.174.3.2HoA: 172.16.2.2

MACMN: 00:08:02:da:4c:2d

Registration Request

72

CN

InternetR1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

R3IP=155.174.3.1

HAIP=172.16.2.1

HA

MN

Registration reply from HA to FA

FA

FAIP=155.174.3.2

N3: 155.174.x.xGRANTED

FCoA: 155.174.3.2HoA: 172.16.2.2

MACMN: 00:08:02:da:4c:2d

Registration Reply

73

CN

InternetR1

CN

R3

R1IP=198.100.1.1

N2: 172.16.x.x

N1: 198.100.x.x

CNIP: 198.100.1.2

R3IP=155.174.3.1

N3: 155.174.x.x

FAIP=155.174.3.2 HAIP=172.16.2.1

HA

MN

Registration reply from FA to MN

FA

GRANTED

FCoA: 155.174.3.2HoA: 172.16.2.2

MACMN: 00:08:02:da:4c:2d

Registration Reply

74

Registration Message Format

TYPE(1 or 3) LIFETIME

CARE-OF ADDRESS

FLAGS

HOME ADDRESS

IDENTIFICATION

EXTENSIONS …

TYPE 1:request, 3:replyLIFETIME # seconds the registration is valid. 0 means immediate deregistration. All ones means infinite lifetime.IDENTIFICATION: generated by MN to match requests with replies, and to ignore old messages.

0 168 31

75

FLAGS: SBDMGrTx

S Simultaneous bindings: Add binding in HA instead of updating it.

This flag avoids many registrations messages when MN changes Foreign Networks rapidly.

Request for HA to tunnel a copy of each datagram to each active COA.

76

FLAGS: SBDMGrTx

S Simultaneous bindings: Add binding in HA instead of updating it.B Broadcast datagrams: send a copy of broadcasts received by HA from the home network.

HAR3

Home NetworkForeign Network

MN

FA

77

FLAGS: SBDMGrTx

S Simultaneous bindings: Add binding in HA instead of updating it.B Broadcast datagrams: send a copy of broadcasts received by HA from the home network.D Decapsulation by Mobile Node: MN will decapsulate (CCoA case).M Request to use Minimal EncapsulationG Request to use GRE encapsulationr zeroT Request reverse tunneling ( MN CN through HA )x zero

HA-specific FA-specific

78

Status Codes

Successful:0 Registration accepted1 Registration accepted, but ‘S’ request unsupported.

Denied by FA:71 poorly formed reply72 requested encapsulation unavailable

Denied by HA:135 Too many ‘S’ bindings.136 Unknown HA address.

Denied by (FA, HA):66, 130 Insufficient resources67, 131 MN failed authentication68, 132 (HA, FA) failed authentication70, 134 poorly formed request

79

Registration Request: MNFA

UDPHeader

UDP Data



Dst MAC address: MACFA

Src MAC address: MACMN


Src port= SPMN

Dst port= 434

Version=4 (IPv4)TTL=1Protocol=0x11 (UDP)Src = HoA: 172.16.2.2Dst = FAIP: 155.174.3.2 or 224.0.0.11 (all agents for link-layer agent discovery)

RegistrationRequest Extensions

Type=1 (request)Flags=SBDMGrTxLifetime=seconds remainingHome Address: HoA: 172.16.2.2Home Agent: HAIP: 172.16.2.1Care-of Address: FCoA: 155.174.3.2Identification: …

80

Registration Request: FAHA

UDPHeader

UDP Data



Dst MAC address: MACHA

Src MAC address: MACFA


Src port= SPFA

Dst port= 434

Version=4 (IPv4)TTL=64Protocol=0x11 (UDP)Src = FAIP: 155.174.3.2Dst = HAIP: 172.16.2.1

RegistrationRequest Extensions

Type=1 (request)Flags=SBDMGrTxLifetime=seconds remainingHome Address: HoA: 172.16.2.2Home Agent: HAIP: 172.16.2.1Care-of Address: FCoA: 155.174.3.2Identification: …

81

Registration Reply: HAFA

UDPHeader

UDP Data



Dst MAC address: MACFA

Src MAC address: MACHA


Src port= AnyDst port= SPFA

Version=4 (IPv4)TTL=64Protocol=0x11 (UDP)Src = HAIP: 172.16.2.1Dst = FAIP: 155.174.3.2

RegistrationReply Extensions

Type=3 (reply)Code=0 (registration accepted)Lifetime=seconds granted by HAHome Address: HoA: 172.16.2.2Home Agent: HAIP: 172.16.2.1Identification: …

82

Registration Reply: FAMN

UDPHeader

UDP Data



Dst MAC address: MACMN

Src MAC address: MACFA


Src port= AnyDst port= SPMN

Version=4 (IPv4)TTL=1Protocol=0x11 (UDP)Src = FAIP: 155.174.3.2Dst = HoA: 172.16.2.2

RegistrationReply Extensions

Type=3 (reply)Code=0 (registration accepted)Lifetime=seconds granted by FAHome Address: HoA: 172.16.2.2Home Agent: HAIP: 172.16.2.1Identification: …

83

Registration Extensions

• Mobile-Home Authentication Extension

• Mobile-Foreign Authentication Extension

• Foreign-Home Authentication Extension

84

• Communication on a Foreign Network

• Proxy ARP

• Gratuitous ARP

• Communication on the Home Network

85

MN communication on a Foreign Network

• Relaxing the rules for IP addressing :– MN FA : MN is allowed to use IPSrc=HoA– FA MN : FA is allowed to use IPDst=HoA

• FA cannot use ARP to find the MACMN. FA has to keep all MN information from the registration request including the MACMN. MN also disables processing ARP requests.

• Because IPMN=HoA, the Foreign Network and the ISP that connects it to the Internet must inhibit Ingress Filtering to allow an arbitrary source address.

• MN CN follows the shortest path. The reply does not.

86

Proxy ARP

Host A sends an ARP request to obtain MACMN.HA sends an ARP reply to A with MACHA. (HA sends the reply in behalf of MN)

HAR3


MN

FA

A

B

IP MAC IPMN MACHA

87

Gratuitous ARP

HA sends an ARP broadcasts(not in response to any requests)

HAR3


MN

FA

A

B

IP MAC IPMN MACHA

IP MAC IPMN MACHA

Registration

Internet

88

MN communication on the Home Network

• HA is usually the router that connects the home network with the rest of the Internet so that HA can easily intercept and tunnel datagrams that arrive for MN from outside.

• When HA accepts a registration request, it performs a gratuitous ARP on behalf of MN, and starts using Proxy ARP to reply to requests for MACMN.

• When Src, and Dst are in the same subnet, IP protocol specifies direct delivery, so Src will not forward datagrams to the default router (HA) if Dst=MN. In this case, Src will use ARP to bind IPMN. (HA replies the ARP request)

• Proxy ARP solves the problem of having multiple routers in the home network: only one acts as HA and tunnels datagrams while the others are deceived through ARP that MN is directly attached.

89

• The Two-Crossing Problem

• Other Issues

90

Two-Crossing Problem

B wants to talk to MN. (Common because of Spatial Locality of Reference)R3 is B’s default router and it is not the FA.HA Intercepts the datagrams for MN and tunnels them back to FA

HA


MN

FA

AB

InternetR3

If this situation is likely to happen, propagate host-specific routes.

91

Other Issues

• The Two-Crossing problem (or 2X problem) illustrates a major disadvantage of mobile IP: inefficient routing. Another example: MNCN follows shortest path, but CNMN goes through HA: Triangular routing. Solution Approach: HA sends bind update over UDP to CN with COA (CN should support binding protocol. CN needs to encapsulates datagrams)

• Tunneling makes it difficult to debug network errors: ICMP report of Unreachable Destination (type 3) contains IP header + the next 64 bits of the datagram that caused the problem. Traceroute would use this information to know which address is unreachable, but since the datagram is encapsulated, it cannot know.

• Asymmetric routing makes Path MTU a difficult problem (used by non-TCP mechanisms to enhance performance). The Ideal MSS (Maximum Segment Size) is the minimum MTU along the path so that the maximum amount of information can be sent without fragmentation.

92

Low Latency Handoffs

For MIPv4

93

Overview

• Issues:– As a mobile node moves from one network to another, data

flow will be interrupted because the MN can only be connected to one FA at a time, causing packet loss

– During the process of disconnection from one FA and connection to another FA, there is a delay of traffic called latency

94

Overview

• Sources of latency that are usually sequential and cause packet loss/interruption

1. Layer 2 latency – Time between link layer detachment from previous network to link reattachment at new network

2. Advertisement latency -Latency at Layer 3 between the Mobile Node attaching to new link and receiving a broadcast Foreign Agent Advertisement.

3. Registration latency - Latency at Layer 3 between the Mobile Node receiving the Foreign Agent Advertisement and completing registration with the Foreign Agent and Home Agent.

• Reduce latency by overlapping the above

95

But first, some definitions

• low latency handoff - L3 handoff in which the period of time during which the MN is unable to receive packets is minimized.

• low loss handoff - L3 handoff in which the number of packets dropped or delayed is minimized. Low loss handoff is often called smooth handoff.

• seamless handoff - L3 handoff that is both low latency and low loss

• bi-directional edge tunnel (BET) - A bi-directional tunnel established between two FAs for purposes of temporarily routing a MN's traffic to/from it on a new subnet without requiring the MN to change CoA, referred to in the presentation as just a “tunnel”

• IP address identifier - IP address of a MN or FA, or an L2 identifier that allows an FA to deduce the IP address of a MN or FA.

96

Two general solutions (1)

• PRE-REGISTRATION handoff method– Allow connection of mobile node to both FA's during

handover– L3 before L2 means that the new TCP connection is

established for the MN before the MN switches networks– L2 triggers initiate this (from MN, MN-initiated & from FA,

FA-initiated)Remember: Layer 2 is the data link layer - logical link control, media access control, hardware

addressing, error detection and handling, (LLC & MAC)Layer 3 is the network layer - IP (or in this case mobile IP)

• So PRE-REGISTRATION the latency at layer 2 and 3 are overlapped to occur simultaneously!

97

Two general solutions (2)

• POST-REGISTRATION handoff method– Provide data flow from new FA before registration at new FA

occurs– L2 before L3 means that the MN has moved to the new

network but uses the old TCP connection to the previous FA

• L2 latency still exists, but the Advertisement and Registration latency is dealt with after handoff !

98

What is a “trigger”

• Triggers = signals that start a handoff between wireless networks and happen at the L2 layer

Remember:

Layer 2 is the data link layer - logical link control, media access control, hardware addressing, error detection and handling, (LLC & MAC)

• For mobile IP usage, these should be considered abstractions that contain mandatory information that can be used for any type of Layer 2

• L2 Triggers can be received by and defined as:– MN – can receive mobile trigger (L2-MT) or link-up (L2-LU)

– oFA - can receive source trigger (L2-ST) or link-down (L2-LD)

– nFA - can receive target trigger (L2-TT) or link-up (L2-LU)

99

Types of trigger (1)

L2 Trigger Mobile Trigger

(L2-MT)

Source Trigger (L2-ST)

Received by MN oFA

Method PRE-Mobile initiated PRE-network initiated

POST source trigger

What? An L2 trigger that occurs at the MN informing of movement to a certain nFA (Mobile Trigger)

An L2 trigger that occurs at oFA, informing the oFA that L2 handoff is about to occur.

When? Enough in advance of the L2 handover so that MN can still solicit ProxyRtAdv from oFA

Enough in advance of the L2 handover for FA to send proxyRtAdv to MN

Enough in advance of the L2 handover for oFA and nFA to exchange HRqst/Hrply

Parameters nFA IP address identifier nFA IP address identifier

MN IP address identifier

100

Types of trigger (2)

L2 Trigger Target Trigger

(L2-TT)

Link-Up

(L2-LU)

Link-Down

(L2-LD)

Received by nFA MN or nFA oFA

Method PRE-Network initiated

POST Target trigger

PRE & POST POST

What? An L2 trigger that occurs at nFA, informing the nFA that a MN is about to be handed off to nFA.

An L2 trigger that occurs at the MN or nFA, informing that the L2 link between MN and nFA is established.

An L2 trigger that occurs at the oFA, informing the oFA that the L2 link between MN and oFA is lost.

When? Same as source trigger When radio link between MN & nFA is established

When radio link between MN & oFA is lost

Parameters oFA IP address identifier

MN IP address identifier

MN, nFA IP or L2 address

MN IP address identifer

101

More on PRE-Registration (1)

• L2 triggers (L2-MT, L2-ST) initiate this type• MN registers in advance (I.e. before it moves to new

wireless network) with nFA • TCP connection exists through a oFA<->nFA tunnel

to nFA until MN actually moved to network served via nFA

• Until the MN actually completes the L2 handoff to the new FA and establishes the new L2 link, the new FA can receive packets for which it does not have a link layer connection.

102

More on PRE-Registration (2)

• PRE-REGISTRATION won’t work unless the FA or MN are able to obtain an L2 trigger that indicates pending L2 handoff

• The L2 trigger must allow enough time for the PRE-REGISTRATION handoff procedure to be performed.

• The PRE-REGISTRATION Handoff method is applicable in the following cases:– when the MN has locally defined policies that determine a preference for one access

over another, for example due to service cost within the same or different technology, and therefore where it is necessary to allow the MN to select the appropriate FA with which to connect,

– when L2 security between the MN and the FA is either not present or cannot be relied upon to provide adequate security,

– when the trigger to initiate the handoff is received at the MN

– scenarios where a period of service disruption due to layer 3 is not acceptable, e.g. performing real-time communications

103

PRE-REGISTRATION – FA solicitations of adverts #1

oFa

#1nFa

Ha

#4nFa

#3nFa

#2nFa

Router Solicitation

Rou

ter S

olic

itatio

n

Router Soliciatation

Router S

oliciatatio

n

The oFA that is currently serving the network that the MN polls FA’s in adjacent networks for their information. The TTL in the Router Solicitation = 1 so only adjacent FA’s are polled.

MN

104

PRE-REGISTRATION – current FA RT Adverts back

oFa

#1 nFa

Ha

#4 nFa

#3nFa

#2 nFa

Router Advertisement #4 + LLE

Router Advertisement #1 +LLE

Router A

dvertise

ment #3 +

LLE

Rou

ter A

dvertis

em

en

t #2

Cache:#1 nFa advert

…#4 nFa advert

The FA that is currently serving the network that the MN is in caches all the most current Router Advertisements from surrounding FA’s. This is done periodically with the minimum requirement being every one second. Also note that the cached Advertisements contain link-layer extensions of one type or another. Router Advertisements are also sent with a TTL = 1.

MN

105

PRE-REGISTRATION variations on the standard MIP messages

• An MN, in MIPv4, sends a Router Solicitation directly to an FA to begin the registration process. However for a Mobile Initiated PRE-REGISTRATION, the MN sends a ProxyRouterSolicitation to the oFA about the nFA.

• In the case of network initiated PRE-REGISTRATION, the MN received a ProxyRouterAdverstisement for the nFA through the oFA. This ProxyRouterAdvertisement contains the nFA’s layer 2 address in a Generalized Link Layer Extension

• Note that the “proxy” here is the oFA and the MN is registering with an FA which is not only one hop away, thus need some other way to send addresses then in layer 2 or layer 3 data packets. Hence the use of GLLEs.

106

L2 address and Link Layer Extenstions

Note in the following diagrams, IP addresses are indicated, but in reality, any identifier as mentioned above can be used in the LLE’s

Generalized Link Layer Extensions have a generic format as follows:

Type Length Sub-Type Identifier (1-7) LLA

Link Layer Sub-Type ID1 3GPP2 International Mobile Station Identity & Connection ID 2 3GPP International Mobile Subscriber Identity 3 Ethernet 48 bit MAC address [5]4 64 bit Global ID, EUI-64 [6]5 Solicited IP Address6 Access Point Identifier7 FA IP Address

The actual data corresponding to the Identifier:

e.g. IMSI, IMSI, MAC, MAC, IP, AP, IP

107

PRE-REGISTRATION – current oFA RT Adverts back (network initiated source trigger L2-ST)

oFa

Ha

#4 nFa

Cache:#1 nFa advert

…#4 nFa advert

Got an L2-ST signal! MN

moving to #4 network – got nFA IP and MN IP from

the L2-ST

MN is moving

Pro

xyR

ou

terA

dvertis

em

en

t nFa #

4

+LLE

Als

o, th

e T

TL o

f this

Ad

vertis

em

en

t =

1

Reg

istr

ati

on

Req

ud

est

to n

Fa

#4

Registration Request to nFa #4 – oFA has nFA’s IP address

Registration Requdest to Ha

+LLE with MN layer 2 address

Registration Reply + data

Reg

istra

tion

Rep

ly +

Data

p

ackets

Buffer this reply and

start buffering

data too, no L2 yet!!

Got an L2-UP signal! From MN – start sending

Ag

en

t S

olicit

ati

on

to n

Fa #

4 o

r L2-

UP

MN MN

X

Time between L2 trigger at oFA & actual L2 handoff (1st 4 messages) is crucial. If not possible MN may set “S” bit in Registration Request to allow reception of packets from both oFA and nFA. This applies to this and following scenarios.

108

PRE-REGISTRATION – current FA RT Adverts back (network initiated target trigger L2-TT)

oFa

Ha

#4 nFa

Cache:#1 nFa advert

…#4 nFa advert

Got an L2-TT signal w/ MN & oFA IP’s. MN moving

my network, send an

advert to the MN’s IP

MN is moving

Pro

xyR

ou

terA

dvertis

em

en

t nFa

#4

Reg

istr

ati

on

Req

ud

est

to n

Fa

#4

Registration Request to nFa #4


Registration Reply +

data R

eg

istra

tion

Rep

ly +

Data

p

ackets

Tunnel Agent Advertisement to MN – MUST BE AUTHENTICATED

Ag

en

t S

olicit

ati

on

to n

Fa #

4

Buffer this reply and start buffering data

too, no L2 yet !!

MNMN

X

109

PRE-REGISTRATION – current FA RT Adverts back (mobile initiated L2-MT)

oFa

Ha

#4 nFa

Cache:#1 nFa advert

…#4 nFa advert

Got a L2-MT signal it has nFA’s IP address, moving to #4 – have to solicit registration

with that nFA

MN is moving

Pro

xyR

ou

terA

dvertis

em

en

t nFa

#4

Pro

xyR

ou

terS

olicit

ati

on

nFa #

4

IP

Reg

istr

ati

on

Req

ud

est

to n

Fa

#4




Reg

istra

tion

Rep

ly +

Data

p

ackets

Buffer this reply and

start buffering data too

MN MN

X

110

PRE-REGISTRATION – Security Considerations (L2 Address)

oFa

Ha

#4 nFa

Cache:#1 nFa advert

…#4 nFa advert

Got a L2-MT signal,

moving to #4 – have to register!

MN is moving

Pro

xyR

ou

terA

dvertis

em

en

t nFa

#4

Pro

xyR

ou

terS

olicit

ati

on

nFa

#4 R

eg

istr

ati

on

Req

ud

est

to n

Fa

#4



Reg

istra

tion

Rep

ly +

Data

p

ackets


MN MN

All FAs involved in PRE-REGISTRATION handoffs MUST HAVE security associations with other neighboring FA’s to authenticate and protect the integrity of them and to allow solicitations between them.

A FA must not accept solictations or advertisements from sources that are not authenticated.

111

POST-Registration Handoffs

• Recall: L2 latency still exists, but the Advertisement and Registration latency is dealt with after handoff

• L2 actually becomes disconnected, L3 persists• method uses bi-directional edge tunnels (BETs) or unidirectional tunnels to

transfer data between the oFA and nFA while performing a low latency change in the L2 point of attachment for the MN without requiring any involvement by the MN

• oFA becomes the anchorFA and MN still uses it even after hand off• MN is still actually registered with oFA the whole time

112

More on POST-Registration

• allows FAs to communicate directly about a pending handoff, • best for technologies where the link layer imposes hard deadlines on handoff

time windows• This makes POST-REGISTRATION best for handoffs between FAs that support

the same radio access technology

• POST-REGISTRATION handoff is appropriate in the following cases:– L2 triggers are available on the network to indicate that L2 handoff is pending.

– Pre-provisioned security mechanisms are in place to allow fast and secure messaging between the FAs and between the MN and an FA.

– Access point choice by the MN is not a concern or choice requires user intervention and therefore is not on the critical path for handoff.

113

POST-Registration new messages – Handoff Request

• Message and field definitions

Type H N R M G T B Reserved

Lifetime – seconds of life for tunnel service for MN. Context is as follows:HRqst(t): lifetime requested by nFA for reverse tunnel, 0 = reverse tunnel uneeded

HRqst(s): max time oFA will maintain reverse and forward tunnel, 0= refusal to tunnel

HRqst<r>: renewal for indicated lifetime, 0 = terminate tunnel immediately

Reserved

MN Home Address: HRqst(s), the home address of the MN

HA Address: HRqst(s), the HA address of the mobile node

Identification

Extensions … needs LLA + MN's L2 address

B=1: HRqst(s) only, MN request for nFA to use reverse tunnel to HA if nFA will not reverse tunnel to oFA

T=1: HRqst(s) – oFA supports both fwd and rev tunnelHRqst(t) – nFA requesting reverse tunnel service

G=1, FA sending message will use GRE Encapsualtion for tunnel

M=1, sending FA will use Minimal Encapsulation at tunnel

H=0 & N=0 & R=1, then this is a request to renew the tunnel

Source or Target triggers handoff requestH = 1 & N = 0, L2-ST at oFAH = 0 & N = 1, L2-TT at nFA

114

POST-Registration new messages – Handoff Reply

• Message and field definitions

Type H N R M G T B Reserved Code – 0 = handoff request OK,

1= handoff cannot be perfomed

Lifetime - seconds of life for bi-directional tunnel for MN.HRply(t): max time oFA will grant to nFA

HRply(s): lifetime requested by nFA, less then max sent in HRqst

Hrply{r}: amount of time tunnel life will be extended

Reserved

MN Home Address: HRply(t), the home address of the MN

HA Address: HRply(t), the HA address of the mobile node

Identification

Extensions: FA-FA Authentication Extension used to secure the HRply message

B=1: HRply(t) only, MN request for nFA to use reverse tunnel to HA if nFA will not reverse tunnel to oFA, this can only be sent if T bit not sent in HRqst(t)

T=1: HRply(s) – nFA requesting reverse tunnel serviceHRply(t) – oFA provides both fwd & rev tunnel

G=1, FA sending message will use GRE Encapsualtion for tunnel

M=1, sending FA will use Minimal Encapsulation at tunnel

H=0 & N=0 & R=1, then this is a request to renew the tunnel

H = 1 & N = 0, this is reply to HRqst(s)H = 0 & N = 1, this is reply to HRqst(t)

115

POST-Registration new messages – Handoff To Third

• Message and field definitions - – same as HRqst & HRply with a few differences– If HTT sent in response to L2-ST to initiate a handoff, fields & extensions are the same as a HRqst(s)– If HTT sent in response to L2-TT to initiate a handoff, fields & extensions are the same as a HRqst(t)

Type H N R M G T B Reserved Code

Lifetime - seconds of life for bi-directional tunnel for MN Reserved

MN Home Address

HA Address

Identification

Solicited IP Address Option: containing aFA's Address &

LLA Option: containing the L2 address of the MN Extensions

H = 1 & N = 1 are always set in all cases !!

Tunnel bits are never set in all cases !!

116

POST-Registration L2-ST at oFA

oFa

Ha

nFa

MN moving to new network. Got a L2-ST signal, contains MN’s L2 address and nFA

identifier (IP or other)

MN is moving

Handoff Rqst H=1, N=0, lifetime, HA & MN’s IP, LLA w/ MN’s L2 addr

Handoff Reply, H=0, N=0, R=0, if T=1, rev tunnel duration=lifetime

MN L2-LD signal that MN is not connected start tunnel & send

data via nFaGot a L2-LU signal

from MN start delivering data

buffered and new data

I am still taking to oFA, but can re-

register with nfa if I want, if I do, nFA

become aFA. If I move again without

registering, my oFA becomes an aFA

MN MN

X

117

POST-Registration L2-TT at nFA

oFa

Ha

nFa

MN is moving

Handoff Request, H=0, N=1, lifetime, LLA w/ MN’s L2 addr, T= rev tunnel req

MN moving to this network. Got a L2-TT

signal, contains MN’s L2 address and oFA

identifier (IP or other)

Handoff Reply, N=1, H=0, R=0, if T=1, then tunnel duration=lifetimeMN L2-LD signal that

MN is not connected start tunnel & send




I am still taking to oFA, but can re-

register with nfa if I want, if I do, nFA

become aFA. If I move again without

registering, my oFA becomes an aFA

MN MN

X

118

POST-Registration – Security Considerations

oFa

Ha

nFa

MN is moving

Handoff Request

Got a L2-TT signal, MN

moving to my network

Handoff Reply

MN L2-LD signal that MN is not connected start tunnel & send




I am still taking to

oFA, but can re-register with nfa if I

want

Interesting issue because a MN will be receiving packets from an FA that which it has never registered with. Messages between oFA/aFA and nFA MUST also be authenticated. All FAs involved in low latency handoffs MUST HAVE security associations with other neighboring FA’s via a variety of mechanisms (shared keys and such) that minimally must be manually configured.

MN MN

L2 triggers must also be secured and guarentee that both the L2 addresses and IP addresses of the MN’s and FA’s are authentic.

119

POST-Registration 3rd party hand off

• MN has already established an aFA • The aFA is not in the current or destination network• MN retains L3 connection to aFA, so no L3 change

120

aFa

POST-Registration three party handoff L2-ST

oFa

Ha

nFa

MN is moving

HTT w/ H=1, N=1, MN’s IP, MN’s HA IP, LLA w/MN L2, LLA w/ nFA IP

Handoff Reply(s)MN L2-LD signal that MN is not connected

do a HRqst(r ) to stop tunnel from oFA to aFa. NOTE: if tunnel from aFa to nFa has not been established

yet, must do immediately !

Got a L2-LU signal from MN start delivering data


I am still taking via

aFA, but can re-register with nFa if I

want

MN moving to new network. Got a L2-ST signal with MN’s IP

and nFA’s IP identifier.

Handoff Request(t)

Handoff Reply

(t)

Handoff Reply

(r )

Handoff Request

(r )

Add message specific Icons w/ bits

MN MN

X

HTT received, am I already

tunneling for this MN?

No: register with aFa

Yes: nFa = aFa so after get L2-LU start routing to

MN

121

aFa

POST-Registration three party handoff L2-TT

oFa

Ha

nFa

MN is moving

Handoff Request(t)

HTT w/ H=1, N=1, MN’s IP, MN’s HA IP, LLA w/MN L2, LLA w/nFA IPMN L2-LD signal that MN is not connected

do a HRqst(r ) to stop tunnel from oFA to aFa. NOTE: if tunnel from aFa to nFa has not been established

yet, must do immediately !

Got a L2-LU signal from MN start delivering data


I am still taking via

aFA, but can re-register with nFa if I

want

Handoff Request(t)

Handoff Reply

(t)

Handoff Reply

(r )

Handoff Request

(r )

Add message specific Icons w/ bits

MN MN

XMN moving to new network. Got a L2-TT signal with MN’s L2 addr and oFA’s IP

identifier.

HTT received, am I already tunneling for

this MN? No: register with aFa

Yes: nFa = aFa so after get L2-LU start routing

to MN

122

Some notes on Tunneling service

• The MN’s current FA can signal the aFA to keep the BET alive by renewal with no registration needed from the MN

• The aforementioned HRqst (r ) and Hrply(r ) messages are used between FA’s for BET renewal and include the R (renewal) bit set and a lifetime indicated

• However aFA always controlls the tunnel and can shorten the requested lifetime or deny renewal

• The aFA will terminate the BET if the lifetime expires before a renewal message arrives

123

Some notes on Mobile IP Registrations

• The MN’s current FA can also signal the aFA to cancel & terminate the BET, if this is the case, the FA must start MIP registration with the MN

• The MN should attempt to register with the nFA via an Agent Solicitation before the lifetime expires or if a renewal of the BET is denied

• The MN can also decide to do registration at any time by sending an Agent solicitation

• MN must do registration if it receives an Agent Advertisement

124

One last option

• Uses both- Combined Handoff Method• This method protects the MN from delays caused by errors such as

loss of one of the Mobile IP PRE-Reg messages

• Both PRE & POST started at same time– Timer at nFA started on the PRE process after Registration Req

message– if PRE can be done before timer pops for L2 handover

• then go with PRE Registration

– Otherwise nFA contacts oFA to automatically start forwarding traffic to nFA to prepare for POST Registration

125

Summary Comparison

• The POST-REGISTRATION handoff – approach allows FAs to communicate directly about a pending handoff, same

L3 link is used– does not require any IP layer messages to be sent to or from a MN prior to

the L2 handoff event– only L2 latency is seen during handoff procedure– best between FAs that support the same radio access technology where MN

does not have to be involved

• PRE-REGISTRATION – overlaps the L3 and L2 latencies and possibly already redirects packets

before the L2 link is down– requires MN interaction with the network – best for radio technologies that also require such interaction– best for heterogeneous technology handoffs that require the MN to participate

126

Performance Considerations

• Study [4] did a comparison that demonstrated:• POST-REGISTRATION

– less loss packets then PRE-REGISTRATION– some packets have slightly larger delays– better suited to tight L2 trigger timing– influence of the handoff on the stream’s delay starts later as

well as lasts longer ( i.e. packet loss and latency happen later)

• PRE-REGISTRATION – higher quantity of packets are lost– fewer packets then POST-REGISTRATION experience

delay, but those late packets have very much higher delays

128

RegistrationRegistration

When the mobile node is away from home, it registers its care-of-address with its home agent. Mobile node registers it’s care-of-address each time it changes its care-of-address.

Disadvantages If the distance between the visited network and the home network of

the mobile node is large the signaling delay for these registrations may be long. This condition is worsen if the MN switches from one FA to another FA within the visited network introducing unnecessary signaling delay for registrations with the home agent.

Home Agent Foreign Agent1 Foreign Agent2

Public IP network

(Eg., Internet, ISP)

Home Network

Visited Network

129

Regional Registration Regional Registration

Registration local to the visited domain. The regional registration is performed via a new network entity called a Gateway foreign agent and introduces a layer of hierarchy in the visited domain.

Advantages

Regional Registration reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This will both decrease the load on the home network, and speed up the process of handover within the visited domain.

Home Agent

Foreign Agent1 Foreign Agent2

Public IP network


Home Network Visited Network

Gateway Foreign Agent

130

Protocol Overview

In case of regional registrations, the care-of-address that is registered at the home is the address of a GFA. The GFA keeps a visitor list of all the mobile nodes currently registered with it. Since the care-of-address registered at the home agent is the GFA address, it will not change when the mobile node changes the foreign agent under the same GFA. Thus, the home agent does not need to be informed of any further mobile node movements within the visited domain.

Home Agent


Public IP network




CO

A1

CO

A2

GFA ADDRESS

131

Advertising Foreign Agent and GFA

If the ‘I’ flag is set, there must be at least one care-of-address in the agent advertisement message, but that address may be set to “all ones” address.

If the ‘I’ flag is set, and there is only one care-of-address (which is not all ones), it is the address of the FA.

If the ‘I’ flag is set, and there are multiple care-of-address, the first care-of-address is the local FA, and the last care-of-address is the GFA.

Note: AAM is Agent advertisement message


Visited Network


AAM AAM

Flag I: This domain supports Regional Registration

Type Length Sequence Number

Life Time R B H F M G V T S I

Zero or More Care-of-Address

reserved

132

Home Registration MN Compares the domain part of the foreign agent NAI, from AAM, with the domain

part of its own NAI, to determine whether it is in its home domain or in a visited domain.

Mobile node uses two messages to register with Home agent Registration Request Message Registration Reply Message Registration Message extension

Mobile node can use any of the following address as the care-of-address: FA as care-of-address GFA as care-of-address Co-located care-of-address Zero’s as care-of-address All one’s as care-of-address

133

Registration Request MessageType Life Time

Home Address

S xTrGMDB

Home Agent

Care-of-Address

Identification

Extension……….

Type: TBD (Regional Registration Request)

Life Time: no of seconds the registration is valid, 0 means immediate deregistration and All ones means infinite lifetime.

Home address: The IP address of the mobile node’s home agent.

Home agent: The IP address of the mobile node’s home agent.

Care-of Address: The IP address for the end of the tunnel.

134

Registration Reply MessageType Life Time

Home Address

Code

Home Agent

Identification

Extension……….

Type: TBD (Registration Reply)

Code: A value indicating the result of the registration request.

Life Time: If the code field indicates that the registration was accepted, the lifetime field is set to the number of seconds remaining before the registration is considered expired. A value of zero indicates that the mobile node has been de-registered. A value of 0xffff indicates infinity.

Home address: The IP address of the mobile node’s home agent.

Home agent: The IP address of the mobile node’s home agent.

135

GFA IP Address Extension

Type Length GFA IP Address…..

GFA IP Address

Type: TBD (GFA IP address)

Length: 4

GFA IP Address: The GFA IP address field contains the gateway foreign agent’s publicly routable address.

The mobile node can request for a dynamically assigned GFA by sending a registration request message with the care-of-address field set to zero.

If the mobile node requests a dynamically assigned GFA, the GFA adds a GFA IP address extension to the RReqM before relaying it to the HA.

When Home agent receives a RReqM with care-of-address set to zero, and a GFA IP address extension, it registers the GFA IP address as the care-of-address of the mobile node.

The home agent includes the GFA IP address in the RRpyM from the RReqM. The GFA IP address appears before the mobile-home Authentication ext. in the

RRpyM

136

Hierarchical Foreign Agent Extension

Type Length FA IP Address…..

FA IP Address

Type: TBD (GFA IP address)

Length: 4

FA IP Address: The IP address of the foreign agent relaying the RReqM

When this extension is added to a RReqM by a foreign agent, the receiving mobility agent sets up a pending registration record for the mobile node, using the IP address in the Hierarchical Foreign agent extension as the care-of-address for the mobile node.

The extension must be appended at the end of all previous extensions that had been included in the registration message as received by the foreign agent.

The receiving foreign agent must remove the hierarchical foreign agent extension added by the sending foreign agent in the RReqM.

The hierarchical foreign agent extension should be protected by a FA-FA authentication extension.

137

MN using FA as care-of-address


Visited Network

Gateway Foreign AgentHome Agent

Public IP network


Home Network

RR

Q

RRQ

RR

P

RRP

IF the care-of-address in the registration request is the address of the foreign agent, the foreign agent relays the message directly to the home agent.

For each pending or current home registration, the foreign agent maintains a visitor list entry.

138

MN using GFA as care-of-address


Visited Network


Home Agent

Public IP network


Home Network

RR

Q

RRQ

RR

P

RRP

RR

Q-w

/ext

RR

P-w

/ext

If the care-of address in the Registration Request is the address of a GFA (or zero), the foreign agent adds a Hierarchical Foreign Agent extension, including its own address, to the Registration Request message, and relays it to the GFA.

The Hierarchical Foreign Agent extension MUST be appended at the end of all previous extensions that were included in the Registration Request message when the foreign agent received it.

139

MN using GFA as care-of-address (continued……)

If the Hierarchical Foreign Agent extension comes after the MN-FA authentication extension, the GFA will remove it from the Registration Request message and then sends the request to the home agent.

Upon receipt of the Registration Reply message, the GFA consults its pending registration record to find the care-of address within its domain that is currently used by the mobile node, and sends the Registration Reply to that care-of address.

140

MN using co-located care-of-address


Visited Network


Home Agent

Public IP network


Home Network

RR

Q

RRQ

RR

P

RRP

A mobile node with a co-located care-of address might also want to use Regional Registrations.

The mobile node MAY then generate a Registration Request message, with the GFA address in the care-of address field, and send it directly to the GFA (not via a foreign agent).

In this case, the mobile node MUST add a Hierarchical Foreign Agent extension, including its co-located care-of address, to the Registration Request before sending it.

141

If the mobile node has established a mobility security association with the GFA, the Hierarchical Foreign Agent extension will be placed after the MN-HA authentication extension and before the MN-FA authentication extension. Otherwise the Hierarchical Foreign Agent extension will be placed before the MN-HA authentication extension.

If the Replay extension is present in a home registration, and follows the MN-HA authentication extension, the GFA will remove the Replay extension after performing any necessary processing, before sending the home registration to the home agent.

MN using co-located care-of-address (continued……)

142

MN using zero’s as care-of-address


Visited Network


Home Agent

Public IP network


Home Network

RR

Q

RRQ-W/ext

RR

P

RRP-W/ext

RR

Q-W

/Ext

RR

P-W

/ext

When the mobile node requests that a GFA address is dynamically assigned to it by setting the care-of-address in a registration request to zero, the mobile node and its home agent must support the GFA IP address extension.

If the care-of address in the Registration Request is the address of a GFA (or zero), the foreign agent adds a Hierarchical Foreign Agent extension, including its own address, to the Registration Request message, and relays it to the GFA.

143

MN using zero’s as care-of-address (continued…….)

The Hierarchical Foreign Agent extension MUST be appended at the end of all previous extensions that were included in the Registration Request message when the foreign agent received it.

If the care-of address field of the Registration Request is set to zero, the GFA assigns a GFA care-of address for this Mobile Node, and adds a GFA IP Address extension with this address to the Registration Request message and then sends the request to the home agent.

144

MN using one’s as care-of-address

A mobile node that doesn’t support regional registration copies an “all ones” in the care-of-address from an advertisement.

If the foreign agent receives a registration request where the care-of-address is set to “all ones”, it must reply with the code field set to “Poorly Formed Request”.


Visited Network


Home Agent

Public IP network


Home Network

RR

Q

RR

P

145

Regional Registration

Once the home agent has registered the GFA address as the care-of address of the mobile node, the mobile node may perform regional registrations.

If the advertised GFA care-of address is the same as the one the mobile node registered during its last home registration, or the realm part of the newly advertised FA-NAI matches the FA-NAI advertised by the mobile nodes previous FA. Then the mobile node can perform regional registration

Home Agent


Public IP network



Gateway Foreign AgentGFA ADDRESS

RR

RQ

RR

RQ

-w/e

xt

RRRR-w/ext

RR

RR

146

Regional Registration (Continued…)

The mobile node issues a regional registration request message via the new foreign agent.

The mobile node may register one of the following when performing regional registration

FA as care-of-address Co-located care-of-address Zero’s as care-of-address

The new FA adds a Hierarchical foreign agent extension to the message and relays it to the GFA, if it does not contain care-of-address in the regional registration request.

Based on the information in the hierarchical foreign agent extension, the GFA updates the mobile node’s current point of attachment in its visitor list.

GFA then issues a regional registration reply to the mobile node via the foreign agent.

147

Regional Registration Request Message

Type Lifetime

Home Address

S xTrGMDB

GFA IP Address

Care-of-Address

Identification

Extension……….

Type: TBD (Regional Registration Request)

GFA IP address: The IP address of the gateway foreign agent.

Care-of Address: Care-of address of local foreign agent; May be set to all ones.

Extensions: For the Regional Registration Request, the Hierarchical foreign agent extension is also an allowable extension in addition to those which are allowable for the registration request message.

148

Regional Registration Reply Message

Type Lifetime

Home Address

Regional FA IP Address

Identification

Extension……….

Code

Type: TBD (Regional Registration Reply)

Regional FA IP address: The IP address of the gateway foreign agent.

Extensions: The regional FA IP address is the address of the regional foreign agent generating the regional registration reply message. For the two-level hierarchy, it may be the address of the GFA. For more levels of hierarchy, it may be the address of an intermediate RFA.

149

Mobile node consideration

The mobile node maintains the following information:• The link-layer address of the foreign agent to which the Registration Request

was sent, if applicable, • The IP destination address of the Registration Request• The care-of address used in the registration• The Identification value sent in the registration• The originally requested Lifetime, and • The remaining Lifetime of the pending registration.• The GFA address • The style of replay protection in use for the regional registration • The Identification value for the regional registration.

150

Foreign agent consideration

When the foreign agent receives a Regional Registration Request message from a mobile node, addressed to a GFA, it processes the message generally according to the rules of processing a Registration Request message addressed to a home agent.

The only difference is that the GFA IP address field replaces the home agent address field. If that address belongs to a known GFA, the foreign agent forwards the request to the indicated GFA. Otherwise, the foreign agent will generate a Regional Registration Reply with error code UNKNOWN_GFA.

For each pending or current registration, the foreign agent maintains a visitor list entry.

151

GFA consideration

If the GFA accepts a request for regional registration, it MUST set the lifetime to be no greater than the remaining lifetime of the mobile node's registration with its home agent, and put this lifetime into the corresponding Regional Registration Reply.

The GFA MUST NOT accept a request for a regional registration if the lifetime of the mobile node's registration with its home agent has expired. In that case the GFA sends a Regional Registration Reply with the value in the Code field set to NO_HOME_REG.

If the GFA receives a tunneled packet from a foreign agent in its domain, then after de-capsulation the GFA looks to see whether it has an entry in its visitor list for the source IP address of the inner IP header after de-capsulation.

If so, then it checks the visitor list to see whether reverse tunneling has been requested; if it was requested, the GFA re-encapsulates the packet with its own address as the source IP address, and the address of the home agent as the destination IP address.

153

The Idea

• Assign an optimal HA for a Mobile IP session.

154

1) If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long.

2) In a large scale Mobile IP deployment, it is cumbersome to provision MNs with multiple HA addresses

3) To achieve some form of load balancing between multiple HAs in the network.

155

The technique

• Proposing a messaging mechanism for dynamic home agent assignment and home agent redirection during initial registration.

Redirected HA Extension

156

The technique

• Proposing a messaging mechanism for dynamic home agent assignment and home agent redirection during initial registration.

Dynamic HA Extension

157

Problem Highlight

158

• Mobile IP requires that a Mobile Node (MN) have a static Home Agent (HA) and a permanent home IP address, which is not always desirable for MNs, especially MNs in a commercial ISP domain.

159

• Furthermore, for some big network domains such as national wireless network service providers, the MN’s current network attach point could be far away from the static HA and hence could cause severe triangle routing problems.

160

• Finally, when a MN keeps migrating to a nearby Foreign Agent (FA) if the MN is fast moving, which is typical for wireless network subscribers, the signaling with

the remote HA will cause an unacceptable long delay.

161

Solution

162

Dynamic Home Agent Assignment

163

Dynamic Home Agent Assignment

Dynamic Home address Assignment

FA Pending registration request

NAI (Network Access Identifier)

164

Network Access Identifier

• For example using the user name as an Identifier.

165

Dynamic Home Agent Assignment “The Gory Details”

• Mobile IPv4 discovers the mobile node's home agent using subnet-directed broadcast IP address in the home agent field of the Registration Request.

Drawbacks:

1) Assumes fixed network prefix and fixed home address

HA on Fixed Network Signaling delay can’t be avoided.

2)Some routers drop directed broadcast packets.

166

The Dynamic HA address Extension

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-Type | Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA-Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sub-Type:

sub-type 1 = Requested HA Extension

sub-type 2 = Redirected HA Extension

All-zero-one-Address: 255.255.255.255 indicates a preference for an HA in the home domain. An address of 0.0.0.0 indicates no preference for home vs. visited domain.

167

The Gory Details

• Messaging for dynamic HA assignment.

• Messaging for HA redirection.

168

Messaging for dynamic HA assignment

1) The MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR. If the MN is aware of a desired HA address, it can add that address in the Requested HA Extension in the Registration Request.

2) The MN sets the Home Agent address field in the Registration Request to the HA address (instead of

setting it to ALL-ZERO-ONE-ADDR). The MN also adds the same HA address in the Requested HA Extension in the Registration Request.

3) The MN sends the Registration Request to the "Requested HA". If the Requested HA Extension is

present, Requested HA is specified in the "HA Address" of this extension. The FA forwards the Registration Request to the address in the HA field of the Request.

4) The "Requested HA" is the home agent that processes the Registration Request. It creates mobility binding for successful Registration Request. It also sends a Registration Reply to the MN.

5) The MN obtains an "Assigned HA" address from the HA field in the successful Registration Reply

and uses it for the remainder of the session. (Note that the "Assigned HA" will be same as the "Requested HA").

6) Subsequent Registration Request messages for renewal are sent to the Assigned HA.

169

Messaging for dynamic HA assignment

MN FA Requested/Assigned

1

43

2

5

170

Messaging for HA redirection

1. The MN sets the Home Agent address field in the Registration Request to ALL-ZERO-ONE-ADDR.

2. The MN sends the Registration Request to the "Requested HA". If the MN

is aware of an HA address, it can add that address in the Requested HA Extension in Registration Request.

3. When the HA receives the Registration Request, if the HA field is set to ALL-ZERO-ONE-ADDR,

the HA may reject the request with Reply code REDIRECT-HA-REQ and suggest an alternate HA. If the HA rejects the Request, the HA field in the Reply is set to this HAs address. The IP address of the HA that is the target of the redirection is specified in Redirected HA Extension.The presence of this extension is mandatory when the reply code is set to REDIRECT-HA-REQ. HA sends the Reply to the FA/MN.

4. FA sends the Reply to the MN. 5. If the error code is set to REDIRECT-HA-REQ, MN obtains the HA address from Redirected HA

Extension. The MN then sends a Registration Request to Redirected HA. The MN may choose to add Requested HA extension in this new Registration Request.

171

Messaging for HA redirection

MN FA Requested/Assigned Redirected HA

1

43

2

5

172

What if the mobile node is not aware of desired HA Address

• This is solved by the presence of an AAA server.

173

Advantages Dynamic Home Agent Assignment

• Lower Signaling Delay.

• Automated operation of home address as well as home agent address.

• Capabilities to specify priorities.

174

Security Considerations

175

The big picture

• Mobile computers will be connected to the network via wireless links. Such links are particularly vulnerable to passive eavesdropping, active replay attacks, and other active attacks.

176

Message Authentication Codes

• Home Agents, Foreign Agent and Mobile node must be able to perform authentication.

• Default Algorithm:HMAC-MD5 with key size 128 bits.

177

Key Management

• Key distribution without Network Key Management Protocol.

• Not required for all messages between Mobile node and Home Agent.

• Commercial Environment requires authentication of all messages for billing and legitimacy purposes.

178

Picking a Good Random Number

• Strength Of an authentication mechanism depends on the following factors:

1) Innate strength of the authentication algorithm.

2) The secrecy of the key.

3) The strength of the key. Generated Randomly

179

Privacy

• Authentication not Encryption.

• Data Privacy: Use Encryption.

• Location Privacy: Use Tunneling.

180

Replay Protection for Registration Requests

181

Replay Protection for Registration Requests

• Two methods for generating the Identification field:

1) Timestamps (mandatory)

2) “Nonces” (optional)• Low order 32-bits copied from registration

request to Registration reply for matching purposes.

182

Timestamps

• Generating node inserts current time of day.• Receiving node checks the timestamp to calculate the

difference.• Synchronized time of day clocks.• Synchronization of clocks must also be authenticated.• NTP is a protocol designed to synchronize the clocks of

computers over a network. • Lower order 32 bits are filled from the timestamp.• Higher order 32 bits are filled randomly.

184

“Nonces”

• Source node “A” generates a new random number and expects the destination node “B” to return the same number in the reply and vice versa.

• Most use authentication code to protect against alteration.

185

Intersting Link:http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html

186

Thank You

187

[RP1994] Reynolds, J., Postel J., “Assigned Numbers” STD 2, RFC 1700, October 1994.

[COM2000] Comer, Douglas, “Mobile IP” in Internetworking with TCP/IP, Vol 1, ed. Prentice Hall, New Jersey, 2000, p. 377-386

[KOR2002] Körpeoğlu, Ibrahim, http://www.cs.bilkent.edu.tr/~korpe/courses/cs515-fall2002 , 2002.

[PER2002] Perkins, Ed., “IP Mobility Support for IPv4”, RFC 3344, August 2002.[PIL2004] Pillai, Krish, Lecture on “Mobile IP” as part of the class

Internetworking Protocols and Programming.

[1] C. Perkins, Ed, “IP Mobility Support for IPv4”, RFC 3344, August 2002

[2] K. El Malki (editor), “Low Latency Handoffs in Mobile IPv4”,draft-ietf-mobileip-lowlatency-handoffs-v4-07.txt, October 2003.

[3] Nat Natarajan, “Support of Layer 2 Triggers for Faster Handoffs”, IEEE802.20-3-107.pdf

[4] C. Blondiaa, O. Casalsb, Ll. Cerdàb, N. Van den Wijngaerta, G. Willemsa, P. De Cleyna, “Performance Comparison of Low Latency Mobile IP schemes” [HLK2002] Harte, Lawrence, Levine, Richard, Kikta, Roman, “Handoff” in

3G Wireless Demystified, ed. McGraw-Hill, New York, 2002, p 50.

http://www.cs.bilkent.edu.tr/~korpe/courses/cs515-fall2002

alvaro agudelo alexander tucker wael kdouh suresh srinivasan

Documents