UNIVERZITET U TRAVNIKU

FAKULTET ZA TEHNIČKE STUDIJE

INŽINJERSKA INFORMATIKA

DHCP
SEMINARSKI RAD

Kandidat: Mentor:

AĐ Ime i prezime

Travnik, maj 2018. godine

SADRŽAJ

SAŽETAK....................................................................................................................1
UVOD...........................................................................................................................2
1. NASTANAK DHCP SERVISA........................................................................3
1.1. BOOTP PROTOKOL..................................................................................3
1.1.1. Format paketa.............................................................................................4
1.2. OPĆENITO O DHCP PROTOKOLU........................................................5
1.3. DIZAJNERSKI CILJEVI DHCP-A...........................................................7
2. PRINCIP RADA DHCP SERVISA.................................................................8
2.1. FORMAT DHCP PAKETA........................................................................8
2.2. POHRANA KONFIGURACIJSKIH PARAMETARA............................11
2.3. DINAMICKA DODJELA MREŽNIH ADRESA....................................12
2.4. KLIJENT – POSLUŽITELJ PROTOKOL..............................................13
2.4.1. Klijent – poslužitelj komunikacija: dodjela mrežnih adresa................13
2.4.2. Klijent – poslužitelj komunikacija: ponovno korištenje prethodno.....17
dodijeljene mrežne adrese..................................................................................17
2.4.3. Interpretacija vremenskih vrijednosti...................................................19
2.4.4. Dobivanje parametara sa rucno postavljenom mrežnom adresom.....19
2.4.5. DHCP parametri klijenta......................................................................20
2.4.6. Korištenje DHCP-a na klijentima sa više mrežnih kartica..................21
2.4.7. Klijenti: kada koristiti DHCP................................................................21
2.5. SPECIFIKACIJE DHCP KLIJENT – POSLUŽITELJ PROTOKOLA 21
2.5.1. Administrativne kontrole DHCP poslužitelja.......................................23
2.5.2. Ponašanje DHCP poslužitelja...............................................................24
2.5.3. Ponašanje DHCP klijenta.....................................................................27
3. ZAKLJUČAK..................................................................................................31
4. LITERATURA................................................................................................33
 SAŽETAK
Tema rada je DHCP servis (eng.: Dynamic Host Configuration Protocol), tačnije
opis servisa i njegove značajke. Svaki uređaj na mreži mora imati jedinstvenu IP adresu.
Uređaj može biti poslužitelj, računalo, usmjerivač, prespojnik. IP adrese se mogu
dodjeljivati statički i dinamički. Pri statičkom dodjeljivanju adresa uređaju se postavlja
fiksna adresa koja je nepromjenjiva tokom vremena. Ukoliko se ukaže potreba, adresa se
može ručno promijeniti. Statičko dodjeljivanje adresa se koristi za uređaje kao što su
poslužitelji domene, web poslužitelji, pisači. IP adrese se mogu dodjeljivati i dinamički,
pomoću DHCP protokola. Protokol DHCP omogućava da uređaji prilikom inicijalizacije
automatski dobivaju adrese od DHCP poslužitelja. Dinamičko dodjeljivanje adresa
omogućava efikasniju raspodjelu adresnog prostora i smanjuje vjerojatnost da dva
uređaja dobiju istu IP adresu. Prednosti protokola DHCP vjerojatno se najviše očituju
prilikom administriranja mreže. DHCP znatno olakšava konfiguriranje IP adresa na
klijentima - nije potrebno konfigurirati svaki klijent pojedinačno, jer se sve promjene
obavljaju na centralnom DHCP poslužitelju. Ova prednost naročito dolazi do izražaja u
mrežama s velikim brojem računala. Umjesto da se ručno mijenjaju svojstva mreže na
nekoliko stotina računala, dovoljno je da se na DHCP poslužitelju napravi potrebna
izmjena. DHCP se često koristi prilikom spajanja na internet a da se na to niti ne obraća
pozornost. Pri povezivanju sve većeg broja računala na internet putem ADSL i
kablovske tehnologije koriste ste raznoliki usmjerivači. Oni se, uz poznavanje tematike,
jednostavno konfiguriraju kao DHCP poslužitelji te time pojednostavljuju spajanje na
internet do popularne fraze „plug and play“. DHCP poslužitelj računalu (klijentu)
dodjeljuje parametre (IP adresu, mrežnu masku, osnovni usmjernik, itd.). Time
omogućava direktan pristup internet stranicama, bez nepotrebnog pokretanja konekcije,
unošenja korisničkih imena i lozinki, spajanja itd.

1
 UVOD
U prvom dijelu ovoga rada upoznat ćemo se sa povijesti DHCP protokola, koja
uključuje dio o prethodniku DHCP protokola - BOOTP (eng.: BOOTstrap Protocol)
protokolu te RFC (eng.: Request For Comment) dokumentaciju koja detaljno opisiva
DHCP servis. Obrađeni su i dizajnerski ciljevi DHCP-a. U drugom dijelu ovog rada
upoznat ćemo se sa principom rada DHCP servisa. Tu je detaljno opisan izgled DHCP
poruke, koji uključuje i opis polja DHCP paketa. Definirana je komunikacija
izmeđuDHCP klijenta i poslužitelja te proces u kojem klijent dobiva konfiguracijske
parametre od poslužitelja. Detaljno su opisane vrste poruka koje se koriste u DHCP
komunikaciji i njihova namjena.

2
 1. NASTANAK DHCP SERVISA
DHCP je klijent/poslužitelj protokol koji omogućuje klijentu automatsko
pribavljanje IP adrese i ostalih relevantnih mrežnih konfiguracijskih postavki kao što su
mrežna maska i osnovni usmjernik. RFC 2131 i RFC 2132 definiraju DHCP kao IETF
(eng.: Internet Engineering Task Force) standard baziran na BOOTP protokolu, sa
kojim dijeli mnogo izvedbenih detalja.

1.1. BOOTP PROTOKOL

BOOTP protokol je standardiziran RFC 951 dokumentom u 11. mjesecu 1985.
godine. Baziran je na klijent-poslužitelj razmjeni poruka. Implementiran je na višem
sloju i koristi UDP za transport poruka. Uvedena je nova mogućnost koja je potakla
širenja računala bez tvrdog diska. Kratko nakon što se uključi takvo računalo automatski
dobiva svoju IP adresu, adresu poslužitelja i ime datoteke koju je potrebno učitati u
radnu memoriju i izvršiti. Operacija uključivanja se sastoji od dvije faze. Ovdje je
opisana prva faza, koja se naziva određivanje adrese i odabir datoteke za pokretanje.
Druga faza, koja se odvija nakon što je pribavljena IP adresa i ime datoteke, sastoji se od
prebacivanja datoteke u radnu memoriju.
Kratke smjernice protokola:
1. Razmjenjuje se jedan paket. Dobiveno vremensko ograničenje se koristi za
ponovno slanje dok se ne primi odgovor. Koristi se isti format polja paketa u oba smjera
komunikacije i maksimalna razumna duljina polja u cilju pojednostavljena definicije
strukture i sintakse.
2. Klijent emitira bootrequest paket koji sadrži fizičku (MAC) adresu mrežne
karticeklijenta. Na to poslužitelj odgovara bootreply paketom.
3. Zahtjev može sadržavati i ime poslužitelja od kojeg klijent želi odgovor. Na taj
način klijent se može pokrenuti s tačno određenog poslužitelja. Klijent ne mora voditi
računa o imenima i domenskim servisima. Tu funkciju obavlja BOOTP poslužitelj.
4. Zahtjev može sadržavati i ime datoteke koja se koristi za pokretanje klijenta.
Kada poslužitelj pošalje bootreply paket, upotpunjuje polje koje sadrži ime datoteke sa
potpuno kvalificiranim domenskim imenom za navedeno ime datoteke. U utvrđivanju
ovog imena poslužitelj se koristi svojom bazom koja sadrži adrese i imena klijenata, sa
3
tačno određenom datotekom sa pokretanje navedenog klijenta. Ako je polje koje sadrži
ime datoteke u bootrequest paketu prazno, poslužitelj vraća polje s podrazumijevanim
imenom datoteke za tog klijenta.
5. Za klijente koji ne znaju svoje IP adrese, poslužitelj mora imati bazu koja
sadrži MAC adresa i odgovarajucih IP adresa. Ova IP adresa klijenta se stavlja u polje
bootreply paketa.
6. Određene mrežne topologije mogu biti takve da dani fizički vod nema FTP
poslužitelj spojen direktno na njega. U suradnji sa susjednim usmjerivačima, BOOTP
može omogućiti klijentima da se pokrenu s poslužitelja koji su udaljeni više skokova.
Ovaj dio protokola ne zahtijeva nikakve dodatne akcije od strane klijenta. Primjena je
neobavezna i zahtijeva malo dodatnih instrukcija u usmjerivačima i poslužiteljima.

