3. Az IPv6 bemutatása

Az IPv6 bemutatása legegyszerűbben az IPv4-hez képesti újdonságokon és különbségeken keresztül mutatható be.

3.1. Címzési architektúra

Az IPv4-hez hasonlóan az IPv6-ban is hálózati interfészekhez rendelünk IP-címeket, nem gépekhez, csomópontokhoz. Egy interfésznek több IP címe is lehet. Ez IPv4-ben a routerek kivételével eléggé szokatlan eset volt, de IPv6-ban nem csak általános, de bizonyos funkciók alapvető feltétele.

Az IPv6-os címeket három fő típusba sorolhatjuk annak megfelelően, hogy milyen útválasztást alkalmazunk rájuk. A címeket ezen kívül különböző formátumuk alapján is csoportosíthatjuk. Ezen fő két szempontunk nem teljesen független egymástól. [RFC2373]

3.1.1. Címtípusok

Az IPv6-os címeket három csoportba gyűjthetjük annak alapján, hogy a hálózaton hogyan történik egy csomag továbbküldése:

• egyedi cím (unicast cím)
• bárki cím (anycast cím)
• csoport cím (multicast cím)

3.1.1.1. Unicast cím

Leginkább ez a típus hasonlít az IPv4-ben használatos címekre. Az ilyen címekre küldött csomagok arra az egyetlen interfészre fognak megérkezni, amelyhez ez a cím van hozzárendelve. Az unicast cím egyértelműen meghatároz egy interfészt (az adott területen belül: globálisan, linkre vagy site-ra korlátozottan), és egy hozzá tartozó hosztot.

3.1.1.2. Anycast cím

Anycast címeket interfész-csoportokhoz rendelhetünk. Ezeknek nem feltétlenül kell ugyanazon a gépen lenniük, sőt akár egymástól távol is lehetnek. A forgalmat, amit ilyen címre küldünk, legalább egy interfész meg fog kapni az ezzel a címmel rendelkező csoportból. Az útválasztáskor általában a legközelebbi interfészre irányítjuk ezeket a csomagokat.

Az anycast és az unicast címek formátuma teljesen megegyezik, szintaktikailag tehát nem, csak a hálózati konfiguráció alapján lehet meghatározni az anycast/unicast címeket.

3.1.1.3. Multicast cím

Multicast címeket is interfész-csoportokhoz rendelhetünk, hasonlóan az anycast címekhez, azonban itt a csoport minden tagja megkapja a küldött csomagokat. Az IPv4-es broadcast címek helyett IPv6-ban ilyen címeket használunk.

A multicast címek egyértelműen megkülönböztethetőek az uni- és anycast címektől a formátumuk alapján.

3.1.2. Formátumok

Az IPv4-es címeket osztályokba (A, B, ...) soroljuk attól függően, hogy a cím mekkora része van kihasználva. Az IPv4-es cím MSB bitjei azonosítják az osztályt. IPv6 esetén nincs ilyen alapú osztályozás (IPv4 esetén is főleg címhiány okozta kényszermegoldás volt ez).

IPv6 esetén a prefix határozza meg a különféle formátumokat. A prefix az MSB-nél kezdődik és típusonként eltérő hosszúságú lehet.

Ezen kívül vannak speciális címek. Például a meghatározatlan (::0), a loopback (::1), és az IPv4-es beágyazott (embedded) címek.

3.1.2.1. Unicast címormátumok

IPv6-ban sokféle unicast cím létezik: az NSAP és IPX kompatibilitási címek, az Aggregatable Global Unicast (aggregálható, globális, egyedi címek), a Link és Site Local címek.

Az IPv6-os cím legegyszerűbb formájában strukturálatlanul 128 bitből áll. Gyakorlati felhasználás szempontjából ez csak a legritkább esetekben hatékony. Általában (nem IPv4-es beágyazott cím esetén) az IPv6-os cím áll egy hálózati részből, és egy interfész-azonosító részből. A hálózati rész közvetlenül a prefix után következik és változó hosszúságú lehet (hasonlóan az IPv4-es CIDR formátumhoz). A hálózati rész, amit hálózati prefix-nek hívnak (nem összekeverendő a formátum prefix-el), strukturált lehet, hasonlóképp az Aggregatable Global Unicast címhez.

3.1.2.2. Interfész ID

Sok IPv6 unicast cím (köztük az Aggregatable Global Unicast és a Link/Site Local címek) 64 bites interfész ID-t használnak. Ez az ID EUI-64-es formátumú [EUI64]. Az interface ID-t valamilyen interfész azonosítóból generáljuk, mint például Ethernet esetén a 48 bites MAC címből. Amennyiben nincs ilyen, úgy más módon, például véletlengenerátorral vagy kézzel állíthatunk elő egyedi ID-ket.

3.1.2.3. Link-Local, Site-Local címek

Ez a címtípus azért került bele az IPv6-ba, hogy lokálisan egyszerűbben lehessen kommunikálni. Ezek a címek csak egy linken, illetve site-on belül egyediek, ezért nem használhatók globális kommunikációra. Ez azt jelenti, hogy nem is szabad kiengedni az ilyen címeket a routereken.

Ezek a címek automatikusan generálódnak és felkonfigurálódnak. Fő céljuk, hogy a hoszt külső beavatkozás nélkül a hálózathoz csatlakozás után kommunikálni tudjon. Ezek után már ezen az IP-címen tud minden egyéb konfigurációs lépést megtenni. Mivel ezeket már IP-szinten tudja megtenni, így médiafüggetlen tud lenni, sőt ki tudja használni az IPSec lehetőségeit már konfiguráció során.

Minden interfésznek rendelkeznie kell tehát egy link-local címmel. [RFC2373]

3.1.2.4. Aggregatable Global Unicast Cím

Az AGU (Aggregatable Global Unicast) címeket használjuk globális kommunikáció esetén IPv6-ban. Ez a cím is tartalmaz hálózati részt, ami 61 bites, illetve a 64 bites EUI-64 formátumú interfész ID-t. [RFC2374]. A hálózati prefix részt az aggregáció miatt négy további részre bonthatjuk:

Ez a struktúra lehetővé tesz szolgáltató szerinti és egyéb csatlakozásalapú aggregációt. Az egyes hálózati prefixek jelentése:

• TLA ID: (Top Level Aggregation ID): Ezeket a útvonalválasztási hierarchia legfelső szintjéhez rendelhetjük. Gerinchálózatok routereinek ismernie kell minden TLA ID-t, azaz mind a 8192 bejegyzést tárolniuk kell routing tábláikban. Az [RFC2450] alapján napjainkban a gerinchálózati routereknek közel 50000 bejegyzést tárolnak, ez tehát jelentős csökkenést jelent. A TLA ID-k kiosztásával jelenleg a IANA foglalkozik. Az ehhez szükséges feltételek rögzítettek az [RFC2450]-ben.
• res (reserved): 0 értékeknek kell lenniük, később esetleg felhasználhatják a TLA és/vagy az NLA mező növelésére.
• NLA ID: (Next Level Aggregation ID): TLA-k által meghatározott ID-k, amiket szabadon oszthatnak szét további megkülönböztetésre.
• SLA ID: (Site Level Aggregation ID): A Site-ok saját belátásuk szerint létrehozhatják hierarchiájukat, és ezen kívül subneteket is.

A hálózati topológia tükröződése a címzésben jelentősen leegyszerűsíti a útvonalválasztást, és további nagy előnye, a újraszámozás (renumbering) kifejezett támogatása. Amikor internet-szolgáltató váltás történik, csak a hierarhiában magasan elhelyezkedő (TLA, vagy NLA) azonosítókat kell módosítani, a Site szintű struktúra és címzés változatlan maradhat.

3.1.2.5. Visszafelé kompatibilásra fenntartott címek

Jelenleg beágyazott (embedded) IPv4-es címeket használunk, ezen kívül NSAP és IPX címeket is definiál a szabvány[RFC1888]. Kétféle formátum használatos jelenleg, az egyiket az [RFC1993] definiálja az IPv4 feletti automatikus IPv6 tunelezésre. Itt a végpont beágyazott IPv4 címmel rendelkezik, amit IPv4 kompatibilis IPv6 címnek hívunk. Ennek a formátuma látható alább:

A másik formátumot IPv6 mapped IPv4-nek hívjuk amelyet az áttérési mechanizmusokban alkalmazzák. Ennek a formátuma a következő:

NSAP és IPX címeket úgyszintén definiáltak IPv6 alatt, ezeknek a formátum prefixe 0000 001, illetve 0000 010. Az NSAP-pal az [RFC1888] foglalkozik, míg az IPX kompatibilitás még nincs kidolgozva.

3.1.2.6. Multicast címek

Az IPv4-el ellentétben IPv6 alatt a multicast címeknek saját formátumuk van, amely az alábbi:

A flag-bitek a multicast címek kiosztásának módját határozzák meg. A 0000 az állandóan meglévő (ezeket jólismert címeknek hívjuk), míg a 0001 a tetszőlegesen kiosztható címeket jelöli. A többi állapot fenntartott.

A scope bitek a cím érvényességi tartományát határozzák meg. Jelenleg az alábbi lehetőségeket határozzák meg:

A Group ID azonosítja a fenti bitek után a multicast csoportot.

Több jólismert IPv6-os multicast cím van, amelyek érvényesek scope-tól függetlenül, ezek az [RFC2375]-ben vannak definiálva. Például az FF02:0:0:0:0:0:0:1 jelöli egy linken belül az összes csomópontot megcímző multicast címet.

Az FF02:0:0:0:0:1:FF00::/104 prefixű multicast cím a preferált cím, amely megcímzi az összes csomópontot. A csomópontok unicast címének alsó 24 bitje hozzácsatolódik az előbb említett prefixhez, és így alkotják preferált csomóponti multicast címet. Az olyan több unicast címmel rendelkező gépek, amelyeknek a címei eltérő aggregációban vannak (eltérő prefixűek), ugyanahhoz a preferált csomóponti multicast címhez csatlakoznak, mert csak az alsó biteket használjuk az ilyen címek kialakításakor. Így a node-ot anélkül megcímezhetjük, hogy kiválasztanánk akár egy prefixét is. Minden csomópontnak csatlakoznia kell a preferált csomóponti multicast csoporthoz.

3.1.2.7. Anycast címek

Ezeket a címeket konfigurálás útján tudjuk előállítani egyszerű unicast címekből. Így ránézésre nem is lehet megállapítani egy ilyen címről, hogy anycast cím lenne-e. Az anycast címek felhasználása még mindig fejlesztés alatt áll. Globális felhasználásuk erősen korlátozott az ilyen címek útvonalválasztási korlátai miatt.

Az anycast címek egy lehetséges felhasználása, hogy egy domain határán levő routereket azonosítják.

Vannak előredefiniált anycast címek. Egy ilyen a subnet-routerek címe. Az erre a címre küldött csomagok az alháló egyik routerére fognak megérkezni. Egy másik jólismert anycast cím a Mobil IPv6-os honi ágensek (Home-Agentek) címe, amely egy hálózaton levő Home-Agenteket éri el. Ehhez egy speciális EUI-64-es interface ID használatos: fdff:ffff:ffff:fffe. Ez, és más egyéb jól-ismert anycast címek az [RFC2526]-ban vannak definiálva.

