IIIDenitionsThefollowingspecictermsareusedinthispaperNodeAdevicein - PDF document

,y, III.DeÞnitionsThefollowingspecictermsareusedinthispaper:NodeAdeviceinthenetworkthatimplementstheInternetProtocol,IP[10].RouterAnodethatforwardsIPdatagrams,asspec-iedin[1].Thisdoesnotincludenodesthat,thoughcapableofIPforwarding,havethatca-pabilityturnedoff,nordoesitincludenodesthatperformIPforwardingonlyinprocessingIPSourceRouteoptions.HostAnynodethatisnotarouter.MobilehostAhostthatmayconnecttotheInternetinnetworksotherthanitsownhomenetwork,whilestillusingitshomeaddress.StationaryhostAhostthatisnotamobilehost.CorrespondenthostAhostcommunicatingwithan-otherhost.Thistermisusedwhenitisnotrele-vantwhetherahostisamobilehostorastationaryhost.HomeaddressAnaddressusedtoidentifyamobilehost,nomatterwhereitmaycurrentlybelocated.HomenetworkThe(logical)networkonwhichamobilehost’shomeaddressresides.Care-ofaddressAnaddressthatdenesthelocationofamobilehostatsomeparticularinstantoftime.Packetsaddressedtothemobilehostwillarriveatthisaddress.ForeignagentAnagentthatoffersacare-ofaddressforvisitingmobilehosts,anddeliversarrivingpacketsaddressedtooneofthesemobilehostslocallytothemobilehost.HomeagentAnagentthatmaintainsinformationaboutthecurrentcare-ofaddressofeachofthemobilehostsitisconguredtoserve,andthatfor-wardspackets(addressedtoanyofthesemobilehosts)tothecare-ofaddressforthatmobilehost.TriangleroutingAsituationinwhichacorrespon-denthost’spacketstoamobilehostareforwardedthroughthemobilehost’shomeagent,ratherthanfollowingtheshortestpathdirectlytothemobilehost.CacheagentAnagentthatcachesthelocationofoneormoremobilehostsandforwardspacketstothesemobilehosts.IV.BasicOperationIV.A.Infrastructure AmobilehostistheIMHPentitythatmaymovethroughtheIPinternetwork.ItisassignedaconstantIPaddressonahomenetwork,knownasitshomeaddress.Correspondenthostsmayalwaysusethehomeaddresstoaddresspacketstoamobilehost.Amobilehosthasahomeagent,whichisattachedtoitshomenetwork.Eachhomeagentmaintainsalistknownasahomelist,whichidentiesthosemobilehoststhatitisconguredtoserve,alongwiththecur-rentlocationofeachofthesemobilehosts,ifknown.IMHPmakesnoassumptionsaboutwhethermobilehostsusewiredorwirelessinterfacesforconnectiontothenetwork.Thehomenetworkcongurationmaycorrespondtoaphysicalsubnetoravirtualsubnet.Forexample,thehomenetworkmaybeaphysicalnetworkcon-nectedtotheInternetthroughanIProuter,whichisresponsibleforadvertisingconnectivitytothehomenetwork.Thehomeagentmaybeaseparatenodeattachedtothephysicalhomenetwork,ormaybeimplementedbythesamenodeastheIProuter.Alter-natively,thehomenetworkmaybeavirtualnetwork,whichmeansthatmobilehostsneverconnectdirectlytotheirhomenetwork.TheseexamplecongurationsareillustratedinFigure1.Othercongurationsarealsopossibl

