• CampusIPv6DeploymentMotives

1. IPv6 bevezetését indokló tényezők

1.1. Bevezetés

Az IPv4 protokoll kiállta az idők próbáját. A különböző adathálózati protokollok közül egyedüli nyertesként ma már gyakorlatilag minden hálózatra kötött eszköz TCP/IP-t használ. Miért van mégis igény az IPv4 leváltására? Az évek során sok olyan körülmény adódott, amelyre az eredeti protokoll tervezésekor nem számítottak, ezen problémákat gyakran tűzoltásszerű megoldásokkal próbálták orvosolni. Ilyen probléma például a címtartomány kimerülése, melyet a NAT/PAT megoldással viszonylag sikeresen kezeltek. Már ekkor felmerült az igény egy új az IPv4 jó tulajdonságait megtartó, a felmerült problémákat pedig a kezdetektől megoldó protokoll bevezetésére. Ez lett az IPv6.

Az IPv6 protokoll bevezetése már évek óta folyik. Az olyan hazai és nemzetközi projektek, mint a Tipster6 vagy a 6net jelentős lépéseket tettek a hazai IPv6 közösség létrehozásában és az akadémiai hálózat IPv6-képessé tételében. Bár természetesen vannak még tennivalók a szolgáltatói hálózatok területén

Más a helyzet az alacsonyabb szinteken. Az intézményi hálózatokban és a végfelhasználóknál még gyakorlatilag ismeretlen az IPv6. Nyilvánvaló, hogy bár az okok összefüggenek, más indokok szolgálnak a szolgáltatói hálózaton belüli bevezetésre és más érvek szolgálnak egy intézményen belüli bevezetésre. Ismét más okok miatt dönthet úgy egy végfelhasználó, hogy neki is szüksége van az új protokollra.

A következőkben megvizsgáljuk, hogy milyen tényezők indokolhatják az IPv6 bevezetését, elsősorban a campus hálózatokon belül. Az indokok felmérése segít meghatározni a szükséges bevezetési lépések megtételét.

A Camp6 projekt felmérése szerint az üzemeltetők (akadémiai hálózaton) 42%-a egyenlőre nem tervezi az Ipv6 bevezetését. Viszont a maradék körülbelül fele-fele aránybán már vagy használja, vagy egy éven belül készül használni. Azt, hogy ez lesz a preferált protokoll rövid időn belül, viszont csak kisebb részük gondolja. Ugyanakkor 84%-uk használná, ha „készen kapná” a szolgáltatást. Ez azt mutatja, hogy csak mérsékelten tekintik sürgősnek a bevezetést, de felismerik, hogy előbb-utóbb szükség lesz az új protokollra.

1.2. Az IPv6 kidolgozását indító okok

A jelenleg is használt IPv4 protokoll leváltására az 1990-es évek elejétől kezdve voltak törekvések.

1.2.1. Az IPv4 problémái

Az IPv4 messze túlteljesítette a tervezésekor támasztott elvárásokat. Mégis, a mai hálózatokban vannak olyan esetek, amelyek hátráltatják a további fejlődést vagy költséges kerülőutak megtételére kényszeríthetik a szolgáltatókat és a felhasználókat.

A felmerült problémákat alapvetően hat témakör köré csoportosíthatjuk:

• A címtartomány kérdése – az IPv4 címzési architektúrája, az azóta bevezetett fejlesztések ellenére korlátozza a fejlődést.
• Multicast képesség - mivel a multicast ötlete az IPv4 címzési architektúrájának megtervezése után merült fel, ezért utólag, egy viszonlyag kicsi cím tartomány lett erre a célra lefoglalva. (D osztály)
• Teljesítmény – a nagyméretű és nagyteljesítményű hálózatokban szűk keresztmetszetet jelenthetnek az IPv4 bizonyos megoldásai.
• Menedzselhetőség – az IPv4 hálózatok menedzselhetősége bizonyos esetekben és környezetekben problémás, vagy legalább is többletmunkát igényel.
• Biztonság – az IPv4-ből koncepcionálisan is hiányoznak az átfogó biztonsági megoldások.
• Quality of Service – teljeskörű támogatása problematikus jelenlegi protokollban.
• Mobilitás – a mobil üzem megvalósítása IPv4 alatt körülményes.

Annak megvizsgálására, hogy ezek közül mely jelent valós hajtóerőt, célszerű részletesen megvizsgálni az IPv4 hiányosságait.

1.2.1.1. Címtartomány

