4. Áttérés IPv6-ra

4.1. Miért érdemes áttérni az IPv6-ra?

Az IPv6-ra történő áttéréskor csak viszonylag alacsony költségekre és csak kisebb áttérési nehézségekre kell számítani, mivel az áttérés eléggé sokféle elvi módja kimunkált. Az IPv6 áttérési tulajdonságai a hálózatmenedzsment szempontokat figyelembe véve:

• Koncepcionálisan új rendszer, mely megtartja az IPv4-ben meglévő helyes koncepciókat (pl. skálázhatóság, végpont-végpont modell stb.)
• Az Internet ebbe az irányba fejlődik, aki nem alkalmazza, nem fog tudni kommunikálni és lemarad.
• A felhasználók nem sokat tapasztalnak az IPv6-ra történő áttérésből, ha helyesen történik meg és a helyes módon használják az Internet technológiát.
• Az áttérésnek nincs egy kijelölt napja és nem jár az egész site leállításával.
• Azonnali előnyként jelentkezik, hogy a hatékonyság megnő az IPv6 új lehetőségein keresztül.
• Az autokonfiguráció lehetővé teszi a hálózat menedzserek számára, hogy sokkal kisebb energia befektetésessel adjanak a hálózathoz új eszközöket, módosítsák konfigurációjukat, akár megváltoztassák a hálózat topológiáját.
• Ebből a változásból a felhasználók szinte semmit sem vesznek észre, még akkor sem, ha éppen dolgoznak.
• Az Anycast címzési mód hatékonyabbá teheti hálózat kihasználását (jelenleg az útvonal választás, de későbbiekben esetleg a szolgáltatások helyesebb elosztását) [anycast_analysis].
• Az egyszerűsített IPv6 csomaglánc struktúra hatékonyabbá teheti az útvonal választó szoftvereket [header_chaining].
• Hatékonyabb,és jobban menedzselhető Internet használatot tesz lehetővé a biztonság és a minőségi paraméterek kezelése. A biztonsági kiterjesztések (IPSec) megteremtik a védelem lehetőségét a szolgáltatások erőforrásainak védelmét (lehetőség a védelemre az DDoS ellen). Ezek a beépített védelmek lehetővé teszik a támadások gyorsabb felismerését illetve a támadások által okozott károk helyreállítására fordított idő csökkentését. A szolgáltatás minőségi paraméterek megoldhatják a differenciált kiszolgálást, új lehetőséget jelenthetnek az Internetnek, ami így még hatékonyabbá teheti a felhasználót.
• Az IPv6-ra történő átállás nem egy kikerülhető lépés. Az igazi döntést az igényli, hogy mikor váltunk IPv6-ra, vállalva ennek minden pozitív és negatív következményét. Azok a cégek, amelyek nem váltanak IPv6-ra egyre inkább izolálttá fognak válni, ahogy az IPv6 tért hódit.

Az új technológia, ahogy a technológia fejlődése során általában megfigyelhető, kétféle eredményre vezethet: csökkenő költségek, illetve növekvő hatékonyság. A sikeres új technológiák általában a nagyobb költségeket általában jól meghálálják, a gyorsabb növekedés, a nagyobb hatékonyság és az új távlatok lehetőségeivel. Hogy az IPv6 melyik kategóriába tartozik az az adott környezettől, szituációtól függ. Az új technológiára való áttérésre vonatkozó döntés meghozásához meg kell vizsgálni a költségeket.

4.2. Az IPv6-ra történő áttérés költségei

Az áttérés költségei több összetevőből állnak: beszerzés, oktatás, adminisztráció, a helyileg fejlesztett alkalmazások konvertálása.

4.2.1. Beszerzés

Az IPv6-ra történő átállásnak vannak beszerzési összetevői, melyek elkerülhetetlenek, azonban helyes választással és döntéssel az új szoftverek, eszközök vásárlásakor az IPv6 támogatottságot mint követelményt meg lehet jeleníteni. A legtöbb gyártó nagy valószínűséggel fog ajánlani IPv6-os szoftvert a normál upgrade folyamán. Egyes gyártók már most megteszik ezt: pl. Compaq, IBM, Sun, FreeBSD, OpenBSD, Linux, Cisco,Nortel, Ericsson, Hitachi nyújtanak Dual IPv6-IPv4 protokoll stack-el felszerelt eszközöket [howto]. Ilyen módon beszerzett szoftverek a normal update folyamatban beszerzésre kerülnek és nem jelentenek további költségeket.

A beszerzés megtervezésekor egy beszerzési tervet kell készíteni, mely meghatározza, hogy mely eszközöket milyen új szoftvereket, bővítéseket igényelünk (pl. egy izolált lokális hálózat nem igényelhet áttérést), illetve milyen új eszközök szükségesek.

4.2.2. Adminisztráció

A hálózati adminisztrációs költségek nehezen becsülhetőek meg, mivel ezek általában nincsenek külön nyilvántartva. Az adminisztrációs költségeket leginkább a nagy információtechnológia váltásokhoz lehet hasonlítani: pl. mainframe kliens-szerver architektúra váltás, 2000 év válság, mobil információtechnológiára váltás stb. A jelenlegi hálózat-menedzseri gyakorlatot figyelembe véve 4 fő szempontot kell a költségek meghatározásához figyelembe venni:

1. Címzés, címgazdálkodás és útvonalválasztás menedzsmentje
2. A kapcsolat fenntartása az Internet egészével: a különböző áttérési technikák menedzsmentje.
3. A biztonság menedzsmentje
4. A hálózat felügyelete

4.2.3. Az oktatás

Az oktatás költségei nagy mértékben függenek attól, hogy milyen információ források állnak rendelkezésre. Az első lehetőségek a hálózat menedzserek számára már régóta adottak, hogy megismerkedjenek az IPv6 technológiájával. Ezek a lehetőségek a különböző szemináriumok és konferenciák [IETF]. További lehetőségek akkor jelennek meg, amikor a gyártók a piacon széles körben megjelennek, és igény jelentkezik arra vonatkozóan, hogy saját termékük IPv6-os tulajdonságait a vásárlók kihasználhassák és megfelelő támogatást kapjanak hozzá. Különböző független oktatási cégek már napjainkban is kínálnak különböző tanfolyamokat.

A kurzusok különbözőek lehetnek, attól függően, hogy milyen célközönségnek szánják: IPv4-et ismerők számára, illetve kezdők számára. Magyarországon is, néhány egyetem informatikus diákjai már napjainkban is hallanak a IPv6 technológiáról, így 2-3 év múlva az IPv6 alapjaival megismerkedett friss diplomások jelenhetnek meg a cégeknél.

4.2.4. Helyileg fejlesztett alkalmazások frissítésének költségei

Ebben a tekintetben nagyon hasonló a helyzet a 2000. év váltás problémájához. Azonban itt valamivel egyszerűbb a helyzet, mivel az Internet igen széleskörű elterjedtsége csak 5-8 éves, így bizonyos tekintetben nem alakulhatott ki akkora probléma halmaz mint a 2000. év problémája esetén, másrészt viszont az Internet sokkal viharosabban hódította meg a vállalatokat. Több módszer is rendelkezésre áll a költségek csökkentésére:

1. Olyan áttérési módszer, ill. eljárás megvalósítása, amely nem teszi szükségessé az alkalmazás megváltoztatását.
2. Automatikus és félautomatikus fordító, ill. a programok módosítását segítő programok alkalmazása.

A költségek megbecsléséhez kapcsolódik a tanulmány 4.3.4. fejezete is, amely az IPv6-ra történő áttérés programozói vonatkozásait tárgyalja.

4.3. Az áttérés folyamat

Az IPv6 tervezői az IPng követelményei között egyértelműen megfogalmazták, hogy az új protokollra való áttérésnek a lehetõ legzökkenõmentesebbnek kell lennie, különösen a felhasználók számára. Ennek megfelelõen határozták meg az IPv6 tulajdonságait, és koncepcionális elemeit. Amint arról már korábban szó volt, egyértelműen deklarálták azt is, hogy nem írható elõ egy olyan határnap, ameddig az összes site-nak át kell állnia az új protokollra. A belátható jövõben a régi és az új protokollnak együtt kell működnie, miközben a felsõbb szintű protokollok számára ennek az együttműködésnek maximálisan láthatatlannak kell lennie. Az IPv6 tulajdonságait nem lehet kötelezõvé tenni, és csak folyamatosan szabad õket bevezetni. Ezen követelményeket megfogalmazó és kielégítõ egy lehetséges megoldás dokumentációja megtalálható a R. Gilligan és E. Nordmark által írt "Transition Mechanisms for IPv6 Hosts and Routers" című, RFC 1933 számú szabvány leírásában [RFC1933].

