Part V Mobile IP

This part introduces Mobile Internet Protocol (Mobile IP) and contains tasks for Mobile IP administration. You can install Mobile IP on systems such as laptops and wireless communications, enabling these computers to operate on foreign networks.

The Mobile IP feature has been removed from all Oracle Solaris updates after Solaris 10 8/07.

Chapter 27 Mobile IP (Overview)

Mobile Internet Protocol (IP) enables the transfer of information between mobile computers. Mobile computers include lap tops and wireless communications. The mobile computer can change its location to a foreign network. At the foreign network, the mobile computer can still communicate through the home network of the mobile computer. The Solaris implementation of Mobile IP supports only IPv4.

This chapter contains the following information:

• Introduction to Mobile IP

• Mobile IP Functional Entities

• How Mobile IP Works

• Agent Discovery

• Care-of Addresses

• Mobile IP With Reverse Tunneling

• Mobile IP Registration

• Routing Datagrams to and From Mobile Nodes

• Security Considerations for Mobile IP

For Mobile IP-related tasks, refer to Chapter 28, Administering Mobile IP (Tasks). For Mobile IP reference materials, refer to Chapter 29, Mobile IP Files and Commands (Reference).

What's New in Mobile IP

The Mobile IP feature is removed from Solaris 10 updates after Solaris 10 8/07.

Introduction to Mobile IP

Current versions of the Internet Protocol (IP) assume that the point at which a computer attaches to the Internet or a network is fixed. IP also assumes that the IP address of the computer identifies the network to which the computer is attached. Datagrams that are sent to a computer are based on the location information that is contained in the IP address. Many Internet Protocols require that a node's IP address remain unchanged. If any of these protocols are active on a Mobile IP computing device, their applications fail. Even HTTP would fail if not for the short-lived nature of its TCP connections. Updating an IP address and refreshing the web page is not a burden.

If a mobile computer, or mobile node, moves to a new network while its IP address is unchanged, the mobile node address does not reflect the new point of attachment. Consequently, routing protocols that exist cannot route datagrams to the mobile node correctly. You must reconfigure the mobile node with a different IP address that represents the new location. Assigning a different IP address is cumbersome. Thus, under the current Internet Protocol, if the mobile node moves without changing its address, it loses routing. If the mobile node does change its address, it loses connections.

Mobile IP solves this problem by allowing the mobile node to use two IP addresses. The first address is a fixed home address. The second address is a care-of address that changes at each new point of attachment. Mobile IP enables a computer to roam freely on the Internet. Mobile IP also enables a computer to roam freely on an organization's network while still maintaining the same home address. Consequently, communication activities are not disrupted when the user changes the computer's point of attachment. Instead, the network is updated with the new location of the mobile node. See the Glossary for definitions of terms that are associated with Mobile IP.

The following figure illustrates the general Mobile IP topology.

Figure 27–1 Mobile IP Topology

By using this figure's Mobile IP topology, the following scenario shows how a datagram moves from one point to another point within the Mobile IP framework:

1. The Internet host sends a datagram to the mobile node by using the mobile node's home address (normal IP routing process).

2. If the mobile node is on its home network, the datagram is delivered through the normal IP process to the mobile node. Otherwise, the home agent receives the datagram.

3. If the mobile node is on a foreign network, the home agent forwards the datagram to the foreign agent. The home agent must encapsulate the datagram in an outer datagram so that the foreign agent's IP address appears in the outer IP header.

4. The foreign agent delivers the datagram to the mobile node.

5. Datagrams from the mobile node to the Internet host are sent by using normal IP routing procedures. If the mobile node is on a foreign network, the packets are delivered to the foreign agent. The foreign agent forwards the datagram to the Internet host.

6. In situations with ingress filtering present, the source address must be topologically correct for the subnet that the datagram is coming from, or a router cannot forward the datagram. If this scenario exists on links between the mobile node and the correspondent node, the foreign agent needs to provide reverse tunneling support. Then, the foreign agent can deliver every datagram that the mobile node sends to its home agent. The home agent then forwards the datagram through the path that the datagram would have taken had the mobile node resided on the home network. This process guarantees that the source address is correct for all links that the datagram must traverse.

Regarding wireless communications, Figure 27–1 depicts the use of wireless transceivers to transmit the datagrams to the mobile node. Also, all datagrams between the Internet host and the mobile node use the home address of the mobile node. The home address is used even when the mobile node is located on the foreign network. The care-of address is used only for communication with mobility agents. The care-of address is invisible to the Internet host.

Mobile IP Functional Entities

Mobile IP introduces the following new functional entities:

• Mobile node (MN) – Host or router that changes its point of attachment from one network to another network while maintaining all existing communications by using its IP home address.

• Home agent (HA) – Router or server on the home network of a mobile node. The router intercepts datagrams that are destined for the mobile node. The router then delivers the datagrams through the care-of address. The home agent also maintains current information on the location of the mobile node.

• Foreign agent (FA) – Router or server on the foreign network that the mobile node visits. Provides host routing services to the mobile node. The foreign agent might also provide a care-of address to the mobile node while the mobile node is registered.

How Mobile IP Works

Mobile IP enables routing of IP datagrams to mobile nodes. The home address of the mobile node always identifies the mobile node regardless of where the mobile node is attached. When away from home, a care-of address is associated with the mobile node's home address. The care-of address provides information about the current point of attachment of the mobile node. Mobile IP uses a registration mechanism to register the care-of address with a home agent.

The home agent redirects datagrams from the home network to the care-of address. The home agent constructs a new IP header that contains the care-of address of the mobile node as the destination IP address. This new header encapsulates the original IP datagram. Consequently, the home address of the mobile node has no effect on the routing of the encapsulated datagram until the datagram arrives at the care-of address. This type of encapsulation is called tunneling. After the datagram arrives at the care-of address, the datagram is de-encapsulated. Then the datagram is delivered to the mobile node.

The following figure shows a mobile node that resides on its home network, Network A, before the mobile node moves to a foreign network, Network B. Both networks support Mobile IP. The mobile node is always associated with the home address of the mobile node, 128.226.3.30.

Figure 27–2 Mobile Node Residing on Home Network

The following figure shows a mobile node that has moved to a foreign network, Network B. Datagrams that are destined for the mobile node are intercepted by the home agent on the home network, Network A. The datagrams are encapsulated. Then, the datagrams are sent to the foreign agent on Network B. The foreign agent strips off the outer header. Then the foreign agent delivers the datagram to the mobile node that is located on Network B.

Figure 27–3 Mobile Node Moving to a Foreign Network

The care-of address might belong to a foreign agent. The care-of address might be acquired by the mobile node through the Dynamic Host Configuration Protocol (DHCP) or the Point-to-Point Protocol (PPP). In the latter situation, a mobile node has a colocated care-of address.

Mobility agents (home agents and foreign agents) advertise their presence by using agent advertisement messages. Optionally, a mobile node can solicit an agent advertisement message. The mobile node uses any mobility agent that is attached locally through an agent solicitation message. A mobile node uses the agent advertisements to determine whether the mobile node is on the home network or a foreign network.

The mobile node uses a special registration process to inform the home agent about the current location of the mobile node. The mobile node is always “listening” for mobility agents advertising their presence. The mobile node uses these advertisements to help determine when the mobile node moves to another subnet. When a mobile node determines that the mobile node has moved its location, the mobile node uses the new foreign agent to forward a registration message to the home agent. The mobile node uses the same process when the mobile node moves from one foreign network to another foreign network.

When the mobile node detects that it is located on the home network, the mobile node does not use mobility services. When the mobile node returns to the home network, the mobile node deregisters with the home agent.

Agent Discovery

A mobile node uses a method that is known as agent discovery to determine the following information:

• When the node has moved from one network to another network

• Whether the network is the home network or a foreign network

• The foreign agent care-of address that is offered by each foreign agent on that network

