07Mar_Kandirakis

7/28/2019 07Mar_Kandirakis

1/121

NAVAL

POSTGRADUATESCHOOL

MONTEREY, CALIFORNIA

THESIS

Approved for public release; distribution is unlimited

ROUTE OPTIMIZATION FOR MOBILE IPV6 USING THE

RETURN ROUTABILITY PROCEDURE: TEST BED

IMPLEMENTATION AND SECURITY ANALYSIS

by

I oanni s Kandi r aki s

Mar ch 2007

Thesi s Advi sor : Geof f r ey Xi eSecond Reader : J ohn Ful p


2/121

THI S PAGE I NTENTI ONALLY LEFT BLANK


3/121

i

REPORT DOCUMENTATION PAGE Form Approved OMB No. 0704-0188

Publ i c r epor t i ng bur den f or t hi s col l ect i on of i nf or mat i on i s esti mat ed to aver age 1 hour perr esponse, i ncl udi ng t he t i me for r evi ewi ng i nst r ucti on, sear chi ng exi st i ng data sour ces, gat her i ngand mai ntai ni ng t he dat a needed, and compl et i ng and r evi ewi ng t he col l ect i on of i nf ormati on. Sendcomment s r egardi ng thi s bur den est i mate or any ot her aspect of t hi s col l ect i on of i nf ormati on,i ncl udi ng suggesti ons f or r educi ng t hi s bur den, t o Washi ngt on headquart ers Ser vi ces, Di r ector ate

f or I nfor mati on Operat i ons and Report s, 1215 J ef f erson Davi s Hi ghway, Sui t e 1204, Ar l i ngt on, VA22202- 4302, and t o t he Of f i ce of Management and Budget , Paperwork Reduct i on Pr oj ect ( 0704- 0188)Washi ngt on DC 20503.

1. AGENCY USE ONLY (Leave blank) 2. REPORT DATEMar ch 2007

3. REPORT TYPE AND DATES COVEREDMaster s Thesi s

4. TITLE AND SUBTITLE: Rout e Opt i mi zat i on f or Mobi l eI Pv6 Usi ng t he Retur n Rout abi l i t y Pr ocedur e: Test BedI mpl ement at i on and Securi t y Anal ysi s

6. AUTHOR I oanni s Kandi r aki s

5. FUNDING NUMBERS

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

Naval Post graduat e SchoolMonter ey, CA 93943- 5000

8. PERFORMING ORGANIZATION

REPORT NUMBER

9. SPONSORING /MONITORING AGENCY NAME(S) AND ADDRESS(ES)

Hel l eni c Navy General St af f

At hens, Gr eece

10. SPONSORING/MONITORING

AGENCY REPORT NUMBER

11. SUPPLEMENTARY NOTES The vi ews expressed i n t hi s t hesi s are t hose of t he aut hor and do notr ef l ect t he of f i ci al pol i cy or posi t i on of t he Depart ment of Def ense or t he U. S. Government .

12a. DISTRIBUTION / AVAILABILITY STATEMENTApproved for publ i c rel ease; di str i but i on i s unl i mi t ed

12b. DISTRIBUTION CODE

13. ABSTRACT

Mobi l e I Pv6 i s an I P- l ayer mobi l i t y pr ot ocol t hat i s desi gned t o pr ovi de mobi l i t ysuppor t , al l owi ng an I Pv6 node t o ar bi t r ar i l y change i t s l ocat i on on t he I Pv6 I nt er netand st i l l mai nt ai n exi st i ng connect i ons by handl i ng t he change of addr esses at t heI nt er net l ayer usi ng Mobi l e I Pv6 messages, opt i ons, and pr ocesses t hat ensur e thecor r ect del i ver y of dat a r egar dl ess of t he mobi l e node' s l ocat i on. Ret ur n Rout abi l i t yi s an i nf r ast r uct ur el ess, l i ght wei ght pr ocedur e t hat enabl es a mobi l e I Pv6 node t or equest another I Pv6 node (maybe unaware of mobi l i t y) t o test t he ownershi p of i t sper manent I Pv6 addr ess i n both i t s home network and i t s t empor ary address i n t hecur r ent I Pv6 network; and aut hori zes a bi ndi ng pr ocedur e by t he use of a crypt ogr aphi ct oken exchange.

The mai n obj ect i ve of t hi s r esear ch ef f or t i s t o bui l d a t est bed f ori nvest i gat i ng t he vul ner abi l i t i es of t he Mobi l e I Pv6 RR pr ocedur e. The test bed shal lf aci l i t at e t he enact ment and anal ysi s of t he ef f ect s of speci f i c threat s on t he hostsand t he net wor k. Whi l e thi s t hesi s i s not about di scover i ng new vul ner abi l i t i es oreval uati ng count ermeasur es, t he resul t i ng t est bed and sof t ware shal l l ay t he necessar ygr oundwor k f or f ut ur e r esear ch i n those di r ect i ons.

15. NUMBER OF

PAGES121

14. SUBJECT TERMS Mobi l e I Pv6, Ret ur n Rout abi l i t y Pr ocedur e, TestBed, Secur i t y, MI PL 2. 0. 2, SUSE LI NUX 10. 1

16. PRICE CODE

17. SECURITY

CLASSIFICATION OF

REPORTUncl assi f i ed

18. SECURITY

CLASSIFICATION OF THIS

PAGE

Uncl assi f i ed

19. SECURITY

CLASSIFICATION OF

ABSTRACT

Uncl assi f i ed

20. LIMITATION OF

ABSTRACT

UL

NSN 7540- 01- 280-5500 St andar d Form 298 ( Rev. 2-89)Prescr i bed by ANSI Std. 239- 18


4/121

i i



5/121

i i i

Approved for public release; distribution is unlimited

ROUTE OPTIMIZATION FOR MOBILE IPV6 USING THE RETURN

ROUTABILITY PROCEDURE: TEST BED IMPLEMENTATION AND SECURITY

ANALYSIS

I oanni s Kandi r aki sLi eut enant , Hel l eni c Navy

B. S. , Hel l eni c Naval Academy, 1993

Submi t t ed i n par t i al f ul f i l l ment of t her equi r ement s f or t he degr ee of

MASTER OF SCIENCE IN COMPUTER SCIENCE

f romthe

NAVAL POSTGRADUATE SCHOOL

March 2007

Aut hor : I oanni s Kandi r aki s

Appr oved by: Geof f r ey Xi eThesi s Advi sor

J ohn Ful pSecond Reader

Pet er J . Denni ngChai r man, Depar t ment of Comput er Sci ence


6/121

i v



7/121

v

ABSTRACT

Mobi l e I Pv6 i s an I P- l ayer mobi l i t y pr ot ocol t hat i s

desi gned t o pr ovi de mobi l i t y suppor t , al l owi ng an I Pv6 node

t o ar bi t r ar i l y change i t s l ocat i on on t he I Pv6 I nt er net and

st i l l mai nt ai n exi st i ng connect i ons by handl i ng t he change

of addr esses at t he I nt er net l ayer usi ng Mobi l e I Pv6

messages, opt i ons, and pr ocesses t hat ensure t he corr ect

del i ver y of dat a r egar dl ess of t he mobi l e node' s l ocat i on.

Ret ur n Rout abi l i t y i s an i nf r ast r uct ur el ess, l i ght wei ght

pr ocedur e t hat enabl es a mobi l e I Pv6 node t o request

another I Pv6 node (maybe unaware of mobi l i t y) t o t est t he

owner shi p of i t s per manent I Pv6 addr ess i n both i t s home

net wor k and i t s t empor ar y addr ess i n t he cur r ent I Pv6

net work; and aut hor i zes a bi ndi ng pr ocedur e by t he use of a

cr ypt ogr aphi c t oken exchange.

The mai n obj ect i ve of t hi s r esear ch ef f or t i s t o bui l d

a t est bed f or i nvest i gat i ng t he vul ner abi l i t i es of t he

Mobi l e I Pv6 RR pr ocedur e. The t est bed shal l f aci l i t at e t he

enact ment and anal ysi s of t he ef f ect s of speci f i c t hr eat s

on t he host s and t he net wor k. Whi l e t hi s t hesi s i s not

about di scover i ng new vul ner abi l i t i es or eval uat i ng

count er measur es, t he r esul t i ng t est bed and sof t war e shal l

l ay the necessar y gr oundwor k f or f ut ur e r esear ch i n t hose

di r ecti ons.


8/121

vi



9/121

vi i

TABLE OF CONTENTS

I. INTRODUCTION ............................................1A. OBJECTIVE ..........................................2B. RESEARCH QUESTIONS .................................3C. ORGANIZATION .......................................3

II. BACKGROUND ..............................................5A. THE NEED FOR TRANSITION TO IPV6 ....................5B. IP MOBILITY ........................................7C. MOBILE IPV6 TERMINOLOGY ............................8D. MOBILE IPV6 .......................................10E. BASIC MOBILE IPV6 PROCESS-TUNNELING MODE ..........11F. OVERVIEW OF RETURN ROUTABILITY (RR) PROCEDURE .....14G. PRIOR EVALUATIONS OF MIPV6 PROTOCOL ...............22

III.MIPV6 TEST BED CONFIGURATION ...........................29A. PUBLISHED IMPLEMENTATIONS OF MIPV6 ................29B. CHOOSING MIPV6 SOFTWARE ...........................31C. TEST BED DESCRIPTION ..............................32

1. Test Bed Layout Description ..................322. Configure-Patch-Build and Install the MIPv6

Kernel at HA, MN and CN ......................353. Setup of HA, MN, CN, and routers .............45

a. HA ......................................45b. MN ......................................47c. CN ......................................48d. CNrouter ................................48e. Frouter .................................49

D. VERIFYING THE CONFIGURATION .......................491. Scenario without the Use of IPsec ............50

a. Phase 1: MN Is At Its Home Network ......50b. Phase 2: MN Moves to a Foreign Network ..56c. Phase 3: MN Returns to its Home Network .63

2. Scenario with the Use of IPsec ...............63IV. SECURITY ISSUES OF MOBILE IPV6 .........................71

A. IDENTIFIED SECURITY THREATS AND MIPV6 PROTOCOLDEFENCE ...........................................71

B. TEST BED SECURITY OBSERVATIONS ....................73C. ATTACK TRAFFIC GENERATION WITH SCAPY6 .............73D. WORK IN PROGRESS FOR SECURING THE ROUTE

OPTIMIZATION PROCEDURE FOR MOBILE IPV6 ............74V. CONCLUSIONS AND FUTURE WORK ............................77

A. CONCLUSIONS .......................................77B. FUTURE WORK .......................................78


10/121

vi i i

APPENDIX A. CONFIGURATION FILES OF HA ......................81APPENDIX B. CONFIGURATION FILES OF MN ......................87APPENDIX C. CONFIGURATION FILES OF CNROUTER ................89APPENDIX D. CONFIGURATION FILES OF FROUTER .................91APPENDIX E. CONFIGURATION FILES OF CNROUTER ................93APPENDIX F. USING SCAPY6 FOR CONSTRUCTING A BU MESSAGE .....97LIST OF REFERENCES .........................................101INITIAL DISTRIBUTION LIST ..................................105


11/121

i x

LIST OF FIGURES

Fi gur e 1. Bi di r ect i onal Tunnel i ng of Mobi l e I Pv6. . . . . . . . . . 13Fi gur e 2. Ti mi ng Di agr am and Message For mat of RR

Pr ocedur e. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Fi gur e 3. Physi cal Layout of MI Pv6 Test bed. . . . . . . . . . . . . . . 34Fi gur e 4. Runni ng Out put of HA mi p6d when MN i s at Home

Net wor k. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Fi gur e 5. Runni ng Out put of MN mi p6d when MN i s at Home

Net wor k. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Fi gur e 6. Runni ng Out put MN i f conf i g when MN i s at Home

Net wor k. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Fi gur e 7. Runni ng Out put CN mi p6d when MN i s at Home

Net wor k. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Fi gur e 8. MN Kernel I P Rout i ng Tabl e bef or e MN Movement . . . 55Fi gur e 9.