4.3.1. Áttérés a felhasználók szemszögéből

A felhasználók számára, akik az Internettel webböngészőjükön és levelező programjukon keresztül tartanak kapcsolatot nem fognak különbséget tapasztalni:

• A távoli szolgáltatásokat szimbolikus nevekkel (pl. www.ipv6.ik.bme.hu) érik el, így nem találkoznak a 128 bites címekkel.
• Az e-mail rendszer (SMTP, IMAP, POP3 stb.) szintén szimbolikus neveket használ (sokkal inkább mint a WWW)
• Az e-mail-ek borítékján megjelenhetnek a 128 bites IPv6-os címek, de ezzel a felhasználó csak akkor foglalkozik, ha valamilyen probléma merül fel, és ilyenkor a rendszergazda segítségét is igénybe veszi.
• Az URL-ek port specifikációja különbözhet az IPv6-ban, azonban ez nem jelent lényeges különbséget a korábbiakhoz képest, mivel ezt egyre kevésbé alkalmazzák a hálózaton a különböző tűzfal megoldások miatt, illetve általában a hypertext-ben előre beírt módon rendelkezésre állnak, így a felhasználónak nem kell begépelnie [RFC2732].
• Bizonyos protokollok esetén (pl. ftp) inkompatibilitások merülhetnek fel, mivel a protokoll "szövegrésze" tartalmazhatja a kommunikáló partnerek IP címét [NAT_friendly]. Ezért a felhasználók némileg megváltozott felhasználói felülettel találkozhatnak.

4.3.2. Áttérés a rendszergazdák szemszögéből

Az IPv6-ra történő áttérés a rendszergazdákra több terhet ró:

1. Az áttérési stratégia kidolgozása
2. Az áttérési módszer kiválasztás
3. Az áttérési módszer kidolgozása
4. Az áttérési módszer megvalósítása
5. Az áttérés értékelése

Ez az öt pont azonban előfordulhat, hogy nem egyszer kell, hogy végrehajtásra kerüljön, hanem többször a belső ill. külső igények változásának függvényében. Az igényektől függően a hálózat evolúcióval fejlődik (mint minden nagy rendszer), és ennek megfelelően változhat, hogy egy adott szituációban melyik áttérés ill. IPv4 -IPv6 együttműködési mód lehet optimális. Áttekintésül a következőkben áttérési módszereket részletezzük:

4.3.2.1. Dual stack megoldás

A Dual stack megoldásnak [RFC1933] az a lényege, hogy az IPv6 kompatibilis hoszt-ok és routerek egy kettős protokoll stack-kel rendelkeznek. Ez azt jelenti, hogy meglévő IPv4 (és pl. IPX, AppleTalk stb.) protokoll stack mellé egy IPv6 is bekerül, de olyan módon, hogy az alkalmazások IPv4 helyett/mellett az IPv6-ot is alkalmazhassák.

4-1 ábra: Duál stack IPv4/IPv6 az alkalmazás szempontjaiból

Hoszt esetében viszonylag egyszerű a dual stack megoldás, hiszen ahogy az előbb említésre került "csak egy újabb" protokoll stack integrálása a feladat. Azonban a TCP és UDP protokoll stack-et szintén frissíteni kell, hogy támogassa az IPv6-ot. Szintén meg kell oldani a két cím (IPv4 és IPv6) kezelését is, azonban ezt a IPv6 autokonfigurációs mechanizmusával nem nehéz ezt megtenni.

Router IPv6-os frissítését nehezebb megtenni. Amellett, hogy egy újabb protokoll stack-et kell integrálni a router szoftverbe. A router-nek tartalmaznia kell egyéb szolgáltatásokat is: IPv6 csomag továbbítás, útvonal választás, routing update (RIPng, OSPFv6 BGP4+) és routing (és egyéb hálózati paraméterek) terítése (Routing Advertisement) a hálózaton, menedzsment protokollok stb.

Mind a routernél, mind a hosztnál szükség van arra is, hogy a resolver library képes legyen IPv6 AAAA és A6 címek kezelésére [RFC1886][RFC2874], úgymint:

1. Csak IPv6 cím visszaadására
2. Csak IPv4 cím visszaadására
3. IPv4 és IPv6 cím visszaadására

Attól függően, hogy milyen címeket ad vissza a resolver, illetve ezeket milyen sorrendben teszi változhat, hogy milyen IP forgalom jön létre [UNIXNETPRGv1].

A Dual stack létezését a legtöbb áttérési megoldás feltételezi, így ennek támogatottsága alapkövetelmény a sikeres áttéréshez. Bizonyos esetekben (specializált beágyazott rendszerek esetén), illetve hosszú idő múlva (amikor már nem nagyon lesznek csak IPv4-el működő berendezések) elképzelhető, hogy megjelenjenek csak IPv6 protokollt támogató berendezések.

A dual-host megoldás adminisztratív szempontból elég egyszerű, hiszen csak installálni, frissíteni kell a megfelelő (host/router) szoftvereket, hogy IPv6 kompatibilis legyen az eszköz. Várható, hogy minden IPv4 megoldást nyújtó berendezés támogatni fogja az IPv6-ot. A Dual stack megoldással szinte teljesen láthatatlanul lehet áttérni, mivel amint a frissítés megtörtént, az alkalmazások használhatják az IPv6 új megoldásait és javításait egy másik IPv6-os csomóponttal történő kommunikációhoz, feltéve, hogy valódi IPv6-os összeköttetés lehetséges. Természetes a régi IPv4-es alkalmazások IPv4-en fognak kommunikálni, tehát nem oldja meg igazán az IPv4-es címek elfogyásának problémáját. Hosszabb távon természetesen megoldja, mivel minden eszköz IPv6-os címmel rendelkezni fog, így a kommunikáció lehetséges lesz.

Előnyök:

• Egyszerű installálni és konfigurálni.
• Egyszerű karbantartani (Ha DNS-t egyszerű karbantartani).
• A végpont-végpont koncepció nem sérül meg.
• Az IPv6 funkcionalitása kihasználható, ha IPv6-os csomópontok kommunikálnak.
• A dual-stack csomópont képes kommunikálni IPv4/IPv6, IPv4 és csak IPv6-os csomópontokkal.

Hátrányok:

• Nem jól skálázható. Ahogy említésre került, a dual-stack koncepciója szerint minden csomópontnak kell rendelkeznie IPv6-os és IPv4-es címekkel. Amint az IPv4-es címek kifogytak nem alkalmazható tovább a technológia.
• Címzés menedzselésének komplexitása. Elég nehéz egy csomóponthoz két IP címet nyilvántartani és karbantartani. Ebben nagy mértékben segíthet a Dinamikus DNS Update Protocol [RFC2136].
• Megnövekedett router tábla. Mivel két IP cím tartománya lesz ilyen módon minden hálózatnak ezért a router tábla bejegyzéseinek a száma megnövekszik (nem kétszeresére, mert az IPv6-os táblák hatékonyabbak a topológia szerinti címzés miatt).
• Nincsen kommunikációs lehetőség a csak IPv6-os és csak IPv4-es csomópontok között.

4.3.2.2. Globális IPv4-es címek hozzárendelése IPv6-os csomópontokhoz átmeneti jelleggel (AIIH)

Ez a Digital-nál (jelenleg Compaq) kifejlesztett mechanizmus[AIIH][DSTM] a dual stack megoldás skálázhatóságát próbálja orvosolni azzal a megoldással, hogy dinamikusan, a kommunikáció idejére globális IPv4 címeket kapnak a hosztok, ha IPv4-es szerverrel kívánnak kommunikálni. Természetesen minden csomópont egyedi IPv6-os címmel rendelkezik. Amikor egy ilyen csomópont kommunikálni akar egy IPv4-es csomóponttal, akkor egy IPv4-es címet foglal le az AIIH DHCP szerverétől ennek a kommunikációs viszonynak az idejére. Ez a IPv4-es cím vissza kerül a közös tartományba, miután a kommunikáció befejeződött.

4-2 ábra: AIIH módszer

Ezt a megoldást akkor lehet jól használni, ha a szervezet rendelkezik ugyan IPv4-os címekkel, de nem elegendővel. Természetesen a szolgáltatást nyújtó szervereknek IPv4-es címmel is kell rendelkezniük (nem dinamikussal), hogy a szolgáltatásokat IPv6 domain-en kívülről is elérhessék. Szintén jól alkalmazható ez a megoldás, ha az IPv6 már eléggé elterjedt és csak néhány esetben van szükség IPv4-es kommunikációra.

Előnyök:

• A végpont-végpont koncepció nem sérül meg.
• A forrás csomópont direkt módon kommunikál vagy IPv6-on vagy IPv4-en.
• Skálázható: IPv4-es cím csak akkor rendelődik hozzá egy csomóponthoz, ha tényleges kommunikációra van szükség
• A címek foglalása és menedzsmentje egyszerű (AIIH DHCP szerver, IPv6 cím menedzsment vagy autokonfigurációval vagy DHCPV6-al)[DHCPv6][DHCPv6_EXT].

Hátrányok:

• Az IPv4 infrastruktúrára továbbra is szükség van, ha IPv4-es csomóponttal kell kommunikálni (a belső és a külső hálózatban egyaránt.)
• Jelentős többlet kommunikációt igényel a AIIH DHCP szerverrel való kommunikáció minden egyes IPv4-es szerverrel való kommunikáció.
• Nem túlságosan egyszerű implementálni, mivel működtetni kell egy AIIH DHCP szervert (módosított DHCP szerver) és egy ezzel együtt működő Dinamikus DNS szervert.
• A TCP/IP világában nincs olyan terminológia, mint viszony (session) ennek megfelelően nem lehet pontosan tudni, hogy mikor lehet visszaadni a dinamikusan kiosztott IPv4-es címet. A DHCP által alkalmazott megoldást kell itt is alkalmazni, azaz a timeout-ot kell használni [DHCP].
• Ha egy csomópontnak a dinamikus allokáció során nem jut IPv4-es cím, akkor a kommunikáció nem tud létrejönni.
• Nincsen kommunikációs lehetőség a csak IPv6-os és csak IPv4-es csomópontok között.

4.3.2.3. Tunneling

Az előzőekben vázolt megoldásokban nem volt lehetőség nagyobb távolságok áthidalására két IPv6-ot alkalmazó hálózat között, ha köztük még nem áll rendelkezésre IPv6-os infrastruktúra, mert ebben az esetben mind a Dual-stack megoldásban, mind az AIIH esetében, a konfigurációtól függően szükséges lehet visszaváltani IPv4-re. A tunneling alkalmazásával, melynek lényege, hogy az IPv6-os csomagokat IPv4-es csomagokba csomagoljuk, lehetséges két IPv6-os hálózat összekötése akkor is, ha a két hálózat között nem lehetséges az "anyanyelvi" IPv6-os összeköttetés. Ez a becsomagolás a belépési ponton történik meg. A belépési csomóponton minden tunnelről információkat kell nyilvántartani, mint például a tunnel végpontja, az MTU az alagútban stb. [RFC1933].

A köztes IPv4-es csomópontok (tipikusan routerek) nem kell, hogy megvizsgálják a csomag tartalmát. Egyszerűen továbbítják azt a tunnel (alagút) végpontjához.

Az alagút végén a csomópont (Természetesen egy dual-stack csomópont) felismeri, hogy IPv6 csomag van becsomagolva az IPv4-es csomagba. Levágja a külső burkot a csomagról, majd az IPv6-os cím alapján továbbítja az IPv6-os cél állomás felé.

4-3 ábra: Tunnelezés koncepciója

Az áttérés folyamán elő fog fordulni olyan eset, hogy a csomópontok (routerek és hosztok) mindegyike frissítve lesz Dual-stack-es konfigurációra, tehát egymás között IPv6-on beszélgethetnek.

4-4 ábra: IPv6 tunnel IPv4 fölött

Az egymástól elszigetelt IPv6-os hálózatokat ilyen alagutakkal kapcsolják össze. Ahogy egyre több és több hálózat tér át IPv6-ra egyre kevésbe lesz szükség ezekre a tunnel-ekre, mert IPv6-on keresztül közvetlenül tudnak majd kommunikálni. Kétfajta tunneling technikát definiált az eredeti áttérési dokumentáció [RFC1933]: az automatikus és a konfigurált alagút technológiáját. Mindkettőre szükség lehet a helyes kommunikációhoz.

A különböző biztonsági problémák merülhetnek fel a különböző tunnelezési megoldások kapcsán. Nemcsak az IPv6 ellen irányuló támadásokra kell odafigyelni, hanem a becsomagoló IPv4 elleni támadásra is. Amennyiben IPv6 szintű titkosírás (ESP) kerül alkalmazásra, akkor az külső IPv4 szintű titkosítás csak akkor szükséges, ha forgalom analízis megakadályozása is szükséges. Ha az IPv6 csomagra hitelsítő fejléc is kerül (AH), akkor az külső IPv4 hitelesítés nem ad jelentősebb védelmet. Ha viszont csak IPv4 szintű IPSec megoldásakat alkalmazunk, akkor amint a tunnelből kilép az IPv6-os csomag, akkor védtelenné válik [TRANSITION_CONCEPT].

További biztonsági megfontolásokra van szükség az olyan megoldások esetén, amelyek egy fajta relay-ként funkcionálnak (pl. 6to4 relay, tunnel broker), hiszen ott relay-nek nem szabad átengednie jogosulatlan forgalmat. Ezt például csomagszüréssel, kliens azonosítással ki lehet szűrni [TRANSITION_ABUSE].

Nagyon fontos azonban megjegyezni, hogy semmelyik tunneling megoldás nem teszi lehetővé csak IPv4-es és csak IPv6-os csomópontot kommunikációját. Ehhez különböző transzlációs megoldások szükségesek.

Fontos szintén megjegyezni, hogy a tunneling megoldások csak akkor használhatóak általában, ha az IPv4 oldalon nincsen transzláció (pl. NAT) [NAT].

4.3.2.4. Automatikus tunneling

Az automatikus alagutat akkor lehet használni, ha egy IPv6-os csomópont akar kommunikálni egy IPv4 kompatibilis IPv6-os címmel rendelkező interfésszel [RFC1933]. Az IPv4 kompatibilis IPv6-os cím formátuma nagyon egyszerű: 96 bit 0, majd az IPv4-es cím.

Ezt a címformátumot arra definiálták, hogy egy IPv6-os csomópontot (dual stack) képes legyen valamilyen módon kihasználni az IPv6 előnyeit egy IPv4-es hálózatban. Ezt olyan módon éri el, hogy az automatikus alagút kialakításakor az IPv6-os csomópont IPv4 kompatibilis címét használja az IPv6 csomagban, majd becsomagolja egy IPv4-es csomagba. Az alagút túlsó oldalán az IPv4-es csomagolást lehántja a kommunikációs partner, hogy hozzá jusson az IPv6-os címhez. Ezt a módszert alkalmazva az IPv6-os csomópont tulajdonképpen feltérképezheti az IPv4-es hálózatot. Alapvetően két esetben használható: hoszt-hoszt és router-hoszt viszonylatban.

4-5 ábra: Automatikus tunnel a hoszt-hoszt között

4-6 ábra: Automatikus tunnel a router-host között

Az ilyen módon történő áttérésnél nincsen mód kihasználni a 128 bites címeket, hiszen 32 bites IPv4-es címeket kell használni, de ki lehet használni az IPv6 minden egyéb lehetséges előnyeit, mint például a flow mező, hitelesítés, titkosítás, multicast vagy anycast. Ha ilyen módon egy csomópontot migráltunk, akkor nyitva áll a kapu arra, hogy fájdalommentesen áttérjünk a teljes IPv6-os címtartomány alkalmazására. Az IPv4 kompatibilis címzési mód lehetővé teszi, hogy az adminisztrátor megtartva a már meglévő IPv4-es címzési és alhálózati struktúrát (subnet structure) kipróbálja az IPv6-ot. Az automatikus alagutak, ha szükségesek, akkor rendelkezésre állnak, de már nem lesz rájuk szükség, ha a gerinchálózaton is IPv6-ot alkalmazunk.

Előnyök:

• Nem rontja el a végpont-végpont koncepciót
• A csomag az IPv4 kompatibilis cím szerint irányítódik, megtartva az eredeti subnet struktúrát.
• Az alagút csomagból a kibontás csak a végponton történik meg. Az útvonalválasztó nem kezeli külön az ilyen csomagokat, azaz nem jár teljesítményveszteséggel a router részéről az ilyen csomagok továbbítása.
• Ki lehet használni az IPv6 bizonyos előnyeit.

Hátrányok:

• IPv4-es hálózatot igényel.
• Csak izolált dual-stack hosztok összekapcsolására használható.
• Nem képes használni az IPv6-os címeket.
• Az alagút csomagok többlet terhelést jelentenek az egész hálózatra.
• Az MTU kezelés bonyolult lehet, hiszen az alagútban szükség lehet a csomag tördelésére, tehát nem szabad tunnel végpontokon a "do not fragment" bitet beállítani
• Az IPv6 multicasting csak külön IPv6 multicasting routinggal valósítható meg, mivel a tunnelek nem biztos, hogy követik a multicasting topológiát
• Az IPv6-os útvonalválasztási táblába bekerülő IPv4 kompatibilis IPv6-os címek, továbbítják a IPv4 útvonalválasztás problémáját az IPv6-ba akár 5-szörösére is duzzasztva azt.
• Bizonyos esetekben aszimetrikus lehet az útvonalválasztás.

