Átmenet az IPv4-ből az IPv6-ba

Átmenet az IPv4-ből az IPv6-ba

Átmenet az IPv4-ből az IPv6-ba Tranzíciós eljárások Dual-stack strategy - kettős stack stratégia Tunneling Header translation - fejléc fordítás

Dual-stack strategy Az IPv6 felé tett első lépés olyan rendszerek telepítése, melyek támogatják az IPv6-ot. Ezek a rendszerek a kettős stack stratégián alapulnak, amely az IPv4 és IPv6 használatát is támogatja. Ezek a rendszerek IPv6-ot használnak más IPv6 rendszerekkel való kommunikációra, illetve képesek visszalépni IPv4 módba régi rendszerekkel való párbeszédhez. Annak eldöntésére, hogy melyik protokollt válasszák megkérdeznek egy DNS szervert és ellenőrzik, hogy IPv6 vagy IPv4 címmel válaszol.

Dual-stack strategy Application TCP IPv6 IPv4 Ethernet IPv6 Host IPv4 Host Dual Stack Host

Dual-stack strategy Ha már egyszer egy hoszt tudja, hogy a cél képes IPv6-t kezelni, akkor még azt is ki kell derítenie, hogy hogyan továbbítsa a csomagokat. Ha cél ugyanazon a linken található mint a forrás, akkor IPv6-ot kell használni. Ha azonban a cél más linken van, akkor a hoszt az IPv6 útvonalválasztók hirdetéseire figyel. Ha egy ilyen hírdetés megérkezik, akkor a csomagokat ehhez az útvonalválasztóhoz küldi. Ha nem érkezik, akkor a hosztnak tunnel-eken (alagutakon) kell kommunikálnia.

Tunneling IPv6 szigetek összekötése IPv4 felett Ha csomagot küldünk az egyik IPv6 rendszerből egy másik IPv6 rendszerbe, akkor ezt a két rendszert egy IPv4 rendszer elválaszthatja egymástól. Sokféle topológia lehetséges Router to router Host to router Host to host Tunneling típusok Configured tunnels Automatic tunnels Tunnel broker 6to4 6over4

Átmenet az IPv4-ből az IPv6-ba IPv4 Packet IPv6 Packet IPv4 Destination IPv6 Host IPv6 Host IPv4 Internet Token Ring

Automatic tunneling Ez a tunneling egy olyan válfaja, mely IPv4-kompatibilis IPv6-os címeket használ fel az IPv6-os csomagok IPv4-en keresztülmenő alagutakon való automatikus továbbítására. A küldő állomás (vagy router) ilyenkor a célcím mezőből állapítja meg az alagút végpontját, ezért a következő két esetben használható: Állomástól-állomásig terjedő alagút. Tipikusan ilyet használunk két, IPv4-es hálózattal összekapcsolt dual-stack-es állomás összekötésére. Ilyenkor az alagút lefedi a csomag teljes útvonalát. Routertől állomásig terjedő alagút. Ebben az esetben az alagút a csomag útvonalának utolsó szegmensét fedi le. Amikor a csomag megérkezik az IPv4 - IPv6 határra, akkor az Ipv6 csomagokat IPv4 csomagokba csomagolják be és ezeket elküldik az IPv4 cél végpontra. A vevő rendszer pedig automatikusan visszaállítja az IPv6 üzeneteket. Ez a technika nem igényel semmilyen speciális konfigurálást egyik rendszerben sem, ezért automatic tunneling-nek hívják.

Automatic tunneling Az automatikus alagutak nagy előnye a kényelem, és a minimális konfiguráció szükségessége. Technikailag úgy oldható meg a dolog, hogy minden dual stack-es állomás, amelyikhez IPv4-kompatibilis IPv6-os cím rendelhető (a stack megengedi), alkalmas az automatikus tunnelinggel csomagolt datagramok fogadására. Ilyenkor az IPv4-kompatibilis címet szükségszerűen a ki/becsomagolást végző pszeudo interfészhez rendeljük. Ez a hozzárendelés történhet teljesen automatikusan, pl. bootoláskor, a gép az IPv4-es címéből kiszámolt IPv4 kompatibilis címet a fenti interfészhez rendeli.