1.1.1. Format paketa

BOOTP paket je sadržan unutar IP UDP datagrama. U IP zaglavlju bootrequest
paketa klijent, ukoliko je poznata, stavlja svoju adresu kao izvorišnu, a inače stavlja 0.
Kada je adresa poslužitelja nepoznata, odredišna adresa je broadcast adresa
255.255.255.255. Ova adresa znači “odašalji na lokalnom vodu”. UDP zaglavlje sadrži
izvorišne i odredišne priključne tačke. BOOTP protokol koristi dvije rezervirane
priključne tačke, BOOTP klijent – 68 i BOOTP poslužitelj – 67. Klijent šalje zahtjev
koristeći BOOTP poslužitelj kao odredišnu priključnu tačku; ovo se obično emitira.
Poslužitelj odgovara koristeći priključnu tačku 68 kao odredišnu priključnu tačku.
Odgovor bootreply na zahtjev bootrequest može i ne mora biti emitiran. Budući da
poslužitelj i ostali klijenti neće slušati BOOTP klijent priključnu tačku svaki takav
dolazeći emitirani paket će biti filtriran na sloju kernela – jezgre upravljačkog sustava.
Ne može se jednostavno dozvoliti klijentu da izabere proizvoljni broj priključne tačke za
UDP izvorišnu priključnu tačku, jer odgovor poslužitelja na zahtjev može biti emitiran, i
proizvoljno odabran broj priključne tačke može zbuniti ostale klijente koji slušaju na toj
prikljucnoj točci. Duljina UDP polja je postavljena na duljinu UDP plus BOOTP porciju
paketa. UDP checksum polje može biti postavljeno na nulu od strane klijenta (ili
poslužitelja) da bi se izbjeglo prekoračenje u implementaciji PROM-a.

4
 Tablica 1. Opis i velicina polja BOOTP poruke

1.2. OPĆENITO O DHCP PROTOKOLU

DHCP stvara platformu za prenošenje konfiguracijskih informacija ka klijentima
na TCP/IP mrežama. Baziran je na BOOTP protokolu, na koji dodaje mogućnosti poput
automatske alokacije mrežnih adresa koje se mogu ponovno koristiti i mnogih drugih
dodatnih konfiguracijskih opcija. DHCP prati ponašanje BOOTP prijenosnih agenata
tako da korisnici DHCP usluga mogu istovremeno koegzistirati sa korisnicima BOOTP
usluga. DHCP pruža konfiguracijske parametre klijentima. Sastoji se od dviju
komponenti:
 Protokola za prosljeđivanje konfiguracijskih parametara klijentima
 Mehanizma za alokaciju mrežnih adresa klijentima

5
 DHCP je sagrađen na principu klijent-poslužitelj, gdje određeni DHCP poslužitelj
dodjeljuje mrežne adrese i šalje konfiguracijske parametre dinamicki konfigurabilnim
klijentima. DHCP podržava tri načina dodjele IP adresa:
 Kod automatske dodjele (eng.: automatic allocation) DHCP dodjeljuje stalnu IP
adresu klijentu.
 Kod dinamicke dodjele (eng.: dynamic allocation), DHCP dodjeljuje IP adresu
klijentu na odre_eno vrijeme (ili dok klijent izricito ne vrati adresu).
 Kod rucne dodjele (eng.: manual allocation), klijentu IP adresu dodjeljuje
mrežni administrator, a DHCP se koristi za prijenos te adrese klijentu.
Određena mreža može koristiti jednu ili više ovih metoda.
Od nabrojenih metoda, jedino dinamicka dodjela omogucava automatsko ponovno
korištenje adrese koja je dodijeljena klijentu i više mu nije potrebna. Stoga, dinamicka
dodjela je posebno korisna za dodjelu adresa klijentima koji ce privremeno biti povezani
na mrežu, ili za dijeljenje ogranicenog broja IP adresa u grupi klijenata koji ne trebaju
stalnu IP adresu. Dinamicka dodjela tako_er može biti dobar izbor za dodjelu IP adresa
novim klijentima koji su stalno povezani na mrežu, gdje je dodijeljena IP adresa ona
adresa koju je koristio klijent koji je npr. maknut sa mreže. Rucna DHCP dodjela IP
adresa uklanja rucno konfiguriranje računala s IP adresama (sklono greškama) u okolini
gdje je, iz bilo kojeg razloga, poželjno upravljanje IP adresama ne koristeći DHCP
mehanizam. Izgled DHCP paketa se temelji na izgledu BOOTP paketa, zbog pracenja
ponašanja BOOTP prijenosnog agenta i da bi se dozvolila koegzistencija postojecih
BOOTP klijenata s DHCP poslužiteljima. Korištenje BOOTP prijenosnog agenta
uklanja potrebu postojanja DHCP poslužitelja na svakom fizickom mrežnom segmentu.
Postoji nekoliko Internet protokola i s njim povezanih mehanizama koji rješavaju
neke probleme dinamicke konfiguracije klijenata. RARP protokol (eng.: Reverse
Address Resolution Protocol) iskljucivo rješava problem otkrivanja mrežnih adresa, i
uključuje mehanizam za automatsku dodjelu adresa. TFTP protokol (eng.: Trivial File
Transfer Protocol) služi za prijenos datoteka za pokretanje s poslužitelja na kojem se
iste nalaze. ICMP protokol (eng.: Internet Control Mesage Protocol) se koristi za
obavještavanje klijenata o dodatnim usmjerivačima, te se tako_er koristi za informacije
o mrežnoj maski kroz ICMP poruku zahtjev mrežne maske.

6
 DHCP je dizajniran da pruža DHCP klijentima konfiguracijske parametre definirane
u RFC dokumentu zahtjevi klijenta (eng.: Host Requirements RFC). Nakon prikupljanja
parametara preko DHCP-a, klijent mora biti u mogućnosti izmjenjivati pakete s bilo
kojim drugimračunalom na Internetu. U iducim poglavljima se nalazi popis svih
parametara trenutno podržanih od strane DHCP-a. Svi ti parametri se ne trebaju
konfigurirati. Klijent i poslužitelj mogu dogovoriti prijenos samo onih parametara koje
zahtjeva klijent ili onih koji su specificni za odre_enu podmrežu. DHCP ne zahtjeva, ali
dozvoljava konfiguriranje klijentskih parametara koji nisu u izravnoj vezi s IP
protokolom. DHCP nije namijenjen za konfiguriranje usmjerivaca.

1.3. DIZAJNERSKI CILJEVI DHCP-A

Popis glavnih ciljeva prilikom dizajna DHCP-a:
- DHCP treba biti samo alat u ostvarenju cilja. On mora dozvoljavati lokalnom sistem
administratoru kontrolu nad konfiguracijskim parametrima.
- Klijenti ne bi smjeli zahtijevati rucnu konfiguraciju. Svaki klijent mora pronaci
odgovarajuce konfiguracijske parametre bez akcije korisnika, te ih ukomponirati u
vlastitu konfiguraciju.
- Mreža ne treba zahtijevati nikakvu rucnu konfiguraciju za pojedinacnog klijenta. U
normalnim okolnostima, mrežni administrator ne bi trebao unijeti nijednu klijentsku
konfiguracijsku opciju.
- DHCP ne treba zahtijevati poslužitelja na svakoj podmreži. Da bi se povecala
ekonomicnost i skalabilnost, DHCP mora raditi preko usmjerivaca ili preko BOOTP
prijenosnog agenta.
- DHCP klijent mora biti spreman primiti više odgovora na zahtjev konfiguracijskih
parametara. Neke mreže mogu uključivati višestruke, preklapajuce DHCP poslužitelje s
ciljem da se poveca pouzdanost i kvaliteta.
- DHCP mora koegzistirati sa staticki konfiguriranim računalima i u postojecim
implementacijama mrežnih protokola.
- DHCP mora pravilno raditi s BOOTP prijenosnim agentima.
- DHCP mora pružati usluge postojecim BOOTP klijentima.
Popis ciljeva koji su postavljeni za prijenos parametara mrežnog sloja. DHCP mora:

7
 - Osigurati da se, u isto vrijeme, odre_ena mrežna adresa neće koristiti na više od
jednom DHCP klijentu.
- Sacuvati DHCP konfiguraciju klijenta nakon ponovnog pokretanja. DHCP klijent bi
trebao, kad je god to moguce, dobiti iste konfiguracijske parametre kao odgovor na svaki
zahtjev.
- Sacuvati DHCP konfiguraciju klijenta nakon ponovnog pokretanja poslužitelja, i
kad god je to moguce, DHCP klijentu treba dodijeliti iste konfiguracijske parametre bez
obzira na ponovno pokretanje DHCP mehanizma.
- Dozvoliti automatsko dodjeljivanje konfiguracijskih parametara novim klijentima i
izbjeci rucnu konfiguraciju novih klijenata.
- Podržavati unaprijed odre_ene ili stalne konfiguracijske parametre za odre_ene
klijente.

