perkins ipv4

8/2/2019 Perkins Ipv4

http://slidepdf.com/reader/full/perkins-ipv4 1/12

IEE E Communications Magazine • May 199784

Mobile IP

0163-6804/97/$10.00 © 1997 IEEE

ecent years have seen an explosive growth both in thenumber of laptop and notebook computers sold, and

in the number of nodes connected to the Internet and theWorld Wide Web. The noteb ook computers are t hemselvesever more powerful, equal in pr ocessing capability to man ysystems sold as desktop workstat ions. In fact , the futur egrowth of the Inte rnet is likely to be fueled in large par t bythese very notebook computers, since they account for thepart of the computer market that is growing fastest.

Along with th ese tren ds, we also see the steady growth of the market for wireless commun ications devices. Such devicescan only have the effect of increasing the options for makingconnections to the global Internet. Mobile customers can finda wide array of such wireless devices available. There arenumerous varieties of radio attachments and infrared devices;of course, communications by way of the cellular telephonenetwork is always an option for those willing to pay the fees.

MOBILITY VS. P ORTABILITYThese trends are motivating a great deal of interest in makingsure that mobile wireless computers can attach to the Internetand remain attached to the Intern et even as they move fromplace to place, establishing new links and moving away frompreviously established links. Early on, it was apparen t th atsolving the problem at the network layer (say, by modifying IP[1], the Internet Protocol, itself) would provide major bene-fits, including application transpa rency and the possibility of seamless roaming. App lication tran sparency is almost r equiredfor all reasonab le solutions, because it is unacceptable t oforce mobile users to bu y all new mobile-aware app lications.Seamless roaming, while not yet mand ator y, is nonethe lessexpected to r egister very high on th e scale of user conve-

nience factors once the physical wireless means for continuedconnectivity are widely deployed. Moreover, seamless roamingprovides application tr ansparen cy. Mobile IP is the only cur-rent means for offering seamless roaming to mobile comput-ers in the Internet. It has recently progressed along the ladderto standardization within the Internet Engineering Task Force(IETF), and its specification is now available as Request forComments (RFC) 2002 [2]. Related specifications are avail-able as RFCs 2003–2006.

This art icle follows the logical outline indicated below. Wefirst describe the problem that is solved by mobile IP in thenext section. In the second section there is a list of terminolo-gy and an overview of mobile IP. In the third section, the dis-

covery mechanisms of mobile IP are d escribed in d etail. Fol-lowing that, the mechanisms are described by which a mobilecomputer is located. Ne xt, the available tun neling mechanismsare shown, which the home agent uses to forward datagramsfrom the home network to the mobile computer.

Having covered the details of the base mobile IP specifica-tion, we then describe further protocol messages which helpto d ecrease the inefficiency associated with inserting the homeagent in the routing path of dat a destined for mobile comput-ers. This route optimization is still a topic for furth er work within th e IE TF. Finally, we summarize and d iscuss the cur-ren t pro blems facing mobile IP, as well as a few areas of active p rotocol development.

MOBILE IP O VERVIEW

M obile IP can be thought of as the cooperation of three

major subsystems. First, there is a discovery mechanismdefined so that mobile computers can determine their newattachment po ints (new IP add resses) as th ey move fromplace to place within the Inte rnet. Second, once the mo bilecomputer knows the IP address at its new attachment point, itregisters with an agent repr esenting it at its home network .Lastly, mobile IP defines simple mechanisms to d eliver data-grams to the mobile node when it is away from its home net-work.

WHY ISN ’T MOBILITY SIMPLE?Consider how IP addresses are used today in the Internet. Inthe first place, they are primarily used to identify a particularend system. In th is respect, IP addr esses are often thought of as being semantically equivalent to Dom ain Name Server’s

(DNS’s) Fully Qualified D omain Names (F QD Ns). In othe rwords, one can (conceptu ally) use either an IP add ress orFQDN to identify one particular node out of the tens of mil-l ions of computer nod es making up the Inter net . Populartransport protocols such as Transmission Control Protocol(TCP) [3] keep tr ack of their internal session state betweenthe communicating endpoints by using the IP address of thetwo endpoints, stored along with the demultiplexing selectorsfor each session, that is, the port numbers.

However, IP addresses a re a l so used to f ind a rou tebetween the endpo ints. The rout e does not have to be thesame in both directions. Modeling the session as a bidirection-al byte stream, the IP destination address for datagrams going

Charles E. Perkins, Sun Microsystems

R

AbstractMobile IP has been designed within the IETF to serve the needs of the burgeoning population of mobile computer users who wish toconnect to the Internet and maintain communications as they move from place to place. The basic protocol is described, with details

given on the three major component protocols: Agent Advertisement, Registration, and Tunneling. Then route optimization proceduresare outlined, and further topics of current interest are described.



IEE E Commun ications Magazine • May 1997 85

in one direction would be the same as the IP source addr essfor dat agrams going in the o ppo site direction. Typically, theroute selected for a datagram dep ends only on the IP destina-tion address, and not (for example) on the IP source address,time of day, or length of the payload. The only other factorusually influencing rout e selection is the current state of n et-work congestion. In other words, a route that might usually beselected by an intermediate router for a particular destinationmay go out o f favor if traffic along that d irection is delayed o rdropped because of congestion.

Putting these two uses together results in a situation fraughtwith contr adiction for mobile computing. On one h and, amobile computer needs to have a stable IP address in order tobe stably identifiable to other Intern et computers. On theother hand, if the addr ess is stable, the rou ting to the mobilecomputer is stable, and the datagrams always go essentially tothe same place — thus, no mo bility. Mobile IP extends IP byallowing the mobile computer to effectively utilize two IPaddresses, one for identification, the other for rou ting.

Some attempts have been made to manage the movementof Internet computers by less functional methods. For starters,it is certainly possible, given sufficient deployment of DHCP[4, 5], for a mobile node to get an IP address at every newpoint of attachment. This will work fine until the mobile nodemoves somewhere else. Then the o ld addre ss will no longer beof use, and the node will have to get another o ne. Unfort u-nately, this approach usually also means th at every establishedIP client on the mobile node will stop working, so the mobilenode will have to r estart its Inte rnet subsystems. Many userswill not be so selective, and will just r eboo t th eir system. T hisisn’t so bad if each new point of attachment is separate d bysome time du ring which the system is disconnected or t urnedoff anyway. Many mobile computer users are satisfied with justthat mode of operation, which we’ll describe as portability.

Even with portable operation, however, there are other bigdifficulties. Most app lications initially identify an In tern etnode by means of its FQD N, but subsequently only make useof the node’s IP addre ss. In order to contact the node, theapplication consults the appropriate DNS server to get an IP

address. If the IP a ddress is allocated dynamically, either theserver will have it wrong, or the server will need to get updates(say, from the portable Internet node). Since DNS is typicallyat the adm inistrative heart at most networked ente rprisesusing the Interne t, any protocols designed to alter the d ataare going to have to be extremely well designed, implemente d,and administered. The more often updates are ap plied toDNS re cords [6], and t he mo re platforms involved in h ostingthe update protocol implementation, the more likely thatthings are going to go haywire in a big, expensive me ltdown.At minimum, one can be confident that a lot more work isgoing to be n ecessary before system ad ministrator s learn totrust that thousands (o r millions!) of mobile nodes can reli-ably reach into the guts of their enterpr ise oper ations andtweak a record or two here an d ther e. Much of this work will

involve precisely carrying out certain cryptographic techniquesthat a re on ly now being standardized for use with DNS [7].

TERMINOLOGYBefore getting into more details, it is a good idea to frame thediscussion b y setting some t erminology, adapte d from themobile IP specification [2]. Mobile IP introduces the followingnew functional entities:

Mobile node — A host or r outer that changes its point of attachment from one network or subnetwork to another, with-out changing its IP ad dress. A mobile node can continue tocommunicate with other Intern et nod es at any location usingits (constant) IP address.

Home agent — A router on a mobile node’s home network which del ivers datagrams to departe d mobile nodes, andmaintains current location information for each.

Foreign agent — A rou ter o n a mo bile node’s visited net-work which cooperates with the home agent to complete thedelivery of datagrams to the mobile node while it is away fromhome.

A mobile node h as a home addre ss, which is a long-term IPaddr ess on its home network. When away from its home n et-work, a care-of address is associated with the mobile node andreflects the mo bile nod e’s current po int of attachment. Th emobile node uses its home address as the source address of allIP d atagrams it sends, except where othe rwise required for cer-tain registration request datagrams (e.g., see the fourth section).