Az IPv4 az egyes állomások (pontosabban: interfészek) azonosítására 32 bites, globálisan egyedi címeket használ. Ez önmagában 2³². Ennyi cím azonban nem osztható ki, ugyanis az IP cím egy hálózati és egy hoszt címből tevődik össze. Az IPv4 címzési architektúrájának kidolgozásakor elkövették azt a hibát, hogy a hálózati és a hoszt címek meghatározásánál mai szemmel nézve helytelen felosztást választottak, amely nem jól idomult a hálózatok méretéhez.

A kényelmetlen hálózat méretekre több megoldás is született, a subnetting (alhálózatok kialakítása) az osztályon belüli további bontást teszi lehetővé, még az osztálynélküli címek bevezetése tulajdonképpen az osztályok eltörléséhez és a rugalmas címfelosztáshoz vezetett.

1.2.1.2. Multicast képesség

Az utólag lefoglalt D tartománnyal nehéz, ha nem lehetetlen világ méretű többesküldő hálózatot kiépíteni. Ezen csak az IPv6 cím tartománya tud segíteni.

1.2.1.3. Menedzselhetőség

Az IPv4 hálózatok üzembeállítása és üzemeltetése meglehetősen sok manuális beavatkozást igényel, ezért költséges. A már üzemelő hálózatok átkonfigurálása hasonlóan munkaigényes, és jelentős kiesésekkel járhat.

Ugyanakkor a protokoll nem toleráns a konfigurációs problémák iránt. Bizonyos helytelen beállítások az egész hálózat működését lehetetlenné tehetik, de legalább is fennakadásokat okozhat más szolgáltatások üzemében.

Természetesen mind a konfigurálásra, mint a menedzselhetőségre kidolgoztak megoldásokat, amelyek nagyjából teljesítik is a célkitűzéseket, azonban robosztusságban mindenképpen hagynak kívánnivalót.

1.2.1.4. Biztonság

Az IPv4 tervezésekor a biztonság, mint igény gyakorlatilag nem merült fel, vagy legalább is nem olyan módon, hogy azzal a hálózati szinten foglalkozni kellene. Az idők folyamán azonban az Internet kikerült az ilyen szempontból kevésbé veszélyeztetett kutatói szférából és alapvető igény lett a hálózati kommunikáció biztonságossá tétele.

Így azután a biztonság megteremtésére „felülről”, az alkalmazások irányából voltak kezdeményezések, és egyedi alkalmazásokra (email, web) születtek is megoldások.

1.2.1.5. Quality of Service

Bizonyos kezdemények (prioritást és forgalmi osztály valamilyen szinten reprezentáló bitek az IP fejlécben) vannak az IPv4-ben is, amelyek célja a különböző QoS feladatok támogatása, azonban ezek sosem kerültek igazán teljesen kidolgozásra, illetve jelentésük az idők során változott. Ugyanakkor az időközben kidolgozott QoS elveket csak nehézkesen lehetett ezek segítségével megvalósítani.

1.2.1.6. Teljesítmény

Az utóbbi években a hálózati eszközök nyers teljesítménye olyan szintre növekedett, hogy egyre gyakrabban ütköznek magának a TCP/IP protokoll család teljesítőképességének határaiba. Sok probléma jelentkezik a TCP szinten és sok megoldás is született, azonban IP szinten is vannak gondok.

A címzési architektúrából következik, hogy az IP címek kiosztása (amely alapján az útválasztás történik) nem követi a hálózat topológiáját (amely alapján pedig a hatékony útválasztás megvalósítható). A globális Internet méretének növekedésével főleg a gerinchálózatok útválasztóira egyre nagyobb terhelés nehezedik, routing-táblájuk gyakran kezelhetetlen méretűre nő.

Nem csak ez okozza azonban az útválasztók leterheltségét, a csomagok menet közbeni tördelése legalább ekkora gondot jelent és az IPv4 csomag szerkezete sincsen a hatékony feldolgozásra optimalizálva.

Kisebb mértékű a végpontok terheltségének problémája, ugyanis itt relatíve jóval nagyobb teljesítmény áll rendelkezésre, még a végzendő munka jóval kevesebb.

1.2.1.7. Mobilitás

A IP szintű mobilitás (makro mobilitás) az IPv4-ben megoldott ugyan, de a rendszerből adódóan sok hiányossággal küzd, és inkompatibilis más (pl. NAT) megoldásokkal.

Ugyanakkor az igény, ha nem is tömegesen, de megvan arra, hogy eszközök képesek legyenek hálózatok között gyakorlatilag transzparensen mozogni.

1.3. Lényeges tervezett különbségek

