S z e g e d i T u d o m á n y e g y e t e m

Számítógép-hálózatok 5. gyakorlat ICMP, DHCP Jánki Zoltán Richárd, Maczák Bálint

Ősz 2018 UNIVERSITAS SCIENTIARUM SZEGEDIENSIS

UNIVERSITY OF SZEGED Department of Software Engineering

2

Tartalomjegyzék Bevezetés ..................................................................................................................................................................................................... 3

ICMP .............................................................................................................................................................................................................. 3 Feladata .................................................................................................................................................................................................. 3 Megvalósítása a TCP/IP architektúrában .................................................................................................................................. 3 Ismertebb ICMP üzenetek ................................................................................................................................................................ 4

DHCP ............................................................................................................................................................................................................. 5 Feladata .................................................................................................................................................................................................. 5 DHCP konfiguráció ............................................................................................................................................................................. 5 DHCP működése .................................................................................................................................................................................. 5

Gyakorlati háttér ...................................................................................................................................................................................... 7 Ping ........................................................................................................................................................................................................... 7

Ping példa ................................................................................................................................................................................................................. 7 Traceroute ............................................................................................................................................................................................. 9

Traceroute példa ................................................................................................................................................................................................ 10 DHCP parancsok ............................................................................................................................................................................... 12

IPv6 ............................................................................................................................................................................................................. 15

Ellenőrző kérdések ............................................................................................................................................................................... 19

Források ................................................................................................................................................................................................... 19

3

Bevezetés Ezen a gyakorlaton két újabb protokollal ismerkedünk meg, melyek segítségével még jobban elmélyedhetünk a hálózatban résztvevő eszközök kommunikációjának és IP-címzésének témakörében. Mindkét protokoll még mindig a TCP/IP architektúra szerinti Hálózati rétegben található, nevezetesen ők lesznek az ICMP (Internet Control Message Protocol) és a DHCP (Dynamic Host Configuration Protocol) protokollok.

ICMP

Feladata Az ICMP csomagokat a host-ok és a router-ek képesek indítani (akik rendelkeznek IP-címekkel), és ezekben a csomagokban hálózati rétegbeli információkat közölnek egymással az eszközök. A protokoll leggyakoribb alkalmazása az ún. hiba jelentés (error reporting). Például, tfh. indítunk egy HTTP kérést a kliensünkkel, azonban válaszként egy hibát kapunk: "Destination network unreachable." Ez a hibaüzenet az ICMP-ből származik. Miért is? Ez tipikusan olyan hiba, amikor egy router nem képes megtalálni a cél alhálózatot, amelyben az elérni kívánt host van. Ilyenkor a router előállít egy ICMP csomagot a megfelelő hibaüzenettel, és visszaküldi a HTTP kérést küldő host-nak (azaz a kliensünknek). De ez nem az egyetlen alkalmazási módja.

Megvalósítása a TCP/IP architektúrában Sokan az ICMP-t az IP protokoll részének tekintik, azonban a TCP/IP architektúra szerint ez mégis fölötte található, egész pontosan az IP payload részt tölti ki (akárcsak a TCP vagy az UDP szegmensek), lásd: 1. ábra.

1. ábra ICMP protokoll beágyazódása

Az ICMP üzenetek tartalmaznak egy Type és egy Code mezőt. A Type mezőben specifikáljuk, hogy milyen típusú ICMP üzenetről van szó, a Code mező segítségével pedig a típuson belül altípusokat különböztetünk meg. Az alábbi táblázat néhány ismertebb ICMP típust nevez meg (2. ábra).

4

2. ábra ICMP üzenet típusok

Ismertebb ICMP üzenetek Ahogy az fentebb tárgyaltuk, az ICMP üzenetek tartalmaznak egy Type és egy Code mezőt, melyek egyértelműen meghatározzák az üzenet "mondanivalóját".

A leggyakrabban előforduló típusok a 0-s és 8-as számmal ellátott echo reply és echo request üzenetek. Ezek tulajdonképpen a közismert ping parancs hatására állnak elő. A pingelési folyamat közismert, kérés-válasz interakción alapszik. Egy host vagy router megpingel egy másik host-ot vagy router-t. Aki kezdeményez, az bocsájt ki egy echo request (8) üzenetet, ha eljut a fogadó félhez, azt feldolgozza, majd válaszol egy echo reply-jal (0).

