Mobile IP Registration


When the Mobile Node determines that is has moved, whether roaming across different FAs or returning home, it initiates a Mobile IP handover by entering into the Mobile IP registration phase. During this phase, the Mobile Node signals this location update to its Home Agent. This signaling is accomplished through a Mobile IP RRQs, one of the most important messages in Mobile IP. RRQ messages are the equivalent of a routing update, because they inform the network how to deliver traffic to the Mobile Node (through the CoA). A RRP is a positive or negative acknowledgment of the RRQ, and can be originated by either the Home Agent or FA. A depiction of the registration message exchange when the Mobile Node is in a Foreign Network is shown in Figure 2-13.

Figure 2-13. Registration Message Exchange in Foreign Network


For a Mobile IP handover other than returning home, upon successful exchange of a Mobile IP RRQ and Mobile IP RRP, the Mobile Node is said to be registered with the Home Agent (and FA if one is used) for the lifetime specified by the Home Agent in the RRP. Thus, in addition to sending RRQs as location updates, the Mobile Node must also send a RRQ to continue its registration if the lifetime is about to expire.

For a Mobile IP handover when returning home, the Mobile Node is said to be deregistering during the RRQ and RRP message exchange.

The RRQ and RRP messages are center to the Mobile IP registration phase. They are sent through User Datagram Protocol (UDP) signaling with destination port number 434.

NOTE

The UDP transport layer protocol is chosen over Transmission Control Protocol (TCP) because it is lighter-weight than TCP. The overhead and retransmission mechanism in TCP is unwarranted, because the RRQ messages can be retransmitted by the Mobile Node if an RRP is not received.


The message exchange must be unambiguous and secure because it alters routing to the Mobile Node. To this end, the messages are comprised of major components as follows.

RRQs are comprised of the following three major components:

  • Identification Unique identification of the RRQ and unique identification of the Mobile Node

  • Service Requests Negotiation of Mobile IP services

  • Authentication Parameters Security parameters for message authentication

Registration Replies are also comprised of the following three major components:

  • Identification Unique identification to match the RRP to the RRQ, and unique identification of the Mobile Node

  • Reply Codes Status of the Mobile Node's registration

  • Authentication Parameters Security parameters for message authentication

In the next sections, we look into the details of each message and describe how they impact behavior on the different Mobile IP entities. After you gain an understanding of what the messages look like and what they convey, we look into message delivery and how the messages accomplish the Mobile IP handovers outlined in the section "Mobile IP Handover," in this chapter.

Identification

A crucial aspect of the Mobile IP registration message exchange is that the messages must be unique and specific in their identity. Two types of identification appear in each RRQ and RRP message: one to identify the Mobile Node and one to identify the registration or reply message itself. A unique Mobile Node identifier is required to determine who the request is coming from, what services are available for this Mobile Node, and which authentication tokens should be used for this Mobile Node. Mobile Node identification is either through a statically allocated Home Address (Home Address field) or a Network Access Identifier (NAI) extension, defined in RFC 3846, which can be used with dynamic Home Address allocation, as described in Chapter 8, "Deployment Scalability and Management."

NOTE

The NAI concept was first introduced as a way to support PPP roaming. Users are identified by either a username or a username and a realm, represented in the form user@realm. While an NAI looks similar to an e-mail address, the realm portion does not need to be a fully qualified domain name. The use of a realm allows users to be classified into groups; the groups can signify different administrative domains, different service classes, or both. The username portion uniquely identifies the individual within that group.


The second identifier in the Mobile IP messages uniquely identifies the registration or reply message. This field is referred to as the identification field in the RRQ and RRP, and is chosen by the Mobile Node to uniquely distinguish each registration attempt. The identification field allows the Mobile Node to correlate each RRQ with its corresponding received RRP. Several pending RRQs can exist for a Mobile Node at a given time, and hence, the Mobile Node can match each outstanding RRQ with its RRP. The identification field prevents replay attacks of the RRQ specifically, because it is unique in each RRQ and thus thwarts a bad-intentioned node from keeping a copy of an RRQ and replaying it at a later time. Use of the identification field is covered in depth in Chapter 3, "Mobile IP Security."

