Automaattinen asetusten määritys käynnistettäessä (BOOTP, DHCP)

23 Automaattinen asetusten määritys käynnistettäessä (BOOTP, DHCP) 23.1 Johdanto Tässä luvussa esitetään, kuinka asiakas-palvelin-mallia sovelletaan laitteita käynnistettäessä. TCP/IP-yhteisverkkoon kytketyn tietokoneen on tiedettävä oma IP-osoitteensa, ennen kuin se voi lähettää tai vastaanottaa tietosähkeitä. Lisäksi tietokone tarvitsee muita tietoja, kuten reitittimen IP-osoitteen, aliverkon peitteen ja nimipalvelimen osoitteen. Luvussa 6 kerrottiin, kuinka tietokone voi hankkia itselleen IP-osoitteen käynnistysvaiheessa RARP-protokollalla. Tässä luvussa esitellään vaihtoehtoisia menetelmiä: kaksi käynnistysprotokollaa (bootstrap protocol), joita käyttämällä tietokone voi pyytää IP-osoitteen tarvitsematta käyttää RARP-protokollaa. Yllättävää kyllä asiakas ja palvelin kommunikoivat UDP-protokollalla (ks. luku 12). UDP-protokollahan käyttää IP:tä sanomien kuljettamiseen ja siksi tuntuu mahdottomalta, että tietokone voi tätä protokollaa käyttämällä pyytää itselleen kommunikoinnissa käytettävän IP-osoitteen. Tarkastelemalla protokollia lähemmin nähdään, kuinka tietokone voi käyttää hyväkseen tiettyjä, luvussa 4 mainittuja osoitteita ja UDP/IP-kuljetusmekanismin joustavuutta. Lisäksi nähdään, kuinka palvelin antaa tietokoneelle IP-osoitteen automaattisesti. Osoitteen antaminen automaattisesti on erityisen kätevää ympäristöissä, joissa yhteydet yhteisverkkoon luodaan tilapäisesti tai joissa tietokoneet siirtyvät verkosta toiseen (esimerkiksi kannettavaa tietokonetta käyttävä työntekijä siirtyy yrityksen sisällä paikasta toiseen). 443

444 Luku 23 23.2 Miksi RARP-protokollalle tarvitaan vaihtoehto? Luvussa 6 käsiteltiin levyasemattoman tietokoneen käynnistykseen liittyviä ongelmia. Tällaisissa tietokoneissa käynnistysohjelma on tavallisesti tallennettu haihtumattomaan muistiin (ROM-muisti). Kustannussyistä ja jotta osat olisivat vaihtokelpoisia, valmistaja käyttää samaa ohjelmaa kaikissa tietokoneissa. Koska jokainen tietokone tarvitsee oman IP-osoitteen, osoitetta ei voi tallentaa koodiin. Tämän vuoksi levyasemattoman tietokoneen on hankittava IP-osoite muualta. Tietokoneen on kuitenkin IP-osoitteen lisäksi tiedettävä paljon muutakin. ROM-muisti sisältää tavallisesti vain pienen käynnistysohjelman, joten levyasemattoman tietokoneen on myös ladattava varsinainen käyttöjärjestelmä. Jokaisen tietokoneen on lisäksi hankittava tietojen varastoinnissa käytettävän tiedostopalvelimen osoite sekä lähimmän IPreitittimen osoite. Luvussa 6 esitellyllä RARP-protokollalla on kolme heikkoutta. Ensiksi, koska RARP on lähellä laitetasoa toimiva protokolla, sen käyttäminen edellyttää suoraa kommunikointia verkon liitäntäkortin kanssa. Sovellusohjelmoijan on siksi vaikeaa tai jopa mahdotonta kirjoittaa palvelinohjelma. Toiseksi, paketti, jonka asiakas saa vastaukseksi palvelimelle lähettämäänsä kyselyyn, sisältää vain vähän tietoja: asiakkaan IP-osoitteen (4 oktettia). Tämä haitta on erityisen kiusallinen Ethernetin kaltaisissa verkoissa, joissa paketeilla on tietty vähimmäispituus eli tietoja voitaisiin palauttaa enemmänkin lisäämättä verkon kuormaa. Kolmanneksi, koska RARP yksilöin tietokoneen sen laiteosoitteen perusteella. Protokollaa ei voi käyttää verkoissa, joissa määritellään laiteosoitteet dynaamisesti. RARP-protokollaan liittyvien haittojen vuoksi suunnittelijat kehittivät BOOTP (BOOTstrap Protocol) -protokollan. Myöhemmin BOOTP-protokollalle kehitettiin seuraaja nimeltä DHCP (Dynamic Host Configuration Protocol). Koska nämä kaksi protokollaa ovat läheistä sukua toisilleen, suurin osa tämän luvun tekstistä koskee molempia. Yksinkertaisuuden vuoksi BOOTP-protokolla käsitellään ensiksi. Sen jälkeen tarkastellaan DHCP-protokollan tarjoamia lisätoimintoja (dynaaminen osoitteiden määrittäminen). BOOTP voidaan toteuttaa sovelluksena, koska se käyttää UDP- ja IP-protokollia. RARPprotokollan tapaan BOOTP käyttää asiakas-palvelin-mallia ja edellyttää vain yhden sanoman vaihtamisen. BOOTP on kuitenkin paljon tehokkaampi kuin RARP, koska yksi BOOTPsanoma sisältää useita käynnistysvaiheessa tarvittavia tietoja, kuten tietokoneen IP-osoite, reitittimen osoite ja palvelimen osoite. Vastaussanomassa on myös vapaamuotoisia tietoja sisältävä valmistajakohtainen kenttä, johon laitevalmistajat voivat tallentaa omissa tietokonejärjestelmissään käytettäviä tietoja. 23.3 IP-osoitteen määrittäminen IP-protokollalla Edellä sanottiin, että BOOTP käyttää UDP-protokollaa sanomien kuljettamiseen ja että UDP-sanomat kapseloidaan IP-tietosähkeisiin kuljetusta varten. Jotta voitaisiin ymmärtää, kuinka tietokone voi lähettää BOOTP-sanoman IP-tietosähkeessä, ennen kuin tietokone tietää Termi valmistajakohtainen on harhaanjohtava, koska nykyiset määritykset suosittavat tiettyjen yleisten tietojen, esimerkiksi aliverkon peitteen, tallentamista tähän kenttään. DHCP:n määrityksissä kentän nimi onkin optiot.

