mobile ipv6 : architectures et protocolesguillaume.valadon.net/research/files/thesis.pdf · mobile...

These de Doctorat de l’Universite Paris VI

Pierre et Marie Curie

Specialite

Systemes Informatiques

presentee par

Guillaume Valadon

pour obtenir le grade de

Docteur de l’Universite Pierre et Marie Curie

Mobile IPv6 : architectures et protocoles

soutenue le 27 Juin 2008 devant le jury compose de

MM. : Eric Fleury RapporteursThomas Noel

MM. : Rui Aguiar ExaminateursHiroshi EsakiSebastien Tixeuil

M. : Serge Fdida DirecteurM. : Ryuji Wakikawa Encadrant

Remerciements

Je remercie Eric FLEURY, Professeur a l’Ecole Normale Superieure de Lyon, etThomas NOEL, Professeur a l’Universite Louis Pasteur de Strasbourg, d’avoir bienvoulu accepter la charge de rapporteurs.

Je remercie Rui AGUIAR, Professeur a l’Universite d’Aveiro au Portugal, HiroshiESAKI, Professeur a l’Universite de Tokyo au Japon, et Sebastien TIXEUIL, Professeura l’Universite Pierre et Marie Curie, d’avoir bien voulu juger ce travail.

Je remercie Serge FDIDA, Professeur a l’Universite Pierre et Marie, d’avoir bienvoulu encadrer cette these. Je tiens egalement a remercier Ryuji WAKIKAWA, desormaisChercheur chez Toyota ITC au Japon, avec qui j’ai eu l’honneur de travailler surdifferents projets lies a la mobilite comme Home Agent Migration, presente dans cettethese. Ses qualites scientifiques et humaines ont tout particulierement contribue au tresbon deroulement de mon sejour au Japon. Je remercie enfin Clemence MAGNIEN,Chargee de Recherche au CNRS, pour m’avoir apporte une aide tres precieuse dans laredaction et les multiples relectures de ce manuscrit.

Mon experience japonaise, quant a elle, n’aurait pas ete possible sans l’aide de nom-breuses personnes dont Atau TANAKA, Professeur a l’Universite de Newcastle en An-gleterre, et Kenjiro CHO, Chercheur chez Internet Initiative Japan, qui m’ont presentedifferents chercheurs japonais, et de ce fait ont activement participe aux premieresetapes de mon projet de these au Japon. Dans ce contexte, je tiens tout d’abord aremercier Hiroshi ESAKI pour m’avoir chaleureusement accueilli dans son laboratoirea l’Universite de Tokyo et finance pendant les derniers mois de mon sejour. Je remercieegalement mes collegues de Murai lab, a l’Universite de Keio, ainsi que mes colleguesd’Esaki lab, a l’Universite de Tokyo. Qu’il me soit permis de remercier separement Seii-chi YAMAMOTO pour tout le temps qu’il a passe a m’aider lors de mon installation aTokyo, ainsi que dans les differentes demarches administratives precedant mon arrivee.

J’ai egalement rencontre de nombreuses personnes durant mes deux annees au Japonqui resteront, je l’espere, des amis malgre la distance. Pele-mele, merci a Daphne,Romain, Koshiro, Lou, Marin, Martin, Mai, et Yukie. Mention speciale au master dumeilleur restaurant du monde (a Yokohama) : le teppan et la biere sont deux elementsindissociables des recherches reussies !

Finalement, je remercie Ema pour l’aide qu’elle m’a apportee avant et pendantmon sejour. Sans elle, tout aurait ete beaucoup plus complique, voire impossible. Mercide m’avoir fait decouvrir le Japon, et permis de pratiquer le peu de japonais que jeconnais !

i

Merci aux membres du bureau 720 : Laurent, Georges, Florian, et Christophe, pourleurs delires, leur aide, et leur bonne humeur. Merci aux anciens et autres dinosaures,Augustin, Julien, Chantal, et Matthieu, pour m’avoir montre la voie de la sagesse ; parceque c’est important. Merci egalement aux autres membres du labo pour les discussionsautour d’un cafe et les depannages de clopes !

Finalement, merci a ma famille, mes amis et mes relectrices. Merci aux hipss, bar-bus, zedou et autres clubers du week-end. Merci a celles et ceux qui ont eu la patienceet le courage de me supporter durant ces quatre annees. Merci egalement a celles etceux qui n’ont pas eu cette chance. Merci a celles et ceux qui ont fait un detour parTokyo. Merci a celles et ceux qui sont venus me chercher un mercredi matin a 4h30a Roissy. Merci au Limoncello et a Radio Head. Merci a ceux qui m’ont mis une redhat entre les mains par un beau dimanche de juin 98. Merci aux globotruncanides.Merci aux Urgences (et surtout bienvenue). Merci a Philibert et au Quick. Merci auxjoggings du vendredi soir. Par ordre alphabetique, sans ordre de preference, et sur unair des Berus, merci a toi : Alexis, Adeline, Arnaud, Boulette, Bozze, Carter, Ceache,Citrouille, Delphine, Emilie, Etis, Evy, Faustine, Flavie, Fred, Galipette, Gratoune,Grizz, Helene, IKR, Julio, Karim, Kat, Kinou, Kozette, Leo, Manu, Marion, Mat, Mel,Michel, Philippe, Pingouin, Pwetty, Renaud, Romain, Sail, Severine, Shai, Sly, Spyou,Thierry, troglocan, Vincent, Virginie, et Zoro. Si jamais malgre toute mon attention,je t’ai oublie (ou alors si tu es megalomane), ajoute ton nom ici :

Enfin, merci a tous ceux qui ont releve le defi d’affronter la soutenance !

ii

Resume

L’architecture de l’Internet est telle que, lorsqu’un utilisateur se deplace et changede reseau, l’adresse IP de son peripherique est modifiee, entraınant la perte des com-munications en cours. Afin de resoudre ce probleme, des protocoles de gestion de lamobilite ont ete definis pour rendre les communications insensibles aux mouvements etindependantes du reseau ou se trouve l’utilisateur. Cependant, la plupart des proposi-tions souffrent de problemes affectant leurs performances, ou bien encore leur utilisationdans l’architecture actuelle de l’Internet. Par exemple, certaines d’entre elles, commele protocole HIP, imposent que tous les peripheriques, y compris ceux qui sont fixes,implementent le protocole de mobilite. D’autres encore, tel que le protocole MobileIPv6, induisent des chemins plus longs et donc des delais de communication plus im-portants.

Ce travail de these vise a ameliorer les performances du protocole Mobile IPv6en controlant les differentes limitations induites par l’utilisation d’un routeur gerant lamobilite : le home agent. Pour ce faire, nous proposons deux approches complementairesqui tout en etant compatibles avec l’infrastructure actuelle de l’Internet, permettentde gerer la mobilite de facon transparente a la fois pour le reseau et les peripheriquesfixes. Tout d’abord, nous decrivons une nouvelle architecture distribuee de gestion dela mobilite appelee Home Agent Migration qui permet d’utiliser plusieurs home agentssimultanement. Grace a un deploiement reel, nous montrons qu’il est possible d’obtenirdes performances comparables a celles de communications n’utilisant pas Mobile IPv6.Ensuite, nous definissons formellement les proprietes des emplacements des home agentsen termes de theorie des graphes. En s’appuyant sur cette etude, nous quantifionsl’impact du protocole Mobile IPv6 sur les communications. Finalement, nous proposonsun nouvel algorithme qui permet de traiter les problematiques de deploiement de MobileIPv6 et de Home Agent Migration dans des graphes qui modelisent des reseaux decommunication.

Mots-Cles

Mobile IPv6, gestion de la mobilite, anycast, graphe, centralite

iii

Abstract

Nowadays, mobile devices, such as laptops, are commonly used to access the Internetfrom different locations during the same day. With the current Internet architecture, achange of location requires a mandatory modification of the IP address, and as a resultthe loss of ongoing communications. Under these constraints, mobility protocols weredesigned to make communications resilient to movements and location independent. Sofar, diverse mobility protocols were defined that efficiently solve mobility related issues.Unfortunately, most of them suffer from design choices that impact their performances,or make them impractical for immediate deployments. For example, some protocolsrequire that every node implements mobility support, including non-mobile ones; orcauses longer paths and higher communications delays.

In this thesis, we present two possible approaches to improving Mobile IPv6 per-formances, and to control its current shortcomings. These approaches are completelycompatible with the current networking technologies, and can be used to perform im-mediate deployments of mobility support on the Internet. We first propose Home AgentMigration, an additional mobility management plane, which distributes home agents(specific mobility routers) inside the Internet topology. Practical experiments showthat it is possible to obtain performances almost identical to communications withoutMobile IPv6. Then, we formally define the properties of home agent locations in termsof graph theory, and quantify the impact of Mobile IPv6 on communications. Finally,based on this study, we describe a new algorithm that addresses deployment issuesof Mobile IPv6 and Home Agent Migration that could be applied to any operator’snetwork.

Keywords

Mobile IPv6, mobility management, anycast, graph, betweenness centrality

v

Contents

Remerciements i

Resume iii

Abstract v

Contents vii

1 Introduction 1

1.1 Standard problems induced by Mobility . . . . . . . . . . . . . . . . . . 2

1.2 What is mobility support anyway? . . . . . . . . . . . . . . . . . . . . . 4

1.3 Approaches for Internet mobility support . . . . . . . . . . . . . . . . . 5

1.3.1 Locators and identifiers . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.2 Which identifiers? . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.3 Design constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.6 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Background on Mobile IPv6 13

2.1 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.1 Preliminary terminology . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.2 Operation of Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . 15

2.1.3 Return Routability Procedure . . . . . . . . . . . . . . . . . . . . 18

2.1.4 NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.5 Home Agent Discovery . . . . . . . . . . . . . . . . . . . . . . . . 22

vii

2.2 Protocols limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.1 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.2 Return Routability Procedure . . . . . . . . . . . . . . . . . . . . 242.2.3 NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3 Security overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3.1 Possible attacks against Mobile IPv6 . . . . . . . . . . . . . . . . 262.3.2 IPsec protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4 Standardized optimizations . . . . . . . . . . . . . . . . . . . . . . . . . 292.4.1 Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . 302.4.2 Fast Handover for Mobile IPv6 . . . . . . . . . . . . . . . . . . . 312.4.3 Multiple Care-of Address . . . . . . . . . . . . . . . . . . . . . . 32

2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3 Home Agent Migration 35

3.1 General overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.1 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.2 Typical deployments . . . . . . . . . . . . . . . . . . . . . . . . . 393.1.3 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.1.4 Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2 Practical implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2.1 Notion of Binding Cache . . . . . . . . . . . . . . . . . . . . . . . 433.2.2 Communication examples . . . . . . . . . . . . . . . . . . . . . . 433.2.3 Movements of mobile nodes . . . . . . . . . . . . . . . . . . . . . 453.2.4 Example of a typical deployment . . . . . . . . . . . . . . . . . . 463.2.5 The underlying protocol . . . . . . . . . . . . . . . . . . . . . . . 473.2.6 NEMO support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.7 Security considerations . . . . . . . . . . . . . . . . . . . . . . . . 49

3.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.3.1 Performances comparisons . . . . . . . . . . . . . . . . . . . . . . 503.3.2 Experimental results . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4 Mobile IPv6 deployments 59

4.1 Graph theory reminders . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.1.1 Preliminary definitions . . . . . . . . . . . . . . . . . . . . . . . . 604.1.2 Importance of vertices . . . . . . . . . . . . . . . . . . . . . . . . 62

viii

4.2 Networks as graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.2.1 Observing networks . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2.2 Modeling networks . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2.3 Weights on edges . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3 Home Agents locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.3.1 Impact on paths lengths . . . . . . . . . . . . . . . . . . . . . . . 66

4.3.2 Optimal locations . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.3.3 Comparison methodology . . . . . . . . . . . . . . . . . . . . . . 68

4.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.4.1 Studied networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.4.2 Relationship between the degree and the betweenness . . . . . . 72

4.4.3 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.4.4 Home Agent Migration . . . . . . . . . . . . . . . . . . . . . . . 78

4.5 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5 Conclusion 87

A Scapy: IPv6 and BPF extensions 93

A.1 Contributed extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

A.1.1 Scapy6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

A.1.2 BPF extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

A.2 Routing Header Type 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

A.2.1 In a nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

A.2.2 Advanced traceroutes . . . . . . . . . . . . . . . . . . . . . . . . 102

A.2.3 Amplification attacks . . . . . . . . . . . . . . . . . . . . . . . . 104

B Thesis’ French Version 107

B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

B.1.1 Protocoles de mobilite . . . . . . . . . . . . . . . . . . . . . . . . 110

B.1.2 Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

B.2 Mobile IPv6 et ses limitations . . . . . . . . . . . . . . . . . . . . . . . . 113

B.2.1 Fonctionnement de Mobile IPv6 . . . . . . . . . . . . . . . . . . 113

B.2.2 Limitations de Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 114

B.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

B.3 Home Agent Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

B.3.1 Apercu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

ix

B.3.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118B.3.3 Resultats experimentaux . . . . . . . . . . . . . . . . . . . . . . . 119B.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

B.4 Deploiement de Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 122B.4.1 Emplacements des home agents . . . . . . . . . . . . . . . . . . . 122B.4.2 Methodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124B.4.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125B.4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

B.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128B.5.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128B.5.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Bibliography 131

List of Figures 141

List of Tables 143

x

Chapter 1Introduction

Contents

1.1 Standard problems induced by Mobility . . . . . . . . . . . . 2

1.2 What is mobility support anyway? . . . . . . . . . . . . . . . 4

1.3 Approaches for Internet mobility support . . . . . . . . . . . 5

1.3.1 Locators and identifiers . . . . . . . . . . . . . . . . . . . . . 5

1.3.2 Which identifiers? . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.3 Design constraints . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 9

1.5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.6 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 1.1. Standard problems induced by Mobility

Since 2000, both computing and networking landscapes have drastically changed.In developed countries, networks are accessible virtually everywhere, thanks to hetero-geneous wireless technologies and computing devices that can easily fit in one’s pocketand are powerful enough to compete with desktops. Moreover these technical evolu-tions also change how we interact with the technology itself. Mobile phones are indeedentirely part of our daily life. We use them not only for work but also to communicatewith friends, access the Internet or play games. They are slowly modifying the waywe socialize with each other [80] and how we access the information: in 2006, mobiledevices in Japan represents 57%1 of all user access to the Internet. Nowadays, userscan do with their mobile phones what they would sitting in front of their desktops:exchange emails [2], access maps [6] or buy music [7]. For decades, people had beenmobile on a daily basis but they can only use technology on the go since a few years.

Another change in mobile phones usages recently took place thanks to dual-modeGSM/Wi-Fi handsets and Voice over IP (VoIP) services. In metropolitan areas, wirelessnetworks are available in diverse locations such as workplaces, cafes, parks or homes.As a consequence, the high density of Wi-Fi access points [55, 68, 67] and their widecommunication ranges allow mobile devices to detect tens of access points from thesame location while walking in the streets. Users can therefore take advantage of theirVoIP accounts by using Wi-Fi to make cheap phone calls wherever they are.

1.1 Standard problems induced by Mobility

A high density of Wi-Fi access points is however not synonym of mobility. Strictlyspeaking, a mobile device is only connected to one access point at the same time.Traditionally, if the device goes out of the access point’s range, it looses its networkconnectivity and must connect to another access point. Previous works addressed thisissue by expanding a unique network broadcast domain across several Wi-Fi accesspoints by relying on wired or wireless [17, 61] backbones.

Nevertheless, as of today, it is not possible to perform vertical handovers in orderto provide seamless voice calls between different access technologies such as Wi-Fi andHSDPA. Such handovers would for example allow a mobile phone to automaticallyswitch a phone call from a paying HSDPA link to a free Wi-Fi one when the usercomes in range of well-known Wi-Fi access points. From the Internet Protocol (IP)perspective, a handover2 occurs when a node moves from one subnetwork to another.

1owned by approximately 48 million people, according to The Japanese Ministry of Internal Affairsand Communications.

2either horizontal or vertical.

Chapter 1. Introduction 3

Technically, it currently implies a mandatory change of the node’s IP address andtherefore the termination of ongoing UDP and TCP connections. They cannot berecovered, and must be restarted using the newly acquired address. If we considerphone calls, this change of address means that the call is first stopped then restarted.As of today, handovers in Internet-like architecture are far from being easy to recoverfrom, as they must be handled either manually by the users, or independently in everysingle application.

This example intelligibly lays down the context of mobility support on the Internetas well as technical constraints that it must deal with. We list the main categories ofsuch constraints below.

1. Change of IP address

Due to the Internet routing and addressing architectures, a node’s IP addressmust correspond to its physical location at all times. Otherwise it is not able toreceive and send IP packets to its correspondents. Consequently, a node cannotuse the same address everywhere it goes, and must obtain a new address when itjoins a new subnetwork.

2. Connection losses

The most popular transport protocols (TCP and UDP) were not designed tohandle changes of IP address. As a result, ongoing communications stop workingafter a movement. Similarly, applications need to implement mechanisms to auto-matically recover from connection losses. However, most applications do not havesuch mechanisms and, in practice, users must manually restart lost connections.

3. End-to-end communications

The recent arrival of Voice over IP makes the first move towards the come backof real end-to-end communications. Today, client/server communications prevailand close to zero application makes use of end-to-end communications. Eventhough some applications3 are able to establish direct communications in NetworkAddress Traversal (NAT) environments, they cannot be considered as pure end-to-end communications as a third party is necessary to punch holes into NAT [51]. Ina mobility context, end-to-end communications represent an important technicalchallenge, as they must survive both changes of IP address and connection losses.

So far, various protocols [93, 91, 83, 94, 74, 100, 20] were defined at the InternetEngineering Task Force (IETF) to provide mobility support to mobile nodes and to

3such as Skype.

4 1.2. What is mobility support anyway?

solve problems such as previously described. This thesis focuses on the Mobile IPv6protocol [66], described in Section 1.4, which aims at achieving immediate deploymentsof mobility services over the Internet through incremental upgrades of its current ar-chitecture. This thesis proposes solutions to improve the performance of Mobile IPv6and solve its various limitations. It specifically concentrates on the IPv6 protocol thatmakes up a favorable environment for mobility with the disappearance of NAT, anda flat addressing space. Unless stated otherwise, this manuscript will only discussIPv6 [41, 18], therefore terms such as IP address or IP must be interpreted as IPv6address and IPv6.

1.2 What is mobility support anyway?

With mobile phones technologies, such as GSM [118], users keep the same phone num-ber, a unique identifier, when they move or even travel to a different country; theycan be reached whatever their locations. Handovers are appropriately supported: voicecalls are not stopped during or after movements. Using these technologies as a ref-erence, mobility can be interpreted as the capacity to move easily and freely withoutimpacting the ongoing communications.

Accordingly from an end-user perspective, being mobile is being able to move adevice around while seamlessly accessing the communication network with no modi-fication to the device applications nor configurations. This implies that every devicemust be uniquely and permanently identified independently of its physical location.

From the network architecture point of view, an address is required to deliver datafrom, and to users. On the Internet, as described in Section 1.1, when a node moves,its IP address changes. Because, the address is strongly linked to the node’s physicallocation and the subnetwork it is connected to, it is called a locator. Providing mobilitysupport on the Internet is therefore offering a permanent identifier to a mobile device4

along with a temporary locator which can change over time, and defining mechanismsto store and retrieve the binding between identifiers and locators.

Nowadays, many research works try to address mobility support on the Internet:they range from local to Internet scopes, are implemented at the transport or networklevel, or target modifications of end-nodes or the infrastructure. Their application timelines are also different: some research aim at providing near future deployments [66],while other ones require heavy changes to the current Internet architecture [49] thatwill not be possible until several tens of years. In the remainder of this chapter, we

4also referred as a mobile node.


will first provide a deeper analysis of requirements to support mobility on the Internet.Then, we will briefly present our work to improve the performance of the Mobile IPv6protocol.

1.3 Approaches for Internet mobility support

In this section, we summarize the issues and technical choices that arise while designingmobility protocols for the Internet. Our goal is to describe the common requirementsof Internet mobility support and briefly present typical mobility protocols as well astheir design constraints.

1.3.1 Locators and identifiers

As previously discussed, the primary property of a mobility protocol is to give both anidentifier and a locator to mobile nodes; two elements that describe a node’s identityand its physical location. However, in order to make mobility protocols complete, theremust be some mechanisms to map a locator to an identifier, and retrieve a locatorgiven its corresponding identifier. For example, in a phone book, people’s names arethe identifiers and phone numbers are the locators that change over time as peoplemove to new residences. In order to make a phone call to a friend, a user can look upinto a phone book and find the corresponding phone number. If it changes, the usercan look up into an updated phone book and find its friends new phone number. Fromthe network perspective, this metaphor brings several problematic questions that affectmobility protocols design.

1. What are identifiers and locators exactly?

Phone numbers; IPv6 addresses; domain names; people names?

2. How is the mapping performed?

In mobile nodes; with an external database; in a peer-to-peer fashion; by pushingonly the mapping to well-known correspondents?

3. When does a correspondent choose to retrieve the mapping?

Each time it needs to communicate with the mobile node; at fixed time interval;with a cache that uses a timer to make entries expire; never?

On the Internet, the addressing and routing architectures strongly constrain thelocation of a node. An IPv6 address belonging to an IPv6 prefix allocated to a French

6 1.3. Approaches for Internet mobility support

Names Protocols

Domain names DNS

ID HIP, SCTP

IP addresses MIPv6, LISP, NETLMM

Table 1.1: Identifiers examples

Internet Service Provider cannot be used to receive packets in Japan. Consequently,the current Internet architecture makes it impossible to keep the same address whena node moves. This problem is linked to the dual function of the IP address. First, itimplicitly provides the position of a node on the globe (the locator). Then, it uniquelyidentifies the node in the whole Internet topology (the identifier). As a consequence,mobility protocols simply rely on the Internet routing architecture to ensure the deliveryof mobile nodes packets, and use IP addresses as mobile nodes locators. The differentprotocols will therefore compete in the way they provide permanent identifiers andefficient mapping mechanisms.

1.3.2 Which identifiers?

The elements used as identifiers are deeply related to the design of mobility protocols.As listed in Table 1.1, several possibilities to supply permanent identifiers are avail-able. For example, if we consider domain names as the identifier, we can define anelementary application-based mobility protocol as follows. Every time a mobile nodejoins a new subnetwork, it updates its DNS Resource Record [82] with its newly ac-quired IPv6 address. This could be easily implemented with virtually no modificationto correspondents or mobile nodes, and will work on the current Internet. However,this protocol presents drawbacks as ongoing connections are lost after handovers, andas correspondents must access the DNS server frequently to retrieve the most recentIP address.

On the other hand, HIP [83] and SCTP [91, 104] are designed as new transport5

protocols implemented in both mobile and correspondent nodes. Connections in theseprotocols are able to survive to a handover by automatically notifying correspondentsof a change of IP address: ongoing connections can therefore be used after a movement.

5although HIP is often referred as a layer 3.5 protocol.


From the application perspective, packet losses put aside, handovers have no impact.These protocols allow both end-nodes to move inside the Internet topology. However,they require all applications to be modified so as to benefit from their mobility support:HIP and SCTP sockets are not compatible with regular TCP and UDP ones.

Finally with mobility protocols that use IPv6 addresses as identifiers, such as MobileIPv6, LISP (Locator/ID Separation Protocol) [49] or NETLMM (Network-based Lo-calized Mobility Management) [56], correspondents nodes are not concerned by mobilenodes mobility and communicate with them using the IPv6 address as they would dowith non-mobile nodes. Consequently, such protocols are fully compatible with currentimplementations of TCP and UDP. Applications are not aware that mobility supportis being used, even on the mobile node’s side. In such protocols, mobility is eithersupported by mobile nodes or by the network. These protocols can however introducelonger communication delays due to non-optimal communication paths.

1.3.3 Design constraints

As previously discussed, all mobility protocols designed at the IETF take different ap-proaches to provide mobility support over the Internet. While these protocols maysometime look divergent, they can however be classified and compared using the fol-lowing requirements.

1. Realistic utilization

In order to ease its deployment and accelerate its adoption, a mobility protocolmust not require any modification on correspondents’ sides: they should be ableto communicate with mobile nodes as if they were not mobile. Concerning animmediate usage of mobility support on the Internet, it is indeed unreasonableto assume that all nodes will be upgraded to support mobility. Moreover, it isunlikely that any mobility protocol will be implemented on the server side, such asGoogle or MSN, as this leads to higher operational costs without any performancebenefit for the service provider.

2. Small impact on the existing network architecture

This is somehow similar to (1) but from a network perspective. All requiredchanges to the network architecture should remain compatible with the cur-rent Internet technologies. Concerning immediate deployments, only incrementalchanges could be seriously considered for practical mobility support: it is notfeasible to break the current addressing and routing architectures.

8 1.3. Approaches for Internet mobility support

Protocols 1 2 3 4

DNS-based x x

SCTP, HIP x x

LISP x x x

MIPv6 x x x

MIPv6 & RRP x x x

OLSR, AODV x x

Table 1.2: Design constraints and mobility protocols examples

3. Transparency to transport layers and applications

We allow packet losses, but ongoing connections must smoothly survive han-dovers. Moreover, mobility support must not require any modification to appli-cations. This is impracticable, as every application would need to be upgraded.In terms of network layers, this means that the mobility protocol must eitherreside below transport layers, or provide its functionalities through transparentapplication proxies such as SOCKS [75].

4. Similar performances

A mobility protocol should not seriously impact the communications perfor-mances, nor increase the load on the network. Moreover, it should also scaleto provide acceptable performances when the number of mobile nodes increases.Ultimately, the users experience should remain the same as in a non-mobile con-text.

Giving the four design constraints, we provide an overview of different mobilityprotocols alternatives in Table 1.2. It easily highlights that the implementation choices(such as the networking layer, the locator/identifier mapping, or the locator types)impact application scopes of mobility protocols. For example, the Optimized Link StateRouting (OLSR) routing protocol [33], designed to support Mobile Ad-hoc Networks(MANET), must be implemented in every node that want to benefit from its features.However, it allows nodes to communicate in areas where there is no communicationinfrastructure by automatically adapting itself to nodes movements. On the otherhand, LISP efficiently separates nodes identifiers from routing locators while remaining


compatible with current IPv6 stacks. Nevertheless, it requires heavy changes to thecurrent Internet Architecture.

Under the previous design constraints, we concluded that the IPv6 address is theonly identifier that could be used to achieve immediate deployments of mobility support.This observation led us to focus our work on Mobile IPv6. At the beginning of this thesisin 2004, four implementations were already available, and the protocol was supportedby major vendors of networking equipments [13, 8, 32, 79]. At the same time, peopleagreed that Mobile IPv6 was a good, yet flawed, intermediary solution to providemobility support over the Internet. Today, in 2008, Mobile IPv6 is pushed by StandardDevelopment Organizations, and unlike any other mobility protocol, it is expected tosoon go to market.

So far we did not discuss security as a design constraint, however we firmly believethat it is a critical aspect of mobility systems. Security is important but is drivenby usages scenarios and must be designed consequently. For example, concerning theintegration of Mobile IPv6 in the WiMAX architecture, a simple authentication mecha-nism [92] modeled from Mobile IPv4 [93] and pushed by telecommunications operatorsis preferred to IPsec which is the common way to secure Mobile IPv6 [42]. Indeed,the implementation and use of IPsec are considered as being too demanding to beintegrated into small devices such as mobile phones.

1.4 Overview of Mobile IPv6

In this section, we briefly describe the Mobile IPv6 protocol, its advantages, its limi-tations and our solutions. It will be further described in Chapter 2. The Mobile IPv6protocol provides a unique permanent identifier (an IPv6 address) to a mobile node(MN) independently of its network of attachment. As shown in Figure 1.1, the keycomponent of Mobile IPv6 is the home agent (HA) located in the mobile node’s homenetwork. It is a dedicated IPv6 router that manages the home IPv6 prefix, as well asthe binding between the identifier and the locator which, in the Mobile IPv6 termi-nology, are respectively referred as Home Address and Care-of Address. The Care-ofAddress is used by the mobile node to communicate with its home agent. Packets sentto the Home Address (that belongs the home prefix) by correspondent nodes (CN) arerouted to the home network and intercepted by the home agent which forwards it tothe current location of the mobile node: its Care-of Address. Likewise, packets sentfrom the mobile node to its correspondent node must go through the home agent priorto being delivered. This deviation of packets to the home agent is called dogleg routing,

10 1.4. Overview of Mobile IPv6

HA Home

network

Foreign network

Internet

Visited network

CN

MN

tunnel

Optimized Path

HA: Home Agent; CN: Correspondent Node; MN: Mobile Node

Figure 1.1: Mobile IPv6

and causes longer paths and higher communication delays between mobile nodes andtheir correspondents.

The Mobile IPv6 specification only requires the protocol to be implemented inhome agents and mobile nodes, moreover it is transparent to transport layers. As aconsequence, it satisfies design constraints 1, 2 and 3 as previously specified.

In addition, the base specification of Mobile IPv6 includes a route optimizationscheme called the Return Routability Procedure (RRP) that solves the deviation ofpackets. In Figure 1.1, the resulting communication path is represented as OptimizedPath. This procedure allows packets to be directly sent between a mobile node and itscorrespondent without involving the home agent. Since this optimization reduces thelatency of the communications and improves performances, it consequently validatesthe fourth design constraint. However, the Return Routability Procedure requiresupgrading all correspondents, it do not anymore meet the requirements of the firstdesign constraint.

With the dogleg routing, the restricted position of the home agent is the funda-mental problem that weakens Mobile IPv6 performances. Due to the addressing androuting architectures, the location of a home agent is topologically and physically re-stricted by its home prefix. It must be in the correct physical location so that it canreceive packets destined to the home prefix. Therefore, the home agent has to be placed


where this prefix is advertised on the Internet. All of the previously described designconstraints cannot be satisfied at the same time with the current Mobile IPv6 specifi-cation. Putting the Return Routability Procedure aside, the protocol does not fulfillthe fourth constraints: it presents performances drawbacks.

1.5 Contributions

The primary goals of this thesis are to improve Mobile IPv6 performances, and to con-trol its current shortcomings. Currently promoted by the Third Generation PartnershipProject (3GPP) and the WiMax Forum, the Mobile IPv6 protocol is a major solutionto provide mobility support while remaining compatible with current network archi-tectures and end-nodes implementations. In order to achieve our goals, we thoroughlyanalyze Mobile IPv6 limitations and then propose optimizations that satisfy the designconstraints described in Section 1.3.2. To do so, we use both practical and theoreticalapproaches. Our main contributions are listed below.

1. Home Agent Migration

We propose a new mobility architecture, called Home Agent Migration, that usesthe traditional Mobile IPv6 protocol with an additional mobility managementplane. In this new plane, home agents are distributed all over the Internet and areexchanging information about mobile nodes that they can reach. This deploymentis performed with the help of anycast routing [69] in which each home agentadvertise the same home IPv6 prefix. Consequently, a mobile node will exchangetraffic with its topologically closest home agent, reducing communication delays.This work led to one publication [117], and one submission to a journal [116](currently under review).