• Mobility services that are provided by the mobility agent, advertised as flags, and additional extensions in the agent advertisement

Mobility agents transmit agent advertisements to advertise services on a network. In the absence of agent advertisements, a mobile node can solicit advertisements. This capability is known as agent solicitation. If a mobile node is capable of supporting its own colocated care-of address, the mobile node can use regular router advertisements for the same purposes.

Agent Advertisement

Mobile nodes use agent advertisements to determine the current point of attachment to the Internet or to an organization's network. An agent advertisement is an Internet Control Message Protocol (ICMP) router advertisement that has been extended to also carry a mobility agent advertisement extension.

A foreign agent (FA) can be too busy to serve additional mobile nodes. However, a foreign agent must continue to send agent advertisements. Then, the mobile node, which is already registered with a foreign agent, knows that the mobile node has not moved out of range of the foreign agent. The mobile node also knows that the foreign agent has not failed. A mobile node that is registered with a foreign agent from which it no longer receives agent advertisements probably knows that the mobile node can no longer contact that foreign agent.

Agent Advertisement Over Dynamic Interfaces

You can configure the implementation of the foreign agent to send advertisements over dynamically created interfaces. You have options to enable or disable limited unsolicited advertisements over the advertising interfaces. Dynamically created interfaces are defined as only those interfaces that are configured after the mipagent daemon starts. Advertisement over dynamic interfaces is useful for applications that support transient mobility interfaces. Moreover, by limiting unsolicited advertisement, network bandwidth might be saved.

Agent Solicitation

Every mobile node should implement agent solicitation. The mobile node uses the same procedures, defaults, and constants for agent solicitation that are specified for solicitation messages of ICMP routers.

The rate that a mobile node sends solicitations is limited by the mobile node. The mobile node can send three initial solicitations at a maximum rate of one solicitation per second while the mobile node searches for an agent. After the mobile node registers with an agent, the rate that solicitations are sent is reduced to limit the overhead on the local network.

Care-of Addresses

Mobile IP provides the following alternative modes for the acquisition of a care-of address:

• A foreign agent provides a foreign agent care-of address, which is advertised to the mobile node through agent advertisement messages. The care-of address is usually the IP address of the foreign agent that sends the advertisements. The foreign agent is the endpoint of the tunnel. When the foreign agent receives datagrams through a tunnel, the foreign agent de-encapsulates the datagrams. Then, the foreign agent delivers the inner datagram to the mobile node. Consequently, many mobile nodes can share the same care-of address. Bandwidth is important on wireless links. Wireless links are good candidates from which foreign agents can provide Mobile IP services to higher bandwidth-wired links.

• A mobile node acquires a colocated care-of address as a local IP address through some external means. The mobile node then associates with one of its own network interfaces. The mobile node might acquire the address through DHCP as a temporary address. The address might also be owned by the mobile node as a long-term address. However, the mobile node can only use the address while visiting the subnet to which this care-of address belongs. When using a colocated care-of address, the mobile node serves as the endpoint of the tunnel. The mobile node performs de-encapsulation of the datagrams that are tunneled to the mobile node.

A colocated care-of address enables a mobile node to function without a foreign agent. Consequently, a mobile node can use a colocated care-of address in networks that have not deployed a foreign agent.

If a mobile node is using a colocated care-of address, the mobile node must be located on the link that is identified by the network prefix of the care-of address. Otherwise, datagrams that are destined to the care-of address cannot be delivered.

Mobile IP With Reverse Tunneling

The section How Mobile IP Works assumes that the routing within the Internet is independent of the source address of the datagram. However, intermediate routers might check for a topologically correct source address. If an intermediate router does check, the mobile node needs to set up a reverse tunnel. By setting up a reverse tunnel from the care-of address to the home agent, you ensure a topologically correct source address for the IP data packet. Reverse tunnel support is advertised by foreign agents and home agents. A mobile node can request a reverse tunnel between the foreign agent and the home agent when the mobile node registers. A reverse tunnel is a tunnel that starts at the care-of address of the mobile node and terminates at the home agent. The following figure shows the Mobile IP topology that uses a reverse tunnel.

Figure 27–4 Mobile IP With a Reverse Tunnel

Limited Private Addresses Support

Mobile nodes that have private addresses that are not globally routeable through the Internet require reverse tunnels. Solaris Mobile IP supports mobile nodes that are privately addressed. See Overview of the Solaris Mobile IP Implementation for the functions that Solaris Mobile IP does not support.

Enterprises employ private addresses when external connectivity is not required. Private addresses are not routeable through the Internet. When a mobile node has a private address, the mobile node can only communicate with a correspondent node by having its datagrams reverse-tunneled to its home agent. The home agent then delivers the datagram to the correspondent node in whatever manner the datagram is normally delivered when the mobile node is at home. The following figure shows a network topology with two mobile nodes that are privately addressed. The two mobile nodes use the same care-of address when they are registered to the same foreign agent.

Figure 27–5 Privately Addressed Mobile Nodes Residing on the Same Foreign Network

The care-of address and the home agent address must be globally routeable addresses if these addresses belong to different domains that are connected by a public Internet.

The same foreign network can include two mobile nodes that are privately addressed with the same IP address. However, each mobile node must have a different home agent. Also, each mobile node must be on different advertising subnets of a single foreign agent. The following figure shows a network topology that depicts this situation.

Figure 27–6 Privately Addressed Mobile Nodes Residing on Different Foreign Networks

Mobile IP Registration

Mobile nodes detect when they have moved from one subnet to another subnet through the use of agent advertisements. When the mobile node receives an agent advertisement that indicates that the mobile node has changed locations, the mobile node registers through a foreign agent. Even though the mobile node might have acquired its own colocated care-of address, this feature is provided to enable sites to restrict access to mobility services.

Mobile IP registration provides a flexible mechanism for mobile nodes to communicate the current reachability information to the home agent. The registration process enables mobile nodes to perform the following tasks:

• Request forwarding services when visiting a foreign network

• Inform the home agent of the current care-of address

• Renew a registration that is about to expire

• Deregister when the mobile node returns home

• Request a reverse tunnel

Registration messages exchange information between a mobile node, a foreign agent, and the home agent. Registration creates or modifies a mobility binding at the home agent. Registration associates the home address of the mobile node with the care-of address of the mobile node for the specified lifetime.

The registration process also enables mobile nodes to do the following functions:

• Register with multiple foreign agents

• Deregister specific care-of addresses while retaining other mobility bindings

• Discover the address of a home agent if the mobile node is not configured with this information

Mobile IP defines the following registration processes for a mobile node:

• If a mobile node registers a foreign agent care-of address, the mobile node is informing the home agent that it is reachable through that foreign agent.

• If a mobile node receives an agent advertisement that requires the mobile node to register through a foreign agent, the mobile node can still attempt to obtain a colocated care-of address. The mobile node can also register with that foreign agent or any other foreign agent on that link.

• If a mobile node uses a colocated care-of address, the mobile node registers directly with the home agent.

• If a mobile node returns to the home network, the mobile node deregisters with the home agent.

These registration processes involve the exchange of registration requests and registration reply messages. When the mobile node registers by using a foreign agent, the registration process takes the following steps, which the subsequent figure shows:

1. The mobile node sends a registration request to the prospective foreign agent to begin the registration process.

2. The foreign agent processes the registration request and then relays the request to the home agent.

3. The home agent sends a registration reply to the foreign agent to grant or deny the request.

4. The foreign agent processes the registration reply and then relays the reply to the mobile node to inform the mobile node of the disposition of the request.

Figure 27–7 Mobile IP Registration Process

When the mobile node registers directly with the home agent, the registration process requires only the following steps:

• The mobile node sends a registration request to the home agent.

• The home agent sends a registration reply to the mobile node that grants or denies the request.