Automaattinen asetusmääritys käynnistettäessä (BOOTP, DHCP) 445 oman IP-osoitteensa, on palautettava mieleen, että käytettävissä on erityistarkoitukseen varattuja IP-osoitteita (ks. luku 4). Eräs eritystapaus on kohdeosoite, jonka kaikki bitit ovat ykkösiä (255.255.255.255). Se määrittää rajoitetun yleislähetyksen. IP-ohjelmisto voi vastaanottaa ja lähettää tämän osoitteen sisältäviä yleislähetystietosähkeitä, vaikka tietokoneella ei vielä olisikaan omaa IP-osoitetta. Lyhyesti sanottuna: Sovellus voi rajoitetun yleislähetyksen IP-osoitetta käyttämällä lähettää tietosähkeen lähiverkkoon, ennen kuin käytettävissä on lähiverkon IP-osoitetta tai tietokoneen omaa IP-osoitetta. Oletetaan, että tietokone A haluaa ladata käynnistystiedot (kuten oman IP-osoitteensa) BOOTP-protokollalla ja oletetaan, että B on samaan fyysiseen verkkoon kuuluva palvelin, joka vastaa pyyntöön. Koska A ei tiedä B:n IP-osoitetta eikä verkon IP-osoitetta, sen on lähetettävä BOOTP-kysely IP:n rajoitettua yleislähetysosoitetta käyttämällä. Entä sitten vastaus? Voiko B lähettää vastauksen suoraan A:lle? Tavallisesti ei. B saattaa joutua käyttämään rajoitetun yleislähetyksen osoitetta myös vastauksessa, vaikka se tietäisikin A:n IP-osoitteen. Syyn ymmärtää, kun tarkastellaan, mitä tapahtuu, jos B:ssä toimiva sovellus yrittää lähettää tietosähkeen A:n IP-osoitteeseen. Reititettyään tietosähkeen B:n IP-ohjelmisto, siirtää sen verkon liitäntäkortille. Liitäntäkortin ohjelman on löydettävä seuraavan etapin IP-osoitetta vastaava laiteosoite esimerkiksi ARP-protokollalla (ks. luku 5). Tietokone A ei kuitenkaan ole vielä saanut BOOTP-vastausta, joten se ei tiedä omaa IP-osoitettaan eikä voi siten vastata B:n ARP-kyselyyn. B:llä on näin ollen vain kaksi vaihtoehtoa: se voi joko lähettää vastauksen yleislähetyksenä tai se voi lisätä pyynnössä olevat tiedot omaan ARP-välimuistiinsa. Järjestelmissä, jotka eivät salli sovellusten tekevän muutoksia ARP-välimuistiin yleislähetys on ainoa ratkaisu. 23.4 BOOTP:n uudelleenlähetyskäytäntö BOOTP:tä käyttävän asiakkaan on itse vastuussa siitä, että kommunikointi on luotettavaa. Koska UDP käyttää IP:tä sanomien kuljettamiseen, viipeet voivat olla pitkiä, sanomia voi kadota, ne voivat saapua perille väärässä järjestyksessä tai ne voivat monistua. Lisäksi IP ei sisällä virheentarkistuksessa tarvittavaa tarkistussummaa, joten siirtovirheet voivat jäädä huomaamatta. Tämän vuoksi BOOTP edellyttää, että UDP käyttää tarkistussummia. Se määrittää lisäksi, että sanomien älä lohko (do not fragment) -bitti on asetettu, jotta myös asiakkaat, joiden muisti ei riitä sanomien uudelleen kokoamiseen, pystyvät vastaanottamaan sanomat. BOOTP voi myös vastaanottaa useita vastauksia. Se kuitenkin käsittelee vain ensimmäisen. Tietosähkeiden katoamistapauksissa BOOTP käyttää tavanomaista aikakatkaisu- ja uudelleenlähetystekniikkaa. Asiakas käynnistää ajastimen, lähettäessään pyynnön. Jos aikakatkaisu tapahtuu ennen vastuksen saapumista, asiakkaan on lähetettävä pyyntö uudelleen. On selvää, että esimerkiksi virtakatkon jälkeen, kun verkon kaikki laitteet käynnistyvät uudelleen samanaikaisesti, ne saattavat ylikuormittaa BOOTP-palvelimen. Jos kaikki asiakkaat valitsevat saman aikakatkaisurajan, myös uudelleenlähetykset tapahtuvat samanaikaisesti. Tämän vuoksi BOOTP-määrityksissä suositellaan ajastimen arvon määrittämistä

446 Luku 23 satunnaisluvulla. Lisäksi määritys suosittaa, että ensimmäinen aikavakio valitaan väliltä 0 4 sekuntia ja että arvo kaksinkertaistetaan jokaisen uudelleenlähetyksen jälkeen. Kun ajastimen arvo on kasvanut 60 sekuntiin, asiakas ei enää kasvata arvoa, vaan valitsee uuden satunnaisluvun. Aikavakion kaksinkertaistamisella pyritään välttämään verkon tukkeutuminen BOOTP-sanomilla. Satunnaislukuja käyttämällä vältetään samanaikaiset uudelleenlähetykset. 23.5 BOOTP-sanoman rakenne Toteutuksen yksinkertaistamiseksi BOOTP-sanomien kentät ovat kiinteänpituisia. Lisäksi vastaus- ja pyyntösanoman rakenne on samanlainen. Edellä sanottiin, että asiakkaat ja palvelimet ovat ohjelmia, mutta BOOTP-protokolla tulkitsee näitä termejä vapaasti. Se kutsuu BOOTP-pyyntöjä lähettävää tietokonetta asiakkaaksi ja vastauksia lähettävää laitetta palvelimeksi. BOOTP-segmentin rakenne on esitetty kuvassa 23.1. Kuva 23.1 BOOTP-sanoman rakenne.