4.3.2.5. Konfigurált tunneling

A konfigurált alagutat [RFC1933] arra lehet használni, hogy csomagokat továbbítsunk csomópontok között, melyek nem rendelkeznek IPv4 kompatibilis IPv6 címmel, azaz két vagy több IPv6-s hálózatot lehet velük összekötni. A konfiguráltság lényege, hogy az adminisztrátor az alagút végpontján definiálja az IPv6-IPv4 leképezést. A tunnelen kívül a 128 bites IPv6-os címeket lehet használni. Másik IPv6-os hálózathoz való eléréshez az alagút végpontját megvalósító csomóponton egy manuálisan konfigurált router tábla bejegyzést is kell definiálni, hogy milyen IPv4-es címet kell alkalmazni a becsomagoló IPv4-es csomag célcímeként, hogy átjusson a csomag az alagúton.

4-7 ábra: Konfigurált tunnel a router-router között

Amint látható, ez elég nagy mérvű adminisztrációt igényel az alagutak (tunnelek) végpontjain, de a forgalom az IPv4-es topológiának megfelelően irányítódik, anélkül, hogy szükség volna további konfigurációra.

A dual stack módszer, kombinálva a konfigurált tunnellel bizonyítottan egy jó megoldás, hiszen lehetővé teszi az IPv6-os és IPv4-es csomópontok egymás melletti alkalmazását mindaddig, míg rendelkezésre áll IPv4-es cím. Megvédi azokat a beruházásokat, melyeket a Interneten megtettek, és lehetővé teszi, hogy mindenki a saját ritmusának megfelelően térjen át. Ezt mutatja a 6Bone sikere is, mely hosszú idő óta folyamatosan növekszik [6bone].

Előnyök:

• Nem rombolja le a végpont-végpont koncepciót
• Sikerességét a 6bone bizonyította
• Izolált IPv6 hálózatok összeköthetőek vele

Hátrányok:

• Nehezen konfigurálható.
• Minden IPv6 hálózathoz újabb és újabb tunnelt kell manuálisan konfigurálni, ha csak IPv4 hálózat létezik a két hálózat között.
• IPv4-es infrastruktúra szükséges hozzá.
• A becsomagolás megnöveli indirekt módon a hálózat terhelését
• Az MTU kezelés bonyolult lehet, hiszen az alagútban szükség lehet a csomag tördelésére, tehát nem szabad tunnel végpontokon a "do not fragment" bitet beállítani
• Az IPv6 multicasting csak külön IPv6 multicasting routinggal valósítható meg, mivel a tunnelek nem biztos, hogy követik a multicasting topológiát.

4.3.2.6. 6to4

A komplex tunnel menedzsment elkerülésére találták ki a 6to4 áttérési módszert [6to4]. A módszer lényege, hogy egy speciális routing prefix-en keresztül az IP6-os site hirdeti az IPv4-es tunnel végpontjának a címét. Ilyen módon, ha egy IPv6-os site egy másikhoz akar csatlakozni, akkor ezt egyszerűen a Domain Name System segítségével teheti meg, hiszen ezen routing prefix ismeretében a távoli site felé kialakítható a tunnel. Ez a tunnel csak átmenetileg áll fenn, mivel állapot nem tartozhat hozzá, csak addig létezik, míg az adott tranzakció használja az adott tunnelt. 6to4 segítségével nem szükséges kialakítani egy IPv6 routing magot, mint például a 6bone.

4-8 ábra: 6to4 áttekintő ábra

Egy 48 bites globálisan aggregálható routing prefix lehetővé teszi a fenti módszer alkalmazását, hiszen elegendő hely áll rendelkezésre ahhoz, hogy tartalmazza 32 bites IPv4-es címet is és meg lehessen különböztetni a többi globálisan aggregálható, de adminisztratíve definiált címtartományoktól. Továbbá ezzel a választással kompatibilis marad a globálisan aggregálható címtartományokkal, hiszen a site-level-id-nek fenntartott 16 bit még rendelkezésre áll [IRALLOC][6PAPA].

Ezt a 6to4 prefixet ugyanúgy lehet és kell használni mint más IPv6-os prefixet, egyedüli nehézség akkor merül fel, ha több IPv6-os prefixe van egy hálózatnak, hogy melyik prefixet mikor kell használni. Ezt néhány egyszerű esetben a következőkben foglalhatjuk össze. A legegyszerűbb eset az, ha a több site egyszerre alkalmaz 6to4 tunneling technikát az IPv4 mellett (fölött), azonban nincsen IPv6-os infrastruktúrájuk. Természetesen minden site-nak egy dual stack routerrel kell rendelkeznie és a 6to4 tunnel végpontokat ezen routerek IPv4-es címei fogják meghatározni (feltételezhető, hogy ezt a routert minden IPv6-os hoszt eltudja érni a site-on belülről). Az 6to4 routing prefixet a routerek hirdetni fogják a saját site-jukon belül és a prefix meg kell, hogy jelenjen a DNS bejegyzések között. Ezek alapján a küldő csomópont megtalálhatja a 6to4 prefix-et és a routeren keresztül el tudja érni a célállomást. Ehhez a routernek a következőképpen kell működnie. Ha az IPv6-os csomagot nem helyileg kell továbbítani és az a speciális 2002::/16 6to4 prefix-et tartalmazza, akkor a IPv6-os csomagot a cél 6to4 prefix-nek megfelelő IPv4-es célcímű csomagba kell csomagolni 41-es azonosítójú csomag típussal [RFC1933]. A forrás IPv4 cím a küldő 6to4 prefix-éből származik (ez a 6to4-IPv6 relay miatt szükséges). A vevő oldalon nem szükséges semmilyen módosítás, mivel az már definiált az alapvető áttérési mechanizmusok között [RFC1933]. További érdekessége a megoldásnak, hogy nem szükséges autonom rendszerek közötti avagy exterior IPv6 routing protokollokat működtetni, hiszen az IPv4-es routing protokollok (pl. BGP4) elégségesek lehetnek a site-ok összekapcsolásához [RFC2283].

Komplexebb a helyzet, ha egyes site-ok IPv6-os kapcsolattal is rendelkeznek a 6to4 kapcsolat mellett. Amennyiben a küldő site rendelkezik IPv6-os és 6to4 prefix-el, és cél site csak 6to4 címmel rendelkezik, akkor egyértelműen a 6to4 címet kell választani a forrás címként (ennek megfelelően kell működnie a csomópontok forrás címválasztó mechanizmusának), hogy tudjon kommunikálni a partnerével. Ha a küldő csak 6to4 címmel rendelkezik, és a cél 6to4 és valódi IPv6-os címmel is, akkor szinte semmilyen követelmény nincs, hiszen a programok többsége úgy van megírva, ha több célcímmel is rendelkezik az állomás, akkor végig próbálják a címeket, és amelyiken létrejön a kommunikáció azt használják. Ebben az esetben természetesen szerencsésebb, hogyha az automatikusan a 6to4 címet preferálja hiszen ilyenkor próbálkozás nélkül is létrejöhet a kommunikáció. Ha a kommunikáló felek mindegyike valódi IPv6-os címmel is rendelkezik, akkor azt kell választani az 6to4 prefix helyett, hiszen így elkerülhető a tunnelezés miatti overhead [SCOPED_COMM]. A legkomplexebb eset, ha egy csak IPv6-os site és egy csak 6to4 prefix-el rendelkező site akar kommunikálni egymással. Ehhez egy 6to4 relay-re van szükség amely 6to4 és valódi IPv6-s kapcsolattal is rendelkezik (ami tulajdonképpen egy 6to4-t támogató IPv4/IP6 dual stack útvonalválasztó). Az ezen konfiguráció lényege, hogy a 6to4 relay a valódi IPv6 infrastruktúra számára meghirdeti 2002::/16-os prefixet, és a valódi IPv6-os hálózatokon pedig szűrésre kerül a 2002::/16 -osnál hosszabb prefixű útvonal hirdetés. A 6to4 hálózat felé pedig a 6to4 relay az valódi IPv6-os prefixeket hirdeti. Természetesen több 6to4 relay is müködhet, sőt ajánlott is, hogy működjön, mivel 6to4 relay feladata a IPv6-os csomagok IPv4 csomagba történő becsomagolása, illetve kicsomagolása, ami erőteljes terhelést jelenthet.