MN Moved t o For ei gn Net wor k 2005: : / 64. . . . . . . . . . . 56

Fi gur e 10. i f conf i g of MN moved t o t he For ei gn Net wor k. . . . . 57Fi gur e 11. Vi r t ual Ter mi nal I nf or mat i on Pr ovi ded by HA. . . . . 58Fi gur e 12. Vi r t ual Ter mi nal I nf or mat i on Pr ovi ded by MN. . . . . 59Fi gur e 13. MN Kernel I P Rout i ng Tabl e af t er Movement t o

For ei gn Net wor k. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Fi gur e 14. HOTI Message f rom MN t o CN. . . . . . . . . . . . . . . . . . . . . . 60Fi gur e 15. COTI Message f r om MN ( CoA) t o CN. . . . . . . . . . . . . . . . 60Fi gur e 16. HOT Message f r om CN t o CN ( HoA) . . . . . . . . . . . . . . . . . 61Fi gur e 17. COT Message f r om CN t o MN ( CoA) . . . . . . . . . . . . . . . . . 61Fi gur e 18. BU Message f r om MN( CoA) t o CN. . . . . . . . . . . . . . . . . . . 62Fi gur e 19. BA Message f r om CN t o MN( CoA) . . . . . . . . . . . . . . . . . . . 62Fi gur e 20. HA Vi r t ual Termi nal Out put . . . . . . . . . . . . . . . . . . . . . . 63Fi gur e 21. MN SPD Out put bef or e MN Moves t o t he Forei gn

Net wor k. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Fi gur e 22. MN SPD Out put af t er MN Moves t o t he For ei gn

Net wor k. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Fi gur e 23. Et her eal Screen Capt ur e of RR Pr ocedur e. . . . . . . . . 69


12/121

x



13/121

xi

LIST OF TABLES

Tabl e 1. Har dwar e Char act er i st i cs of MI Pv6 Test bedComponent s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Tabl e 2. Test Bed I P and MAC Addr esses. . . . . . . . . . . . . . . . . . . 35Tabl e 3. Tabl e of Mobi l i t y Header Types. . . . . . . . . . . . . . . . . . 50Tabl e 4. Poss i bl e Threat s and Def ense Mechani sms

provi ded by t he RR Prot ocol . . . . . . . . . . . . . . . . . . . . . 73


14/121

xi i



15/121

xi i i

ACKNOWLEDGMENTS

Ther e ar e l ot s of peopl e I woul d l i ke t o t hank f or a

huge var i et y of r easons.

I woul d l i ke t o thank t he Hel l eni c Navy f or pr ovi di ng

t he opport uni t y t o pur sue my st udi es at t he Naval

Post gr aduate School .

I am deepl y i ndebt ed t o my advi sor s Prof . Geof f r ey Xi e

and Pr of . J ohn Ful p f or t hei r ment or i ng, i nspi r at i on and

support t hr oughout t hi s work. Wi t hout t hei r common- sense,

knowl edge and percept i veness I woul d never have f i ni shed.I woul d al so l i ke t o t hank al l t he r est of t he

Academi c St af f of t he Naval Post gr aduate School and

especi al l y t he Depart ment of Comput er Sci ence f or t he

knowl edge t hat t hey pr ovi ded me wi t h a hi gh sense of

r esponsi bi l i t y.

The great est acknowl edgement I r eser ve f or my f ami l y,

my wi f e Fi l i o and my son Fi l i ppos, who endur ed t hi s l ongpr ocess wi t h me, al ways of f er i ng suppor t , l ove and

pat i ence.

I dedi cat e t hi s t hesi s t o my bel oved f at her whom I

l ost dur i ng my st udi es i n NPS and he wi l l never have t he

chance t o see my di pl oma.


16/121

xi v



17/121

1

I. INTRODUCTION

Mobi l e I Pv6 ( MI Pv6) i s a net wor k l ayer pr ot ocol f or

enabl i ng mobi l i t y i n I Pv6 net wor ks. I P mobi l i t y t echnol ogy

has gai ned a si gni f i cant amount of t r act i on over t he l ast

f ew year s, mai nl y due t o t he f ol l owi ng f act or s [ Sol i man04] :

I ncr easi ng dependence of soci et y on i nf or mat i onand t he need t o access i t f r om any pl ace and anyt i me

Wi de spr ead depl oyment of hi gh- speed wi r el essnet works.

Emergence of 3G wi r el ess networks t hat suppor t

packet dat a servi ces.

Af f or dabl e mobi l e devi ces t hat ar emul t i f unct i onal and capabl e of ser vi ces t hat gobeyond j ust voi ce and SMS

I ncl usi on of I P st acks i n PDAs, mobi l e phones andpor t abl e PCs.

Mobi l e I Pv6 i s t he net wor k l ayer pr ot ocol devel oped t o

r epl ace mobi l e I Pv4. I Pv6 has a l ar ger addr ess space and i s

expect ed t o i mprove net wor k per f or mance and net wor k

secur i t y over t hat of I Pv4. The i nt ended i mpr ovement s

i ncl ude bot h enhancement s of exi st i ng I Pv4 f unct i onal i t i es

and new f eat ur es. Most of t he f ormer cat egory of

i mprovement s have been t est ed and anal yzed dur i ng t he

oper at i onal per i od of I Pv4; t he new f eat ur es; however , have

not been equal l y t est ed. Some of t hem st i l l have not been

i ncorporated i nt o popul ar oper at i ng syst ems, and some exi st

onl y as RFC speci f i cat i ons, wi t h no act ual i mpl ement at i on.

One of t he new f eat ur es of Mobi l e I Pv6 i s t he Ret ur n

Rout abi l i t y ( RR) pr ocedur e, an i nf r ast r uct ur el ess sol ut i on

t o achi eve Rout i ng Opt i mi zat i on and avoi d r out i ng

t r i angl es.


18/121

2

Thi s procedure i s t he subj ect of ser i ous di scussi ons

concer ni ng i t s secur i t y i mpl i cat i ons. Sever al pr obl ems have

been i dent i f i ed, and sol ut i ons have been pr oposed

[ J ohnson04] . A syst emat i c i mpl ement at i on and anal ysi s i n a

l abor at or y envi r onment of t he pot ent i al t hr eat s t o t he

host s and t he net work, dur i ng t he execut i on of t he RR

pr ocess, wi l l hel p i n t he eval uat i on of t he pr oposed

sol ut i ons and i n r esear ch f or new ones. Such anal ysi s,

t oget her wi t h t he t ool s t o gat her t he dat a t o suppor t t hat

anal ysi s, i s t he f ocus of t hi s t hesi s.

A. OBJECTIVE

The mai n obj ect i ve of t hi s r esear ch ef f or t i s t o bui l d

a t est bed f or i nvest i gat i ng t he vul ner abi l i t i es of t he

Mobi l e I Pv6 RR pr ocedur e. The t est bed shal l f aci l i t at e t he

enact ment and anal ysi s of t he ef f ect s of speci f i c t hr eat s

on t he host s and t he net wor k. The thr eat s shal l be

i mpl ement ed i n sof t ware and val i dated usi ng t he test bed.

Whi l e t hi s t hesi s i s not about di scover i ng new

vul ner abi l i t i es or eval uat i ng count er measur es, t her esul t i ng t est bed and sof t war e shal l l ay t he necessary

gr oundwor k f or f ut ur e r esear ch i n t hose di r ect i ons. Thus,

t he f ol l owi ng t asks wi l l be accompl i shed.

1. I dent i f y known secur i t y i ssues wi t h t he pr oposedMobi l e I Pv6 RR pr ocedur e.

2. Conf i gur e a sui t e of hardware component s t oi nvest i gat e t he suscept i bi l i t y of t heaut oconf i gur at i on pr ot ocol t o t he sel ect ed r i sks.

3. I mpl ement at t acks agai nst t he t est bed and assesst he per f ormance of t he pr ot ocol i n t he pr esenceof mal i ci ous acti vi t y.


19/121

3

B. RESEARCH QUESTIONS

Thi s t hesi s i nvest i gat es t he f ol l owi ng speci f i c

i ssues.

1. Ar e t her e any OSs t hat support t he pr oposed

secur i t y f unct i ons of MI Pv6, and i f t her e ar e, t owhi ch ext ent ?

2. How do t he components of t he MI Pv6 secur e t hei rcommuni cat i on?

3. What ar e t he possi bl e t hr eat s t o secur ecommuni cat i on bet ween t he mobi l e I Pv6 nodes?

4. What are t he suggest ed sol ut i ons?

5. Ar e t her e any known expl oi t s of t hevul ner abi l i t i es of t he MI Pv6?

6. Ar e t her e any pr oposed t hr eat mi t i gat i onsol ut i ons, and i f so, what ar e t hey?

C. ORGANIZATION

Thi s t hesi s i s or gani zed as f ol l ows.

Chapt er I pr ovi des and i nt r oduct i on t o t he t hesi s and

t he r udi ment s of t he Mobi l e I Pv6 pr otocol .

Chapt er I I pr esent s t he need f or t r ansi t i on t o I Pv6,

t he benef i t s of I P Mobi l i t y, and pr ovi des an over vi ew oft he Mobi l e I Pv6 pr ot ocol . I n addi t i on, i t descri bes t he RR

procedure and t he assumpt i ons made f or t he desi gn

i mpl ement at i on of t he MI Pv6 pr ot ocol . I t i s i nt ended t o be

a hi gh- l evel descri pt i on t hat wi l l i nt r oduce t he MI Pv6

t ermi nol ogy and hel p t he r eader comprehend how t he MI Pv6

pr otocol and i t s RR pr ocedur e work.

Chapt er I I I pr esent s t he l ayout and conf i gur at i onpr ocess of t he i mpl ement ed MI Pv6 t est bed. A ver y l i mi t ed

number of publ i shed host oper at i ng syst ems ar e adver t i sed

t o have suppor t f or MI Pv6. Wor se, al l t he avai l abl e MI Pv6

capabl e OS r el eases ar e exper i ment al i n nat ur e and st i l l

goi ng t hr ough r i gor ous val i dat i on t est s. As such, a


20/121

4

si gni f i cant amount of ef f or t f or t hi s t hesi s was spent

determi ni ng a worki ng combi nat i on of OS versi on and MI Pv6

ext ensi on i n a t r i al and er r or manner . The exper i ence i s

document ed i n t hi s chapt er . Thi s chapt er i s i nt ended t o

pr ovi de suf f i ci ent det ai l s so t hat i t can be used as a

how- t o gui de f or depl oyi ng a MI Pv6 t est bed usi ng open-

sour ce sof t ware.

An eval uat i on of t he RR pr ocedur e i s provi ded i n

Chapt er I V t hat i s based on t he exper i ment al r esul t s f r om

bot h Chapt er I I I and t he resear ch of [ Aur a06] , whi ch was

publ i shed dur i ng t hi s r esear ch.

Concl usi ons and r ecommendat i ons f or t hr eat mi t i gat i on

ar e pr esent ed i n t he f i nal chapt er , al ong wi t h suggest i ons

f or f ut ur e wor k on t he anal ysi s and eval uat i on of t he

pr oposed sol ut i ons.


21/121

5

II. BACKGROUND

Thi s chapt er br i ef l y present s t he ar gument f or

t r ansi t i on t o I Pv6, t he r udi ment s of t he I P Mobi l i t y

pr ot ocol , and t he Mobi l e I Pv6 pr ot ocol i n par t i cul ar .

Fi nal l y, i t descr i bes t he RR pr ocedur e and t he assumpt i ons

made f or t he desi gn i mpl ement at i on of t he MI Pv6 pr ot ocol .

I t i s i nt ended t o be a hi gh- l evel descri pt i on t hat wi l l

i nt r oduce t he Mobi l e I Pv6 t er mi nol ogy ( MI Pv6) and hel p the

r eader comprehend how t he MI Pv6 prot ocol and i t s at t endant

RR procedure wor k.

A. THE NEED FOR TRANSITION TO IPV6