The following terms a re freq uently used in conne ction withmobile IP:

Agent advert isement — Foreign agents advertise theirpresence by using a special message, which is constructed byattaching a special extension to a router advertisement [8], asdescribed in the next section.

Care -o f address — The te rmina t ion poin t o f a tunne ltoward a mobile node, for datagrams forwarded to the mobilenode while it is away from hom e. There are two differenttypes of care-of address: a foreign agent care-of address is anaddress of a foreign agent with which the mobile node is reg-istered; a collocated care-of address is an externally obtainedlocal address which the mo bile node ha s associated with on eof its own network interfaces.

Correspondent n ode — A peer with which a mobile nodeis communica t ing . A cor respondent node may be e i thermobile or stationar y.

Foreign network — Any network other than the mobilenode’s home network.

Home address — An IP addre ss that is assigned for a nextended per iod of t ime to a mobi le node . I t remainsunchanged regardless of where th e nod e is attached to th eInternet.

Home network — A network, possibly virtual, having a net-work prefix matching that of a mobile node’s home address.

Note that standard IP routing mechanisms will deliver data-grams des t ined to a mobi le node’s home ad dress to themobile node’s home network.

Link — A facility or medium over which nodes can com-municate at th e link layer. A link und erlies the network layer.

Link-layer address — The address used to identify an end-point of some communication over a physical link. Typically,th e link-layer addr ess is an interface’s media access control(MAC) address.

Mobility agent — Either a home agent or a foreign agent.Mobility binding — The association of a hom e addr ess

with a care-of address, along with the remaining lifetime of that association.

Mobility secur ity association — A collection of securitycontexts between a pair of no des which may be ap plied to

mobile IP pr otocol messages exchanged between th em. Eachcontext indicates an authen tication algorithm and mo de (a sdescribed in t he fourth section), a secret (a shared key, orappropriate public/private key pair), and a style of replay pro-tection in use.

Node — A host or a router.Nonce— A randomly chosen value, different from previous

choices, inserted in a me ssage to protect against replays.Security parameters index (SPI) — An ind ex identifying a

security context between a pair of nodes among the contextsavailable in the mobility security association .

Tunn el — The p ath followed by a datagra m while it isencapsulated. The model is that, while encapsulated, a data-




gram is routed to a knowledgable agent, which decapsulates thedatagram and then forwards it along to its ultimate destination.

Virtu al n etwork — A network with no physical instantia-tion beyond its route r (with a p hysical network interface onanother network). The router (e.g., a home agent) generallyadvertises reachability to the virtual network using conven-tional routing pro tocols.

Visited n etwork — A network other than a mobile node’shome network to which the mobile node is currently connected.

Visitor list — The list of mobile nodes visiting a foreign agent.

PROTOCOL OVERVIEWMobile IP is a way of performing three r elated functions:Agent Discovery — Mobility agents advertise their avail-

ability on each link for which they provide service.Registration — When the mobile node is away from home,

it registers its care-of address with its ho me agent.Tunneling — In order for datagrams to be delivered to the

mobile node when it is away from ho me, the ho me agent hasto tunnel the datagrams to the care-of address.

The following will give a rough outline of operation of themobile IP protocol, making use of the above-mentioned oper-ations. Figure 1 may be used to help envision the roles playedby the e ntities.• Mobility agents make themselves known by sending agent

advertisement messages. An impatient mobile nod e mayoptionally solicit an agent advertisement message.

• After receiving an agent advertisement, a mobile node

deter mines whether it is on its home net work or a for-eign net work. A mobile no de ba sically works like an yother node on its home network when it is at home.

• When a mobile node moves away from its home network,it obtains a care-of address on the foreign network, forinstance, by soliciting or listening for agent a dvertise-ments, or contacting Dynamic Host Configuration Proto-col (DHCP) or Point-to-Point Protocol (PPP).

• While away from home, the mobile node registers eachnew care-of ad dre ss with its hom e agen t, possibly by wayof a foreign agent.

• Datagrams sent to the mobile node’s home address areintercepted by its home agent, tunneled by its home agentto the care-of addre ss, received at the tunnel end point(at either a foreign agent or the mobile node itself), and

finally delivered to th e mo bile no de.• In the reverse direction, datagrams sent by the mobilenode are gener ally delivered t o their d estination usingstandard IP routing mechanisms, not necessarily passingthrough the home agent (but see the eighth section).When the home agent tunnels a datagram to the care-of

address, the inner IP header dest inat ion ( i .e . , the mobilenode’s home address) is effectively shielded from interveningrouters between its home network and its current location. Atthe care-of address, the original datagram exits from the tu n-nel and is delivered to the mobile node.

It is the job of every home agent to attra ct and interceptdatagrams that are destined to th e home ad dress of any of its

registered mobile nodes. The home agent basically does thisby using a minor variation on proxy Address Resolution Protocol(ARP) , and to do so in the natural model it has to have a net-work interface on the link indicated by the mobile node’s homeaddress. However, the latter requirement is not part of themobile IP specification. When foreign agents are in use, simi-larly, the n atural model o f operation suggests that the mobilenode be able to establish a link its foreign agent. Other con-figurations are possible, however, using protocol operationsnot defined by (and invisible to) mobile IP. Notice that, if thehome agent is the only router advertising reachability to thehome network, but there is no physical link instantiating thehome ne twork, then al l datagrams transmitted to mobilenodes add ressed on tha t home network will naturally reachthe h ome agent without any special link ope rations.

Figure 1 illustrates the routing of datagrams to and from amobile node away from home, on ce the mobile node h as reg-istered with its home agent. The mobile node is presumed tobe using a care-of addr ess provided by the foreign agent:• A datagram to the mobile node arrives on the home net-

work via standard IP routing.• The datagram is intercepted by the home agent and is

tunneled to the care-of address, as depicted by the arrowgoing through the tube.

• The datagram is detunneled and delivered to the mobilenode.

• For datagrams sent by the mobile node, standard IP rout-ing delivers each to its destination. In the figure, the for-eign agent is the mobile node ’s default rout er.Now, we will go into more detail about the various parts of

the protocols outlined above.

MOBILE AGENT DISCOVERY

T he process of detecting a mobility agent is quite similar tothat used by Interne t nodes to detect routers running

Internet Control Message Protocol (ICMP) Rou ter D iscovery(RFC 1256) [7]. The basic operation involves periodic broad-casts of advert isements by the rou ters ont o th eir direct ly

attached subnetworks. Noticing the similarity, the M obile IPworking group decided to use RFC 1256 directly, and supportthe special additional needs of mobility agents by attachingspecial extensions to the standard ICMP [9] messages.

AGENT ADVERTISEMENT

B y far th e most impo rtant extension is the mobility agentextension, which is applied to ICMP Router Advertise-

ment a nd illustrated in Fig. 2.The flags (R, B, H, F, M, G, and V) inform mobile nodes

regarding special features of the advert isement, and ar edescribed below. The type field allows mobile nod es to d istin-guish between th e various kinds of extensions which may beapplied by mobility agents to the IC MP R outer Advertise-

ments; the type for th e mobility agent a dvertisement extensionis 3. Other extensions may, of course, precede or succeed thisextension; almost no ot her e xtensions are defined as of th iswriting. The length field is the length of this single extension,which really only depends on how many care-of addresses arebeing advertised. Furthermor e, currently, at most o ne care-of address will typically be advertised (see the eighth section).Home agents do not have to advertise care-of addresses, butthey still need to br oadcast mobility agent a dvertisements sothat mobile nodes will know when they have returned to theirhome network. Indee d, mobility agents can ad vertise care-of addr esses even when they do not offer an y default rou teraddresses, as would be found in other ICMP R outer Ad ver-

sFigu re 1. Mobile IP datagram flow.

Home agent

IP host

GlobalInternet

Foreignagent

Mobilenode

1

2 3

4




tisements. No preferences apply to adver-tised care-of addr esses.

The flags are defined as follows:R Registration required. Registration

with this foreign agent ( or an otherfore ign agent on th i s l ink) i srequ ired, even if using a collocatedcare-of address.

B The foreign agent is busy.H The agent is a home agent.F The agent is a foreign agent.M Minimal encapsulation (R FC 2004 [10])G GRE encapsulation (RFC 1701 [11])V Van Jacobson header compression (RFC 1144 [12])