Egy igen érdekes megfontolást takar a 4-es Type értékkel ellátott üzenet. Ennek a neve source quench, amely a torlódásokat hivatott szabályozni. A működési elve szerint egy túlterhelt router képes volt küldeni egy 4-es típusú ICMP-t a küldő host-nak, mellyel az átvitel mértékét egy alacsonyabb számra korlátoztatta. Erre azonban tanultunk egy elegánsabb megoldást a TCP témakörében (MSS), a szállítási rétegben. Gyakorlatban nagyon ritkán használt megoldás az ICMP-vel végzett torlódáskezelés.

A 3-as típussal jelölt üzenetek mindegyike sikertelen ICMP csomag kézbesítés eredményeként jönnek létre. Ezeket jellemzően a router-ektől kapjuk, amelyek nem találják azt a hálózati eszközt vagy hálózati komponenst (alhálózatot), amellyel mi kapcsolatba szeretnénk lépni. Ezeket soroljuk a "Destination unreachable" kategóriába.

Érdekesség: Az IPv6-os címek bevezetésével megoldást kellett találni az ICMP üzenetek megvalósításához is, így készültek ICMPv6-os üzenetek, melyekkel számos új típus definiálásra került.

5

DHCP

Feladata A címkiosztást eddig csak manuális megoldásokkal vizsgáltuk, azaz mi "pötyögtük be" egyesével, hogy az egyes host-ok és router-ek milyen IP-címeket vegyenek fel a különböző interfészeken. Ez kis hálózatok esetén könnyen kivitelezhető, és talán nincs is értelme az automatizálásnak. Azonban nagy méretű topológiák esetében a statikus IP-címkiosztás igen komoly fejtörést okozhat a rendszergazdák számára. Erre a problémára ad egy kényelmes megoldást a DHCP (Dynamic Host Configuration Protocol) protokoll, melyet magyarul automatikus címkiosztásnak is neveznek.

DHCP konfiguráció A rendszergazdák a router-ek IP-címeit jellemzően statikus módon adják meg, ezzel azokat fixálják, így például az átjáró állandó. Viszont az azonos alhálózatban levő host-ok már automatikus címkiosztással kapnak IP-címeket, azaz DHCP-vel. A DHCP lehetővé teszi, hogy egy host automatikus felvegyen magának egy IP-címet. Az, hogy melyik IP-címet veszi fel az adott host, az konfiguráció kérdése. Lehetőség van arra is, hogy egy host a hálózathoz csatlakozáskor mindig ugyanazt az IP-címet kapja meg, de lehetőség van ún. temporális IP-címekkel is dolgozni, amelyek mindig felszabadulnak, ha a host lecsatlakozik a hálózatról. A DHCP-vel elérhető, hogy akár egy IP-címhez tartozó specifikus maszk is hozzárendelődjön az interfészhez, akár az átjáró címe is vagy akár egy lokális DNS-szerver címe is.

DHCP működése A DHCP - hasonlóan a korábban tanult protokollokhoz - egy kliens-szerver protokoll. A kliens a hálózathoz újonnan csatlakozó host lesz, a szerver pedig egy ún. DHCP szerver. A legegyszerűbb esetben, mint alhálózatban található egy ilyen DHCP szerver. (Amennyiben mégsem, olyankor egy ún. DHCP relay-agent az (jellemzően egy router), aki ismeri a DHCP szerver címét (3. ábra)).

3. ábra DHCP szerver relay-agent-tel megvalósítva

6

