Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

IP és mobilitás támogatás

Hasonló előadás


Az előadások a következő témára: "IP és mobilitás támogatás"— Előadás másolata:

1 IP és mobilitás támogatás
dr. Imre Sándor

2 Tartalom Trendek Terminológia IPv4 összefoglaló Gondok az IPv4-gyel
IPv6 - új elemek az IPv4-hez képest Az IPv6 fejléc formátuma Az IPv6 címzési rendszere Az IPv6 útvonalválasztása Plug & Play Biztonsági kérdések Átmenet az IPv4-ből az IPv6-ba IPv6 kísérleti rendszerek IPv6 és a mobil rendszerek

3 Tartalom Mobilitás támogatása az IPv6-ban -Mobil IPv6
Az IETF Munkacsoport Bevezetés Az IPv6 összevetése az IPv4-gyel a mobilitás szemszögéből Mobil IPv6 áttekintése Alapvető működés Az új IPv6 cél opciók áttekintése Adat struktúrák Binding menedzsment Követelmények az IPv6 csomópontokkal szemben

4 Tartalom Levelező csomópont - Correspondent Node működése
Csomagok vétele mobil csomóponttól Binding Update-k vétele Kérés a kötés tárolására Kérés a kötés törlésére Binding Acknowledge küldése Binding Request küldése Tároló kezelés ICMP hibaüzenetek vétele Csomagok küldése a mobil csomóponthoz Az otthoni ügynök működése Router Advertisement üzenetek vétele Dinamikus otthoni ügynök cím felderítés Elsődleges care-of cím regisztrálása

5 Tartalom Elsődleges care-of cím de-regisztrálása
Mobil csomópontnak küldött csomagok elfogása Elfogott csomagok tunnelezése a mobil csomóponthoz Az otthoni alhálózat átszámozása A mobil csomópont működése Csomagok küldése otthontól távol Csomagok vétele otthontól távol Mozgásdetekció Új care-of cím létrehozása Binding Update küldése az otthoni ügynöknek Dinamikus otthoni ügynök cím felderítés Binding Update küldése a levelező csomópontnak

6 Tartalom Binding Update küldése az előző alapértelmezés szerinti útvonalválasztónak Binding Update-k újraküldése Gyakoriság korlátozás a Binding Update-k küldésénél Binding Acknowledgement-k vétele Binding Update-k vétele ICMP hibaüzenetek vétele Tunnelezett Router Advertisement üzenetek vétele Többszörös care-of címek használata Multicast csomagok útvonalválasztása Hazatérés

7 Trendek

8 Konvergencia az IP-be IP Számítástechnika Média Távközlés Mobilitás
Internet hozzáférés Elektronikus levelezés Multimédia Mobil számítástechnika l video on demand interaktív video TV/Rádió/Adat elosztás Mobilitás Nagysebességű szolgáltatások IP Mobilitás Személyi szolgáltatások Mobilitás szélessávú szolgáltatások Távközlés l ISDN szolgáltatások Video telefon Szélessávú adatszolgáltatások

9 Felhasználói előrejelzés
Forrás: Ericsson

10 Internet felhasználói előrejelzés
100 200 300 400 500 600 700 800 900 1,000 95 96 97 98 99 00 01 02 03 Subscribers (in million) Japan (excl. PHS) Asia Pacific (excl. Japan) Latin America Rest of the world North America Western Europe Forrás: IPv6 Fórum IX. 25.

11 Media Gateways Hálózati jövőkép Today Single-service networks GSM
Radio/TV Fixed Telephony LAN (Data) Services Servers Clients IP Backbone Network Access Future Multi-service networks Communcations Control Content Media Gateways Transport, Switching & Access Networks

12 Hálózati jövőkép Forrás: Nokia PSTN (vonalkapcsolt) IS-41 / MAP
Szélessávú IP hálózat Selector OMC Hozzáférés felügyelet Egyéb Szerverek (billing,etc.) Képesség Szerver Gateway Directory Name Server Vezetéknélküli hívás szerver Vállalati szerver (intranet) Tartalom szolgáltató Internet Vezetékes felhasználó 2G+/3G RF hozzáférés Terminálok Mobil/Nomád IP telefon, Web telefon Zsinornélküli környezet Helyi lakos IP alapú PBX Iroda Forrás: Nokia

13 Forradalom a hálózati technológiában
Csomagkapcsolt adathálózatok PSTN Ma Vezeték nélküli hozzáférési hálózat Átmenet PSTN GPRS, EDGE Csomagkapcsolt adathálózatok Vezeték nélküli hozzáférési hálózat A jövő PSTN 3G és azon túl Csomagkapcsolt adathálózatok Vezeték nélküli hozzáférési hálózat GSM, HSCSD = Adat = Vonalkapcsolt beszéd = Csomagkapcsolt beszéd

14 Mobil rendszerek

15 Terminológia

16 Terminológia IP: Internet Protocol Version 6 (IPv6).
Csomópont (node): eszköz, mely IP-t implementál Útvonalválasztó (router): csomópont, mely olyan IP csomagokat továbbít, melyeket nem neki címeztek Hoszt (host): minden csomópont, amely nem router Link: kommunikációs eszköz vagy közeg, amelyen a csomópontok a link (adatkapcsolati) rétegen keresztül kommunikálnak (pl. Ethernet). A link a közvetlenül IP alatti réteg. Interfész: A csomópont csatlakozása a linkhez Subnet prefix: bit string, amely egy IP cím kezdõ bitjeit tartalmazza.