einwhichthehomeagentisreplicatedordistributed,orthehomenetworkisdistributed,butsuchcongurationsarenotdiscussedinthispaper.Whenamobilehostconnectstothenetwork,itmustperformaregistrationprocessbeforepacketswillbedeliveredtoit.Themechanismsusedtoiden-tifythatthemobilehosthasconnectedtotheanewnetworkdependonthesub-networklayertechnologybeingused.Eitherthepotentialforeignagentorthehomeagentmayrejectaregistrationattempt.Typi-callythegroundsforrejectionwillbesecuritybased,althoughotherfactorssuchasloadmayalsobeconsid-ered.Duringtheregistrationprocess,themobilehostwillspecifywhetherornotitsnewlocationshouldbemadeavailabletootherIMHPentitiesforthepurposesofrouteoptimization(SectionIV.C). home agent Router andhome agent Internetwork Physicalhome network InternetworkVirtualhome network InternetworkRouter Physicalhome networkHome agent Figure1ExamplehomenetworkconÞgurations InternetMobileHostProtocolProc INET94/JENC5Perkins Myles andJohnson Eachforeignagentmaintainsalistknownasavisitorlist,whichidentiesthosemobilehoststhatarecurrentlyregisteredwithit.Theaddressoftheforeignagent,suppliedasthemobilehost’scare-ofaddress,denesthemobilehost’scurrentlocation.Thecombinationofahomeaddressandacare-ofaddressisknownasabinding.Thebindingbetweenamobilehostandaforeignagentisalsotaggedbyalogicaltimestamp,whichisgeneratedbythemobilehostbyincrementingitsprevioustimestampvalueeachtimeitattemptstoregisterwithaforeignagent.Thetimestampisalwaysincludedwithanybindingstoredorpassedthroughthenetwork.Timestampsmaybeusedtocomparebindingsforagivenmobilehosttodeterminewhichisthemostrecent.Theregistrationprotocolensuresthatamobilehost’shomeagentlearnsaboutthenewbindingofanymobilehostitserves.Theregistrationprotocolalsonotiesthepreviousforeignagent(s)thatthemobilehost’shasmoved.Thismechanismallowsthepre-viousforeignagenttoforwardpackets,destinedtoamobilehostthathasmovedelsewhere,tothemobilehost’snewlocation.Insteadofnotifyingtheprevi-ousforeignagentofthemobilehost’snewlocation,theregistrationprotocolmaysimplynotifyitthatthemobilehosthasmoved,withoutrevealingitsnewlo-cation;inthiscase,thepreviousforeignagentsimplyremovesthemobilehostfromitslistofvisitingmobilehosts.Theexchangeofpacketsusedbytheregistra-tionprotocolisillustratedinFigure2foratypicalIMHPconguration.Anynodemaycachethecurrentbindingofamobilehostinordertobeabletoforwardpacketsdirectlytothatmobilehost.Amobilehost’sprevi-ousforeignagent(functioningasacacheagent)maycachethenewbindingofthemobilehostfromtheno-ticationsentduringthenewregistration;thiscacheentryservesasa“forwardingpointer”toallowpack-etsarrivingatthemobilehost’soldlocationtobefor- Register with home agentHome agent No

tify previousforeign agentPreviousforeign agent Register with foreign agentForeign agent Mobile host Figure2Exampleregistrationprocesswardedtoitsnewlocation.AnycorrespondenthostthatimplementsIMHP(forexample,anothermobilehost)mayalsofunctionasacacheagentbysimilarlymaintainacacheofbindingsforothermobilehosts;theIMHPmanagementprotocolsendsaBindingNo-tifypacket(SectionV.A)tocorrespondenthostsasneededtobuildandmaintainthesecaches.ThecacheofbindingsmaintainedbyacacheagentisknownaslocationcacheEachentryinthevisitorlistorlocationcacheofanodehasatimeoutassociatedwithit,ensuringthatastaleentrydoesnotpersistforever.ThetimeoutisresetwhenevertheentryisreconrmedbytheIMHPmanagementprotocolorbytheregistrationprotocol.Themobilehostisresponsibleforensuringthatitsvisitorlistentryinitscurrentforeignagentisnottimedout.AcacheagentmayactivelyattempttoreconrmbindingsinitslocationcacheusingtheIMHPmanage-mentprotocol.Activereconrmationmethodsmaybeappropriatewhenalocationcacheentryisusedoftenandatimeout(alongwiththesubsequentrediscoveryprocess)woulddisruptcommunications.Thenoticationtoamobilehost’spreviousfor-eignagentsmustbesentreliably,becauseotherwisepacketsmightbelostuntilthepreviousforeignagenttimesoutitsvisitorlistentryforthemobilehost.Thenoticationisthusperiodicallyretransmittedeitheruntilitisacknowledgedoruntilthepreviousforeignagentcanbeassumedtohavetimedoutitsvisitorlistentryforthemobilehost.Thetimeoutperiodthataforeignagentusesforavisitorlistentryisestablishedbynegotiationwhenamobilehostregisterswiththeforeignagent.Whenamobilehostisconnectedtoitsphysicalhomenetworkitmay,afternotifyingitshomeagent,reverttooperatingasahostusingconventionalproto-colswithoutanyIMHPoverheads,ifcertainminimalconditionsaremet.Mostnotably,whenamobilehostdepartsfromitshomenetwork,anyARPcacheentriesforthemobilehoststoredatexistingnodesonthehomenetworkmustbeupdated.ThiscanbedonebyhavingthehomeagentsendoutanARPreplypacketonbehalfofthemobilehost,specifyingthatthehomeaddressofthemobilehostistobeassociatedwiththeMACaddressofthehomeagent.ThisARPreplyisknownasagratuitousARP.Foreignagents,homeagents,andmobilehosts,althoughdescribedseparatelyinthissection,maybecombinedtogetherwithinthesamenodeformanypurposes.TheIMHPmanagementprotocoldiscussedinthissectionisdescribedmorefullyinSectionV.A.IV.B.PacketRouting IMHPentitiesmustdirectpacketsdestinedtoamobilehosttoitscurrentknownlocation(i.e.,care-ofaddress).IMHPentitiessendpacketstoamobilehost’scurrentlocationusingtunneling.Asageneralrule,tunnelinginvolvestheuseofanencapsulation InternetMobileHostProtocolProc INET94/JENC5Perkins Myles andJohnson protocol.AllIMHPentitiesmustsupportthedefaultIMHPtunnelingpr

