Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

for secure communications (see the topic on security issues for more details). It also

includes the ability to have a mobile node maintain more than one concurrent binding, when

needed.

Key Concept: Mobile IP home agent registration is the process by which a mobility

binding is created between a home agent and a traveling mobile node to enable

datagram forwarding to be performed. Registration is performed by the mobile node

sending a Registration Request message, and the home agent returning a Registration

Reply. The foreign agent may be required to act as a “middleman” to facilitate the trans-

action, but is otherwise not involved.

Registration Request Message Format

Registration Request messages have the format shown in Table 84 and Figure 132.

Figure 132: Mobile IP Registration Request Message Format

This message is carried in the payload of a User Datagram Protocol (UDP) message, the headers of which

are not shown.

Type = 1 Flags Lifetime

4 8 12 16 20 24 28 320

Simult-

aneous

Bindings

(S)

Broadcast

Datagrams

(B)

Decap by

Mobile

Node

(D)

Minimal

Encap-

sulation

(M)

GRE

Encap-

sulation

(G)

Res er v ed

(r)

Rev er s e

Tunneling

(T)

Res er v ed

(x)

480

Home Agent

Care-Of Address

Identification

Home Address

Extensions

Table 84: Mobile IP Registration Request Message Format (Page 1 of 2)

Field Name

Size

(bytes)

Description

Type 1 Type: Identifies the registration message type. For a request, this field is 1.

Flags 1

Lifetime 2

Lifetime: Length of time, in seconds, that the mobile node requests from

the home agent for this registration.

Home Address 4

Home Address: The home (normal) IP address of the mobile node when

on its home network. Uniquely identifies the device regardless of how the

request is conveyed to the home agent.

Home Agent 4

Home Agent: The IP address of the device acting as the mobile node's

home agent.

Care-Of Address 4

Care-Of Address: The IP address being used by the mobile node as its

care-of address.

ags:

one-

con

ng severa

orma

ona

ags

convey

specific requests being made by the mobile node to the home agent. When

set, a flag conveys the meanings given in the appropriate entry below:

Subfield

Name

Size

(bytes)

Description

1/8 (1

bit)

Simultaneous Bindings: Mobile node requests

that prior mobility bindings be retained in addition

to the one in the current request.

1/8 (1

bit)

Broadcast Datagrams: Mobile node requests that

broadcasts on the home network be forwarded to

it.

1/8 (1

bit)

Decapsulation By Mobile Node: Mobile node is

telling the home agent that it will itself decapsulate

encapsulated datagrams, as opposed to a foreign

agent. In other words, when this is one, the mobile

node is using a co-located care-of address; when

zero, it is using a foreign agent care-of address.

1/8 (1

bit)

Minimal Encapsulation: Mobile node requests

that home agent use minimal encapsulation for

forwarded datagrams.

1/8 (1

bit)

GRE Encapsulation: Mobile node requests that

home agent use GRE encapsulation for forwarded

datagrams.

1/8 (1

bit)

Reserved: Not used; sent as zero.

1/8 (1

bit)

Reverse Tunneling: Mobile node requests that

reverse tunneling be used by the home agent.

1/8 (1

bit)

Reserved: Not used; sent as zero.

Related Information: See the topic on Mobile IP encapsulation for more on

minimal and GRE encapsulation and reverse tunneling.

Registration Reply Message Format

Registration Reply messages are formatted as shown in Table 85 and Figure 133.

Identification 8

Identification: A 64-bit number that uniquely identifies the Registration

Request and is used to match requests to replies. It also provides

protection against replay attacks; see the topic on Mobile IP security issues

for more.

Extensions Variable

Extensions: Extension fields are included here for authentication of the

request. Other extensions may also be included.

Table 85: Mobile IP Registration Reply Message Format

Field Name

Size

(bytes)

Description

Type 1 Type: Identifies the registration message type. For a reply, this field is 3.

Code 1

Code: Indicates the result of the registration request. This field is set to 0 if

the registration was accepted, 1 if it was accepted but simultaneous

bindings were requested and are not supported. If the registration was

denied, a different reason code is provided that indicates the reason for the

rejection, as well as whether it was the home agent or foreign agent that

denied it.

Lifetime 2

Lifetime: If the registration was accepted, the length of time in seconds

until the registration expires. This may of course be a different value than

the mobile node requested.

Home Address 4

Home Address: The home (normal) IP address of the mobile node when

on its home network. Uniquely identifies the device regardless of how the

request is conveyed to the home agent, so the message can be delivered

to it if multiple mobile nodes are served by the same foreign agent.

Home Agent 4

Home Agent: The IP address of the device acting as the mobile node's

home agent.

Identification 8

Identification: A 64-bit number that uniquely identifies the Registration