2. Expose the impact of home agents locations

We model operator’s networks as undirected graphs and define the properties ofthe good home agents locations in terms of graph theory. We then quantify theimpact of the dogleg routing on communications performances. In particular,we use notions of centrality in graphs to quantify increases of communicationdistances induced by dogleg routing and identify relevant home agents locations.

3. Methodology for home agent deployments

Using the results from the above study, we describe a new approach to addressdeployments issues of Mobile IPv6 that could be applied to any operator’s net-work. We propose an algorithm that indicates good home agents locations given

12 1.6. Outline

a specific network topology. We evaluate this approach using real-world networktopologies and show that the obtained Mobile IPv6 performances could be close todirect paths ones. The proposed algorithm is generic and can be used to achieveMobile IPv6 as well as Home Agent Migration deployments.

4. NEMO enhancements

We provide detailed descriptions of possible usages of Home Agent Migrationalong with Network Mobility (NEMO) [43]. This protocol based on Mobile IPv6delivers mobility service to whole networks, such as sensors deployed in a car, andto standard IPv6 nodes that do not implement Mobile IPv6 on the client side.This work led to a publication [110].

5. Tool for rapid IPv6 prototyping

IPv6 as well as Mobile IPv6 extensions to Scapy6 [26] were developed in collab-oration with Arnaud Ebalard7 [109, 108]. Their primary goal was to emulateMobile IPv6 node from the userland using the Python programming language[11]. These emulated nodes were used to conduct experiments in environmentswhere its was not possible to set up real mobile nodes. These extensions are notonly used by the research community but also by companies that mostly use themto test their IPv6 implementations.

1.6 Outline

Chapter 2 provides a detailed description of the Mobile IPv6 protocol and its limita-tions, as well as an overview of standardized optimizations. Chapter 3 describes theHome Agent Migration architecture from a synthetic to an implementation perspective,and finally provides an evaluation based on a real deployment. Chapter 4 presents ananalysis of Mobile IPv6 and Home Agent Migration in terms of graph theory, and givesdetails about a methodology that efficiently choose relevant home agents locations ingiven network topologies.

Appendix A describes two Scapy extensions that were written during this thesis,and then presents possible usages of the IPv6 Routing Header that were discoveredwhile developing these extensions. Appendix B summarizes this thesis in French.

6tool written in Python that simplifies the injection and the reception of frames and packets.7from EADS Innovation Works.

Chapter 2Background on Mobile IPv6

Contents

2.1 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.1 Preliminary terminology . . . . . . . . . . . . . . . . . . . . . 14

2.1.2 Operation of Mobile IPv6 . . . . . . . . . . . . . . . . . . . . 15

2.1.3 Return Routability Procedure . . . . . . . . . . . . . . . . . . 18

2.1.4 NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.5 Home Agent Discovery . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Protocols limitations . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.1 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.2 Return Routability Procedure . . . . . . . . . . . . . . . . . . 24

2.2.3 NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3 Security overview . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.1 Possible attacks against Mobile IPv6 . . . . . . . . . . . . . . 26

2.3.2 IPsec protection . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4 Standardized optimizations . . . . . . . . . . . . . . . . . . . 29

2.4.1 Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . . . . . . 30

2.4.2 Fast Handover for Mobile IPv6 . . . . . . . . . . . . . . . . . 31

2.4.3 Multiple Care-of Address . . . . . . . . . . . . . . . . . . . . 32

2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

14 2.1. Mobile IPv6

2.1 Mobile IPv6

In this section, we give a detailed overview of Mobile IPv6. Then we discuss issuesraised by this protocol and its route optimization procedure. The aim of this section isto describe problems that this thesis is addressing while considering immediate deploy-ments of mobility support in the Internet, and to highlight our contributions concerningthe distribution of home agents and their locations.

2.1.1 Preliminary terminology

Here, we present the terminology that we will use throughout this thesis, visuallysustained by Figure 2.1 that locates terms in an example network topology.

Prefixes, addresses, and abstract elements

1. Home prefix: an IPv6 prefix managed by the home agent that corresponds tothe mobile node Home Address.

2. Home Address (HoA): a fixed IPv6 address that belongs to the home prefixof the mobile node; it is the identifier.

3. Care-of Address (CoA): it is an IPv6 address that belongs to the networkwhere the mobile node is physically located. The CoA changes as the mobilenode moves; it is the locator.

4. Home Link: the physical link on which the home prefix is advertised usingIPv6’s auto-configuration mechanisms [105].

5. Binding Cache: a database (similar to a routing table) that contains the map-pings between Home Addresses and Care-of Addresses.

6. Mobility Header: a new type of network header that is used to carry MobileIPv6 related signaling packets. It is transported directly over IPv6.

Nodes

1. Home agent (HA): a specific router located in the home network. It delegates aHome Address from the home prefix to a mobile node, and forwards the associateddata traffic to the mobile node.

Chapter 2. Background on Mobile IPv6 15

Foreign network

Visited network

CN

MN

HA

Internet

Home Network

Home Link

Figure 2.1: Mobile IPv6 terminology

2. Mobile node (MN): a node that keeps its Home Address after changing itsnetwork of attachment. It implements Mobile IPv6.

3. Correspondent node (CN): a node that communicates with a mobile node. Itmay implement Mobile IPv6 if it supports the Return Routability Procedure.

Networks

1. Home network: network where the home agent is located. The home prefixand thus Home Addresses belongs to this network.

2. Foreign network: network where the correspondent node is located.

3. Visited network: network where the mobile node is located; its Care-of Addressbelongs to the IPv6 prefix of this network.

2.1.2 Operation of Mobile IPv6

On the Internet, the location of a node is strongly constrained by the routing architec-ture. An IPv6 address that belongs to an IPv6 prefix allocated to a French InternetService Provider cannot be used to receive packets in Japan. Consequently, the currentInternet architecture makes it impossible to keep the same address when a nodes move.

16 2.1. Mobile IPv6

HA Home

network

Foreign network

Internet

Visited network

CN

MN

tunnel2001:db8:d0d0::/64

2001:db8:cafe:deca::/64

2001:db8:dead::/64

Figure 2.2: Mobile IPv6: communication example

This problem is linked to the dual function of the IP address. First, it implicitly pro-vides the position of a node on the globe; this role is called locator. Then, it uniquelyidentifies the node in the whole Internet topology; this second role is called identifier.The Mobile IPv6 protocol provides a solution to separate these two functions. A mo-bile node implementing Mobile IPv6 uses two different IP addresses: its Home Address(HoA), which plays the role of the identifier, and its Care-of Address (CoA) the locator.

In order to bind the Home Address to the Care-of Address, Mobile IPv6 relieson the home agent, a specific router located in the home network. Its goals are todelegate a Home Address from the home network to each mobile node, and to for-ward the mobile node’s data traffic. At any given time, the mobile node alwayscommunicates using its Home Address regardless of the network it is connected to.A simple communication example is shown in Figure 2.2 when Mobile IPv6 is used.The home prefix is 2001:db8:d0d0::/64, the HoA is 2001:db8:d0d0::42, and the CoA is2001:db8:cafe:deca:217:f2ff:fec7:881a1.

1auto-configured with the prefix advertised by the Access Router (AR).


ICMPv6 Echo Reply

Router Solicitation

ICMPv6 Echo Request

ICMPv6 Echo Reply

Router Advertisement

Binding Update

Binding Acknowledgment

ICMPv6 Echo Request

MN CN

1. Movement detection

2. Association

3. Sending data

HAAccess router (AR)

IPv6-in-IPv6 tunnel

Figure 2.3: Mobile IPv6: packets exchanges

Exchanged Packets

Figure 2.3 represents the successive packets exchanges occurring after a mobile nodedetected that it moves until the communication with its correspondent. The movementdetection relies on the standard IPv6 auto-configuration mechanism described in RFC4862 [105]; it is not specific to Mobile IPv6.

1. when the mobile node moves to a new network, it first configures a new Care-ofAddress (2001:db8:cafe:deca:217:f2ff:fec7:881a) using the prefix announced by theAccess Router (AR; 2001:db8:cafe:deca::/64), and its network interface’s MACaddress 00:17:f2:c7:88:1a.

2. it registers its binding information with its home agent by sending a messagecalled a Binding Update containing its Home Address (2001:db8:d0d0::42) andits new Care-of Address (2001:db8:cafe:deca:217:f2ff:fec7:881a) to its home agent.After the reception of this packet, the home agent sets up an IPv6-in-IPv6 tunnelwith the mobile node. It also fills up its Binding Cache with a mapping that

18 2.1. Mobile IPv6

HA Home

network

Foreign network

Internet

Visited network

CN

MN

Optimized Path

2001:db8:d0d0::/64

2001:db8:cafe:deca::/64

2001:db8:dead::/64

Figure 2.4: Return Routability Procedure: communication example

associates the HoA to the CoA. Finally, it sends back a Binding Acknowledgmentmessage to notify the mobile node of the completion of the binding phase.

3. when the mobile node sends an ICMPv6 Echo Request message to its correspon-dent (2001:db8:dead::beef), this message is sent to the home agent using thetunnel, decapsulated by the home agent, and finally forwarded to the correspon-dent. As previously shown in Figure 2.2, all of the communications between amobile node and a correspondent node must go through the home agent.

2.1.3 Return Routability Procedure

The base specification of Mobile IPv6 includes a route optimization scheme called theReturn Routability Procedure. It allows the mobile node to send a Binding Updatemessage to its correspondent nodes that also implement Mobile IPv6. After the com-pletion of this procedure, the packets are directly routed between the mobile node andits correspondent nodes along the optimized path2, as shown in Figure 2.4.

2in practice, the optimized path is the direct path between the visited network and the foreignnetwork.


CoT

HoTi

MN CN

1. HoA test

HA

IPv6-in-IPv6 tunnel

HoTi

HoT

CoTi

3. Association

HoT

Binding Update

Binding Acknowledgment

ICMPv6 Echo Request

ICMPv6 Echo Reply

2. CoA test

4. Sending data

Figure 2.5: Return Routability Procedure: packets exchanges

20 2.1. Mobile IPv6

In this optimized mode, the correspondent node behaves somehow like a home agentas it is aware of the mobile node’s Care-of Address. However, unlike on the home agent,no preliminary information is available on the correspondent node to authenticate themobile node. The mobile node must therefore prove that it is the real owner of theCare-of Address and the Home Address that it wants to use. It does so by proving thatit is able to receive as well as emit packets from these two addresses [89].

Exchanged Packets

Figure 2.5 describes the packets exchanged between a mobile node and its correspondentuntil they can send packets over the direct path. The movement detection is notrepresented in the Figure. Note that this entire procedure must be repeated after eachmovement.

1. the first exchange of HoTi (Home Test init) and HoT (Home Test) messages isused to ensure that the mobile node is able to emit and receive packets using itsHome Address. These messages are exchanged through the tunnel establishedwith the home agent.

2. likewise, the exchange of CoTi (Care-of Test init) and CoT (Care-of Test) mes-sages checks that the mobile node is able to emit and receive packets using itsCare-of Address. These messages are exchanged directly between the mobile nodeand its correspondent.

3. after the reception of the HoTi and CoTi messages, the mobile node sends aBinding Update message to its correspondent to register the binding betweenits Care-of Address and its Home Address. The correspondent also fills up itsBinding Cache.

4. packets exchanged between the mobile node and its correspondent use the opti-mized path and are not deviated to the home agent. Packets are sent using theRouting Header Type 2 and the Home Address Option extensions to make surethat the IPv6 addresses contained in the IPv6 headers are topologically correct.Otherwise, if the Home Address was directly used in the IPv6 header, packetscould be discarded by the mobile node’s and the correspondent node’s accessrouters.

In practice, the four messages (HoTi/HoT and CoTi/CoT) exchanged during theReturn Routability Procedure are used to generate a cryptographic key that is employed


HA1

Home network

MR1Tunnel

Foreign network

CN

Figure 2.6: NEMO

by the mobile node to cryptographically sign the Binding Update message. Uponreception of the HoTi and CoTi messages, the correspondent knows that the mobilenode can emit packets from its two addresses (HoA and CoA). It then sends back twotokens to the mobile node into the HoT and CoT messages. These two tokens arehashed together to generate the key used to sign the Binding Update message sent bythe mobile node to the correspondent node. Possible attacks against Mobile IPv6 andthe Return Routability Procedure are later discussed in Section 2.3.1.

2.1.4 NEMO

Defined at the IETF in RFC 3963 [43], NEMO (NEtwork MObility) is an extension toMobile IPv6 that allows a whole network to move and change its point of attachmentto the Internet as would a mobile node. A new entity similar to the mobile node,called a Mobile Router (MR), implements the NEMO protocol. Its goal is to hide theeffect of mobility to the nodes connected to its ingress3 interface as shown in Figure2.6. The main concept of NEMO is to provide a mobility service to IPv6 nodes that donot implement Mobile IPv6, using an IPv6 prefix delegated from the home network. Atypical usage scenario for this protocol is public transportation systems such as trainswhere end-nodes are connected to the Mobile Router using 802.11b.

Like a Mobile Node, the Mobile Router has a permanent Home Address that remainsthe same wherever it moves. In addition, it also manages a Mobile Network Prefix(MNP) delegated from the home network. This is the IPv6 prefix used by end-nodesconnected to its ingress interface. In NEMO, the home agent is slightly modified soas to delegate Home Addresses as well as Mobile Network Prefixes, and to process

3internal.

22 2.1. Mobile IPv6

HA2MR2HA1

Home network 1

MR1

Home network 2

tunnel 1tunnel 2

Foreign network

CN

node B

node A

parent-NEMOsub-NEMO

Figure 2.7: Nested NEMO

dedicated Binding Update messages. It does not only intercept packets destined tothe Home Address of mobile routers but also intercepts data packets sent to nodesbelonging to the Mobile Network Prefix.

As defined by the NEMO terminology [45], a mobile network is said to be nested(sub-NEMO) when it is directly connected to another mobile router (parent-NEMO).Figure 2.7 shows a simple case of nested mobile network where a mobile router, MR2,is connected to another mobile router, MR1. The networks interconnecting MR1 andHA1, and HA1 and HA2 are not represented. We consider that Binding Update mes-sages were respectively sent and received by the mobile routers and their correspondinghome agents. When node A in the parent-NEMO sends packets to node B located inthe sub-NEMO, they are forwarded to MR1 which encapsulates packets into tunnel 1.Then, HA1 decapsulates and forwards them to the home network 2 which is the correctdestination owing to the routing architecture. When packets reach this network, theyare intercepted by HA2, immediately forwarded to MR2 via tunnel 2, and deliveredto node B. This is a typical use of NEMO that presents some performance issues thatwill be described in the following Section. This scenario is likely to happen when apassenger brings its mobile router, MR2, into a train, and use it to provide Internetaccess to its devices such as his laptop and smart-phone.

2.1.5 Home Agent Discovery

While away from its home network, a mobile node might not know the IPv6 address ofthe home agent serving its home prefix. The Mobile IPv6 RFC defines a new DynamicHome Agent Address Discovery (DHAAD) ICMPv6 message that could be used by a


mobile node to discover all home agents configured on the home link. On the homelink, home agents periodically advert their home prefix using Router Advertisement(RA) messages. Using these messages, a home agent can maintain a list of home agentsthat serve the same home prefix.

In practice, the DHAAD message is sent to a specific anycast address [65] that isconstructed using the home prefix4. This message is routed and delivered to only onehome agent that sends back a DHAAD reply message containing a list of home agentsmanaging the home prefix.

DHAAD allows several home agents to serve different set of mobile nodes with thesame home prefix. However, if the home agent serving a mobile node crashes, on-goingcommunications are stopped and the mobile node must rebind to another home agent.The Mobile IPv6 RFC does not define any mechanism that provides transparent homeagent redundancy in case of system failures.

2.2 Protocols limitations

2.2.1 Mobile IPv6

Mobile IPv6 has some fundamentals problems related to the use of the home agent toperform the bindings between Home Addresses and Care-of Addresses. They especiallyweaken the protocol performance as well as its scalability. We describe these problemsbelow.

1. Dogleg routing

In Mobile IPv6, a mobile node is only associated with a single home agent. Allpackets are first routed to the home agent and then forwarded to the destination inan IPv6-in-IPv6 tunnel. Consequently, packets take a non-optimal path becauseall of the traffic must transit through the home network. This problem is knownas dogleg routing and is responsible for increasing communications delays whena mobile node communicates with its correspondent node.

2. Restricted position

The location of a home agent is topologically and physically restricted by its homeprefix. It must be in the correct location so that it can receive packets destined tothe home prefix; as a result, it must be placed where this prefix is advertised on theInternet. This strong location requirement is particularly problematic. Moreover,

4the anycast address associated to the prefix 2001:db8:d0d0::/64 is 2001:db8:d0d0::fdff:ffff:ffff:fffe.

24 2.2. Protocols limitations

when the home network becomes unreachable, mobile nodes also become isolatedand cannot be reached through their home address.

3. Constraints for the home link

In usual Mobile IPv6 deployments, when a mobile node is located in a foreignnetwork, it can not reply to Neighbor Discovery5 messages sent from the homenetwork’s access router. In order to intercept mobile nodes’ packets, the homeagent is therefore in charge of replying to these messages on behalf of mobilenodes away from the home network; in practice, they act as Neighbor Discoveryproxies (Proxy NDP) [87]. This leads to a serious scalability issue, as the numberof Neighbor Discovery packets sent by the home agent is proportional to thenumber of mobile nodes it serves. Additionally, the total bandwidth requiredby mobile nodes’ data traffic of mobile nodes might be bigger than the totalhome link bandwidth. Therefore, deploying Mobile IPv6 could be an operationalchallenge to maintain the balance between the mobile nodes’ total bandwidth andthe home link’s stability.

2.2.2 Return Routability Procedure

The route optimization scheme described in the base specification of Mobile IPv6 hasthe issues listed below.

1. Privacy

Since the mobile node reveals its Care-of Address to its correspondent node bysending Binding Update messages, the real location of the mobile node is disclosedto other nodes on the network. This is a severe problem as it can ease industrialspying, and threaten location privacy. In addition, when route optimization isperformed the mobile node’s data traffic is not protected by IPsec, which leavesthe communications vulnerable to eavesdropping on the visited network.

2. Modifications of end-nodes

In order to perform the route optimization, every end-node must support theReturn Routability Procedure. However, it is unrealistic to expect that all IPv6nodes will support route optimization, as it means upgrading existing nodes.Therefore, these legacy IPv6 nodes will not be able to benefit from this procedureand all of the data traffic will be destined to the home network.

5it replaces the Address Resolution Protocol (ARP) in IPv6.


3. Complexity

As previously described, prior to sending a Binding Update message to a corre-spondent node, the mobile node must exchange four messages to generate a keythat will be used to authenticate the binding. This binding procedure is usedwith each correspondent node every time the mobile node moves. In the worstcase, this whole message exchange is repeated after each movement. Depend-ing on implementation choices, the HoTi/HoT exchange is only necessary onceper correspondent. The overhead of this procedure is therefore high and implieslonger handovers. If the Return Routability Procedure cannot be performed af-ter a mobile node’s movement, due to strict firewall policies or packet losses, themobile node cannot exchange any data with its correspondent nodes until theBinding Cache’s entry expires.

4. Server overload

We must consider that a server communicating with thousands of users may beacting as a correspondent node. In this case, the Return Routability Proceduredangerously increases the amount of work the server performs to serve queries.The deployment of Mobile IPv6 using the Return Routability Procedure causesits operational cost to also be supported by entities other than the one in charge ofthe home network. Unlike non Mobile IPv6 based communications, more packetsare exchanged and more powerful hardware is required to handle the same amountof users. Therefore, it is unlikely that Mobile IPv6 will be implemented in servers,as it leads to bigger operational costs. These problems can seriously slow downthe adoption of this route optimization scheme, as it does not bring direct benefitfor the companies managing servers.

5. Filtering

This is more a side effect that a direct issue of the Routing Routability Procedure,however it can seriously affect its effective usages. Nowadays, networks adminis-trators tend to drastically filter both their egress and ingress traffic, and restrictpackets types to the strict minimum (i.e. not Mobile IPv6). This new trend offiltering could for example forbid correspondent nodes to establish an optimizedpath with the mobile node. This filtering issue is especially serious since January2007 and the disclosure of a critical bug affecting the handling of Routing Headerextensions on Cisco routers [3]: some routers are now discarding every packetscontaining Routing Headers, and as a side effect messages related to Mobile IPv6and the Return Routability Procedure.

26 2.3. Security overview

2.2.3 NEMO

As described in the NEMO problem statement document [88], besides with the previousMobile IPv6 issues, this protocol also suffers from the nested mobile network scenariodescribed in Section 2.1.4. This is an important problem as all of the packets ex-changed between correspondents and nodes behind the mobile router must go throughthe tunnel. When mobile routers are not managed by the same home agent, the com-munication’s path and delay are altered by the mandatory derivation to different homeagents HA1 and HA2. Moreover, the bandwidth usage uselessly increases with thenumber of nested networks, wasting network resources and increasing the probabilityof the tunnel congestion. The impact of this problem is even more serious when thehome agents are far away, for example if HA1 is located in Tokyo and HA2 located inParis. In addition to this first issue, if the egress6 network interface of MR1 fails, nodeA can no longer send packets to node B. In other words, the egress network interfaceof the root mobile router, here MR1, limits communications from all sub-NEMO interms of bandwidth and stability. So far, the NEMO working group at the IETF didnot come up with a solution to these issues. The only consensus is that the RoutingRoutability Procedure as defined in the Mobile IPv6 RFC cannot be used with NEMO.

2.3 Security overview

Mobile IPv6 and its extensions should not bring new security related issues into theInternet architecture. This section first describes the possible attacks that could targetMobile IPv6 if communications are not protected. Then, it discusses security protec-tions that were designed at the IETF.

2.3.1 Possible attacks against Mobile IPv6

Binding Update spoofing

The communications between a mobile node and its home agent are interesting targetsfor an attacker. By default, Binding Update messages are not authenticated. Theattacker only needs to know the Home Address of the target in order to inject fakeBinding Update messages. As a result, the attacker can do whatever she wants toperturb the mobile node such as retrieving its traffic, forbidding it to communicate,or redirecting the traffic to a target to perform a Denial of Service attack. For thisreason, real life deployments of Mobile IPv6 outside closed networks cannot be done

6external.


without at least authenticating signaling messages, such as Binding Update messages,and protecting them against replay.

Traffic injection

If the tunnel between the mobile node and its home agent is not protected, an attacker,that knows its Home Address and its Care-of Address, could easily inject data packetsinto the tunnel and pretend to send traffic from the Home Address. Similar to thesignaling messages, packets sent in the tunnel should be authenticated and protectedagainst replay.

Return Routability Procedure

From its conception, the Return Routability Procedure was developed to limit Denialof Service attacks against the network infrastructure and the correspondents nodes [22].No amplification attack is possible as one message sent by the mobile node correspondsto one reply sent by the correspondent node. If an attacker want to send a fake BindingUpdate message to a correspondent node, it must know the two authentication cookiessent in the Home Test and Care-of Test messages. In other words, it must be able toeavesdrop traffic on the home network as well as on the visited link, which is not aneasy task. Note that the Return Routability Procedure does not provide any protectionagainst an attacker based on the visited network: the threat is, in this case, independentof Mobile IPv6, and equivalent to an attacker eavesdropping traffic on a non-protectedWi-Fi hotspot.

2.3.2 IPsec protection

IPsec

IPsec [73] is a set of protocols (namely AH7, ESP8, and IKE9) and algorithms designedto secure IP based communications. As IPsec operates at layer 3, it is a convenientsolution to transparently secure end-user applications, and to provide security servicesto upper layer protocols. IPsec has two modes of operation: tunnel mode (IP-in-IPtunnels are protected) and transport mode (end-to-end communications are protected).The ESP header [72] provides encryption and protection against eavesdropping. TheAH header [71] provides authentication, replay protection, and integrity verification.

7Authentication Header.8Encryption Security Payload.9Internet Key Exchange.

28 2.3. Security overview

In order to protect IP packets, IPsec relies on two databases: the Security Policy(SP) database, and the Security Association (SA) database. Security Policies are ruleson IP addresses, or protocol types that define which packets must be processed byIPsec. On the other hand, Security Associations (SA) are sets of algorithms and pa-rameters (such as the operation mode, or cryptographic key) that define how to protectpackets selected by a Security Policy. Both Security Policy and Security Associationdesignate simplex communications, as a consequence two of each are required to securea bi-directional communication. Security Policies are manually configured by admin-istrators or users, while Security Associations can be configured either manually ordynamically using the IKE protocol [57, 70]: this is referred as dynamic keying by theIPsec terminology.

In order to protect from packets injection and eavesdropping, signaling messages10

as well as the tunnel between the mobile node and the home agent must be protectedwith AH and ESP as defined in RFC 3776 [19] and 4877 [42]. No IPsec protection isnatively available for the Return Routability Procedure has there is no prior knowledgeof the correspondent node that could be used to perform mutual authentication. How-ever, some work is being done to standardize the IPsec protection of communicationbetween a mobile node and its correspondent node when this mutual authentication ispossible [47].

Nowadays, it is quite simple to use Mobile IPv6 and IPsec conjointly, howeverit required some important adjustments to the standard IPsec framework in order toadapt it to mobility. For example, when the mobile node changes its Care-of Address theend points of Security Policies and Security Associations must be updated accordinglyupon the reception of a Binding Update or a Binding Acknowledgment message [97].Likewise, the IKE protocol was extended to support mobility more efficiently, and tomake it more reliable in case of handovers [46]. As of today, the most advanced MobileIPv6 implementations are available for BSD and Linux kernels, named respectivelySHISA [13] and MIPL [8], and both support IPsec protection with dynamic keying.

Binding Update authentication

As previously discussed in the introduction, the IPsec protection is often consideredby telecommunications operators as being too complicated to be embedded into mobiledevices. Moreover, they consider that IPsec is not mandatory in their core networks ifefficient packets filtering is performed internally. As a consequence, an alternate mech-anism to secure signaling messages was defined [92] based on Mobile IPv4. It relies on

10Binding Update and Binding Acknowledgment messages.


HA

Internet

CN

BU

MAP2MAP1

MN

BU

(a) Before the handover

HA

Internet

CN

MAP2MAP1

MN

BU

MN

(b) After the handover

Figure 2.8: Hierarchical Mobile IPv6

an authentication and a replay protection options that are carried by Binding Updatemessages. Using these two options, the home agent can authenticate a mobile node,and prevent the injection of fake signaling messages. If the Care-of Address is never dis-closed, this protection is consequently sufficient to secure Mobile IPv6 communications;if it is disclosed, an attacker can still inject packets into the tunnel.

2.4 Standardized optimizations

Several proposals were defined at the IETF to solve some of Mobile IPv6 limitations.Their main goals are to reduce the number of signaling packets sent from the mobilenode to the home agent. Hierarchical Mobile IPv6 (HMIPv6) makes mobility within anoperator’s network transparent to correspondent nodes through a pyramidal hierarchyof home agents. On the other hand, Fast Handovers for Mobile IPv6 (FMIPv6) andthe multiple Care-of Address (mCoA) extension proposes two different approaches toreduce packets losses during handovers.

30 2.4. Standardized optimizations

2.4.1 Hierarchical Mobile IPv6

The Hierarchical Mobile IPv6 (HMIPv6) RFC [100] was specifically designed to enhancethe mobility of mobile nodes within a site11 by pushing home agents closer to mobilenodes. It relies on new equipments called Mobility Anchor Points (MAP) that behavelike home agents. As shown in Figure 2.8(a), they are distributed in the network tominimize the effects of the dogleg routing through a hierarchical organization of thehome agent and Mobility Anchor Points. Thanks to this hierarchy, HMIPv6 providesa scalable mobility support to Mobile IPv6: the number of signaling messages outsidethe local network is limited. Moreover, if one MAP fails, only a small fraction of themobile nodes will be impacted.

Mobility Anchor Points are used to reduce the number of Binding Update messagessent to perform local handovers: if a mobile node moves under the hierarchy, BindingUpdate messages are not send over the Internet. Moreover, the hierarchy also reducesthe handover latency as signaling messages do not need to cross the whole Internet.The handovers are handled locally: the MAP hides local mobility.

In addition to its Care-of Address12, a mobile node also maintains a Regional Care-of Address (RCoA) constructed using information periodically sent by Mobility AnchorPoints. In Figure 2.8(a), the RCoA is an IPv6 address that belongs to the IPv6 prefixmanaged by the MAP as a consequence packets sent to the RCoA will be routed to theMAP. Along with its Home Address, the mobile node will use these addresses whensending Binding Update messages.

1. Binding Update to the MAP: the mobile node first sends a Binding Updatecontaining the CoA and the RCoA in order to bind the RCoA to its currentlocation. This could be seen as a first level of HMIPv6 hierarchy. Such messagesare sent when the mobile nodes moves under the same MAP: only its CoA changes.

2. Binding Update to the Home Agent: the mobile node then sends anotherBinding Update containing the RCoA and the HoA. These messages are sentwhen the mobile node is associated with a new MAP: both its CoA and RCoAchange.

Upon a movement from the subnetwork 1 to the subnetwork 2, the mobile nodewill acquire a new CoA, but the RCoA will remain the same. As a consequence, themobile node only needs to send a Binding Update message to the MAP to announce

11also referred as local mobility.12called Local CoA (LCoA) in the HMIPv6 terminology.


Internet

MNMN

CN

PAR HA

NAR

PreviousVisited Network

NewVisited Network

(a) Before the handover

Internet

MN

MN

CN

PAR

NAR

Tunn

el

HA

PreviousVisited Net.

NewVisited Network

(b) After the handover

Figure 2.9: Fast Handover for Mobile IPv6

the change of its CoA, as shown in Figure 2.8(b). Upon reception of this message, theMAP will forward the entire mobile node traffic to its CoA. Concerning the home agent,this movement is completely transparent. If the mobile node moves to a subnetworkmanaged by another MAP, it will acquire a new RCoA. As a consequence, it will needto notify both the Home Agent and the new Mobility Anchor Point of this movement,and send them new Binding Update messages.

2.4.2 Fast Handover for Mobile IPv6

Fast Handover for Mobile IPv6 (FMIPv6) [74] defines a set of extensions designed tominimize packets losses, and reduce handovers latency when a mobile node moves fromone visited network to another. The key idea is to enhance Mobile IPv6 with mecha-nisms that can anticipate handovers by pushing some of the home agent functionalitiesinto access routers, and by suppressing delays inherent to Neighbor Discovery andbinding registration.

In Figure 2.9(a), the mobile node exchanges packets with its correspondent using thetunnel established between its Care-of Address and its home agent, like it would withMobile IPv6. As shown in Figure 2.9(b), FMIPv6 allows the mobile node to continuereceiving packets delivered to the Previous Care-of Address (PCoA) immediately afterit joined the new visited network by establishing a tunnel between the Previous AccessRouter (PAR) and the New Care-of Address (NCoA). This tunnel will be removed assoon as the mobile node sends a Binding Update containing the NCoA to its homeagent. In practice, the handover latency is reduced using the following independentsteps.