Az IPv6 spoofing (címlopás) elkerülésére legalább egy hihetőség vagy hitelesség ellenörzésre szükség van, hogy a csomag ténylegesen érkezhetett-e onnan, ahonnan IPv4 tunnel állítja. Azaz a 6to4 címe és IP4 tunnel forrás végpontjának a címe megegyezik-e. Ez az ellenőrzés 6to4 relay esetén nem tehető meg, ezért ott másfajta csomagszűrésre van szükség. Természetesen az olyan V4ADDR-al rendelkező 6to4 címek eldobhatóak, melyek broadcast, multicast, subnet broadcast vagy privát IPv4 címet jelölnek [6to4][TRANSITION_ABUSE].

Előnyök:

• Nem rombolja le a végpont-végpont koncepciót a hálózatban.
• Nem szükséges az IPv4 kompatibilis IPv6 címek használata.
• Nem kell kézzel minden tunnelt bekonfigurálni.
• Együtt tud működni más módszerekkel is mint például NAT, NAT-PT.
• Kompatibilis az IPv6 anycast-al.
• Nem növeli sem az IPv6, sem az IPv4 routing tábla méretét.

Hátrányok:

• A tunnel alkalmazása növeli a hálózat terheltségét
• A végpontoknak helyesen kell implementálniuk a forrás és cél cím választási mechanizmust.
• Az MTU kezelés bonyolult lehet, hiszen az alagútban szükség lehet a csomag tördelésére, tehát nem szabad tunnel végpontokon a "do not fragment" bitet beállítani
• Az IPv6 multicasting csak külön IPv6 multicasting routing-al valósítható meg, mivel a tunnelek nem biztos, hogy követik a multicasting topológiát
• Figyelemmel kell lenni, hogy a 6to4 prefix ne kerüljön hirdetésre a IPv6 útvonalválasztási infrastruktúrában.
• Nem müködik privát IPv4 címmel egy NAT mögött.

4.3.2.7. IPv6-os csomagok továbbítása IPv4 fölött explicit alagutak (tunnelek) nélkül (6over4)

A 6over4 módszer [RFC2529] célja, hogy izolált hosztokat kössön össze IPv4-be csomagolt IPv6 csomagokkal egy site-on belül annélkül, hogy alagutakat kéne kialakítani. Erre a célra egy virtuális linket definiál, amelyhez egy site (vagy intézmény) hatáskörű (scope) multicast cím tartozik. A módszer lényege, hogy az IPv6 multicast címeket leképezik a 6over4 technológiát ismerő hosztok ezekre az IPv4-es címekre, ami segítségével az IPv6-os csomópontontok a Szomszéd felderítési (Neighbor discovry) algoritmusa működni képes, és úgy tekintik az IPv4-es hálózatot, mint egy virtuális hordozó hálózat (link layer). Router esetén legelább az egyik belső interfészét a routernek 6over4 működésre kell konfigurálni.

Előnyök:

• Nem rombolja le a végpont-végpont koncepciót a hálózatban.
• Nem szükséges az IPv4 kompatibilis IPv6 címek használata.
• Nem kell kézzel minden tunnelt bekonfigurálni.
• Együtt tud működni más módszerekkel is, mint például NAT, NAT-PT.
• Kompatibilis az IPv6 anycast-al.

Hátrányok:

• A tunnel alkalmazása növeli a hálózat terheltségét
• A végpontoknak helyesen kell implementálniuk a forrás és cél cím választási mechanizmust.
• Az MTU kezelés bonyolult lehet, hiszen az alagútban szükség lehet a csomag tördelésére, tehát nem szabad tunnel végpontokon a "do not fragment" bitet beállítani
• Müködnie kell az IPv4 multicastingnak a hálózatban és a alagutak biztos, hogy követik a multicasting topológiát

4.3.2.8. Tunnel broker

A jelenlegi globális IPv6 Internet manapság tunnelek segítségével épül fel, támaszkodva a meglévő IPv4-es infrastruktúrára [6BONE]. Sajnos azonban ezeket a tunneleket konfigurálni menedzselni meglehetősen nehéz. A tunnelek menedzselése Internet szolgáltatóknak (ISP), hálózati szolgáltatóknak (Network provider) nem kis feladat, de a működő 6Bone jó példa arra, hogy megoldható. Azonban a végfelhasználóknak az alagútak konfigurálása, menedzsmentje nem könnyű feladat, hiszen az ismereteik az IPv6-os világról, még csak most alakulnak ki, és nem olyan kiterjedtek, mint az IPv4-es Internetről. A végfelhasználókat, akik egy vagy néhány dualstackes IPv6-os hosztot szeretnének üzemeltetni kísérleti jellegel (pl. dial up felhasználó), az áttérési módszerek nem támogatják túlságosan. Az automatikus tuneling egy jó megoldás lehet, de csak viszonylag szűk keretek közt használható. További hátránya, hogy az IPv6-os útvonalválasztási táblába bekerülő IPv4 kompatibilis IPv6-os címek továbbítják a IPv4 útvonalválasztás problémáját az IPv6-ba akár 5-szörösére is duzzasztva azt. A többi eljárás (6to4, 6over4, AIIH) elsősorban site-ok, IPv6-os domain-ek összekapcsolására koncentrál.

A tunnel broker [TUNNEL_BROKER] lényege, hogy egy dedikált szerver működik a szolgáltatónál (Tunnel Broker Server), ami automatikusan felépíti a felhasználótól érkező tunnel kéréseknek megfelelő tunnelt és menedzseli azt. A tunnel broker tulajdonképpen egy virtuális IPv6 ISP-nek tekinthető. A felhasználó ezen tunnel brokerek közül kiválasztják a valamilyen algoritmus alapján a legkedvezőbbet (legolcsóbb, legközelebbi stb.).

4-9 ábra: Tunnel broker áttekintő ábra

A tunnel broker feladata, hogy amint a felhasználó regisztrálta és aktiválta a tunnelt, akkor létrehozza, módosítsa, esetleg törölje a tunnelt a felhasználó helyett. A regisztrácó során a felhasználónak valamiyen módon azonosítania kell magát (pl. Radius protokoll) [RADIUS], és meg kell adnia legalább a tunnel saját oldali IPv4-es címét, a regisztrálni kívánt nevet, és hogy routert vagy hosztot kíván üzemeltetni (ennek megfelelő hosszúsági IPv6 prefix (128bit, 64 bit vagy 48 bit) foglalódik le). A létrehozáskor a tunnel broker bejegyezteti a kívánt alagutat az egyik tunnel szerverben. Természetesen több tunnel szerver lehet, így jobban skálázható a rendszer. A tunnel broker feladata ezenkívül a DNS bejegyzés elkészítése is a IPv6 felhasználó számára. A tunnel broker IPv4-en mindenképpen elérhető kell, hogy legyen, és opcionálisan IPv6-on is elérhető lehet. A tunnel broker a felhasználó számára legegyszerübben egy-egy scriptet biztosíthat a kliens oldali tunnel kofigurálására és lebontására. Alternativaként jelöli meg ( a script biztonsági problémáinak kiküszöbölésére) a jelenlegi draft [TUNNEL_BROKER] egy új MIME type (pl. application/tunnel) alkalmazását, bár ez csak akkor alkalmazható, ha a kliens és a tunnel broker szerver HTTP-n kommunikál egymással. Ehhez természetesen egy HTTP szervert is kell üzemeltetni. A regisztrált felhasználók adatait egy adatbázisban célszerű tárolni, hogy ne kelljen újra regisztrálniuk magukat, ha újra használni kívánják a tunnel broker szolgáltatását. A tunnelt nem csak kiépíteni kell, hanem esetleg megszüntetni. A megszüntetés hozzákapcsolható ahhoz az eseményhez, amikor az dial-up felhasználó megszünteti kapcsolatot, vagy visszaadja a szolgáltatónak DHCP szerverének a kiosztott IPv4-es címét.

Előnyök:

• Nem rontja el a végpont-végpont modellt
• Felhasználó azonosítás
• A konfigurált tunnel élettartama jól kézben tartható
• Jól alkalmazható a tunnel broker koncepció más tunnelezési megoldásoknál is (pl. Multicast tunnel [MBONE], IPSec tunnel [RFC2406] stb.)

Hátrányok:

• IPv4-es infrastruktúra szükséges hozzá.
• Nem működik privát IPv4-es címmel egy NAT mögött.
• A becsomagolás megnöveli indirekt módon a hálózat terhelését
• Az MTU kezelés bonyolult lehet, hiszen az alagútban szükség lehet a csomag tördelésére, tehát nem szabad tunnel végpontokon a "do not fragment" bitet beállítani
• Az IPv6 multicasting csak külön IPv6 multicasting routing-al valósítható meg, mivel a tunnelek nem biztos, hogy követik a multicasting topológiát
• Veszélyes lehet a tunnel broker által szolgáltatott script végrehajtása

