While choosing a trigger at an 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 such that the trigger is stored at an server close to the CH instead of itself. This would result in a low latency stretch without compromising the MH's location privacy. Let 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 to share the first 128 bits with . This is because with , all triggers whose identifiers share the same 128-bit prefix are stored at the same server .
To also allow fast handoff, the MH can use two triggers, one of the form 5inserted near the CH, and one of the form 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 to the MH. Because the CH does not need to know , the location privacy of the MH is ensured. Moreover, the choice of and ensures a low latency stretch, and enables the MH to do fast handoff by updating trigger .
If both end-points require location privacy, they can choose completely random servers. The flexibility of allows each application to make the tradeoff between location privacy and routing efficiency as desired.