Reply and is matched to the Identification field of the request that precipi-

tated it.

Extensions Variable

Extensions: Extension fields are included here for authentication of the

reply. Other extensions may also be included.

Table 84: Mobile IP Registration Request Message Format (Page 2 of 2)

Field Name

Size

(bytes)

Description

Mobile IP Data Encapsulation and Tunneling

Once a mobile node on a foreign network has completed a successful registration with its

home agent, the Mobile IP datagram forwarding process described in the general operation

topic will be fully “activated”. The home agent will intercept datagrams intended for the

mobile node as they are routed to its home network, and forward them to the mobile node.

This is done by encapsulating the datagrams and then sending them to the node's care-of

address.

Mobile IP Data Encapsulation Techniques

Encapsulation is required because each datagram we intercept and forward needs to be

resent over the network to the device's care-of address. In theory, the designers might

conceivably have done this by just having the home agent change the destination address

and stick it back out on the network, but there are various complications that make this

unwise. It makes more sense to take the entire datagram and wrap it in a new set of

headers before retransmitting. In our mail analogy, this is comparable to taking a letter

received for our traveling consultant and putting it into a fresh envelope for forwarding, as

opposed to just crossing off the original address and putting a new one on.

The default encapsulation process used in Mobile IP is called IP Encapsulation Within IP,

defined in RFC 2003 and commonly abbreviated IP-in-IP. It is a relatively simple method

that describes how to take an IP datagram and make it the payload of another IP datagram.

In Mobile IP, the new headers specify how to send the encapsulated datagram to the mobile

node's care-of address.

Figure 133: Mobile IP Registration Reply Message Format

This message is carried in the payload of a User Datagram Protocol (UDP) message, the headers of which

are not shown.

Type = 3 Code Lifetime

4 8 12 16 20 24 28 320

Home Agent

Identification

Home Address

Extensions

In addition to IP-in-IP, two other encapsulation methods may be optionally used: Minimal

Encapsulation Within IP, defined in RFC 2004, and Generic Routing Encapsulation (GRE),

defined in RFC 1701. To use either of these, the mobile node must request the appropriate

method in its Registration Request and the home agent must agree to use it. If foreign

agent care-of addressing is used, the foreign agent also must support the method desired.

The Mobile IP Data Delivery Tunnel

The encapsulation process creates a logical construct called a tunnel between the device

that encapsulates and the one that decapsulates. This is the same idea of a tunnel used in

discussions of virtual private networks (VPNs), IPSec tunnel mode, or the various other

tunneling protocols used for security. The tunnel represents a conduit over which

datagrams are forwarded across an arbitrary internetwork, with the details of the encapsu-

lated datagram (meaning the original IP headers) temporarily hidden.

In Mobile IP, the start of the tunnel is the home agent, which does the encapsulation. The

end of the tunnel depends on what sort of care-of address is being used:

☯ Foreign Agent Care-Of Address: The foreign agent is the end of the tunnel. It

receives encapsulated messages from the home agent, strips off the outer IP header

and then delivers the datagram to the mobile node. This is generally done using layer

two, because the mobile node and foreign agent are on the same local network, and of

course, the mobile node does not have its own IP address on that network (it is using

that of the foreign agent.)

☯ Co-Located Care-Of Address: The mobile node itself is the end of the tunnel and

strips off the outer header.

Mobile IP Conventional Tunneling

Normally, the tunnel described above is used only for datagrams that have been sent to the

mobile node and captured by the home agent. When the mobile nodes wants to send a

datagram, it doesn't tunnel it back to the home agent; this would be needlessly inefficient.

Instead it just sends out the datagram directly using whatever router it can find on its current

network, which may or may not be a foreign agent. When it does this, it uses its own home

address as the source address for any requests it sends. As a result, any response to those

requests will go back to the home network. This sets up a “triangle” of sorts for these kinds

of transactions:

1. The mobile node sends a request from the foreign network to some third party device

somewhere on the internetwork.

2. The third party device responds back to the mobile node. However, this sends the

reply back to the mobile node's home address on its home network.

3. The home agent intercepts the response on the home network and tunnels it back to

the mobile node.

This process is illustrated in Figure 134. The reverse transaction would be pretty much the

same, just in the reverse order. In that case the third party (Internet) device would send a

request to mobile node, which would be received and forwarded by the home agent. The

mobile node would reply back directly to the Internet host.

Key Concept: Once Mobile IP is set up and operational, it works by having the home

agent encapsulate and tunnel received datagrams to the mobile node. The mobile

device normally sends datagrams directly to Internet hosts, which respond back to

the mobile’s home agent which forwards those datagrams to the mobile node. This means a

request/reply communication takes three transmissions.

