Supporting Mobility in LISP∗

Lorand Jakab Albert Cabellos-AparicioUniversitat Politecnica de Catalunya

{ljakab,acabello,jordid}@ac.upc.edu

Jordi Domingo-Pascual

AbstractAfter several years of research there is still no widespread deploy-ment of mobility protocols. Mobile IPv4 offers very little in ad-dition to using a VPN, which is one of the preferred “mobility”solutions today. Both approaches suffer from poor performancedue the lack of route optimization. Mobile IPv6 adds routing opti-mization but it requires explicit mobility support in correspondingnodes. Recently the IETF has been designing a new Internet archi-tecture, the Locator/ID Separation Protocol (LISP). LISP aims tosolve the scalability of the routing system but it comes at a cost, assome entities in the Internet should be updated. This offers a rarewindow of opportunity to add native mobility support. The pre-sented proposal offers route optimized paths, even for IPv4, whichwas previously not supported. Additionally it requires no mobil-ity support in corresponding nodes or networks and a has a lowdeployment cost. Incremental deployment is possible, as well asmixing with and/or fallback to Mobile IP. Further we provide ananalytical model that shows that the signalling overhead of our ap-proach is lower than the existing ones.

1 IntroductionThe 2006 Internet Architecture Board Routing and Address-ing Workshop report [1] listed the alarming rate of growthof the Default Free Zone (DFZ) routing table the most im-portant problem facing the Internet today. The scalabilityissues of the current Internet Routing architecture were pre-viously recognized, and proposals already existed for futureInternet architectures. Many of them are centered aroundthe idea of separating the network node’s identifier from itstopological location. This report however sparked researchfor a solution, that would enable incremental deploymentof the new proposed protocol, changing as little as possiblecurrent hardware, software and addressing schemes. TheLocator/ID Separation Protocol (LISP) [2] is a promisingproposal, pushed by Cisco and academia, that tries to meetthe above mentioned goals.

Nevertheless, even though its authors recognize the im-portance of mobility, they have not included it in the pro-

∗This work has been partially supported by the Ministry of Innovation,Universities and Enterprise of the Generalitat of Catalonia under scholar-ship number 2006FI-00935 and the Spanish Ministry of Science and Tech-nology under contract TSI 2005-07520-C03-02.

tocol. As we know, mobile devices are evolving at an im-pressive pace, having smartphones, mobile internet devices(MIDs), ultra-mobile PCs and netbooks with mobile broad-band access breaking out of the high-end business marketsto the everyday consumer. Technology has reached a mile-stone where a rich mobile Internet experience is possible atlow prices of both the device and broadband access, and theconvergence to all-IP services is becoming a reality. In thisclimate we have a fertile ground for the explosion of thefuture mobile Internet, where things like direct optimizedpaths and global reachability with the same identifier willbe a must.

To this day, mobile usage was restricted to but a few ap-plications, which had to tolerate suboptimal network config-urations, imposed by the limits of existing mobility proto-cols, such as Mobile IP. The most important limitation ofMobile IPv4 [3] is the lack of route optimization, whichleads to decreased performance [10]. Mobile IPv6 [4] intro-duces support for route optimization, but requires additionalsoftware support at end hosts, which have little incentive tohave it. Additionally IPv4 will probably still be in use for along time, mobility should work well with this protocol too.

The current LISP specification considers fast endpointmobility in terms of using the existing mechanisms of Mo-bile IPv4 and Mobile IPv6, and has no provision for built-in native mobility support [2]. The reason behind this isconcern for the scalability of the system. LISP employs aspecial distributed database to store bindings between thelocation and the identity of the nodes. Based on the fact thatIP prefix assignments are relatively constant and providerchanges unfrequent, designs for this database have assumedlow update rates for the values stored. Global mobilitysupport at the LISP level would significantly increase therate at which stored values are updated, when nodes changetheir point of attachment to a different autonomous system.Since mobility was not considered as a design goal for thesedatabases, they don’t scale to the requirements of fast end-point mobility. As we will detail in a later section, the de-sign of the database is not part of the main LISP specifica-tion and existing proposals can be replaced without affect-ing how LISP works.

If LISP was to take off and be deployed in the future In-ternet, we have a rare window of oportunity to avoid “patch-work” and design and introduce native mobility support intothe network. To this date the level of penetration of exist-

1

