- Mobile IP agent
The mipagent utility implements the Mobile IP home agent and foreign agent functionality described in RFC 2002, IP Mobility Support. The term “mobility agent” is used to refer to the home agent and foreign agent functionality collectively. mipagent responds to Mobile IP registration and deregistration requests and router discovery solicitation messages from a mobile node. Besides responding to external messages, the mipagent utility also tasks on a periodic basis, such as aging the mobility bindings and visitor entries and sending agent advertisements. The mobility agent can also handle direct delivery style reverse tunneling as specified in RFC 2344, Reverse Tunneling for Mobile IP. Limited private address support for mobile nodes is also available. In addition, separate IPsec policies for registration requests, replies, and tunnel traffic can be configured to protect the datagrams associated with these between two mobility agents.
Run the mipagent daemon as root using the start-up script, which has the following syntax:
example# /etc/init.d/mipagent [start|stop]
/etc/inet/mipagent.conf must be present before you start-up the mipagent daemon. See mipagent.conf(4). At start up, mipagent reads the configuration information from /etc/inet/mipagent.conf. The mipagent daemon records a continuous log of its activities by means of syslog(). See syslog(3C). You can use the LogVerbosity parameter in /etc/inet/mipagent.conf to control the verbosity level of the log.
The mipagent daemon can be terminated either by the script:
example# /etc/init.d/mipagent stop
or by the kill command.
Periodically while running, or if terminated or shutdown, the mipagent daemon stores the following internal state information in /var/inet/mipagent_state:
a list of the mobile nodes supported as home agents;
their current care-of addresses; and
the remaining registration lifetimes.
If the mipagent utility is terminated for maintenance and restarted, mipagent_state is used to recreate as much of the mobility agent's internal state as possible. This minimizes service disruption for mobile nodes that may be visiting other networks. If mipagent_state exists, it is read immediately after mipagent.conf when mipagent is restarted. The format of mipagent_state is undocumented since it is likely to change and programs other than mipagent should not use it for any purpose. A separate utility program mipagentstat is provided for monitoring mipagent.
The following exit values are returned:
The daemon started successfully.
The daemon failed to start.
Configuration file for Mobile IP mobility agent.
File where private state information from mipagent is stored.
mipagent start-up script.
See attributes(5) for descriptions of the following attributes:
Montenegro, G., editor.RFC 2344, Reverse Tunneling for Mobile IP. Network Working Group. May 1998.
Perkins, C. RFC 2002, IP Mobility Support. Network Working Group. October 1996.
The mipagent utility exits with an error if the configuration file, mipagent.conf, cannot be read successfully. Upon receiving a SIGTERM or SIGINT signal, mipagent cleans its internal state, including any changes to the routing and ARP tables, and exits.
The foreign agent adds host– specific local routes to its routing table for visiting mobile nodes after they are successfully registered. If a visiting mobile node departs without sending a de-registration message through the foreign agent, these routing entries persist until the mobile node's previous registration expires. Any packets that arrive at the foreign agent for the departed mobile node during this time, for example because the foreign agent is also a router for the foreign network, will be lost. System administrators can configure foreign agents to accept only short registration lifetimes. This will automatically restrict the maximum duration for which a departed mobile node will be temporarily unreachable.
Home and foreign agents dynamically add and delete IPsec policies configured with a mobility agent peer. Those pertaining to the tunnel are only added when the tunnel is plumbed. At this time, IPsec tunnel policies must be identical in the forward and reverse direction. IPsec policies pertaining to permiting registration requests on the home agent are added to the IPsec policy file at init time as it must be ready to receive these at any time. Otherwise, IPsec policies pertaining to registration request and reply messages with a mobility agent peer are added as soon as they are needed, and are not removed until all mobile nodes are no longer registered with the mobility agent peer, at which point the tunnels are torn down.