2. PRINCIP RADA DHCP SERVISA

DHCP je proširenje BOOTP mehanizmu, gledano sa stajališta klijenta. Ovo
stvara pogodnost koja omogucava postojecim BOOTP klijentima da rade s DHCP
poslužiteljima bez potrebe za pravljenjem ikakvih promjena u softveru klijenta.

2.1. FORMAT DHCP PAKETA

Postoje dvije glavne razlike između DHCP-a i BOOTP-a. Prvo, DHCP definira
mehanizam kojim se klijentima mogu dodijeliti mrežne adrese na odre_eno konacno
vrijeme, omogucavajuci dodjeljivanje adrese razlicitim klijentima u razlicitom vremenu.
Drugo, DHCP pruža mehanizam koji omogucava klijentu da zatraži sve IP
konfiguracijske parametre koje mu trebaju za rad. DHCP uključuje i malu promjenu u
terminologiji koja pojašnjava znacenje jednog od polja. Ono što je bilo polje ekstenzije
proizvo_aca (eng.: vendor extensions) u BOOTP-u je preimenovano u polje opcije
(eng.: options) u DHCP-u. Slicno tome su oznacene stavke podataka korištene u
BOOTP polju ekstenzije proizvo_aca, sada su jednostavno nazvane opcije. Slika 1. nam
prikazuje format DHCP poruke a tablica 2. opisuje svako od polja u DHCP poruci.
Brojevi prikazuju velicinu svakog polja u bajtovima.

8
Slika 1. Format DHCP poruke

9
 Tablica 2. Opis i velicina polja DHCP poruke
DHCP odre_uje novu opciju oznaka klijenta (eng.: client identifier) koja se koristi za
prijenos jednoznacne oznake klijenta prema DHCP poslužitelju. Ova promjena uklanja
korištenje ‘chaddr’ polja u BOOTP porukama gdje se ‘chaddr’ polje koristilo i kao
fizicka adresa i za prepoznavanje klijenta. Oznaka klijenta se ne obra_uje od strane
poslužitelja. Npr. ona može sadržavati fizičku adresu, isto kao i ‘chaddr’ polje, ili može
sadržavati bilo koji drugi oblik prepoznavanja, kao npr. DNS ime. Oznaka klijenta
odabrana od DHCP klijenta mora biti jedinstvena za tog klijenta na podmreži na koju je
klijent spojen. Ako klijent koristi oznaku klijenta u jednoj poruci, on mora istu
jednoznacnu oznaku koristiti i u svim sljedecim porukama, da bi ga svi poslužitelji
pravilno raspoznali. DHCP objašnjava interpretaciju ‘siaddr’ kao adresu poslužitelja
koju treba koristiti u iducem koraku klijentovog bootstrap procesa. DHCP poslužitelj
može vratiti svoju IP adresu u‘siaddr’ polju ako je poslužitelj spreman da pruži sljedece
bootstrap usluge (npr. Slanje izvršne datoteke operativnog sustava). DHCP poslužitelj
uvijek vraća vlastitu adresu u opciji oznaka poslužitelja (eng.: server identifier). Polje
10
opcije ima varijabilnu dužinu. DHCP klijent mora biti spreman primiti DHCP poruku sa
poljem opcije velicine najmanje 312 okteta. Ovaj zahtjev znači da DHCP klijent mora
biti spreman primiti poruke od 576 okteta što je minimalna velicina IP datagrama.
DHCP klijenti mogu dogovoriti korištenje vecih DHCP poruka kroz opciju maksimalna
velicina DHCP poruke (eng.: maximum DHCP message size). Opcijsko polje se može
još proširiti u polje datoteke (eng.: file) i polje opcijskog imena poslužitelja (eng.:
sname) polja. U slucaju kad klijent koristi DHCP za pocetnu konfiguraciju, DHCP
zahtjeva kreativno korištenje TCP/IP softvera klijenta. TCP/IP softver bi trebao primiti i
proslijediti IP sloju sve IP pakete dostavljene fizickoj adresi klijenta prije nego je IP
adresa konfigurirana; DHCP poslužitelj i BOOTP prijenosni agent ne mogu isporuciti
DHCP poruku klijentu koji ne može prihvatiti jednoznacno poslani fizički datagram
prije nego je TCP/IP konfiguriran. Da bi DHCP radio s klijentima koji ne mogu
prihvatiti jednoznacno poslane IP datagrame, prije nego li je TCP/IP softver
konfiguriran, DHCP koristi polje zastave (eng.: flags). Prvi bit je odre_en kao
BROADCAST (B) zastava. Znacenje ove zastave je kasnije opisano. Ostali bitovi ove
zastave su rezervirani za buducu upotrebu. Oni moraju biti postavljeni na nulu od strane
klijenta i ignorirani od strane poslužitelja i prijenosnog agenta.

B: BROADCAST zastava
Slika 2. Format polja zastave

2.2. POHRANA KONFIGURACIJSKIH PARAMETARA

Osnovni servis koji DHCP pruža je stalna pohrana mrežnih parametara za
mrežne klijente. Model DHCP stalne pohrane se temelji na tome da DHCP servis cuva
kljucnu vrijednost za svakog klijenta, gdje je kljuc neka jednoznacna oznaka a vrijednost
sadrži konfiguracijske parametre za tog klijenta. Npr. kljuc može biti par (IP mrežna
maska, fizicka adresa) koji dozvoljava korištenje fizicke adrese na drugoj podmreži, i da
11
fizicka adresa nije globalno jedinstvena. Alternativno, kljuc može biti par (IP mrežna
maska, ime računala) dozvoljavajuci poslužitelju inteligentnu dodjelu parametara DHCP
klijentu koji se premjestio na drugu podmrežu ili je promijenio fizičku adresu
(promijenjena mrežna kartica). Protokol odre_uje da je kljuc (IP mrežna maska, fizicka
adresa), osim ako je klijent izricito tražio drugacije, koristeći opciju oznaka klijenta.
Klijent može poslati upit DHCP poslužitelju tako da primi svoje konfiguracijske
parametre. Klijentsko sucelje, za prikupljanje konfiguracijskih parametara, se sastoji od
poruke za zahtjev konfiguracijskih parametara i odgovora od poslužitelja koji nosi
konfiguracijske parametre.

2.3. DINAMICKA DODJELA MREŽNIH ADRESA

Drugi servis koji DHCP pruža je dodjela privremenih ili stalnih IP adresa
klijentima. Osnovni mehanizam za dinamicku dodjelu mrežnih adresa je jednostavan:
klijent zatraži korištenje adrese na odre_eni vremenski period. Dodjeljujuci mehanizam
(skup DHCP poslužitelja) osigurava da neće dodijeliti tu adresu u zatraženom vremenu i
pokušava vratiti uvijek istu adresu, svaki put kad klijent zatraži adresu. Vrijeme unutar
kojeg je neka adresa dodijeljena određenom računalu se naziva vrijeme posudbe (eng.:
lease time). Klijent može produžiti svoje vrijeme posudbe sa podzahtjevima. Tako_er,
klijent može poslati i poruku povratka adrese poslužitelju, kad mu ona više nije
potrebna. Klijent može zatražiti i stalnu dodjelu na način da zatraži beskonacno vrijeme
posudbe. Cak i kad dodjeljuje ‘stalnu’ adresu, poslužitelj može izabrati da dodjeli
dugorocnu, ali ne i beskonacnu, da bi omogucio otkrivanje cinjenice da klijent više ne
postoji. U nekim okolinama bit ce neophodno ponovno dodjeljivanje vec korištenih
mrežnih adresa, zbog potrošenosti slobodnih adresa. U tim slucajevima mehanizmom ce
se ponovo dodjeljivati adrese kojima je vrijeme posudbe isteklo. Poslužitelj treba
iskoristiti sve dostupne informacije u spremniku konfiguracijskih informacija, da bi
izabrao koju ce adresu ponovo upotrijebiti. Npr. poslužitelj može izabrati posljednju
dodijeljenu adresu. Kao sigurnosnu provjeru, poslužitelj bi trebao testirati ponovno
dodjeljivanu adresu prije nego je stvarno i dodjeli, npr. sa ICMP povratnim zahtjevom
(cesto se umjesto navedenog koristi izraz ping), a i klijent bi trebao testirati novo

12
primljenu adresu, npr. sa protokolom za rezoluciju adrese ARP (eng. Address Resolution
Protocol).

2.4. KLIJENT – POSLUŽITELJ PROTOKOL