32 2.4. Standardized optimizations

1. Acquire surrounding IPv6 prefixes: each access router is aware of the dif-ferent IPv6 prefixes served by the other access routers. A FMIPv6 mobile nodecan perform a Wi-Fi scanning to discover the BSSID13 of the surrounding accessrouters. Using this list, the mobile node can query its access router and retrieveIPv6 prefixes associated to these BSSID.

2. Decrease Neighbor Discovery delays: using the resulting list, the mobilenode can construct its New Care-of Address and request the NAR to reserve theNCoA on its physical link. By doing so, the mobile node ensure that no othernode will use the same IPv6 address, and will be able to use it as soon as it joinsthe new visited network.

3. Tunnel data between the NCoA and the PAR: after joining a new network,a mobile node is able to send a message similar to a Binding Update to the PAR.Upon reception, the PAR will setup a tunnel with the NCoA of the mobile node,and use it to forward traffic sent to the PCoA. Note that the mobile node cannotuse its NCoA until it sends a Binding Update message to its home agent, orcorrespondents nodes.

4. Communication between the PAR and the NAR: PAR and NAR exchangemessages to confirm that a mobile node will move to the new visited network andto indicate whether the NCoA is available or not.

Using these mechanisms, a mobile node is able to send and receive packets as soonas it is physically associated to a new network and before it sends a Binding Updatemessage to its home agent. Upon reception, the home agent will configure a tunnelwith the NCoA, and forward packets to the real location of the mobile node. Thecommunication scheme is then similar to Mobile IPv6.

2.4.3 Multiple Care-of Address

With the Mobile IPv6 RFC, a mobile node can only bind one Care-of Address to itsHome address at the same time. As a consequence, a device with different accesses tothe Internet cannot use them simultaneously to communicate with its correspondents.Likewise, it cannot easily anticipate its handovers and for example decide to simulta-neously use a second interface before the first one goes down. The Multiple Care-ofAddress (mCoA) Internet Draft [113] defines mechanisms that allow a mobile node with

13Basic Service Set IDentifier; unique identifier of a Wi-Fi access point; similar to a MAC address.


Home network

HA

Internet

Wi-Fi network

EDGE network

CoA1

CoA2

HoA

Tunnel 1

Tunnel 2

MN

Figure 2.10: Multiple Care-of Address

multiple network interfaces to associate all of the corresponding Care-of Addresses toits Home Address. In practice, it defines a new Binding Update option that can carryseveral Care-of Addresses in one message. Similarly, mCoA allows a NEMO mobilerouter to use different Care-of Address with the same Mobile Network Prefix.

This new extension brings an efficient handover mechanism model to Mobile IPv6that does not require any specific equipment like in FMIPv6. As it is only implementedin the home agent and the mobile nodes, it has no impact on the network architecture.Moreover, mCoA makes it possible to define per flow policies on the home agent. Forexample, in Figure 2.10, the mobile node could use its Wi-Fi link (with Tunnel 1) forVoIP communications, and its EDGE link (with Tunnel 2) for emails and web browsing.Note that like in Mobile IPv6, its correspondents will communicate with the mobilenode only using its Home Address. Along with the possibility to associate differentCare-of Address with one Home Address, the mCoA extension permits to perform loadbalancing between the network interfaces, and to drastically minimize packets lossesduring handovers if they are predicted correctly.

2.5 Conclusion

In this chapter, we thoroughly presented the Mobile IPv6 protocol, and provided detailsabout the mechanisms used to assign a permanent IPv6 address to mobile nodes. Dueto its design relying on the home agent, Mobile IPv6 is completely transparent tothe current Internet architecture and to transport protocols such as TCP or UDP.Consequently, it is a pertinent solution to achieve immediate deployments of mobilityservices over the Internet as it does not require any change to non-mobile nodes and

34 2.5. Conclusion

applications. However, its performances are limited by several problems mainly inducedby the home agent and its restricted position. The dogleg routing is indeed especiallyserious as it makes the handovers latency increase with the distance between a mobilenode and a home agent. In other words, performances of Mobile IPv6 are constrainedby the home agent’s location.

Several solutions were already designed to minimize the impact of the home agent’slocations on handover latencies, and communications performances. For example,FMIPv6 pushes some of Mobile IPv6 functionalities into access routers to permit mo-bile nodes to communicate immediately after a handover prior to rebinding to thehome agent. Similarly, mCoA describes another approach that allows mobile nodeswith multiple network interfaces to anticipate handovers by binding different Care-ofAddresses to the same Home Address. On the other hand, HMIPv6 proposes to locatehome agents closer to mobile nodes using a dedicated hierarchy of home agents thatminimize the impact of mobile nodes locations, and movements, on the communicationperformances.

In the following chapters, we will present two different solutions to address limita-tions caused by home agents locations. The first one, called Home Agent Migration,takes a practical approach and describes a new architecture that distributes homeagents in network topologies using anycast routing. Unlike HMIPv6, it can be used toachieve deployments within a single network, or over the whole Internet. The secondsolution takes a more formal approach to describe the dogleg routing in terms of graphtheory, and identify which locations within a network are suitable to achieve efficienthome agents deployments.

Chapter 3Home Agent Migration

Contents

3.1 General overview . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1.1 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.2 Typical deployments . . . . . . . . . . . . . . . . . . . . . . . 39

3.1.3 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.4 Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2 Practical implementation . . . . . . . . . . . . . . . . . . . . . 43

3.2.1 Notion of Binding Cache . . . . . . . . . . . . . . . . . . . . . 43

3.2.2 Communication examples . . . . . . . . . . . . . . . . . . . . 43

3.2.3 Movements of mobile nodes . . . . . . . . . . . . . . . . . . . 45

3.2.4 Example of a typical deployment . . . . . . . . . . . . . . . . 46

3.2.5 The underlying protocol . . . . . . . . . . . . . . . . . . . . . 47

3.2.6 NEMO support . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2.7 Security considerations . . . . . . . . . . . . . . . . . . . . . . 49

3.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.3.1 Performances comparisons . . . . . . . . . . . . . . . . . . . . 50

3.3.2 Experimental results . . . . . . . . . . . . . . . . . . . . . . . 51

3.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

36

As previously discussed, the Mobile IPv6 protocol, due to its use of the home agent,generates resilience and performances issues such as protocol scalability and longerpaths. Here, we show that Internet-Scale Mobility deployments are possible usingthe traditional Mobile IPv6 protocol with an additional mobility management planecalled Home Agent Migration. In this new plane, home agents are distributed all overthe current Internet topology to reduce communication distances between mobile andcorrespondent nodes. This deployment is performed with the help of anycast routingin which every home agent advertises the same IPv6 network prefix from differentlocations; moreover they also exchange information about their associations with mobilenodes contained in the Binding Cache. Consequently, a mobile node will transparentlyexchange its traffic with its topologically closest home agent, reducing communicationdelays. Similarly, when a correspondent node needs to exchange packets with a mobilenode, the data traffic will be intercepted by its closest home agent and redirected tothe home agent to which the mobile node is bound. We also introduce the concept of aGlobal Mobility eXchange (GMX), a dedicated overlay network that efficiently handlesdata traffic from and to mobile nodes, and that operates home agents, as would anInternet eXchange Point (IXP). This research was successfully deployed in a real BGPAutonomous System during Winter 2006.

Unlike other works that focus on end-to-end transport protocols or new routingarchitecture to provide mobility, our aim is to provide an Internet-Scale Mobility sys-tem that does not modify the existing architecture of the Internet. Our proposal isespecially interesting compared to other solutions as its deployments can be performedwith realistic operational and financial costs. In fact, if a mobility system is based onend-to-end communications like HIP [83], all of the nodes – mobile or not – must bemodified to benefit from the system (first design constraint in Section 1.3.3). Thus,during the deployment phase of this mobility system it is unlikely that many nodeswill really benefit from it. Likewise, modifications of the routing plane to supportmobility introduce important financial issues as core routers must be upgraded or re-placed (second design constraint). This will probably slow down the deployment ofsuch technologies. On the other hand, Home Agent Migration satisfies with the fourdesign requirements described in the Introduction: it maintains compliance with end-nodes regardless of whether they implement Mobile IPv6 or not, and only requires smallchanges on regular home agents. Since no modification is made to end-nodes our workcan be seamlessly embedded in a network, easing the deployment of an Internet-ScaleMobility system.

The rest of this chapter is organized as follows: we first introduce the concept of

Chapter 3. Home Agent Migration 37

Home Agent Migration in Section 3.1. Then, in Section 3.2, we provide lengthy detailsabout this proposal, and describe possible deployments. In Section 3.3, we presentoperational results from experiments performed in a real network. Finally, prior to theconclusion, we discuss related work in Section 3.4.

3.1 General overview

The underlying concept of the Home Agent Migration system is to disengage homeagents from the home link so as to distribute them in the Internet topology. The aimof this new kind of home agent deployment is to provide an efficient route optimizationscheme that (1) reduces communication latency, (2) is compatible with current speci-fication and implementation of Mobile IPv6’s mobile nodes, and (3) is transparent forcorrespondent nodes.

HA 1

ADSL subnetISP network

HA 2

HA 3

Wi-FI subnet

WiMAX subnet

node A

node B

node C

Figure 3.1: Home Agent Migration and different access technologies

The main scenario assumed while developing this solution is a mobile node roamingon a continent or country scale, i.e. from Tokyo to Paris. For example, home agentscould be globally distributed in every big city around the world in order to be closer tomost of mobile nodes and to provide seamless access to this architecture. While thisscenario mainly concerns worldwide operators, our solution also applies to smaller-scaledeployments. In particular, the Home Agent Migration is also useful to Internet ServiceProviders (ISP) delivering IP connectivity with several network access technologies suchas WiMAX and 802.11b. As shown in Figure 3.1, such an ISP can set up home agents in

38 3.1. General overview

each network that provides IP connectivity to the WiMAX, Wi-FI and ADSL networks.This causes the mobile nodes A, B, and C, to register with a home agent relative to theiraccess technology. As a consequence, they can keep the same IPv6 address when theyswitch from one access technology to another with a little communication overhead.

3.1.1 How it works

MN CN

Internet

HA 1 HA 2

Figure 3.2: Concept of Home Agent Migration

In the proposed architecture, multiple home agents advertising the same IPv6 prefixare deployed along the Internet topology as shown in Figure 3.2. This routing operation,known as anycast routing [69], is designed to solve load balancing and redundancyissues. Nowadays, it is mainly used to operate root DNS servers [34]. Home agents canuse any routing protocols such as BGP4+ [23], OSPFv3 [35], or RIPng [77] dependingon the scale of the system. Home agents are interconnected to form an overlay networkthat allows them to exchange mobile nodes’ data traffic as well as signaling packets.These interconnections can be created directly over the Internet or over dedicated high-speed backbones.

Figure 3.3 compares the network architectures of Mobile IPv6 and the proposedsystem. Due to the distribution of home agents in the Internet topology, a mobile nodewill always use the nearest home agent as if the home agent had migrated close to themobile node’s location. This closest home agent is referred to as the primary homeagent (P-HA in Figure 3.3(b)), since it receives the first Binding Update message sentby the mobile node. Similarly, packets sent by a correspondent node are routed to theirclosest home agent using generic IP routing mechanisms and are then forwarded to theprimary home agent over the fast backbone.


MN CN

b)

a) HA

InternetP-HA

Internet

HA 1 HA 2

Figure 3.3: Mobile IPv6 compared to Home Agent Migration

3.1.2 Typical deployments

There are two kinds of possible deployments for the Home Agent Migration architecture.They are linked to the routing protocol operated to advertise the mobile prefix and toperform the anycast routing. When an Interior Gateway Protocol (IGP) is used, thescope of Home Agent Migration is limited to a single Autonomous System (AS). Theachieved route optimization only concerns communications directed to mobile locatedin the AS. On the other hand, when an Exterior Gateway Protocol (EGP) is used,the prefix is distributed globally on the Internet. The optimization therefore concernsnodes located all over the Internet topology. We give the details of these deploymentsbelow. In both deployments, each home agent has an IPv6 address that is topologicallycorrect regarding its physical location, as well as an IPv6 address that belongs to themobile prefix.

1. In an Autonomous System

In this deployment, the mobile prefix is picked up from the set of IPv6 prefixesassociated with the Autonomous System. This mobile prefix is advertised fromdifferent routers in the network using an IGP such as OSPFv3. The choice ofthese routers and their numbers is left to network administrators. In Chapter 4,we will describe how to efficiently locate home agents in a given network topology


MSP 1

MSP 2

MSP 3

MN 1

Home Agent belonging to MSP N

MN 3

MN 1

GMX 1 GMX 2

CN

Figure 3.4: Concept of Global Mobile eXchange

using a graph theory approach. Depending on the Autonomous System, homeagents could be interconnected using direct links or VLAN1, so as to provide afast and reliable distribution system to synchronize the shared Binding Cacheand exchange mobile node’s data traffic. This IGP based deployment is moreflexible than the EGP based one, described below, as network administrators areable to efficiently place the home agent in the locations that provide the bestperformance within their network.

2. In the Internet

The mobile prefix must be associated to a dedicated Autonomous System num-ber. The Home Agent Migration architecture therefore looks like a distributedAutonomous System in regard to the Internet topology. The mobile prefix isadvertised from many different locations around the globe using an EGP suchas BGP. With this deployment, we take advantage of the current Internet in-frastructure that relies on Internet Exchange Points (IXPs). Tier-1 ISPs areinterconnected thought these IXPs, and use them to exchange most of their datatraffic. As a consequence, it is possible to efficiently deploy home agents in IXPsas rendez-vous points for mobility services. The home agents are operated with

1Virtual LAN.


a concept similar to an IXP; therefore, we call this deployment Global MobileeXchange (GMX).

The primary goals of GMX are to decrease the cost of the transit data trafficrelated to mobile nodes and to allow Internet-Scale Mobility services. Differentdeployments of GMX are possible depending on the number of providers manag-ing the mobility service. Figure 3.4 shows three Mobile Service Providers, MSP 1,MSP 2 and MSP 3, managing different two home agents each. These distributedhome agents are located where a Mobile Service Provider is physically connectedto an IXP. All MSPs are interconnected by home agents located in GMX1 andGMX2. In a GMX, home agents exchange traffic and routing information, as aregular router would do in an IXP. GMXs should be located where the concentra-tion of users (and thus data traffic) is high, so as to enhance performances. Forexample, in Tokyo and Osaka for a Japanese Mobile Service Provider. However,this EGP based deployment could be difficult to achieve, as it requires peeringagreements with Internet Service Providers located in IXPs where home agentsare placed.

In order to ease deployments over the Internet, a unique mobile prefix could bemanaged by a Mobile Service Operator (MSO) that operates all of the GMX aroundthe globe. The primary goals of the MSO are to advert the mobile prefix to theInternet using anycast routing, locally negotiate peering agreements, and assign partsof the mobile prefix addressing space to Mobile Service Providers. For example, theMSO could advert 2001:db8:cafe::/48 and provide smaller prefixes to MSP1 and MSP2such as 2001:db8:cafe:1::/64 and 2001:db8:cafe:2::/64. In other words, a MSO providesthe interconnection of various mobility services around the world. MSPs are only incharge of the installation and the operation of their own home agents, and do not needto take care of the anycast routing management. Concerning the routing architecture,announcing a single IPv6 prefix dedicated to mobility is beneficial as it reduces theimpact of Home Agent Migration on the size of routing tables. Indeed, increasing thenumber of mobile nodes and mobile service providers will have no impact on the routingarchitecture.

3.1.3 Advantages

While away from its home network, a mobile node will always be associated with thenearest home agent in terms of network topology. As home agents are distributedthroughout the Internet, signaling and data traffic can be distributed among home


agents, the home agent is no longer a performance bottleneck. Depending on homeagents locations, the distribution of the home agents also reduces delay and optimizesroutes.

As previously described, home agents are interconnected to exchange mobile nodes’binding information. In addition, they are also able to detect and report each other’sfailures. Therefore, when a mobile node’s primary home agent crashes, another homeagent can send a failure alert to the mobile node, and quickly take over the failedone. After receiving the alert, the mobile node sends a Binding Update message to thehome agent and resume communications immediately. As a consequence, unlike legacyMobile IPv6, Home Agent Migration is not vulnerable to constraints for the home linkas described in Section 2.2, and is able to handle home agents’ deficiencies.

Mobile IPv6’s route optimization procedure (i.e. Return Routability Procedure) hasa serious privacy issue, as a mobile node must disclose its Care-of Address. While thissolution allows end-nodes to use the optimal path between them, it also exposes the factthat the mobile node is not in its home network, but visiting another network. HomeAgent Migration does not disclose the mobile node’s Care-of Address, preserving itslocation privacy. In addition, unlike what happens when using the Return RoutabilityProcedure, the mobile node’s traffic cannot be eavesdropped in the visited network sincethe tunnel between the home agent and the mobile node can be securely protected withIPsec.

3.1.4 Drawbacks

Home Agent Migration relies on anycast routing to distribute home agents in networktopologies. As a result, it is threaten by routers failures and convergence time of routingprotocols. For example, if a router that controls a specific geographical region fails,mobile nodes cannot communicate anymore. Similarly, correspondent nodes are notable to send data packets to any mobile node. As a consequence, high care must betaken to manage routers that advert the mobile prefix and provide connectivity to thehome agents.

In order to achieve maximum benefit from Home Agent Migration deployments,the locations of the distributed home agents and their numbers must be meticulouslychosen. Simple deployments as done with Mobile IPv6 are no longer possible: adminis-trators need to plan which locations will be more efficient in terms of communicationsperformances. A formal solution to this issue is discussed in Chapter 4 along with analgorithm that select the home agents locations given a network topology.


3.2 Practical implementation

This section describes in details the behavior of the Home Agent Migration concerningthe communications between home agents, mobile nodes and correspondent nodes.

3.2.1 Notion of Binding Cache

The Binding Cache is a dedicated routing table that allows the home agents to knowif a mobile node is reachable, as well as the primary home agent that will be used toforward packets to the mobile node. For every mobile node, it maintains the relationshipbetween the Care-of Address, the Home Address and the home agent associated witha mobile node, which is called the primary home agent. The home agents share thesame Binding Cache. Therefore, they can always find out the primary home agent of aspecific mobile node, in order to forward it the mobile node’s data traffic.

In order to synchronize the Binding Cache, each home agent establishes a securedtunnel with other home agents and uses it to exchange signaling and traffic of mobilenodes. When a primary home agent receives a Binding Update message, it sends theresulting relationship to the other home agents over the tunnels. When a home agentreceives this relationship, it updates its own Binding Cache. This simple mesh-basedbinding synchronization can obviously be optimized to be more efficient. However, asit does not impact the mobile nodes’ performance, this mechanism is sufficient for ourpurpose, and the evaluation of the Home Agent Migration architecture.

When a mobile node sends a Binding Update message to a home agent, the MobileIPv6 specification requires that the home agent verifies the uniqueness of the HomeAddress on the home link, using the IPv6’s Duplicate Address Detection (DAD) mech-anism2 [105]. However, in our system, as this link is virtual, no DAD packet can besent on the home link. Consequently, this detection cannot be performed. Instead ofthe regular DAD mechanism, a home agent uses the Binding Cache in order to verifyif the Home Address is already associated to another mobile node.

3.2.2 Communication examples

Thanks to anycast routing and the distribution of the home agents all over the Internet,the home agents are able to efficiently intercept the packets sent to the mobile nodes.Consequently, the Home Agent Migration architecture can be seen as a vacuum forthe traffic destined to the mobile nodes. The following descriptions of communications

2in practice, it uses ICMPv6 Neighbor Discovery messages to check if the Home Address is not usedon the home link.

44 3.2. Practical implementation

HA 1 HA 2

HA 1 HA 2

a)

b)

MN CN

Figure 3.5: Home Agent Migration: communication examples

assume an architecture with two home agents HA1 and HA2 and two nodes, the mobilenode MN, closer to HA1, and the correspondent node CN, closer to HA2, as shown inFigure 3.5. The notion of proximity is given by the regular routing of packets from thenodes to the home agents. The MN is already associated with its primary home agent,HA1, and the Binding Caches of HA1 and HA2 are consistent.

From the MN to the CN (Figure 3.5-a): When the MN wants to send apacket to the CN, it sends it to its primary home agent over the tunnel. As there isno straightforward way to know which home agent is closer to the CN, HA1 directlysends the packet to the CN as a regular router does.

From the CN to the MN (Figure 3.5-b): When the CN sends a packet to theMN, it is intercepted by HA2 because of anycast routing. HA2 performs a lookup inthe Binding Cache to discover the primary home agent of MN. It sends the packet overthe secured tunnel that it maintains with HA1. Then, HA1 decapsulates the packetand sends it to MN over the tunnel they share.

The communications between two mobile nodes are similar to the previously de-scribed explanations except that data packets are always going through the two homeagents.


3.2.3 Movements of mobile nodes

In Mobile IPv6, the Dynamic Home Agent Address Discovery (DHAAD) mechanismis used by a mobile node to discover the home agent that it must use. Similarly in theHome Agent Migration system, it is necessary for a mobile node to find out its closesthome agent. As our proposal does not require any modification of the mobile node,this discovery is performed the same way in both systems. As described in the MobileIPv6 RFC, a Dynamic Home Agent Address Discovery (DHAAD) request is sent bythe mobile node to the specific IPv6 address identifying all of the home agents presenton the home link, as described in Chapter 2. When a home agent receives this message,it sends back a DHAAD reply including the list of reachable home agents. Thus, inour system this reply is used by the mobile node to discover the address of its primaryhome agent.

Each time that a mobile node enters a new subnetwork, and acquires a new Care-ofAddress, it must send a Dynamic Home Agent Address Discovery request and a BindingUpdate message. This is necessary as a mobile node is not able to find out if it willkeep the same primary home agent after a movement. Thanks to anycast routing, themessage is routed to the closest home agent that will reply to the mobile node. Whena change of home agents occurs, the mobile node does not need to de-register from theold home agent before sending a new Binding Update message to the new one. This isbecause all the home agents share the Binding Cache.

However, it is possible that the closest home agent remains the same after a move-ment: in this case the Binding Update message is sent to the same primary homeagent. For example, this will happen if a Japanese mobile node moves from Tokyo toYokohama3 and the Home Agent Migration architecture is only deployed in Tokyo andOsaka.

The change of home agent can also be performed in a reactive way if a home agentdetects that it is closer to a mobile node than the current primary home agent, HA1.The trigger occurs when a mobile node moves but for some reasons did not detectthat it is now closer to another home agent, HA2. As usual, the mobile node willsend a Binding Update message to its primary home agent (HA1). Due to the routingarchitecture, this message will however be routed to the new home agent (HA2), thenforwarded to the primary home agent (HA1) over the secured tunnel. As the primaryhome agent does not receive this Binding Update message on its physical networkinterface, it can detect that the mobile node moves, and that it is now closer to another

3south of Tokyo.


home agent (HA2). The primary home agent (HA1) will thus ask the mobile node tobind to the new home agent (HA2).

3.2.4 Example of a typical deployment

HA 4HA 3

HA 2HA 1

Internet

2001:db8::1 2001:db8::2

2001:db8::42001:db8::3

Virtual home link 12001:db8::/48




Figure 3.6: An example of home agents configuration

Figure 3.6 shows four home agents HA1 to HA4 serving the same IPv6 home prefix2001:db8::/48. Each home agent has a distinct home agent address from the samehome network prefix even if they are located in different networks. For example, in theFigure, HA1 has the address 2001:db8::1. Each home agent acts as a regular accessrouter for the virtually configured home link and intercepts packets meant for mobilenodes.

When multiple home agents are configured in different networks, each home agentshould know the other home agents beforehand and establish IPsec tunnels to ensuresecure paths with the other home agents. As previously explained in Chapter 2, withMobile IPv6, each home agent maintains a list of home agents located in the same homelink. However, the home agent list management mechanism requires that all the homeagents should be on the same link. Thus, in Home Agent Migration, a new messagecalled Hello is used to periodically exchange home agent information and to confirmhome agent availability. The home agent information carried by the Hello message is


indeed the same information as Router Advertisements sent by a home agent in MobileIPv6.

3.2.5 The underlying protocol

Figure 3.7 shows the packets exchanged in the Home Agent Migration system. Theprotocol is based on the Inter Home Agents protocol (HAHA) [112, 115, 106]. Amobile node (MN) first registers its binding to its primary home agent (Seq1). Theprimary home agent creates a binding for the Home Address of the mobile node, andthen sends a copy (BCU) to other home agents in order to synchronize the BindingCaches (Seq2). When a home agent receives the copy from the primary home agent, itupdates its Binding Cache.

When a mobile node communicates with a correspondent node, outgoing packetsfrom the mobile node are tunneled to the primary home agent (here HA1) (Seq3) andincoming packets to the mobile node are intercepted by the home agent HA2, whichis closer to the correspondent node. Then, the intercepted packets are tunneled to theprimary home agent. The primary home agent delivers the packets to the mobile nodethrough the IPv6-in-IPv6 tunnel (Seq4).

If the mobile node decides to switch its primary home agent because of its move-ment, it sends a Binding Update message to the new primary home agent (Seq7). Wedescribed in Section 3.2.3 how to discover the closest home agent. The new primaryhome agent then synchronizes the binding with other home agents (Seq8). After receiv-ing the Binding Update copy (BCU), all the home agents update the Binding Cache.

3.2.6 NEMO support

Home Agent Migration could easily be extended in order to provide route optimiza-tion to Network Mobility (NEMO). Small modifications to the shared Binding Cacheare sufficient to also take Mobile Network Prefixes into account: the Mobile NetworkPrefix information is also managed in a Binding Cache entry. Moreover, the networkprefixes associated with mobile routers must belong to the IPv6 prefix advertised by thedistributed home agents using anycast. However, the sub-NEMO scenario, describedin Chapter 2, cannot fully benefit from our proposal. For example, when node B,located in a sub-NEMO, wants to communicate with node A in a parent-NEMO, theperformance is similar to the performance of two mobile nodes communicating togetherthrough the same home agent. Data packets are not anymore routed to a distant homeagent as both tunnels terminate on the closest home agent. The overhead is thus equiv-


HA 1

P-HA

HA 2 CN 1 HA 3 CN 2

BU: Binding UpdateBA: Binding AcknowledgementBCU: Binding Copy Update

tunneled data packetdata packet send directlysignaling message

MN

P-HA

BU

BA

BCU

BCU

BU

BABCU

BCU

Seq1: Home Registration

Seq2: Sending BCU to HA2 & HA3

Seq3: Sending data packet to CN1 via HA1

Seq4: Sending data packet to MN via HA2

Seq5: Sending data packet to CN2 via HA1

Seq6: Sending data packet to MN via HA3 and HA1

Seq7: Home Registration

Seq8: Sending BCU to HA1 & HA3

Figure 3.7: Home Agent Migration: packets exchanges


alent to the Round Trip Time between the parent mobile router and the home agent.While this could be considered as huge in environments sensible to delay, our proposaldoes not alter the privacy and the security of the communications as IPsec protects thepackets between the home agent and the two mobile routers.

3.2.7 Security considerations

In a simple Home Agent Migration deployment, each home agent has a distinct homeagent address that belongs to the same home network prefix. Concerning the protec-tion provided by IPsec, this implies that each mobile node is pre-configured with fourSecurity Policies for each home agent. Two ensure the protection of Binding Updateand Binding Acknowledgment messages, and the two others the protection of the tun-nel4. The pre-configuration of these policies could be problematic, and could lead tooperational issues if home agents are added after the first deployments of mobile nodes.

An advanced deployment of Home Agent Migration could solve this problem. If allthe Home Agents share the same IPv6 address, only two Security Associations must bepre-configured for each mobile node. While promising, this architecture could lead toproblems concerning the interaction of the IPsec and Mobile IPv6 stacks especially onthe home agent side. In fact, in order to keep the IPsec sessions alive after a movement,the home agent would have to synchronize information and states about the negotiatedSecurity Associations.

The use of IPsec to secure the distribution system is however much simpler. In orderto synchronize the Binding Cache, home agents are interconnected using IPv6-in-IPv6tunnels in a mesh like fashion. Consequently, if the distribution system includes N

home agents, each home agent must be pre-configured with N − 1 security associationsto the other home agents.

3.3 Evaluation

In this section, we first describe the proposed solution in terms of exchanged signalingmessages and handover durations. Then, the results of a real Internet scale experimentare shown and discussed in terms of Round Trip Time between end-nodes.

4one Security Policy each way.

50 3.3. Evaluation

3.3.1 Performances comparisons

Smip6 = BU + BA (3.1)

Srrp = BU + BU + Ncn × (BU + BA + HoTi + HoT + CoTi + CoT ) (3.2)

Sham = BU + BA + Nha − 1 (3.3)

Putting Dynamic Home Agent Address Discovery aside, with Mobile IPv6’s ReturnRoutability Procedure, when a mobile node performs a handover it must advertise itsnew Care-of Address by exchanging Binding Update and Binding Acknowledgementmessages with its home agent, and possibly with each of its correspondent nodes. Priorto exchanging Binding Update and Binding Acknowledgement with a correspondentnode, the mobile node must send four signaling messages, as described in Chapter 2.The total number of exchanged messages is proportional to the number of correspondentnodes. With Home Agent Migration, a mobile node only registers with a single homeagent. However, assuming an inefficient mesh-based distribution system, this bindinginformation must be delivered to every home agent. With Mobile IPv6, the mobilenode simply exchanges a Binding Update and a Binding Acknowledgement with itshome agent. Equations 3.1, 3.2, and 3.3 represent the number of signaling messagesnecessary to handle a handover for Mobile IPv6 (Smip6), Mobile IPv6 with the ReturnRoutability Procedure (Srrp) and Home Agent Migration (Sham), respectively. Ncn andNha are the numbers of correspondent nodes and home agents. In terms of signalingmessages, the Home Agent Migration is therefore an improvement comparing to theReturn Routability Procedure. However, depending on the distribution system in use,it could require much more messages than Mobile IPv6.

Trrp = Rmnha +Ncn∑n=1

(Rmnha + Rhacn[n] + 2×Rmncn[n]) (3.4)

Tham = Rmnha +Nha−1∑n=1

Rhaha[n] (3.5)

Along with the number of signaling packet exchanged, the handover can also bestudied as the time to complete a new association to a home agent. As the processingtime of the signaling packets is not significant regarding their Round Trip Time (RTT),it is safe to describe the handover duration with the RTT. Equations 3.4 and 3.5represent this duration for Mobile IPv6 with the Return Routability Procedure (Trrp)