Note that bits F and H are no t mutually exclusive, and thatB cannot be set unless F is also set. Note also that a foreignagent typically needs to continue sending ad vertisements ou t(with the B bit set), even though it is too busy to provide ser-vice to new mobile nodes. Otherwise, the foreign agent’s cur-rent customers might think the foreign agent had crashed, andmove away unnecessarily.

The mo bility agent gener ally increments the seq uencenumber by one for each successive advertisement. Specialrules enable a m obile no de to distinguish between foreignagent crashes, and wraparound of the sequence number field.

AGENT SOLICITATIONA mobile node is allowed to send ICMP Router Solicitationmessages in or der to elicit a mobility agent ad vertisement.

There are t wo kinds of re gistration messages, the registra-tion request and r egistration reply, both sent to U ser Data-gram Protocol (UDP) port 434. The overall data structure of the registration messages is shown in Fig. 3. The request mes-sage allows the mobile node to inform its home agent of itscurrent care-of address, tells the home agent how long themobile node wants to use the care-of address, and indicatesspecial features that may be available from the foreign agent.The foreign agent is considered a passive agent in the regis-tration procedure, and agrees to pass the request to th e home

agent , and subsequently to pass the reply from the homeagent back to the mobile node.

REGISTRATION REQUESTThe registrat ion pro cess is almost the same whether th emobile node has obtained its care-of address from a foreignagent, or alternatively has acquired it from another indepen-dent service such as DH CP. In th e former case, the mob ilenode basical ly send s the r eque st (with f ields f i lled in as

described below) to the foreign agent, which then relays therequest to the home agent. In the latter case, the mobile nodesends its request directly to the home agent, using its collocat-ed care-of address as the source IP address of the request.

After the IP and U DP headers, the registration request hasthe stru cture illustrated in Fig. 4.

Given the discussion ab out th e bi t f ields in the agentadvertisement extension in the th ird section, the ne ed formost of the fields is clear. The V bit in the request serves toinform the foreign agent whether Van Ja cobson compressionis desired. The M and G bits tell the home agent which addi-tional encapsulation methods can be used. The B bit is usedto tell the home agent to en capsulate broadcast datagramsfrom the h ome network for delivery to the care-of address(and from there to the mobile node). The D bit describeswhether or not t he mob ile nod e is collocated with its care-of addr ess, and is mainly useful for det ermining ho w to deliverbroadcast and multicast datagrams to the mobile node.

Also included are the home add ress and the proposedcare-of address. The identification field, a 64-bit field, is usedfor replay protection, as described below when security is dis-cussed. The most important extension is the m obile-homeauthe ntication extension, described in the fourt h section,which is required in every registration in or der to allow thehome agent to prevent fraudulent remote redirects.

REGISTRATION REPLYThe r egistration r eply has the structure illustrated in Fig. 5.

The lifetime field tells the mobile node how long the regis-tration will be honored by the home a gent. It can be shorterthan requested, but never longer. The code field describes thestatus of the registration. If the registration succeeds, well andgood. If the registration fails, the code field o ffers detailsabout what went wrong.

Typical values include:0 registration accepted

Re gis t ra t ion denied by the fore ignagent:

66 insufficient resources

69 lifetime request > advertised limit70 poorly formed request71 poorly formed reply88 home agent unreachable

Registration denied by the home agent:130 insufficient resources131 mobile no de failed auth entication133 registration identification mismatch134 poorly formed request136 unknown home agent addressR eceiving code 133 usually indicates

the need for resynchronization between

s Figu re 2. Mobility agent extension format.

Zero or more care-of addresses• • • •

00 1 2 3 4

Type Length Sequence number

ReservedLifetime R B H F M G V

5 6 7 8 910 1 2 3 4 5 6 7 8 9

20 1

30 12 3 4 5 6 7 8 9

s Figu re 3. Data structure of a registration message.

Extensions ... ..Mobile IP message headerUDP headerIP header fields

s Figu re 4. Registration request format.

Home address

LifetimeType S B D M G V rsvd

Home agent

Care-of address

Identification

Extensions .....

00 1 2 3 4 5 6 7 8 9

10 1 2 3 4 5 6 7 8 9

20 1

30 12 3 4 5 6 7 8 9




the home agent and the mobile node. This synchronizationcan be either time-based or based on the exchange of ran-domly generat ed non ce values. Note that er ror code 130should effectively be impossible. The home agent shou ld notbe configured to accept the m obile node if it does not ha vethe needed resources.

Up -to-date values of the code field are specified in th emost recent assigned n umbers ( e.g., [13]).

DYNAMIC HOME AGENT DISCOVERYRe jection code 136 forms the basis for allowing the mo bilenode to find the address of a home agent when needed. If theregistrat ion re ply is addr essed to the directed broadcast address , every home agent on the home ne twork shouldreceive and reject it. However, the registration reply contain-ing the re jection also contains the home agent’s addre ss, sothe mobile node can try again and succeed.

SECURING THE REGISTRATION PROCEDURERegistration in mobile IP must be made secure so tha t fraud-ulent registrations can be detected and rejected. Otherwise,any malicious user in the Internet could disrupt communica-tions between the home agent an d the mo bile node by thesimple expedient o f supplying a registration req uest contain-ing a bogus care-of address (perhaps the IP add ress of themalicious user). This would effectively disrupt all traffic des-tined for the mobile node.

The method specified to protect against such malicioususers involves the inclusion of an unforgeable value along withthe r egistration that cha nges for every new registration. Inorder to make e ach one different, a timestamp or n ewly gen-erated random number (a nonce ) is inserted into the identifi-

cation field. The home agent and mobile node have to agreeon reasonable values for the timestamp or nonce, and the pro-tocol allows for r esynchron ization, as d escribed ear lier, by useof reply code 133.

There are three authentication extensions defined for usewith mobile IP, as follows:• The mobile-home authentication extension• The mobile-foreign authentication extension• The foreign-home authentication extension

As illustrated in Fig. 6, they all have similar formats, distin-guishable only by different type numbers. The mobile-homeauthen tication e xtension is required in a ll registration requ estsand replies. The SPI within any of the authentication exten-

sions defines the security context used tocompute (and check) the au thenticator. Inparticular, the SPI selects the authentica-t ion algorithm and mode, and secret (ashared key, or app ropr iate public/privatekey pair) used to compute the authentica-tor. A mobile node has to be able to asso-ciate arbi trary SPI values with anyauthen t ica t ion a lgor i thm and mode i timplements. SPI values 0 through 255 arereserved and not allowed to be used in anymobility security association.

The d efault authentication algorithmuses keyed-MD5 [14] in prefix+ suffixmode to compute a 128-bit message digest of the registration me ssage. The d efaultauthe nticator is a 128-bit message digestcomputed b y the de fault algorithm overthe following stream of bytes:• The sh ar ed secr et defin ed by

the mobil i ty securi ty associat ionbetween the no des and by SPI value

specified in the authen tication extension, followed by• The protected fields from the registration message, in the

order specified above, followed by• The shared secret again

The au thent ica tor i t se l f and the U DP header a re no tincluded in th e computat ion of the default authenticatorvalue. All implementat ion s of mobile IP ar e requ ired toimplement the default authentication algorithm just described.

ROUTING AND TUNNELING

T he home agent, after a successful registration, will begin toattract datagrams destined for th e mobile node and tunnel

each one to the mobile node at its care-of address. The tun -neling can be don e by one of several encapsulation algo-r i thms , bu t the defau l t a lgor i thm tha t mus t a lways besuppor ted is simple IP-within-IP encapsulation, as described

in R FC 2003 [15]. Encapsulation is a very general techniqueused for many different reasons, including multicast, multipro-tocol operations, authentication, privacy, defeating trafficanalysis, and general policy routing.

Pictorially, Fig. 7 shows how an IP datagram is encapsulatedby preceding it with a new IP header (the tunnel header). Inthe case of mobile IP, the values of the fields in the new headerare selected naturally, with th e care-of add ress used as th e de s-tination IP address in the tunnel header. The encapsulating IPheader indicates the presence of the encapsulated IP datagramby using the value 4 in the outer protocol field. The inner head-er is not modified except to decrement the TTL by 1.

Alternatively, minimal encapsulation [10] can be used a slong as the mobile node, home a gent, and foreign agent (if present) all agree to do so. IP-within-IP uses a few more

