-mobility protocols operate across domains. The legacy applications can still be used unchanged with a mobility protocol in this layer. But this protocol requires operating system level modification in the MH operating system to implement the functions specific to network-layer mobility (e.g., the registration messages in Mobile IP). Architecturally, the network layer is the "right layer" to provide mobility for all transports and all applications. For a variety of reasons, such as ingress C 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security filtering or non-deployment of mobility agents, network-layer mechanisms have not been widely deployed to-date, although many of these issues have been addressed in the Mobile IPv6 proposal [5]. The availability of workable micro- mobility mechanisms may, however, increase the attractiveness of Mobile IP in the future. 17.3.3 Transport Layer The transport layer maintains the true end-to-end connection, whereas the lower layer is completely ignorant of this end-to-end semantic. As mobility protocol implementation moves upward in the protocol stack, its binding with applications grows stronger. The interface between the application and trans- port layers gets changed with the introduction of a transport-layer mobility protocol. Of course, there are proposals like TCP Migrate [6] to keep the inter- face unchanged, but they involve substantial change in the network, such as the introduction of a proxy server and changes in the MH kernel. Thus, they are neither scalable nor deployable on a global basis. However, there are two ways to get around the interface change problem. One way is to recompile all the applications with the modified interface to the transport layer; the other is to put a wrapper around the transport layer libraries that the applications use. Both solutions are fairly costly and hence not widely accepted or deployed. Transport-layer mobility solutions suffer from an additional disadvantage: they require modified transport laye