3.1.3. IPv6 címek írásmódjai

Az IPv6-os címeket hexadecimális számok csoportjaiként szoktuk leírni. Nyolc darab 16 bites (négyjegyű) csoportból áll, amelyeket kettőspont választ el egymástól. Például: 3ffe:2f00:0000:0000:0200:c0ff:fec6:068b.

Egy csoportban az elöl álló nullák elhagyhatók. Gyakran előfordul a címekben, hogy sok nulla van egymás mellett, amennyiben egymás melletti csoportokban csak és kizárólag nullák fordulnak elő, azok elhagyhatók, és helyettük egy kettőspont írható. Például: 3ffe:2f00::200:c0ff:fec6:68b.

Amennyiben szeretnénk jelölni, hogy a hálózati prefix hány bit hosszú, ezt a cím után tehetjük meg egy per ('/') jel után: 3ffe:2f00::200:c0ff:fec6:68b/64.

Ha csak a hálózati címet szeretnénk ábrázolni, akkor a fentihez hasonló módon tehetjük meg, az interface részt elhagyva belőle: 3ffe:2f00::/24.

A beágyazott IPv4-es címeket vegyes írásmódban használhatjuk, ahol az IPv4-es címet decimális formátumban, egymástól pontokkal választjuk el. Például: ::ffff:152.66.243.148.

Az 3.2. IPv6 fejléc szerkezete

Az IPv6 fejléc egyszerűbb lett, mint az IPv4-es.Az alapesetben csak az útvonalválasztáshoz szükséges információkat tartalmazza, a megfelelő QoS paraméterekkel kiegészítve.A fejléc nagy részét a forrás és cél állomások 128 bites címei teszik ki.Az IPv6 alap fejlécben található mezők:

• Version (4 bit): Az internet protokoll verziója, értéke 6. A célja megegyezik az IPv4 csomag azonos nevű mezőjével.
• Traffic Class (8 bit): Szerepe a különböző forgalmi osztályok és rendek megkülönböztetése. Értékét a küldő és a továbbító állomások vizsgálják és állítják be. A hasonló célú IPv4-es mező (Type of Service) sorrendi és teljesítménybeli követelményekkel járt.
• Flow Label (20 bit): Ez a mező azon csomagok sorozatát azonosítja, melyek különlegesen kezelendők. A speciális kiszolgálás részleteit egyéb protokollok határozzák meg (pl:erőforrás lefoglaló protokoll). A folyamok címzése sajátos módon két összetevőből áll: a Forrás Címből és a nem 0 értékű Flow Label-ből. Utóbbi egy álvéletlen szám vagy valamilyen más eszköz (pl: RSVP), melyet a küldő állomás rendel a csomaghoz hatékony hash táblás keresést téve lehetővé a folyamok azonosítására. Ez jelentős változás a jelenleg használt leghosszabb illeszkedés kereséshez (Longest Match Search) képest, jobb szolgáltatásokat téve lehetővé.
• Length of Payload (16 bit): Az adatmező hossza bájtokban megadva, melybe - ha vannak - a kiegészítő fejlécek hossza is beleszámít.
• Next Header (8 bit): Szerepe azonos a hasonló nevű IPv4 mezőjével, a következő fejlécet azonosítja.
• Hop Limit (8 bit): Feladata az IPv4-es Time To Live mezőjéhez hasonlóan a csomagok élettartamának szabályozása (azzal ellentétben ennek valóban csak az egyes állomások közti áthaladásnál csökken az értéke, tehát nem idő jellegű mennyiség).
• Source Address (128 bit): A csomag forrásának címe.
• Destination Address (128 bit): A csomag címzettjének címe.

Az IPv4-hez képest bizonyos mezők kimaradtak a fejlécből és opcionális fejlécbe kerültek át. Így a fejlécek feldolgozása egyszerűsödött.

3.2.0.1. Tördelés (Fragmentation)

Csak a végpontokon levő állomások tördelhetik szét és állíthatják ismét össze a csomagokat, a közbeesők nem. Az útközbeni tördelés komoly erőforrás igényeket támaszt a routerekkel szemben, ez a módszer azonban kiküszöböli ezt a problémát. A forrás állomás meghatározza a maximálisan átvihető méretű egységet (MTU), és ha kell tördelést végez. Ekkor az összeillesztéshez szükséges információkat a Fragmentation Header nevű kiegészítő fejlécben tárolja el, mely csak ebben az esetben van jelen a csomagban.

3.2.0.2. Opciók (Options)

Mivel az IPv6 erre külön fejlécet hozott létre (Option Extension Header) értelemszerűen nem kapott helyet az alap fejlécben.

3.2.0.3. Fejléc ellenörző összeg (Header Checksum)

Ennek kihagyása több szempontból is indokolt volt. Egyrészt a checksum számolás jelentős többletidőt igényel és csak kis haszonnal jár. Másfelől a magasabb szintű protokollok amúgy is végeznek hasonló célú ellenőrzéseket, ráadásul a modern hálózati technológiák viszonylag alacsony hibaaránnyal rendelkeznek. Ha mégis szükséges a csomagok integritásának ellenőrzése ezen a szinten, akkor az IPSec Authentication Header vagy az Encapsulating Security Payload mechanizmus használható.

3.3. Kiegészítő Fejrészek (Extension Header-ek)

Bizonyos opcionális információk nem az alap, hanem valamely kiegészítő fejlécben kapnak helyet, melyek az IPv6 és a felsőbb protokollok fejlécei között találhatók. Rendszerint csak a célállomás dolgozza fel a bennük levő információkat, de vannak amelyek útközbeni (hop-by-hop) feldolgozást igényelnek. Ezek közvetlenül az IPv6 fejléc után következnek, míg az előbbiek csak utánuk. Ez lehetővé teszi, hogy a routereknek csak a csomag elejét kelljen átnézniük, egyszerűbb feldolgozást téve lehetővé különösen az IPv4-hez képest, ahol a fejléc hossza a különböző opcióktól függően változott.

Az IPv6 kiegészítő fejlécei (extension headerei) sorrendben:

• Hop-by-hop Options Header:
• Destination Options Header: Ez a két fejléc az útközbeni (hop-by-hop) feldolgozást igénylő kiegészítő információkat tartalmazza (a formátumát lásd [RFC2460]). Számos itt használatos opció már ki van dolgozva (például 64 kB-nál nagyobb csomagok továbbítására a Jumbogram [RFC2675], vagy az IPv6 Router Alert Option [OPTAL]). Egyes Destination Options fejléceket minden a Routing Header-ben előforduló állomás felhasznál, másokat csak a célállomás. Az utóbbi esetben a Destination Options a fejléc lista végére is kerülhet. A Hop-by-hop Options Header mindig közvetlenül az IPv6 fejléc mögé kerül.
• Routing Header: Funkciója az IPv4 Source Route-jához és Record Route-jához hasonló.
• Fragment Header: A tördelés kezelésére szolgál. Ha a forrás állomás tördelést alkalmaz, akkor a tördelt csomagokat és a sorrendjüket ez a fejléc mutatja.
• Authentication Header:
• Encapsulating Security Payload Header: Ez a két fejléc az IPSec megvalósításáért felel.

3.4. A Környezet Felmérő protokoll (Neighbor Discovery)

A környezet felmérő protokoll a hálózatban elhelyezkedő entitások (csomóponti gépek és útvonalválasztók) feltérképezésére szolgál. Információt szolgáltat az útvonalválasztóknak, munkaállomásoknak a környezetükben található gépek elérhetőségéről, címéről stb.

A protokoll konkrétan a következő problémákat igyekszik megoldani:

• Útvonalválasztó (router) felderítése: eljárás a csomóponti gépek számára, hogy hogyan deríthetik fel a hálózathoz kapcsolódó útvonalválasztókat.
• Cím előtagjának (prefix) felderítés: eljárás a csomóponti gépek számára, a cím előtag beállítására. (A csomópontok előtagokkal –prefix- különböztetik meg az egy hálózatba tartózó gépeket az útvonalválasztón túl elhelyezkedő gépektől.)
• Paraméter felderítés: a csomóponti gépek honnan szerezhetnek tudomást az egyes paraméterekről úgymint a kapcsolatparaméterekről (pl. a maximálisan elküldhető csomagméret), vagy az Internet paramétereiről (pl. maximálisan hány pontot érinthet útja során a csomag – hop limit)
• Automatikus címkonfigurálás: a csomóponti gépek hogyan végezhetik el az egyes kapcsolódási pontok címének automatikus konfigurálását.
• Cím feloldás: a csomóponti gépek hogyan határozhatják meg az IP cím ismeretében a fizikai címet.
• Következő ugrás (next hop) meghatározása: ez az algoritmus, amely leképezi a cél IP címét annak a csomóponti gépnek a címére, ahova a csomagot továbbítani kell. Ez lehet maga a célpont vagy egy útvonalválasztó (router).
• Elérhetetlen szomszéd érzékelés (Neighbor Unreachability Detection): módszer arra, hogy a csomóponti gépek hogyan érzékelhetik, ha valamelyik, velük egy hálózaton levő gép elérhetetlenné válik.
• Cím ismétlődés érzékelése: a csomóponti gépek hogyan érzékelhetik, hogy az általuk használni kívánt címet használja-e valaki más entitás.
• Átirányítás: egy útvonalválasztó hogyan tudja értesíteni a csomóponti gépet arról, hogy létezik az általa használtnál jobb (gazdaságosabb) csomagküldési útvonal is.

A környezet felmérő (Neighbor Discovery: ND) protokoll ICMP (Internet Control Message Protocol: ICMPv6) csomagokat felhasználva oldja meg a fent említett feladatokat. Az IPv6 természetesen tartalmazza az összes IPv4-ben megszokott ICMP üzeneteket, mint például a visszhang kérést (echo request) és visszhang választ (echo reply) stb. A környezet felmérés céljaira öt féle ICMPv6 csomagot definiáltak. Ezek a következők: útvonalválasztó kérelmezés és hirdetés (Router Solicitation, Router Advertisements), szomszéd kérelmezés és hirdetés (Neighbor Solicitation, Neighbor Advertisements) továbbá átirányítás (redirect) üzeneteket.

Ezek az üzenetváltások következők és a következő funkciókat látják el:

• Útvonalválasztó kérelmezés (router solicitation): Csomóponti számítógép üzenete, amelyre az útvonalválasztó hirdetési üzenettel köteles válaszolni. A csomag forráscíme a küldő címe (vagy nem specifikált cím), a célcím pedig útvonalválasztó csoportcím. Az ICMPv6 csomag típusa 133 (kód: 0).
• Útvonalválasztó hirdetés (router advertisement): Az útvonalválasztók ezzel az üzenettel hirdetik magukat időnként megismételve ezt az üzenetet, vagy ezzel válaszolnak az útvonalválasztó kérelmezés üzenetére. Az üzenet forráscíme a küldő címe, a célcím lehet csoportcím, vagy (útvonalválasztó kérelmezési procedúra esetén) egy adott cím (a kérelmező címe). Az üzenet ICMPv6 (típusa: 133, kód: 0 ) csomagja tartalmazza a következőket:
• Továbbítási korlát (hop-limit) értéket (nulla érték azt jelenti, hogy az útvonalválasztó nem specifikálta ezt).
• M-jelzőbit (Managed Address Configuration). M=1 esetén a csomóponti gép DHCPv6 (Dynamic Host Configuration Protocol) protokollt használ címek konfigurációjakor.
• O-jelzőbit (Other Stateful Configuration).
• Időzítők állapota (elérhetőség, válaszidők).
• Opciók: címelőtag (prefix) információk, MTU információk.
• Szomszéd kérelmezés (neighbor solicitation): A csomópont gép ezzel az üzenettel tudja megkapni valamely szomszédja (csatoló egységének, pl. Ethernet) címét, avagy megállapítani hogy az általa eltárolt címen elérhető-e még a csomópont. Ugyancsak ez az üzenet használatos a már használt címek többszöri felhasználásának elkerülésére. Az üzenet ICMPv6 (típusa: 135, kódja: 0) a célállomás fizikai címét, illetve a kérdező állomás fizikai címét (opcionálisan).
• Szomszéd hirdetés (neighbor advertisement): A csomópont válasza a fenti szomszéd kérelmezés üzenetre, de lehet egy csomópont nem kérelmezett hirdetési üzenetet is abban az esetben ha megváltozott fizikai címét akarja közölni. Az üzenet fejléce tartalmazza a küldő címét (forráscím), vagy egy célcímet, ha válasz egy kérelmezési üzenetre. Az üzenet ICMPv6 üzenetrésze (típus: 136, kód: 0) tartalmazza a küldő típusát is. Az R-jelzőbitet beállítja, ha a küldő útvonalválasztó. Hasonlóan az S-jelzőbitet beállítja, ha ez a küldemény egy válasz volt egy szomszéd kérelmezési üzenetre. Az üzenet tartalmazza a megszólított csomópont címét, illetve csomópont címét, ha a csomópont azért hirdette meg a címét mert megváltozott. (Ez a megoldás nagyon hasonló az IPv4-ben alkalmazott ARP (Address Resolution Protocol) protokollhoz, de mivel itt a szomszéd felderítése a protokoll része, ezért a környezet felmérés működhet olyan környezetben is ahol nincsen lehetőség üzenetszórásra (broadcast) pl. ATM, Frame Relay, Non-Broadcasting Multiple Access médiák esetén)
• Átirányítás: Ez az üzenet átirányítók információs üzenete, amelyekben a csomóponti gépeket más (optimálisabb) útvonal megválasztásáról informálják. Üzenet forráscíme, amelyik csomópontról az átirányítandó üzenet érkezett, a célcím pedig az a állomás, amelyik az átirányítási üzenetet kiváltotta. Az ICMPv6 üzenet (típus: 137, kód: 0) tartalmazza az átirányítási IPv6-os címet.

Azokon a hálózatokon ahol lehetőség van multicast (csoportos című) üzenetek küldésére, minden átirányító meghatározott időközönként küld egy útvonalválasztó hirdetés (csoport című) csomagot ezzel jelezve létét a hálózaton. A csomóponti gépek ezeknek az üzeneteknek a segítségével egy listát készíthetnek a létező átirányítókról. A periódikusan kiküldött üzenetek megfelelőek arra, hogy néhány perc alatt az összes csomóponti gép tudomást szerezzen az átirányítók létezéséről, viszont ahhoz nem elég gyakoriak, hogy az esetleges átirányítók kieséséről időben értesüljön mindenki.

Az útvonalválasztó hirdetés üzenet tartalmaz még előtagokat (prefix) is. Ezeket a csomóponti gépek az automatikus címkonfigurációnál, illetve az alhálózat meghatározásnál használhatják. A csomóponti gépek, a hirdetett előtagokból egy listát készítenek, amely segítségével meg tudják határozni egy csomagról, hogy az egy alhálózatból érkezett, hogy egy útirányítóról kívülről érkezett. Természetesen küldhetnek a csomóponti gépek előtagokkal nem rendelkező üzeneteket is alhálózaton belülre, ebben az esetben a router küld egy átirányítás (redirect) üzenetet a csomóponti gépnek.

Az útvonalválasztó hirdetés (router advertisement) üzenet lehetőséget nyújt a útvonalválasztóknak, hogy információt közöljön a csomóponti gépeknek segítve a cím-autókonfigurációt. A router meg tudja határozni, hogy a csomópontok állandó címeket, illetve automatikus címkiosztást (DHCP) használjanak.

Az üzenetek tartalmaznak még Internet paramétereket, úgy mint továbbítási korlát (hop limit: a csomag hány csomópontot érinthet maximálisan), avagy a kapcsolatra jellemző paramétereket, mint például a továbbküldhető maximális csomag méretét (MTU). Az üzenetek segítségével ezeket a fontos paramétereket elegendő csak a routerekben beállítani s a továbbiakban az egész hálózat értesül a beállításokról.

Az egyes csomópontok a cím feloldása a szomszéd kérelmezés (Neighbor Solicitation) üzenettel oldható meg. A csomóponti számítógép küld egy csoport-címzéssel szomszéd kérelmezés üzenetet a preferált csomóponti multicast címre megjelölve a célállomás címét, amelyre egy egyszerű egycímű szomszéd hirdetés üzenettel válaszol a megcímzett.

A címek többszöri felhasználásának detektálására is a szomszéd kérelmezés üzenetet használják.

3.5. Automatikus konfiguráció

Az automatikus konfiguráció célja a csomóponti eszközök egyszerű és gyors felcsatlakoztatása a hálózatra. Lehetővé tenni, hogy a hálózatra kapcsolt berendezés (számítógép) beavatkozás nélkül megkaphassa a főbb hálózati paramétereket: hálózati cím (link local address), valamint egyéb konfigurációs paramétereket. Három módszer van erre kidolgozva: “stateless” vagy állapotmentes, “stateful” módszerek és ezek kombinációja. Ezek a módszerek csak csomóponti számítógépekre érvényesek. A routerek automatikus konfigurációja más módszerrel történik.

A stateful automatikus konfigurációs módszer esetén a felcsatlakozott csomóponti számítógép az összes szükséges adatot (cím, konfigurációs információk, paraméterek stb.) egy kiszolgálótól (annak adatbázisából) kapja meg. Az adatok szigorú ellenőrzés alatt vannak, s a vezérlést például a DHCPv6 protokoll végezheti.

A stateless automatikus konfiguráció esetén nem szükséges a fenti feltétel. A felcsatlakozott számítógép a felcsatlakozásához szükséges adatokat a hálózatból nyeri ki (a már ismertetett hirdetési üzenetek segítségével). Az IPv6 címek csak egy meghatározott ideig érvényesek, azt követően más csomópontnak lesznek kiosztva.

A cím egy speciális címelőtagból (link-local address prefix: 10 bit) és egy a hálózati modult meghatározó címből (64 bit) lesz összekombinálva. Ezt követően a csomópont ellenőrzi (Neighbor Solicitation), hogy az így kialakított cím egyedüli-e a hálózaton. Amennyiben nem, akkor kézi beavatkozásra lehet szükség. Ha egyedüli a cím, akkor lehetséges felderíteni (Router Solicitation üzenet), hogy a hálózaton vannak-e routerek, ha nincs, akkor DHCPv6 protokoll igénybevételével a stateful automatikus konfigurációt lehet választani. A router hirdetési üzenetében (annak opcionális részében) minden további információ megtalálható: fizikai (Ethernet) cím, a maximálisan átvihető üzenethossz (MTU), és az adott hálózatra vonatkozó címelőtag (address prefix).

3.6. DHCPv6 protokoll (Dynamic Host Configuration Protocol)

Az előzőekből látható, hogy ha a hálózaton címütközés van, vagy nincs router, akkor a DHCP protokoll használatára lehet szükség. Azonban a IPv6 képes működni akkor is, ha nincsen router a hálózatban ilyenkor a link-local címekkel kommunikálhatnak a csomópontok. Címütközés esetén pedig lehetséges adminisztratív beavatkozás vagy DHCPv6 használata. Ez egy kliens és kiszolgáló programrészből álló protokoll, amely képes a címet és a hálózati paramétereket a felcsatlakozott számítógépnek megadni.

A DHCP üzenetek szerkezete azonos: üzenet típusa, információ leíró és maga az információ, amely tartalmazhat: az IP címet, időzónára vonatkozó információkat, névszerverre vonatkozó információt, hitelesítési, és más szerverekre vonatkozó információkat. [DHCPv6][DHCPv6_EXT]

3.7. DNS támogatás az IPv6-ban

Az IPv6 nagyobb cím mezejéhez természetesen a DNS-ben[RFC1034][RFC1035] is változtatásokat kellett végrehajtani [RFC1886]. A változtatás viszonylag kis mérvű volt, ami ezt jelenti, hogy az eddigi A rekordok mellett megjelentek az AAAA rekordok is, ami a nevekhez IPv6-os címek hozzárendelését teszi lehetővé. Az IPv6 címhez név rendelést a PTR rekordok látják el továbbra is, azzal a módosítással, hogy míg az IPv4 esetében ezek a viszont irányú bejegyzések az in-addr.arpa. domain alá kerülnek bejegyzésre addig itt az IPv6-nál az IP6.INT domain alá. Azonban az IPv6 egyszerű átszámozhatósága [RFC1887] és a multihome-ing [MULTIHOMED_INGRES] miatt szükség volt egy hierarchikusan jól karbantartható módosítására is a DNS-nek [RFC2874]. Ez a szabvány tovább bőviti a rekordokat olyan módon, hogy az AAAA rekordok mellett az A6 rekordok is alkalmasak hostnévből IPv6 cím leképzésre. Bevezetésre került a bitlabel típusú PTR rekord, ami azt teszi lehetővé, hogy tetszőleges inverz zónát lehessen delegálni és a DNAME rekord, ami egy tetszőleges DNS részfa, illetve zóna szimbólikus cimkézésre használható.

3.8. Mobilitás

A mobilitás célja annak a problémának a megoldása, hogy egy IPv6 eszköznek a globális címe - mellyel egyértelműen azonosítható az Interneten - tartalmaz hálózati részt, és ezért, ha az eszköz mobillá kíván válni, biztosítani kell, hogy a hálózat akkor is hozzá továbbítsa erre a címre érkező csomagokat, ha éppen más hálózatban tartózkodik. [MOBIL6]

3.8.1. Mobil működés

Minden mobilitásra képes IPv6 eszköznek van egy honos hálózata (home network). Az eszköz "otthon van", ha ehhez a hálózathoz csatlakozik, ekkor globális címével közvetlenül elérhető, működése nem különbözik a nem mobil IPv6 eszközökétől.