The Internet Protocol ( IP) i s a dat a- or i ent ed pr ot ocol

used f or communi cat i ng dat a across a packet - swi t ched

i nt er net wor k. I P i s a net wor k l ayer pr ot ocol i n t he

i nt er net pr ot ocol sui t e and i s encapsul at ed i n a dat a l i nk

l ayer pr ot ocol ( e. g. , Et her net ) . As a l ower l ayer pr ot ocol ,

I P pr ovi des t he ser vi ce of communi cabl e uni que gl obal

addr essi ng amongst comput er s. Thi s i mpl i es t hat t he data

l i nk l ayer need not pr ovi de t hi s ser vi ce. Et her net pr ovi des

gl obal l y uni que addr esses except i t i s not gl obal l y

communi cabl e ( i . e. , t wo ar bi t r ar i l y chosen Et her net devi ces

wi l l onl y be abl e t o communi cate i f t hey ar e on the same

bus) . The di f f er ence i s t hat I P i s concer ned wi t h t he f i nal

dest i nat i on of dat a packet s. Et her net i s concer ned wi t h

onl y t he next devi ce ( comput er , r out er , et c. ) i n t he chai n.

The f i nal dest i nat i on and next devi ce coul d be one and t he

same ( i f t hey ar e on t he same bus) , but t he f i nal

dest i nat i on coul d be on t he ot her si de of t he wor l d

[ ht t p: / / en. wi ki pedi a. or g/ wi ki / I nt er net _Pr ot ocol Last

vi si t ed on Febr uar y 2, 2007] .


22/121

6

The cur r ent ver si on of t he I P prot ocol ( I Pv4) has not

changed a l ot si nce RFC 791, whi ch was publ i shed i n 1981.

I t i s common bel i ef t hat I Pv4 served us wel l f or over 25

year s and st i l l does.

However , t he i ni t i al desi gn of I Pv4 di d not ant i ci pat e

cont emporary i ssues such as [ Sol i man04] :

The exponent i al growt h of t he I nt er net and t hei mpendi ng exhaust i on of t he I Pv4 addr ess space.

The need f or si mpl er and mor e aut omat i cconf i gur at i on of addr esses and ot her set t i ngst hat do not necessar i l y r el y on t headmi ni st r at i on of a DHCP i nf r ast r uct ur e.

The r equi r ement f or secur i t y at t he I P l evel .

The need f or bet t er suppor t f or r eal - t i medel i ver y of dat a.

The emer gence of I P- capabl e mobi l e devi ces.

The need of soci et y t o access i nf or mat i on f r omany pl ace and at any t i me.

To addr ess not onl y t hese, but al so many pr oposed

met hods f or i mpr ovi ng I Pv4, t he I ETF has devel oped a sui t e

of pr otocol s and st andar ds known as I P ver si on 6 ( I Pv6)wi t h t he f ol l owi ng f eat ur es [ Davi es02] :

New header f or mat

Larger addr ess space

Ef f i ci ent and hi er ar chi cal addr essi ng and r out i ngi nf r astr uct ur e

St at el ess and st at ef ul addr ess aut o conf i gur at i on

Bui l t - i n secur i t y

Bet t er suppor t f or qual i t y of ser vi ce ( QoS)

A new pr ot ocol f or nei ghbor i ng node i nt er act i on

Ext ens i bi l i t y

I n addi t i on, t he i nt er nal s of t he I Pv6 pr ot ocol have

been desi gned wi t h scal abi l i t y and ext ensi bi l i t y i n mi nd.


23/121

7

Thi s wi l l al l ow many di f f er ent ki nds of devi ces besi des

PCs, l i ke cel l phones and home appl i ances, t o mor e easi l y

j oi n t he I nt er net i n f ut ure

[ ht t p: / / wi r el ess. about . com/ od/ net wor kpr ot ocol si p/ g/ bl def _i p

v6. ht m Last vi si t ed on Febr uar y 5, 2007] .

B. IP MOBILITY

I P Mobi l i t y i s def i ned as t he change i n a node s I P

addr ess due to t he f ol l owi ng r easons:

Change of i t s at t achment poi nt wi t hi n t heI nt er net t opol ogy.

Change i n t he t opol ogy i t sel f , whi ch causes a

node t o change i t s addr ess.Mobi l i t y i s consi der ed t o be an i mpor t ant i ssue, and

t he need f or an I P mobi l i t y management sol ut i on i s

mot i vat ed by t he f ol l owi ng [ Sol i man04] :

Users woul d l i ke t o have t he choi ce of usi ngcer t ai n t echnol ogi es over ot her s.

Host s need t o be r eachabl e i ndependent l y of t hei rnor mal ( home) physi cal or i gi n.

Mobi l e I Pv6 i s desi gned t o handl e t he mobi l i t y managementon t he I P l ayer f or t he emer gi ng I Pv6 pr ot ocol .

The sol ut i on t o I P mobi l i t y i s t he Mobi l e I P prot ocol ,

desi gned to al l ow mobi l e devi ce users t o move f r om one

net wor k to anot her whi l e mai nt ai ni ng r eachabi l i t y vi a t hei r

permanent / home I P addr ess. Def i ned i n RFC 2002, Mobi l e I P

i s an enhancement of t he I nt er net Pr ot ocol ( I P) t hat adds

mechani sms f or f or war di ng I nt er net t r af f i c t o mobi l e

devi ces ( known as mobi l e nodes) when t hey ar e connect i ng

t hr ough ot her t han thei r home network.

[ ht t p: / / sear chmobi l ecomput i ng. t echt ar get . com/ sDef i ni t i on/ 0,

, si d40_gci 849848, 00. ht ml Last vi si t ed on Febr uar y 5, 2007]


24/121

8

C. MOBILE IPV6 TERMINOLOGY

I n or der f or t he r eader t o bet t er under st and t he

descr i pt i on of t he MI Pv6 pr ot ocol and t he RR pr ocedur e, i t s

concomi t ant t ermi nol ogy and message t r ansact i ons ar e

pr esent ed i n t hi s sect i on:

Home link: The home l i nk i s t he l i nk t hat i s assi gned

t he home subnet pref i x. The mobi l e node uses t he home

subnet pr ef i x to creat e a home addr ess.

Home Address (HA): A uni cast r out abl e addr ess assi gned

t o a mobi l e node, used as t he permanent addr ess of t he

mobi l e node. Thi s addr ess i s wi t hi n t he mobi l e node' s home

l i nk. St andar d I P r out i ng mechani sms wi l l del i ver packet s

dest i ned f or a mobi l e node' s home addr ess t o i t s home l i nk.

Mobi l e nodes can have mul t i pl e home addr esses, f or i nst ance

when t here ar e mul t i pl e home pr ef i xes on t he home l i nk.

Home Agent (HA): The home agent i s a r out er on t he

home l i nk t hat mai nt ai ns an awareness of t he mobi l e nodes

of i t s home l i nk t hat are away f r om home and t he addr esses

t hat t hey ar e cur r ent l y usi ng. I f a mobi l e node i s on t he

home l i nk, t he home agent act s as a nor mal I Pv6 r out er ,

f or war di ng packet s addr essed t o the mobi l e node. I f t he

mobi l e node i s away f r om home, t he home agent t unnel s dat a

sent t o t he mobi l e node' s home addr ess t o t he mobi l e node' s

cur r ent ( r emot e) l ocat i on on t he I Pv6 I nt er net .

Mobile node (MN): A mobi l e node i s an I Pv6 node t hat

can change l i nks/ net works, and t her ef ore addr esses, and yetcont i nue t o mai nt ai n r eachabi l i t y usi ng i t s home addr ess. A

mobi l e node has awareness of i t s home addr ess and the


25/121

9

gl obal addr ess of i t s cur r ent l i nk addr ess, and i ndi cat es

i t s home address t o t he home agent and I Pv6 nodes wi t h

whi ch i t i s communi cat i ng.

Foreign link: A f or ei gn l i nk i s a l i nk t hat i s not t he

mobi l e node' s home l i nk. A f or ei gn l i nk i s assi gned a

f or ei gn subnet pr ef i x.

Care-of Address (CoA): t he t empor ar y, net wor k- speci f i c

I P addr ess f or r out i ng messages t o t he mobi l e node s

cur r ent l ocat i on. The associ at i on of a car e- of addr ess wi t h

a home addr ess f or a mobi l e node i s known as a bi ndi ng.

Cor r espondent nodes and home agent s keep i nf or mat i on on

bi ndi ngs i n a bi ndi ng cache.

Correspondent Node (CN): A cor r espondent node i s an

I Pv6 node t hat i s capabl e of communi cat i ng wi t h a mobi l e

node whi l e i t i s away f r om home. A CN can al so be a mobi l e

node.

Cookie: r andom number used by a mobi l e node used t o

prevent spoof i ng by a bogus CN i n the RR procedure.

Care-of init cookie: a cooki e sent t o t he CN i n t he

Car e- of Test I ni t message, t o be ret ur ned i n t he Car e- of

Test message.

Home init cookie: a cooki e sent t o t he CN i n t he Home

Test I ni t message, t o be r et urned i n t he Home Test message.

Keygen Token: a number suppl i ed by a CN i n t he RR

procedure t o enabl e t he MN t o comput e t he necessary bi ndi ngmanagement key f or aut hor i zi ng a BU.

Nonces: r andom number s used i nt er nal l y by t he CN i n

t he cr eat i on of keygen t okens r el ated t o t he RR pr ocedur e.


26/121

10

Binding management key (Kbm): Key used f or aut hor i zi ng

a bi ndi ng cache management message ( e. g. , BU and BACK

messages) .

Binding Update (BU): Used by a mobi l e node to not i f y

ot her nodes of a new care- of addr ess. I t can al so be used

t o del et e ol d bi ndi ngs.

Binding Acknowledgement (BA): Used t o acknowl edge

r ecei pt of a Bi ndi ng Updat e.

Binding Refresh Request (BRR): Used by t he CN t o

i nf or m t he mobi l e node t hat t he bi ndi ng i s ( or i s goi ng)

stal e.

Binding Error (BE): I t i sused by t he CN t o si gnal an

error.

D. MOBILE IPV6

Mobi l e I Pv6 gr ew out of exper i ences wi t h Mobi l e I Pv4;

i t sel f an at t empt t o enabl e I P at t ached devi ces t o mi gr at e

between physi cal networks wi t hout havi ng t o change the

publ i cl y vi si bl e I P addr ess by whi ch t hey wer e uni quel y

known t o the r est of t he I nt er net .

When a node moves f r om one access net wor k t o anot her

or swi t ches bet ween access t echnol ogi es, i t acqui r es a new

I Pv6 addr ess and cannot be reached di r ect l y vi a i t s ol d

I Pv6 addr ess due t o i t s r out er s i ngr ess f i l t er i ng. Thi s

i mpl i es t hat al l cur r ent communi cat i ons ( f or exampl e

st r eami ng vi deo f r om t he I nt er net or a TCP sessi on) ar est opped and wi l l have t o be r est ar t ed by t he user or t he

appl i cat i on.


27/121

11

The Mobi l e I Pv6 prot ocol ( RFC 3775) has been def i ned

t o addr ess t hose i ssues and al l ow t he node t o be al ways

r eachabl e at t he same I Pv6 addr ess what ever t he access

net wor k i t uses. I t al l ows t he host t o move t r anspar ent l y

f or t he appl i cat i ons and t he user s, wi t hout t he need t o

r eset al l t he cur r ent connect i ons each t i me t he host moves

t o anot her access network.

I t s desi gn ai ms t o sol ve t wo pr obl ems:

To al l ow t r anspor t l ayer sess i ons ( TCPconnect i ons and UDP- based t r ansact i ons) t ocont i nue even i f t he host ( s) move and changet hei r I P addr esses.

To al l ow a node t o be r eached t hrough a st at i c I Paddr ess; t hat i s, a home ( of ) addr ess ( HoA) .

E. BASIC MOBILE IPV6 PROCESS-TUNNELING MODE

