Az "Internet" napjainkban nem egy technológia a sok közül, hanem önálló életre kelt, a társadalmat befolyásoló eszköz.

8. Internet Az "Internet" napjainkban nem egy technológia a sok közül, hanem önálló életre kelt, a társadalmat befolyásoló eszköz. A technológiai cél: egymástól eltérő fizikai architectúrájú hálózatok összekapcsolása annak érdekében, hogy a hálózatban szereplő gépek egymással kommunikálni tudjanak 8.1 ábra. Eltérő technológiák kapcsolódása az Interneten. Az Internet alapvetően a TCP/IP rétegmodellre épül. A hivatkozási modell rétegeit, és szerepüket más hivatkozási modellekhez képest az 1. fejezet 1.10 és 1.11 ábrán szemléltettük. Az egyes rétegekben működő protokollok áttekintését 8.2 ábrán láthatjuk. A protokollok listája nem teljes, csak néhány jellegzetes elemet tartalmaz. 167

Web browser e-mail Other user Applications Application protocols: HTTP,SMTP,FTP,DNS.. USER space Applications Application Programming Interface (API) Transport Network ICMP TCP IP UDP RIP OS kernel ARP Data Link RARP FDDI WAN technology LAN technology Ethernet 8.1. A működés modellje 8.2.ábra. TCP/IP protocol stack A hálózatban egyedi, egymástól független "csomagok" haladnak, melyeknek a célhoz vezető útvonalát a csomagban lévő cím alapján keressük. Nem biztos, hogy van ilyen útvonal, vagy ha létezik, akkor biztosan megtaláljuk meghatározott időn belül! A hálózat csomópontjain "routerek" vannak, melyek táblázatokat (Routing tables) tartanak fenn a célokhoz vezető útvonalakról. Belátható, hogy elegendő azoknak a szomszédos csomópontoknak a tárolása, ami a célhoz vezet, nem kell a teljes útvonalat tárolni. Gyakorlatban elképzelhetetlen egy olyan táblázat, ami a világ összes hosztját tartalmazza a hozzá vezető optimális útvonallal együtt. Egy részhálózatról azonban elképzelhető, hogy pontosan ismert minden tulajdonsága, és ez az ismeret felhasználható a legjobb útvonal meghatározására. Léteznek természetesen olyan útvonalak is, melyeket előre, pontosan meghatároznak a forrástól a célig. Ha egy routernek 4 "lába" van, akkor egy beérkező csomag a 3 kimenet valamelyikén továbbítható. Csak azt kell eldöntenünk, hogy melyiken a 3 közül. A további útvonal meghatározása a következő router feladata. 168

DA = Destination Address ( cél cím) SA = Source Address ( forrás cím) 8.3 ábra. Routerek a hálózatban A 8.3 ábrán az x című állomás küld csomagot az y címűnek. A csomagok fejléce tartalmazza yx-et. A routerek az "y" címhez tárolják azoknak a szomszédaiknak a címét, melyeken keresztül "y" a legkedvezőbben elérhető. (Legkevesebb ugrás, legkisebb költség, legrövidebb idő, stb.) A szolgáltatás datagram jellegű: A csomagok ezért elveszhetnek többszöröződhetnek beérkezési sorrendjük megváltozhat A biztonságos átvitelről a felettes rétegeknek kell gondoskodni. Az útválasztás folyamatát a 8.4 fejezetben tárgyaljuk. 8.2. Az Internet protokolljai A nagy hálózatok összekapcsolásának valódi alapja az Internet Protocol (IP). Eleve a különböző hálózatok összekapcsolására tervezték. Optimális továbbítást biztosít a datagramok számára a forrásgéptől a célgépig. 169

Az alkalmazás a szállítási rétegnek adja át az adatokat. A szállítási réteg max. 64kbyte hosszú darabokra tördeli az üzenetet. Az üzeneteket a hálózati réteg esetleg tovább darabolva továbbítja. A célgépen a hálózati réteg visszaállítja a datagramot, és átadja a szállítási rétegnek. A szállítási réteg protokoll vermeket tart fenn a különböző protokolloknak. Általában négyféle protokoll vermet tartanak fenn az operációs rendszerek. Ha az útvonal más jellegű hálózaton is áthalad, akkor az alagút típusú átvitelt használhatjuk (Pl. SNA hálózatokban). A csomagot tartalmazó keretet beburkoljuk egy az adott hálózaton használatos keretbe, az alagút végén pedig kicsomagoljuk. Hasonló a folyamat ahhoz, ahogy a gépkocsikat berakjuk vasúti kocsikba az alagút előtt, az alagút után pedig az autók saját erőforrásaikkal haladnak tovább. 8.2.1 Ipv4 protokoll Hálózataink jelenleg ezt a protokollt használják. 8.4. ábra. Ipv4 csomagformátum A mezők jelentése: Version (Verzió) Biztosítja, hogy a régebbi verzióval működő gépek csomagjait is megfelelően dolgozzuk fel az átmeneti időszakban. Az átmeneti idő, míg az új verzió elterjed, éveket is jelenthet. IHL - fejrész hossza 32 bites szavakban adja meg a fejrész hosszát. Legkisebb értéke 5. Maximális értéke 15. Ez a fejrész hosszát 60 bájtra korlátozza. 170