17 Terminológia Interfész azonosító:szám, mely egy linken a csomópont interfészének azonosítására szolgál. Az interfész azonosító a csomópont IP címének subnet prefixet követõ része. Link-réteg cím: interfész link-réteg azonosítója, pl. IEEE 802 címek az Ethernet linkeken. Csomag: IP fejléc + fizetett információ ( payload). Otthoni cím (home address): mobil csomóponthoz az otthoni linkjén belül rendelt IP cím Otthoni subnet prefix: a mobil csomópont otthoni címének megfelelõ IP subnet prefix.

18 Terminológia Otthoni link (home link): az a link, amelyen a mobil csomópont otthoni subnet prefixe definiálva van. A szabványos IP útvonalválasztás a mobil otthoni címére küldött csomagokat az otthoni linkre továbbítja. Mobil csomópont: olyan csomópont, amely képes az egyik linkrõl a másikra átlépni úgy, hogy közben az otthoni címén keresztül folyamatosan elérhetõ marad. Mozgás: a mobil csomópont megváltoztatja a csatlakozási pontját az Internethez úgy, hogy másik linkre kerül. Azt a csomópontot, amelyik nem csatlakozik az otthoni linkjéhez „otthonról távollevõnek” hívjuk.

19 Terminológia Levelezõ csomópont: az a csomópont, amivel a mobil csomópont kommunikál. Lehet mobil vagy fix is. Idegen subnet prefix: bármely IP subnet prefix, ami nem egyezik meg a mobil csomópont otthoni subnet prefixével. Idegen link (Foreign link): bármely link, ami nem egyezik meg a mobil csomópont otthoni linkjével. Otthoni ügynök (home agent):egy útvonalválasztó egy mobil csomópont otthoni linkjén, melynek segítségével a csomópont regisztrálja az aktuális care-of címét. Mialatt a mobil csomópont nincs odahaza az otthoni ügynök elfogja az otthoni linkre érkezõ csomagokat, átcsomagolja õket és továbbítja a csomópont regisztrált care-of címére.

20 Terminológia Care-of cím: egy mobil csomóponthoz rendelt IP cím, mialatt a csomópont egy idegen linket látogat meg. Ezen IP cím subnet prefixe idegen subnet prefix. Egy csomópontnak egy idõben több care-of címe is lehet (pl. különbözõ subnet prefixszel). Ezek közül azt, amelyik a csomópont otthoni ügynökénél van regisztrálva, elsõdleges care-of címnek hívjuk. Kötés (binding): egy mobil csomópont otthoni címének összerendelése egy care-of címmel. Privacy - személyes adatok kezelesi joga : az egyén azon joga, hogy felügyelje és befolyással legyen a vele kapcsolatos információkra, illetve, hogy kigyűjthesse, tárolhassa azokat, és eldönthesse ki számára legyenek felfedhetõk. Confidentiality: azon képesség, hogy a nem hitelesített entitások számára az információ nem áll rendelkezésre, illetve nem fedhetõ fel számukra,

21 IPv4 összefoglaló

22 OSI-ARPA referencia modell
Az OSI szabványosított egy hálózati referencia modellt. Ez gyakorlatilag egy elsődleges (master, elterjedtebb formájában: hálózati verem) protokoll, amely az összes protokoll egymáshoz rendeltségét határozza meg. Továbbá meghatározza a jövendőbeli protokollok szerkezetét is. A modellt azért alakították ki, hogy a hálózati szabványok számára egységes keretet biztosítsanak. Ami többnyire sikerült is, de a nyílt rendszerek elterjedésével (főleg az Internet), egyre inkább alapvetővé válik az általános trend, hogy az ARPA (Advanced Research Project Agency) által definiált réteg veszi át a referencia szerepet.

23 OSI-ARPA referencia modell
A referencia modell kommunikáló entitások viszonyaiban írja le a hálózat működését. Egy a kommunikációban résztvevő berendezés belsejében több, egymástól jól elkülöníthető egységet, entitást tételez fel, melyek mindegyike más-más feladatot valósít meg. Például az egyik felelős a jeleknek a kábelre való juttatásáért, egy másik a titkosításért vagy az információ célba juttatásához a megfelelő útvonal kiválasztásáért. Az entitások kommunikációs szolgáltatásokat nyújtanak, mint például bitfolyam átvitele, információcsomagok hibamentes átvitele vagy dialógusokba szervezett kommunikáció. Ezeket a szolgáltatásokat vagy az alkalmazások (és azon keresztül a felhasználó) veszi igénybe vagy egy másik hálózati entitás, mely a felhasznált szolgáltatások segítségével többletszolgáltatásokat nyújt.

24 OSI-ARPA referencia modell

25 Fizikai és adatkapcsolati réteg
A fizikai réteg felelős a hálózat hardware elemeinek közvetlen kezeléséért, a „biteknek a kábelre juttatásáért". Itt rögzítik a közvetít ő médium fizikai és elektromos tulajdonságait. (Például csatlakozóméret és lábkiosztás valamint a jelszintek vagy a kódolás.) A tipikus szolgáltatás bitfolyam átvitele olyan bithiba aránnyal, amilyet az adott fizikai közvetítő közeg lehetővé tesz. Az adatkapcsolati réteg szolgáltatása a két szomszédos (közvetlen fizikai összeköttetéssel rendelkező) berendezés közötti, biztonságos bitfolyam átvitel. A bitfolyamot többnyire egységekre tördelik, melyeket kereteknek (frame) hívunk. A réteg úgy teszi biztonságossá az átvitelt, hogy ha hibás keret érkezik, akkor annak újraküldését kéri mindaddig, amíg az hibamentesen meg nem érkezik. A szolgáltatás kiterjed 2. szint ű kapcsolatok létrehozására, adatátvitelre és a kapcsolat lebontására. Szokásos az adatkapcsolati réteget két független alrétegként kezelni.

