Tải bản đầy đủ - 0 (trang)
Chapter 28. BOOTP and Dynamic Host Configuration Protocol (DHCP)

Chapter 28. BOOTP and Dynamic Host Configuration Protocol (DHCP)

Tải bản đầy đủ - 0trang

networks,bothareexaminedinthischapter.Mostmodern

DHCPservers,includingWindows2000and2003serversand

theUnix/Linuxfamilyofoperatingsystems,stillsupportBOOTP.







WhatIsBOOTP?

BOOTPstandsfortheBootstraporBOOTProtocol.Thestandard

methodforbootingacomputeristolocateabootblockona

localdriveandthengofromthere,sowhyarewediscussing

bootinginabookthatissupposedtobeaboutnetworks?

Duringthe1980s,BOOTPwasdevelopedtoallowdiskless

workstationstobootbydownloadingtheoperatingsystemfrom

anothernetworknode.Manyoperatingsystemsatthattime

usedthisprotocolbecauseitallowedtheuseofcheaper

desktopworkstationsonthenetworklongbeforePCsbecamea

standarddesktopitem.Atthetime,theX-Windowsworkstation

waspopularinUnixandOpenVMSnetworks.BOOTPwasan

economicalwaytoprovideanX-Windowsdesktopwithan

operatingsystemwithouttheneedtoequipthemachinewith

diskdrivesandotherdevicesnotnecessaryforasimpleclient.

OthertypesofnetworkclientsadoptedtheBOOTPprotocol,

allowingnetworkdevicestoalsobesuitablyconfiguredbyuse

oftheprotocol.



Note

TheBOOTPprotocolwasoriginallydefinedinRFC

951,"BootstrapProtocol,"in1985,andfurther

detailswereprovidedbyRFC1542,"Clarifications

andExtensionsfortheBootstrapProtocol,"in1993.

ThatRFCwasmadeobsoletebyseveralotherRFCs,

ofwhichthemostcurrentistheproposedstandard

ofthesamename(RFC2132).Anotherimportant

proposedstandardisRFC1534,"Interoperation

BetweenDHCPandBOOTP."



Downloadinganoperatingsystemisonlyoneofthefunctions

performedbyBOOTP.Inaddition,thedisklessworkstation(or

otherclient)canalsoobtainnetworkaddressinginformation.

Thisisbecausethelowest-levelBOOTPclientispresumedtobe

"diskless."IthasnomethodtostoreconfigurableIPaddressing

informationbetweenpowercycles.

TheBOOTPprotocolisnotcomplex.Indeed,itisasimple

protocolthatissmallandeasytoimplementinprogrammable

read-onlymemory(PROM)chips.Thefollowingaresome

importantfeaturesofBOOTP:

Asimplerequest/replymechanismisused.Thesame

packetformatisusedforbothrequestsandreplies.

TheUDPprotocolisusedtocarrymessages(ports67and

68,thesameasareusedbyDHCP).

Usingrelayagents,BOOTPexchangescanoccuracross

routers.

BOOTPcansupplytheclientwithanIPaddress,asubnet

mask,andadefaultgateway.ABOOTPservercanalsogive

theclientnameofatrivialFTPserver(TFTP)andafilename

thatcanbeusedtodownloadanoperatingsystem.This

TFTPserverisespeciallyimportantfordiskless

workstations,aswellasnetworkdevicesthatneedto

downloadanoperatingsystem.ThetrivialFTPserver,which

isastripped-downsimpleversionofFTP,iscoveredin

Chapter25,"BasicTCP/IPServicesandApplications."



Anotherprotocol,theReverseAddressResolutionProtocol(RARP),

operatesatthesecondlayeroftheOSInetworkmodelandisalso

capableofprovidinganIPaddresstoanothernodethatisbooting

onthenetwork.However,RARPisverylimited.Formore

informationaboutRARP,seeChapter24,"OverviewoftheTCP/IP

ProtocolSuite."



FormatoftheBOOTPPacket

Theclientandservershareacommonpacketformat.This

packetispassedtoUDP(theUserDatagramProtocol)and

encapsulatedinsideaUDPpacket.TheUDPandIPheadersare

added,andtheinformationisfinallypassedtotheDataLink

andPhysicallayersfortransmissiononthenetworkmedium.