Mobillá válás esetén az eszköz lecsatlakozik honos hálózatáról és rácsatlakozik egy idegen hálózatra (foreign network). Globális címével továbbra is elérhető, ugyanis a mobil eszköz honi ágens (home agent) az idegen hálózatra továbbítja az ide érkező forgalmat. Ezt az által teheti meg, hogy a mobil csomópont az idegen hálózaton - rendszerint a szabványos IPv6 autokonfigurációs mechanizmusok segítségével - egy ideiglenes címet (care-of address) kap, amelyről értesíti ágensét, aki ide fogja irányítani a forgalmat.

3-1 ábra: Az mobil IPv6 architektúra

3.8.2. Részletes működés

A honos hálózaton tartózkodó eszköz működése megegyezik a normál (mobilitást nem alkalmazó) csomópontok működésével. Címét és egyéb hálózati paramétereit az IPv6 szabványos autokonfigurációs szolgáltatások segítségével állítja be. A globális címére érkező csomagokat hagyományos módon fogadja és a tőle kiinduló csomagoknak ez a cím lesz a forráscíme.

A mobilitás során az eszköz elhagyja a honos hálózatot és csatlakozik egy másik hálózatra. Az idegen hálózaton, ugyancsak a megfelelő autokonfigurációs mechanizmusok segítségével felvesz egy újabb, az idegen hálózat tartományába eső címet. Amint az ideiglenes cím érvényes, a mobil eszköz kötődési frissítés felhívást (Binding Update) küld honi ágensének. Saját honi ágensét a mobil állomás rendszerint ismeri, de bizonyos esetekben elképzelhető, hogy az eszköz áttelepülése során megváltozik az ágens. Ilyenkor a dinamikus honi ágens felderítés (Dynamic Home Agent Discovery) mechanizmusával a mobil eszköz először megkeresi az új ágenst azáltal, hogy a kötődési frissítést a honi ágensek anycast címére küldi a honos hálózaton.

A mobil csomópont ideiglenes címét, mint elsődleges távoli címet (Primary Care-of Address) a honi ágens regisztrálja, és erről kötődési visszaigazolást (Binding Acknowledgement) küld. Mind a változási felhívás, mind a visszaigazolás IPSec autentikációs eszközökkel hitelesített az illegális forgalomeltérítés megakadályozása érdekében.

Az új cím regisztrálása után az ágens proxy Neighbor Discovery segítségével a mobil eszköz honi címére érkező csomagokat átveszi és az elsődleges távoli címre továbbítja IPv6 beágyazás (encapsulation) segítségével.

Amennyiben a mobil eszköz egyik idegen hálózatból áttér egy másik idegen hálózatba, akkor is kötődési frissítés felhívást küld saját honi ágensének, továbbá hasonló felhívást intézhet az elhagyott hálózat routerjeihez, hogy azok ideiglenes honi ágensként továbbítsák számára a régi hálózatba érkező csomagokat. Ez utóbbi esetben a mobil eszköznek több ideiglenes címe lehet, amelyek közül mindig az az elsődleges, amely címhez tartozó hálózatban éppen tartózkodik.

A honos hálózatba visszatérő mobil állomás megfelelő kötődési frissítés küldésével tudatja a honos ágensét a visszatérésről.

Az IPv6 mobilitás nemcsak a mobil eszközök esetén jelent változást a normál működési módhoz képest, hanem mindazon csomópontoknál is, amelyek mobil állomással kommunikálnak. Ha egy másik csomópont (mobil vagy nem mobil) egy mobil állomással kommunikál, akkor kezdetben a mobil eszköz honos címére küldi a csomagokat. A fent leírt mechanizmusok segítségével ezek a csomagok eljutnak a mobil csomópontra, amely észleli, hogy a forgalom közvetve érkezik hozzá. Ekkor egy kötődési frissítési felhívást küld a forrásnak, aki eltárolja az ideiglenes címet és az eredeti honos címet. További kommunikációban, ha olyan címre irányul egy csomag, amely címhez létezik eltárolt ideiglenes cím, akkor az eszköz közvetlenül, a honi ágens nélkül fog kommunikálni a mobil csomóponttal. A mobil egységgel kommunikáló állomások bármikor kérhetnek kötődési frissítést a mobil eszköztől kötődési kérés (Bindig Request) formájában.

3-2 ábra: Mobil IPv6 jellemző szekvenciái

3.8.3. A "Home Address" opció

Mivel a mobil IPv6 eszközök minden körülmények között elérhetőek honos címükkel, ezért ennek a címnek kell szerepelnie minden, az adott eszköztől induló csomag forráscímében. Ez problémát jelent minden olyan hálózatnál, ahonnan nem engednek ki olyan csomagot, amely forráscíme nem a hálózat címtartományából van (ingress filtering). A megoldást egy új opcionális fejléc, a "Home Address" opció adja. Ezt az opciót minden IPv6 implementációnak ismernie kell. A mobil eszköz küldéskor az ideiglenes címet helyezi el az IPv6 csomag fejlécében forráscímnek, és a Home Address fejlécben jelzi honos címét. A célállomás a csomag vétele során felismeri a honos címet, és a vett csomagban behelyettesíti a forráscím helyére.

3.8.4. Különbségek az IPv4-hez képest

Az IPv4 mobilitás [RFC2002] utólag lett kifejlesztve, szemben az IPv6 integrált megoldásával. Ennek megfelelően több jelentős különbség fedezhető fel a két megoldás között.

• Az IPv6 mobilitás túlnyomó részben olyan alap IPv6 mechanizmusokra épül, mint például az autokonfiguráció, vagy a Neighbor Discovery. Mivel ezek minden implementációban rendelkezésre állnak, a mobil üzemet fogadni képes környezet kialakítása nem kíván speciális megoldásokat.
• A honos ágens nélküli direkt kommunikáció az IPv4 megoldásban csak opcionális, az IPv6 mobilitás kötelezően tartalmazza.
• A Home Address opció lehetővé teszi ingress filteringet alkalmazó hálózatok használatát. Egyben, mivel az ideiglenes cím a forrás, a mobil eszköz multicast csomagokat is tud küldeni.
• Az IPSec alkalmazása nem igényli más biztonsági megoldások bevezetését a mobilitás tekintetében.
• A Proxy Neighbor Discovery használata függetlenné teszi a mobilitást az alkalmazott hálózati technológiától. Az IPv4 Proxy ARP nem független ebben a tekintetben.
• Az IPv6 mobilitás vezérlő információi opcionális fejlécként vannak megvalósítva, így akár más IPv6 csomagokra is ráültethetőek. Ezzel szemben az IPv4 mobilitás UDP-t használ erre a célra.
• A dinamikus honos ágens felfedezés hatékonyabb az IPv4 directed broadcastjánál.
• A mozgás során kétirányú megerősítések vannak. Ez előnyös olyan környezetben, ahol a forgalom két irányának különböző jellemzői vannak (például vezeték nélküli rendszerek)
• A legtöbb esetben az átirányított forgalom egyszerű Routing Header megoldással küldhető tovább, ellentétben az IPv4-gyel, ahol minden esetben beágyazás (encapsulation) történik. Így az IPv6 mobilitás képes helyesen kezelni az ICMPv6 üzeneteket.

3.8.5. Az IPv6 mobilitás által nem megoldott problémák

Bár az IPv6 által alkalmazott mobilitási megoldások igen átfogóak és hatékonyan kialakítottak, két lényeges kérdésre nem adnak választ:

Részleges elérhetőséggel rendelkező hálózati közegek. Olyan rendszerek, mint például a vezetéknélküli eszközök nem biztosítanak folyamatos hálózati jelenlétet. Előfordulhatnak olyan esetek, amikor az eszköz bizonyos időre nem csatlakozik egyik hálózathoz sem. Ezt a helyzetet és az ebből kifolyólag felmerülő más problémákat az IPv6 mobilitás egyelőre nem kezeli le.

Az IPv6 mobilitás megoldja a mobil eszköz mozgásával összefüggő hitelesitési (authentication) és partner-azonosítási (authorisation) kérdéseket a honos hálózat szempontjából, de nem foglalkozik az idegen hálózatokon alkalmazandó hozzáférési korlátozásokkal. Ezek egy részét más IPv6 funkciók, mint pl. az autokonfiguráció megoldják.

3.9. Biztonság

Az IP protokoll szintjén biztonsági szolgáltatásokról az IPSec programrendszer gondoskodik. Az IPSec értelmezett IPv4 és IPv6 esetén egyaránt: az alapvető különbség, hogy míg IPv4 esetén az IPSec csupán opcionális, addig IPv6 esetén az implementáció számára egy kötelezően megvalósítandó szolgáltatás.

3.9.1. IPSec

Az IPSec [Stallings] három fő biztonsági szolgáltatást tud nyújtani: csak hitelesítési (authentication) (AH fejléc), egy kombinált hitelesítés (authentication) és titkosítás (ESP csomagok) és a mindkettőt kiszolgáló kulcskezelés. Az IPSec egy meglehetősen bonyolult protokoll-együttes, amelyet több, alapvetően hét csoportba sorolható RFC ír le:

• Az IPSec felépítése [RFC2411][RFC2401]
• Az AH protokoll [RFC2402]
• Az ESP protokoll [RFC2406]
• Titkosító algoritmusok [pl. RFC2405]
• Hitelesítési (Authentication) algoritmusok [pl. RFC2085]
• Interpretációs dokumentumok [RFC2407]
• Kulcskezelés [RFC2408][RFC2409]

Az IPSec egyik kulcs-fogalma a Security Association (SA - Biztonságos Kapcsolat). Az SA egy egyirányú kapcsolat a kommunikáló partnerek között. Kétirányú biztonságos kapcsolatokhoz két SA szükséges. Egy SA vagy egy AH, vagy egy ESP által megvalósított egyirányú biztonságos kapcsolatot ír le. Ha egy kapcsolatban egyik irányban AH-t és ESP-t egyaránt akarnak használni, akkor mindegyikhez egy-egy SA szükséges. Egy SA-t három paraméter azonosít egyértelműen:

• Security Parameter Index (SPI) - Biztonsági Paraméter Index: az SPI mind az AH, mind az ESP fejlécekben továbbítódik a fogadó fél felé. Az SPI-nek lokális jelentése van az általa meghatározott SA létrehozója (általában az SPI-t hordozó csomag címzettje) számára.
• Az IP célcím: az IPSec és az SA jelenleg csak unicast címekre van értelmezve.
• A használt biztonsági protokoll azonosítója, amely az AH vagy az ESP azonosítójának felel meg.

Az SA adatbázisban az SA-k és a hozzájuk tartozó, az adott SA működését leíró paraméterek találhatók:

• Sorozatszámláló: az AH vagy ESP fejlécek sorszámának generálásához szükséges számláló.
• Sorozatszám-túlcsordulás jelző: kapcsoló, amely azt jelzi, hogy vajon a sorszámláló túlcsordulása egy jelzendő esemény-e és ezen SA-beli csomagok további küldésének a letiltását jelenti-e.
• Anti-replay ablak: a bejövő AH vagy ESP csomagok sorozatszámának ellenőrzésére való ablak. Az újraküldéses támadások kivédésére szolgál.
• AH információk: az alkalmazott hitelesítési (authentication) algoritmus, kulcsok, a kulcsok élettartama és más az AH használatához szükséges paraméterek.
• ESP információk: az alkalmazott titkosító és hitelesítési (authentication) algoritmusok, kulcsok, titkosító kezdőértékek, kulcs-élettartamok és más az ESP használatához szükséges paraméterek.
• Ezen SA élettartama: egy idő intervallum vagy bájtszámláló, amelynek elérése után ezt az SA-t egy új SA-val (és SPI-vel) kell helyettesíteni, vagy a kapcsolatot meg kell szakítani, továbbá egy kapcsoló, hogy a kettő közül melyik történjék meg.
• IPSec protokoll mód: tunnel, transzport vagy tetszőleges mód.
• Path MTU - az úton átvihető maximális csomag mérete: csomag-tördelés nélkül a címzett felé vezető útvonalon átvihető maximális csomagméret és azzal kapcsolatos paraméterek.

A kulcskezelő eljárásokat csak az SPI köti össze az autentikációs és titkosító eljárásokkal, így az hitelesítés (authentication) és a titkosítás teljesen független bármilyen kulcskezelő mechanizmustól.

Az IPSec-nél nagyon rugalmasan határozhatjuk meg, hogy mely forgalomra milyen minőségű IPSec szolgáltatást szeretnénk használni. Ennek leírására a Security Policy Database (SPD - Biztonságpolitikai Adatbázis) szolgál. A legegyszerűbb formájában az IP forgalom azon részhalmazait határozza meg, amelyek egy-egy SA-hoz tartoznak. Bonyolultabb esetben több olyan részhalmaz is lehet, amely egy SA-ra mutat, vagy egy-egy részhalmaz, amely több SA-t igényel. A következő elemek határozzák meg az SPD bejegyzéseket:

• Cél IP címe: lehet egy IP cím, címek listája vagy tartománya, vagy maszkolt (wildcard) cím. Az utóbbi esetekben több címzett osztozhat ugyanazon az SA-n.
• Forrás IP cím: lehet egy IP cím, címek listája vagy tartománya, vagy maszkolt (wildcard) cím. Az utóbbi esetekben több küldő osztozhat ugyanazon az SA-n.
• Felhasználói azonosító: egy érvényes felhasználói azonosító vagy rendszernév (DNS hostnév).
• Az adat érzékenységi szintje: például “titkos”, vagy “nem minősített”.
• Szállítási szintű protokoll: az IPv4 fejléc protokoll vagy az IPv6 fejléc következő fejléc mezőjének az értéke. Lehet egy protokoll, protokollok listája vagy tartománya.
• Az IPSec protokoll: AH vagy ESP vagy AH/ESP.
• Forrás és cél portok: TCP vagy UDP port, portok listája vagy wildcard port.
• IPv6 osztály: adott IPv6 osztály vagy wildcard.
• IPv6 flow label: adott IPv6 flow label vagy wildcard.
• IPv4 szolgáltatás-típus (Type of Service, TOS): lehet adott TOS érték, vagy wildcard.

A kimenő csomagoknak az SPD bejegyzések alapján való feldolgozása a következő módon történik:

• A csomag megfelelő mezőinek az értékeit sorban összevetjük az SPD bejegyzések értékeivel. Ha valamelyik SPD bejegyzéssel egyezést találtunk, akkor megnézzük az ahhoz tartozó értéket:
• a forgalom nem engedélyezett - a csomagot el kell dobni.
• a forgalom IPSec nélkül engedélyezett - a csomag további feldolgozás nélkül a hálózatra kerülhet.
• a forgalom az IPSec alá tartozik - megkapjuk azt az egy vagy több SA értéket, amelyek alapján a hálózatra való küldés előtt az IPSec feldolgozás megtörténik.

3.9.1.1. Az AH protokoll

A hitelesítési fejléc (Authentication Header, AH) az egyes IP csomagok hitelesítése, a bennük lévő adat sértetlenségének az ellenőrzésére és ún. replay támadások elleni védelemre nyújt módot. A hitelesítés lehetővé teszi, hogy a csomag címzettje megbizonyosodjon az IP csomag feladójáról, ezzel téve lehetetlenné például a napjainkban oly könnyen megvalósítható IP-cím hamisítást. Az adatsértetlenség ellenőrzésével a címzett igazolhatja, hogy a csomagot annak feladása óta egy közbülső ponton nem módosították. A replay támadásoknál egy támadó az általa elfogott hitelesített csomag későbbi újraküldésével próbálja a rendszerek működését megzavarni - az AH-ban levő sorozatszám ez ellen nyújt bizonyos fokú védelmet.

Az AH fejlécet közvetlenül megelőző protokoll fejléc protokoll (IPv4) vagy következő fejléc (IPv6, IPv6 kiterjesztéses fejléc) mezőjében az AH fejléc azonosítójaként az 51-es szerepel.

Az hitelesítési fejléc (authentication header) a következő részekből áll:

3-3 ábra: IPSec AH-Authentication header/ Hitelesítési fejléc

• Next Header - következő fejléc (8 bit): ez a mező adja meg az AH header-t közvetlenül követő fejléc típusát.
• Payload Length - hasznos adathossz (8 bit): a mező értéke az hitelesítési (authentication) fejléc teljes hossza 32-bites egységekben mérve, mínusz kettő. Példaként nézzük a fönti ábrát: az hitelesítési (authentication) adat default hossza 96 bit, azaz 3× 32-bites szó. A három szó hosszúságú fix fejléccel számolva a teljes fejlécméret 6, így a Payload Length mező értéke 4 lesz.
• Reserved - fenntartott (16 bit): ez a mező későbbi használatra fenntartott.
• Security Parameter Index - biztonsági paraméter-index (32 bit): tetszőleges 32 bites szám. Az SPI a címzett IP címével és a biztonsági protokoll azonosítójával (AH esetén 51) egyértelműen azonosítja az IP csomaghoz tartozó SA-t.
• Sequence Number - sorszám (32 bit): a mező egy monoton növekvő számláló értékét tartalmazza.
• Authentication Data - hitelesítési (authentication) adat (változó méret): az ezzel a fejléccel védett csomagra vonatkozó hitelesítési (authentication) adat, amelyre még szoktak hivatkozni az Integrity Check Value (ICV) és Message Authentication Code (MAC) kifejezésekkel is.

Az SA tárolja annak az alkalmazott hitelesítési (authentication) algoritmusnak a típusát, amellyel a MAC kiszámítása történtik és amely lehet szimmetrikus titkosító algoritmus (pl DES) vagy egyirányú hash függvény (MD5 vagy SHA-1). A MAC kiszámítása során az IP csomag következő részeit veszik figyelembe:

• Az IP fejléc azon mezői, amelyek vagy nem változnak meg az út során, vagy amelyeknek a célpontbeli értéke a feladó számáta kiszámítható. A megváltozó és nem kiszámítható mezők tartalmát a MAC kiszámításához a feladó és a címzett oldalon egyaránt zérusokkal helyettesítik.
• Az egész AH fejléc úgy, hogy az hitelesítési (authentication) mező nullákkal van kitöltve.
• Az egész felsőbb szintű protokoll adat (például a TCP szegmens vagy a belső IP csomag tunnel mód esetén), amelyről feltesszük, hogy az út során nem változik meg.

IPv6 esetén az IP fejlécnek az út során nem változó mezői például a verzió, az adathossz, a következő fejléc mező, a forráscím és (routing fejléc hiányában) a célcím. Változó, de kiszámítható mező a célcím routing fejléc jelenlétében. Változó, ezért a MAC számítás során nullákkal kitöltött mezők a class, flow label és hop limit mezők.

A küldő a fenti logikai algoritmus alapján számolja ki a MAC értékét, amelyet azután az hitelesítési (authentication) adatmezőben helyez el. A fogadó szintén ezek alapján számolja ki a MAC értékét és veti össze az eredményt az hitelesítési (authentication) mezőben kapott értékkel. Ha a kettő megegyezik, a csomag feladójának az hitelesítése és a csomag integritásának az ellenőrzése sikeres volt.

A replay támadások elleni védekezésül a fejlécben levő sorszám szolgál. Amikor a rendszer egy új SA-t hoz létre, a feladó a sorszám kezdőértékét 0-ra állítja, és minden elküldött csomag előtt eggyel növeli az értékét. Így az első csomagban a sorszám értéke 1. Ha a replay elleni védekezés nincs kikapcsolva (amit csak a címzett kérhet), akkor a feladó nem engedheti, hogy a sorszám számláló a 2^32-1 értéket elérve körbeforduljon. Ezt a számot elérve a feladónak törölni kell az SA-t és egy új kulcssal egy újat kell létrehozni.

Mivel az IP egy kapcsolat-nélküli nem megbízható protokoll, ezért nem garantálja a csomagok sorrendben való megérkezését. Ezért a IPSec AH feldolgozásánál a fogadónak egy (default 64 csomagnyi) ablakban kell kezelnie a bejövő csomagokat. Az ablak jobb oldalát az eddig megkapott legmagasabb sorszámú csomag sorszáma határozza meg. A bejövő csomagok feldolgozása a következő módon történik:

• Ha a beérkező csomag az ablakba esik és új, akkor át kell, hogy essen az hitelesítési ellenőrzésen. Ha az a csomagot rendben levőnek találta, akkor a csomagnak az ablakban levő sorozatszáma megjelölődik, mint már beérkezett, hitelesített csomag.
• Ha a csomag sorszáma az ablak jobb szélén kívülre esik, akkor a hitelességét ellenőrizni kell. Ha az rendben van, akkor az ablak eltolódik ezen új csomag sorozatszámáig és a sorozatszáma az ablakban megjelölődik.
• Ha a csomag az ablak bal szélén kívülre esik vagy a hitelesség ellenőrzése sikertelen, akkor a csomagot el kell dobni és ezt a rendszernek eseményként jelezni, naplózni kell.

3.9.1.2. Az ESP protokoll

Az ESP (Encapsulating Security Payload) titkosítási szolgáltatást nyújt, védve az üzenet tartalmát a lehallgatások ellen, valamint korlátozott védelmet tud nyújtani a forgalmi adat-analízisen alapuló támadások ellen. Az ESP opcionálisan az AH-hoz hasonló hitelesítési szolgáltatásokra is képes.

Az ESP csomagot közvetlenül megelőző protokoll fejléc protokoll (IPv4) vagy következő fejléc (IPv6, IPv6 kiterjesztéses fejléc) mezőjében az ESP csomag azonosítójaként az 50-es szerepel.

Az ESP csomag a következő részekből áll:

3-4 ábra: IPSec ESP titkosított csomag