and Home Agent Migration (Tham). We define Rmnha to be the RTT between a mobilenode and its primary home agent, Rhacn[n] the RTT between the primary home agentand the n-th correspondent node, Rmncn[n] the RTT between a mobile node and then-th correspondent node, and Rhaha[n] the RTT between the primary home agent andthe n-th home agent. Rmncn[n] is bound by: Rmncn[n] ≤ (Rmnha + Rhacn[n]). Equation3.5 is straightforward: in Home Agent Migration a mobile node sends a Binding Updatemessage and receives a Binding Acknowledgement (Rmnha), the Binding Cache is thensynchronized among other home agents. Equation 3.4 is slightly more complicated, butdirectly comes from the operation of the Return Routability Procedure. The mobilenode first sends and receives Binding Update and Binding Acknowledgement messages(Rmnha), then for each correspondent node, it sends and receives a pair of Home ofTest init and Home of Test messages (Rmnha + Rhacn[n]), a pair of Care-of Test initand Care-of Test messages (Rmncn[n]), and finally the Binding Update and the BindingAcknowledgement messages (Rhacn[n]).

With the Return Routability Procedure, the handover duration increases propor-tionally with the number of correspondent nodes and the Rmnha increases as the mobilenode moves far away from its home agent. The last correspondent node that receivesa Binding Update message must wait as long as Trrp before it can use the optimizedpath with the mobile node. In Home Agent Migration, if home agents are carefullydistributed in the Internet, it is possible to bound Rmnha to a value not related to themobile nodes’ locations. Furthermore, the latest sum of Equation Tham can be limitedaccording to the solution used to distribute binding information. After the receptionof the Binding Acknowledgment message, a mobile node can directly tunnel data toits primary home agent and does not need to wait for the completion of binding in-formation distribution. The Home Agent Migration thus provides route optimizationwith better handover latency, especially if a larger number of correspondent nodes isinvolved.

3.3.2 Experimental results

In order to conduct our experiments, a userland daemon was developed using theKAME BSD IPv6 stack [15] and the advanced socket API [103, 30]. It is a lightweightversion of a regular home agent that also performs Binding Synchronization. Duringmost of the experiments we used SHISA [13], an implementation of Mobile IPv6 forBSD kernels, for the mobile nodes. However, in some locations as we were unableto set up real mobile nodes, we had to emulate them. These emulated mobile nodeswere implemented in the Python programming language using Scapy6 [109] which is

52 3.3. Evaluation

HA1 HA2 Tokyo Amsterdam Belgium San Francisco

HA1 - 110 0.52 297 292 141

HA2 110 - 110 188 194 30

Table 3.1: Round Trip Time in our experiment (in ms)

described later in Appendix A. We observed almost no difference between the resultsfor a real and an emulated mobile node.

San Francisco

Internet

WIDE's AS

Belgium

Tokyo

Amsterdam

HA 1 HA 2

Figure 3.8: Abstract network topology of the experimentation

Two home agents were setted up inside the WIDE project’s Autonomous System(AS). One was located in Los Angeles and the other one in Tokyo. In the AS, eachhome agent advertises the same IPv6 prefix using OSPFv3. The mobile node is locatedin San Francisco, and the correspondent nodes in Tokyo, Amsterdam, and in Belgium.The abstract topology used during the experiment is shown in Figure 3.8. Table 3.3.2details average Round Trip Times between all of the involved nodes. The operationalissue in this network is the link between Japan and the United States that goes underthe Pacific Ocean. The goal of this experiment is to use the Home Agent Migration inorder to avoid this link if the mobile nodes are not located in Japan.

The results of the experiment are presented in Figures 3.9 to 3.11 which show the


0

0.1

0.2

0.3

0.4

0.5

0 5 10 15 20 25 30 35 40

RTT

(sec

onds

)

Time (seconds)

(a) Direct Path

0

0.1

0.2

0.3

0.4

0.5

0 5 10 15 20 25 30 35 40

RTT

(sec

onds

)Time (seconds)

(b) Regular Mobile IPv6

0

0.1

0.2

0.3

0.4

0.5

0 5 10 15 20 25 30 35 40

RTT

(sec

onds

)

Time (seconds)

(c) Home Agent Migration

Figure 3.9: RTT between San Francisco and Tokyo

0

0.1

0.2

0.3

0.4

0.5

0 5 10 15 20 25 30 35 40

RTT

(sec

onds

)

Time (seconds)

(a) Direct Path

0

0.1

0.2

0.3

0.4

0.5

0 5 10 15 20 25 30 35 40

RTT

(sec

onds

)

Time (seconds)


0

0.1

0.2

0.3

0.4

0.5

0 5 10 15 20 25 30 35 40

RTT

(sec

onds

)

Time (seconds)


Figure 3.10: RTT between San Francisco and Amsterdam

0

0.1

0.2

0.3

0.4

0.5

0 5 10 15 20 25 30 35 40

RTT

(sec

onds

)

Time (seconds)

(a) Direct Path

0

0.1

0.2

0.3

0.4

0.5

0 5 10 15 20 25 30 35 40

RTT

(sec

onds

)

Time (seconds)


0

0.1

0.2

0.3

0.4

0.5

0 5 10 15 20 25 30 35 40

RTT

(sec

onds

)

Time (seconds)


Figure 3.11: RTT between San Francisco and Belgium

54 3.3. Evaluation

Round Trip Time for communications between the mobile node and the correspondentnodes in three different scenarios; (a) show the Round Trip Time when Mobile IPv6 isnot used (i.e. direct path), (b) when Mobile IPv6 is used, and (c) when Home AgentMigration is deployed. Note that for Mobile IPv6, we used HA1 as the home agent. Nomore than the first forty seconds of the experiment are represented here so as to makethe plots easily readable.

When the mobile node is located in San Francisco and the correspondent node inTokyo, Figure 3.9, the average Round Trip Time is almost the same (around 142 ms)in the three cases. These results were expected as HA1 and HA2 are both located onthe direct communication path between the correspondent node and the mobile node.The negligible overhead of the Home Agent Migration is caused by the tunnel betweenHA1 and HA2 and is dependent on our Home Agent Migration implementation. Whenhome agents are carefully deployed on the Internet, Mobile IPv6 does not provideany overhead. With this pair of nodes, no benefit arose from Home Agent Migration;however, the performance is the same as with regular Mobile IPv6.

In Figure 3.10, the mobile node is located in San Francisco and the correspondentnode in Amsterdam. In this scenario, HA2 located in Los Angeles is obviously closerto the mobile node and is automatically selected as the primary home agent for HomeAgent Migration. As a result, the average Round Trip Time with Home Agent Migra-tion is 220 ms smaller than the Round Trip Time when legacy Mobile IPv6 is used,and the traffic goes through HA1, see Figure 3.10(b). This difference is caused by thelatency of packets traveling under the Pacific Ocean as shown in Table 3.3.2. WhenHome Agent Migration is used, the average Round Trip Time is exactly the same asthe direct communication path. Therefore, Home Agent Migration allows the use ofMobile IPv6 with no significant Round Trip Time overhead.

In Figure 3.11, the mobile node is located in San Francisco and the correspondentnode in Belgium. Whereas results are expected to be the same as in Figure 3.10,the optimized Round Trip Time, when HA2 is used, is not the same as the directcommunication path. When the Home Agent Migration is used, the path from SanFrancisco to Belgium is through the nearest home agent (i.e. HA2), while the reversepath is via Tokyo (i.e. HA1) due to BGP peerings. Although the Round Trip Timeis smaller than the one with regular Mobile IPv6, Home Agent Migration does notprovide an improvement as important as in the previous case.

The critical aspect of Home Agent Migration in a single Autonomous System is thecorrect placement of the home agents in the network topology. In order to achieve thebest performance, the home agents should be located on the direct communication path


between mobile nodes and correspondent nodes. Moreover, if the path is not symmetric,the optimization provided by our proposal is only partial. This last issue can be resolvedby the administrators of the Autonomous System if they carefully configure the costsof paths using routing protocols. For Internet-Scale deployments using GMX, thehome agents are located in important Internet eXchange Points, and are thus on thedirect communication path between most mobile and correspondent nodes. Maximumperformance can therefore be achieved as the paths cannot be asymmetric anymore.

3.4 Related Work

In this section, we introduce and compare several approaches aiming, like Home AgentMigration, at providing better route optimization for Mobile IPv6.

Previous works in route optimization [66, 85, 114] involve caching binding informa-tion in the correspondent nodes and in routers on-demand. However, these end-to-endoptimizations also introduce the issues described in Chapter 2: modifications of end-nodes and complexity of operation. Unlike these systems, Home Agent Migration isdesigned to be transparent to end-nodes and only requires small changes in home agents.

Several regional and hierarchical approaches for reducing the binding overhead havebeen proposed [29, 24, 52, 90, 60]. The underlying concept of these efforts is to enablea mobile node to associate with a closer agent instead of its home agent. Although thedesign concept looks similar to Home Agent Migration in terms of home agent distri-bution, these studies significantly modify the implementations of the mobile nodes. Forexample, HMIPv6 [29] requires the mobile node to manage several Care-of Addresses.

Efficient dynamic assignment of home agents have also been introduced to provideoptimal routing between end-nodes. Mobile IPv6 regional mobility management [84]uses a Regional Anchor Point (RAP) located in the network that the mobile nodes visitin order to optimize routes. The NASA and Cisco investigated multiple home agentsetups in an Autonomous System [63]. By assigning priority to home agents, mobilenodes can be associated with a closer home agent. This approach is similar HomeAgent Migration but the choice of the primary home agent is performed using accesslists. In order to set up access lists, the system operator must know beforehand thepattern of mobile node movements. In contrast to this system, Home Agent Migrationdynamically selects the closest home agent using anycast routing.

Finally, the home agent reliability protocol [111] provides redundancy and reliabilityto Mobile IPv6 by duplicating the home agents on the home link. It exchanges mobilenode registration information among home agents. If a home agent fails, another home

56 3.5. Conclusion

agent automatically takes its place in order to seamlessly ensure the continuity of amobile node’s connections. There are several similar works such as the Home AgentRedundancy Protocol (HARP) [31] and Virtual Home Agent Reliability (VHAR) pro-tocol [48]. However, the main drawback of these systems is that they only activate onehome agent at a time. In the Home Agent Migration, every home agent are alwaysactive. Furthermore, our proposal is not affected if the home link becomes unreachable.

3.5 Conclusion

We described a new architecture for Internet-Scale Mobility deployment called HomeAgent Migration. This proposal efficiently solves Mobile IPv6 limitations such as pro-tocol scalability and reliability, and redundant communication paths. In our solution,unlike in Mobile IPv6, multiple home agents are distributed over the Internet, andadvertise the same IPv6 prefix using anycast routing. The mobile nodes only see onehome agent and do not need to know about the other ones. From any location, theyare always associated with their closest home agent in terms of the network topology.Therefore, if home agents are carefully distributed, it is possible to improve the delaybetween a home agent and a mobile node located anywhere on the Internet. Com-pared to other route optimization schemes, Home Agent Migration does not requireany modifications on end-nodes and offers performances similar to a communicationwithout Mobile IPv6. In addition, it can also be applied to the Network Mobility(NEMO) basic protocol [43], as it is just an extension of Mobile IPv6. The only differ-ence is that home agents must also exchange Mobile Network Prefixes. Our proposalis especially useful for NEMO as no route optimization procedure is yet standardizedat the IETF.

However, we identified some issues that must be taken into account while deployingthe Home Agent Migration system. When routing paths are not symmetric, the perfor-mance offered by our solution is not as good as direct communication; thus, the benefitis only effective in one way. We performed experiments that validated our assumptionsabout the optimizing effect on the performance of the Mobile IPv6 protocol and showedthat the solution can be deployed on the actual Internet architecture.

In our future work, we will focus mainly on scalability issues. In fact, in the actualproposal, a simplistic mesh-based protocol is used to distribute binding informationbetween home agents, and we are investing the use of Distributed Hash Tables toenhance the performance of the binding synchronization between home agents. Besides,we will also study the effects of our scheme on the scaling of BGP routing.


From a standardization point of view, we want to submit an Internet Draft (ID)to the IETF in order to start discussions about Home Agent Migration with the Mo-bile IPv6 community. Moreover, we would like to debate the shortcoming and thepossible requirements concerning the use of IPsec with our proposal. This could leadto necessary modifications of the Internet Key Exchange (IKE) protocol concerningmobility.

Finally, from an operator point of view, it is necessary to study the feasibility ofGlobal Mobility eXchange and validate its business model. As a matter of fact, anoperator will require that Home Agent Migration could be integrated into standardAuthentication, Authorization, and Accounting (AAA) frameworks prior to any com-mercial deployment.

Chapter 4Mobile IPv6 deployments

Contents

4.1 Graph theory reminders . . . . . . . . . . . . . . . . . . . . . 60

4.1.1 Preliminary definitions . . . . . . . . . . . . . . . . . . . . . . 60

4.1.2 Importance of vertices . . . . . . . . . . . . . . . . . . . . . . 62

4.2 Networks as graphs . . . . . . . . . . . . . . . . . . . . . . . . 63

4.2.1 Observing networks . . . . . . . . . . . . . . . . . . . . . . . 64

4.2.2 Modeling networks . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2.3 Weights on edges . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3 Home Agents locations . . . . . . . . . . . . . . . . . . . . . . 66

4.3.1 Impact on paths lengths . . . . . . . . . . . . . . . . . . . . . 66

4.3.2 Optimal locations . . . . . . . . . . . . . . . . . . . . . . . . 68

4.3.3 Comparison methodology . . . . . . . . . . . . . . . . . . . . 68

4.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.4.1 Studied networks . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.4.2 Relationship between the degree and the betweenness . . . . 72

4.4.3 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.4.4 Home Agent Migration . . . . . . . . . . . . . . . . . . . . . 78

4.5 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

60 4.1. Graph theory reminders

In Mobile IPv6, as formerly outlined, the accurate location of the home agent is acritical aspect since it impacts communication delays and path lengths. Here, we modeloperator’s networks as graphs and formally describe the impact of the dogleg routingaccording to the home agent’s locations using well-known graph metrics. In particu-lar, we use notions of centrality in graphs to identify relevant home agents locations.Based on these observations, we describe a generic methodology to address Mobile IPv6deployment issues, which could be applied to any operator network. Our proposal issingular compared to other solutions, such as the Return Routability Procedure, sincethe optimization of paths is only achieved with a correct placement of home agents, andis non-intrusive protocol-wise. Consequently, it can immediately be used to enhanceMobile IPv6 deployments, and remain compatible with Mobile IPv6-based protocols,such as NEMO, as well as the current Internet architecture.

The rest of this chapter is organized as follows: we first recall the graph theorynotions [25] used in our discussions in Section 4.1. Then in Section 4.2, we brieflydiscuss several techniques commonly used to obtain graph models of communicationnetworks. In Section 4.3, we formally define the impact of Mobile IPv6 and HomeAgent Migration on path lengths, and discuss a methodology for comparing homeagent locations. In Section 4.4, we numerically evaluate this methodology using real-world network topologies. Finally, prior to the conclusion, we examine related work inSection 4.5.

4.1 Graph theory reminders

4.1.1 Preliminary definitions

An undirected graph G = (V,E) is defined by two finite sets: V , the set of vertices,and E ∈ V × V , the set of edges. Each edge e = (x, y) is a pair of vertices calledextremities1 of the edge e. We define n = |V | and m = |E| as the number of verticesand edges in G. In following discussions, we only consider undirected graphs ((u, v) and(v, u) are equivalent) without any loop (edges of the type (u, u)) and without paralleledges: the edge (u, v) is unique (which implies that the edge (v, u) does not exist). Anexample of such a graph is represented in Figure 4.1(a).

A weighted graph Gw, Figure 4.1(b), is a graph in which to each edge e in E isassociated a positive real value ω(e) ≥ 1 that we call weight. An unweighted graph isequivalent to a weighted graph in which each edge has weight one. As a consequence,

1or end-vertices.

Chapter 4. Mobile IPv6 deployments 61

a b

c d

e

f

(a) Undirected graph

D G

E F

A

C

B

1000

42

1

1

10

200 28

(b) Weighted undirected graph

Figure 4.1: Examples of unweighted and weighted graphs

algorithms presented in subsequent sections of this chapter will only consider weightedgraphs.

A path between two vertices x and y is a sequence of vertices (x = v1, v2, ..., vk = y)such there is an edge (vi, vi+1) ∀i, 1 ≤ i ≤ k− 1. In Figure 4.1(a) and 4.1(b), (a, e, b, d)and (A,B, G) are paths.

The length of a path P is defined as the sum of its edges’ weights. We note itl(P ). In Figure 4.1(a), we have l(a, e, d, b) = 3. Likewise, in Figure 4.1(b), we havel(A,B, C, F ) = 1242.

A shortest path between two vertices x and y is a path between x and y withminimal length. In Figure 4.1(b), the path (A,B, G, F, C) is the unique shortest pathfrom A to C. In Figure 4.1(a), paths (c, a, e) and (c, d, e) are both shortest paths fromc to e.

The distance between two vertices x and y is the length of a shortest path fromx to y. We note it d(x, y). If x = y, we have d(x, y) = 0. For all x, y, we haved(x, y) = d(y, x). For all x, y, z, we have d(x, z) <= d(x, y) + d(y, z). In Figure 4.1(a)and Figure 4.1(b), we respectively have d(a, d) = 2 and d(B,C) = 238.

The degree of a vertex x is the number of edges that end in x. We note it δ(x).For example in Figure 4.1(a), we have: δ(a) = 2, δ(e) = 3 and δ(f) = 1. In thefollowing, we will only consider graphs in which there is no isolated vertex, so that∀i ∈ V, δ(i) ≥ 1.

62 4.1. Graph theory reminders

B

C

A D E

G

H

F I

3000

Figure 4.2: Centrality: example graph

4.1.2 Importance of vertices

Centrality is a notion that aims at capturing the importance of vertices within a graph:a vertex with a high centrality belongs to a high number of shortest paths. In otherwords, such a vertex has a strong position within the graph. Likewise, a vertex with asmall centrality belongs to few shortest paths. Concerning a communication networklike the Internet, a router with a high centrality will be on most communication pathswithin the network. Correspondingly, a router with a small centrality2 will only gathercommunications from nodes connected to its egress network interface.

Centrality consequently provides an interesting estimate to calculate the importanceof a vertex inside a graph. It is frequently used in various scientific fields such associology, or epidemiology. Indeed, sociologists consider the centrality as an importantmeasure in social networks [53]. For example, they use it to pinpoint highly connectedpeople in relationships graphs. Likewise, it is used to identify how a viral infection willspread in a given graph, and which highly connected vertices should be protected orcured to limit the epidemic [40].

Several measures of centrality were defined so far, namely betweenness, closeness,and eigenvector centrality. They all define the importance of a vertex using well-knowngraph metrics such as the distances, or shortest paths. In our study, we only consider thebetweenness centrality as it provides good results in identifying home agents locations.

The betweenness centrality of a vertex x, noted CB(x), describes the position of x

regarding all shortest paths in the graph to which x belongs. For a given vertex x, thebetweenness centrality is equal to:

2located in a subnetwork, for example.


Node Betweenness Betweenness & weights

A 1 14

B 6 0

C 6 24

D 31 30

E 32 32

F 31 31

G 6 6

H 6 6

I 1 1

Table 4.1: Comparison of centrality values for the graph of Figure 4.2

CB(x) =∑

y 6=z 6=x∈V

ρyz(x)ρyz

, (4.1)

where ρyz is the number of shortest paths from y to z, and ρyz(x) the number of shortestpaths from y to z that contains x.

The betweenness centrality is affected by weights on edges. In Figure 4.2, whenthe graph is considered as unweighted (i.e all edges weights are equal to 1), we haveCB(A) = 1 and CB(C) = 6. If we take weights into account, we now have CB(A) = 14and CB(C) = 24. Table 4.1 gives the betweenness centrality values for the graph inFigure 4.2. One can easily see the influence of weights on the betweenness centrality.When a high weight is associated to the edge (B,D), the node B does not belong to anyshortest path. As a consequence, its betweenness centrality is equal to zero. Similarly,node A becomes more important in the graph as it belongs to all of the shortest pathsto node B.

4.2 Networks as graphs

In order to use graph metrics to find relevant locations for home agents, networks mustbe represented as graphs. In this section, we explain how we do this. Obtaining anaccurate model of a communication network like the Internet is currently a challenging

64 4.2. Networks as graphs

task, and represents an entire research topic in itself. Here, we first provide an overviewof common techniques currently used to acquire snapshots of communication networks.Then, we describe how we manipulate this data, and what vertices and edges in thegraph represent from a network perspective.

4.2.1 Observing networks

Different techniques are commonly used to acquire knowledge about communicationsnetworks. Here, we describe three main techniques and briefly discuss their advantagesand shortcomings. As a matter of fact, while observing network topologies, two mainproblems can occur: some routers are not discovered at all, and some routers appearmore than once (because they have one IP address per network interface).

The first category of approaches relies on active measurements to probe thenetwork and discover routers as well as links between them. Such measurements usevariants of the well-known traceroute tool. In practice, the observed topology mightdiffer from the real one in several aspects. So as to obtain more accurate information,several new techniques were defined to identify all of the IPv6 addresses that belongto the same router [102], performing faster network discoveries [76], or identify routersthan perform load balancing [21].

The second category uses information contained in routing tables to deduce thenetwork topology. Depending on the considered routing protocol, the granularity ofthe obtained information will differ. For example, if OSPF is used, one can obtaina precise view of routers and links in the same Autonomous System; when BGP isused, the graph will only contain links between Autonomous Systems. Compared totraceroute-like measurements, the use of routing tables usually provides a more preciseview of the network. However, OSPF routing tables are usually not publicly available,and BGP ones are only accessible from a limited set of routers such as provided by theRoute Views project [12]. The principal advantage of this approach is that routers caneasily be uniquely distinguished using identifiers carried by routing protocols. Whileconsidering BGP, the main drawback is that the resulting graph might be partial dueto filtering and prefixes aggregations commonly performed in BGP peerings.

Finally, the last category of approaches relies on information provided directly bynetwork administrators. By far, they will result in the most accurate informationon the topology either at Layer-2 or Layer-3. However, this information is also difficultto obtain because private companies often consider it as sensible. As a consequence,such graphs models are only possible in academic or research networks and contain arather limited number of nodes.


(a) (b)

Figure 4.3: Relation between a Network Operating Center and graph vertex

4.2.2 Modeling networks

In the graphs that we will manipulate in this chapter, we mostly consider that eachvertex is a single router, and that edges correspond to physical or virtual3 links betweenthem. Still, whenever possible, we tried to aggregate routers located in the sameNetwork Operating Center into a single vertex. As these routers are interconnectedwith high-speed links, the Round Trip Times between them can be neglected and it issafe to represent them as a single vertex in our model. This aggregation reduces thenumber of vertices and consequently decreases the computation times. Furthermore,it makes it easier to identify locations of home agents that deliver good performancesince it is not significant to compare routers that are physically in the same NetworkOperating Center. Figure 4.3(a) shows several routers located in a Network OperatingCenter in Tokyo, while Figure 4.3(b) shows the resulting aggregation. The links betweenthese routers are removed, but all of the external links to other routers are preserved.

4.2.3 Weights on edges

Weights on graph edges can be used to represent more accurately the observed networktopologies. In a networking context, edges can for example be weighted using costsinternally used by routing protocols, or Round Trip Times between vertices4.

3like MPLS or tunnel based links.4routers, or Network Operating Center.

66 4.3. Home Agents locations

Such routing costs express specific routing optimizations made by networks admin-istrators. Moreover, the costs help to differentiate network links and reflect that someare more important than others: high routing costs are for example used to refrain theusage of transit links in favor of peering ones. When information about networks comesfrom routing tables, routing costs are directly available.

Likewise, Round Trip Times between routers can also be used as edges weights.They help in reflecting the real expected network delays between any pair of vertices.A cumbersome yet efficient way to gather these values is to log into routers and tolaunch the ping command to evaluate the average Round Trip Time on each edgebetween routers. However as this might not be possible, Round Trip Times valuescould also be inferred using outputs of the traceroute tool.

4.3 Home Agents locations

In this section, we formally define the impact of Mobile IPv6 and Home Agent Mi-gration on paths lengths. Then, we discuss the influence of home agents locations oncommunications. Finally, we provide details about the comparison methodology thatwe will later use in the evaluation presented in Section 4.4.

4.3.1 Impact on paths lengths

We now discuss the influence of the Mobile IPv6 and Home Agent Migration protocolon the paths length between two vertices in a graph, both in weighted and unweightedgraphs. Vertices in the graph independently represent locations of home agents, mo-bile nodes or correspondent nodes depending on the discussions. We define two newnotations, such as dmip6(A,B) and dham(A,B) denote the length of a shortest com-munication path from A to B when Mobile IPv6 or Home Agent Migration is used,respectively. From now, we will call them communication distances. The length of sucha path is in general larger than the distance between A and B, because the communi-cation path has to go through one or two home agents depending on the case.

Mobile IPv6

With Mobile IPv6, packets exchanged between two (correspondent or mobile) nodes Aand B must go through the home agent HA. By definition, the resulting path lengthbetween A and B is the sum of the distances between A and HA, and between HA andB:


dmip6(A,B) = d(A,HA) + d(HA, B) (4.2)

Note that with Mobile IPv6, the paths between a mobile node and a correspondentnode are symmetric. Therefore, communications between mobile nodes and correspon-dent nodes are equivalent to communications between correspondent nodes and mobilenodes.

Home Agent Migration

Contrary to Mobile IPv6, communications between correspondent and mobile nodes arein general not symmetric when Home Agent Migration is used. As a consequence, weneed to consider separately the three possible communications patterns: between twomobile nodes MN1 and MN2, from a mobile node MN to a correspondent node CN ,and finally from a correspondent node CN to a mobile node MN . In the followingequations, the notation HAX represents the home agent that is closest to node X

according to anycast routing.Concerning communications between two mobile nodes, the length of the communi-

cation path between MN1 and MN2 is simply the sum of the distances between MN1and its primary home agent HAMN1, between HAMN1 and HAMN2, and betweenMN2 and its primary home agent HAMN2:

dham(MN1,MN2) = d(MN1,HAMN1) + d(HAMN1,HAMN2) (4.3)

+ d(HAMN2,MN2)

Concerning communications between a correspondent node and a mobile node, thebehavior is the same:

dham(CN, MN) = d(CN, HACN ) + d(HACN ,HAMN ) (4.4)

+ d(HAMN , CN)

On the other hand concerning mobile nodes to correspondent nodes communica-tions, the path goes only through the primary home agent of the mobile node:

68 4.3. Home Agents locations

dham(MN, CN) = d(MN, HAMN ) + d(HAMN , CN) (4.5)

4.3.2 Optimal locations

Regarding Mobile IPv6, when the path length between two nodes A and B is not alteredby the dogleg routing, i.e. d(A,B) = dmip6(A,B), the home agent is located on theshortest path between A and B. For instance, in the graph of Figure 4.2, if the homeagent is located in E, the path realizing dmip6(C,H) is (C,D,E, F, H). Consequently,good home agent locations correspond to vertices that belong to a maximum numberof shortest paths in the graph, i.e. vertices with the highest betweenness centralitymeasures.

A similar discussion applies to Home Agent Migration: when two mobile nodesMN1 and MN2 communicate5, the two primary home agents HAMN1 and HAMN2

must be on the shortest path between MN1 and MN2 to obtain performances similarto the direct communication, i.e. d(MN1,MN2) = dham(MN1,MN2). With HomeAgent Migration, increasing the number of home agents enables the mobility systemto control more shortest paths and, as a result, allows to achieve better performances.Finding out the best arrangement of a limited number home agents is a difficult andcomputationally expensive task. Indeed, it implies computing all of the possible homeagents arrangements, then recomputing paths lengths according to home agents loca-tions, and finally comparing the resulting modified distances with the direct distances.

4.3.3 Comparison methodology

We will now focus on the methodology and algorithms that we use to study the impactof home agents locations. They will be used in the evaluation Section 4.4. We comparehome agents locations by placing home agents, mobile and correspondents nodes inall vertices, and comparing the distance between two vertices to the communicationdistances with dmip6 and dham. Two different strategies are used to identify relevantlocations for home agents: one uses the degree, and the other one the betweennesscentrality.

In Internet-like graphs, the betweenness and the degree centrality can be correlated.It has been shown that, to some extent, the betweenness of a vertex is proportional

5also true with communications from a correspondent node to a mobile node.


to its degree [39]. This is an important result concerning the upcoming evaluation inunweighted graph as degree can be computed faster than betweenness.

Computing distances

As previously described in Section 4.3.1, the communication distances in Mobile IPv6and Home Agent Migration can be expressed as sums of distances between verticeswhere mobile nodes, home agents and correspondent nodes are located. We thereforeneed to first compute the distances between all pairs of vertices in the graph. Dis-tances are stored in the array distances, we note distances[A][B] the distance betweenvertices A and B. As we only consider undirected graph, we have distances[A][B] =distances[B][A]. We use the Floyd-Warshall algorithm [50] to compute the distancesbetween all pair of vertices, and to build the array distances.

Degree and Betweenness centrality

The degree is directly computed using the number of edges each vertex has. We keep anarray degree for vertices degrees. Moreover, we note sd, sorted degree, a list of verticesordered by their degree in decreasing order. sd[i] is the i-th node in decreasing degree,sd[0] is the node with the highest degree, and sd[n − 1] the node with the smallestdegree.

We compute the betweenness centrality using the algorithm designed by Brandes[107] which is, as of today, the fastest known algorithm to compute it. It outputs anarray of betweenness centrality values noted betweenness. Moreover, we note sb, sortedbetweenness, a list of vertices ordered by decreasing betweenness centrality, similarlyto sd.

Anycast routing emulation

With Home Agent Migration, a mobile node is always associated with its topologicallyclosest home agent. Likewise, packets sent from a correspondent node to a mobile nodeare intercepted by the home agent that is the closest to the correspondent node. Inpractice, these automatic selections of home agents are accomplished thanks to anycastrouting, and the routing protocols used to advert the mobile prefix to the network, asdescribed in Section 3.1.2.

When studying Home Agent Migration from a graph theory perspective, the au-tomatic selection of home agents must be adapted and redefined using graph basedmethods. So as to emulate anycast routing, we consider that primary home agents are

70 4.4. Evaluation

chosen according to their distances to mobile or correspondent nodes. Given an array ofdistances in the graph, distances, a list of home agents used in Home Agent Migration,ha, and a node, n, we define the select pha() function that returns the closest homeagent to node n, i.e. the vertex with the minimum distance to n. When two homeagents are equally distant from the node, the preference is given to the first home agentthat appears in the home agent list ha.

With the distances array preliminary computed, it is then straightforward to de-termine the new distances with Home Agent Migration and Mobile IPv6 based on thefollowing sums. We note pha1 and pha2 the primary home agents of mn1 and mn2respectively, as selected by the select pha() function.

dmip6[mn1][mn2] = distances[mn1][ha] + distances[ha][mn2] (4.6)

dham[mn1][mn2] = distances[mn1][pha1] + distances[pha1][pha2] (4.7)

+ distances[pha2][mn2]

