RFC 2103

Mobility Support for Nimrod: Challenges and Solution Approaches ✨

Okay bestie, let's start with the title block 🎀

• Author: R. Ramanathan, BBN Systems and Technologies
• Series: Network Working Group, Request for Comments: 2103
• Category: Informational
• Date: February 1997
• Obsoletes / Updates: the header doesn't list anything this document obsoletes or updates

---

Status of This Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Abstract 💜

Okay so this doc is about mobility in Nimrod 🦋 A mobility solution isn't part of the Nimrod architecture, BUT Nimrod still needs that solution to have certain characteristics. The author lists the requirements Nimrod has for any mobility solution, then classifies and compares existing approaches for supporting mobility within an internetwork, and talks about their advantages and disadvantages. As an example, it outlines how Nimrod could support mobility using the scheme the IETF is currently developing, which is the Mobile-IP protocol 🔥

Table of Contents 🌸

   1  Introduction...................................................  1
   2  Mobility :  A Modular Perspective..............................  2
   3  Effects of Mobility............................................  4
   4  Approaches.....................................................  6
   5  Solution using IETF Mobile-IP.................................. 10
      5.1 Overview .................................................. 10
      5.2 Protocol Details........................................... 11
   6  Security Considerations........................................ 15
   7  Summary........................................................ 16
   8  Acknowledgements............................................... 16
   9  Author's Address............................................... 17

---

1. Introduction 🦋

The nature of emerging applications makes mobility support essential for any future routing architecture, and Nimrod wants to let physical devices as well as networks be mobile. Main character energy 💖

Okay so here's the tea. Nimrod, as a routing and addressing architecture, does not directly concern itself with mobility. In other words, Nimrod does not propose a solution for the mobility problem 💅 There are two chief reasons for this, ngl:

First, mobility is a non-trivial problem. Its implications and requirements are still not well understood, and they'll perhaps only be understood once a mobile internetwork is deployed on a large scale 🙈

Second, a bunch of groups, like the Mobile-IP working group of the IETF, are already studying the problem on its own, and Nimrod isn't trying to duplicate those efforts 🫶

This attitude is super consistent with Nimrod's general philosophy of flexibility, adaptability and incremental change ✨

While a mobility solution isn't part of the "core" Nimrod architecture, Nimrod does require that the solution have certain characteristics. So this document is here to discuss some of those requirements and evaluate approaches for meeting them 🧚

Here's the plan. We start by pinning down the precise functionality needed to accommodate mobile entities (section 2). After that, we look at the effects of mobility on Nimrod (section 3). Next, we classify current and possible approaches to a mobility solution (section 4). Finally, in section 5, we describe how mobility can be implemented using the IETF's Mobile-IP protocol 👑

This document uses lots of terms and concepts from the Nimrod Architecture document [CCS96], and some terms and concepts (in section 5) from the Nimrod Functionality document [RS96]. Most of the discussion assumes you've already read at least the Nimrod Architecture document [CCS96] 📚

2. Mobility : A Modular Perspective 🎀

Nimrod has a basic feature that helps accommodate mobility in a graceful and natural way, and that's the separation of the endpoint naming space from the locator space 🦋

The Nimrod architecture [CCS96] associates an endpoint with a globally unique endpoint identifier (EID) and an endpoint label (EL). The endpoint's location within the Internetwork topology is given by its locator. When an endpoint moves, its EID and EL stay the same, but its locator might change. Nimrod can route a packet to the endpoint after the move, as long as it's able to obtain the endpoint's new locator 💜

So, providing a solution to mobility in the context of Nimrod can be seen as maintaining a dynamic association between the endpoints and the locators. Taking this a step further, you can think of mobility-capable Nimrod as basically two "modules": the Nimrod routing module and the dynamic association module (DAM) 🧚 The DAM is an abstraction that embodies the functionality needed to maintain that dynamic association. It's a valuable paradigm because it makes it easier to compare various mobility schemes from a common viewpoint. The discussion is structured around the DAM abstraction, and it's in two parts, which are about:

• What constitutes mobility for the DAM and Nimrod? Is realizing mobility as a mobility "module" that interacts with Nimrod viable? And what are the interactions between Nimrod and such a module? These points are discussed in section 3.
• What are some approaches one can take in engineering the DAM functionality? Some approaches are classified and compared in section 4.