DHCP koristi BOOTP format poruke koji je prikazan u tablici 1. ‘op’ polje svake
DHCP poruke poslane od klijenta prema poslužitelju sadrži BOOTREQUEST.
BOOTREPLY se koristi u ‘op’ polju za svaku DHCP poruku poslanu od poslužitelja
prema klijentu. Dosad je definirano nekoliko opcija. Jedna odre_ena opcija mora biti
ukljucena u svaku DHCP poruku. Ona definira tip DHCP poruke (eng.: DHCP message
type). Dodatne opcije mogu biti dozvoljene, zahtijevane ili zabranjene, u ovisnosti o tipu
DHCP poruke. Kroz ovaj rad, za DHCP poruke koje sadrže opciju tip DHCP poruke ce
se koristiti naziv s obzirom na tip poruke, npr. za DHCP poruku sa tipom DHCP poruke
1 ce se koristiti naziv DHCPDISCOVER poruka.

2.4.1. Klijent – poslužitelj komunikacija: dodjela mrežnih adresa

Sljedeci sažetak komunikacije izmeđuklijenta i poslužitelja se odnosi na DHCP
poruke opisane u tablici 3. Vremenski dijagram u slici 3. prikazuje vremensku ovisnost u
tipicnoj klijent-poslužitelj komunikaciji. Ako klijent vec zna svoju adresu neki koraci se
mogu
preskociti.
1. Klijent emitira DHCPDISCOVER poruku na svojoj lokalnoj fizickoj
podmreži. DHCPDISCOVER poruka može sadržavati opcije koje predlažu vrijednosti
za mrežnu adresu i vrijeme posudbe. BOOTP prijenosni agenti mogu proslijediti poruku
do DHCP poslužitelja koji nisu na istoj fizickoj podmreži.
2. Svaki poslužitelj može odgovoriti sa DHCPOFFER porukom koja uključuje
dostupnu mrežnu adresu u ‘yiaddr’ polju (i druge konfiguracijske parametre u DHCP
opcijama). Poslužitelj ne treba rezervirati ponu_enu mrežnu adresu, iako ce protokol
raditi ucinkovitije ako poslužitelj izbjegne dodjelu ponu_ene mrežne adrese drugom
klijentu. Kad dodjeljuje novu adresu, poslužitelj bi trebao provjeriti da li je ponu_ena
mrežna adresa vec u upotrebi šaljuci ICMP povratni zahtjev. Poslužitelji bi trebali biti

13
implementirani na način da mrežnim administratorima dozvole iskljucivanje provjere
ponu_ene adrese. Nakon toga poslužitelj šalje DHCPOFFER poruku klijentu, koristeći i
BOOTP prijenosne agente ako je potrebno.

Tablica 3. Popis DHCP poruka

14
 Slika 3. Vremenski dijagram poruka izmijenjenih izmeđuDHCP klijenta i poslužitelja
kad se radi dodjela nove mrežne adrese
3. Klijent primi jednu ili više DHCPOFFER poruka od jednog ili više
poslužitelja. Može se izabrati da ceka više odgovora. Na temelju te poruke klijent izabire
jedan poslužitelj od kojeg zatraži konfiguracijske parametre. Klijent emitira
DHCPREQUEST poruku koja mora uključivati oznaku poslužitelja da bi naznačio koji
poslužitelj je izabrao, i ta poruka može uključivati ostale opcije posebno odre_ujuci
konfiguracijske vrijednosti. Opcija zatražena IP adresa (eng.: Requested IP address)
mora biti postavljena na vrijednost ‘yiaddr’ iz DHCPOFFER poruke od poslužitelja.
Ova DHCPREQUEST poruka je emitirana i prenesena preko DHCP/BOOTP
prijenosnog agenata. Da bi se osiguralo da ce svaki BOOTP prijenosni agent proslijediti
DHCPREQUEST poruku istom skupu DHCP poslužitelja koji su primili i originalnu
DHCPDISCOVER poruku, DHCPREQUEST poruka mora koristiti istu vrijednost u

15
DHCP zaglavlju ‘secs’ polju i biti poslana na istu IP adresu za emitiranje kao i izvorna
DHCPDISCOVER poruka. Ako klijent ne primi nijednu DHCPOFFER poruku, on
ponovo pošalje DHCPDISCOVER poruku.
4. Poslužitelji prime DHCPREQUEST poruku emitiranu sa klijenta. Oni
poslužitelji koji nisu izabrani s DHCPREQUEST porukom koriste poruku kao obavijest
da je klijent odbio ponudu poslužitelja. Poslužitelj izabran DHCPREQUEST porukom
zapocinje uskla_ivanje s klijentom uz pomoc DHCPACK poruke koja sadrži
konfiguracijske parametre. Kombinacija oznake ili ‘chaddr’ i dodijeljene mrežne adrese
sacinjava jednoznacnu oznaku koja se koristi od strane klijenta i od strane poslužitelja,
da bi se prepoznalo na koju se posudbu DHCP poruka odnosi. Svi konfiguracijski
parametri u DHCPACK poruci bi trebali biti isti kao oni u prijašnjoj DHCPOFFER
poruci na koju je klijent odgovorio. Poslužitelj ne bi trebao provjeravati ponu_enu
mrežnu adresu u ovom trenutku. ‘Yiaddr’ polje u DHCPACK poruci je popunjeno sa
izabranom mrežnom adresom. Ako izabrani poslužitelj ne može udovoljiti zahtjevima iz
DHCPREQUEST poruke (zatražena mrežna adresa je dodijeljena), onda treba
odgovoriti s DHCPNAK porukom.
5. Klijent primi DHCPACK poruku sa konfiguracijskim parametrima. Nakon
toga treba izvršiti završnu provjeru nad tim parametrima (ARP za dodijeljenu mrežnu
adresu) i označiti vrijeme posudbe odre_eno u DHCPACK poruci. U ovom trenutku
klijent je konfiguriran. Ako klijent detektira da je adresa vec u upotrebi (koristeći ARP),
klijent mora poslati DHCPDECLINE poruku poslužitelju i zapoceti ispocetka
konfiguracijski proces. Klijent bi trebao pricekati minimalno deset sekundi prije
ponovnog pokretanja konfiguracijskog postupka da bi se izbjegao prekomjerni mrežni
promet u slucaju petlje. Ako klijent primi DHCPNAK poruku, klijent ponovo zapocinje
konfiguracijski proces. Ako klijent ne primi ni DHCPACK ni DHCPNAK poruku onda
proglasi istek vremena i ponovo šalje DHCPREQUEST poruku. Klijent ponovo šalje
DHCPREQUEST prema algoritmu za ponovno slanje. Klijent bi trebao ponovo poslati
DHCPREQUEST zahtjev dovoljan broj puta da bi pružio odre_enu vjerojatnost za
kontaktiranje poslužitelja bez prevelikog cekanja prije odustajanja. Npr. klijent ponovo
šalje DHCPREQUEST zahtjeve cetiri puta u ukupnom vremenskom periodu od 60
sekundi, prije nego što ponovno zapocne inicijalizacijski postupak. Ako klijent ne primi

16
ni DHCPACK ni DHCPNAK poruku nakon ponovnog slanja algoritma, klijent se
prebacuje u INIT stanje i ponovo zapocinje inicijalizacijski postupak. Klijent bi trebao
obavijestiti korisnika da inicijalizacijski postupak nije uspio i da se ponovo pokrece.
6. Klijent može vratiti svoju adresu šaljuci DHCPRELEASE poruku poslužitelju.
Klijent raspoznaje posudbu sa oznakom klijenta ili ‘chaddr’ i mrežnom adresom u
DHCPRELEASE poruci. Ako je klijent koristio oznaku klijenta kad je primio posudbu,
mora koristiti istu oznaku klijenta u DHCPRELEASE poruci.

2.4.2. Klijent – poslužitelj komunikacija: ponovno korištenje prethodno

dodijeljene mrežne adrese
Ako klijent zapamti i želi ponovo koristiti prethodno dodijeljenu mrežnu adresu,
može izostaviti neke od procedura spomenutih u prethodnoj cjelini. Vremenski dijagram
na slici 4. prikazuje vremensku ovisnost u tipicnoj klijent-poslužitelj komunikaciji gdje
klijent ponovo koristi vec prethodno dodijeljenu mrežnu adresu.

Slika 4. Vremenski dijagram poruka izmijenjenih izmeđuDHCP klijenta i poslužitelja

prilikom ponovnog korištenja prethodno dodijeljene mrežne adrese
17
 1. Klijent emitira DHCPRQUEST poruku na svojoj lokalnoj podmreži. Poruka