bytes per datagram than m inimal encapsulation, but allowsfragmentation at the home agent when needed to deal withtunn e ls wi th smal le r pa th m aximum t r ansmission uni t s(MTUs).

The minimal encapsulation header fits in the same relativelocation within th e en capsulated payload, as indicated by theold IP header in Fig. 7. The presence of the minimal encapsu-lation header is indicated by using protocol number 55 in theencapsulating IP header protocol field. Figure 8 shows thef ie lds of t he m in imal encapsula t ion he ader, which a redescribed below. The length of the minimal header is either12 or 8, depending on whether the or iginal source IP ad dressis present.

s Figu re 5. Registration reply format.

Identification

Home agent

Home Address

Extensions .....

Type Code Lifetime

00 1 2 3 4 5 6 7 8 9

10 1 2 3 4 5 6 7 8 9

20 1

30 12 3 4 5 6 7 8 9

s Figu re 6. Mobile IP authentication extensions.

Type

.... SPI (continued) Authenticator ....

Length SPI .....

00 1 2 3 4 5 6 7 8 9

10 1 2 3 4 5 6 7 8 9

20 1

30 12 3 4 5 6 7 8 9




Protocol — Copied from the pro-tocol field in the original IP header.

Original Source Address Pre- sen t (S) — If 1, the originalsource addr ess field (below) is pre-sent; otherwise, it is not.

Reserved — Sent as zero; ignored on reception.

Header Checksum — The 16-bit 1’s complemen t o f the 1’scomplement sum of all 16-bit words in th e minimal forward-ing header. For p urposes of computing the checksum, thevalue of th e checksum field is 0. The IP header and I P pay-load (after the minimal forwarding header) are not includedin this checksum compu tation.

Original Dest inatio n Ad dress — Copied from the destina-tion address field in the original IP header.

O r ig in a l Sou r ce Addre s s — Copied f rom the sourceaddress field in the or iginal IP header . This field is presentonly if the original source ad dress present (S) bit is set.

SOFT TUNNEL STATEOne unfortunate aspect of ICMP er ror messages is that theyare only required by the protocol to incorporate 8 bytes of theoffending datagram. Ther efore, when delivery of a datagramtunneled to a care-of address fails, the ICMP error r eturnedto the home agent may not contain the IP add ress of the orig-inal source of the tunneled datagram.

Naturally, it makes sense for the home agent to try to noti-fy the correspondent host (the source of the datagram whichcould not be d elivered) in this situation. If the ho me agentkeeps track of which dat agrams have been tu nneled to whichcare-of addresses (including the I P sequence nu mber), theICMP err or retur n can be used by the home agent to indicatewhich datagram caused the problem. If that determination ismade, the ICMP error return can be relayed by the home

agent to the correspondent n ode which sent the o ffendingdatagram.When a correspondent node sends the datagram to the

home network, and the datagram arrives at the home ne t-work, i t seems inapprop riate for the h ome agent to relayICMP network unreachable messages without any change.In fact, from the point o f view of the correspondent n ode, thetunnel should be invisible, almost as if it were an extension of the ho me link. So when the home agent can determine whichcorrespondent node should receive the error, it makes sensefor the home agent to transform the network unreachable

message into a host unreachable message.When the h ome agent is about to tun nel a datagram to a

care-of address which has just failed, it is quite feasible for thehome agent to remember that th e tunnel is broken. The home

agent can then inform the correspondent host directly, usingan ICMP host unreachable message. In fact, the h ome

agent can keep t rack of o therin te res t ing tunne l parameters ,especially including the p ath M TUfor the tunnel and the necessarytime to live (TTL) for encapsulat-ed datagrams using that tunnel .This collection of tunnel parame-ters is called the soft state of the

tunnel. The IP-within-IP encapsulation specification, RFC2003 [15], recommends maintenance of soft state, and givesspecific rules for relaying ICMP messages.

HOME NETWORK CONFIGURATIONSThere are th ree basic configurations for home networks. Thefirst is a standard physical network connected by way of arouter, with another node on the network acting as a homeagent. The configuration shown in Fig. 9a will be very popu -lar, especially for ent erprises starting to use m obile IP. If thehome agent is also an enterprise router, the physical homenetwork layout can be conceptua lly simpler, as illustrated inFig. 9b. In either case, wireless devices can be configured withIP addresses on existing physical (say, Ethernet) networkswith the help of bridging devices that cause the wireless pack-ets to be bridged onto the physical network.

At the other extreme, it is possible to manage a ho me net-work that has no physical realization, called a virtual network ,as shown in Fig. 9c. The home agent appears to the rest of theInternet as the router for the home network, but when data-grams arrive at th e home agent, they are never forwarded.Instead, the home agent encapsulates them and sends them toa known care-of addr ess.

PROXY AND GRATUITOUS ARPIn either configuration a or b of Fig. 9, the home agent has toperform proxy AR P for the mobile node. Ot herwise, existingInternet hosts on the home network would not be able to con-tact the mobile node after it has moved to some new care-of address.

In fact, hosts remaining on the ho me network which com-

municate with the mobile node while it is at home are likelyto have ARP [16] cache entr ies for the mo bile node t hatbecome stale the instant the mobile node moves away. Forthis reason, the home agent is required to broadcast gratuitous

ARPs as soon as the mobile node moves away from its homenetwork and registers a new care-of address. The gratuitousARPs are supposed to have the effect of updating the ARPcaches of every node physically attached to the home network so that they resolve the IP home address of the mobile nodeinto the link-layer address of the home agent. Similarly, whenthe mobile node returns to its home network, it broadcastsgratuitous AR Ps so that its home addre ss is again associatedto its own link-layer address by the other nodes on the homenetwork. Networks on which nodes are attached that d o notwork with gratui tous ARP should not be administered as

home networks.Because of the danger of irreparably creating stale AR Pcaches, mobile nodes must never broadcastan AR P request or AR P reply packet onany visited network. If, for instance, a wire-less mobile node were to bro adcas t anAR P requ est to find the link-layer addressof the foreign agent broadcasting a care-of addr ess, any other wireless stations withinrange could po ssibly create AR P cacheentries for that mobile node. Those entrieswould make it hard to contact the mobilenode after it moves away.

s Figu re 7. IP-within-IP encapsulation.

New IP headerIP header

IP payload

Old IP header

IP payload

s Figu re 8. Minimal encapsulation format.

Original source address (if present)

Original destination address

Protocol S

••••••••

Reserved Header checksum

00 1 2 3 4 5 6 7 8 9

10 1 2 3 4 5 6 7 8 9

20 1

30 12 3 4 5 6 7 8 9




ROUTE OPTIM IZATION

As noted above, datagrams going to the mobile node haveto travel through the home agent when the mobile node is

away from home, but datagrams from the mobile node toother stationary Internet n odes can instead be routed directlyto th eir destination s (Fig. 10). This asymmetr ic routing, calledtriangle routing, is generally far from optimal, e specially incases when the correspondent node is very close to the mobilenode.

In t his section, we will describe in some deta il the ne ces-sary protocol operations (called route optimization ) to elimi-na te the t r iangle rou t ing problem. The cur ren t p r o tocoldefinition may be found in the Internet draft [17], and thereare additional details in an earlier paper on the subject [18].The advantages of route optimization are clear. The disadvan-tage is that, for the first time, and in major d istinction to thebase mobile IP pro tocol, changes are required in the corre -spondent nodes.

ROUTE OPTIM IZATION OVERVIEWThe basic idea underlying route optimization is that the routes

to mobi le nodes f rom the i r cor respondent nod es can beimproved if the correspondent node has an up-to-date mobili-ty binding (see the second section) for the mo bile nod e in itsrouting table. Most of the p roposed pr otocol described belowis geared toward providing such an updated mobility binding(usually shortened to just binding ) to correspondent nodesthat need them. With an updated binding, the correspondentnode will be able to send en capsulated data grams directly tothe mobile node’s care-of address instead of relying on a pos-sibly distant home agent to do so.

Every aspect of the design is influenced by the n eed toallow the correspondent nodes to be sure of the authenticityof the u pdates. Mobile computer users would not be very sat-isfied if their traffic were easily hijacked, and their very mobil-ity increases the likelihood that aspects of network security at

their point of attachment may be inadequate. We also have tokeep in mind that a majority of such nodes, today, will not beable to understand the protocol.