We can now define an algorithm that will compute the communication distanceswhen Mobile IPv6 and Home Agent Migration are considered. Algorithm 1 describeshow to compute all distances using the distances array, a list of home agents ha, andthe list of all nodes in the graph nodes. The same algorithm is used to computedistances with Mobile IPv6 and Home Agent Migration, the detection of the mobilityprotocol used is based on the length of the ha (line β). If the length is equal to one,Mobile IPv6 is considered: Mobile IPv6 is indeed similar to Home Agent Migrationwith a single home agent. If the length is greater than one, Home Agent Migration isconsidered. Line α is an optimization that uses the fact that d(pha1, pha2) = 0 whenpha1 = pha2 to merge computations of path lengths with Mobile IPv6 and Home AgentMigration. For better efficiency, primary home agents can be computed beforehand andstored in an array that could be used to replace calls to the select pha() function inthe algorithm.

4.4 Evaluation

In this Section, we provide an evaluation of home agent locations based on the method-ology previously described in Section 4.3, and compare the two location strategies(according to degree and betweenness centrality in increasing order). We first describethe three graphs that we will use for this evaluation. Then, we separately discuss Mo-


Algorithm 1: Distances and mobility protocols

Input: distances: array of distances, ha: list of home agents, nodes: list ofnodes in the graph

new distances = {};forall start ∈ nodes do

forall end ∈ nodes doβ if len(ha) > 1 then

/* Home Agent Migration */pha1 = select pha(ha, start) ;pha2 = select pha(ha, end) ;

else/* Mobile IPv6 */pha1 = pha2 = ha[0] /* first element of the list */

endα new distances[start][end] = distances[start][pha1]

new distances[start][end] += distances[pha1][pha2]new distances[start][end] += distances[pha2][end]

endreturn new distances ;

end

bile IPv6 and Home Agent Migration, and show that it is possible to minimize theirimpact on path lengths by judiciously choosing the home agent locations.

4.4.1 Studied networks

Here, we consider three graphs that represent the following communications networks:

1. GEANT: this graph represents the GEANT network: a European research networkspread over thirty countries. This graph was built using information about thelayer 2 topology released on December 2004 on the GEANT web page [5]. Itcontains 63 vertices. Edges are weighted using routing costs6 provided along withthe layer 2 topology.

2. WIDE: it represents the WIDE project’s network: a Japanese research networkconnecting university campuses. This graph was obtained using layer 2 topologyinformation privately available to members of the project, then refined based onpersonal discussions with the network administrators. It contains 28 nodes thatcorrespond to Network Operating Centers, campus networks, as well as peering

6the ISIS routing protocol is used in GEANT.

72 4.4. Evaluation

10

100

1000

1 2 3 4 5 6 7 8 9 10

betw

eenn

ess

degree

(a) GEANT

0.01

0.1

1

10

100

1000

10000

100000

1e+06

1e+07

0 20 40 60 80 100 120

betw

eenn

ess

degree

(b) V6-MAP

Figure 4.4: Degree against betweenness centrality

points. As described in Section 4.2.2, aggregations of several routers into a singlevertex were performed. Edges are not weighted.

3. V6-MAP: this graph represents the layer 3 IPv6 topology of the Internet producedon June 2003 using the network cartographer (nec) tool [9]. It is publicly availableon the project web page. This tool sends traceroute queries to a set of distributedservers and is able to identify IPv6 addresses that belong to the same router inorder to combine them into a single vertex. Moreover, it merges the differenttopologies discovered by the traceroute servers. The graph contains 4256 vertices.Edges are not weighted.

4.4.2 Relationship between the degree and the betweenness

As previously discussed, the degree is directly retrieved using the graph descriptionwhile the betweenness centrality is much more expensive to calculate since it requiresto search the graph and compute all shortest paths between any pairs of vertices. Asa consequence, prior to comparing the degree and the betweenness centrality as homeagents placement strategies, we will study how these two measures are related in thethree studied graphs.

Figures 4.4(a) and 4.4(b) represent the betweenness centrality values, in log scale,plotted against the degree values. The betweenness centrality was computed withoutusing weights on edges in order to strictly compare the graphs structures. While theresults of the WIDE graph are similar to the ones given in this section, their visualrepresentation is not significant enough to be provided.


A

B

C

D

subgraph 1 subgraph 2

E

F

Figure 4.5: Degree against betweenness centrality: example graph

Both figures indicate that vertices that have the highest degrees also have the highestbetweenness centrality values. This is a remarkable property concerning our placementstrategies as we proposed to locate home agents in vertices that have the highest degreeand betweenness centrality values. Such a property is indeed not symmetric. FromFigure 4.4(b), it is clear that vertices with a small degree do not have necessarily asmall betweenness centrality value.

While this is somehow a counter-intuitive result, it could easily be illustrated usingthe example graph in Figure 4.5. We consider that the two subgraphs 1 and 2 containmany vertices that are not represented for convenience. Nodes D, E, and F have asmall degree (2), whereas node B has a high degree (6). However, both nodes D andB have a high betweenness centrality value: they are on the same number of shortestpaths between vertices in the subgraph 1 and vertices in the subgraph 2.

In practice, the relation between high degree and high betweenness is especiallyinteresting. Indeed, it could be used by system administrators that want to deployMobile IPv6, but can not apply our graph based strategies because they do not havea graph model of their network. They could instead locate the home agent close tohighly connected Network Operating Centers or routers; i.e. with a high degree.

4.4.3 Mobile IPv6

In Mobile IPv6, the communications between two mobile nodes, and between a mobilenode and a correspondent node are equivalent: all packets must go through the homeagent. As a consequence, in this evaluation, we will only consider the influence of homeagent locations on communications between two mobile nodes.

From a deployment point of view, Mobile IPv6 is still a young protocol. As oftoday, it has never been commercially deployed; its practical usage is mainly limited

74 4.4. Evaluation

0

20

40

60

80

100

0 200 400 600 800 1000

% o

f pai

rs o

f ver

tices

% added to paths length

maxmin

(a) WIDE

0

20

40

60

80

100

0 200 400 600 800 1000

% o

f pai

rs o

f ver

tices


maxmin

(b) V6-MAP

Figure 4.6: Mobile IPv6: one home agent located in a subnetwork (unweighted)CDF of path length augmentation compared to direct distances. min: subnetworkthat modifies path lengths the most (worst). max : subnetwork that modifies path

lengths the least (better).

to testbeds or research networks. There is therefore no such thing as a typical MobileIPv6 deployment. Nevertheless, we noticed that network administrators often locatehome agents in subnetworks for management convenience. Such a setup is also quitecommon in the literacy. We will now study the impact of the home agent location oncommunication distances when it is located in a subnetwork, i.e. a vertex with degreeone.

Figures 4.6 and 4.7 show the modification of path lengths when the home agent islocated in a subnetwork, for the WIDE, GEANT and V6-MAP graphs. The x-axis representsthe increase of paths lengths in percents: 100% means that the communication distancein this case is twice as large as the direct distance between the two nodes. The y-axis represents the number of pairs of vertices in the graph for which the increaseof the communication distance is lesser than or equal to the corresponding x value.Figure 4.7(b) is similar but weights are taken into account. In these four figures, mincorresponds to the subnetwork which modifies path lengths the most, and max to thesubnetwork which modifies path lengths the least, i.e. the subnetwork that improvesperformances the most.

In Figure 4.6(a), when the home agent is located in the max subnetwork, 56% ofall pairs of vertices are increased by 80% or less. The corresponding fraction is 19%with min. We observe a similar behavior in 4.7(a). Concerning Figure 4.6(b), thedifference is even more significant. When the home agent is in min, only 0.4% of pairs


0

20

40

60

80

100

0 200 400 600 800 1000

% o

f pai

rs o

f ver

tices


maxmin

(a) GEANT unweighted

0

20

40

60

80

100

0 200 400 600 800 1000

% o

f pai

rs o

f ver

tices


maxmin

(b) GEANT weighted

Figure 4.7: Mobile IPv6: one home agent located in a subnetwork (GEANT)CDF of path length augmentation compared to direct distances. min: subnetworkthat modifies path lengths the most (worst). max : subnetwork that modifies path

lengths the least (better).

of vertices are increased at most of 80%. In this case, 80% of all shortest paths areseriously modified: their length is increased by 1250%. With max, 80% of all shortestpaths are only increased by 80% or less. Finally when weights are used to computethe distance, Figure 4.7(b), the two considered subnetworks deliver results even moredissimilar: with min 6% of all pairs of vertices are not modified. In contrast, with max,this fraction is higher: 80%.

From these four figures, it is clear that the subnetworks are not identical from aperformance point of view: they do not equally modify paths lengths. However, thereis no straightforward solution to find out which vertex will perform the best comparingto the other vertices of degree one. Therefore, we now compare the subnetwork thatmodify paths lengths the least (called max to keep the same naming convention) tovertices with the highest degree and betweenness centrality. Results are presented inFigures 4.8(a), 4.9(a), and 4.8(b) for the unweighted graphs WIDE, GEANT and V6-MAP

and in Figure 4.9(b) for GEANT with weights. In all of these cases, the two verticeswith the highest degree and the highest betweenness centrality, and the vertex thatcorresponds to max are different.

When the home agent is located in one of the two vertices with the highest degreeor betweenness centrality, the number of paths that are not modified is drasticallyincreased in the unweighted graphs. In WIDE, 51% and 54% of all shortest paths arenot modified when the degree and the betweenness centrality are respectively used to

76 4.4. Evaluation

0

20

40

60

80

100

0 200 400 600 800 1000

% o

f pai

rs o

f ver

tices


maxhighest betweenness

highest degree

(a) WIDE

0 10 20 30 40 50 60 70 80 90

100

0 50 100 150 200 250

% o

f pai

rs o

f ver

tices



highest degree

(b) V6-MAP

Figure 4.8: Mobile IPv6: degree and betweenness centrality (unweighted)CDF of path length augmentation compared to direct distances. max : subnetwork

that modifies path lengths the least.

0

20

40

60

80

100

0 200 400 600 800 1000

% o

f pai

rs o

f ver

tices



highest degree


0

20

40

60

80

100

0 200 400 600 800 1000

% o

f pai

rs o

f ver

tices


maxhiggest betweenness

highest degree

(b) GEANT weighted

Figure 4.9: Mobile IPv6: degree and betweenness centrality (GEANT)CDF of path length augmentation compared to direct distances. max : subnetwork

that modifies path lengths the least.


B DC FE

G

A

Figure 4.10: Centrality: example graph

select the home agent location. This is 7% with max. Similarly in V6-MAP, 17% and26% are not modified with the degree and the betweenness centrality; this is 0.008%when the home agent is located in max.

From now on, we respectively call HB and HD the vertices with the highest be-tweenness and the highest degree. In the general case, placing the home agent in HB

provides slightly better results than placing it in HD. In GEANT, the performances ofHD are slightly better than HB. For instance, the fraction of pairs for the commu-nication distance is equal to the real distance in 34% of the case for HD and 30% forHB. This behavior indicates that the vertex HD is indeed on a shortest path betweenmore pairs of vertices than HB. This seems counter-intuitive, because the betweennesscentrality aims precisely at identifying vertices located on many shortest paths. How-ever, due to the definition of the betweenness centrality (see Equation 4.1 page 63),when there are many shortest paths between two vertices this lowers the betweennesscentrality of the vertices on any of these shortest paths. However, in our context whatis important is whether a vertex is on any shortest path between two vertices. Wepresent, in Figure 4.10, an example of a case where a vertex with a higher between-ness centrality is on shortest paths between fewer vertices than a vertex with a lowerbetweenness centrality. In this example, the vertex A is on a shortest path between 18pairs of vertices, and the vertex E is on a shortest path between 12 pairs of vertices;their respective betweenness centrality are 9 and 10.5. The same behavior occurs inthe GEANT graph, that is why locating the home agent in HD provides a better resultthan locating it in HB.

When weights are used with GEANT, HB as a home agent location gives betterresults than either HD or max. The comparison between HD and max is howevernot as straightforward, and reveals some interesting features. The number of pairs for

78 4.4. Evaluation

80

85

90

95

100

0 20 40 60 80 100 120 140

% o

f pai

rs o

f ver

tices

% added to paths lengths

2 HA5 HA

10 HA20 HA

(a) WIDE

20

30

40

50

60

70

80

90

100

0 20 40 60 80 100 120 140

% o

f pai

rs o

f ver

tices


2 HA5 HA

10 HA50 HA

500 HA1000 HA2000 HA3000 HA4000 HA

(b) V6-MAP

Figure 4.11: Home Agent Migration: correspondent and mobile nodes communications(unweighted)CDF of path length augmentation between the two communication patterns MN-CN

and MN-MN. Home agents are selected using the betweenness centrality.

which the communication distance is strictly equal to the distance is higher for HD

than max. Notice that in this case, the vertex with the highest degree is the one with thesecond highest betweenness centrality. This shows that even though the betweennesscentrality does not capture perfectly the fact that a vertex is a good location for ahome agent, it is still a very good indicator. However, this tendency is reversed whenwe consider cases in which the communication distance is larger than the distance. Forinstance, with max 94% of all pairs of vertices are increased by 150% or less; this is93% with HD. This indicates that when the home agent is located in the subnetworkmax, the communication distances are smaller than when it is located in HD. Indeed,even thought the vertex max has as small betweenness, it is the neighbor of the vertexwith the second highest betweenness centrality. Consequently, it delivers slightly betterresults than HD.

4.4.4 Home Agent Migration

Unlike in the Mobile IPv6 protocol, the communications between mobile and correspon-dent nodes are not symmetric in Home Agent Migration (see Equations 4.5 and 4.5 page68). Prior to other studies, we will therefore evaluate this difference by comparing thecommunication distances from a mobile node to a correspondent (called pattern MN-CN ) and from a mobile node to another mobile node (called pattern MN-MN ; whichis the same as the one from a correspondent node to a mobile node).


60

65

70

75

80

85

90

95

100

0 20 40 60 80 100 120 140

% o

f pai

rs o

f ver

tices


2 HA5 HA

10 HA20 HA30 HA


60

65

70

75

80

85

90

95

100

0 20 40 60 80 100 120 140

% o

f pai

rs o

f ver

tices


2 HA5 HA

10 HA20 HA30 HA

(b) GEANT weighted

Figure 4.12: Home Agent Migration: correspondent and mobile nodes communications(GEANT)CDF of path length augmentation between the two communication patterns MN-CN

and MN-MN. Home agents are selected using the betweenness centrality.

By definition, the communication distance of MN-MN is larger than or equal toMN-CN. Figures 4.11 and 4.12 represent the difference of paths lengths between thesecommunication for the WIDE, GEANT, and V6-MAP graphs. The x-axis represents theincrease of communications distances in percents: 100% means that the MN-MN com-munication distance in this case is twice as large as the MN-CN one. The y-axisrepresents the number of pairs of vertices in the graph for which the increase of thecommunication distance is lesser than or equal to the corresponding x value. Figure4.12(b) is similar but weights are taken into account. The vertices corresponding tohome agents are selected according to their betweenness centrality: as previously dis-cussed, such locations perform better than the ones selected using the degree. The caseof one home agent is not represented because it is equivalent to Mobile IPv6 and thecommunication distances are equal in this case.

In Figures 4.11(a) and 4.11(b), when the number of home agents increases, thedifference between the two communication patterns becomes less important. In theWIDE graph, when five home agents are used, 97% of communications distances areequal. We observe comparable results with the GEANT graph. Concerning the V6-MAP

graph, we chose to represent a broad range of home agent sets. However, if we considera realistic deployment of Home Agent Migration, only small values are important.Deploying and managing a high number of home agents is indeed not feasible in practice.When only ten home agents are used, 91% of communication distances are modified byless than 60%: the MN-MN communication distance is only 1.6 times longer than the

80 4.4. Evaluation

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600 700 800

% o

f pai

rs o

f ver

tices


1 HA2 HA5 HA

10 HA20 HA

(a) WIDE

20

30

40

50

60

70

80

90

100

0 50 100 150 200

% o

f pai

rs o

f ver

tices


1 HA2 HA5 HA

10 HA50 HA

500 HA1000 HA2000 HA

(b) V6-MAP

Figure 4.13: Home Agent Migration: increasing the number of home agents (un-weighted)

CDF of path length augmentation compared to direct distances.

MN-CN one. Finally, when weights are used to compute distances (Figure 4.12(b)),increasing the number of home agents does not always decrease the difference betweenthe two communication patterns. Though two vertices with high betweenness centralityare relevant locations for home agents individually, in practice, they can be far fromeach other. When they are used in conjunction, many communication paths must gothrough these two vertices inducing high communication distances. Yet, when only fivehome agents are used 92% of communication distances are only modified by 30% orless.

Finally, even though the difference between communication distances from a mobilenode to a correspondent node and from a mobile node to a mobile node (or, equivalentlyfrom a correspondent node to a mobile node) can be important in some cases, inpractice it is quite small. In the following discussions, we will therefore only considercommunications between two mobile nodes.

We now evaluate the impact of the number of home agents on communicationdistances. We select home agents by decreasing betweenness centrality: when a singlehome agent is considered, it is placed on the vertex with the highest betweennesscentrality, when two home agents are considered, they are placed on the two verticeswith the highest betweenness centrality, and so on. We only consider the betweennesscentrality from the time being, because as seen in the previous section, it globally isthe best strategy for home agent placement. We will present a comparison with thedegree at the end of this section.


20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600 700 800

% o

f pai

rs o

f ver

tices


1 HA2 HA5 HA

10 HA20 HA30 HA


86

88

90

92

94

96

98

100

0 100 200 300 400 500 600 700 800

% o

f pai

rs o

f ver

tices


1 HA2 HA5 HA

10 HA20 HA30 HA

(b) GEANT weighted

Figure 4.14: Home Agent Migration: increasing the number of home agents (GEANT)CDF of path length augmentation compared to direct distances.

Figures 4.13 and 4.14 show the modification of communication distances when thenumber of home agents is increased for the WIDE, GEANT and V6-MAP graphs. The x-axis represents the increase of communication distances compared to direct distancesin percents. The y-axis represents the number of pairs of vertices in the graph forwhich the increase of the communication path length is lesser than or equal to thecorresponding x value. Figure 4.14(b) is similar but weights are taken into account.

From these figures, it is clear that increasing the number of home agents increasesthe number of shortest paths controlled by the Home Agent Migration infrastructure.As a consequence, less communication distances are modified when more home agentsare added to the system. However, in the case of the V6-MAP graph (Figure 4.13) withless than five home agents, Home Agent Migration is less efficient than Mobile IPv6(one home agent). This is linked to the fact that, as already explained, communicationsbetween two mobile nodes in Home Agent Migration must go through two home agents,instead of one in Mobile IPv6. As a result, with Home Agent Migration, when homeagents are far from each other, their impact on communication distances is also moreimportant.

We now compare the number of home agents according to the degree or the be-tweenness centrality. We only consider communications between mobile nodes. Figures4.15 and 4.16 show the percentage of the communication distances modified by 10% orless with a given number of home agent for the WIDE, GEANT and V6-MAP graphs. Thex-axis represents the number of home agents used. Figure 4.16(b) is similar but weightsare taken into account. For any number x of home agents, we will compare the results

82 4.4. Evaluation

50

60

70

80

90

100

5 10 15 20 25

% o

f pai

rs o

f ver

tices

Number of home agents

betweennessdegree

(a) WIDE

40

45

50

55

60

5 10 15 20 25 30 35 40 45 50%

of p

airs

of v

ertic

es


betweennessdegree

(b) V6-MAP

Figure 4.15: Home Agent Migration: comparison of degree and betweenness centrality(unweighted)

CDF of communication distances modified by 10% or less, when the correspondingnumber of home agents is used (higher is better).

30

40

50

60

70

80

90

100

10 20 30 40 50 60

% o

f pai

rs o

f ver

tices


betweennessdegree


80

85

90

95

100

10 20 30 40 50 60

% o

f pai

rs o

f ver

tices


betweennessdegree

(b) GEANT weighted

Figure 4.16: Home Agent Migration: comparison of degree and betweenness centrality(GEANT)

CDF of communication distances modified by 10% or less, when the correspondingnumber of home agents is used (higher is better).


obtained when placing them in the x vertices with the highest degree or betweennesscentrality.

Except for the WIDE and V6-MAP graphs, when home agents are selected using thebetweenness centrality, the communication distances are less modified than when thedegree is used. Using the betweenness centrality is even more significant when consid-ering weights for the GEANT graph (Figure 4.16(b)): with ten home agents, 95% of thecommunication distances are modified by less than 10%. The corresponding percentagewhen the degree is used is 93%.

When the number of home agents is low, we observe a strange behavior in twocases. In Figure 4.16(a), when considering the degree, when three home agents areused instead of two, the performance are less good. We observe a similar behavior withthe V6-MAP graph, see Figure 4.15(b). This is an important result that shows that careshould be taken when deploying Home Agent Migration. In fact, while this mobilityarchitecture is designed to improve the performances of the Mobile IPv6 protocol, itcould lead to longer communication distances if home agents locations are not correctlyselected.

4.5 Related work

Finding the judicious locations of servers’ instances is a topic that has already beenaddressed in different networking fields ranging from Content Delivery Networks to In-ternet mapping architectures. The common concept is to distribute multiple instancesof the service in the network topology in order to maximize a quality function. De-pending on the context, such a function aims at minimizing the distances between themultiple instances and end-nodes, maximizing end-nodes bandwidth and users experi-ence, reducing the number of retransmitted packets, or using high quality paths.

Content Delivery Networks deliver media content to end-users by transparently dis-tributing duplicated mirrors in the Internet architecture. Here, the quality functionintends to optimize the placement based on network metrics. Indeed, a common strat-egy is to identify relevant mirror locations based on the estimated path lengths toend-nodes [64]. Other works [96, 38] use more metrics in the quality function such asclient bandwidth, request rates, or path quality, and show that, when possible, takingnetwork metrics into account improves the accuracy of the placement strategy.

Concerning Internet mapping using traceroute like approaches, performing mea-surements from multiple locations allows to discover more routers and links, and as aresult improve the overall quality of the mapping [76]. In this case, the quality function

84 4.5. Related work

aims at finding monitor locations, as well as destinations to probe, that maximize thenumber of discovered routers and links. To some extent, this problematic is similar tothe efficient placement of home agents in which we want to control a maximum numberof shortest paths. Several strategies based on random selection, or vertices degreessorted by increasing and decreasing degree can be used to place the traceroute moni-tors in the Internet topology [54]. However, this work indicates that the most efficientsolution is to select servers and locations by increasing vertices degrees similarly towhat was done in this chapter.

Distributed server instances is nowadays a key element of the Internet infrastructurethat is used commercially to put the media content closer to the users [1], or sharingnetwork load among the instances. One of the closest approaches to ours comes from theroot DNS server deployments using anycast routing. Its efficiency in performing loadbalancing among the multiple instances was the key feature that drastically mitigatedthe Distributed Denial of Service attack against the DNS root servers in February2007. Similarly, studies [62, 34] showed that anycast routing is an effective solution todecrease the latency of replies. This is an important practical result that strengthensthe conjoint use of the Home Agent Migration architecture and our placement proposal.

While placement strategies of servers’ instances is a well studied topic both inresearch and industrial fields, little has been done, strictly speaking, regarding theMobile IPv6 protocol and the placement of home agents in network topologies. Aspreviously described in Section 2.4.1, Hierarchical Mobile IPv6 [29, 100] describes anenhanced Mobile IPv6 architecture that locates home agents closer to mobile nodes,as well as on the path to end-nodes. This proposal does not specifically describe howto locate the home agents but provides good performances and keeps the network loadlow as the network’s size and the number of home agents increases. The influenceof home agents locations on performances had been specifically studied in UniversalMobile Telecommunications System (UMTS) [98]. Using a network simulator, theauthor evaluated different home agents locations given a single UMTS architecture.The results clearly outline that concerning data transmission, there is a direct relationbetween the home agent location and the performances: the closer the home agentsare to mobile nodes, the higher the effective bandwidth is. While this paper usesan approach different from our proposal, its outcome is complementary and indicatesthat placing home agents based on their degree or betweenness centrality is not onlyimproving the paths lengths in theory but will also deliver enhanced performances inpractice.


4.6 Conclusion

In this Chapter, we formally describe the Mobile IPv6 and Home Agent Migrationprotocols using graph metrics in order to quantify their impacts on communicationdistances. We proposed and evaluated two placement strategies that use the vertices’degree and their betweenness centrality to identify home agents locations. Our proposalhas the advantage of providing an accurate description of genuine operational issuesraised by these two mobility architectures.

Concerning the Mobile IPv6 protocol, we described the dogleg routing in termsof distances, and confirmed that all home agent locations do not provide equivalentperformances. Locating home agents in subnetworks, as is often done in the literacy,could indeed lead to bad performances and seriously increase communications distances.We also provided a detailed analysis of Home Agent Migration that highlights thateven using a small number of home agents can drastically decrease communicationdistances. We propose two solutions to finding good locations that use the degreeand the betweenness centrality. Selecting the best location for a given number of homeagents being NP-hard, we showed that they allow to efficiently find home agent locationsthat provide good overall performances.

However, we identified several issues in the placement strategies that are linked tothe underlying graph topology. In some specific cases, vertices with a high betweennesscentrality deliver inferior performances than vertices with a lower betweenness central-ity. In our future work, we would like to evaluate how other centrality measures, such asthe closeness or the eigenvector centrality, allow finding efficient home agent locations.It might also be possible to modify the definition of the betweenness centrality in orderto precisely reflect the required properties of home agent locations.

We believe that taking into account network metrics such as the Round Trip Timebetween routers, by using them as edges weights, is an important follow-up work. Itwill not only provide more accurate results, but will also ease their interpretation forreal deployments. Likewise, the knowledge of mobile nodes locations would surelyimprove the outcome of our placement strategies. This will allow focusing only oncommunication paths that are specifically used by mobile nodes. Traffic matrices, suchas available for the GEANT graph, could also help locating which routers gather most ofthe traffic, and which communication paths must be improved in priority.

Chapter 5Conclusion

Nowadays, mobility is clearly an important research and commercial issue, as well asone of the main features for upcoming Internet technologies. We expect that this trendwill also evolve with the deployment of mobility services such as Fourth Generationcell phones, vehicle communications (Intelligent Transport System, ITS), and PersonalArea Networks (PAN). The number of smart phones is increasing every day, and isquickly changing usages and the way people access the Internet. For example, in lessthan a year, the iPhone drastically changed Internet usages habits: 85% of iPhoneusers browse the web while only 13% of mobile phones users do [81]. As a consequence,it is necessary to consider that mobile computers will soon be predominant, and toanticipate future trends in network protocols and architectures.

Most of the current state of the art proposals aiming to provide mobility fail indesigning architectures that can be realistically deployed on the Internet. They requireeither heavy structural changes to the network or to end-nodes or, do not proposeincremental updates to present networking protocols and architectures. In contrast, wechoose to focus on immediate deployments of mobility systems based on Mobile IPv6given the fact that Standard Development Organizations such as the WiMAX Forum or3GPP are currently supporting this protocol. Our dominant motivation was to enhancethe Mobile IPv6 protocol so as to improve its performances while remaining transparentto network architectures as well as transport layers and applications. Our work isnot only compatible with the protocol specification itself but also with its operations.Any Mobile IPv6 implementation can benefit from our proposals without any change.As a consequence, our proposals make it possible to deploy a transitional mobilityarchitecture that does not require modification to the existing Internet architecture.

88

This thesis provides an enhanced mobility support architecture, built upon theexisting Mobile IPv6’s flexibility, that could either be deployed in a single operatornetwork, or in the whole Internet topology. This advanced architecture is achievedthrough two distinct works that can separately be used to solve performance limitationsof Mobile IPv6.

At first, we introduced an improved mobility support architecture, called Home

Agent Migration, that aims to distribute home agents in network topologies. Usinganycast routing and efficient placements of home agents, communication paths betweenmobile and correspondent nodes can be controlled to suppress the drawbacks of thedogleg routing. We not only described how Home Agent Migration works, but alsoexperimentally validated it in the WIDE project’s network. In most cases, we were ableto improve communications delays between mobile nodes and their correspondents, andobtained delays close to optimal as if no mobility support was used.

We also studied the Mobile IPv6 protocol from a graph theory perspective andshowed that home agents locations matter. Moreover, we quantified the influence ofthe dogleg routing on communications performances. By modeling operator’s networksas graphs, we were able to precisely compare home agents locations and show thatthey are not equal from a performance point of view. Indeed, we confirmed that nodeswith a high betweenness centrality are the best candidates to become home agents. Weproposed a new algorithm that can identify good home agents locations in anyoperator’s networks. It could either be applied to Home Agent Migration or MobileIPv6. This graph based study showed that Home Agent Migration is an improvementcomparing to regular Mobile IPv6 deployments, and complements the experimentalevaluations that we made.

The work presented in this thesis brings several research and engineering directionsthat would certainly improve the current Home Agent Migration architecture. They areof primary importance to achieve commercial deployments of Home Agent Migrationbased mobility support.

In the current proposal, the information contained in the Binding Cache is dis-tributed based on a simple full-mesh approach. While this solution was adequate toevaluate the Home Agent Migration architecture, it is far from being appropriate toachieve efficient deployments. Better distribution mechanisms must be investigated toefficiently disseminate the Binding Cache in order to maximize the hit/miss ratio whileminimizing the size of the local Binding Caches. One could for example consider Dis-tributed Hash Tables (DHT) as a possible solution to efficiently disseminate the

biding cache. However, it is unlikely that a generic dissemination solution can be built

Chapter 5. Conclusion 89

as it is deeply related to the mobility patterns of users. For example, if we consider aHome Agent Migration architecture distributed all over the globe, binding informationof Japanese users moving only in the Tokyo area should not be distributed to otherhome agents if their data traffic is mainly local.

Home Agent Migration improves the overall scalability and availability of MobileIPv6, however it remains threaten by the stability of the underlying routing protocolsused to advert the home prefix. Due to the use of the anycast routing, if a routerthat connects a home agent fails, mobile nodes bound to this home agent cannot com-municate with their correspondents until the underlying routing protocol converges.Elementary solutions could rely on redundant routers architectures as well as multi-homed home agents. However, prior to any other work, it is necessary to quantify

the impact of routing failures on the availability of the Home Agent Migrationarchitecture. Eventually, this will allow anticipating failures and design new solutionsto minimize their consequences.

In order to thoroughly validate the Home Agent Migration architecture, we need toperform an Internet-scale deployment by distributing home agents and advertisinga home prefix from several locations around the globe. This will allow the comparisonof results with the Autonomous System-scale deployment conducted during the evalu-ation of Home Agent Migration. Moreover, by monitoring routers and not only mobilenodes and home agents, such deployment could also help to gather data about anycastrouting and help identifying routing failures. In order to acquire rich data from variousgeographical locations, mobile nodes could be deployed in Planetlab [10] using Scapy6.

In the current Home Agent Migration architecture, the communications betweenthe distributed home agents are the only ones that are protected by IPsec. Sincecommunications between home agents and mobile nodes are valuable targets for amalicious attacker, it is essential to conduct interoperability tests when Home Agent