Services

A key outcome of the Mobile IP registration phase is for the Mobile Node and Home Agent to agree on the Mobile IP services that are to be provided during the lifetime of the registration. You might have already pieced together how this "negotiation" occurs, but we risk stating the obvious. A Mobility Agent advertises the Mobile IP services that it is willing to provide in its agent advertisements. The Mobile Node then requests particular services in its RRQ. The FA and Home Agent either accept or reject these requests in the RRP.

Most of the services that a Mobile Node can request center around the Mobile IP tunnel and associated delivery options. For example, a Mobile Node can request that a specific CoA be used as the tunnel endpoint, and a particular encapsulation be used for the tunnel. Services can be requested either by setting specified option bits in the RRQ or by appending appropriate Mobile IP extensions. The use of extensions allows new services to be added to the Mobile IP protocol at any time. (Mobile IP includes provisions for 256 types of extensions, but extension subtypes can add an unlimited number of extensions.) All Mobility Agents must understand extensions of type 0127 (considered critical extensions), or the entire RRQ that contains the extension must be silently discarded. This is because Mobile IP connectivity can depend on the nonoptional parameters conveyed in these extensions, and if an agent does not understand what is being requested, simply ignoring the extension and processing the rest of the request are likely to result in problems. On the other hand, options that do not critically affect connectivity, namely, extensions of type 128255, might be ignored if they are not understood, with the rest of the RRQ, including all extensions, processed as normal.

Service Fields and Bits

The standard services offered in Mobile IP are best described by the different option bits and relevant fields in the RRQ, which are as follows:

  • CoA field The Mobile Node requests that the Mobile IP tunnel terminate at this address. This address can be an FA-CoA or a CCoA.

  • Lifetime field The Mobile Node requests Mobile IP services for this time period. If this field is set to 0, the Mobile Node is requesting a deregistration, either because it has roamed back to the Home Network or it is powering down.

The options bits are S, B, D, M, G, and T; when set to 1, the bits mean the following:

  • SA Mobile Node is requesting the use of simultaneous bindings. This requires the Home Agent to duplicate all packets and forward them to multiple CoAes.

  • BA Mobile Node is requesting that broadcast datagrams from its Home Network be delivered to it.

  • DThe Mobile Node is specifying that it can perform the Mobile IP tunnel decapsulation, that is, the Mobile Node is using a CCoA and, thus, is the tunnel endpoint.

  • MThe Mobile Node is requesting that the Home Agent use minimal encapsulation, as defined in RFC 2004, instead of IP-in-IP encapsulation for the Mobile IP tunnel.

  • GThe Mobile Node is requesting that the Home Agent use GRE, as defined in RFC 1701, instead of IP-in-IP encapsulation for the Mobile IP tunnel.

  • TThe Mobile Node is requesting reverse tunneling for packets originated by the Mobile Node. (Reverse tunneling is described in Chapter 6.)

To perform a Mobile IP handover other than returning home, the Mobile Node sends a RRQ, requesting relevant Mobile IP services and requesting that the Home Agent tunnel its packets to the CoA specified for the lifetime requested. If the RRQ and requested services are accepted by the FA and Home Agent, a RRP indicating success is received by the Mobile Node, with the registration lifetime specified in the lifetime field. The actual lifetime of the registration is determined by the Home Agent in the RRP and can differ from the lifetime requested by the Mobile Node in the RRQ.

On the other hand, if the RRQ is rejected, a RRP with a failure code (as outlined in the section "Registration Reply Codes," later in this chapter) is received by the Mobile Node. Many Mobile IP services are negotiated in this manner, that is, the Mobility Agent rejecting the RRQ sends a RRP with an appropriate error code, indicating to the Mobile Node how to amend its request.

If a Mobile Node commences a Mobile IP handover to return home or if it decides to power down, it sends a RRQ with the lifetime field set to 0 and the CoA field set to its Home Address. This type of RRQ is known as a deregistration.