The cur rent u nsatisfactory state o f security within theInternet, and especially the lack of key distribution protocols,has deter mined several further aspects of the design of theroute optimization protocols. In particular, we believe that forthe near future while security protocols are still in the earlystages of development a nd dep loyment, corresponden t nodesare m ore likely to ma intain security relationships with homeagents than with individual mobile nod es. Observe that mobilenodes usually spend time connected to nodes either withintheir home domain or near their current point of attachment.

For instance, suppose an employee from one enterprise,say Home Dom ains, In c. (company H), wishes to use mobileIP while roaming the premises of another enterprise, say Fly

Away With Us, Inc. (company F). We expect that the employ-ee would, first of all, make sure the administrator of thehome domain sets up a security association with the admin-istrator of the foreign domain at company F. If the en ter-prises communicate frequen tly for business purposes (al ikely circumstance given the emp loyee’s need to roa mthere), such a security association might already exist andbe ready for use. Then we further hope that any relevantcorrespondent node could get the necessary security associ-ation need ed for commun ication with company H’s homeagent , perh aps by browsing an adm inistrat ive panel andrequesting the necessary information encrypted by its ownlocal security transform.

Following this speculative model of the fut ure , we havedesigned th e pro tocol so that the home agent is responsiblefor providing binding updates to any concerned correspondentnodes at foreign en terprises. Briefly, the p rotocol opera tes inas many as four steps:• A binding warning control message may be sent to the

home agent, indicating a correspondent node t hat seemsunaware of th e mobile node ’s care-of address.

• The correspondent node may send a binding request.• The home agent (typically) may send an authenticated

binding update containing the mobile node’s current care-of address.

• For smooth handoffs (sixth section), the mobile nodetransmits a binding update and ha s to be certain that theupd ate was received. Thus, i t can reque st a bindingacknowledgment from the recipient.In th e next sections, a brief description of the ab ove mes-

sage types will be pr esented . Note th at, par ticularly with th ebinding warning and binding updat e messages, the send ingagent mu st be careful not to blindly send the me ssages with-out re gard to pas t h i s tory. I f the message has been sen trecently, and seemingly has had no effect, the natural conclu-sion can be drawn that the intended recipient does not under -

stand rou te optimization pr otocol messages. Therefore, thesender is obligated to send th ose messages less frequently inthe future, or perhaps not at all. The protocol specifies a ran-dom exponential backoff mechanism for retr ansmitting thesemessages. Also note t hat all reserved fields are ignored onreception and must be set to zero upo n transmission. Later, abrief description of the security architecture currently plannedto make the ab ove transactions secure is present ed. All mes-sages are tra nsmitted b y way of UD P. As with th e basicmobile IP proto col, there is no nee d for the ad ditional fea-tures of TCP.

s Figu re 9. Hom e network configurations.

InternetworkA Router

Home agent

Physicalhome netw ork

InternetworkB Rout er andhome agent

Physicalhome netw ork

InternetworkC Rout er andhome agent

Virtualhome netw ork

s Figu re 10. Triangle routing.

Packets from Internet hostrouted indirectly through home agent

Encapsulation

Home

agent

Internet

host

Foreignagent

Packets t o Int ernethost rout ed OK

Mobile client




BINDING WARNING

A binding warning message (Fig. 11)informs the recipient that the target nodecould benefit from obtaining a fresh bind-ing for the mobile node. Usually, the recip-ient is the home agent, which is likely to beknown to the sender because the senderobtained its binding from the home agentin the first place.

BINDING REQUESTAny time a correspondent n ode determinesthat its binding is stale, or is going stale, itcan issue a binding request message (Fig. 12)to the home agent. The correspondent nodesends a 64-bit number (the identification ) tothe home agent for use in prote cting againstreplay attacks, and also to help ma tch pend-ing requests with subsequent updates.

BINDING UPDATESThe home agent (typically) sends a bindingupdate message (Fig. 13) to th ose corre-spondent nodes that need them. This often happens becausethe home a gent has rece ived a da tagram addressed to amobile node from the correspondent node, which subsequent-ly has to be tunneled by the ho me agent to the mobile node’scurrent care-of address. If the home agent has a security rela-tionship with the corresponde nt nod e, it can send a bindingupdat e stra ightaway without waiting for any binding warningor binding request. As with any binding, the binding includedin the update must contain an associated lifetime, after whichthe binding is to be purged by the recipient.

Notice that the correspondent node may be willing to useminimal encapsulation or GR E to tunnel datagrams to themobile node. The h ome agent sets the approp riate bits (M orG) to no t i fy the cor respondent node th a t the respec t iveencapsulation protocols may be used if desired. The A bit isused to r equest an acknowledgment, and the I bit is set if the

identification field is pre sent. Ca ses involving smooth handoff require acknowledgments. On the other hand, the home agentusually finds out if the correspondent nod e has not gotten theupdate yet, just by the fact that it still has to encapsulate data-grams from that correspondent node sent to the mobile node.

The binding update mu st be accompan ied by the rou teoptimization a uthen tication e xtension, similar to t he mo bile-home authentication extension.

BINDING ACKNOWLEDGMENTThe binding ackn owledgment message (Fig. 14) is used toacknowledge the reception of binding update messages. The64-bit identification field, again, protects against re plays and

allows the acknowledgment to be associated with a pendingbinding update. Th e N bit allows the r ecipient of th e bindingupdate to satisfy the A b it of the binding update, while inform-ing the updating agent that the up date was not acceptable.

SMOOTH HANDOFFSAs mobile nodes move from one point of attachment to th enext within the Internet, it would be nice if the transitions(called handoffs ) were as smooth as possible. This could be aproblem if datagrams heading toward one point of attachmentwere dropped because the mobile node had just left to attachsomewhere else nearby. With route optimization such prob-lems will almost certainly arise, because the re is no way thatall correspon dent nodes can instantane ously receive upd atedbindings reflecting the node’s movement. Moreover, studieshave shown that because of the way TCP works, the distrac-

tion caused by dropping datagrams is magnified (by about afactor of two) [19].Thus, it is important to d eliver d atagrams correctly even

though they may arrive at the “wrong” care-of address. Routeoptimization enables the solution to this problem, by allowingprevious foreign agents to maintain a binding for their formermobile visitors, showing a current care-of addre ss for each.With such information, a previous foreign agent can reencap-sulate a datagram with the r ight care-of addr ess and send italong to the mobile node.

In order to obtain the maximum benefit from using routeoptimization to effect smooth handoffs from one foreignagent to the next, it would be best if the home agent were not

involved. In fact, the hand off is targetedtoward handling datagrams in flight with-

out dro pping them, but the home agent isoften too far a way to respon d in time. If datagrams are being dropped for th e hun-dreds of milliseconds it would ta ke for adistant home agent to respond, megabits of data could be dr opped. R ecognizing thisprob lem, we have designed a method b ywhich coope rating fore ign agents can, byauthority of the mobile node, agree to p er-form smooth handoffs before the new reg-istration has completed; see Fig. 15 for anil lustrat ion of the pro cess. Essential ly,when the mobi le node moves to a new

s Figu re 11. Binding warning message format.

Target node address

Mobi le node home address

ReservedType

00 1 2 3 4 5 6 7 8 9

10 1 2 3 4 5 6 7 8 9

20 1

30 12 3 4 5 6 7 8 9

s Figu re 12. Binding request message format.

Identification

Mob ile node home address

ReservedType

00 1 2 3 4 5 6 7 8 9

10 1 2 3 4 5 6 7 8 9

20 1

30 12 3 4 5 6 7 8 9

s Figu re 13. Binding update message format.

Identification

Care-of address

Mob ile node hom e address

Type A I M G Reserved Lifetime

00 1 2 3 4 5 6 7 8 9

10 1 2 3 4 5 6 7 8 9

20 1

30 12 3 4 5 6 7 8 9




point of att achment, it instructs its new foreign agent to senda binding update to its previous foreign agent.

If the previous foreign agent has no fresh binding for themobile node, it can deliver the datagram to th e home a gentfor further handling. This might conceivably be done by thesimple expedient of de capsulating the datagram a nd send ing itout for normal IP routing. The datagram would then be rout-ed to t he ho me agent a gain. Such action, however, wouldprobably cause routing loops whenever the home agent encap-sulates datagrams for delivery to a foreign agent which haslost track of one of its visiting mobile nodes.