Az opciós mező így legfeljebb 40 bájt lehet. Néhány opcióhoz ez túl kicsi. (Lásd: opciók) Type of service - szolgálat típusa lehetővé teszi, hogy a hoszt megadja az általa kért szolgálat jellegét. A sebesség és megbízhatóság különböző kombinációit adhatjuk meg. 1 tulajdonsághoz 1 bit tartozik. Pl. hangátvitelnél a sebesség, fájl átvitelnél a megbízhatóság lehet a fontos. Ha a bitenkénti értelmezés helyett a kombináció számértékét adjuk meg, akkor az alábbi táblázat írja le a szolgáltatásokat: TOS mező értékei: Ø normál szolgála 1 minimális költség 2 maximális megbízhatóság 3 maximális átbocsátás 4 minimális késleltetés Precedence mező Ø-7 értékkel jelöli a csomag fontosságát. Ø a legalacsonyabb prioritás 7 a legmagasabb prioritást jelöli, a hálózati vezérlő csomagok szintje. Flags 3 bitet tartalmaz Az első bit használaton kívüli. A Don't fragment annak a jelzésére szolgál, hogy a csomag nem darabolható. Ennek a jelzőnek a beállítása veszélyeket is hordoz. Ha a routerek nem tudnak olyan méretű csomagokat továbbítani, mint amit küldünk, akkor "az útvonal nem létezik" jelzéssel leállhat az adatforgalom. Egy másik lehetőség, hogy a rövidebb csomagok továbbítására alkalmas rendszerszakaszon mégis feldaraboljuk a csomagot, továbbítjuk, és a szakasz végén helyreállítjuk. A lényeg az, hogy nem a célállomásra bízzuk a darabok összeállítását, hanem a szakasz végén lévő routerre. A szakasz után a csomag olyan, mintha nem daraboltuk volna fel. A célállomás a fel nem darabolható csomagok egymás közötti sorrendjével foglalkozik csak. 171

M - More fragments bit azt jelzi, hogy a feldarabolt csomagnak nem ez az utolsó darabja. Ha megkaptuk azt a darabot, ahol M=Ø, akkor tudjuk, hogy ez az utolsó, és ismerjük a "Fragment offset" értékét. Ennek birtokában ellenőrizhető, hogy minden darab megérkezett-e. Fragment offset (Darabeltolás) megadja, hogy a darab hova tartozik a datagramban. A címzésre 13 bit áll rendelkezésre, így a teljes datagram címezhetősége érdekében az eltolást 8 bájtos egységekben adja meg. A 8192 *8 bájt 1-el több mint amit a teljes hossz (Total length) le tud írni. Identification mező szolgál a datagram azonosítására. Egy datagram minden darabja ugyanazt az azonosítót tartalmazza. Ez teszi lehetővé, hogy a cél - hoszt azonosítsa az egy datagramhoz tartozó darabokat. Time to live mező a darab maximális élettartamát adja meg másodpercekben. A 8 bit maximum 255 másodpercet jelent. A számláló értékét minden másodpercben, illetve minden routeren való áthaladáskor csökkentjük 1-el. A routerek sokszor eltérnek ettől a szabálytól, és csak az áthaladáskor csökkentik a számlálót, az időt figyelmen kívül hagyják. Az indok az, hogy a pufferben tárolt adatokra nehézkes a megvalósítás. Az adatokon túl tárolnunk kellene a pufferbe való elhelyezés időpontját is. A csomagjaink tehát nem maradnak végtelen ideig a hálózatban. Az élettartam mező kezdőértéke beállítható. Általában 40-50 közötti érték a szokásos. Gyors hálózatokban 10 körüli érték megadása is indokolt lehet, hogy ne fordulhasson elő az élettartamon belül két azonos sorszám. "Protocol" mező A hálózati réteg összeállítja a datagramot, és a protokoll mezőben meghatározott szállítási folyamatnak adja át. A folyamat általában TCP vagy UDP, de más is lehet. A protokollok számozása egységes, az RFC 1700 definiálja. Header checksum (fejrész ellenőrző összege). Csak a fejrészt ellenőrzi, a tartalmat nem. Képzése rendkívül egyszerű. 1-es komplemens módon összeadjuk a beérkező fél-szavakat (16 bit), és képezzük az eredmény 1-es komplemensét. 172

Az ellenőrző összeget minden routeren újra kell számolni, mert az élettartam mező mindig megváltozik. Source Address, Destination address Forrás és cél címe 32 biten. (Az IP címek szerkezetét, és címfeloldást lásd később.) Options mező 0-40 bájt hosszú lehet. Eddig 5 opciót definiáltak. A biztonság opció az információ titkosságának fokára utal. Használata gyakorlatban nem célszerű, mert felhívja a figyelmet a fontos információra. Eredményesebb álcázás, ha a fontos adatok eltűnnek a lényegtelenek tömegében. Szigorú forrás általi forgalomirányítás IP címek sorozataként megadja a teljes útvonalat Laza forrás általi forgalomirányítás lényegében az útvonal irányát jelöli ki. (Az információ bizonyos országokon ne haladjon át, ne hagyja el az országot, stb) Útvonal feljegyzése opció főként a routerek üzemeltetőinek fontos..lehetővé teszi a hibák felderítését.(miért ment USA-n keresztül a szomszéd épületbe címzett üzenet?) A mai körülmények között sokszor kevés a 40 bájt az útvonal tárolására. Az időbélyeg opció az IP cím mellé egy 32 bites időbélyeget is feljegyez. Főként a router algoritmusok hibakeresésénél hasznos eszköz. 8.2.2. IP címzési rendszer A címzési módokat az RFC791 (1981) írja le. Az Ipv4 cím két részből áll: hálózati cím + hoszt cím. Egy hoszt egyszerre több hálózathoz is csatlakozhat. Ekkor minden hálózatban külön IP címe van. A címet megjeleníthetjük binárisan, vagy decimális formában. Szokásos az u.n. "Dotted decimal" formátum. A 32 bit 4 bájtnak felel meg. Minden bájt decimális értékét írjuk ki, pontokkal elválasztva. Pl.: 193. 221. 15. 179 173