Példánkban a legegyszerűbb esetet vizsgáljuk, azaz amikor van az alhálózatban egy DHCP szerver (nincs szükség relay-agent-re). Az automatikus címkiosztás 4 lépésből áll (lásd: 4. ábra). 1. lépés: DHCP szerver felderítés Az újonnan érkező kliensnek meg kell találnia a DHCP szervert. Ezt egy UDP kapcsolaton keresztül valósítja meg a kliens, mégpedig egy beágyazott DHCP felderítő üzenetet (DHCP discover message) küld a 67-es portra. (A yiaddr mező a "your IP address"-re utal.) Ki a cél? Erről nincs információnk, még arról sem, hogy melyik alhálózatban található. Épp ezért kiküldi az üzenetet egy szórásos címre (255.255.255.255), amelyet mindenki meg fog kapni, és elküldi a yiaddr mezőben a 0.0.0.0-t (azaz még nem kapott IP-címet). 2. lépés: DHCP szerver ajánlás(ok) A DHCP szerver fogadja a szórásos címre küldött üzenetet, és válaszol egy DHCP ajánló üzenettel (DHCP offer message). Ismét felmerül a kérdés, hogy kinek küldje el? Ő is a szórásos címet választja (255.255.255.255), de a port szám, amelyre küldi az üzenetet az a 68-as. Az ajánló üzenet már tartalmazza a kínált IP-címet (223.1.2.4), tranzakciós azonosítót (hogy a kliens meg tudja különböztetni, hogy mely DHCP szerver válaszolt, ha esetleg több is van az alhálózatban), illetve egy Lifetime mezőt, mely az IP-cím érvényességének idejét határozza meg. Ez az érvényességi idő jellemzően több óra vagy akár nap is szokott lenni. 3. lépés: DHCP kérés A kliens fogadja az ajánlatot (vagy ajánlatokat, ha többet is kapott), és választ. A választás egy DHCP kérés üzenettel (DHCP request message) rögzítődik, melyet visszaküld ismét a szervernek, de itt már ismert a szerver helyi IP-címe. Ebben rögzítődik a konfiguráció. 4. lépés: DHCP ACK A szerver fogadja a kérést, és visszaválaszol egy DHCP ACK üzenettel (DHCP ACK message), mellyel megerősíti a kért paramétereket. Amikor a kliens megkapja a DHCP ACK üzenetet, a 4 lépéses folyamat véget ért, és felveheti a felkínált és elfogadott IP-címet a rögzített időtartamra. Előfordulhat természetesen, hogy a kliens a határidőn (Lifetime) túl is szeretné a címet használni. Erre egy ún. "megújító" (renew) mechanizmust kínál a DHCP protokoll.

7

Gyakorlati háttér A következőkben megvizsgáljuk azokat az operációs rendszerbeli programokat, amelyekkel generálhatunk ICMP üzeneteket, és megnézzük, hogy a Wireshark milyen csomagadatokat jelenít meg.

Ping A pingelés egyfajta tesztelésként szolgál a hálózatban. Segít abban, hogy a hálózat különböző komponensei, és azon belül az egyes host-ok elérhetőek-e a pingelő eszköz számára. A legtöbb TCP/IP implementáció közvetlenül támogatja a pingelést az operációs rendszerben. Az interneten számos forráskód elérhető a ping kliens programhoz.

Ping példa Teszteljük a ping parancs működését és kimenetét! A pingelés legegyszerűbb kivitelezése az, ha nyitunk egy Parancssort (Windows alatt) vagy Terminált (Unix rendszereken), és kiadjuk a ping utasítást. A parancs szintaxisa igen egyszerű:

ping [-option] destination

Ez a ping általános paraméterezése. A parancsot követően megadhatunk különböző opciókat, valamint fontos, hogy minden esetben meg kell adnunk a célállomás nevét/IP-címét. Ha több állomást szeretnénk megpingelni, akkor az állomások listáját kell megadnunk. Az alábbi táblázat egy útmutatást ad az opciók használatára a teljesség igénye nélkül egy-egy példával.

Opció Megnevezés Példa

-t A megadott állomás folyamatos pingelése megszakításig (CTRL+C)

ping -t www.google.com

-n [number] Egy állomás irányába indított ICMP üzenetek száma

ping -n 10 www.google.com

-S [source address]

Előfordulhat, hogy több interfésszel is rendelkezik a gépünk (pl.: vezeték nélküli és Ethernet), és szeretnénk specifikálni, hogy melyikről indítsuk a ping-elést

ping -S 192.168.0.1 www.google.com

-4 IPv4-es címek használatának kikényszerítése

ping -4 www.google.com

Indítsunk ICMP üzeneteket a kanadai Macleans magazin web-szervere felé (www.macleans.ca)!

8

4. ábra ping parancs futtatása parancssorban

Eredményképp megkaptuk a web-szerver IP-címét, az egyes csomagokra mennyi időn belül érkezett válasz, illetve végül egy teljes statisztikát a pingelési folyamatról. A web-szerver IP-címe: 77.234.72.18 Átlagos válaszidő: 12 ms Veszteség: 4/0 (0%) Tekintsük meg a Wireshark monitorozás eredményét is!

5. ábra Wireshark ping info

Láthatjuk, hogy a ping-elés következtében ICMP echo request és echo reply típusú üzenetek mentek keresztül az interfészünkön. A ping-elés indításakor a host-unk indított egy echo request-et, válaszként pedig a web-szerver egy echo reply-t küldött. Nézzük meg az összetartozó kérés-válasz csomagok részleteit!

9

6. ábra ICMP Echo Request részletek (ping)

7. ábra ICMP Echo Reply részletek (ping)