TheIPandUDPprotocolsarealsodiscussedingreaterdetailin

Chapter24.



ThefieldsoftheBOOTPpacketareusedforthefollowing

purposes:

OpcodeThis1-bytefieldhasavalueofeitherzeroorone.

Ifsettoavalueofone,thepacketisarequestfromaclient

toaBOOTPserver(oraDHCPserver,asexplainedlater).If

thevalueiszero,thepacketisareplyfromaservertothe

client.

HardwareTypeValuesinthis1-bytefieldareusedto

designatedifferentkindsofhardware,differentcomputer

types,ornetworkdevicetypes,forexample.Avalueofone

inthisfieldindicatesthattheunderlyinghardwaretypeof

thenetworkis10MbEthernet,whereasthevalueof32is

usedfortheemergingtechnologyknownasInfiniBand.You

canfindthefulllistofvaluesatwww.iana.org/assignments/arpparameters.



HardwareAddressLengthThis1-bytefieldindicatesthe

numberofbytesthattheclienthardwareaddressfield

contains.ForEthernet,thisvalueissixbecauseittakes6

bytestorepresentthe48-bitMediaAccessControl(MAC)

addressusedbyEthernetnetworkcards.

HopCountThis1-bytefieldisalwayssettozerobythe

client,thoughtheBOOTPserverusesthisfieldwhen

relayingBOOTPrequestsacrossrouters.

TransactionIDThisisa4-bytefieldthatisaunique32-bit

integertheclientsetssothatitcanmatchuprepliesfrom

theservertotherequeststheclienthassent.

SecondsThis2-bytefieldisexpressedinsecondsandis

filledinbytheclientwithavalueindicatingthetimethat

haselapsedsincetheclientstartedthebootprocess.This

valuecanbeusedbysecondaryserverstorecognizethat

theclient'sprimaryserverisnotresponding.Inthatcase,a

secondaryBOOTPservercanmakeanattempttosatisfythe

request.

FlagsIntheoriginalspecificationsforBOOTP,this2-byte

fieldwasnotused.However,inRFC1542thisfieldwasset

asidetostoreflagbits.Onlyonehasbeendefinedsofar.

ThemostsignificantbitinthisfieldisusedasaBroadcast

flag.Theremainingbitsarenotyetdefinedandshouldbe

settozeros.

ClientIPAddress(ciaddr)Iftheclientalreadyknowsits

ownaddress(whichisexplainedshortly),itwillfillinthat

addressinthis4-bytefield.Inmostcasestheclientdoes

notknowitsownIPaddress(becausethat'soneofthe

mainthingsBOOTPisusedtosupplytotheclient),andin

caseslikethesethevalueforthisfieldshouldbezero.



YourIPAddress(yiaddr)ThisfieldisusedbytheBOOTP

servertosupplyanIPaddresstoaclientrequestingone.It

alsoisa4-bytefield,thenumberofbytesneededtostore

anIPaddress.Althoughtheclientcanfillintheciaddrfield

witharequestedaddress,thisfieldcontainstheaddressthe

DHCPserverreturnstotheclienttouse.

ServerIPAddress(siaddr)TheBOOTPserverfillsinthis

field,usuallyplacingitsownaddresshere.

GatewayIPAddress(giaddr)IfaBOOTPproxyserveris

beingused,theaddressinthis4-bytefieldistheaddressof

therouterorotherdeviceperformingtheproxyfunction.

ProxyBOOTPservicesarediscussedlaterinthischapter.

Notethatthisisnottheaddresstheclientshoulduseasa

defaultgatewayforTCP/IPconfiguration(thoughitcouldbe

thesame).ThisfieldisusedonlytorelayBOOTPrequests

acrossrouterstoandfromtheactualBOOTPserver.The

defaultgatewayinformationissuppliedinBOOTPoptions,

