Az IPv6 hálózati protokoll

Mohácsi János, Szigeti Szabolcs, Máray Tamás

Folyamatszabályozási Tanszék,
Budapesti Műszaki Egyetem,
Műegyetem rakpart 9, 1111, Budapest

e-mail:{mohacsi,pink,maray}@fsz.bme.hu

Absztrakt

Az IP hálózatok üzemeltetôi és fejlesztôi már évekkel ezelôtt felismerték a jelenleg is használt IP 4-es protokoll korlátait és hiányosságait. Az Internet nagyarányú fejlôdése következtében egyre sürgetôbbé vált az IP protokoll továbbfejlesztése, a hiányosságok kiküszöbölése. Az IETF által koordinált kutatómunka eredményeként 1994-ben jelent meg az elsô javaslat az IP protokoll következô generációjára (IPng). A 1995 végén elfogadott új hálózati technólógia (IPv6) figyelembe veszi a jelenlegi és a jövôben várhatóan felmerülô, a modern hálózati infrastruktúrával szemben támasztott igényeket. Várható, hogy az IPv6 bevezetése a közeljövôben megkezdôdik és néhány éven belül az Internet hálózat jellemzô protokolljává válik.

A BME Folyamatszabályozási Tanszékén 1997 februárjában megkezdtük az IPv6 technológia tesztelését, valamint a bevezetésével kapcsolatos kísérleteket.

Az elôadásunkban szeretnénk bemutatni az IPv6 fôbb jellemzôit és az IPv6 címzési rendszerét. Beszámolunk a világon jelenleg folyó IPv6-al kapcsolatos fejlesztések eredményeirôl, hol tart ma az IPv6 specifikációja és implementációja. Ismertetjük a Folyamatszabályozási Tanszéken folyó kutató munka és kísérletek tapasztalatait.

Tartalom

  1. Az IPv4 problémái
  2. Az IPv6 kialakulása
  3. Az IPv6 legfontosabb tulajdonságai
  4. Az IPv6 címzési rendszere
  5. IPv6 fejlesztések és implementációk
  6. A 6bone
  7. A BME-FSZ IPv6 kísérletek
  8. Az IPv6-ra történô átállás
  9. Összegzés
  10. Hivatkozások

Az IPv4 problémái

A TCP/IP fejlesztôi sem gondolták a 1980-as évek elején, hogy majdan az IP hálózat növekedésének korlátaival kell szembenézniük. Még 1987-ben is csak néhány százezer hálózat összekapcsolásának szükségességét tartották elképzelhetônek. Szinte hihetetlen, hogy az eredeti Internet hálózat, amely csak néhány tucat rendszerbôl állt, mára több tízmilliós rendszerré fejlôdött, ami ma is robbanásszerűen fejlôdik.[]

Manapság a legtöbb Internet végpont bérelt vonalak, vagy telefon vonal segítségével csatlakozik. Az IP technológia további nagymérvű elterjedése várható más új médiumok, mint például a kábel-televízió, elektromos-vezetékek és az Internet otthoni használatával.

A szédítô sebességű növekedés az Internet alapvetô technologiáját (az IPv4-et) nehezen megoldható feladatok elé állította. Elméletileg az Internet címek tartománya elegendô csaknem 4 milliárd gép megcímzéséhez. Valójában ez nincs így, mert az elméleti címkiosztási hatékonyságtól messze elmarad a gyakorlatban elérhetô érték [RFC1715]. Az alacsony hatékonyság további oka az IP címtartomány osztályokra bontása. Az osztályozás azon a feltételezésen alapul, hogy az Internet nagyon sok kisméretű intézmény (kevesebb mint 250 gép, C osztályú cím), kevés közepes méretű (kevesebb mint ~64000 számítógép, B osztályú cím), és még kevesebb nagyon nagy méretű cég ( ~15 millió számítógép, A osztályú cím) összekapcsolásából épül fel. A gazdaságtalan címkiosztás miatt a legközkedveltebb B osztályú címek gyakorlatilag elfogytak. Jelenleg a B osztályú címek helyett a közepes méretű szervezetek C osztályú címek folytonos tartományát kapják meg. Ez azonban egy újabb problémát vet fel: mivel ezek a C osztályú címek külön hálózatot jelölnek, ezért a routing-protokollok ennek megfelelôen kezelik ôket, így a router táblák, és a kicserélôdô routing-információk igen nagyra duzzadtak. Ezen próbál segíteni a CIDR (Classless Inter-Domain Routing) [RFC1519]. További "címnyerési" lehetôségek is felmerültek az idôk folyamán, például olyan IPv4-es címek használata, amelyek nem globálisan egyediek. Ezeket olyan eszközök számára lehet kiosztani, amelyek soha nem lesznek az Internetbe kapcsolva [RFC1918].