ing proposals is very low: on one hand Mobile IPv4 haslittle advantages over existing VPN solutions, on the otherthe lack of IPv6 obiquity makes deploying the performanceoptimized Mobile IPv6 not feasable.

Our contributions are twofold. First, we explore the so-lution space and present a new architecture that providesnative mobility, taking into account the main requirementsof LISP: low deployment costs and incremental transition.Second, we address the database scalability issue and pro-pose an architecture where updates are localized to the en-tities involved in traffic exchange, yet instantly made acce-sible to the global infrastructure. The proposed architectureis based LISP-DHT [6] but it can be adapted to other ap-proaches. We then compare the performance of this archi-tecture with that of the existing approach, that is Mobile IPrunning on top of LISP. Our evaluation shows that signif-icant improvements are achieved, such as route optimizedcommunications from the mobile nodes to their correspond-ing nodes, which need not be aware of mobility. These gainsare achieved with no changes to exisiting deployments ofend hosts and network infrastructure. Further we provide ananalytical model that shows that our solution is more scal-able, in terms of signalling overhead, than the existing ap-proach. Our work is rooted in existing research on mobilityarchitectures, but to the best of our knowledge there is nopreviuos work in the area of mobility in the context of LISPdeployment.

2 Background

2.1 The Locator/ID Separation ProtocolThis section presents a basic overview of LISP [2]. Thereader already familiar with this protocol can safely skipit. As mentioned before, the main drivers of this proposalare the scalability issues of the current Internet’s routing in-frastructure. According to its authors, the solution lies inthe separation of the address space of end hosts (Destina-tion Space) from that of the transit network (Transit Space).Fig. 1 illustrates this separation. An additional plane, theMapping System is required in order to facilitate the “glue”between the two spaces.

In order to decouple the identifiers of nodes from theirlocation, LISP introduces Routing Locators (RLOCs), andEndpoint Identifiers (EIDs). RLOCs are addresses used bynetwork elements in the Transit Space, and define where inthe routing topology a destination node is to be found. EIDsrepresent the identity of the node, regardless of its locationand are used as addresses in the Destination Space. In orderto be incrementally deployable, and with no changes in endsystems, RLOCs and EIDs are both using the IP addressspace, either IPv4 or IPv6.

When a packet is sent in the LISP-enabled Internet, ittravels within the autonomous system (AS) using currentlydeployed mechanisms, until it reaches the border router.

Figure 1: LISP Architecture

This router is called the ingress tunnel router (ITR) in LISPterminology because it is the ingress point to the tunnel tothe border router of the destination AS, the egress tunnelrouter (ETR). Since a border router can implement bothfunctions, we will use the term Tunnel Router (xTR) for thiskind of device. Consider Fig. 1 for example. A host withEIDA wants to send a packet to EIDB. It reaches xT RA1,which takes the destination address (EIDB), looks it up inthe mapping system, which returns RLOCB. xT RA1 encap-sulates the packet in a LISP header, sends it to xT RB, whichdecapsulates it and then gets delivered to the destination.

The previously mentioned EID-to-RLOC mappinglookup relies on a distributed database which returns one orseveral RLOCs (in a Map-Reply) for an EID query (Map-Request). Implementation details of the database are notpart of the main LISP specification to allow flexibility in itsdesign. To this date, several proposals exist: based on an al-ternative BGP overlay, among others [5], a Chord DHT [6]and a hierarchical content distribution system [7].

2.2 LISP-DHT

As discussed earlier, the mapping system is the “glue” be-twen the Destination Space and the Transit Space in LISP.It is based on a distributed database, to which ITRs turn tolook up which RLOC(s) correspond to a given destinationEID. We can look at this database as a collection of key-value pairs, where each key is an EID and the correspondingvalue a list of RLOCs.

LISP-DHT [6] proposes an efficient way to build such adatabase using a distributed hash table (DHT) to store thesekey-value pairs in a peer-to-peer network. Many differentDHT algorithms exist, with their strengths and weaknesses,which can be adapted to specific applications. Mathy et al.chose to build on Chord [8], because of one property thatdetermines the node responsible for a given key.

2

In Chord each participating node has a unique k-bit iden-tifier (ChordID), in a space organized in a ring topology. Itmust know the predecessor and successor nodes from thistopology, and for routing efficiency it also keeps a fingertable with nodes that are further away. The DHT storeskey-value pairs with keys in the same k-bit numerical space,where each node is responsible for the keys between its ownand its predecessor’s ChordID. The interested reader canfind all the details in [8].