Nem meglepő módon a korábban vizsgált táblázatban leírt kódok megtalálhatóak a részletes csomaginformációk között. Az 5. ábrán szereplő csomag az első ICMP kérés volt, így a Type mezőben 8-as szerepel, a Code mezőben pedig 0. A 6. ábrán a válasz csomag látható, melyben a Type mezőben 0 található, és a Code is 0. Van azonban egy nagyon meglepő jelenség, amelyhez kicsit körültekintőbben meg kell vizsgálnunk a csomagot. Az IP-címek specifikálva vannak, azonban a portok sehol sem láthatóak. Mi lehet ennek az oka? Ha visszaemlékszünk a jegyzet elején tárgyaltakra, akkor elmondhatjuk ismét, hogy az ICMP üzenetek a hálózati rétegbeli információkat hivatottak hirdetni. Mivel az ICMP üzenetek típusa és kódja egyértelműen meghatározza az üzeneteket, így nincs szükség az ICMP csomagok átirányítására a megfelelő alkalmazási rétegbeli folyamatokhoz. A Sequence number mezőkben levő értékek összetartozó kérés-válasz esetén mindig megegyeznek.

Traceroute A traceroute program segít abban, hogy végigmenjünk azon a "nyomvonalon", amelyen egy tetszőlegesen elindított csomag végighaladna. Eszközről eszközre léphetünk végig a hálózaton, megvizsgálva azt, hogy hány "ugrásra" található a cél, milyen eszközökön és komponenseken kellett keresztülmenni, illetve hiba esetén hol akadhat el az üzenetküldés. Itt is előkerülnek az ICMP üzenetek, azonban egy picit mégis eltér a ping-től. A traceroute a forrás eszköznél hagyományos IP datagram-ok sorozatát állítja elő a cél eszköz IP-címével. Minden ilyen datagram-ba beágyazásra kerül egy UDP szegmens egy valószínűtlen UDP port számmal. A datagram-ok közül az első rendelkezik egy 1-es TTL-lel (Time-To-Live), a második 2-es TTL-lel, a harmadik 3-assal, és így tovább. (Megjegyzés: a Time-To-Live mezőben szereplő érték mondja meg, hogy egy TCP/UDP kapcsolat legfeljebb meddig maradjon nyitva (másodpercekben), ha nincs rajta aktív forgalmazás. Az 1, 2, 3, stb... számok a lépések számával ekvivalensek). A forrás eszköz a

10

kiküldésekkel egyidejűleg egy-egy időzítőt is elindít. Amikor az n-edik datagram megérkezik az n-edik router-hez, akkor az n-edik router észleli, hogy a TTL lejárt, így a csomagot eldobja. Az eldobást követően pedig válaszol a traceroute-ot indító host-nak egy 11-es típusú ICMP üzenettel (TTL expired). Ebben a válasz üzenetben benne van az említett n-edik router neve és IP-címe. A válasz alapján a traceroute-ot indító host képes meghatározni a csomag oda-vissza megtett útjához szükséges időtartamot az időzítő segítségével, valamint az n-edik router nevét és IP-címét az ICMP csomag alapján. Jogosan vetődhet fel az alábbi kérdés: honnan tudja a forrás (küldő), hogy hány IP datagram-ot kell kiküldenie? Mivel folyamatosan növeljük a TTL értékét, így biztosak lehetünk abban, hogy előbb-utóbb egy csomag (és onnantól mindegyik) képes eljutni a célállomásig. Az viszont már képes válaszolni hagyományos echo reply üzenetekkel.

Traceroute példa A traceroute folyamat - hasonlóképp a ping-hez - az operációs rendszer szintjén meg van valósítva, így parancssorból ez is elérhető. A szintaxis igen hasonló:

tracert [-option] destination Néhány opciót és annak jelentését példákkal itt is megvizsgáljuk!

Opció Megnevezés Példa

-h [max hop]

Meghatározhatjuk a maximális ugrások számát (hány állomáson engedjük meg, hogy keresztülhaladjon a csomag)

tracert -h 10 www.google.com

-4 IPv4-es címek használatának kikényszerítése

tracert -4 www.google.com

Indítsunk egy nyomkövetést (traceroute-ot) ugyanúgy a kanadai Macleans magazin web-szervere felé!

8. ábra tracert parancs futtatása parancssorban

11