Az egy hálózatba tartozó gépek száma igen tág határok között változhat, ezért cím - osztályokat alakítottak ki. A címosztályoknak az információ továbbítása során is fontos szerepe van. A címtartomány korlátozottsága miatt (mindössze 32 bit, és ez sem osztható ki maradéktalanul) belátható időn belül szükség lesz a módosítására az Internet rohamos terjedése miatt. Számos javaslat született a megoldásra, és van szabvány javaslat is (Ipv6), de az áttérés jelentős költségei miatt egyelőre várat magára az áttörés. Valószínű, hogy az Ipv4 világban Ipv6 szigetek jönnek létre, melyeket a meglévő kapcsolatokon keresztül alagút jelleggel kapcsolnak össze mindaddig, míg az Ipv6 általánossá válik. 8.2.3. Címosztályok az Ipv4-ben A címosztály a cím 1.-5. bitje alapján határozható meg. 32 bit Osztály A 0 Hálózat Hoszt 1.0.0.0-tól 127.255.255.255-ig B 10 Hálózat Hoszt 128.0.0.0-tól 191.255.255.255-ig C 110 Hálózat Hoszt 192.0.0.0-tól 223.255.255.255-ig D 1110 Többesküldési cím 224.0.0.0-tól 239.255.255.255-ig E 11110 Jővőbeni alkalmazásokhoz fenntartva 240.0.0.0-tól 255.255.255.255-ig 8.5. ábra IP címosztályok. A címek egy része speciális célokra foglalt. A 0.0.0.0 címmel indul minden hoszt, majd a hálózati paraméterek betöltése után többet nem használja. A 127.xx.yy.zz címek a visszacsatolások címzésére vannak fenntartva. A 127.0.0.1 a hoszt saját maga. A 255.255.255.255 helyi adatszórást jelent. Az adatszórás csak az alhálózaton belülre szól. Egy távolabbi hálózatban is végezhetünk adatszórást, ha egy helyes hálózati cím mögé csupa 1-eket írunk. 174

Hálózati cím + 11.11 A helyi alhálózatunkban egy hosztot úgy is megcímezhetünk, hogy nem adjuk meg a teljes címet, csak az alhálózaton belüli hoszt címet. 0000 00 + hoszt cím Egy HOST-ot egyértelműen azonosít az IP cím. Ha ez igaz, akkor mi szükség van a címosztályokra? Egyszerűsíti és gyorsítja a csomagok irányítását. A helyi hálózatból kilépve az eszközök csak a célhálózat elérésével foglalkoznak. A hoszt cím célhálózaton belüli értelmezésére csak a fogadóoldali router után van szükség. A címnek a hálózati cím része a címosztályt jelző bitek alapján leválasztható, és a csomagirányításhoz csak ezt a részt kell használni. 8.2.4. Alhálózatok. A nagyszámú géppel rendelkező felhasználó hamar szembe kerül azzal a problémával, hogy az adminisztráló szervezettől szeretne egy összefüggő címtartományt kapni, ugynakkor ezt a címtartományt szeretné kisebb, külön-külön managelhető tartományra bontani. A hálózati cím és a hoszt cím szétválasztására alkalmas eszköz a netmaszk. A netmaszk a hálózati cím-pozíciókban 1-et, a hoszt - cím helyén Ø-kat tartalmaz. A címosztály meghatározza, hogy a hálózati cím hány bites. Kívülről csak a hálózat címezhető,az alhálózatunk nem, mert a továbbított csomagokban nincs benn a netmaszk. A helyi hálózatunkban azonban valamennyi eszköz tartalmazza a netmaszk-ot, és így kiderül, hogy a csomag melyik alhálózatnak szól. A hoszt címeket egy EXOR művelettel választhatjuk le a teljes címből. (teljes cím) EXOR (netmaszk) = (hoszt cím) Példaként hozzunk létre alhálózatot egy C osztályú címen belül. Az alhálózat max. 32 gépet tartalmaz. A címtartomány legyen: 193.221.15.32-193.221.15.63 175