describedlaterinthischapter(seethesection"Enablingthe

DHCPRelayAgent").

Client'sHardwareAddress(chaddr)Iftheclientalready

knowsitsownIPaddress,itwillplacetheIPaddressinto

this4-bytefield.Theclientmustfillinthisrequiredfield

becausethetypicalBOOTPserverusesitinanindexof

valuesitkeepstrackofforitsclients.

ServerHostname(sname)Thisfieldcanbeupto64

bytesinlengthandcontainsanull-terminatedASCIIstring

ofcharactersthatrepresenttheserver'shostnameonthe

network.Thishostnamecanbeasimplehostnameorafully

qualifieddomainname(FQDN).Thisisanoptionalfield.

BootFilename(file)Thisfieldcanbeupto128

charactersinlengthandisusedtosupplytheclientwiththe



filenameitcandownloadandusetoboot.Thevaluehereis

alsoanull-terminatedstringandincludesthefullpaththe

clientneedsinordertolocatethefile.

Vendor-SpecificAreaThese64bytesaresetasideto

storevendor-specificoptionalinformation.Theitemsare

listedinTable29.1inthesection"BOOTPVendor-Specific

InformationOptions."Thefirstfouroctetsinthisfieldwill

bea"magiccookie."Thelastoctetisthe"End"tag,the

value255.

Theclient'shardwareaddress(technicallycalledtheMedia

AccessControladdress,orMACaddress)thatisplacedinthe

BOOTPpacketisthesamehardwareaddressthatwillbefound

intheEthernetframethatdeliversthepacket.However,after

theEthernetframeisreceived,thelower-levelheader