This particular way of storing keys in Chord is the mainreason behind the choice of the DHT: because mappingservers of an AS are responsible for mapping EIDs belong-ing to a particular prefix to RLOCs, they join the DHT usingthe highest available IP address of that particular prefix astheir ChordID. This ensures that they are resposible (author-itative) for lookups of EIDs belonging to that prefix. As wewill explore later, this property is also the reason LISP-DHTwas chosen for the proposal presented in this paper.

Due to Chord’s generic design, a new node connectingto the DHT with a ChordID lower with just one unit couldhijack resposibility for the prefix. If it is a malicious node,it could hijack traffic destined for those EIDs, by returningthe RLOC of an xTR owned by the attacker. To solve thisweakness, a mechanism is needed to provide trust betweenthe nodes participating to the DHT.

In order to provide trust, when the prefix is allocated bya regional registry, a signed certificate of ownership is alsoissued to the requesting organization. The LISP-DHT draftproposes the use of a mechanism based on PKIX ResourceCertificates [9] for this purpose. The organization then is-sues certificates of authority to its mapping servers, whichwill include this certificate in messages that trigger an up-date of routing information in other nodes. This way a nodejoining the DHT can prove “ownership” of the claimed ad-dress space. All participants to the DHT have the publickeys of the registries and can verify this certificate. Sinceobtaining an IP prefix requires a trust relationship betweenthe registry and the organization independent of this Pub-lic Key Infrastructure, scalability is not an issue. For moredetails the reader is referred to [6].

3 Overlay (Mobile IP)As previously mentioned, the LISP proposal has no built-insupport for mobility in its current form. In order to offer mo-bility, a mechanism exterior to LISP needs to be employed.This mechanism will run on top of the LISP architecture,thus we will call it an overlay approach. In the followingparagraphs we describe how the overlay approach works ina LISP-enabled Internet, and explore its advantages and dis-advantages.

While the LISP specification does not include mobility,it does mention the use of Mobile IP [3, 4] to accomplishit. This protocol introduces a new entity called the HomeAgent (HA), which is attached to the home network (HN)

of the mobile node (MN). Each network wishing to offermobility services to its hosts should have at least one HAdeployed.

When a mobile node MN moves to a foreign network, itgets a new EID (Care-of-Address or CoA), announces thisaddress to its HA with whom then sets up a tunnel. The cor-responding nodes know nothing about this change, and con-tinue sending packets to the old EID. These packets reachthe HN of the MN, are intercepted by the HA in its absenceand tunneled to the CoA (see Fig. 2). In this case the LISPcontrol plane is unaware of mobility since it is managed ata different plane, by the end hosts.

Figure 2: Overlay Approach (Mobile IP)

This approach does not present any issues to LISP’s con-trol plane, however it has some drawbacks. Communica-tions must be forwarded through the HA (lack of route opti-mization) leading to a sub-optimal path that increases delayand infrastructure load [10]. Moreover, since all data trafficof MNs belonging to a given HN passes through the HA, itmay become the bottleneck of networks using Mobile IP.

The lack of route optimization can be solved in IPv6based networks using the return routability procedure de-fined in the Mobile IPv6 standard [4]. This mechanism al-lows the authentication the new location (CoA) of the MN.Its major advantage is that it is based on routing rather thancertificates, which are usually costly to deploy. For this pro-cedure to work, explicit support is needed both at the MNand the CNs. MIPv6 does specify native support for CNs,but it is not a strict requirement of an IPv6 stack implemen-tation. Unfortunately, depending on the mapping cache sta-tus of the involved xTRs, in the worst case scenario up to6 additional mapping system lookups may be required, forthe messages BU, HoTI, CoTI, HoT, CoT and BA, see [4]for more details. This overhead may cause packet drops andmay result in an unacceptable performance.

3

4 Localized Native Approach

The central idea of LISP is separating location informationfrom the identifier of a node, and storing a mapping froman identifier to a location in a distributed database. If wetake this concept at an abstract level, this is exactly whatmobility is about: knowing at each moment in time where agiven node is. Due to this conceptual closeness, we will callthe proposal a native approach.