A word of caution: the DAM should NOT be thought of as equivalent to the current day Domain Name Service (DNS). The DAM is a more general concept than that 🙈

Let's look at an example. Consider a mobility solution for Nimrod similar to the scheme described in [Sim94]. Very roughly, the approach goes like this: every endpoint is associated with a "home" locator. If the endpoint moves, it tells a "home representative" about its new locator. Packets destined for the endpoint that are sent to the old locator get picked up by the home representative and sent on to the new locator 🌸 In this scheme, the DAM embodies the functionality implemented by all of the home representatives when it comes to tracking the mobile hosts. The point is that association maintenance, while required in some form or other, may not be an explicitly distinct part. It might instead be implicit in the way mobility is handled 💅

So the DAM is merely an abstraction that's useful to our discussion. It shouldn't be construed as dictating a design 🫶

In summary, we view the Nimrod architecture as carrying a functional "stub" for mobility, with the details of the stub deferred for later. The stub will be elaborated when a solution that meets the requirements of Nimrod becomes available (for instance, from the IETF Mobile-IP research). We don't preclude modifying any such solutions to meet the Nimrod requirements, and we don't preclude developing an independent solution within Nimrod either 🌈

---

Part 1 of 5 done! More parts coming, bestie 🦋💖

3. Effects of Mobility ✨

okay so first things first: mobility changing an endpoint's locator is the big one 💖 but it's NOT the only thing that happens. Some moves don't change the locator at all (a host hopping around inside a LAN, for example 🙈), and mobility can also change the topology map. That usually happens when a whole network moves, like an organization relocating or a wireless network on a train or plane hopping between cells 🚆✈️. And if the network is a Nimrod network, the node representing it can get different connectivity, which means the map changes too 🗺️

Here we look at what mobility does to the two "modules" from earlier: Nimrod, which handles routing to a locator, and a hypothetical DAM, which keeps the dynamic endpoint-locator association Nimrod needs 🦋. We check four scenarios, based on whether the topology and the endpoint's locator change, and talk about what each one means for Nimrod and the DAM.

• Scenario 1. Neither the locator nor the topology changes. This is the easy one 🌸 It doesn't affect the DAM or Nimrod. An example is a workstation moved to a new interface on the same local area network (this is not true for all LANs, only those in which all interfaces are part of the same Nimrod node), or when mobility is handled transparently (by lower layers).
• Scenario 2. The locator changes but the topology remains the same. This is when an endpoint moves from one node to another and its locator changes 🏃‍♀️ The DAM is affected, since it has to note the new endpoint-locator association and tell Nimrod about it if needed. The effect on Nimrod comes from getting that change from the DAM. For example, Nimrod may be told about the change, or it may ask for the association when it finds out the mobile host can't be reached.
• Scenario 3. The locator does not change but the topology changes. One way this happens is if a network node moves and changes its neighbors (a topology change) but stays inside the same enclosing node 🧩 The DAM is not affected, because the endpoint-locator association hasn't changed. Nimrod is affected, since the topology map now has to be updated.
• Scenario 4. Both the locator and the topology change. If a network node moves out of its enclosing node, both the map and the locators of the devices in that network change 😭 In this case, both Nimrod and the DAM are affected.

In scenarios 3 and 4, it may not be enough to just let Nimrod handle the topology change with the update mechanisms described in [RS96]. Those mechanisms are likely optimized for relatively slow changes 🐢

Mobile wireless networks (in trains and cars, for instance) are likely to cause more frequent topology changes 💨 So topological updates caused by mobility might need extra mechanisms. One idea is sending specific updates to the appropriate node representatives, so packets entering that node can be routed using the new topology. We also observe that accommodating network mobility, especially for fast-moving networks, might need a closer interaction between Nimrod and the DAM than endpoint mobility does. Specifying the nature of that interaction is beyond the scope of this document 🙅‍♀️ But a solution to mobility should handle the case where a network as a whole moves. Current trends [WJ92] suggest these situations will be common in the future, once wireless networks show up in trains, airplanes, cars, ships, and so on 🚢

---

Now the summary, which is kinda the tea ☕ If we ignore network movement (i.e., assume no topology changes), the mobility solution can stay fairly independent of Nimrod and can be handled by an implementation of the DAM 💅 But to deal with network mobility (scenarios 3 and 4), Nimrod routing and routers might need to get involved with mobility too.