4.3.2.9. Dinamikus tunneling (DTI)

A dinamikus tunneling [DTI][DSTM] lényege, hogy az IPv4-es csomagok IPv6 -os csomagokba kerülnek becsomagolásra. Ennek az a célja, hogy az áttérés utolsó szakaszában már ne kelljen fenntartani IPv4-es útvonalválasztási infrastruktúrát. Ezt a módszert használva a routerekben nem szükséges egyszerre az IPv4-es és IPv6-os útvonalválasztási tábla.

4-10 ábra: Dinamikus Tunneling (DTI) áttekintő ábra

A DTI-t több helyen lehet alkalmazni: a küldő állomáson, cél állomáson, útvonal választókon, illetve specializált DTI berendezéseken. Ha routeren kerül alkalmazásra, akkor a site teljes forgalma át kell, hogy haladjon a DTI routeren.

Előnyök:

• Nem rombolja le a végpont-végpont koncepcióját a hálózatnak
• Nincsen szükség IPv6 infrastruktúrára.
• Leegyszerűsíti a belső IPv4 címzési struktúrát.
• Jól alkalmazható, ha már alig van IPv4-es infrastruktúra.

Hátrányok:

• Nehéz implementálni, ha csak nem az összes IPv4-es berendezés egyetlen hálózati szegmensen helyezkedik el.
• A becsomagolás növeli a hálózat terheltségét.

Jelenleg az AIIH és a DTI módszer egyesítésén dolgoznak az IETF ngtrans munkacsoportjában. Logikus lépésnek tűnik, mivel mindkét eljárás a DHCP-t használja, mint konfigurációs eszközt. Az egyesített ajánlásnak a címe a dinamikus dual-stack metódus lesz (DSTM) [DSTM].

4.3.2.10. Transzlációs megoldások

Az eddig tárgyalt áttérési megoldások nem alkalmasak arra, hogy csak IPv6-ot beszélő csomópont kommunikáljon csak IPv4-et beszélő csomópontokkal. Ennek a problémának a megoldási igényével születtek a különböző transzlációs megoldások, melyek a translators_draft [IPV6_TRANSLATORS] szerint nem alkalmasak hosszabbtávú megoldásra, mivel több hátrányos tulajdonságuk nem teszi lehetővé ezt. Ezenkívül csak bizonyos elszigetelt esetekben használhatóak jól, amelyek a következőkben láthatóak. A transzlációs megoldások lényege a címek valamilyen leképzése, melyet a Domain Name Systemel szinkronban kell működtetni.

4-11 ábra: Transzlátorok áttekintése

Translator A

Az áttérés korai szakaszában használható arra, hogy egy IPv6 csomópont egy IPv6-os szigeten kommunikáljon egy IPv4-es csomóponttal az IPv4-es oceánban.

A lehetséges implementáció lényege, hogy a globális IPv4 címet statikusan leképezzük egy globális IPv6-os címre. Az erre célra rendelkezésre álló címtartomány része lehet a IPv6 site részére globálisan kiosztott IPv6-os címtartománynak. A DNS cache-ekben nem jelentkezik probléma, mivel egyértelmű a leképzés. Az implementáció viszonylag egyszerű, mivel csak egy előre definiált IPv6 prefixbe kell beágyazni a IPv4-es címet.

Translator B

Az áttérés korai szakaszában használható, hogy egy IPv4-es csomópont az IPv4-es óceánban kommunikáljon egy IPv6-os csomóponttal egy IPv6-os szigeten.

A lehetséges implementáció lényege, hogy a globális IPv6 címet dinamikusan leképezzük egy globális IPv4-os címre. Az erre célra rendelkezésre álló címtartomány része lehet a IPv6 site részére globálisan IPv4-es címtartománynak. A DNS cache-ekben probléma merülhet fel, mivel nem egyértelmű a leképzés. Ez a DNS cache probléma azonban ki kerül az Internetre is. Az implementáció nagyon bonyolult, mivel bizonyos csomópontokra statikusan kell a leképzést megoldani (IPv6-os szerverek), míg másoknál muszáj dinamikusan megoldani címhozzárendelést, mivel nagy valószínűséggel nem áll rendelkezésre elegendő IPv4-es cím.

Translator C

Az áttérés késői szakaszában használható, hogy egy IPv4 csomópont egy IPv4-os szigeten kommunikáljon egy IPv6-es csomóponttal az IPv6-es óceánban.

A lehetséges implementáció lényege, hogy a globális IPv6 címet dinamikusan leképezzük egy privát IPv4-os címre. Az erre célra rendelkezésre álló címtartomány része lehet bármelyik privát IPv4-es címtartománynak (cite private IPv4). A DNS cache-ekben probléma merülhet fel, mivel nem egyértelmű a leképzés, azonban ez a probléma csak a site-on belül alakul ki. Az implementáció közepesen nehéz, mivel UDP alkalmazások nem képesek megmondani a kommunikáció végét, így valamilyen időzítő alkalmazása szükséges. Hasonlóan problematikus lehet azon alkalmazások használata is, melyek valamilyen okból cache-elik a DNS bejegyzéseket.

Translator D

Az áttérés késői szakaszában használható, hogy egy IPv6-es csomópont az IPv6-es óceánban kommunikáljon egy IPv4-os csomóponttal egy IPv4-os szigeten.

A lehetséges implementáció lényege, hogy a globális IPv4 címet statikusan leképezzük egy globális IPv6-os címre. Az erre célra rendelkezésre álló címtartomány része lehet a IPv6 site részére globálisan kiosztott IPv6-os címtartománynak. A DNS cache-ekben nem jelentkezik probléma, mivel egyértelmű a leképzés. Az implementáció viszonylag egyszerű, mivel csak egy előre definiált IPv6 prefixbe kell beágyazni a IPv4-es címet.

Előnyök:

• Viszonylag olcsó lehet az alkalmazásuk
• Hatékony lehet az alkalmazásuk, ha csak néhány külső kapcsolatot kell kezelni.

Hátrányok:

• Megsérti a végpont-végpont koncepciót, így nem lehetséges végpont-végpont QoS, illetve végpont-végpont biztonságot alkalmazni. A transzlátor a biztonságot veszélyeztető pont lehet a rendszerben.
• Koncentrált meghibásodási pont. Minden transzlálásra kerülő forgalomnak keresztül kell haladnia a transzlátoron, ami, ha meghibásodik, a kommunikációt megakadályozhatja.
• Szűkkeresztmetszet lehetősége. Minden transzlálásra kerülő forgalomnak keresztül kell haladnia a transzlátoron, ami szűkkeresztmetszetet jelenthet, ha nagy a forgalom, hiszen minden csomagot (legalább fejrészét) fel kell dolgozni.

Három alapvető transzlátor implementáció létezik manapság:

1. Alkalmazás szintű gateway
2. Transport Relay Translator, illetve SOCKSv64
3. Header konverter

4.3.2.11. Alkalmazás szintű gateway (ALG)

Az alkalmazás szintű gateway [ALG] lényege, hogy teljes protokoll konverzióra sor kerül. Ilyen módon általában nincsen szükség a végpontokon semmilyen módosításra. Az ALG alapvetően a két inkompatibilis hálózat között helyezkedik el és rendelkezik mindkét protokoll stackkel és teljes protokoll konverziót végez. Sajnos, illetve bizonyos esetben jó, hogy bizonyos funkciók elvesznek, mivel nem lehet a két protokollt teljesen konvertálni. Alkalmazás szintű tűzfalaknál (proxy) [Firewall] ez általában előny, mivel jobban kézben tarthatóak így a protokollok, illetve a kommunikáció. Sajnos azonban, ha gateway nem elég hatékony, akkor komoly korlátozó tényező és szűkkeresztmetszet lehet.

4-12 ábra: Proxy áttekintése

Ezt a transzlációs megoldást több különböző proxy-val meg lehet oldani. A követelmény csak az, hogy a proxy tudjon IPv4-en és IPv6-on is beszélni.

Előnyök:

• Megold minden transzlációs problémát, amely más transzlációs megoldásoknál jelentkezik.

Hátrányok:

• A transzláció lassú lehet, ami szűkkeresztmetszetet jelenthet.

4.3.2.12. Transport Relay Translator (TRT) [TRT] és SOCKS64 [SOCKS64]