The basi c i dea i n Mobi l e I Pv6 i s t o al l ow a home agent

( HA) t o work as a st at i onary pr oxy f or a mobi l e node ( MN) .

Whenever t he mobi l e node i s away f r om i t s home network, t he

home agent i nt ercept s packet s dest i ned t o t he node and

f or war ds t he packet s by t unnel i ng t hem t o t he node' scur r ent addr ess, t he car e- of addr ess ( CoA) . The t r anspor t

l ayer ( e. g. , TCP, UDP) uses t he home addr ess as a

st at i onar y i dent i f i er f or t he mobi l e node.

Wi t h Mobi l e I Pv6, a host has t wo addr esses whi l e

movi ng i n t he I nt ernet t opol ogy: one per manent addr ess t hat

i dent i f i es t he host , and t he ot her r epr esent i ng t he

l ocat i on i n t he I nt er net t opol ogy. The Mobi l e I Pv6 pr ot ocol

t akes car e of t he bi ndi ng between t hese t wo addr esses

( t hanks t o a Home Agent ) , and ensures t hat t he host i s

al ways r eachabl e at i t s per manent addr ess even i f i t moves

i n t he I nt er net t opol ogy.


28/121

12

Mobi l e I Pv6 adopt s a new st r ategy f or secur i ng a MN

t hat r oams ar ound t he I nt ernet . A MN needs t o keep get t i ng

new l ocal I P addr esses ( CoA) and keep hi s HA i nf ormed t hat

he' s moved and where he has gone.

Ther e ar e t wo possi bl e modes f or communi cat i ons

bet ween t he mobi l e node and a CN i n MI Pv6. The f i r st mode,

bi di r ect i onal t unnel i ng, does not r equi r e Mobi l e I Pv6

suppor t f r om t he CN and i s avai l abl e even i f t he mobi l e

node has not r egi st er ed i t s cur r ent bi ndi ng wi t h t he CN.

Packets f r om t he CN are rout ed t o t he home agent and then

t unnel ed t o t he mobi l e node. Packet s t o t he CN are t unnel ed

f r om t he mobi l e node to t he home agent ( " r ever se t unnel ed" )

and then r out ed normal l y f r om t he home network t o t he CN.

The r oami ng devi ce i s aut hent i cat ed t hrough i t s home

addr ess, and al l communi cat i ons t o t hat devi ce pass t hr ough

t he home addr ess bef ore bei ng sent t o t he t emporary

l ocat i on ( CoA) .

Bi di r ecti onal t unnel i ng i s responsi bl e f or t r i angl e

r out i ng. Tr i angl e rout i ng may i ncur unnecessary l at ency,whi ch i s not desi r abl e f or r eal t i me t r af f i c such as VoI P.

Al so i t i mpact s on r el i abi l i t y si nce a l onger dat a pat h i s

mor e l i kel y t o br eak due t o a l i nk f ai l ur e.

I n a nut shel l , t he bi di r ecti onal t unnel i ng i s

descr i bed by t he f ol l owi ng st eps:

1. The MN uses i t s HoA when i t i s i n i t s homenet wor k. A dat agr am sent f r om CN t o MN, wi l l be

sent t o MN s HA.

2. HA del i ver s t he datagr am t o MN at i t s HoA.

3. MN moves t o a vi si t i ng network and acqui r es at empor ar y I P addr ess, CoA f r om t he agent ( l ocalr out er ) of t he vi si t i ng net wor k.

4. The MN r egi st er s i t s CoA t o i t s HA.


29/121

13

5. The CN sends a dat agram t o t he MN, unawar e i f i ti s i n i t s home net wor k, t o t he onl y addr ess t hati t can r each t he MN, i t s HoA.

6. The HA f or war ds t he dat agram t o MN, at i t s CoA.

7. The MN sends dat agrams t o CN, t unnel i ng t hemt hr ough i t s HA due t o i ngr ess f i l t er i ng.

The above procedure i s i l l ust r at ed i n Fi gur e 1 bel ow.

Fi gur e 1. Bi di r ect i onal Tunnel i ng of Mobi l e I Pv6

Thi s i s t he basi c mode of f unct i on of Mobi l e I Pv6 i n

absence of any opt i mi zat i on and i s cal l ed t r i angl e r out i ng

because ever y message bet ween MN and CN has t o r out e vi a

t he MN s Home Agent .

Tr i angl e r out i ng may cr eat e del ays, caused by a l ong

t r i p t i me t hat af f ect s r eal t i me t r af f i c such as VoI P.

Al so, i t i mpact s on r el i abi l i t y si nce t he l onger pat h may

have br oken l i nks.

Correspondent Node

( 4)

( 5)MN ati t s HoA

HA

MN away f r omi t s homenet work

( 1)( 2)

( 6)

( 3)

( 7b)

( 7a)


30/121

14

Rout e opt i mi zat i on i s an opt i onal f eat ur e of Mobi l e

I Pv6 t hat el i mi nat es t r i angl e r out i ng. I t i s a mode of

oper at i on t hat al l ows t he mobi l e node and i t s peer , a CN,

t o exchange packet s di r ect l y, bypassi ng t he home agent

compl et el y af t er t he i ni t i al set up phase.

When r out e opt i mi zat i on i s used, t he mobi l e node sends

i t s cur r ent car e- of addr ess t o t he CN, usi ng bi ndi ng updat e

( BU) messages. The CN st or es t he bi ndi ng bet ween t he home

addr ess and care- of addr ess i nt o i t s Bi ndi ng Cache. One way

t o achi eve rout e opt i mi zat i on i s t he i mpl ement at i on of t he

RR pr ocedur e, an i nf r ast r uct ur el ess sol ut i on i n whi ch t he

MN r equest s t he CN t o t est i t s ownershi p of t he HoA and CoA

and aut hor i zes a bi ndi ng pr ocedur e by t he use of a

cr ypt ogr aphi c t oken exchange.

F. OVERVIEW OF RETURN ROUTABILITY (RR) PROCEDURE

Mobi l e I Pv6 Rout e Opt i mi zat i on ver i f i es a mobi l e

node' s aut hent i ci t y t hr ough a r out i ng pr oper t y. H. Sol i man

i n Chapt er 5 of hi s book, [ Sol i man04] , descr i bes t he Ret ur n

Rout abi l i t y ( RR) pr ocedur e wi t h gr eat det ai l . The essence

of t he RR pr ocedur e i s t hat t he MN r equest s t hat t he CN

t est i t s owner shi p of i t s HoA and CoA. Thi s i s done by

sendi ng two i ndependent messages: t he Home address Test

I ni t ( HOTI ) and Car e- Of addr ess Test I ni t ( COTI ) . The CN

cr eates t wo t okens t hat onl y t he CN can cr eate ( encr ypt

wi t h a secret key Kcn that i s known onl y t o CN) and sends

one token t o each address ( home and care- of addr esses) i nt wo separ at e messages: HOme Test ( HOT) and Car e- Of Test

( COT) .


31/121

15

The mobi l e node uses bot h of t hese t okens t o cr eat e a

key ( Kbm) t hat can be used t o aut hent i cat e a bi ndi ng updat e

message t o the CN. Si nce t he CN knows al l t he i nf ormat i on

needed t o pr oduce t he key, i t can r epr oduce i t when t he

bi ndi ng updat e i s r ecei ved, and so aut hent i cat e t he

message. The same key i s used t o aut hent i cat e t he bi ndi ng

acknowl edgment .

The HOTI message i s sent by t he mobi l e node t o r equest

a test of t he home addr ess. The sour ce addr ess used i n t he

I Pv6 header i s t he mobi l e node s home addr ess and t he

dest i nat i on i s t he CN s addr ess. Hence, t hi s message has t o

be t unnel ed t o t he home agent ( si nce t he home addr ess i s

not t opol ogi cal l y cor r ect i n t he vi si t ed net wor k) , whi ch

decapsul at es t he message and f orwards i t t o the CN. The

HOTI message i s t r anspor t ed i nsi de a mobi l i t y header t ype

1. Thi s message cont ai ns a cooki e ( cal l ed home i ni t cooki e)

generat ed by t he mobi l e node and l at er r etur ned by t he CN.

The cooki e i s a r andom number t hat has no si gni f i cance; i t

i s i ncl uded t o ensur e t hat t he ent i t y r espondi ng t o t he

HOTI message has act ual l y recei ved i t . Thi s message i s

prot ect ed on t he mobi l e nodehome agent pat h by ESP i n

t unnel mode.

The home agent ver i f i es t he ESP header and f or war ds

t he i nt ernal message to t he CN. I n t hi s case t he home agent

i s not pr ovi ded wi t h a home addr ess opt i on i n t he out er

header ( unl i ke t he bi ndi ng update message) t o use i n or der

t o l ocat e t he r i ght secur i t y associ at i on i n t he SAD. I n

t hi s scenar i o, t he home agent s SPD i s conf i gur ed t o t r eat

t he mobi l e node s care- of addr ess as a secur i t y gat eway

addr ess. The i mpl i cat i on of t hi s conf i gur at i on i s t hat t he

home agent can associ at e a secur i t y associ at i on ent r y i n


32/121

16

t he SAD wi t h a speci f i c tunnel i nt er f ace, i dent i f i ed by t he

mobi l e node s care- of addr ess. Hence, t he home agent wi l l

be abl e t o i dent i f y t he secur i t y associ at i on based on t he

i nt er f ace f r om whi ch i t was r ecei ved. Thi s message ( and t he

HOT message) i s t r eat ed di f f er ent l y by not i ncl udi ng t he

home addr ess opt i on. The reason i s t hat t he bi ndi ng update

i s sent bef or e est abl i shi ng t he t unnel . Ther ef or e, no

t unnel i nt er f ace can be used t o i dent i f y the secur i t y

associ at i on.

Al most si mul t aneousl y, t he mobi l e node can send a COTI

message. The COTI message i s sent f r om t he mobi l e node s

car e- of addr ess di r ect l y t o t he CN. I t i s t r anspor t ed i n a

mobi l i t y header t ype 2. The message cont ai ns anot her r andom

cooki e ( cal l ed car e- of i ni t cooki e) . The COTI cooki e i s a

r andom number used t o ensure that t he r esponder t o a COTI

message has act ual l y recei ved t he or i gi nal ( COTI ) message.

When t he CN r ecei ves t he HOTI message, i t gener at es a

64- bi t home keygen t oken ( t he t oken generat ed i s based on

t he home addr ess) . The home keygen t oken i s gener at ed byt aki ng t he f i r st 64 bi t s of t he out put of a message

aut hent i cat i on code f unct i on usi ng Kcn and i s t hen comput ed

on t he concat enat i on of t he home addr ess and a nonce

generat ed by t he CN as f ol l ows:

Home keygen token = First (64, HMAC_SHA1(Kcn, home

address|nonce|0))

wher e Fi r st( n, j ) r epr esent s the f i r st n bi t s i n j .

HMAC_SHA1(Kcn, i nf o) means a hashed message aut hent i cat i on

code ( or a keyed hash) based on t he SHA1 hash al gor i t hm and

uses Kcn t o key t he f unct i on, whi ch oper at es on i nf o. The 0

i s used to di st i ngui sh t he home keygen token f r om t he car e-

of keygen t oken, shown l ater .


33/121

17

The CN t hen const r uct s a HOT message and sends i t t o

t he mobi l e node. Thi s message cont ai ns t he home i ni t cooki e

or i gi nal l y sent by t he mobi l e node and the home keygen

t oken. Si nce the CN gener at es nonces f r equent l y, i t needs

t o be aware of t he nonce used t o gener ate a part i cul ar

cooki e. Nonces ar e st or ed i n an i ndexed l i st . Ther ef or e, a

CN onl y needs t o know t he i ndex cor r espondi ng t o a

par t i cul ar nonce to be abl e to generat e t he home keygen

t oken agai n. The nonce i ndex i s i ncl uded i n t he HOT

message. Thi s wi l l be needed l ater by t he CN t o

aut hent i cat e t he bi ndi ng updat e.