information(suchastheclient'shardwareaddress)isstripped

offbeforetheremainingpacketispassedupthroughtheIPand

UDPlayers.AtthepointwheretheBOOTPprotocolbeginsto

examinethepacket,theEthernetframeheaderinformationis

notavailableinmostTCP/IPstacks.Forthisreason,the

hardwareaddressisduplicatedinsidetheBOOTPpacket.

RememberthattheRARPprotocolisalink-layerprotocol,soit

canretrievetheclient'shardwareaddressfromtheEthernet

frame,somethingmostimplementationsofBOOTPcannotdo.



Note

Forthosewhoareinterestedinthenitty-gritty

details,thepacketsdiscussedherearetransmitted

onthewireintheordershowninthefiguresinthis

chapter.Additionally,theindividualbytesaresent

withtheleftmostbitbeingthemostsignificant.For

multi-octetvalues,themostsignificantoctetis

transmittedfirst.Thisinformationmighthelpyou

whendiagnosingproblemsonthenetworkusinga

LANanalyzerorothermethodstointerceptand



interpretnetworkpackets.



TheBOOTPRequest/ReplyMechanism

Becauseitisusuallyimplementedinaread-onlymemory

(ROM)chip,theBOOTPprotocolclientisasimple,concisebitof

code.TheexchangeofUDPmessagesbetweentheclientand

theBOOTPserverconsistsofaseriesofrequestsandreplies.

Thesamepacketformatisusedforbothtypesofmessages

withanOpcodefieldusedtoindicatewhetherthemessageisa

requestfromtheclientorareplyfromtheserver.

Thefollowingbasicstepsareinvolvedinobtaininginformation

fromaBOOTPserver:

1. Theclientsendsabroadcastmessageatthelink-layerlevel

becausetheclientatthispointisunawareofitsownIP

addressorthatofanyBOOTPserverthatmightbeonthe

network.IntheIPheaderinformationfortherequest,the

clientusuallysetsthesourceIPAddressfieldto0.0.0.0and

thedestinationaddressto255.255.255.255.Becausethisis

aUDPpacketbeingsentthroughIP,theclientsetsthe

destinationUDPportnumberto68(theBOOTPserverport)

sothatalisteningserverwillknowtointerceptthepacket.

TheTransactionIDfieldthattheclientplacesintheBOOTP

requestpacketisusedbyclientstosortoutwhichreplies

aremeantforthem.Thefirst4bytesofthevendor-specific

informationareashouldbesettoamagiccookie.



Note



AmagiccookieisamethodusedbyBOOTPtotell

theserverwhatkindofformattousewhencreating

areplyforaclient'srequest.Themagiccookie

usuallyisthevalue99.130.83.99butcanbea

vendor-suppliedvalue.Themagiccookieisusually

usedtoindicatethatthevendor-specificarea

containsinformationfortheservertoexamine.The

remaininginformationinthe64-bytevendor-specific

informationisdefinedasaseriesoftagsfollowedby

alengthfieldandthen,inmostcases,avariablelengthfieldofinformation.

2. Ifthebroadcastflagisset,theservernextbroadcastsa

replythatcontainstheclient'sIPaddress,theserver'sown

IPaddress,andotherrequestedinformation.

3. Ifthebroadcastflagisnotset,theservercansendaunicast

addressusingtheclient'sIPaddresstotheaddresssupplied

bytheclient.TheservershouldalwayschecktheClientIP

Address(fromClient)fieldsetbytheclienttobesureitis

notthedefaultvalueof0.0.0.0.Ifitisnot,then,depending

ontheimplementation,theserverwillsettheClientIP

Address(fromServer)fieldtothesamevalueandsenda

directed(unicast)packetbacktotheclient.However,note

thatthiscanvaryfromoneimplementationtothenext,and

theservermightdecidetooverridetheclient'srequestedIP

addressandsubstituteanother.

4. Anotherpossibilitythatoccurswhenusingarouterorother

hosttoactasaproxyrelayagentisthattheDefaultGatewayserverfieldwillbefilledin.Inthiscase,theserver

knowstousethisfieldtosendadirected(unicast)packetto

therouterorotherdevicethatisrelayingthemessage

insteadoftryingtobroadcastorsendthepacketdirectlyto

theclientusingtheclient'saddress.



Instep2,eventhoughtheclientmightbecapableof

determiningwhatitthinksitsownIPaddressshouldbeby

savingittoadiskfileinthecaseofaworkstationthatdoes

havethatcapability,forexampletheservercanchoosetoreturn

adifferentIPaddresstotheclient.Inthatcase,theclient

shouldstopusingitspreviousIPaddressandacceptthenew

onefromtheserver.Thereissomedisagreementinthe

literatureaboutthissituation,andyoumightfindthatitvaries

fromoneimplementationtoanother.Forexample,some

vendorsallowtheclienttospecifytheaddressitwantstouse,

ignoringtheonesuppliedbytheserver.Inthistypeof

situation,theclientisusuallyusingtheBOOTPservertoobtain

otherconfigurationinformation,suchasabootfilenameor

vendor-specificitems,whenitalreadyknowswhatitsownIP

addressshouldbe.



BOOTPVendor-SpecificInformationOptions

InadditiontosupplyinganetworknodewithanIPaddressand

abootfilename(andtheserverfromwhichthefilecanbe

retrieved),64bytesarereservedintheBOOTPReply/Request

packetthatcanbeusedtosupplyadditionalconfiguration

informationtotheclient.Theclientcanalsousetheoptions

fieldstorequestcertaininformationfromtheserver.

TheoptionsusedbyBOOTPareasubsetofthosenow

incorporatedintoDHCP.Thoselistedinthissectionapply,

therefore,tobothBOOTPandDHCP.Theseoptionsaredefined

(anddiscussedingreaterdetail)inRFC2132,"DHCPOptions

andBOOTPVendorExtensions."

Theformatfordataintheoptionsfieldisstandard:

OptionCodeThis1-bytefieldcontainsacodethat



identifiestheparticularoption.Thevalueof0isusedfor

paddingandthevalueof255isusedasanendmarker.

NotethatOptionCodevaluesfrom128to254arereserved

forsite-specificoptions.

LengthOctetThis1-bytevaluespecifiesthelengthofthe

optiondatatofollow.Thislengthdoesnotincludethe

OptionCodeortheLengthOctets.

Variable-lengthoptionalconfigurationdataThisdata

dependsonwhatkindofinformationtheoptionsupplies.

Asnotedearlier,thevalueof255markstheendofanoptions

listinthepacket.

RFC2132definesalargenumberofoptionsthatcanbeused.

Table28.1liststhosethatapplytobothBOOTPandDHCP.

Table28.1.DefinitionofBOOTPVendorExtension

Opcodes

Opcode Name



Description



0



Pad



Usedtoalignfollowingentriesonaword

boundary.



255



End



Marksendofoptions.



1



SubnetMask Subnetmaskforclienttouse.



2



TimeOffset



UTCtimeoffsetvalue.



3



Router



ListofIPaddressofroutersontheclient's

subnet.



4



TimeServer



Listoftimeservers.



5



NameServer ListofIEN116nameservers.



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 28. BOOTP and Dynamic Host Configuration Protocol (DHCP)

Tải bản đầy đủ ngay(0 tr)

×