A fent leírt módszereket valamint más technikákat is alkalmazva (pl. átszámozás, felhasználatlan címtartomány visszakérése, stb.) a becslések szerint 2005 körül fog elfogyni az összes IPv4-es cím.

A TCP/IP használata során egyéb problémák is felmerültek az IPv4-el kapcsolatban. Az egyik ilyen fontos probléma, hogy a fragmentáció támogatása - amellett, hogy lelassítja a feldolgozást (meg kell várni az összes fragmenst, míg további feldolgozásra átadható a csomag felsôbb szinteknek) -, rendkívül erôforrás igényes, mivel tárolni kell a fragmenseket, hogy össze lehessen állítani az eredeti IP csomagot. Az ilyen késleltetés nagyon sok multimédia jellegű alkalmazásnál megengedhetetlen. Fontos problémája az IPv4-nek, hogy nem eléggé flexibilis az útvonalválasztása, nem támogatja a hierarchikus útvonalválasztást. Nem elhanyagolható dolog, hogy az IPv4 nem nyújt semmiféle támogatást a csomagok titkos küldésére és az azonosításra. További hiányossága az IPv4-nek, hogy a multicast támogatás meglehetôsen szegényes és korlátozott.

Az IPv6 kialakulása

Az új IP verzió kifejlesztését alapos felmérések és tanulmányok elôzték meg. Az IETF (Internet Engineering Task Force) által kezdeményezett kutatások alapján felállították az új IP által kielégítendô követelmények listáját. E követelményeket úgy határozták meg hogy nem csak a jelenlegi ill. már korábban felmerült igényeket vették figyelembe hanem megpróbálták megjósolni a következô évtizedekben megjelenô új feladatokat is. Olyan protokoll tervezése volt a cél amely hosszú távon megoldást nyújt a számítógéphálózatokkal kapcsolatos egyre komolyabb és szerteágazóbb igények kielégítésére.

Az IPng-vel (IP new generation) szemben támasztott egyik legfontosabb követelmény az volt hogy a bevezetése egyszerű és könnyű legyen, az új rendszer a régivel párhuzamosan tudjon működni még hosszú ideig és az áttéres semmiféle fennakadást, zökkenôt ne okozzon. A jelenleg használt IPv4 már túlságosan elterjedt, és az Internet túl nagyra nôtt ahhoz hogy az új protokollra való átállást mindenhol egyidejűleg meg lehessen oldani es a régit egy csapásra el lehessen felejteni.

1992 decemberére összesen hét különbözô javaslatot publikáltak az IP új verziójának a kidolgozására. A további munka során a javaslatok közül háromnak az összedolgozásával 1994 nyarára megszületett az a változat [RFC 1883] amelyet november 17-én az Internet Engineering Steering Group is elfogadott és a saját ajánlásává tett.

Az új protokoll az IPv6 nevet kapta ami az IP 6-os verzióját jelenti. A jelenleg használt IP verzió a 4-es. (Az 5-ös egy belsô, munkaverzió amely nem került implementálásra.)

Az IPv6 legfontosabb tulajdonságai

Az IPv6 tervezésekor nem csak az IPv4 meglévô hibáit igyekeztek kiküszöbölni, hanem olyan új szolgáltatásokat igyekeztek beépíteni, amelyek gyorsabbá, robosztusabbá, és az új hálózati és felhasználói igényeknek jobban megfelelôvé teszik az új protokollt.