otocoldescribedinSectionV.B.IMHPestablishesafewrulesforforwardingpack-ets.Theseruleshelpensurethatoptimalroutesareusedwhenpossible.Ingeneral,anodeuseswhat-everlocationcache,visitorlist,homelist,andnormalroutingtableinformationithasavailabletoforwardpackets,withasmallnumberofrestrictions.Ifnoneoftherulesbelowapplytoaparticularpacket,thennormalIProutingrulesarefollowed.ThefollowingtwobasicrulesapplytoallIMHPnodes,whichallowforthedeliveryofpacketsad-dressedtothesenodesandforthedecapsulationoftunneledpackets:Ifanodereceivesatunneledpacket,andthedes-tinationofthetunnelisoneofthenode’sownaddresses,thenthenodedecapsulatesthepacketandcontinuesprocessingthepacketaccordingtotheremainingforwardingrules.Ifanodereceivesapacketthatisnottunneled,andthedestinationofthepacketisoneofthenode’sownaddresses,thenthenodepassesthepackettohigherlayerprotocolsforprocessing.Ahomeagentwillgenerallyhaveacurrentau-thenticatedbindingforthemobilehostsinitshomelist.Ahomeagentmustalsoserveasacacheagentforthesemobilehosts,andmaybeaforeignagentforthemobilehostsitservesaswell.Thesepropertiesservetodenethefollowingforwardingrulesforahomeagent,whendealingwithpacketsaddressedtothemobilehostsinitshomelist:Ifahomeagentreceivesatunneledpacketforamobilehostinitshomelist,inwhichtheorig-inaldestinationisthesameastheencapsulateddestination,thenthehomeagentdecapsulatesthepacketandcontinuesprocessingthepacketac-cordingtotheremainingforwardingrules.Ifahomeagenthasavisitorlistentryforthemobilehost,thenthehomeagentdeliversthepacketlocallytothenetworkinterfaceindicatedbythevisitorlistentry.Ifahomeagenthasalocationcacheentryforthemobilehost,thenthehomeagenttunnelsthepackettothecare-ofaddressindicatedinthelo-cationcacheentry,subjecttotherestrictioninthefollowingrule.Ahomeagentmustnevertunnelapackettoaforeignagentifthepacketwasjusttunneledtothehomeagentfromthatsameforeignagent.Thisruleavoidsloopingbetweenahomeagentandaforeignagentthatnolongerthinksitservessomemobilehost.Thehomeagentmayalsoundertakeappropriateactions(hereundened)tofurtherhandlethepacketorlocatethemobilehost.Ifahomeagentdoesnothavealocationcacheen-tryoravisitorlistentryforthedestinationmobilehost,furtheractionisundened.Thehomeagentmayinthiscaseundertakeappropriateactionstofurtherhandlethepacketorlocatethemobilehost.Foreignagentsandcacheagentsuseforwardingrulesthataresimilartothoseusedbyahomeagent.Thedifferencesfromtherulesusedbyahomeagentareprimarilyduetothefactthataforeignagentoracacheagentmightnothaveanauthenticatedbindingforthemobilehost,ifthatagentisnotalsothehomeagentservingthatmobilehost.Thefollowingfor-wardingrulesapplytopacketsreceivedbyaforeignagentoracacheagent:Ifaforeignagentrec