A Transport Relay Translator egy olyan mechanizmus, amit szervereken lehet implementálni. Elfogja a TCP-UDP/IPv6 csomagokat és továbbítja az aktuális célpont felé TCP-UDP/IPv4 felett, és vissza ugyanígy. Ha egy kapcsolat kialakult, akkor az összes adat a relay szerveren keresztül kerül továbbításra. A SOCKS64-t vagy FAITH [KAME_FAITH] tekinthető implementációnak. Ez a módszer megoldja a tördelés, illetve az ICMP problémáját, mivel a kapcsolatnak behatárolható a végpontja. Probléma merülhet azonban azoknál az alkalmazásoknál, melyek protokollja beépítve tartalmazza a végpont címet (pl. ftp). A TRT csak abban az esetben használható, ha az IPv6-os állomás kezdeményezi a kapcsolatot, mivel így a cím leképezés egyszerűen megoldható (Translator A, Translator D). A TRT lényege, hogy egy speciális DNS segítségével az IPv4-es címek helyett (A record) a DNS egy IPv6-os (AAAA vagy A6) címet szolgáltat, mely egy speciális prefixel rendelkezik és tartalmazza az IPv4-es címet. Ez a prefix pedig a TRT csomóponthoz, vagy a TRT csomópontok anycast címére van irányítva [TOTD][NEWBIE].

4-13 ábra: Transzport Relay Transzlátor áttekintése

Előnyök:

• Nincsen probléma a tördeléssel és ICMP csomagokkal, mivel a kapcsolatnak van végpontja.
• TRT esetén nincs szükség a kapcsolatot kezdeményező IPv6-os csomópont módosítására.

Hátrányok:

• A végponti alkalmazásokat, vagy az operációs rendszert módosítani kell, hogy támogassa a TCP relayt (TRT esetén nem feltétlenül).
• Csak TCP kapcsolatokat lehet relézni (TRT esetén UDP-t is lehet).
• Probléma a beágyazott címet használó alkalmazások esetén [NAT_friendly].
• Csak unicast (két irányú) forgalmat támogat, multicast forgalmat nem.
• TRT nem skálázható úgy, mint SIIT, mivel állapotot kell fenntartani a TRT transzlátorokban.

4.3.2.13. Header konverter

A header konverter [HEADER_KONVERTER] a NAT-hoz (Hálózati cím translatorhoz) hasonlóan működik, de attól eltérően az egész fejlécet konvertálni próbálja IPv4 és IPv6 között. Az ilyen típusú eszközök a fejléc ellenőrző összegét is újra számolják. Header konvertert akkor érdemes használni, ha A vagy D típusú transzlációra van szükség.

Előnyök:

• Viszonylag egyszerű implementálni. Egyetlen eszköz elég lehet a hálózathatár pontján. Viszonylag kevés konfiguráció szükséges.
• Gyorsabb, mint az egyéb transzlátorok

Hátrányok:

• Nem transzlálja a beágyazott IP címeket pl. FTP, DNS, mivel nem vizsgálja a csomagok tartalmát csak a fejlécét. Ilyen módon bizonyos alkalmazások hibásan működhetnek.
• Különböző méretű IPv4 és IPv6 fejlécek miatt nem biztos, hogy tördelés nélkül megoldható a transzláció, azonban az IPv6-ban nincs lehetőség közbenső csomópontokon a tördelésre, így a teljes kommunikáció meghiúsulhat.
• Az ICMP és az ICMPv6 nem képezhető le egymásra maradéktalanul.

4.3.2.14. Network address translator (NAT)

Ezt az eszközt évek óta használják az IPv4-es hálózatokon azért, hogy privát IP hálózatokat kössenek össze a globális Internet hálózattal. Azért van szükség erre az eszközre, mert privát IP hálózatokban privát IP címeket [RFC1918][RFC2685] használnak, melyeket nem lehet használni az Interneten. Az ilyen címfordítók egy előre definiált globálisan használható IPv4 cím tartományt használnak arra, hogy minden privát címet, amely elhagyja a hálózatot lecseréljenek ebből a globális tartományból egy címre. Ilyen módon a privát hálózat tetszőleges belső hierarchiát és subnetelést valósíthat meg az Internet számára láthatatlan módon. Nagyon nagy hátránya módszernek, hogy minden egyes csomagot, amely elhagyja a privát hálózatot transzlálni kell. Ilyen módon a NAT nem lehet olyan hatékony, mint egy útvonal választó, ugyanakkor megtakaríthatunk vele IPv4-es címeket. Az a kérdés milyen áron. A végpont-végpont koncepciót is tönkre teszi, valamint nem működik olyan protokolloknál, melyek beágyaznak IP címeket pl.: FTP, WINS, DNS stb. A NAT koncepció továbbfejlesztésének tekinthető a NAT-PT (Network Address Translator + Protocol Translator) áttérési módszer [CARPENTER_TALK].

4.3.2.15. Network address translator - Protocol Translator (NAT-PT)

A NAT-PT [RFC2766] elnevezés oka, hogy az SIIT-hez hasonlóan itt is azonos szintü protokollok transzlációjára van szükség. Nevezetesen az IPv4 és IPv6 csomagok közöti transzlációra. A NAT-PT alkalmazásakor dinamikusan hozzárendelődik egy IPv4 cím minden IPv6 szigetet elhagyó azonos célpont fele tartó csomaghoz. Ezt a csomagot hívják a NAT-PT-ben viszony kezdeményező csomagnak (Session initiation packet). A hozzárendelt IPv4-es címet használja az NAT-PT transzlátor arra, hogy a lecserélje az eredeti IPv6-os címet, és végponti alkalmazás számára átlátszó módon továbbítsa az IPv4-es cél felé. Az onnan visszaérkező válaszban hasonlóan lecserélje az eredeti IPv6-os címre a csomagfejlécében az IPv4-es címet. A NAT-PT lényege, hogy nincsen szükség semmilyen végpont alkalmazásbeli változtatásra. Ehhez azonban szükség van arra, hogy a NAT-PT eszköz folyamatosan monitorozza a használt és használaton kívüli globális IPv4 címeket, mivel nincsen a TCP/IP modellben az OSI modellhez hasonló viszony szint, mely lehetővé tenné az globális IPv4-es címek felszabadítását. TCP kapcsolatok esetén lehetséges ez a monitorozás a TCP háromutas kézfogásos kapcsolat kiépítésének és a TCP kapcsolat bontásának monitorozásával. UDP esetén valamilyen heurisztikus módszereket kell alkalmazni a NAT-hoz hasonlóan. A helyes működéshez az is szükséges, hogy minden kimenő kapcsolat egy NAT-PT routeren vagy együttműködő NAT-PT routereken haladjon keresztül. A teljes átlátszósághoz szükség van továbbá arra is, hogy bizonyos protokollok, melyek beágyazott IP címet tartalmazhatnak, magasabb szinten kerüljenek fordításra. Erre utalhat az ALG kiterjesztés is.

4-14 ábra: NAT-PT áttekintése

További problémát jelenthet, hogy az IPv4 cím pool kifogyhat sok kapcsolat esetén, így további kapcsolat kialakítására nincsen mód. Ennek kiküszöbölésére alkalmazzák a NAPT-PT (Network Address Port Translator + Protocol Translator) megoldást, ahol a port számokat is bevonják a transzlációba, így 1 IPv4 címhez 63000 kapcsolat tartozhat. Ennek negatív hatása, hogy lefoglalt portok (pl HTTP port 80) csak egyszer oszthatóak ki.

Előnyök:

• Transzparensre lett tervezve.
• Nincs szükség dual stack csomópontokra.
• Egyszerűbb a címek adminisztrációja
• Skálázható, mivel nincs szükség minden csomópontnak IPv4-es címre

Hátrányok:

• A hiba lehetősége egyetlen pontban koncentrálódik, így nem skálázható nagy hálózatokra.
• Szűkkeresztmetszet lehet a NAT-PT transzlátor.
• Mint minden transzlációs megoldás, a végpont-végpont koncepciót lerombolja.
• Szükség van ALG-re is a transzlátoron.

4.3.2.16. Állapotmentes IP/ICMP translator (Stateless IP/ICMP Translator (SIIT))

A SIIT [RFC2765] ajánlás célja, mint minden transzlációs megoldásé, hogy csak IPv6-os és csak IPv4-es csomópontok kommunikációját megoldja. Alapvetően két esetben használható az SIIT:

1. Teljesen új hálózat, ahol minden eszköz támogatja az IPv6 kommunikációt. Ilyenkor a külső IPv4-es Internettel történő kommunikációt kell megoldani.
2. Egy már létező hálózat eszközeinek többsége támogatja az IPv6 kommunikációt. Ebben az esetben a külső komunikáció mellett a kevés rendelkezésre álló IPv4 címet is el kell osztani.