Beyond what the Nimrod interaction forces, it would be nice if the mobility solution had some general features 🌈 By "general," we mean they aren't Nimrod-specific. Their importance in future applications is huge though, so they're worth mentioning here. The desirable features are:

• Support of both off-line and on-line mobility. Off-line mobility (or portability) is when a session is torn down during the move, while on-line mobility is when the session stays up during the move 📴📶 Right now a lot of mobility is off-line, but the trends say a large part of future mobility will be on-line. A solution that only supports off-line mobility would probably have limited applications in the future 🙃
• Scalability. Scalability is one of Nimrod's main goals, so it would go against our design goals if the mobility solution didn't scale 📈 The Internet is growing fast, and with Personal Communication Systems (PCS) [WJ92] arriving, the number and speed of mobile components is probably going to go up too. So scalability matters in three directions: the size of the network, the number of mobile entities, and how often those entities move 🔥

Note that for any given system with a minimum response time (to a move) of o seconds, if the mobile entity changes attachment points faster than 1=o changes per second, the system will fail to track the entity 😩 Augmenting traditional location tracking mechanisms with special techniques such as predictive routing might be necessary in this case. Hooks in the mobility solution for that kind of augmentation are a desirable feature 🪝

• Security. Secure communications are likely to be in higher demand in the future 🔐 Apart from the security mechanisms that aren't specific to mobility, the solution should address the following:
  • Authentication. The information a mobile host sends about its location should be authenticated to prevent impersonation 🕵️‍♀️ There should also be mechanisms to decide whether a mobile user who wants to join a network has the privileges to do so or not.
  • Denial of service. The schemes used for handling mobility in general could drain resources if they aren't controlled carefully 💀 In particular, the resource-intensive parts of the protocol should be guarded so that inappropriate use of them doesn't cause excessive load on the network. This one's serious, bestie.

4. Approaches

As we discussed in section 2, the problem of mobility in the context of Nimrod can be seen as keeping a dynamic association (the DAM) and communicating that association, and any changes to it, to Nimrod 🧠 Approaches to mobility can be sorted based on how the different aspects of the DAM are handled 🗂️

Our classification identifies two aspects of the mobility solution:

1. How and where to maintain the dynamic association between endpoints and locators? This can be thought of as a database maintenance problem 🗄️ The database could be maintained in a centralized way, where one single entity keeps the association and the mobile host sends it updates. Or it could be distributed, where several entities store the associations.

A (distributed) database that stores the endpoint-locator mapping is required by Nimrod even without mobility 💜 If this service can handle dynamic update and retrieval requests at the rate mobility produces, it's a candidate for a solution. However, we note that the availability of such a system should not be a requirement for the mobility solution.

2. Where to do the remapping between the endpoint and the locator when the association changes? By remapping, we mean associating a new locator with the endpoint 📍 Some candidates are: the source, the "home" location of the host that has moved, and any router (say, between the source and the destination) in the network.

Lots of the existing approaches, and maybe some new ones, to the problem of mobile internetworking can be seen as combinations of a dynamic association method and a remapping method 🧩 We consider some combinations as illustrated in Table 1.

                         (Re-mapping location)
                                   |
                                   v
          -----------------------------------------
          |            |Source |  Home  | Routers |
          -----------------------------------------
 (Assoc.  |Centralized |  A1   |   X    |    X    |
  maint)-> ----------------------------------------
          |Distributed |  X    |   A2   |   A3    |
          ----------------------------------------

Table 1 : Classification of approaches based on how the association is maintained and where the remapping is done.

We discuss three combinations (marked A1 - A3 in the table) and look at their advantages and disadvantages in the context of our requirements 🔍 The other combinations (marked X in the table) are possible, but they don't represent a substantially different class of solutions from the ones discussed, so they aren't considered here.

Note that this is just one classification of mobility schemes, and the remapping and endpoint-locator maintenance strategies in the table aren't exhaustive 🙏 The main goal is to help us understand the kinds of approaches that would be most suitable for Nimrod 💖

In the following, we use the term source for the endpoint that is trying to communicate with, or send packets to, a mobile endpoint. The source could be static or mobile 🚀 We use the term mobile destination for the endpoint that is the intended destination of the source's packets.

A1. In this approach, all endpoint-locator mappings are kept at a centralized location 🏛️ The source queries the database to get the locator of the mobile destination. Alternatively, the database can send updates to the source when the mobile destination moves. The main advantage of this scheme is its simplicity 🎀 Also, no modification to routers is required, and the route from the source to a mobile destination is direct ✨