26 Adatkapcsolati réteg Az alsót közeg-hozzáférési (Medium Access Control) alrétegnek nevezzük, a fölső t pedig kapcsolatvezérlési (Logical Link Control) alrétegnek. A MAC alréteg feladata a közeghez való hozzáférés, a kereteknek a kábelre való juttatása (az adási jog megszerzése és az adás), míg az LLC ellenőrzi a vett keretek épségét, kéri és végzi az újraküldést és szervezi a kapcsolatot. Mindezt természetesen a MAC réteg szolgáltatásainak (keret adása és vétele) felhasználásával. (pl.: Ethernet hálózatok)

27 Hálózati réteg A hálózati réteg végzi a történelmileg kialakult nagykiterjedésű hálózatokon belüli adattovábbítást, valamint két különböző fizikai hálózat közötti átjárást. Például az IP (Internet Protocol) képes adatot átvinni a világ bármely két, az Internethez kapcsolt számítógép között, bár közben a legkülönfélébb fajta átviteli közegeken (2. rétegbeli berendezések) halad át az információ. Az adategységet ezen a szinten csomagnak hívjuk.

28 Hálózati réteg A hálózati protokollok két részre oszthatók:
Kapcsolat-orientált: az adatok átvitele előtt szükség van valamiféle kapcsolatfelvételre a két végpont között. Minden csomagot ellátunk a kapcsolat azonosítójával, így a hálózat a már kiépült útvonalon keresztül továbbíthatja csomagjainkat. Ez azzal az előnnyel jár, hogy nem kell minden csomagba elhelyeznünk a címzett és a feladó címét, csupán a kapcsolat azonosítóját. Ezen felül a hálózatnak nem kell minden egyes alkalommal kitalálnia, hogy milyen útvonalon továbbítsa a csomagot, hiszen a kapcsolat felépítésekor az útvonal rögzül. A kapcsolatorientáltság legjobb analógiája a telefonhálózat, ahol a beszélgetés a híváskor épül ki.

29 Hálózati réteg Datagram (kapcsolatmentes eset): az adattovábbításhoz nincsen szükség kapcsolatfelvételre, egyszerűen veszünk egy csomagot, megcímezzük, és a hálózatra bízzuk annak továbbítását. Ilyen például az IP is. A datagram hálózatokban elmarad a kapcsolatfelépítés által okozott késleltetés. Ez a megoldás ezen felül sokkal robosztusabb is. Ha ugyanis egy kapcsolatorientált hálózatban kiépült kapcsolatunk közepén valamilyen hiba keletkezik, a kapcsolat megszakad. (Az ATM-ben lehetőség van dinamikus VC -Virtual Circuit- felépítésére is; ekkor ha a vonal megszakad, átkerül egy másikra.) A datagram jelleg ű hálózatok esetében viszont minden csomag egyedi elbírálás alá esik és ha egy útvonal megszűnik, akkor egy másikon még célba juthat a csomag. Arról, hogy hiba történt, a kommunikáló felek nem is értesülnek. A datagram jellegű hálózatok legjobb analógiája a postai levéltovábbítás, ahol a megcímzett borítékot egyszerűen beejtjük a postaládába, s az célba jut még vasutassztrájk esetén is, legfeljebb kis késleltetéssel.

30 Hálózati réteg Minthogy a kapcsolat-orientált esetben minden csomag ugyanazon az útvonalon halad, könnyű elérni, hogy a csomagok a feladási sorrendben érkezzenek meg. A datagram jellegű hálózatoknál ez nem garantálható, hisz két csomag nem feltétlenül ugyanazon az útvonalon halad és a később elküldött megelőzheti a korábbit. Trend, hogy a két paradigma lassan összemosódik. Mind a kapcsolatorientált ATM hálózatokban léteznek datagram jelleg ű megoldások, melyek rövid és ritka üzenetek elküldését teszik lehetővé a költséges kapcsolatfelépítés nélkül, mind a datagram jellegű Internetben terjed el egyre inkább a folyam (flow) fogalma az olyan csomagsorozatokra, melyek megadott útvonalon haladnak. Ezen utak mentén ugyanis erőforrások lefoglalásával garantálni lehet, hogy az adott folyamhoz tartozó csomagok nem szenvednek túl nagy késleltetést. Ezek a módszerek egyesítik a két paradigma előnyeit.

31 A transzport - szállítási réteg
A transzport réteg az első vég-vég réteg. Az OSI definíció szerint a világ bármely két számítógépe között lehet vele kapcsolatot teremteni, függetlenül a közbeeső hálózati rétegektől. A gyakorlatban azonban a 4. szint ű protokollok erősen kötődnek egy hálózati protokollhoz (pl. TCP és UDP az IP-hez), nem pedig az azoktól való függetlenséget valósítják meg, hanem inkább valamiféle többletszolgáltatást nyújtanak. Így például datagram jellegű hálózatok fölött is létezik kapcsolat-orientált transzport protokoll (például a TCP az IP felett). Maga a hálózati protokoll azonban ettől még szigorúan datagram jelleg ű és csak a végpontok „tudnak" a kapcsolat kiépüléséről. A kapcsolat léte alatt elküldött információ közönséges csomagok formájában utazik, akár mindegyik csomag teljesen más útvonalon. A végpontok feladata a sorbarendezés és ezzel sorrendhelyes átviteli szolgáltatás nyújtása. Az ilyen szolgáltatást igénybe vevő fölsőbb rétegnek azonban nem is kell tudnia arról, hogy maga a hálózat nem kapcsolat-orientált.