Also, either the foreign agent or the home agent might require a reverse tunnel. If the foreign agent supports reverse tunneling, the mobile node uses the registration process to request a reverse tunnel. The mobile node sets the reverse tunnel flag in the registration request to request a reverse tunnel.

Network Access Identifier (NAI)

Authentication, authorization, and accounting (AAA) servers, in use within the Internet, provide authentication and authorization services for dialup computers. These services are likely to be equally valuable for mobile nodes that use Mobile IP when the nodes attempt to connect to foreign domains with AAA servers. AAA servers use the Network Access Identifier (NAI) to identify clients. A mobile node can identify itself by including the NAI in the Mobile IP registration request.

Because the NAI is typically used to uniquely identify the mobile node, the home address of the mobile node is not always necessary to provide that function. Thus, a mobile node can authenticate itself. Consequently, a mobile node can be authorized for connection to the foreign domain without even having a home address. To request that a home address be assigned, a message that contains the mobile node NAI extension can set the home address field to zero in the registration request.

Mobile IP Message Authentication

Each mobile node, foreign agent, and home agent supports a mobility security association between the various Mobile IP components. The security association is indexed by the security parameter index (SPI) and IP address. In the instance of the mobile node, this address is the home address of the mobile node. Registration messages between a mobile node and the home agent are authenticated with the mobile-home authentication extension. In addition to mobile-home authentication, which is mandatory, you can use the optional mobile-foreign agent and home-foreign agent authentications.

Mobile Node Registration Request

A mobile node uses a registration request message to register with the home agent. Thus, the home agent can create or modify a mobility binding for that mobile node (for example, with a new lifetime). The foreign agent can relay the registration request to the home agent. However, if the mobile node is registering a colocated care-of address, then the mobile node can send the registration request directly to the home agent. If the foreign agent advertises that registration messages must be sent to the foreign agent, then the mobile node must send the registration request to the foreign agent.

Registration Reply Message

A mobility agent returns a registration reply message to a mobile node that has sent a registration request message. If the mobile node requests service from a foreign agent, that foreign agent receives the reply from the home agent. Subsequently, the foreign agent relays the reply to the mobile node. The reply message contains the necessary codes to inform the mobile node and the foreign agent about the status of the registration request. The message also contains the lifetime that is granted by the home agent. The lifetime can be smaller than the original request. The registration reply can also contain a dynamic home address assignment.

Foreign Agent Considerations

The foreign agent plays a mostly passive role in Mobile IP registration. The foreign agent adds all mobile nodes that are registered to the visitor table. The foreign agent relays registration requests between mobile nodes and home agents. Also, when the foreign agent provides the care-of address, the foreign agent de-encapsulates datagrams for delivery to the mobile node. The foreign agent also sends periodic agent advertisement messages to advertise the presence of the foreign agent.

If home agents and foreign agents support reverse tunnels, and the mobile node requests a reverse tunnel, the foreign agent then tunnels all the packets from the mobile node to the home agent. The home agent then sends the packets to the correspondent node. This process is the reverse of the home agent tunneling all of the mobile node's packets to the foreign agent for delivery to the mobile node. A foreign agent that supports reverse tunnels advertises that the reverse tunnel is supported for registration. Because of the local policy, the foreign agent can deny a registration request when the reverse tunnel flag is not set. The foreign agent can only distinguish multiple mobile nodes with the same (private) IP address when these mobile nodes are visiting different interfaces on the foreign agent. In the forward tunnel situation, the foreign agent distinguishes between multiple mobile nodes that share the same private addresses by looking at the incoming tunnel interface. The incoming tunnel interface maps to a unique home agent address.

Home Agent Considerations

Home agents play an active role in the registration process. The home agent receives registration requests from the mobile node. The registration request might be relayed by the foreign agent. The home agent updates its record of the mobility bindings for this mobile node. The home agent issues a suitable registration reply in response to each registration request. The home agent also forwards packets to the mobile node when the mobile node is away from the home network.

A home agent might not have to have a physical subnet configured for mobile nodes. However, the home agent must recognize the home address of the mobile node through the mipagent.conf file or some other mechanism when the home agent grants registration. For more information about mipagent.conf, refer to Creating the Mobile IP Configuration File.

A home agent can support private addressed mobile nodes by configuring the private addressed mobile nodes in the mipagent.conf file. The home addresses that are used by the home agent must be unique.

Dynamic Home Agent Discovery

In some situations, the mobile node might not know the home agent address when the mobile node attempts to register. If the mobile node does not know the home agent address, the mobile node can use dynamic home agent address resolution to learn the address. In this situation, the mobile node sets the home agent field of the registration request to the subnet-directed broadcast address of its home network. Each home agent that receives a registration request with a broadcast destination address rejects the mobile node's registration by returning a rejection registration reply. By doing so, the mobile node can use the home agent's unicast IP address that is indicated in the rejection reply when the mobile node next attempts registration.

Routing Datagrams to and From Mobile Nodes

This section describes how mobile nodes, home agents, and foreign agents cooperate to route datagrams for mobile nodes that are connected to a foreign network. See Overview of the Solaris Mobile IP Implementation for Mobile IP functions that are supported in the Solaris OS.

Encapsulation Methods

Home agents and foreign agents use one of the available encapsulation methods to support datagrams that use a tunnel. Defined encapsulation methods are IP-in-IP Encapsulation, Minimal Encapsulation, and Generic Routing Encapsulation. Foreign agent and home agent cases, or indirect colocated mobile node and home agent cases, must support the same encapsulation method. All Mobile IP entities are required to support IP-in-IP Encapsulation.

Unicast Datagram Routing

When registered on a foreign network, the mobile node uses the following rules to choose a default router:

• If the mobile node is registered and uses a foreign agent care-of address, the process is straightforward. The mobile node chooses its default router from among the router addresses that are advertised in the ICMP router advertisement portion of that agent advertisement. The mobile node can also consider the IP source address of the agent advertisement as another possible choice for the IP address of a default router.

• The mobile node might be registered directly with the home agent by using a colocated care-of address. Then, the mobile node chooses its default router from among those routers that are advertised in any ICMP router advertisement message that it receives. The network prefix of the chosen default router must match the network prefix of the care-of address of the mobile node that is externally obtained. The address might match the IP source address of the agent advertisement under the network prefix. Then, the mobile node can also consider that IP source address as another possible choice for the IP address of a default router.

• If the mobile node is registered, a foreign agent that supports reverse tunnels routes unicast datagrams from the mobile node to the home agent through the reverse tunnel. If the mobile node is registered with a foreign agent that provides reverse tunnel support, the mobile node must use that foreign agent as its default router.

Broadcast Datagrams

When a home agent receives a broadcast datagram or multicast datagram, the home agent only forwards the datagram to mobile nodes that have specifically requested that they receive them. How the home agent forwards broadcast and multicast datagrams to mobile nodes depends primarily on two factors. Either that mobile node is using a foreign-agent provided care-of address, or the mobile node is using its own colocated care-of address. The former means that the datagram must be double encapsulated. The first IP header identifies the mobile node for which the datagram is to be delivered. This first IP header is not present in the broadcast or multicast datagram. The second IP header identifies the care-of address, and is the usual tunnel header. In the latter instance, the mobile node is decapsulating its own datagrams, and the datagram needs only to be sent through the regular tunnel.

Multicast Datagram Routing

To begin receiving multicast traffic when a mobile node is visiting a foreign subnet, a mobile node can join a multicast group in any of the following ways:

• If the mobile node is using a colocated care-of address, the mobile node can use this address as the source IP address of any Internet Group Management Protocol (IGMP) join messages. However, a multicast router must be present on the visited subnet.

• If the mobile node wants to join the ICMP group from its home subnet, the mobile node must use a reverse tunnel to send IGMP join messages to the home agent. However, the mobile node's home agent must be a multicast router. The home agent then forwards multicast datagrams through the tunnel to the mobile node.