Figure 134: Mobile IP Encapsulation and Tunneling

This example illustrates how a typical request/reply message exchange in Mobile IP results in a “triangle” of

communication. In step #1, the mobile node sends a request to a remote server somewhere on the Internet. It

uses its own home address as the source for this request, so in step #2 the reply goes back to the home

agent. Step #3 consists of the home agent tunneling the reply back to the mobile node.

Foreign Network (Tokyo)

210.4.79.0/24

Home Network (London)

71.13.204.0/24

Mobile Node

Home Location

Home Address 71.13.204.20

Remote

Server

Addess 56.1.78.1

Home

Age nt

Mobile Node

Foreign Location

Care-Of Address 210.4.79.19

Foreign

Age nt

210.4.79.2

Request To: 56.1.78.1

From : 71.13.204.20

Tunnel To: 210.4.79.19

Reply To: 71.13.204.20

From : 56.1.78.1

Reply To: 71.13.204.20

From : 56.1.78.1

Mobile IP Reverse Tunneling

There may be situations where it is not feasible or desired to have the mobile node send

datagrams directly to the internetwork using a router on the foreign network as we just saw.

In this case, an optional feature called reverse tunneling may be deployed, if it is supported

by the mobile node, the home agent and if relevant, the foreign agent.

When this is done, a reverse tunnel to complement the normal one is set up between the

mobile node and the home agent, or between the foreign agent and the home agent,

depending on care-of address type. All transmissions from the mobile node are tunneled

back to the home network where the home agent transmits them over the internetwork,

resulting in a more symmetric operation rather than the “triangle” just described. This is

basically what I described earlier as being “needlessly inefficient”, because it means each

communication requires four steps. Thus, it is used only when necessary.

One situation where reverse tunneling may be required is if the network where the mobile

node is located has implemented certain security measures that prohibit the node from

sending datagrams using its normal IP address. In particular, a network may be set up to

disallow outgoing datagrams with a source address that doesn’t match its network prefix.

This is often done to prevent “spoofing” (impersonating another’s IP address.)

Key Concept: An optional feature called reverse tunneling may be used in certain

cases, such as when a network does not allow outgoing datagrams with a foreign

source IP address. When enabled, rather than sending datagrams directly, the

mobile node tunnels all transmissions back to the home agent, which sends them on the

Internet.

Note that everything I've just discussed is applicable to “normal”—meaning unicast—

datagrams sent to and from the mobile node. Broadcast datagrams on the home network,

which would normally be intended for the mobile node if it were at home, are not forwarded

unless the node specifically asks for this service during registration. Multicast operation on

the foreign network is also supported, but extra work is required by the mobile node to set it

up.

Mobile IP and TCP/IP Address Resolution Protocol (ARP) Operation

Mobile IP is a protocol that does a good job of implementing a difficult function: transpar-

ently allowing an IP device to travel to a different network. Unfortunately, a problem with any

protocol that tries to change how IP works is dealing with “special cases”. Having a home

agent intercept datagrams and tunnel them to the mobile node works well in general terms,

but there are some places where extra work is required. One of these is the use of the TCP/

IP Address Resolution Protocol (ARP), which under Mobile IP “breaks” unless we take

special steps.

Background Information: Some understanding of how ARP works in general

terms is assumed in this topic. This includes ARP proxying.

Difficulties With Mobile IP and ARP

To understand the problem with ARP, consider a mobile node that is on a foreign network

and has successfully registered with its home agent. The home agent will intercept all

datagrams that come onto the home network intended for the mobile node, and then encap-

sulate and forward them. For this to happen, though, the home agent (home router) must

see the datagram. This normally only occurs when a datagram comes onto the home

network from the “outside” and is processed by the router.

What happens when a local device on the home network itself wants to transmit to a mobile

node that has traveled elsewhere? Remember that this device may not be mobile itself and

probably knows nothing about Mobile IP. It will follow the standard process for deciding

what to do with a datagram it needs to send as explained in the topic discussing direct and

indirect delivery of IP datagrams. It will compare its network ID to that of the mobile node

and realize it doesn't need to route its datagram; it can send it directly to the mobile node.

The local host will attempt to use ARP to find the data link layer address of the mobile node

so it can send the datagram to it directly. It will start by looking in its ARP cache and if it

finds the node's data link layer address there, will use it to send at layer two. Of course the

mobile node is no longer on the local network segment so the message will never be

received. If there is no ARP cache entry, the host on the home network will attempt to send

an ARP Request to the mobile node to determine its layer two address. Again, the mobile

node has traveled away, so this request will go unanswered.

Additional Home Agent Tasks To Deal With ARP

Solving this problem requires the intervention of, you guessed it, the home agent. It must