At the heart of this solution we have the EID of the MN,which is kept regardless of the the point of attachement asthe global identifier of the node. While the node is mov-ing within the same domain, it is managed by intra-domainmobility protocols, such as [11, 12]. When a domain bound-ary is crossed, the mapping system is updated with the newRLOC mapping for the EID. This new RLOC is the addressof the visited network’s (VN) xTR.

When the update is sent to the mapping system, it shouldbe instantly available globally to any xTR that would re-quest it. The mapping system currently in use on the pilotexperimental LISP deployment [5] is based on BGP, and hasto propagate the update to all xTRs. This approach cannotscale to the needs of fast enpoint mobility in the global In-ternet. In contrast to this approach, LISP-DHT distributesmappings in the Chord-based peer-to-peer network accord-ing to the EID that has to be resolved. This distribution isdone in such a way that each AS’s node participating in theDHT is resposible for the AS’s own EIDs. This propertywas described in more detail in Section 2.2. As direct con-sequence, for a mapping update the MN can avoid using theDHT’s lookup mechanism to store the updated mapping, in-stead it can contact directly the mapping server of its owndomain. Since the change directly affects only that server,we call it a localized approach. Note that this localizationdoesn’t mean that the information is not available locally: anew Map-Request would be routed in the DHT to the pre-viously mentioned server, and get the updated mapping as aresult.

The localized native approach needs three steps to com-plete a handover (see Fig. 3) whenever a MN moves to a VNin a different AS: authentication, intra-domain tunnel setup,and location update. The first step is related to a securityproblem posed by the need to preserve the node’s EID glob-ally: virtually anyone can claim ownership of an EID, with-outh a mechanism to verify the authenticity of such claims.Autonomous systems accepting visiting mobile nodes musthave an authentication mechanism in place in order to pre-vent false claims. The following paragraphs describe how avisiting node can be authenticated.

Authentication. The first step the MN must take in theVN is to authenticate and obtain a temporary local EID.This is similar to the Care-of Address (CoA) from MobileIP, with one important distinction: it is not used for com-munications with CNs, only for the signalling required toperform mobility-related tasks. In the following we will use

Figure 3: The proposed approach

the term signalling Address (SiA) for this address. Depend-ing on the VNs policies, the MN may be required to au-thenticate before obtaining the EID, using a layer 2 authen-tication method, after, by obtaining the SiA using DHCPand authenticating at the application layer, or both whichis the recommended approach. Commercial agreements be-tween providers are a good example of how this can be im-plemented at the policy level.

For the purposes of this paper, we distinguish two types ofauthentication: (i) the MN is accepted to the VN, but with-out proof of HoA ownership; (ii) HoA ownership is proven.Proof of HoA ownership means that the VN recognized theMN as the legitimate owner of his global EID. When au-thentication includes proof of ownership, the MN can di-rectly perform the location update procedure, othervise aseparate mechanism is needed to establish ownership.

This proof is required to make sure that the ETR on theVN side will accept, decapsulate and forward packets des-tined to the global EID of the MN. A return routability checkis a simple, practical method to establish a limited confi-dence level in ownership of an EID.

To perform the return routability check, the MN proceedsas follows: after authentication with the VN it contacts theETR of the AS to set up the tunnel within the domain. TheETR then sends two different cryptographic tokens to theHoA and to the SiA of the MN, which in turn combinesthem and send the result back. Being able to combine themessages proves that the node initiating the procedure isable to receive traffic at both addresses and gives the samelevel of security as we have in the current Internet.

The main problem of this approach is that ETRs areinvolved in computationally heavy work, generating andchecking cryptographic tokens, maintaining state for eachMN, which is not the typical workload of a border router.We discuss a possible solution for these problems in Sec-tion 5.

4

Intra-domain Tunnel Setup. After the xTR decides toaccept and forward traffic for the MN (it is authenticated),a mechanism is needed for the traffic flow within the vis-ited network’s premises. Packets arriving for the MN reachthe xTR, are decapsulated, an then they must be tunneledto the final destination. Also, packets originating from theMN have to be accepted by the xTR and encapsulated forthe transit space. To do this, the xTR can use the SiA as thetunnel endpoint for inter-domain forwarding, because it iseasily routable within the domain. After the tunnel is set up,the MN performs a location update and starts exchangingtraffic using this tunnel. It is worth noting here that more so-phisticated solutions for intra-domain mobility can be used(see [11, 12] as examples).