• If the mobile node is using a colocated care-of address, the mobile node can use this address as the source IP address of any IGMP join messages. However, a multicast router must be present on the visited subnet. After the mobile node has joined the group, the mobile node can participate by sending its own multicast packets directly on the visited network.

• Send directly on the visited network.

• Send through a tunnel to the home agent.

Multicast routing depends on the IP source address. A mobile node that is sending a multicast datagram must send the datagram from a valid source address on that link. So a mobile node that is sending multicast datagrams directly on the visited network must use a colocated care-of address as the IP source address. Also, the mobile node must have joined the multicast group that is associated with the address. Similarly, a mobile node that joined a multicast group while on its home subnet before roaming, or joined the multicast group while roaming through a reverse tunnel to its home agent, must use its home address as the IP source address of the multicast datagram. Thus, the mobile node must have these datagrams reverse-tunneled to its home subnet as well, either through itself by using its colocated care-of address, or through a foreign agent reverse tunnel.

While it seems more efficient for a mobile node to always join from the subnet that the mobile node is visiting, it is still a mobile node. Consequently, the mobile node would have to repeat the join every time the mobile node switches subnets. The more efficient way is for the mobile node to join through its home agent, and not have to carry this overhead. Also, multicast sessions might be present that are only available from the home subnet. Other considerations might also force the mobile node to participate in a specific way.

Security Considerations for Mobile IP

In many situations, mobile computers use wireless links to connect to the network. Wireless links are particularly vulnerable to passive eavesdropping, active replay attacks, and other active attacks.

Because Mobile IP recognizes its inability to reduce or eliminate this vulnerability, Mobile IP uses a form of authentication to protect Mobile IP registration messages from these types of attack. The default algorithm that is used is MD5, with a key size of 128 bits. The default operational mode requires that this 128-bit key precede and succeed the data to be hashed. The foreign agent uses MD5 to support authentication. The foreign agent also uses key sizes of 128 bits or greater, with manual key distribution. Mobile IP can support more authentication algorithms, algorithm modes, key distribution methods, and key sizes.

These methods do prevent Mobile IP registration messages from being altered. However, Mobile IP also uses a form of replay protection to alert Mobile IP entities when they receive duplicates of previous Mobile IP registration messages. If this protection method were not used, the mobile node and its home agent might become unsynchronized when either of them receives a registration message. Hence, Mobile IP updates its state. For example, a home agent receives a duplicate deregistration message while the mobile node is registered through a foreign agent.

Replay protection is ensured either by a method known as nonces, or timestamps. Nonces and timestamps are exchanged by home agents and mobile nodes within the Mobile IP registration messages. Nonces and timestamps are protected from change by an authentication mechanism. Consequently, if a home agent or mobile node receives a duplicate message, the duplicate message can be thrown away.

The use of tunnels can be a significant vulnerability, especially if registration is not authenticated. Also, the Address Resolution Protocol (ARP) is not authenticated, and can potentially be used to steal another host's traffic.

Chapter 28 Administering Mobile IP (Tasks)

This chapter provides procedures for modifying, adding, deleting, and displaying parameters in the Mobile IP configuration file. This chapter also shows you how to display mobility agent status.

This chapter contains the following information:

• Creating the Mobile IP Configuration File (Task Map)

• Creating the Mobile IP Configuration File

• Modifying the Mobile IP Configuration File

• Modifying the Mobile IP Configuration File (Task Map)

• Displaying Mobility Agent Status

• Displaying Mobility Routes on a Foreign Agent

For an introduction to Mobile IP, refer to Chapter 27, Mobile IP (Overview). For detailed information about Mobile IP, refer to Chapter 29, Mobile IP Files and Commands (Reference).

The Mobile IP feature is removed from Solaris 10 updates after Solaris 10 8/07.

Creating the Mobile IP Configuration File (Task Map)

Creating the Mobile IP Configuration File

This section explains how to plan for Mobile IP and create the /etc/inet/mipagent.conffile.

How to Plan for Mobile IP

When you configure the mipagent.conf file for the first time, you need to perform the following tasks:

1. Depending on your organization's requirements for its hosts, determine what functionality your Mobile IP agent can provide:

   • Foreign agent functionality only

   • Home agent functionality only

   • Both foreign agent and home agent functionality

2. Create the /etc/inet/mipagent.conf file and specify the settings you require by using the procedures that are described in this section. You can also copy one of the following files to /etc/inet/mipagent.conf and modify it according to your requirements:

   • For foreign agent functionality, copy /etc/inet/mipagent.conf.fa-sample.

   • For home agent functionality, copy /etc/inet/mipagent.conf.ha-sample.

   • For both foreign agent and home agent functionality, copy /etc/inet/mipagent.conf-sample.

3. You can reboot your system to invoke the boot script that starts the mipagent daemon. Or, you can also start mipagent by typing the following command:

   # /etc/inet.d/mipagent start

How to Create the Mobile IP Configuration File

1. Assume the Primary Administrator role, or become superuser, on the system where you want to enable Mobile IP.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Create the /etc/inet/mipagent.conf file by using one of the following options:

   • In the /etc/inet directory, create an empty file named mipagent.conf.

   • From the following list, copy the sample file that provides the functionality you want for the /etc/inet/mipagent.conf file.

     • /etc/inet/mipagent.conf.fa-sample

     • /etc/inet/mipagent.conf.ha-sample

     • /etc/inet/mipagent.conf-sample

3. Add or change configuration parameters in the /etc/inet/mipagent.conf file to conform to your configuration requirements.

   The remaining procedures in this section describe the steps to modify sections in /etc/inet/mipagent.conf.

How to Configure the General Section

If you copied one of the sample files in the /etc/inet directory, you can omit this procedure because the sample file contains this entry. General Section provides descriptions of the labels and values that are used in this section.

1. Edit the /etc/inet/mipagent.conf file and add the following lines:

   [General] Version = 1.0

   ---

   Note –

   The /etc/inet/mipagent.conf file must contain this entry.

   ---

How to Configure the Advertisements Section

Advertisements Section provides descriptions of the labels and values that are used in this section.

1. Edit the /etc/inet/mipagent.conf file and add or change the following lines by using the values that are required for your configuration.

   [Advertisements interface] HomeAgent = <yes/no> ForeignAgent = <yes/no> PrefixFlags = <yes/no> AdvertiseOnBcast = <yes/no> RegLifetime = n AdvLifetime = n AdvFrequency = n ReverseTunnel = <yes/no/FA/HA/both> ReverseTunnelRequired = <yes/no/FA/HA>

   ---

   Note –

   You must include a different Advertisements section for each interface on the local host that provides Mobile IP services.

   ---

How to Configure the GlobalSecurityParameters Section

GlobalSecurityParameters Section provides descriptions of the labels and values that are used in this section.

1. Edit the /etc/inet/mipagent.conf file and add or change the following lines by using the values that are required for your configuration:

   [GlobalSecurityParameters] MaxClockSkew = n HA-FAauth = <yes/no> MN-FAauth = <yes/no> Challenge = <yes/no> KeyDistribution = files

How to Configure the Pool Section

Pool Section provides descriptions of the labels and values that are used in this section:

1. Edit the /etc/inet/mipagent.conf file

2. Add or change the following lines by using the values that are required for your configuration:

   [Pool pool-identifier] BaseAddress = IP-address Size = size

How to Configure the SPI Section

SPI Section provides descriptions of the labels and values that are used in this section.

1. Edit the /etc/inet/mipagent.conf file.

2. Add or change the following lines by using the values that are required for your configuration:

   [SPI SPI-identifier] ReplayMethod = <none/timestamps> Key = key

   ---

   Note –

   You must include a different SPI section for each security context that is deployed.

   ---

How to Configure the Address Section

Address Section provides descriptions of the labels and values that are used in this section.

1. Edit the /etc/inet/mipagent.conf file.