Automaattinen asetusmääritys käynnistettäessä (BOOTP, DHCP) 447 Kaikki kentät ovat kiinteänpituisia, jotta koodi saataisiin mahtumaan pieneen ROMmuistiin. OP-kenttä määrittää, onko sanoma pyyntö (1) vai vastaus (2). HTYYPPI- ja HPITkentät määrittävät fyysisen verkon tyypin ja laiteosoitteen pituuden, kuten ARP-protokollassa (esimerkiksi Ethernetin tyyppi on 1 ja osoitteen pituus 6). Asiakas sijoittaa nollan ETAPITkenttään. BOOTP-palvelin kasvattaa ETAPIT-laskurin arvoa, jos se päättää lähettää pyynnön eteenpäin toiselle laitteelle (käynnistystiedot voidaan esimerkiksi pyytää useiden reitittimien kautta). TAPAHTUMATUNNUS-kenttä sisältää kokonaisluvun, joka avulla asiakkaat tunnistavat saapuvat sanomat. SEKUNNIT-kenttä määrittää, montako sekuntia on kulunut asiakkaan käynnistymisestä. ASIAKKAAN IP-OSOITE -kenttä ja sitä seuraavat kentät sisältävät tärkeimmät tiedot. Asiakkaat täyttävät kaikki ne kentät, jotka ne pystyvät täyttämään ja asettavat muut kentät nolliksi. Jos asiakas esimerkiksi tietää palvelimen nimen tai osoitteen, se voi täyttää PALVE- LIMEN IP-OSOITE- tai PALVELIMEN NIMI -kentän. Jos nämä kentät eivät ole tyhjiä, vain se palvelin, joka kentissä on määritetty, vastaa pyyntöön. Jos kentät ovat tyhjiä, mikä tahansa palvelin voi lähettää vastauksen. BOOTP-pyynnön voi lähettää myös sellainen asiakas, jolla jo on IP-osoite (esimerkiksi saadakseen muita tarvitsemiaan tietoja). Jos asiakas tietää IP-osoitteensa se tallentaa osoitteen ASIAKKAAN IP-OSOITE -kenttään. Muussa tapauksessa kenttä sisältää nollan. Jos tämän kentän arvo on nolla, palvelin antaa asiakkaalle IP-osoitteen, jonka se tallentaa UUSI IP- OSOITE -kenttään. 23.6 Kaksivaiheinen käynnistysprosessi Käynnistysprosessi on BOOTP-protokollaa käytettäessä kaksivaiheinen. BOOTP ei lähetä asiakkaille käyttöjärjestelmää. Se ainoastaan antaa tiedot, joita käyttämällä asiakas voi hankkia tarvitsemansa ohjelmat. Käyttöjärjestelmän asiakas lataa toista protokollaa (esimerkiksi luvussa 26 esiteltyä TFTP-protokollaa) käyttämällä. Käynnistysprosessin suorittaminen kahdessa vaiheessa saattaa näyttää tarpeettomalta, mutta näin asetustiedot voidaan pitää muista tiedoista erillään. BOOTP-palvelimen ei tarvitse toimia samassa tietokoneessa, johon käyttöjärjestelmät on tallennettu. BOOTP-palvelin käyttää itse asiassa yksinkertaista tietokantaa, joka sisältää vain käyttöjärjestelmien nimet. Asetustietojen pitäminen erillään käyttöjärjestelmätiedostoista on tärkeää, koska näin verkonhallitsijat voivat määrittää tietokoneille samanlaiset tai erilaiset asetukset. Tarkastellaan esimerkiksi BOOTP-sanoman KÄYNNISTYSTIED. NIMI -kentän käyttöä. Oletetaan, että verkkoon on liitetty useita työasemia, joiden laitekokoonpanot vaihtelevat ja oletetaan, että käyttäjät voivat työasemaa käynnistäessään valita joko UNIXin tai laitteen oman käyttöjärjestelmän. Koska työasemien laitekokoonpanot ovat erilaiset, niissä ei voi käyttää samanlaista käyttöjärjestelmäkokoonpanoa. Tätä varten BOOTP-pyynnön KÄYNNISTYSTIED. NIMI -kenttään voidaan tallentaa jokin yleinen nimi, kuten unix, jolla asiakas voi sanoa: Haluan ladata tähän koneeseen UNIX-käyttöjärjestelmän. BOOTP-palvelin etsiin asetustietokannasta pyynnön lähettäneen työaseman kokoonpanoa vastaavan UNIX-käyttöjärjestelmätiedoston nimen ja palauttaa nimen (täydellinen tiedostonimi) vastauksessa. Asetustieto- HTYYPPI-kentän arvot on määritetty Assigned Numbers RFC-dokumentissa.

448 Luku 23 kanta sisältää myös oletuskäyttöjärjestelmän nimen, joten jos asiakas jättää KÄYNNIS- TYSTIED. NIMI -kentän tyhjäksi, BOOTP-palvelin palauttaa asiakkaalle ohjelmatiedoston nimen oletusarvon. Tämän menetelmän etu on se, että käyttäjät voivat käyttää yleisiä nimiä kaikissa työasemissa. Heidän ei tarvitse muistaa työasemakohtaisia tiedostonimiä. 23.7 Valmistajakohtainen kenttä VALMISTAJAKOHTAINEN ALUE sisältää valinnaisia tietoja, joita palvelin voi tarvittaessa lähettää asiakkaalle. Käytetty syntaksi on konstikas, mutta ei vaikea. Kentän neljästä ensimmäisestä oktetista käytetään nimeä taikaeväs (magic cookie), joka määrittää muiden tietojen muodon. Tässä esiteltävässä rakenteessa (standardi muoto) nämä oktetit sisältävät arvon 99.130.83.99 (pisteillä erotetussa desimaalimuodossa). Kentän loppuosa sisältää tietueita, joista kukin sisältää yhden oktetin pituisen tyypin, valinnaisen pituuden (yksi oktetti) ja arvon (useita oktetteja). Standardi määrittää seuraavat tyypit, joilla on määrätyt kiinteänpituiset arvot: Tyyppi Koodi Arvon pituus Arvon sisältö Täyte 0 - Nolla - käytetään vain täytteenä Aliverkon peite 1 4 Lähiverkon aliverkkopeite Kellonaika 2 4 Kellonaika yleisajan mukaan Loppu 255 - Luettelon loppu Kuva 23.2 Valmistajakohtaisen kentän sisältämät tietueet. Pituus-kenttä on määritettävä tyypeille 1 ja 2. Muissa tyypeissä sitä ei käytetä. Vaikka tietokone voi pyytää aliverkon peitteen ICMP-sanomalla, standardi suosittelee, että BOOTP-palvelimet lähettävät peitteen jokaisen vastauksen mukana, jotta ICMP-sanomaa ei tarvitse lähettää. Muissa valmistajakohtaisen alueen tietueissa käytetään TLV-koodausta. Kukin tietue sisältää tyyppi-oktetin, pituus-oktetin ja arvon. Käytetyt arvot on esitetty kuvassa 23.3. 23.8 Asetusten määrittäminen dynaamisesti BOOTP suunniteltiin suhteellisen staattisiin ympäristöihin, joissa tietokoneet on liitetty pysyvästi verkkoon. Verkonhallitsija luo BOOTP-asetustiedoston, joka sisältää jokaisen tietokoneen BOOTP-parametrit. Tiedosto muuttuu vain harvoin, koska asetukset ovat tavallisesti pysyviä. Asetukset säilyvät muuttumattomina tavallisesti useita viikkoja. Langattomat verkot ja kannettavat tietokoneet ovat tehneet mahdolliseksi sen, että tietokone voidaan siirtää paikasta toiseen nopeasti ja helposti. BOOTP ei sovellu tällaiseen käyttöön, koska asetustiedot saattavat muuttua nopeasti. BOOTP pystyy lähettämään tietokoneelle vain tuota laitetta varten etukäteen määritetyt staattiset parametrit. Lyhenne TLV tulee sanoista Type Length Value (Tyyppi Pituus Arvo).