Broadcast Support

If the Mobile Node requests that broadcast datagrams (by setting the B bit) be forwarded from its Home Network, care must be taken to ensure that the broadcasts do not appear on the visited network, but are delivered directly to the Mobile Node. The action that the Home Agent takes to ensure this depends on where the Mobile IP tunnel is terminating in the Foreign Network.

In the case that the tunnel terminates on the FA, the Home Agent encapsulates the broadcast datagram in a unicast IP packet destined for the Mobile Node's Home Address. This encapsulated packet is then sent through the Mobile IP tunnel as any other datagram, resulting in double encapsulation. The outer encapsulation allows the packet to be sent down the Mobile IP tunnel, and the inner encapsulation allows the FA to know which Mobile Node to forward the inner broadcast datagram. It is the responsibility of the Mobile Node to remove this inner encapsulation header to receive the broadcast datagram. This implies that the Mobile Node must be able to decapsulate packets to request broadcast support.

When the Mobile Node is using a CCoA and registering directly with the Home Agent, the Home Agent simply tunnels the broadcast datagram as any other packet destined for the Mobile Node. The extra inner encapsulation is not necessary because datagrams are tunneled directly to the Mobile Node.

Simultaneous Bindings

When the Mobile Node requests simultaneous bindings (by setting the S bit), it is requesting that the Home Agent maintain this mobility binding in addition to mobility binding(s) that the Home Agent might already have for it. If the Home Agent accepts the request, it duplicates each data packet and sends a copy to the CoA in each of the mobility bindings simultaneously, as shown in Figure 2-14.

Figure 2-14. Simultaneous Bindings


Simultaneous binding support is often interpreted as a feature necessary to have a Mobile IP handover occur without packet loss. Mobile IP is often perceived as a "break before make" protocol, that is, the current Mobile IP connection is lost before a new Mobile IP registration is made. Using simultaneous bindings is perceived as making Mobile IP a make before break protocol because the bindings seem to provide a good communication path before the old path goes away. In practice, these characterizations are, for the most part, link-layer phenomena, and while simultaneous bindings can achieve a Mobile IP handover without packet loss, to leverage it with a single roaming interface, the underlying link layer must be designed for proper support. However, even then, a significant advantage over a standard Mobile IP handover would be unlikely.

Regardless of whether simultaneous bindings are used, Mobile IP generally switches over instantly without packets being discarded by the Home Agent. This can be clearly seen when two different link types are being used and a Mobile Node is handing over from one active link to another active link. Packets to the Mobile Node are tunneled through the initial link until a reregistration is accepted by the Home Agent. At this point, the Home Agent immediately starts forwarding packets to the new CoA. As long as both links are active, no packets are lost, providing a Mobile IP handover without packet loss and without simultaneous bindings, as illustrated in Figure 2-15.

Figure 2-15. Mobile IP Handover Without Simultaneous Bindings


NOTE

Here is the worst case: If the initial link is slower than the new link, some packets can arrive out of sequence. However, this problem is not solved with simultaneous binding support, because it is an effect of the link speed, not the Mobile IP routing. However, if the link-layer capabilities of the Mobile Node were such that it could associate with two lossy links at the same time, simultaneous bindings can improve the probability that the Mobile Node can correctly receive its packets, because they are tunneled to both locations.


Authentication

Mobile IP authentication is covered in depth in Chapter 3, but you should understand the authentication concepts at this stage to understand the full capability of the Mobile IP registration messages and any appended Mobile IP extensions. To this end, we provide an overview of the concepts and refer you to Chapter 3 for more details.

Like other routing protocols, Mobile IP uses digital signaturestyle authentication to protect routing updates (that is, the RRQ and RRP) and is accomplished using authentication extensions (AEs). Different types of authentication extensions exist, each used to establish a bidirectional trust relationship between two specific Mobile IP entities. The critical purpose of the authentication extensions is to verify the sender of the message or portion of the message and to ensure that the message (or portion) was not altered while in transit.