2. Add or change the following lines by using the values that are required for your configuration:

   • For a mobile node, use the following:

     [Address address] Type = node SPI = SPI-identifier

   • For an agent, use the following:

     [Address address] Type = agent SPI = SPI-identifier

   • For a mobile node that is identified by its NAI, use the following:

     [Address NAI] Type = Node SPI = SPI-identifier Pool = pool-identifier

   • For a default mobile node, use the following:

     [Address Node-Default] Type = Node SPI = SPI-identifier Pool = pool-identifier

Modifying the Mobile IP Configuration File (Task Map)

Modifying the Mobile IP Configuration File

This section shows you how to modify the Mobile IP configuration file by using the mipagentconfig command. This section also shows you how to display the current settings of parameter destinations.

Configuring the Mobility IP Agent provides a conceptual description of the mipagentconfig command's usage. You can also review the mipagentconfig(1M) man page.

How to Modify the General Section

1. Assume the Primary Administrator role, or become superuser on the system where you want to enable Mobile IP.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. On a command line, type the following command for each label that you want to modify in the General section.

   # mipagentconfig change <label> <value>

Example 28–1 Modifying a Parameter in the General Section

The following example shows how you might change the version number in the configuration file's General section.

# mipagentconfig change version 2

How to Modify the Advertisements Section

1. Assume the Primary Administrator role, or become superuser, on the system where you want to enable Mobile IP.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Type the following command for each label that you want to modify in the Advertisements section:

   # mipagentconfig change adv device-name <label> <value>

   For example, if you are changing the agent's advertised lifetime to 300 seconds for device hme0, use the following command.

   # mipagentconfig change adv hme0 AdvLifetime 300

Example 28–2 Modifying the Advertisements Section

The following example shows how you might change other parameters in the configuration file's Advertisements section.

# mipagentconfig change adv hme0 HomeAgent yes
# mipagentconfig change adv hme0 ForeignAgent no
# mipagentconfig change adv hme0 PrefixFlags no
# mipagentconfig change adv hme0 RegLifetime 300
# mipagentconfig change adv hme0 AdvFrequency 4
# mipagentconfig change adv hme0 ReverseTunnel yes

How to Modify the GlobalSecurityParameters Section

1. Assume the Primary Administrator role, or become superuser, on the system where you want to enable Mobile IP.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Type the following command for each label that you want to modify in the GlobalSecurityParameters section:

   # mipagentconfig change <label> <value>

   For example, if you are enabling home agent and foreign agent authentication, use the following command:

   # mipagentconfig change HA-FAauth yes

Example 28–3 Modifying the Global Security Parameters Section

The following example shows how you might change other parameters in the configuration file's GlobalSecurityParameters section.

# mipagentconfig change MaxClockSkew 200
# mipagentconfig change MN-FAauth yes
# mipagentconfig change Challenge yes
# mipagentconfig change KeyDistribution files

How to Modify the Pool Section

1. Assume the Primary Administrator role, or become superuser, on the system where you want to enable Mobile IP.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Type the following command for each label that you want to modify in the Pool section:

   # mipagentconfig change Pool pool-identifier <label> <value>

Example 28–4 Modifying the Pool Section

The following example shows the commands to use for changing the base address to 192.168.1.1 and the size of Pool 10 to 100.

# mipagentconfig change Pool 10 BaseAddress 192.168.1.1
# mipagentconfig change Pool 10 Size 100

How to Modify the SPI Section

1. Assume the Primary Administrator role, or become superuser, on the system where you want to enable Mobile IP.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Type the following command for each label that you want to modify in the SPI section:

   # mipagentconfig change SPI SPI-identifier <label> <value>

   For example, if you are changing the key for SPI 257 to 5af2aee39ff0b332, use the following command.

   # mipagentconfig change SPI 257 Key 5af2aee39ff0b332

Example 28–5 Modifying the SPI Section

The following example shows how to change the ReplayMethod label in the configuration file's SPI section.

# mipagentconfig change SPI 257 ReplayMethod timestamps

How to Modify the Address Section

1. Assume the Primary Administrator role, or become superuser, on the system where you want to enable Mobile IP.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Type the following command for each label that you want to modify in the Address section:

   # mipagentconfig change addr [NAI | IPaddr | node-default] <label> <value>

   See Address Section for a description of the three configuration methods (NAI, IP address, and node-default).

   For example, if you are changing the SPI of IP address 10.1.1.1 to 258, use the following command:

   # mipagentconfig change addr 10.1.1.1 SPI 258

Example 28–6 Modifying the Address Section

The following example shows how you can change other parameters that are provided in the sample configuration file's Address section.

# mipagentconfig change addr 10.1.1.1 Type agent
# mipagentconfig change addr 10.1.1.1 SPI 259
# mipagentconfig change addr mobilenode@abc.com Type node
# mipagentconfig change addr mobilenode@abc.com SPI 258
# mipagentconfig change addr mobilenode@abc.com Pool 2
# mipagentconfig change addr node-default SPI 259
# mipagentconfig change addr node-default Pool 3
# mipagentconfig change addr 10.68.30.36 Type agent
# mipagentconfig change addr 10.68.30.36 SPI 260

How to Add or Delete Configuration File Parameters

1. Assume the Primary Administrator role, or become superuser, on the system where you want to enable Mobile IP.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Type the appropriate command for each label that you want to add or delete for the designated section:

   • For the General section use the following:

     # mipagentconfig [add | delete] <label> <value>

   • For the Advertisements section use the following:

     # mipagentconfig [add | delete] adv device-name <label> <value>

     ---

     Note –

     You can add an interface by typing the following:

     # mipagentconfig add adv device-name

     In this instance, default values are assigned to the interface (for both the foreign agent and the home agent).

     ---

   • For the GlobalSecurityParameters, section use the following:

     # mipagentconfig [add | delete] <label> <value>

   • For the Pool section, use the following:

     # mipagentconfig [add | delete] Pool pool-identifier <label> <value>

   • For the SPI section, use the following:

     # mipagentconfig [add | delete] SPI SPI-identifier <label> <value>

   • For the Address section, use the following:

     # mipagentconfig [add | delete] addr [NAI | IP-address | node-default] \ <label> <value>

   ---

   Note –

   Do not create identical Advertisements, Pool, SPI, and Address sections.

   ---

Example 28–7 Modifying File Parameters

For example, to create a new address pool, Pool 11, that has a base address of 192.167.1.1 and a size of 100, use the following commands.

# mipagentconfig add Pool 11 BaseAddress 192.167.1.1 
# mipagentconfig add Pool 11 size 100

Example 28–8 Deleting SPI

The following example shows how to delete the SPI security parameter SPI 257.

# mipagentconfig delete SPI 257

How to Display Current Parameter Values in the Configuration File

You can use the mipagentconfig get command to display current settings that are associated with parameter destinations.

1. Assume the Primary Administrator role, or become superuser, on the system where you are enabling Mobile IP.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Type the following command for each parameter for which you want to display settings:

   # mipagentconfig get [<parameter> | <label>]

   For example, if you are displaying the advertisement settings for the hme0 device, use the following command:

   # mipagentconfig get adv hme0

   As a result, the following output might be displayed:

   [Advertisements hme0] HomeAgent = yes ForeignAgent = yes

Example 28–9 Using the mipagentconfig get Command to Display Parameter Values

The following example shows the results of using the mipagentconfig get command with other parameter destinations.

# mipagentconfig get MaxClockSkew
      [GlobalSecurityParameters]
         MaxClockSkew=300

# mipagentconfig get HA-FAauth
      [GlobalSecurityParameters]
         HA-FAauth=no

# mipagentconfig get MN-FAauth
      [GlobalSecurityParameters]
         MN-FAauth=no

# mipagentconfig get Challenge
      [GlobalSecurityParameters]
         Challenge=no

# mipagentconfig get Pool 10
      [Pool 10]
         BaseAddress=192.168.1.1
         Size=100