Migration and IPsec are used conjointly. Based on our expertise of Mobile IPv6 andIPsec, we believe that it should work with close to zero modification to their respectiveimplementations. However, the use of IPsec to protect the communications could leadto reduced performances, and longer handover durations. Finally, concerning securityat large, the integration of Home Agent Migration and AAA1 architectures

must also be considered prior to starting commercial deployments. If we considerHome Agent Migration with several Mobile Service Providers, this will allow roamingagreements and ease movements of users in the resulting global mobility system.

1Authentication, Authorization and Accounting.

90

Concerning mobility at large, the results presented in this thesis suggest that worksaiming at the characterization of users mobility are of primary importance to the field.Not only Home Agent Migration and its dissemination system will benefit from suchworks, but they will likely improve our understanding of mobility needs and anticipatetrends in future networking protocols and technologies. We propose two research per-spectives related to the study of users mobility that we want to use to improve currentDelay Tolerant Networks (DTN) approaches.

So far, most studies of users mobility are based on the analysis of 802.11 tracesacquired on universities campuses, or similar finite areas [4]. As a result, users canonly move in rather restricted geographical spaces, and connect to a limited number ofWi-Fi access points. Moreover, if users do not keep their devices running while movingbetween two different access points, it is not possible to obtain a precise estimate oftheir movements patterns. So as to address these problems and gather informationon a wider scale, we believe that it is necessary to set up experiments that will focuson capturing continuous users movements. To do so, electronic landscapes available inurban areas are particularly interesting. During the course of this thesis, preliminaryexperiments based on surrounding Wi-Fi access points [55] showed that studying

users mobility could be done using regular smartphones. Concerning Home AgentMigration, the study of user mobility could for example help to find out spots withhigh user-concentration and consequently enhance the identification of home agentslocations.

Movements of users in the Wi-Fi landscape could also be used to enhance Wi-fi

based location systems. Location systems currently exploited commercially [99, 95]rely on Wi-Fi access points databases acquired using techniques similar to wardriving.However, driving around cities with a laptop and a GPS receiver to associate geograph-ical coordinates to Wi-Fi access points is an expensive and time consuming task. Wethink that users mobility can be efficiently used to perform these associations on the goeven though their devices are not embedded with GPS receivers. For example, start-ing with a rather small database of access points coordinates around a train station,users could expand this local knowledge when they move in and out the station. Asa result, users mobility will be used to spread the geographical coordinates to Wi-Fiaccess points that were not known at the beginning of the experiment.

Although the outcomes of this thesis improve the performances of the Mobile IPv6protocol, there is still some work to complete in order to achieve smooth handoversbetween different network access technologies under strict architectural and securityconstraints. It is likely that mobility support on the Internet will remain a challenging

Chapter 5. Conclusion 91

task during upcoming years. We believe that focus should be put on designing network-based systems that will support mobility more efficiently that could be done today. Asa matter of fact, it will become necessary and intrinsically fundamental to provides andverify identifiers proofs of ownership. Mobility management protocols such as MobileIPv6 make it difficult to identify the real physical location of a mobile device thanksto the permanent identifier. However, this permanent identifier also raises questionsconcerning privacy, as it is a simple method to trace users on the Internet. As aconsequence, we think that protecting users privacy while providing secured mobilitysystem will undoubtedly be one of the key topics of upcoming mobility researches.

Appendix AScapy: IPv6 and BPFextensions

Contents

A.1 Contributed extensions . . . . . . . . . . . . . . . . . . . . . . 95

A.1.1 Scapy6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

A.1.2 BPF extension . . . . . . . . . . . . . . . . . . . . . . . . . . 98

A.2 Routing Header Type 0 . . . . . . . . . . . . . . . . . . . . . . 101

A.2.1 In a nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

A.2.2 Advanced traceroutes . . . . . . . . . . . . . . . . . . . . . . 102

A.2.3 Amplification attacks . . . . . . . . . . . . . . . . . . . . . . 104

94

Developed by Philippe Biondi1, Scapy [26] is a powerful tool that ease the manip-ulation of network frames and packets. Written entirely in the Python programminglanguage, Scapy is a script, named scapy.py, that can similarly be used as a standalonesoftware, or as a Python module to build well-known networking tools such as a portscanner, traceroute, or packets sniffer. Unlike common libraries and tools specificallydesigned for a unique purpose, Scapy only matches sent packets to replies and do nottry to interpret these replies on behalf of users. Indeed, it allows users to easily de-scribe fields contained in a packet as a Python object. The following example providesthe description of the UDP header that can directly be used to inject or read UDPpackets: only fields’ types and their default values need to be specified; the checksumcomputation code is not represented here.

class UDP(Packet ):name = "UDP"fields_desc = [ ShortEnumField ("sport", 53,

ShortEnumField (" dport", 53,ShortField ("len", None),XShortField (" chksum", None) ]

In order to inject Ethernet frames, Scapy internally implements a routing table aswell as an ARP cache to decide which interface is used to send a frame, and whichsource addresses (IP and MAC) must be used. Scapy provides support for variousnetwork protocols ranging from layer 2 (Ethernet, 802.1q, Bluetooth, or 802.11) tolayer 4 (DNS, SNMP, NTP or RIP). More details about Scapy and its usages areavailable on the project web page: http://www.secdev.org/projects/scapy/.

During the course of this thesis, Scapy was heavily used as an experimental anddiagnostic tool. More specifically, it seriously simplified the setup, and measurementsconducted during the deployment of the Home Agent Migration experiment. Thisappendix first describes two extensions that were specifically written for this thesis: theIPv6 and the BPF extension. Then, we present security issues related to the RoutingHeader Type 0 that were discovered while working on the IPv6 extension. While notexactly related to this thesis, this last section is however an important contribution asit led to the deprecation of the Routing Header Type 0 in the RFC 5095 [18].

1from EADS Innovation Works.

http://www.secdev.org/projects/scapy/

Appendix A. Scapy: IPv6 and BPF extensions 95

A.1 Contributed extensions

A.1.1 Scapy6

Developed in collaboration with Arnaud Ebalard2, Scapy6 provides support for theIPv6 protocol [41, 18] and related protocols such as Neighbor Discovery [86, 59, 36,28]. Moreover, it implements several protocols that are not available in any othernetworking tool such as Node Information Query [37], Mobile IPv6 and NEMO [66, 58],and DHCPv6 [44]. The alpha version of Scapy6 was available as a patch to the Scapysource code; as a consequence, it was somehow cumbersome to use. Later on, it wasredesigned as a standalone Python module to facilitate both software developments.Scapy6 actually supports Linux and most of BSD flavors such as NetBSD and FreeBSD.During the year 2007, Scapy6 was downloaded approximately 100 times every month.Scapy6 is not only used by academic and industrial researchers but also by well-knownnetworking companies that use it to evaluate their IPv6 related developments, andequipments.

Scapy6 source code as well as lengthy usage examples can be retrieved on the exten-sion web page: http://namabiiru.hongo.wide.ad.jp/scapy6/. The current devel-opment version is available separately at http://hg.natisbad.org/scapy6/. Supportcan be obtained on the regular Scapy mailing list.

Examples

Here, we present some functionalities of Scapy6, and describe typical packets thatcan be injected to the network. Scapy6 adopts a naming convention for packets thatease their usage with automatic names completion: ICMPv6 messages starts withICMPv6, Neighbor Discovery ones start with ICMPv6ND, and IPv6 extensions startswith IPv6Ext. In Scapy, packets headers can be stacked with the / operator such asIPv6()/UDP() represents an IPv6 packet encapsulating an UDP message. The sr1()function, used in the following examples, sends a packet provided as an argument, andreturns the corresponding reply3. >>> represents Scapy’s interactive prompt.

1. Sending and receiving ICMPv6 Echo messages

In the following example, a simple IPv6 packet encapsulating an ICMPv6 EchoRequest message is constructed in line 1 and sent in line 2. The destinationaddress is the only parameter to be specified, Scapy6 will internally choose the

2from EADS Innovation Works.3similarly, the srp1() sends a frame and returns the received reply.

http://namabiiru.hongo.wide.ad.jp/scapy6/

http://hg.natisbad.org/scapy6/

96 A.1. Contributed extensions

source address, compute the checksum, and set other necessary fields. Finally,the reply is displayed from lines 4 to 7.

1 >>> pkt = IPv6(dst=’www.netbsd.org ’)/ ICMPv6EchoRequest ()2 >>> reply = sr1(pkt)3 >>> reply4 <IPv6 version =6L tc=0L fl=0L plen=8 nh=ICMPv6 hlim =595 src =2001:4 f8 :4:7:2 e0:81ff:fe52:9a6b6 dst =2001:200:0:1 cd1 :211:43 ff:fecd:3b1c |<ICMPv6EchoReply7 type=Echo Reply code=0 cksum=0 x7d4e id=0x0 seq=0x0 |>>

2. IPv6 extensions

Here, we provide two simple examples of some of the IPv6 extensions that canbe constructed and injected using Scapy6: the Fragment (lines 1 to 2) and theHop-by-Hop extensions (lines 4 to 7). In complement to the / operator, the/ = operator allows to stack packet headers on top of previously defined packets.Later in Section A.2, we will describe how to manipulate Routing Headers.

1 >>> pkt1 =IPv6 ()/ IPv6ExtHdrFragment(nh=’TCP ’, offset =0)2 >>> pkt1 /= ’aaaa ’34 >>> jlen = 200005 >>> pkt2 = IPv6()6 >>> pkt2 /= IPv6ExtHdrHopByHop(options =[ Jumbo(jumboplen=jlen])7 >>> pkt2 /= ICMPv6EchoRequest ()

3. Neighbor Discovery

In this example, we forge a Neighbor Solicitation packet to find out the MACaddress that belongs to the host 2001:200:0:1cd1::1. On lines 1 and 2, the packetis prepared by providing the targeted IPv6 address and the MAC address of thenode sending this message4. Again, Scapy6 will internally choose relevant IPv6addresses. In line 4, we use a syntax shortcut that allows to directly access thereply’s field that contains the MAC address of 2001:200:0:1cd1::1.

1 >>> pkt = IPv6 ()/ ICMPv6ND_NS(tgt = ’2001:200:0:1 cd1::1’)2 >>> pkt /= ICMPv6NDOptSrcLLAddr(lladdr=get_if_hwaddr(’eth0 ’)))3 >>> reply = sr1(pkt)4 >>> reply.lladdr5 00:0c:db:e0 :15:00

4. Router discovery and address auto-configuration4the get if hwaddr() returns the MAC address corresponding to a network interface.


Here, we provide one of the simplest examples that can be written with Scapy6.In line 1, we construct and send a Router Solicitation message. Scapy6 willautomatically set all other fields present in the packet. In line 6, we display theIPv6 prefix contained in the reply. In practice, this prefix is used by an IPv6node to perform addresses auto-configuration.

1 >>> reply = sr1(IPv6 ()/ ICMPv6ND_RS ())2 Begin emission:3 .Finished to send 1 packets.4 ................................................*5 Received 50 packets , got 1 answers , remaining 0 packets6 >>> reply.prefix7 2001:200:0:1 cd1::

5. Mobile IPv6

The following example uses Scapy6 as a Python module in a script that prepares(lines 3 to 6) and sends (line 8) a Binding Update message. Then, it analyzesthe reply (lines 10 and 11), and displays information contained in the BindingAcknowledgement message (lines 12 to 14) if the home agent accepted it or whyit was rejected. In C, a similar piece of code would be around 100 lines long.

1 from scapy6 import *23 coa = ’2001:db8:dead::beef ’4 p = IPv6(dst=coa)5 p /= IPv6ExtHdrDestOpt(options =[HAO(hoa = ’2001: db8::cafe ’)])6 p /= MIP6MH_BU(options =[ MIP6OptAltCoA(acoa=coa)])78 r = sr1(p)9

10 if isinstance(r, IPv6) and MIP6MH_BA in r \11 and r[MIP6MH_BA ]. status == 0:12 print ’Binding ACK receved ’13 else:14 print ’BU rejected %s’ % r.status

6. Node Information Query

The Node Information Query protocol was designed to query an IPv6 node aboutits network information such as its hostname or its IPv4 address. This proto-col is currently implemented in most BSD flavors5 and Linux 2.6 kernels. Inthe following example, we first retrieve the hostname associated to the host

5including Mac OS X.


2001:200:0:1cd1::23 (lines 1 to 14): taopaipai. Then, lines 16 to 29, using thisname as a parameter in the Node Information Query, line 17, we obtain its IPv4address: 203.178.135.23.

1 >>> p = IPv6(dst = ’2001:200:0:1 cd1 ::23 ’)2 >>> p /= ICMPv6NIQueryName(data = ’2001:200:0:1 cd1 ::23 ’)3 >>> r=sr1(p)4 Begin emission:5 .............. Finished to send 1 packets.6 *7 >>> r8 Received 15 packets , got 1 answers , remaining 0 packets9 <IPv6 version =6L tc=0L fl=0L plen =32 nh=ICMPv6 hlim =64

10 src =2001:200:0:1 cd1 ::23 dst =2001:200:0:1 cd1 :211:43 ff:fecd:3b1c11 |<ICMPv6NIReplyName type=ICMP Node Information Response12 code=Successful Reply cksum=0xd11 qtype=Node Name unused =0L13 flags= nonce=’\x183\x81*\xe6\xb7B\x9c ’14 data=[ (0, taopaipai) ] |>>1516 >>> p = IPv6(dst = ’2001:200:0:1 cd1 ::23 ’)17 >>> p /= ICMPv6NIQueryIPv4(data=’taopaipai ’)18 >>> r = sr1(p)19 Begin emission:20 ... Finished to send 1 packets.21 *22 >>> r23 Received 4 packets , got 1 answers , remaining 0 packets24 <IPv6 version =6L tc=0L fl=0L plen =24 nh=ICMPv6 hlim =6425 src =2001:200:0:1 cd1 ::23 dst =2001:200:0:1 cd1 :211:43 ff:fecd:3b1c26 |<ICMPv6NIReplyIPv4 type=ICMP Node Information Response27 code=Successful Reply cksum=0 xe727 qtype=IPv4 Address28 unused =0L flags= nonce=’p8\xf9\xd8.\x90\xa3S ’29 data=[ (0, 203.178.135.23) ] |>>

A.1.2 BPF extension

Initially developed for Linux, Scapy only supports packets injection and reception us-ing AF PACKET sockets. As these kind of sockets are only available on Linux, *BSDoperating systems are not natively supported. On these systems, the py-dnet and py-pcap Python modules must be installed along with the scapy.py script. The py-netmodule provides a programming interface around the libdnet library [101]: a portableand simple library designed to manipulate and inject frames and packets. Likewise, thepy-pcap module allows the reception of network frames from Python using the libp-cap library6 [14]. The installation of these Python modules in addition to scapy.py is

6standard packets capture library developed along with the famous tcpdump tool.


somehow inconvenient, and might not be possible under strict system administrationconstraints. Indeed, during the Home Agent Migration evaluation, we were not allowedto install these modules on some nodes. In this context, the BPF extension was de-veloped to suppress dependencies on the Python modules, in order to make Scapy andScapy6 work natively on *BSD.

At the time of writing, the BPF extension is not yet integrated into Scapy, and isavailable as a separate patch to Scapy’s latest version. The source code can be retrievedfrom a separate development repository: http://hg.natisbad.org/scapy-bpf/. Thisextension was thoroughly tested on: OpenBSD 4.2, NetBSD 4.0, FreeBSD from 5.4 to7.0 as well as Mac OS X from 10.4 to 10.5. The following example displays scapy.pyrunning natively on Mac OS X 10.4.11, sending a TCP segment, and displaying somefields of the reply.

1 # python scapy.py2 WARNING: did not find pcap module.3 WARNING: did not find dnet4 INFO: Fallback to native BPF primitives.5 Welcome to Scapy (1.2.0.2)6 >>> sys.platform7 ’darwin ’8 >>> reply = sr1(IP(dst=’www.free.fr ’)/ TCP ())9 Begin emission: .. Finished to send 1 packets.

10 .* Received 4 packets ,11 got 1 answers , remaining 0 packets12 >>> reply.src13 212.27.48.1014 >>> reply.ttl15 5516 >>> reply.flags17 2L

In a nutshell, Berkeley Packet Filter (BPF) [78] is a mechanism available on BSDbased kernels that provides a convenient userland interface to data link layers andallows link layer frames to be injected and received. Moreover, depending on the devicesdrivers, it authorizes to alter the source MAC address7 and to receive all frames thatflows on the wire.

The BPF extension brings native BSD support to Scapy. From an implementationpoint of view, this extension adds two fundamental contributions along with sparsenon-critical modifications to the conventional Scapy. First, all functions that deal withthe manipulation of network interfaces8 were ported to BSD: they do not anymore rely

7this is often referred as MAC address spoofing.8like getting the list of valid interfaces, or the MAC address of a given interface.

http://hg.natisbad.org/scapy-bpf/


on external libraries, or operating system dependent tools. Next, new Super Socketsusing BPF natively were added. In Scapy, Super Sockets are high-level Python objectsthat provide programming interfaces to inject and receive frames and packets. Inter-nally, Scapy only manipulates Super Sockets, and as a consequence they provide anabstraction to the underlying methods used to access the networking devices such asAF PACKET sockets or BPF.

So as to evaluate how the BPF extension competes with the py-dnet module, weimplemented two different tests in the Python programming language and in Scapy.These two tests inject one million Ethernet frames using either the libdnet9 or BPF,and outputs the time required to inject these frames by thousand increments. Theexperiment was conducted on Mac OS 10.4.11; the four tests were run one hundredtimes each on a 100 Mbps full duplex link. Even after these hundred runs, there isno significant difference between the libdnet and the BPF tests. Both achieve similarperformances; however libdnet based tests tend to be slightly faster. This is caused bythe overhead of the Python interpreter and can be easily understood as follows: whenusing the py-dnet module, we exit the Python interpreter earlier; as a consequence, thecorresponding C functions and system calls are called faster than if we remain in thePython interpreter.

Concerning the reception of frames, the BPF extension must cope with one impor-tant BPF specificity: when the read() function is called on a BPF descriptor to receiveframes from the network interface, several frames could be retrieved at once in thereturned buffer. In practice, this improves frames reception performances, for exampleseveral small ARP messages can be retrieved with a single call to read(). As Scapyprocesses received frames one by one, the BPF extension needs to manage an internalbuffer of received frames while polling the BPF descriptor consistently. Tests that weconducted on the current implementation showed that it works fine but could performa little bit worst than the py-pcap module under particular network conditions. Weare actually investigating other mechanisms to receive frames in order to make sniff-ing faster. Nevertheless, in the current implementation, the reception speed can beefficiently improved using BPF filters10 to select which frames must be handed to theuserland process. These filters can for example be used to discard an heavy UDP loadon the network, and only receive TCP segments sent from a given host.

9on *BSD, libdnet is simply a high level interface to BPF.10commonly used with tcpdump to filter out network traffic.


packet source

2001:7a:78d::1 2001:7a:78d::11 2001:7a:78d::21

specified router non-specified router packet final destination

segment left: 2

src: 2001:7a:78d::1

dst: 2001:7a:78d::11

addr[1] 2001:7a:78d::21

addr[2] 2001:7a:78d::31

segment left: 1

src: 2001:7a:78d::1

dst: 2001:7a:78d::21

addr[1] 2001:7a:78d::11

addr[2] 2001:7a:78d::31

segment left: 0

src: 2001:7a:78d::1

dst: 2001:7a:78d::31

addr[1] 2001:7a:78d::11

addr[2] 2001:7a:78d::21

2001:7a:78d::31

Figure A.1: Routing Header Type 0 processing

A.2 Routing Header Type 0

In IPv6, the Routing Header Type 0 extension is similar to the Loose Source Routingoption in IPv4: it allows a node that sends a packet to specify a list of routers that mustbe crossed prior to being delivered to the destination. During the implementation ofthe Routing Header extension in Scapy6, we discovered that it represents a serious se-curity threat as it allows to bypass firewall filtering rules, permits efficient amplificationattacks, and is often badly implemented [3]. Later on, after a talk at CanSecWest byArnaud Ebalard and Philippe Biondi [27], these discoveries led to vigorous discussionsat the IETF and to the deprecation of the Routing Header Type 0 [18].

Note that the Mobile IPv6 RFC specifies a Routing Header Type 2 [66] that is usedto carry home addresses in Binding Acknowledgement messages sent to mobile nodes.While semantically similar, the Routing Header Type 2 is not targeted by the problemsthat conducted to the revocation of Type 011.

In this section, we first describe how the Routing Header extension works. Then wepresent two novel traceroute approaches that take advantage of this extension. Finally,we present the most dangerous security threat of the Routing Header Type 0 prior toits revocation: amplification attacks.

A.2.1 In a nutshell

Figure A.1 illustrates how Routing Header Type 0 extensions are built and processedfrom a source (2001:7a:78d::1) to a destination (2001:7a:78d::31). In spite of the naturalpath, we want to specify two routers as waypoints: 2001:7a:78d::11 and 2001:7a:78d::21.

11however in practice, we found routers that blindly drop any type of Routing Headers.

102 A.2. Routing Header Type 0

In IPv6, unlike in IPv4, the waypoints successively appear in the IPv6 destination field.As a result, these specified routers are required to process the Routing Header Type0. Unspecified routers only need to route packets as they would with any other regularpackets. For the sake of clarity, we only represented relevant headers fields in theFigure. From top to bottom, we have the IPv6 source address, the IPv6 destinationaddress, the RH0 segment left field, and finally a list of waypoints. We assume thatthe upper layer is an ICMPv6 Echo Request message.

When the source node prepares the IPv6 packet and the Routing Header Type 0,it uses its IPv6 address as the packet’s source address, and sets the destination as thefirst waypoint to cross. Then, it sets the segment left field to 2: meaning that there aretwo remaining addresses in the waypoints list. Finally, its puts the second waypointand the final destination in the waypoint list.

This packet is then sent to the network and reaches the first waypoint (2001:7a:78d::11).Because this router is the current destination of the packet, it must process networklayers on top of IPv6. First, it checks if the segment left is null. As it is equal to 2,it permutes IPv6 addresses in the destination field and the first entry in the waypointlist. Then, it decrements the segment left value. The packet is now sent to the secondwaypoint 2001:7a:78d::21. The second waypoint receives this packet, and processes itas the first waypoint did.

The final destination 2001:7a:78d::31 receives this packet and first checks the valueof the segment left field. It is equal to zero: there is no more waypoint to process. Thedestination then processes the encapsulated ICMPv6 Echo Request, and as a resultsends a ICMPv6 Echo Reply to the source 2001:7a:78d::1.

A.2.2 Advanced traceroutes

Using the Routing Header Type 0, it is possible to perform new advanced traceroutesthat we called indirect and boomerang traceroutes. Indirect traceroute is taking ad-vantage of the Routing Header Type 0 to specify routers that must be crossed prior toreach the destination. Figure A.2(a) shows the difference between the natural path andthe forced path that goes to the waypoint. Indirect traceroute is especially interestingin the context of Internet mapping as it allows a node to probe more paths than it willusually do with the classical traceroute. Such traceroute can easily be performed withScapy6 such as shown in Figure A.3. In this example, we send an ICMPv6 Echo Re-quest message towards 2001:319:2000:3002::21 using 2001:301:0:8002:203:47ff:fea5:3085as a waypoint, and display routers between the source and the waypoint (lines 5 to 8),then between the waypoint and the real destination (lines 10 to 24). For convenience,


Target

Source IPv6 router

Natural path

Forced path (using RH0)

Waypoint

(a) Indirect traceroute

Source IPv6 router

Source to waypoint

Waypoint to Source

Waypoint

(b) Boomerang traceroute

Figure A.2: Advanced traceroutes using Routing Header Type 0

we used the minttl parameter to start probing routers after the 14-th hop (lines 5 to8). On line 9, the message is received by the waypoint, and then forwarded towardsthe real destination (lines 10 to 15).

Boomerang traceroute is similar to indirect traceroute but aims to detect both egressand ingress interfaces of routers between the node and the waypoint: the node is atthe same time the source and the destination of the packet. Figure A.2(b) illustrates aboomerang traceroute: the packet goes to the waypoint and then goes back to the node.As the hop limit does not expire on the same interface in both ways, two addresseswill be ideally discovered for each router on the path. We used this kind of tracerouteto detected asymmetric routing paths during the Home Agent Migration experiment.Concerning Internet mapping, it could be used to gather different addresses of the samerouter in order to perform addresses aggregation and as a result achieve a more precisenetwork mapping.

104 A.2. Routing Header Type 0

1 >>> waypoint = "2001:301:0:8002:203:47 ff:fea5 :3085"2 >>> tgt = "2001:319:2000:3002::21"3 >>> traceroute6(waypoint , minttl =15 , maxttl =24, \4 l4=IPv6OptionHeaderRouting(addresses =[tgt ])/ ICMPv6EchoRequest ())5 2001:301:0:8002:203:47 ff:fea5 :3085 :IER6 15 2001:319:2000:5000::92 37 16 2001:301:0:1 c04 :230:13 ff:feae:5b 38 17 2001:301:0:4800::7800:1 39 18 2001:301:0:8002:203:47 ff:fea5 :3085 3

10 19 2001:301:0:2::6800:1 311 20 2001:301:0:1 c04 :20e:39ff:fee3 :3400 312 21 2001:301:133::1 dec:0 313 22 2001:301:901:7::18 314 23 2001:301:0:1800::2914:1 315 24 2001:319:2000:3002::21 316 (<Traceroute: ICMP:0 UDP:0 TCP:0 Other:10>,17 <Unanswered: ICMP:0 UDP:0 TCP:0 Other:0>)

Figure A.3: Indirect traceroute with Scapy6

R2

tgt

Attacker 2Attacker 1

R1

Figure A.4: Routing Header Type 0 based attacks: capacitor effect

A.2.3 Amplification attacks

The Routing Header Type 0 can specify up to 86 waypoints12 that must be crossed bythe encapsulated packet. This could be used by a malicious attacker to cause seriousnetwork overload by allowing packets to remain in the network longer than they should.For example, using a forged Routing Header Type 0, an attacker can make a packet loopbetween two routers, hence overloading the corresponding link. In practice, we verifiedthat, depending on network conditions, such packet could remain tens of seconds in thenetwork.

A more advanced attack could take advantage of the resulting capacitor effect.12assuming a standard MTU of 1500 bytes.


Indeed, as illustrated in Figure A.4, we can consider that packets looping between thetwo routers R1 and R2 are stored in the network. In this example, Attacker 1 floods thetarget tgt at a constant rate13 while Attacker 2 is able to store packets in the networkduring the round trip time between R1 and R2 and deliver all of these packets at oncecreating a powerful Denial of Service attack against the target.

13limited by its upload bandwidth.

Appendix BThesis’ French Version

Contents

B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

B.1.1 Protocoles de mobilite . . . . . . . . . . . . . . . . . . . . . . 110

B.1.2 Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

B.2 Mobile IPv6 et ses limitations . . . . . . . . . . . . . . . . . . 113

B.2.1 Fonctionnement de Mobile IPv6 . . . . . . . . . . . . . . . . 113

B.2.2 Limitations de Mobile IPv6 . . . . . . . . . . . . . . . . . . . 114

B.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

B.3 Home Agent Migration . . . . . . . . . . . . . . . . . . . . . . 117

B.3.1 Apercu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

B.3.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 118

B.3.3 Resultats experimentaux . . . . . . . . . . . . . . . . . . . . . 119

B.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

B.4 Deploiement de Mobile IPv6 . . . . . . . . . . . . . . . . . . 122

B.4.1 Emplacements des home agents . . . . . . . . . . . . . . . . . 122

B.4.2 Methodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

B.4.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

B.4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

B.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

B.5.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

B.5.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

108

The next pages correspond to a french resume of this thesis, which is a requirementof the University Pierre et Marie Curie.

Appendix B. Thesis’ French Version 109

B.1 Introduction

Dans les zones urbaines, les reseaux sans fil sont accessibles depuis divers endroitscomme les cafes, les parcs ou bien encore les lieux de travail. Par consequent, la densitedes points d’acces Wi-Fi est telle qu’il est possible d’en detecter des dizaines en sedeplacant dans les rues. Des lors, les utilisateurs de ces peripheriques mobiles peuventen tous lieux naviguer sur Internet ou bien encore telephoner gratuitement grace a lavoix sur IP (VoIP).

Une forte densite de points d’acces n’est cependant pas strictement synonyme demobilite. Ainsi, lorsqu’un peripherique mobile1 passe d’un point d’acces a un autre2,son adresse IP change et les connexions en cours sont perdues. Par consequent, il n’estpas possible de maintenir un appel telephonique lors d’un handover entre differentspoints d’acces Wi-Fi ou technologies d’acces (comme HSDPA ou EDGE). La mobilitepeut ainsi etre definie comme la capacite de se deplacer sans avoir de consequence surles communications en cours. Techniquement, du point de vue du protocole IP, un han-dover survient lors du passage d’un sous-reseau a un autre, et implique les contraintessuivantes qui constituent les problematiques inherentes aux differents protocoles gerantla mobilite.

1. Changement d’adresse IP

En raison des architectures de routage et d’adressage dans l’Internet, une adresseIP doit correspondre a la position physique du nœud. Autrement, il ne peutemettre et recevoir des paquets. Par consequent, un nœud mobile ne peut utiliserla meme adresse IP partout ou il va, et doit en obtenir une nouvelle lorsqu’il entredans un nouveau sous-reseau.

2. Pertes de connexions

Les protocoles de transport tels que TCP et UDP n’ont pas ete concus pourresister aux changements d’adresses IP. Les connexions en cours sont donc inter-rompues par les mouvements du nœud mobile. Les applications doivent egalementintegrer des mecanismes leur permettant de retablir automatiquement les connexionsperdues.

3. Communications de bout en bout

Actuellement, les communications clients/serveurs sont predominantes et peud’applications utilisent les communications de bout en bout en raison des limi-tations techniques relatives au NAT (Network Address Translation). Les arrivees

1egalement appele nœud mobile.2ce passage d’un reseau a un autre est appele handover.

110 B.1. Introduction

recentes de la VoIP et du protocole IPv6 se sont accompagnees du retour descommunications de bout en bout. Celles-ci constituent un challenge techniquedans le cadre des protocoles de gestion de la mobilite qui doivent etre capablesde resister aux changements d’adresses IP ainsi qu’a la perte des connexions.

B.1.1 Protocoles de mobilite

Differents protocoles [93, 91, 83, 94, 74, 100, 20] ont d’ores et deja ete proposespar l’Internet Engineering Task Force (IETF) pour gerer la mobilite et resoudre lesproblemes precedemment decrits. Bien que ces protocoles adoptent des approches etdes solutions techniques differentes, ils peuvent etre classes en fonction des criteressuivants.

1. Deploiement realiste

Afin de faciliter son adoption, un protocole de mobilite ne doit pas necessiter demodification sur les nœuds non mobiles3. Ceux-ci doivent egalement etre capablesde communiquer indifferemment avec des nœuds mobiles et des nœuds fixes. Eneffet, en ce qui concerne l’utilisation immediate d’un protocole de mobilite surl’Internet, il n’est pas possible de modifier tous les nœuds afin de gerer la mo-bilite. De plus, il est peu probable qu’aucun protocole de mobilite soit integredans les serveurs, comme ceux de Google ou de MSN, car cela conduirait a uneaugmentation des couts operationnels sans aucun benefice pour le fournisseur duservice.

2. Impact reduit sur le reseau

Les changements concernant l’architecture du reseau doivent etre compatiblesavec les technologies couramment utilisees sur l’Internet. Afin de realiser desdeploiements efficaces et rapides, seules les modifications incrementales de l’ar-chitecture de l’Internet doivent etre considerees. En effet, il n’est pas envisageablede changer le fonctionnement des architectures de routage et d’adressage actuel-lement utilisees.

3. Transparence vis-a-vis des protocoles de transport

Le protocole de mobilite permet aux connexions en cours de resister aux han-dovers sans pour autant modifier les applications et les protocoles de transportsclassiques. En termes de couches reseaux, ce point implique que le protocole demobilite se trouve en dessous des couches transports.

3egalement appeles nœuds fixes.


4. Performances equivalentes

Un protocole de mobilite ne doit pas serieusement alterer les performances, niinduire une charge importante sur le reseau. De plus, il doit pouvoir passer al’echelle et fournir des performances acceptables lorsque le nombre de nœudsmobile augmente.

Protocoles 1 2 3 4

SCTP, HIP x x

LISP x x x

MIPv6 x x x

OLSR, AODV x x

Tab. B.1 – Classification de differents protocoles de mobilite

En fonction des definitions precedentes, nous proposons une classification de differentsprotocoles de mobilite dans le tableau B.1. Celui-ci permet de constater facilement queles differents protocoles ont des champs d’application differents : certains requierent desmodifications sur tous les nœuds, ou dans le coeur du reseau. Par exemple, le protocoleOLSR (Optimize Link State Routing) [33] permet a des nœuds de communiquer dansdes environnements sans infrastructure en s’adaptant automatiquement a la mobilitedes nœuds, il impose par contre de modifier tous les nœuds souhaitant communiquer.Le protocole LISP reste, quant a lui, compatible avec les nœuds existants mais necessitede lourdes modifications de l’architecture de l’Internet.

Cette classification nous a conduit a nous interesser au protocole Mobile IPv6 caril satisfait trois des quatre points precedemment discutes. En effet, ce dernier restecompatible avec les protocoles de transport actuels, et n’entraıne pas de modificationsde l’infrastructure reseau ni des nœuds fixes. Au debut de mes recherches fin 2004,quatre implementations de Mobile IPv6 etaient disponibles, et le protocole etait acti-vement supporte par la plupart des equipementiers [13, 8, 32, 79]. Cependant, bien queconsidere comme une bonne solution intermediaire pour fournir un service de mobilitesur Internet, et devant bientot etre deploye commercialement, le protocole Mobile IPv6est sujet a plusieurs problemes qui limitent ses performances.

112 B.1. Introduction

L’objet de cette these est par consequent de proposer des solutions permettantd’ameliorer les performances du protocole Mobile IPv6 en controlant ses limitationspar des approches a la fois pratiques et theoriques.

B.1.2 Plan

Ce resume comprend quatre parties. Dans la Section B.2, nous introduisons toutd’abord le protocole Mobile IPv6 et ses limitations, afin de decrire le cadre dans lequels’inscrivent nos contributions. Ensuite, dans la Section B.3, nous decrivons une nouvellearchitecture distribuee basee sur Mobile IPv6, appelee Home Agent Migration. Dans laSection B.4, nous proposons des strategies de placement des home agents s’appuyantsur la theorie des graphes. Enfin, dans la Section B.5, nous concluons ce resume ensynthetisant les contributions de cette these et en presentant leurs perspectives d’ex-tension.


B.2 Mobile IPv6 et ses limitations

B.2.1 Fonctionnement de Mobile IPv6

L’architecture de routage de l’Internet impose une forte contrainte sur la positiongeographique d’un nœud. Une adresse appartenant a un prefixe IPv6 alloue a un four-nisseur d’acces francais ne peut etre utilisee pour recevoir des paquets au Japon. Parconsequent, l’architecture actuelle de l’Internet empeche un nœud de conserver sonadresse IPv6 lorsqu’il change de reseau. Cette limitation est liee au double role quejoue l’adresse IP pour un nœud : en plus de l’identifier uniquement (role d’identifier),elle fournit implicitement sa position sur le globe (role de locator). Le protocole MobileIPv6 fournit une solution pour decoupler ces deux roles. Le nœud mobile (en anglaisMobile Node, MN) se voit attribuer deux adresses IPv6 distinctes : la Home Address(HoA), qui joue le role d’identifier et qui appartient au prefixe IPv6 du reseau mere, etla Care-of Address (CoA), le locator.

Afin d’effectuer la relation entre la Home Address et la Care-of Address, Mobile IPv6utilise un routeur specifique place dans le reseau mere appele home agent. Il a pour butde fournir une Home Address appartenant au prefixe du reseau mere a tous les nœudsmobiles, et de retransmettre les paquets envoyes a la Home Address. A tout instant, lenœud mobile communiquera toujours avec sa Home Address independamment de sonreseau d’accueil.

En pratique, quand un nœud mobile arrive dans un nouveau reseau d’accueil, ilenvoie un message Binding Update au home agent afin d’enregistrer la relation entresa Home Address et sa nouvelle Care-of Address. A la reception de ce paquet, le homeagent met en place un tunnel IPv6 avec le nœud mobile, et ajoute cette nouvelle relationdans son Binding Cache (une table de routage specifique a Mobile IPv6). Pour finir,le home agent envoie un message Binding Acknowledgment au nœud mobile pour luiindiquer que la relation a bien ete effectuee. Un exemple d’utilisation de Mobile IPv6est presente dans la Figure B.1 ; tous les paquets envoyes par et a destination du nœudmobile doivent transiter par le home agent.

Les specifications de Mobile IPv6 incluent un mecanisme dit d’optimisation de route(en anglais Return Routability Procedure, RRP) permettant d’etablir une connexiondirecte entre le nœud mobile et ses correspondants qui ne transite pas par le home agent,comme illustre par les fleches en pointilles dans la Figure B.1. Les nœuds correspon-dants sont desormais capables de recevoir des messages Binding Update envoyes par les

114 B.2. Mobile IPv6 et ses limitations

HA Réseau mère

Réseaudu correspondant

Internet

Réseaud'accueil

CN

MN

tunnel

Chemin optimisé

Fig. B.1 – Mobile IPv6 : exemple de communication

nœuds mobiles. Cependant, ce mecanisme presente des limites, le rendant difficilementutilisable en pratique, qui sont presentees dans la section suivante.

B.2.2 Limitations de Mobile IPv6

Le protocole Mobile IPv6 presente un ensemble de problemes qui affectent ses per-formances. Ceux-ci sont lies a l’utilisation du home agent pour effectuer la relationentre la Home Address et la Care-of Address.

1. Routage Triangulaire

Avec Mobile IPv6, un nœud mobile ne peut etre associe qu’a un seul home agent.Tous les paquets echanges avec ses correspondants doivent tout d’abord etreroutes a ce home agent, puis retransmis au nœud mobile dans le tunnel. Cettedeviation des paquets via le home agent (dogleg routing en anglais) induit desdelais de communication plus importants lorsque le nœud mobile communiqueavec ses correspondants.

2. Position restreinte

L’emplacement du home agent est restreint par le home prefix. Celui-ci doitetre place ou ce prefixe est annonce sur l’Internet afin de recevoir les paquetsemis a destination des nœuds mobiles. Cette forte contrainte est particulierement


problematique car il est impossible de changer de home agent sans changer deHome Address.

3. Contrainte pour le reseau mere

Afin d’intercepter les paquets envoyes aux nœuds mobiles, le home agent doitrepondre aux messages de decouverte de voisins4 envoyes par le routeur d’accesa la place des nœuds mobiles. En pratique, le home agent se comporte comme unproxy pour la decouverte de voisins (Proxy NDP, en anglais [87]). Ceci impliqueque le nombre de messages de decouverte de voisins traites par le home agent estproportionnel au nombre de nœuds mobiles qu’il gere. De plus, la bande passanterequise par l’ensemble des nœuds mobiles peut etre superieure a celle du reseaumere. Par consequent, un deploiement de Mobile IPv6 peut etre difficile a mettreen oeuvre tout en conservant la stabilite du reseau mere.

Le mecanisme d’optimisation de route decrit dans les specifications de Mobile IPv6possede les limitations suivantes.

1. Modification des correspondants

Afin de communiquer directement sans passer par le home agent, tous les nœudsdoivent implementer le mecanisme d’optimisation de route. Cependant, il n’estpas realiste de considerer que tous les nœuds de l’Internet vont etre mis a jourpour supporter ce mecanisme. Par consequent, la plupart des nœuds ne pourrontbeneficier de cette optimisation de route, et la majeure partie du trafic continueraa transiter par le home agent.

2. Complexite

Avant l’envoi du message Binding Update a son correspondant, le nœud mobiledoit echanger quatre messages lui permettant de generer une cle cryptographiquepour signer le Binding Update. Cette procedure doit etre effectuee pour tous lescorrespondants du nœud mobile a chaque fois que celui-ci change de sous-reseau.

3. Surcharge des serveurs

Si l’on considere un serveur communiquant avec des milliers de clients, le mecanismed’optimisation de route induit une surcharge de traitement que ce serveur doiteffectuer afin de servir les requetes. En effet, davantage de paquets doivent etretraites par le serveur pour servir la meme quantite de requetes. Il est donc peuprobable que ce mecanisme d’optimisation de route soit un jour implemente dansdes serveurs car il ne represente pas de benefice immediat pour les societes com-merciales les exploitant.

4mecanisme remplacant ARP (Address Resolution Protocol) dans IPv6.

116 B.2. Mobile IPv6 et ses limitations

B.2.3 Conclusion

Le protocole Mobile IPv6 est completement transparent pour l’architecture del’Internet ainsi que pour les couches de transport TCP et UDP. Par consequent, ilrepresente une excellente solution de transition pour gerer la mobilite sur Internet sansmodification des nœuds fixes et des applications. Cependant, ses performances sontlimitees par des problemes lies a l’emplacement du home agent. Le routage triangulaireest un probleme particulierement serieux car il augmente la duree des handovers, etconduit a des delais de communication plus importants. En d’autres termes, le proto-cole Mobile IPv6 est affecte par l’emplacement du home agent.

Dans les sections suivantes, nous presentons deux solutions visant a resoudre lesproblemes induits par les home agents et leurs emplacements. La premiere, appeleeHome Agent Migration, adopte une approche pratique pour distribuer plusieurs homeagents dans un reseau a l’aide du routage anycast. La seconde decrit le routage triangu-laire en termes de theorie des graphes, et propose un algorithme permettant d’identifierau sein d’un reseau les emplacements les plus efficaces pour y installer des home agents.


B.3 Home Agent Migration

B.3.1 Apercu

Le concept fondamental de l’architecture Home Agent Migration est de distribuerplusieurs home agents au sein d’un meme reseau, et de les utiliser conjointement. L’ob-jectif de ce nouveau type de deploiement est de fournir une optimisation de route qui(1) reduit les delais de communication, (2) est compatible avec le protocole MobileIPv6 actuel, et (3) transparent vis-a-vis des nœuds correspondants, et de l’architectureactuelle de l’Internet.

HA 1

sous-réseau ADSLréseau du FAI

HA 2

HA 3

sous-réseau Wi-Fi

sous-réseau WiMAX

noeud A

noeud B

noeud C

Fig. B.2 – Home Agent Migration et differentes technologies d’acces

Un fournisseur d’acces a Internet (FAI) offrant une connectivite au travers dedifferentes technologies d’acces peut aisement tirer parti de cette architecture. Commeillustre Figure B.2, cet ISP peut ainsi distribuer des home agents dans chacun desreseaux d’acces. Les nœuds mobiles A, B, et C seront toujours associes avec le homeagent deploye dans leurs reseaux d’acces respectifs. Ces home agents etant prochesdes nœuds mobiles, l’effet du routage triangulaire est ainsi limite. Par consequent, lesnœuds mobiles peuvent conserver la meme adresse IP lorsqu’ils passent d’une techno-logie d’acces a une autre, tout en beneficiant d’un mecanisme d’optimisation de routeefficace.

118 B.3. Home Agent Migration

MN CN

b)

a) HA