Automaattinen asetusmääritys käynnistettäessä (BOOTP, DHCP) 449 Tyyppi Koodi Pituusoktetti Arvon sisältö Reitittimet 3 N N/4 kpl reitittimien IP-osoitteita Kellopalvelin 4 N N/4 kpl kellopalvelimien IP-osoitteita IEN116 -palvelin 5 N N/4 kpl IEN 116 -palvelinten IP-osoitteita Toimialuepalvelin 6 N N/4 kpl DNS-palvelinten IP-osoitteita Lokipalvelin 7 N N/4 kpl lokipalvelinten IP-osoitteita Päivän mietelause -palvelin 8 N N/4 kpl päivän mietelause -palvelinten IP-osoitteita Lpr-palvelimet 9 N N/4 kpl lpr-palvelinten IP-osoitteita Impress 10 N N/4 Impress -palvelinten IP-osoitteet RLP-palvelin 11 N N/4 kpl RLP-palvelinten IP-osoitteita Isäntänimi 12 N N-tavun pituinen isäntänimi Käynnistystied. pituus 13 2 Käynnistystiedoston pituus (2-tavuinen kokonaisluku) VARATTU 128-254 - Varattu toimipaikan omaan käyttöön Kuva 23.3 BOOTP-vastaussanoman valmistajakohtaisen alueen tietueiden tyypit ja sisältö. Verkonhallitsijan on kirjoitettava joukko parametreja jokaista tietokonetta varten ja tallennettava tiedot BOOTP-palvelimen asetustiedostoon. BOOTP ei sisällä menetelmää, jolla tiedot voitaisiin määrittää dynaamisesti. Erityiden tärkeää on, että verkonhallitsija määrittää jokaiselle tietokoneelle IP-osoitteen ja laatii määritykset, joiden perusteella palvelin tietää, mille tietokoneelle mikin IP-osoite kuuluu. Kiinteiden parametriarvojen käyttäminen on hyvä ratkaisu, jos verkon tietokoneiden määrä on vakio eikä tietokoneita siirrellä ja käytettävissä on riittävästi IP-osoitteita. Kuitenkin, jos tietokoneita siirretään usein tai tietokoneita on enemmän kuin IP-osoitteita, kiinteiden parametriarvojen käyttäminen on työlästä. Kuinka sitten on mahdollista, että tietokoneita voi olla enemmän kuin IP-osoitteita? Asian ymmärtää, kun tarkastellaan yliopiston tietokonelaboratorion lähiverkkoa, jossa käytetään /24- tyyppistä osoitetta (eli verkossa voi olla 254 tietokonetta). Oletetaan, että laboratoriossa on vain 30 paikkaa, mutta opiskelijoita on 300, joten opiskelijat on jaettava 10 ryhmään. Oletetaan lisäksi, että kullakin opiskelijalla on oma kannettava tietokone, jota he käyttävät laboratoriossa. Verkkoon samanaikaisesti liitetty enintään 30 tietokonetta. Koska käytössä oleva osoitetyyppi mahdollistaa kuitenkin vain 254 IP-osoitetta, verkonhallitsija ei voi antaa jokaiselle tietokoneelle yksilöllistä IP-osoitetta. Näin ollen, vaikka resurssirajoitusten eli liitäntöjen määrän vuoksi verkkoon voidaan samanaikaisesti liittää vain 30 tietokonetta, verkkoa käyttävien tietokoneiden määrä on paljon suurempi. On selvää, että verkonhallitsija ei voi muuttaa palvelimen asetustietokannan asetuksia manuaalisesti joka kerran, kun tietokoneita liitetään verkkoon tai poistetaan siitä. Tarvitaan siis automaattinen menetelmä.

450 Luku 23 23.9 Asetusten määrittäminen dynaamisesti IETF on suunnitellut uuden protokollan, jolla IP-osoitteet määritetään automaattisesti. Tämä nimellä DHCP (Dynamic Host Configuration Protocol) tunnettu protokolla laajentaa BOOTP-protokollan toimintoja kahdella tavalla. Ensiksi tietokone saa kaikki tarvitsemansa kokonpanotiedot yhdessä sanomassa. DHCP-sanoma voi IP-osoitteen lisäksi sisältää myös aliverkon peitteen. Toiseksi DHCP-palvelin määrittää tietokoneen IP-osoitteen dynaamisesti käytettävässä olevasta varannosta. Tätä varten verkonhallitsijan on tallennettava palvelimen asetustietokantaan käytettävissä olevat IP-osoitteet. Kun uusi tietokone liittyy verkkoon, se ottaa yhteyden palvelimeen ja pyytää osoitetta. Palvelin valitsee varannosta yhden osoitteen ja antaa sen tietokoneelle. Jotta järjestelmä olisi joustava, osoitteet voidaan määrittää kolmella tavalla. Verkonhallitsija päättää, mitä tapaan kuhunkin verkkoon tai tietokoneeseen sovelletaan. BOOTPprotokollan tapaan DHCP-protokolla sallii manuaalisen asetusmäärityksen eli verkonhallitsija voi määrittää osoitteet tietokonekohtaisesti. Toinen tapa on automaattinen asetusmääritys, joka tarkoittaa sitä, että DHCP-palvelin antaa tietokoneelle pysyvän osoitteen, kun tietokone liitetään verkkoon. Kolmas tapa on dynaaminen asetusmääritys, jolloin palvelin lainaa tietokoneelle IP-osoitteen määräajaksi. BOOTP-protokollan tapaan DHCP päättää menettelytavan asiakkaan tunnisteen mukaan. Ottaessaan yhteyden DHCP-palvelimeen, asiakas lähettää tunnisteensa, joka tavallisesti on asiakkaan laiteosoite. Palvelin määrittää asiakkaalle annettavan IP-osoitteen asiakkaan tunnisteen ja sen verkon mukaan, johon asiakas on liitetty. Verkonhallitsija voi siten tarkkaan hallita osoitteiden käyttöä. Palvelin voidaan määrätä antamaan tiettyjen tietokoneiden osoitteet staattisesti (kuten BOOTP), kun taas muille tietokoneille annetaan pysyvät tai tilapäiset osoitteet dynaamisesti. 23.10 IP-osoitteiden antaminen dynaamisesti DHCP:n uusi ja merkittävin ominaisuus on se, että osoitteet antaa dynaamisesti. Kun osoitteet varataan dynaamisesti, niillä ei ole yhtä kiinteätä vastaanottajaa, kuten BOOTPprotokollassa, eikä asiakkaiden tunnisteita tarvitse määrittää palvelimeen etukäteen. DHCPpalvelin voi sen sijaan antaa IP-osoitteen mille tahansa tietokoneelle. DHCP-protokolla mahdollistaa siten järjestelmän asetuksen määrittämisen automaattisesti. Kun tietokone liitetään verkkoon, se pyytää IP-osoitteen DHCP-palvelimelta ja määrittää sitten TCP/IPohjelmistonsa asetukset saamansa osoitteen mukaisesti. Verkonhallitsija luonnollisesti päättää, mitkä DHCP-palvelimet sallivat asetusten määrittämisen automaattisesti. Lyhyesti sanottuna: DHCP mahdollistaa asetusten määrittämisen automaattisesti, koska se pystyy antamaan tietokoneelle sen tarvitsemat parametrit ilman manuaalisia toimenpiteitä. Automaattisten asetusmääritysten käytön laajuudesta päättää verkonhallitsija.

