Network-based, Localized Mobility Management – the Problem James Kempf DoCoMo Labs USA

Why Not Use Global Mobility Management on Every Subnet Move? If correspondent and/or global routing anchor is topologically far away, high update latency results in dropped packets Amount of signaling to come up on a new subnet, including subnet configuration and global mobility management, is prohibitive Changes in the care-of address on host can reveal a mobile node’s topological and geographical location to an undesirable granularity

What’s Changed? IETF has been working on this problem for about 5 years –MIP related protocols – HMIP, FMIP, LLMIPv4 Experimental, FMIP about to go PS track –Micromobility routing protocols – no real progress Last year has seen two important trends –In IETF, new, non-MIP related global mobility management protocols have arisen HIP, Mobike* –In market, WLAN Switches have taken over Proprietary IP Mobility allows MN to move between switches of same vendor in different subnets without changing its IP address No change in MN protocol stack required!! Customers really like this approach (otherwise they wouldn’t be buying it) *Note: Mobike is not really a global mobility management protocol even though it behaves like one

Problems with Experimental IETF Protocols Changes required in host stack –Localized mobility management can’t be used by any host Designed to support Mobile IPv6 –Other mobility management protocols are not supported Security issues –Because localized mobility management is a service provided to a host, auth/authz required between host and localized mobility server Security association required between every roaming partner’s network and every roamed MN –Virus/mal-ware on host can expose host’s local care-of address or address of localized mobility server in network Opens MN’s location privacy and server’s security to Internet-wide attack

Problems with WLAN Switch Solutions Some are very 802.3/ specific –Need a protocol that works on any link technology Protocols are proprietary –No interoperablity between different vendors’ solutions –Note: This is NOT a CAPWAP issue! Scaling up to wide area questionable

New Solution Sought Localized mobility management is provided by the network as a routing-style service Auth/Authz for network access is sufficient to authorize MN for localized mobility management –I.e. localized mobility management is provided as part of the basic IP routing service with no additional authorization required Minimize special IP level software required on the host –Drivers or IP movement detection OK Host’s IP addresses do not change as it moves across the localized mobility management domain Works across wide area on any combination of link/wireless technologies