Automatic tunneling Fontos, hogy mind a küldő, mind a fogadó állomásnak rendelkeznie kell IPv4 kompatibilis címmel, illetve az automatikus tunnelinget végrehajtó interfésszel. Az automatikus tunnelinget kezdeményező állomások forráscímébe is IPv4-kompatibilis cím kerül, így ezeknek válaszolni is csak automatikus tunnelinggel lehetséges (ez akkor is így van, ha ugyanazon a hálózati szegmensen helyezkednek el!). küldhet datagramokat IPv4-es broadcast vagy multicast címekre, illetve a loopback címre. Egy komoly probléma merül fel ezzel kapcsolatban. Az állomás csak a saját hálózatának broadcast címeit ismeri, ezért nem dobja el azokat a csomagokat, melyek egy távoli broadcast-ra vonatkoznak.

Configured Tunneling Ha nem állnak rendelkezésre IPv4 kompatíbilis címek (pl. ha más hosztok nem ismerik az IPv6-ot), akkor az automatic tunneling nem alkalmazható. Ilyenkor configured tunneling-re van szükség. Ez az alagút végpontjának explicit konfigurálását jelenti. Valamennyi IPv6 implementáció támogatja ezt a megoldást. Az alagutak végponthainak dual-stack csomópontoknak kell lenniük. Az IPv4 cím a tunnel végpontja. Elérhető IPv4 címekre van szükség, nem lehet NAT a végpontok között!

Configured Tunneling

A két módszer kombinálása A két technika (konfigurált és automatikus tunneling) jól kiegészíti egymást, ezért célszerű a kettőt együtt használni. Az elszigetelt dual-stackes állomásokat (vagyis azokat, amelyek nem kapcsolódnak IPv6-os routerhez) úgy konfiguráljuk, hogy legyen egy előre beállított alagútjuk egy IPv6-os routerhez (tipikusan egy 6Bone routerhez), és IPv4-kompatibilis címet rendelünk hozzájuk. Ha ez az állomás ezután egy IPv4-kompatibilis célcímmel rendelkező állomással akar kommunikálni, akkor az automatikus tunnelinget használja, ha egy natív IPv6-os címmel rendelkező állomásnak akar csomagot küldeni, akkor azt az előre konfigurált alagútba küldi. Ha az utóbbi állomás válaszol, akkor azt az alagút másik végpontján elhelyezkedő routernek küldi, amelyik automatikus tunnelinggel tovább küldi az első állomásunknak.

Tunnel Broker Az IPv6-os Internet napjainkban és várhatóan a közeljövőben még főként az IPv4 feletti alagutak hálózatából áll, nagyon kevés a WAN szintű natív IPv6-os kapcsolat. Ha rendelkezünk egy natív IPv6-os szigettel és egy dual stackes routerrel, vagy akár csak egyetlen dual-stack-es állomással, és azt szeretnénk az IPv6-os Internetre kapcsolni, akkor először is fel kell venni a kapcsolatot egy olyan szervezettel, mely gateway-ként szolgálhat a 6Bone felé (ez lehet akár egy backbone router is), meg kell kérni őket, hogy routerüket konfigurálják úgy, hogy az a tőlünk induló alagút másik végpontjaként funkcionáljon, és nem utolsósorban az alagút konfigurációt saját hálózatunkon is el kell végezni. Továbbá meg kell oldani még, hogy IPv6-os csomópontjaink szerepeljenek a DNS-ben. A Tunnel Broker kitalálói ezt az egész hosszadalmas és vesződséges folyamatot igyekeztek automatizálni.

Tunnel Broker

Tunnel Broker Az ábrán a távoli gép/hálózat jelenti azt az állomást, melyet az IPv6-os Internetre szeretnénk kapcsolni (a továbbiakban egy állomásról lesz szó, melyet kliens-nek nevezek, de ez akár egy egész hálózat is lehetne). Adott tehát egy dual stack-es állomás, globálisan egyedi IPv4-es címmel, az IPv4-es Internetre kapcsolva. A Tunnel Broker egy virtuális IPv6-os Internet szolgáltató funkcióját tölti be, mely biztosítja a kliensek és a 6Bone gateway-ek (tunnel szerverek) közti kapcsolat menedzselését, illetve a klienseket bejegyzi a DNS rendszerbe. Ehhez a kliens állomáson mindössze egy Tunnel Broker kliensprogramnak kell futnia.