InternetP-HA

Internet

HA 1 HA 2

Fig. B.3 – Mobile IPv6 compare a Home Agent Migration

B.3.2 Fonctionnement

Avec Home Agent Migration, les differents home agents sont deployes dans la to-pologie de l’Internet et annoncent le meme prefixe IPv6 a l’aide d’un protocole deroutage. Cette technique de routage, appelee routage anycast [69], est courammentutilisee afin de repartir la charge de trafic sur differents serveurs, et pour resoudredes problemes de redondance de serveurs. Pour mettre en oeuvre cette technique deroutage, les home agents peuvent utiliser n’importe quel protocole de routage, commeBGP4+ [23], OSPFv3 [35], ou bien encore RIPng [77]. Les home agents sont de plusinterconnectes pour former un reseau d’overlay leur permettant de s’echanger le traficde donnees des nœuds mobiles ainsi que les donnees de signalisation.

La Figure B.3 compare les architectures de Mobile IPv6 et de Home Agent Migra-tion. Grace a la distribution des home agents dans l’Internet, un nœud mobile seratoujours associe au home agent le plus proche : tout se passe comme si le home agentavait migre pres de l’emplacement du nœud mobile. Ce home agent est appele homeagent primaire (P-HA dans la Figure 3.3(b)) car il recoit le premier message BindingUpdate envoye par le nœud mobile. Les paquets envoyes par un correspondant sonttout simplement routes a son plus proche home agent, puis envoyes au home agentprimaire via le reseau d’overlay.


Avantages

Un nœud mobile sera toujours associe avec le plus proche home agent dans latopologie du reseau. Les home agents etant distribues, les trafics de donnees et designalisation sont ainsi repartis sur les differentes instances : le home agent n’est plusune limitation du point de vue des performances. En fonction des emplacements deshome agents, il est egalement possible d’optimiser efficacement les routes et de reduireles delais de communication par rapport a Mobile IPv6.

Les home agents etant interconnectes, ils sont capables de detecter que l’un d’entreeux ne fonctionne plus et de reagir en consequence. Ainsi, lorsque le home agent primaired’un nœud mobile tombe en panne, un autre home agent peut envoyer un message failurealert au nœud mobile et prendre la place du home agent primaire. A la reception de cemessage d’alerte, le nœud mobile envoie un message Binding Update au nouveau homeagent afin de retablir les communications en cours le plus rapidement possible.

Inconvenients

L’architecture Home Agent Migration s’appuie sur le routage anycast pour distri-buer les home agents. Elle est donc sensible aux pannes des routeurs ainsi qu’au tempsde convergence des protocoles de routage utilises. Par exemple, si un routeur controlantune zone geographique particuliere tombe en panne, les nœuds mobiles associes avecle home agent correspondant ne peuvent plus communiquer. De meme, les correspon-dants ne peuvent envoyer de donnees aux nœuds mobiles. Par consequent, une grandeattention doit etre apportee a la gestion des routeurs annoncant le prefixe IPv6.

Afin de tirer le meilleur parti des deploiements de Home Agent Migration, les empla-cements des home agents ainsi que leur nombre doivent etre choisis de facon meticuleuse.Des deploiements simples tels qu’effectues avec Mobile IPv6 ne sont plus possibles : lesadministrateurs doivent prealablement etudier quels emplacements seront les plus effi-caces en ce qui concerne les performances.

B.3.3 Resultats experimentaux

Afin de conduire nos experiences, un demon a ete developpe a l’aide de la pile IPv6de KAME [15], et de son API permettant de manipuler les paquets relatifs a MobileIPv6 [103, 30]. Ce demon est en fait une version simplifiee d’un home agent classiquepouvant synchroniser son Binding Cache avec d’autres home agents. Les nœuds mobilesutilisent quant a eux SHISA [13], l’implementation de Mobile IPv6 pour les noyauxBSD, ou sont emules a l’aide de Scapy6 [109].

120 B.3. Home Agent Migration

San Francisco

Internet

AS de WIDE

Amsterdam

HA 1 HA 2

Fig. B.4 – Topologie representant l’experience

La Figure B.4 presente une topologie abstraite de l’experience que nous avonsrealisee. Deux home agents ont ete deployes au sein de l’AS du projet WIDE, l’una Los Angeles, et l’autre a Tokyo. Chaque home agent annonce le prefixe IPv6 a l’aidedu protocole OSPFv3. Le nœud mobile est place a San Francisco, et le correspondanta Amsterdam. Dans ce reseau, le lien trans-pacifique entre les Etats-Unis et le Japoninduit des delais de communication importants. L’objet de cette experience est doncd’utiliser l’architecture Home Agent Migration afin de ne pas emprunter ce lien si lescorrespondants ne sont pas au Japon.

0

0.1

0.2

0.3

0.4

0.5

0 5 10 15 20 25 30 35 40

RTT

(sec

onde

s)

Temps (secondes)

(a) Chemin direct

0

0.1

0.2

0.3

0.4

0.5

0 5 10 15 20 25 30 35 40

RTT

(sec

onde

s)

Temps (secondes)

(b) Mobile IPv6

0

0.1

0.2

0.3

0.4

0.5

0 5 10 15 20 25 30 35 40

RTT

(sec

onde

s)

Temps (secondes)


Fig. B.5 – RTT entre San Francisco et Amsterdam

Les resultats de l’experience sont presentes dans la Figure B.5 qui montre le tempsd’aller retour (RTT) des communications entre le nœud mobile et son correspondantdans trois scenarios distincts ; (a) lorsqu’aucun protocole de mobilite n’est utilise (i.e.


chemin direct), (b) lorsque Mobile IPv6 est utilise, et (c) lorsque Home Agent Migrationest deploye. Dans le cas de Mobile IPv6, HA1 est utilise comme home agent du nœudmobile.

Dans la Figure B.5, le nœud mobile est place a San Francisco et le correspondanta Amsterdam. HA2 place a San Francisco est le home agent le plus proche du nœudmobile : c’est le home agent primaire lorsque Home Agent Migration est utilise. Parconsequent, le RTT avec Home Agent Migration est 220ms plus court que le RTTavec Mobile IPv6, lorsque le trafic passe par HA1 3.10(b). Cette difference s’expliquepar la duree du RTT du lien traversant le Pacifique : 110ms. Lorsque Mobile IPv6est utilise, les paquets utilisent 4 fois le lien trans-pacifique : 220ms sont alors ajoutesau RTT entre le nœud mobile et son correspondant. Avec Home Agent Migration, lespaquets sont interceptes par HA2 situes a San Francisco et n’utilisent jamais le lientrans-pacifique. L’architecture que nous proposons permet donc d’utiliser Mobile IPv6sans modification significative du RTT.

B.3.4 Conclusion

Nous avons propose une nouvelle architecture de gestion de la mobilite appeleeHome Agent Migration qui peut etre utilisee a l’echelle de l’Internet, et resout effi-cacement les limitations de Mobile IPv6. Dans notre solution, differents home agentssont distribues dans l’Internet, et annoncent le meme prefixe IPv6 a l’aide du routageanycast. A tout instant, les nœuds mobiles ne sont associes qu’a un seul home agent :le plus proche topologiquement.

A l’inverse des mecanismes d’optimisation de route precedemment definis, HomeAgent Migration reste totalement compatible avec l’architecture actuelle de l’Internet,et les implementations standard de Mobile IPv6. Si les home agents sont correctementdistribues, le delai entre les home agents et les nœuds mobiles peuvent etre controlespour reduire les effets du routage triangulaire.

122 B.4. Deploiement de Mobile IPv6

B.4 Deploiement de Mobile IPv6

Avec Mobile IPv6, l’emplacement du home agent est un aspect critique de toutdeploiement car il influe sur les delais de communication ainsi que sur la longueurdes chemins. Dans cette section, nous decrivons formellement Mobile IPv6 et HomeAgent Migration en termes de theorie des graphes. En outre, nous utilisons les notionsde degre et de centralite pour identifier les emplacements des home agents les plusappropries. Cette approche est differentes des autres solutions d’optimisation de routecar elle s’appuie uniquement sur un placement efficace des home agents, et de ce faitn’implique pas de modifier l’architecture de l’Internet et les implementations actuellesdu protocole Mobile IPv6.

B.4.1 Emplacements des home agents

Dans cette section, nous decrivons l’influence de Mobile IPv6 et Home Agent Mi-gration sur la longueur des chemins entre deux nœuds du graphe. En fonction de ladiscussion, les nœuds representent indifferemment les emplacements des home agents,des nœuds mobiles, et des correspondants. Nous definissons deux notations dmip6(A,B)et dham(A,B) representant la longueur des chemins lorsque Mobile IPv6 et Home AgentMigration sont mis en œuvre respectivement. Nous appellerons ces longueurs distancesde communication. Les longueurs de communication sont en general plus grandes queles distances dans le graphe, car le chemin doit passer par un ou deux home agents enfonction du protocole considere.

Importance des nœuds

Tous les nœuds d’un graphe n’ont pas la meme importance. Il existe differentesmesures permettant de determiner la place qu’occupe un nœud dans un graphe. Dansnotre etude, nous ne considerons que le degre des nœuds (i.e. le nombre de liens quepossede un nœud), et la centralite d’intermediarite 5 car ces deux mesures fournissentde bons resultats pour selectionner les emplacements des home agents.

La centralite d’un nœud x, notee CB(x), decrit la position de x vis-a-vis de tousles plus courts chemins dans le graphe auxquels x appartient. Pour tout nœud x, lacentralite est egale a :

5appelee simplement centralite par la suite.


CB(x) =∑

y 6=z 6=x∈V

ρyz(x)ρyz

, (B.1)

ou ρyz est le nombre de plus courts chemins de y a z, et ρyz(x) le nombre de plus courtschemins de y a z contenant x.

Mobile IPv6

Avec Mobile IPv6, les paquets echanges entre deux nœuds (correspondants et mo-biles) A et B doivent passer par le home agent HA. Par definition, la longueur duchemin resultant est la somme des distances entre A et HA, et HA et B :

dmip6(A,B) = d(A,HA) + d(HA, B) (B.2)


A l’inverse de Mobile IPv6, les communications entre des nœuds mobiles et corres-pondants ne sont pas equivalentes avec Home Agent Migration. Par consequent, nousdevons etudier separement deux motifs de communication differents : entre deux mo-biles A et B (ce cas est equivalent a une communication d’un nœud correspondant A

vers un nœud mobile B), equation B.3, et d’un nœud mobile C vers un correspondantD, equation B.4. Dans les equations suivantes, la notation HAX represente le homeagent ayant la plus petite distance a X.

dham(A,B) = d(A,HAA) + d(HAA,HAB) + d(HAB, B) (B.3)

dham(C,D) = d(C,HAC) + d(HAC , D) (B.4)

Emplacements de home agents

Avec Mobile IPv6, le cas optimal est celui ou la longueur du chemin entre deuxnœuds A et B n’est pas modifiee par le routage triangulaire (d(A,B) = dmip6(A,B)),c’est a dire que le home agent est situe sur le plus court chemin entre A et B. Parconsequent, les bons emplacements de home agents correspondent aux nœuds apparte-nant a un maximum de plus courts chemins dans le graphe, i.e. les nœuds de plus fortecentralite.


De meme, avec Home Agent Migration, lorsque deux nœuds mobiles MN1 et MN2communiquent6, les deux home agents primaires HAMN1 et HAMN2 doivent etre placessur le plus court chemin entre MN1 et MN2 afin d’obtenir des performances similairesa celles de la communication directe (d(MN1,MN2) = dham(MN1,MN2)).

B.4.2 Methodologie

Nous etudions ici les emplacements des home agents en placant les home agents, lesnœuds mobiles et les correspondants dans tous les nœuds du graphe, puis en comparantles distances de communication aux distances dans le graphe.

Calcul des distances, des degres et des centralites

Les distances entre tous les noeuds du graphe sont tout d’abord calculees, et stockeesdans le tableau distances : nous notons distances[A][B] la distance entre deux nœuds A

et B. Nous ne considerons que des graphes non orientes : distances[A][B] = distances[B][A].Nous utilisons l’algorithme Floyd-Warshall [50] pour calculer les distances entre toutesles paires des nœuds et construire le tableau distances. Le degre est directement calculeen utilisant le nombre de liens de chaque nœud. La centralite est, quant a elle, calculeeavec l’algorithme decrit par Brandes [107].

Emulation du routage anycast

Prealablement au calcul des distances de communication avec Home Agent Mi-gration, le routage anycast doit etre emule afin de determiner les home agents les plusproches des nœuds. Nous considerons ici que les home agents primaires sont selectionnesen fonction de leurs distances aux nœuds mobiles et aux nœuds correspondants. A par-tir du tableau, distances, des distances dans le graphe, d’une liste de home agents, ha,et d’un nœud, n, la fonction select pha() renvoie le home agent le plus proche de n, i.e.le nœud possedant la plus petite distance a n.

Algorithme employe

L’algorithme 2 decrit comment calculer les distances de communication, pour Mo-bile IPv6 et Home Agent Migration, a partir du tableau distances, d’une liste de homeagents ha, et de la liste de tous les nœuds du graphe nœuds. La ligne α est une optimi-sation qui utilise le fait que d(pha1, pha2) = 0 lorsque pha1 = pha2 afin d’uniformiserles calculs de distances de communication avec Mobile IPv6 et Home Agent Migration.

6egalement vrai pour des communications entre un nœud correspondant et un nœud mobile.


Algorithme 2: Distances de communication

Input: distances : tableau des distances, ha : liste des home agents,nœuds : liste des nœuds du graphe

distances communication = {} ;forall debut ∈ nœuds do

forall fin ∈ nœuds doif taille(ha) > 1 then

/* Home Agent Migration */pha1 = select pha(ha, debut) ;pha2 = select pha(ha, fin) ;

else/* Mobile IPv6 */pha1 = pha2 = ha[0] /* premier element de la liste */

endα distances communication[debut][fin] = distances[debut][pha1]

distances communication[debut][fin] += distances[pha1][pha2]distances communication[debut][fin] += distances[pha2][fin]

endreturn distances communication ;

end

B.4.3 Evaluation

Ici, nous evaluons deux strategies de placement de home agents, basees sur le degreet la centralite, dans le reseau du projet WIDE [16]. Il s’agit d’un reseau academiquejaponais interconnectant des campus universitaires. Le graphe associe a ce reseau a eteobtenu a partir des informations sur la topologie de niveau 2 fournies par les adminis-trateurs de ce reseau. Il contient 28 nœuds qui correspondent a des centres serveurs, oua des points de peering. Les liens ne sont pas ponderes.

Mobile IPv6

La Figure B.6(a) represente la modification des longueurs de chemins lorsque lehome agent est place dans un sous-reseau (nous supposons que les sous-reseaux cor-respondent a des nœuds de degre 1). L’axe des abscisses indique la modification deslongueurs de chemins en pourcentage : 100% signifie que la distance de communica-tion vaut le double de la distance directe. L’axe des ordonnees indique quant a lui lenombre de paires de nœuds dans le graphe pour lesquelles la modification est inferieureou egale a la valeur correspondante sur l’axe des x (min correspond au sous-reseau


0

20

40

60

80

100

0 200 400 600 800 1000

% d

es p

aire

s de

noe

uds

% ajoutés aux longueurs des chemins

maxmin

(a) Home agent dans un sous-reseau

0

20

40

60

80

100

0 200 400 600 800 1000

% d

es p

aire

s de

noe

uds

% ajoutés aux longueurs de chemins

maxplus grande centralité

plus grand degré

(b) Degre et centralite

Fig. B.6 – Mobile IPv6

qui modifie le plus les longueurs de chemins, et max a celui-ci les modifiant le moins).Nous constatons ainsi que lorsque le home agent est place dans le sous-reseau max, leslongueurs de chemins de 56% des paires de nœuds sont allongees de moins de 80%. Lavaleur correspondante est de 19% pour min.

Les sous-reseaux ne sont donc pas identiques d’un point de vue des performances. Iln’existe cependant pas de solution simple pour identifier facilement le nœud representantle sous-reseau qui fournit les meilleures performances. C’est pourquoi nous comparonsa present le sous-reseau max avec les nœuds possedant les degres et les centralites lesplus elevees7. Lorsque le home agent est place dans l’un des nœuds ayant le plus fortdegre ou la plus forte centralite, Figure B.6(b), le nombre de chemins qui ne sont pasmodifies augmente tres nettement : 51% et 54% de tous les plus courts chemins ne sontpas du tout modifies. La valeur correspondante est de 7% lorsque le home agent estplace dans le nœud max. Les performances sont donc nettement meilleures quand onchoisit l’un de ces nœuds.


La Figure B.7(a) represente la modification des longueurs de chemins lorsque lenombre de home agents augmente (ceux-ci sont classes puis selectionnes par centralitedecroissante). L’axe des abscisses indique la modification des longueurs de cheminsen pourcentages. L’axe des ordonnees indique, quant a lui, le nombre de paires denœuds dans le graphe pour lesquelles la modification est inferieure ou egale a la valeurcorrespondante sur l’axe des x. Il est clair qu’augmenter le nombre de home agents

7ces trois nœuds sont differents dans le graphe que nous etudions ici.


20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600 700 800

% d

es p

aire

s de

noe

uds

% ajoutés aux longueurs des chemins

1 HA2 HA5 HA

10 HA20 HA

(a) Variation du nombre de home agents

50

60

70

80

90

100

5 10 15 20 25

% d

es p

aire

s de

noe

uds

Nombre de home agents

centralitédegré

(b) Degre et centralite

Fig. B.7 – Home Agent Migration

implique que l’architecture controle un nombre plus important de plus courts chemins.Par voie de consequence, l’ajout de home agents s’accompagne d’une nette diminutiondes distances de communication par rapport a Mobile IPv6.

La Figure B.7(b) represente le pourcentage des paires de nœuds pour lesquelles leslongueurs de chemins sont modifiees de moins de 10%, en fonction du nombre de homeagents. Nous placons les home agents par ordre de degre et de centralite decroissants.Dans la plupart des cas, nous constatons ainsi que la centralite fournit de meilleursresultats que le degre pour la selection des home agents.

B.4.4 Conclusion

Dans cette section, nous avons formellement defini les protocoles Mobile IPv6 etHome Agent Migration en termes de theorie des graphes afin d’etudier leur influence surles distances de communication. Nous avons propose et evalue deux strategies de place-ment utilisant le degre et la centralite pour identifier les emplacements des home agents.Choisir le meilleur emplacement parmi un ensemble de home agents etant NP-difficile,nous avons montre que nos methodes de placement procurent une solution rapide etefficace pour selectionner les emplacements fournissant de bonnes performances.

En ce qui concerne le protocole Mobile IPv6, nous avons decrit le routage triangu-laire a l’aide des distances, et confirme que tous les emplacements de home agentsne sont pas equivalents. Placer un home agent dans un sous-reseau peut en outreserieusement affecter les performances et augmenter les distances de communication.Finalement, concernant Home Agent Migration, nous avons montre qu’utiliser plusieurshome agents diminue tres nettement les distances de communication.