A megnövelt címtartomány lehetôvé teszi a racionálisabb, a topológiához jobban illeszkedô címzés és útvonalválasztás kialakítását. Az IPv6-ban nem csak a unicast típusú címek kezelése egyszerűsödött, hanem a multicast címeké is. A hatékonyabb útvonal választás következtében a routerek memóriája optimálisabban lesz kihasználható. A multicast és unicast címeken túl létezik egy ún. anycast címzés is, ami az interfészek csoportjából egyet címez meg. Broadcast címzés nincsen, ennek szerepét a multicast veszi át.

Az IPv4-es fejléchez képest az IPv6-os fejléc szerkezete egyszerűsödött. Eddig kötelezô mezôk opcionálisakká váltak, így az IP csomag feldolgozása egyszerűsödik, ezzel is növelve az elérhetô teljesítményt.

Az opcionális mezôk kezelése egyszerűbbé és egyben sokkal általánosabbá vált, lehetôvé téve az IPv6 könnyű továbbfejlesztését, valamint az adott alkalmazáshoz illeszkedô megfelelô opcionális mezôk flexibilisebb alkalmazását. Külön választották a minden közbensô node-ra vonatkozó opciókat és a csak a cél állomásra vonatkozó opciók, ami szintén növeli a hatékonyságot.

A Quality of Service mezôk megszűntek, illetve egy sokkal általánosabb mechanizmus vette át a szerepüket, az ún. "flow". A kidolgozás alatt álló RSVP szabványhoz [RSVP] illeszkedôen az IPv6-ban lehetôség van "virtuális adatcsomag útvonal" kialakítására. Az IPv6 így korlátozott formában alkalmas vonalkapcsolás jellegű hálózati szolgáltatások megvalósítására. Ez a tulajdonság a multimédia/műsorszóró alkalmazások esetén hatékonyan kihasználható. Természetesen az IPv6 továbbra is tartalmaz prioritás mezôt, ami alapján a routerek szelektálhatnak hogy milyen prioritású csomagot dolgoznak fel elôször. Az ajánlásban megtalálható az is, hogy a különbözô prioritásokhoz milyen típusú forgalmat célszerű rendelni.

További elônyös tulajdonsága az IPv6-nak, hogy támogatja a munkaállomások automatikus hálózati konfigurálását.[RFC1972][DHCP6] Ennek következtében az IPv6 alkalmazásával sokkal hatékonyabban alakíthatók ki és menedzselhetôk nagyméretű hálózatok.

Hasznos újdonsága az IPv6-nak, hogy hálózati szinten lehetôséget nyújt titkosítás és azonosítás alkalmazására. Ez természetesn nem zárja ki annak a lehetôségét, hogy magasabb szinten másfajta módszereket is alkalmazzunk ezeket kiegészítve és hatékonyabbá téve.

Az IPv6 címzési rendszere

A legszembetűnôbb változás az IPv4-hez képest az IPv6 címzési rendszere. A felhasználható címtartomány sok kvadrilliószorosa az eddigieknek, mivel a címek hossza 32 bitesrôl 128 bitesre növekedett. Az eddigi A, B és C osztályú címtartományokhoz képest jóval gazdaságosabban és a rugalmasabb címkiosztási módszerek bevezetésével lényegesen jobban lehet kihasználni a címeket. A legpesszimistább becslések szerint is legalább másfél ezer kiosztható IPv6 cím esik a Föld felszínének minden négyzetméterére.

Az IPv6 címek 128 bites azonosítók, amelyek egy hálózati interfészhez, vagy interfészek csoportjához vannak rendelve. Alapvetôen három csoportba oszthatjuk a címeket:

Az IPv6-os címek különbözô csoportjai egyértelműen azonosíthatóak a legmagasabb helyiértékű bitjeik (Format Prefix) alapján. Ez alapján -többek közt- megkülönböztethetünk földrajzilag kioszott unicast, szolgáltatón alapuló (Provider based) unicast, link local, site local és multicast címeket. Ezen kívül külön címtartomány van fenntartva az IPv4 címek IPv6 kompatibilis használatára, valamint az IPX és OSI hálózatok számára is.