Tunnel Broker A központ, azaz a Tunnel Broker ezután különféle konfigurációs üzeneteket küld három irányba: a kliensek, a Tunnel Serverek és a DNS rendszer irányába. Ezekkel a konfigurációs üzenetekkel biztosítja az alagutak létrehozását, konfigurálását, lebontását, illetve regisztrálja a kliens gépet a DNS-ben. Ugyancsak a Tunnel Broker feladata egy IPv6-os cím/címtartomány (attól függően, hogy a kliens egy állomás vagy egy router) kiosztása, melyet a saját, IANA-nál bejegyzett címei közül választ (ez is azt mutatja, hogy úgy működik, mint egy ISP).

Tunnel Broker A Tunnel Broker előnye, hogy adaptívan váltogat az erőforrások között. Például egy alagút kiépítését csak akkor kezdeményezi, ha a kliens részéről igény érkezik rá, amikor már nem kell bontja a kapcsolatot, és az alagutat kiosztja másnak. Továbbá a megfelelő módszerek implementálásával hatékonyság növelhető azáltal, hogy mindig a klienshez legközelebbi, vagy a leggyorsabb kapcsolattal rendelkező szerverrel létesít kapcsolatot. Ami az egészet igazán vonzóvá teszi az az, hogy ezt a kliens felé tökéletesen átlátszó módon oldja meg, ő csak annyit érzékel, hogy van egy gyors és megbízható IPv6-os Internet kapcsolata.

Tunnel Broker Már csak arra van szükség, hogy a kliens kiépítse a kapcsolatot a Tunnel Brokerrel. Erre magától értetődő megoldás adódik, használjuk ki a jelenlegi IPv4-es Internet szolgáltatásait. A Tunnel Broker szolgáltatók egy nyilvános WWW oldalon hirdethetik magukat, ahol a majdani kliens letöltheti a megfelelő konfigurációs kliensprogramot. Itt elküldheti a megfelelő regisztrációs információkat is a Tunnel Broker felé. Miután felinstallálta és beállította a kliensprogramot, a dolog automatikusan működésbe lép. A módszer a NAT-doboz mögött helyet foglaló, lokális IP címmel konfigurált hálózat esetében nem alkalmazható.

Tunnel Broker

6to4 Az automatikus tunneling egyik nagy hátránya, hogy a célcímnek mindenképpen IPv4-kompatibilisnek kell lennie, és az alagút végpontjának meg kell egyeznie a csomag célcímével. Amennyiben tehát IPv6-os hálózatunkból egy natív IPv6-os állomást szeretnénk megszólítani, azt (a tunneling technikát alkalmazva) csak előre konfigurált tunnelekkel tehetjük meg. Ehhez tehát szükséges az, hogy a konfigurált alagút a cél IPv6-os hálózatra mutasson, vagy egy olyan IPv6-os routing infrastruktúrára, amellyel a célállomás kapcsolatban áll (tipikusan 6Bone). A 6to4 technika lehetővé teszi, hogy két olyan natív IPv6-os tartomány ( tartomány alatt akár egyetlen állomást is érthetünk) kapcsolatot létesíthessen egymással, melyek elszigeteltek bármilyen IPv6-os routing infrastruktúrától, és egymással sem állnak explicit alagút kapcsolatban.

6to4 A módszer implementálásához mindössze az IPv6-os hálózatunk címtartományát kell gondosan megválasztani és a határoló router szorul némi extra konfigurációra. A becsomagolást/kicsomagolást a határoló router végzi, a kapcsolatok kiépítéséhez tehát elegendő egyetlen IPv4-es cím az egész IPv6- os hálózatnak.

6to4 A 6to4 natív IPv6-os tartománynak a következő prefix-el kell rendelkeznie: FP 3 bit 001 TLA ID 13 bit 0x0002 RES + NLA ID 8 + 24 = 32 bit IPv4-es cím SLA ID 16 bit Interfész ID 64 bit Látható, hogy ez egy teljesen szabályos, akár globálisan is routolható IPv6-os cím. Annyi a specialitás benne, hogy a legfelsőbb szintű hálózat azonosító egy az IANA által bejegyzett érték (FP+TLA=2002/16), mely az összes 6to4 tartományt azonosítja. Ezután következik a 6to4 router IPv4-es címe, mely alapján becsomagolást végző partner kiépíti a 6to4 routerünkkel az alagút kapcsolatot.