• Security Parameter Index - biztonsági paraméter-index (32 bit): tetszőleges 32 bites szám. Az SPI a címzett IP címével és a biztonsági protokoll azonosítójával (ESP esetén 50) egyértelműen azonosítja az IP csomaghoz tartozó SA-t.
• Sequence Number - sorszám (32 bit): a mező egy monoton növekvő számláló értékét tartalmazza.
• Payload Data - adatmező (változó hossz): a transzport-szintű szegmens (transzport mód) vagy IP csomag (tunnel mód).
• Padding - helykitöltés (0-255 byte): ha a titkosító algoritmus a jellegéből fakadóan csak valamilyen szó-méret (pl. 8 byte) többszörösének megfelelő adattal tud csak dolgozni, akkor szüksége lehe néhány extra byte-ra; a padding mező a valós adatforgalom méretének a "meghamisításával" a forgalmi analízisek ellen való valamilyen fokú védekezésre is használható.
• Pad Length - a helykitöltés hossza (8 bit): a megelőző helykitöltő mező byte-jainak a száma (lehet zérus is).
• Next Header (a fönti ábrán hibásan Next Length) - következő fejléc (8 bit): az ESP hasznos terhében levő adat fejlécének a típusa.
• Authentication Data - hitelesítési (authentication) adat (változó): Egy változó hosszúságú (de 32-bites szavak egész számú többszöröse) mező, amely az hitelesítési (authentication) adat nélküli ESP csomag hitelesítésére szolgál.

Az adatmező, helykitöltés, helykitöltés hossza és következő fejléc mezőket az ESP az SA-ban tárolt szimmetrikus titkosító algoritmussal titkosítja, amely algoritmus default esetben a DES. Sok más titkosító algoritmus ESP-ben való használatát szabvánzosították, például: háromkulcsos háromszoros DES, RC5, IDEA, CAST, Blowfish. Az hitelesítési algoritmusként a AH-nál alkalmazottak használatók.

ESP esetében a két szolgáltatás - titkosítás és hitelesítés (authentication) - egymástól függetlenül kapcsolható be, de mindkettőt egyszerre kikapcsolni nem lehet. Mindkét szolgáltatás használata esetén az ESP először titkosítja a hasznos adat, helykitöltés, helykitöltés hossza és következő fejléc mezőket, majd hitelesítíti az ESP csomagot. Az ESP csomagot tartalmazó IP csomag fejléc-elemeinek az hitelesítését az ESP - az AH-val ellentétben - nem végzi el, ezért az ESP NULL titkosítás melletti autentikációs szolgáltatása nem teljesen azonos az AH szolgáltatásával.

3.9.1.3. Transzport mód

Az AH és ESP mindegyike két módban, transzport vagy tunnel módban használatók.

A transzport mód elsősorban a felsőbb szintű protokollok, azaz az IP csomag adatmezejének a védelmére szolgál. Ilyenek például a TCP vagy UDP szegmensek vagy az ICMP csomagok, amelyek közvetlenül az IP fölött vannak. A transzport mód tipikusan két host (IP kommunikációs szereplő) közti végpont-végpont kapcsolatokban használatos. Amikor egy host AH-t vagy ESP-t használ IPv4 fölött, akkor a hasznos adat az, ami az IP fejlécet követi. IPv6 esetén a adatmező az, ami az IP fejlécet és az IPv6 kiterjesztéses fejléceket követi, a címzett opcionális fejlécek nélkül, amelyek belefoglalhatók, vagy kihagyhatók az AH és ESP védelméből.

3-5 ábra: ESP transport és tunnel mód

Az ESP transzport módban az IP fejléc nélküli adatmezejétt titkosítja, opcionálisan hitelesíti. Az AH transzport módban az IP hasznos terhét és az IP fejléc bizonyos részeit hitelesíti. Az ESP transzport mód a következőkben foglalható össze:

• A forrásnál az egész transzport-szintű szegmenst az ESP fejléc megfelelő részével együtt titkosítják és a titkosítatlan blokkot a titkosítottal helyettesítik. Az hitelesítési (authentication) adatot opcionálisan hozzáadják a csomaghoz, majd az IP csomagot kiküldik a hálózatra.
• A csomag a címzett felé irányítódik. A közbülső routereknek csak az IP fejlécet és a titkosítatlan IP kiterjesztéses fejléceket kell megvizsgálni, a titkosított adatot nem.
• A címzett megvizsgálja és feldolgozza az IP fejlécet és a titkosítatlan kiterjesztéses fejléceket. Ez után, az ESP fejlécben levő SPI, címzett IP cím és biztonsági protokoll azonosító (ESP vagy AH) alapján meghatározott SA-ban levő paraméterek segítségével opcionálisan ellenőrzi a csomag hitelességét, majd visszafejti a titkosított transzport-szintű szegmenst.
• Az AH csomagok feldolgozása hasonló módon történik.

A transzport módú működés bármely alkalmazás esetén használható. Ez a mód meglehetősen hatékony, mivel nem sokkal növeli meg az IP csomag méretét. Az eljárás egyetlen hátránya, hogy a hoszt-hoszt közti kommunikáció forgalmi analízise továbbra is lehetséges marad. (A forgalmi analízises támadásokat elsősorban (ipari) kémkedésekben használják általános következtetések levonására, azok más módon szerzett adatokkal való összevetésére. Például, ha A hoszthoz a partnerei általában FTP-vel kapcsolódnak hozzá, akkor az adatforgalom megfigyelésével egy támadó levonhatja azt a következtetést, hogy az X szervezet fő FTP szervere nagy valószínűséggel A, így a további adatszerzési erőfeszítéseit erre érdemes koncentrálni.)

3.9.1.4. Tunnel mód

Tunnel mód esetén az egész eredeti csomagot egy másik IP csomag belsejébe helyezik (IP-IP tunnelezés), így biztosítva, hogy az egész eredeti csomag a (publikus) hálózaton való áthaladás közben változatlan marad. Mivel ESP esetén az eredeti IP fejléc a célcímen kívül tartalmazhat egyéb routing információkat is (source routing utasítások, hop-by-hop opciók), ezért nem lehet egyszerűen kiküldeni az ESP-vel titkosított tunnelezett IP csomagokat. Hogy a közbülső routerek képesek legyenek megfelelő módon kezelni a titkosított tunnelezett csomagot, olyan új IP fejlécbe kell azt becsomagolni, amelyik a megfelelő eredeti routing információkat tartalmazza.

A tunnel módot leginkább két biztonsági gateway (pl. tűzfal vagy router) között használják, amely esetben a két gateway között egy VPN-t (Virtual Private Network, virtuális magánhálózat) hoznak létre. Tunnel móddal a két gateway mögötti hosztok közti biztonságos kommunikáció valósítható meg anélkül, hogy az összes kommunikáló hoszton IPSec-et kellene implementálni.

Míg a transzport mód az ESP-képes hosztok közti kommunikáció védelmére alkalmazható a leginkább, a tunnel mód egész hálózatok közti forgalom védelmére képes. Mivel ezen utóbbi esetben a titkosítás és autentikáció csak a két gateway gépen történik, az leveszi a titkosítás terhét a hosztokról és a kisszámú résztvevő miatt egyszerűsíti a kulcskezelést. A VPN-ként használt tunneles ESP lehetetlenné teszi a forgalmi analízisen alapuló támadásokat.

3.9.2. Kulcskezelés

Az AH és ESP működése a kommunikálni akaró hosztok titkos kulcsain alapul: titkos kulcsok szükségesek az autentikációhoz és a titkosításhoz egyaránt. Az IPSec architektúrája című RFC [RFC2401] két kulcskezelő mechanizmus támogatását teszi kötelezővé:

• Manuális: a rendszeradminisztrátor minden egyes résztvevő hoszton kézzel konfigurálja a hoszt saját és a kommunikáló partnerei kulcsait. Ez nyilvánvalóan csak kisszámú host és statikus konfiguráció esetén tartható kézben. A manuális kulcskezelés következményeként elvész a replay támadások elleni IPSec védelem (nem lehet új SA-t létrehozni).
• Automatizált: az automatizált kulcskezelés lehetővé teszi kulcsok új SA-k számára való igény szerinti generálását és a kulcsok automatikus propagálását. Az automatikus kulcskezelés több szoftvert és azok nehezebb konfigurációját jelenti, de ez jóval rugalmasabb, mint a manuális kulcskezelés.

Az IPSec default automatikus kulcskezelő protokollja az IKE (Internet Key Exchange - Internet Kulcs Csere). Az IKE standard eljárásokat fogalmaz meg az IPSec-et használó partnerek dinamikus autentikációjára, az igényelt biztonsági szolgáltatásoknak a partner képességei alapján való beállítására és kulcsok dinamikus generálására. Az IKE több különböző protokollból létrejött hibrid-protokoll. Része az ISAKMP (Internet Security Association and Key Management Protocol - Internet Biztonsági Kapcsolat és Kulcskezelő Protokoll), amely egyrészt egy keretrendszer a kulcskezelés számára, másrészt jól definiált protokoll támogatás az SA létrrehozására és paramétereinek a megállapítására; az IPSec DOI (Domain Of Interpretation - Interpretáció Területe) for ISAKMP, amellyel a meglehetősen absztrakt ISAKMP alkalmazhatóvá válik az adott területen; végül az Oakley kulcsmeghatározási protokoll (pontosabban azok egy csoportja), amellyel a kulcsokat hozzák létre.

Az IPSec RFC-k a kulcsok terjesztésére több protokollt/infrastruktúrát is definiálnak:

• PKI - Public Key Infrastructure (Nyilvános Kulcsú Infrastruktúra): a PKI lényege, hogy a felhasználók nyilvános kulcsainak az hitelesítését egy, a mindeki által elfogadott Certificate Authority (CA - Igazoló Hatóság) által kibocsátott publikus kulcs-igazolás teszi lehetővé. Az alkalmazott lépések a következők:
1. A kliens létrehoz egy nyilvános és titkos kulcspárt. Elkészít egy aláíratlan igazolást a felhasználói azonosítója és a publikus kulcsa felhasználásával, amelyet biztonságos módon eljuttat a CA-nak.
2. A CA létrehozza az aláírást: kiszámolja az aláíratlan igazolás hash értékét és titkosítja azt a saját titkos kulcsával. A CA hozzácsatolja az igazolást az aláíratlan igazoláshoz és visszaküldi a kliensnek.
3. A kliens az aláírt igazolását bárkinek elküldheti: bárki igazolhatja az igazolás valódiságát kiszámolva az aláíratlan igazolás hash értékét és visszafejtve az aláírt igazolást a CA publikus kulcsával. Ha a két kapott érték megegyezik, akkor a felhasználó hitelesítése sikeres volt.
• Több kereskedelmi cég támogatja a PKI-t és CA szolgáltatás vásárolható/építhető már létező szoftverek alkalmazásával.
• Secure DNS [RFC2230][RFC2535][RFC2538] - Biztonságos DNS: a DNS-nek mint egy már létező és kiépített infrastruktúrának kulcsok tárolására/cserélésére való kibővítését több RFC taglalja. Amennyiben az RFC-k implementálása befejeződik és a biztonságos DNS szolgáltatás elterjed, várhatóan ez lesz az elsődleges kulcskezelő eljárás: neutrális és egy jól ismert szolgáltatás kibővítése.
• Photuris [RFC2522]: a Photuris az IKE és ISAKMP egy alternatívája. Az OpenBSD támogatja ezt a kulcskezelő eljárást.