Instead, route optimization defines a way to use specialtunnels , which indicate to the home agent the need for specialhandling. When a foreign agent wants to send a data gramback to the home agent (be cause the home addr ess in thedecapsulated datagram is not available), it instead encapsu-lates the datagram to be sent to the h ome agent. The newlyencapsulated datagram uses the foreign agent’s care-of address as the source IP address. Upon reception of the newlyencapsulated datagram, the home agent compares the sourceIP address with the care-of address known in the binding cre-ated from the last registration. If the two addresses match, thehome agent must not tunn el the datagram back to the care-of address. Otherwise, the home agent is allowed to retunnel thedecapsulated result to the current care-of address known fromthe registration.

SECURING THE BINDING UPDATES

Whenever a binding update is transmitted, it has to be accom-panied by an authentication extension. However, doing so ismore challenging in the case of smooth handoffs. It is impor-tant to note t hat, again, foreign agents are considered anon y-mous entities that are not tr usted by the mobile node to doanything except follow protocol, and whose identity cannotnecessarily be verified. The implication follows that themobile node and foreign agent might share no special secretwhich can be used t o bu ild a security association. E ven with-out a secret, however, the mobile node needs to persuade itsprevious foreign agent that the binding update (sent for thepurpose of effecting a smooth handoff) has not been forged.The p rocess of offering this persuasive evidence has been achallenging problem for designing the smooth handoff mecha-nism. The per suasive evidence possessed by the mobile node

is called a registration key , and obtaining the registration key isaccomplished by one of several means.In the interest of keeping the description to an appropriate

size, the precise details of managing security between themobile node and foreign agent will largely be omitte d. Ho w-ever, the overall procedure is as follows:• The foreign agent uses agent advert isement f lags and

extensions to provide information about the style of secu-rity it is prepared to offer the mobile node.

• The mobi le node se lec t s one of a menu of poss ib leactions, depending on availability.

• The foreign agent responds to the mobile node’s request,and if necessary cooperates with the mobile node to pro-

vide smooth han doff operation and toobta in a reg ist ra t ion key f rom thehome agent.Our design of the smooth handoff proce-

dure, using the binding update message asshown above, relies mostly on the mobilenode to observe available methods and initi-ate t heir execution. The mobile nod e willknow whether or not the foreign agent iswilling to take part in the smooth handoff procedure by inspecting the advertised flags.

In ad dition, the mobile node, when it first detects the foreignagent, will know immediately whether a mobility security asso-ciation is available with th at agent. I n th at case, the mobilenode can establish a registration key by the simple expedient of picking a good random number and encoding it for the foreignagent, using their shared secret. In this case, the registrationhas to include a mobile-foreign authentication extension .

However, in our estimation the appropriate security associ-ation is a luxury unlikely to be encoun tered. Th erefore, th emobile node may instead rely on the home agent to pick out aregistration key for use by the mobile node and foreign agent.This, again, can be done in one of two ways. If the foreign agentand home agent share a security association, the foreign agentcan reque st that the home a gent encrypt a diligently selectedregistration key using that security association and transmitthe result back to the foreign agent as part of the registrationreply. The home agent informs the mobile node of the regis-trat ion key value by using the mobility security associationwhich is always known to exist between the two nodes.

If, on the other hand, the foreign agent does not have asecurity association with the h ome agent , but instead has apublic key, it can send the public key to the home agent alongwith the registration, and accomplish much the same result asoutlined in the last paragrap h. Lastly, if the foreign agent doesnot have a public key, and has security associations with nei-ther the home agent nor the mobile node, there is still thepossibility for a Diffie-Hellman key exchange [20].

Performing smooth handoffs is complicated by the need to

create a registration key in the absence of well-defined, stan-dardized, widely deployed security protocols. Nevertheless, it ishop ed t hat the complication of the latter opera tion will notobscure the basic simplicity of the protocol, and that providing thepro tocol definition for each of a variety of feasible scenarios willbroaden the appeal of smooth handoffs rather than cloud its future.

IETF

I n this section, we describe the pertinent details of the status of mobile IP in the standardization process, and interesting details

about working groups and the standardization process itself.The IE TF is a somewhat loose confederation of numerous

(over 60, at last count) working groups that meets three timesa year. At these meetings, each working group may meet once

or several times, or not at all. The working groups are dividedinto areas , each administered by an area director . For instance,the Mobile IP working group is part of the routing area. Thearea director for each area has to review the proposals fromeach working group before they can be submitted for furtherconsideration by the IE TF at large. The area directors, takentogether, also constitute another group called the InternetEngineering Steering Group (IESG). The I ESG, upon recom-mendation of the p articular area d irector sponsoring a proto-co l document , t r i es to ensure a h igh degree of p r o tocolquality, and to ensure that standardized protocols work wellwith ea ch other . To pu t it mildly, this is a huge job, gettingbigger all the time with the growth of the Internet. Complicat-

s Figu re 14. Binding acknowledgment message format.

Identification

Mob ile node home address

ReservedNType

00 1 2 3 4 5 6 7 8 9

10 1 2 3 4 5 6 7 8 9

20 1

30 12 3 4 5 6 7 8 9




ing an already complex problem isthe fac t tha t In te rne t p ro tocolssuddenly represent big business,and a false step on the par t of anarea d i rec tor o r work ing groupchair could easi ly result in anexpensive lawsuit.

The M obile IP working groupitself has had a long and at timescontentious history. A successionof eminently competent workinggroup chairs have fortunat ely man-aged to br ing the p rocess to asomewhat successful milestone,with the recent pu blication o f thebase mobi le IP pro tocol docu-ments as proposed standards, andRFCs 2002–2006. A good place tolook for such documents is on theIETF Web page, ht tp: / /www.ietf.org. After some furthe r con-sensus has been achieved and additional operational experi-ence gained, mobile IP may progress to a draft standard. Thisstep should a lso be accompanied by a large increase in thenumber of deployed mobile IP systems in the Intern et. Forvarious reasons, mobile IP has not until now enjoyed its fullpotential.

Route op t imiza t ion , and the o ther pro tocol e ffor t sdescribed in the next section, are in a far more fluid state.These are still Internet drafts, not yet proposed standards.

CURRENT TOPICS

IP VERSION 6 (IP V6)Although space does not permit a full exposition of the detailsof the proposed mobility protocols for IPv6, some overall dis-cussion is certainly in or der. The current Interne t dra ft [21]and a recent paper on the subject [22] should be consulted for

full details.The IPv6 protocol [23, 24] and its attendant address con-figuration protocols ( Neighbor D isco very [25] and Stateless

Address Autoconfiguration [26]) form an almost perfect proto-col basis for mobile networking. The basic idea, that a mobilenode is reachable by sending packets to its home network, andthat the h ome agent sends packets from a home network tothe mo bile nod e’s current care-of add ress, remains the same.Also, similar to the me thod used before (for IP v4, as describedearlier), the ho me agent encapsulates packets for d eliveryfrom the home network to the care-of address.

What has changed is that the mo bile node now has anensured capability to obtain a care-of address by using theabove-mentioned address configuration protocols. Thus, thereis a greatly reduced ne ed for fore ign agents, and they have

been eliminated from the mo bility suppor t prot ocol. More -over, the idea from route optimization of supplying bindingupdates to correspondent nodes is able to be integrated nicelyinto I Pv6 by using the newly defined destination options . Sincedestination opt ions are inspected on ly by the destination,there is no performance pena lty at intermediate rout ers forusing them. Since such options can be placed into any IPv6packet, there is far less overhead involved in sending bindingupdates to correspondent nodes. The binding update can beincluded in any normal data packet that the mobile nodewould be sending to the correspon dent n ode an yway. If apacket ever arrives at the home network, it will be encapsulat-ed and sent to the mobile node. Thus, when a mo bile node

receives such an encapsulated IP v6packet, it can infer that the o rigi-nator of th e decapsulated packetshould receive a binding update(in a destination option) sent alongwith th e very next packet tran smit-ted to the originator.

Just as with IPv4, bindingupdates need to be authenticated.What is different, however, is theexpectation that every IPv6 no dewill be able to establish and main-tain security relationships as need-ed. In ord er to comply with theIPv6 specification, each no de isrequi red to implement IPv6authentication header [27] process-ing. Thus, the mobile node canassume that, by using security pro-tocols already specified, its bindingupdates wil l be confidently

received by the corresponde nt nod es which need them . InIPv6, the mobile node is the only node authorized to supplybinding updates to its correspondent nodes, and typically doesso at the earliest reasonable time after moving to a new pointof attachment to the IPv6 Internet.