The main disadvantage is vulnerability. If the centralized location goes down, all the information is lost 💀 While this scheme may be enough for small networks with low mobility, it doesn't scale well enough to be a long-term solution for Nimrod 😭

A2 is the one where the home does all the remapping, and it's giving "keep the house in order" 🏠💖. Every mobile endpoint is associated with a "home," and a "home representative" keeps track of where every mobile endpoint associated with it is. A protocol between the mobile endpoint and the home representative keeps all of that info up-to-date 🔄. The source sends the packet using the home locator of the mobile destination, and the home representative forwards it along to the mobile destination 📦. The vibe here is simple: it's fairly simple and doesn't involve either the source or the routers in the network 🧚.

It also gets the mobile destination a secret location ghost mode 🕶️. The mobile destination can keep its location secret, known only to the home representative. This is likely to be a desirable feature for mobile hosts in some applications 🙈. Most of the control info is confined to the node with the home representative and the mobile host, and that's a plus for scalability 📈 iconic.

BUT the main disadvantage is triangular routing 📐💀. The packets have to go from the source to the home representative first, before they get to the mobile destination. It's especially inefficient if the source and mobile destination are both in, say, England and the home representative is in, say, Australia 🦘🇬🇧 not it. There's also some vulnerability, because if the home representative becomes unreachable, the location of all the mobile hosts it tracks is lost, and communication from most sources to the mobile host gets cut off 😭. And it's not clear how well this scheme will scale to mobile internetworks of the future 🤷‍♀️.

Nevertheless, we feel that this approach, or a modification thereof, might be a viable first-cut mobility solution for Nimrod 🌸✨.

A3 is where the routers finally get involved 👑. In each of the previous cases, the routers in the network were not involved in tracking the location of the mobile host. In this approach, state is maintained in the routers 🧠. An example is the approach proposed in [TYT91], where the packets sent by a mobile host are snooped and state is created. The packets contain the mobile host's home location and its new location. This mapping is maintained at some routers in the network. When a packet intended for the mobile host, addressed to its home location, enters such a router, a translation is made and the packet is redirected to the new location 🦋.

There's also an alternate mechanism, which is to maintain the mapping in all of the border routers (e.g., forwarding agents) in the node within which the movement took place 🚪. A packet from outside the node intended for a destination within the node would typically enter the node through one of the border routers. Using the mapping, the border router could figure out the most recent locator of the mobile destination and send the packet directly to that locator 🎯. If most of the movements are within low level nodes, this would scale to large numbers of movements 🔥. Furthermore, the packet takes an optimal path (or as optimal as one can get with a hierarchical network) to the new location, within the time it takes for the node representative to get the new information. That time is typically quite small for low-level nodes ⚡.

The main disadvantage of this scheme is that routers have to be involved 😬. However, future requirements in regard to scalability and response time might necessitate such an approach 🚀. Furthermore, this solution has closer ties with Nimrod routing and is better suited to handling scenarios 3 and 4, where the topology changes as a result of mobility 🌈.

All of these approaches seem potentially capable of handling scenarios 1 and 2 of the previous section 💅. Scenarios 3 and 4 are best handled by an approach similar to A3. However, approaches like A3 are more complex and involve more Nimrod entities (e.g., routers) than may be desirable 🫠.

We have tried to bring out the various issues governing mobility in Nimrod 📝. In the final analysis, the tradeoffs between the various options will have to be examined vis-a-vis our particular requirements (for instance, the need to support network mobility) when adopting a solution 🧐. It is likely that general requirements such as scalability and security will also influence the direction of the approach to mobility in Nimrod 🔐💜.

---

5. A Solution using IETF Mobile-IP ✨

The Mobile-IP Working Group of the IETF is in the process of standardizing a protocol that allows an IPv4 capable network to support mobile hosts 🎀. In this section, we outline how mobility can be implemented within Nimrod using the same mechanism and, indeed, the same protocol headers defined in [Sim94] 🧚‍♀️. Not all functionality described in [Sim94] are covered. Only the ones that form the "core" of mobility support are 🫶.

In order to follow this section, the reader is required to have some familiarity with the IETF Mobile-IP protocol (see [Sim94]) 📚🤓.

5.1. Overview