32 TCP és UDP A TCP/IP család két legfontosabb transzport protokollja a TCP és az UDP. Ezek, bár a hálózati IP fölött működnek, mégsem egyértelműen feleltethetők meg az OSI modell 4. rétegének. Inkább úgy fogalmazhatunk, hogy a TCP-IP és UDP-IP együtt alkotja a 4. Szintet vagy a 3-4. szintet együtt. A TCP (Transmission Control Protocol) egy kapcsolatorientált, byte-stream jellegű, megbízható protokoll. A kommunikáció megkezdése előtt ki kell építeni a kapcsolatot, majd megkezdhetjük az adatátvitelt. Hiba (elveszett vagy hibás csomag) esetén a TCP réteg maga kér újraadást, elfedve ezzel az IP szint megbízhatatlanságát.

33 TCP és UDP A TCP processz egy több mint 20 állapotos állapotgép, meglehetősen bonyolult, hiszen az IP szint számos hibát képes produkálni. Az adat, amit átküldhetünk egy byte-folyam, amit a TCP csomagokra vág és elküld. A kapcsolat full-duplex és rendelkezik egy sebességszinkronizációs mechanizmussal, ami megakadályozza, hogy az adó elárassza a vevőt. A TCP figyeli a kapcsolatot és megpróbálja felbecsülni az effektív sávszélességet (torlódásokból, válaszidőből, ICMP üzenetekből, stb.), amit szintén felhasznál a kimenő adatsebesség beállításakor.

34 TCP és UDP Annak érdekében, hogy egy állomás egyszerre több élő TCP kapcsolattal rendelkezhessen, az TCP adatot hordozó IP csomagokban nemcsak a cél-címet kell megadni, hanem az úgynevezett TCP portot is. Ez a 16 bites szám azonosítja a célállomáson belül megszólítandó kommunikációs partnert. A 0 és 1023 közötti portszámok foglaltak, ezeken találhatóak az ismert szolgáltatások (well-known-services), e fölött szabadon használhatóak a port-számok. Például a HTTP processz hallgatja a 80-as TCP portot, a bejövő kérelmet feldolgozza és válaszol (például küldi a WWW oldalt). Aki tehát egy állomás HTTP processzével kíván kommunikálni, az a 80-as TCP portot szólítsa meg. Minden TCP által előállított IP csomagban a TCP protokollazonosítója található, így az állomás az IP csomag vételekor az információt el tudja juttatni a TCP feldolgozóba. Ott a TCP fejlécből kiolvasva, a megfelel ő portot hallgató processzhez juttathatjuk el az információt.

35 TCP és UDP Az UDP (User Datagram Protocol) egy összeköttetésmentes protokoll. Az UDP információját egy IP csomagba helyezi, ellenőrző összeget számol hozzá és feladja. Így a kézbesítést nem garantálja, de a hibás kézbesítést észlelhetővé teszi. Olyan kérdés-válasz jellegű szolgáltatásokhoz használatos, ahol ha a kérdés vagy a válasz elvész, a hiba egyszerű újrakérdezéssel megoldható. Az, ugyanis, hogy egy csomag elvész, ritka esemény és ilyen kérdés-válasz esetén könnyen felderíthető. Az UDP egyszerűsége miatt sokkal kíméletesebben bánik a hálózati erőforrásokkal, mint a TCP. (Egy TCP kapcsolat kiépülése minimum 3 IP csomagba kerül, mielőtt még akár 1 bájtnyi felhasználói adatot átvittünk volna.) A TCP-hez hasonlóan az UDP is rendelkezik portokkal, melyek számkiosztása független a TCP portokétól.

36 IPv4 Az IP egy csomagkapcsolt, datagram jellegű , megbízhatatlan hálózati protokoll. Az információt csomagokban továbbítjuk, a csomagok haladási útvonaláról azok feladásakor semmit sem tudhatunk. Minden csomag tartalmazza a küldő és a vevő címét. A protokoll nem garantálja sem a csomag továbbítását, sem azt, hogy jó helyre érkezik, sem azt, hogy hibátlanul. A hibakezelés és -korrekció a felsőbb rétegek feladata.

37 IP4 fejléc formátum 20 octet + opciók : 13 mező, 3 flag bit 0 bits 31
Ver IHL Total Length Identifier Flags Fragment Offset 32 bit Source Address 32 bit Destination Address 4 8 24 16 Service Type Options and Padding Time to Live Header Checksum Protocol Removed Changed

38 IP4 fejléc formátum Version: a jelenlegi IP verziószámot, ami most még 4 (IPv4). Header Length: a fejléc hosszát. Type of Service (TOS): a szolgáltatás típusát határozza meg; lehetővé teszi a datagramokkal való „bánásmód” megkülönböztetését, de korlátozottan . Ezt ma már DS (Differentiated Service) mezőnek hívják (DiffServ). Minthogy a specifikáció nem követelte meg ezeknek a biteknek a figyelését, a jelenlegi Internetben nagyon sok helyen nem sokat számít a TOS bitek beállításai. De mára az igények megváltoztak. Total Length: a csomag hossza . Identification: az Internet réteg által a csomaghoz rendelt egyedi azonosító számot. Flags and Fragment Offset: az Identification mezővel együtt segítenek abban, hogy a több részben küldött datagramok a fogadó gépen ismét az eredeti adattá álljanak össze.