eivesatunneledpacket,andtheforeignagenthasanentryinitsvisitorlistforthepacket’sdestinationafterdecapsulatingthepacket,thentheforeignagentdeliversthepacketlocallytotheinterfaceindicatedbythevisitorlistentry.Ifaforeignagentreceivesapacket,andthefor-eignagenthasanauthenticatedvisitorlistentryforthepacket’sdestination,thentheforeignagentdeliversthepacketlocallytotheinterfaceindi-catedbythevisitorlistentry.Ifacacheagentreceivesadatapacket(notanIMHPmanagementpacket),andthecacheagenthasalocationcacheentryforthepacket’sdesti-nation,thenthecacheagenttunnelsthepackettothecare-ofaddressindicatedinthelocationcacheentry.Ifacacheagentoraforeignagentreceivesatunneledpacket,andthecacheagentorforeignagentisunabletoforwardthepacketusingtheaboverulesafterdecapsulatingthepacket,thenthecacheagentorforeignagenttunnelsthepackettothemobilehost’shomeagentbysendingthepacketwithboththeoriginaldestinationandtheencapsulateddestinationsettothemobilehost’shomeaddress.ThephilosophyofIMHPistoperformlazyup-datingoflocationcaches,sincecachedbindingsforamobilehostneednotbeupdateduntiltheyareused.Ifastalebindingisused,thepacketwillexperiencenon-optimalroutinguntilthestalebindingisupdated,butthenaturalactionofIMHPentitiescausesbind-ingstobeupdatedassoonaspossiblewhenevertheyareinuse.IfoneIMHPentitydiscoversthatanotherIMHPentitymightbeholdingincorrectinformationaboutthelocationofamobilehost,itshouldattempttocorrecttheotherIMHPentity.Theonlyexceptionstothisrulearethatamobilehostusuallyattemptstonotifyitspreviousforeignagentthatithasmoved,andamobilehostalwaystellsitshomeagentthatithasmoved.Forexample,ifanIMHPentityreceivesapacketthatneedstobetunneledtoamobilehost,itmaycon-cludethatthesource(thesourceoftunnelincaseoftunneledpackets)doesnothaveacorrectbindingforthedestinationmobilehost.TheIMHPentityshouldreturnanIMHPBindingNotifyprotocolpacketcon-tainingacurrentbindingtotheIMHPentitythathasthesuspectedincorrectbinding,asillustratedinFig- ,y, VI.A.MobileHosttoMobileHost Figure6illustratesthebasicoperationwhenamobilehost,MH1,withinrangeofaforeignagent,FA1,havingahomeagent,HA1,wantstocommuni-catewithanothermobilehost,MH2,withinrangeofaforeignagent,FA2,havingahomeagent,HA2.ThefollowingoperationsareshowninFigure6:1.MH1andMH2bothregisterwiththeirforeignagents(FA1andFA2,respectively)andnotifytheirhomeagents(HA1andHA2,respectively),oftheirnewbindings.2.SupposeMH1wantstosendapackettoMH2,andMH1doesnothaveabindingcachedforMH2.MH1transmitsthepacketrelyingonexistingroutingprotocols,usingFA1asitsdefaultrouter.ThepacketiseventuallyreceivedbyMH2’shomeagent,HA2,whichtunnelsthepackettoMH2’sforeignagent,FA2.WhenFA2receivesthetun-neledpacket,itdecapsulatesitanddel