Látható, hogy itt is megkapjuk a web-szerver IP-címét, továbbá alapértelmezés szerint 30 ugrást kezel a tracert parancs. (Ez az érték természetesen felüldefiniálható a táblázatban szereplő -h opcióval.) Az útvonalkövetés 7 lépésből eljutott a cél web-szerverhez, ami azt jelenti, hogy 5 különböző másik állomáson ment keresztül a csomagunk. 1. lépés: saját router-em IP-címe (azaz a hálózatom átjárója) (192.168.0.1) 2. lépés: Digi egy privát alhálózata (10.0.0.1) 3. lépés: Digi egy másik privát alhálózata (10.1.129.65) 4. lépés: Digi szolnoki központja - itt már globális címmel dolgozunk (94.21.3.13) 5. lépés: Digi budapesti központja - mely összeköttetésben áll a szolnokival (94.21.3.6) 6. lépés: Digi másik budapesti központja (94.21.3.140) 7. lépés: Kanadai web-szerver IP-címe (94.21.255.200) (Most ezzel elárultam, hogy Digi-nél van internet előfizetésem... :).) Ami még érdekes lehet, de nem túl magától értetődő, az a lépésenkénti 3 szám egymás mellett ms-ban megadva. Minden echo request üzenet az adott TTL számmal 3-szor kerül kiküldésre, ezeknek az RTT (round-trip-time) értékei láthatóak, azaz mennyi idő alatt érkezett meg a válasz. Nézzük meg a Wireshark monitorozás eredményét (9. ábra)!

9. ábra Wireshark tracert info

A monitorozást vizsgálva láthatjuk - hasonló módon a parancssorhoz -, hogy minden (adott TTL-lel ellátott) csomag 3-szor került elküldésre. A válaszok mindig az aktuális router-től érkeznek vissza, amelyiknél a TTL lejárt. Az üzenet pedig egy újabb ICMP csomagba kerül beágyazásra, mégpedig, hogy a TTL lejárt. TTL=1 esetében egy lépést tesz meg a csomag, ez épp a saját router-emnél lesz, és annak az átjárója válaszol. Ez elküldött echo request-et összehasonlítva a ping-nél küldöttel megállapíthatjuk, hogy nincs eltérés a Type és a Code mezők tartalmát tekintve. A válasz azonban annál izgalmasabb, ugyanis egy új Type - Code páros kerül elő, ez pedig a Type=11, Code=0 (lásd: 10. és 11. ábra). A traceroute végén megtalálhatjuk a célba érésért járó 4 elemű echo request - echo reply sorozatot.

12

10. ábra ICMP Echo Request részletek (tracert)

11. ábra ICMP TTL-Exceeded részletek (tracert)

DHCP parancsok Amint az elméleti részben tárgyaltuk, a DHCP protokoll egy 4 lépéses folyamatot valósít meg. Ahhoz, hogy egy kliensen ezt a 4 lépést monitorozni tudjuk, egy új alhálózatra kellene csatlakoznunk, ahol van DHCP szerver. Ez nem olyan egyszerűen kivitelezhető, de szerencsére vannak manuális megoldások. A lépéseket követően beszéltünk a címek megújításáról (renew). Nem csak megújítani tudunk címet, hanem elengedni is kézzel. Windows alatt a Parancssorban van erre megfelelő parancs.

ipconfig /release

Ennek hatására a kliens IP-címe visszaáll a 0.0.0.0-s induló címre. Az elindításhoz a megújítás parancsára lesz szükségünk, és ez fogja kiváltani a 4 lépéses kliens-szerver interakciót.

ipconfig /renew

13

Lássuk a két parancs kimenetét a Parancssorban!

12. ábra ipconfig /release

13. ábra ipconfig /renew

Ahogy látszik a két ábrán (a bekeretezett rész a lényeges), a vezeték nélküli adapterhez volt hozzárendelve IP-cím, és azt sikeresen felszabadítottuk az ipconfig /release paranccsal. Ezt követően az ipconfig /renew paranccsal kommunikáltunk a DHCP szerverrel, és kértünk egy új IP-címet.

14

Tekintsük meg az e mögött álló üzenetváltásokat Wireshark-ban!

14. ábra Wireshark DHCP üzenetváltás