Alhálózat IP cím Hálózat címe Hoszt cím 193.221.15.32 110 00001 11011101 00001111 001 00000 193.221.15.63 110 00001 11011101 00001111 001 11111 "C" osztályú a cím Hoszt cím a külső hálózat számára A külső hálózat nem látja az alhálózati maszkot, csak a "C" osztályt ismeri fel!! Alhálózati maszk 11111111 11111111 11111111 111 00000 Decimálisan: 255.255.255.224 Példa: alhálózati cím leválasztása a 193.221.15.41 címből Az alhálózat címe: 193.221.15.32 110 00001 11011101 00001111 001 01001 ÉS 11111111 11111111 11111111 111 00000 = 110 00001 11011101 00001111 001 00000 8.6. ábra. Alhálózat címzése Az alhálózati maszkot valójában a router használja. A kérdés az, hogy egy bejövő üzenetet melyik kimenetre továbbítja az eszköz. Ha C osztályú címünket 8 db 32 címet tartalmazó részre osztottuk, mint a példánkban, akkor ez azt jelenti, hogy a bejövő üzeneteket 8 alhálózati szegmens felé tudjuk irányítani. A maszkban az utolsó nyolc bit 1110 0000. Ennek decimális értéke 224. A maszk hatására az 1-es portra kerülnek 0-31 végződésű címek, a 2-es portra 32-63 végződésű címek, és így tovább. A router kimenetén a teljes cím információ megjelenik. A maszk azt dönti el, hogy melyik kimenetre kerül a csomag. Az alhálózatból érkező csomag esetén a router azt tudja eldönteni, hogy a célcím az alhálazaton belül, vagy kívül van. Ha célcím az alhálózaton belül van, akkor routernek nincs tennivalója, nem továbbítja a csomagot. Ha nem az adott alhálózathoz tartozó forráscímet tartalmazó csomagot kap, azt szintén nem továbbítja. 176

Maszk 255.255.255.224 11111111 11111111 11111111 111 00000 Cím ÉS 193.225.11.15 11000001 11011101 00001111 000 01111 11000001 11011101 00001111 000 00000 A csomagot az 1-es portra továbbítja Maszk 255.255.255.224 11111111 11111111 11111111 111 00000 Cím ÉS 193.225.11. 36 11000001 11011101 00001111 001 00100 11000001 11011101 00001111 001 00000 A csomagot az 2-es portra továbbítja Maszk 255.255.255.224 11111111 11111111 11111111 111 00000 Cím ÉS 193.225.11.152 11000001 11011101 00001111 100 11000 11000001 11011101 00001111 100 00000 A csomagot az 5-ös portra továbbítja Ha a tartományt csak 2 részre szeretnénk osztani, akkor a HOST címből egy bitet kell csak elvennünk. A maszk utolsó 8 bitje ekkor 1000 0000. A teljes maszk decimálisan 255.255.255.128. A címtartományok részekre osztásának a B osztályú címeknél van igazán jelentősége. Egy nagyvállalat a B osztályú címtartományát szabadon oszthatja fel, változtathatja anélkül, hogy a címtartományokat nyilvántartó hivatalhoz kellene kellene fordulnia. CIDR (Classless Internet Domain Routing (RFC 4632) A valós világban ma A vagy B osztályú címhez jutni gyakorlatilag lehetetlen. A C osztályú címek túl kevés hoszt egységes kezelését teszik lehetővé a hálózatokat üzemeltető cégeknek. A nagy hálózatokat szolgáltató szervezetek (Internet Service Provider, ISP) működtetik, és a protokollok tervezésénél ezt figyelembe kell venni. A CIDR a gyakorlati igényekhez jobban alkalmazkodó címzési séma, mint a cím-osztályos megoldás. A CIDR rendszerben a hálózat-azonosító a cím bármekkora része lehet. A hálózati cím hosszát az un. CIDR prefix határozza meg. Az előtagot szokás változó hosszúságú alhálózati maszknak (Variable Length Subnet Mask, VLSM) is nevezni. A CIDR általánosítja az alhálózati címzési rendszert. Tizes számrendszerben megadott címeknél a címet jelölő számsor után, egy / jelet követően adjuk meg a hálózati címet tartalmazó bitek számát. Ezzel a módszerrel 177

egyszerűsíthető egy C osztályú hálózat alhálózatának megadása is. Megadhatunk 24-nél nagyobb bitszámot is. Egy 25 bites hálózati cím pl.:198.223.18.191/25 CIDR formátum megfelel a 193.225.18.191 címnek, 255.255.255.128 alhálózati maszkkal. A maszk utolsó bájtja 10000000 binárisan, tehát a 25. bittel végzett hálózati címet leválasztó ÉS művelet nem befolyásolja a cím 25. bit tartalmát, ami az alhálózatot jelöli ki (Két részre osztottuk a C osztályú címtartományt. A cím 25.-dik bitje 0 vagy 1 lehet). A két címtartomány: 193.225.18.1-193.225.18.126/25 Broadcast: 193.225.18.127/25 193.225.18.129-193.225.18.254/25 Broadcast: 193.225.18.255/25 A CIDR lehetővé teszi az egymást követő C osztályú címtartományok összevonását is egy logikai címtartománnyá. A CIDR előtag azt jelenti más megközelítésben, hogy a címek hány bitje azonos egy logikai csak, ha a címtartomány folytonos. Nem folytonos címtartományok is kiszolgálhatók ezzel a technológiával. Ilyenkor mindegyik tartományt meghirdeti a tartomány kiszolgáló. A hálózat a leghosszabban illeszkedő prefix felé fogja továbbítani a csomagokat. Egy B osztályú címen belül (pl.193.225.18.0/20). A megoldás igazi előnyeit az INTERNET szolgáltatók szerint felépített modelljében fogjuk látni, ahol a szolgáltató cégek hierarchikusan kapcsolódnak egymáshoz, és kis szolgáltatók egy-egy zárt csoportot szolgálnak ki. 8.2.5 Címblokkok kiosztása Egy zárt, saját tulajdonú hálózatban olyan IP címeket használunk amilyet akarunk. A saját címek megválasztásánál is célszerű az ajánlásokban szereplő címtartományokat betartani, mivel ezek a címeket nem adják ki publikus IP címként. A privát IP címek soha nem jelenhetnek meg a publikus interneten. Ha ki akarunk lépni az internetes világba, akkor regisztrált és engedélyezett címekre van szükségünk. A címek adminisztrációját korábban a NIC (Network Information Center) végezte. 2007 óta az ICANN (Internet Corporation for Assigned Names and Numbers) utalja ki a cím - tartományokat. A tényleges címkiosztást regionális címnyilvántartó hivatalok (Addres Supporting Organization ICANN).) végzik. Jelenleg öt régió van meghatározva. Az EU-ban a RIPE NCC (Réseaux IP Européens Network Coordination Centre) a regionális hivatal. Jelenleg (2013) Magyarországon a HUNGARNET jogosult címtartományok engedélyezésére. A 2009-ben elfogadott módosítások (pl. díj ellenében tetszőleges zárótag alkalmazható a szövegesen megadott címben) nehezen kezelhető helyzetet hoztak létre. Sze- 178