Automaattinen asetusmääritys käynnistettäessä (BOOTP, DHCP) 451 Jotta osoitteiden automaattinen käsittely olisi mahdollista, verkonhallitsija antaa DHCPpalvelimen hallitavaksi joukon IP-osoitteita. Verkonhallitsija määrittää säännöt, joiden mukaan palvelimen on toimittava. DHCP-asiakas pyytää osoitetta lähettämällä palvelimelle sanoman. Palvelin vastaa lähettämällä osoitteen ja asiakas hyväksyy osoitteen lähettämällä kuittauksen. Kun asiakas on hyväksynyt osoitteen, se voi alkaa käyttää sitä. Dynaamisesti varattu osoite on voimassa määräajan, toisin kuin staattista osoitemääritystä käytettäessä, jolloin tietokone saa pysyvän osoitteen. Sen vuoksi sanotaankin, että DHCPpalvelin antaa asiakkaalle osoitteen käyttöluvan (lease) määräajaksi. Palvelin ilmoittaa käyttöluvan voimassaoloajan, kun se lähettää osoitteen. Palvelin ei anna osoitetta toiselle asiakkaalle osoitteen voimassaoloaikana. Kun voimassaoloaika päättyy, asiakkaan on lähetettävä uusintapyyntö tai lopetettava osoitteen käyttäminen. Kuinka pitkä voimassaoloajan tulisi olla? Ihanteellinen aika määräytyy verkon ja tietokoneen tarpeiden mukaan. Jos esimerkiksi halutaan varmistaa, että osoitteita voidaan käyttää nopeasti uudelleen, yliopiston laboratorion verkkoon liitetyille opiskelijoiden tietokoneille kannattaa antaa lyhyt voimassaoloaika (esimerkiksi yksi tunti). Toisaalta yrityksen verkossa voimassaoloaika voisi olla yksi päivä tai viikko. Jotta DHCP:tä voitaisiin käyttää erilaisissa ympäristöissä, voimassaoloaikaa ei määritetä kiinteästi. Sen sijaan asiakas voi pyytää itselleen sopivaa voimassaoloaikaa ja palvelin voi ilmoittaa asiakkaalle, mikä on käyttöajan pituus. Verkonhallitsija voi siten päättää, kuinka pitkäksi ajaksi palvelin antaa osoitteet asiakkaille. Ääritapauksessa DHCP voi antaa osoitteen asiakkaalle toistaiseksi, kuten BOOTP-protokolla. 23.11 Useiden osoitteiden pyytäminen Moniosoitteinen tietokone on liitetty useaan verkkoon. Kun tällainen tietokone käynnistyy, sen on pyydettävä asetustiedot jokaista liitäntää varten. BOOTP-sanoman tapaan DHCP-sanoma sisältää vain tiedot vain yhtä liittymää varten. Jos tietokoneella on useita verkkoliittymiä, sen on käsiteltävä kukin liittymä erikseen. Näin ollen, vaikka tekstin perusteella näyttäisikin siltä, että jokainen tietokone tarvitsee vain yhden osoitteen, lukijan on muistettava, että moniosoitteisen tietokoneen eri liitännät voivat olla protokollan suhteen eri asemassa. Sekä BOOTP että DHCP sallivat toiseen verkkoon liitetyn tietokoneen ottavan yhteyden palvelimeen niin sanotun välitysagentin (relay agent) kautta. Kun välitysagentti vastaanottaa yleislähetyssanoman asiakkaalta, se lähettää sanoman palvelimelle ja palauttaa palvelin lähettämän vastauksen asiakkaalle. Välitysagenttien käyttäminen voi tehdä moniosoitteisen tietokoneen asetusmäärityksen monimutkaisemmaksi, koska palvelin saattaa saada useita pyyntöjä samalta tietokoneelta. Koska sekä BOOTP- että DHCP-protokolla kuitenkin määrittävät termin asiakastunniste, voidaan olettaa, että moniosoitteinen asiakas lähettää arvon, joka yksilöi liitännän (esimerkiksi yksilöllinen laiteosoite). Palvelin pystyy siten aina erottamaan moniosoitteisen tietokoneen lähettämät pyynnöt toisistaan, vaikka sanomat saapuisivatkin välitysagentin kautta.

452 Luku 23 23.12 Osoitteen hankkimisen eri vaiheet Hankkiessaan IP-osoitteen DHCP-palvelimelta asiakas vaihtaa tilaansa kuusi kertaa. Kuvan 23.4 tilanvaihtokaaviosta nähdään tapahtumat ja sanomat, joiden mukaan asiakas vaihtaa tilansa. Kun asiakas käynnistyy, se menee INITIALIZE-tilaan. Asiakas aloittaa osoitteen hankintaprosessin ottamalla yhteyden paikallisen verkon DHCP-palvelmiin. Yhteydenotto tapahtuu lähettämällä DHCPDISCOVER-yleislähetyssanoma. Sitten asiakas siirtyy SELECTtilaan. Koska protokolla on BOOTP-protokollan laajennus, asiakas lähettää DHCPDISCOVERsanoman UDP-tietosähkeessä, jonka porttiosoitteeksi se asettaa BOOTP-portin (67). Kaikki paikallisen verkon DHCP-palvelimet vastaanottavat sanoman ja ne palvelimet, jotka on ohjelmoitu vastaamaan tuolle asiakkaalle, lähettävät DHCPOFFER-sanoman. Asiakas saattaa siten saada useita vastauksia tai ei yhtään. Olleessaan edelleen SELECT-tilassa asiakas kerää DHCP-palvelimilta tulevat DHCPOF- FER-sanomat. Kukin vastaus sisältää asetustiedot ja IP-osoitteen, jonka käyttölupaa palvelin tarjoaa asiakkaalle. Asiakkaan on valittava yksi tarjouksista (esimerkiksi ensimmäinen) ja neuvoteltava palvelimen kanssa osoitteen käyttöluvasta. Tätä varten asiakas lähettää DHCP- REQUEST-sanoman ja siirtyy REQUEST-tilaan. Palvelin kuittaa vastaanottaneensa pyynnön ja aloittavansa osoitteen käyttämisen lähettämällä DHCPACK-sanoman. Kun asiakas vastaanottaa kuittauksen, se siirtyy BOUND-tilaan ja aloittaa osoitteen käyttämisen. Lyhyesti sanottuna: Tietokone ryhtyy DHCP-asiakkaaksi lähettämällä yleislähetyssanoman jokaiselle paikallisen verkon DHCP-palvelimelle. Tietokone kerää palvelimilta tulevat tarjoukset, valitsee niistä yhden ja lähettää palvelimelle hyväksymiskuittauksen. 23.13 Osoitteen käytön ennenaikainen lopettaminen BOUND-tila on normaali toimintatila, asiakas pysyy BOUND-tilassa niin kauan kuin se käyttää saamaansa IP-osoitetta. Jos asiakkaalla on käytössään muistiväline (esimerkiksi levy), asiakas voi tallentaa saamansa IP-osoitteen ja voi pyytää saman osoitteen käynnistyessään uudelleen seuraavan kerran. Joissakin tapauksissa asiakas voi kuitenkin BOUND-tilassa ollessaan havaita, että se ei enää tarvitse IP-osoitetta. Asiakas voi esimerkiksi liittää kannettavan tietokoneensa verkkoon, pyytää IP-osoitteen DHCP-palvelimelta ja lukea sitten sähköpostiviestit TCP/IP:llä. Käyttäjä ei ehkä tiedä, kauanko sähköpostin lukeminen kestää tai kannettava tietokone saattaa antaa palvelimen määrittää voimassaoloajan. DHCP määrittää kummassakin tapauksessa minimiajan, joka on yksi tunti. Kun käyttäjä on lukenut sähköpostinsa, hän saattaa sulkea tietokoneen ja siirtyä toiseen paikkaan. DHCP sallii asiakkaan lopettavan osoitteen käyttämisen ennen käyttöajan päättymistä, jos asiakas ei enää tarvitse osoitetta. Tällainen menettely on käytännöllinen silloin, kun asiakas tai palvelin ei osoitteen käyttämistä aloitettaessa tiedä, kauanko osoitetta tarvitaan, koska näin palvelin voi valita kohtuullisen pitkän voimassaoloajan. Osoitteen käyttämisen lopettaminen ennenaikaisesti on erityisen tärkeää silloin, kun palvelimella on käytettävissään IP-osoitteita paljon vähemmän kuin verkossa on tietokoneita. Jos kukin asiakas ilmoittaa lopettavansa