Indítsunk azzal, hogy a DHCP-re történő megjelenítési szűrő nem egészen triviális. A jól megszokott protokoll név beírás a Display filter részbe itt nem működik. Ennek az az oka, hogy a DNS múltjára tekint vissza a szoftver, és egy régebbi protokollt kell megadnunk szűrő kifejezésként. A DHCP az ún. BOOTP (Bootstrap Protocol) protokollból nőtte ki magát, de a régi protokollnak is a fő feladata megegyezett a DHCP-ével. Így a szűrő kifejezés: bootp. 5 üzenetünk van, ebből az első az IP-cím elengedéséért felelős, a maradék 4 pedig a 4 lépéses címkiosztási folyamatért. A csomagokat megvizsgálva láthatjuk, hogy az ipconfig /release parancs következtében valóban a 0.0.0.0-s induló címre állt vissza az adapter, hiszen a DHCP discover message forrás IP-je 0.0.0.0. Valóban igaz volt az is, hogy nem ismert a DHCP szerver címe, ezért szórásos címet választottunk. A DHCP szerverünk jelen esetben a router-ünk maga, hiszen ő volt az, aki válaszolt (elképzelhető más hálózatoknál, hogy a relay agent válaszol vissza). Ha relay agent áll az interakció mögött, akkor annak az IP-címe megtalálható a csomag részletei között (Relay agent IP address: ... ). Ha ez a cím 0.0.0.0, akkor nincs relay agent. A port nyitás is az elmélet szerint történik, ugyanis a kliens a 68-as porton küld és fogad, míg a szerver a 67-esen. A ipconfig /renew parancs következtében láthatjuk, hogy ismételten a 192.168.0.101-es IP-címet kapta meg a kliens. A tranzakció azonosítója megegyezik a 4 lépéses interakció alatt, azaz egyetlen DHCP szervertől érkezett csak IP-cím ajánlás. Érdekesség: Ahogy látjuk a DHCP Release-ről nincs visszaigazolás (ellentétben a többi DHCP üzenet típussal). Mi történik vajon, ha a DHCP Release csomag elveszik? Ilyenkor a DHCP szerver kénytelen megvárni a Lifetime lejáratát, hiszen megszakítás hiányában az összerendelés addig életben van.

15

IPv6

Feladata Egy állomásnak IP-címre van szüksége, hogy része lehessen az Internetnek, vagy bármely hálózatnak. Az IP-cím egy logikai hálózati cím, ami azonosít egy bizonyos hálózatot, és abban egy bizonyos állomást. Megfelelően kell konfigurálni és egyedinek kell lennie ahhoz, hogy kommunikálni tudjunk más eszközökkel. Minden, az Interneten keresztül küldött csomagnak van egy forrás és egy cél IP-címe. Ezt az információt igénylik a hálózati eszközök, hogy biztosítsák az információ eljutását a célhoz, és bármely válasz visszatérését a forráshoz.

Motiváció Az IPv6 váltja le a már közel 30 éves IPv4-et. Az IPv4 legfőbb problémája, hogy 32 bit-es címet használ, ez azt jelenti, hogy körülbelül 4 milliárd IPv4 cím létezik. A számítástechnika fejlődésével már legtöbbünk zsebében ott lapul az interneten keresztül kommunikáló okostelefon, és a háztartásokban a számítógépeken kívül is egyre több készüléknek kell rendelkeznie interneteléréssel, ez a tendencia pedig töretlen. Ha még azt is figyelembe vesszük, hogy a földön körülbelül 7,5 milliárd ember él, akkor hamar beláthatjuk, hogy az IPv4 címzés nem fenntartható. Az IPv4 címek elfogyásának problémáját tréfásan úgy is emlegetik, hogy IPcalypse vagy ARPAgeddon. De miért is megoldás az IPv6? Az új protokoll 126 bit-es címet használ, ami azt jelenti, hogy 2^96-szor több IP címet lehet kiosztan, mint IPv4 esetében. Hogy a mértékugrás még szemléletesebb legyen, nézzünk egy példát. Ha a teljes IPv4 címtér egyetlen vízmolekula lenne, akkor az IPv6 címzési kapacitásának egy körülbelül 2500 liter vízzel teli tartály felelne meg.

Újdonságok, eltérések A legfontosabb eltérés az előző pontban már tárgyalt címhossz.

15. ábra IPv4 – Ipv6 cím hossza

Az IPv6 protokoll az IPv4 protokollhoz képest lényegesen egyszerűbb fejrészt használ, annak érdekében, hogy az irányítótábla bejegyzések számának csökkentésével növelje a forgalomirányítás hatékonyságát. Bár az IPv6 címek nem 32, hanem 128 bit-esek, a fejrész mégis csupán kétszer olyan hosszú, mint az IPv4 esetében.

16

16. ábra IPv4 – Ipv6 fejrész felépítése

A címformátum is eltér, míg az IPv4 címek négy darab pontokkal tagolt 8 bites decimális számból álltak, addig az IPv6 címek nyolc darab kettőspontokkal tagolt 16 bites hexadecimális számból állnak. Alább látható egy-egy példa a két protokoll címformátuma közötti eltérésről.