uključuje mrežnu adresu klijenta u opciji zatražena IP adresa. Buduci da klijent nije
primio svoju mrežnu adresu, ne smije popuniti ‘ciaddr’ polje. BOOTP prijenosni agent
proslijedi poruku do DHCP poslužitelja koji nisu na istoj podmreži. Ako je klijent
koristio oznaku klijenta pri dobivanju adrese, onda je mora koristiti i u DHCPREQUEST
poruci.
2. Poslužitelj (sa evidentiranim konfiguracijskim parametrima klijenta) odgovara
klijentu s DHCPACK porukom. Poslužitelji ne bi trebali provjeravati da li se mrežna
adresa klijenta vec koristi. Ako je zahtjev klijenta neispravan (npr. klijent je preselio na
novu podmrežu), poslužitelj bi trebao odgovoriti klijentu s DHCPNAK porukom. Ako je
‘giaddr’ polje postavljeno na 0x0 u DHCPREQUEST poruci, klijent je na istoj podmreži
kao i poslužitelj. Poslužitelj mora emitirati DHCPNAK poruku na 0xffffffff adresu za
emitiranje zbog toga što klijent možda nema tocnu mrežnu adresu ili mrežnu masku, i
klijent možda ne odgovara na ARP zahtjev. U suprotnom, poslužitelj mora poslati
DHCPNAK poruku na IP adresu BOOTP prijenosnog agenta koja je postavljena u
‘giaddr’ polju. Prijenosni agent ce tu poruku proslijediti direktno na fizičku adresu
klijenta, pa se DHCPNAK poruka može dostaviti i ako se klijent premjesti na drugu
mrežu.
3. Klijent primi DHCPACK poruku s konfiguracijskim parametrima. Nakon toga
izvršava završne provjere na parametrima i naznači vrijeme posudbe odre_eno u
DHCPACK poruci. Odre_ena posudba se jednoznacno definira s oznakom klijenta ili
‘chaddr’ i mrežnom adresom. U ovom trenutku, klijent je konfiguriran. Ako klijent
otkrije da se IP adresa u DHCPACK poruci vec koristi mora poslati DHCPDECLINE
poruku poslužitelju i ponovo zapoceti konfiguracijski postupak zahtijevajuci novu
mrežnu adresu. Ovaj postupak je sukladan prelasku u INIT stanje u dijagramu DHCP
stanja. Ako klijent primi DHCPNAK poruku, onda ne može koristiti zapamcenu mrežnu
adresu. Umjesto toga mora zatražiti novu adresu ponovnim zapocinjanjem
konfiguracijskog postupka. Ovaj postupak je tako_er sukladan prelasku u INIT stanje
DHCP dijagrama stanja. Ako ne primi DHCPACK ni DHCPNAK poruku klijent objavi

18
istek vremena i ponovo šalje DHCPREQUEST poruku. Ponovo šalje DHCPREQUEST
prema algoritmu za ponovno slanje.
4. Klijent može vratiti svoju posudbu mrežne adrese tako da pošalje
DHCPRELEASE poruku poslužitelju. Svoju posudbu odre_uje s oznakom klijenta ili s
‘chaddr’ i mrežnom adresom u DHCPRELEASE poruci. Treba primijetiti da u ovom
slucaju klijent, kada zadržava svoju adresu lokalno, neće vratiti posudbu mrežne adrese
tokom uobicajenog iskljucivanja računala. Jedino ce klijent poslati DHCPRELEASE
poruku kada definitivno treba vratiti svoju posudbu mrežne adrese, npr. prilikom
premještaja klijenta na drugu podmrežu.

2.4.3. Interpretacija vremenskih vrijednosti

Buduci da klijent i poslužitelj ne moraju biti sinkronizirani, vrijeme u DHCP
poruci se prezentira kao relativno, da bi se ispravno protumacilo na lokalnom satu
klijenta. Predstavljajuci relativno vrijeme u intervalima, od jedne sekunde koristeći 32
bitnu rijec, dobije se raspon relativnog vremena od 0 sekundi do približno 100 godina.
Klijent dobiva vrijeme posudbe za mrežnu adresu na odre_eni vremenski period (koji
može biti i beskonacan). U protokolu se vrijeme tumaci kroz vremensku jedinicu
sekundu. Vremenska vrijednost od 0xffffffff je rezervirana da predstavlja beskonacnost.
Algoritam za tumacenje vremena posudbe pretpostavlja da su satovi klijenta i
poslužitelja stabilni u odnosu jedan naprama drugome. Ako postoji razlika izmeđudvaju
satova, poslužitelj može pretpostaviti da je vrijeme posudbe isteklo prije nego što to
klijent pretpostavi. Da bi se to kompenziralo, poslužitelj može vratiti klijentu krace
vrijeme posudbe nego što ga postavi u svojoj lokalnoj bazi klijentskih podataka.

2.4.4. Dobivanje parametara sa rucno postavljenom mrežnom adresom

Ako je klijentu dodijeljena mrežna adresa na neki drugi način (npr. Rucna
konfiguracija), on može koristiti DHCPINFORM poruku, da bi prikupio ostale
konfiguracijske parametre. Poslužitelji koji prime DHCPINFORM poruku kreiraju
DHCPACK poruku sa bilo kojim lokalnim konfiguracijskim parametrima, prikladnima
za klijenta, bez: dodjele nove adrese, provjere za postojecim usklađivanjem,
popunjavanja yiadde polja ili uključivanja parametara vremena posudbe.

19
 Poslužitelji trebaju poslati DHCPACK odgovor poruku pojedinacnom klijentu, na
adresu iz ‘ciaddr’ polja DHCPINFORM poruke. Poslužitelj treba provjeriti da li postoji
mrežna adresa iz DHCPINFORM poruke, ali ne smije provjeravati postoji li vrijeme
posudbe. Poslužitelj kreira DCHPACK poruku koja sadrži konfiguracijske parametre za
klijenta i šalje poruku izravno klijentu.

2.4.5. DHCP parametri klijenta

Ne zahtijevaju svi klijenti dodjeljivanje svih parametara koje podržava DHCP.
Koriste se dvije metode da bi se smanjio broj parametara koji se prenosi od poslužitelja
prema klijentu. Prvo, vecina parametara ima unaprijed zadane vrijednosti; ako klijent ne
primi vrijednosti koje zamjenjuju pretpostavljene vrijednosti, klijent nastavlja koristiti
pretpostavljene vrijednosti. Drugo, u svom pocetnom DHCPDISCOVER ili
DHCPREQUEST poruci, klijent može pružiti popis odre_enih parametara za koje je
klijent zainteresiran. Ako klijent uključi popis parametara u DHCPDISCOVER poruci,
onda ih mora uključiti i u svim nadolazecim DHCPREQUEST porukama. Klijent može
obavijestiti poslužitelja koji ga parametri zanimaju na način da uključi opciju lista
zahtijevanih parametara (eng.: parameter request list). Podatkovni dio ove opcije daje
eksplicitni popis zatraženih opcija preko tag broja. Klijent bi trebao uključiti i opciju
maksimalna velicina DHCP poruke tako da kaže poslužitelju koliko veliku DHCP
poruku može kreirati. Parametri koji se vraćaju klijentu i dalje mogu prijeci velicinu
dodijeljenu opcijama DHCP poruke. U tom slucaju, dvije dodatnezastave opcija (koje se
moraju postaviti u opcijskom polju poruke) ce ukazivati da ce se polja datoteke i
opcijsko ime poslužitelja koristiti za opcije. Dodatno, klijent može predložiti vrijednosti
mrežne adrese i vremena posu_ivanja u DHCPDISCOVER poruci. Klijent može
uključiti opciju zatražena IP adresa da predloži da mu dodijeli odre_ena IP adresa i može
uključiti opciju vrijeme posudbe IP adrese (eng.: IP address lease time) opciju da
predloži vrijeme posudbe koje želi. Ostale opcije su dozvoljene u DHCPDISCOVER ili
DHCPREQUEST poruci. Ali, dodatne opcije mogu biti ignorirane od strane poslužitelja,
pa više poslužitelja može vratiti razlicite vrijednosti za neke opcije. Opcija zatražena IP
adresa se može popuniti samo u DHCPREQUEST poruci kad klijent potvr_uje
prethodno prikupljene mrežne parametre. Ako poslužitelj primi DHCPREQUEST

20
poruku sa nevažecom opcijom zatražena IP adresa, trebao bi odgovoriti klijentu s
DHCPNAK porukom. Postoji opcija i da se navedeni problem prijavi sistem
administratoru. Poslužitelj može uključiti poruku o grešci u opciji poruka (eng.:
message).

2.4.6. Korištenje DHCP-a na klijentima sa više mrežnih kartica

Klijent s više mrežnih kartica mora koristiti DHCP kroz svaku karticu nezavisno,
da bi prikupio informacije o konfiguracijskim parametrima za tu određenu karticu.

2.4.7. Klijenti: kada koristiti DHCP

Klijenti bi trebali koristiti DHCP da bi zatražili ili potvrdili IP adresu i mrežne
parametre (kad god su se mrežni parametri mogli promijeniti), npr. prilikom pokretanja
klijenta ili nakon iskljucenja s lokalne mreže (kad se lokalne mrežne postavke mogu
promijeniti bez znanja klijenta ili korisnika klijenta). Ako klijent zna svoju prije
korištenu mrežnu adresu i ne može pristupiti lokalnom DHCP poslužitelju može
nastaviti koristiti prijašnju mrežnu adresu sve dok vrijeme posudbe te adrese ne istekne.
Ako vrijeme posudbe istekne prije nego klijent pristupi DHCP poslužitelju, klijent mora
odmah prestati koristiti prijašnju mrežnu adresu i može obavijestiti korisnika o
problemu.