FIREWALLS AND PACKET FILTERING PROBLEMSOne of the biggest problems facing the deployment of mobileIP in today’s Internet is that mobile nodes roaming in foreignenterprises look like interlopers, and the firewalls and borderrouters administered at the foreign domain are usually config-ured t o interrup t traffic to and from interloper no des. This isa reaction to the growing danger of protocol attacks and thedesire to eliminate as many as possible of the hiding placesfavored by malicious users.

So, for instance, a recent In ternet draft [28] exhorts sys-tems administrators to perform ingress filtering , by which ismeant the action of disallowing datagrams entry into the

Interne t from any leaf domain, unless those datagrams con-form to e xpectations about t heir source IP a ddress. By doingso, the Internet is considered better protected from domainsharboring malicious users, because users sending datagramsfrom the domain will not be able to impersonate users fromthe ingress-filtering domains.

This, of course, is anathema for mobile IP. Any mobilenode in a foreign domain is going to have a source IP addresswhich do esn’t “look r ight” to such ingress-filtering bo rde rrouters. One idea is to allow the mobile nodes to issue encap-sulated datagrams using their care-of addresses as the outersource IP add resses. Note th at using the care-of address asthe source IP address of the original datagram is typically alosing prop osition, since the correspondent node is keepingtrack of its sessions by way of the mobile node’s home address,

not its care-of addr ess.The downside of this encapsulation approach is that IPv4correspond ent nod es are unlikely to be able to de capsulatesuch datagrams, so the mobile node has to find another likelytarget for the en capsulated datagrams, and ther e aren’t manycommonly available today. One p ossible tar get would be themobile node’s home agent, which is pretty much guaranteedto be able to perform decapsulation. Obviously, this intro-duces yet another inefficiency in the routing of da tagramsfrom mo bile nodes, and ther e is work actively in pro gress totry to find other solutions to this problem.

An associated difficulty is the prob lem of a llowing themobile node to send datagrams into its home domain. The

s Figu re 15. Sm ooth handoff during registration.

Home agent

Foreign agent

Mob ile host

Previousforeign agent

Notify previousforeign agent

Register with home agent

Internetwork

Register w ith foreign agent




border routers protecting the home domain are likely to disal-low any datagrams which seem to have a source IP addre ssbelonging to an inter nal subnet of the h ome dom ain. Thisproblem is proba bly amenable to solution by way of some pro-tocol which informs the (probably specialized) border routersabout those source IP addresses which are allowed to exter-nally originate datagrams into the home domain. It is also fea-sible for border routers to encapsulate such datagrams fordelivery to an enterp rise home agent [29, 30].

As a matter of administrative convenience, it is likely thatthe firewalls will be configured to allow all datagrams in aslong as they are addressed to a home agent, protocol UDP,port 434. This will at least ena ble mobile IP to get the r egis-trations in from the global Internet to the home agents. Fromthe considerations in the previous paragraphs, it is also rea-sonable to expect that the local network adm inistrator willdemand a very high degree of reliability and code qua lity from

the home agent.SIM ULTANEOUS BINDINGS

One feature of mobile IP which has not been stressed in thisarticle is the u se of multiple simultaneous registrations. Thebase specification permits a mobile node to register more thanone care-of address at the same time, and to d eregister a spe-cific care-of addresses as necessary, by setting the S bit in theregistration request message. When there is more than one care-of address active for a mobile node, the home agent is instruct-ed to send a duplicated encapsulated datagram to each care-of address. Presumably, then, the mobile node will receive thedecapsulated result at each of the several care-of addresses.

This unusual behavior still does technically conform torouter and host requirements for IP, because the IP specifica-

tion allows duplicating of data grams. There are t imes whensuch behavior is justified for certain classes of links. More-over, it is easier from a network-layer protocol standpoint notto require that network nodes enforce any policy ensuring thatdatagrams a re not duplicated. R emoving duplicates is typicallydone by transport- or application-layer p rotocols whenever itmakes a difference. In the case of mobile IP, the original jus-tification for simultane ous registrations was that ma ny wire-less links are erro r-pron e, an d cert ainly receiving noisy signalsfrom multiple sources can often allow a target to reconstructthe original signal more accurately.

Simultaneous registrations, while still holding promise forthe improved handling of IP wireless connectivity, have not

been available in any implementation kno wn to the au thor.Thus, this optional feature should be considered a possiblefuture benefit. The unavailability of simultaneous registrationis probab ly mostly due to the slow dissemination of wirelesslocal area network (LAN) technology into the mar ketplace,considering that wireless connectivity was the motivating fac-tor for the inclusion of the feature in the first place.

REGIONALIZED REGISTRATIONThe concern has been raised that, for highly mobile com-puter s, too much traffic between th e visited and hom e net-works would be generated by the registration process. Giventhe current state of the protocol, several counterargumentscan be made against that objection:• Unless route op timization is enabled, the nor mal traffic

of encapsulated datagrams from th e home agent willmake the control traffic from the registration seem n eg-ligible.

• The mobile IP specification technically allows registra-tions to be issued no more often th an once per secondper mobile node. That should not present too muchnetwork traffic.

Thus, the pr oblem of frequent registration is probably notterr ibly import ant u nti l route o ptimization is more ful lydeployed. However, there are other factors that must be con-sidered. First, with some diligent management of the localconnectivity available to the mobile node and buffering of datagrams that ha ve to be delivered, one can get some of thebenefit of smooth han doffs without implementing route opti-mization in the foreign agents (e.g., see [31]).

In fact, it is also possible to h ave a collection of foreignagents joined together in a multicast group, and then subse-quently allow the mobile node to use the multicast IP addressas its care-of addr ess. In either case, work is necessary tocause each foreign agent to buffer each datagram, at leastmomentar ily, in case the mobile node de cides to de part th eprevious foreign agent from which the datagram was expectedto be transmitted to the mo bile no de. Also, notably, any suchapproach requ ires new protocol to be operated by the foreign

agents, and the schemes are really intended to only be used ina two-level hierarchy. It is an open question whether doingthe buffering is better in conjunction with the above-men-tioned methods or with route optimization techniques.

Another alternative [32] establishes a hierarchy of foreignagents, and advertises multiple foreign agents in the agentadvertisement. Then registrations can be localized to the for -eign agent which is the lowest common ancestor o f the care-of addresses at the two points of at tachment of interest . Toenable this, the mobile node has to figure out how high up thetree its new registration has to go, and th en arr ange for thetransmission of the registration to each level of the hierarchybetween itself and the closest common ancestor between itsnew and previous care-of addresses.

Consider the illustration in Fig. 16. While it was using the

services of foreign agent FA 7, the mobile node was receivingagent advertisements describing the hierarchical lineage FA 7,FA 4, FA 2, FA 1, and had caused a registration, now specializedfor this purpose, to be transmitted to each of those foreignagents as well as its home agent. Its ho me agent believes themobile node is located at care-of address FA 1, foreign agentFA 1 believes the mobile node is located at foreign agent FA 2,and so on, until foreign agent FA 7 actually knows the where-abouts of the mobile node. When th e mobile node moves toforeign agent FA 8, it only has to cause the new hierarchicalregistration to propagate as far as FA 4. When the mo bilenode moves to foreign agent FA 9, it receives advertisement sindicating the lineage FA 9, F A 6, F A 3, F A 1. By comparing the

s Figu re 16. Hierarchical foreign agents.

Internet

HA

FA1

FA3FA2

FA6FA5

MH@IFMH@IF

MH@FA 2MH@FA 3

MH@FA 7MH@FA 8

MH@FA 6

MH@FA 9

MH@FA 4

MH@FA 1

FA4

FA10FA9FA8FA7



C i i i 199

previous and current lineage, the mobile node determines thatit has to cause the registration to propagate up the hierarchyto FA 1, but the re gistration still does not h ave to reach thehome a gent. The ho me agent can, in this scenario, be consid-ered th e “ultimate” care-of address of the mobile node. Notealso that, as a result of th e differing views of the hierarchicalagents about the mobile node’s care-of address, the originaldatagram must be relayed to a number of intermediate nod esin the h ierarchy; each is then charged with the r esponsibilityof retun neling the datagram if necessary to the next lowerlevel of the hierarchy.

SUMMARY

I n this article, we have explored most of the technical detailsof mobile IP, an extension to IP which allows mobile nodes