Unlike other routing protocols, authentication between the Mobile Node and its Home Agent is mandatory for all routing updates. Because the registration messages alter routing to the Mobile Node, the information exchanged during the registration phase must be protected. To accomplish this, the Mobile NodetoHome Agent Authentication Extension (MHAE) provides a bidirectional trust relationship between the Mobile Node and its Home Agent. It is the only authentication extension that is required in every RRQ and RRP. Other authentication extensions facilitate a bidirectional trust relationship between the Mobile Node and the FA (MFAE), the FA and the Home Agent (FHAE), and the Mobile Node and an authentication, authorization, and accounting (AAA) server (Mobile Node-AAA), as seen in Chapter 3.

The security of any appended Mobile IP service extensions depends on their placement relative to the authentication extensions present in the Mobile IP messages. For example, the FA can append a service extension after the mandatory MHAE and then secure it with an FHAE. Thus, controlling the placement of service extensions in this way allows extensions to be added and removed by individual Mobile IP entities in the path without impacting the integrity of the data protected by other authentication extensions. For example, Figure 2-16 shows how the MHAE authenticates only the information between the UDP header and the MHAE, while the FHAE protects the information between the UDP header and the FHAE, that is, including the FA-appended extensions.

Figure 2-16. Use of Mobile IP Authentication Extensions


Relevant Address Fields

The different IP address fields within the Mobile IP RRQ message and the IP tunnel header depend on the registration situation and Mobile IP handover. Although it might seem confusing at first, it is quite straightforward. The possible Mobile IP handovers lead to the following four main registration scenarios:

  • A Mobile Node registering with an FA-CoA through a FA

  • A Mobile Node registering with a CCoA directly with its Home Agent

  • A Mobile Node registering with a CCoA through a FA

  • A Mobile Node deregistering with its Home Agent

In scenarios 13, the Mobile Node can operate either with a statically allocated Home Address or it can request a dynamically allocated Home Address. If the Mobile Node is requesting a dynamically allocated address, the Home Address field of the RRQ is 0.0.0.0. Table 2-1 outlines the different scenarios and IP address values.

Table 2-1. Registration Request Address Field and IP Header Values Set by the Mobile Node
 

1

FA-CoA through FA

2

CCoA to Home Agent

3

CCoA through FA

4

Deregistration

IP Source Address

Mobile Node's Home Address or 0.0.0.0

CCoA2

CCoA2

Mobile Node's Home Address3

IP Dest. Address

An interface address on the FA

Home Agent's IP address

An interface address on the FA

Home Agent's IP address

Home Agent Address

Home Agent's IP address

Home Agent's IP address

Home Agent's IP address

Home Agent's IP address

CoA

FA-CoA[1]

CCoA[2]

CCoA[3]

Mobile Node's Home Address[3]

Home Address

Mobile Node's static Home Address or 0.0.0.0 for dynamic allocation

Mobile Node's Home Address[3]


[1] This is the FA-CoA learned from the FA advertisement.

[2] his is an address in the foreign domain that is obtained through DHCP, manual configuration, or other means.

[3] his is either the Mobile Node's static Home Address or the dynamically allocated Home Address.

Example 2-2 shows the RRQ message in detail. In this example, the Mobile Node has an NAI (user@example.com) and is requesting that a Home Address be dynamically allocated. The Mobile Node is registering through a FA (192.168.100.28) with its Home Agent (192.168.101.1). It is requesting a registration lifetime of 2 hours and is appending an mobile foreign challenge extension (MFCE) and Mobile Node-AAA extension on top of the mandatory MHAE. (The MFCE and Mobile Node-AAA extensions are described in Chapter 3.)

Example 2-2 is a packet capture and decode of a RRQ taken with Ethereal, a network protocol analyzer. Protocol analyzers are widely used for troubleshooting and provide a field-by-field view of the packet.