3.9.3. Problémák

Az IPSec - noha jelenleg az egyik legjobb biztonsági szolgáltatást nyújtó protokoll - néhány problémát is rejt magában [FerSch]:

• Komplexitás: a biztonsági szoftverek legnagyobb ellensége a komplexitás, az IPSec pedig egy meglehetősen bonyolult rendszer. Az ebből eredő nehézségek a következők:
• Komplex biztonsági rendszerek biztonságának formális igazolása nagyon nehéz, ha nem lehetetlen feladat.
• Komplex rendszerek implementálása során nehéz elkerülni a belső programhibákat.
• A komplex rendszerek használata a sok lehetséges opció és rugalmasság miatt nehéz a felhasználók számára. Fennáll a veszélye, hogy elveszvén a lehetőségek között a felhasználó a rossz opció-kombinációt választja az optimális/ideális/biztonságos helyett (pl. ESP esetén titkosítást használ autentikáció nélkül, amely a biztonság hamis érzetét kelti valós biztonság helyett).
• Az IPSec egyszerűsítése érdekében többen javasolták a többé-kevésbé redundáns AH protokoll elhagyását és annak megkötését, hogy ESP esetén autentikáció nélküli titkosítást ne lehessen választani.
• Biztonsági szempontból megbízhatóbb megoldásnak tekintik az "először hitelesítés, utána titkosítás" sorrendet, ahogyan pédául az SSL is működik. As ESP-nél a rossznak tekintett sorrendben először titkosítják az adatokat majd hitelesítéssel látják el a kapott titkosított adatblokkot.
• Az IPSec-ben külön rész foglalkozik az ún. kritpográfiailag gyenge kulcsok kizárásával. A kriptográfialiag gyenge kulcsok elleni védekezés helyett egyszerűbb lenne elhagyni a gyönge titkosító algoritmusokat és megfelően erőseket szabványosítani az IPSec számára.
• Az IKE/ISAKMP protokoll alternatíváját jelentő Photuris protokoll szerzője szerint [Simpson] az ISAKMP-ben néhány belső inkonzisztencia és tervezési hiba található (Denial of Service (Dos) támadási pontok, különböző implementációk közti együttműködési nehézségek, stb).

Mindezek ellenére még egyszer hangsúlyoznunk kell: az IPSec jelenleg az egyik legjobb és legteljesebb biztonsági szoftver, amely napjainkban elérhető és használható.

3.10. QoS (Quality of Service) szolgáltatások.

A QoS kialakításának lehetőségét és problémáinak vizsgálatát IP hálózatokon a következők indokolják:

• Felmerült az igény az Internet hálózat (csomagkapcsolt) és a hagyományos (áramkörkapcsolt) távközlési hálózatok integrálására, összekapcsolására.
• A használó szempontjából ezt az indokolja, hogy
  • a két hálózaton nyújtott szolgáltatásokat egységesen lehet majd használni, másrészt
  • a sok feladatra gazdaságosabb csomagkapcsolt hálózat a szolgáltatások díját is csökkenti.

A fenti igény felveti azt a kérdést, hogy a jelenlegi IP hálózat alkalmas-e valós idejű szolgáltatások (hang és kép) lebonyolítására, illetve alkalmas-e megbízható kapcsolatok (pl. pénzügyi, államközi) kialakítására, ahol elsőrendű fontosságú a valós idejű adattovábbítás, illetve a biztonságos adatvédelem kialakítása. Arra, hogy a fenti problémákra választ lehessen adni a következő kérdéseket kell megvizsgálni, illetve a következő vizsgálatokat kell elvégezni:

• Meg kell vizsgálni a jelenlegi Internet hálózat tulajdonságait, hogy fenti követelményeknek mennyire tesznek eleget. Ez magába foglalja a hardver elemek, valamint a kommunikációban résztvevő protokollok vizsgálatát. Mellékesen megjegyezzük, hogy a távközlésben minden berendezés, protokoll egy nemzetközi szerv által elfogadott szabványos konformancia (illetve megfelelőségi) vizsgálatnak vetnek alá, amely vizsgálat bizonyítja, hogy a berendezés (protokoll) konform az nemzetközi ajánlásban rögzített specifikációval. Csak megfelősségi vizsgálat után kapcsolható a távközlési hálózatra. A fenti megfelőségi vizsgálat kikényszeríti, hogy a protokoll leírásai egységesek és pontosak, valamint a vizsgálat (bárhol végzik a világban) azonos körülmények között történik, a vizsgálat eredményét rögzítő dokumentum is azonos formátumú. Ezzel a problémával jelenleg részletesebben nem kívánunk foglalkozni, csupán megjegyezzük, hogy ilyen vizsgálatok (valamilyen szinten) az Internet hálózat esetében sem kerülhetők meg, mivel ez rendkívüli módon befolyásolja a szolgáltatás minősségét (megbízhatóságot, biztonságot stb.). Jelenleg ezek a vizsgálatok az Internet hálózatra vonatkozóan korlátozottak, de a leírások (rfc protokoll specifikációk), valamint az implementálók által kiadott specifikációk sem felelnek meg a távközlésben elvárt és megszokott minőségnek. Felmerül a kérdés, hogy a fentiek pontos tisztázása nélkül, vagyis egy pontatlanul definiált hálózat esetén hogyan fogalmazzuk meg a minőségi szolgáltatást?
• Meg kell vizsgálni, hogy a jelenlegi hálózat alkalmas-e valósidejű adatátvitelre. Erre a kérdésre a válasz vagy nem, vagy az, hogy átalakítás nélkül nem lehetséges. Az Internet hálózat ugyanis nem erre készült. Célkitűzés volt a hálózat állapotának megfelelő legoptimálisabb (“best effort”) szolgáltatás, ennek a kritériumnak felel meg a jelenlegi hálózat. Kérdés milyen változtatásokat, új eszközöket és új protokollokat szükséges üzembe helyezni ahhoz, hogy az Internet hálózat alkalmas legyen a valósidejű szolgáltatások lebonyolítására? A továbbiakban ezeket a kérdéseket próbáljuk vázlatosan megvilágítani.

Az IPv4-es protokoll tervezésekor is gondoltak arra, hogy egyes csomagokat a hálózaton különböző képen kell kezelni, azaz szükséges optimalizálni a teljesítményt, megbízhatóságot, költséget, s biztosítani (amennyire a hálózat forgalma megengedi) a kis késleltetést (pl. Telnet és FTP parancs funkciói esetén). Erre a célra az IP protokoll fejlécében 8 bit hosszúságú, a szerviz típusát meghatározó (type-of-service: TOS) bitek szolgálnak (ebből négy bit nem használt, mivel csak akkor van értelme ezeket a biteket használni, ha ezeket egységesen kezeli az összes csomópont és router).

Az IPv6 protokoll tervezésekor erre a célra két összesen 28 bit hosszúságú mezőt terveztek be az IPv6 protokoll fejlécében. Ez két mezőre van bontva. Egy 8 bit hosszúságú mező szolgál az IPv6 csomagok prioritásának meghatározására (class: prioritás szerinti osztályozására), míg 20 bit szolgál a folyamat azonosítójaként (flow label), a csomagok finomabb megkülönböztetésére.

A fentiek alapján látható, hogy mindkét Internet protokoll esetében gondoltak a csomagok prioritás szerinti kiszolgálásra, azaz a valós idejű szolgáltatásra. Az belátható, hogy ez valós idejű szolgáltatás megvalósítása nem csak ezen a protokollon múlik (ez csak egy lehetőség), amit igénybe vesznek (vehetnek) a felette lévő protokollok. Jelenleg ezeknek a lehetőségeknek elvi tisztázása folyik. Ugyanis az opciókat használó felhasználói protokollok kidolgozásával egyidejűleg szabályozni kell azokat az elveket, hogy hogyan lehet használni ezeket az opciókat, azaz jogosultságokat kell bevezetni. Ellenkező esetben a minőségi szolgáltatás nem azoknál a használóknál valósul meg, akikre ezt vonatkoztatni akarjuk. Így ez a szolgáltatás több megoldandó problémát felvet: felhasználói protokollok megváltoztatása (operációs rendszer vonzata is van a problémának), felhasználói jogok titkosítása, útvonalválasztók (router) megfelelő átalakítása. Az látható, hogy a IPv6 pontosabb megkülönböztetést tesz lehetővé az egyes kiemelt fontosságú csomagok között. A probléma, hogy IPv6-os rendszer (ez alatt az IPv6 alkalmazói protokolljait is értjük) jelenleg nagyon változatos képet mutat. Elvileg minden gyártó támogatja, de pontosabban vizsgálva a problémát, kiderül, hogy az alkalmazói protokollok hiányosak vagy nem is léteznek.

A forrás (f) és célállomás (v) közti vonalat jellemezhetjük a két állomás között (ábra) áthaladó csomagok késleltetésével (delay), a késleltetés változásával (jitter), valamint vonal adatvesztésével. Ezt a három mérőszámot nagyban befolyásolja a vonal sávszélessége (bandwidth), és függ a vonal csomópontjaiban üzemeltetett routerek képességeitől (ezt később részletezzük).

3-6 ábra: QoS architektúra

A továbbiakban megpróbálunk három módszert elemezni (s ezek hardver és szoftver vonzatát), amelyek megkísérlik lehetővé tenni a valósidejű szolgáltatásokat internet hálózatokon. Ezek:

• IntServ (Integrated Services) szolgáltatások
• DiffServ (Differenciated Services) szolgáltatások
• MPLS (Multiprotocol Label Switching) eljáráson alapuló szolgáltatások.

Mindegyik alapja, hogy az internet szolgáltatóknak előre meg kell állapodni a forgalom nagyságában, illetve a forgalom minőségében (a forgalom teljesítésének idejében, csomagvesztés nagyságában és minden más, a forgalom minőségét meghatározó mutatóban). Természetesen minden minőségi követelmény bevezetésének anyagi (beruházási vonzata) is van, mivel a jelenlegi internet szolgáltatás (s az internet hálózat elemei, elsősorban itt a routerekre gondolunk) erre nem alkalmasak. Természetesen a minőségi szolgáltatást megfelelő díjazásban is kell részesíteni, hogy a beruházó pénze idővel megtérüljön. Az utóbbi felveti a minőségi szolgáltatást használók megkülönböztetését a “best-effort" szolgáltatók csoportjától, illetve annak megakadályozását, hogy az utóbbi csoport csalárd módon hozzá férhessen a minőségi szolgáltatásokhoz (ismerve az internet biztonsági problémáit az utóbbi kritérium nem lebecsülendő).

Mindegyik megoldásban igen komoly feladat hárul az routerekre, mivel minden egyes csomagot meg kell vizsgálni a következő szempontok szerint:

• csomagok prioritása
• forráscíme
• célcíme.