iversitlocally.3.WhenHA2receivesandthentunnelsthepacket,italsosendstothesource(here,MH1)anIMHPBindingNotifypacketcontainingMH2’sbind-ing,asMH1seemsnottohaveabindingcachedforMH2.WhenMH1receivestheIMHPman-agementprotocolpacketcontainingthebindingforMH2,itmayneedtoauthenticatethebindingusingmethodsdescribedinSectionIV.4.AssumingMH1issatisedthatthereceivedbind-ingisgenuine,MH1cantransmitfuturepacketsforMH2bytunnelingthemdirectlytoMH2’scurrentforeignagent,FA2.Aclosetooptimumrouteisthusestablished.VI.B.MobileHostMovement Figure7extendstheexampleofFigure6toshowthemovementofMH2toanewlocation.Thefollow-ingoperationsareshowninFigure7:1.MH2detectsthatitisconnectedtoanewnetwork.Theregistrationprotocolisusedtoregisterwithanewforeignagent,FA3,andnotifyMH2’shomeagent,HA2.2.MH2’spreviousforeignagent,FA2,isalsoreli-ablynotiedofMH2’snewbinding.Thenoti-cationtoFA2mayincludeauthenticationinfor-mation. HA2 MH2 FA2 MH1 FA1 MH2 FA2 MH1 HA2 MH2 FA2 MH1 RegistrationRegistrationFigure6Mobilehosttomobilehostcommunication FA3 MH1 FA2 MH2 FA3 MH1 RegistrationBinding Notify1. MH2 FA3 3.4. HA2 FA3 Figure7Mobilehostmovement3.SupposeMH1wantstosendapackettoMH2.MH1tunnelsthepackettowhereitbelievesMH2islocatedatFA2.FA2forwardsthepackettoFA3,usingthebindingthatitreceivedintheno-ticationfromMH2’snewregistrationwithFA3.Finally,FA3decapsulatesthepacketanddeliversitlocallytoMH2.4.FA2recognizesthatMH1musthaveanoldbind-ingforMH2,sinceotherwiseMH1wouldnothavetunneledthepackettoFA2.FA2thussendsMH1aBindingNotifypacketnotifyingitofMH2’snewbindingatFA3.MH1mayneedtoauthenticatethisbindingbeforeusingit.5.Oncethenewbindingisauthenticated,futurepacketstoMH2aretunneleddirectlytoFA3.HA1isnotinvolvedinanyofthemessagesrelatedtothemovementofMH2andthesubsequentupdateofbindingsheldbyMH1.VI.C.StationaryHosttoMobileHost Figure8illustratesthecaseinwhichastationaryhost,SH,whichdoesnotimplementIMHP,wantstocommunicatewithamobilehost,MH,withinrangeofaforeignagent,FA,havingahomeagent,HA.ThefollowingoperationsareshowninFigure8:1.MHdetectsitisconnectedtoanewnetworkandusestheregistrationprotocoltoregisterwithanewforeignagent,FA,andtonotifyitshomeagent,HA.2.SupposeSHwantstosendapackettoMH.SinceSHdoesnotimplementIMHP,itdoesnothaveMH’slocationcached.SHthereforesendsthepackettoMHusingconventionalprotocols.ThepacketiseventuallyreceivedbyHA,whichtun-nelsittheMH’sknownlocation,FA.FAdecap-sulatesthepacketanddeliversitlocallytoMH. MH FA MH FA HA SH Figure8Stationaryhosttomobilehostcommunications InternetMobileHostProtocolProc INET94/JENC5Perkins Myles andJohnson 3.WhenHAreceivesthepacketfromSH,itsendsaBindingNotifytothesource,SH.SinceSHdoesnotimplementIMHP,HAmayeventuallysurm