Az IPv6 kidolgozásának fő mozgatóereje a címtartomány szűkössége volt, ennek megoldása olyan mély változtatásokat igényelt a protokoll szerkezetében, hogy „egy füst alatt” szinte minden más problémára is lehetett megoldást találni, hiszen nem volt semmi olyan „örökölt” szabvány, amelyhez kompatibilisnek kellett volna maradni.

1.3.1. Címzési architektúra

Természetes, hogy az IPv6 leglátványosabban különböző tulajdonsága a címzési architektúra. A cím mérete 32 bitről 128 bitre nőtt, tehát rendelkezésre áll 2¹²⁸ azaz 4x10³⁸ darab cím.

Természetes, hogy ebben az esetben sem osztható ki minden cím, azonban a rendelkezésre álló hatalmas mennyiségű cím az allokáció során megkönnyíti olyan más szempontok figyelembevételét, mint például a teljesítmény, vagy a menedzselhetőség.

A címzési architektúra egyik nagy előnye, hogy definiálva van az egyes címek hatóköre. Ez többesküldés esetén érdekes különösen ahol IPv4 esetén csak a TTL mezővel lehetett beállítani az egyes többesküldés tartományok hatókörét.

1.3.2. Autokonfiguráció

Az IPv6 tervezése során követelmény volt, hogy az egyes eszközök konfigurálása és újrakonfigurálása a lehető legkevesebb kési beavatkozással és a lehető legnagyobb robosztussággal történjen. Ennek nem csak a cím beállítását, de más hálózati paraméterek felvételét is tartalmaznia kell, és támogatni kell a dinamikus rekonfigurációt. Mindeközben minimalizálni kell a konfigurációs hibák kihatását a hálózat más részeire.

Az IPv6 átfogó és kifinomult autokonfigurációs mechanizmusokkal rendelkezik. Alapvetően két fajta autokonfiguráció létezik, az állapotmentes (stateless) és az állapottartó (stateful). Az állapotmentes konfigurációs során az eszköz autonóm módon, az útválasztók hirdetése alapján állítja be a paramétereket, az állapottartó konfiguráció viszont külső konfigurációs szervert tételez fel.

Közös tulajdonsága mindkettőnek, hogy tisztán IPv6 felett történik, ellentétben az IPv4-es megoldásoknál (bootp, dhcp), ahol a fizikai hálózattól függött (pl.: Ethernet címek).

1.3.3. IPSec

Az IPv6 kötelező tartozéka az IPSec biztonsági keretrendszer. Ennek segítségével IP szinten van lehetőség autentikációra és titkosításra. Az IPv4 alatt elérhető IPSec az IPv6-os változat adaptálásából született.

• Az IPSec nem konkrét megoldásokat tartalmaz, hanem keretrendszer, amelynek a következő komponensei vannak:
• Az IPSec keretrendszer
• Az autentikációt megvalósító AH rendszer
• A titkosítást megvalósító ESP rendszer, amely magában foglalja az AH funkciókat is.
• A kulcs-menedzsment rendszer
• A kriptográfiai algoritmusok

1.3.4. QoS támogatás

Az IPv6 önmagában nem tartalmaz QoS szolgáltatásokat, azonban az IP fejléc erre a célra szolgáló Traffic Class és Flow Label mezőivel lehetővé teszi a forgalom osztályba sorolhatóságát és az egyes kapcsolatok megkülönböztethetőségét, így tehát akár a differenciált, akár az integrált QoS szolgáltatásokat könnyen implementálhatóvá teszi.

Ugyanakkor meg kell jegyezni, hogy mindezidáig viszonylag kevés konkrét eredmény született az IPv6 és a QoS tekintetében. Ennek egyik oka lehet a tulajdonképpen nem meggyőző igény ezekre a szolgáltatásokra.

1.3.5. Teljesítménynövelő megoldások

Az IPv6 több ponton is elősegíti a nagyteljesítményű feldolgozást. A címzési architektúra önmagában teljesítménynövelő hatással van. Ehhez jön még a csomagok és fejlécek kezelésének új módszere.

1.3.6. IPv6 mobilitás

Az IPv6 mobilitása alapvetően az IPv4 mobilitásban használt elveken alapul, de kihasználva az IPv6 tulajdonságait, sokkal letisztultabban és hatékonyabban képes működni.

A mobil működés során a mobil eszköznek van egy vagy több honi ágense, amely a honos hálózatba érkező forgalmat továbbítja az idegen hálózatba átmozgott eszköznek.