Location Update. The location update is the last step re-quired to perform the handover using the native approach.This is the step when the necessary changes to the mappingsystem are committed. To perform it, the MN contacts itsHA using his SiA from the VNs address space. Since thisaddress is authenticated, it can be used for global commu-nications. We assume that the HA has a preestablished trustrelationship with the MN, established upon the first regis-tration to the HN, so the MN can ask it to update its EID-to-RLOC mapping. The trust relationship is crucial to thesecurity of the MN, or else any node could hijack its com-munications.

The HA is not directly resposible for the mappings, itcontacts the mapping server of the AS on behalf of the MNwith the mapping update. The mapping server is part of thesame domain, it has a trust relationship with the HA too, andupdates the mapping. At this moment, any lookup for theMNs RLOC will result in the new location being returned.

The location update concludes the inter-domain han-dover, and the MN can start communicating using a direct(route optimized) path to its CNs. The next section dis-cusses the shortcomings of the above presented approachand offers the necessary architectural solutions for a morerealistic deployment.

5 EvaluationIn this section we review the improvements brought by thenative approach and contrast them with the inconvenients.We first evaluate from a qualitative point of view, followedby a quantitative evaluation (signalling overhead).

5.1 Qualitative AnalysisTo evaluate the localized native proposal, we take as a ref-erence point the existing overlay aproach and take a look atthe pros and cons relative to that. The improvements are:

1. Optimized routes from MN to CNs, even for IPv4.

2. No bottleneck at HA.

3. No need for mobility awareness at Correspondent Net-works (either hosts or routers).

Indeed, the native approach allows the MN to keep its EIDregardless of its point of attachement and communicate di-rectly with CNs. This results in significant performace im-provements, notably decreased round-trip delays. Sincetraffic doesn’t have to pass through the HN, the bottleneckat the HA is alleviated too. Additionally, there is no needto add any kind of mobility support at the CNs. This is avery important improvement, since not all destination hostswhich a MN may wish to access have an incentive to sup-port mobile clients. If there is a need to modify the networkstack or software configuration of any end hosts and/or net-works, it has to be done on the nomadic side of the connec-tion, i.e. MN, HN and VN. The localized native approachimplements this essential improvement.

Along with the improvements, we also have some disad-vantages, first of all the load at the border routers (xTRs) isincreased. To implement the localized native approach theyhave to assume additional tasks. During the authenticationphase they may be required to do a return routability check,involving the generation of cryptographic tokens, a compu-tationally intensive task. After the MN is authenticated theyhave to set up a tunnel to that node and update it accord-ing to its intra-domain movements. The xTR has to be ableto accept packets destined to an EID which is not part ofits own network (the HoA of the MN). Since these devicesmust handle large amounts of traffic at high speed they maynot cope with the extra load. One possible solution is tooffload these functions using a dedicated add-on module forthe router, or to a completely different entity. This separatedentity becomes responsible for the return routability check,can take part in the authentication, depending on the mech-anisms used, offloading these tasks from the tunnel routersimilarly to Foreign Agents in Mobile IP. We call these en-tities Mobility Agents (MA). Using MAs relieves the load onxTRs, but introduces another potential problem: traffic fromall the visiting MNs in the domain must pass through MAs,which may become a bottleneck for traffic. This problem iseasy to solve by progressively adding MAs to the domain,according to capacity planning. Many techniques exist thatprovide load balancing among similar entities. The secondmain issue is the need for a separate intra-domain mobilityprotocol. This is unavoidable, but it is not an essential prob-lem, and as it has been mentioned above many protocolshave been designed for this purpose [11, 12].

5.2 signalling Overhead ComparisonOne of the parameters that differentiate the two approachespresented before is the signalling overhead. In order to com-pare them, we built a simple mathematical model, countingthe number of signalling messages exchanged per second(OH) in each case. Mapping lookups were modeled basedon the average lookup path (the number of nodes that have

5

to be visited to resolve a query) for Chord: when the DHTis stabilized, 1

2 log2N nodes have to be traversed on average,where N is the number of participating nodes in the DHT[8]. The model denotes the mean number of handovers persecond with h, the mean number of connections to CNs indifferent ASes per MN with c and the grouping coefficientwith γ. pcm represents the probability of a mapping cachemiss, while pid stands for the probability that the handoverin question is inter-domain.

Based on the number of exchanged signalling messages,the overhead is calculated using the following equations.