rencsére az alkalmazók nem éltek ezzel a lehetőséggel, és a címzési rendszer stabil maradt. (lásd :Domain Name Server fejezet): 8.2.6 Hoszt címek kiosztása A hosztoknak a hálózatban egyedi azonosítóval kell rendelkezni, hogy egyértelműen azonosíthassuk őket. A hálózati eszközök egy részéhez a rendszergazda fix IP címeket rendel, az intézménynél rendelkezésre álló címtartományból. Az eszközök egy másik csoportjához dinamikusan rendelünk IP címet a tartományból. A dinamikus IP cím az üzemeltetők számára számos szempontból előnyös: ha nincs minden felhasználó állandóan a hálózatra kapcsolódva, akkor több felhasználót tudunk kiszolgálni azonos méretű címtartománnyal; azonos névkiszolgálóhoz tartozó alhálózatok között lehet barangolni, nem kell újra konfigurálni a hosztot (lehetővé tehetjük például, hogy az egyetem területén belül lehessen barangolni az alhálózatok között). Különösen hasznosnak tűnő tulajdonság ez a rádiós hálózatoknál, ahol eleve arra számítunk, hogy a felhasználók mozognak, és csak rövid időre kapcsolódnak egy-egy alhálózathoz. A hoszt-címek kiosztásának automatizálására fejlesztett protokoll a DHCP, Dynamik Host Configuration Protocol (RFC 2131). A DHCP automatizálja az IP címek kiosztását. A DHCP konfigurációjától függően egy host kaphat fix IP címet minden bejelentkezéskor új címet meghatározott ideig állandó címet lehetőség szerint állandó címet. A lehetőleg állandó azt jelenti, hogy nem írjuk felül, ha van még kiosztható IP címünk. Ha változik a hoszt IP címe, akkor ezt az útvonalon található valamennyi forgalomirányító eszköznek be kell jegyezni az új címet a saját táblázataiba. Tehát olcsóbb, az IP címek állandóságára törekedni. A DHCP egy kliens-szerver protokoll, ahol a kliens az újonnan csatlakozó hoszt, és van valahol egy DHCP szerver. Ha a DHCP szerver az alhálózaton belül van, akkor kliens egy adatszórásos üzenettel megtalálhatja a szervert. Ha az alhálózaton kívül van,akkor további lépésekre van szükség. A hoszt nem ismeri az alhálózat címét 179