A mobil állomás mozgásáról értesíti az ágensét, amely a forgalmat felé továbbítja majd. Megfelelő opciók felhasználásával az első csomag után már nincsen szükség a honi ágensre, mert a mobil csomópont értesíti partnereit az ideiglenes (távoli hálózatban lévő) címéről. Ezzel kiküszöbölhető a háromszögletű kommunikáció okozta teljesítményveszteség.

1.4. Valós különbségek

A tervezett különbségekhez képest a bevezetési kérdések vizsgálatakor célszerű figyelembe venni a jelenlegi gyakorlatban kihasznált különbségeket az IPv4 és az IPv6 között.

1.5. SWOT elemzés

Az IPv6 bevezetésének lehetőségeit SWOT elemzésen keresztül vizsgáljuk. Az elemzés során felmérjük az IPv6 tulajdonságit, erősségeit, amelyek alapján valószínűsíthető az elterejedése, és gyengeségeit, amelyek hátráltathatják bevezetését. A környezet lehetőségeket és fenyegetéseket jelent az IPv6 számára. Bemutatjuk a lehetőségeket, amelyeket kihasználva az IPv6 előtérbe kerülhet. Végül megvizsgáljuk azokat a fenyegetéseket, amelyek az IPv6-ra leselkednek. A vizsgálat során elsősorban az IPv4-gyel történő összehasonlításra koncentrálunk. Az összehasonlítás során két területet veszünk figyelembe a műszaki és az egyéb (pl. gazdasági) indokokat.

1.5.1. Erősségek

Az IPv6 alapvető erősségei abban rejlenek, hogy bizonyos műszaki és üzemeltetési problémákra komoly tervezőmunkával megalapozott megoldásokat biztosít.

• A címzési kérdésekre (címtartomány szűkössége) a műszakilag legjobb megoldást adja, a címtartomány kiszélesítését. Ezzel megmarad az end-to-end kapcsolati modell, vagyis meglévő alkalmazásokat nem kell alapvetően átalakítani, vagy áthidaló megoldásokat (proxy, stb.) alkalmazni.
• Csak a hálózati réteg változik, a szállítási szint nem, vagyis az alkalmazások kevés módosítással képesek IPv6-ot használni. Sok alkalmazás (szinte minden nyílt forrású) már most IPv6 képes.
• A biztonságra kezdetektől fogva nagy hangsúlyt helyezett az IPv6. Ez fontos tényező a jelenleg egyre biztonság-tudatosabb felhasználók számára, akkor is, ha önmagában az IPv6 nem érdekli.
• Stabil implementációk léteznek, viszonylag régóta, amelyek gyakorlatilag már most képesek kiváltani az IPv4 implementációkat.
• Az autokonfigurációs mechanizmusok jelentős segítséget nyújthatnak a helyi hálózatok menedzselésében. A robosztusabb működés csökkentheti a hálózat működéséhez szükséges munka-igényt, így olcsóbbá téve az üzemeltetést.

1.5.2. Gyengeségek

A gyengeségek egyik fő oka az IPv6 koncepciójának kialakulása óta megváltozott körülményekben kereshető.

• A felhasználó számára gyakorlatilag „láthatatlan”. Annak ellenére, hogy ez műszaki szempontból hatalmas előny, másik oldalról nézve ez azt is jelenti, hogy a felhasználó nem érzékeli a különbséget, vagyis felhasználói oldalról nem várható a bevezetésre irányuló igény.
• Nem teljesek specifikációk és implementációk. Annak ellenére, hogy az IPv6 fejlesztése már több mint egy évtizede folyik, bizonyos specifikációk máig nem készek, illetve az implementációk nem tudtak megegyezni a megfelelő megoldásban. Ilyen például a multihoming vagy mobil ipv6 bizonyos kérdései .
• Csak részben megoldott a teljeskörű áttérés az IPv4 és az IPv6 világ között.

1.5.3. Lehetőségek

Az IPv6 előremozdítására több lehetőség is adódik.

• 3G mobil rendszerek. A 3G mobil rendszerek központi eleme az IPv6, ennek eredményeként a különböző eszköz gyártók Ipv6 támogatással készítik termékeiket. Így egy „normál” hálózat esetében tulajdonképpen minimális, vagy nulla többletköltséget jelent az IPv6 képes eszközök beszerzése.
• Hasonlóan az USA védelmi minisztériuma előírja az IPv6 használatát a jövőbeli fejlesztéseknél, ez szintén oda vezet, hogy a gyártók ezen előírás kielégítésére fejlesztik a termékeiket. (De emlékezzünk az ADA nyelvre és az OSI protokollra!)
• Új alkalmazások (pl. p2p) hatékonyabban működhetnek IPv6 felett. A multicast jellegű felhasználás (pl. video közvetítés) jobban idomulnak az IPv6 kifinomult multicast címzési struktúrájához.
• A szélessávú kapcsolatok terjedése a szolgáltatói címtartomány kifogyásához vezet. A NAT és más megoldások nem skálázhatóak ilyen méretekben, tehát a szolgáltatás fenntartása miatt más megoldásokra van szükség.