Example 2-2. Mobile IP Registration Request Protocol Detail
 Internet Protocol, Src Addr: 0.0.0.0 (0.0.0.0), Dst Addr: 192.168.100.28   (192.168.100.28)     Version: 4     Header length: 20 bytes     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)         0000 00.. = Differentiated Services Codepoint: Default (0x00)         .... ..0. = ECN-Capable Transport (ECT): 0         .... ...0 = ECN-CE: 0     Total Length: 118     Identification: 0x6c41     Flags: 0x00         .0.. = Don't fragment: Not set         ..0. = More fragments: Not set     Fragment offset: 0     Time to live: 255     Protocol: UDP (0x11)     Header checksum: 0x2a71 (correct)     Source: 0.0.0.0 (0.0.0.0)     Destination: 192.168.100.28 (192.168.100.28) User Datagram Protocol, Src Port: mobileip-agent (434),     Dst Port: mobileip-agent (434)     Source port: mobileip-agent (434)     Destination port: mobileip-agent (434)     Length: 98     Checksum: 0xe7f7 (correct) Mobile IP     Message Type: Registration Request (1)     Flags: 0x00         0... .... = Simultaneous Bindings: False         .0.. .... = Broadcast Datagrams: False         ..0. .... = Co-lcated Care-of Address: False         ...0 .... = Minimal Encapsulation: False         .... 0... = GRE: False         .... .0.. = Van Jacobson: False         .... ..0. = Reverse Tunneling: False     Lifetime: 7200     Home Address: 0.0.0.0 (0.0.0.0)     Home Agent: 192.168.101.1 (192.168.101.1)     Care of Address: 192.168.100.28 (192.168.100.28)     Identification: Jan 13, 2003 12:52:34.389797056     Extensions         Extension: Mobile Node NAI Extension     Extension Type: Mobile Node NAI Extension (131)     Extension Length: 12     NAI: user@example Extension: Mobile-Home Authentication Extension     Extension Type: Mobile-Home Authentication Extension (32)     Extension Length: 20     SPI: 0x00000100     Authenticator: CF62301B0031DB59959A12B3E0AC939C Extension: Mobile Node-FA Challenge Extension     Extension Type: MN-FA Challenge Extension (132)     Extension Length: 4     Extension: 179823C4 Extension: Generalized Mobile-IP Authentication Extension     Extension Type: Generalized Mobile-IP Authentication Extension (36)     Gen Auth Ext SubType: MN AAA Extension (1)     Extension Length: 20     SPI: 0x00000002     Authenticator: DF0461262E7DDB651E2C68B9180EC3AC 

Here are the descriptions of the fields in the IP Header:

  • Source Address This is the CoA if the request has been forwarded by the FA or if the Mobile Node is using a Colocated CoA. Otherwise, the source is the Mobile Node's Home Address. If the Mobile Node does not have a Home Address, it is 0.0.0.0.

  • Destination Address This is either the Home Agent's IP address or the source address from the agent advertisement, but not necessarily the CoA.

  • Destination Port The destination port in the UDP Header is always 434.

Here are the descriptions of the fields in the Mobile IP Registration:

  • Type This is 1 for a RRQ and 2 for a RRP.

  • Simultaneous Bindings Flag The Mobile Node would like the Home Agent to duplicate packets and send them to multiple CoAes.

  • Broadcast Datagrams Flag The Mobile Node would like broadcast packets from the Home Network to be tunneled to its current location.

  • Colocated Colocated Care- of Address (CCoA) FlagThe Mobile Node is using a Colocated CoA and not a FA.

  • Minimal Encapsulation Flag The Mobile Node would prefer to use minimal encapsulation for the tunnel instead of IP-in-IP encapsulation.

  • GRE Flag The Mobile Node would prefer to use GRE for the tunnel instead of IP-in-IP encapsulation.

  • Van Jacobson Flag This flag has been deprecated because it was deemed unimplementable.

  • Reverse Tunneling Flag The Mobile Node would like traffic to be reverse tunneled.

  • Lifetime This is the length of time in seconds that the Mobility Agent can retain an active binding. The lifetime value can range from 0 to 65,535 seconds. If the lifetime is 0, the Mobile Node is deregistering. A lifetime value of 65,535 is infinite.

  • Home Address This is the Mobile Node's Home Address. If the Home Address is set to 0.0.0.0, the Mobile Node would like a Home Address to be dynamically allocated.

  • Home Agent This is the IP address of the Mobile Node's Home Agent. This can be 0.0.0.0 if dynamic Home Agent assignment is being used.

  • CoA This is the address that the Mobile Node would like all traffic tunneled to.

  • Identification The identification field prevents replay attacks. It is usually represented as an NTP-style timestamp.

  • Extensions These begin with a type and length and then are followed by extension-specific data.