2.5. SPECIFIKACIJE DHCP KLIJENT – POSLUŽITELJ PROTOKOLA

U ovom dijelu pretpostavljamo da poslužitelj ima skup mrežnih adresa iz kojeg
može zadovoljiti zahtjeve za novim adresama. Svaki poslužitelj održava bazu podataka
dodijeljenih adresa i vremena posudbe u trajnoj lokalnoj pohrani. Klijent i poslužitelj
konstruiraju DHCP poruku na način da popunjavaju polja u unaprijed određenom
formatu sekcija poruke i prilago_avajuci uokvirene vrijednosti u opcijsko podrucje
proizvoljne velicine. Opcijsko podrucje uključuje prva cetiri okteta ‘magic cookie’ koje
slijedi opcija. Posljednja opcija mora uvijek biti ‘end’ opcija. DHCP koristi UDP kao
svoj transportni protokol. DHCP poruka od klijenta prema poslužitelju se šalje na
prikljucnoj tocki 67 - DHCP poslužitelj a DHCP poruka od poslužitelja prema klijentu je
poslana na prikljucnoj tocki 68 - DHCP klijent. Poslužitelj sa višestrukim mrežnim

21
adresama može koristiti bilo koju od svojih mrežnih adresa za odlaznu DHCP poruku.
Polje oznaka poslužitelja se koristi za prepoznavanje DHCP poslužitelja u DHCP poruci,
i kao odredišna adresa od klijenta prema poslužitelju. Poslužitelj sa višestrukim mrežnim
adresama mora biti spreman prihvatiti bilo koju od svojih mrežnih adresa za
prepoznavanje tog poslužitelja u DHCP poruci. Da bi se riješio potencijalno nepotpune
mrežne povezanosti, poslužitelj mora, kao oznaku poslužitelja, izabrati adresu koja je
prema spoznajama poslužitelja dostupna od strane klijenta. Npr. ako su DHCP
poslužitelj i DHCP klijent povezani na istu podmrežu (npr. ‘giaddr’ polje u poruci od
klijenta je nula), poslužitelj mora izabrati IP adresu poslužitelja koju koristi za
komunikaciju u toj podmreži, kao oznaku
poslužitelja. Ako poslužitelj koristi višestruke IP adrese na toj podmreži, bilo koja od
tih adresa se može koristiti. Ako je poslužitelj primio poruku preko DHCP prijenosnog
agenta, DHCP poslužitelj mora izabrati adresu te mrežne kartice na koju je poruka
primljena, kao oznaku poslužitelja (osim ako poslužitelj ima druge bolje informacije na
temelju kojih može donijeti odluku). DHCP klijent mora koristiti IP adresu primljenu u
opciji oznaka poslužitelja, za svaki jednoznacni zahtjev prema DHCP poslužitelju.
DHCP poruka emitirana od klijenta, prije nego klijent dobije vlastitu IP adresu, mora u
polju izvorišne adrese u IP zaglavlju biti postavljena na nulu. Ako je ‘giaddr’ polje u
DHCP poruci od klijenta razlicito od nule, poslužitelj šalje odgovor na prikljucnoj tocki
67 (DHCP poslužitelj) na BOOTP prijenosnom agentu cija je adresa prikazana u
‘giaddr’ polju. Ako je ‘giaddr’ polje nula a ‘ciaddr’ polje razlicito od nule, tada
poslužitelj pošalje jednoznacnu poruku, DHCPOFFER i DHCPACK na adresu u
‘ciaddr’ polju. Ako je ‘giaddr’ nula i ‘ciaddr’ je nula, a broadcast bit je postavljen, onda
poslužitelj emitira DHCPOFFER i DHCPACK poruku na 0xfffffff. Ako broadcast bit
nije postavljen i ‘giaddr’ je nula i ‘ciaddr’ je nula, onda poslužitelj jednoznacno šalje
poruku DHCPOFFER i DHCPACK poruke na klijentovu fizičku adresu i ‘yiaddr’
adresu. U svakom slucaju, kad je ‘giaddr’ nula, poslužitelj emitira sve DHCPNAK
poruke na 0xffffffff. DHCP klijent je odgovaran za sva ponovna slanja poruka. Klijent
se mora prilagoditi strategiji ponovnog slanja koja uključuje proizvoljno eksponencijalni
odbijajuci algoritam da bi utvrdio odgodu izmeđuslanja. Odgoda izmeđuponovnih slanja
bi trebala biti izabrana tako da dozvoli dovoljno vremena da se dostavi odgovor od

22
poslužitelja ovisno o karakteristikama mreže izmeđuklijenta i poslužitelja. Npr. u 10Mb
ethernet mrežama, odgoda izmeđuprvogponovnog slanja trebala bi biti 4 sekunde,
prilago_ena vrijednosti proizvoljno izabranog broja iz raspona od –1 do +1. Odgoda
prije sljedeceg ponovnog slanja trebala bi biti 8 sekundi, prilago_ena vrijednosti
proizvoljnog broja od –1 do +1. Ponovno slanje bi se trebalo duplo povecati svakim
sljedecim ponovnim slanjem, do maksimalno 64 sekunde. Klijent može pružiti pregled
ponovnih slanja korisniku, kao pregled konfiguracijskog procesa. Polje transakcijski ID
(eng.: xid) se koristi od strane klijenta da bi se povezala dolazeca DHCP poruka, sa
pokrenutim zahtjevom. DHCP klijent mora izabrati transakcijski ID na takav način da
minimalizira šanse poklapanja vrijednosti transakcijskog ID-a sa drugim klijentom. Npr.
klijent može izabrati razliciti, nasumicno izabrani inicijalni, transakcijski ID svaki put
kad se ponovno pokrene i stalno koristiti taj transakcijski ID sve do sljedeceg ponovnog
pokretanja. Korištenje nove vrijednosti transakcijskog ID-a za svako ponovno slanje je
odluka koja ovisi o pojedinoj implementaciji. Klijent može ponovno koristiti isti
transakcijski ID ili izabrati novi za svako novo ponovno slanje poruke. DHCP poslužitelj
i BOOTP prijenosni agent pokušavaju klijentu izravno dostaviti DHCPOFFER,
DHCPACK i DHCPNAK poruke koristeći jednoznacno slanje. IP odredišna adresa (u IP
zaglavlju) je postavljena na DHCP ‘yiaddr’ adresu i odredišna adresa sloja veze je
postavljena na DHCP ‘chaddr’ adresu. Nažalost, implementacije nekih klijenata nisu u
mogućnosti primiti takav jednoznacno poslani datagram sve dok nije konfiguriran sa
valjanom IP adresom (dolazimo do slijepe ulice u kojoj se IP adresa klijenta ne može
dodijeliti sve dok klijent nije konfiguriran s IP adresom). Na klijentu koji ne može
primiti jednoznacno poslani IP datagram, sve dok program protokola nije konfiguriran
sa IP adresom, treba postaviti broadcast bit u polju zastave na jedan, u svakoj
DHCPDISCOVER ili DHCPREQUEST poruci koju šalje. Broadcast bit ce naznačiti
DHCP poslužitelju i BOOTP prijenosnom agentu da emitira sve poruke prema klijentu
na klijentovoj podmreži. Klijent koji može primiti jednoznacno poslani IP datagram
prije nego je njegov program protokola konfiguriran treba broadcast bit postaviti na
nula.

2.5.1. Administrativne kontrole DHCP poslužitelja

23
 DHCP specifikacije opisuju samo interakciju izmeđuklijenta i poslužitelja kad
klijent i poslužitelj odluce da komuniciraju. DHCP poslužitelj ne treba odgovoriti na
svaku DHCPDISCOVER i DHCPREQUEST poruku koju primi. Npr. mrežni
administrator, da bi sacuvao vecu kontrolu nad klijentima povezanim na mrežu, može
konfigurirati DHCP poslužitelj da odgovara samo onim klijentima koji su prethodno
registrirani preko nekog vanjskog mehanizma. Odre_ene implementacije DHCP
poslužitelja mogu podržavati razne kontrole ili pravila koje zahtjeva mrežni
administrator. U nekim okruženjima, DHCP poslužitelj mora razmotriti vrijednosti u
opcijama klasa proizvo_aca (eng.: vendor class) opcijama unutar DHCPDISCOVER i
DHCPDISCOVER poruka prilikom odre_ivanja odgovarajucih parametara za pojedinog
klijenta. DHCP poslužitelj treba koristiti neku jedinstvenu oznaku da bi povezao klijenta
s njegovim vremenom posudbe. Klijent može izabrati da eksplicitno pruži identifikaciju
kroz opciju oznaka klijenta. Ako klijent pruži oznaku klijenta mora koristiti istu oznaku
klijenta u svim sljedecim porukama. Poslužitelj mora koristiti istu oznaku klijenta da bi
raspoznao klijenta. Ako klijent ne pruži opciju oznaku klijenta, poslužitelj mora koristiti
sadržaj ‘chaddr’ polja da bi prepoznao klijenta. Od iznimne je važnosti da DHCP klijent
koristi jedinstvenu oznakuklijenta u svojoj podmreži. Korištenje ‘chaddr’ kao
jedinstvene oznake može stvoriti neželjene rezultate, jer se jedinstvena oznaka može
povezati s mrežnom karticom koja se naknadno može prebaciti u neko drugo računalo.
Da bi se to izbjeglo, u nekim se implementacijama koristi serijski broj mrežne kartice ili
DNS ime kao oznaka klijenta. Potonji uzrokuje da posudba adrese bude povezana s DNS
imenom, radije nego s odre_enim dijelom fizicke komponente.