isethattheBindingNotifypacketsitissendingtoSHarehavingnoeffect;HA’sbackoffalgorithmwillcauseitsendanewBindingNotifypackettoSHonlyinfrequently,notsendingoneatallformostnewpacketsitreceivesfromSHforMH.ThepacketsfromSHwillcontinuetofollowa“trianglerouting”path,whichislikelytobenon-optimum.VI.D.RoutingLoopResolution Suppose,perhapsbecauseofsomeincorrectim-plementationoftheprotocol,thattwoormorecacheagentshadlocationcacheentriesformingaloopforaparticularmobilehost.Considerthecaseofthreecacheagents(CA1,CA2,andCA3)thathavesuchbindingsintheirlocationcachesforamobilehost,MH.TheresolutionoftheloopisillustratedinFig-ure9.ThefollowingoperationsareshowninFigure9:1.IfCA1tunnelsapacketdestinedforMHtoCA2,CA2willtunnelthepackettoCA3.2.WhenCA3receivesthepacket,itwilltunnelthepacketonagaintoCA1.3.TheloopisbrokenbytheBindingNotifypacketsthataresenttothesourceofeachtunnel.CA2sendsaBindingNotifytoCA1,andCA3sendsaBindingNotifytoCA2.4.Finally,CA1sendsaBindingNotifytoCA3.EachforeignagentthatreceivesaBindingNo-tifypacketusesthelogicaltimestamptodecidewhetheritscurrentbindingisoutofdate.Ifso,theforeignagentreplacesthislocationcacheen-try,possiblyafterauthenticatingthenewbinding.VII.ExtensionsVII.A.Popups SomeareasoftheInternetmaynothaveIMHPfacilities,suchasforeignagents,availableforuse.Whenthissituationarises,amobilehostmayuseatechniquecalled[3]tomaintainconnectiv-ity.ThepopupmethodappliedtoIMHPrequiresthemobilehosttoacquireatemporarylocaladdressfromalocaladdressserver(forexample,aserverimple- CA1 CA2 2. CA1 CA1 CA3 CA2 CA3 Figure9RoutingloopresolutionmentingDHCP[2])andtothenreporttheallocatedaddresstoitshomeagentasitscare-ofaddress.Themobilehost,ineffect,actsasitsownforeignagent,usingthistemporaryaddress.Ifthehomeagentisallowedtodistributethisbind-ingtoothernodesinBindingNotifymessages,opti-malroutingofpacketstothemobilehostusingthistemporaryaddressispossible.However,whenthemobilehostsubsequentlymovestoanewnetwork,communicationtothemobilehostmightbelostforuptothetimeoutperiodonthelocationcacheentry.Thismovementofthemobilehostwouldappeartothecor-respondenthostsasacrashoftheforeignagent,sincenonodewouldthenberespondingtothistemporaryaddress.Thisproblemmaybesolvedbyinsteadnotdistributingthisnewbindingtonodesotherthanthemobilehost’shomeagent,butthiswouldrequireallpacketstothemobilehosttobeforwardedthroughthehomeagent,resultinginroutingthatislikelytobenon-optimal.Ineithercase,truemobilefunctionalitydependsontheabilityofthemobilehosttodetectautomaticallythatithasmoved.Withoutarealforeignagent,thismightbedifcult,ormightrequireuserintervention;onemethodthatmightbeusedwouldbetomonitorthesourceaddressofreceivedbroadcastpacketssuchasARPr

equests.VII.B.IntermediateCacheAgents Differenttypesofintermediateagentshavebeensuggestedbyanumberofproposals[12,5,7]asawayofoptimizingroutesbetweenstationaryhostsandmobilehosts.InIMHP,thefunctionalityofacacheagentmayalsobeimplementedinintermediateroutersnototh-erwisefunctioningashomeagents,foreignagents,ormobilehosts.WhensuchanintermediaterouterreceivesapacketfornormalIPforwarding,itcanin-steadthentunnelthepacketdirectlytotheforeignagentcurrentlyservingthedestinationmobilehost.IntermediateroutersservingascacheagentsdiscovernewbindingsbysnoopingonIMHPBindingNotifypacketsasitforwardsthem.VIII.SummaryandConclusionsWehaveproposedmechanismsusefulforenablingcomputerstomaintainnetworkconnectionsevenastheymoveaboutfromonelocationtoanother.ThemodelwehavedevelopedtsnaturallywithintheexistingInternetandallowsmobilehoststocommu-nicatewithexistingcomputingresourceswithoutre-quiringanychangestoexistingnodes.Wehavetrans-formedtheproblemofprovidingseamlessconnec-tivitytomobilehosts,intoaproblemofmaintainingdynamiclocationinformationforthemobilehostatthehomeagentandoptionallyatcacheagents.Byenablingnewhoststoalsocachebindingsformobilehosts,weprovidemechanismsforbetterroutingwhichbypassesthedefaultrelianceonroutes InternetMobileHostProtocolProc INET94/JENC5Perkins Myles andJohnson throughthehomeagent.Thus,asmorenewequip-mentisdeployedthatincorporatesthesetechniquesforavoiding“trianglerouting,”theroutinginefciencyassociatedwithmaintainingnetworkconnectionswithmobilehostswilldisappear.Thisnewfeature,whichisroughlyanalogoustothecurrentICMP“HostRedi-rect”message,requirescarefulauthentication,sinceotherwiseamalicioususermightissueanintention-allyincorrectbindinginordertodisruptorusurpadatastreamintendedforamobilehost.Theuserofthemobilehostneednotperformanyunusualproceduresoroperationstoachievetheben-etsofseamlessmobilitywhereverallowedbythephysicsofthenetworkmedium.Byprovidingmecha-nismsfordistributingthemobilehost’scare-ofaddressjusttotheplaceswhereitisinuse,IMHPeliminatesthelikelihoodthatthehomeagentwouldbeabottle-neckintheoperationofthehomenetwork.Schemesthatrelyonthehomeagentfortransmissionofev-erypacketdestinedtothemobilehostarelikelytoprovidepoorerperformance,presentextraloadtotheinterconnectednetworks,andoffertrafccharacteris-ticstiedtothevagariesoftheprocessingloadcarriedbythehomeagent.WehavetriedtotakegreatcaretomakesurethatthemaintenanceofthedistributedbindingsinIMHPlocationcachesissimple,effective,andreliable.AcknowledgmentsWegratefullyacknowledgetheinteractionswehavehadwithAlQuirt,KannanAlagoppan,andoth-ersintheIETFMobileIPWorkingGroupwhohavehelpedshapetheideaswithinthisproposal.References[1]R.BradenandJ.Pos