Automaattinen asetusmääritys käynnistettäessä (BOOTP, DHCP) 453 osoitteen käyttämisen heti, kun se ei enää tarvitse osoitetta, palvelin voi antaa osoitteen toiselle asiakkaalle. Laite käynnistyy INITIALIZE / DHCPDISCOVER SELECT DHCPOFFER Yhden tarjouksen valitseminen / DHCPREQUEST DHCPNACK tai käyttöaika päättyy REBIND DHCPNACK 87,5 % käyttöajasta on kulunut / DHCPREQUEST RENEW DHCPACK REQUEST DHCPACK DHCPACK BOUND 50%käyttöajasta on kulunut / DHCPREQUEST Osoitteen käyttäminen lopetetaan / DHCPRELEASE Kuva 23.4 DHCP-asiakkaan kuusi toimintatilaa ja niiden väliset siirtymät. Siirtymäluettelon otsakkeet nimeävät saapuvat sanomat tai tapahtumat, jotka aiheuttavat siirtymisen tilasta toiseen. Otsakkeen perässä on asiakkaan lähettämä sanoma. Jos asiakas lopettaa osoitteen käyttämisen ennenaikaisesti, se lähettää palvelimelle DHCPRELEASE-sanoman. Kun asiakas vapauttaa osoitteen, se ei saa enää käyttää sitä. Toisin sanoen, kun asiakas on lähettänyt DHCPRELEASE-sanoman, se ei saa lähettää tuon osoitteen sisältäviä tietosähkeitä. Kuvan 23.4 tilakaavion mukaan asiakas, joka lähettää DHCP- RELEASE-sanoman, poistuu BOUND-tilasta ja sen on aloitettava uudelleen INITIALIZEtilasta, jos se haluaa IP-osoitteen.

454 Luku 23 23.14 Käyttöluvan uusimistilat Edellä sanottiin, että DHCP-asiakas siirtyy BOUND-tilaan, kun se saa osoitteen. Kun asiakas aloittaa osoitteen käyttämisen, se käynnistää kolme ajastinta, joista yksi ilmoittaa käyttöluvan uusimisajan, yksi uudelleensitomisajan ja yksi päättymisajan. DHCP-palvelin voi määrittää ajastimien arvot antaessaan osoitteen asiakkaalle. Jos palvelin ei määritä aikoja, asiakas käyttää oletusarvoja. Oletusarvo ensimmäiselle ajastimelle on puolet käyttöluvan voimassaoloajasta. Kun ensimmäinen aikaraja umpeutuu, asiakkaan on yritettävä uudistaa käyttölupa. Tätä varten asiakas lähettää DHCPREQUEST-sanoman sille palvelimelle, jolta se sai käyttöluvan. Sen jälkeen asiakas siirtyy RENEW-tilaan odottamaan vastausta. DHCPREQUEST-sanoma sisältää asiakkaan käytössä olevan IP-osoitteen, jonka käyttölupaa se yrittää jatkaa. Asiakas voi määrittää pyynnössä jatkoajan pituuden, mutta viime kädessä palvelin määrittää, kuinka pitkän jatkoajan asiakas saa. Palvelin voi vastata pyyntöön kahdella tavalla: se voi määrätä asiakkaan lopettamaan osoitteen käyttämisen tai se voi hyväksyä pyynnön. Jos palvelin hyväksyy pyynnön, se lähettää DHCPACK-sanoman, jonka saatuaan asiakas siirtyy uudelleen BOUND-tilaan ja jatkaa osoitteen käyttämistä. DHCPACK-sanoma voi sisältää myös uudet määräajat ajastimille. Jos palvelin ei hyväksy pyyntöä, se lähettää DHCPNACK-sanoman (kielteinen kuittaus), jonka saatuaan asiakas lopettaa heti osoitteen käyttämisen ja palaa INITIALIZE-tilaan. Lähetettyään DHCPREQUEST-sanoman, jossa asiakas pyytää jatkoaikaa käyttöluvalle, se asettuu RENEW-tilaan odottamaan vastausta. Jos vastausta ei tule, palvelin, joka antoi käyttöluvan, on joko pois käytöstä tai tavoittamattomissa. Tätä varten DHCP määrittää toisen ajastimen, joka käynnistettiin, kun asiakas siirtyi BOUND-tilaan. Toisen ajastimen toimintaaika on 87,5 % käyttöluvan voimassaoloajasta. Kun tämä aika on kulunut umpeen asiakas siirtyy RENEW-tilasta REBIND-tilaan. Vaihtaessaan tilaansa asiakas olettaa, että alkuperäinen DHCP-palvelin ei ole käytettävissä ja lähettää DHCPREQUEST-yleislähetyssanoman kaikille verkon palvelimille. Mikä tahansa palvelin, jolla on oikeus palvella pyynnön lähettänyttä asiakasta voi lähettää myöntävän vastauksen (eli jatkaa käyttöluvan voimassaoloaikaa) tai kieltävän vastauksen (eli kieltää IP-osoitteen käyttämisen). Jos asiakas saa myöntävän vastauksen se palaa BOUND-tilaan ja käynnistää ajastimet uudelleen. Jos asiakas saa kielteisen vastauksen, sen on heti lopetettava IP-osoitteen käyttäminen, siirryttävä INITIALIZE-tilaan ja pyydettävä uutta IP-osoitetta, jos se haluaa kommunikoida IP:llä. Siirtyessään REBIND-tilaan asiakas jo lähettänyt käyttöluvan voimassaoloajan jatkamispyynnön alkuperäiselle palvelimille ja kaikille muille verkon palvelimille. Siinä epätodennäköisessä tapauksessa, että asiakas ei saa vastausta yhdeltäkään palvelimelta ennen kolmannen ajastimen aikakatkaisua, käyttölupa vanhenee. Asiakkaan on heti lopetettava IP-osoitteen käyttäminen, siirryttävä INITIALIZE-tilaan ja pyydettävä uutta osoitetta.

Automaattinen asetusmääritys käynnistettäessä (BOOTP, DHCP) 455 23.15 DHCP-sanoman rakenne Kuvasta 23.5 nähdään, että DHCP käyttää samaa sanomarakennetta kuin BOOTP, sillä erotuksella, että joidenkin kenttien merkitykset ovat toiset. Kuva 23.5 DHCP-sanoman rakenne, joka vastaa BOOTP-sanoman rakennetta. Optiotkenttä on vaihtuvanpituinen. Asiakkaan on varauduttava ottamaan vastaan vähintään 312 oktettia. Kuten kuva osoittaa, suurin osa DHCP-sanoman kentistä on samoja kuin BOOTPsanomassa. Itse asiassa protokollat ovat yhteensopivia. DHCP-palvelin voidaan ohjelmoida ottamaan vastaan BOOTP-pyyntöjä. DHCP kuitenkin vaihtaa kahden kentän merkityksen. Ensiksi BOOTP-sanoman KÄYTTÄMÄTÖN-kenttä on nyt 16-bittinen LIPUT-kenttä. Kuten kuvasta 23.6 nähdään, vain kentän ylimmälle bitille on määritetty merkitys.