2.5.2. Ponašanje DHCP poslužitelja

DHCP poslužitelj obra_uje dolazecu DHCP poruku od strane klijenta temeljem
trenutnog stanja uskla_ivanja s tim klijentom. DHCP poslužitelj može primiti sljedece
poruke od klijenta:
 DHCPDISCOVER
 DHCPREQUEST
 DHCPDECLINE
 DHCPRELEASE

24
  DHCPINFORM.
DHCPDISCOVER poruka
Kad poslužitelj primi DHCPDISCOVER poruku od strane klijenta, poslužitelj
odabire mrežnu adresu za tog klijenta. Ako nijedna adresa nije slobodna, poslužitelj
može prijaviti problem mrežnom administratoru. Ako ima slobodnih adresa, nova adresa
bi se trebala izabrati na sljedeci način:
- trenutna adresa klijenta koja je zapisana u trenutnim pregovorima klijenta
- prethodna adresa klijenta koja je zapisana u pregovoru klijenta (sad vec
završenom) , ako je ta adresa u skupu slobodnih adresa
- adresa zahtijevana u opciji zatražena IP adresa, ako je takva adresa valjana i nije vec
dodijeljena
- nova adresa iz skupa slobodnih adresa; adresa je izabrana na osnovi podmreže iz
koje je poruka primljena (ako je ‘giaddr’ jednako 0) ili na osnovu adrese prijenosnog
agenta koji je proslijedio poruku (ako je ‘giaddr’ razlicito od 0)
Poslužitelj mora izabrati vrijeme posudbe na sljedeci način:
- ako klijent nije zatražio odre_eno vrijeme posudbe u svojoj DHCPDISCOVER
poruci i ako klijent vec ima dodijeljenu mrežnu adresu, poslužitelj ce klijentu dodijeliti
jednako vrijeme posudbe
- ako klijent nije zatražio odre_eno vrijeme posudbe u DHCPDISCOVER poruci i
klijent nema vec dodijeljenu mrežnu adresu, poslužitelj ce mu dodijeliti lokalno
konfigurirano podrazumijevano vrijeme posudbe
- ako je klijent zatražio odre_eno vrijeme posudbe u DHCPDISCOVER poruci (bez
obzira da li vec ima dodijeljenu mrežnu adresu) poslužitelj može izabrati da mu ponudi
zatraženo ili neko drugo vrijeme
Jednom kad se odredi mrežna adresa i vrijeme posudbe, poslužitelj konstruira
DHCPOFFER poruku s ponu_enim konfiguracijskim parametrima. Važno je da svi
DHCP poslužitelji vrate iste parametre, da bi se osiguralo predvidljivo ponašanje
klijenta, bez obzira koji je poslužitelj klijent izabrao. Konfiguracijski parametri se
moraju izabrati koristeći ispod opisana pravila, po navedenom rasporedu. Mrežni
administrator je odgovoran da osigura jednoznacni odgovor svih poslužitelja.
Poslužitelj mora poslati klijentu:

25
 - mrežnu adresu klijenta, kao što je opisano u prijašnjem tekstu
- vrijeme isteka posudbe klijenta
- parametre koje je klijent zatražio, prema sljedecim pravilima
 ako je poslužitelj konfiguriran iskljucivo na osnovnu vrijednost, poslužitelj mora
uključiti tu vrijednost u odgovarajucu opciju polja opcije
 ako poslužitelj prepozna da je parametar definiran u dokumentu zahtjevi klijenta
mora uključiti osnovnu vrijednost za taj parametar kao što je navedeno u tom
dokumentu
 poslužitelj ne smije vratiti vrijednost za taj parametar.
Poslužitelj mora podržavati što više zatraženih parametara i mora zanemariti
parametre koje ne može pružiti. Poslužitelj mora uključiti svaki od zatraženih
parametara samo jednom, osim ako nije drugacije dozvoljeno u DHCP opcijama.
DHCPREQUEST poruka
DHCPREQUEST poruka može doci od klijenta kao:
 odgovor na DHCPOFFER poruku od poslužitelja
 potvrda prethodno dodijeljene IP adrese
 produženje vremena posudbe.
Ako DHCPREQUEST poruka sadrži opciju oznaka poslužitelja, poruka je odgovor
na DHCPOFFER poruku. Ako nema, onda je to poruka zahtjeva potvrde ili produženja
postojeće posudbe. Ako klijent koristi oznaku klijenta u DHCPREQUEST poruci, onda
mora koristiti istu oznaku klijenta i u svim sljedecim porukama. Ako klijent uključi
popis zatraženih parametara u DHCPDISCOVER poruci, onda mora uključiti taj popis i
u svim naknadnim porukama. Konfiguracijski parametri u DHCPACK poruci ne smiju
biti u proturjecju s onim u prijašnjim DHCPOFFER porukama na koje klijent odgovara.
Klijent bi trebao koristiti parametre iz DHCPACK poruke za konfiguraciju.
DHCPDECLINE poruka
Ako poslužitelj primi DHCPDECLINE poruku, to znači da je klijent, koristeći neke
druge načine, otkrio da je predložena mrežna adresa vec u upotrebi. Poslužitelj mora
označiti tu mrežnu adresu kao nedostupnu i treba obavijestiti lokalnog mrežnog
administratora o mogucim konfiguracijskim problemima.
DHCPRELEASE poruka

26
 Nakon primitka DHCPRELEASE poruke, poslužitelj oznacava navedenu mrežnu
adresu slobodnom za dodjelu. Poslužitelj bi trebao sacuvati podatke o inicijalizacijskim
parametrimaklijenta za mogucu ponovnu upotrebu u odgovoru na naknadne
nadovezujuce poruke od strane klijenta.
DHCPINFORM poruka
Poslužitelj odgovara na DHCPINFORM poruku šaljuci DHCPACK poruku. Odgovor
šalje izravno na adresu koja je navedena u ‘ciaddr’ polju DHCPINFORM poruke.
Poslužitelj prema klijentu ne smije slati vrijeme isteka posudbe i ne smije popunjavati
‘yiaddr’ polje.
PORUKE KLIJENTA
Tablica 4. detaljno prikazuje razlike izmeđuporuka klijenta iz razlicitih stanja.

Tablica 4. Poruke klijenta iz različitih stanja

2.5.3. Ponašanje DHCP klijenta

Na slici 5. je prikazan dijagram stanja-prijelaza za DHCP klijenta. Klijent može
primiti sljedece poruke od DHCP poslužitelja:
 DHCPOFFER
 DHCPACK
 DHCPNAK
DHCPINFORM poruka nije prikazana na 6. Klijent jednostavno pošalje
DHCPINFORM poruku i ceka na DHCPACK poruku. U trenutku kad klijent izabere
parametar, on je završio konfiguracijski proces.

27
 Slika 5. Dijagram stanja-prijelaza za DHCP klijente

Inicijalizacija i dodjela mrežnih adresa