tel.RequirementsforInter-netGateways.RFC1388,June1987.[2]RalphDroms.DynamicHostCongurationPro-tocol.RFC1531,October1993.[3]J.Ioannidis,D.Duchamp,G.Maguire,andS.Deering.ProtocolsforMobileInternetwork-ing.InternetDraft,June1992.[4]JohnIoannidis,DanDuchamp,andGeraldQ.MaguireJr.IP-basedProtocolsforMobileInternetworking.InProceedingsoftheSIG-COMM’91Conference:CommunicationsAr-chitectures&Protocols,pages235–245,1991.[5]DavidB.Johnson.TransparentInternetRoutingforIPMobileHosts.InternetDraft,July1993.[6]DavidB.Johnson.ScalableandRobustInter-networkRoutingforMobileHosts.InProceed-ingsofthe14thInternationalConferenceonDis-tributedComputingSystems,June1994.[7]AndrewMylesandCharlesPerkins.MobileIP.InternetDraft,August1993.[8]C.PerkinsandY.Rekhter.SupportforMobilitywithConnectionlessNetworkLayerProtocols.InternetDraft,November1992.[9]J.Postel.InternetControlMessageProtocol.RFC792,September1981.[10]J.Postel.InternetProtocol.RFC791,September[11]F.Teraoka,KimClaffy,andM.Tokoro.Design,implementation,andevaluationofvirtualinter-netprotocol.InProceedingsofthe12thInter-nationalConferenceonDistributedComputingSystems,pages170–177,June1992.[12]FumioTeraoka.VIP:IPExtensionsforHostMi-grationTransparency.InternetDraft,July1992.[13]FumioTeraoka,YasuhikoYokote,andMarioTokoro.ANetworkArchitectureProvidingHostMigrationTransparency.InProceedingsoftheSIGCOMM’91Conference:Communica-tionsArchitectures&Protocols,pages209–220,September1991.AuthorInformationCharlesPerkinsreceivedtheB.A.degreeandtheM.E.E.degreefromRiceUniversity,andtheM.A.degreefromColumbiaUniversity.Since1984,hehasworkedforIBMonavarietyofprojectsrelatedtonetworks,multiprocessors,andmobilecomputing.HeisamemberofUSENIX,IEEE,andACM.AndrewMylesreceivedtheB.Sc.degreeinandtheB.E.(Electrical)degreewithFirstClassHon-oursandUniversityMedalin1986fromtheUniversityofSydney.From1987to1989heworkedatHewlettPackardLaboratoriesinBristol,UKbeforereturningtoAustralia.HeiscurrentlyworkingtowardsthePh.D.degreeatMacquarieUniversity,withaspecialinterestinMACandnetworklayerprotocolsforwire-lessandmobilenetworks.HeisamemberoftheIEEECommunicationsSociety.DavidJohnsonreceivedtheB.A.degreeincom-puterscienceandmathematicalsciencesin1982,andtheM.S.andPh.D.degreesincomputersciencein1985and1990,respectively,allfromRiceUniver-sity.HeiscurrentlyanAssistantProfessorofCom-puterScienceatCarnegieMellonUniversity,wherehehasbeensince1992.PriortojoiningthefacultyatCarnegieMellon,hewasaResearchScientistandLec-tureratRiceUniversityforthreeyears.Hisresearchinterestsincludenetworkprotocols,distributedsys-tems,andoperatingsystems.Dr.JohnsonisamemberoftheIEEEComputerSociety,IEEECommunicationsSociety,ACM,USENIX,andSi