mipagent

- Mobile IP agent

Synopsis

/usr/lib/inet/mipagent

Description

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.

Diagnostics

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.

Notes

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.