to roam transparently from place to p lace within the I nternet,usually with no discernible disruption of service. Mobile IPaffects the routing of datagrams within the Internet, by effec-t ively al lowing the hom e agent t o create a tun nel , usingencapsulation, between the mobile node’s home network andwhatever care-of address happens to identify its current pointof attachment. The advertisement and registration protocolsare described in detail, and variations on the tunneling proto-cols shown.

Tunneling from the home agent introduces additional rout-ing links into the communication paths between mobile nodesand their correspondent nodes. This suboptimal routing canbe cured, with the cooperation of the correspondent nodes, byallowing the d issemination of binding upd ates to each activecorrespondent using the route optimization protocols. Bindingupdates allow the correspondents to tunnel datagrams directlyto the mobile node’s care-of address instead of relying on thehome agent for t his function. With virtually the same routeoptimization t echniques, foreign agents can cooper ate withthe mo bile nod e to effect smooth handoffs, being careful notto drop any datagrams even when the mobile node has movedaway from th e care-of add ress receiving the da tagrams.

Mobile IP and route optimization both must be subject to

rigid requirements for authentication of the claimed care-of addresses, because otherwise malicious hosts could disrupt orcompletely usurp communications with the mobile node.These new requirements have fostered the inclusion of simpleyet r elatively new techniques into these p rotocols to e nsurethat the care-of address information has been sent by anauthor ized en tity.

Aspects of the standardization pro cess within the IE TF,which have had a major impact on the development of mobileIP, have been described. Finally, we describe some areas of current and supplemental interest related to mo bile IP. Theproblems facing mobile IP in th e realm o f secure enterpr isecomputing ar e d etailed, especially regarding ingress filteringand firewalls. Mobility suppo rt for IPv6 is outlined in its grossaspect. The possible futur e ben efits of simultaneous r egistra-

tions are briefly explained, and several ways to localize regis-tration requests are described.

FINAL WORDS

W e hope this brief introduction to mobile IP will engenderinterest in the solution to the remaining problems which

continue to challenge deployment of the protocol, particularlyin the area s involving existing enterprise security facilities usingfirewalls and recent packet filtering techniques. Participationon the mobile IP mailing list is encouraged; the mailing list canbe joined by sending mail to ma jordomo@ Smallworks.COM ,including the line “subscribe mobile-ip” in the b ody of the

message. One can keep up with general events within theIE TF by selecting the app ropr iate links on the We b pagehttp ://www.ietf.org. Th e au tho r will also gladly answer elec-tronic mail sent to [email protected]. Acknowledgmentis due to V ipul Gupt a, without whom th is article could neverhave been finished even in the time it took to do so, and to themany people who have contributed greatly to the effort of pr o -ducing and improving the mobile IP specifications.

REFERENCES[1] J. B. Postel, ed., “ Int ernet Protocol ,: RFC 791, Sept. 1981.[2] C. Perkins, ed., “ IPv4 Mobili ty Support ,” RFC 2002, Oct. 1996.[3] J. B. Postel, ed., “ Transmission Control Prot ocol,” RFC 793, Sept. 1981.[4 ] S. Alexander and R. Drom s, “ DHCP Opt ion s and BOOTP Vendor Exten -

sions,” RFC 1533, Oct. 1993.[5] R. Droms, “Dynamic Host Configurat ion Protocol, ” RFC 1541, Oct. 1993.[6] P. Vixie et al. , “ Dynamic Updat es in t he Domain Name System (DNS),”

draft-ietf-dnsind-dynDNS-11.txt , Nov. 1996, (work in progress).[7] D. E. Eastlake and C. W. Kaufm an, “ Domain Name System Prot ocol

Security Extensions,” draft-ietf-dnssec-secext-09.txt , Jan. 1996 (workin progress).

[8] S. E. Deering, ed., “ ICMP Rout er Discovery Messages,” RFC 1256, Sept . 1991.[9] J. B. Postel, ed., “ Int ernet Control M essage Prot ocol,” RFC 792, Sept. 1981.[10] C. Perkins, “Minimal Encapsulation w it hin IP,” RFC 2004, May 1996.[11] S. Hanks et al. , “ Generic Routing Encapsulat ion (GRE),” RFC 1701, Oct. 1994.[12] V. Jacobson , “ Compr essing TCP/IP Headers for Low -Speed Serial Links,”

RFC 1144, Feb. 1990.[13] J. K. Reynolds and J. Postel, “ Assigned Numbers,” RFC 2000, Oct. 1994.[14] D. L. Rivest, “ The MD5 M essage-Digest Algorithm,” RFC 1321, Apr . 1992.[15] C. Perkins, “ IP Encapsulation wi th in IP, RFC 2003,” May 1996.[16] D. C. Plumm er, “ An Ethernet Addr ess Resolut ion Prot ocol: Or Convert-

ing Network, Protocol Addresses to 48.bit Ethernet Addresses for Trans-mission on Ethernet Hardware,” RFC 826, Nov. 1982.

[17] D. B. Johnson and C. E. Perkins, “ Rout e Optim ization in M obil e-IP,”draft-ietf-mobileip-optim-05.txt, Nov. 1996 (work in progress).

[18] C. Perkins, A. Myles, and D. Johnson, “ IMHP: A Mobil e Host Proto colfor the Internet,” Comp. Networks and ISDN Sys. , vol. 27, no. 3, Dec.1994, pp. 479–91.

[19] R. Caceres and L. Ift ode, “ Improving t he Performance of Reliable Trans-port Protocols in Mobile Computing Environments,” IEEE JSAC , vol. 13,no. 5, June 1995, pp. 850–57.

[20] B. Schneier, Applied Cryptography , New York: John Wiley and Sons, 1993.[21] D. Johnson and C. Perkins, “M obili ty Suppor t in IPv6,” draft -ietf -

mobileip-ipv6-03.txt, Nov. 1996 (work in progress).[22] C. E. Perkins and D. B. Johnson, “ Mobil it y Support in IPv6,” Proc. ACM

Mobicom ’96 , Nov. 1996.[23] S. Deering and R. Hinden, “ Int ernet Protocol, Version 6 (IPv6) Specifi-

cation, ” RFC 1883, Dec. 1995.[24 ] R. Hinden and S. Deering, “ IP Version 6 Add ressing Arch it ecture,” RFC

1884, Dec. 1995.[25] S. Thomson and T. Narten, “ IPv6 Stat eless Address Autoconf igur ation,”

RFC 1971, Aug. 1996.[26] T. Narten, E. Nordmark, and W. Simp son, “ Neighbor Di scovery for IP

Version 6 (IPv6),” RFC 1970, Aug. 1996.[27] R. Atkin son, “ IP Authenti cation Header,” RFC 1826, Aug. 1995 .[28] P. Ferguson, “Ing ress Filt ering in t he Internet,” draft -ferguson-ingress-

filtering-01.txt, Nov. 1996 (work in progress).[29] G. Mont enegro, “ Reverse Tunneling for M obile IP,” draft -ietf-m obileip-

tunnel-reverse-00.txt, Jan. 1997 (work in progress).[30] V. Gupta and S. Glass, “Firewall Traversal for M obil e IP: Goals and Require-

ments,” draft-ietf -mobileip-ft -req-00.txt, Jan. 1997 (work in progress).[31] R. Caceres and V. Padmanabhan, “ Fast and Scalable Handof fs for Wi re-

less Networks,” ACM Mobicom ’96 , Nov. 1996.[32] C. Perkins, “ Mo bil e-IP Local Registrat ion w it h Hierarchical Foreign

Agents,” draft -perkins-mobileip-hierfa-00.txt, Feb. 1996 (work inprogress).

BIOGRAPHYCHARLES E. P ERKINS [M] has recently joined Sun Microsystems. He was previ-ously a research staff member at IBM T. J. Watson Research Center, and hasbeen involved with developing mobile computer systems for the last eightyears. He is editor for ACM/IEEE Transactions on Networking in the area ofwireless networking, and for ACM Wireless Networks in the area of networkprotocols. He is serving as document editor for the Mobile-IP working groupof the Internet Engineering Task Force (IETF), and is author or co-author ofstandards-track documents in the svrloc, dhc (dynamic host configuration),and IPng working groups. He is serving on the Internet Architecture Board(IAB) and nominated to serve on the board of directors of the Internet Soci-ety. He holds a B.A. in mathematics and an M.E.E. degree from Rice Univer-sity, and an M.A. in mathematics from Columbia University.

perkins ipv4

Documents