Registration Reply Codes

A RRP is sent either by a FA or a Home Agent in response to a RRQ. In the case of an FA-CoA, if the FA accepts the RRQ from the Mobile Node, it forwards the request to the Home Agent. However, if the FA rejects the RRQ or cannot forward the request to the Home Agent, it immediately sends a RRP with an appropriate error code, and does not propagate the reply to the Home Agent. Similarly, if the FA receives a RRP from the Home Agent and deems the reply to be invalid, it generates a new RRP with the appropriate error code. The possible FA reply codes are as follows:

        64 reason unspecified        65 administratively prohibited        66 insufficient resources        67 mobile node failed authentication        68 home agent failed authentication        69 requested Lifetime too long        70 poorly formed Request        71 poorly formed Reply        72 requested encapsulation unavailable        73 reserved and unavailable        77 invalid care-of address        78 registration timeout        80 home network unreachable (ICMP error received)        81 home agent host unreachable (ICMP error received)        82 home agent port unreachable (ICMP error received)        88 home agent unreachable (other ICMP error received) 

The FA attempts to use a specific reply code so that the Mobile Node knows why the registration was rejected. For example, the FA can send back error code 72 to indicate that the requested encapsulation [is] unavailable so that the Mobile Node can request a different encapsulation type in its next registration attempt.

When the Home Agent receives the RRQ, it generates a RRP. The Home Agent either responds with a successful reply code or an appropriate error code. The possible Home Agent reply codes are as follows:

 Registration successful:       0 registration accepted       1 registration accepted, but simultaneous mobility         bindings unsupported Registration rejected by the home agent:       128 reason unspecified       129 administratively prohibited       130 insufficient resources       131 mobile node failed authentication       132 foreign agent failed authentication       133 registration Identification mismatch       134 poorly formed Request       135 too many simultaneous mobility bindings       136 unknown home agent address 

Registration Delivery

By this timealthough this might fall into the same category as saying that a stop sign says "STOP"a Mobile IP RRQ is initiated by a Mobile Node to commence a Mobile IP handover. The delivery details of the RRQ and RRP messages during the Mobile IP handover depend on whether a FA is being used. A Mobile Node can either forward a RRQ directly to the Home Agent if it is operating in CCoA mode without a FA or it is deregistering from its Home Network; otherwise, it forwards the request to the FA. The behavior of the Mobility Agents depends on the success of the messages and the type of Mobile IP handover being performed.

Regardless of the Mobile IP handover, when a FA receives a RRQ, it first verifies any necessary security associations. It then verifies that it is capable and allows the Mobile IP services requested by the Mobile Node. If the FA cannot or does not provide the requested services, it generates a RRP with an appropriate failure code, as described in the previous section.

If the FA can provide all the requested services, it creates an entry in its pending registration table. The pending registration table tracks RRQs that have not yet received a reply from the Home Agent. A pending registration is held by the FA for a maximum of 7 seconds before assuming that the Home Agent is unavailable. If an RRP is not received from the Home Agent, the FA generates a RRP with a registration timeout error code.

When the Home Agent receives the RRQ, either from the FA or directly from the Mobile Node, it begins by verifying the relevant security associations, as covered in Chapter 3. After the authenticity of the RRQ has been verified, the Home Agent begins to process the request, and if at any time the Home Agent cannot successfully support the request of the Mobile Node, it sends a RRP with an appropriate error code, as described in the previous section.