39 IP4 fejléc formátum Time To Live: egy datagram elküldésénél ezt a mezőt maximumra állítja. Egy másodpercben megadott érték és a csomag élettartamát jelöli. Minden hálózati berendezés köteles másodpercenként csökkenteni ezen az értéken, és ha eléri a nullát, a csomagot el kell dobni. Ezzel érjük el, hogy egy csomag ne kerengjen az örökkévalóságig a hálózatban. A router-eknek akkor is csökkenteniük kell egyel ezt a mezőt, ha egy másodpercnél rövidebb idő alatt továbbítják a csomagot. Minthogy az esetek többségében ez történik, a TTL mező gyakorlatilag minden router-en való áthaladáskor csökken egyet. Protocol: annak a felsőbb szint ű protokollnak a kódját tartalmazza, amelyik számára a csomag szól. Header Checksum: ellen ő rz ő összeget. Source Address: a küld ő IP címe. Destination Address: a célállomás IP címe.

40 Fragmentáció A fragmentáció akkor következik be, ha haladási útvonalon a következő linken az MTU (Maximum Tansmission Unit) kisebb, mint a csomagméret. Ekkor a router (vagy maga a feladó) több darabra tördeli a csomagot, mindegyik darabba beleírja, hogy ez az eredeti csomag hányadik bájtjától kezdődő információkat tartalmazza és ad a csomagnak egy egyedi azonosítót. Az azonosító belekerül a fragmentbe és jelzi a vevőnek, hogy mely darabok alkotják az eredeti csomagot. A router a kapott darabokat egyesével feladja, és a hálózatra bízza őket. A nagyobb fragmentek esetleg később még tovább darabolódhatnak egy még kisebb MTU-jú linken. A vevő feladata a csomag összevárása és összerakása. A feladó egy bit (DF=Don't Fragment bit) beállításával kérheti, hogy csomagját ne darabolják, ez esetben, ha az MTU túl kicsi a csomag továbbításához, a csomagot eldobják és erről ICMP üzenetben tájékoztatják a feladót (lásd később).

41 Fragmentáció Az IP csupán azt követeli meg, hogy az alatta lévő hálózat képes legyen minimum 68 byte-os IP csomagok továbbítására, ez tehát a minimálisan szükséges MTU. Minden állomásnak képesnek kell lennie minimum 576 byte-os csomagok fogadására (egészben vagy fragmentálva) és javaslat, hogy ekkora csomagokon keresztül kommunikáljanak az állomások

42 Opciók Az opciók szolgálnak olyan ritka, IP szint ű funkciók megvalósítására, melyeknek nem volt érdemes a minden csomagban jelen lévő fejlécben helyen fenntartani. Az opciókat minden állomás köteles megérteni és feldolgozni, nem implementációjuk, csupán jelenlétük választható. Security. A csomag hitelesítéséhez szükséges információk. Source routing. A feladó által megadott útvonalon, állomások megadott listáján halad végig a csomag. Két vállfaja van, a szigorú (strict) és a laza (loose). Az első esetben csak a listán felsorolt állomásokon haladhat végig a csomag és ha két szomszédosnak felsorolt állomás nem szomszédos, akkor a csomag elvész és egy „Source routing failed" ICMP csomag érkezik a feladóhoz. A második esetben ha a listán két szomszédosnak feltüntetett állomás a valóságban nem szomszédos, akkor is továbbítódik a csomag a lista következő eleméhez, de a router-ek által kijelölt útvonalon.

43 Opciók Útvonalrögzítés. A csomag által érintett állomások IP címe rögzül a csomagban. Időbélyeg Stream ID. Egy 16 bites azonosító, főként más, folyam(kapcsolat)orientált hálózatokkal való együttműködés segítése miatt.

44 Internet Control Message Protocol (ICMP)
Az ICMP tulajdonképpen az IP felügyeleti protokollja, úgy viselkedik, mintha magasabb szintű protokoll lenne, de az IP integráns része. Egy ICMP csomag valójában egy IP csomag, melyben a protokoll azonosítója 1 . ICMP üzenetet a következő szituációkban küldenek: A címzett elérhetetlen. A router-ek küldik a feladónak, ha a cél nem létezik, vagy a hálózata végtelen távolságban van, esetleg beállított DF bit mellett fragmentációra lett volna szükség. A címzett is küldheti, ha például nem fut a jelölt protokollt támogató processz. Lejárt a csomag élettartama. A router-ek küldhetik, ha a TTL nullára csökkent, vagy a címzett, ha a fragmentek összevárására kijelölt idő letelt és még nem érkezett meg az összes darab. Hibás IP csomagot adtunk fel.

45 ICMP Túl gyorsan küldjük a csomagokat. Ezt az üzenetet router-ek vagy a címzett küldheti, tipikusan még mielőtt kimeríti erőforrásait, így az a csomag, amire válaszként jön, még célbaérhetett. Átirányítás (Redirect). Más irányba küldjük inkább az ehhez a címzetthez küldendő csomagjainkat, mert arra rövidebb az út. Ezt router-ek küldhetik az állomásoknak a hálózat működésének javítása érdekében. Echo és Echo reply. Ezzel a két üzenettel a címzett elérhetőségét és működését tesztelhetjük. Egy Echo üzenetre minden állomás kötelező Echo reply-jal válaszolni. (Ezt használja a UNIX alatti ping parancs is.) Időbélyeg kérés és válasz. Ez az állomások óráinak szinkronizálására használatos. Saját hálózat számának lekérdezése és megválaszolása. Arra szolgálnak, hogy egy állomás megszólítson valakit a saját hálózatán (a hálózat száma kitöltetlenül hagyható) és attól elkérje a hálózat számát. A válaszoló egy teljesen kitöltött címmel válaszol, így a lekérdező állomás is birtokába jut a hálózat számának.

46 ICMP Az eredeti ICMP funkciók mellé az RFC megjelenésével az ICMP router discovery mechanizmusa társult. A router-ek periodikusan hirdetményeket tesznek közzé a linken (Router Advertiement), melyekben számos paraméterüket közlik az állomásokkal (többek között MAC címüket). Az állomások így megismerik, milyen router-ek is vannak a linken és könnyen továbbíthatják nekik csomagjaikat, melyek nem a linkre szólnak. Az állomásoknak nem kell megvárniuk a hirdetmények periodikus közzétételét, hanem felszólításokkal (Router Solicitation) soron kívül is kiválthatják azokat.

47 IPv4 címzés Az IP 32 bites címeket használ, a címeket bájtonként, egymástól ponttal ('.') elválasztva, tízes számrendszerben írjuk. (Például ) Minden cím egy hálózati és egy állomásszámból áll. A hálózat száma azonosítja azt a hálózatot, melyen a cél található, az állomásszám pedig azon belül magát az állomást. Kezdetben a hálózat száma 7 bites, az állomás száma pedig 24 bites volt, minthogy kevés, de népes hálózatokra számítottak. A könnyebb olvashatóság kedvéért a 32 bites IP címet négy, ponttal elválasztott decimális számként ábrázolják, mindegyik decimális szám 0-tól 255-ig terjed, és a négy bájtos cím egy bájtját ábrázolja. Ennek megfelelően, egy IP cím lehet például a következő:

48 IPv4 címzés - A, B és C címosztályok
Később ezt a címformátumot A osztályú címnek nevezve még két címosztályt vezettek be, a B és C osztályt. Ezekben nagyobb hely volt a hálózat száma részére (14 és 22 bit) és kisebb az állomás számára (16 és 8 bit), több, de kisebb hálózat számára címteret biztosítva. Sajnálatos módon a legtöbb jelenlegi hálózat számára a B osztály sok, a C osztály kevés állomás bekapcsolását teszi lehetővé, s emiatt a B osztály kimerülni látszik.

49 IPv4 címzés Az Internet Multicast számára van fenntartva a D osztály, az ebben levő 28 hasznos bit struktúrálatlan és egy cím egy multicast csoportot jelöl. A D osztályt az IGMP (Internet Group Management Protocol) mellett vezették be az RFC 1112-ben. Az E osztályú címek későbbi felhasználásra vannak fenntartva és kevéssé valószínű , hogy valaha használni fogják őket. Ha az állomás száma helyére csupa 0-t írunk, a kapott szám magát a hálózatot azonosítja (például egy B osztályú cím esetén), ha csupa 1-et, akkor a hálózaton minden állomást broadcast jelleggel (például ).

50 IPv4 címzés Az állomások számára fenntartott mezőt gyakran két részre osztják, egyik rész a subnet-et (alhálózat) azonosítja, másik pedig azon belül magát az állomást. Ez oly elterjedt, hogy szinte az címzési architektúra részét képezi. [RFC950] Azt, hogy az állomás számára rendelkezésre álló biteket (B osztály esetén 16), hogyan osztják fel a subnet és a tényleges állomás azonosítója között, a rendszer szempontjából teljesen mindegy, mindössze egy subnet maszk megadása szükséges. Ebben a 32 bites maszkban minden bit 1 , ami a hálózat vagy a subnet számához tartozik és 0, ami magát az állomást azonosítja. Tehát, ha egy B osztályú hálózatban a felső 8 bitet tartják fenn a subnet jelölésére, akkor a subnet maszk lesz.

51 IPv4 címzés Újabban létezhetnek változó hosszúságú subnet-ek is, tehát egy hálózatban lehet olyan subnet, melynek azonosítására az állomásszám felső 8 bitjét használjuk, és lehetnek olyanok, ahol a felső 12 bitet. Természetesen a subnet-ek számait úgy kell kiosztani, hogy a felső 8 bitből el lehessen dönteni, hogy ez most egy 8 vagy 1 2 bites subnet szám. Ez akkor lehet hasznos, ha sok eltér ő méret ű subnet-ünk van és fix beosztás esetén nem elegendő a címtér. A módszer viszont egy fokkal bonyolultabb routing protokollt és adminisztrációt igényel.

52 IPv4 címzés Egy sub-neten lévő állomások szomszédosnak számítanak, tehát router közbeiktatása nélkül tudnak kommunikálni, egy közös linken vannak. Lehetséges azonban, hogy egy linken több subnet is legyen, azonban egy subnet nem tartalmazhat több linket, hiszen azok között az átjárás csak router-en át lehetséges. Ha egy linken több subnet van, akkor a különböző sub-neten lévő állomások, bár közvetlenül is kommunikálhatnának, mégis router-t vesznek igénybe

53 QoS támogatás Az Internet alapszolgáltatása a megbízhatatlan datagram továbbítás. A csomagok megkettőződhetnek, elveszhetnek, meghibásodhatnak, vagy helytelen sorrendben érkezhetnek. Az sem kizárt, hogy a mi állomásunk kap meg egy másvalakinek szánt csomagot. A hálózat nem nyújt semmiféle garanciát a továbbítás idejére, a sávszélességre vagy a késleltetés-ingadozásra vonatkozóan. Ezzel szemben mindent elkövet, hogy a csomagokat minél gyorsabban, pontosabban és nagy biztonsággal juttassa el a címzetthez. A fenti szolgáltatás jól megfelel a számítógépes adatok továbbítására, ahol a késleltetés nem kritikus. Egy fölsőbb réteg (TCP) ugyanis az elvesztett, rossz sorrendben érkező, vagy meghibásodott csomagokat ugyan késleltetés árán, de képes kezelni, azaz sorrendbe rakni vagy újraküldetni. Egy interaktív telnet kapcsolat ugyan már komolyabb zavarokat szenvedhet, ha nagy a késleltetés, ám néhány tizedmásodpercnyi válaszidő még könnyen torelálható.

54 QoS támogatás Azok az alkalmazások, melyek az utóbbi időben kezdenek elterjedni, alapvetően más szolgáltatásokat igényelnének. Természetesen ezzel a felhasználók nem törődnek, csupán használják a hálózatot, de megjósolható, hogy egy ponton túl már nem lesznek megelégedve a kapott minőséggel. Az is könnyen belátható, hogy e szolgáltatások hiányában a vállalatok a stratégiai jelentőségű adataikat nem az Interneten fogják továbbítani. Az olyan alkalmazások elterjedése, mint a Voice-over-IP vagy a virtuális magánhálózatok (VPN), mind attól függ, hogy a hálózat képes-e megkülönböztetett minőségű szolgáltatásokat biztosítani számukra. Másfelől az Internet-szolgáltatók igénye is egyre növekszik egy kiterjeszthető, többféle szolgáltatási szintet nyújtó technika iránt. Ez részint abból az üzleti érdekből táplálkozik, hogy ezáltal lehetőségük nyílik a magasabb szint ű szolgáltatásokért azoknak megfelel ő díjat felszámítani.

55 QoS támogatás Ebben az irányban az első kezdeményezést az ATM Forum tette meg, kifejlesztve a QoS egy átfogó modelljét. Az ATM-ben minden hívás saját szolgáltatás minőségi paramétereket határoz meg, dinamikusan, végponttól-végpontig terjed ő jelzéssekkel, melyet a hívás ideje alatt számára a hálózat biztosít. Az ATM által kínált mechanizmusok megvalósítása azonban túl bonyolultnak bizonyul a mai hardver és szoftver feltételek mellett. Az ATM hatására az IETF (Internet Engineering Task Force) berkein belül kívánatosnak látták, hogy az Internetet is ruházzák fel az ATM QoS-éhez hasonló lehetőségekkel. Így született meg az Integrated Services (IntServ) ötlete, melynek az ATM-éhez hasonló szolgáltatási osztályok és forgalmi paraméterek az elemei.

56 QoS támogatás Az IntServ megvalósítását támogató protokoll az RSVP (Resource reSerVation Protocol), amely lehetővé teszi, hogy a vevő az általa venni kívánt folyam számára a hálózattól bizonyos forgalomkezelő jellemzőket igényeljen. Az RSVP nem szerves része az IntServnek, csak egy lehetséges átviteli szolgáltatást nyújtó protokoll, ami alkalmas az IntServ számára fontos jelzések, üzenetek átvitelére. Ez a mechanizmus kis hálózatokban kiválóan működik, de az Internet gerinchálózati routereiben teljesen megvalósíthatatlan a milliónyi folyam igényeinek nyilvántartása és az erőforrások kizárólagos lefoglalása. A probléma másik megközelítése a Differentiated Service (DiffServ) architektúra melyet szintén az IETF szabványosít. A szolgáltatások megkülönböztetésének az egész Internetre való kiterjeszthetőségét biztosítja azáltal, hogy a routerek nem tárolnak folyamonkénti állapotot és nincs folyamonkénti jelzés sem.

57 Gondok az IPv4-gyel

58 Híres kijelentések Thomas Watson, chairman of IBM, 1943
I think there is a world market for maybe five computers.“ Thomas Watson, chairman of IBM, 1943 "640K ought to be enough for anybody." Bill Gates, 1981 “32 bits should be enough address space for Internet” Vint Cerf, 1977 (Honorary Chairman of IPv6 Forum 2000)

59 Címzés Az IPv4 nem jelzi a földrajzi távolságokat, ami pedig nagyon hasznos lenne az útvonalválasztás optimalizálásánál. A nagyméretű site-k több C osztályú blokkot igényelnek, ami miatt az interdomain routing táblák gyorsabban nőnek, mint a router memóriája A felosztott címtér kezelése drága és összetett feladat. 3 Millió Web Site (. Jan 1999) 700+ Millió weboldal 8000 ISP világ szinten (4700+ U. S.); A forgalom növekedése %/ évente 300 M M felhasználó 2002-r Csak 2 milliárd cím 6 milliárd ember számára!

60 Ideiglenes megoldások a címprobléma kezelésére
CIDR – Classless Inter-Domain Routing NAT - Network Address Translator A használaton kívüli címek visszakérése Használaton kívüli A osztályú címek kiosztása A cím-birtoklás jelenlegi struktúrájának módosítása

61 CIDR – Classless Inter-Domain Routing
A CIDR lényege, hogy szakít az A, B és C címosztályok koncepciójával. Helyette a hálózati prefix, hálózati maszk koncepcióját általánosítja. Az Internet routerek nem az IP cím első három bitje alapján állapítják meg, hogy hol húzódik a határ a hálózati cím és az állomáscím között, hanem e helyett a routing protokollok magukkal hordoznak egy bitmaszkot, amely a hálózati előtag hosszát adja meg. A CIDR-t ismerő routing protokollok nem törődnek a címosztállyal, mindössze a maszkot figyelik. Elemzők szerint, ha 1994/95-ben nem vezetik be a CIDR technológián alapuló címkiosztást, a routing táblák akkorára nőttek volna, hogy az Internet mára működésképtelen lenne. A legtöbb router ma már ismeri ezt a technikát, és jelenleg az IANA is CIDR alapján osztja ki a címeket.

62 NAT - Network Address Translator
A NAT technika manapság az egyik legelterjedtebb módja az Internetre kapcsolódásnak. Alapötlete az RFC 1918, amely az Internetre nem kapcsolódó IP alapú hálózatok címkiosztására tesz ajánlást. Ezeknek a hálózatoknak nem kell globálisan egyedi címeket lefoglalni, elég, ha a címek lokálisan egyediek. Éppen ezért az IANA 3 különböző méretű címtartományt különített el erre a célra: Egy szervezet, mely nem kívánja hálózatát az Internetre kapcsolni, tetszés szerint választhat ezekből a címekből, mindössze arra kell ügyelni, hogy a hálózaton belül ne legyen konfliktus. Így tehát nem kell az IANA-hoz fordulni IP-címekért, az IANA pedig vállalja, hogy ezek a címek nem kerülnek kiosztásra.

63 NAT - Network Address Translator
A gyakorlatban ezt úgy valósítják meg, hogy egy NAT-olni akaró szervezet kér egy vagy néhány (nem sok) IP címet az Internet szolgáltatójától, ez lesz a NAT külső oldalán. A hálózaton levő állomásokat megcímzi a fenti három címtartomány valamelyikéből vett címekkel, ez lesz a NAT belső oldalán. A NAT-oló modul dinamikusan rendeli a külső címeket a belsőkhöz, hiszen jóval kevesebb külső, globálisan egyedi cím van, mint belső. A NAT nagy előnye, hogy csökkenti az Internet eléréshez szükséges IP címek számát, mindemellett növeli a biztonságot (a belső hálózati struktúra láthatatlan a külvilág felé, csak a NAT külső oldalán elhelyezkedő címek látszanak), a hálózati struktúrát a szervezet akkor is megtarthatja, ha átáll egy másik Internet szolgáltatóra. Nagy hátránya az, hogy a kommunikációt ezáltal nem csak a végpontok irányítják, továbbá, ha két ilyen NAT-os tartományt szeretnénk egyesíteni, az számos problémát okoz a hálózatépítőknek.

64 A használaton kívüli címek visszakérése
Az RFC 1917 ajánlást tesz arra nézve, hogy azok a hálózatok, melyek biztonsági okokból sohasem kapcsolódnának az Internetre, szolgáltassák vissza az IANA-nak a már lefoglalt IP címeiket. Javaslatot tesz továbbá arra nézve, hogy azok az ISP-k (Internet Service Provider) amelyek túl sok használaton kívüli hálózati előtagot birtokolnak, szolgáltassák vissza ezeket az IANA-nak.

65 Használaton kívüli A osztályú címek kiosztása
Az A címosztály felső részét egyéb célokra tartják fenn, az IANA ezt a /2 címtartományt nem osztotta ki. Született egy ajánlás arra nézve, hogy ezt a címtartományt is ki kellene osztani, hiszen ez a teljes IP címtartománynak csak ez önmagában jelentős részét teszi ki.

66 A cím-birtoklás jelenlegi struktúrájának módosítása
A cím allokálás jelenleg úgy működik (természetesen a legfelső szintekről beszélünk), hogy egy ISP kér egy címtartományt az IANA-tól, azt megkapja és addig birtokolja amíg az neki jól esik (vagy ameddig fizetni tud érte). Az IETF elkészített egy ajánlást, melynek lényege, hogy az ISP csak “kölcsön” kapná a címtartományt, egy idő után le kellene mondania róla, és másikat kellene igényelnie. Ezáltal bizonyos dinamizmussal ruháznánk fel a címek allokálását, a módszernek azonban több nagy hátránya is van.

67 A cím-birtoklás jelenlegi struktúrájának módosítása
Először is, a CIDR technológiának egyik alapfeltétele, hogy a címkiosztás tükrözze a hálózati topológiát. A folyamatos újra címzésekkel ez meglehetősen kaotikus lenne, egyre újabb és újabb elkerülő útvonalak beszúrására lenne szükség a routing táblákban, tehát a dinamizmus árát a csomagok routolhatóságának csökkenése jelentené. Nem beszélve arról, hogy a módszer meglehetősen kényelmetlen, az Internetes közösségek ellenérzését váltaná ki. E kérdéssel jelenleg az IETF PIER (Procedures for Internet/Enterprise Renumbering) munkacsoportja foglalkozik.

68 But they cannot be relied on forever Source: http// ops/bgptable.html Projected routing table growth without CIDR/NAT Moore’s Law and NATs make routing work today Deployment Period of CIDR

69 Mobilitás Egyik hálózatból másikba mozogva változik az IPv4 cím.
A létező kapcsolatok megszakadnak handover esetén. Roaming esetén az új protokollra van szükség, hogy a HLR-ben az új IP címet és az egyéni azonosítót összerendelje. A WAP és GPRS felhasználók drasztikusan növelik a mobil Internet használatot. A korlátozott IPv4 címtér hamarosan kifogy.

70 Egyebek Otthoni hálózat (Home Networking) Szolgáltatások támogatása
Nagyon sok egyedi IP címet igényelnek eszköz szinten. Szolgáltatások támogatása Az új szolgáltatások nem tudják hasznosítani az IP fejléc fix mezőit. Nincs beépített IPv4 biztonsági algoritmus. A QoS-n sokat segítenének az IP szintű forgalmi folyam jelzők.


Letölteni ppt "IP és mobilitás támogatás"

Hasonló előadás


Google Hirdetések