1.5.4. Fenyegetettségek

Az IPv6-ot alapvetően két oldalról érik fenyegetések: alternatív – régi vagy új – technológiák helyettesítik az IPv6 funkcióit, illetve ezek mellett nem lesz gazdaságilag indokolt az áttérés.

• Az IPv6 eredetileg kitűzött céljai közül sok okafogyottá váltak, illetve más, versenyképes megoldások születtek:
  • A címtartomány kérédésben a NAT – főleg a vállalati hálózatok esetében – vonzó alternatíva.
  • A hálózati szintű titkosítás (IPSec) gyakorlatilag csak VPN kiépítésére használt. A TLS, SSL megoldások szinte egyeduralkodóak lettek az alkalmazás szintű biztonságra és VPN megoldások esetében is fenyegetik az IPSec-et.
  • A címzési architektúrából adódó hierarchikus címzési rendszerek – politikai okok miatt – csak korlátozottan használhatóak.
  • A QoS igényeket a nyers sávszélesség-növelés olcsóbban oldja meg, mint más eljárások, így általános formában kevés igény van a megoldásra.
• Mivel nincs közvetlen felhasználói igény, illetve a szolgáltatók a felmerülő problémákat más „tűzoltás” jellegű módon oldják meg, ezért fennál a veszélye annak, hogy az IPv6 örökre kísérleti eszköz marad csak.

1.6. Igények

Ezek alapján vizsgáljunk meg néhány kérdést az IPv6-ra történő áttérésben!

1.6.1. Címzési kérdések

Az IPv6 által biztosított címtartomány a helyi hálózatokon belül gyakorlatilag minden problémát megold a címtartomány méretét tekintve. Ezzel kiküszöbölhetőek a NAT hátrányai. Fontos viszont felismerni hogy ez önmagában még nem feltétlenül vonzó. A Camp6 projekt felmérése szerint az üzemeltetők közül többen indokolták a NAT használatát azzal, hogy elrejti a belső hálózatot, mint azzal, hogy nincs elég IPv4 címük. Bár az elrejtés megoldható más tűzfal módszerekkel IPv6 alatt is, ez mindenképpen külön erőfeszítést igényel, tehát ezt a megoldást is kínálni kell a felhasználóknak, ha IPv6-tal szeretnék kiváltani a NAT-ot.

Az IPv6 címek használata gyakorlatilag csak DNS-sel együtt képzelhető el, vagyis csak akkor várható el az üzemeltetőktől az IPv6 alkalmazása, ha hatékony eszközt kapnak ezen címek kiosztására, kezelésére és DNS-sel történő összekapcsolására. Ehhez hatékony DHCPv6 megoldásra van szükség.

1.6.2. Implementációk

Az implementációk különböző fejlettségi szintekkel rendelkeznek. Az alap infrastruktúrát működtető implementációk nagyrészt rendelkezésre állnak. Más a helyzet az alkalmazásokkal. Mivel az átlagfelhasználót nem érdekli, hogy milyen protokollt használ az alkalmazása, ha az működik, ezért az IPv6 bevezetése csak abban az esetben lehetséges campus szinten, ha a felhasználók „kedvenc” alkalmazásai ugyanúgy működőképesek maradnak.

1.6.3. Üzemeltetés költsége

Az üzemeltetés költségét alapvetően két részre bonthatjuk:

• Az áttérés költsége
• A folyamatos üzemeltetés költsége

Az áttérés igen jelentős költségekkel járhat, ez főleg emberi munkaerő-igényben jelentkezik. A felmérés szerint az akadémiai hálózat üzemeltetői fele beható, egynegyede pedig általános IPv6 ismeretekkel rendelkezik. Ennek alapján viszonylag kis befektetés szükséges az ismeretek megszerzéséhez. Más környezetben is jellemző, hogy az üzemeltetők próbálnak előre felkészülni az Ipv6-ra átállásra ismeretszerzéssel.

Kérdés, hogy ha egyszer megtörtént az áttérés, akkor mekkora megtakarítást jelent az IPv6 használata.