After this point, the behavior of the Mobility Agents depends on the type of Mobile IP handover being initiated in the RRQ.

Mobile IP Handover Other Than Returning Home

For a RRQ initiating a Mobile IP handover other than returning home, as the first step in processing the RRQ, the Home Agent determines whether a Home Address must be allocated for the Mobile Node by examining the home address field of the RRQ. (If the Mobile Node is requesting that a Home Address be dynamically assigned, it sets the Home Address field of the RRQ to 0.0.0.0, as described in the section "Relevant Address Fields," earlier in this chapter.) If a dynamic Home Address is needed, the Home Agent allocates an address to the Mobile Node that can be retained for as long as the Mobile Node is registered with the Home Agent. Details of dynamic Home Address allocation can be found in Chapter 8.

The Home Agent then updates the Mobile Node's mobility binding, if it already exists, or creates a new mobility binding for the Mobile Node. The mobility binding is a structure that keeps track of the attributes of an active Mobile Node. The Home Agent uses the binding to monitor which Mobile IP services are in use by the Mobile Node, the current CoA, and the lifetime of the registration. The Home Agent maintains the mobility binding in a binding table, which is a database of all the active Mobile Nodes and is a similar concept to the database in OSPF. Mobility bindings are uniquely indexed within the binding table by the Mobile Node's Home Address and are removed if the lifetime of the binding expires.

The Home Agent uses the information in the mobility binding to create a Mobile IP tunnel between itself and the CoA. It updates its routing table so that traffic for the Mobile Node is sent on the tunnel. The Home Agent then sends a gratuitous ARP on the Home Network to attract all traffic for the Mobile Node. This ensures that the Mobile Node's traffic is delivered to the Home Agent and, thus, can be sent down the Mobile IP tunnel to the Mobile Node. The result of the registration message exchange can be seen in Figure 2-17.

Figure 2-17. Result of a Successful Mobile IP Registration


Finally, the Home Agent sends a RRP to the Mobile Node, either through a FA, if one is used, or directly. If the Home Agent allocated a dynamic Home Address for the Mobile Node, it includes the assigned address in the home address field of the RRP.

When the FA receives the RRP and deems the reply valid, it considers the Mobile Node to be visiting on its network. It moves the pending registration entry for the Mobile Node into its visitor table. The visitor table keeps track of all the Mobile Nodes with active sessions and is analogous to the binding table in the Home Agent. The visitor entry is not removed until the lifetime expires or until a Deregistration Reply, as described in the next section, is received.

Mobile IP Handover Returning Home

Upon successful receipt of a Deregistration Request by a Mobile Node initiating a Mobile IP handover to return home or powering down, the Home Agent tears down the Mobile IP tunnels and dismantles (removes) the mobility binding. At this point, Mobile IP is no longer used for routing to the Mobile Node. The Home Agent sends a RRP, in this case known as a Deregistration Reply, to the Mobile Node.

If the FA receives the Deregistration Reply, it removes the corresponding Deregistration Request from its pending registration table and removes the Mobile Node's visitor table entry. The FA can only receive a Deregistration Reply for a Deregistration Request that it forwards. The FA forwards the Deregistration Reply to the Mobile Node.

Upon deregistration, the Mobile Node sends out a gratuitous ARP on the Home Network to ensure that its traffic is delivered to it and is no longer delivered to the Home Agent. Typically, the Mobile Node surrenders a dynamically allocated Home Address at this point.

Mobile IP Example