amiben saját maga van, nem ismeri a DHCP szerver IP címét, de még a sajátját sem, hiszen ez után fogja megkapni. Ha a DHCP szerver más alhálózatban van, akkor szükség van egy olyan eszközre, ami ismeri az alhálózathoz tartozó DHCP szerver címét. Ezt a szerepet (DHCP relay agent) gyakran egy útválasztó látja el. (RFC1542 kompatibilis útválasztók). A kapcsolódás lépései: DHCP szerver felderítése A belépő eszköz generál egy DHCP felderítés üzenetet, a 67-es portra; saját címként 0.0.0.0. címet tüntet fel. A válasz egy DHCP ajánlat üzenet (DHCP offer message). Az üzenet tartalmazza a tranzakció azonosítóját,kliens számára ajánlott IP címet, az alhálózati maszkot, és az IP- cím bérleti időt (address lease time, vagyis az érvényesség idejét. A DHCP szerver ismerheti a kérést küldő fizikai címét, így elvileg egyes-küldéses keretben tud válaszolni. Ez felel meg a http://tools.ietf.org/html/rfc1541 ajánlásnak. A gyakorlati esetek többségében a DHCP szerver nem a kérést küldő gép alhálózatában van, így szükség van egy DHCP továbbító ügynökre. Az ügynök ismeri a DHCP szerver címét. A DHCP ügynök és a DHCP ügyfél ugyanabban az alhálózatban van, a válasz üzenetszórásos is lehet (nem az ajánlásnak megfelelő megoldás). Egyes megvalósítások csak az üzenetszórásos változatot tartalmazzák. Egy kérésre több DHCP szerver is válaszolhat, amiből a kliens választhat. DHCP kérés A kliens az ajánlat-üzenetre egy DHCP kérés üzenettel (DHCP request message) válaszol.a válasz tartalmazza az üzenetből kimásolt, kliens által kért paramétereket. A válasz RFC1541 szerint üzenetszórásos, hogy azok a DHCP szerverek, melyeknek az ajánlatát nem kéri a kliens, a címet felszabadíthassák. A valóságban nem minden kliens küld üzenetszórásos választ. Az igénybe nem vett címek ilyenkor egy időzítés után szabadulnak fel. DHCP nyugtaüzenet (DHCP ACK message) A szerver DHCP nyugtaüzenettel válaszol, és megerősíti a paramétereket. 180

A DHCP megoldás automatizálja a címkiosztást, ezzel sok gondot megold. Hátrányai is vannak azonban. Ha barangolunk az alhálózatok között (kezünkben egy tablettel átmegyünk egy másik alhálózatba) akkor a TCP kapcsolatok megszakadnak. A rádiós hálózatoknál a mobil-ip oldja meg a problémát, ahol az alhálózatok közötti váltásnál az IP címünk állandó maradhat. 8.2.7 Hálózati címfordítás (Network Address Translation, RFC 2663,RFC 3022) A hálózaton lévő valamennyi IP-t támogató eszköznek rendelkeznie kell IP címmel. A kisméretű hálózatok egyszerű adminisztrációja és az IP címekkel való takarékoskodás egyaránt azt sugallja, hogy egy alhálózatot tudjunk egyetlen IP címmel üzemeltetni. Ha egy otthoni hálózatot bővíteni akarunk, akkor ne kelljen a szolgáltatóhoz fordulnunk további IP címekért. Ha az alhálózati címek kiosztására van automatizálási lehetőség (DHCP), akkor vélhetően ez a feladat is megoldható. A megoldás a NAT. A NAT fogalmát az irodalom meglehetősen önkényesen használja. Az RFC 2663 több altípust különböztet meg aszerint, hogy a kapcsolat jellege egy az egyhez (oneto-one), több az egyhez (many-to-one). Egy az egyhez kapcsolatra akkor van szükség, ha címzési szempontból inkompatibilis hálózatokat kapcsolunk össze, vagy a privát hálózat egyes gépeit közvetlenül címezhetővé akarjuk tenni a külső hálózatról. Ezt nevezi az ajánlás NAT-nak, vagy statikus NAT nak. A használt további kifejezések: NAPT (network address and port translation), cím és port fordítás. Hasonló értelemben használt kifejezések: PAT (port address translation) IP masquerading, IP elfedés; NAT Overload (CISCO konfigurációs állományokban); many-to-one NAT. Valamennyi kifejezés több az egyhez kapcsolatot jelöl, és általában ezt szokás egyszerűen NAT-nak nevezni. Az alhálózat a külvilág felé általában egyetlen IP címmel rendelkezik. Ha van több statikus NAT cím is, akkor minden ilyen belső címhez tartozik egy további külső, WAN oldali cím is. A belső, privát címek nem jelennek meg a nyilvános interneten. A statikus NAT általában biztonsági célokat szolgál. A külvilág és a belső un. privát hálózat között elhelyezkedő útválasztó kívülről nem útválasztónak, hanem egyetlen 181

(+ a statikus NAT címek) eszköznek tűnik. A privát hálózatok számára fenntartott címtatományok: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 A több az egyhez működés azon alapul, hogy az útválasztó az egyes kapcsolatokhoz port-számot is hozzárendel, és a hozzárendelést a NAT címfordító táblában tárolja. A külvilág felé egyetlen IP cím jelenik meg, ahonnan különböző port-számokról indítanak folyamatokat. Elvileg a 16 biten leképezhető, mínusz a foglalt portok számú kapcsolat hozható létre. A portszám kiválasztása véletlenszerű, de nem lehet un. ismert port, vagy használatban lévő port sem. Példaként tételezzük fel, hogy 193.225.18.29 szerver 80-as portjáról akarunk egy WEB oldalt lekérni. A kérést előállító gép 10.0.0.2 belső címmel rendelkezik. A kliens a kérést önkényesen pl.: 4301 porton továbbítja. A NAT útválasztó önkényesen kijelölheti a külvilág felé a kérést előállító portszámot, pl.: 5002. A kérés elküldésekor az útválasztó a saját WAN oldali címét és az 5002-es portszámot tünteti fel a kérésen, mikor 193.225.18.29:80 as címhez fordul. A beérkező válaszhoz megkeresi a NAT címfordító táblában az 5002-es bejegyzéshez tartozó belső IP címet és portszámot. Sokan bírálják a NAT-os megoldásokat, mivel több hálózatos alapelvet is sért a megoldás (végponttól-végpontig elv, a port cím folyamatokhoz rendelt és nem hoszt címzésre való, ). Problémát akkor jelent a NAT, ha az alhálózatba szervert szeretnénk üzemeltetni,ami a jól ismert port -számokon várja a kéréseket. A NAT zavarja a P2P hálózatok működését, mivel a NAT mögött lévő eszköz nem tud szerverként működni. A probléma megkerülhető az un. NAT áthidalás alkalmazásával. Igazi megoldás az alkalmazás szintű átjárók (Gateway) használata (pl.: SKYPE átjátszók), vagy áttérés az IPv6 protokollra. Más megközelítése a problémának, amikor a privát hálózat és a külvilág közé olyan eszközt telepítünk, ami több publikus IP címmel rendelkezik. A privát hálózat éppen aktív hosztjai egy az egyhez kapcsolattal csatlakozhatnak a külvilághoz. A lehetséges egyidejű kapcsolatok száma a publikus IP címek számával egyezik meg. 182

UPnP (Universal Plug and Play) protokoll A protokoll a NAT áthidalására létrehozott eszköz. A működés feltétele, hogy mind a hoszt, mind az útválasztó implementálja a protokollt, mindkettő UPnP kompatibilis legyen. Az alapgondolat az, hogy az útválasztó által meghirdetett portszámot az alkalmazás határozza meg, ne az útválasztó. Ez lehetővé teszi, hogy az alkalmazás meghirdesse az elérhetőségét. Az alkalmazás tehát azt kéri az útválasztótól, hogy hozzon létre leképzést a privát IP cím, privát portszám és egy nyilvános IP cím, nyilvános portszám között. Ha ez megtörtént a hálózaton lévő csomópontok képesek lesznek TCP vagy UDP kapcsolat kialakítására. Pl.: egy BitTorrent alkalmazás meghirdetheti a nyomkövetőjének (tracker, a résztvevő partnerek nyilvántartása), hogy milyen publikus címen érhető el. Legyen a BitTorrent alkalmazás privát címe 10.0.0.2:4301. Az útválasztó publikus címe 193.93.41.9. Az alkalmazás által választott port 5201. Az alkalmazás azt kéri, hogy az útválasztó feleltesse meg (írja be a NAT táblájába) 193.93.41.9:5201 és a 10.0.0.1:4301 megfeleltetést, hirdesse meg 193.93.41.9:5201 címet. A külső hosztok most már kezdeményezhetnek kapcsolatot (küldhetnek TCP SYN szegmenst tartalmazó csomagot) a NAT mögötti hosztnak. A megoldás hatékony, és megbízhatóan működik. A NAT azonban számos biztonsági és megvalósítási problémát takar, (DNS szerver bejegyzések a NAT mögött üzemelő kiszolgálókról, biztonsági kérdések,kapcsolat a hitelesítő szerverekkel) melyek tárgyalása túlmutat a félév anyagán. Sok hasznos ismeretet találhatunk az upnp.org fórumon, vagy a CISCO NAT fórumon is. Irodalom: http://www.cisco.com/en/us/docs/security/asa/asa82/configuration/guide/asa82cfg.pdf, Routing with NAT -Part of the documentation for the IBM iseries 8.2.5. Az IP új generációja: IPv6 A fejlesztés céljai: Nagyszámú hoszt támogatása (>10 12 ) Forgalomirányító táblázatok méretének csökkentése Protokollok egyszerűsítése, gyorsabb feldolgozás a routereken Hitelesség és titkosság biztosítása 183

Jobb alkalmazkodás a szolgáltatás típusához, valós idejű adatok jobb kezelése Többesküldés lehetősége, hatósugarak megadásának lehetősége Mozgó hosztok jobb támogatása IPv4 és IPv6 együttélésének biztosítása hosszabb távon is. Az IPV6 fejlesztés 1992-1997 között folyt intenzíven. A javaslatban az eredeti megnevezése Simple Internet Protocol Plus volt. Az IPv6 jelölést azért kapta, mert az IPv5 már foglalt volt egy kísérleti fejlesztés számára. Az IPv6 nem kompatíbilis az IPv4-el, de a protokollok legnagyobb részével igen (TCP, UDP, ICMP, IGMP, OSFP, BGP és DNS). A hálózat vezérlésével és a névfeloldással kapcsolatos protokollok tehát kompatibilisek. Az IPv6 magyarországi mérföldkövei ( Idézet Wikipedia szócikkből) A BME Folyamatszabályozási Tanszékén már 1997-ben folytak kutatások a IPv6 hálózatok kiépítésének tesztelésére. A NIIF által üzemeltetett és fejlesztett felsőoktatási és kutatói hálózaton 2001- ben kezdődtek meg az IPv6-os kísérletek és 2005 óta szolgáltatásként elérhető az IPv6 az egyetemek, kutatóintézetek és közgyűjtemények számára. Az Externet 2009. május 19-én zárta le a közel egy éves tesztidőszakot és azóta nyújtja rendes szolgáltatásként az IPv6-ot. A Magyar Telekom 2009. november 2-án kezdte meg hálózatában az IPv6 nyilvános tesztelését. [5][6] A Magyar Telekom 2011. június 3-án kapcsolta be az IPv6 hálózatát. Az IPv6 előnyei a végfelhasználó számára Az IPv6 amellett, hogy a jelenlegi dinamikus IP-cím kiosztás helyett minden végfelhasználó kaphat egy fix IP-címet, a biztonság terén is hoz újításokat a jelenleg használt IPv4-hez képest. A 128 bites címtartomány több ezer milliárd eszköz számára biztosíthat IP-címet, így gyakorlatilag kimeríthetetlen a kapacitása. Lefordítva ezt a háztartásokra, az otthonokban minden internetképes eszköz önálló IP-címet kaphat, így azok zavar nélkül kommunikálhatnak egymással. Ha az eszközök az internethez kapcsolódnak, akár a fűtőberendezéseket vagy a mosógépet is bekapcsolhatjuk mobiltelefonunkon keresztül. Sokan magát az IPv6-ot tekintik killer application -nek, mint ami megteremti a hálózatcentrikus világ létrehozásának lehetőségét. Ideális esetben az IPv6 használata a végfelhasználó számára láthatatlan marad. Az egyetlen változás, 184

hogy az internetezés egyes esetekben egyszerűbbé válhat, illetve megjelennek majd olyan szolgáltatások/alkalmazások melyek IPv4 alapon csak igen bonyolult módon lennének nyújthatóak. Az IPv6 a végfelhasználó szempontjából egy ajtó, mely megteremti a lehetőséget a változásra. Éppen úgy, mint ahogyan anno a vezetékes világban a DSL, vagy a mobil világában a 3G megjelenése indított el egy-egy kommunikációs forradalmat. IPv6 szabványok és migrációs stratégiák [szerkesztés] Az IPv6-ra vonatkozó, annak alapvető működését rögzítő szabványok az IETF szervezetében születnek. [10] Ugyanakkor érdemes nyomon követni más szabványosítási szervezetek munkáját is, hiszen fontos irányelveket fogalmaznak meg például a Broadband Forum (BBF) munkacsoportjai, melyek a meglévő szabványokon alapuló szolgáltatói környezet tekintetében rögzítenek ajánlásokat. [11] Az IPv6-bevezetési megoldások tekintetében számos eltérő a szabványosítás különböző fázisában lévő metódus látott napvilágot (pl. 6to4, 6rd, DS-lite, Softwire, Carrier Grade NAT, stb.). Az egyes megoldásoknak természetesen eltérő előnyei ill. hátrányai vannak, így folyamatos vitatémát biztosítanak a szakértők számára. Egyetértés van azonban a tekintetében, hogy a felhasználók számára egyidejűleg kell mind IPv4, mind IPv6 kapcsolódást biztosítani. Az ilyen megoldást nevezik dualstack elérésnek. A dual-stack [12] megoldás egyik fő előnye, hogy nincs szükség IPv4 és IPv6 hálózati átjárók létrehozására, melyek segítségével a csak egyik vagy másik verziót támogató végpontok kommunikálni tudnának egymással Az IPv6 föbb tulajdonságai: 128 bitre növelt címtartomány. Új címzési séma. Hatékonyabb és flexibilisebb csomagformátum, egyszerűbb fejrész A továbbfejlesztés lehetősége az opcionális fejrészek bevezetésével A biztonsági mechanizmusok beépültek a protokollba (hitelesítés, titkosítás) Névfeloldás és a csoportmenedzsment része a protokollnak Az ARP (Address Resolution Protocol) és az IGMP (Internet Group Management Protocol) kikerült a rendszerből. Szolgáltatások a jobb támogatása 185

32 bit verzió prioritás folyamatcímke Adat mező hossza Következő fejrész Átugrás korlát Forrás címe (16 byte) Cél címe (16 byte) 8.7.ábra. IPv6 fejrész A verzió mező az IPv4-nél mindig 4, az IPv6-nál mindig 6. A prioritás mezőben a 0-7 értékek olyan alkalmazásokhoz tartoznak, melyek képesek lassítani egy esetleges torlódásnál. A 8-15 értékek real-time folyamatokhoz tartoznak. Ezek az alkalmazások akkor sem lassítanak, ha minden csomag elvész. (Élő beszéd, mozgókép). Az alkalmazás szintjén természetesen más a helyzet. Egy videó átvitelnél esetleg tudom rontani a képpontok számát, a színmélységet, a képváltások számát, stb. Ez azonban nem a hálózat feladata, és nem is tudja befolyásolni. Mindkét csoporton belül az alacsonyabb szám alacsonyabb prioritást jelent. A folyamatcímke címke a virtuális áramkörök előnyei próbálja becsempészni a datagram típusú rendszerekbe. Az összeköttetést a forrás és célcím, valamint a folyamatcímke együttesen azonosítja. Ez lehetővé teszi, hogy több folyamat legyen aktív egy időben két IP cím között. Az egyes címkékhez különleges elbánást is rendelhetünk a routerekben, ami hasonló hatású lehet, mint a virtuális áramkörök létrehozása. Az adatmező hossza a tényleges adatmező hosszát jelöli, nem számolják bele a 40 byte hosszú fejrészt ( IPv4-nél bele számít!). A következő fejrész azt mutatja, hogy milyen további opcionális fejrészek vannak a csomagban, ha vannak. Az opcionális fejrész bevezetése tette lehetővé a kötelező fejrész jelentős egyszerűsítését. A kiegészítő fejrészek az átugrási opciókra forgalomirányításra darbolásra 186