The message wi l l be i nt er cept ed by t he home agent and

t unnel ed t o t he mobi l e node s care- of addr ess. A secur e

t unnel ( ESP) i s used t o f or war d t hi s message to t he mobi l e

node.

A si mi l ar oper at i on i s done when t he CN r ecei ves t he

COTI message. I t generat es a care- of keygen t oken, where

Care-of keygen token = First(64, MAC (Kcn, care-of address

|nonce|1))The nonce used i n t hi s oper at i on mi ght not be t he same

nonce used t o cr eat e a home keygen token, dependi ng on when

t he COTI message was r ecei ved ( t he CN mi ght have generat ed

a new nonce) . Ther ef ore, t he nonce i ndex shoul d be sent t o

t he mobi l e node i n t he COT message.

Thi s message concl udes t he RR procedure. At t hi s

poi nt , t he CN has not yet st ored any more i nf ormat i on t hani t had at t he begi nni ng of t hi s pr ocedur e: Kcn and an

i ndexed l i st of nonces. The CN st ores nei t her t he home

keygen t oken nor t he car e- of keygen t oken. When needed,

t hese t okens can be regener ated, gi ven the nonce i ndi ces

or i gi nal l y used t o gener at e t hem.


34/121

18

Af t er r ecei vi ng t he HOT ( t unnel ed f r om t he home agent )

and t he COT message, t he mobi l e node i s i n a posi t i on t o

gener at e a bi ndi ng management key, Kbm. Thi s i s done as

f ol l ows:

Kbm = SHA1 (home keygen token|care-of keygen token)

The mobi l e node can now const r uct t he mobi l i t y header

used f or t he bi ndi ng updat e message. The mobi l i t y header

i ncl udes t he bi ndi ng updat e, a nonce i ndi ces opt i on, and a

bi ndi ng aut hor i zat i on dat a opt i on. The nonce i ndi ces opt i on

cont ai ns t he two i ndi ces r ecei ved i n t he HOT and COT

messages.

The aut hent i cat i on dat a ar e cal cul at ed as f ol l ows:

Auth_data = First (96, MAC(Kbm, Mobility_data)

wher e

Mobility_data = care-of address| final dst| Mobility header

data

The mobi l i t y header dat a i ncl udes t he cont ent of t he

mobi l i t y header wi t h t he except i on of t he aut hor i zat i on

dat a opt i on i t sel f . The f i nal dest i nat i on i s t he packet s

f i nal dest i nat i on, t hat i s, t he CN s addr ess. I f t he CN

were al so a mobi l e node, a rout i ng header t ype 2

( cont ai ni ng i t s home addr ess) woul d be i ncl uded i n t he

packet . Si nce t he r out i ng header i s pr ocessed bef or e t he

mobi l i t y header , t he f i nal dst f i el d shoul d cont ai n t hat

CN s home address.

Si nce t he CN does not keep st at e f or any mobi l e nodes

dur i ng t he RR procedur e, t he mobi l e node needs t o i ncl ude

i t s home and care- of addr esses i n t he bi ndi ng update. The

home addr ess i s i ncl uded i n a home addr ess opt i on ( i n a


35/121

19

dest i nat i on opt i ons extensi on header ) , whi ch pr ecedes t he

mobi l i t y header . I f t he car e- of addr ess wer e di f f er ent f r om

t he packet s sour ce addr ess, i t shoul d be i ncl uded i n t he

al t er nat e- car e- of addr ess opt i on; ot her wi se, t he packet s

sour ce addr ess i s assumed t o be t he care- of addr ess. I n any

case, t he care- of addr ess shoul d al ways be t he one used i n

t he sour ce addr ess f i el d of t he COTI message; other wi se,

t he wr ong care- of keygen t oken wi l l be used t o generat e Kbm

when t he bi ndi ng updat e i s r ecei ved at t he CN.

Af t er t he bi ndi ng updat e message i s const r uct ed, t he

mobi l e node sends i t t o t he CN.

When t he CN r ecei ves t he bi ndi ng updat e, i t l ooks i nt o

t he nonce i ndi ces opt i on and f i nds t he cor r espondi ng

nonces. The CN wi l l be abl e to regener at e Kbm as f ol l ows:

1. Generat e home keygen t oken: Fi r st ( 64, MAC ( Kcn,home addr ess| nonce| 0) ) . The home address i st aken f r om t he home addr ess opt i on.

2. Gener at e car e- of keygen t oken: Fi r st ( 64, MAC( Kcn, car e- of addr ess| nonce| 1) ) . The car e- ofaddr ess i s t aken f r om t he al t er nat e car e- ofaddr ess opt i on when pr esent ; ot her wi se, t hesour ce addr ess i s used.

3. Gener at e Kbm: Hash ( home keygen t oken| car e- ofkeygen t oken) .

4. Cal cul at e Aut h_dat a: Fi r st ( 96, MAC( Kbm,Mobi l i t y_dat a) .

5. I f Aut h_dat a i s equal t o t he cont ent of t hebi ndi ng aut hor i zat i on dat a opt i on, accept t hebi ndi ng update.

I f an acknowl edgment i s r equest ed, t he CN must send abi ndi ng acknowl edgment . The bi ndi ng acknowl edgment shoul d

al so cont ai n t he bi ndi ng aut hor i zat i on dat a opt i on.

The bi ndi ng r ef r esh advi ce opt i on i nf or ms t he mobi l e

node about t he t i me when a new bi ndi ng updat e i s needed.


36/121

20

The advant age of t he RR procedure i s t hat i t i s

l i ght wei ght and does not r equi r e pr e- shar ed aut hent i cat i on

mat er i al . I t al so r equi r es no st at e at t he CN. On t he ot her

hand, t he t wo r eachabi l i t y t est s can l ead t o a handof f

del ay unaccept abl e f or many r eal t i me or i nt er act i ve

appl i cat i ons such as Voi ce over I P (VoI P) and vi deo

conf er enci ng. Al so, t he secur i t y t hat t he Ret ur n-

Rout abi l i t y pr ocedur e guar ant ees mi ght not be suf f i ci ent

f or secur i t y- sensi t i ve appl i cat i ons. And f i nal l y,

per i odi cal l y r ef r eshi ng a r egi st r at i on at a CN i mpl i es a

hi dden si gnal i ng over head t hat may pr event mobi l e nodes

f r om hi ber nat i on dur i ng t i mes of i nact i vi t y [Ar kko06] .


37/121

21

Fi gur e 2. Ti mi ngDi agr am and Message Format of RR Procedure

Ti me Di agr am and Messages For mat of RR

MN CN

HA1: HOTI : Home i ni t cooki e1

2: COTI : Care- of i ni t cooki e2

3: HOTI

5: HOT4: COT

6: HOT

7: BU

8: BA

HOTHome nonce1 i ndexHome i ni t cooki e1Home keygent oken=Fi r st ( 64,HMAC_SHA1 (Kcn,( homeaddr ess| nonce| 0) ) )

COTCare- of nonce2 i ndexCare of i ni t cooki e2Care of keygen token

Fi rst (64,HMAC_SHA1 (Kcn,( care of addr ess |nonce | 1) ) )

kbm = SHA1(home keygen token | care- ofkeygen t oken)

BU: HMAC_SHA1( kbm, ( CoA| CNA | BU) )

Auth_data=Fi r st ( 96, MAC( Kbm, Mobi l i t y_dat a)

Mobility_data=CoA| f i nal dest | mobi l i t yheader dat a

CN generat es a r andom key Kcnonce and nonces r egul ar l y

1, 3: MN gener at es a home i ni tcooki e1 and sends i t t o the CNt hrough HA2: MN generat es a car e- of i ni tcooki e2 and sends i t di r ect l yt o t he CN4: CN r epl i es t o COTI sendi ng amessage COT t o t he MN5, 6: CN r epl i es t o HOTI sendi nga message HOT t o t he MNt hrough HA7: BU mess age8: BA mess age

1. HOTII Pv6 headersrc = CoAdst = HAESP headerI Pv6 headerSr c= HoAdst = CNMobi l i t y Headert ype 1Home i ni t cooki e1

2. COTII Pv6 headerSr c= CoAdst = CNMobi l i t y Headert ype 2Care-of i ni tcooki e2

3. HOTI Pv6 headersrc = CNdst = HoAMobi l i t y Headert ype 3Home nonce1 i ndexHome i ni t cooki e1Home keygen t oken

4. COTI Pv6 headersrc = CNdst = CoAMobi l i t y Headert ype 4Care- of nonce2i ndexCare-of i ni tcooki e2Care- of keygent oken

6. BUI Pv6 headersr c = CoAdst = CNDST- opt i ons header

Home addr ess opt i onMobi l i t y header t ype 5Bi ndi ng updat eNonce i ndi ces opt i on[ opt i onal al t er nat e- CoAopt i on]Aut hor i zat i on dat a opt i on

7. BUI Pv6 headersrc: CNdst : CoARout i ng header t ype 2

mobi l e node s home addr essDST- opt i ons headerHome addr ess opt i on ( i f CN were al so a mobi l enode)Mobi l i t y header t ype 6Bi ndi ng Acknowl edgment[ opt i onal bi ndi ng r ef r esh advi ce opt i on]Aut hor i zat i on dat a opt i on


38/121

22

G. PRIOR EVALUATIONS OF MIPV6 PROTOCOL

One i mport ant base assumpt i on i s t hat t he r out i ng

pr ef i xes avai l abl e t o a node ar e det er mi ned by i t s cur r ent

l ocat i on, and t her ef or e the node must change i t s I P addr ess

as i t moves. I n cur r ent I Pv6 oper at i onal pr act i ce t he I P

addr ess pr ef i xes ar e di st r i but ed i n a hi er ar chi cal manner .

Thi s l i mi t s t he number of r out i ng t abl e ent r i es each

i ndi vi dual r out er needs t o handl e. An i mpor t ant i mpl i cat i on

i s t hat t he t opol ogy det er mi nes what gl obal l y r out abl e I P

addr esses ar e avai l abl e at a gi ven l ocat i on. That i s, t he

nodes cannot f r eel y deci de what gl obal l y r out abl e I P

addr ess t o use; t hey must r el y on t he r out i ng pr ef i xesserved by t he l ocal r out er s vi a Rout er Adver t i sement s or by

a DHCP server . I n other words, I P addr esses are j ust what

t he name says, addr esses ( i . e. , l ocat or s) [ Ni kander 05] .

Fur t her mor e, i n t he cur r ent I nt er net st r uct ur e, t he

r out er s col l ect i vel y mai nt ai n a di st r i but ed dat abase of t he

network t opol ogy and f orward each packet t owards t he

l ocat i on det er mi ned by t he dest i nat i on addr ess car r i ed i n

t he packet . To mai nt ai n t he topol ogy i nf or mat i on, t he

r out er s must t r ust each ot her , at l east t o a cer t ai n

ext ent . The r out er s l ear n t he t opol ogy i nf or mat i on f r om t he

ot her r out er s, and t hey have no opt i on but t o t r ust t hei r

nei ghbor r out er s about di st ant t opol ogy. At t he bor der s of

admi ni st r at i ve domai ns, pol i cy r ul es ar e used t o l i mi t t he

amount of per haps f aul t yr out i ng t abl e i nf ormat i on r ecei ved

f r om t he peer domai ns. Whi l e t hi s i s most l y used t o weed

out admi ni st r at i ve mi st akes, i t al so hel ps wi t h secur i t y.

The ai m i s t o mai nt ai n a r easonabl y accurat e i dea of t he

net wor k t opol ogy even i f someone i s f eedi ng f aul t y

i nf or mat i on t o t he r out i ng syst em [ Ni kander 05] .


39/121

23

I n t he Mobi l e I Pv6 secur i t y desi gn, di f f er ent

approaches were chosen f or secur i ng t he communi cat i on

between t he mobi l e node and i t s home agent and between t he

mobi l e node and i t s CNs. I n t he home agent case, i t was

assumed t hat t he mobi l e node and t he home agent know each

other t hr ough a pr i or arr angement , such as a busi ness

r el at i onshi p. I n cont r ast , i t was st r i ct l y assumed t hat t he

mobi l e node and t he CN do not need t o have any pr i or

ar r angement , t her eby al l owi ng Mobi l e I Pv6 t o f unct i on i n a

scal abl e manner wi t hout r equi r i ng any conf i gur at i on at t he

CNs [ Ni kander05] .

The Ret urn- Rout abi l i t y procedure was desi gned wi t h t he

obj ect i ve of pr ovi di ng a l evel of secur i t y that compar es t o

t hat of t oday' s non- mobi l e I nt er net . As such, i t pr ot ect s

agai nst i mper sonat i on, deni al of ser vi ce, and r edi r ect i on-

based f l oodi ng at t acks t hat woul d not be possi bl e wi t hout

Rout e Opt i mi zat i on. Thi s appr oach i s based on an assumpt i on

t hat a mobi l e I nt er net cannot become any saf er t han t he

non- mobi l e I nt er net [ Ni kander 05] .

The goal of t he cur r ent Mobi l e I Pv6 r out e opt i mi zat i on

secur i t y has been t o pr oduce a desi gn wi t h a l evel of

secur i t y cl ose t o t hat of a st at i c I Pv4- based I nt er net , and

wi t h an accept abl e cost i n t er ms of packet s, del ay, and

pr ocessi ng. The r esul t i s not what one woul d expect . I t i s

def i ni t el y not a tr adi t i onal crypt ogr aphi c pr ot ocol .

I nst ead, t he r esul t r el i es heavi l y on t he assumpt i on of an

uncor r upt ed r out i ng i nf r ast r uct ur e and bui l ds upon t he i dea

of checki ng t hat an al l eged mobi l e node i s i ndeed r eachabl e

t hr ough both i t s home addr ess and i t s care- of addr ess.

Fur t her mor e, t he l i f et i me of t he st at e creat ed at t he


40/121

24

cor r esponded nodes i s del i ber at el y rest r i ct ed t o a f ew

mi nut es, i n or der t o l i mi t t he pot ent i al t hr eat f r om t i me

shi f t i ng [ Ni kander 05] .

Mor eover , gi ven t he t ypi cal l y l i mi t ed bandwi dt h i n a

wi r el ess medi um, r esour ces ought t o be spent i n an economi c

mat t er . Thi s i s especi al l y i mpor t ant f or t he amount of

si gnal i ng t hat a mobi l i t y pr ot ocol r equi r es [ Ar kko06] .

Addi t i onal l y, appl i cat i ons t hat r equi r e a secur i t y

l evel hi gher t han what t he Ret ur n- Rout abi l i t y pr ocedur e can

pr ovi de ar e gener al l y advi sed t o use end- t o- end pr ot ect i on

such as I Psec or Tr anspor t Layer Secur i t y ( TLS) [ Ar kko06] .

RR pr otect s cer t ai n si gnal i ng messages, exchanged

bet ween a mobi l e node and i t s home agent , t hrough an

aut hent i cat ed and encr ypt ed tunnel . Thi s prevent s

unaut hor i zed nodes on t hat pat h, i ncl udi ng eavesdr opper s i n

t he mobi l e node' s wi r el ess access net wor k, f r om l i st eni ng

i n on t hese messages [ Sol i man04] .

Gi ven t hat a pr e- exi st i ng end- t o- end secur i t y

r el at i onshi p bet ween t he mobi l e node and t he CN cannot

gener al l y be assumed, t hi s pr ot ect i on exi st s onl y f or t he

mobi l e node' s s i de. I f t he CN i s i mmobi l e, t he pat h bet ween

t he home agent and t he CN r emai ns unpr ot ect ed. Thi s i s a

pat h bet ween t wo st at i onar y nodes, so al l t ypes of at t acks

t hat a vi l l ai n coul d wage on t hi s pat h ar e al r eady possi bl e

i n t he non- mobi l e I nt er net . I n case t he CN i s mobi l e, i t

has i t s own home agent , and onl y t he pat h bet ween the t wo

( st at i onary) home agent s r emai ns unpr otect ed [Ar kko06] .

RFC 3775 f ai l s t o conceal a mobi l e node' s curr ent

posi t i on as rout e- opt i mi zed packet s al ways car r y both home

and care- of addr esses. Both t he CN and a thi r d part y can


41/121

25

t her ef ore t r ack the mobi l e node' s wher eabout s. A workar ound

i s t o f al l back t o bi di r ecti onal t unnel i ng wher e l ocat i on

pr i vacy i s needed. Packet s carr yi ng t he mobi l e node' s care-

of addr ess ar e t hus onl y t r ansf er r ed bet ween t he mobi l e

node and t he home agent , where t hey can be encr ypt ed

t hr ough I Psec ESP. But even t hen, t he mobi l e node shoul d

per i odi cal l y r e- est abl i sh i t s I Psec secur i t y associ at i ons

so as t o become unt r aceabl e t hr ough i t s SPI s [ Ar kko06] .

The RR procedure i mpl i ci t l y assumes t hat t he r out i ng

i nf r ast r uctur e i s secur e and t r ust ed. Thus, i t i s

appr opr i at e t o desi gn a pr ot ocol t o secur e t he bi ndi ng

updat e as l ong as i t i s no l ess secur e t han t he under l yi ng

r out i ng i nf r ast r uct ur e. I n ot her wor ds, i f a packet i s sent

t o a par t i cul ar dest i nat i on, t he r out i ng syst em del i ver s i t

t o t hat dest i nat i on. I f an at t acker compr omi ses t he r out i ng

i nf r ast r uct ur e and manages t o cont r ol one or more r out er s,

sever al ser i ous at t acks can be l aunched i ndependent l y of RR

pr ocedur es [ Sol i man04] .

The RR procedure pr ot ect s Bi ndi ng Updat es agai nst al lat t acker s who ar e unabl e to moni t or t he pat h bet ween t he

home agent and t he CN. The procedure does not def end

agai nst at t acker s who can moni t or t hi s pat h [ Aur a06] .

Anot her assumpt i on made by RR i s t hat i t i s di f f i cul t

f or an at t acker t o be l ocat ed on t wo di f f er ent pat hs at t he

same t i me and r ecei ve bot h t okens needed to gener at e Kbm.

Thi s coul d happen i f an at t acker i s shar i ng a l i nk wi t h t heCN; he woul d be abl e t o see al l of t he RR packets,

const r uct a bi ndi ng update message, send i t t o t he CN, and

r ecei ve al l of t he CN s t r af f i c addr essed t o t he mobi l e

node. However , an at t acker does not need to go t hr ough al l

t hi s t r oubl e t o hi j ack t he CN s connect i ons wi t h t he mobi l e


42/121

26

node i f he shar es a l i nk wi t h t he CN; he can si mpl y pr etend

t o be a r out er by st eal i ng t he def aul t r out er s l i nk- l ayer

addr ess and sendi ng a f ake r out er adver t i sement t o t he CN.

Al t er nat i vel y, he can send a Nei ghbor Di scover y r edi r ect

message t o t he CN r equest i ng t hat al l i t s t r af f i c be sent

t o hi s l i nk- l ayer addr ess. Thus, an at t acker shar i ng a l i nk

wi t h t he CN can cause ser i ous har m wi t hout Mobi l e I Pv6;

t hat i s, Nei ghbor Di scover y messages are t he weakest l i nk

when an at t acker i s shar i ng a l i nk wi t h t he CN

[ Ni kander 05] .

Si nce the mai n goal of t he RR pr ocedur e i s t o ensure

t hat secur i ng r out e opt i mi zat i on does not make t hi ngs worse

t han t hey ar e i n t oday s I nt er net , t he above case can be

i gnor ed. However , i t i s wor t h not i ng t hat t hi s t ype of

at t ack wi l l become si gni f i cant as soon as a mechani sm i s

devi sed t o secur e Nei ghbor Di scover y messages. When t hi s

happens, t he RR pr ocedur e wi l l become the weakest l i nk

[ Sol i man04] .

An at t acker can be l ocat ed on t he mobi l e nodeCN pat h.I n t hi s l ocat i on, he woul d onl y be abl e t o see t he car e- of

keygen t oken, whi ch woul d not al l ow hi m t o const r uct Kbm

cor r ect l y t o st eal t he mobi l e node s t r af f i c.

The at t acker mi ght al so send a l ar ge number of HOTI

and COTI messages t o t r y t o consume t he CN s r esour ces i n a

way t hat makes i t unabl e t o pr ocess l egi t i mate r equest s

f r om r eal mobi l e nodes. The RR pr ocedur e i s desi gned t oal l ow CNs t o be pr otect ed f r om memory- exhaust i on at t acks; a

CN woul d onl y keep st ate when i t r ecei ves an aut hent i cated

bi ndi ng updat e f r om a mobi l e node. Cl ear l y, t hi s pr ocedur e

cannot pr ot ect agai nst an at t acker ai mi ng at usi ng up t he

CN s l i nk bandwi dt h by sendi ng a very l arge number of


43/121

27

HOTI / COTI messages. However , t hi s at t ack can be l aunched

wi t hout RR by si mpl y sendi ng a l arge number of bogus

messages. I t i s wort h not i ng t hough, t hat t he CN can si mpl y

deci de t o not r ecei ve any HOTI / COTI messages i f i t det ect s

t hat i t i s bei ng at t acked. That i s, t he CN can t ur n of f

r out e opt i mi zat i on; communi cat i on wi t h mobi l e nodes wi l l

st i l l t ake pl ace t hr ough the home agent [ Sol i man04] .

Moreover , i t i s assumed t hat CN i s abl e t o i mpl ement

t he RR al gor i t hm and mai nt ai n a cache of MNs.

One of t he most i mpor t ant advant ages of t he RR

pr ocedur e i s t hat i t does not r equi r e any manual

conf i gur at i on or i nf r ast r uct ur e suppor t . Thi s f eat ur e

assi st s wi t h the qui ck depl oyment of Mobi l e I Pv6 and

encour ages vendor s t o suppor t r out e opt i mi zat i on, whi ch

woul d have been much harder i f r out e opt i mi zat i on came wi t h

t he bur den of i nf r ast r uct ur e suppor t or t he unr eal i st i c

assumpt i on of manual conf i gur at i on. However , i t i s

i mpor t ant t o note t hat t hi s comes at t he cost of havi ng

weak aut hent i cat i on compared to t he more t r adi t i onalappl i cat i ons of publ i c key cr ypt ogr aphy [ Ar kko06] .


44/121

28



45/121

29

III. MIPV6 TEST BED CONFIGURATION

Thi s chapt er present s t he l ayout and conf i gurat i on

pr ocess of t he i mpl ement ed MI Pv6 t est bed. A ver y l i mi t ed

number of publ i shed host oper at i ng syst ems ar e adver t i sed

t o have suppor t f or MI Pv6. Wor se, al l t he avai l abl e MI Pv6

capabl e OS r el eases are exper i ment al i n nat ur e and yet

goi ng t hr ough r i gor ous val i dat i on t est s. As such a

si gni f i cant amount of ef f or t f or t hi s t hesi s was spent

determi ni ng a worki ng combi nat i on of OS versi on and MI Pv6

ext ensi on, i n a t r i al and er r or manner . The exper i ence i s

document ed i n t hi s chapt er .

Thi s chapt er i s i nt ended t o provi de suf f i ci ent det ai l s

so t hat i t can be used as a how- t o gui de f or depl oyi ng a

MI Pv6 test bed usi ng open- sour ce sof t ware.

A. PUBLISHED IMPLEMENTATIONS OF MIPV6

The most known i mpl ementat i ons of MI Pv6 ar e: MI PL

( Mobi l e I Pv6 f or Li nux [ ht t p: / / www. mi pl . medi apol i . com/ Last

vi si t ed on J anuar y 10, 2007] ) , KAME pr oj ect ( Mobi l e I Pv6

f or BSD based Oss [ ht t p: / / www. kame. net Last vi si t ed on

J anuar y 11, 2007] ) and USAGI ( Mobi l e I Pv6 f or Li nux based

Oss [ ht t p: / / www. l i nux- i pv6. or g/ Last vi si t ed on Febr uar y 8,

2007] ) .

Mobi l e I Pv6 f or Li nux ( MI PL) i s an i mpl ement at i on t hat

was or i gi nal l y devel oped as par t of a sof t war e pr oj ect

cour se i n t he Hel si nki Uni ver si t y of Technol ogy ( HUT) , wi t h

t he goal t o creat e a pr ot ot ype i mpl ement at i on of Mobi l e

I Pv6 f or Li nux. Af t er t he cour se, t he i mpl ement at i on was

f ur t her devel oped i n t he cont ext of t he GO/ Cor e pr oj ect at

HUT Tel ecommuni cat i ons and Mul t i medi a Lab. I t i s an open


46/121

30

sour ce i mpl ement at i on, r el eased under t he GNU GPL l i cense

and f r eel y avai l abl e t o anyone( ht t p: / / www. mobi l e-

i pv6. or g/ sof t war e/ ) . The MI PL i mpl ement at i on has been

t est ed i n i nt er oper abi l i t y and conf or mance t est i ng event s

such as t he ETSI I Pv6 Pl ugt est s and TAHI I nt er oper abi l i t y

event s.

The "KAME" and "USAGI " , proj ect s ar e wor ki ng on

r esearch and devel opment on t he i mpl ement at i on of t he I Pv6

and I Psec pr ot ocol s, whi ch operat es on BSD based OSs f or

t he "KAME" pr oj ect and on a Li nux based OS f or t he "USAGI "

pr oj ect . Accur acy of t he i mpl ement at i on i s now wi del y

accept ed and i s bei ng i ncorporat ed i nt o BSD based OSs

( Fr eeBSD, Net BSD, OpenBSD and BSD/ OS) and Li nux versi on 2. 6

f or t he pr ovi si on of an envi r onment enabl i ng t he easy use

of I Pv6 t o a l arge number of user s

[ ht t p: / / www. wi de. ad. j p/ about / r esear ch. ht ml Last vi si t ed on

J anuar y 15, 2007] .

The KAME pr oj ect was a j oi nt ef f or t of si x compani es

i n J apan t o pr ovi de a f r ee sui t e of I Pv6, I Psec, and Mobi l eI Pv6 pr ot ocol s f or BSD var i ant s. Par t i cul ar l y, a mobi l e

I Pv6 i mpl ement at i on f or t he Fr eeBSD and NetBSD pl at f orms

has been devel oped under t hi s proj ect . The code i s

i mpl ement ed as par t of t he ker nel . I n addi t i on, sever al

user space progr ams have been devel oped f or MI Pv6 cont r ol ,

f or ext r act i ng MI Pv6 st at i st i cs and f or dynami c home agent

di scover y. The i mpl ement at i on f ol l ows RFC 3775 and i ncl udes

f unct i onal i t y f or HA, MN and CN ( mandatory f or an I Pv6

i mpl ement at i on t hat cl ai ms t o be I Pv6 compl i ant ) . I t al so

suppor t s authent i cat i on of messages bet ween a MN and i t s HA

usi ng I Psec [ M. Dunmore, Fi nal MI Pv6 Support Gui de,


47/121

31

Febr uar y 8 2005, 6net ,

[ht t p: / / www. 6net . or g/ publ i cat i ons/ del i ver abl es/ D4. 1. 4. pdf

Last vi si t ed on J anuar y 15, 2007] .

The USAGI Pr oj ect ( Uni ver SAl pl ayGr ound f or I Pv6Pr oj ect ) ai ms t o pr ovi de a bet t er I Pv6 envi r onment f or

Li nux i n conj unct i on wi t h t he WI DE, KAME, and TAHI

pr oj ect s. I t i ncl udes Li nux ker nel ext ensi ons, I Pv6 r el at ed

l i br ar i es, and I Pv6 appl i cat i ons.

The TAHI proj ect [ ht t p: / / www. t ahi . or g/ Last vi s i t ed

on Febr uary 22, 2007] i s ai mi ng at pr ovi di ng a means of

hi gh- l evel ver i f i cat i on of t hese t echnol ogi es.

B. CHOOSING MIPV6 SOFTWARE

I n t he begi nni ng, t he Fr eeBSD OS devel oped by t he KAME

pr oj ect was chosen f or t he MI Pv6 t est bed. The mai n r eason

f or t hi s choi ce was t hat al l MI Pv6 f unct i onal i t y was

i ncl uded i n t he OS kernel and no pat ch was r equi r ed.

Fol l owi ng t he i nst r uct i ons f or a si mi l ar pr oj ect based on

t he 4. 9 Versi on of Fr eebSD [ Lawr ence04] and usi ng t he

cur r ent ver si on ( 6. 2) as wel l as t he det ai l ed i nst r uct i ons

of [ Bl anchet 06] i t was made an at t empt t o conf i gur e and

bui l d a MI Pv6 t est bed. However , t hi s at t empt was

unsuccessf ul . Dur i ng my resear ch, t her e wer e cont r adi ct or y

i nf or mat i on about t he compat i bi l i t y and f unct i onal i t y of

t he cur r ent ver si on wi t h t he Mobi l e I Pv6 f unct i onal i t y.

Pressed by t i me, a deci si on was made to swi t ch and use a

Li nux OS and t he MI PL i mpl ement at i on.

Speci f i cal l y, SUSE Li nux 10. 1 was used and the

exper i ence suggest ed t hat t he Li nux opt i on has sever al

advant ages over t he Fr eeBSD opt i on:


48/121

32

1. SUSE Li nux has a ver y wel l - desi gned and f ul l -f eat ur ed syst em conf i gur at i on t ool , YAST, whi chi s a compl et e cont r ol cent er f or syst emadmi ni st r at i on. SUSE Li nux pr oved t o be easy t oi nst al l and conf i gur e i t i n dept h dur i ng t he

i nst al l at i on t i me. Mor eover , Novel l , t he companybehi nd SUSE, of f er s gr eat on- l i ne t echni calsuppor t and document at i on.

2. Under Li nux whenever a sof t war e modul e was neededf or t he t est bed, t he onl y thi ng t o do was t oi nvoke YAST t o sear ch and ver i f y i f t he modul e( cal l ed package i n Li nux) was i nst al l ed or not .I f i t wasn t , a si mpl e mouse cl i ck on t he modul ewas suf f i ci ent and YAST assumed t her esponsi bi l i t y t o i nstal l , conf i gur e and r esol veal l dependenci es aut omat i cal l y.

3. The MI PL proj ect was t he most r ecent r el ease f orMI Pv6 i mpl ement at i on ( r el eased on 14 J une 2006)and f ul l y RFC 3775 compl i ant .

C. TEST BED DESCRIPTION

1. Test Bed Layout Description

The i mpl emented net wor k t est bed consi st s of f i ve

comput ers. Two of t hem assume t he r ol es of t he CN and MN

r espect i vel y. The ot her t hr ee ar e conf i gur ed as I Pv6

capabl e r out er s. PC- based sof t war e r out er i mpl ement at i on i sused i nst ead of commer ci al I Pv6 r out er s i n or der t o have

mor e f l exi bi l i t y f or t he addi t i on of new I Pv6 f eat ur es and

f i ne t uni ng of net work paramet ers such as t he r out er

adver t i sement s i nt er val s [ M. Dunmor e ( 6net ) Fi nal MI Pv6

Suppor t Gui de Febr uary 8, 2005] . Tabl e 1 present s t he mai n

har dwar e char act er i st i cs of t he PCs used.


49/121

33

Role Make/Model CPU/speed RAM size

MN DELL Opt i pl exGX620

I nt el ( R)Pent i um( R) 4

3. 40 GHz

2 GB

CN DELL Opt i pl exGX620


3. 40 GHz

2 GB

HA r out er DELLPr eci si on 340


2. 40 GHz

256 MB

Fr out er DELLPr eci si on 340


1. 8 GHz

512 MB

CNr out er DELLPr eci si on 340


2. 40 GHz

512 MB

Tabl e 1. Har dwar e Charact er i st i cs of MI Pv6 Test bedComponent s

Al l t he component s of t he network ar e connect ed vi a

Net gear dual speed hubs ( model DS104) r unni ng at 10 Mbps so

as t o f aci l i t at e packet sni f f i ng f or debuggi ng pur poses.

Handof f s bet ween net works f or t he MN ar e si mul at ed by

unpl uggi ng t he Et her net cabl e to whi ch t he MN i s curr ent l y

at t ached and r epl ace i t wi t h a cabl e f r om t he net wor k we

wi sh t o move i nt o.

Fi gur e 3 shows t he physi cal l ayout f or t he i mpl ement ed

t est bed.


50/121

34

Fi gur e 3. Physi cal Layout of MI Pv6 Test bed

The home networ k of t he mobi l e node ( MN) i s t he

2003: : / 64. The home agent ( HA) i s i nst al l ed on t he HA

r out er . The home net work of t he CN i s t he 2001: : / 64. Dur i ng

t he exper i ment s, t he MN was moved between t he home net wor k

and a f or ei gn net wor k, 2005: : / 64 whi ch i s adver t i sed by t heFrouter.

Al l syst ems r un t he boxed di st r i but i on SUSE 10. 1 as

t hei r OS wi t h Li nux ker nel 2. 6. 16. 13- 4 except t he HA, t he

MN and t he CN whi ch have been recompi l ed wi t h Li nux ker nel

2. 6. 16 pat ched wi t h t he MI Pv6- 2. 0. 2- l i nux- 2. 6. 16. pat ch t o

pr ovi de t he Mobi l e I Pv6 f eatur es. The OS and the patch wer e

downl oaded f r om

f t p: / / f t p. ker nel . or g/ pub/ l i nux/ ker nel / v2. 6/ l i nux-

2. 6. 16. t ar . bz2 and

ht t p: / / mobi l e- i pv6. or g/ sof t war e/ downl oad/ mi pv6- 2. 0. 2- l i nux-

2. 6. 16. pat ch. gz, r especti vel y.

2002: : 22002: : 1

2003: : 2

CNrouter

2003: : / 642001: : / 64

2002: : / 64 2004: : / 64

2005: : / 64

2001: : 8

2004: : 3

2003: : 1

2001: : 1 2005: : 3

MNCN

HA Frouterhub

hubhub hub

hub

2004: : 2


51/121

35

I n Tabl e 2 ar e pr esent ed t he i nt er f aces of t he

Components of t he t est bed net work al ong wi t h t hei r MAC and

I P addr esses.

Node Interface MAC IP address

HA et h0 00: 04: 75: b5: a6: 32 2003: : 2

et h1 00: 0b: db: 25: 69: 61 2004: : 2

et h2 00: 40: f 4: 5f : a9: 13 2002: : 2

MN et h0 00: 12: 3f : ae: 20: 5b 2003: : 1

CNr out er et h0 00: 0a: 5e: 00: 49: 1b 2002: : 1

et h1 00: 0b: db: 25: 73: 68 2000: : 1

et h2 00: 40: f 4: 5a: 5b: cc 2001: : 1

Fr out er et h0 00: 08: 74: 41: 5e: 3f 2004: : 3

et h1 00: 09: 5b: 0a: 5d: b3 2005: : 3

CN et h0 00: 12: 3f : ae: 21: c2 2001: : 8

Tabl e 2. Test Bed I P and MAC Addresses

2. Configure-Patch-Build and Install the MIPv6

Kernel at HA, MN and CN

For t he conf i gur at i on of t he i mpl ement ed MI Pv6 net work

component s ( HA, MN and CN) , t he f ol l owi ng excel l ent

t ut or i al s wer e used:

How To Compi l e A Ker nel - The SuSE Way, [ ht t p: / / www. howt of or ge. com/ ker nel _compi l at i on_suse

Last vi si t ed on Febr uar y 2, 2007] .

Li nux Mobi l e I Pv6 HOWTO, [ ht t p: / / gni st . or g/ ~l ar s/ doc/ Mobi l e- I Pv6-HOWTO/ Mobi l e- I Pv6- HOWTO. ht ml Last vi si t ed onFebr uary 10, 2007] .


52/121

36

Mobi l e I Pv6 Mi ni HOWTO, [ ht t p: / / www. i pt . et si . or g/ mi ni _howt o. ht m Lastvi si t ed on Febr uar y 12, 2007] .

The f i r st si t e descr i bes t he procedure of compi l i ng a

ker nel on SuSE syst ems. I t descr i bes how t o bui l d a cust omker nel usi ng t he l at est unmodi f i ed ker nel sour ces f r om

[ ht t p: / / www. ker nel . or g/ ( vani l l a ker nel ) so t hat t he user

coul d be i ndependent f r om t he ker nel s suppl i ed by hi s

di st r i but i on.

Anot her r eason f or choosi ng t hi s t ut or i al was because

i t s goal was t o bui l d a ker nel r pm package t hat coul d be

used not onl y f or i nst al l at i on of t he MI Pv6 capabl e ker nel

on t he speci f i c syst em, but al so on t he ot her SuSE syst ems

t hat ar e used i n the t est bed and demand the same

conf i gur at i on.

The t ut or i al al so shows how t o pat ch t he ker nel

sour ces i f addi t i onal f eat ur es ar e needed, l i ke t he MI Pv6

pat ch f or t he Mobi l e I Pv6 f unct i onal i t i es.

Mor e speci f i cal l y, t he f ol l owi ng st eps wer e f ol l owed

t o i nst al l and pat ch a Li nux ker nel . ( The t ut or i al pr ovi des

mor e det ai l ed scr eenshot s of t he i nst al l at i on. )

a. I nst al l ncurses-devel whi ch wi l l be needed by t he

make menuconfig command whi ch wi l l be used l at er

on:

# yast - i ncur ses- devel

b. Modi f y a f ew t ool s t hat wi l l be needed t o bui l d

t he new kernel :

# cp / usr / l i b/ r pm/ f i nd- pr ovi des. ksyms

/ usr/ l i b/ r pm/ f i nd- pr ovi des. ksyms_or i g


53/121

37

# cp / usr / l i b/ r pm/ f i nd- r equi r es. ksyms

/ usr/ l i b/ r pm/ f i nd- r equi r es. ksyms_or i g

# cp / usr / l i b/ r pm/ f i nd- suppl ement s. ksyms

/ usr / l i b/ r pm/ f i nd- suppl ement s. ksyms_or i g

c. Open each of t hese scr i pt s and r epl ace

kernel-*) is_kernel_package=1;; wi t h

kernel*) is_kernel_package=1 :

# vi / usr / l i b/ r pm/ f i nd- pr ovi des. ksyms

# vi / usr/ l i b/ r pm/ f i nd- r equi r es. ksyms

# vi / usr / l i b/ r pm/ f i nd- suppl ement s. ksyms

Next , move t o / usr / sr c i n or der t o downl oad t he

desi r ed ker nel ( 2. 6. 16) t o / usr / sr c directory.

# cd / usr/ src

d. Go t o ht t p: / / www. ker nel . or g/ and sel ect t he

desi r ed f or i nstal l at i on ker nel , i n t hi s case,

l i nux- 2. 6. 16. t ar . bz2. The Ker nel can be

downl oaded t o di r ect or y / usr / sr c l i ke t hi s: # wget ht t p: / / www. ker nel . or g/ pub/ l i nux/ ker nel / v2. 6/

l i nux- 2. 6. 16. t ar. bz2

e. Unpack t he kernel sources and cr eat e a syml i nk

linuxt o the ker nel sour ces di r ect or y:

# t ar xj f l i nux- 2. 6. 16. t ar. bz2

# l n - s l i nux- 2. 6. 16 l i nux

Check that t he l i nux i s syml i nked wi t h t he

desi r ed Ker nel :

# l s l


54/121

38

I t shoul d be seen: l i nuxl i nux- 2. 6. 16. I f t he

l i nux i s st i l l connect ed wi t h t he pr evi ous

ker nel , i mpl ement t he commands:

# rm l i nux

# l n - s l i nux- 2. 6. 16 l i nux

f . Change di r ect ory and downl oad t he pat ch f ound i n

ht t p: / / mobi l e- i pv6. or g/ sof t war e/ downl oad/ mi pv6-

2. 0. 2- l i nux- 2. 6. 16. pat ch. gz t o the Ker nel sour ce

and uncompress i t :

# cd / usr/ l ocal / src# wget ht t p: / / mobi l e- i pv6. org/ sof t ware/ downl oad/ mi pv6-

2. 0. 2- l i nux- 2. 6. 16. pat ch. gz

g. Move agai n t o / usr / sr c/ l i nux i n or der t o t est t hepat ch bef or e appl y i t :

# cd / usr/ src/ l i nux

# zcat /usr/local/src/mipv6-2.0.2-linux-2.6.16.patch.gz

| patch -p1 --dry-run

Thi s command i s j ust a t est , i t does not hi ng

t o sour ces. I f i t doesn' t show er r or s, t he

f ol l owi ng command shoul d be execut ed whi ch

actual l y appl i es t he pat ch. Don' t do i t i f t he

f i r st command shows er r or s:

# zcat /usr/local/src/mipv6-2.0.2-linux-2.6.16.patch.gz

| patch -p1


55/121

39

h. Conf i gur e The Kernel

The conf i gur at i on of t he cur r ent wor ki ng

ker nel wi l l be used as a basi s f or t he new

ker nel . The exi st i ng conf i gur at i on i s copi ed

t o / usr / s rc/ l i nux:

# make mr pr oper

# cp / boot / conf i g- `uname - r ` . / . conf i g

i . Run

# make menuconf i g

Thi s command br i ngs up t he ker nel

conf i gur at i on menu. Go t o Load an Alternate

Configuration File and choose .config ( whi ch

cont ai ns t he conf i gur at i on of t he cur r ent

wor ki ng ker nel ) as t he conf i gur at i on f i l e.

Then br owse t hrough t he ker nel conf i gurat i on

menu and make your choi ces. Make sur e t hat you

get i nsi de Networking and l oad al l t he

necessar y f unct i onal i t i es of MI Pv6. I choset hem al l . Make sur e a ker nel ver si on

i dent i f i cat i on str i ng i s speci f i ed, under

General Setup ---> ( - def aul t ) Local ver si on -

append t o ker nel r el ease ( i n my conf i gur at i on

I named i t MI Pv6) .

j . When t hi s st ep i s f i ni shed, sel ect Exit and

answer t he f ol l owi ng quest i on ( Do you wi sh to

save your new ker nel conf i gur at i on?) wi t h Yes.


56/121

40

k. I nst al l t he user space MI Pv6 t ool . Change

di r ector y ( / usr / l ocal / sr c), downl oad t he l at est

Li nux MI Pv6 sour ce code ( mi pv6- 2. 0. 2) f r om

ht t p: / / mobi l e- i pv6. or g/ sof t war e/ downl oad/ mi pv6-

2. 0. 2. t ar . gz and uncompress i t :

# cd / usr/ l ocal / src

# wget ht t p: / / mobi l e- i pv6. org/ sof t ware/ downl oad/ mi pv6-

2. 0. 2. t ar . gz

# t ar zxf v mi pv6- 2. 0. 2. t ar . gz

l . Change di r ect ory:

# cd mi pv6- 2. 0. 2

m. Conf i gur e, compi l e and i nst al l t he sour ce code

i ncl udi ng t he --enable-vt opt i on t o configure,

whi ch wi l l enabl e a vi r t ual t er mi nal l i st eni ng on

l ocal host port 7777 and can be used l ater on t o

pr ovi de wi t h hel pf ul i nf or mat i on.

# CPPFLAGS=- I / usr / sr c/ l i nux/ i ncl ude . / conf i gur e - -

enabl e- vt

# make

# make i nst al l

n. Bef or e t he ker nel i s bei ng bui l t , i t i s of vi t al

i mpor t ance t o check i f i t i s MI Pv6 r eady. Ther e

ar e t wo ways t o ver i f y i t :

The f i r st one i s t o go t o di r ect or y t hat you

have i nst al l ed t he MI Pv6 user space sour ce

code


57/121

41

# cd / usr/ l ocal / src/ mi pv6- 2. 0. 2

and execut e t he f ol l owi ng command:

# . / chkconf _ker nel . sh / usr/ src/ l i nux

I f t he r esponse i s t he f ol l owi ng:

Checki ng ker nel conf i gur at i on. . .

Us i ng / usr / src/ l i nux/ . conf i g

Al l ker nel opt i ons are as t hey shoul d.

a cor r ect conf i gur at i on has t aken pl ace.

Ot herwi se, make t he cor r ect i ons suggest ed and

cont i nue.

Anot her way to check i f t he conf i gur at i on i s

cor r ect i s t o use an edi t or

( vi , pi co, gedi t , et c) and ver i f y t hat i n t he

.config f i l e i n / user / s rc/ l i nux, t he f ol l owi ng

opt i ons have been chosen:

CONFI G_EXPERI MENTAL=y

CONFI G_SYSVI PC=y

CONFI G_PROC_FS=y

CONFI G_NET=y

CONFI G_I NET=y

CONFI G_I PV6=y

CONFI G_I PV6_MI P6=y

CONFI G_XFRM=y

CONFI G_XFRM_USER=y

CONFI G_XFRM_ENHANCEMENT=y

CONFI G_I PV6_TUNNEL=y


58/121

42

CONFI G_I PV6_ADVANCED_ROUTER=y

CONFI G_I PV6_MULTI PLE_TABLES=y

The Mobi l e Node al so needs:

CONFI G_I PV6_SUBTREES=y

CONFI G_ARPD=y

I n case t hat I PSec i s desi r ed t o be enabl ed,

i t i s al so needed:

CONFI G_I NET6_ESP=y

CONFI G_NET_KEY=y

CONFI G_NET_KEY_MI GRATE=y

o. Bui l d t he ker nel , si mpl y execut i ng t hi s command:

# make r pm

p. I nst al l The New Ker nel

Af t er t he successf ul ker nel bui l d, a src.rpm

and an rpm package have been cr eated. The

src.rpm package can be f ound i n the

/usr/src/packages/SRPMS/ di r ect or y. Ver i f y i t s name

by runni ng:

# l s - l / usr / sr c/ packages/ SRPMS/

On my syst em i t was cal l ed:

kernel-2.6.16MIPv6-1.src.rpm.

The r pm package can be f ound, dependi ng on t he

ar chi t ect ur e, i n one of t he f ol l owi ng

di r ector i es:


59/121

43

/usr/src/packages/RPMS/i386/, /usr/src/packages/RPMS/i586/,

/usr/src/packages/RPMS/i686/,

/usr/src/packages/RPMS/x86_64/, e t c . ,

On my system i t was l ocat ed i n

/usr/src/packages/RPMS/i386/, and by runni ng

# l s - l / usr / sr c/ packages/ RPMS/ i 386/

I f ound out t hat i t s name was:

kernel-2.6.16MIPv6-1.i386.rpm.

q. I nst al l t he ker nel r pm package l i ke t hi s:

# cd / usr / sr c/ packages/ RPMS/ i 386/

# r pm - i vh ker nel - 2. 6. 16MI Pv6- 1. i 386. r pm

( The cr eat ed ker nel r pm package can be

t r ansf er r ed and i nst al l ed t o ot her SuSE

syst ems wi t hout havi ng t o compi l e t he ker nel

t her e agai n. )

r . Cr eat e a r amdi sk f or t he new ker nel , because

ot her wi se t he syst em wi l l most l i kel y not boot

our new kernel :

# mki ni t r d

( Thi s command wi l l cr eate new r amdi sks f or al l

i nstal l ed ker nel s. )

s. Conf i gur e the GRUB boot l oader so t hat t he new

ker nel get s boot ed when t he syst em i s r est ar t ed.

I nst ead of modi f yi ng / boot / g

Documents

07Mar_Kandirakis