The general scheme employed by the IETF Mobile-IP protocol is as follows 🦋. A Mobile Host (MH) has a predefined Home Agent (HA) that is responsible for the MH's whereabouts. Typically, the MH spends most of its time in the network containing the HA 🏡. Let us assume that the MH wanders to a new network 🧳. The MH then contacts a Foreign Agent (FA) at the new network, and that FA will act on its behalf. It sends a registration request to the HA via the FA 📨. This serves the purpose of informing the HA of the MH's new whereabouts, and it's also a means of verification of the MH's authenticity 🔑. It also contains the address of the FA as the new Care-of-Address 📍.

A correspondent host (CH) wishing to send a message to the MH uses the MH's Home IP address 💌. This message is captured by the HA and tunnelled using encapsulation to the FA. Then the FA decapsulates and sends the original message to the MH 🎁.

If the MH can get itself a new transient address, then there is no need for a Foreign Agent 🙌. The transient address will be sent as the Care-of-Address. The packets will be tunnelled directly to this address by the Home Agent. Note, however, that some networks may require that a mobile host go through a Foreign Agent 👀.

A fundamental difference between IP and Nimrod is that in the latter, an endpoint has both a (topologically sensitive) locator and a (topologically insensitive) endpoint-id (EID) 💫. In IP, the IP address serves as both the EID and the locator 🌸. Thus, it should be possible to use the Mobile-IP protocol for providing mobility support in Nimrod by simply using the EID of the MH wherever its Home IP Address was being used, and by appropriately using the EID and locator of the FA and HA in place of their IP addresses 🪄. (An issue is the format and length compatibility between EIDs and IP addresses. For the discussion here, we assume that an EID can fit into an IP (v4 or v6) address given in Figure 1 🤔.) We give below the details of the protocol fields and the actions taken by the MH, FA and HA, to show that this is possible and that it is quite simple 💖✨.

5.2. Protocol Details 💅

okay bestie, so there are two kinds of protocol headers in play here 🎀: the Mobile-IP Protocol headers (MIPP headers) and the headers for data packets carried by Nimrod (NP headers). The goal is for Nimrod to use the next generation IP (IPv6) header as much as possible ✨. The NP header basically contains, as a subset, the fields that will eventually show up in the IPv6 header 🦋.

In the scheme below, the MIPP header gets tucked inside the NP packet, so MIPP operates over NP. The details of the NP header fields are out of scope for this doc 🙈, but without getting into bit lengths, here are a few fields that matter for us:

• Source EID (S-EID): The endpoint ID of the source entity originating the packet.
• Destination EID (D-EID): The endpoint ID of the destination.
• Source locator (S-LOC): Locator of the entity originating the packet.
• Destination locator (D-LOC): Locator of the destination.

The MIPP header fields are described in [Sim94].

Next up, we describe the values that must be assigned to the relevant NP and MIPP fields so Nimrod can work with Mobile-IP. There are three phases we need to think about: agent discovery, registration and forwarding [Sim94] 🧚. A pictorial summary of the control and data packets is in Figure 1.

Agent Discovery 🔍

In this phase, the MH discovers the foreign agent, if any, that will act on its behalf. In MIPP, this is done using the ICMP Router Discovery messages.

When an MH attaches to a Nimrod network (node), foreign agent discovery goes like this. We assume a link-level connection is established between the MH and a node N that belongs to the network. For instance, this node could be a wireless equipped base station that sets up a signalling channel for talking to the MH 📡.

If the MH is itself a node, then N and the MH run an arc formation procedure between themselves, as described in [RS96]. This results in a locator being assigned to the MH and to the arcs between N and MH.

If the MH is not a node but only an endpoint, then the MH starts a locator acquisition procedure, as described in [RS96]. This results in a locator being assigned to the MH.

The MH then sends a Foreign Agent Request message to N. This message contains, amongst other information, the EID and locator of the MH. If N is not itself the foreign agent, then we assume that it knows of and has the ability to reach a foreign agent.

The foreign agent (FA) notes the EID of the MH in its Visitor List and sends a Foreign Agent Reply to the MH. This contains the EID and the locator of the FA, and it will be used as the "Care-of-Address" (COA) of the MH for a prespecified period 💜.

Registration 📝

In the registration phase, information is exchanged between the MH and the Home Agent (HA). The HA could, for instance, be the endpoint representative of the endpoint in its home location 🏠. The registration procedure is used to create a mobility binding, which the HA uses to forward data packets intended for the MH. Another purpose of registration is to verify the authenticity of the MH.

