Location Privacy

Figure: Achieving location privacy: (a) MH chooses a trigger close to the CH; (b) MH uses two triggers to preserve fast handoff.

While choosing a trigger $(id, MH)$ at an $i3$server close to the MH improves the routing and handoff efficiency, this choice would reveal (to some extent) the location of the MH. To avoid this problem, the MH can choose $id$ such that the trigger is stored at an $i3$server close to the CH instead of itself. This would result in a low latency stretch without compromising the MH's location privacy. Let $(id_1, CH)$ be the trigger advertised by the CH to the MH (see Figure 4(a)). Assuming that the CH chooses this trigger close to itself, the MH can simply choose $id$ to share the first 128 bits with $id_1$. This is because with $i3$, all triggers whose identifiers share the same 128-bit prefix are stored at the same $i3$server [6].

To also allow fast handoff, the MH can use two triggers, one of the form $(id, id')$ ⁵inserted near the CH, and one of the form $(id', MH)$ inserted close to itself (see Figure 4(a)). Note that this change is transparent to the CH, i.e., the CH will still send packets of the form $(id, data)$ to the MH. Because the CH does not need to know $id'$, the location privacy of the MH is ensured. Moreover, the choice of $id$ and $id'$ ensures a low latency stretch, and enables the MH to do fast handoff by updating trigger $(id', MH)$.

If both end-points require location privacy, they can choose completely random $i3$servers. The flexibility of $i3$allows each application to make the tradeoff between location privacy and routing efficiency as desired.