CímtartományPrefixÖsszes cím hányad része
Fenntartott 0000 0000 1/256
Kiosztatlan 0000 0001 1/256
NSAP címeknek fenntartott 0000 001 1/128
IPX címeknek fenntartott 0000 010 1/128
Kiosztatlan 0000 011 1/128
Kiosztatlan 0000 1 1/32
Kiosztatlan 0001 1/16
Kiosztatlan 001 1/8
Szolgáltatón alapuló címek 010 1/8
Kiosztatlan 011 1/8
Földrajzi címek 100 1/8
Kiosztatlan 101 1/8
Kiosztatlan 110 1/8
Kiosztatlan 1110 1/16
Kiosztatlan 1111 0 1/32
Kiosztatlan 1111 10 1/64
Kiosztatlan 1111 110 1/128
Kiosztatlan 1111 1110 0 1/512
Link Local cím 1111 1110 10 1/1024
Site Local cím 1111 1110 11 1/1024
Multicast cím 1111 1111 1/256

Átalakult a subnet mask fogalma subnet prefixszé, de ez a különbözô címtípusok esetében további bontással finomabb címkiosztást eredményez.

A provider based címek lehetôvé teszik a címtartomány allokálás decentralizálását, azzal, hogy a címben szerepel az adott tartományért felelôs szervezet (registry) azonosítója és az általuk -ebbôl a tartományból- kiosztott címért felelôs szolgáltató azonosítója. A megmaradó címtartományt pedig a szolgáltató maga oszthatja ki elôfizetôi között.

A link local és site local címek az egy szegmensen vagy egy szervezeten belüli kommunikációra vannak fenntartva, és rendszerint az IPv6 autokonfigurációs mechanizmusának segítségével, automatikusan állítódnak be..

A címek szöveges megjelenítése is új az IPv4-hez képest. A címet 8 darab 16 bites részre bontva, hexadecimális alakban, kettôspontokkal elválasztva írjuk le. A csupa 0 bitet tartalmazó tartományok rövidítve, :: jellel írhatóak. Például a 1080:0:0:0:0:3:a143:2c2b cím rövidítve 1080::3:a143:2c2b formában írható.

IPv6 fejlesztések és implementációk

Az IETF IPng munkacsoportja elkészítette az IPv6-ra vonatkozó RFC ajánlásokat. Ezek közül a legfontosabbak: Az IETF-tôl szokatlan módon a programozói interfészre (API) is készítettek ajánlást, hogy minél egyszerűbben lehessen átvinni az IPv4-es programokat IPv6-ra [IP6bsd]. Szintén az átállás megkönnyítésére ajánlást dolgoztak ki arra, hogy hogyan lehet és kell áttérni az IPv4-rôl az IPv6-ra [RFC1933].

Az elmúlt 2 évben az IPv6 területén nagy fejlôdés volt tapasztalható. A különbözô kutatási IPv6 változatokon kívül az összes fontosabb TCP/IP eszközt gyártó cég elkészítette saját IPv6 implementációját. Ezek megvalósítási szintje nem egységes, de az alapvetô IPv6 működésre mindegyikük alkalmas. A következô felsorolásban a létezô implementációkat tüntettük fel.

Host szoftverek:
Router szoftverek:
Szabad ill. kísérleti szoftverek:
A legtöbb implementáció jellemzôje, hogy nem tartalmazza a titkosítási és azonosítási modulokat, az exportkorlátozási elôírasok miatt.

A 6bone

A 6bone egy nemzetközi, kísérleti, virtuális számítógéphálózat amely IPv6 protokollon alapul. Azért virtuális, mert nem valódi, külön e célra létrehozott kommunikációs infrastruktúrán üzemel, hanem az IPv4 alapú Internet hálózaton képezték ki az adatátviteli csatornáit.

A 6bone hálózat létrehozásának ötlete 1995-ben, az IPv6 protokoll IETF általi elfogadása után merült fel, és az IPng projekt folytatásának tekinthetô. A gyakorlati megvalósítás az 1996 márciusi, Los Angelesben tartott IETF találkozó után kezdôdött el.

A 6bone legfontosabb célja az hogy kísérleti terepet biztosítson az IPv6 technológiával kapcsolatos kutatásokhoz és fejlesztésekhez, az üzemeltetési és konfigurálási tapasztalatok gyűjtéséhez, az IPv4 -> IPv6 átmenet minél tökéletesebb kidolgozásához.