There are four parts to the registration. Here are the values assigned to the relevant fields. Remember, there are two headers we have to create: the Nimrod Protocol (NP) header and the Mobile-IP Protocol (MIPP) header. The NP fields are as described above, and the MIPP fields are as in [Sim94]. The fields mh-eid(mh-loc), fa-eid(fa-loc) and ha-eid(ha-loc) are used to refer to the EID (locator) of the mobile host, foreign agent and home agent respectively.

1. The MH sends a Registration Request to the prospective Foreign Agent to begin the registration process.
   • NP fields: S-EID = mh-eid; D-EID = fa-eid; S-LOC = mh-loc ; D-LOC = fa-loc.
   • MIPP fields: Home Agent = ha-eid; Home Address = mh-eid; Care-of-Address = fa-eid.

Note that the mh-loc is known to the MH by virtue of the locator acquisition (see paragraph on "Agent Discovery"), and that the fa-eid is known to the MH from the Foreign Agent Reply. The FA caches the mh-eid for future reference 🗂️.

2. The Foreign Agent relays the request by sending a Registration Request to the Home Agent, asking the Home Agent to provide the requested service.
   • NP fields: S-EID = fa-eid; D-EID = ha-eid; S-LOC = fa-loc; D-LOC = ha-loc.
   • MIPP fields: Same as in (copied from) (1) above.

The HA caches the (Home Address, Care-of-Address) as a mobility binding. Optionally, for efficiency, it may also cache fa-loc ⚡.

3. The Home Agent sends a Registration Reply to the Foreign Agent to grant or deny service.
   • NP fields: S-EID = ha-eid; D-EID = fa-eid; S-LOC = ha-loc; D-LOC = fa-loc.
   • MIPP fields: Home Address = mh-eid; code = as in [Sim94].

The S-EID and D-EID fields are taken from the Request and swapped, and the S-LOC and D-LOC fields are swapped too. The Home Address in the MIPP is the same as the Home Address in the Request. The code shows whether or not permission was granted by the Home Agent ✅❌.

4. The Foreign Agent sends a copy of the Registration Reply to the MH to let it know how its request went.
   • NP fields: S-EID = fa-eid; D-EID = mh-eid; S-LOC = fa-loc; D-LOC = mh-loc.
   • MIPP fields: Same as (copied from) (3) above.

At this point the MH is registered with the HA (provided the registration request is approved by the HA), and packets can be forwarded to the MH 🎉.

  +--------+
  |  CH    |
  +--------+
      V
      V
  #--------------#
  |mh-eid | data | = P(orig)
  #--------------#
      V
  +--------+  *----------------*   +--------+ *--------------* +------+
  |        |  |fa-eid | mh-eid |   |        | | ha-eid|mh-eid| |      |
  |        |  *----------------*   |        | *--------------* |      |
  |  HA    |------<-REG REQ-<------|  FA    |----<-REG REQ-<---| MH   |
  |        |   2                   |        |  1               |      |
  | mh-eid |                    3  | mh-eid |                4 |      |
  |   |    |------>-REG REPL->-----|   |    |---->-REG REPL->--|      |
  |   v    |  *----------------*   |   v    | *--------------* |      |
  | fa-eid |  |mh-eid | yes/no |   | mh-loc | |mh-eid|yes/no | |      |
  |        |  *----------------*   |        | *--------------* |      |
  |        |  #------------------# |        | #---------#      |      |
  |        |>>|       #--------# |>|        |>| P (orig)|>>>>> |      |
  +--------+5 |fa-eid | P(orig)| | +--------+ #---------#  6   +------+
              |       #--------# |
              #------------------#

Figure 1 : The control and data packets for mobility handling using the Mobile-IP protocol. The packets bordered as # denote data packets and those bordered * denote control packets. Only the crucial information conveyed in each message is shown (i.e., locators and EIDs in packet headers are not shown. The associations maintained at HA and FA are shown.

Forwarding Data 📦

We describe how a packet from the correspondent host (CH) intended for the MH is encapsulated and forwarded by the HA. Here's the tea ☕:

At HA: Suppose that a packet P intended for MH arrives at HA. For instance, P first comes to the router for the local network, and the router finds that MH is unreachable. The router then forwards P to the HA for possible redirection.