IPv4 címformátum 192.168.1.1 IPv6 címformátum 2001:0db8:0a0b:12f0:0000:0000:0000:0001

Az IPv6 címek formátuma azonban nem rögzített, bizonyos alapelvek, szabályszerűségek alapján egyszerűsíthető, rövidíthető a leírott formátumuk. A hexadecimális értéket jelölő betűk nem érzékenyek a kis- és nagybetűkre. A mezők (amint a kettőspontok tagolnak) elején lévő 0-k opcionálisok, vagyis például a 0A0B ugyan azt jelenti, mint az A0B, és a 0000 megegyezik a 0 mezővel. A 0-k egy csoportja egy címben egyszer helyettesíthető a „::” karakterekkel. A „::” jelölés használata jelentősen csökkenti a legtöbb cím méretét, például az FF01:0:0:0:0:0:0:1 címből FF01::1 lesz. A meg nem határozott címet, mely csupa 0-kat tartalmaz az előző szabály szerint egyszerűen jelölhetjük a „::” karakterekkel.

17. ábra Ipv6 címek ábrázolása

17

A cím felsô bitjei itt is a cím funkcióját azonosítják, de nem címosztályokat jelölnek, a címtér felosztására csak funkcionális okokból került sor. A prefixeket (előtag) az alábbi táblázat foglalja össze.

A Prefix célja Prefix Méret Fenntartott 0000 0000 3.9 ‰

NSAP címeknek 0000 001 7.8 ‰ IPX címeknek 0000 010 7.8 ‰

Szolgáltatók által osztott címeknek 010 125 ‰ Földrajzi alapon osztott címeknek 100 125 ‰

A link-en lokális címek 1111 1110 10 1 ‰ A telephelyen lokális címek 1111 1110 11 1 ‰

Multicast címek 1111 1111 3.9 ‰ Felhasználatlan minden egyéb 725 ‰

A link-en lokális címek (röviden link-local címek) olyan címek, melyek csupán az adott link-en egyediek és éppen emiatt csak a link-en való kommunikációra használhatóak. A router-ek feladata, hogy ilyen feladó címmel ellátott csomagokat ne továbbítsanak a link-en kívülre. A telephelyen lokális címek (site-local) címek pedig értelemszerűen csak a telephelyen belül használatosak. Egy állomásnak, sőt akár egy interface-nek így több címe lehet, ezek közül néhány link-local, néhány site-local néhány pedig globális lehet. Az IPv6 nem használ üzenetszórást. IPv4 esetén az üzenetszórások jelentős forgalmat generálnak a hálózatban, ami úgynevezett üzenetszórási viharokhoz vezethet, és a teljes hálózatot működésképtelenné teheti. Az IPv6 szórásos (broadcast) címek helyett csoportos (multicast) és többszörös felhasználású (anycast) címeket használ. Egyedi címzéskor (unicast) a csomagok küldése egy konkrét címmel rendelkező konkrét eszközhöz történik. Csoportos (multicast) címzés esetén a csoport minden tagja megkapja a csomagokat, míg többszörös használatú (anycast) cím használatával a csomag az azonos címet használó csoport egyetlen tagjához kerül csak továbbításra. Hatékonysági szempontok miatt egy többszörös használatú címre küldött csomag a legközelebbi interfészre kerül csak továbbításra, így az ilyen címre, mint „azonosak közül a legközelebbi” típusú címre gondolhatunk.

18. ábra IPv6 címzések felépítése

18