A 6bone kitűnô eszköz az IPv6 új routolási stratégiáinak és algoritmusainak kipróbálására és az IPv6 szoftverek és berendezések tesztelésére. Az IPv6 fejlesztésekben élen járó egyetemek és kutatóintézetek mellett bekapcsolódtak az Internet technológia legfontosabb ipari szereplôi is (Cisco, SUN, IBM, DEC, stb.).

A 6bone hálózathoz mára már 22 ország számítógéphálózati fejlesztô csoportjai csatlakoztak a saját kísérleti IPv6 lokális hálózatuk bekapcsolásával. Az elsô magyar IPv6 host 1997 április elején kapcsolódott a 6bone-hoz a Budapesti Műszaki Egyetem Folyamatszabályozási Tanszékén. Az IPv6 hálózatok regisztrálását a RIPE NCC végzi.

A virtuális hálózat kiépítése céljából a 6bone routereket IPv4 fölött létrehozott "alagutak" (tunnelek) segítségével kapcsolják egymáshoz. A routerek az IPv6 csomagokat IPv4 packetekbe csomagolva a tunneleken keresztül továbbítják.

A BME-FSZ IPv6 kísérletek

A BME Folyamatszabályozási Tanszékén folyó hálózati kutatások keretében felállítottunk egy -jelenleg két hosztból álló- IPv6 teszt hálózatot, amely IPv4 tunneleken keresztül csatlakozik a 6bone-hoz.

Mindkét gép egy 486 alapú PC. Az operációs rendszer FreeBSD-2.1.7.1, az INRIA IPv6 implementációval. A választásunk azért is esett erre a rendszerre, mert a teljes operációs rendszer ill. IPv6 csomag szabadon és forrásban elérhetô. Ebben a kategóriában az INRIA implementáció tűnt a legkiforrottabnak (az IBM is erre alapozza az AIX IPv6 támogatást), és FreeBSD rendszerek üzemeltetésében és konfigurálásában is széleskörű tapasztalatokkal rendelkeztünk.

A csomag az IPv6 protokollon kívül tartalmazza a konfiguráláshoz szükséges programokat (ifconfig, cticonfig stb.), az IPv6 segédprogramokat (ping6, traceroute6, netstat stb.), az IPv6 autokonfigurációs programot (autoconf6), RIPng támogatást (ndpd-router), egy IPv6 firewall programot, valamint néhány egyéb alkalmazást (named, sendmail, apache, telnet, ftp, stb.) IPv6 támogatással kiegészítve. Nem része azonban az IPv6 security kiegészítése, a francia exportkorlátozási törvények miatt, de a következô verzióban valószínűleg lesz egy exportálható megvalósítás.

A rendszer installálása nem okoz különösebb problémát, a FreeBSD forrásban kell kicserélni az változott, illetve új állomanyokat, és újrafordítani az érintett programokat és a kernelt. Ezzel szemben a konfigurálás komoly nehézségeket jelentett, a hiányos dokumentáció és a bonyolult cím architektúra miatt. Természetesen egy már működô IPv6-os lokális hálózatba történô host csatlakozás esetén a fenti problémák nem jelentkeznek, az IPv6 autokonfigurációs mechanizmusa miatt. Router konfigurálásnál természetesen elkerülhetetlen a címzési rendszer alapos ismerete.

A szoftver elsô verziója nem tartalmazta az általunk használt hálózati kártya IPv6-os driverét, ezért ezt magunk készítettük el.

A tesztekhez jelenleg 3 tunnelen keresztul (6bone.chicago.cic.net, unvea6.ipv6.uni-c.dk, 6bone.join.uni-muenster.de) csatlakozunk a 6bone-hoz. A 6bone-hoz közvetlenül csatlakozó host (tracy.ipv6.fsz.bme.hu) és a másik IPv6 host (mzperx.ipv6.fsz.bme.hu) között egy szeparált hálózati szegmens van kiépítve, és az mzperx felôl érkezô csomagokat a tracy továbbítja a 6bone felé.