# mipagentconfig get SPI 257
      [SPI 257]
         Key=11111111111111111111111111111111
         ReplayMethod=none

# mipagentconfig get SPI 258
      [SPI 258]
         Key=15111111111111111111111111111111
         ReplayMethod=none

# mipagentconfig get addr 10.1.1.1
      [Address 10.1.1.1]
         SPI=258
         Type=agent

# mipagentconfig get addr 192.168.1.200
      [Address 192.168.1.200]
         SPI=257
         Type=node

Displaying Mobility Agent Status

You can use the mipagentstat command to display a foreign agent's visitors list and a home agent's binding table. Mobile IP Mobility Agent Status provides a conceptual description of the mipagentstat command. You can also review the mipagentstat(1M) man page.

How to Display Mobility Agent Status

1. Become superuser or assume an equivalent role on the system where you are enabling Mobile IP.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Display the mobility agent status.

   # mipagentstat options

   -f

   Shows the list of active mobile nodes in the foreign agent's visitor list.

   -h

   Shows the list of active mobile nodes in the home agent's binding table.

   -p

   Shows the list of security associations with an agent's mobility agent peers.

Example 28–10 Displaying Mobility Agent Status

This example shows how to display the visitor list for all mobile nodes that are registered with a foreign agent.

# mipagentstat -f

As a result, output similar to the following is displayed:

Mobile Node     Home Agent     Time (s)     Time (s)  Flags
                               Granted      Remaining
--------------- -------------- ------------ --------- -----
foobar.xyz.com  ha1.xyz.com    600          125       .....T.
10.1.5.23       10.1.5.1       1000         10        .....T.

As a result, output similar to the following is displayed:

Foreign                  ..... Security Association(s).....
Agent                    Requests Replies  FTunnel  RTunnel
----------------------   -------- -------- -------- --------
forn-agent.eng.sun.com   AH       AH       ESP      ESP

This example shows how to display home agent security associations.

# mipagentstat -fp

As a result, output similar to the following is displayed:

Home                     ..... Security Association(s) .....
Agent                    Requests Replies  FTunnel  RTunnel
----------------------   -------- -------- -------- --------
home-agent.eng.sun.com   AH       AH       ESP      ESP
ha1.xyz.com              AH,ESP   AH       AH,ESP   AH,ESP

Displaying Mobility Routes on a Foreign Agent

You can use the netstat command to display additional information about source-specific routes that are created by forward tunnels and reverse tunnels. See the netstat(1M) man page for more information about this command.

How to Display Mobility Routes on a Foreign Agent

1. Become superuser or assume an equivalent role on the system where you are enabling Mobile IP.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Display the mobility routes.

   # netstat -rn

Example 28–11 Displaying Mobility Routes on a Foreign Agent

The following example shows the routes for a foreign agent that uses a reverse tunnel.

Routing Table:   IPv4 Source-Specific     
Destination      In If     Source      Gateway Flags  Use  Out If
--------------  ------- ------------ --------- -----  ---- -------
10.6.32.11      ip.tun1      --      10.6.32.97  UH      0 hme1
    --          hme1    10.6.32.11       --      U       0 ip.tun1

The first line indicates that the destination IP address 10.6.32.11 and the incoming interface ip.tun1 select hme1 as the interface that forwards the packets. The next line indicates that any packet originating from interface hme1 and source address 10.6.32.11 must be forwarded to ip.tun1.

Chapter 29 Mobile IP Files and Commands (Reference)

This chapter describes the components that are provided with the Solaris implementation of Mobile IP. To use Mobile IP, you must first configure the Mobile IP configuration file by using the parameters and commands that are described in this chapter.

This chapter contains the following information:

• Overview of the Solaris Mobile IP Implementation

• Mobile IP Configuration File

• Configuring the Mobility IP Agent

• Mobile IP Mobility Agent Status

• Mobile IP State Information

• netstat Extensions for Mobile IP

• snoop Extensions for Mobile IP

The Mobile IP feature is removed from Solaris 10 updates after Solaris 10 8/07.

Overview of the Solaris Mobile IP Implementation

The mobility agent software incorporates home agent and foreign agent functionality. The Solaris Mobile IP software does not provide a client mobile node. Only the agent functionality is provided. Each network with mobility support should have at least one static (non-mobile) host running this software.

The following RFC functions are supported in the Solaris implementation of Mobile IP:

• RFC 1918, "Address Allocation for Private Internets"

• RFC 2002, "IP Mobility Support" (Agent only)

• RFC 2003, "IP Encapsulation Within IP"

• RFC 2794, "Mobile IP Network Access Identifier Extension for IPv4"

• RFC 3012, "Mobile IPv4 Challenge/Response Extensions"

• RFC 3024, "Reverse Tunneling for Mobile IP"

The base Mobile IP protocol (RFC 2002) does not address the problem of scalable key distribution and treats key distribution as an orthogonal issue. The Solaris Mobile IP software utilizes only manually configured keys, specified in a configuration file.

The following RFC functions are not supported in the Solaris implementation of Mobile IP:

• RFC 1701, "General Routing Encapsulation"

• RFC 2004, "Minimal Encapsulation Within IP"

The following functions are not supported in the Solaris implementation of Mobile IP:

• The forwarding of multicast traffic or broadcast traffic by the home agent to the foreign agent for a mobile node that is visiting a foreign network

• The routing of broadcast and multicast datagrams through reverse tunnels

• Private care-of addresses or private home agent addresses

See the mipagent(1M) man page for additional information.

Mobile IP Configuration File

The mipagent command reads configuration information from the /etc/inet/mipagent.conf configuration file at startup. Mobile IP uses the /etc/inet/mipagent.conf configuration file to initialize the Mobile IP mobility agent. When configured and deployed, the mobility agent issues periodic router advertisements and responds to router discovery solicitation messages as well as Mobile IP registration messages.

See the mipagent.conf(4) man page for a description of file attributes. See the mipagent(1M) man page for a description of this file's usage.

Configuration File Format

The Mobile IP configuration file consists of sections. Each section has a unique name and is enclosed in square brackets. Each section contains one or more labels. You assign values to the labels by using the following format:

[Section_name]
     Label-name = value-assigned

Configuration File Sections and Labels describes the section names, labels, and possible values.

Sample Configuration Files

The default Solaris installation provides the following sample configuration files in the /etc/inet directory:

• mipagent.conf-sample – Contains a sample configuration for a Mobile IP agent that provides both foreign agent and home agent functionality

• mipagent.conf.fa-sample – Contains a sample configuration for a Mobile IP agent that provides only foreign agent functionality

• mipagent.conf.ha-sample – Contains a sample configuration for a Mobile IP agent that provides only home agent functionality

These sample configuration files contain mobile node address and security settings. Before you can implement Mobile IP, you must create a configuration file with the name mipagent.conf and place it in the /etc/inet directory. This file contains the configuration settings that satisfy your Mobile IP implementation requirements. You can also choose one of the sample configuration files, modify it with your addresses and security settings, and copy it to /etc/inet/mipagent.conf.

For more information, see How to Create the Mobile IP Configuration File.

mipagent.conf-sample File

The following listing shows the sections, labels, and values that are contained in the mipagent.conf-sample file. Configuration File Sections and Labels describes the syntax, sections, labels, and values.

[General]
   Version = 1.0    # version number for the configuration file. (required)
   
[Advertisements hme0]
   HomeAgent = yes
   ForeignAgent = yes
   PrefixFlags = yes
   AdvertiseOnBcast = yes
   RegLifetime = 200
   AdvLifetime = 200
   AdvFrequency = 5
   ReverseTunnel = no
   ReverseTunnelRequired = no
   
[GlobalSecurityParameters]
   MaxClockSkew = 300
   HA-FAauth = yes
   MN-FAauth = yes
   Challenge = no
   KeyDistribution = files