128 B.5. Conclusion

B.5 Conclusion

B.5.1 Contributions

Cette these propose une architecture avancee de gestion de la mobilite s’appuyantsur la flexibilite du protocole Mobile IPv6, et peut etre deployee aussi bien dans l’In-ternet que dans un reseau d’operateur. Cette architecture s’articule autour de deuxtravaux distincts pouvant etre independamment utilises pour resoudre les limitationsde Mobile IPv6.

Tout d’abord, nous avons presente une architecture distribuee, appelee Home

Agent Migration, qui permet d’utiliser conjointement plusieurs home agents. Graceau routage anycast et a un placement judicieux des home agents, le chemin entre lesnœuds mobiles et leurs correspondants peut etre controle afin de limiter les effets du rou-tage triangulaire. En plus d’une description complete de cette architecture et du proto-cole mis en oeuvre, nous avons egalement valide son fonctionnement experimentalementdans le reseau du projet WIDE [16]. Ainsi, dans la majeure partie des cas, les delaisde communication avec Home Agent Migration sont comparables a ceux obtenus lors-qu’aucun protocole de gestion de mobilite n’est utilise.

Nous avons egalement etudie le protocole Mobile IPv6 en termes de theorie desgraphes, et montre que l’emplacement des home agents modifie les performances. Deplus, nous avons quantifie l’impact du routage triangulaire sur les chemins de commu-nications. En utilisant des graphes modelisant des reseaux d’operateurs, nous avonsprecisement compare les differents emplacements des home agents, et montre qu’ils nesont pas tous egaux du point de vue des performances obtenues. De plus, nous avonsconfirme que les nœuds ayant la plus grande centralite sont les meilleurs candidatspour accueillir des home agents. Nous avons propose un nouvel algorithme permettantd’identifier les emplacements des home agents avec Mobile IPv6 et Home AgentMigration dans n’importe quel reseau d’operateur. Cette etude a egalement montre queHome Agent Migration constitue une nette amelioration par rapport aux deploiementsclassiques de Mobile IPv6 et, de ce fait, complete l’evaluation experimentale dans lereseau du projet WIDE.

B.5.2 Perspectives

Le travail presente dans cette these peut etre approfondi de plusieurs manieresafin d’ameliorer l’architecture actuelle de Home Agent Migration. Ces perspectivesde recherche et d’ingenierie sont particulierement importantes pour permettre desdeploiements commerciaux de Home Agent Migration.


Avec l’architecture actuelle de Home Agent Migration, les informations contenuesdans le Binding Cache sont simplement envoyees a tous les home agents. Cette solutionfut adequate pour valider notre approche, cependant elle n’est pas appropriee pour ef-fectuer des deploiements efficaces de cette architecture. De meilleures approches doiventetre etudiees pour distribuer le Binding Cache tout en diminuant la taille des copieslocales. Les tables de hachage distribuees (en anglais Distributed Hash Table, DHT)representent ainsi une premiere approche afin de proposer une solution pour distribuer

le Binding Cache efficacement. Cependant, il est fort possible qu’aucune methodede distribution generique ne puisse etre concue car elle est tres liee a la mobilite des uti-lisateurs. Ainsi, si l’on considere un deploiement planetaire de Home Agent Migration,les informations concernant des utilisateurs japonais se deplacant uniquement dans laregion de Tokyo ne doivent idealement pas etre distribuees aux autres home agentssi les communications de ces utilisateurs sont principalement locales et se limitent auJapon.

Home Agent Migration ameliore sensiblement la disponibilite de Mobile IPv6. Ce-pendant, cette architecture est sensible a la stabilite des protocoles de routage utilisespour annoncer le prefixe IPv6. En raison du routage anycast, si un routeur connectantun home agent cesse de fonctionner, les nœuds mobiles associes a ce home agent nepourront plus communiquer tant que le protocole de routage n’aura pas converge. Dessolutions basees sur des routeurs redondants ou des home agents multi-homes peuventetre envisagees. Cependant, avant tout autre travail, il est necessaire de quantifier

l’impact des problemes de routage sur la disponibilite d’un deploiement de HomeAgent Migration. Ceci pourrait eventuellement permettre d’anticiper les problemes deroutage, et de definir des solutions limitant leurs consequences.

Afin de totalement valider l’architecture de Home Agent Migration, il convient d’ef-fectuer un deploiement a l’echelle de l’Internet en distribuant les home agents eten annoncant le prefixe IPv6 depuis differents endroits dans le monde. Cette experienceest en effet complementaire de celle conduite dans le reseau du projet WIDE. De plus,un tel deploiement peut egalement permettre de monitorer les routeurs utilises pourgerer l’anycast et ainsi aider a identifier puis analyser les problemes de routage tels queprecedemment decrits.

Actuellement, avec Home Agent Migration, seules les communications intra homeagents sont protegees par IPsec. Les communications entre les home agents et les nœudsmobiles etant des cibles de choix pour des attaquants eventuels, il convient d’effectuerdes tests d’interoperabilite entre Home Agent Migration et IPsec. Notre expertisede Mobile IPv6 et d’IPsec nous conduit a penser qu’il ne devrait pas y avoir de probleme,

130 B.5. Conclusion

et que peu de modifications de leurs implementations seront necessaires. Finalement,concernant la securite au sens large, l’integration des architectures Home Agent Mi-

gration et AAA8 doit egalement etre etudiee avant tout deploiement commercial. Sil’on considere Home Agent Migration et differents fournisseurs d’acces a Internet, cetteintegration permettra de mettre en place des accords d’itinerance, et de faciliter lesmouvements des utilisateurs dans ce systeme de mobilite a l’echelle planetaire.

8Authentication, Authorization and Accounting.

Bibliography

[1] Akamai. http://www.akamai.com/.

[2] BlackBerry. http://www.blackberry.com/.

[3] Cisco Security Advisory: IPv6 Routing Header Vulnerability.http://www.cisco.com/warp/public/707/cisco-sa-20070124-IOS-IPv6.shtml.

[4] CRAWDAD. http://crawdad.cs.dartmouth.edu/.

[5] The GEANT Website. http://www.geant.net/.

[6] Google Maps. http://www.google.com/gmm/index.html.

[7] iTunes Wi-Fi Music Store. http://www.apple.com/itunes/store/wifistore.html.

[8] Mobile IPv6 For Linux. http://www.mobile-ipv6.org/.

[9] network cartographer (nec). http://dpt-info.u-strasbg.fr/∼magoni/nec/.

[10] PlanetLab. http://www.planet-lab.org/.

[11] Python programming language. http://www.python.org/.

[12] Route Views Project Page. http://www.routeviews.org/.

[13] SHISA Mobile IPv6 for BSD kernels. http://www.mobileip.jp/.

[14] tcpdump. http://www.tcpdump.org/.

[15] The KAME project. http://www.kame.net/.

[16] WIDE Project. http://www.wide.ad.jp/.

132 Bibliography

[17] IEEE Standard for Information technology-Telecommunications and informa-tion exchange between systems-Local and metropolitan area networks-Specificrequirements - Part 11: Wireless LAN Medium Access Control (MAC) and Phys-ical Layer (PHY) Specifications. IEEE Std 802.11-2007 (Revision of IEEE Std802.11-1999), pages C1–1184, June 12 2007.

[18] J. Abley, P. Savola, and G. Neville-Neil. Deprecation of Type 0 Routing Headersin IPv6. RFC 5095 (Proposed Standard), December 2007.

[19] J. Arkko, V. Devarapalli, and F. Dupont. Using IPsec to Protect Mobile IPv6Signaling Between Mobile Nodes and Home Agents. RFC 3776 (Proposed Stan-dard), June 2004. Updated by RFC 4877.

[20] J. Arkko, C. Vogt, and W. Haddad. Enhanced Route Optimization for MobileIPv6. RFC 4866 (Proposed Standard), May 2007.

[21] Brice Augustin, Xavier Cuvellier, Benjamin Orgogozo, Fabien Viger, Timur Fried-man, Matthieu Latapy, Clemence Magnien, and Renata Teixeira. Avoiding tracer-oute anomalies with Paris traceroute. In IMC ’06: Proceedings of the 6th ACMSIGCOMM conference on Internet measurement, pages 153–158, New York, NY,USA, 2006. ACM.

[22] Tuomas Aura. Mobile IPv6 Security. In Proc. Security Protocols, 10th Interna-tional Workshop, volume 2845 of LNCS, pages 215–228, Cambridge, UK, April2002. Springer.

[23] T. Bates, R. Chandra, D. Katz, and Y. Rekhter. Multiprotocol Extensions forBGP-4. RFC 4760 (Draft Standard), January 2007.

[24] Yigal Bejerano and Israel Cidon. An Anchor Chain Scheme for IP MobilityManagement. In Wireless Networks Volume 9, Issue 5, pages 409–420, September2003.

[25] Claude Berge. Theorie des graphes et ses applications. Dunod, 1963.

[26] Philippe Biondi. Scapy. http://www.secdev.org/projects/scapy/.

[27] Philippe Biondi and Arnaud Ebalard. IPv6 Routing Header Security. InCanSecWest Security Conference, April 2007.

[28] R. Bonica, D. Gan, D. Tappan, and C. Pignataro. Extended ICMP to SupportMulti-Part Messages. RFC 4884 (Proposed Standard), April 2007.

Bibliography 133

[29] C. Castelluccia. HMIPv6: A Hierarchical Mobile IPv6 Proposal. In ACM MobileComputing and Communication Review (MC2R), April 2000.

[30] S. Chakrabarti and E. Nordmark. Extension to Sockets API for Mobile IPv6(work in progress, draft-ietf-mip6-mipext-advapi-07.txt). Internet Draft, InternetEngineering Task Force, February 2006.

[31] B. Chambless and J. Binkley. Home Agent Redundancy Protocol (HARP) (ex-pired, draft-chambless-mobileip-harp-00.txt). Internet Draft, Internet Engineer-ing Task Force, 1997.

[32] Cisco IOS IPv6 Configuration Library. Implementing Mobile IPv6. Technicalreport.

[33] T. Clausen and P. Jacquet. Optimized Link State Routing Protocol (OLSR).RFC 3626 (Experimental), October 2003.

[34] L. Colitti, E. Romijn, H. Uijterwaal, and A. Robachevsky. Evaluating the effectsof anycast on DNS root name servers. In RIPE document RIPE-393, 2006.

[35] R. Coltun, D. Ferguson, and J. Moy. OSPF for IPv6. RFC 2740 (ProposedStandard), December 1999.

[36] A. Conta, S. Deering, and M. Gupta. Internet Control Message Protocol(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC 4443(Draft Standard), March 2006. Updated by RFC 4884.

[37] M. Crawford and B. Haberman. IPv6 Node Information Queries. RFC 4620(Experimental), August 2006.

[38] Mark Crovella and Robert Carter. Dynamic Server Selection in the Internet. InProceedings of the Third IEEE Workshop on the Architecture and Implementationof High Performance Communication Subsystems (HPCS ’95), 1995.

[39] L. Dall’Asta, I. Alvarez-Hamelin, A. Barrat, A. Vazquez, , and A. Vespignani.Exploring networks with traceroute-like probes: Theory and simulations. In The-oretical Computer Science 355, 2006.

[40] David C. Bell, John S. Atkinson and Jerry W. Carlson. Centrality measures fordisease transmission networks. Social Networks, 21:1–21, 1999.

134 Bibliography

[41] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC2460 (Draft Standard), December 1998. Updated by RFC 5095.

[42] V. Devarapalli and F. Dupont. Mobile IPv6 Operation with IKEv2 and theRevised IPsec Architecture. RFC 4877 (Proposed Standard), April 2007.

[43] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Network Mobility(NEMO) Basic Support Protocol. RFC 3963 (Proposed Standard), January 2005.

[44] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, and M. Carney. DynamicHost Configuration Protocol for IPv6 (DHCPv6). RFC 3315 (Proposed Stan-dard), July 2003. Updated by RFC 4361.

[45] T. Ernst and H. Lach. Network Mobility Support Terminology (work in progress,draft-ietf-nemo-terminology-03). Internet Draft, Internet Engineering Task Force,May 2003.

[46] P. Eronen. IKEv2 Mobility and Multihoming Protocol (MOBIKE). RFC 4555(Proposed Standard), June 2006.

[47] F. Dupont and J-M. Combes. Using IPsec between Mobile and CorrespondentIPv6 Nodes. Internet-Draft, Internet Engineering Task Force, December 2005.

[48] J. Faizan, H. El-Rewini, and M. Khalil. Virtual Home Agent Reliability Proto-col (VHAR) (expired, draft-jfaizan-mipv6-vhar-02.txt). Internet Draft, InternetEngineering Task Force, April 2004.

[49] D. Farinacci, V. Fuller, D. Oran, and D. Meyer. Locator/ID Separation Protocol(LISP). Internet Draft, Internet Engineering Task Force, November 2007.

[50] Robert W. Floyd. Algorithm 97: Shortest path. Commun. ACM, 5(6):345, 1962.

[51] Bryan Ford, Dan Kegel, and Pyda Srisuresh. Peer-to-Peer Communication AcrossNetwork Address Translators. In Proceedings of the 2005 USENIX TechnicalConference, 2005.

[52] D. Forsberg, J. T. Malinen, T. Weckstrom, and M. Tiusanen. Distributing mobil-ity agents hierarchically under frequent location updates. In Mobile MultimediaCommunications, 1999. (MoMuC ’99), pages 159–168, November 1999.

[53] Linton C. Freeman. A Set of Measures of Centrality Based on Betweenness.Sociometry, 40(1):35–41, March 1977.

Bibliography 135

[54] Jean-Loup Guillaume, Matthieu Latapy, and Damien Magoni. Relevance of mas-sively distributed explorations of the Internet topology: Qualitative results. Com-puter Networks, 50(16):3197–3224, 2006.

[55] Guillaume Valadon, Florian Le Goff and Christophe Berger. Daily Walks in Paris:A Practical Analysis of Wi-Fi Access Points. In Student Workshop CoNext, New-York, December 2007.

[56] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil. ProxyMobile IPv6 (work in progress, draft-sgundave-mip6-proxymip6-10). InternetDraft, Internet Engineering Task Force, February 2008.

[57] D. Harkins and D. Carrel. The Internet Key Exchange (IKE). RFC 2409 (Pro-posed Standard), November 1998. Obsoleted by RFC 4306, updated by RFC4109.

[58] J. Heffner, M. Mathis, and B. Chandler. IPv4 Reassembly Errors at High DataRates. RFC 4963 (Informational), July 2007.

[59] R. Hinden and D. Thaler. IPv6 Host-to-Router Load Sharing. RFC 4311 (Pro-posed Standard), November 2005.

[60] Choong Seon Hong, Ki-Woon Yim, Dae-Young Lee, and Dong-Sik Yun. AnEfficient Fault Tolerance Protocol with Backup Foreign Agents in a Hierarchi-cal Local Registration Mobile IP. In ETRI Journal, vol.24, no.1, pages 12–22,Febuary 2002.

[61] Luigi Iannone and Serge Fdida. MeshDV: A Distance Vector mobility-tolerantrouting protocol for Wireless Mesh Networks. Jul 2005.

[62] ICANN. Root server attack on 6 February 2007. ICANN factsheet, ICANN,2007.

[63] William D. Ivancic, David Stewart, Terry L. Bell, Phillip E. Paulsen, and DanShell. Use of Mobile-IP Priority Home Agents for Aeronautics Space Operationsand Military Applications. In IEEE Aerospace Conference 2004, March 2004.

[64] Sugih Jamin, Cheng Jin, Yixin Jin, Danny Raz, Yuval Shavitt, and Lixia Zhang.On the Placement of Internet Instrumentation. In INFOCOM 2000 (1), pages295–304, 2000.

136 Bibliography

[65] D. Johnson and S. Deering. Reserved IPv6 Subnet Anycast Addresses. RFC 2526(Proposed Standard), March 1999.

[66] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6. RFC 3775(Proposed Standard), June 2004.

[67] Kipp Jones and Ling Liu. What Where Wi: An Analysis of Millions of Wi-FiAccess Points. In Proceedings of 2007 IEEE Portable: International Conferenceon Portable Information Devices, May 2007.

[68] Kaspersky Lab. Wardriving in London. http://www.viruslist.com/, May 2007.

[69] D. Katabi and J. Wroclawski. A framework for scalable global IP-anycast (GIA).In ACM SIGCOMM’2000, August 2000.

[70] C. Kaufman. Internet Key Exchange (IKEv2) Protocol. RFC 4306 (ProposedStandard), December 2005.

[71] S. Kent. IP Authentication Header. RFC 4302 (Proposed Standard), December2005.

[72] S. Kent. IP Encapsulating Security Payload (ESP). RFC 4303 (Proposed Stan-dard), December 2005.

[73] S. Kent and K. Seo. Security Architecture for the Internet Protocol. RFC 4301(Proposed Standard), December 2005.

[74] R. Koodli. Fast Handovers for Mobile IPv6. RFC 4068 (Experimental), July2005.

[75] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones. SOCKS ProtocolVersion 5. RFC 1928 (Proposed Standard), March 1996.

[76] Damien Magoni and Mickael Hoerdt. Internet core topology mapping and anal-ysis. Computer Communications, 28(5):494–506, 2005.

[77] G. Malkin and R. Minnear. RIPng for IPv6. RFC 2080 (Proposed Standard),January 1997.

[78] Steven McCanne and Van Jacobson. The BSD packet filter: A new architecturefor user-level packet capture. In USENIX Winter, pages 259–270, 1993.

[79] Microsoft Corporation. Understanding Mobile IPv6, November 2005.

Bibliography 137

[80] I. Mizuko, D. Okabe, and M. Matsuda. Portable, Pedestrian: Mobile Phones inJapanese Life. In MIT Press, Cambridge, MA, 2005.

[81] m:metrics. m:metrics: iphone hype holds up, March 2008.http://www.mmetrics.com/press/PressRelease.aspx?article=20080318-iphonehype.

[82] P.V. Mockapetris. Domain names - concepts and facilities. RFC 1034 (Standard),November 1987. Updated by RFCs 1101, 1183, 1348, 1876, 1982, 2065, 2181, 2308,2535, 4033, 4034, 4035, 4343, 4035, 4592.

[83] R. Moskowitz and P. Nikander. Host Identity Protocol (HIP) Architecture. RFC4423 (Informational), May 2006.

[84] Steve Mtika and Fambirai Takawira. Mobile IPv6 Regional Mobility Manage-ment. In Proceedings of the 4th international symposium on Information andcommunication technologies, pages 93 – 98, January 2005.

[85] Andrew Myles, David B. Johnson, and Charles Perkins. A Mobile Host Pro-tocol Supporting Route Optimization and Authentication. In IEEE Journal onSelected Areas in Communications, special issue on Mobile and Wireless Com-puting Networks, vol.13, No.5, pages 823–849, June 1995.

[86] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6(IPv6). RFC 2461 (Draft Standard), December 1998. Obsoleted by RFC 4861,updated by RFC 4311.

[87] T. Narten, E. Nordmark, W. Simpson, and H. Soliman. Neighbor Discovery forIP version 6 (IPv6). RFC 4861 (Draft Standard), September 2007.

[88] C. Ng, P. Thubert, M. Watari, and F. Zhao. Network Mobility Route Optimiza-tion Problem Statement (work inprogress, draft-ietf-nemo-ro-problem-statement-03). Internet Draft, Internet Engineering Task Force, September 2006.

[89] P. Nikander, J. Arkko, T. Aura, G. Montenegro, and E. Nordmark. Mobile IPVersion 6 Route Optimization Security Design Background. RFC 4225 (Informa-tional), December 2005.

[90] H. Omar, T. Saadawi, and M. Lee. Support for Fault Tolerance in Local Regis-tration Mobile-IP Systems. In MILCOM 1999 - IEEE Military CommunicationsConference, pp. 126 - 130, October 1999.

138 Bibliography

[91] L. Ong and J. Yoakum. An Introduction to the Stream Control TransmissionProtocol (SCTP). RFC 3286 (Informational), May 2002.

[92] A. Patel, K. Leung, M. Khalil, H. Akhtar, and K. Chowdhury. AuthenticationProtocol for Mobile IPv6. RFC 4285 (Informational), January 2006.

[93] C. Perkins. IP Mobility Support for IPv4. RFC 3344 (Proposed Standard),August 2002. Updated by RFC 4721.

[94] C. Perkins, E. Belding-Royer, and S. Das. Ad hoc On-Demand Distance Vector(AODV) Routing. RFC 3561 (Experimental), July 2003.

[95] PlaceEngine. http://www.placeengine.com/.

[96] L. Qiu, V. N. Padmanabhan, and G. M. Voelker. One The Placement of WebServer Replicas. In INFOCOM 2001, 2001.

[97] S. Sugimoto, F. Dupont and N. Nakamura. PF KEY Extensions as an Inter-face between Mobile IPv6 and IPsec/IKE (draft-sugimoto-mip6-pfkey-migrate-02). Internet-Draft, Internet Engineering Task Force, September 2006.

[98] Behcet Sarikaya. Home Agent Placement and IP Address Management for In-tegrating WLANs with Cellular Networks. Wireless Communications, IEEE,13:77–86, December 2006.

[99] Skyhook Wireless. http://www.skyhookwireless.com/.

[100] H. Soliman, C. Castelluccia, K. El Malki, and L. Bellier. Hierarchical MobileIPv6 Mobility Management (HMIPv6). RFC 4140 (Experimental), August 2005.

[101] Dug Song. libdnet. http://libdnet.sourceforge.net/.

[102] N. Spring, R. Mahajan, and D. Wetherall. Measuring ISP Topologies with Rock-etfuel. In ACM/SIGCOMM, August 2002.

[103] W. Stevens, M. Thomas, E. Nordmark, and T. Jinmei. Advanced Sockets Ap-plication Program Interface (API) for IPv6. RFC 3542 (Informational), May2003.

[104] R. Stewart. Stream Control Transmission Protocol. RFC 4960 (Proposed Stan-dard), September 2007.

Bibliography 139

[105] S. Thomson, T. Narten, and T. Jinmei. IPv6 Stateless Address Autoconfigura-tion. RFC 4862 (Draft Standard), September 2007.

[106] P. Thubert, R. Wakikawa, and V. Devarapalli. Global HA to HA protocol, (workin progress, draft-thubert-nemo-global-haha-00.txt). Internet Draft, Internet En-gineering Task Force, October 2004.

[107] Ulrik Brandes. A Faster Algorithm for Betweenness Centrality. Journal of Math-ematical Sociology, 25:163–167, 2001.

[108] Guillaume Valadon. BPF mode for Scapy. http://hg.natisbad.org/scapy-bpf/.

[109] Guillaume Valadon and Arnaud Ebalard. IPv6 support for Scapy.http://namabiiru.hongo.wide.ad.jp/scapy6/.

[110] Guillaume Valadon and Ryuji Wakikawa. Extending Home Agent Migration ToMobile IPv6 based Protocols. In AINTEC07, Phuket, Thailand, December 2007.

[111] R. Wakikawa. Home Agent Reliability Protocol (work in progress, draft-ietf-mip6-hareliability-01.txt). Internet Draft, Internet Engineering Task Force, March2007.

[112] R. Wakikawa, V. Devarapalli, and P. Thubert. Inter Home Agents Protocol(HAHA) (work in progress, draft-wakikawa-mip6-nemo-haha-01.txt). InternetDraft, Internet Engineering Task Force, February 2004.

[113] R. Wakikawa, T. Ernst, K. Nagami, and V. Devarapalli. Multiple Care-of Ad-dresses Registration (work in progress, draft-ietf-monami6-multiplecoa-06). In-ternet Draft, Internet Engineering Task Force, February 2008.

[114] R. Wakikawa., S. Koshiba, K. Uehara, and J. Murai. ORC: Optimized RouteCache Management Protocol for Network Mobility. In IEEE 10th InternationalConference on Telecommunication (ICT) 2003, pages 119–126, February 2003.

[115] R. Wakikawa, P. Thubert, and V. Devarapalli. Inter Home Agents Protocol Spec-ification, (work in progress, draft-wakikawa-mip6-nemo-haha-spec-00.txt). Inter-net Draft, Internet Engineering Task Force, October 2004.

[116] Ryuji Wakikawa, Guillaume Valadon, and Jun Murai. Distributed Mobility Man-agement Scheme for Mobile IPv6. Submitted to IEICE Transactions on Commu-nications Special Section on Networking Technologies for Dependable Networks.

140 Bibliography

[117] Ryuji Wakikawa, Guillaume Valadon, and Jun Murai. Migrating Home AgentsTowards Internet-Scale Mobility Deployments. In CoNext06, Lisbonne, Portugal,December 2006.

[118] Sami Tabbane Xavier Lagrange, Philippe Godlewski. Reseaux GSM. Hermes -Lavoisier, 2000.

List of Figures

1.1 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Mobile IPv6 terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Mobile IPv6: communication example . . . . . . . . . . . . . . . . . . . 162.3 Mobile IPv6: packets exchanges . . . . . . . . . . . . . . . . . . . . . . . 172.4 Return Routability Procedure: communication example . . . . . . . . . 182.5 Return Routability Procedure: packets exchanges . . . . . . . . . . . . . 192.6 NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.7 Nested NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.8 Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.9 Fast Handover for Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 312.10 Multiple Care-of Address . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1 Home Agent Migration and different access technologies . . . . . . . . . 373.2 Concept of Home Agent Migration . . . . . . . . . . . . . . . . . . . . . 383.3 Mobile IPv6 compared to Home Agent Migration . . . . . . . . . . . . . 393.4 Concept of Global Mobile eXchange . . . . . . . . . . . . . . . . . . . . 403.5 Home Agent Migration: communication examples . . . . . . . . . . . . . 443.6 An example of home agents configuration . . . . . . . . . . . . . . . . . 463.7 Home Agent Migration: packets exchanges . . . . . . . . . . . . . . . . . 483.8 Abstract network topology of the experimentation . . . . . . . . . . . . 523.9 RTT between San Francisco and Tokyo . . . . . . . . . . . . . . . . . . 533.10 RTT between San Francisco and Amsterdam . . . . . . . . . . . . . . . 533.11 RTT between San Francisco and Belgium . . . . . . . . . . . . . . . . . 53

4.1 Examples of unweighted and weighted graphs . . . . . . . . . . . . . . . 61

142 List of Figures

4.2 Centrality: example graph . . . . . . . . . . . . . . . . . . . . . . . . . . 624.3 Relation between a Network Operating Center and graph vertex . . . . 654.4 Degree against betweenness centrality . . . . . . . . . . . . . . . . . . . 724.5 Degree against betweenness centrality: example graph . . . . . . . . . . 734.6 Mobile IPv6: one home agent located in a subnetwork (unweighted) . 744.7 Mobile IPv6: one home agent located in a subnetwork (GEANT) . . . . . 754.8 Mobile IPv6: degree and betweenness centrality (unweighted) . . . . . 764.9 Mobile IPv6: degree and betweenness centrality (GEANT) . . . . . . . . . 764.10 Centrality: example graph . . . . . . . . . . . . . . . . . . . . . . . . . . 774.11 Home Agent Migration: correspondent and mobile nodes communica-

tions (unweighted) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.12 Home Agent Migration: correspondent and mobile nodes communica-

tions (GEANT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.13 Home Agent Migration: increasing the number of home agents (un-

weighted) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.14 Home Agent Migration: increasing the number of home agents (GEANT) . 814.15 Home Agent Migration: comparison of degree and betweenness centrality

(unweighted) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.16 Home Agent Migration: comparison of degree and betweenness centrality

(GEANT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

A.1 Routing Header Type 0 processing . . . . . . . . . . . . . . . . . . . . . 101A.2 Advanced traceroutes using Routing Header Type 0 . . . . . . . . . . . 103A.3 Indirect traceroute with Scapy6 . . . . . . . . . . . . . . . . . . . . . . . 104A.4 Routing Header Type 0 based attacks: capacitor effect . . . . . . . . . . 104

B.1 Mobile IPv6 : exemple de communication . . . . . . . . . . . . . . . . . 114B.2 Home Agent Migration et differentes technologies d’acces . . . . . . . . 117B.3 Mobile IPv6 compare a Home Agent Migration . . . . . . . . . . . . . . 118B.4 Topologie representant l’experience . . . . . . . . . . . . . . . . . . . . . 120B.5 RTT entre San Francisco et Amsterdam . . . . . . . . . . . . . . . . . . 120B.6 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126B.7 Home Agent Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

List of Tables

1.1 Identifiers examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Design constraints and mobility protocols examples . . . . . . . . . . . . 8

3.1 Round Trip Time in our experiment (in ms) . . . . . . . . . . . . . . . . 52

4.1 Comparison of centrality values for the graph of Figure 4.2 . . . . . . . 63

B.1 Classification de differents protocoles de mobilite . . . . . . . . . . . . . 111

Resume

L’architecture de l’Internet est telle que, lorsqu’un utilisateur se deplace et changede reseau, l’adresse IP de son peripherique est modifiee, entraınant la perte des com-munications en cours. Afin de resoudre ce probleme, des protocoles de gestion de lamobilite ont ete definis pour rendre les communications insensibles aux mouvements etindependantes du reseau ou se trouve l’utilisateur. Cependant, la plupart des proposi-tions souffrent de problemes affectant leurs performances, ou bien encore leur utilisationdans l’architecture actuelle de l’Internet. Par exemple, certaines d’entre elles, commele protocole HIP, imposent que tous les peripheriques, y compris ceux qui sont fixes,implementent le protocole de mobilite. D’autres encore, tel que le protocole MobileIPv6, induisent des chemins plus longs et donc des delais de communication plus im-portants.

Ce travail de these vise a ameliorer les performances du protocole Mobile IPv6en controlant les differentes limitations induites par l’utilisation d’un routeur gerant lamobilite: le home agent. Pour ce faire, nous proposons deux approches complementairesqui tout en etant compatibles avec l’infrastructure actuelle de l’Internet, permettentde gerer la mobilite de facon transparente a la fois pour le reseau et les peripheriquesfixes. Tout d’abord, nous decrivons une nouvelle architecture distribuee de gestion dela mobilite appelee Home Agent Migration qui permet d’utiliser plusieurs home agentssimultanement. Grace a un deploiement reel, nous montrons qu’il est possible d’obtenirdes performances comparables a celles de communications n’utilisant pas Mobile IPv6.Ensuite, nous definissons formellement les proprietes des emplacements des home agentsen termes de theorie des graphes. En s’appuyant sur cette etude, nous quantifionsl’impact du protocole Mobile IPv6 sur les communications. Finalement, nous proposonsun nouvel algorithme qui permet de traiter les problematiques de deploiement de MobileIPv6 et de Home Agent Migration dans des graphes qui modelisent des reseaux decommunication.

Mots-Cles

Mobile IPv6, gestion de la mobilite, anycast, graphe, centralite

mobile ipv6 : architectures et protocolesguillaume.valadon.net/research/files/thesis.pdf · mobile...

Documents