Neighbour Discovery A szomszédos állomások felkutatása IP szinten folyik. Az IPv6-ban minden router periodikusan hirdetményeket (Router Advertisement) postáz a minden-állomás címre, melyet természetesen az alatta lévő adatkapcsolati szint kvázi-broadcast üzenetként fog elküldeni. Ebben a router közzéteszi saját MAC címét, a link-en használatos prefixeket és egyéb információkat, mint például a link MTU (Maximum Transmission Unit) vagy az, hogy a kívülre küldött csomagokban mekkora hop-korlát (maximális ugrások száma) használata javasolt. A router hirdetmények számos kérdést megoldanak. Egyrészt minden állomás összeállíthatja a link-en lévő router-ek listáját, ezek felderítésére tehát a továbbiakban nincs szükség, mint az IPv4-ben. A router-ek MAC címét sem kell ARP-vel megtudakolni, ráadásul olyan paraméterek, mint az MTU egy központi helyről konfigurálhatóak. Ezenfelül az állomások maguk állíthatják elő valamely kitüntetett prefix segítségével saját címüket. Azt is központi helyről közölhetjük az állomással, hogy ne állítson elő így címet, hanem keresse a DHCP servert. Erről bővebben a következő fejezetben olvashatunk. Ha egy állomás bekapcsolódik nem kell megvárnia a router-ek periodikus hirdetményeit, egy a minden-router címre küldött felszólítással (Router Solicitation) kiválthatja azok soron kívüli elküldését is. A hirdetményekből az állomás előállíthatja a link-en használatos prefixek listáját is, így egy adott csomagról a cím alapján könnyen el tudja majd dönteni, hogy az adott link-re szól vagy egy router-nek kell elküldeni. Ettől függetlenül, ha egy állomás címe nem illeszkedik egyik prefixre sem, az még nem feltétlen jelenti, hogy nincs az adott link-en, hiszen lehetnek rögzített című állomások, melyek prefixe eltér minden más ezen a link-en használatos prefixtől. Ebben az esetben az állomás a csomagot egy router-nek küldi, aki továbbítja is a célpont felé, de egyúttal egy átirányító (Redirect) üzenetben közli az állomással hogy a kérdéses IP cím gazdája a link-en van és megmondja annak MAC címét is.

IPv6 „DHCP” Az IPv6 alapvetően kétféle autokonfigurációt definiált. Az egyik szigorúbb és precízebb, a konfigurációs információkat itt egy szerver szolgáltatja, alapját a DHCP képezi (stateful autoconfiguration). A másik némileg egyszerűbb, az állomások önmagukban is képesek lebonyolítani, a Neighbor Discovery módszereit használja és implementálása erősen javasolt (stateless autoconfiguration). Ez utóbbi a következőképpen zajlik. Minden állomás eleve rendelkezik egy olyan azonosítóval, ami a link-en egyedi módon azonosítja: ez a MAC címe. Az autokonfiguráció céljaira használhatunk más azonosítót, de ez a legkézenfekvőbb. Ebből az azonosítóból és az FE80:0::/10 (link-local) prefixből minden állomás előállíthatja saját link-local címét, aminek segítségével legalább a link-en kommunikálhat. A kapott link-local címet azonban még nem használhatjuk, hiszen lehet, hogy más állomás is pont ugyanerre a címre jutott; a cím még kérdéses (tentative). A kérdéses címekre kapott csomagokat az állomás figyelmen kívül hagyja, kivéve a szomszéd felszólításokat (Neighbour Solicitation) és a rájuk érkező válaszokat, mert ezek segítségével ellenőrizzük a cím egyediségét. A link-local cím birtokában feladunk egy szomszéd felszólítást a link-local címből számított megszólított-állomás multicast címre. Ha senki sem válaszol (meghatározott időn belül), akkor úgy vehetjük, hogy a címet csak mi használjuk. Link-local címünk véglegesítése után, a router-ek által kibocsájtott hirdetményekre (Router Advertisement) várunk (esetleg a minden router csoportra elküldött felszólítással ezt megsürgetjük). A kapott hirdetményből eldöntjük, hogy végre kell-e hajtanunk önálló autokonfigurációt vagy sem. Ha igen, az erre a célra megjelölt prefix(ek)ből és a korábban használt azonosítóból előállítjuk további címeinket.

19

Ellenőrző kérdések 1. Miért nem jelenik meg port szám a pingelés során? 2. Hogyan indíthatunk olyan ping parancsot, melynek megállási feltétele a megszakítás? 3. Egy traceroute-ban jellemzően mely eszközhöz jutunk el az első lépés következtében? 4. Hányszor küldünk ki egy adott TTL-lel ellátott echo request-et traceroute esetén? 5. Mi jelzi azt, hogy egy traceroute célba ért? 6. Milyen Type - Code párossal vannak ellátva a TTL lejártát jelző ICMP válaszok? 7. Hány lépésből áll a DHCP konfiguráció? Melyek ezek a lépések részleteiben? 8. Mely parancs segítségével engedhetünk el egy klienshez rendelt IP-címet? 9. Mely paranccsal újítható meg a kliens IP-cím hozzárendelése? 10. Mely portokat használják a DHCP alatt a kliensek és a szerverek? 11. Ki az a relay agent?

Források • James F. Kurose, Keith W. Ross: Computer Networking, A Top-Down Approach (Seventh

Edition) • CISCO CCNA negyedik szemeszterének tananyaga • https://www.szabilinux.hu/trendek/trendek73.html