Ez az ajánlás nem törődik azzal, hogy hogyan kell az IPv6-os állomásokhoz IPv4-es címeket rendelni, hanem feltételezi, hogy ez valahogy megtörténik, hogy ezek az állomások tudjanak kommunikálni az IPv4-es csomópontokkal. Ezt figyelembe véve a SIIT célja, hogy felsőbb protokolloktól függetlenül, állapotmentesen (ne kelljen állapotot nyilvántartani a transzlátorban), a lehető legnagyobb hűséggel fordítsa le a IPv4-es csomagokat IPv6-ra, és vissza. Egy ilyen SIIT eszközt elsősorban egy útvonalválasztóban lehet jól használni, mely egy site határán helyezkedik el.

A hosztokon, sajnos módosításokat kell tenni a hálózati rétegben. Amennyiben az alkalmazás egy IPv4-es vagy mappelt IPv4-es címet akarna használni egy csak IPv6-ot beszélő eszközön, akkor normál esetben ezt a hálózati réteg megtagadná, hiszen nincsen IPv4-es interfésze. SIIT esetében viszont meg kell engedni ezt a tranzakciót, hogy a hálózati rétegben IPv6 fejléccel el lehessen látni a csomagot. Sajnos ezt minden csomóponton meg kell tenni.

Ezt a módszert ott lehet alkalmazni, ahol a site teljesen áttért IPv6-ra és nincsen semmilyen IPv4-es függősége, vagy ha van IPv4 függősége, akkor az dual-stack-el oldja meg.

4-15 ábra: SIIT áttekintése

A bejövő csomagok nem szükségképpen kell hogy egy SIIT eszközön érkezzenek be, így több SIIT eszközt is lehet párhuzamosan használni a site határoló pontjainál. Az IPv4 translated IPv6 címeket egy erre felkészített DHCP szerver osztja ki.

Ha az A csomópont kommunikálni akar a B csomóponttal, akkor DNS szervertől megkérdezi a célcímet. Amennyiben ez IPv4-es cím (A record), akkor az A csomópontnak IPv6 translated IPv4 címet kell szereznie. Ezt DHCP szervertől szerezhet, vagy használhatja az AIIH áttérési mechanizmust.

4-16 ábra: SIIT küldési mechanizmusa

Az A csomópont a B csomópontnak címzett csomagot, mely célcímként mappelt IPv4 címet, forrás címként pedig a DHCP-től, vagy AIIH DHCP szervertől kapott IPv4 translated IPv6 címet tartalmazta, az egyik SIIT eszközhöz továbbítja. Ezt legkönnyebben úgy lehet elérni, hogy az összes ::ffff:0:0:/96 című címet a legközelebbi SIIT eszközhöz, vagy a SIIT eszközök anycast címére irányítja az útvonalválasztó. A SIIT ezek után a lehető leghűségesebben megpróbálja konvertálni az IP csomag fejrészét.

Ezt olyan módon teszi meg, hogy a SIIT transzlátor lecseréli az IPv4 headert IPv6 headerre és az IP csomag adat részét nem módosítja a következő esetek kivételével:

1. A tödeletlen UDP csomag pseudo ellenörző összegét módosítani kell (ki kell újra számolni)
2. Az ICMP csomagokat le kell képezni a megfelelő ICMPv6 csomagokra

4-17 ábra: IPv4-IPv6 transzlációs mechanizmus

Nagy problémája az SIIT módszernek, hogy egy külső IPv4 állomás nem tud kapcsolatot létesíteni egy IPv6 szigeten lévő csak IPv6-ot beszélő állomással.

A SIIT módszerrel együtt használható az IPSec, legalább is az IPSec ESP módszere. Az AH nem lehetséges mivel a címek lecserélődnek útközben.

Előnyök:

• Nincsen szükség dual-stackkel rendelkező gépekre
• Egyszerűbb adminisztrálni a címeket
• Jól alkalmazható, ha nagyon sok csomópont van, és viszonylag kicsi külső forgalom és viszonylag kevés ebből is az IPv4-os forgalom.
• Kevés IPv4-es cím is elegendő lehet.
• Alternatív megoldás a D típus transzlátorra.
• Jól skálázható.

Hátrányok:

• Nem teszi lehetővé önmagában az IPv6-os csomópontok elérését IPv4-es szigetekről.
• A végpont-végpont koncepciót elrontja.
• Minden csomóponton meg kell változtatni a hálózati réteget.

4.3.2.17. Bump in the Stack (BIS)

Ennek a technikának [RFC2767] a lényege, hogy egy modul épül be a rendszerbe, mely figyeli TCP/IPv4 és halózati driver közötti kommunikációt és az IPv4-et IPv6-ra konvertálja menetközben és vissza. Ilyen módon a megörökölt IPv4-es alkalmazások úgy működhetnek, mintha IPv6-on is működnének nemcsak IPv4-en. Ez akkor lehet hasznos, ha az alkalmazások forráskódja nem áll rendelkezésre, azért hogy IPv6-ra lehessen őket alakítani. A BIS módszer feltételezi a dual-stack módszert is. Amennyiben a dual-stack és BIS is rendelkezésre áll minden csomóponton, akkor lehetséges a csak IPv4-es és csak IPv6-os csomópontok kommunikációja is.

4-18 ábra: Bump In the Stack mechanizmus struktúrája

A csomópont resolver library-jét is módosítani kell. Az alkalmazás IPv4-re vonatkozó kérése helyett egy A és egy AAAA illetve A6 kérést kell kiadnia. Amennyiben csak AAAA és A6 címe van a célcsomópontnak, akkor az address mapperttől kér egy IPv4-es címet, amit a mapper hozzá rendel az adott IPv6-os címhez. A mapper feladata kettős:

1. A resolvertől érkező kérésnek megfelelően oszt egy privát IPv4 címet és hozzá rendeli az IPv6-os címhez
2. Ha transzlátortól olyan kérés érkezik, amelyre forrás IPv6 címre nincsen még bejegyzés az address mapperben, akkor szintén hozzárendel egy még használatlan privát IPv4 címet.

4-19 ábra: Bump In the Stack küldés idődiagramja

4-20 ábra: Bump In the Stack vétel idődiagramja

Előnyök:

• Viszonylag könnyű implementálni.
• Skálázható. Az IPv4-es címeknek csak a csomóponton kell egyedinek lenniük és nem a site-on, ha csak IPv6 kommunikációra van szükség.
• Lehetővé teszi, hogy csak IPv6-ot beszélő csomópont csak IPv4-et beszélővel kommunikáljon.
• Nem kell útvonal irányítani a transzlált csomagokat, mivel a csomópontban van a transzlátor.
• Tetszőleges alkalmazás IPv6 kompatibilissé tehető.

Hátrányok:

• Beágyazott IP címet tartalmazó protokollokat nem transzlálja.
• Tördelési problémák.
• Az ICMP és az ICMPv6 jelentősen különböző.
• Elronthatja a végpont-végpont koncepciót.

4.3.3. Áttérés a programozók szemszögéből

Az IPv6-os programozói interfésze nem különbözik gyökeresen a már megszokott IPv4 programozói interfésztől, azonban tartalmaz olyan programozói interfészeket, melyek nem, körülményesen vagy "nem szabványos" módon voltak elérhetőek IPv4 esetén a hagyományos Berkeley socket interfészen keresztül. Az IPv4 esetében voltak olyan hívások, melyek csak bizonyos implementációkban működtek úgy, ahogy azt a BSD4.4. definiálja, mivel ezek a funkciók még nem léteztek akkor amikor BSD 4.2 megszületett. Az IPv6 megjelenésével lehetőség nyílt egy programozói interfész egységesítésre. Ezt az egységesítést az IETF, történetében először felvállalta és megalkotott két szabványt, amely a programozói interfész interfészét definiálja. Az RFC 2553 [RFC2553] az alapinterfészt definiálja:

1. nagyobb cím kezelését lehetővé tevő cím és adatstruktúrák
2. IPv6-IPv4 együttes működését lehetővé tevő névkezelő funkciók
3. címkonvertáló funkciók

Itt definiálták az IPv4 mappelt IPv6 címet, amit arra használ a socket programozói interfész, hogy csak IPv6-os alkalmazást kelljen írni, de ha mégis IPv4-es címre érkezne az alkalmazáshoz az üzenet, akkor a megkülönböztetés ezzel a címmel történhet.

A másik szabvány pedig kiterjesztett változatát definiálja [RFC2292bis] (hozzáférés a különböző IPv6 specifikus mezőkhöz, új funkciókhoz). Érdekes módon a kiterjesztett funkciók néhány oldalban leírhatóak [UNIXNETPRGv1] illetve a programon szükséges változtatások, egy helyesen megírt program esetében, nem több néhány napos munkánál és elég jól automatizálható [SOCKET_SCRUBBER], [MSSOCKET_CONVERTER].

4.4. Összefoglalás

Összefoglalásképpen egy táblázatba lehet leírni, hogy milyen követelményei vannak a különböző áttérési technikáknak [TRANSITION_CONCEPT].