Célunk egy tisztán IPv6 alapú belsô hálózat kiépítése. A DNS hiányosságai miatt ez jelenleg nem lehetséges mert sem a name szerver, sem a resolver library nincsen felkészítve a tisztán IPv6 feletti működésre. A probléma megoldásán az IPv6 francia fejlesztôivel együtt dolgozunk. A fentiek miatt a belsô hálózaton a DNS IPv4 felett üzemel.

A RIP új változatát (RIPng) használjuk az útvonalválasztás szabályozására. Tervezzük a BGPng tesztelését is.

Felállítottunk egy kísérleti WWW szervert, amely mind IPv6, mind IPv4 protokollal érkezô kéréseket képes kiszolgálni. (http://www.ipv6.fsz.bme.hu/)

Eddigi tapasztalataink alapján a rendszer üzembiztosan működik, ezt bizonyítják a 6bone automatikus ping statisztikái is.

Az IPv6-ra történô átállás

Az IPv6 széleskörű elterjesztése érdekében szükség van arra, hogy az IPv4-rôl IPv6-ra váltás a lehetô legsimábban történjen meg. Ezért az IETF más rendszerek tapasztalatait is figyelembe véve olyan módszert dolgozott ki, ami segítségével zökkenômentesen lehet áttérni az új protokollra. Az IPv6-ra történô áttérést nem csak a kifogyó IPv4 címek ösztönzik, hanem más más tényezôk is. Ezek közül a legfontosabbak:
  1. A IPv4 cím tartomány elfogyásának közeledtével egyre kevesebb idô áll rendelkezésre, így ugyanazt a munkát rövidebb idô alatt kell elvégezni, ezért célszerű a minél korábbi áttérés.
  2. Az IPv6 rendelkezik cím autokonfigurációs lehetôséggel. Ez egyrészt a felhasználó szempontjából elônyös (bekapcsolás után azonnal használhatja a IPv6-al működô számítógépét), másrészt a rendszergazdáknak is jó, mert megkönnyíti a hálózat adminisztrációját.
  3. A multicast támogatás szabványosított. Ez azért elônyös, mert az összes IPv6-os router támogatja a multicast-ot, így a unicast és multicast topológia azonos, vagy nagyon hasonló lehet. Ezért, a multicast alkalmazások mindenűtt működnek.

Az IPv4->IPv6 áttérés lehetô legsimább biztosítása érdekében a következô szempontok jelentek meg az áttérés megtervezésekor:

  1. Ne legyen semmiféle áttérési függôség.
  2. Tegye lehetôvé az IPv6-ra történô áttérést inkrementálisan. Ne legyen egy átkapcsolási nap.
  3. Mindenki a saját ütemében térhessen át.
  4. Legyen lehetôség különbözô opciókra a címkiosztás tekintetében.
  5. A felhasználók számára a lehetô legegyszerűbbb legyen.
  6. A meglevô IPv4 infrastruktúra továbbra is használható legyen.
Ezen követelményeket az IPv6-os implementációk a következô módon biztosítják:
  1. Az új szoftvereknek mind az IPv4-et mind az IPv6-ot támogatniuk kell.
  2. A transport szint változatlan, így az alkalmazások (apróbb módosításoktól eltekintve) úgyanúgy működnek. Természetesen, ha ki akarjuk használni a IPv6 új szolgáltatásait, akkor módosítani kell a meglévô alkalmazásokat.
  3. Teljes együttműködés a már meglévô IPv4-es gépekkel.
  4. A IPv6 IPv4 csomagokba csomagolva (tunneling) halad át a hálózaton és a jelenlegi IPv4 routing infrastruktúrán.

Összegzés

Az IPv6 technológia fejlesztése és implementálása világszerte gyors ütemben halad. A külföldi eredmények és saját tapasztalataink is azt mutatják, hogy az IPv6 kidolgozása hamarosan eléri azt a szintet, ami az éles bevezetés megkezdéséhez szükséges. Nyilvánvaló, hogy a teljes Internet átállása hosszú éveket fog igénybe venni, de az új hálózati fejlesztéseknél nemsokára már az IPv6 technológiát kell alkalmazni.

Hivatkozások


© Szigeti Sz., Mohácsi J., Máray T., 1997