456 Luku 23 0 15 B ON OLTAVA NOLLIA Kuva 23.6 DHCP-sanoman LIPUT-kentän rakenne. Vasemman puoleinen bitti tulkitaan yleislähetysbitiksi. Kaikkien muiden bittien on oltava nollia. Koska DHCP-sanoma sisältää asiakkaan laiteosoitteen, DHCP-palvelin lähettää tavallisesti vastauksen yksiosoitelähetyksenä asiakkaan laiteosoitteella. Asiakas asettaa LIPUTkentän ylimmän bitin ykköseksi, jos se haluaa, että palvelin lähettää vastauksen yleislähetyksenä. Syy siihen, miksi asiakas saattaa haluta vastauksen yleislähetyksenä, selviää, kun muistetaan, että lähettäessään pyynnön, asiakkaalla ei vielä ole IP-osoitetta. Vaikka saapuvassa tietosähkeessä olisikin oikea laiteosoite, mutta jos IP-ohjelmisto ei tunne tietosähkeessä olevaa kohdeosoitetta, IP saattaa hylätä tietosähkeen. Toisaalta IP:n on käsiteltävä kaikki tietosähkeet, joissa on IP-yleislähetysosoite. Varmistaakseen sen, että IP-ohjelmisto hyväksyy ja toimittaa eteenpäin DHCP-sanomat, ennen kuin laitteen IP-osoite on määritetty, DHCP-asiakas voi pyytää palvelinta lähettämään vastaukset IP-yleislähetyksinä. 23.16 DHCP-optiot ja sanomatyypit Yllättävää kyllä DHCP ei lisää uusia kiinteitä kenttiä BOOTP:n sanomarakenteeseen. Lisäksi useimpien kenttien käyttötarkoitus on sama. Esimerkiksi DHCP-sanoman OP-kenttä sisältää samat arvot kuin BOOTP-sanoman OP-kenttä: sanoma on joko pyyntö (1) tai vastaus (2). Lisätiedot, kuten käyttöluvan voimassaoloajan, DHCP ilmoittaa optioilla. Kuvassa 23.7 on esitetty eräs optio, DHCP:n sanomatyyppi, jolla määritetään lähetettävän DHCP-sanoman tyyppi. Optiokentän rakenne on sama kuin valmistajakohtaisen alueen rakenne ja DHCP tukee kaikkia BOOTP-protokollan määrittämiä valmistajakohtaisia tietoja. BOOTP-protokollan tapaan, optio sisältää koodikentän (1 oktetti) ja pituuskentän (1 oktetti), joita seuraa data. Kuten kuva osoittaa, DHCP-sanoman tyypin määrittävä optio on kolmen oktetin pituinen. Ensimmäinen oktetti sisältää koodin 53, toinen sisältää arvon 1 (pituus) ja kolmas sisältää arvon, joka määrittää DHCP-sanoman tyypin.

Automaattinen asetusmääritys käynnistettäessä (BOOTP, DHCP) 457 0 8 16 23 KOODI (53) PITUUS (1) TYYPPI (1-7) TYYPPIKENTTÄ Vastaava DHCP-viestityppi 1 DHCPDISCOVER 2 DHCPOFFER 3 DHCPREQUEST 4 DHCPDECLINE 5 DHCPACK 6 DHCPNACK 7 DHCPRELEASE Kuva 23.7 DHCP-sanoman tyypin määrittävän option rakenne. Taulukossa on lueteltu sallitut arvot ja niiden merkitykset. 23.17 Uudelleenmääritys-optio DHCP-sanoman otsikon PALVELIMEN NIMI- ja KÄYNNISTYSTIEDOSTON NIMI kenttien pituus on useita oktetteja. Jos sanomassa ei tarvitse ilmoittaa näitä tietoja, kentät ovat hukkatilaa. Jotta DHCP-palvelin voisi tallentaa näihin kenttiin muita optioita, protokolla määrittää Uudelleenmääritys-option. Jos sanoma sisältää tämän option, vastaanottaja tietää, että normaalien tietojen sijasta PALVELIMEN NIMI- ja KÄYNNISTYSTIEDOSTON NIMI -kentät sisältävät optioita. 23.18 DHCP ja toimialuenimet Vaikka DHCP pystyy pyydettäessä antamaan tietokoneelle IP-osoitteen, protokolla ei automatisoi kokonaan kaikkia toimia, jotka tarvitaan tietokoneen liittämiseksi pysyvästi yhteisverkkoon. Eräs puute on se, että DHCP ei käytä DNS-järjestelmää. Näin ollen tietokoneen nimen ja DHCP:n antaman IP-osoitteen välinen sidonta on hoidettava erikseen. Millaisen nimen tietokoneen tulisi saada IP-osoitteen mukana? Mahdollisuuksia on kolme. Ensiksi tietokone ei saa nimeä. Vaikka asiakasohjelmia voidaankin suorittaa tietokoneessa, jolla ei ole nimeä, nimettömän tietokoneen käyttäminen voi olla hankalaa. Toiseksi tietokoneelle annetaan automaattisesti nimi IP-osoitteen mukana. Tätä tapaa käytetään nykyään yleisesti, koska nimet voidaan määrittää etukäteen eikä DNS-järjestelmään tarvitse tehdä muutoksia. Järjestelmänhallitsija voi esimerkiksi määrittää paikalliseen DNS-palvelimeen kutakin DHCP-palvelimen hallitsemaa IP-osoitetta vastaavan nimen. Nimien ja osoitteiden välinen sidonta on staattinen eli se tarvitsee tehdä vain kerran. Staattisen sidonnan suurin haitta on se, että tietokoneen nimi vaihtuu, kun se saa uuden osoitteen (esimerkiksi, kun tietokone DNS-palvelua käsitellään yksityiskohtaisesti luvussa 24.

458 Luku 23 siirretään toiseen verkkoon). Kolmanneksi tietokoneelle voidaan antaa pysyvä nimi. Pysyvän nimen käyttäminen on hyvä tapa, koska yhteys tietokoneeseen voidaan aina luoda nimen avulla, riippumatta siitä, missä tietokone kulloinkin on. Pysyvien isäntänimien käyttäminen edellyttää lisämekanismeja. Eräs niistä on DHCP:n ja DNS-järjestelmän välinen yhteistyö. DNS-palvelimen on muutettava osoitteen ja nimen välinen sidonta aina, kun tietokoneelle annetaan IP-osoite ja sidonta on poistettava, kun osoitteen käyttölupa päättyy. Eräs IETF:n työryhmä pohtii parhaillaan DHCP:n ja DNS:n välistä kanssakäymistä, mutta tällä hetkellä ei ole protokollaa, jolla DNS-päivitykset voitaisiin tehdä dynaamisesti. Näin ollen toistaiseksi käytettävissä ei ole protokollaa, joka mahdollistaisi pysyvien isäntänimien ylläpitämisen, kun DHCP vaihtaa tietokoneen IP-osoitteen. 23.19 Yhteenveto BOOTP-protokolla on vaihtoehto RARP-protokollalle tietokoneissa, joiden tarvitsee hankkia itselleen IP-osoite. BOOTP on yleisempi kuin RARP, koska se käyttää UDPprotokollaa, joka mahdollistaa sanomien kuljettamisen reitittimien kautta. BOOTP-protokollan avulla tietokone voi määrittää myös reitittimen osoitteen, tiedostopalvelimen osoitteen ja tietokoneen tarvitseman käyttöjärjestelmän nimen. Lisäksi verkonhallitsijat voivat luoda asetustietokannan, jossa määritetään työasemakohtaisesti sen käyttöjärjestelmätiedoston nimi, joka vastaa työaseman käyttämää yleistä nimeä (kuten unix ). BOOTP on suunniteltu pieneksi ja yksinkertaiseksi, jotta se mahtuisi työaseman ROMmuistiin. Kun asiakas kommunikoi palvelimen kanssa, se käyttää rajoitetun yleislähetyksen määrittävää osoitetta. Asiakkaan on itse huolehdittava siitä, että se lähettää pyynnöt uudelleen, jos palvelin ei vastaa. Uudelleenlähetyksissä käytetään samanlaista eksponentiaalista backoffkäytäntöä, jolla Ethernet pyrkii välttämään yhteentörmäykset. DHCP (Dynamic Host Configuration Protocol), joka kehitettiin BOOTP-protokollan seuraajaksi, tarjoaa useita lisäominaisuuksia. Tärkein niistä on se, että DHCP-palvelin voi antaa IP-osoitteet asiakkaille automaattisesti tai dynaamisesti. Dynaaminen osoitteiden käsittely on tarpeen esimerkiksi langattomissa verkoissa, joihin tietokoneet voivat liittyä ja joista ne voivat erota helposti. DHCP:tä käyttävästä tietokoneesta tulee asiakas. Tietokone lähettää pyynnön DHCP-palvelimille, valitsee yhden saamistaan tarjouksista ja vaihtaa sitten palvelimen kanssa sanomat, jolla sovitaan IP-osoitteen käyttöoikeudesta. Saatuaan IP-osoitteen asiakas käynnistään kolme ajastinta. Kun ensimmäisen ajastimen aika kuluu umpeen, asiakas yrittää uudistaa käyttöluvan. Jos toisen ajastimen aika kuluu umpeen, ennen kuin palvelin on vahvistanut käyttöluvan voimassaolon jatkamisen, asiakas lähettää uudistuspyynnön kaikille muillekin palvelimille. Jos viimeisenkin ajastimen aika umpeutuu, ennen kuin jatkoaika käyttöluvalle on vahvistettu, asiakas lopettaa IP-osoitteen käyttämisen ja aloittaa osoitteen hakuprosessin uudelleen. Kuvassa 23.4 on esitetty osoitteen haku- ja uusimisprosessien tilanvaihdot.