6to4 A rendszer működése nagyon egyszerű: natív IPv6-os állomásunktól egy csomag indul, melynek 2002/16 a prefixe. Ez mondjuk a default útvonalon eljut a 6to4 routerig. A router felismeri azt, hogy ez egy 6to4 cím, és nem a saját hálózatán található. A címből kiveszi az IPv4-es címet, majd becsomagolja az IPv6-os csomagot egy IPv4-esbe, és elküldi erre az IPv4-es címre (ehhez természetesen szükséges, hogy a router szoftvere támogassa a 6to4 routolást). A fogadó dual stack-es, 6to4 router érzékeli, hogy egy IPv4-be ágyazott IPv6-os csomag érkezett az egyik interfészére (41-es protokoll mező). Ezután kicsomagolja és tovább routolja a natív IPv6-os hálózat felé.

6over4 A 6OVER4 ajánlás lényege, hogy olyan elszigetelt IPv6-os állomások, melyeknek nincs közvetlen összeköttetése egy IPv6-os routerrel, teljes értékű állomásokként működhessenek, mintha egy fizikailag is kiépített IPv6-os hálózat részei lennének. Az állomásokról feltételezzük, hogy szerves részei egy működő, Internetre kapcsolt IPv4-es infrastruktúrának. Az ötlet az, hogy az IPv6-os réteg az IPv4-es réteget adatkapcsolati rétegként használja fel. Az IPv4-es réteg tehát mint egy virtuális adatkapcsolati réteg funkcionál. Az ugyanazon az IPv4-es, multicastolásra képes hálózaton levő, 6over4-el bekonfigurált dual stack-es állomások IPv6-os szinten azt látják, hogy a többiekkel fizikai összeköttetésben állnak (holott az összeköttetés ezen a multicastolásra képes IPv4-es hálózaton keresztül valósul meg). A módszer alapfeltétele az, hogy az összekötő IPv4-es hálózat multicastolásra képes legyen.

Header translation Még a távolabbi jövőben is szükség lehet a régi IPv4 hálózatokkal való kommunikációra az IPv6 hálózatból. Ehhez a régi rendszerekben fejléc fordításra lesz szükség. Ahhoz, hogy egy IPv6 hosztról érkező, IPv4 hálózatbeli IPv4 hosztnak csomagot küldhessünk, az IPv4 hálózat útvonalválasztóinak le kell fordítani az IPv6 címet egy IPv4 címre. Ennek módja az, hogy elhagyjuk az IPv6 cím felső 96 bitjét és a maradék 32 bit adja az IPv4 címet, valamint az Ipv6 fejlécet egy IPv4 fejléccel kell helyettesíteni. A fordításhoz IPv4 mapped címeket használnak. Fordított irányban az útvonalválasztó 80 nullát és 16 egyest tesz az IPv4 cím elé, így kapjuk a 128 bites IPv6 címet.

Átmenet az IPv4-ből az IPv6-ba Az átmeneti eljárások előnyei: Fokozatos frissítés és telepítés: egyedileg lehet IPv4 hosztokat és útvonalválasztókat upgreade-elni, anélkül, hogy ezzel egyidejûleg más hosztokat és útvonalválasztókat frissítenénk. Az új IPv6 hosztok és útvonalválasztók egyesével installálhatók. Minimális frissítés függés: a hosztok IPv6 frissítéséhez elõkövetelményként csupán a DNS szervereknek kell képeseknek lenniük az IPv6 címbejegyzések kezelésére. Az útvonalválasztókkal szemben ugyanakkor nincs elõkövetelmény. Könnyû címzés: ha egy IPv4 hosztot IPv6 hoszttá frissítenek, attól még folyamatosan használhatja a meglévõ címét. Így nem kell új címet igényelnie és ezért az adminisztrátoroknak sem kell a címzési tervet módosítaniuk.

Átmenet az IPv4-ből az IPv6-ba A fokozatos frissítés lehetõvé teszi a hoszt és útvonal forgalmazók számára, hogy az IPv6-ot termékeik sorába a megfelelõ helyre integrálják. A végfelhasználók és hálózati operátorok pedig saját ütemtervük szerint telepíthetik az IPv6-ot. A migráció lépései a következõk: No D-Day! A DNS szerverek felkészítése az IPv6 címek kezelésére. A kettõs stack rendszer bevezetése (IPv4 és IPv6 egyidejû támogatása). IPv6 címek elhelyezése a frissített rendszerek DNS rekordjaiban. Tunneling alkalmazása IPv4 rendszerrel szeparált IPv6 rendszerek között. IPv4 támogatás megszüntetése a rendszerekben. Header translation alkalmazása a maradék csak IPv4-et kezelõ rendszerekben.