Klijent zapocne s INIT stanjem i kreira DHCPDISCOVER poruku. Klijent bi trebao
pricekati izmeđujedne i deset sekundi, da bi izbjeglo višestruko korištenje DHCP-a
prilikom pokretanja. Klijent postavi ‘ciaddr’ na 0x00000000. Klijent može zatražiti
odre_ene parametre uključivanjem opcije lista zahtijevanih parametara. Klijent može
predložiti mrežnu adresu i/ili vrijeme posudbe uključivanjem opcije zatražena IP adresa i
vrijeme posudbe IP adrese. Klijent mora uključiti vlastitu fizičku adresu u ‘chaddr’
polju, ako je nužna za proslje_ivanje DHCPREPLY poruke. Klijent može uključiti
drugaciju jedinstvenu oznaku u opciji oznaka klijenta, kao što je ranije objašnjeno. Ako
28
uključi popis zahtijevanih parametara u DHCPDISCOVER poruci, mora ih uključiti i u
svim sljedecim porukama. Klijent generira i sprema proizvoljnu prijenosnu oznaku i
unosi je kao oznaku u polje transakcijski ID. Sprema vlastito vrijeme, za kasnije
računanje isteka vremena posudbe. Klijent nakon toga emitira DHCPDISCOVER
poruku na lokalnoj fizickoj adresi za emitiranje na 0xffffffff i na DHCP poslužitelj UDP
prikljucnoj tocki. Ako transakcijski ID dolazece DHCPOFFER poruke ne odgovara
transakcijskom ID-u posljednje DHCPDISCOVER poruke, DHCPOFFER poruka se
mora odbaciti. Tako_er, svaka nadolazeca DHCPACK poruka se mora odbaciti. Klijent
prikuplja DHCPOFFER poruke tijekom proizvoljnog vremenskog perioda, odabere
jednu DHCPOFFER poruku (npr. prvu primljenu poruku ili poruku od ranije korištenog
DHCP poslužitelja) i izvuce adresu poslužitelja iz opcije oznaka poslužitelja u
DHCPOFFER poruci. Vrijeme tijekom kojeg klijent prikuplja poruke i mehanizam
odabira DHCPOFFER poruke ovise o implementaciji. Ako su parametri prihvatljivi,
klijent sacuva adresu poslužitelja koji mu je poslao parametre iz polja oznake
poslužitelja i šalje tu adresu u polju oznake poslužitelja DHCPREQUEST poruke.
Jednom kada DHCPACK poruka od poslužitelja stigne, klijent je inicijaliziran i prelazi u
BOUND stanje. DHCPREQUEST poruka sadrži isto polje transakcijskog ID-a kao i
DHCPOFFER poruka. Klijent sacuva vrijeme posudbe kao zbroj vremena u kojem se
originalni zahtjev poslao i vremena posudbe iz DHCPACK poruke. Tada izvršava
provjeru predložene adrese, da bi osigurao da adresa nije vec u upotrebi. Npr. ako je
klijent u mreži koja podržava ARP, onda može poslati ARP zahtjev. Kad se emitira ARP
zahtjev za predloženu adresu, klijent mora popuniti vlastitu fizičku adresu kao
pošiljateljevu fizičku adresu, i 0 kao pošiljateljeva IP adresa, da bi izbjegao
onecišcavanje ARP memorije kod ostalih klijenta na istoj podmreži. Ako je mrežna
adresa u upotrebi, klijent mora poslati DHCPDECLINE poruku poslužitelju.
Korištenje emitiranja i jednoznacnog slanja
DHCP klijent emitira DHCPDISCOVER, DHCPREQUEST i DHCPINFORM
poruke, osim ako klijent zna adresu DHCP poslužitelja. Klijent jednoznacno šalje
DHCPRELEASE poruku poslužitelju. Zbog toga što klijent odbija korištenje IP adrese
ponu_ene od strane poslužitelja, on emitira DHCPDECLINE poruku. Kad DHCP klijent
zna adresu DHCP poslužitelja, bilo u INIT ili REBOOTING stanju, klijent može

29
koristiti tu adresu u DHCPDISCOVER ili DHCPREQUEST poruci, umjesto da
emitirana cijeloj podmreži. Klijent tako_er može jednoznacno slati DHCPINFORM
poruku poznatom DHCP poslužitelju. Ako klijent ne dobije odgovor na DHCP poruku
poslanu na IP adresu poznatog DHCP poslužitelja, onda emitira zahtjev.

30
 3. ZAKLJUČAK
Korištenjem DHCP poslužitelja omogućeno je centralizirano upravljanje nad
dodjelom IP adresa i ostalih mrežnih parametara, koje nije ograničeno sa jednom
podmrežom jer DHCP poslužitelj može dodjeljivati IP adrese klijentima na više
podmreža, po potrebi koristeći usmjerivače i prijenosne agente. U slučaju potrebe za
promjenama, npr. IP adrese DNS poslužitelja, dovoljno je napraviti promjenu na jednom
centralnom DHCP poslužitelju. DHCP servis je normalna i očekivana stvar čak i u
mrežama sa par računala, a da ne govorimo o firmama sa velikim brojem računala.
Među prvim je servisima koji se implementiraju u mrežnoj infrastrukturi. Na njega se
obično naslanja DNS servis sa kojim ima definiranu interakciju, npr. prilikom koje vrši
registriranje PTR pokazivačkih zapisa koji se koriste za inverzno pretraživanje
(nalaženje imena računala po zadatoj IP adresi računala). Kao servis je definiran od
strane IETF organizacije (velika otvorena internacionalna organizacija mrežnih
dizajnera, istraživača, operatera i proizvođaca) pa nije vezan uz određenog proizvođaca,
bilo programa, bilo fizičkih uređaja. To mu omogućava jednostavnu interoperabilnost pa
su nerijetki scenariji da u jednoj mrežnoj infrastrukturi koegzistira DHCP poslužitelj
baziran na Windows Server platformi, fizičkom uređaju ili Linux platformi. Stabilnost
DHCP poslužitelja je najbolja kod fizičkog uređaja, u ovom slučaju Cisco usmjerivača,
za razliku od Linux i Microsoft platforme gdje uslijed blokiranja bilo koje programske
komponente može doći do blokiranja kompletnog poslužitelja pa tako i DHCP servisa.
Prednost Microsoft DHCP poslužitelja je jednostavno dodavanje dodatnih servisa i
njihova integracija sa postojećim servisima, npr. vrlo je jednostavno naknadno dodati
DNS servis u postojeće mrežno okruženje sa DHCP servisom. DHCP servis će
automatski, po osnovnoj postavci, obavljati registraciju adresnih i/ili pokazivačkih
zapisa na DNS poslužitelju. Slična stvar se događa ukoliko npr. poželimo implementirati
RRAS servis i VPN pristup, gdje nam se nudi opcija dodjeljivanja adresa za vanjske
klijente iz postojećeg DHCP skupa. Među prednosti DHCP poslužitelja na Microsoft
platformi definitivno spada i pregledno grafičko sučelje koje nam nudi nadzor nad
radom DHCP poslužitelja, jednostavan pregled izdanih IP adresa, konfiguracijskih
parametara i upravljanje rezervacijama. DHCP poslužitelj na Linux platformi nam
naizgled omogućava jednostavniju inicijalnu konfiguraciju, jer u datoteci dhcpd.conf
31
imamo primjere koji se mogu lako prilagoditi željenoj mrežnoj infrastrukturi, u običnom
tekst editoru. Nakon toga je potrebno pokrenuti DHCP servis koji učitava postavke iz
navedene datoteke i imamo funkcionalan DHCP poslužitelj. Mana DHCP poslužitelja na
Linux platformi je loša dokumentiranost odnosno nedostatak kvalitetne detaljne
dokumentacije jer je riječ o besplatnom softveru otvorenog programskog koda. Situaciju
dodatno pogoršava velik broj distribucija Linux baziranih operativnih sustava. Primjera
radi, lako se može doći do konkretnih primjera konfiguracije DHCP poslužitelja iz
prakse, no vrlo teško je naći detaljnije opise naredbi i sintakse za iste, ili načina
komunikacije između pojedinih komponenti. Kao što se i može vidjeti iz ovog rada,
DHCP je robustan servis na sve tri platforme. Dobro je prihvaćen od strane mrežnih
administratora zbog toga što obavlja cjelokupni posao dodjeljivanja IP adresa i ostalih
mrežnih parametara DHCP klijentima, što im olakšava posao. Smanjuje se broj konflikta
IP adresa koji su česta pojava kod ručnog definiranja IP adresa, pa se samim time
smanjuje i broj interventnih situacija.

32
4. LITERATURA

1. Umrežavanje pomoću Cisco i Microsoft tehnologija, Anthony Chaiarella

2. Osnove Cisco tehnologija, Toby J. Velte
3. Croft, B., Gilmore, J.: “BOOTSTRAP PROTOCOL (BOOTP)”,
http://www.ietf.org/rfc/rfc0951.txt?number=951, 1985.
4. Droms, R.: “Dynamic Host Configuration Protocol”,
http://www.ietf.org/rfc/rfc2131.txt?number=2131, 1997.
5. Alexander, S., Droms, R.: “DHCP Options and BOOTP Vendor Extensions”,
http://www.ietf.org/rfc/rfc2132.txt?number=2132, 1997.
6. Microsoft TechNet: “What Is DHCP?”,
http://technet.microsoft.com/en-us/library/cc781008.aspx, 2003.
7. Microsoft TechNet: “Dynamic Host Configuration Protocol for Windows Server
2003”, http://technet.microsoft.com/en-us/library/bb726932.aspx, 2003.
8. Microsoft TechNet: “DHCP Tools and Settings”,
http://technet.microsoft.com/en-us/library/cc782411.aspx, 2003.
9. Microsoft TechNet: “How DHCP Technology Works”,
http://technet.microsoft.com/en-us/library/cc780760.aspx, 2003.

33