We now look at a Mobile IP example to get a good feel for the protocol. Consider a Mobile Node with a single interface whose Home Address is 192.168.10.30 and Home Agent is 192.168.10.1. In this example, the Mobile Node roams away from home to FA 192.168.100.6, and then to another FA, 192.168.200.6. It then finds itself still roaming, but not within the domain of a FA. At this point, it obtains a Colocated CoA and continues to roam. After some time, it returns home. The example is as follows:

  1. The Mobile Node powers on and hears a Mobility Agent advertisement with the H bit set and router address as 192.168.10.1. Using this information and other relevant information from the advertisement, the Mobile Node recognizes that it is at home and does nothing.

  2. At some later time, the Mobile Node hears another Mobility Agent advertisement with the F bit set, router address as 192.168.100.6 with a prefix length extension of /24, and CoA as 192.168.100.6. The Mobile Node detects that it has moved into a foreign domain and can request services by this FA. Using the new network algorithm, the Mobile Node determines that it needs to initiate a Mobile IP handover.

  3. The Mobile Node sends a RRQ to its Home Agent through the FA. It conveys its new CoA (192.168.100.6) and its Home Address (192.168.10.30). As required, the Mobile Node appends an MHAE with the correct security credentials. The IP source of the RRQ is the Mobile Node's Home Address (192.168.10.30), and the IP destination is the FA (192.168.100.6).

  4. The FA receives the RRQ, validates the requested services, creates an entry in its pending registration table, and forwards it on to the Home Agent. The IP source of the RRQ is now the FA 192.168.100.6, and the IP destination is the Home Agent 192.168.10.1.

  5. The Home Agent authenticates and then validates the RRQ. The Home Agent establishes the mobility binding and Mobile IP tunnel to the CoA, sends a gratuitous ARP on the Home Network, and sends a positive RRP to the Mobile Node through the FA (the IP source is the Home Agent 192.168.10.1, and the IP destination is the FA 192.168.100.6). As required, the Home Agent appends an MHAE with the correct security credentials.

  6. The FA receives the RRP, verifies that it is a successful reply, and changes the pending registration entry into a visitor entry for the Mobile Node. The FA then forwards the RRP to the Mobile Node using link-layer addressing.

  7. The Mobile Node receives the RRP and enjoys the established Mobile IP services for the lifetime granted, or until it moves again and must reregister.

  8. At some time later, the Mobile Node hears a Mobility Agent advertisement with the F bit set, router address 192.168.200.6 with a prefix length extension of /24, and CoA of 192.168.200.6. This time, the Mobile Node uses the steady-state algorithm and, thus, does not do anything until its current FA's advertisement expires, even though it hears this new FA advertisement.

  9. Upon expiry of its current FA's advertisement, the Mobile Node initiates a Mobile IP handover and sends an updated RRQ to its Home Agent with the new CoA of 192.168.200.6. The RRQ and RRP follow the same logic as previously described, and the Mobile Node successfully registers with the new FA.

  10. The Mobile Node realizes that it has not heard an advertisement from its FA in some time and that the hold time is about to expire. It sends out an agent solicitation in hopes of finding a FA.

  11. The Mobile Node receives no Mobility Agent advertisements and realizes that it is still roaming away from home, but is not under the domain of a FA. It then sends a DCHP request to obtain a CCoA (192.168.250.7) in the Foreign Network. It sends a RRQ directly to its Home Agent with the D bit set, the CCoA as 192.168.250.7, and the Home Address as 192.168.10.30. The IP source is the CCoA 192.168.250.7, and the IP destination is the Home Agent 192.168.10.1. The Home Agent sends a positive RRP directly to the Mobile Node 192.168.250.7.

  12. At some time later, the Mobile Node hears a Mobility Agent advertisement with the H bit set and router address 192.168.10.1 with prefix length extension /24, and realizes that it is back home. It initiates a Mobile IP handover and sends a RRQ with the IP source as its Home Address (192.168.10.30) and IP destination as the Home Agent (192.168.10.1). It sets the CoA as its Home Address (192.168.10.30) and lifetime as 0 to indicate that it is deregistering its mobility binding. The Mobile Node sends out a gratuitous ARP on its Home Network to ensure that its traffic is delivered to it and is no longer tunneled by the Home Agent.



    Mobile IP Technology and Applications
    Mobile IP Technology and Applications
    ISBN: 158705132X
    EAN: 2147483647
    Year: 2005
    Pages: 124

    Similar book on Amazon

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net