Figure 1
| Dynamics | ||
| Functional Definition | $Revision: 1.47 $ | State approved |
| Date 03-Dec-1998 | Author Björn Andersson | |
| Review date 10-Dec-1998 | Reviewed by Jouni Malinen | |
| Approval date 10-Dec-1998 | Approved by Jouni Malinen | |
$Id: func_def.html,v 1.47 1998/12/09 22:38:16 jkmaline Exp $
The main motive of the Dynamics project is to make a prototype version of a hierarchical IP tunnel for IPv4 network. The project will use existing solutions and solution proposals as far as possible to achieve stable implementation.
Mobile Node is a computer, which is connected to the Internet. It can move from one network to another (Visiting Network). Home Agent redirects the packets arriving at the Mobile Node's Home Network to the Mobile Node so that the IP address of the Mobile Node need not be changed. The redirection to the Mobile Node is implemented as a tunnel using encapsulated IP packets (an IP packet inside another IP packet).
The path from the Home Agent to the Mobile Node is constructed of many tunnels. Foreign Agents reside between the tunnels and they make it possible to update the path more locally when the Mobile Node moves. The Foreign Agents establish a tree hierarchy from the root Foreign Agent which then communicates with Home Agents. Every Foreign Agent can communicate with Mobile Nodes. Different kinds of tunneling methods exist, but the main purpose for this project is to implement bi-directional tunneling, where data is moved entirely in the tunnel in both directions.
Foreign Agents advertise themselves for Mobile Nodes and when a Mobile Node moves it registers itself to the Home Agent through a path from the advertising Foreign Agent to the Home Agent. The registration message updates also the data structures in the Foreign Agents. Routing is thus changed in the Foreign Agent tree.
A Mobile Node and its corresponding Home Agent share a secret key. This secret key is used to calculate message authentication codes for the signaling messages in order to be able to authenticate Mobile Node and Home Agent to each other.
Every Foreign Agent has a public and a secret key. When the registration goes through the path to the Home Agent and the tunnel is established, every Foreign Agent sends its public key to its parent. The Home Agent gets the public key of the root Foreign Agent and uses this key to encrypt the Session Key for the Foreign Agent tree. In addition, the Session Key is encrypted for the Mobile Node using the shared secret between Home Agent and Mobile Node. The Session Key, that was generated by the Home Agent, is used to authenticate the Mobile Node when it moves.
Pre-configured and dynamic data is maintained at each module (Home Agent, Foreign Agent, Mobile Node). Linux system logging utilities, syslogd(8), are used in logging the events of the system.
A care-of address from the Visited Network is always required for the Mobile Node. It is used to direct the tunnel from the Home Agent to the Mobile Node. Registration protocol is used to register Mobile Nodes entering or changing the Visiting Network. Keep alive protocol is used to maintain the tunnels so that they will not expire and discard tunnel specific data. The main object was to use as few messages as possible when developing these protocols. Timeouts and critical information savings to disk drives are used to help the system to recover from errors and unexpected situations.
Linux kernel interface supports IP over IP tunneling and the modules in the kernel will be used and enhanced. Configuration and monitoring tools will be made as well as an API for developers for each module of the system.
This project will use existing solutions and solution proposals as far as possible. This will prevent extra work of "reinventing the wheel", and should lead to a more stable implementation. The main task for this project is to select the suitable solutions and to implement a working prototype of the hierarchical IP tunnel.
"RFC2002 - IP Mobility Support" [RFC2002] and "IP Mobility Support version 2" [IPMOB2] (work in progress) describe the base functionality needed for mobility. "Tunnel Establishment Protocol" [TEP] (work in progress) gives general ideas about tunnel establishment. "Mobile-IP Local Registration with Hierarchical Foreign Agents" [HIERFA] (work in progress) brings in the hierarchical aspects that are needed to make roaming more efficient. "Registration Keys for Route Optimization" [REGKEY] (work in progress) suggests a solution that makes roaming management more secure.
To fit the customer's needs our mission is mainly to combine existing solutions and, as these documents provide solutions for a broad spectrum of features, to filter out the extra functionality described in the documents.
This document will not go into the details described in the documents mentioned above, but instead it will try to give a big picture of the system in a way that is easier to understand than reading all the referenced documents one by one.
The Mobile Node is the mobile computer from which a user wants to have the Internet available. In addition she wants to be reachable from other computers, even while visiting other networks. Internet protocol v4 addresses are associated with a certain point of attachment somewhere in the Internet. Thus all packets destined for a particular computer will be routed to a fixed network. In order to let the Mobile Node move to other networks there must be a way of routing the packets arriving at the Home Network to the Mobile Node's location in the Visited Network. For this purpose each Home Network has a Home Agent.
In order to be able to know where to route packets to a Mobile Node visiting a foreign network, the Home Agent should always be aware of the current location of its Mobile Nodes. This is achieved by making the Mobile Nodes register with their Home Agent each time they change their point of attachment.
Sometimes, however, it can be expensive (or even impossible) for the Mobile Node to register with the Home Agent. This could happen, for example when the Home Agent is far away and the Mobile Node is receiving real-time video data. If the Mobile Node changes its point of attachment while receiving the video, it could take a while for the Home Agent to receive the registration of the new location, and the mobile user would perceive an annoying gap in the video stream. For this purpose so called Foreign Agents are placed in the Visited Network.
With the aid of the Foreign Agents, the Home Agent only needs to know under which Foreign Agent the Mobile Node is in care of; i.e. the Mobile Node registers with the Home Agent the location of the Foreign Agent. The actual point of attachment is registered with the Foreign Agent. When the Mobile Node now changes its point of attachment within the same Foreign Network, the Mobile Node only has to register its new point of attachment with the Foreign Agent.
To make the scheme even more flexible we can place one Foreign Agent within each subnet in a Foreign Network, so that the Foreign Agents make up a hierarchical structure. Now the registrations need to be sent only to a minimal distance.
The packets that the Home Agents and Foreign Agents route to the registered location must be kept intact. This can be done placing the original packet within another packet, that is then sent to the registered location. The receiver of the encapsulated packet can then unwrap the outer packet to retain the original inner packet intact. This method of encapsulating IP packets within other IP packets is called IP-over-IP, and the routing of packets with the aid of the wrapper packets is called tunneling [RFC2003]. The tunnel is thus, in our environment, between the Home Agent and the registered location of the Mobile Node. The tunnel is built of segments between the Home Agent and the root Foreign Agent, between each Foreign Agent in the path and finally between the lowest Foreign Agent and the Mobile Node.
Note that in principle the tunnel only has to be a one way pipe from the Home Agent to the Mobile Node, and not necessarily the other way around. Packets arriving from a Correspondent Host at the Home Network will be tunneled to the Mobile Node, but the Mobile Node can send packets directly to the Correspondent host, if the source address to be used in the packet is the address of the Mobile Node in the Home Network. This way of tunneling is called triangle routing or semi tunneling. Sometimes, however, a two-way tunnel, where both incoming and outgoing packets pass the tunnel through the Foreign Agents and Home Agent is preferred. This is called bi-directional routing or full tunneling. Full tunneling could for instance be useful because of security concerns when the source address in a packet must be topologically correct [REVTUN].
When a Mobile user arrives to a Foreign Network and connects to the network, the Mobile Node receives an IP address. This triggers the Mobile Node to execute a Registration Protocol. Registration Protocol is implemented hierarchically and the tunnel is created through the Foreign Agent hierarchy step by step. This allows each Foreign Agent on the path to examine, if they already have a tunnel for the specified Mobile Node, which would allow them to perform local tunnel updates. For a new registration, the protocol reaches the Home Node which then confirms the tunnel creation. During registration, the Mobility Agents agree on the lifetime of the tunnel. Keep Alive protocol is used to keep the tunnel open and it should be re-initiated well before the tunnel's lifetime ends.
During tunnel creation each Mobility Node stores the next Mobility Node in upstream and downstream directions for each tunnel. This information is called Mobility Binding and it allows the nodes to forward packets to the next Mobility Agent.
When Mobile Node moves to another place and connects to a new Access Point it automatically receives a new IP address, and the Registration Protocol is executed again. This time, however, a local tunnel update is performed.
The Mobile Node and the Home Agent have a preconfigured shared key that they use to authenticate each other. As the mobile node moves it should authenticate itself with the Foreign Agents. It is, however, not very practical to manually configure Foreign Agents with shared keys, so another approach is needed. The approach we have chosen confirms with the "Home Agent as a Key Distribution Center" method as specified in [REGKEY].
When the mobile node registers with the Home Agent, each Foreign Agent sends in the Registration Request its public key to the next higher Foreign Agent, and the top level Foreign Agent to the Home Agent. The Home Agent then generates a Session Key. This key is sent in two copies in the Registration Reply: one for the top level Foreign Agent encrypted with its public key and one for the Mobile Node encrypted with the shared secret. When the top level Foreign Agent receives the Registration Reply it decrypts the Session Key, and encodes it with the next lower level Foreign Agent's public key, and so on. The Mobile Node in turn can decrypt its copy of the key with the shared secret. [REGKEY]
The Foreign Agents in the old path already know the Session Key for the tunnel, so the target Foreign Agent for the authentication is the first Foreign Agent that is in both the old and the new path. When the point of attachment for the mobile node changes it authenticates itself with the target Foreign Agent by computing a message authentication code (MAC) for the signaling message using the Session Key. The MAC is then sent to the Foreign Agent along with the Registration Request, and as before each Foreign Agent along the new path sends its own public key to the next higher Foreign Agent. When the target Foreign Agent receives the Registration Request it checks the MAC with its own Session Key. It then sends a registration reply to the Mobile Node. In the registration reply it includes the Session Key encrypted with the next lower Foreign Agent's public key, and so on. This way the Foreign Agents in the new path will get the Session Key for the tunnel. [REGKEY]
This section describes the data associated with each of the three elements -- the Mobile Node, the Foreign Agent and the Home Agent -- that are to be implemented to give mobile users transparent and flexible routing of datagrams in the Internet.
The data that each element has to maintain can roughly be divided into two categories:
This section also describes how each element react to different events such as incoming messages and expiring timers.
All elements will use the Linux syslog system to log events.
The Mobile Node is the mobile computer from which a user wants to have the Internet available. In addition she wants to be reachable from other computers, even while visiting other networks.
The Mobile Node requires that there is always a co-located care-of address available. This makes the implementation more flexible and consistent.
The Mobile Node should be pre-configured with the following data:
The Mobile Node maintains the following parameters for a registered tunnel:
The Mobile Node accepts the following messages:
On receipt of a Registration Reply the Mobile Node will check if it has any pending unconfirmed Mobility Bindings, indexed by the identification field. If there is no match the reply will be silently discarded. Otherwise the lifetime and the decrypted Session Key is recorded and the binding is marked as confirmed. The Mobile Node configures the tunnel and the lifetime timer starts ticking.
If the Mobile Node has changed its point of attachment the Mobile Node will send a Registration Request to the sender of the Agent Advertisement.
Agent Advertisement messages contain information that shows if the Mobility Agent has booted. If the Mobile Node notice such information it should send a Registration Request to re-register.
If the Agent Advertisement is from the Mobile Node's Home Agent the Mobile Node will send a Registration Request with the lifetime value set to zero to deregister with the Home Agent.
An external event will notify the Mobile Node when its point of attachment has changed. This will make the Mobile Node send a Mobility Agent Solicitation message, so that registration with the Foreign Agent can begin.
some short time before the lifetime timer for a tunnel expires the Mobile Node sends a Registration Request. The time used will be defined in a later phase. The Request will not include a Session Key. This is so that Foreign Agents will know that they should forward the Registration Request up to the Home Agent
When the lifetime timer expires the Mobile Node purges the associated tunnel.
When the timer expires the Mobile Node will send a new Registration Request
The Mobile Nodes log the following events:
The Home Agent is responsible for forwarding packets to its Mobile Nodes when they are away from their Home Network. It also decapsulates and forwards tunneled packets originating from its Mobile Nodes.
For each authorized Mobile Node the Home Agent must be configured with:
For each registered Mobile Node the Home Agent will maintain the following data:
The Home Agent accepts the following messages:
On receipt of an Agent Solicitation Message the Home Agent replies to the sender with an Agent Advertisement Message.
On receipt of a Registration Request Message the Home Agent looks up the shared secret for the corresponding Mobile Node. The shared secret is used to check the MAC of the request message. If a Mobility Binding for the Mobile Node exists, then the timestamp in the request is checked that is greater than the one in the Mobility Binding. If either of these checks fail, the Home Agent responds to the sender with a Registration Reply with a code indicating registration failure. If the checks succeed the Home Agent will determine the smaller lifetime value of the one in the request and the Home Agent's pre-configured value. It will then generate a Session Key and create a Mobility Binding consisting of the Mobile Node's address, its highest Foreign Agent, the identification timestamp and the Session Key. The Home Agent then responds with a Registration Reply indicating registration success. The message includes the same timestamp as the request, the lifetime value, a MAC, the Session Key encrypted with the shared secret, the Session Key encrypted with the highest Foreign Agent's public key. The Home Agent configures a tunnel between itself and the highest Foreign Agent. From this point on the Home Agent works as a proxy ARP for the registered Mobile Node.
If the lifetime in the request is set to zero, the Home Agent interprets this as a deregistration from the Mobile Node. On deregistration the Foreign Agent purges the tunnel configuration and stops the proxy ARP functionality for the Mobile Nodes address.
When the lifetime timer for a mobility binding expires, the Home Agent will purge the associated tunnel.
The Home Agent will log:
The purpose of the Foreign Agent is to forward packets arriving from the upstream Mobility Agents to a downstream Mobility Agent or the Mobile Node.
The Foreign Agent should be pre-configured with the following data:
The Foreign Agent accepts the following messages:
On receipt of an Agent Solicitation message the Foreign Agent replies to the sender with an Agent Advertisement message.
On receipt of a Registration Request the Foreign Agent checks whether it has a pending mobility binding for the Home Agent specified in the request.
If the there is no pending binding, an unconfirmed binding is created. This binding will contain the Home Address, Home Agent, source address, identification and, if available, the public key retrieved from the request. The Registration Request is then forwarded to the pre-configured next upper Foreign Agent, but with the public key replaced with its own. The unconfirmed binding will be maintained for a specified interval that will be defined in a later phase.
If there is a pending binding and the source address of the binding and request differs then the MAC of the request message is checked with the Session Key. If the check fails the request is forwarded to the next higher agent. If there is a pending binding but source address of the binding and the request is the same, the request is forwarded to next higher agent. Otherwise the binding is updated, and a Registration Reply is sent to the source address of the request. If the request contains a public key, the Session Key is encrypted with it, and the encrypted Session Key is appended to the reply. The lifetime of the binding is set to the minimum of the requested lifetime and the remaining lifetime of the pending binding. This lifetime is returned in the reply. If the request has a lifetime of zero the binding will be purged.
If there is a pending binding but there is no MAC included in the Registration Request, the Foreign Agent forwards the request to the next higher Mobility Agent.
On the receipt of a Registration Reply the Foreign Agent will check if it has any pending unconfirmed mobility bindings, indexed by the Home Address, Home Agent and identification fields. If there is no match the reply will be silently discarded. Otherwise the lifetime and the decrypted Session Key is recorded and the binding is marked as confirmed. The Registration Reply is then forwarded to the care-of address found in the binding, but with the Session Key replaced by the Session Key encrypted with the recorded public key. A tunnel is configured and the lifetime counter starts counting down.
When the lifetime timer for a mobility binding expires, the Foreign Agent will purge the associated binding.
The Foreign Agents will log:
Two protocols will be used for signaling: Registration protocol for mobile registration in network and Keep Alive Protocol, which confirms that the tunnel is still working and should not be destroyed.
The protocol will be based on idea that the mobile is dumb and the network is smart. The mobile will not need to know anything about the structure of the Foreign Network. This approach is different from the one specified in Mobile IP standards [RFC2002]. The approach was selected because it minimizes the traffic over radio interface, results in simpler mobile construction, is easier to scale and minimizes the requirements for the Foreign Network (no need to identify the organization).
The protocol needs to negotiate the tunnel Lifetime, because different Mobile Agents may have different maximum Lifetimes for their tunnels. Also as a result the lowest maximum Lifetime is selected and propagated through the system. In the following the sequence of messages is presented. However, more detailed actions performed by the agents are presented in their respective descriptions.
The Mobile Node needs to know which Foreign Agents are present and it initiates registration by sending a Mobility Agent Solicitation message, which results in a Mobile Agent Advertisement message sent by lowest Foreign Agents. Having heard an advertisement message, the Mobile Node requests a tunnel of a specific type and lifetime by sending a Registration Request message to the lowest Foreign Agent.
Each Mobility Agent has three options to continue the protocol. They can reject the tunnel creation if they cannot accept any more connection. A rejecting Registration Reply is sent down in this case. They can accept a location update and send an accepting Registration Reply down. Otherwise the message is relayed further upwards and finally to the Home Agent. The Home Agent is then responsible for the acceptance or rejection of the tunnel.
Figure 1
Figure 2
The Keep Alive Protocol is used to confirm that the tunnel is still up and all Mobile Agents are within reach. The protocol is initiated by the Mobile Node when the tunnel's lifetime is ending.
The Mobile Node sends a Registration Request message without a Session Key. Foreign Agents relay the message to the Home Agent, which authenticate the message and replies with a normal Registration Reply confirming the tunnel again. Foreign Agents can now reset their tunnel timers having received a Registration Reply for the active tunnel. Finally the Registration Reply arrives to the Mobile Agent, which in turn now knows that the underlying tunneling is working. Otherwise the old tunnel should be destroyed and a new one requested.
If the mobile node decides that the tunnel is not working properly or is no longer needed, it can deregister itself from the network and purge the tunnel. This is accomplished with the Deregistering Protocol. The mobile node simply sends a Registration Request message with Lifetime set to zero to deregister the tunnel.
Four signaling messages are needed. Foreign Agents and Home Agents use Mobility Agent Advertisement messages to broadcast their presence. Mobile Nodes asks for Mobility Agent Advertisements with Mobility Agent Solicitation messages and initiate tunnels using Registration Request messages, which are passed through the hierarchy of Foreign Agents to the Home Agent. The Home Agent uses Registration Reply message to confirm tunnel creation. Registration Reply message passes back to mobile confirming the tunnel creation.
All messages have a type field. This information can be used to deduce the version of a message and what messages each element can accept.
The purpose of the Agent Solicitation message is for the Mobile Node to request an Agent Advertisement from a Mobile Agent.
An Agent Solicitation message is identical to an ICMP Router Solicitation [RFC1256] with the further restriction that the IP TTL field is set to 1. [RFC2002]
This message is broadcasted by Foreign Agents and Home Agents to inform the Mobile Nodes of their presence. The message must be broadcast even when the Mobility Agents cannot accept any more connections, because registered Mobile Nodes use these messages to determine that the Foreign Agent is still reachable and alive.
The messages should include the following information:
The Mobile Node sends a Registration Request when it wants to create or update a hierarchical tunnel. The message registers the Mobile Node with all the Mobility Agents between itself and up to and including the Home Agent. Each Mobility Agent receiving the request relays it to the next higher level care-of address in the hierarchy. [HIERFA]
The Registration Request is formatted as described in [HIERFA]. When relayed from a Foreign Agent it will contain the Foreign Agent Public Key Extension as described in [REGKEYS].
The message should include the following information:
The message is sent by Foreign Agents and Home Agents to indicate the failure or success of a Registration Request.
The message should include the following information:
There can be situations where something unexpected happens. The home agent, foreign nodes or the mobile node could crash or suffer from a power loss and reboot. Network connections could be very slow or have long delays. Radio channel disturbances might block the communication between the Mobile Node and Foreign Agent. Error recovery actions in situations like these must be defined.
Timeouts take care that the old tunnels are removed. Otherwise the information on unused tunnels might be active forever. Removing old tunnels after a timeout releases more system resources.
The Home Agent saves the necessary information from the databases to a disk drive to help recover from a power loss or system crash. At least the latest care-of address of the Mobile Nodes should be saved. For security reasons the session keys must not be saved to the disk. The session key can be regenerated after that kind of incident. The most important thing is just to know, where the Mobile Node can be reached in case a connection request is received from the Correspondent Host. However, if that information has been lost, incoming connections to the Mobile Node will report "Destination host unreachable" until the Mobile Node has re-authenticated after specified timeout.
If the Home Agent notices that the connection with the Correspondent Host in the Internet is lost, the Mobile Node will be informed about the loss of the connection.
The Home Agent will not accept broken or unauthorized packets from the Mobile Node. Those packets are dropped. Information about unauthorized packets will be logged.
The Foreign Agents save the connection information to the disk. If that information cannot be restored after the reboot, the Foreign Agent can ask the neighboring Foreign Agents to recover as much information as possible. If a connection information is lost, the Foreign Agent has to wait for the Mobile Node to re-register.
If the Mobile Node is rebooted, it will simply connect to the Foreign Agent as if it had just arrived in the Visited Network. As the rebooting closes all the connections, no more intelligent solution is required in the Mobile Node.
If the Mobile Node goes to area that is outside the radio coverage or otherwise unconnected to the network, the system does not close the connections immediately before the timeout. After the timeout the Mobile Node has to reconnect to the Visited Network.
Linux kernel includes two modules to support IP over IP tunneling, the encapsulator (tunnel.o) and the decapsulator (ipip.o). The tunnel driver is implemented as a network device. After the driver is loaded, it can be setup as any other network interface using ifconfig. The tunnel device is given the home address of the Mobile Node, and also the point-to-point address, namely the care-of address. After the device is configured for use, the 'route' command can be used to route traffic through the IP tunnel [REATUN]. Tunnel.o and ipip.o modules in the Linux kernel provide the base functionality for our implementation. Some additional code will be added to these modules. Modules use skb_* function calls which provide manipulation functionality for the IP packets. There are for example functions to add the extra header needed for encapsulation and to remove the extra header when decapsulating.
The users will be provided support tools to access the system. Following tools will be created:
Home Agent Configuration & Monitoring Tool is used to monitor and configure the home agent. All functionality provided by the Mobile Node API will be available.Foreign Agent Configuration & Monitoring Tool is used to monitor and configure the foreign agents. All functionality provided by Foreign Agent API will be available.
Mobile Configuration & Monitoring Tool is used to monitor and configure the mobile node. All functionality provided by Mobile Node API will be available.
Mobile Tunnel Control Tool provides mobile users the means to connect and disconnect from network as well as selecting the tunneling mode.
The programs will be started from the unix command prompt. Users may use the program's command line based interface or give commands as command line parameters. The commands will be in English and 'Help'-command will be available explaining what commands can be used, what they do and which parameters they require. The interface will support using the programs in scripts.
The monitoring commands will by dynamic, allowing the user to set the refresh interval.
The more precise functional description of the APIs follows.
The modularity in the mobility management security design will allow inserting additional cryptographic modules into the system. Adding modules won't need any big changes in the actual code. This is a relatively important property.
The purpose of this appendix is to give a checklist that each requirement has its place in the functional specification.
| Functional requirements | Supporting functionalities |
|---|---|
| Tunneling shall be hierarchical | Multiple Foreign Agents in Visited Network |
| The system shall update only those elements that need to be updated | On handover the Mobile Node registers with the first common Mobile Agent available in the current and previous hierarchy |
| The length of the tunnel shall not be explicitly restricted by the system architecture. | The protocol sets no practical limits on the tunnel length |
| The tunnel configuration information updates shall be dynamic | The Mobile Node daemon handles updates without user interaction |
| Further development and inter operability shall be supported | A version number in all messages is provided |
| The functionality should be transparent to the mobile user | The mobile user has to make manual static configuration once |
| The lowest foreign agents should use broadcasting to advertise availability | Foreign Agents broadcast Agent Advertisement messages |
| The mobile node shall select the lowest foreign agent | The Mobile Node selects Mobility Agent by sending Registration Requests |
| The home elements shall handle several concurrent users | The implementation places no limits |
| Mobility management information updates shall be secure | A shared secret and checksums provide security between the Mobile Node and Home Agent. |
| The system should support logging | The Mobile Node and Mobility Agents use Linux' syslog feature |
| Resource allocation should be optimized | Registrations can be limited to a specified lifetime |
| There may be multiple modes for tunneling | Bi-directional and triangle tunnel modes are supported by the design |
| Product requirements | Supporting functionality |
| The product maturity level shall be a working prototype | N/A |
| The software shall have an installation mechanism | See section "6.5 Installation" |
| The mobility management security design should be modular | Security parameters are sent as extensions in the messages and can be changed. |
| Each piece of the software should be configurable | Text files are used for configuration |
| There should be monitoring tools for the software | Monitoring tools are defined |
| There should be a programming API for the software | Programming API is defined |
| External requirements | Supporting functionalities |
| The mobility of the mobile computer shall be transparent to an external observer | IP packets to the Mobile Node are delivered in the conventional way to the Mobile Node's Home Network. The source address in IP packets are that of the Mobile Nodes home address. |
| The IP-protocol version shall be 4 | IPv4 is used |
| The platform should be Linux | Linux is used |
| Other requirements | Supporting functionalities |
| Tunneling should be possible with minimum firewall openings | Only a single port is used for control messages. Tunnels are IP over IP. |
| The software should not be a clear bottleneck | N/A |
| The portability should be taken into account | Defined in next phase |
To clarify how the mobile-IP with hierarchical foreign agents works, some concrete examples are given in this appendix.
Figure 3
All examples use the network configuration shown in Figure 3. To simplify the examples pseudo IP-addresses of the form network.node will be used.
The elements used in the examples are:
This example shows the basic operation when the Mobile Node registers in the Visited Network.
The following demonstrates an example where the corresponding host CN1 (address 3.13) wants to send a packet to MN1. MN1 then sends a packet back to CN1.
CN1 wants to send a packet to MN1:
MN1 wants to send a packet to CN1:
The following example shows what happens when the Mobile Node moves to another network with a new foreign agent, and how the tunnel is regionally updated.