Automaattinen asetusmääritys käynnistettäessä (BOOTP, DHCP) 459 LISÄTIETOJA BOOTP on TCP/IP-protokollaperheeseen kuuluva standardiprotokolla. Croft ja Gilmore [RFC 951]: BOOTP-protokollan virallinen standardi ja BOOTP- sekä RARP-protokollien välinen vertailu. Reynolds [RFC 1084]: valmistajakohtaisen alueen käyttö. Braden [RFC 1123]: valmistajakohtaisen alueen käyttäminen aliverkon peitteen lähettämiseen. Droms [RFC 2131]: DHCP:n määritykset mukaan lukien yksityiskohtainen tilanvaihtoja koskeva kuvaus. Uudistettu versio julkaistaan pian. Alexander and Droms [RFC 2132]: DHCP:n optioiden tulkitseminen ja BOOTP:n valmistajakohtaiset laajennukset. Droms [RFC 1534]; BOOTP- ja DHCP-protokollien yhteensopivuus. HARJOITUKSIA 23.1 BOOTP-sanoma ei sisällä erityistä kenttää kellonajan tallentamista varten, vaan palvelin voi ilmoittaa ajan asiakkaalle valmistajakohtaisissa tiedoissa. Olisiko aikakenttä lisättävä pakolliseksi kentäksi? Perustele myönteinen tai kielteinen vastaus. 23.2 Osoita, että asetustietojen ja käyttöjärjestelmätiedostojen tallentaminen erikseen ei ole hyvä menetelmä. (Asiaa koskevia vihjeitä on RFC 951 -dokumentissa.) 23.3 BOOTP-sanoma on epäjohdonmukainen, koska siinä on kaksi kenttää asiakkaan IP-osoitetta varten ja yksi kenttä käyttöjärjestelmän nimeä varten. Jos asiakas jättää omalle IP-osoitteelleen varatun kentän tyhjäksi, palvelin palauttaa asiakkaan IP-osoitteen toisessa kentässä. Jos asiakas jättää käyttöjärjestelmän tiedostonimelle varatun kentän tyhjäksi, palvelin kirjoittaa nimen siihen. Miksi? 23.4 Lue standardista, miten asiakkaat ja palvelimet käyttävät ETAPIT (HOPS) -kenttää. 23.5 Kun BOOTP-asiakas vastaanottaa vastauksen laitatason yleissanomana, minkä perusteella se voi selvittää, onko vastaus tarkoitettu sille itselleen vai toiselle saman verkon BOOTP-asiakkaalle. 23.6 Aliverkon peitteen lähettäminen tietokoneelle BOOTP-sanomassa ICMP-sanoman sijasta kuormittaa vähemmän muita tietokoneita. Selitä miksi. 23.7 Lue standardista, kuinka DHCP-asiakas ja -palvelin voivat sopia käyttöluvan voimassaoloajan synkronoimatta kellojaan. 23.8 Oletetaan, että levymuistilla varustettu asiakas pyytää IP-osoitetta DHCP-palvelimelta. Jos osoite ja käyttöluvan voimassaoloaika tallennetaan levylle ja tietokone käynnistetään uudelleen käyttöluvan voimassaoloaikana, voiko tietokone käyttää osoitetta edelleen? Perustele myönteinen tai kielteinen vastaus. 23.9 Määrityksen mukaan DHCP-palvelimen antaman osoitteen käyttöluvan lyhin voimassaoloaika on yksi tunti. Voitko kuvitella tilanteen, jossa tästä minimiajasta aiheutuu hankaluuksia? Selitä miksi. 23.10 Lue RFC-dokumentista, kuinka DHCP määrittää uudistus- ja uudelleensitomisajastimien pituuden. Voiko palvelin määrittää vain toisen niistä? Perustele myönteinen tai kielteinen vastaus. 23.11 Kuvan 23.4 tilanvaihtokaaviossa ei ole esitetty uudelleenlähetyksiä. Lue standardista, kuinka monta kertaa asiakkaan olisi lähetettävä pyyntö uudelleen.

460 Luku 23 23.12 Takaako DHCP sen, että asiakas ei esiinny salanimellä (toisin sanoen, voiko DHCP taata, että tietokoneen A asetustietoja ei lähetetä tietokoneelle B)? Pitääkö sama paikkansa BOOTP:n suhteen? Perustele myönteinen tai kielteinen vastaus. 23.13 DHCP määrittää, että asiakkaan on pystyttävä käsittelemään ainakin 312 oktettia optioita. Miksi juuri 312 oktettia? 23.14 Voiko palvelimena toimiva tietokone pyytää osoitteen DHCP-palvelimelta? Jos voi, niin kuinka asiakkaat voivat tavoittaa palvelimen?