[Pool 1]
   BaseAddress = 10.68.30.7
   Size = 4

[SPI 257]
   ReplayMethod = none
   Key = 11111111111111111111111111111111

[SPI 258]
   ReplayMethod = none
   Key = 15111111111111111111111111111111

[Address 10.1.1.1]
   Type = node
   SPI = 258

[Address mobilenode@sun.com]
   Type = node
   SPI = 257
   Pool = 1

[Address Node-Default]
   Type = node
   SPI = 258
   Pool = 1

[Address 10.68.30.36]
   Type = agent    
   SPI = 257

mipagent.conf.fa-sample File

The following listing shows the sections, labels, and values that are contained in the mipagent.conf.fa-sample file. Configuration File Sections and Labels describes the syntax, sections, labels, and values.

The mipagent.conf.fa-sample file shows a configuration that provides only foreign agent functionality. This sample file does not contain a Pool section because pools are used only by a home agent. Otherwise, this file is the same as the mipagent.conf-sample file.

[General]
   Version = 1.0    # version number for the configuration file. (required)
   
[Advertisements hme0]
   HomeAgent = no
   ForeignAgent = yes
   PrefixFlags = yes
   AdvertiseOnBcast = yes
   RegLifetime = 200
   AdvLifetime = 200
   AdvFrequency = 5
   ReverseTunnel = yes
   ReverseTunnelRequired = no
   
[GlobalSecurityParameters]
   MaxClockSkew = 300
   HA-FAauth = yes
   MN-FAauth = yes
   Challenge = no
   KeyDistribution = files

[SPI 257]
   ReplayMethod = none
   Key = 11111111111111111111111111111111

[SPI 258]
   ReplayMethod = none
   Key = 15111111111111111111111111111111

[Address 10.1.1.1]
   Type = node
   SPI = 258

[Address 10.68.30.36]
   Type = agent    
   SPI = 257

mipagent.conf.ha-sample File

The following listing shows the sections, labels, and values that are contained in the mipagent.conf.ha-sample file. Configuration File Sections and Labels describes the syntax, sections, labels, and values.

The mipagent.conf.ha-sample file shows a configuration that provides only home agent functionality. Otherwise, this file is the same as the mipagent.conf-sample file.

[General]
   Version = 1.0    # version number for the configuration file. (required)
   
[Advertisements hme0]
   HomeAgent = yes
   ForeignAgent = no
   PrefixFlags = yes
   AdvertiseOnBcast = yes
   RegLifetime = 200
   AdvLifetime = 200
   AdvFrequency = 5
   ReverseTunnel = yes
   ReverseTunnelRequired = no

[GlobalSecurityParameters]
   MaxClockSkew = 300
   HA-FAauth = yes
   MN-FAauth = yes
   Challenge = no
   KeyDistribution = files

[Pool 1]
   BaseAddress = 10.68.30.7
   Size = 4

[SPI 257]
   ReplayMethod = none
   Key = 11111111111111111111111111111111

[SPI 258]
   ReplayMethod = none
   Key = 15111111111111111111111111111111

[Address 10.1.1.1]
   Type = node
   SPI = 258

[Address mobilenode@sun.com]
   Type = node
   SPI = 257
   Pool = 1

[Address Node-Default]
   Type = node
   SPI = 258
   Pool = 1

Configuration File Sections and Labels

The Mobile IP configuration file contains the following sections:

• General (Required)

• Advertisements (Required)

• GlobalSecurityParameters (Optional)

• Pool (Optional)

• SPI (Optional)

• Address (Optional)

The General and GlobalSecurityParameters sections contain information relevant to the operation of the Mobile IP agent. These sections can appear only once in the configuration file.

General Section

The General section contains only one label: the version number of the configuration file. The General section has the following syntax:

[General]
     Version = 1.0

Advertisements Section

The Advertisements section contains the HomeAgent and ForeignAgent labels, as well as other labels. You must include a different Advertisements section for each interface on the local host that provides Mobile IP services. The Advertisements section has the following syntax:

[Advertisements interface]
     HomeAgent = <yes/no>
     ForeignAgent = <yes/no>
     .
     .

Typically, your system has a single interface, such as eri0 or hme0, and supports both home agent and foreign agent operations. If this situation exists for the example hme0, then the yes value is assigned to both the HomeAgent and ForeignAgent labels as follows:

[Advertisements hme0]
     HomeAgent = yes
     ForeignAgent = yes
     .
     .

For advertisement over dynamic interfaces, use '*' for the device ID part. For example, Interface-name ppp* actually implies all PPP interfaces that are configured after the mipagent daemon has been started. All the attributes in the advertisement section of a dynamic interface type remain the same.

The following table describes the labels and values that you can use in the Advertisements section.

GlobalSecurityParameters Section

The GlobalSecurityParameters section contains the labels maxClockSkew, HA-FAauth, MN-FAauth, Challenge, and KeyDistribution. This section has the following syntax:

[GlobalSecurityParameters]
     MaxClockSkew = n
     HA-FAauth = <yes/no>
     MN-FAauth = <yes/no>
     Challenge = <yes/no>
     KeyDistribution = files

The Mobile IP protocol provides message replay protection by allowing timestamps to be present in the messages. If the clocks differ, the home agent returns an error to the mobile node with the current time and the mobile node can register again by using the current time. You use the MaxClockSkew label to configure the maximum number of seconds that differ between the home agent and the mobile node's clocks. The default value is 300 seconds.

The HA-FAauth and MN-FAauth labels enable or disable the requirement for home-foreign and mobile-foreign authentication, respectively. The default value is disabled. You use the challenge label so that the foreign agent issues challenges to the mobile node in its advertisements. The label is used for replay protection. The default value is disabled here, also.

The following table describes the labels and values that you can use in the GlobalSecurityParameters section.

Pool Section

Mobile nodes can be assigned dynamic addresses by the home agent. Dynamic address assignment is done within the mipagent daemon independently of DHCP. You can create an address pool that can be used by mobile nodes by requesting a home address. Address pools are configured through the Pool section in the configuration file.

The Pool section contains the BaseAddress and Size labels. The Pool section has the following syntax:

[Pool pool-identifier]
     BaseAddress = IP-address
     Size = size

If you use a Pool identifier, then it must also exist in the mobile node's Address section.

You use the Pool section to define address pools that can be assigned to the mobile nodes. You use the BaseAddress label to set the first IP address in the pool. You use the Size label to specify the number of addresses available in the pool.

For example, if IP addresses 192.168.1.1 through 192.168.1.100 are reserved in pool 10, the Pool section has the following entry:

[Pool 10]
     BaseAddress = 192.168.1.1
     Size = 100

Address ranges should not encompass the broadcast address. For example, you should not assign BaseAddress = 192.168.1.200 and Size = 60, because this range encompasses the broadcast address 192.168.1.255.

The following table describes the labels and values that are used in the Pool section.

SPI Section

Because the Mobile IP protocol requires message authentication, you must identify the security context by using a security parameter index (SPI). You define the security context in the SPI section. You must include a different SPI section for each security context that is defined. A numerical ID identifies the security context. The Mobile IP protocol reserves the first 256 SPIs. Therefore, you should use only SPI values greater than 256. The SPI section contains security-related information, such as shared secrets and replay protection.

The SPI section also contains the ReplayMethod and Key labels. The SPI section has the following syntax:

[SPI SPI-identifier]
     ReplayMethod = <none/timestamps>
     Key = key

Two communicating peers must share the same SPI identifier. You must configure them with the same key and replay method. You specify the key as a string of hexadecimal digits. The maximum length is 16 bytes. For example, if the key is 16 bytes long, and contains the hexadecimal values 0 through f, the key string might resemble the following:

Key = 0102030405060708090a0b0c0d0e0f10

Keys must have an even number of digits, corresponding to the two digits per byte representation.

The following table describes the labels and values that you can use in the SPI section.