OHoverlay = ((log2N · pcm +2log2N · pcm ·cγ

+8c)pid+

+8c(1− pid)) ·h

OHnative = ((4+ log2N)pcm +12

log2N · pcm ·cγ) · pid ·h

0 5000 100000

1

2

3x 105

handovers/sec

Sign

alin

g [m

sg/s

ec]

Basic, 30500 ASes

NativeOverlay

0 5000 100000

2

4

6

8

10x 106

handovers/sec

Sign

alin

g [m

sg/s

ec]

P2P, 30500 ASes

NativeOverlay

0 5000 100000

1

2

3x 105

handovers/sec

Sign

alin

g [m

sg/s

ec]

Basic, 65000 ASes

NativeOverlay

0 5000 100000

2

4

6

8

10x 106

handovers/sec

Sign

alin

g [m

sg/s

ec]

P2P, 65000 ASes

NativeOverlay

Figure 4: Signalling overhead comparison (in some figuresthe line which plots the native signalling is overlapped withthe x-axis)

Using MATLAB, we simulated two different scenarios:first, we assumed the MN uses only a browser, email andinstant messaging client (c = 3, γ = 2). The second sce-nario is based on relatively heavy peer-to-peer usage, withc = 100 connections and γ = 2. At the time of this writingthere were over 30500 ASes present in the Internet routingtables, according to APNIC so we set N = 30500. We hada different run for N = 65000, in order to consider futuregrowth. Iannone et al. determined the average cache missrate for ITRs at about 5% (pcm = 0.05) in [13]. Based onresults by Cuevas et al. using simulations of a realistic In-ternet topology in [14] we chose pid = 0.01. As we cansee in Fig. 4, signalling overhead increases linearly withthe handover rate, but much faster in the case of the overlayapproach. This trend is even more remarkable in the caseof using peer-to-peer. The doubling of the number of au-tonomous systems has little impact on the results, showing

that the choice of mapping system is very scalable in termsof signalling.

6 ConclusionsIn this paper we explored one architectural solution to addfast endpoint mobility support to the LISP-enabled globalInternet. To the best of our knowledge this is the first studyexploring this problem space. We showed that this solu-tion enables a route optimized path between the MN and allCNs, while it requires no mobility awareness at the CNs.We believe this a feasable solution, because the large de-ployed base of hosts that a MN may want to contact neednot modify its software to support mobile clients. The onlymodifications have to be done to the LISP mapping system,which is still open for discussion. We believe that we shouldtake this opportunity to offer native mobility.

References[1] D. Meyer et al. “Report from the IAB Workshop on Routing

and Addressing.” RFC 4984, Sept. 2007.

[2] D. Farinacci et al. “Locator/ID Separation Protocol (LISP).”IETF draft. Mar. 2009

[3] C. Perkins, “IP Mobility Support for IPv4.” RFC 3344 Aug.2002.

[4] D. Johnson et al. “Mobility Support in IPv6.” RFC 3775,June 2004.

[5] D. Farinacci et al. “LISP Alternative Topology(LISP+ALT).” IETF draft, Feb. 2009.

[6] L. Mathy et al. “LISP-DHT: Towards a DHT to map identi-fiers onto locators.” IETF draft, Feb. 2008.

[7] S. Brim et al. “LISP-CONS: A Content distribution OverlayNetwork Service for LISP.” IETF draft Apr. 2008.

[8] I. Stoica et al. “Chord: A scalable peer-to-peer lookup proto-col for internet applications,” in IEEE/ACM Trans. of Netw.2003

[9] G. Huston et al. “A Profile for X.509 PKIX Resource Certifi-cates.” IETF draft, Feb. 2009.

[10] C. Ng et al. “Network Mobility Route Optimization ProblemStatement.” RFC 4888, July 2007.

[11] H. Soliman et al.“Hierarchical Mobile IPv6 Mobility Man-agement (HMIPv6).” RFC 4140, Aug. 2005.

[12] S. Gundavelli et al. “Proxy Mobile IPv6.” RFC 5213, Aug.2008.

[13] L. Iannone et al. “On the cost of caching Locator/ID map-pings,” in Proc. of CoNEXT 2007

[14] R. Cuevas et al. “fP2P–HN: A P2P-based route optimiza-tion architecture for mobile IP-based community networks,”ComNet 2009

6