The HA extracts the destination EID from the NP header for P. If no match is found in its mobility binding, then the MH is deemed unreachable. If a match is found, the corresponding fa-eid is extracted. A new header is prepended to P. For this header, S-EID = ha-eid, D-EID = fa-eid, S-LOC = ha-loc and D-LOC = fa-loc. The fa-loc may be obtained from the Association Database [CCS96]. Alternatively, if it was cached in (2) above, it could be obtained from the cache.

At FA: By looking at the next header field in the Nimrod Protocol packet header, the FA knows that the packet is an encapsulated one. It removes the wrapping and looks at the EID in P. If that EID is found in the Visitor List, then the FA knows the locator of the MH and can deliver the packet to the MH. Otherwise, the packet is discarded and an error message is returned to HA 🚫.

Other Issues 🧐

We have not addressed a number of issues such as deregistration, authentication, etc. The mobility specific portion of authentication can be adapted from the specification in [Sim94]. Deregistration can be done in a manner similar to registration.

The protocol in [Sim94] describes a registration scheme without the involvement of the Foreign Agent. This is done when the MH obtains a transient IP address using some link-level protocol (e.g. PPP). A similar scheme can be given in the context of Nimrod. In this case, the MH obtains its locator (typically inherited from the node to which it attaches) and sends this locator as its Care-of-Address in the Registration Request. The HA, while forwarding, uses this as the locator in the outer NP header, and thus the encapsulated packet is delivered directly to the MH, which then decapsulates it. No Foreign Agent Discovery is needed. Apart from this, the fields are used as described for the scheme with the FA 🌈.

We note however that many networks may require that the registration be through a Foreign Agent, for purposes of security, billing etc.

---

6. Security Considerations 🔐

The registration protocol between a mobile host and the network (for instance, in the mobile-ip protocol, the MH and the HA) contains security mechanisms to validate access, prevent impersonation etc.

This document is not a protocol specification and therefore does not contain a description of security mechanisms for Nimrod.

7. Summary 🌸

• Nimrod permits physical devices to be mobile, but does not specify a particular solution for routing in the face of mobility.
• The fact that the endpoint naming (EID) space and the locator space are separated in Nimrod helps in accommodating mobility in a graceful and natural manner. Mobility may be perceived, essentially, as dynamism in the endpoint - locator association 🦋.
• Nimrod allows two kinds of mobility:
  • Endpoint mobility. For example, when a host in a network moves. This might cause a change in the locator associated with the host, but does not cause a change in the topology map for Nimrod.
  • Network mobility. For example, when a router or an entire network moves. This might cause a change in the topology in addition to the locator.
• Endpoint mobility may be handled by maintaining a dynamic association between endpoints and locators. However, network mobility requires addressing the topology change problem as well.
• Apart from the ability to handle network mobility, it is desirable that the mobility solution be scalable to large networks and large numbers of mobile devices, and provide security mechanisms.
• There are a number of existing and emerging solutions to mobility. In particular, adaptation of solutions developed by the IETF is a first cut possibility for Nimrod. As the description given in section 5 shows, it is relatively easy to implement the scheme being designed by the Mobile-IP working group in the context of Nimrod 👑.

8. Acknowledgements 💖

We thank Isidro Castineyra (BBN), Charles Lynn (BBN), Martha Steenstrup (BBN) and other members of the Nimrod Working Group for their comments and suggestions on this memo 🫶.

9. Author's Address ✨

Okay bestie, here's where to find the author! Ram Ramanathan was at BBN Systems and Technologies 🎀

Ram Ramanathan
BBN Systems and Technologies
10 Moulton Street
Cambridge, MA 02138

Phone :  (617) 873-2736
Email :  ramanath@bbn.com

References 💖

Here's the whole reading list, exactly as it's written, so you can go find every source yourself 🧚

[CCS96] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod
        Routing Architecture", RFC 1992, August 1996.

[RS96]  Ramanathan, S., and M. Steenstrup.  Nimrod functional and
        protocol specifications, Work in Progress.

[Sim94] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

[TYT91] F. Teraoka, Y. Yokote, and M. Tokoro.  A network architecture
        providing host migration transparency.  In Proceedings of ACM
        SIGCOMM, 1991.

[WJ92]  K. A. Wimmer and J. B. Jones.  Global development of pcs. IEEE
        Communications Magazine, pages 22--27, Jun 1992.