Address Section

The Solaris implementation of Mobile IP enables you to configure mobile nodes using one of three methods. Each method is configured in the Address section. The first method follows the traditional Mobile IP protocol, and requires that each mobile node have a home address. The second method enables a mobile node to be identified through its Network Access Identifier (NAI). The last method enables you to configure a default mobile node, which can be used by any mobile node that has the proper SPI value and related keying material.

Mobile Node

The Address section for a mobile node contains the Type and SPI labels that define the address type and SPI identifier. The Address section has the following syntax:

[Address address]
     Type = node
     SPI = SPI-identifier

You must include an Address section in a home agent's configuration file for each mobile node that is supported.

If Mobile IP message authentication is required between the foreign agent and home agent, you must include an Address section for each peer with which an agent needs to communicate.

The SPI value that you configure must represent an SPI section that is present in the configuration file.

You can also configure private addresses for a mobile node.

The following table describes the labels and values that you can use in the Address section for a mobile node.

Mobility Agent

The Address section for a mobility agent contains the Type and SPI labels that define the address type and SPI identifier. The Address section for a mobility agent has the following syntax:

[Address address]
     Type = agent
     SPI = SPI-identifier
     

You must include an Address section in a home agent's configuration file for each mobility agent that is supported.

If Mobile IP message authentication is required between the foreign agent and the home agent, you must include an Address section for each peer with which an agent needs to communicate.

The SPI value that you configure must represent an SPI section that is present in the configuration file.

The following table describes the labels and values that you can use in the Address section for a mobility agent.

Mobile Node Identified by Its NAI

The Address section for a mobile node that is identified by its NAI contains the Type, SPI, and Pool labels. The NAI parameter enables you to identify mobile nodes through their NAI. The Address section, using the NAI parameter, has the following syntax:

[Address NAI]
     Type = Node
     SPI = SPI-identifier
     Pool = pool-identifier

To use pools, you identify mobile nodes through their NAI. The Address section permits you to configure an NAI, as opposed to a home address. An NAI uses the format user@domain. You use the Pool label to specify which address pool to use in order to allocate the home address to the mobile node.

The following table describes the labels and values that you can use in the Address section for a mobile node that is identified by its NAI.

You must have corresponding SPI and Pool sections for the SPI and Pool labels that are defined in an Address section with a mobile node that is identified by its NAI, as shown in the following figure.

Figure 29–1 Corresponding SPI and Pool Sections for Address Section With Mobile Node Identified by Its NAI

Default Mobile Node

The Address section for a default mobile node contains the Type, SPI, and Pool labels. The Node-Default parameter enables you to permit all mobile nodes to get service if they have the correct SPI (defined in this section). The Address section, using the Node-Default parameter, has the following syntax:

[Address Node-Default]
     Type = Node
     SPI = SPI-identifier
     Pool = pool-identifier

The Node-Default parameter enables you to reduce the size of the configuration file. Otherwise, each mobile node requires its own section. However, the Node-Default parameter does pose a security risk. If a mobile node is no longer trusted for any reason, you need to update the security information on all trusted mobile nodes. This task can be very tedious. However, you can use the Node-Default parameter in networks that consider security risks unimportant.

The following table describes the labels and values that you can use in the Address section for a default mobile node.

You must have corresponding SPI and Pool sections for the SPI and Pool labels that are defined in the Address section with a default mobile node, as shown in the following figure.

Figure 29–2 Corresponding SPI and Pool Sections for Address Section With a Default Mobile Node

Configuring the Mobility IP Agent

You can use the mipagentconfig command to configure the mobility agent. This command enables you to create or modify any parameter in the /etc/inet/mipagent.conf configuration file. Specifically, you can change any setting. Also, you can add or delete mobility clients, pools, and SPIs. The mipagentconfig command has the following syntax:

# mipagentconfig <command> <parameter> <value>

The following table describes the commands that you can use with mipagentconfig to create or modify parameters in the /etc/inet/mipagent.conf configuration file.

See the mipagentconfig(1M) man page for a description of command parameters and acceptable values. Modifying the Mobile IP Configuration File provides procedures that use the mipagentconfig command.

Mobile IP Mobility Agent Status

You can use the mipagentstat command to display a foreign agent's visitor list and a home agent's binding table. You can also display the security associations with an agent's mobility agent peers. To display the foreign agent visitor list, you use the mipagentstat command's -f option. To display the home agent binding table, you use the mipagentstat command's -h option. The following examples show typical output when the mipagentstat command is used with these options.

Example 29–1 Foreign Agent Visitor List

Mobile Node     Home Agent     Time (s)     Time (s)  Flags
                               Granted      Remaining
--------------- -------------- ------------ --------- -----
foobar.xyz.com  ha1.xyz.com    600          125       .....T.
10.1.5.23       10.1.5.1       1000         10        .....T.

Example 29–2 Home Agent Binding Table

Mobile Node     Home Agent     Time (s)     Time (s)  Flags
                               Granted      Remaining
--------------- -------------- ------------ --------- -----
foobar.xyz.com  fa1.tuv.com    600          125       .....T.
10.1.5.23       123.2.5.12     1000         10        .....T.

See the mipagentstat(1M) man page for more information about the command's options. Displaying Mobility Agent Status provides procedures that use the mipagentstat command.

Mobile IP State Information

On shutdown, the mipagent daemon stores internal state information in /var/inet/mipagent_state. This event occurs only when the mipagent provides services as a home agent. This state information includes the list of mobile nodes that are being supported as a home agent, their current care-of addresses, and remaining registration lifetimes. This state information also includes the security association configuration with mobility agent peers. If the mipagent daemon is terminated for maintenance and restarted, mipagent_state is used to recreate as much of the mobility agent's internal state as possible. The intention is to minimize service disruption for mobile nodes that might be visiting other networks. If mipagent_state exists, it is read immediately after mipagent.conf every time mipagent is started or restarted.

netstat Extensions for Mobile IP

Mobile IP extensions have been added to the netstat command to identify Mobile IP forwarding routes. Specifically, you can use the netstat command to display a new routing table that is called “Source-Specific.” See the netstat(1M) man page for more information.

The following example shows the output of netstat when you use the -nr flags.

Example 29–3 Mobile IP Output From netstat Command

Routing Table:   IPv4 Source-Specific     
Destination      In If     Source      Gateway Flags  Use  Out If
--------------  ------- ------------ --------- -----  ---- -------
10.6.32.11      ip.tun1      --      10.6.32.97  UH      0 hme1
    --          hme1    10.6.32.11       --      U       0 ip.tun1

The example shows the routes for a foreign agent that uses a reverse tunnel. The first line indicates that the destination IP address 10.6.32.11 and the incoming interface ip.tun1 select hme1 as the interface that forwards the packets. The next line indicates that any packet that originates from interface hme1 and source address 10.6.32.11 must be forwarded to ip.tun1.

snoop Extensions for Mobile IP

Mobile IP extensions have been added to the snoop command to identify Mobile IP traffic on the link. See the snoop(1M) man page for more information.

The following example shows the output of snoop that runs on the mobile node, mip-mn2.

Example 29–4 Mobile IP Output From snoop Command

mip-mn2# snoop
Using device /dev/hme (promiscuous mode)
  mip-fa2 -> 224.0.0.1    ICMP Router advertisement (Lifetime 200s [1]: 
{mip-fa2-80 2147483648}), (Mobility Agent Extension), (Prefix Lengths), 
(Padding)
  mip-mn2 -> mip-fa2   Mobile IP reg rqst 
  mip-fa2 -> mip-mn2   Mobile IP reg reply (OK code 0)

This example shows that the mobile node received one of the periodically sent mobility agent advertisements from the foreign agent, mip-fa2. Then, mip-mn2 sent a registration request to mip-fa2, and in response, received a registration reply. The registration reply indicates that the mobile node successfully registered with its home agent.