A fentiek alapján kell elvégezni a csomagok:

• osztályozását, valamint
• a csomagok továbbításának ütemezését.

Ez az routerben speciális hardver tulajdonságokat feltételez (ami csak az újabb korszerű routerekben van meg), mivel a beérkezett nagy prioritású csomagokat prioritásuk sorrendjében azonnal továbbítani kell, míg a kisprioritású csomagokat időszakos tárolóban kell elhelyezni, s továbbítását késleltetni. Mivel a tárolókapacitás véges méretű, ezért a prioritás, célcím és forráscím alapján és a szolgáltató utasítása alapján az megfelelően osztályozott csomagok (egy korláton belül) kitörölhetők a tárolóból. Ez természetesen csomagvesztést eredményez, viszont biztosítja a nagyobb prioritású csomagok megállapodás szerinti továbbítását.

3.10.1. IntServ (Integrated Services) szolgáltatások

Az kidolgozott eljárás az internet hálózatot, amely több különálló internet hálózatot is tartalmazhat (egymástól távollévő és különböző szolgáltatók hálózata), egy egységes hálózatnak tekinti. Feltételezi, hogy a hálózatban lévő routerek rendelkeznek forgalomvezérlési tulajdonságokkal (osztályozás, ütemezés, tárolás). A feltételezés a jelenlegi helyzetben nem mindig teljesül. ezért a módszer igen korlátozottan alkalmazható. Az erőforrások menedzselését (lefoglalását) az erre a célra kidolgozott RSVP (Resource Reservation Protocol) végzi.

Az RSVP protokoll képes az routereknek jelezni a forgalommal kapcsolatos erőforrás igényeket (itt elsősorban a csomagok időszakos tárolására van szükség abban az esetben, ha a csomag azonnal nem továbbítható a célállomás irányába). Természetesen a sürgős csomagok valós idejű kiszolgálása (router) processzor teljesítmény igényt is jelent. Az RSVP protokoll a forrástól (f) kiindulva, végig haladva a célállomáshoz (v) vezető úton routereket értesíti a forgalom főbb paramétereiről. Abban az esetben, ha mindegyik router képes az adatforgalom lebonyolítására a kívánt minőségi paraméterekkel, akkor a kapcsolat felépülhet (ellenkező esetben hibajelzés keletkezik). A kapcsolat felépítése csak a forrástól a célállomásig történik meg, hasonló folyamatnak kell lezajlani a másik irányba is, a célállomástól a forrásállomásig.

3-7 ábra: IntServ (RSVP)

A módszer főbb tulajdonságai (előnyei és hátrányai) és a felmerült nehézségek:

• Az kommunikáció kiépítése bonyolult, ha figyelembe vesszük, hogy egy távoli kapcsolatnál a routerek száma nagy lehet (a kapcsolat létesítési idő megnő).
• Kapcsolat (forrás lefoglalás) kiépítése csak egy megadott időtartamra szól, ha ezen az időn belül nem érkezik frissítés (újabb RSVP üzenet), akkor a kapcsolat automatikusan lebomlik. Ez egy nagy forgalmú hálózat esetén nagyon gyakran előfordulhat, hogy időben nem érkezik meg az RSVP kérés.
• Minden adatfolyamról a routernek tárolni kell a főbb paramétereket (forrásállomás és célállomás címe, a minőségi paraméterek stb.)
• A fentiek alapján becsülhető a processzor teljesítmény: feltételezve egy 100 Mb/s sebességű hálózatot kiszámítható, hogy több tízezer csomag adatait kell tárolni, s a tárolt adatok alapján néhány tíz mikro-másodperc alatt kell dönteni a beérkezett csomag sorsáról.
• A számlázás problémája igen bonyolult. Mivel több internet szolgáltató rendszerén (ábra) keresztül haladhat a forgalom, ezért mindegyikkel forgalom megállapodást kell kötni, illetve meg kell állapodni a számlázás feltételeiben.
• A forgalom átterelése –meghibásodott, vagy leterhelt útvonal esetén- nehézségekben ütközik, ha egy újabb szolgáltató hálózatán kell átvezetni a forgalmat.
• A megoldás mind IPv4-es, mind IPv6-os hálózat esetén működik.
• A megadott útvonal felépítése (távközlési fogalommal: hívásfelépítés) hosszú (ami meghatározhatatlan) időt vehet igénybe. Ennek oka, hogy hívásfelépítéskor az RSVP protokoll üzenetei egy "best-effort" tulajdonságú hálózaton futnak, ami nem-determinisztikus tulajdonságokkal rendelkezik.

3-8 ábra: IntServ szolgáltatás.

3.10.2. DiffServ (Differenciated Services) szolgáltatások

A fenti bonyolult eljárások kiküszöbölésére egy másik módszert is kidolgoztak, ez a DiffServ eljárás. A módszer mentesíti a routerek többségét a forgalom paramétereinek tárolásától, viszont nem mentesíti forgalmat jellemző paraméterek csomagonkénti feldolgozásától. A módszer lényege, hogy mivel a csomag tartalmazza a jellemző paramétereket (címek, prioritás, minőségi követelmények), ezen értékek és a forgalmi megállapodások alapján lehet a minőségi szolgáltatásokat biztosítani. Az internet szolgáltató három csoportba rendezi az routereket:

• A be- és kilépési pontok routerei (ingress, egress router), amelyek számon tartják a szomszédos szolgáltatókkal kötött forgalom-megállapodások alapján a forgalmat, s azt a megállapodás alapján teljesítik, vagy elutasítják ("szemétkosárba" dobják) vagy külön díj ellenében teljesítik (ha ez nem megy a más szolgáltatókkal kötött megállapodás rovására). A SLA (Service Level Agreement) és TCA (Traffic Condition Agreement) megállapodásoknak megfelelően: itt kell ellenőrizni a jogosultságokat, a forgalmi szerződéseknek megfelelő erőforrás foglalást, valamint a megfelelő forgalom szabályozást.
• Közbenső útvonalválasztók. Ezek a lehető legrövidebb útvonalra eső routereket jelenti, amelyek lehetővé teszik az átmenő forgalom gyors (a prioritásnak megfelelő) lebonyolítását. Természetesen a fenti routereket képessé kell tenni a forgalom-megállapodásnak megfelelő forgalom lebonyolítására. A módszer az IPv4 protokoll fejlécében lévő TOS mezőt helyettesíti a DS (Differenciated Services) mezővel (IPv6-os protokoll esetén az eljárás hasonló), s így belső útvonalválasztóknak már csak ennek értékének megfelelően kell a csomagirányítást végezni, nem kell a SLA, TCA megállapodások szerinti osztályozást végezni, ami sokkal kisebb számítási kapacitás lekötést jelent.
• Egyéb routerek. Ezek szolgálhatnak a nem minőségi szolgáltatások lebonyolítására, illetve ezek nem képesek minőségi követelményeknek megfelelő szolgáltattásokat nyújtani. Természetesen az előző két csoportba tartozó routereknek is képesnek kell lenniük nem minőségi alapokon nyugvó szolgáltatásra.

3-9 ábra: DiffServ szolgáltatás

Könnyen belátható, hogy a hálózat megfelelő tervezésével a rendszer könnyebben kézben tartható, mint az IntServ szolgáltatás, valamint a számlázás is megoldhatóbbnak tűnik (a belépő pontoknál kell figyelni a erre). A külső csomópontoknál a forgalom szabályozással meg lehet akadályozni a rendszer túlterheltségét, s az útvonalválasztók, valamint vonalak áteresztőképessége jobban tervezhetőbbé válik. Természetesen a kitüntetett szerepeket betöltő routereknek szintén komoly adminisztratív feladatot kell elvégezni.

3.10.3. MPLS (Multiprotocol Label Switching) eljáráson alapuló szolgáltatások.

Ez a megoldás egy új most kialakulóban lévő eljárás, amelyik több hálózaton is működik: IP, DECnet, ATM, FR stb. A hagyományos IP hálózatokban a csomagok irányítása a harmadik rétegben történik. Az MPLS eljárás alapján a csomagok irányítása a második rétegben történik, kiosztott címkék alapján. A csomagok a hálózatba lépéskor, a belépési pontokon osztályokba lesznek sorolódnak, a célcím (hálózatból való kilépés pontja), és a szolgáltatás szintje szerint. A cimkék 20 bites számok, melyek ezek után egyértelműen azonosítják az adott osztályba tartozó forgalmat. Az osztályokhoz természetesen szolgálatatási garanciákat lehet rendelni és ilyen módon biztosítani a QoS szolgáltatásokat. A címkék kiosztását és a forgalom irányítását a LDP jelzésprotokoll végzi.

3.10.4. QoS összegzés

Az előzőekből látható, hogy a valósidejű szolgáltatás megvalósítása internet hálózaton nem egy egyszerű feladat. Általános és teljes körű megoldás erre a célra nem adható. Az előzőekben vázlatosan ismertetett módszerek a probléma korlátozott megoldásának tekinthetők. Az is világos, hogy a megoldások új beruházást is igényelnek. A beruházások pedig csak abban az esetben történnek meg, ha lehetőség lesz a beruházott összegek megtérülésére, ez pedig csak akkor lehetséges, ha a díjtételek, illetve a számlázás megoldódik. Jelenleg az IntServ és DiffServ megoldások ilyen szempontból nem tekinthetők kiforrottnak.

A valósidejű szolgáltatásban használt protokollok az IPv4 és IPv6, UDP és RTP protokollok. Érdemes néhány szóban elemezni ezek hatását a valós idejű szolgáltatásra.

• Az látható, hogy az IPv6-os protokoll alkalmazása sokkal több lehetőséget teremt a csomagok osztályozására, mint az IPv4-es protokoll, s ezzel a növeli a szolgáltatás minőségét. Hátrányos lehet rövid csomagok (mint a hangszolgáltatás) esetén a szolgáltatás hatásfokára az IPv6-os fejléc (opció nélkül 40 byte, míg IPv4 esetén 20 byte).
• A valós idejű szolgáltatások esetén az hoszt-host réteg protokollként az UDP jöhet számításban. Használatakor semmilyen korrigálási lehetőség nincs, az elküldött csomag biztonságos és hibátlan megérkezéséről nincs visszajelzés a küldő részére. UDP alkalmazásának oka, hogy a hibás, vagy elveszett csomagok sokkal kisebb kárt okoznak (elveszett és hibás csomagok matematikai eljárásokkal korrigálhatók), mint a hibásan érkezett csomagok megismétlése (az FTP protokoll alkalmazása esetén). A minőség biztosítását a vonalak gondos tervezésével és jó hálózati elemek beépítésével kell biztosítani.
• Az RTP protokoll a csomagok sorrendiségét biztosítja (mivel az internet hálózat nem garantálja, hogy az elküldött csomagok ugyanolyan sorrendben érkezzenek meg a célállomáshoz, mint amilyen sorrendben elküldték őket), ami elengedhetetlen egy kép-hang szolgáltatás esetén (pl. konferencia esetén a képhez hozzá kell rendelni a hangot is).