perform two tasks to enable local hosts to send to the mobile node:

☯ ARP Proxying: The home agent must listen for any ARP Requests sent by nodes on

the same network as any of the mobile nodes that are currently registered to it. When

it hears one, it replies in the mobile node's stead, and specifies its own data link layer

address as the binding for the mobile node's IP address. This will cause hosts on the

home network to send any datagrams intended for the mobile node to the home agent

where they can be forwarded. This process is illustrated in Figure 135.

☯ “Gratuitous” ARP: Proxying helps with ARP Requests but what about devices that

already have cache entries for the mobile node? As soon as the mobile node leaves

the network, these become automatically stale. To correct them, the home agent

sends what is called a gratuitous ARP message that tells devices on the local network

to associate the mobile node's IP address with the home agent's data link layer

address. The term “gratuitous” refers to the fact that the message isn't being sent in

order to perform an actual address resolution but merely to cause caches to be

updated. It may be sent more than once to ensure that every device “gets the

message”.

Once this is done, ARP should function normally on the home link. Of course, when the

mobile device returns back to the home network, the process must be reversed. Upon

deregistration with the home agent, it will stop proxying for the mobile node. Both the mobile

node and the home agent will also send gratuitous ARP broadcasts that update local device

caches to again associate the mobile node's IP address with its own layer two address,

instead of that of the home agent.

Figure 135: ARP Proxying By Mobile IP Home Agent

The home agent must take special steps to deal with transmissions from devices on the local network to the

mobile node. In this example (using short hardware addresses for simplicity) the hardware address of the

mobile node is #48 and that of the home agent #63. A local client on the home network with hardware address

#97 sends an ARP Request to find out the hardware address of the mobile node. The home agent responds

on the mobile’s behalf, specifying not hardware address #48 but rather its own, #63. The client will thus send

to the home agent, which can then forward the data to the mobile node on the foreign network.

Foreign Network (Tokyo)

210.4.79.0/24

Home Network (London)

71.13.204.0/24

Mobile Node

Home Location

Home Address 71.13.204.20

Foreign

Age nt

Who Is 71.13.204.20?

Mobile Node

Foreign Location

Hardware Address #48

Home

Age nt

H/W Addr #63

71.13.204.20 Is #63

Local Client

Address 71.13.204.193

Hardware Address #97

Key Concept: To avoid problems with hosts on the mobile node’s home network

trying to send datagrams to it at layer two, the home agent is required to use proxy

ARP to direct such devices to send to the home agent so they can be forwarded. It

must also use “gratuitous” ARP to update any existing ARP caches to that effect.

Mobile IP Efficiency Issues

Having the home agent forward all datagrams to the mobile node wherever it may be is a

convenient solution to mobility, but is also a rather inefficient one. Since every datagram

must be sent first to the home network and then be forwarded to the mobile node,

datagrams are going to travel over some part of the internetwork twice. The degree of ineffi-

ciency represented by forwarding can be significant, and may lead to problems with certain

applications.

To see what the problem is, let's consider a traveling mobile node M and a regular device

that wants to send to it, device A. The degree of the inefficiency of Mobile IP is a function of

the internetwork distance between device A and M's home network, compared to the inter-

network distance between device A and M's current network. By distance here, I mean the

term as it is used in determining routes on an internetwork; two devices are “closer” when it

takes less time and/or fewer hops to communicate between them, and “farther” when it

takes more. (I use geography in my examples below to represent this notion of distance, but

remember that geographical distance is only one factor in internetwork distance.)

The Impact on Efficiency of Sending Device Location

Let's consider the case where mobile node M is on a foreign network quite far from home,

and a sending device, device A, wants to send a datagram using node M’s home IP

address. Suppose the home network is in London and the device is again in Tokyo, Japan.

The following examples are arranged in order of increasing inefficiency of Mobile IP,

compared to the alternative of having the mobile node just get a new temporary IP address

on the foreign network and not use Mobile IP:

☯ Sending Device On Home Network: In this situation, device A will send a datagram

that is immediately intercepted by the home agent on the home network and forwarded

to the mobile node. There is really no inefficiency here at all (except for overhead for

encapsulation and such) because even if A sent directly to the mobile node with a new

foreign address, it would probably be routed through the home agent router anyway.

☯ Sending Device On Network Close To Home Network: Here, let's say a device in

Paris, France wants to send to the mobile node. The datagram goes from Paris to

London and then to Tokyo. That's not too bad.

☯ Sending Device On Network Close To Foreign Network: Now, suppose the sending

device is in Taipei, Taiwan. In this situation, Mobile IP becomes quite inefficient. The

datagram must be sent from Taipei all the way to London, and then all the way back to

Tokyo.