Mobile Ipv6

Th`se de Doctorat de lUniversit Paris VI e e Pierre et Marie Curie
Spcialit e e
` Systemes Informatiques
prsente par e e
Guillaume Valadon
pour obtenir le grade de
Docteur de lUniversit Pierre et Marie Curie e
Mobile IPv6 : architectures et protocoles
soutenue le 27 Juin 2008 devant le jury compos de e MM. : MM. : Eric Thomas Rui Hiroshi Sbastien e Serge Ryuji Fleury Noel Aguiar Esaki Tixeuil Fdida Wakikawa Rapporteurs Examinateurs
M. : M. :
Directeur Encadrant
Th`se de Doctorat de lUniversit Paris VI e e Pierre et Marie Curie
Spcialit e e
` Systemes Informatiques
prsente par e e
Guillaume Valadon
pour obtenir le grade de
Docteur de lUniversit Pierre et Marie Curie e
Mobile IPv6 : architectures et protocoles
soutenue le 27 Juin 2008 devant le jury compos de e MM. : MM. : Eric Thomas Rui Hiroshi Sbastien e Serge Ryuji Fleury Noel Aguiar Esaki Tixeuil Fdida Wakikawa Rapporteurs Examinateurs
M. : M. :
Directeur Encadrant
Remerciements
Je remercie Eric FLEURY, Professeur ` lEcole Normale Suprieure de Lyon, et a e Thomas NOEL, Professeur ` lUniversit Louis Pasteur de Strasbourg, davoir bien a e voulu accepter la charge de rapporteurs. Je remercie Rui AGUIAR, Professeur ` lUniversit dAveiro au Portugal, Hiroshi a e ESAKI, Professeur ` lUniversit de Tokyo au Japon, et Sbastien TIXEUIL, Professeur a e e a ` lUniversit Pierre et Marie Curie, davoir bien voulu juger ce travail. e Je remercie Serge FDIDA, Professeur ` lUniversit Pierre et Marie, davoir bien a e voulu encadrer cette th`se. Je tiens galement ` remercier Ryuji WAKIKAWA, dsormais e e a e Chercheur chez Toyota ITC au Japon, avec qui jai eu lhonneur de travailler sur dirents projets lis ` la mobilit comme Home Agent Migration, prsent dans cette e e a e e e th`se. Ses qualits scientiques et humaines ont tout particuli`rement contribu au tr`s e e e e e bon droulement de mon sjour au Japon. Je remercie enn Clmence MAGNIEN, e e e Charge de Recherche au CNRS, pour mavoir apport une aide tr`s prcieuse dans la e e e e rdaction et les multiples relectures de ce manuscrit. e Mon exprience japonaise, quant ` elle, naurait pas t possible sans laide de nome a ee breuses personnes dont Atau TANAKA, Professeur ` lUniversit de Newcastle en Ana e gleterre, et Kenjiro CHO, Chercheur chez Internet Initiative Japan, qui mont prsent e e dirents chercheurs japonais, et de ce fait ont activement particip aux premi`res e e e tapes de mon projet de th`se au Japon. Dans ce contexte, je tiens tout dabord ` e e a remercier Hiroshi ESAKI pour mavoir chaleureusement accueilli dans son laboratoire a ` lUniversit de Tokyo et nanc pendant les derniers mois de mon sjour. Je remercie e e e galement mes coll`gues de Murai lab, ` lUniversit de Keio, ainsi que mes coll`gues e e a e e dEsaki lab, ` lUniversit de Tokyo. Quil me soit permis de remercier sparment Seiia e e e chi YAMAMOTO pour tout le temps quil a pass ` maider lors de mon installation ` ea a Tokyo, ainsi que dans les direntes dmarches administratives prcdant mon arrive. e e e e e Jai galement rencontr de nombreuses personnes durant mes deux annes au Japon e e e qui resteront, je lesp`re, des amis malgr la distance. P`le-mle, merci ` Daphne, e e e e a Romain, Koshiro, Lou, Marin, Martin, Mai, et Yukie. Mention spciale au master du e meilleur restaurant du monde (` Yokohama) : le teppan et la bi`re sont deux lments a e ee indissociables des recherches russies ! e Finalement, je remercie Ema pour laide quelle ma apporte avant et pendant e mon sjour. Sans elle, tout aurait t beaucoup plus compliqu, voire impossible. Merci e ee e de mavoir fait dcouvrir le Japon, et permis de pratiquer le peu de japonais que je e connais ! i
Merci aux membres du bureau 720 : Laurent, Georges, Florian, et Christophe, pour leurs dlires, leur aide, et leur bonne humeur. Merci aux anciens et autres dinosaures, e Augustin, Julien, Chantal, et Matthieu, pour mavoir montr la voie de la sagesse ; parce e que cest important. Merci galement aux autres membres du labo pour les discussions e autour dun caf et les dpannages de clopes ! e e Finalement, merci ` ma famille, mes amis et mes relectrices. Merci aux hipss, bara bus, zedou et autres clubers du week-end. Merci ` celles et ceux qui ont eu la patience a et le courage de me supporter durant ces quatre annes. Merci galement ` celles et e e a ceux qui nont pas eu cette chance. Merci ` celles et ceux qui ont fait un dtour par a e Tokyo. Merci ` celles et ceux qui sont venus me chercher un mercredi matin ` 4h30 a a a ` Roissy. Merci au Limoncello et ` Radio Head. Merci ` ceux qui mont mis une red a a hat entre les mains par un beau dimanche de juin 98. Merci aux globotruncanids. e Merci aux Urgences (et surtout bienvenue). Merci ` Philibert et au Quick. Merci aux a joggings du vendredi soir. Par ordre alphabtique, sans ordre de prfrence, et sur un e ee air des Brus, merci ` toi : Alexis, Adeline, Arnaud, Boulette, Bozze, Carter, Ceache, e a Citrouille, Delphine, Emilie, Etis, Evy, Faustine, Flavie, Fred, Galipette, Gratoune, Grizz, Hl`ne, IKR, Julio, Karim, Kat, Kinou, Kozette, Lo, Manu, Marion, Mat, Mel, ee e Michel, Philippe, Pingouin, Pwetty, Renaud, Romain, Sail, Sverine, Shai, Sly, Spyou, e Thierry, troglocan, Vincent, Virginie, et Zoro. Si jamais malgr toute mon attention, e je tai oubli (ou alors si tu es mgalomane), ajoute ton nom ici : e e
Enn, merci ` tous ceux qui ont relev le d daronter la soutenance ! a e e
ii
Rsum e e
Larchitecture de lInternet est telle que, lorsquun utilisateur se dplace et change e de rseau, ladresse IP de son priphrique est modie, entra e e e e nant la perte des communications en cours. An de rsoudre ce probl`me, des protocoles de gestion de la e e mobilit ont t dnis pour rendre les communications insensibles aux mouvements et e ee e indpendantes du rseau o` se trouve lutilisateur. Cependant, la plupart des proposie e u tions sourent de probl`mes aectant leurs performances, ou bien encore leur utilisation e dans larchitecture actuelle de lInternet. Par exemple, certaines dentre elles, comme le protocole HIP, imposent que tous les priphriques, y compris ceux qui sont xes, e e implmentent le protocole de mobilit. Dautres encore, tel que le protocole Mobile e e IPv6, induisent des chemins plus longs et donc des dlais de communication plus ime portants. Ce travail de th`se vise ` amliorer les performances du protocole Mobile IPv6 e a e en contrlant les direntes limitations induites par lutilisation dun routeur grant la o e e mobilit : le home agent. Pour ce faire, nous proposons deux approches complmentaires e e qui tout en tant compatibles avec linfrastructure actuelle de lInternet, permettent e de grer la mobilit de faon transparente ` la fois pour le rseau et les priphriques e e c a e e e xes. Tout dabord, nous dcrivons une nouvelle architecture distribue de gestion de e e la mobilit appele Home Agent Migration qui permet dutiliser plusieurs home agents e e simultanment. Grce ` un dploiement rel, nous montrons quil est possible dobtenir e a a e e des performances comparables ` celles de communications nutilisant pas Mobile IPv6. a Ensuite, nous dnissons formellement les proprits des emplacements des home agents e ee en termes de thorie des graphes. En sappuyant sur cette tude, nous quantions e e limpact du protocole Mobile IPv6 sur les communications. Finalement, nous proposons un nouvel algorithme qui permet de traiter les problmatiques de dploiement de Mobile e e IPv6 et de Home Agent Migration dans des graphes qui modlisent des rseaux de e e communication.
Mots-Cls e
Mobile IPv6, gestion de la mobilit, anycast, graphe, centralit e e
iii
Abstract
Nowadays, mobile devices, such as laptops, are commonly used to access the Internet from dierent locations during the same day. With the current Internet architecture, a change of location requires a mandatory modication of the IP address, and as a result the loss of ongoing communications. Under these constraints, mobility protocols were designed to make communications resilient to movements and location independent. So far, diverse mobility protocols were dened that eciently solve mobility related issues. Unfortunately, most of them suer from design choices that impact their performances, or make them impractical for immediate deployments. For example, some protocols require that every node implements mobility support, including non-mobile ones; or causes longer paths and higher communications delays. In this thesis, we present two possible approaches to improving Mobile IPv6 performances, and to control its current shortcomings. These approaches are completely compatible with the current networking technologies, and can be used to perform immediate deployments of mobility support on the Internet. We rst propose Home Agent Migration, an additional mobility management plane, which distributes home agents (specic mobility routers) inside the Internet topology. Practical experiments show that it is possible to obtain performances almost identical to communications without Mobile IPv6. Then, we formally dene the properties of home agent locations in terms of graph theory, and quantify the impact of Mobile IPv6 on communications. Finally, based on this study, we describe a new algorithm that addresses deployment issues of Mobile IPv6 and Home Agent Migration that could be applied to any operators network.
Keywords
Mobile IPv6, mobility management, anycast, graph, betweenness centrality
Contents
Remerciements Rsum e e Abstract Contents 1 Introduction 1.1 1.2 1.3 Standard problems induced by Mobility . . . . . . . . . . . . . . . . . . What is mobility support anyway? . . . . . . . . . . . . . . . . . . . . . Approaches for Internet mobility support . . . . . . . . . . . . . . . . . 1.3.1 1.3.2 1.3.3 1.4 1.5 1.6 Locators and identiers . . . . . . . . . . . . . . . . . . . . . . . Which identiers? . . . . . . . . . . . . . . . . . . . . . . . . . . Design constraints . . . . . . . . . . . . . . . . . . . . . . . . . .
i iii v vii 1 2 4 5 5 6 7 9 11 12 13 14 14 15 18 21 22
Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Background on Mobile IPv6 2.1 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 Preliminary terminology . . . . . . . . . . . . . . . . . . . . . . . Operation of Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . Return Routability Procedure . . . . . . . . . . . . . . . . . . . . NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Home Agent Discovery . . . . . . . . . . . . . . . . . . . . . . . . vii
2.2
Protocols limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Return Routability Procedure . . . . . . . . . . . . . . . . . . . . NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23 23 24 26 26 26 27 29 30 31 32 33 35 37 38 39 41 42 43 43 43 45 46 47 47 49 49 50 51 55 56 59 60 60 62
2.3
Security overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 2.3.2 Possible attacks against Mobile IPv6 . . . . . . . . . . . . . . . . IPsec protection . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . Fast Handover for Mobile IPv6 . . . . . . . . . . . . . . . . . . . Multiple Care-of Address . . . . . . . . . . . . . . . . . . . . . .
2.4
Standardized optimizations . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 2.4.2 2.4.3
2.5
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Home Agent Migration 3.1 General overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 3.1.4 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.3 3.3.1 3.3.2 3.4 3.5 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Typical deployments . . . . . . . . . . . . . . . . . . . . . . . . . Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notion of Binding Cache . . . . . . . . . . . . . . . . . . . . . . . Communication examples . . . . . . . . . . . . . . . . . . . . . . Movements of mobile nodes . . . . . . . . . . . . . . . . . . . . . Example of a typical deployment . . . . . . . . . . . . . . . . . . The underlying protocol . . . . . . . . . . . . . . . . . . . . . . . NEMO support . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security considerations . . . . . . . . . . . . . . . . . . . . . . . . Performances comparisons . . . . . . . . . . . . . . . . . . . . . . Experimental results . . . . . . . . . . . . . . . . . . . . . . . . .
Practical implementation . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Mobile IPv6 deployments 4.1 Graph theory reminders . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 Preliminary denitions . . . . . . . . . . . . . . . . . . . . . . . . Importance of vertices . . . . . . . . . . . . . . . . . . . . . . . . viii
4.2
Networks as graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.2.3 Observing networks . . . . . . . . . . . . . . . . . . . . . . . . . Modeling networks . . . . . . . . . . . . . . . . . . . . . . . . . . Weights on edges . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on paths lengths . . . . . . . . . . . . . . . . . . . . . . . Optimal locations . . . . . . . . . . . . . . . . . . . . . . . . . . Comparison methodology . . . . . . . . . . . . . . . . . . . . . . Studied networks . . . . . . . . . . . . . . . . . . . . . . . . . . . Relationship between the degree and the betweenness . . . . . . Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Home Agent Migration . . . . . . . . . . . . . . . . . . . . . . .
63 64 65 65 66 66 68 68 70 71 72 73 78 83 85 87 93 95 95 98
4.3
Home Agents locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 4.3.3
4.4
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 4.4.2 4.4.3 4.4.4
4.5 4.6
Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Conclusion A Scapy: IPv6 and BPF extensions A.1 Contributed extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.1 Scapy6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.2 BPF extension . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Routing Header Type 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 A.2.1 In a nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 A.2.2 Advanced traceroutes . . . . . . . . . . . . . . . . . . . . . . . . 102 A.2.3 Amplication attacks . . . . . . . . . . . . . . . . . . . . . . . . 104 B Thesis French Version 107
B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 B.1.1 Protocoles de mobilit . . . . . . . . . . . . . . . . . . . . . . . . 110 e 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 Aperu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 c ix
B.3.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 B.3.3 Rsultats exprimentaux . . . . . . . . . . . . . . . . . . . . . . . 119 e e B.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 B.4 Dploiement de Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 122 e B.4.1 Emplacements des home agents . . . . . . . . . . . . . . . . . . . 122 B.4.2 Mthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 e B.4.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 B.4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 B.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 B.5.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 B.5.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Bibliography List of Figures List of Tables 131 141 143
Chapter
1
Standard problems induced by Mobility . . . . . . . . . . . . What is mobility support anyway? . . . . . . . . . . . . . . . Approaches for Internet mobility support . . . . . . . . . . . 1.3.1 1.3.2 1.3.3 Locators and identiers . . . . . . . . . . . . . . . . . . . . . Which identiers? . . . . . . . . . . . . . . . . . . . . . . . . Design constraints . . . . . . . . . . . . . . . . . . . . . . . . 2 4 5 5 6 7 9 11 12
Introduction
Contents
1.1 1.2 1.3
1.4 1.5 1.6
Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 heterogeneous wireless technologies and computing devices that can easily t in ones pocket and are powerful enough to compete with desktops. Moreover these technical evolutions also change how we interact with the technology itself. Mobile phones are indeed entirely part of our daily life. We use them not only for work but also to communicate with friends, access the Internet or play games. They are slowly modifying the way we socialize with each other [80] and how we access the information: in 2006, mobile devices in Japan represents 57%1 of all user access to the Internet. Nowadays, users can 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 been mobile 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-mode GSM/Wi-Fi handsets and Voice over IP (VoIP) services. In metropolitan areas, wireless networks are available in diverse locations such as workplaces, cafs, parks or homes. e As a consequence, the high density of Wi-Fi access points [55, 68, 67] and their wide communication ranges allow mobile devices to detect tens of access points from the same location while walking in the streets. Users can therefore take advantage of their VoIP 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. Strictly speaking, a mobile device is only connected to one access point at the same time. Traditionally, if the device goes out of the access points range, it looses its network connectivity and must connect to another access point. Previous works addressed this issue by expanding a unique network broadcast domain across several Wi-Fi access points by relying on wired or wireless [17, 61] backbones. Nevertheless, as of today, it is not possible to perform vertical handovers in order to provide seamless voice calls between dierent access technologies such as Wi-Fi and HSDPA. Such handovers would for example allow a mobile phone to automatically switch a phone call from a paying HSDPA link to a free Wi-Fi one when the user comes 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.
owned by approximately 48 million people, according to The Japanese Ministry of Internal Aairs and Communications. 2 either horizontal or vertical.
1
Chapter 1. Introduction
Technically, it currently implies a mandatory change of the nodes IP address and therefore the termination of ongoing UDP and TCP connections. They cannot be recovered, and must be restarted using the newly acquired address. If we consider phone calls, this change of address means that the call is rst stopped then restarted. As of today, handovers in Internet-like architecture are far from being easy to recover from, as they must be handled either manually by the users, or independently in every single application. This example intelligibly lays down the context of mobility support on the Internet as well as technical constraints that it must deal with. We list the main categories of such constraints below. 1. Change of IP address Due to the Internet routing and addressing architectures, a nodes IP address must correspond to its physical location at all times. Otherwise it is not able to receive and send IP packets to its correspondents. Consequently, a node cannot use the same address everywhere it goes, and must obtain a new address when it joins a new subnetwork. 2. Connection losses The most popular transport protocols (TCP and UDP) were not designed to handle changes of IP address. As a result, ongoing communications stop working after a movement. Similarly, applications need to implement mechanisms to automatically recover from connection losses. However, most applications do not have such mechanisms and, in practice, users must manually restart lost connections. 3. End-to-end communications The recent arrival of Voice over IP makes the rst move towards the come back of real end-to-end communications. Today, client/server communications prevail and close to zero application makes use of end-to-end communications. Even though some applications3 are able to establish direct communications in Network Address Traversal (NAT) environments, they cannot be considered as pure end-toend communications as a third party is necessary to punch holes into NAT [51]. In a mobility context, end-to-end communications represent an important technical challenge, as they must survive both changes of IP address and connection losses. So far, various protocols [93, 91, 83, 94, 74, 100, 20] were dened at the Internet Engineering Task Force (IETF) to provide mobility support to mobile nodes and to
3
such as Skype.
1.2. What is mobility support anyway?
solve problems such as previously described. This thesis focuses on the Mobile IPv6 protocol [66], described in Section 1.4, which aims at achieving immediate deployments of mobility services over the Internet through incremental upgrades of its current architecture. This thesis proposes solutions to improve the performance of Mobile IPv6 and solve its various limitations. It specically concentrates on the IPv6 protocol that makes up a favorable environment for mobility with the disappearance of NAT, and a at addressing space. Unless stated otherwise, this manuscript will only discuss IPv6 [41, 18], therefore terms such as IP address or IP must be interpreted as IPv6 address and IPv6.
1.2
What is mobility support anyway?
With mobile phones technologies, such as GSM [118], users keep the same phone number, a unique identier, when they move or even travel to a dierent country; they can be reached whatever their locations. Handovers are appropriately supported: voice calls are not stopped during or after movements. Using these technologies as a reference, mobility can be interpreted as the capacity to move easily and freely without impacting the ongoing communications. Accordingly from an end-user perspective, being mobile is being able to move a device around while seamlessly accessing the communication network with no modication to the device applications nor congurations. This implies that every device must be uniquely and permanently identied independently of its physical location. From the network architecture point of view, an address is required to deliver data from, 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 nodes physical location and the subnetwork it is connected to, it is called a locator. Providing mobility support on the Internet is therefore oering a permanent identier to a mobile device4 along with a temporary locator which can change over time, and dening mechanisms to store and retrieve the binding between identiers 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 network level, or target modications of end-nodes or the infrastructure. Their application time lines are also dierent: some research aim at providing near future deployments [66], while other ones require heavy changes to the current Internet architecture [49] that will not be possible until several tens of years. In the remainder of this chapter, we
4
also referred as a mobile node.
will rst provide a deeper analysis of requirements to support mobility on the Internet. Then, we will briey present our work to improve the performance of the Mobile IPv6 protocol.
1.3
Approaches for Internet mobility support
In this section, we summarize the issues and technical choices that arise while designing mobility protocols for the Internet. Our goal is to describe the common requirements of Internet mobility support and briey present typical mobility protocols as well as their design constraints.
1.3.1
Locators and identiers
As previously discussed, the primary property of a mobility protocol is to give both an identier and a locator to mobile nodes; two elements that describe a nodes identity and its physical location. However, in order to make mobility protocols complete, there must be some mechanisms to map a locator to an identier, and retrieve a locator given its corresponding identier. For example, in a phone book, peoples names are the identiers and phone numbers are the locators that change over time as people move to new residences. In order to make a phone call to a friend, a user can look up into a phone book and nd the corresponding phone number. If it changes, the user can look up into an updated phone book and nd its friends new phone number. From the network perspective, this metaphor brings several problematic questions that aect mobility protocols design. 1. What are identiers 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 pushing only 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 xed time interval; with a cache that uses a timer to make entries expire; never? On the Internet, the addressing and routing architectures strongly constrain the location of a node. An IPv6 address belonging to an IPv6 prex allocated to a French
1.3. Approaches for Internet mobility support
Names Domain names ID IP addresses
Protocols DNS HIP, SCTP MIPv6, LISP, NETLMM
Table 1.1: Identiers 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 when a node moves. This problem is linked to the dual function of the IP address. First, it implicitly provides the position of a node on the globe (the locator). Then, it uniquely identies the node in the whole Internet topology (the identier). As a consequence, mobility protocols simply rely on the Internet routing architecture to ensure the delivery of mobile nodes packets, and use IP addresses as mobile nodes locators. The dierent protocols will therefore compete in the way they provide permanent identiers and ecient mapping mechanisms.
1.3.2
Which identiers?
The elements used as identiers are deeply related to the design of mobility protocols. As listed in Table 1.1, several possibilities to supply permanent identiers are available. For example, if we consider domain names as the identier, we can dene an elementary application-based mobility protocol as follows. Every time a mobile node joins a new subnetwork, it updates its DNS Resource Record [82] with its newly acquired IPv6 address. This could be easily implemented with virtually no modication to correspondents or mobile nodes, and will work on the current Internet. However, this protocol presents drawbacks as ongoing connections are lost after handovers, and as correspondents must access the DNS server frequently to retrieve the most recent IP 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 these protocols are able to survive to a handover by automatically notifying correspondents of a change of IP address: ongoing connections can therefore be used after a movement.
5
although 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 modied so as to benet 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 identiers, such as Mobile IPv6, LISP (Locator/ID Separation Protocol) [49] or NETLMM (Network-based Localized Mobility Management) [56], correspondents nodes are not concerned by mobile nodes mobility and communicate with them using the IPv6 address as they would do with non-mobile nodes. Consequently, such protocols are fully compatible with current implementations of TCP and UDP. Applications are not aware that mobility support is being used, even on the mobile nodes side. In such protocols, mobility is either supported by mobile nodes or by the network. These protocols can however introduce longer communication delays due to non-optimal communication paths.
1.3.3
Design constraints
As previously discussed, all mobility protocols designed at the IETF take dierent approaches to provide mobility support over the Internet. While these protocols may sometime look divergent, they can however be classied and compared using the following requirements. 1. Realistic utilization In order to ease its deployment and accelerate its adoption, a mobility protocol must not require any modication on correspondents sides: they should be able to communicate with mobile nodes as if they were not mobile. Concerning an immediate usage of mobility support on the Internet, it is indeed unreasonable to assume that all nodes will be upgraded to support mobility. Moreover, it is unlikely that any mobility protocol will be implemented on the server side, such as Google or MSN, as this leads to higher operational costs without any performance benet for the service provider. 2. Small impact on the existing network architecture This is somehow similar to (1) but from a network perspective. All required changes to the network architecture should remain compatible with the current Internet technologies. Concerning immediate deployments, only incremental changes could be seriously considered for practical mobility support: it is not feasible to break the current addressing and routing architectures.
1.3. Approaches for Internet mobility support
Protocols DNS-based SCTP, HIP LISP MIPv6 MIPv6 & RRP OLSR, AODV
1 x
2 x x
x x x
x x x x
x x x 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 handovers. Moreover, mobility support must not require any modication to applications. This is impracticable, as every application would need to be upgraded. In terms of network layers, this means that the mobility protocol must either reside below transport layers, or provide its functionalities through transparent application proxies such as SOCKS [75]. 4. Similar performances A mobility protocol should not seriously impact the communications performances, nor increase the load on the network. Moreover, it should also scale to provide acceptable performances when the number of mobile nodes increases. Ultimately, the users experience should remain the same as in a non-mobile context. Giving the four design constraints, we provide an overview of dierent mobility protocols alternatives in Table 1.2. It easily highlights that the implementation choices (such as the networking layer, the locator/identier mapping, or the locator types) impact application scopes of mobility protocols. For example, the Optimized Link State Routing (OLSR) routing protocol [33], designed to support Mobile Ad-hoc Networks (MANET), must be implemented in every node that want to benet from its features. However, it allows nodes to communicate in areas where there is no communication infrastructure by automatically adapting itself to nodes movements. On the other hand, LISP eciently separates nodes identiers from routing locators while remaining
compatible with current IPv6 stacks. Nevertheless, it requires heavy changes to the current Internet Architecture. Under the previous design constraints, we concluded that the IPv6 address is the only identier 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 thesis in 2004, four implementations were already available, and the protocol was supported by major vendors of networking equipments [13, 8, 32, 79]. At the same time, people agreed that Mobile IPv6 was a good, yet awed, intermediary solution to provide mobility support over the Internet. Today, in 2008, Mobile IPv6 is pushed by Standard Development Organizations, and unlike any other mobility protocol, it is expected to soon go to market. So far we did not discuss security as a design constraint, however we rmly believe that it is a critical aspect of mobility systems. Security is important but is driven by usages scenarios and must be designed consequently. For example, concerning the integration of Mobile IPv6 in the WiMAX architecture, a simple authentication mechanism [92] modeled from Mobile IPv4 [93] and pushed by telecommunications operators is 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 be integrated into small devices such as mobile phones.
1.4
Overview of Mobile IPv6
In this section, we briey describe the Mobile IPv6 protocol, its advantages, its limitations and our solutions. It will be further described in Chapter 2. The Mobile IPv6 protocol provides a unique permanent identier (an IPv6 address) to a mobile node (MN) independently of its network of attachment. As shown in Figure 1.1, the key component of Mobile IPv6 is the home agent (HA) located in the mobile nodes home network. It is a dedicated IPv6 router that manages the home IPv6 prex, as well as the binding between the identier and the locator which, in the Mobile IPv6 terminology, are respectively referred as Home Address and Care-of Address. The Care-of Address is used by the mobile node to communicate with its home agent. Packets sent to the Home Address (that belongs the home prex) by correspondent nodes (CN) are routed to the home network and intercepted by the home agent which forwards it to the current location of the mobile node: its Care-of Address. Likewise, packets sent from the mobile node to its correspondent node must go through the home agent prior to being delivered. This deviation of packets to the home agent is called dogleg routing,
10
1.4. Overview of Mobile IPv6
CN
Foreign network
Internet Home network Optimized Path

HA
tun
nel
MN
Visited network
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 and their correspondents. The Mobile IPv6 specication only requires the protocol to be implemented in home agents and mobile nodes, moreover it is transparent to transport layers. As a consequence, it satises design constraints 1, 2 and 3 as previously specied. In addition, the base specication of Mobile IPv6 includes a route optimization scheme called the Return Routability Procedure (RRP) that solves the deviation of packets. In Figure 1.1, the resulting communication path is represented as Optimized Path. This procedure allows packets to be directly sent between a mobile node and its correspondent without involving the home agent. Since this optimization reduces the latency of the communications and improves performances, it consequently validates the fourth design constraint. However, the Return Routability Procedure requires upgrading all correspondents, it do not anymore meet the requirements of the rst design constraint. With the dogleg routing, the restricted position of the home agent is the fundamental problem that weakens Mobile IPv6 performances. Due to the addressing and routing architectures, the location of a home agent is topologically and physically restricted by its home prex. It must be in the correct physical location so that it can receive packets destined to the home prex. Therefore, the home agent has to be placed
11
where this prex is advertised on the Internet. All of the previously described design constraints cannot be satised at the same time with the current Mobile IPv6 specication. Putting the Return Routability Procedure aside, the protocol does not fulll the fourth constraints: it presents performances drawbacks.
1.5
Contributions
The primary goals of this thesis are to improve Mobile IPv6 performances, and to control its current shortcomings. Currently promoted by the Third Generation Partnership Project (3GPP) and the WiMax Forum, the Mobile IPv6 protocol is a major solution to provide mobility support while remaining compatible with current network architectures and end-nodes implementations. In order to achieve our goals, we thoroughly analyze Mobile IPv6 limitations and then propose optimizations that satisfy the design constraints described in Section 1.3.2. To do so, we use both practical and theoretical approaches. Our main contributions are listed below. 1. Home Agent Migration We propose a new mobility architecture, called Home Agent Migration, that uses the traditional Mobile IPv6 protocol with an additional mobility management plane. In this new plane, home agents are distributed all over the Internet and are exchanging information about mobile nodes that they can reach. This deployment is performed with the help of anycast routing [69] in which each home agent advertise the same home IPv6 prex. Consequently, a mobile node will exchange trac 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 operators networks as undirected graphs and dene the properties of the good home agents locations in terms of graph theory. We then quantify the impact of the dogleg routing on communications performances. In particular, we use notions of centrality in graphs to quantify increases of communication distances 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 address deployments issues of Mobile IPv6 that could be applied to any operators network. We propose an algorithm that indicates good home agents locations given
12
1.6. Outline a specic network topology. We evaluate this approach using real-world network topologies and show that the obtained Mobile IPv6 performances could be close to direct paths ones. The proposed algorithm is generic and can be used to achieve Mobile IPv6 as well as Home Agent Migration deployments. 4. NEMO enhancements We provide detailed descriptions of possible usages of Home Agent Migration along with Network Mobility (NEMO) [43]. This protocol based on Mobile IPv6 delivers mobility service to whole networks, such as sensors deployed in a car, and to 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 collaboration with Arnaud Ebalard7 [109, 108]. Their primary goal was to emulate Mobile IPv6 node from the userland using the Python programming language [11]. These emulated nodes were used to conduct experiments in environments where its was not possible to set up real mobile nodes. These extensions are not only used by the research community but also by companies that mostly use them to test their IPv6 implementations.
1.6
Outline
Chapter 2 provides a detailed description of the Mobile IPv6 protocol and its limitations, as well as an overview of standardized optimizations. Chapter 3 describes the Home Agent Migration architecture from a synthetic to an implementation perspective, and nally provides an evaluation based on a real deployment. Chapter 4 presents an analysis of Mobile IPv6 and Home Agent Migration in terms of graph theory, and gives details about a methodology that eciently choose relevant home agents locations in given 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 discovered while developing these extensions. Appendix B summarizes this thesis in French.
6 7
tool written in Python that simplies the injection and the reception of frames and packets. from EADS Innovation Works.
Chapter
2
Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 Preliminary terminology . . . . . . . . . . . . . . . . . . . . . Operation of Mobile IPv6 . . . . . . . . . . . . . . . . . . . . Return Routability Procedure . . . . . . . . . . . . . . . . . . NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 14 15 18 21 22 23 23 24 26 26 26 27 29 30 31 32 33
Background on Mobile IPv6

Contents
2.1
Home Agent Discovery . . . . . . . . . . . . . . . . . . . . . .
2.2
Protocols limitations . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Return Routability Procedure . . . . . . . . . . . . . . . . . . NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
Security overview . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 2.3.2 Possible attacks against Mobile IPv6 . . . . . . . . . . . . . . IPsec protection . . . . . . . . . . . . . . . . . . . . . . . . .
2.4
Standardized optimizations . . . . . . . . . . . . . . . . . . . 2.4.1 2.4.2 2.4.3 Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . . . . . . Fast Handover for Mobile IPv6 . . . . . . . . . . . . . . . . . Multiple Care-of Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5
Conclusion
14
2.1. Mobile IPv6
2.1
Mobile IPv6
In this section, we give a detailed overview of Mobile IPv6. Then we discuss issues raised by this protocol and its route optimization procedure. The aim of this section is to describe problems that this thesis is addressing while considering immediate deployments of mobility support in the Internet, and to highlight our contributions concerning the distribution of home agents and their locations.
2.1.1
Preliminary terminology
Here, we present the terminology that we will use throughout this thesis, visually sustained by Figure 2.1 that locates terms in an example network topology. Prexes, addresses, and abstract elements 1. Home prex: an IPv6 prex managed by the home agent that corresponds to the mobile node Home Address. 2. Home Address (HoA): a xed IPv6 address that belongs to the home prex of the mobile node; it is the identier. 3. Care-of Address (CoA): it is an IPv6 address that belongs to the network where the mobile node is physically located. The CoA changes as the mobile node moves; it is the locator. 4. Home Link: the physical link on which the home prex is advertised using IPv6s auto-conguration mechanisms [105]. 5. Binding Cache: a database (similar to a routing table) that contains the mappings between Home Addresses and Care-of Addresses. 6. Mobility Header: a new type of network header that is used to carry Mobile IPv6 related signaling packets. It is transported directly over IPv6.
Nodes 1. Home agent (HA): a specic router located in the home network. It delegates a Home Address from the home prex to a mobile node, and forwards the associated data trac to the mobile node.
Chapter 2. Background on Mobile IPv6
15
CN
Foreign network
HA
Internet Home Link

MN
Home Network
Visited network
Figure 2.1: Mobile IPv6 terminology
2. Mobile node (MN): a node that keeps its Home Address after changing its network of attachment. It implements Mobile IPv6. 3. Correspondent node (CN): a node that communicates with a mobile node. It may implement Mobile IPv6 if it supports the Return Routability Procedure. Networks 1. Home network: network where the home agent is located. The home prex and 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 Address belongs to the IPv6 prex of this network.
2.1.2
Operation of Mobile IPv6
On the Internet, the location of a node is strongly constrained by the routing architecture. An IPv6 address that belongs to an IPv6 prex allocated to a French Internet Service Provider cannot be used to receive packets in Japan. Consequently, the current Internet architecture makes it impossible to keep the same address when a nodes move.
16
2.1. Mobile IPv6

2001:db8:dead::/64 Foreign network
CN
Internet Home network
HA
2001:db8:d0d0::/64
tun nel
MN
Visited network
2001:db8:cafe:deca::/64
Figure 2.2: Mobile IPv6: communication example
This problem is linked to the dual function of the IP address. First, it implicitly provides the position of a node on the globe; this role is called locator. Then, it uniquely identies the node in the whole Internet topology; this second role is called identier. The Mobile IPv6 protocol provides a solution to separate these two functions. A mobile node implementing Mobile IPv6 uses two dierent IP addresses: its Home Address (HoA), which plays the role of the identier, and its Care-of Address (CoA) the locator. In order to bind the Home Address to the Care-of Address, Mobile IPv6 relies on the home agent, a specic router located in the home network. Its goals are to delegate a Home Address from the home network to each mobile node, and to forward the mobile nodes data trac. At any given time, the mobile node always communicates 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 prex is 2001:db8:d0d0::/64, the HoA is 2001:db8:d0d0::42, and the CoA is 2001:db8:cafe:deca:217:f2:fec7:881a1 .
1
auto-congured with the prex advertised by the Access Router (AR).

MN Access router (AR) HA CN
17
1. Movement detection
Router S
olicitation
ent
Router A
dvertisem
Binding Update
2. Association
Binding Acknowled gment
ICMPv6 Echo Re
quest
ICMPv6 Echo
Request
3. Sending data
ho Reply ICMPv6 Ec
ICMPv6 Echo Reply
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 node detected that it moves until the communication with its correspondent. The movement detection relies on the standard IPv6 auto-conguration mechanism described in RFC 4862 [105]; it is not specic to Mobile IPv6. 1. when the mobile node moves to a new network, it rst congures a new Care-of Address (2001:db8:cafe:deca:217:f2:fec7:881a) using the prex announced by the Access Router (AR; 2001:db8:cafe:deca::/64), and its network interfaces MAC address 00:17:f2:c7:88:1a. 2. it registers its binding information with its home agent by sending a message called a Binding Update containing its Home Address (2001:db8:d0d0::42) and its new Care-of Address (2001:db8:cafe:deca:217:f2:fec7:881a) to its home agent. After the reception of this packet, the home agent sets up an IPv6-in-IPv6 tunnel with the mobile node. It also lls up its Binding Cache with a mapping that
18
2001:db8:dead::/64 Foreign network
2.1. Mobile IPv6
CN
Internet
Home network
Optimized Path
HA
2001:db8:d0d0::/64
MN
Visited network
2001:db8:cafe:deca::/64
Figure 2.4: Return Routability Procedure: communication example
associates the HoA to the CoA. Finally, it sends back a Binding Acknowledgment message 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 correspondent (2001:db8:dead::beef), this message is sent to the home agent using the tunnel, decapsulated by the home agent, and nally forwarded to the correspondent. As previously shown in Figure 2.2, all of the communications between a mobile node and a correspondent node must go through the home agent.
2.1.3
Return Routability Procedure
The base specication of Mobile IPv6 includes a route optimization scheme called the Return Routability Procedure. It allows the mobile node to send a Binding Update message to its correspondent nodes that also implement Mobile IPv6. After the completion of this procedure, the packets are directly routed between the mobile node and its correspondent nodes along the optimized path2 , as shown in Figure 2.4.
2 in practice, the optimized path is the direct path between the visited network and the foreign network.
19
MN
HA
CN
HoTi
1. HoA test
HoTi
HoT
HoT
2. CoA test
CoTi
CoT
3. Association
Binding Update
Binding Acknowledgment
4. Sending data
ICMPv6 Echo Request
ICMPv6 Echo Reply
IPv6-in-IPv6 tunnel
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 agent
as it is aware of the mobile nodes Care-of Address. However, unlike on the home agent, no preliminary information is available on the correspondent node to authenticate the mobile node. The mobile node must therefore prove that it is the real owner of the Care-of Address and the Home Address that it wants to use. It does so by proving that it 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 correspondent until they can send packets over the direct path. The movement detection is not represented in the Figure. Note that this entire procedure must be repeated after each movement. 1. the rst exchange of HoTi (Home Test init) and HoT (Home Test) messages is used to ensure that the mobile node is able to emit and receive packets using its Home Address. These messages are exchanged through the tunnel established with the home agent. 2. likewise, the exchange of CoTi (Care-of Test init) and CoT (Care-of Test) messages checks that the mobile node is able to emit and receive packets using its Care-of Address. These messages are exchanged directly between the mobile node and its correspondent. 3. after the reception of the HoTi and CoTi messages, the mobile node sends a Binding Update message to its correspondent to register the binding between its Care-of Address and its Home Address. The correspondent also lls up its Binding Cache. 4. packets exchanged between the mobile node and its correspondent use the optimized path and are not deviated to the home agent. Packets are sent using the Routing Header Type 2 and the Home Address Option extensions to make sure that the IPv6 addresses contained in the IPv6 headers are topologically correct. Otherwise, if the Home Address was directly used in the IPv6 header, packets could be discarded by the mobile nodes and the correspondent nodes access routers. In practice, the four messages (HoTi/HoT and CoTi/CoT) exchanged during the Return Routability Procedure are used to generate a cryptographic key that is employed
21
Foreign network CN
Home network
HA1
Tunnel
MR1
Figure 2.6: NEMO by the mobile node to cryptographically sign the Binding Update message. Upon reception of the HoTi and CoTi messages, the correspondent knows that the mobile node can emit packets from its two addresses (HoA and CoA). It then sends back two tokens to the mobile node into the HoT and CoT messages. These two tokens are hashed together to generate the key used to sign the Binding Update message sent by the mobile node to the correspondent node. Possible attacks against Mobile IPv6 and the Return Routability Procedure are later discussed in Section 2.3.1.
2.1.4
NEMO
Dened at the IETF in RFC 3963 [43], NEMO (NEtwork MObility) is an extension to Mobile IPv6 that allows a whole network to move and change its point of attachment to 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 the eect of mobility to the nodes connected to its ingress3 interface as shown in Figure 2.6. The main concept of NEMO is to provide a mobility service to IPv6 nodes that do not implement Mobile IPv6, using an IPv6 prex delegated from the home network. A typical usage scenario for this protocol is public transportation systems such as trains where end-nodes are connected to the Mobile Router using 802.11b. Like a Mobile Node, the Mobile Router has a permanent Home Address that remains the same wherever it moves. In addition, it also manages a Mobile Network Prex (MNP) delegated from the home network. This is the IPv6 prex used by end-nodes connected to its ingress interface. In NEMO, the home agent is slightly modied so as to delegate Home Addresses as well as Mobile Network Prexes, and to process
3
internal.
22
node A Foreign network
2.1. Mobile IPv6
CN Home network 1
HA1 HA2
tunnel 1
MR1 tunnel 2
MR2 node B
Home network 2
parent-NEMO sub-NEMO
Figure 2.7: Nested NEMO dedicated Binding Update messages. It does not only intercept packets destined to the Home Address of mobile routers but also intercepts data packets sent to nodes belonging to the Mobile Network Prex. As dened 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 and HA1, and HA1 and HA2 are not represented. We consider that Binding Update messages were respectively sent and received by the mobile routers and their corresponding home agents. When node A in the parent-NEMO sends packets to node B located in the 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 correct destination owing to the routing architecture. When packets reach this network, they are intercepted by HA2, immediately forwarded to MR2 via tunnel 2, and delivered to node B. This is a typical use of NEMO that presents some performance issues that will be described in the following Section. This scenario is likely to happen when a passenger brings its mobile router, MR2, into a train, and use it to provide Internet access 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 of the home agent serving its home prex. The Mobile IPv6 RFC denes a new Dynamic Home Agent Address Discovery (DHAAD) ICMPv6 message that could be used by a
23
mobile node to discover all home agents congured on the home link. On the home link, home agents periodically advert their home prex using Router Advertisement (RA) messages. Using these messages, a home agent can maintain a list of home agents that serve the same home prex. In practice, the DHAAD message is sent to a specic anycast address [65] that is constructed using the home prex4 . This message is routed and delivered to only one home agent that sends back a DHAAD reply message containing a list of home agents managing the home prex. DHAAD allows several home agents to serve dierent set of mobile nodes with the same home prex. However, if the home agent serving a mobile node crashes, on-going communications are stopped and the mobile node must rebind to another home agent. The Mobile IPv6 RFC does not dene any mechanism that provides transparent home agent redundancy in case of system failures.
2.2
2.2.1
Protocols limitations
Mobile IPv6
Mobile IPv6 has some fundamentals problems related to the use of the home agent to perform the bindings between Home Addresses and Care-of Addresses. They especially weaken the protocol performance as well as its scalability. We describe these problems below. 1. Dogleg routing In Mobile IPv6, a mobile node is only associated with a single home agent. All packets are rst routed to the home agent and then forwarded to the destination in an IPv6-in-IPv6 tunnel. Consequently, packets take a non-optimal path because all of the trac must transit through the home network. This problem is known as dogleg routing and is responsible for increasing communications delays when a mobile node communicates with its correspondent node. 2. Restricted position The location of a home agent is topologically and physically restricted by its home prex. It must be in the correct location so that it can receive packets destined to the home prex; as a result, it must be placed where this prex is advertised on the Internet. This strong location requirement is particularly problematic. Moreover,
4
the anycast address associated to the prex 2001:db8:d0d0::/64 is 2001:db8:d0d0::fd:::fe.
24
2.2. Protocols limitations when the home network becomes unreachable, mobile nodes also become isolated and 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 foreign network, it can not reply to Neighbor Discovery5 messages sent from the home networks access router. In order to intercept mobile nodes packets, the home agent is therefore in charge of replying to these messages on behalf of mobile nodes away from the home network; in practice, they act as Neighbor Discovery proxies (Proxy NDP) [87]. This leads to a serious scalability issue, as the number of Neighbor Discovery packets sent by the home agent is proportional to the number of mobile nodes it serves. Additionally, the total bandwidth required by mobile nodes data trac of mobile nodes might be bigger than the total home link bandwidth. Therefore, deploying Mobile IPv6 could be an operational challenge to maintain the balance between the mobile nodes total bandwidth and the home links stability.
2.2.2
Return Routability Procedure
The route optimization scheme described in the base specication of Mobile IPv6 has the issues listed below. 1. Privacy Since the mobile node reveals its Care-of Address to its correspondent node by sending Binding Update messages, the real location of the mobile node is disclosed to other nodes on the network. This is a severe problem as it can ease industrial spying, and threaten location privacy. In addition, when route optimization is performed the mobile nodes data trac is not protected by IPsec, which leaves the communications vulnerable to eavesdropping on the visited network. 2. Modications of end-nodes In order to perform the route optimization, every end-node must support the Return Routability Procedure. However, it is unrealistic to expect that all IPv6 nodes will support route optimization, as it means upgrading existing nodes. Therefore, these legacy IPv6 nodes will not be able to benet from this procedure and all of the data trac will be destined to the home network.
5
it replaces the Address Resolution Protocol (ARP) in IPv6.
Chapter 2. Background on Mobile IPv6 3. Complexity
25
As previously described, prior to sending a Binding Update message to a correspondent node, the mobile node must exchange four messages to generate a key that will be used to authenticate the binding. This binding procedure is used with each correspondent node every time the mobile node moves. In the worst case, this whole message exchange is repeated after each movement. Depending on implementation choices, the HoTi/HoT exchange is only necessary once per correspondent. The overhead of this procedure is therefore high and implies longer handovers. If the Return Routability Procedure cannot be performed after a mobile nodes movement, due to strict rewall policies or packet losses, the mobile node cannot exchange any data with its correspondent nodes until the Binding Caches entry expires. 4. Server overload We must consider that a server communicating with thousands of users may be acting as a correspondent node. In this case, the Return Routability Procedure dangerously increases the amount of work the server performs to serve queries. The deployment of Mobile IPv6 using the Return Routability Procedure causes its operational cost to also be supported by entities other than the one in charge of the home network. Unlike non Mobile IPv6 based communications, more packets are exchanged and more powerful hardware is required to handle the same amount of 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 down the adoption of this route optimization scheme, as it does not bring direct benet for the companies managing servers. 5. Filtering This is more a side eect that a direct issue of the Routing Routability Procedure, however it can seriously aect its eective usages. Nowadays, networks administrators tend to drastically lter both their egress and ingress trac, and restrict packets types to the strict minimum (i.e. not Mobile IPv6). This new trend of ltering could for example forbid correspondent nodes to establish an optimized path with the mobile node. This ltering issue is especially serious since January 2007 and the disclosure of a critical bug aecting the handling of Routing Header extensions on Cisco routers [3]: some routers are now discarding every packets containing Routing Headers, and as a side eect messages related to Mobile IPv6 and 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 previous Mobile IPv6 issues, this protocol also suers from the nested mobile network scenario described in Section 2.1.4. This is an important problem as all of the packets exchanged between correspondents and nodes behind the mobile router must go through the tunnel. When mobile routers are not managed by the same home agent, the communications path and delay are altered by the mandatory derivation to dierent home agents HA1 and HA2. Moreover, the bandwidth usage uselessly increases with the number of nested networks, wasting network resources and increasing the probability of the tunnel congestion. The impact of this problem is even more serious when the home agents are far away, for example if HA1 is located in Tokyo and HA2 located in Paris. In addition to this rst issue, if the egress6 network interface of MR1 fails, node A can no longer send packets to node B. In other words, the egress network interface of the root mobile router, here MR1, limits communications from all sub-NEMO in terms of bandwidth and stability. So far, the NEMO working group at the IETF did not come up with a solution to these issues. The only consensus is that the Routing Routability Procedure as dened 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 the Internet architecture. This section rst describes the possible attacks that could target Mobile IPv6 if communications are not protected. Then, it discusses security protections that were designed at the IETF.
2.3.1
Possible attacks against Mobile IPv6
Binding Update spoong The communications between a mobile node and its home agent are interesting targets for an attacker. By default, Binding Update messages are not authenticated. The attacker only needs to know the Home Address of the target in order to inject fake Binding Update messages. As a result, the attacker can do whatever she wants to perturb the mobile node such as retrieving its trac, forbidding it to communicate, or redirecting the trac to a target to perform a Denial of Service attack. For this reason, real life deployments of Mobile IPv6 outside closed networks cannot be done
6
external.
27
without at least authenticating signaling messages, such as Binding Update messages, and protecting them against replay. Trac 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 packets into the tunnel and pretend to send trac from the Home Address. Similar to the signaling messages, packets sent in the tunnel should be authenticated and protected against replay. Return Routability Procedure From its conception, the Return Routability Procedure was developed to limit Denial of Service attacks against the network infrastructure and the correspondents nodes [22]. No amplication attack is possible as one message sent by the mobile node corresponds to one reply sent by the correspondent node. If an attacker want to send a fake Binding Update message to a correspondent node, it must know the two authentication cookies sent in the Home Test and Care-of Test messages. In other words, it must be able to eavesdrop trac on the home network as well as on the visited link, which is not an easy task. Note that the Return Routability Procedure does not provide any protection against an attacker based on the visited network: the threat is, in this case, independent of Mobile IPv6, and equivalent to an attacker eavesdropping trac on a non-protected Wi-Fi hotspot.
2.3.2
IPsec
IPsec protection
IPsec [73] is a set of protocols (namely AH7 , ESP8 , and IKE9 ) and algorithms designed to secure IP based communications. As IPsec operates at layer 3, it is a convenient solution to transparently secure end-user applications, and to provide security services to upper layer protocols. IPsec has two modes of operation: tunnel mode (IP-in-IP tunnels are protected) and transport mode (end-to-end communications are protected). The ESP header [72] provides encryption and protection against eavesdropping. The AH header [71] provides authentication, replay protection, and integrity verication.
7 8
Authentication Header. Encryption Security Payload. 9 Internet 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 rules on IP addresses, or protocol types that dene which packets must be processed by IPsec. On the other hand, Security Associations (SA) are sets of algorithms and parameters (such as the operation mode, or cryptographic key) that dene how to protect packets selected by a Security Policy. Both Security Policy and Security Association designate simplex communications, as a consequence two of each are required to secure a bi-directional communication. Security Policies are manually congured by administrators or users, while Security Associations can be congured either manually or dynamically using the IKE protocol [57, 70]: this is referred as dynamic keying by the IPsec 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 protected with AH and ESP as dened in RFC 3776 [19] and 4877 [42]. No IPsec protection is natively available for the Return Routability Procedure has there is no prior knowledge of the correspondent node that could be used to perform mutual authentication. However, some work is being done to standardize the IPsec protection of communication between a mobile node and its correspondent node when this mutual authentication is possible [47]. Nowadays, it is quite simple to use Mobile IPv6 and IPsec conjointly, however it required some important adjustments to the standard IPsec framework in order to adapt it to mobility. For example, when the mobile node changes its Care-of Address the end points of Security Policies and Security Associations must be updated accordingly upon the reception of a Binding Update or a Binding Acknowledgment message [97]. Likewise, the IKE protocol was extended to support mobility more eciently, and to make it more reliable in case of handovers [46]. As of today, the most advanced Mobile IPv6 implementations are available for BSD and Linux kernels, named respectively SHISA [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 considered by telecommunications operators as being too complicated to be embedded into mobile devices. Moreover, they consider that IPsec is not mandatory in their core networks if ecient packets ltering is performed internally. As a consequence, an alternate mechanism to secure signaling messages was dened [92] based on Mobile IPv4. It relies on
10
Binding Update and Binding Acknowledgment messages.
29
Internet
CN HA CN
Internet
HA
BU
MAP1 MAP2 MAP1 MAP2
BU
MN MN
BU
MN
(a) Before the handover
(b) After the handover
Figure 2.8: Hierarchical Mobile IPv6 an authentication and a replay protection options that are carried by Binding Update messages. 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 disclosed, this protection is consequently sucient 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 dened at the IETF to solve some of Mobile IPv6 limitations. Their main goals are to reduce the number of signaling packets sent from the mobile node to the home agent. Hierarchical Mobile IPv6 (HMIPv6) makes mobility within an operators network transparent to correspondent nodes through a pyramidal hierarchy of home agents. On the other hand, Fast Handovers for Mobile IPv6 (FMIPv6) and the multiple Care-of Address (mCoA) extension proposes two dierent approaches to reduce packets losses during handovers.
30
2.4. Standardized optimizations
2.4.1
Hierarchical Mobile IPv6
The Hierarchical Mobile IPv6 (HMIPv6) RFC [100] was specically designed to enhance the mobility of mobile nodes within a site11 by pushing home agents closer to mobile nodes. It relies on new equipments called Mobility Anchor Points (MAP) that behave like home agents. As shown in Figure 2.8(a), they are distributed in the network to minimize the eects of the dogleg routing through a hierarchical organization of the home agent and Mobility Anchor Points. Thanks to this hierarchy, HMIPv6 provides a scalable mobility support to Mobile IPv6: the number of signaling messages outside the local network is limited. Moreover, if one MAP fails, only a small fraction of the mobile nodes will be impacted. Mobility Anchor Points are used to reduce the number of Binding Update messages sent to perform local handovers: if a mobile node moves under the hierarchy, Binding Update messages are not send over the Internet. Moreover, the hierarchy also reduces the 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 Careof Address (RCoA) constructed using information periodically sent by Mobility Anchor Points. In Figure 2.8(a), the RCoA is an IPv6 address that belongs to the IPv6 prex managed by the MAP as a consequence packets sent to the RCoA will be routed to the MAP. Along with its Home Address, the mobile node will use these addresses when sending Binding Update messages. 1. Binding Update to the MAP: the mobile node rst sends a Binding Update containing the CoA and the RCoA in order to bind the RCoA to its current location. This could be seen as a rst level of HMIPv6 hierarchy. Such messages are 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 another Binding Update containing the RCoA and the HoA. These messages are sent when the mobile node is associated with a new MAP: both its CoA and RCoA change. Upon a movement from the subnetwork 1 to the subnetwork 2, the mobile node will acquire a new CoA, but the RCoA will remain the same. As a consequence, the mobile node only needs to send a Binding Update message to the MAP to announce
11 12
also referred as local mobility. called Local CoA (LCoA) in the HMIPv6 terminology.
31
MN
PAR
HA
MN
PAR
HA
ne
Previous Visited Network

CN
Previous Visited Net.
NAR
New Visited Network
Internet
MN
Tu n
CN
New Visited Network
NAR
Internet
(a) Before the handover
(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, the MAP will forward the entire mobile node trac to its CoA. Concerning the home agent, this movement is completely transparent. If the mobile node moves to a subnetwork managed by another MAP, it will acquire a new RCoA. As a consequence, it will need to 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] denes a set of extensions designed to minimize packets losses, and reduce handovers latency when a mobile node moves from one visited network to another. The key idea is to enhance Mobile IPv6 with mechanisms that can anticipate handovers by pushing some of the home agent functionalities into access routers, and by suppressing delays inherent to Neighbor Discovery and binding registration. In Figure 2.9(a), the mobile node exchanges packets with its correspondent using the tunnel established between its Care-of Address and its home agent, like it would with Mobile IPv6. As shown in Figure 2.9(b), FMIPv6 allows the mobile node to continue receiving packets delivered to the Previous Care-of Address (PCoA) immediately after it joined the new visited network by establishing a tunnel between the Previous Access Router (PAR) and the New Care-of Address (NCoA). This tunnel will be removed as soon as the mobile node sends a Binding Update containing the NCoA to its home agent. In practice, the handover latency is reduced using the following independent steps.
32
2.4. Standardized optimizations 1. Acquire surrounding IPv6 prexes: each access router is aware of the different IPv6 prexes served by the other access routers. A FMIPv6 mobile node can perform a Wi-Fi scanning to discover the BSSID13 of the surrounding access routers. Using this list, the mobile node can query its access router and retrieve IPv6 prexes associated to these BSSID. 2. Decrease Neighbor Discovery delays: using the resulting list, the mobile node can construct its New Care-of Address and request the NAR to reserve the NCoA on its physical link. By doing so, the mobile node ensure that no other node will use the same IPv6 address, and will be able to use it as soon as it joins the 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 trac sent to the PCoA. Note that the mobile node cannot use its NCoA until it sends a Binding Update message to its home agent, or correspondents nodes. 4. Communication between the PAR and the NAR: PAR and NAR exchange messages to conrm that a mobile node will move to the new visited network and to indicate whether the NCoA is available or not. Using these mechanisms, a mobile node is able to send and receive packets as soon
as it is physically associated to a new network and before it sends a Binding Update message to its home agent. Upon reception, the home agent will congure a tunnel with the NCoA, and forward packets to the real location of the mobile node. The communication 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 its Home address at the same time. As a consequence, a device with dierent accesses to the Internet cannot use them simultaneously to communicate with its correspondents. Likewise, it cannot easily anticipate its handovers and for example decide to simultaneously use a second interface before the rst one goes down. The Multiple Care-of Address (mCoA) Internet Draft [113] denes mechanisms that allow a mobile node with
13
Basic Service Set IDentier; unique identier of a Wi-Fi access point; similar to a MAC address.
33
Wi-Fi network Tunnel 1 Home network CoA1 MN Tunnel 2 CoA2 Internet EDGE network
HA
HoA
Figure 2.10: Multiple Care-of Address
multiple network interfaces to associate all of the corresponding Care-of Addresses to its Home Address. In practice, it denes a new Binding Update option that can carry several Care-of Addresses in one message. Similarly, mCoA allows a NEMO mobile router to use dierent Care-of Address with the same Mobile Network Prex. This new extension brings an ecient handover mechanism model to Mobile IPv6 that does not require any specic equipment like in FMIPv6. As it is only implemented in the home agent and the mobile nodes, it has no impact on the network architecture. Moreover, mCoA makes it possible to dene per ow policies on the home agent. For example, in Figure 2.10, the mobile node could use its Wi-Fi link (with Tunnel 1) for VoIP 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 mobile node only using its Home Address. Along with the possibility to associate dierent Care-of Address with one Home Address, the mCoA extension permits to perform load balancing between the network interfaces, and to drastically minimize packets losses during handovers if they are predicted correctly.
2.5
Conclusion
In this chapter, we thoroughly presented the Mobile IPv6 protocol, and provided details about the mechanisms used to assign a permanent IPv6 address to mobile nodes. Due to its design relying on the home agent, Mobile IPv6 is completely transparent to the current Internet architecture and to transport protocols such as TCP or UDP. Consequently, it is a pertinent solution to achieve immediate deployments of mobility services 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 induced by the home agent and its restricted position. The dogleg routing is indeed especially serious as it makes the handovers latency increase with the distance between a mobile node and a home agent. In other words, performances of Mobile IPv6 are constrained by the home agents location. Several solutions were already designed to minimize the impact of the home agents locations on handover latencies, and communications performances. For example, FMIPv6 pushes some of Mobile IPv6 functionalities into access routers to permit mobile nodes to communicate immediately after a handover prior to rebinding to the home agent. Similarly, mCoA describes another approach that allows mobile nodes with multiple network interfaces to anticipate handovers by binding dierent Care-of Addresses to the same Home Address. On the other hand, HMIPv6 proposes to locate home agents closer to mobile nodes using a dedicated hierarchy of home agents that minimize the impact of mobile nodes locations, and movements, on the communication performances. In the following chapters, we will present two dierent solutions to address limitations caused by home agents locations. The rst one, called Home Agent Migration, takes a practical approach and describes a new architecture that distributes home agents in network topologies using anycast routing. Unlike HMIPv6, it can be used to achieve deployments within a single network, or over the whole Internet. The second solution takes a more formal approach to describe the dogleg routing in terms of graph theory, and identify which locations within a network are suitable to achieve ecient home agents deployments.
Chapter
3
General overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 3.1.4 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . Typical deployments . . . . . . . . . . . . . . . . . . . . . . . Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 38 39 41 42 43 43 43 45 46 47 47 49 49 50 51 55 56
Home Agent Migration

Contents
3.1
3.2
Practical implementation . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 Notion of Binding Cache . . . . . . . . . . . . . . . . . . . . . Communication examples . . . . . . . . . . . . . . . . . . . . Movements of mobile nodes . . . . . . . . . . . . . . . . . . . Example of a typical deployment . . . . . . . . . . . . . . . . The underlying protocol . . . . . . . . . . . . . . . . . . . . . NEMO support . . . . . . . . . . . . . . . . . . . . . . . . . . Security considerations . . . . . . . . . . . . . . . . . . . . . .
3.3
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 3.3.2 Performances comparisons . . . . . . . . . . . . . . . . . . . . Experimental results . . . . . . . . . . . . . . . . . . . . . . .
3.4 3.5
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 longer paths. Here, we show that Internet-Scale Mobility deployments are possible using the traditional Mobile IPv6 protocol with an additional mobility management plane called Home Agent Migration. In this new plane, home agents are distributed all over the current Internet topology to reduce communication distances between mobile and correspondent nodes. This deployment is performed with the help of anycast routing in which every home agent advertises the same IPv6 network prex from dierent locations; moreover they also exchange information about their associations with mobile nodes contained in the Binding Cache. Consequently, a mobile node will transparently exchange its trac with its topologically closest home agent, reducing communication delays. Similarly, when a correspondent node needs to exchange packets with a mobile node, the data trac will be intercepted by its closest home agent and redirected to the home agent to which the mobile node is bound. We also introduce the concept of a Global Mobility eXchange (GMX), a dedicated overlay network that eciently handles data trac from and to mobile nodes, and that operates home agents, as would an Internet eXchange Point (IXP). This research was successfully deployed in a real BGP Autonomous System during Winter 2006. Unlike other works that focus on end-to-end transport protocols or new routing architecture to provide mobility, our aim is to provide an Internet-Scale Mobility system that does not modify the existing architecture of the Internet. Our proposal is especially interesting compared to other solutions as its deployments can be performed with realistic operational and nancial costs. In fact, if a mobility system is based on end-to-end communications like HIP [83], all of the nodes mobile or not must be modied to benet from the system (rst design constraint in Section 1.3.3). Thus, during the deployment phase of this mobility system it is unlikely that many nodes will really benet from it. Likewise, modications of the routing plane to support mobility introduce important nancial issues as core routers must be upgraded or replaced (second design constraint). This will probably slow down the deployment of such technologies. On the other hand, Home Agent Migration satises with the four design requirements described in the Introduction: it maintains compliance with endnodes regardless of whether they implement Mobile IPv6 or not, and only requires small changes on regular home agents. Since no modication is made to end-nodes our work can be seamlessly embedded in a network, easing the deployment of an Internet-Scale Mobility system. The rest of this chapter is organized as follows: we rst 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 details about this proposal, and describe possible deployments. In Section 3.3, we present operational results from experiments performed in a real network. Finally, prior to the conclusion, we discuss related work in Section 3.4.
3.1
General overview
The underlying concept of the Home Agent Migration system is to disengage home agents from the home link so as to distribute them in the Internet topology. The aim of this new kind of home agent deployment is to provide an ecient route optimization scheme that (1) reduces communication latency, (2) is compatible with current specication and implementation of Mobile IPv6s mobile nodes, and (3) is transparent for correspondent nodes.
node C
HA 2
node B Wi-FI subnet
HA 1
ADSL subnet
ISP network
HA 3
WiMAX subnet node A
Figure 3.1: Home Agent Migration and dierent access technologies
The main scenario assumed while developing this solution is a mobile node roaming on a continent or country scale, i.e. from Tokyo to Paris. For example, home agents could be globally distributed in every big city around the world in order to be closer to most of mobile nodes and to provide seamless access to this architecture. While this scenario mainly concerns worldwide operators, our solution also applies to smaller-scale deployments. In particular, the Home Agent Migration is also useful to Internet Service Providers (ISP) delivering IP connectivity with several network access technologies such as 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 their access technology. As a consequence, they can keep the same IPv6 address when they switch from one access technology to another with a little communication overhead.
3.1.1
How it works
MN
CN
HA 1
HA 2
Internet
Figure 3.2: Concept of Home Agent Migration In the proposed architecture, multiple home agents advertising the same IPv6 prex are 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 redundancy issues. Nowadays, it is mainly used to operate root DNS servers [34]. Home agents can use any routing protocols such as BGP4+ [23], OSPFv3 [35], or RIPng [77] depending on the scale of the system. Home agents are interconnected to form an overlay network that allows them to exchange mobile nodes data trac as well as signaling packets. These interconnections can be created directly over the Internet or over dedicated highspeed backbones. Figure 3.3 compares the network architectures of Mobile IPv6 and the proposed system. Due to the distribution of home agents in the Internet topology, a mobile node will always use the nearest home agent as if the home agent had migrated close to the mobile nodes location. This closest home agent is referred to as the primary home agent (P-HA in Figure 3.3(b)), since it receives the rst Binding Update message sent by the mobile node. Similarly, packets sent by a correspondent node are routed to their closest home agent using generic IP routing mechanisms and are then forwarded to the primary home agent over the fast backbone.
39
Internet a)
HA
MN
CN
b)
HA 1
HA 2
P-HA Internet
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 prex and to perform the anycast routing. When an Interior Gateway Protocol (IGP) is used, the scope of Home Agent Migration is limited to a single Autonomous System (AS). The achieved route optimization only concerns communications directed to mobile located in the AS. On the other hand, when an Exterior Gateway Protocol (EGP) is used, the prex is distributed globally on the Internet. The optimization therefore concerns nodes located all over the Internet topology. We give the details of these deployments below. In both deployments, each home agent has an IPv6 address that is topologically correct regarding its physical location, as well as an IPv6 address that belongs to the mobile prex. 1. In an Autonomous System In this deployment, the mobile prex is picked up from the set of IPv6 prexes associated with the Autonomous System. This mobile prex is advertised from dierent routers in the network using an IGP such as OSPFv3. The choice of these routers and their numbers is left to network administrators. In Chapter 4, we will describe how to eciently locate home agents in a given network topology
40
MN 1
MSP 1
MN 3
MSP 2
GMX 1
GMX 2
CN
MN 1
MSP 3
Home Agent belonging to MSP N
Figure 3.4: Concept of Global Mobile eXchange using a graph theory approach. Depending on the Autonomous System, home agents could be interconnected using direct links or VLAN1 , so as to provide a fast and reliable distribution system to synchronize the shared Binding Cache and exchange mobile nodes data trac. This IGP based deployment is more exible than the EGP based one, described below, as network administrators are able to eciently place the home agent in the locations that provide the best performance within their network. 2. In the Internet The mobile prex must be associated to a dedicated Autonomous System number. The Home Agent Migration architecture therefore looks like a distributed Autonomous System in regard to the Internet topology. The mobile prex is advertised from many dierent locations around the globe using an EGP such as BGP. With this deployment, we take advantage of the current Internet infrastructure that relies on Internet Exchange Points (IXPs). Tier-1 ISPs are interconnected thought these IXPs, and use them to exchange most of their data trac. As a consequence, it is possible to eciently deploy home agents in IXPs as rendez-vous points for mobility services. The home agents are operated with
1
Virtual LAN.
41
a concept similar to an IXP; therefore, we call this deployment Global Mobile eXchange (GMX). The primary goals of GMX are to decrease the cost of the transit data trac related to mobile nodes and to allow Internet-Scale Mobility services. Dierent deployments of GMX are possible depending on the number of providers managing the mobility service. Figure 3.4 shows three Mobile Service Providers, MSP 1, MSP 2 and MSP 3, managing dierent two home agents each. These distributed home agents are located where a Mobile Service Provider is physically connected to an IXP. All MSPs are interconnected by home agents located in GMX1 and GMX2. In a GMX, home agents exchange trac and routing information, as a regular router would do in an IXP. GMXs should be located where the concentration of users (and thus data trac) is high, so as to enhance performances. For example, in Tokyo and Osaka for a Japanese Mobile Service Provider. However, this EGP based deployment could be dicult to achieve, as it requires peering agreements with Internet Service Providers located in IXPs where home agents are placed. In order to ease deployments over the Internet, a unique mobile prex could be managed by a Mobile Service Operator (MSO) that operates all of the GMX around the globe. The primary goals of the MSO are to advert the mobile prex to the Internet using anycast routing, locally negotiate peering agreements, and assign parts of the mobile prex addressing space to Mobile Service Providers. For example, the MSO could advert 2001:db8:cafe::/48 and provide smaller prexes to MSP1 and MSP2 such as 2001:db8:cafe:1::/64 and 2001:db8:cafe:2::/64. In other words, a MSO provides the interconnection of various mobility services around the world. MSPs are only in charge of the installation and the operation of their own home agents, and do not need to take care of the anycast routing management. Concerning the routing architecture, announcing a single IPv6 prex dedicated to mobility is benecial as it reduces the impact of Home Agent Migration on the size of routing tables. Indeed, increasing the number of mobile nodes and mobile service providers will have no impact on the routing architecture.
3.1.3
Advantages
While away from its home network, a mobile node will always be associated with the nearest home agent in terms of network topology. As home agents are distributed throughout the Internet, signaling and data trac can be distributed among home
42
agents, the home agent is no longer a performance bottleneck. Depending on home agents locations, the distribution of the home agents also reduces delay and optimizes routes. As previously described, home agents are interconnected to exchange mobile nodes binding information. In addition, they are also able to detect and report each others failures. Therefore, when a mobile nodes primary home agent crashes, another home agent can send a failure alert to the mobile node, and quickly take over the failed one. After receiving the alert, the mobile node sends a Binding Update message to the home agent and resume communications immediately. As a consequence, unlike legacy Mobile IPv6, Home Agent Migration is not vulnerable to constraints for the home link as described in Section 2.2, and is able to handle home agents deciencies. Mobile IPv6s route optimization procedure (i.e. Return Routability Procedure) has a serious privacy issue, as a mobile node must disclose its Care-of Address. While this solution allows end-nodes to use the optimal path between them, it also exposes the fact that the mobile node is not in its home network, but visiting another network. Home Agent Migration does not disclose the mobile nodes Care-of Address, preserving its location privacy. In addition, unlike what happens when using the Return Routability Procedure, the mobile nodes trac cannot be eavesdropped in the visited network since the tunnel between the home agent and the mobile node can be securely protected with IPsec.
3.1.4
Drawbacks
Home Agent Migration relies on anycast routing to distribute home agents in network topologies. As a result, it is threaten by routers failures and convergence time of routing protocols. For example, if a router that controls a specic geographical region fails, mobile nodes cannot communicate anymore. Similarly, correspondent nodes are not able to send data packets to any mobile node. As a consequence, high care must be taken to manage routers that advert the mobile prex and provide connectivity to the home agents. In order to achieve maximum benet from Home Agent Migration deployments, the locations of the distributed home agents and their numbers must be meticulously chosen. Simple deployments as done with Mobile IPv6 are no longer possible: administrators need to plan which locations will be more ecient in terms of communications performances. A formal solution to this issue is discussed in Chapter 4 along with an algorithm that select the home agents locations given a network topology.
43
3.2
Practical implementation
This section describes in details the behavior of the Home Agent Migration concerning the 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 know if a mobile node is reachable, as well as the primary home agent that will be used to forward packets to the mobile node. For every mobile node, it maintains the relationship between the Care-of Address, the Home Address and the home agent associated with a mobile node, which is called the primary home agent. The home agents share the same Binding Cache. Therefore, they can always nd out the primary home agent of a specic mobile node, in order to forward it the mobile nodes data trac. In order to synchronize the Binding Cache, each home agent establishes a secured tunnel with other home agents and uses it to exchange signaling and trac of mobile nodes. When a primary home agent receives a Binding Update message, it sends the resulting relationship to the other home agents over the tunnels. When a home agent receives this relationship, it updates its own Binding Cache. This simple mesh-based binding synchronization can obviously be optimized to be more ecient. However, as it does not impact the mobile nodes performance, this mechanism is sucient for our purpose, and the evaluation of the Home Agent Migration architecture. When a mobile node sends a Binding Update message to a home agent, the Mobile IPv6 specication requires that the home agent veries the uniqueness of the Home Address on the home link, using the IPv6s Duplicate Address Detection (DAD) mechanism2 [105]. However, in our system, as this link is virtual, no DAD packet can be sent on the home link. Consequently, this detection cannot be performed. Instead of the regular DAD mechanism, a home agent uses the Binding Cache in order to verify if 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 eciently intercept the packets sent to the mobile nodes. Consequently, the Home Agent Migration architecture can be seen as a vacuum for the trac destined to the mobile nodes. The following descriptions of communications
in practice, it uses ICMPv6 Neighbor Discovery messages to check if the Home Address is not used on the home link.
2
44
3.2. Practical implementation
a)
HA 1
HA 2
MN
CN
b)
HA 1
HA 2
Figure 3.5: Home Agent Migration: communication examples assume an architecture with two home agents HA1 and HA2 and two nodes, the mobile node MN, closer to HA1, and the correspondent node CN, closer to HA2, as shown in Figure 3.5. The notion of proximity is given by the regular routing of packets from the nodes 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 a packet to the CN, it sends it to its primary home agent over the tunnel. As there is no straightforward way to know which home agent is closer to the CN, HA1 directly sends 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 the MN, it is intercepted by HA2 because of anycast routing. HA2 performs a lookup in the Binding Cache to discover the primary home agent of MN. It sends the packet over the secured tunnel that it maintains with HA1. Then, HA1 decapsulates the packet and sends it to MN over the tunnel they share. The communications between two mobile nodes are similar to the previously described explanations except that data packets are always going through the two home agents.
45
3.2.3
Movements of mobile nodes
In Mobile IPv6, the Dynamic Home Agent Address Discovery (DHAAD) mechanism is used by a mobile node to discover the home agent that it must use. Similarly in the Home Agent Migration system, it is necessary for a mobile node to nd out its closest home agent. As our proposal does not require any modication of the mobile node, this discovery is performed the same way in both systems. As described in the Mobile IPv6 RFC, a Dynamic Home Agent Address Discovery (DHAAD) request is sent by the mobile node to the specic IPv6 address identifying all of the home agents present on 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, in our system this reply is used by the mobile node to discover the address of its primary home agent. Each time that a mobile node enters a new subnetwork, and acquires a new Care-of Address, it must send a Dynamic Home Agent Address Discovery request and a Binding Update message. This is necessary as a mobile node is not able to nd out if it will keep the same primary home agent after a movement. Thanks to anycast routing, the message is routed to the closest home agent that will reply to the mobile node. When a change of home agents occurs, the mobile node does not need to de-register from the old home agent before sending a new Binding Update message to the new one. This is because all the home agents share the Binding Cache. However, it is possible that the closest home agent remains the same after a movement: in this case the Binding Update message is sent to the same primary home agent. For example, this will happen if a Japanese mobile node moves from Tokyo to Yokohama3 and the Home Agent Migration architecture is only deployed in Tokyo and Osaka. The change of home agent can also be performed in a reactive way if a home agent detects 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 detect that it is now closer to another home agent, HA2. As usual, the mobile node will send a Binding Update message to its primary home agent (HA1). Due to the routing architecture, this message will however be routed to the new home agent (HA2), then forwarded to the primary home agent (HA1) over the secured tunnel. As the primary home agent does not receive this Binding Update message on its physical network interface, it can detect that the mobile node moves, and that it is now closer to another
3
south of Tokyo.
46
home agent (HA2). The primary home agent (HA1) will thus ask the mobile node to bind to the new home agent (HA2).
3.2.4
Example of a typical deployment

Virtual home link 1 2001:db8::/48 Virtual home link 2 2001:db8::/48
2001:db8::1
HA 1
HA 2
2001:db8::2
Internet
2001:db8::3
HA 3 HA 4
2001:db8::4
Virtual home link 3 2001:db8::/48
Virtual home link 4 2001:db8::/48
Figure 3.6: An example of home agents conguration Figure 3.6 shows four home agents HA1 to HA4 serving the same IPv6 home prex 2001:db8::/48. Each home agent has a distinct home agent address from the same home network prex even if they are located in dierent networks. For example, in the Figure, HA1 has the address 2001:db8::1. Each home agent acts as a regular access router for the virtually congured home link and intercepts packets meant for mobile nodes. When multiple home agents are congured in dierent networks, each home agent should know the other home agents beforehand and establish IPsec tunnels to ensure secure paths with the other home agents. As previously explained in Chapter 2, with Mobile IPv6, each home agent maintains a list of home agents located in the same home link. However, the home agent list management mechanism requires that all the home agents should be on the same link. Thus, in Home Agent Migration, a new message called Hello is used to periodically exchange home agent information and to conrm home agent availability. The home agent information carried by the Hello message is
47
indeed the same information as Router Advertisements sent by a home agent in Mobile IPv6.
3.2.5
The underlying protocol
Figure 3.7 shows the packets exchanged in the Home Agent Migration system. The protocol is based on the Inter Home Agents protocol (HAHA) [112, 115, 106]. A mobile node (MN) rst registers its binding to its primary home agent (Seq1). The primary home agent creates a binding for the Home Address of the mobile node, and then sends a copy (BCU) to other home agents in order to synchronize the Binding Caches (Seq2). When a home agent receives the copy from the primary home agent, it updates its Binding Cache. When a mobile node communicates with a correspondent node, outgoing packets from the mobile node are tunneled to the primary home agent (here HA1) (Seq3) and incoming packets to the mobile node are intercepted by the home agent HA2, which is closer to the correspondent node. Then, the intercepted packets are tunneled to the primary home agent. The primary home agent delivers the packets to the mobile node through the IPv6-in-IPv6 tunnel (Seq4). If the mobile node decides to switch its primary home agent because of its movement, it sends a Binding Update message to the new primary home agent (Seq7). We described in Section 3.2.3 how to discover the closest home agent. The new primary home agent then synchronizes the binding with other home agents (Seq8). After receiving 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 optimization to Network Mobility (NEMO). Small modications to the shared Binding Cache are sucient to also take Mobile Network Prexes into account: the Mobile Network Prex information is also managed in a Binding Cache entry. Moreover, the network prexes associated with mobile routers must belong to the IPv6 prex advertised by the distributed home agents using anycast. However, the sub-NEMO scenario, described in Chapter 2, cannot fully benet from our proposal. For example, when node B, located in a sub-NEMO, wants to communicate with node A in a parent-NEMO, the performance is similar to the performance of two mobile nodes communicating together through the same home agent. Data packets are not anymore routed to a distant home agent as both tunnels terminate on the closest home agent. The overhead is thus equiv-
48
MN
BU BA
HA 1
HA 2
CN 1
HA 3
CN 2
P-HA
BCU
Seq1: Home Registration
Seq2: Sending BCU to HA2 & HA3

BCU
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
BU
Seq7: Home Registration

BA BCU
P-HA
BCU
Seq8: Sending BCU to HA1 & HA3
BU: Binding Update BA: Binding Acknowledgement BCU: Binding Copy Update
tunneled data packet data packet send directly signaling message
Figure 3.7: Home Agent Migration: packets exchanges
49
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 proposal does not alter the privacy and the security of the communications as IPsec protects the packets 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 home agent address that belongs to the same home network prex. Concerning the protection provided by IPsec, this implies that each mobile node is pre-congured with four Security Policies for each home agent. Two ensure the protection of Binding Update and Binding Acknowledgment messages, and the two others the protection of the tunnel4 . The pre-conguration of these policies could be problematic, and could lead to operational issues if home agents are added after the rst deployments of mobile nodes. An advanced deployment of Home Agent Migration could solve this problem. If all the Home Agents share the same IPv6 address, only two Security Associations must be pre-congured for each mobile node. While promising, this architecture could lead to problems concerning the interaction of the IPsec and Mobile IPv6 stacks especially on the 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 negotiated Security Associations. The use of IPsec to secure the distribution system is however much simpler. In order to synchronize the Binding Cache, home agents are interconnected using IPv6-in-IPv6 tunnels in a mesh like fashion. Consequently, if the distribution system includes N home agents, each home agent must be pre-congured with N 1 security associations to the other home agents.
3.3
Evaluation
In this section, we rst describe the proposed solution in terms of exchanged signaling messages and handover durations. Then, the results of a real Internet scale experiment are shown and discussed in terms of Round Trip Time between end-nodes.
4
one Security Policy each way.
50
3.3. Evaluation
3.3.1
Performances comparisons
Smip6 = BU + BA (3.1)
Srrp = BU + BU + Ncn (BU + BA + HoT i + HoT + CoT i + CoT ) (3.2) Sham = BU + BA + Nha 1 (3.3)
Putting Dynamic Home Agent Address Discovery aside, with Mobile IPv6s Return Routability Procedure, when a mobile node performs a handover it must advertise its new Care-of Address by exchanging Binding Update and Binding Acknowledgement messages with its home agent, and possibly with each of its correspondent nodes. Prior to exchanging Binding Update and Binding Acknowledgement with a correspondent node, 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 correspondent nodes. With Home Agent Migration, a mobile node only registers with a single home agent. However, assuming an inecient mesh-based distribution system, this binding information must be delivered to every home agent. With Mobile IPv6, the mobile node simply exchanges a Binding Update and a Binding Acknowledgement with its home agent. Equations 3.1, 3.2, and 3.3 represent the number of signaling messages necessary to handle a handover for Mobile IPv6 (Smip6 ), Mobile IPv6 with the Return Routability Procedure (Srrp ) and Home Agent Migration (Sham ), respectively. Ncn and Nha are the numbers of correspondent nodes and home agents. In terms of signaling messages, the Home Agent Migration is therefore an improvement comparing to the Return Routability Procedure. However, depending on the distribution system in use, it could require much more messages than Mobile IPv6.
Ncn
Trrp = Rmnha +
(Rmnha + Rhacn[n] + 2 Rmncn[n] )

n=1 Nha 1
(3.4)
Tham = Rmnha +
n=1
Rhaha[n]
(3.5)
Along with the number of signaling packet exchanged, the handover can also be studied as the time to complete a new association to a home agent. As the processing time of the signaling packets is not signicant regarding their Round Trip Time (RTT), it is safe to describe the handover duration with the RTT. Equations 3.4 and 3.5 represent this duration for Mobile IPv6 with the Return Routability Procedure (Trrp )
51
and Home Agent Migration (Tham ). We dene Rmnha to be the RTT between a mobile node and its primary home agent, Rhacn[n] the RTT between the primary home agent and the n-th correspondent node, Rmncn[n] the RTT between a mobile node and the n-th correspondent node, and Rhaha[n] the RTT between the primary home agent and the n-th home agent. Rmncn[n] is bound by: Rmncn[n] (Rmnha + Rhacn[n] ). Equation 3.5 is straightforward: in Home Agent Migration a mobile node sends a Binding Update message and receives a Binding Acknowledgement (Rmnha ), the Binding Cache is then synchronized among other home agents. Equation 3.4 is slightly more complicated, but directly comes from the operation of the Return Routability Procedure. The mobile node rst sends and receives Binding Update and Binding Acknowledgement messages (Rmnha ), then for each correspondent node, it sends and receives a pair of Home of Test init and Home of Test messages (Rmnha + Rhacn[n] ), a pair of Care-of Test init and Care-of Test messages (Rmncn[n] ), and nally the Binding Update and the Binding Acknowledgement messages (Rhacn[n] ). With the Return Routability Procedure, the handover duration increases proportionally with the number of correspondent nodes and the Rmnha increases as the mobile node moves far away from its home agent. The last correspondent node that receives a Binding Update message must wait as long as Trrp before it can use the optimized path with the mobile node. In Home Agent Migration, if home agents are carefully distributed in the Internet, it is possible to bound Rmnha to a value not related to the mobile nodes locations. Furthermore, the latest sum of Equation Tham can be limited according to the solution used to distribute binding information. After the reception of the Binding Acknowledgment message, a mobile node can directly tunnel data to its primary home agent and does not need to wait for the completion of binding information distribution. The Home Agent Migration thus provides route optimization with better handover latency, especially if a larger number of correspondent nodes is involved.
3.3.2
Experimental results
In order to conduct our experiments, a userland daemon was developed using the KAME BSD IPv6 stack [15] and the advanced socket API [103, 30]. It is a lightweight version of a regular home agent that also performs Binding Synchronization. During most of the experiments we used SHISA [13], an implementation of Mobile IPv6 for BSD kernels, for the mobile nodes. However, in some locations as we were unable to set up real mobile nodes, we had to emulate them. These emulated mobile nodes were implemented in the Python programming language using Scapy6 [109] which is
52
3.3. Evaluation
HA1 HA1 HA2 110
HA2 110 -
Tokyo 0.52 110
Amsterdam 297 188
Belgium 292 194
San Francisco 141 30
Table 3.1: Round Trip Time in our experiment (in ms)
described later in Appendix A. We observed almost no dierence between the results for a real and an emulated mobile node.
San Francisco
Tokyo
WIDE's AS
HA 1 HA 2
Belgium
Internet
Amsterdam
Figure 3.8: Abstract network topology of the experimentation Two home agents were setted up inside the WIDE projects Autonomous System (AS). One was located in Los Angeles and the other one in Tokyo. In the AS, each home agent advertises the same IPv6 prex using OSPFv3. The mobile node is located in 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.2 details average Round Trip Times between all of the involved nodes. The operational issue in this network is the link between Japan and the United States that goes under the Pacic Ocean. The goal of this experiment is to use the Home Agent Migration in order 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
53
0.5
0.5
0.5
0.4 RTT (seconds) RTT (seconds)
0.4 RTT (seconds) 0 5 10 15 20 25 Time (seconds) 30 35 40
0.4
0.3
0.3
0.3
0.2
0.2
0.2
0.1
0.1
0.1
10
15 20 25 Time (seconds)
30
35
40
10
15 20 25 Time (seconds)
30
35
40
(a) Direct Path
(b) Regular Mobile IPv6
(c) Home Agent Migration
Figure 3.9: RTT between San Francisco and Tokyo
0.5
0.5
0.5
0.4
0.3
0.3
0.3
0.2
0.2
0.2
0.1
0.1
0.1
0 0 5 10 15 20 25 Time (seconds) 30 35 40
0 0 5 10 15 20 25 Time (seconds) 30 35 40
(a) Direct Path
Figure 3.10: RTT between San Francisco and Amsterdam
0.5
0.5
0.5
0.4
0.3
0.3
0.3
0.2
0.2
0.2
0.1
0.1
0.1
0 0 5 10 15 20 25 Time (seconds) 30 35 40
0 0 5 10 15 20 25 Time (seconds) 30 35 40
(a) Direct Path
Figure 3.11: RTT between San Francisco and Belgium
54
3.3. Evaluation
Round Trip Time for communications between the mobile node and the correspondent nodes in three dierent scenarios; (a) show the Round Trip Time when Mobile IPv6 is not used (i.e. direct path), (b) when Mobile IPv6 is used, and (c) when Home Agent Migration is deployed. Note that for Mobile IPv6, we used HA1 as the home agent. No more than the rst forty seconds of the experiment are represented here so as to make the plots easily readable. When the mobile node is located in San Francisco and the correspondent node in Tokyo, 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 on the direct communication path between the correspondent node and the mobile node. The negligible overhead of the Home Agent Migration is caused by the tunnel between HA1 and HA2 and is dependent on our Home Agent Migration implementation. When home agents are carefully deployed on the Internet, Mobile IPv6 does not provide any overhead. With this pair of nodes, no benet 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 correspondent node in Amsterdam. In this scenario, HA2 located in Los Angeles is obviously closer to the mobile node and is automatically selected as the primary home agent for Home Agent Migration. As a result, the average Round Trip Time with Home Agent Migration is 220 ms smaller than the Round Trip Time when legacy Mobile IPv6 is used, and the trac goes through HA1, see Figure 3.10(b). This dierence is caused by the latency of packets traveling under the Pacic Ocean as shown in Table 3.3.2. When Home Agent Migration is used, the average Round Trip Time is exactly the same as the direct communication path. Therefore, Home Agent Migration allows the use of Mobile IPv6 with no signicant Round Trip Time overhead. In Figure 3.11, the mobile node is located in San Francisco and the correspondent node 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 direct communication path. When the Home Agent Migration is used, the path from San Francisco to Belgium is through the nearest home agent (i.e. HA2), while the reverse path is via Tokyo (i.e. HA1) due to BGP peerings. Although the Round Trip Time is smaller than the one with regular Mobile IPv6, Home Agent Migration does not provide an improvement as important as in the previous case. The critical aspect of Home Agent Migration in a single Autonomous System is the correct placement of the home agents in the network topology. In order to achieve the best performance, the home agents should be located on the direct communication path
55
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 resolved by the administrators of the Autonomous System if they carefully congure the costs of paths using routing protocols. For Internet-Scale deployments using GMX, the home agents are located in important Internet eXchange Points, and are thus on the direct communication path between most mobile and correspondent nodes. Maximum performance 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 Agent Migration, at providing better route optimization for Mobile IPv6. Previous works in route optimization [66, 85, 114] involve caching binding information in the correspondent nodes and in routers on-demand. However, these end-to-end optimizations also introduce the issues described in Chapter 2: modications of endnodes and complexity of operation. Unlike these systems, Home Agent Migration is designed to be transparent to end-nodes and only requires small changes in home agents. Several regional and hierarchical approaches for reducing the binding overhead have been proposed [29, 24, 52, 90, 60]. The underlying concept of these eorts is to enable a mobile node to associate with a closer agent instead of its home agent. Although the design concept looks similar to Home Agent Migration in terms of home agent distribution, these studies signicantly modify the implementations of the mobile nodes. For example, HMIPv6 [29] requires the mobile node to manage several Care-of Addresses. Ecient dynamic assignment of home agents have also been introduced to provide optimal routing between end-nodes. Mobile IPv6 regional mobility management [84] uses a Regional Anchor Point (RAP) located in the network that the mobile nodes visit in order to optimize routes. The NASA and Cisco investigated multiple home agent setups in an Autonomous System [63]. By assigning priority to home agents, mobile nodes can be associated with a closer home agent. This approach is similar Home Agent Migration but the choice of the primary home agent is performed using access lists. In order to set up access lists, the system operator must know beforehand the pattern of mobile node movements. In contrast to this system, Home Agent Migration dynamically selects the closest home agent using anycast routing. Finally, the home agent reliability protocol [111] provides redundancy and reliability to Mobile IPv6 by duplicating the home agents on the home link. It exchanges mobile node 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 a mobile nodes connections. There are several similar works such as the Home Agent Redundancy Protocol (HARP) [31] and Virtual Home Agent Reliability (VHAR) protocol [48]. However, the main drawback of these systems is that they only activate one home agent at a time. In the Home Agent Migration, every home agent are always active. Furthermore, our proposal is not aected if the home link becomes unreachable.
3.5
Conclusion
We described a new architecture for Internet-Scale Mobility deployment called Home Agent Migration. This proposal eciently solves Mobile IPv6 limitations such as protocol scalability and reliability, and redundant communication paths. In our solution, unlike in Mobile IPv6, multiple home agents are distributed over the Internet, and advertise the same IPv6 prex using anycast routing. The mobile nodes only see one home agent and do not need to know about the other ones. From any location, they are 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 delay between a home agent and a mobile node located anywhere on the Internet. Compared to other route optimization schemes, Home Agent Migration does not require any modications on end-nodes and oers performances similar to a communication without 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 dierence is that home agents must also exchange Mobile Network Prexes. Our proposal is especially useful for NEMO as no route optimization procedure is yet standardized at the IETF. However, we identied some issues that must be taken into account while deploying the Home Agent Migration system. When routing paths are not symmetric, the performance oered by our solution is not as good as direct communication; thus, the benet is only eective in one way. We performed experiments that validated our assumptions about the optimizing eect on the performance of the Mobile IPv6 protocol and showed that 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 actual proposal, a simplistic mesh-based protocol is used to distribute binding information between home agents, and we are investing the use of Distributed Hash Tables to enhance the performance of the binding synchronization between home agents. Besides, we will also study the eects of our scheme on the scaling of BGP routing.
57
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 Mobile IPv6 community. Moreover, we would like to debate the shortcoming and the possible requirements concerning the use of IPsec with our proposal. This could lead to necessary modications of the Internet Key Exchange (IKE) protocol concerning mobility. Finally, from an operator point of view, it is necessary to study the feasibility of Global Mobility eXchange and validate its business model. As a matter of fact, an operator will require that Home Agent Migration could be integrated into standard Authentication, Authorization, and Accounting (AAA) frameworks prior to any commercial deployment.
Chapter
4
Graph theory reminders . . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 Preliminary denitions . . . . . . . . . . . . . . . . . . . . . . Importance of vertices . . . . . . . . . . . . . . . . . . . . . . 60 60 62 63 64 65 65 66 66 68 68 70 71 72 73 78 83 85
Mobile IPv6 deployments

Contents
4.1
4.2
Networks as graphs . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.2.3 Observing networks . . . . . . . . . . . . . . . . . . . . . . . Modeling networks . . . . . . . . . . . . . . . . . . . . . . . . Weights on edges . . . . . . . . . . . . . . . . . . . . . . . . .
4.3
Home Agents locations . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 4.3.3 Impact on paths lengths . . . . . . . . . . . . . . . . . . . . . Optimal locations . . . . . . . . . . . . . . . . . . . . . . . . Comparison methodology . . . . . . . . . . . . . . . . . . . .
4.4
Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 4.4.2 4.4.3 4.4.4 Studied networks . . . . . . . . . . . . . . . . . . . . . . . . . Relationship between the degree and the betweenness . . . . Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Home Agent Migration . . . . . . . . . . . . . . . . . . . . .
4.5 4.6
Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.1. Graph theory reminders In Mobile IPv6, as formerly outlined, the accurate location of the home agent is a
critical aspect since it impacts communication delays and path lengths. Here, we model operators networks as graphs and formally describe the impact of the dogleg routing according to the home agents locations using well-known graph metrics. In particular, 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 IPv6 deployment issues, which could be applied to any operator network. Our proposal is singular compared to other solutions, such as the Return Routability Procedure, since the optimization of paths is only achieved with a correct placement of home agents, and is non-intrusive protocol-wise. Consequently, it can immediately be used to enhance Mobile 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 rst recall the graph theory notions [25] used in our discussions in Section 4.1. Then in Section 4.2, we briey discuss several techniques commonly used to obtain graph models of communication networks. In Section 4.3, we formally dene the impact of Mobile IPv6 and Home Agent Migration on path lengths, and discuss a methodology for comparing home agent locations. In Section 4.4, we numerically evaluate this methodology using realworld network topologies. Finally, prior to the conclusion, we examine related work in Section 4.5.
4.1
4.1.1
Graph theory reminders

Preliminary denitions
An undirected graph G = (V, E) is dened by two nite sets: V , the set of vertices, and E V V , the set of edges. Each edge e = (x, y) is a pair of vertices called extremities1 of the edge e. We dene n = |V | and m = |E| as the number of vertices and 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 parallel edges: the edge (u, v) is unique (which implies that the edge (v, u) does not exist). An example 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 is associated a positive real value (e) 1 that we call weight. An unweighted graph is equivalent to a weighted graph in which each edge has weight one. As a consequence,
1
or end-vertices.
Chapter 4. Mobile IPv6 deployments
61
42
B
0 10 0
10
1
a b
20
28 F
(a) Undirected graph
(b) Weighted undirected graph
Figure 4.1: Examples of unweighted and weighted graphs algorithms presented in subsequent sections of this chapter will only consider weighted graphs. 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 dened as the sum of its edges weights. We note it l(P ). In Figure 4.1(a), we have l(a, e, d, b) = 3. Likewise, in Figure 4.1(b), we have l(A, B, C, F ) = 1242. A shortest path between two vertices x and y is a path between x and y with minimal length. In Figure 4.1(b), the path (A, B, G, F, C) is the unique shortest path from A to C. In Figure 4.1(a), paths (c, a, e) and (c, d, e) are both shortest paths from c to e. The distance between two vertices x and y is the length of a shortest path from x to y. We note it d(x, y). If x = y, we have d(x, y) = 0. For all x, y, we have d(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 the following, we will only consider graphs in which there is no isolated vertex, so that i V, (i) 1.
62
4.1. Graph theory reminders
3000 D E F
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 other words, such a vertex has a strong position within the graph. Likewise, a vertex with a small centrality belongs to few shortest paths. Concerning a communication network like the Internet, a router with a high centrality will be on most communication paths within the network. Correspondingly, a router with a small centrality2 will only gather communications from nodes connected to its egress network interface. Centrality consequently provides an interesting estimate to calculate the importance of a vertex inside a graph. It is frequently used in various scientic elds such as sociology, or epidemiology. Indeed, sociologists consider the centrality as an important measure in social networks [53]. For example, they use it to pinpoint highly connected people in relationships graphs. Likewise, it is used to identify how a viral infection will spread in a given graph, and which highly connected vertices should be protected or cured to limit the epidemic [40]. Several measures of centrality were dened so far, namely betweenness, closeness, and eigenvector centrality. They all dene the importance of a vertex using well-known graph metrics such as the distances, or shortest paths. In our study, we only consider the betweenness 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, the betweenness centrality is equal to:
2
located in a subnetwork, for example.
63
Node A B C D E F G H I
Betweenness 1 6 6 31 32 31 6 6 1
Betweenness & weights 14 0 24 30 32 31 6 6 1
Table 4.1: Comparison of centrality values for the graph of Figure 4.2
CB (x) =
y=z=xV
yz (x) , yz
(4.1)
where yz is the number of shortest paths from y to z, and yz (x) the number of shortest paths from y to z that contains x. The betweenness centrality is aected by weights on edges. In Figure 4.2, when the graph is considered as unweighted (i.e all edges weights are equal to 1), we have CB (A) = 1 and CB (C) = 6. If we take weights into account, we now have CB (A) = 14 and CB (C) = 24. Table 4.1 gives the betweenness centrality values for the graph in Figure 4.2. One can easily see the inuence of weights on the betweenness centrality. When a high weight is associated to the edge (B, D), the node B does not belong to any shortest 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 paths to node B.
4.2
Networks as graphs
In order to use graph metrics to nd relevant locations for home agents, networks must be represented as graphs. In this section, we explain how we do this. Obtaining an accurate 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 rst provide an overview of common techniques currently used to acquire snapshots of communication networks. Then, we describe how we manipulate this data, and what vertices and edges in the graph represent from a network perspective.
4.2.1
Observing networks
Dierent techniques are commonly used to acquire knowledge about communications networks. Here, we describe three main techniques and briey discuss their advantages and shortcomings. As a matter of fact, while observing network topologies, two main problems can occur: some routers are not discovered at all, and some routers appear more than once (because they have one IP address per network interface). The rst category of approaches relies on active measurements to probe the network and discover routers as well as links between them. Such measurements use variants of the well-known traceroute tool. In practice, the observed topology might dier from the real one in several aspects. So as to obtain more accurate information, several new techniques were dened to identify all of the IPv6 addresses that belong to the same router [102], performing faster network discoveries [76], or identify routers than perform load balancing [21]. The second category uses information contained in routing tables to deduce the network topology. Depending on the considered routing protocol, the granularity of the obtained information will dier. For example, if OSPF is used, one can obtain a precise view of routers and links in the same Autonomous System; when BGP is used, the graph will only contain links between Autonomous Systems. Compared to traceroute-like measurements, the use of routing tables usually provides a more precise view 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 the Route Views project [12]. The principal advantage of this approach is that routers can easily be uniquely distinguished using identiers carried by routing protocols. While considering BGP, the main drawback is that the resulting graph might be partial due to ltering and prexes aggregations commonly performed in BGP peerings. Finally, the last category of approaches relies on information provided directly by network administrators. By far, they will result in the most accurate information on the topology either at Layer-2 or Layer-3. However, this information is also dicult to 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 a rather limited number of nodes.
65
(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 each vertex is a single router, and that edges correspond to physical or virtual3 links between them. Still, whenever possible, we tried to aggregate routers located in the same Network Operating Center into a single vertex. As these routers are interconnected with high-speed links, the Round Trip Times between them can be neglected and it is safe to represent them as a single vertex in our model. This aggregation reduces the number of vertices and consequently decreases the computation times. Furthermore, it makes it easier to identify locations of home agents that deliver good performance since it is not signicant to compare routers that are physically in the same Network Operating Center. Figure 4.3(a) shows several routers located in a Network Operating Center in Tokyo, while Figure 4.3(b) shows the resulting aggregation. The links between these 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 network topologies. In a networking context, edges can for example be weighted using costs internally used by routing protocols, or Round Trip Times between vertices4 .
3 4
like MPLS or tunnel based links. routers, or Network Operating Center.
66
4.3. Home Agents locations Such routing costs express specic routing optimizations made by networks admin-
istrators. Moreover, the costs help to dierentiate network links and reect that some are more important than others: high routing costs are for example used to refrain the usage of transit links in favor of peering ones. When information about networks comes from routing tables, routing costs are directly available. Likewise, Round Trip Times between routers can also be used as edges weights. They help in reecting the real expected network delays between any pair of vertices. A cumbersome yet ecient way to gather these values is to log into routers and to launch the ping command to evaluate the average Round Trip Time on each edge between routers. However as this might not be possible, Round Trip Times values could also be inferred using outputs of the traceroute tool.
4.3
Home Agents locations
In this section, we formally dene the impact of Mobile IPv6 and Home Agent Migration on paths lengths. Then, we discuss the inuence of home agents locations on communications. Finally, we provide details about the comparison methodology that we will later use in the evaluation presented in Section 4.4.
4.3.1
Impact on paths lengths
We now discuss the inuence of the Mobile IPv6 and Home Agent Migration protocol on the paths length between two vertices in a graph, both in weighted and unweighted graphs. Vertices in the graph independently represent locations of home agents, mobile nodes or correspondent nodes depending on the discussions. We dene two new notations, such as dmip6 (A, B) and dham (A, B) denote the length of a shortest communication 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 such a path is in general larger than the distance between A and B, because the communication 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 A and B must go through the home agent HA. By denition, the resulting path length between A and B is the sum of the distances between A and HA, and between HA and B:
67
dmip6 (A, B) = d(A, HA) + d(HA, B)
(4.2)
Note that with Mobile IPv6, the paths between a mobile node and a correspondent node are symmetric. Therefore, communications between mobile nodes and correspondent nodes are equivalent to communications between correspondent nodes and mobile nodes. Home Agent Migration Contrary to Mobile IPv6, communications between correspondent and mobile nodes are in general not symmetric when Home Agent Migration is used. As a consequence, we need to consider separately the three possible communications patterns: between two mobile nodes M N 1 and M N 2, from a mobile node M N to a correspondent node CN , and nally from a correspondent node CN to a mobile node M N . In the following equations, 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 communication path between M N 1 and M N 2 is simply the sum of the distances between M N 1 and its primary home agent HAM N 1 , between HAM N 1 and HAM N 2 , and between M N 2 and its primary home agent HAM N 2 :
dham (M N 1, M N 2) = d(M N 1, HAM N 1 ) + d(HAM N 1 , HAM N 2 ) + d(HAM N 2 , M N 2)
(4.3)
Concerning communications between a correspondent node and a mobile node, the behavior is the same:
dham (CN, M N ) = d(CN, HACN ) + d(HACN , HAM N ) + d(HAM N , CN )
(4.4)
On the other hand concerning mobile nodes to correspondent nodes communications, the path goes only through the primary home agent of the mobile node:
68
4.3. Home Agents locations
dham (M N, CN ) = d(M N, HAM N ) + d(HAM N , CN )
(4.5)
4.3.2
Optimal locations
Regarding Mobile IPv6, when the path length between two nodes A and B is not altered by the dogleg routing, i.e. d(A, B) = dmip6 (A, B), the home agent is located on the shortest path between A and B. For instance, in the graph of Figure 4.2, if the home agent 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 number of shortest paths in the graph, i.e. vertices with the highest betweenness centrality measures. A similar discussion applies to Home Agent Migration: when two mobile nodes M N 1 and M N 2 communicate5 , the two primary home agents HAM N 1 and HAM N 2 must be on the shortest path between M N 1 and M N 2 to obtain performances similar to the direct communication, i.e. d(M N 1, M N 2) = dham (M N 1, M N 2). With Home Agent Migration, increasing the number of home agents enables the mobility system to 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 dicult and computationally expensive task. Indeed, it implies computing all of the possible home agents arrangements, then recomputing paths lengths according to home agents locations, and nally comparing the resulting modied 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 impact of home agents locations. They will be used in the evaluation Section 4.4. We compare home agents locations by placing home agents, mobile and correspondents nodes in all vertices, and comparing the distance between two vertices to the communication distances with dmip6 and dham . Two dierent strategies are used to identify relevant locations for home agents: one uses the degree, and the other one the betweenness centrality. 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
5
also true with communications from a correspondent node to a mobile node.
69
to its degree [39]. This is an important result concerning the upcoming evaluation in unweighted graph as degree can be computed faster than betweenness. Computing distances As previously described in Section 4.3.1, the communication distances in Mobile IPv6 and Home Agent Migration can be expressed as sums of distances between vertices where mobile nodes, home agents and correspondent nodes are located. We therefore need to rst compute the distances between all pairs of vertices in the graph. Distances are stored in the array distances, we note distances[A][B] the distance between vertices 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 distances between 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 an array degree for vertices degrees. Moreover, we note sd, sorted degree, a list of vertices ordered 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 smallest degree. 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 an array of betweenness centrality values noted betweenness. Moreover, we note sb, sorted betweenness, a list of vertices ordered by decreasing betweenness centrality, similarly to sd. Anycast routing emulation With Home Agent Migration, a mobile node is always associated with its topologically closest home agent. Likewise, packets sent from a correspondent node to a mobile node are intercepted by the home agent that is the closest to the correspondent node. In practice, these automatic selections of home agents are accomplished thanks to anycast routing, and the routing protocols used to advert the mobile prex to the network, as described in Section 3.1.2. When studying Home Agent Migration from a graph theory perspective, the automatic selection of home agents must be adapted and redened using graph based methods. 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 of distances in the graph, distances, a list of home agents used in Home Agent Migration, ha, and a node, n, we dene the select pha() function that returns the closest home agent to node n, i.e. the vertex with the minimum distance to n. When two home agents are equally distant from the node, the preference is given to the rst home agent that appears in the home agent list ha. With the distances array preliminary computed, it is then straightforward to determine the new distances with Home Agent Migration and Mobile IPv6 based on the following sums. We note pha1 and pha2 the primary home agents of mn1 and mn2 respectively, as selected by the select pha() function.
dmip6[mn1][mn2] = distances[mn1][ha] + distances[ha][mn2] dham[mn1][mn2] = distances[mn1][pha1] + distances[pha1][pha2] + distances[pha2][mn2]
(4.6) (4.7)
We can now dene an algorithm that will compute the communication distances when Mobile IPv6 and Home Agent Migration are considered. Algorithm 1 describes how to compute all distances using the distances array, a list of home agents ha, and the list of all nodes in the graph nodes. The same algorithm is used to compute distances with Mobile IPv6 and Home Agent Migration, the detection of the mobility protocol 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 Migration with a single home agent. If the length is greater than one, Home Agent Migration is considered. Line is an optimization that uses the fact that d(pha1, pha2) = 0 when pha1 = pha2 to merge computations of path lengths with Mobile IPv6 and Home Agent Migration. For better eciency, primary home agents can be computed beforehand and stored in an array that could be used to replace calls to the select pha() function in the algorithm.
4.4
Evaluation
In this Section, we provide an evaluation of home agent locations based on the methodology previously described in Section 4.3, and compare the two location strategies (according to degree and betweenness centrality in increasing order). We rst describe the three graphs that we will use for this evaluation. Then, we separately discuss Mo-
71
Algorithm 1: Distances and mobility protocols Input: distances: array of distances, ha: list of home agents, nodes: list of nodes 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] end return new distances ; end
*/
*/ */
bile IPv6 and Home Agent Migration, and show that it is possible to minimize their impact 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 network spread over thirty countries. This graph was built using information about the layer 2 topology released on December 2004 on the GEANT web page [5]. It contains 63 vertices. Edges are weighted using routing costs6 provided along with the layer 2 topology. 2. WIDE: it represents the WIDE projects network: a Japanese research network connecting university campuses. This graph was obtained using layer 2 topology information privately available to members of the project, then rened based on personal discussions with the network administrators. It contains 28 nodes that correspond to Network Operating Centers, campus networks, as well as peering
6
the ISIS routing protocol is used in GEANT.
72
4.4. Evaluation
1000
1e+07 1e+06 100000
betweenness
betweenness
10000 1000 100 10 1 0.1
100
10 1 2 3 4 5 6 7 8 9 10 degree
0.01 0 20 40 60 degree 80 100 120
(a) GEANT
(b) V6-MAP
Figure 4.4: Degree against betweenness centrality
points. As described in Section 4.2.2, aggregations of several routers into a single vertex were performed. Edges are not weighted. 3. V6-MAP: this graph represents the layer 3 IPv6 topology of the Internet produced on June 2003 using the network cartographer (nec) tool [9]. It is publicly available on the project web page. This tool sends traceroute queries to a set of distributed servers and is able to identify IPv6 addresses that belong to the same router in order to combine them into a single vertex. Moreover, it merges the dierent topologies 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 description while the betweenness centrality is much more expensive to calculate since it requires to search the graph and compute all shortest paths between any pairs of vertices. As a consequence, prior to comparing the degree and the betweenness centrality as home agents placement strategies, we will study how these two measures are related in the three 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 without using weights on edges in order to strictly compare the graphs structures. While the results of the WIDE graph are similar to the ones given in this section, their visual representation is not signicant enough to be provided.
73
D subgraph 1 A B E F C subgraph 2
Figure 4.5: Degree against betweenness centrality: example graph Both gures indicate that vertices that have the highest degrees also have the highest betweenness centrality values. This is a remarkable property concerning our placement strategies as we proposed to locate home agents in vertices that have the highest degree and betweenness centrality values. Such a property is indeed not symmetric. From Figure 4.4(b), it is clear that vertices with a small degree do not have necessarily a small betweenness centrality value. While this is somehow a counter-intuitive result, it could easily be illustrated using the example graph in Figure 4.5. We consider that the two subgraphs 1 and 2 contain many vertices that are not represented for convenience. Nodes D, E, and F have a small degree (2), whereas node B has a high degree (6). However, both nodes D and B have a high betweenness centrality value: they are on the same number of shortest paths between vertices in the subgraph 1 and vertices in the subgraph 2. In practice, the relation between high degree and high betweenness is especially interesting. Indeed, it could be used by system administrators that want to deploy Mobile IPv6, but can not apply our graph based strategies because they do not have a graph model of their network. They could instead locate the home agent close to highly 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 mobile node and a correspondent node are equivalent: all packets must go through the home agent. As a consequence, in this evaluation, we will only consider the inuence of home agent locations on communications between two mobile nodes. From a deployment point of view, Mobile IPv6 is still a young protocol. As of today, it has never been commercially deployed; its practical usage is mainly limited
74
4.4. Evaluation
100 80 60 40 20 0 0 200 400 600 max min 800 1000
100 80 60 40 20 0 0 200 400 600 max min 800 1000
% of pairs of vertices
% added to paths length
(a) WIDE
(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: subnetwork that modies path lengths the most (worst). max : subnetwork that modies path lengths the least (better).
to testbeds or research networks. There is therefore no such thing as a typical Mobile IPv6 deployment. Nevertheless, we noticed that network administrators often locate home agents in subnetworks for management convenience. Such a setup is also quite common in the literacy. We will now study the impact of the home agent location on communication distances when it is located in a subnetwork, i.e. a vertex with degree one. Figures 4.6 and 4.7 show the modication of path lengths when the home agent is located in a subnetwork, for the WIDE, GEANT and V6-MAP graphs. The x-axis represents the increase of paths lengths in percents: 100% means that the communication distance in this case is twice as large as the direct distance between the two nodes. The yaxis represents the number of pairs of vertices in the graph for which the increase of 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 gures, min corresponds to the subnetwork which modies path lengths the most, and max to the subnetwork which modies path lengths the least, i.e. the subnetwork that improves performances the most. In Figure 4.6(a), when the home agent is located in the max subnetwork, 56% of all 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), the dierence is even more signicant. When the home agent is in min, only 0.4% of pairs
75
100 80 60 40 20 0 0 200 400 600 max min 800 1000
100 80 60 max min 40 20 0 0 200 400 600 800 1000 % added to paths length
(a) GEANT unweighted
(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: subnetwork that modies path lengths the most (worst). max : subnetwork that modies path lengths the least (better).
of vertices are increased at most of 80%. In this case, 80% of all shortest paths are seriously modied: their length is increased by 1250%. With max, 80% of all shortest paths are only increased by 80% or less. Finally when weights are used to compute the distance, Figure 4.7(b), the two considered subnetworks deliver results even more dissimilar: with min 6% of all pairs of vertices are not modied. In contrast, with max, this fraction is higher: 80%. From these four gures, it is clear that the subnetworks are not identical from a performance point of view: they do not equally modify paths lengths. However, there is no straightforward solution to nd out which vertex will perform the best comparing to the other vertices of degree one. Therefore, we now compare the subnetwork that modify paths lengths the least (called max to keep the same naming convention) to vertices with the highest degree and betweenness centrality. Results are presented in Figures 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 vertices with the highest degree and the highest betweenness centrality, and the vertex that corresponds to max are dierent. When the home agent is located in one of the two vertices with the highest degree or betweenness centrality, the number of paths that are not modied is drastically increased in the unweighted graphs. In WIDE, 51% and 54% of all shortest paths are not modied when the degree and the betweenness centrality are respectively used to
76
4.4. Evaluation
100 80 60 40 20 0 0 200 max highest betweenness highest degree 400 600 800 1000
100 90 80 70 60 50 40 30 20 10 0 0 50 max highest betweenness highest degree 100 150 200 250
(a) WIDE
(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 modies path lengths the least.
100 80 60 40 20 0 0 200 max highest betweenness highest degree 400 600 800 1000
100 80 60 40 20 0 0 200 max higgest betweenness highest degree 400 600 800 1000
(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 modies path lengths the least.
77
Figure 4.10: Centrality: example graph select the home agent location. This is 7% with max. Similarly in V6-MAP, 17% and 26% are not modied 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 betweenness 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 of HD are slightly better than HB. For instance, the fraction of pairs for the communication distance is equal to the real distance in 34% of the case for HD and 30% for HB. This behavior indicates that the vertex HD is indeed on a shortest path between more pairs of vertices than HB. This seems counter-intuitive, because the betweenness centrality aims precisely at identifying vertices located on many shortest paths. However, due to the denition of the betweenness centrality (see Equation 4.1 page 63), when there are many shortest paths between two vertices this lowers the betweenness centrality of the vertices on any of these shortest paths. However, in our context what is important is whether a vertex is on any shortest path between two vertices. We present, in Figure 4.10, an example of a case where a vertex with a higher betweenness centrality is on shortest paths between fewer vertices than a vertex with a lower betweenness centrality. In this example, the vertex A is on a shortest path between 18 pairs 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 in the GEANT graph, that is why locating the home agent in HD provides a better result than locating it in HB. When weights are used with GEANT, HB as a home agent location gives better results than either HD or max. The comparison between HD and max is however not as straightforward, and reveals some interesting features. The number of pairs for
78
4.4. Evaluation
100
100 90
95
80 70 60 50 40 30 20 0 20 40 60 80 2 HA 5 HA 10 HA 50 HA 500 HA 1000 HA 2000 HA 3000 HA 4000 HA 100 120 140
90
85
80 0 20 40 60 80
2 HA 5 HA 10 HA 20 HA 100 120 140
% added to paths lengths
(a) WIDE
(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 the second highest betweenness centrality. This shows that even though the betweenness centrality does not capture perfectly the fact that a vertex is a good location for a home agent, it is still a very good indicator. However, this tendency is reversed when we consider cases in which the communication distance is larger than the distance. For instance, with max 94% of all pairs of vertices are increased by 150% or less; this is 93% with HD. This indicates that when the home agent is located in the subnetwork max, 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 vertex with the second highest betweenness centrality. Consequently, it delivers slightly better results than HD.
4.4.4
Unlike in the Mobile IPv6 protocol, the communications between mobile and correspondent nodes are not symmetric in Home Agent Migration (see Equations 4.5 and 4.5 page 68). Prior to other studies, we will therefore evaluate this dierence by comparing the communication distances from a mobile node to a correspondent (called pattern MNCN ) and from a mobile node to another mobile node (called pattern MN-MN ; which is the same as the one from a correspondent node to a mobile node).
79
100 95 % of pairs of vertices 90 85 80 75 70 65 60 0 20 40 60 80 2 HA 5 HA 10 HA 20 HA 30 HA 100 120 140 % of pairs of vertices
100 95 90 85 80 75 70 65 60 0 20 40 60 80 2 HA 5 HA 10 HA 20 HA 30 HA 100 120 140
(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 denition, the communication distance of MN-MN is larger than or equal to MN-CN. Figures 4.11 and 4.12 represent the dierence of paths lengths between these communication for the WIDE, GEANT, and V6-MAP graphs. The x-axis represents the increase of communications distances in percents: 100% means that the MN-MN communication distance in this case is twice as large as the MN-CN one. The y-axis represents the number of pairs of vertices in the graph for which the increase of the communication distance is lesser than or equal to the corresponding x value. Figure 4.12(b) is similar but weights are taken into account. The vertices corresponding to home agents are selected according to their betweenness centrality: as previously discussed, such locations perform better than the ones selected using the degree. The case of one home agent is not represented because it is equivalent to Mobile IPv6 and the communication distances are equal in this case. In Figures 4.11(a) and 4.11(b), when the number of home agents increases, the dierence between the two communication patterns becomes less important. In the WIDE graph, when ve home agents are used, 97% of communications distances are equal. 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 consider a 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 modied by less than 60%: the MN-MN communication distance is only 1.6 times longer than the
80
4.4. Evaluation
100 90 % of pairs of vertices 80 70 60 50 40 30 20 0 1 HA 2 HA 5 HA 10 HA 20 HA 100 200 300 400 500 600 700 800 % added to paths lengths % of pairs of vertices
100 90 80 70 60 50 40 30 20 0 50 100 1 HA 2 HA 5 HA 10 HA 50 HA 500 HA 1000 HA 2000 HA 150 200
(a) WIDE
(b) V6-MAP
Figure 4.13: Home Agent Migration: increasing the number of home agents (unweighted) 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 dierence between the two communication patterns. Though two vertices with high betweenness centrality are relevant locations for home agents individually, in practice, they can be far from each other. When they are used in conjunction, many communication paths must go through these two vertices inducing high communication distances. Yet, when only ve home agents are used 92% of communication distances are only modied by 30% or less. Finally, even though the dierence between communication distances from a mobile node to a correspondent node and from a mobile node to a mobile node (or, equivalently from a correspondent node to a mobile node) can be important in some cases, in practice it is quite small. In the following discussions, we will therefore only consider communications between two mobile nodes. We now evaluate the impact of the number of home agents on communication distances. We select home agents by decreasing betweenness centrality: when a single home agent is considered, it is placed on the vertex with the highest betweenness centrality, when two home agents are considered, they are placed on the two vertices with the highest betweenness centrality, and so on. We only consider the betweenness centrality from the time being, because as seen in the previous section, it globally is the best strategy for home agent placement. We will present a comparison with the degree at the end of this section.
81
100 90 % of pairs of vertices 80 70 60 50 40 30 20 0 1 HA 2 HA 5 HA 10 HA 20 HA 30 HA 100 200 300 400 500 600 700 800 % added to paths lengths % of pairs of vertices
100 98 96 94 92 90 88 86 0 1 HA 2 HA 5 HA 10 HA 20 HA 30 HA 100 200 300 400 500 600 700 800 % added to paths lengths
(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 modication of communication distances when the number of home agents is increased for the WIDE, GEANT and V6-MAP graphs. The xaxis represents the increase of communication distances compared to direct distances in percents. The y-axis represents the number of pairs of vertices in the graph for which the increase of the communication path length is lesser than or equal to the corresponding x value. Figure 4.14(b) is similar but weights are taken into account. From these gures, it is clear that increasing the number of home agents increases the number of shortest paths controlled by the Home Agent Migration infrastructure. As a consequence, less communication distances are modied when more home agents are added to the system. However, in the case of the V6-MAP graph (Figure 4.13) with less than ve home agents, Home Agent Migration is less ecient than Mobile IPv6 (one home agent). This is linked to the fact that, as already explained, communications between 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 home agents are far from each other, their impact on communication distances is also more important. We now compare the number of home agents according to the degree or the betweenness centrality. We only consider communications between mobile nodes. Figures 4.15 and 4.16 show the percentage of the communication distances modied by 10% or less with a given number of home agent for the WIDE, GEANT and V6-MAP graphs. The x-axis represents the number of home agents used. Figure 4.16(b) is similar but weights are taken into account. For any number x of home agents, we will compare the results
82
4.4. Evaluation
100 90 80 70 60 50 5 10 betweenness degree 15 20 25
60
55
50
45 betweenness degree 5 10 15 20 25 30 35 40 45 50 Number of home agents
40
Number of home agents
(a) WIDE
(b) V6-MAP
Figure 4.15: Home Agent Migration: comparison of degree and betweenness centrality (unweighted) CDF of communication distances modied by 10% or less, when the corresponding number of home agents is used (higher is better).
100 90 % of pairs of vertices % of pairs of vertices betweenness degree 10 20 30 40 50 60 80 70 60 50 40 30
100
95
90
85 betweenness degree 10 20 30 40 50 60
80
(b) GEANT weighted
Figure 4.16: Home Agent Migration: comparison of degree and betweenness centrality (GEANT) CDF of communication distances modied by 10% or less, when the corresponding number of home agents is used (higher is better).
83
obtained when placing them in the x vertices with the highest degree or betweenness centrality. Except for the WIDE and V6-MAP graphs, when home agents are selected using the betweenness centrality, the communication distances are less modied than when the degree is used. Using the betweenness centrality is even more signicant when considering weights for the GEANT graph (Figure 4.16(b)): with ten home agents, 95% of the communication distances are modied by less than 10%. The corresponding percentage when the degree is used is 93%. When the number of home agents is low, we observe a strange behavior in two cases. In Figure 4.16(a), when considering the degree, when three home agents are used instead of two, the performance are less good. We observe a similar behavior with the V6-MAP graph, see Figure 4.15(b). This is an important result that shows that care should be taken when deploying Home Agent Migration. In fact, while this mobility architecture is designed to improve the performances of the Mobile IPv6 protocol, it could lead to longer communication distances if home agents locations are not correctly selected.
4.5
Related work
Finding the judicious locations of servers instances is a topic that has already been addressed in dierent networking elds ranging from Content Delivery Networks to Internet mapping architectures. The common concept is to distribute multiple instances of the service in the network topology in order to maximize a quality function. Depending on the context, such a function aims at minimizing the distances between the multiple instances and end-nodes, maximizing end-nodes bandwidth and users experience, reducing the number of retransmitted packets, or using high quality paths. Content Delivery Networks deliver media content to end-users by transparently distributing duplicated mirrors in the Internet architecture. Here, the quality function intends to optimize the placement based on network metrics. Indeed, a common strategy is to identify relevant mirror locations based on the estimated path lengths to end-nodes [64]. Other works [96, 38] use more metrics in the quality function such as client bandwidth, request rates, or path quality, and show that, when possible, taking network metrics into account improves the accuracy of the placement strategy. Concerning Internet mapping using traceroute like approaches, performing measurements from multiple locations allows to discover more routers and links, and as a result improve the overall quality of the mapping [76]. In this case, the quality function
84
4.5. Related work
aims at nding monitor locations, as well as destinations to probe, that maximize the number of discovered routers and links. To some extent, this problematic is similar to the ecient placement of home agents in which we want to control a maximum number of shortest paths. Several strategies based on random selection, or vertices degrees sorted by increasing and decreasing degree can be used to place the traceroute monitors in the Internet topology [54]. However, this work indicates that the most ecient solution is to select servers and locations by increasing vertices degrees similarly to what was done in this chapter. Distributed server instances is nowadays a key element of the Internet infrastructure that is used commercially to put the media content closer to the users [1], or sharing network load among the instances. One of the closest approaches to ours comes from the root DNS server deployments using anycast routing. Its eciency in performing load balancing among the multiple instances was the key feature that drastically mitigated the Distributed Denial of Service attack against the DNS root servers in February 2007. Similarly, studies [62, 34] showed that anycast routing is an eective solution to decrease the latency of replies. This is an important practical result that strengthens the conjoint use of the Home Agent Migration architecture and our placement proposal. While placement strategies of servers instances is a well studied topic both in research and industrial elds, little has been done, strictly speaking, regarding the Mobile IPv6 protocol and the placement of home agents in network topologies. As previously described in Section 2.4.1, Hierarchical Mobile IPv6 [29, 100] describes an enhanced Mobile IPv6 architecture that locates home agents closer to mobile nodes, as well as on the path to end-nodes. This proposal does not specically describe how to locate the home agents but provides good performances and keeps the network load low as the networks size and the number of home agents increases. The inuence of home agents locations on performances had been specically studied in Universal Mobile Telecommunications System (UMTS) [98]. Using a network simulator, the author evaluated dierent home agents locations given a single UMTS architecture. The results clearly outline that concerning data transmission, there is a direct relation between the home agent location and the performances: the closer the home agents are to mobile nodes, the higher the eective bandwidth is. While this paper uses an approach dierent from our proposal, its outcome is complementary and indicates that placing home agents based on their degree or betweenness centrality is not only improving the paths lengths in theory but will also deliver enhanced performances in practice.
85
4.6
Conclusion
In this Chapter, we formally describe the Mobile IPv6 and Home Agent Migration protocols using graph metrics in order to quantify their impacts on communication distances. We proposed and evaluated two placement strategies that use the vertices degree and their betweenness centrality to identify home agents locations. Our proposal has the advantage of providing an accurate description of genuine operational issues raised by these two mobility architectures. Concerning the Mobile IPv6 protocol, we described the dogleg routing in terms of distances, and conrmed that all home agent locations do not provide equivalent performances. 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 that even using a small number of home agents can drastically decrease communication distances. We propose two solutions to nding good locations that use the degree and the betweenness centrality. Selecting the best location for a given number of home agents being NP-hard, we showed that they allow to eciently nd home agent locations that provide good overall performances. However, we identied several issues in the placement strategies that are linked to the underlying graph topology. In some specic cases, vertices with a high betweenness centrality deliver inferior performances than vertices with a lower betweenness centrality. In our future work, we would like to evaluate how other centrality measures, such as the closeness or the eigenvector centrality, allow nding ecient home agent locations. It might also be possible to modify the denition of the betweenness centrality in order to precisely reect the required properties of home agent locations. We believe that taking into account network metrics such as the Round Trip Time between routers, by using them as edges weights, is an important follow-up work. It will not only provide more accurate results, but will also ease their interpretation for real deployments. Likewise, the knowledge of mobile nodes locations would surely improve the outcome of our placement strategies. This will allow focusing only on communication paths that are specically used by mobile nodes. Trac matrices, such as available for the GEANT graph, could also help locating which routers gather most of the trac, and which communication paths must be improved in priority.
Chapter
Conclusion
Nowadays, mobility is clearly an important research and commercial issue, as well as one of the main features for upcoming Internet technologies. We expect that this trend will also evolve with the deployment of mobility services such as Fourth Generation cell phones, vehicle communications (Intelligent Transport System, ITS), and Personal Area Networks (PAN). The number of smart phones is increasing every day, and is quickly changing usages and the way people access the Internet. For example, in less than a year, the iPhone drastically changed Internet usages habits: 85% of iPhone users 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 to anticipate future trends in network protocols and architectures. Most of the current state of the art proposals aiming to provide mobility fail in designing architectures that can be realistically deployed on the Internet. They require either heavy structural changes to the network or to end-nodes or, do not propose incremental updates to present networking protocols and architectures. In contrast, we choose to focus on immediate deployments of mobility systems based on Mobile IPv6 given the fact that Standard Development Organizations such as the WiMAX Forum or 3GPP are currently supporting this protocol. Our dominant motivation was to enhance the Mobile IPv6 protocol so as to improve its performances while remaining transparent to network architectures as well as transport layers and applications. Our work is not only compatible with the protocol specication itself but also with its operations. Any Mobile IPv6 implementation can benet from our proposals without any change. As a consequence, our proposals make it possible to deploy a transitional mobility architecture that does not require modication to the existing Internet architecture.
88 This thesis provides an enhanced mobility support architecture, built upon the existing Mobile IPv6s exibility, that could either be deployed in a single operator network, or in the whole Internet topology. This advanced architecture is achieved through two distinct works that can separately be used to solve performance limitations of Mobile IPv6. At rst, we introduced an improved mobility support architecture, called Home Agent Migration, that aims to distribute home agents in network topologies. Using anycast routing and ecient placements of home agents, communication paths between mobile and correspondent nodes can be controlled to suppress the drawbacks of the dogleg routing. We not only described how Home Agent Migration works, but also experimentally validated it in the WIDE projects network. In most cases, we were able to improve communications delays between mobile nodes and their correspondents, and obtained delays close to optimal as if no mobility support was used. We also studied the Mobile IPv6 protocol from a graph theory perspective and showed that home agents locations matter. Moreover, we quantied the inuence of the dogleg routing on communications performances. By modeling operators networks as graphs, we were able to precisely compare home agents locations and show that they are not equal from a performance point of view. Indeed, we conrmed that nodes with a high betweenness centrality are the best candidates to become home agents. We proposed a new algorithm that can identify good home agents locations in any operators networks. It could either be applied to Home Agent Migration or Mobile IPv6. This graph based study showed that Home Agent Migration is an improvement comparing to regular Mobile IPv6 deployments, and complements the experimental evaluations that we made. The work presented in this thesis brings several research and engineering directions that would certainly improve the current Home Agent Migration architecture. They are of primary importance to achieve commercial deployments of Home Agent Migration based mobility support. In the current proposal, the information contained in the Binding Cache is distributed based on a simple full-mesh approach. While this solution was adequate to evaluate the Home Agent Migration architecture, it is far from being appropriate to achieve ecient deployments. Better distribution mechanisms must be investigated to eciently disseminate the Binding Cache in order to maximize the hit/miss ratio while minimizing the size of the local Binding Caches. One could for example consider Distributed Hash Tables (DHT) as a possible solution to eciently 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 a Home Agent Migration architecture distributed all over the globe, binding information of Japanese users moving only in the Tokyo area should not be distributed to other home agents if their data trac is mainly local. Home Agent Migration improves the overall scalability and availability of Mobile IPv6, however it remains threaten by the stability of the underlying routing protocols used to advert the home prex. Due to the use of the anycast routing, if a router that connects a home agent fails, mobile nodes bound to this home agent cannot communicate with their correspondents until the underlying routing protocol converges. Elementary solutions could rely on redundant routers architectures as well as multihomed 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 Migration architecture. Eventually, this will allow anticipating failures and design new solutions to minimize their consequences. In order to thoroughly validate the Home Agent Migration architecture, we need to perform an Internet-scale deployment by distributing home agents and advertising a home prex from several locations around the globe. This will allow the comparison of results with the Autonomous System-scale deployment conducted during the evaluation of Home Agent Migration. Moreover, by monitoring routers and not only mobile nodes and home agents, such deployment could also help to gather data about anycast routing and help identifying routing failures. In order to acquire rich data from various geographical locations, mobile nodes could be deployed in Planetlab [10] using Scapy6. In the current Home Agent Migration architecture, the communications between the distributed home agents are the only ones that are protected by IPsec. Since communications between home agents and mobile nodes are valuable targets for a malicious attacker, it is essential to conduct interoperability tests when Home Agent Migration and IPsec are used conjointly. Based on our expertise of Mobile IPv6 and IPsec, we believe that it should work with close to zero modication to their respective implementations. However, the use of IPsec to protect the communications could lead to reduced performances, and longer handover durations. Finally, concerning security at large, the integration of Home Agent Migration and AAA1 architectures must also be considered prior to starting commercial deployments. If we consider Home Agent Migration with several Mobile Service Providers, this will allow roaming agreements and ease movements of users in the resulting global mobility system.
1
Authentication, Authorization and Accounting.
90 Concerning mobility at large, the results presented in this thesis suggest that works aiming at the characterization of users mobility are of primary importance to the eld. Not only Home Agent Migration and its dissemination system will benet from such works, but they will likely improve our understanding of mobility needs and anticipate trends in future networking protocols and technologies. We propose two research perspectives related to the study of users mobility that we want to use to improve current Delay Tolerant Networks (DTN) approaches. So far, most studies of users mobility are based on the analysis of 802.11 traces acquired on universities campuses, or similar nite areas [4]. As a result, users can only move in rather restricted geographical spaces, and connect to a limited number of Wi-Fi access points. Moreover, if users do not keep their devices running while moving between two dierent access points, it is not possible to obtain a precise estimate of their movements patterns. So as to address these problems and gather information on a wider scale, we believe that it is necessary to set up experiments that will focus on capturing continuous users movements. To do so, electronic landscapes available in urban areas are particularly interesting. During the course of this thesis, preliminary experiments based on surrounding Wi-Fi access points [55] showed that studying users mobility could be done using regular smartphones. Concerning Home Agent Migration, the study of user mobility could for example help to nd out spots with high user-concentration and consequently enhance the identication of home agents locations. Movements of users in the Wi-Fi landscape could also be used to enhance Wi- 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 geographical coordinates to Wi-Fi access points is an expensive and time consuming task. We think that users mobility can be eciently used to perform these associations on the go even though their devices are not embedded with GPS receivers. For example, starting 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. As a result, users mobility will be used to spread the geographical coordinates to Wi-Fi access points that were not known at the beginning of the experiment. Although the outcomes of this thesis improve the performances of the Mobile IPv6 protocol, there is still some work to complete in order to achieve smooth handovers between dierent network access technologies under strict architectural and security constraints. 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 networkbased systems that will support mobility more eciently that could be done today. As a matter of fact, it will become necessary and intrinsically fundamental to provides and verify identiers proofs of ownership. Mobility management protocols such as Mobile IPv6 make it dicult to identify the real physical location of a mobile device thanks to the permanent identier. However, this permanent identier also raises questions concerning privacy, as it is a simple method to trace users on the Internet. As a consequence, we think that protecting users privacy while providing secured mobility system will undoubtedly be one of the key topics of upcoming mobility researches.
Appendix
Scapy: IPv6 and BPF extensions

Contents
A.1 Contributed extensions . . . . . . . . . . . . . . . . . . . . . . A.1.1 Scapy6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.2 BPF extension . . . . . . . . . . . . . . . . . . . . . . . . . . 95 95 98
A.2 Routing Header Type 0 . . . . . . . . . . . . . . . . . . . . . . 101 A.2.1 In a nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 A.2.2 Advanced traceroutes . . . . . . . . . . . . . . . . . . . . . . 102 A.2.3 Amplication attacks . . . . . . . . . . . . . . . . . . . . . . 104
94 Developed by Philippe Biondi1 , Scapy [26] is a powerful tool that ease the manipulation of network frames and packets. Written entirely in the Python programming language, Scapy is a script, named scapy.py, that can similarly be used as a standalone software, or as a Python module to build well-known networking tools such as a port scanner, traceroute, or packets snier. Unlike common libraries and tools specically designed for a unique purpose, Scapy only matches sent packets to replies and do not try to interpret these replies on behalf of users. Indeed, it allows users to easily describe elds contained in a packet as a Python object. The following example provides the description of the UDP header that can directly be used to inject or read UDP packets: only elds types and their default values need to be specied; the checksum computation 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 as well as an ARP cache to decide which interface is used to send a frame, and which source addresses (IP and MAC) must be used. Scapy provides support for various network protocols ranging from layer 2 (Ethernet, 802.1q, Bluetooth, or 802.11) to layer 4 (DNS, SNMP, NTP or RIP). More details about Scapy and its usages are available on the project web page: http://www.secdev.org/projects/scapy/. During the course of this thesis, Scapy was heavily used as an experimental and diagnostic tool. More specically, it seriously simplied the setup, and measurements conducted during the deployment of the Home Agent Migration experiment. This appendix rst describes two extensions that were specically written for this thesis: the IPv6 and the BPF extension. Then, we present security issues related to the Routing Header Type 0 that were discovered while working on the IPv6 extension. While not exactly related to this thesis, this last section is however an important contribution as it led to the deprecation of the Routing Header Type 0 in the RFC 5095 [18].
1
from EADS Innovation Works.
Appendix A. Scapy: IPv6 and BPF extensions
95
A.1
A.1.1
Contributed extensions
Scapy6
Developed in collaboration with Arnaud Ebalard2 , Scapy6 provides support for the IPv6 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 other networking 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 Scapy source code; as a consequence, it was somehow cumbersome to use. Later on, it was redesigned as a standalone Python module to facilitate both software developments. Scapy6 actually supports Linux and most of BSD avors 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-known networking companies that use it to evaluate their IPv6 related developments, and equipments. Scapy6 source code as well as lengthy usage examples can be retrieved on the extension web page: http://namabiiru.hongo.wide.ad.jp/scapy6/. The current development version is available separately at http://hg.natisbad.org/scapy6/. Support can be obtained on the regular Scapy mailing list. Examples Here, we present some functionalities of Scapy6, and describe typical packets that can be injected to the network. Scapy6 adopts a naming convention for packets that ease their usage with automatic names completion: ICMPv6 messages starts with ICMPv6, Neighbor Discovery ones start with ICMPv6ND, and IPv6 extensions starts with IPv6Ext. In Scapy, packets headers can be stacked with the / operator such as IPv6()/UDP() represents an IPv6 packet encapsulating an UDP message. The sr1() function, used in the following examples, sends a packet provided as an argument, and returns the corresponding reply3 . >>> represents Scapys interactive prompt. 1. Sending and receiving ICMPv6 Echo messages In the following example, a simple IPv6 packet encapsulating an ICMPv6 Echo Request message is constructed in line 1 and sent in line 2. The destination address is the only parameter to be specied, Scapy6 will internally choose the
2 3
from EADS Innovation Works. similarly, the srp1() sends a frame and returns the received reply.
96
A.1. Contributed extensions source address, compute the checksum, and set other necessary elds. Finally, the reply is displayed from lines 4 to 7.
1 2 3 4 5 6 7 >>> pkt = IPv6 ( dst = www . netbsd . org )/ IC MPv6Ec hoRequ est () >>> reply = sr1 ( pkt ) >>> reply < IPv6 version =6 L tc =0 L fl =0 L plen =8 nh = ICMPv6 hlim =59 src =2001:4 f8 :4:7:2 e0 :81 ff : fe52 :9 a6b dst =2001:200:0:1 cd1 :211:43 ff : fecd :3 b1c | < ICMPv6EchoReply type = Echo Reply code =0 cksum =0 x7d4e id =0 x0 seq =0 x0 | > >
2. IPv6 extensions Here, we provide two simple examples of some of the IPv6 extensions that can be constructed and injected using Scapy6: the Fragment (lines 1 to 2) and the Hop-by-Hop extensions (lines 4 to 7). In complement to the / operator, the / = operator allows to stack packet headers on top of previously dened packets. Later in Section A.2, we will describe how to manipulate Routing Headers.
1 2 3 4 5 6 7 >>> pkt1 = IPv6 ()/ I Pv 6E xt Hd rF ra gm en t ( nh = TCP , offset =0) >>> pkt1 /= aaaa >>> >>> >>> >>> jlen pkt2 pkt2 pkt2 = 20000 = IPv6 () /= I Pv 6E xt Hd rH op By Ho p ( options =[ Jumbo ( jumboplen = jlen ]) /= IC MPv6Ec hoRequ est ()
3. Neighbor Discovery In this example, we forge a Neighbor Solicitation packet to nd out the MAC address that belongs to the host 2001:200:0:1cd1::1. On lines 1 and 2, the packet is prepared by providing the targeted IPv6 address and the MAC address of the node sending this message4 . Again, Scapy6 will internally choose relevant IPv6 addresses. In line 4, we use a syntax shortcut that allows to directly access the replys eld that contains the MAC address of 2001:200:0:1cd1::1.
1 2 3 4 5 >>> pkt = IPv6 ()/ ICMPv6ND_NS ( tgt = 2001:200:0:1 cd1 ::1 ) >>> pkt /= I C M P v 6 N D O p t S r c L L A d d r ( lladdr = get_if_hwaddr ( eth0 ))) >>> reply = sr1 ( pkt ) >>> reply . lladdr 00:0 c : db : e0 :15:00
4. Router discovery and address auto-conguration

4
the get if hwaddr() returns the MAC address corresponding to a network interface.
97
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 will automatically set all other elds present in the packet. In line 6, we display the IPv6 prex contained in the reply. In practice, this prex is used by an IPv6 node to perform addresses auto-conguration.
1 2 3 4 5 6 7 >>> reply = sr1 ( IPv6 ()/ ICMPv6ND_RS ()) Begin emission : . Finished to send 1 packets . ................................................* Received 50 packets , got 1 answers , remaining 0 packets >>> reply . prefix 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 analyzes the reply (lines 10 and 11), and displays information contained in the Binding Acknowledgement message (lines 12 to 14) if the home agent accepted it or why it was rejected. In C, a similar piece of code would be around 100 lines long.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 from scapy6 import * coa = 2001: db8 : dead :: beef p = IPv6 ( dst = coa ) p /= IPv6E xtHdrD estOpt ( options =[ HAO ( hoa = 2001: db8 :: cafe )]) p /= MIP6MH_BU ( options =[ MIP6OptAltCoA ( acoa = coa )]) r = sr1 ( p ) if isinstance (r , IPv6 ) and MIP6MH_BA in r \ and r [ MIP6MH_BA ]. status == 0: print Binding ACK receved else : print BU rejected %s % r . status
6. Node Information Query The Node Information Query protocol was designed to query an IPv6 node about its network information such as its hostname or its IPv4 address. This protocol is currently implemented in most BSD avors5 and Linux 2.6 kernels. In the following example, we rst retrieve the hostname associated to the host
5
including Mac OS X.
98
A.1. Contributed extensions 2001:200:0:1cd1::23 (lines 1 to 14): taopaipai. Then, lines 16 to 29, using this name as a parameter in the Node Information Query, line 17, we obtain its IPv4 address: 203.178.135.23.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
>>> p = IPv6 ( dst = 2001:200:0:1 cd1 ::23 ) >>> p /= IC MPv6NI QueryN ame ( data = 2001:200:0:1 cd1 ::23 ) >>> r = sr1 ( p ) Begin emission : .............. Finished to send 1 packets . * >>> r Received 15 packets , got 1 answers , remaining 0 packets < IPv6 version =6 L tc =0 L fl =0 L plen =32 nh = ICMPv6 hlim =64 src =2001:200:0:1 cd1 ::23 dst =2001:200:0:1 cd1 :211:43 ff : fecd :3 b1c | < ICMPv 6NIRep lyName type = ICMP Node Information Response code = Successful Reply cksum =0 xd11 qtype = Node Name unused =0 L flags = nonce = \ x183 \ x81 *\ xe6 \ xb7B \ x9c data =[ (0 , taopaipai ) ] | > > >>> p = IPv6 ( dst = 2001:200:0:1 cd1 ::23 ) >>> p /= IC MPv6NI QueryI Pv4 ( data = taopaipai ) >>> r = sr1 ( p ) Begin emission : ... Finished to send 1 packets . * >>> r Received 4 packets , got 1 answers , remaining 0 packets < IPv6 version =6 L tc =0 L fl =0 L plen =24 nh = ICMPv6 hlim =64 src =2001:200:0:1 cd1 ::23 dst =2001:200:0:1 cd1 :211:43 ff : fecd :3 b1c | < ICMPv 6NIRep lyIPv4 type = ICMP Node Information Response code = Successful Reply cksum =0 xe727 qtype = IPv4 Address unused =0 L flags = nonce = p8 \ xf9 \ xd8 .\ x90 \ xa3S data =[ (0 , 203.178.135.23) ] | > >
A.1.2
BPF extension
Initially developed for Linux, Scapy only supports packets injection and reception using AF PACKET sockets. As these kind of sockets are only available on Linux, *BSD operating systems are not natively supported. On these systems, the py-dnet and pypcap Python modules must be installed along with the scapy.py script. The py-net module provides a programming interface around the libdnet library [101]: a portable and simple library designed to manipulate and inject frames and packets. Likewise, the py-pcap module allows the reception of network frames from Python using the libpcap library6 [14]. The installation of these Python modules in addition to scapy.py is
6
standard packets capture library developed along with the famous tcpdump tool.
99
somehow inconvenient, and might not be possible under strict system administration constraints. Indeed, during the Home Agent Migration evaluation, we were not allowed to install these modules on some nodes. In this context, the BPF extension was developed to suppress dependencies on the Python modules, in order to make Scapy and Scapy6 work natively on *BSD. At the time of writing, the BPF extension is not yet integrated into Scapy, and is available as a separate patch to Scapys latest version. The source code can be retrieved from a separate development repository: http://hg.natisbad.org/scapy-bpf/. This extension was thoroughly tested on: OpenBSD 4.2, NetBSD 4.0, FreeBSD from 5.4 to 7.0 as well as Mac OS X from 10.4 to 10.5. The following example displays scapy.py running natively on Mac OS X 10.4.11, sending a TCP segment, and displaying some elds of the reply.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # python scapy . py WARNING : did not find pcap module . WARNING : did not find dnet INFO : Fallback to native BPF primitives . Welcome to Scapy (1.2.0.2) >>> sys . platform darwin >>> reply = sr1 ( IP ( dst = www . free . fr )/ TCP ()) Begin emission : .. Finished to send 1 packets . .* Received 4 packets , got 1 answers , remaining 0 packets >>> reply . src 212.27.48.10 >>> reply . ttl 55 >>> reply . flags 2L
In a nutshell, Berkeley Packet Filter (BPF) [78] is a mechanism available on BSD based kernels that provides a convenient userland interface to data link layers and allows link layer frames to be injected and received. Moreover, depending on the devices drivers, it authorizes to alter the source MAC address7 and to receive all frames that ows on the wire. The BPF extension brings native BSD support to Scapy. From an implementation point of view, this extension adds two fundamental contributions along with sparse non-critical modications to the conventional Scapy. First, all functions that deal with the manipulation of network interfaces8 were ported to BSD: they do not anymore rely
7 8
this is often referred as MAC address spoong. like getting the list of valid interfaces, or the MAC address of a given interface.
100
A.1. Contributed extensions
on external libraries, or operating system dependent tools. Next, new Super Sockets using BPF natively were added. In Scapy, Super Sockets are high-level Python objects that provide programming interfaces to inject and receive frames and packets. Internally, Scapy only manipulates Super Sockets, and as a consequence they provide an abstraction to the underlying methods used to access the networking devices such as AF PACKET sockets or BPF. So as to evaluate how the BPF extension competes with the py-dnet module, we implemented two dierent 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. The experiment was conducted on Mac OS 10.4.11; the four tests were run one hundred times each on a 100 Mbps full duplex link. Even after these hundred runs, there is no signicant dierence between the libdnet and the BPF tests. Both achieve similar performances; however libdnet based tests tend to be slightly faster. This is caused by the overhead of the Python interpreter and can be easily understood as follows: when using the py-dnet module, we exit the Python interpreter earlier; as a consequence, the corresponding C functions and system calls are called faster than if we remain in the Python interpreter. Concerning the reception of frames, the BPF extension must cope with one important BPF specicity: when the read() function is called on a BPF descriptor to receive frames from the network interface, several frames could be retrieved at once in the returned buer. In practice, this improves frames reception performances, for example several small ARP messages can be retrieved with a single call to read(). As Scapy processes received frames one by one, the BPF extension needs to manage an internal buer of received frames while polling the BPF descriptor consistently. Tests that we conducted on the current implementation showed that it works ne but could perform a little bit worst than the py-pcap module under particular network conditions. We are actually investigating other mechanisms to receive frames in order to make sniing faster. Nevertheless, in the current implementation, the reception speed can be eciently improved using BPF lters10 to select which frames must be handed to the userland process. These lters can for example be used to discard an heavy UDP load on the network, and only receive TCP segments sent from a given host.
9 10
on *BSD, libdnet is simply a high level interface to BPF. commonly used with tcpdump to lter out network trac.
101
src: 2001:7a:78d::1 dst: 2001:7a:78d::11 segment left: 2 addr[1] 2001:7a:78d::21 addr[2] 2001:7a:78d::31
2001:7a:78d::1 packet source
2001:7a:78d::11 specified router
2001:7a:78d::21 non-specified router
2001:7a:78d::31
packet final destination
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 Routing option in IPv4: it allows a node that sends a packet to specify a list of routers that must be crossed prior to being delivered to the destination. During the implementation of the Routing Header extension in Scapy6, we discovered that it represents a serious security threat as it allows to bypass rewall ltering rules, permits ecient amplication attacks, and is often badly implemented [3]. Later on, after a talk at CanSecWest by Arnaud Ebalard and Philippe Biondi [27], these discoveries led to vigorous discussions at the IETF and to the deprecation of the Routing Header Type 0 [18]. Note that the Mobile IPv6 RFC species a Routing Header Type 2 [66] that is used to carry home addresses in Binding Acknowledgement messages sent to mobile nodes. While semantically similar, the Routing Header Type 2 is not targeted by the problems that conducted to the revocation of Type 011 . In this section, we rst describe how the Routing Header extension works. Then we present 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 to its revocation: amplication attacks.
A.2.1
In a nutshell
Figure A.1 illustrates how Routing Header Type 0 extensions are built and processed from a source (2001:7a:78d::1) to a destination (2001:7a:78d::31). In spite of the natural path, we want to specify two routers as waypoints: 2001:7a:78d::11 and 2001:7a:78d::21.
11
however 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 eld. As a result, these specied routers are required to process the Routing Header Type 0. Unspecied routers only need to route packets as they would with any other regular packets. For the sake of clarity, we only represented relevant headers elds in the Figure. From top to bottom, we have the IPv6 source address, the IPv6 destination address, the RH0 segment left eld, and nally a list of waypoints. We assume that the 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 packets source address, and sets the destination as the rst waypoint to cross. Then, it sets the segment left eld to 2: meaning that there are two remaining addresses in the waypoints list. Finally, its puts the second waypoint and the nal destination in the waypoint list. This packet is then sent to the network and reaches the rst waypoint (2001:7a:78d::11). Because this router is the current destination of the packet, it must process network layers 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 eld and the rst entry in the waypoint list. Then, it decrements the segment left value. The packet is now sent to the second waypoint 2001:7a:78d::21. The second waypoint receives this packet, and processes it as the rst waypoint did. The nal destination 2001:7a:78d::31 receives this packet and rst checks the value of the segment left eld. It is equal to zero: there is no more waypoint to process. The destination then processes the encapsulated ICMPv6 Echo Request, and as a result sends 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 traceroutes that we called indirect and boomerang traceroutes. Indirect traceroute is taking advantage of the Routing Header Type 0 to specify routers that must be crossed prior to reach the destination. Figure A.2(a) shows the dierence between the natural path and the forced path that goes to the waypoint. Indirect traceroute is especially interesting in the context of Internet mapping as it allows a node to probe more paths than it will usually do with the classical traceroute. Such traceroute can easily be performed with Scapy6 such as shown in Figure A.3. In this example, we send an ICMPv6 Echo Request message towards 2001:319:2000:3002::21 using 2001:301:0:8002:203:47:fea5:3085 as 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,
103
Source
IPv6 router Natural path Forced path (using RH0)
Source
IPv6 router Source to waypoint Waypoint to Source
Waypoint
Target
Waypoint
(a) Indirect traceroute
(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 to 8). On line 9, the message is received by the waypoint, and then forwarded towards the real destination (lines 10 to 15). Boomerang traceroute is similar to indirect traceroute but aims to detect both egress and ingress interfaces of routers between the node and the waypoint: the node is at the same time the source and the destination of the packet. Figure A.2(b) illustrates a boomerang 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 addresses will be ideally discovered for each router on the path. We used this kind of traceroute to detected asymmetric routing paths during the Home Agent Migration experiment. Concerning Internet mapping, it could be used to gather dierent addresses of the same router in order to perform addresses aggregation and as a result achieve a more precise network mapping.
104
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
A.2. Routing Header Type 0
>>> waypoint = " 2 0 0 1 : 3 0 1 : 0 : 8 0 0 2 : 2 0 3 : 4 7 ff : fea5 :3085" >>> tgt = " 2 0 0 1 : 3 1 9 : 2 0 0 0 : 3 0 0 2 : : 2 1 " >>> traceroute6 ( waypoint , minttl =15 , maxttl =24 , \ l4 = I P v 6 O p t i o n H e a d e r R o u t i n g ( addresses =[ tgt ])/ IC MPv6Ec hoRequ est ()) 2 0 0 1 : 3 0 1 : 0 : 8 0 0 2 : 2 0 3 : 4 7 ff : fea5 :3085 : IER 15 2 0 0 1 : 3 1 9 : 2 0 0 0 : 5 0 0 0 : : 9 2 3 16 2001:301:0:1 c04 :230:13 ff : feae :5 b 3 17 2 0 0 1 : 3 0 1 : 0 : 4 8 0 0 : : 7 8 0 0 : 1 3 18 2 0 0 1 : 3 0 1 : 0 : 8 0 0 2 : 2 0 3 : 4 7 ff : fea5 :3085 3 19 2 0 0 1 : 3 0 1 : 0 : 2 : : 6 8 0 0 : 1 3 20 2001:301:0:1 c04 :20 e :39 ff : fee3 :3400 3 21 2001:301:133::1 dec :0 3 22 2 00 1: 30 1: 90 1: 7: :1 8 3 23 2 0 0 1 : 3 0 1 : 0 : 1 8 0 0 : : 2 9 1 4 : 1 3 24 2 0 0 1 : 3 1 9 : 2 0 0 0 : 3 0 0 2 : : 2 1 3 ( < Traceroute : ICMP :0 UDP :0 TCP :0 Other :10 > , < Unanswered : ICMP :0 UDP :0 TCP :0 Other :0 >)
Figure A.3: Indirect traceroute with Scapy6
tgt R1 R2
Attacker 1
Attacker 2
Figure A.4: Routing Header Type 0 based attacks: capacitor eect
A.2.3
Amplication attacks
The Routing Header Type 0 can specify up to 86 waypoints12 that must be crossed by the encapsulated packet. This could be used by a malicious attacker to cause serious network 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 loop between two routers, hence overloading the corresponding link. In practice, we veried that, depending on network conditions, such packet could remain tens of seconds in the network. A more advanced attack could take advantage of the resulting capacitor eect.
12
assuming a standard MTU of 1500 bytes.
105
Indeed, as illustrated in Figure A.4, we can consider that packets looping between the two routers R1 and R2 are stored in the network. In this example, Attacker 1 oods the target tgt at a constant rate13 while Attacker 2 is able to store packets in the network during the round trip time between R1 and R2 and deliver all of these packets at once creating a powerful Denial of Service attack against the target.
13
limited by its upload bandwidth.
Appendix
B
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 B.1.1 Protocoles de mobilit . . . . . . . . . . . . . . . . . . . . . . 110 e B.1.2 Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Thesis French Version

Contents
B.1 Introduction
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 Aperu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 c B.3.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 118 B.3.3 Rsultats exprimentaux . . . . . . . . . . . . . . . . . . . . . 119 e e B.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 B.4 Dploiement de Mobile IPv6 e . . . . . . . . . . . . . . . . . . 122
B.4.1 Emplacements des home agents . . . . . . . . . . . . . . . . . 122 B.4.2 Mthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 e 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 rsum of this thesis, which is a requirement e e of the University Pierre et Marie Curie.
Appendix B. Thesis French Version
109
B.1
Introduction
Dans les zones urbaines, les rseaux sans l sont accessibles depuis divers endroits e comme les cafs, les parcs ou bien encore les lieux de travail. Par consquent, la densit e e e des points dacc`s Wi-Fi est telle quil est possible den dtecter des dizaines en se e e dplaant dans les rues. D`s lors, les utilisateurs de ces priphriques mobiles peuvent e c e e e en tous lieux naviguer sur Internet ou bien encore tlphoner gratuitement grce ` la ee a a voix sur IP (VoIP). Une forte densit de points dacc`s nest cependant pas strictement synonyme de e e mobilit. Ainsi, lorsquun priphrique mobile1 passe dun point dacc`s ` un autre2 , e e e e a son adresse IP change et les connexions en cours sont perdues. Par consquent, il nest e pas possible de maintenir un appel tlphonique lors dun handover entre dirents ee e points dacc`s Wi-Fi ou technologies dacc`s (comme HSDPA ou EDGE). La mobilit e e e peut ainsi tre dnie comme la capacit de se dplacer sans avoir de consquence sur e e e e e les communications en cours. Techniquement, du point de vue du protocole IP, un handover survient lors du passage dun sous-rseau ` un autre, et implique les contraintes e a suivantes qui constituent les problmatiques inhrentes aux dirents protocoles grant e e e e la mobilit. e 1. Changement dadresse IP En raison des architectures de routage et dadressage dans lInternet, une adresse IP doit correspondre ` la position physique du nud. Autrement, il ne peut a mettre et recevoir des paquets. Par consquent, un nud mobile ne peut utiliser e e la mme adresse IP partout o` il va, et doit en obtenir une nouvelle lorsquil entre e u dans un nouveau sous-rseau. e 2. Pertes de connexions Les protocoles de transport tels que TCP et UDP nont pas t conus pour ee c rsister aux changements dadresses IP. Les connexions en cours sont donc intere rompues par les mouvements du nud mobile. Les applications doivent galement e intgrer des mcanismes leur permettant de rtablir automatiquement les connexions e e e perdues. 3. Communications de bout en bout Actuellement, les communications clients/serveurs sont prdominantes et peu e dapplications utilisent les communications de bout en bout en raison des limitations techniques relatives au NAT (Network Address Translation). Les arrives e
1 2
galement appel nud mobile. e e ce passage dun rseau ` un autre est appel handover. e a e
110
B.1. Introduction rcentes de la VoIP et du protocole IPv6 se sont accompagnes du retour des e e communications de bout en bout. Celles-ci constituent un challenge technique dans le cadre des protocoles de gestion de la mobilit qui doivent tre capables e e de rsister aux changements dadresses IP ainsi qu` la perte des connexions. e a
B.1.1
Protocoles de mobilit e
Dirents protocoles [93, 91, 83, 94, 74, 100, 20] ont dores et dj` t proposs e ea ee e par lInternet Engineering Task Force (IETF) pour grer la mobilit et rsoudre les e e e probl`mes prcdemment dcrits. Bien que ces protocoles adoptent des approches et e e e e des solutions techniques direntes, ils peuvent tre classs en fonction des crit`res e e e e suivants. 1. Dploiement raliste e e An de faciliter son adoption, un protocole de mobilit ne doit pas ncessiter de e e modication sur les nuds non mobiles3 . Ceux-ci doivent galement tre capables e e de communiquer indiremment avec des nuds mobiles et des nuds xes. En e eet, en ce qui concerne lutilisation immdiate dun protocole de mobilit sur e e lInternet, il nest pas possible de modier tous les nuds an de grer la moe bilit. De plus, il est peu probable quaucun protocole de mobilit soit intgr e e e e dans les serveurs, comme ceux de Google ou de MSN, car cela conduirait ` une a augmentation des cots oprationnels sans aucun bnce pour le fournisseur du u e e e service. 2. Impact rduit sur le rseau e e Les changements concernant larchitecture du rseau doivent tre compatibles e e avec les technologies couramment utilises sur lInternet. An de raliser des e e dploiements ecaces et rapides, seules les modications incrmentales de lare e chitecture de lInternet doivent tre considres. En eet, il nest pas envisageable e ee de changer le fonctionnement des architectures de routage et dadressage actuellement utilises. e 3. Transparence vis-`-vis des protocoles de transport a Le protocole de mobilit permet aux connexions en cours de rsister aux hane e dovers sans pour autant modier les applications et les protocoles de transports classiques. En termes de couches rseaux, ce point implique que le protocole de e mobilit se trouve en dessous des couches transports. e
3
galement appels nuds xes. e e
Appendix B. Thesis French Version 4. Performances quivalentes e
111
Un protocole de mobilit ne doit pas srieusement altrer les performances, ni e e e induire une charge importante sur le rseau. De plus, il doit pouvoir passer ` e a lchelle et fournir des performances acceptables lorsque le nombre de nuds e mobile augmente. Protocoles SCTP, HIP LISP MIPv6 OLSR, AODV x x x 1 2 x x x x x 3 4 x x
Tab. B.1 Classication de dirents protocoles de mobilit e e
En fonction des dnitions prcdentes, nous proposons une classication de dirents e e e e protocoles de mobilit dans le tableau B.1. Celui-ci permet de constater facilement que e les dirents protocoles ont des champs dapplication dirents : certains requi`rent des e e e modications sur tous les nuds, ou dans le coeur du rseau. Par exemple, le protocole e OLSR (Optimize Link State Routing) [33] permet ` des nuds de communiquer dans a des environnements sans infrastructure en sadaptant automatiquement ` la mobilit a e des nuds, il impose par contre de modier tous les nuds souhaitant communiquer. Le protocole LISP reste, quant ` lui, compatible avec les nuds existants mais ncessite a e de lourdes modications de larchitecture de lInternet. Cette classication nous a conduit ` nous intresser au protocole Mobile IPv6 car a e il satisfait trois des quatre points prcdemment discuts. En eet, ce dernier reste e e e compatible avec les protocoles de transport actuels, et nentra pas de modications ne de linfrastructure rseau ni des nuds xes. Au dbut de mes recherches n 2004, e e quatre implmentations de Mobile IPv6 taient disponibles, et le protocole tait actie e e vement support par la plupart des quipementiers [13, 8, 32, 79]. Cependant, bien que e e considr comme une bonne solution intermdiaire pour fournir un service de mobilit ee e e sur Internet, et devant bientt tre dploy commercialement, le protocole Mobile IPv6 o e e e est sujet ` plusieurs probl`mes qui limitent ses performances. a e
112
B.1. Introduction Lobjet de cette th`se est par consquent de proposer des solutions permettant e e
damliorer les performances du protocole Mobile IPv6 en contrlant ses limitations e o par des approches ` la fois pratiques et thoriques. a e
B.1.2
Plan
Ce rsum comprend quatre parties. Dans la Section B.2, nous introduisons tout e e dabord le protocole Mobile IPv6 et ses limitations, an de dcrire le cadre dans lequel e sinscrivent nos contributions. Ensuite, dans la Section B.3, nous dcrivons une nouvelle e architecture distribue base sur Mobile IPv6, appele Home Agent Migration. Dans la e e e Section B.4, nous proposons des stratgies de placement des home agents sappuyant e sur la thorie des graphes. Enn, dans la Section B.5, nous concluons ce rsum en e e e synthtisant les contributions de cette th`se et en prsentant leurs perspectives dexe e e tension.
113
B.2
B.2.1
Mobile IPv6 et ses limitations

Fonctionnement de Mobile IPv6
Larchitecture de routage de lInternet impose une forte contrainte sur la position gographique dun nud. Une adresse appartenant ` un prxe IPv6 allou ` un foure a e ea nisseur dacc`s franais ne peut tre utilise pour recevoir des paquets au Japon. Par e c e e consquent, larchitecture actuelle de lInternet empche un nud de conserver son e e adresse IPv6 lorsquil change de rseau. Cette limitation est lie au double rle que e e o joue ladresse IP pour un nud : en plus de lidentier uniquement (rle didentier ), o elle fournit implicitement sa position sur le globe (rle de locator ). Le protocole Mobile o IPv6 fournit une solution pour dcoupler ces deux rles. Le nud mobile (en anglais e o Mobile Node, MN) se voit attribuer deux adresses IPv6 distinctes : la Home Address (HoA), qui joue le rle didentier et qui appartient au prxe IPv6 du rseau m`re, et o e e e la Care-of Address (CoA), le locator. An deectuer la relation entre la Home Address et la Care-of Address, Mobile IPv6 utilise un routeur spcique plac dans le rseau m`re appel home agent. Il a pour but e e e e e de fournir une Home Address appartenant au prxe du rseau m`re ` tous les nuds e e e a ` mobiles, et de retransmettre les paquets envoys ` la Home Address. A tout instant, le e a nud mobile communiquera toujours avec sa Home Address indpendamment de son e rseau daccueil. e En pratique, quand un nud mobile arrive dans un nouveau rseau daccueil, il e envoie un message Binding Update au home agent an denregistrer la relation entre sa Home Address et sa nouvelle Care-of Address. A la rception de ce paquet, le home e agent met en place un tunnel IPv6 avec le nud mobile, et ajoute cette nouvelle relation dans son Binding Cache (une table de routage spcique ` Mobile IPv6). Pour nir, e a le home agent envoie un message Binding Acknowledgment au nud mobile pour lui indiquer que la relation a bien t eectue. Un exemple dutilisation de Mobile IPv6 ee e est prsent dans la Figure B.1 ; tous les paquets envoys par et ` destination du nud e e e a mobile doivent transiter par le home agent. Les spcications de Mobile IPv6 incluent un mcanisme dit doptimisation de route e e (en anglais Return Routability Procedure, RRP) permettant dtablir une connexion e directe entre le nud mobile et ses correspondants qui ne transite pas par le home agent, comme illustr par les `ches en pointills dans la Figure B.1. Les nuds correspone e e dants sont dsormais capables de recevoir des messages Binding Update envoys par les e e
114
B.2. Mobile IPv6 et ses limitations
CN
Rseau du correspondant
Internet
Rseau mre
HA
Chemin optimis
tun
nel
MN
Rseau d'accueil
Fig. B.1 Mobile IPv6 : exemple de communication
nuds mobiles. Cependant, ce mcanisme prsente des limites, le rendant dicilement e e utilisable en pratique, qui sont prsentes dans la section suivante. e e
B.2.2
Limitations de Mobile IPv6
Le protocole Mobile IPv6 prsente un ensemble de probl`mes qui aectent ses pere e formances. Ceux-ci sont lis ` lutilisation du home agent pour eectuer la relation e a entre la Home Address et la Care-of Address. 1. Routage Triangulaire Avec Mobile IPv6, un nud mobile ne peut tre associ qu` un seul home agent. e e a Tous les paquets changs avec ses correspondants doivent tout dabord tre e e e routs ` ce home agent, puis retransmis au nud mobile dans le tunnel. Cette e a dviation des paquets via le home agent (dogleg routing en anglais) induit des e dlais de communication plus importants lorsque le nud mobile communique e avec ses correspondants. 2. Position restreinte Lemplacement du home agent est restreint par le home prex. Celui-ci doit tre plac o` ce prxe est annonc sur lInternet an de recevoir les paquets e e u e e mis ` destination des nuds mobiles. Cette forte contrainte est particuli`rement e a e
115
problmatique car il est impossible de changer de home agent sans changer de e Home Address. 3. Contrainte pour le rseau m`re e e An dintercepter les paquets envoys aux nuds mobiles, le home agent doit e rpondre aux messages de dcouverte de voisins4 envoys par le routeur dacc`s e e e e a ` la place des nuds mobiles. En pratique, le home agent se comporte comme un proxy pour la dcouverte de voisins (Proxy NDP, en anglais [87]). Ceci implique e que le nombre de messages de dcouverte de voisins traits par le home agent est e e proportionnel au nombre de nuds mobiles quil g`re. De plus, la bande passante e requise par lensemble des nuds mobiles peut tre suprieure ` celle du rseau e e a e m`re. Par consquent, un dploiement de Mobile IPv6 peut tre dicile ` mettre e e e e a en oeuvre tout en conservant la stabilit du rseau m`re. e e e Le mcanisme doptimisation de route dcrit dans les spcications de Mobile IPv6 e e e poss`de les limitations suivantes. e 1. Modication des correspondants An de communiquer directement sans passer par le home agent, tous les nuds doivent implmenter le mcanisme doptimisation de route. Cependant, il nest e e pas raliste de considrer que tous les nuds de lInternet vont tre mis ` jour e e e a pour supporter ce mcanisme. Par consquent, la plupart des nuds ne pourront e e bncier de cette optimisation de route, et la majeure partie du trac continuera e e a ` transiter par le home agent. 2. Complexit e Avant lenvoi du message Binding Update ` son correspondant, le nud mobile a doit changer quatre messages lui permettant de gnrer une cl cryptographique e e e e pour signer le Binding Update. Cette procdure doit tre eectue pour tous les e e e correspondants du nud mobile ` chaque fois que celui-ci change de sous-rseau. a e 3. Surcharge des serveurs Si lon consid`re un serveur communiquant avec des milliers de clients, le mcanisme e e doptimisation de route induit une surcharge de traitement que ce serveur doit eectuer an de servir les requtes. En eet, davantage de paquets doivent tre e e traits par le serveur pour servir la mme quantit de requtes. Il est donc peu e e e e probable que ce mcanisme doptimisation de route soit un jour implment dans e e e des serveurs car il ne reprsente pas de bnce immdiat pour les socits come e e e ee merciales les exploitant.
4
mcanisme remplaant ARP (Address Resolution Protocol) dans IPv6. e c
116
B.2. Mobile IPv6 et ses limitations
B.2.3
Conclusion
Le protocole Mobile IPv6 est compl`tement transparent pour larchitecture de e lInternet ainsi que pour les couches de transport TCP et UDP. Par consquent, il e reprsente une excellente solution de transition pour grer la mobilit sur Internet sans e e e modication des nuds xes et des applications. Cependant, ses performances sont limites par des probl`mes lis ` lemplacement du home agent. Le routage triangulaire e e e a est un probl`me particuli`rement srieux car il augmente la dure des handovers, et e e e e conduit ` des dlais de communication plus importants. En dautres termes, le protoa e cole Mobile IPv6 est aect par lemplacement du home agent. e Dans les sections suivantes, nous prsentons deux solutions visant ` rsoudre les e a e probl`mes induits par les home agents et leurs emplacements. La premi`re, appele e e e Home Agent Migration, adopte une approche pratique pour distribuer plusieurs home agents dans un rseau ` laide du routage anycast. La seconde dcrit le routage triangue a e laire en termes de thorie des graphes, et propose un algorithme permettant didentier e au sein dun rseau les emplacements les plus ecaces pour y installer des home agents. e
117
B.3
B.3.1

Aperu c
Le concept fondamental de larchitecture Home Agent Migration est de distribuer plusieurs home agents au sein dun mme rseau, et de les utiliser conjointement. Lobe e jectif de ce nouveau type de dploiement est de fournir une optimisation de route qui e (1) rduit les dlais de communication, (2) est compatible avec le protocole Mobile e e IPv6 actuel, et (3) transparent vis-`-vis des nuds correspondants, et de larchitecture a actuelle de lInternet.
noeud C
HA 2
noeud B sous-rseau Wi-Fi
HA 1
sous-rseau ADSL
rseau du FAI
HA 3
sous-rseau WiMAX noeud A
Fig. B.2 Home Agent Migration et direntes technologies dacc`s e e
Un fournisseur dacc`s ` Internet (FAI) orant une connectivit au travers de e a e direntes technologies dacc`s peut aisment tirer parti de cette architecture. Comme e e e illustr Figure B.2, cet ISP peut ainsi distribuer des home agents dans chacun des e rseaux dacc`s. Les nuds mobiles A, B, et C seront toujours associs avec le home e e e agent dploy dans leurs rseaux dacc`s respectifs. Ces home agents tant proches e e e e e des nuds mobiles, leet du routage triangulaire est ainsi limit. Par consquent, les e e nuds mobiles peuvent conserver la mme adresse IP lorsquils passent dune technoe logie dacc`s ` une autre, tout en bnciant dun mcanisme doptimisation de route e a e e e ecace.
118
B.3. Home Agent Migration
Internet a)
HA
MN
CN
b)
HA 1
HA 2
P-HA Internet
Fig. B.3 Mobile IPv6 compar ` Home Agent Migration ea
B.3.2
Fonctionnement
Avec Home Agent Migration, les dirents home agents sont dploys dans la toe e e pologie de lInternet et annoncent le mme prxe IPv6 ` laide dun protocole de e e a routage. Cette technique de routage, appele routage anycast [69], est couramment e utilise an de rpartir la charge de trac sur dirents serveurs, et pour rsoudre e e e e des probl`mes de redondance de serveurs. Pour mettre en oeuvre cette technique de e routage, les home agents peuvent utiliser nimporte quel protocole de routage, comme BGP4+ [23], OSPFv3 [35], ou bien encore RIPng [77]. Les home agents sont de plus interconnects pour former un rseau doverlay leur permettant de schanger le trac e e e de donnes des nuds mobiles ainsi que les donnes de signalisation. e e La Figure B.3 compare les architectures de Mobile IPv6 et de Home Agent Migration. Grce ` la distribution des home agents dans lInternet, un nud mobile sera a a toujours associ au home agent le plus proche : tout se passe comme si le home agent e avait migr pr`s de lemplacement du nud mobile. Ce home agent est appel home e e e agent primaire (P-HA dans la Figure 3.3(b)) car il reoit le premier message Binding c Update envoy par le nud mobile. Les paquets envoys par un correspondant sont e e tout simplement routs ` son plus proche home agent, puis envoys au home agent e a e primaire via le rseau doverlay. e
Appendix B. Thesis French Version Avantages
119
Un nud mobile sera toujours associ avec le plus proche home agent dans la e topologie du rseau. Les home agents tant distribus, les tracs de donnes et de e e e e signalisation sont ainsi rpartis sur les direntes instances : le home agent nest plus e e une limitation du point de vue des performances. En fonction des emplacements des home agents, il est galement possible doptimiser ecacement les routes et de rduire e e les dlais de communication par rapport ` Mobile IPv6. e a Les home agents tant interconnects, ils sont capables de dtecter que lun dentre e e e eux ne fonctionne plus et de ragir en consquence. Ainsi, lorsque le home agent primaire e e dun nud mobile tombe en panne, un autre home agent peut envoyer un message failure alert au nud mobile et prendre la place du home agent primaire. A la rception de ce e message dalerte, le nud mobile envoie un message Binding Update au nouveau home agent an de rtablir les communications en cours le plus rapidement possible. e Inconvnients e Larchitecture Home Agent Migration sappuie sur le routage anycast pour distribuer les home agents. Elle est donc sensible aux pannes des routeurs ainsi quau temps de convergence des protocoles de routage utiliss. Par exemple, si un routeur contrlant e o une zone gographique particuli`re tombe en panne, les nuds mobiles associs avec e e e le home agent correspondant ne peuvent plus communiquer. De mme, les correspone dants ne peuvent envoyer de donnes aux nuds mobiles. Par consquent, une grande e e attention doit tre apporte ` la gestion des routeurs annonant le prxe IPv6. e e a c e An de tirer le meilleur parti des dploiements de Home Agent Migration, les emplae cements des home agents ainsi que leur nombre doivent tre choisis de faon mticuleuse. e c e Des dploiements simples tels queectus avec Mobile IPv6 ne sont plus possibles : les e e administrateurs doivent pralablement tudier quels emplacements seront les plus ee e caces en ce qui concerne les performances.
B.3.3
Rsultats exprimentaux e e
An de conduire nos expriences, un dmon a t dvelopp ` laide de la pile IPv6 e e ee e ea de KAME [15], et de son API permettant de manipuler les paquets relatifs ` Mobile a IPv6 [103, 30]. Ce dmon est en fait une version simplie dun home agent classique e e pouvant synchroniser son Binding Cache avec dautres home agents. Les nuds mobiles utilisent quant ` eux SHISA [13], limplmentation de Mobile IPv6 pour les noyaux a e BSD, ou sont muls ` laide de Scapy6 [109]. e e a
120
San Francisco
B.3. Home Agent Migration
AS de WIDE
HA 1 HA 2
Amsterdam
Internet
Fig. B.4 Topologie reprsentant lexprience e e La Figure B.4 prsente une topologie abstraite de lexprience que nous avons e e ralise. Deux home agents ont t dploys au sein de lAS du projet WIDE, lun e e ee e e a ` Los Angeles, et lautre ` Tokyo. Chaque home agent annonce le prxe IPv6 ` laide a e a du protocole OSPFv3. Le nud mobile est plac ` San Francisco, et le correspondant ea a ` Amsterdam. Dans ce rseau, le lien trans-pacique entre les Etats-Unis et le Japon e induit des dlais de communication importants. Lobjet de cette exprience est donc e e dutiliser larchitecture Home Agent Migration an de ne pas emprunter ce lien si les correspondants ne sont pas au Japon.
0.5 0.5 0.5
0.4 RTT (secondes) RTT (secondes)
0.4 RTT (secondes) 0 5 10 15 20 25 Temps (secondes) 30 35 40
0.4
0.3
0.3
0.3
0.2
0.2
0.2
0.1
0.1
0.1
0 0 5 10 15 20 25 Temps (secondes) 30 35 40
0 0 5 10 15 20 25 Temps (secondes) 30 35 40
(a) Chemin direct
(b) Mobile IPv6
Fig. B.5 RTT entre San Francisco et Amsterdam Les rsultats de lexprience sont prsents dans la Figure B.5 qui montre le temps e e e e daller retour (RTT) des communications entre le nud mobile et son correspondant dans trois scnarios distincts ; (a) lorsquaucun protocole de mobilit nest utilis (i.e. e e e
121
chemin direct), (b) lorsque Mobile IPv6 est utilis, et (c) lorsque Home Agent Migration e est dploy. Dans le cas de Mobile IPv6, HA1 est utilis comme home agent du nud e e e mobile. Dans la Figure B.5, le nud mobile est plac ` San Francisco et le correspondant ea a ` Amsterdam. HA2 plac ` San Francisco est le home agent le plus proche du nud ea mobile : cest le home agent primaire lorsque Home Agent Migration est utilis. Par e consquent, le RTT avec Home Agent Migration est 220ms plus court que le RTT e avec Mobile IPv6, lorsque le trac passe par HA1 3.10(b). Cette dirence sexplique e par la dure du RTT du lien traversant le Pacique : 110ms. Lorsque Mobile IPv6 e est utilis, les paquets utilisent 4 fois le lien trans-pacique : 220ms sont alors ajouts e e au RTT entre le nud mobile et son correspondant. Avec Home Agent Migration, les paquets sont intercepts par HA2 situs ` San Francisco et nutilisent jamais le lien e e a trans-pacique. Larchitecture que nous proposons permet donc dutiliser Mobile IPv6 sans modication signicative du RTT.
B.3.4
Conclusion
Nous avons propos une nouvelle architecture de gestion de la mobilit appele e e e Home Agent Migration qui peut tre utilise ` lchelle de lInternet, et rsout ee e a e e cacement les limitations de Mobile IPv6. Dans notre solution, dirents home agents e sont distribus dans lInternet, et annoncent le mme prxe IPv6 ` laide du routage e e e a anycast. A tout instant, les nuds mobiles ne sont associs qu` un seul home agent : e a le plus proche topologiquement. ` A linverse des mcanismes doptimisation de route prcdemment dnis, Home e e e e Agent Migration reste totalement compatible avec larchitecture actuelle de lInternet, et les implmentations standard de Mobile IPv6. Si les home agents sont correctement e distribus, le dlai entre les home agents et les nuds mobiles peuvent tre contrls e e e oe pour rduire les eets du routage triangulaire. e
122
B.4. Dploiement de Mobile IPv6 e
B.4
Dploiement de Mobile IPv6 e
Avec Mobile IPv6, lemplacement du home agent est un aspect critique de tout dploiement car il inue sur les dlais de communication ainsi que sur la longueur e e des chemins. Dans cette section, nous dcrivons formellement Mobile IPv6 et Home e Agent Migration en termes de thorie des graphes. En outre, nous utilisons les notions e de degr et de centralit pour identier les emplacements des home agents les plus e e appropris. Cette approche est direntes des autres solutions doptimisation de route e e car elle sappuie uniquement sur un placement ecace des home agents, et de ce fait nimplique pas de modier larchitecture de lInternet et les implmentations actuelles e du protocole Mobile IPv6.
B.4.1
Emplacements des home agents
Dans cette section, nous dcrivons linuence de Mobile IPv6 et Home Agent Mie gration sur la longueur des chemins entre deux nuds du graphe. En fonction de la discussion, les nuds reprsentent indiremment les emplacements des home agents, e e des nuds mobiles, et des correspondants. Nous dnissons deux notations dmip6 (A, B) e et dham (A, B) reprsentant la longueur des chemins lorsque Mobile IPv6 et Home Agent e Migration sont mis en uvre respectivement. Nous appellerons ces longueurs distances de communication. Les longueurs de communication sont en gnral plus grandes que e e les distances dans le graphe, car le chemin doit passer par un ou deux home agents en fonction du protocole considr. ee Importance des nuds Tous les nuds dun graphe nont pas la mme importance. Il existe direntes e e mesures permettant de dterminer la place quoccupe un nud dans un graphe. Dans e notre tude, nous ne considrons que le degr des nuds (i.e. le nombre de liens que e e e poss`de un nud), et la centralit dintermdiarit e e e e
5
car ces deux mesures fournissent
de bons rsultats pour slectionner les emplacements des home agents. e e La centralit dun nud x, note CB (x), dcrit la position de x vis-`-vis de tous e e e a les plus courts chemins dans le graphe auxquels x appartient. Pour tout nud x, la centralit est gale ` : e e a
5
appele simplement centralit par la suite. e e
123
CB (x) =
y=z=xV
yz (x) , yz
(B.1)
o` yz est le nombre de plus courts chemins de y ` z, et yz (x) le nombre de plus courts u a chemins de y ` z contenant x. a Mobile IPv6 Avec Mobile IPv6, les paquets changs entre deux nuds (correspondants et moe e biles) A et B doivent passer par le home agent HA. Par dnition, la longueur du e chemin rsultant est la somme des distances entre A et HA, et HA et B : e
dmip6 (A, B) = d(A, HA) + d(HA, B) Home Agent Migration
(B.2)
` A linverse de Mobile IPv6, les communications entre des nuds mobiles et correspondants ne sont pas quivalentes avec Home Agent Migration. Par consquent, nous e e devons tudier sparment deux motifs de communication dirents : entre deux moe e e e biles A et B (ce cas est quivalent ` une communication dun nud correspondant A e a vers un nud mobile B), quation B.3, et dun nud mobile C vers un correspondant e D, quation B.4. Dans les quations suivantes, la notation HAX reprsente le home e e e agent ayant la plus petite distance ` X. a
dham (A, B) = d(A, HAA ) + d(HAA , HAB ) + d(HAB , B) dham (C, D) = d(C, HAC ) + d(HAC , D) Emplacements de home agents
(B.3) (B.4)
Avec Mobile IPv6, le cas optimal est celui o` la longueur du chemin entre deux u nuds A et B nest pas modie par le routage triangulaire (d(A, B) = dmip6 (A, B)), e cest ` dire que le home agent est situ sur le plus court chemin entre A et B. Par a e consquent, les bons emplacements de home agents correspondent aux nuds appartee nant ` un maximum de plus courts chemins dans le graphe, i.e. les nuds de plus forte a centralit. e
124
B.4. Dploiement de Mobile IPv6 e De mme, avec Home Agent Migration, lorsque deux nuds mobiles M N 1 et M N 2 e
communiquent6 , les deux home agents primaires HAM N 1 et HAM N 2 doivent tre placs e e sur le plus court chemin entre M N 1 et M N 2 an dobtenir des performances similaires a ` celles de la communication directe (d(M N 1, M N 2) = dham (M N 1, M N 2)).
B.4.2
Mthodologie e
Nous tudions ici les emplacements des home agents en plaant les home agents, les e c nuds mobiles et les correspondants dans tous les nuds du graphe, puis en comparant les distances de communication aux distances dans le graphe. Calcul des distances, des degrs et des centralits e e Les distances entre tous les noeuds du graphe sont tout dabord calcules, et stockes e e dans le tableau distances : nous notons distances[A][B] la distance entre deux nuds A et B. Nous ne considrons que des graphes non orients : distances[A][B] = distances[B][A]. e e Nous utilisons lalgorithme Floyd-Warshall [50] pour calculer les distances entre toutes les paires des nuds et construire le tableau distances. Le degr est directement calcul e e en utilisant le nombre de liens de chaque nud. La centralit est, quant ` elle, calcule e a e avec lalgorithme dcrit par Brandes [107]. e Emulation du routage anycast Pralablement au calcul des distances de communication avec Home Agent Mie gration, le routage anycast doit tre mul an de dterminer les home agents les plus e e e e proches des nuds. Nous considrons ici que les home agents primaires sont slectionns e e e ` paren fonction de leurs distances aux nuds mobiles et aux nuds correspondants. A tir du tableau, distances, des distances dans le graphe, dune liste de home agents, ha, et dun nud, n, la fonction select pha() renvoie le home agent le plus proche de n, i.e. le nud possdant la plus petite distance ` n. e a Algorithme employ e Lalgorithme 2 dcrit comment calculer les distances de communication, pour Moe bile IPv6 et Home Agent Migration, ` partir du tableau distances, dune liste de home a agents ha, et de la liste de tous les nuds du graphe nuds. La ligne est une optimisation qui utilise le fait que d(pha1, pha2) = 0 lorsque pha1 = pha2 an duniformiser les calculs de distances de communication avec Mobile IPv6 et Home Agent Migration.
6
galement vrai pour des communications entre un nud correspondant et un nud mobile. e
125
Algorithme 2: Distances de communication Input: distances : tableau des distances, ha : liste des home agents, nuds : liste des nuds du graphe distances communication = {} ; forall dbut nuds do e forall n nuds do if taille(ha) > 1 then /* Home Agent Migration pha1 = select pha(ha, dbut) ; e pha2 = select pha(ha, n) ; else /* Mobile IPv6 pha1 = pha2 = ha[0] /* premier lment de la liste e e end distances communication[dbut][n] = distances[dbut][pha1] e e distances communication[dbut][n] += distances[pha1][pha2] e distances communication[dbut][n] += distances[pha2][n] e end return distances communication ; end
*/
*/ */
B.4.3
Evaluation
Ici, nous valuons deux stratgies de placement de home agents, bases sur le degr e e e e et la centralit, dans le rseau du projet WIDE [16]. Il sagit dun rseau acadmique e e e e japonais interconnectant des campus universitaires. Le graphe associ ` ce rseau a t ea e ee obtenu ` partir des informations sur la topologie de niveau 2 fournies par les adminisa trateurs de ce rseau. Il contient 28 nuds qui correspondent ` des centres serveurs, ou e a a ` des points de peering. Les liens ne sont pas pondrs. ee Mobile IPv6 La Figure B.6(a) reprsente la modication des longueurs de chemins lorsque le e home agent est plac dans un sous-rseau (nous supposons que les sous-rseaux core e e respondent ` des nuds de degr 1). Laxe des abscisses indique la modication des a e longueurs de chemins en pourcentage : 100% signie que la distance de communication vaut le double de la distance directe. Laxe des ordonnes indique quant ` lui le e a nombre de paires de nuds dans le graphe pour lesquelles la modication est infrieure e ou gale ` la valeur correspondante sur laxe des x (min correspond au sous-rseau e a e
126
B.4. Dploiement de Mobile IPv6 e
100 % des paires de noeuds 80 60 40 20 0 0 200 400 600 max min 800 1000 % des paires de noeuds
100 80 60 40 20 0 0 200 max plus grande centralit plus grand degr 400 600 800 1000
% ajouts aux longueurs des chemins
% ajouts aux longueurs de chemins
(a) Home agent dans un sous-rseau e
(b) Degr et centralit e e
Fig. B.6 Mobile IPv6
qui modie le plus les longueurs de chemins, et max ` celui-ci les modiant le moins). a Nous constatons ainsi que lorsque le home agent est plac dans le sous-rseau max, les e e longueurs de chemins de 56% des paires de nuds sont allonges de moins de 80%. La e valeur correspondante est de 19% pour min. Les sous-rseaux ne sont donc pas identiques dun point de vue des performances. Il e nexiste cependant pas de solution simple pour identier facilement le nud reprsentant e le sous-rseau qui fournit les meilleures performances. Cest pourquoi nous comparons e a e ` prsent le sous-rseau max avec les nuds possdant les degrs et les centralits les e e e e plus leves7 . Lorsque le home agent est plac dans lun des nuds ayant le plus fort e e e degr ou la plus forte centralit, Figure B.6(b), le nombre de chemins qui ne sont pas e e modis augmente tr`s nettement : 51% et 54% de tous les plus courts chemins ne sont e e pas du tout modis. La valeur correspondante est de 7% lorsque le home agent est e plac dans le nud max. Les performances sont donc nettement meilleures quand on e choisit lun de ces nuds. Home Agent Migration La Figure B.7(a) reprsente la modication des longueurs de chemins lorsque le e nombre de home agents augmente (ceux-ci sont classs puis slectionns par centralit e e e e dcroissante). Laxe des abscisses indique la modication des longueurs de chemins e en pourcentages. Laxe des ordonnes indique, quant ` lui, le nombre de paires de e a nuds dans le graphe pour lesquelles la modication est infrieure ou gale ` la valeur e e a correspondante sur laxe des x. Il est clair quaugmenter le nombre de home agents
7
ces trois nuds sont dirents dans le graphe que nous tudions ici. e e
127
100 90 % des paires de noeuds % des paires de noeuds 80 70 60 50 40 30 20 0 1 HA 2 HA 5 HA 10 HA 20 HA 100 200 300 400 500 600 700 800 % ajouts aux longueurs des chemins
100 90 80 70 60 50 5 10 centralit degr 15 20 25
Nombre de home agents
(a) Variation du nombre de home agents
(b) Degr et centralit e e
Fig. B.7 Home Agent Migration
implique que larchitecture contrle un nombre plus important de plus courts chemins. o Par voie de consquence, lajout de home agents saccompagne dune nette diminution e des distances de communication par rapport ` Mobile IPv6. a La Figure B.7(b) reprsente le pourcentage des paires de nuds pour lesquelles les e longueurs de chemins sont modies de moins de 10%, en fonction du nombre de home e agents. Nous plaons les home agents par ordre de degr et de centralit dcroissants. c e e e Dans la plupart des cas, nous constatons ainsi que la centralit fournit de meilleurs e rsultats que le degr pour la slection des home agents. e e e
B.4.4
Conclusion
Dans cette section, nous avons formellement dni les protocoles Mobile IPv6 et e Home Agent Migration en termes de thorie des graphes an dtudier leur inuence sur e e les distances de communication. Nous avons propos et valu deux stratgies de placee e e e ment utilisant le degr et la centralit pour identier les emplacements des home agents. e e Choisir le meilleur emplacement parmi un ensemble de home agents tant NP-dicile, e nous avons montr que nos mthodes de placement procurent une solution rapide et e e ecace pour slectionner les emplacements fournissant de bonnes performances. e En ce qui concerne le protocole Mobile IPv6, nous avons dcrit le routage triangue laire ` laide des distances, et conrm que tous les emplacements de home agents a e ne sont pas quivalents. Placer un home agent dans un sous-rseau peut en outre e e srieusement aecter les performances et augmenter les distances de communication. e Finalement, concernant Home Agent Migration, nous avons montr quutiliser plusieurs e home agents diminue tr`s nettement les distances de communication. e
128
B.5. Conclusion
B.5
B.5.1
Conclusion
Contributions
Cette th`se propose une architecture avance de gestion de la mobilit sappuyant e e e sur la exibilit du protocole Mobile IPv6, et peut tre dploye aussi bien dans lIne e e e ternet que dans un rseau doprateur. Cette architecture sarticule autour de deux e e travaux distincts pouvant tre indpendamment utiliss pour rsoudre les limitations e e e e de Mobile IPv6. Tout dabord, nous avons prsent une architecture distribue, appele Home e e e e Agent Migration, qui permet dutiliser conjointement plusieurs home agents. Grce a au routage anycast et ` un placement judicieux des home agents, le chemin entre les a nuds mobiles et leurs correspondants peut tre contrl an de limiter les eets du roue oe tage triangulaire. En plus dune description compl`te de cette architecture et du protoe cole mis en oeuvre, nous avons galement valid son fonctionnement exprimentalement e e e dans le rseau du projet WIDE [16]. Ainsi, dans la majeure partie des cas, les dlais e e de communication avec Home Agent Migration sont comparables ` ceux obtenus lorsa quaucun protocole de gestion de mobilit nest utilis. e e Nous avons galement tudi le protocole Mobile IPv6 en termes de thorie des e e e e graphes, et montr que lemplacement des home agents modie les performances. De e plus, nous avons quanti limpact du routage triangulaire sur les chemins de commue nications. En utilisant des graphes modlisant des rseaux doprateurs, nous avons e e e prcisment compar les dirents emplacements des home agents, et montr quils ne e e e e e sont pas tous gaux du point de vue des performances obtenues. De plus, nous avons e conrm que les nuds ayant la plus grande centralit sont les meilleurs candidats e e pour accueillir des home agents. Nous avons propos un nouvel algorithme permettant e didentier les emplacements des home agents avec Mobile IPv6 et Home Agent Migration dans nimporte quel rseau doprateur. Cette tude a galement montr que e e e e e Home Agent Migration constitue une nette amlioration par rapport aux dploiements e e classiques de Mobile IPv6 et, de ce fait, compl`te lvaluation exprimentale dans le e e e rseau du projet WIDE. e
B.5.2
Perspectives
Le travail prsent dans cette th`se peut tre approfondi de plusieurs mani`res e e e e e an damliorer larchitecture actuelle de Home Agent Migration. Ces perspectives e de recherche et dingnierie sont particuli`rement importantes pour permettre des e e dploiements commerciaux de Home Agent Migration. e
129
Avec larchitecture actuelle de Home Agent Migration, les informations contenues dans le Binding Cache sont simplement envoyes ` tous les home agents. Cette solution e a fut adquate pour valider notre approche, cependant elle nest pas approprie pour efe e fectuer des dploiements ecaces de cette architecture. De meilleures approches doivent e tre tudies pour distribuer le Binding Cache tout en diminuant la taille des copies e e e locales. Les tables de hachage distribues (en anglais Distributed Hash Table, DHT) e reprsentent ainsi une premi`re approche an de proposer une solution pour distribuer e e le Binding Cache ecacement. Cependant, il est fort possible quaucune mthode e de distribution gnrique ne puisse tre conue car elle est tr`s lie ` la mobilit des utie e e c e e a e lisateurs. Ainsi, si lon consid`re un dploiement plantaire de Home Agent Migration, e e e les informations concernant des utilisateurs japonais se dplaant uniquement dans la e c rgion de Tokyo ne doivent idalement pas tre distribues aux autres home agents e e e e si les communications de ces utilisateurs sont principalement locales et se limitent au Japon. Home Agent Migration amliore sensiblement la disponibilit de Mobile IPv6. Cee e pendant, cette architecture est sensible ` la stabilit des protocoles de routage utiliss a e e pour annoncer le prxe IPv6. En raison du routage anycast, si un routeur connectant e un home agent cesse de fonctionner, les nuds mobiles associs ` ce home agent ne e a pourront plus communiquer tant que le protocole de routage naura pas converg. Des e solutions bases sur des routeurs redondants ou des home agents multi-homs peuvent e e tre envisages. Cependant, avant tout autre travail, il est ncessaire de quantier e e e limpact des probl`mes de routage sur la disponibilit dun dploiement de Home e e e Agent Migration. Ceci pourrait ventuellement permettre danticiper les probl`mes de e e routage, et de dnir des solutions limitant leurs consquences. e e An de totalement valider larchitecture de Home Agent Migration, il convient deffectuer un dploiement ` lchelle de lInternet en distribuant les home agents et e a e en annonant le prxe IPv6 depuis dirents endroits dans le monde. Cette exprience c e e e est en eet complmentaire de celle conduite dans le rseau du projet WIDE. De plus, e e un tel dploiement peut galement permettre de monitorer les routeurs utiliss pour e e e grer lanycast et ainsi aider ` identier puis analyser les probl`mes de routage tels que e a e prcdemment dcrits. e e e Actuellement, avec Home Agent Migration, seules les communications intra home agents sont protges par IPsec. Les communications entre les home agents et les nuds e e mobiles tant des cibles de choix pour des attaquants ventuels, il convient deectuer e e des tests dinteroprabilit entre Home Agent Migration et IPsec. Notre expertise e e de Mobile IPv6 et dIPsec nous conduit ` penser quil ne devrait pas y avoir de probl`me, a e
130
B.5. Conclusion
et que peu de modications de leurs implmentations seront ncessaires. Finalement, e e concernant la scurit au sens large, lintgration des architectures Home Agent Mie e e gration et AAA8 doit galement tre tudie avant tout dploiement commercial. Si e e e e e lon consid`re Home Agent Migration et dirents fournisseurs dacc`s ` Internet, cette e e e a intgration permettra de mettre en place des accords ditinrance, et de faciliter les e e mouvements des utilisateurs dans ce syst`me de mobilit ` lchelle plantaire. e ea e e
Authentication, 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/wistore.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 information exchange between systems-Local and metropolitan area networks-Specic requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specications. IEEE Std 802.11-2007 (Revision of IEEE Std 802.11-1999), pages C11184, June 12 2007. [18] J. Abley, P. Savola, and G. Neville-Neil. Deprecation of Type 0 Routing Headers in IPv6. RFC 5095 (Proposed Standard), December 2007. [19] J. Arkko, V. Devarapalli, and F. Dupont. Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents. RFC 3776 (Proposed Standard), June 2004. Updated by RFC 4877. [20] J. Arkko, C. Vogt, and W. Haddad. Enhanced Route Optimization for Mobile IPv6. RFC 4866 (Proposed Standard), May 2007. [21] Brice Augustin, Xavier Cuvellier, Benjamin Orgogozo, Fabien Viger, Timur Friedman, Matthieu Latapy, Clmence Magnien, and Renata Teixeira. Avoiding tracere oute anomalies with Paris traceroute. In IMC 06: Proceedings of the 6th ACM SIGCOMM conference on Internet measurement, pages 153158, New York, NY, USA, 2006. ACM. [22] Tuomas Aura. Mobile IPv6 Security. In Proc. Security Protocols, 10th International Workshop, volume 2845 of LNCS, pages 215228, Cambridge, UK, April 2002. Springer. [23] T. Bates, R. Chandra, D. Katz, and Y. Rekhter. Multiprotocol Extensions for BGP-4. RFC 4760 (Draft Standard), January 2007. [24] Yigal Bejerano and Israel Cidon. An Anchor Chain Scheme for IP Mobility Management. In Wireless Networks Volume 9, Issue 5, pages 409420, September 2003. [25] Claude Berge. Thorie des graphes et ses applications. Dunod, 1963. e [26] Philippe Biondi. Scapy. http://www.secdev.org/projects/scapy/. [27] Philippe Biondi and Arnaud Ebalard. IPv6 Routing Header Security. In
CanSecWest Security Conference, April 2007. [28] R. Bonica, D. Gan, D. Tappan, and C. Pignataro. Extended ICMP to Support Multi-Part Messages. RFC 4884 (Proposed Standard), April 2007.
Bibliography
133
[29] C. Castelluccia. HMIPv6: A Hierarchical Mobile IPv6 Proposal. In ACM Mobile Computing 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, Internet Engineering Task Force, February 2006. [31] B. Chambless and J. Binkley. Home Agent Redundancy Protocol (HARP) (expired, draft-chambless-mobileip-harp-00.txt). Internet Draft, Internet Engineering Task Force, 1997. [32] Cisco IOS IPv6 Conguration Library. Implementing Mobile IPv6. Technical report. [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 eects of 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 (Proposed Standard), December 1999. [36] A. Conta, S. Deering, and M. Gupta. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specication. 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. In Proceedings of the Third IEEE Workshop on the Architecture and Implementation of High Performance Communication Subsystems (HPCS 95), 1995. [39] L. DallAsta, I. Alvarez-Hamelin, A. Barrat, A. Vazquez, , and A. Vespignani. Exploring networks with traceroute-like probes: Theory and simulations. In Theoretical Computer Science 355, 2006. [40] David C. Bell, John S. Atkinson and Jerry W. Carlson. Centrality measures for disease transmission networks. Social Networks, 21:121, 1999.
134
Bibliography
[41] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specication. RFC 2460 (Draft Standard), December 1998. Updated by RFC 5095. [42] V. Devarapalli and F. Dupont. Mobile IPv6 Operation with IKEv2 and the Revised 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. Dynamic Host Conguration Protocol for IPv6 (DHCPv6). RFC 3315 (Proposed Standard), 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 Correspondent IPv6 Nodes. Internet-Draft, Internet Engineering Task Force, December 2005. [48] J. Faizan, H. El-Rewini, and M. Khalil. Virtual Home Agent Reliability Protocol (VHAR) (expired, draft-jfaizan-mipv6-vhar-02.txt). Internet Draft, Internet Engineering 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 Across Network Address Translators. In Proceedings of the 2005 USENIX Technical Conference, 2005. [52] D. Forsberg, J. T. Malinen, T. Weckstrom, and M. Tiusanen. Distributing mobility agents hierarchically under frequent location updates. In Mobile Multimedia Communications, 1999. (MoMuC 99), pages 159168, November 1999. [53] Linton C. Freeman. A Set of Measures of Centrality Based on Betweenness. Sociometry, 40(1):3541, March 1977.
Bibliography
135
[54] Jean-Loup Guillaume, Matthieu Latapy, and Damien Magoni. Relevance of massively distributed explorations of the Internet topology: Qualitative results. Computer Networks, 50(16):31973224, 2006. [55] Guillaume Valadon, Florian Le Go and Christophe Berger. Daily Walks in Paris: A Practical Analysis of Wi-Fi Access Points. In Student Workshop CoNext, NewYork, December 2007. [56] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil. Proxy Mobile IPv6 (work in progress, draft-sgundave-mip6-proxymip6-10). Internet Draft, Internet Engineering Task Force, February 2008. [57] D. Harkins and D. Carrel. The Internet Key Exchange (IKE). RFC 2409 (Proposed Standard), November 1998. Obsoleted by RFC 4306, updated by RFC 4109. [58] J. Hener, M. Mathis, and B. Chandler. IPv4 Reassembly Errors at High Data Rates. RFC 4963 (Informational), July 2007. [59] R. Hinden and D. Thaler. IPv6 Host-to-Router Load Sharing. RFC 4311 (Proposed Standard), November 2005. [60] Choong Seon Hong, Ki-Woon Yim, Dae-Young Lee, and Dong-Sik Yun. An Ecient Fault Tolerance Protocol with Backup Foreign Agents in a Hierarchical Local Registration Mobile IP. In ETRI Journal, vol.24, no.1, pages 1222, Febuary 2002. [61] Luigi Iannone and Serge Fdida. MeshDV: A Distance Vector mobility-tolerant routing 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 Dan Shell. Use of Mobile-IP Priority Home Agents for Aeronautics Space Operations and 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), pages 295304, 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-Fi Access Points. In Proceedings of 2007 IEEE Portable: International Conference on 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 SIGCOMM2000, August 2000. [70] C. Kaufman. Internet Key Exchange (IKEv2) Protocol. RFC 4306 (Proposed Standard), December 2005. [71] S. Kent. IP Authentication Header. RFC 4302 (Proposed Standard), December 2005. [72] S. Kent. IP Encapsulating Security Payload (ESP). RFC 4303 (Proposed Standard), 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), July 2005. [75] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones. SOCKS Protocol Version 5. RFC 1928 (Proposed Standard), March 1996. [76] Damien Magoni and Mickal Hoerdt. Internet core topology mapping and anale ysis. Computer Communications, 28(5):494506, 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 lter: A new architecture for user-level packet capture. In USENIX Winter, pages 259270, 1993. [79] Microsoft Corporation. Understanding Mobile IPv6, November 2005.
Bibliography
137
[80] I. Mizuko, D. Okabe, and M. Matsuda. Portable, Pedestrian: Mobile Phones in Japanese Life. In MIT Press, Cambridge, MA, 2005. [81] m:metrics. 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. RFC 4423 (Informational), May 2006. [84] Steve Mtika and Fambirai Takawira. Mobile IPv6 Regional Mobility Management. In Proceedings of the 4th international symposium on Information and communication technologies, pages 93 98, January 2005. [85] Andrew Myles, David B. Johnson, and Charles Perkins. A Mobile Host Protocol Supporting Route Optimization and Authentication. In IEEE Journal on Selected Areas in Communications, special issue on Mobile and Wireless Computing Networks, vol.13, No.5, pages 823849, 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 for IP version 6 (IPv6). RFC 4861 (Draft Standard), September 2007. [88] C. Ng, P. Thubert, M. Watari, and F. Zhao. Network Mobility Route Optimization Problem Statement (work inprogress, draft-ietf-nemo-ro-problem-statement03). Internet Draft, Internet Engineering Task Force, September 2006. [89] P. Nikander, J. Arkko, T. Aura, G. Montenegro, and E. Nordmark. Mobile IP Version 6 Route Optimization Security Design Background. RFC 4225 (Informational), December 2005. [90] H. Omar, T. Saadawi, and M. Lee. Support for Fault Tolerance in Local Registration Mobile-IP Systems. In MILCOM 1999 - IEEE Military Communications Conference, pp. 126 - 130, October 1999. m:metrics: iphone hype holds up, March 2008.
http://www.mmetrics.com/press/PressRelease.aspx?article=20080318-
138
Bibliography
[91] L. Ong and J. Yoakum. An Introduction to the Stream Control Transmission Protocol (SCTP). RFC 3286 (Informational), May 2002. [92] A. Patel, K. Leung, M. Khalil, H. Akhtar, and K. Chowdhury. Authentication Protocol 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 Web Server Replicas. In INFOCOM 2001, 2001. [97] S. Sugimoto, F. Dupont and N. Nakamura. PF KEY Extensions as an Interface between Mobile IPv6 and IPsec/IKE (draft-sugimoto-mip6-pfkey-migrate02). Internet-Draft, Internet Engineering Task Force, September 2006. [98] Behcet Sarikaya. Home Agent Placement and IP Address Management for Integrating WLANs with Cellular Networks. Wireless Communications, IEEE, 13:7786, December 2006. [99] Skyhook Wireless. http://www.skyhookwireless.com/. [100] H. Soliman, C. Castelluccia, K. El Malki, and L. Bellier. Hierarchical Mobile IPv6 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 Rocketfuel. In ACM/SIGCOMM, August 2002. [103] W. Stevens, M. Thomas, E. Nordmark, and T. Jinmei. Advanced Sockets Application Program Interface (API) for IPv6. RFC 3542 (Informational), May 2003. [104] R. Stewart. Stream Control Transmission Protocol. RFC 4960 (Proposed Standard), September 2007.
Bibliography
139
[105] S. Thomson, T. Narten, and T. Jinmei. IPv6 Stateless Address Autoconguration. RFC 4862 (Draft Standard), September 2007. [106] P. Thubert, R. Wakikawa, and V. Devarapalli. Global HA to HA protocol, (work in progress, draft-thubert-nemo-global-haha-00.txt). Internet Draft, Internet Engineering Task Force, October 2004. [107] Ulrik Brandes. A Faster Algorithm for Betweenness Centrality. Journal of Mathematical Sociology, 25:163167, 2001. [108] Guillaume Valadon. BPF mode for Scapy. http://hg.natisbad.org/scapy-bpf/. [109] Guillaume Valadon and Arnaud Ebalard. http://namabiiru.hongo.wide.ad.jp/scapy6/. [110] Guillaume Valadon and Ryuji Wakikawa. Extending Home Agent Migration To Mobile IPv6 based Protocols. In AINTEC07, Phuket, Thailand, December 2007. [111] R. Wakikawa. Home Agent Reliability Protocol (work in progress, draft-ietf-mip6hareliability-01.txt). Internet Draft, Internet Engineering Task Force, March 2007. [112] R. Wakikawa, V. Devarapalli, and P. Thubert. Inter Home Agents Protocol (HAHA) (work in progress, draft-wakikawa-mip6-nemo-haha-01.txt). Internet Draft, Internet Engineering Task Force, February 2004. [113] R. Wakikawa, T. Ernst, K. Nagami, and V. Devarapalli. Multiple Care-of Addresses Registration (work in progress, draft-ietf-monami6-multiplecoa-06). Internet Draft, Internet Engineering Task Force, February 2008. [114] R. Wakikawa., S. Koshiba, K. Uehara, and J. Murai. ORC: Optimized Route Cache Management Protocol for Network Mobility. In IEEE 10th International Conference on Telecommunication (ICT) 2003, pages 119126, February 2003. [115] R. Wakikawa, P. Thubert, and V. Devarapalli. Inter Home Agents Protocol Specication, (work in progress, draft-wakikawa-mip6-nemo-haha-spec-00.txt). Internet Draft, Internet Engineering Task Force, October 2004. [116] Ryuji Wakikawa, Guillaume Valadon, and Jun Murai. Distributed Mobility Management Scheme for Mobile IPv6. Submitted to IEICE Transactions on Communications Special Section on Networking Technologies for Dependable Networks. IPv6 support for Scapy.
140
Bibliography
[117] Ryuji Wakikawa, Guillaume Valadon, and Jun Murai. Migrating Home Agents Towards Internet-Scale Mobility Deployments. In CoNext06, Lisbonne, Portugal, December 2006. [118] Sami Tabbane Xavier Lagrange, Philippe Godlewski. Rseaux GSM. Herm`s e e Lavoisier, 2000.
List of Figures
1.1 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9
Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile IPv6 terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile IPv6: communication example . . . . . . . . . . . . . . . . . . . Mobile IPv6: packets exchanges . . . . . . . . . . . . . . . . . . . . . . . Return Routability Procedure: communication example . . . . . . . . . Return Routability Procedure: packets exchanges . . . . . . . . . . . . . NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nested NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchical Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . Fast Handover for Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . .
10 15 16 17 18 19 21 22 29 31 33 37 38 39 40 44 46 48 52 53 53 53 61
2.10 Multiple Care-of Address . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 Home Agent Migration and dierent access technologies . . . . . . . . . Concept of Home Agent Migration . . . . . . . . . . . . . . . . . . . . . Mobile IPv6 compared to Home Agent Migration . . . . . . . . . . . . . Concept of Global Mobile eXchange . . . . . . . . . . . . . . . . . . . . Home Agent Migration: communication examples . . . . . . . . . . . . . An example of home agents conguration . . . . . . . . . . . . . . . . . Home Agent Migration: packets exchanges . . . . . . . . . . . . . . . . . Abstract network topology of the experimentation . . . . . . . . . . . . RTT between San Francisco and Tokyo . . . . . . . . . . . . . . . . . .
3.10 RTT between San Francisco and Amsterdam . . . . . . . . . . . . . . . 3.11 RTT between San Francisco and Belgium . . . . . . . . . . . . . . . . . 4.1 Examples of unweighted and weighted graphs . . . . . . . . . . . . . . .
142 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9
List of Figures Centrality: example graph . . . . . . . . . . . . . . . . . . . . . . . . . . Relation between a Network Operating Center and graph vertex . . . . Degree against betweenness centrality . . . . . . . . . . . . . . . . . . . Degree against betweenness centrality: example graph . . . . . . . . . . Mobile IPv6: one home agent located in a subnetwork (unweighted) . Mobile IPv6: one home agent located in a subnetwork (GEANT) . . . . . Mobile IPv6: degree and betweenness centrality (unweighted) . . . . . Mobile IPv6: degree and betweenness centrality (GEANT) . . . . . . . . . 62 65 72 73 74 75 76 76 77 78 79 80 81 82 82
4.10 Centrality: example graph . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Home Agent Migration: correspondent and mobile nodes communications (unweighted) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Home Agent Migration: correspondent and mobile nodes communications (GEANT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13 Home Agent Migration: increasing the number of home agents (unweighted) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.14 Home Agent Migration: increasing the number of home agents (GEANT) . 4.15 Home Agent Migration: comparison of degree and betweenness centrality (unweighted) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.16 Home Agent Migration: comparison of degree and betweenness centrality (GEANT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.1 Routing Header Type 0 processing . . . . . . . . . . . . . . . . . . . . . 101 A.2 Advanced traceroutes using Routing Header Type 0 . . . . . . . . . . . 103 A.3 Indirect traceroute with Scapy6 . . . . . . . . . . . . . . . . . . . . . . . 104 A.4 Routing Header Type 0 based attacks: capacitor eect . . . . . . . . . . 104 B.1 Mobile IPv6 : exemple de communication . . . . . . . . . . . . . . . . . 114 B.2 Home Agent Migration et direntes technologies dacc`s . . . . . . . . 117 e e B.3 Mobile IPv6 compar ` Home Agent Migration . . . . . . . . . . . . . . 118 ea B.4 Topologie reprsentant lexprience . . . . . . . . . . . . . . . . . . . . . 120 e e B.5 RTT entre San Francisco et Amsterdam . . . . . . . . . . . . . . . . . . 120 B.6 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 B.7 Home Agent Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
List of Tables
1.1 1.2 3.1 4.1
Identiers examples
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 8 52 63
Design constraints and mobility protocols examples . . . . . . . . . . . . Round Trip Time in our experiment (in ms) . . . . . . . . . . . . . . . . Comparison of centrality values for the graph of Figure 4.2 . . . . . . .
B.1 Classication de dirents protocoles de mobilit . . . . . . . . . . . . . 111 e e
Rsum e e
Larchitecture de lInternet est telle que, lorsquun utilisateur se dplace et change e de rseau, ladresse IP de son priphrique est modie, entra e e e e nant la perte des communications en cours. An de rsoudre ce probl`me, des protocoles de gestion de la e e mobilit ont t dnis pour rendre les communications insensibles aux mouvements et e ee e indpendantes du rseau o` se trouve lutilisateur. Cependant, la plupart des proposie e u tions sourent de probl`mes aectant leurs performances, ou bien encore leur utilisation e dans larchitecture actuelle de lInternet. Par exemple, certaines dentre elles, comme le protocole HIP, imposent que tous les priphriques, y compris ceux qui sont xes, e e implmentent le protocole de mobilit. Dautres encore, tel que le protocole Mobile e e IPv6, induisent des chemins plus longs et donc des dlais de communication plus ime portants. Ce travail de th`se vise ` amliorer les performances du protocole Mobile IPv6 e a e en contrlant les direntes limitations induites par lutilisation dun routeur grant la o e e mobilit: le home agent. Pour ce faire, nous proposons deux approches complmentaires e e qui tout en tant compatibles avec linfrastructure actuelle de lInternet, permettent e de grer la mobilit de faon transparente ` la fois pour le rseau et les priphriques e e c a e e e xes. Tout dabord, nous dcrivons une nouvelle architecture distribue de gestion de e e la mobilit appele Home Agent Migration qui permet dutiliser plusieurs home agents e e simultanment. Grce ` un dploiement rel, nous montrons quil est possible dobtenir e a a e e des performances comparables ` celles de communications nutilisant pas Mobile IPv6. a Ensuite, nous dnissons formellement les proprits des emplacements des home agents e ee en termes de thorie des graphes. En sappuyant sur cette tude, nous quantions e e limpact du protocole Mobile IPv6 sur les communications. Finalement, nous proposons un nouvel algorithme qui permet de traiter les problmatiques de dploiement de Mobile e e IPv6 et de Home Agent Migration dans des graphes qui modlisent des rseaux de e e communication.
Mots-Cls e
Mobile IPv6, gestion de la mobilit, anycast, graphe, centralit e e

Mobile Ipv6

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mobile Ipv6

Transféré par

Droits d'auteur :

Formats disponibles

Th`se de Doctorat de lUniversit Paris VI e e Pierre et Marie Curie

Docteur de lUniversit Pierre et Marie Curie e

Mobile IPv6 : architectures et protocoles

Th`se de Doctorat de lUniversit Paris VI e e Pierre et Marie Curie

Docteur de lUniversit Pierre et Marie Curie e

Mobile IPv6 : architectures et protocoles

Enn, merci ` tous ceux qui ont relev le d daronter la soutenance ! a e e

Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Standardized optimizations . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 2.4.2 2.4.3

Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Home Agents locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 4.3.3

Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 4.4.2 4.4.3 4.4.4

Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4 1.5 1.6

Overview of Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Standard problems induced by Mobility

1.2. What is mobility support anyway?

What is mobility support anyway?

also referred as a mobile node.

Approaches for Internet mobility support

Locators and identiers

1.3. Approaches for Internet mobility support

Names Domain names ID IP addresses

Protocols DNS HIP, SCTP MIPv6, LISP, NETLMM

Table 1.1: Identiers examples

although HIP is often referred as a layer 3.5 protocol.

1.3. Approaches for Internet mobility support

Table 1.2: Design constraints and mobility protocols examples

Overview of Mobile IPv6

1.4. Overview of Mobile IPv6

Internet Home network Optimized Path

Background on Mobile IPv6

Home Agent Discovery . . . . . . . . . . . . . . . . . . . . . .

2.1. Mobile IPv6

Chapter 2. Background on Mobile IPv6

Internet Home Link

Figure 2.1: Mobile IPv6 terminology

Operation of Mobile IPv6

2.1. Mobile IPv6

Internet Home network

Figure 2.2: Mobile IPv6: communication example

auto-congured with the prex advertised by the Access Router (AR).

Chapter 2. Background on Mobile IPv6

Figure 2.3: Mobile IPv6: packets exchanges

2.1. Mobile IPv6

Figure 2.4: Return Routability Procedure: communication example

Return Routability Procedure

Chapter 2. Background on Mobile IPv6

ICMPv6 Echo Request

ICMPv6 Echo Reply

Figure 2.5: Return Routability Procedure: packets exchanges

Chapter 2. Background on Mobile IPv6

2.1. Mobile IPv6

Home Agent Discovery

Chapter 2. Background on Mobile IPv6

the anycast address associated to the prex 2001:db8:d0d0::/64 is 2001:db8:d0d0::fd:::fe.

Return Routability Procedure

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

Chapter 2. Background on Mobile IPv6 3. Complexity

2.3. Security overview

Possible attacks against Mobile IPv6

Chapter 2. Background on Mobile IPv6

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