Új generációs hálózati protokollok Tanulmány
Verzió száma: Kiadás dátuma: Azonosító:
1/92
V1 2008. május 29. EKK_ekozig_uj_generacios_protokollok_080529_V1
A dokumentum az Új Magyarország Fejlesztési Terv keretében, az Államreform Operatív Program támogatásával, az „Elektronikus közigazgatási keretrendszer” tárgyú kiemelt projekt megvalósításának részeként készült. A dokumentum elkészítésében részt vett:
2/92
Megnevezés Cím (Title) Kulcsszó (Subject) Leírás (Description)
Típus (Type) Forrás (Source) Kapcsolat (Relation) Terület (Coverage) Létrehozó (Creator) Kiadó (Publisher) Résztvevı (Contributor) Jogok (Rights) Dátum (Date) Formátum (Format) Azonosító (Identifier) Nyelv (Language) Verzió Státusz Fájlnév Méret Ár Felhasználási jogok
3/92
Leírás
Új generációs hálózati protokollok vizsgálata IPv6, IPv6, IP, hálózati protokollok, e-közigazgatás, operációs rendszer E-közigazgatási informatikai fejlesztési projektek hosszútávra készülnek, ezért mindenképpen figyelembe kell venni az aktuális technológiai trendeket. Jelen tanulmány megvizsgálja az IPv6 és az IPv4 közötti különbségeket és újdonságokat. Ezek alapján felvázolja az IPv6 lehetséges használhatóságát eközigazgatási fejlesztések során.
2008.05.29.
HU 1.0
Megnevezés 1. Elıszó 2. Bevezetés 3. Alkalmazási terület 4. Rendelkezı hivatkozások 5. Fogalom-meghatározások 6. A szabvány egyedi tartalma 7. Mellékletek
4/92
Leírás
Új generációs hálózati protokollok vizsgálata
5/92
Új generációs hálózati protokollok vizsgálata Vezetıi összefoglaló Az internet alkalmazások alapját jelenleg az IPv4 alkotja. Ez a protokoll a nyolcvanas évek eleje óta kitőnıen szolgálta az Internet fejlıdését a mai napig. A robbanásszerő fejlıdés azonban felszínre hozott olyan kérdéseket és problémákat, amelyekre annak idején
a
fejlesztık
nem
is
gondolhattak.
Ezek
a
jelenlegi
megoldások
továbbfejlesztését kényszerítik ki. Ezért a kilencvenes évek közepén megkezdıdött az új generációs protokoll, az IPv6 kidolgozása. E-közigazgatási informatikai fejlesztési projektek hosszútávra készülnek, ezért mindenképpen figyelembe kell venni az aktuális technológiai trendeket. Jelen tanulmány megvizsgálja az IPv6 és az IPv4 közötti különbségeket és újdonságokat. Ezek alapján felvázolja az IPv6 lehetséges használhatóságát e-közigazgatási fejlesztések során. Az IPv6 szinte minden területen fejlettebb az IPv4-nél. Fıbb elınyei az átdolgozott címzési architektúra, az adatbiztonság, a teljesítmény és a kezelhetıség. Az áttérés koránt sem problémamentes és kérdésesek az áttérés idıtávja és mozgatórugói is. Látszik, hogy az eredetileg gyorsra tervezett bevezetés elhúzódik, többek között azért, mert megváltoztak a hajtóerık is. A címtartomány fogyása helyett egyre inkább a biztonság, a teljesítmény és az egyszerő üzemeltetés lép. Szinte már minden jelentıs gyártó rendelkezik IPv6 implementációval és megkezdıdött az IPv6 címek allokálása is. Még mindig váratnak azonban magukra az igazi IPv6 alkalmazások. A kutatási és oktatási szférában egyre több szolgáltató foglalkozik aktívan az IPv6-tal.. Az utóbbi évek során egyre több a hivatalosan is támogatott IPv6 implementáció és több kereskedelmi szolgáltató kezdte meg a kísérleti IPv6 szolgáltatás
6/92
Tartalom Bevezetés ...................................................................................................................... 10 Jelenlegi IPv4 hálózati technológiák ............................................................................ 11 Az IPv4 protokoll ...................................................................................................... 11 Az IPv4 hálózatok ..................................................................................................... 13 Internet ...................................................................................................................... 13 Intranet ...................................................................................................................... 13 VPN-ek...................................................................................................................... 14 Szolgáltatók és felhasználók ..................................................................................... 14 Alkalmazott technológiák ............................................................................................. 16 Lokális hálózatok ...................................................................................................... 16 Nagytávolságú hálózatok .......................................................................................... 16 Az IPv6 bevezetésének mozgatórugói .......................................................................... 18 Az IPv4 problémái .................................................................................................... 18 Címtartomány ........................................................................................................ 18 Menedzselhetıség.................................................................................................. 20 Biztonság ............................................................................................................... 20 Quality of Service.................................................................................................. 21 Teljesítmény .......................................................................................................... 21 Mobilitás ................................................................................................................ 22 Az IPv6 által kínált megoldások ............................................................................... 22 Címzési architektúra .............................................................................................. 22 Címtartomány mérete ........................................................................................ 22 Cím típusok........................................................................................................ 22 Unicast cím..................................................................................................... 23 Anycast cím.................................................................................................... 23 Multicast cím.................................................................................................. 23 Cím formátumok................................................................................................ 24 A cím azonosítója........................................................................................... 24 Unicast formátumok....................................................................................... 25 Az interfész azonosító .................................................................................... 25 Aggregálható globális unicast cím ................................................................. 26 Kompatibilitási címek .................................................................................... 27 Lokális címek ................................................................................................. 28 Multicast címek .............................................................................................. 29 Speciális címek............................................................................................... 30 Címek jelölés módja .......................................................................................... 30 Autokonfiguráció................................................................................................... 31 Konfigurációs lépések ........................................................................................... 31 Állapotmentes konfiguráció............................................................................... 31 Állapottartó konfiguráció................................................................................... 32 Automatikus rekonfiguráció .................................................................................. 32 IPSec ...................................................................................................................... 33 Az IPSec keretrendszer ...................................................................................... 34 7/92
AH...................................................................................................................... 34 ESP..................................................................................................................... 35 Kulcs menedzsment ........................................................................................... 35 QoS támogatás....................................................................................................... 35 Teljesítménynövelı megoldások ........................................................................... 36 Nyers teljesítmény ............................................................................................. 36 A címzés és a teljesítmény................................................................................. 36 Fejlécek kezelése ............................................................................................... 37 Csomagok tördelése ........................................................................................... 38 IPv6 mobilitás........................................................................................................ 39 Az IPv6 mobilitás .............................................................................................. 39 Különbségek az IPv4-hez képest ....................................................................... 39 IPv6 kérdések ............................................................................................................ 40 Az IPv4 és IPv6 által támogatott alkalmazások............................................................ 42 Hagyományos alkalmazások ..................................................................................... 42 Fontosabb alkalmazások IPv6 képessége.............................................................. 42 Új alkalmazások ........................................................................................................ 43 A nemzetközi szabványosítás helyzete......................................................................... 47 Az IPv6-tal foglalkozó szabványosító szervezetek................................................... 47 Az IPv6 szabványok.................................................................................................. 47 A bevezetéshez szükséges hazai szabványosítás .......................................................... 49 Technológiai kérdések............................................................................................... 49 Adminisztratív kérdések............................................................................................ 49 Címtartomány kérdése........................................................................................... 49 Áttérési módszerek ................................................................................................ 50 A gyártók termékei ....................................................................................................... 51 IPv6 megvalósítások ................................................................................................. 51 Hoszt jellegő termékek .......................................................................................... 51 Microsoft............................................................................................................ 52 Microsoft Research IPv6 csomag .................................................................. 52 Microsoft IPv6 Technology Preview for Windows 2000 .............................. 53 Microsoft Windows XP.................................................................................. 53 Microsoft Windows Vista .............................................................................. 53 Kame / FreeBSD ................................................................................................ 53 Inria .................................................................................................................... 55 Linux .................................................................................................................. 56 Sun ..................................................................................................................... 56 HP ...................................................................................................................... 57 FreeBSD (NetBSD, OpenBSD)......................................................................... 57 Apple.................................................................................................................. 59 IBM .................................................................................................................... 59 Router jellegő termékek ........................................................................................ 59 Cisco .................................................................................................................. 59 Hitachi................................................................................................................ 62 Juniper................................................................................................................ 63 Mrt...................................................................................................................... 63
8/92
Zebra .................................................................................................................. 63 Összehasonlítások.................................................................................................. 64 A külföldi szolgáltatók migrációs stratégiái ................................................................. 65 Helyzetkép................................................................................................................. 65 Néhány példa ......................................................................................................... 66 Cím allokáció ............................................................................................................ 67 A migrációs lépések és környezet................................................................................. 69 Az áttérés fázisai ....................................................................................................... 69 Áttérési eszközök ...................................................................................................... 69 Dual-stack implementációk ................................................................................... 69 AIIH....................................................................................................................... 70 Bump-in-the-stack (BIS) ....................................................................................... 71 Bump In the Api (BIA).......................................................................................... 72 Tunneling............................................................................................................... 72 Automatikus tunneling....................................................................................... 73 Konfigurált tunneling......................................................................................... 74 Tunnel broker..................................................................................................... 75 Dinamikus tunneling.......................................................................................... 75 DSTM ................................................................................................................ 75 Teredo – IPv6 over UDP over NAT .................................................................. 75 6to4 .................................................................................................................... 76 6over4 ................................................................................................................ 77 Transzlátorok ......................................................................................................... 77 ALG (Appliation Level Gateway) ..................................................................... 79 Socks .................................................................................................................. 79 TRT (Transport Relay Translator)..................................................................... 79 NAT (Network Address Transzlation) .............................................................. 80 NAT-PT (NAT – Protocol Trasnaltor) .............................................................. 80 Fejléc konverzió................................................................................................. 80 SIIT (Stateless IP/ICMP Translator) ................................................................. 80 Összegzés .................................................................................................................. 81 Az IPv6 az e-közigazgatásban ...................................................................................... 82 Összefoglalás ................................................................................................................ 83 Rövidítések jegyzéke .................................................................................................... 84 Hivatkozások................................................................................................................. 85
9/92
Bevezetés Az Internet közel negyven éves történelemre tekint vissza, amely idı alatt rendkívüli fejlıdésnek lehettünk tanúi. A negyven évbıl az utóbbi huszonöt év a TCP/IP protokollcsalád jegyében telt. Nyugodtan kijelenthetjük, hogy az Internet sikerének egyik fı oka ez a rendkívül rugalmas és nagy teljesítménnyel bíró protokoll, amely minden internetes alkalmazás, így az e-közigazgatási megoldásoknak is az alapját adja. A TCP/IP gyakorlatilag változatlan formában van jelen a kezdetektıl és annak ellenére, hogy még most is kiválóan teljesíti feladatát, az igények változása révén kiütköztek hiányosságai is. A jelenlegi IPv4 protokoll leváltására dolgozta ki az IETF irányításával az Internet közössége az IPv6 protokollt. Az IPv6 nem csak a címzés, de sok más téren is újítást hoz az IPv4-hez képest. Az áttérés hosszú folyamat lesz és ne is mindig fog problémamentesen folyni. Jelenleg az IPv6 funkcionalitása már képes túlszárnyalni az IPv4-et, de vannak még nyitott kérdések és valódi, üzemszerő kipróbálás is várat magára. E-közigazgatási informatikai fejlesztési projektek hosszútávra készülnek, ezért mindenképpen figyelembe kell venni az aktuális technológiai trendeket. Jelen tanulmány megvizsgálja az IPv6 és az IPv4 közötti különbségeket és újdonságokat. Ezek alapján felvázolja az IPv6 lehetséges használhatóságát e-közigazgatási fejlesztések során.
10/92
Jelenlegi IPv4 hálózati technológiák Az jelenleg használt IP technológia alapjait a 70-es években kidolgozott TCP/IP protokoll adja. Az IP hálózatok technológiájában két irányban történt fejlıdés a kezdetekhez képest. Egyik oldalon változott az IP (OSI protokollrétegek szerint hálózati szint) alatti rész, teljesen új hálózati eszközök jelentek meg, amelyek újításokat pl. igényeltek teljesítmény és útválasztás oldalon. Másrészt az IP „feletti” rész, az alkalmazások és az általuk használt hálózati szolgáltatások olyan igényekkel jelentkeztek, amelyek az IP megalkotásakor még nem is jelentkeztek. Ennek ellenére a TCP/IP protokoll csomag magja gyakorlatilag változatlanul képes a mai napig megfelelni az elvárásoknak. Az IPv4 protokoll
Az IPv4 protokoll (TCP/IP) egy hálózati protokoll család, amely alapját adja a globális és lokális Internet hálózatnak. Az IPv4 fı jellemzıi: • A
protokoll
alapvetı
feladata,
hogy
összeköttetés
mentes,
vagy
kapcsolatorientált összeköttetést biztosítson két csomópont között. A TCP/IP hálózat általánosságban összekapcsolt hálózatokból áll. A protokoll nagyon jól skálázható, képes a globális Interneten és kis belsı hálózatokon is mőködni. • Hálózati réteg protokollja az IP (Internet Protocol). Az IP 32 bites, globálisan egyedi címeket használ az egyes csomópontok (pontosabban a csomópontok hálózati interfészének azonosítására). Az IP cím egy – esetlegesen tovább bontott – hálózati címbıl és egy ezen a hálózaton belüli hoszt címbıl áll. A hálózati cím azonosítja a hálózatot. Az adott hálózati címmel ellátott forgalom a rendszer által a megfelelı hálózatba lesz irányítva. A csomagok kézbesítése a „best effort” elv alapján történik, a rendszer nem garantálja sem a csomagok megérkezésének sorrendjét, sem magát a megérkezést. A címek a hálózat mérete alapján eredetileg osztályokba voltak sorolva, késıbb bevezették az osztálynélküli címeket is, amelyeknél a hálózati rész mérete szabadon választható. Az útválasztást a különbözı útválasztási protokollok segítik.
11/92
Megkülönböztethetünk Interior és Exterior Gateway protokollokat, attól függıen, hogy autonóm rendszerek közötti vagy azon belüli útválasztásról van szó. • Az IP nem definiál a hálózati rétegnél alacsonyabb szintet, ennek megfelelıen változatos fizikai rétegen képes mőködni, viszont ennek megoldása minden esetben egyedi. Ethernet esetében pl. az ARP protokoll használatos, amely végzi az IP és az Ethernet címek közti feloldást. Ennek megfelelıen az ARP nem tisztán IP protokoll. • Az Internet protokoll felsıbb szintjét képviseli a TCP és az UDP. A TCP megbízható, kapcsolatorientált összeköttetést, még az UDP kapcsolat nélküli datagram szolgáltatást nyújt. • Az UDP nem megbízható datagram szolgáltatást nyújt. A csomag az IP cím által meghatározott hosztra és azon belül az UDP port által meghatározott processzhez kerül kézbesítésre. Sem a csomagok megérkezése, sem sorrendjük nem biztosított. Az UDP tipikus alkalmazása egyrészt a különbözı multimédia adatok átvitele, másrészt bizonyos más szolgáltatások (pl. DNS) is. • A TCP megbízható, kapcsolatorientált összeköttetést nyújt. A csomag az IP cím által meghatározott hosztra és azon belül a TCP port által meghatározott processzhez kerül kézbesítésre. A protokoll biztosítja az elveszett, duplázódott vagy rossz sorrendő csomagok helyes kezelését. A legtöbb hálózati alkalmazás a TCP-t használja. • A hálózat mőködéséhez szükséges egyéb protokollok, mint pl. az ICMP bizonyos menedzselési feladatokat lát el, a DNS a név-IP cím feloldást kezeli egy elosztott adatbázis segítségével, a DHCP konfigurációs információk kiszolgálását végzi. • A TCP/IP protokollcsaládnak nem szerves részei a rá épülı alkalmazási protokollok, de gyakorlatilag kötıdnek a TCP/IP-hez. Például: SMTP levél továbbítására, HTTP a web forgalomra, FTP állományok továbbítására, SSL/TSL a hitelesített és titkosított kapcsolatra.
12/92
Az IPv4 hálózatok
Az IP protokoll család skálázhatóságánál fogva alkalmasak akár globális, akár helyi hálózatok kialakítására. A globális Internet nem más, mint helyi hálózatok összekapcsolásából eredı hálózat közötti (internetworking) rendszer. Internet
A globális Internet a nemzeti és egyéb helyi hálózatokból alakult hálózat. Különlegessége, hogy irányítása csak nagyon kevésbé centralizált. A technikai fejlesztés és az IP címek valamint domain nevek osztása történik centralizálthierarchikus rendszerben, azonban az üzemeltetés és adminisztráció a helyi szolgáltatók és tulajdonosok kezében van. Az Internet növekedése gyakorlatilag majdnem exponenciális, mint ahogy ezt az ábra is mutatja [ISCHC]. Jól látszik 1983-nál a fejlıdés megugrása. Ekkor vezették ugyanis be a TCP/IP-t a korábbi NCP protokoll helyett, amely nem volt skálázható az elvárt mértékben. A TCP/IP eddig 6 nagyságrenden keresztül szinte problémamentésen terjeszkedett.
19 69 19 72 19 75 19 78 19 81 19 84 19 87 19 90 19 93 19 96 19 99 20 02 20 05 20 08
1 000 000 000 100 000 000 10 000 000 1 000 000 100 000 10 000 1 000 100 10 1
1. ábra: Az Internet mérete csomópontokban Intranet
A belsı vállalati hálózatok összefoglaló neve az intranet. Ez gyakorlatilag Internet technológián alapuló vállalati hálózatok. Elsırendő szempont a biztonságos és megbízható mőködés, valamint a lehetıség szerint alacsony üzemeltetési költség.
13/92
Az intranet elviekben nem különbözik az Internettıl, azonban nincs korlátlan kapcsolata az Internethez, rendszerint valamilyen biztonsági szőrın (tőzfal, proxy) kapcsolódik. VPN-ek
Az Intranetek használata során felmerült az igény a földrajzilag távol lévı belsı hálózatok összekapcsolására. Hagyományosan erre a célra dedikált kapcsolatot, mint például bérelt vonalat használtak. Azonban az amúgy is szükséges Internet kapcsolat felvetette annak a lehetıségét, hogy az Interneten keresztül összekötve a helyi hálózatokat, virtuális magán hálózatot hozzanak létre (VPN – Virtual Private Network). A VPN megvalósítása során a két részhálózatot úgy kapcsolják össze, hogy mindkét hálózat Internethez csatlakozó pontján egy-egy VPN eszköz helyezkedik el. A VPN eszköz a kimenı forgalmat titkosítja és IP csomagokba csomagolja (tunneling), a bejövı fogalmat kititkosítja és továbbítja a hálózatba. Virtuális magánhálózat Hálózat B
Hálózat A VPN
Internet
VPN
2. ábra: Virtuális magánhálózat A VPN-ek alapvetı részei az Intraneteknek, mert igen költséghatékony megoldást kínálnak az egybefüggı vállalati hálózat kialakítására. Szolgáltatók és felhasználók
Az IP hálózatok szempontjából definiálhatunk szolgáltatókat és felhasználókat. A szolgáltatók
(ISP-Internet
Service
Provider)
Internet
hozzáférést
adnak
a
felhasználóknak. Ebbıl a szempontból a felhasználó további szolgáltató lehet és így tovább, vagyis a szolgáltatók is egyfajta hierarchiát alkotnak. Az Internet mőködésének és adminisztrálásának egyik alapelve a feladatok hierarchikus delegálása. Ennek megfelelıen egy felsıbb szintő szolgáltató a
14/92
hozzáféréssel egy IP cím tartomány és DNS delegálást szolgáltat. Ezek további kezelése, tehát pl. a címek további szétosztása a kapott tartományon belül szabadon választható a felhasználó által. Az IP hozzáférési lánc legvégén a végfelhasználók állnak, akik vagy egyetlen IP cím birtokába jutnak (pl. egyéni modemes felhasználó), vagy a címtartományt teljes egészében saját céljukra használják. Teljesítmény és adminisztrációs szempontból célszerő a szolgáltatónak, ha a címtartományokat aggregálni tudja, azaz az általa kiosztható címek egy folytonos blokkot alkotnak. Biztonsági szempontból a szolgáltatónak figyelnie kell, hogy csak az általa osztott címtartományból érkezı forgalmat fogadjon el. A szolgáltatók legfelsı szintje a gerinchálózati szolgáltató. Ezek rendszerint világmérető hálózattal rendelkeznek, de csak további szolgáltatóknak biztosítanak hozzáférést. Az alacsonyabb szintő szolgáltatók egymással is cserélhetnek forgalmat (peering), abból a célból, hogy a gerinc megkerülésével közvetlenül kapcsolódjanak egymáshoz.
15/92
Alkalmazott technológiák Az Internet technológiák eleve heterogén hálózati környezetre lettek kitalálva. Mind a lokális hálózatok, mind a nagytávolságú hálózatok esetében a legkülönbözıbb technológiák használhatóak és használatosak. Az Internet szabványok definiálják a különbözı hálózati közegeken történı IP átvitelt, azonban nem írnak elı kötelezı megoldást. Az IP szint alatti rétegre (OSI: fizikia és adatkapcsolati) gyakorlatilag a minimális csomagméret az egyetlen elıírás. Ez IPv6 alatt egyébként nagyobb, 1280, mint IPv4nél, tehát bizonyos átviteli közegen IPv6 esetén változásokra kell számítani. Mind IPv4, mind IPv6 esetén, ha a minimális csomagméret nem teljesíthetı, akkor az adatkapcsolati réteg felett, de az IP szint alatt kiegészítı megoldásokat kell alkalmazni. Lokális hálózatok
Lokális hálózatokban szinte egyeduralkodó az Ethernet technológia. Többféle, 10 Mbps – 10Gbps sebességgel, réz, üveg médián áll rendelkezésre. Az Ethernet kiemelkedı elınye a rendkívül olcsó megvalósítás és üzemeltetés. A hálózat teljesítıképessége megfelelı és – fıleg switchelt háló esetén - jól skálázható. Hasonló technikával vezeték nélküli megoldások is léteznek 1->100 Mbps sebességgel (Wifi, Wimax, stb.). Az IP közvetlenül továbbítható az Ethernet (vezetékes és vezetéknélküli) csomagokban. IPv4 és IPv6 esetében is gond nélküli az Ethernet használata. Az Ethernet mellett ma már sokkal kisebb jelentıséggel szerepel a TokenRing, az ATM és még néhány egyéb technológia. Nagytávolságú hálózatok
A nagytávolságú hálózatokban nagy számú technológia és teljesítményszint áll rendelkezésre. Az IPv4-IPv6 áttérés szempontjából sokkal kevésbe a fizikai hálózati technológiák a kérdésesek, mint inkább az ezeken a WAN-okon támogatott routing és egyéb protokollok.
16/92
A BGP4+ protokoll használata gyakorlatilag elengedhetetlen, és természetesen minden gyártó által támogatott. Hasonlóan kérdéses az MPLS használata, amely jelentıs teljesítménynövekedést képes okozni, és ráadásul IPv6 esetében egyfajta áttérési eszköznek is használható, hiszen csak az hálózat peremén lévı routereknek kell támogatni az IPv6-ot, a belsı forgalom már a label-switching segítségével megy. Természetesen MPLS nélkül is lehet IPv6 szolgáltatást nyújtani, hiányát teljesítmény szinten bizonyos mértékben ellensúlyozni képes az IPv6 megnövekedett routing teljesítménye. Kisebb igények, illetve egyéni felhasználók számára szolgált a telefonos-modemes kapcsolat, az ISDN, a különbözı xDSL megoldások és a kábel TV.
17/92
Az IPv6 bevezetésének mozgatórugói Az IPv4 problémái
Az IPv4 alapvetıen beváltotta, sıt messze túlteljesítette a tervezésekor támasztott elvárásokat. Mégis vannak olyan pontok, amelyek a mai hálózati környezetben hátráltatják a további fejlıdést vagy költséges kerülıutak megtételére kényszerítik a szolgáltatókat és a felhasználókat. Az 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 korlátokat jelent a további fejlıdés számára. • Menedzselhetıség – az IPv4 hálózatok menedzselhetısége gyakran többlet munkát és költséget jelent. • Biztonság – az IPv4-bıl koncepcionálisan is hiányoztak a biztonsági megoldások. • Quality of Service – újonnan fellépı igény, amelynek teljeskörő támogatása problematikus jelenlegi protokollban. • Teljesítmény – a nagymérető és nagyteljesítményő hálózatokban szők keresztmetszetet jelenthetnek az IPv4 bizonyos megoldásai. • Mobilitás – a mobil üzem megvalósítása IPv4 alatt körülményes Az IPv6 által kínált megoldások részletes megvizsgálásához érdemes részletesen feltárni az IPv4 hiányosságait! 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 232, azaz 4294967296 darab egyedi IP címet jelenthet elméletben. Ennyi cím azonban nem osztható ki, ugyanis az IP cím egy hálózati és egy hoszt (gép) 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.
18/92
Az akkori elképzelés az volt, hogy három nagy kategóriába besorolható hálózatok fogják alkotni az Internetet, és ennek megfelelı címzési osztályokat alakítottak ki: • A osztályú címek: hatalmas mérető hálózatok számára, hálózatonként több mint 16 millió számítógéppel. A cím hálózati része 7 bites mennyiség1, tehát összesen 127 A osztályú cím létezik. • B osztályú címek: közepes hálózat, közepes mennyiségő géppel. A hálózati cím 14 bites, tehát 16384 hálózat lehetséges, hálózatonként kb. 65000 géppel. • C osztályú címek: kis hálózat, kevés géppel. A hálózati cím 22 bites, tehát több mint 4 millió ilyen hálózat lehetséges, hálózatonként 254 géppel2. Az alapvetı cím osztályokon kívül még létezik kísérleti és egyéb fenntartott tartomány is. A hálózatok méretét és az adott osztályban rendelkezésre álló hálózati címek számát összevetve rögtön szembetőnik a probléma. Az A osztályú hálózatokból világméretően kevés van, és az a kevés is már mind foglalt. Ugyanakkor az A osztály tulajdonképpen felesleges, mert egy ilyen mennyiségő gépet egy hálózatban, mindennemő hierarchia vagy particionálás nélkül kezelı megvalósítás a gyakorlatban kezelhetetlen lenne. A B osztályú címek tulajdonképpen praktikusak, de mostanra már ezekbıl is nagyon kevés szabad áll rendelkezésre. A C osztály viszont az A osztály problémáinak a komplementerét jelenti: mennyisége elegendı, de mérete sokszor kicsi. Ugyanakkor az osztályba sorolt címek meglehetısen pazarló allokációhoz vezettek, a valóságban rendelkezésre álló címtartomány néhány százmillióra tehetı. 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
A címek elsı (A osztály), illetve elsı kettı bitje jelzi az osztályt, tehát ezekkel csökken az effektív cím bitek száma az elméleti 8, 16 és 24-rıl. 2 Azért nem 28=256, mert hálózatonként legalább két cím (a csupa 0 és a csupa 1 bit értékő) nem osztható ki hoszt címként.
19/92
A
legnagyobb
„címfalók”,
a
vállalati
hálózatok
problémáit
enyhítette
a
címtranszformáció (NAT) elterjedése, amely nagyságrendekkel csökkentette ezeknek a hálózatoknak a cím igényét. A NAT ugyan sok hátránnyal jár – bár vannak bizonyos elınyei is – mégis olyan mértékben elterjedt, hogy az IPv4 címek fogyásának a réme tulajdonképpen eltőnt. Ugyancsak hiányzik az átfogó multicast (üzenetszórás) támogatás, ezt csak utólagos „barkács” megoldásokkal lehetett megvalósítani, pedig jelentısége egyre nı. Mindezek mellett az IPv4 címzi architektúrájának nem csak magára a címtartományra van kihatással, hanem pl. a hálózat teljesítı képességére is, amelyrıl majd késıbb lesz szó. 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. 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. Átfogó biztonsági rendszer azonban csak az IPv6-ban kidolgozott IPSec vissza20/92
adaptálásával lett, azonban az IPv4 esetében ez sem teljeskörő. Nem lehetséges u.i. a legalacsonyabb szintő hálózati szolgáltatásokra (pl. DHCP, ARP) alkalmazni. 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. Bár egyre inkább úgy tőnik, hogy a QoS, mint közvetlen szolgáltatás veszít a jelentıségébıl, mivel gyakran egyszerőbb nagyobb teljesítményő hálózatot, eszközt beépíteni, mint a meglévıkbıl kihozni a kívánt igényt, ennek ellenére továbbra is meg lenne az igény az átfogó megoldásra. Teljesítmény
Az utóbbi években a hálózati eszközök nyers teljesítménye olyan színtere 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, routingtá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.
21/92
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. Az IPv6 által kínált megoldások
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. Címzési architektúra Címtartomány mérete
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ıtt3, tehát a rendelkezésre áll 2128≈3,4⋅1038 darab cím. [RFC2460][RFC2373][RFC3513] [RFC4291] 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. Cím típusok
Azért, hogy ne következzen be az IPv4-nél egyszer elkövetett hiba még egyszer, az IPv6 radikálisan más címkiosztási stratégiát használ és a címek értelmezésében is eltér az IPv4-tıl. Az az alapvetı tény, hogy a címek továbbra is interfészekhez vannak rendelve, megmaradt, tehát továbbra is interfészek és nem hálózatra kapcsolt eszközök címérıl beszélünk, noha természetesen az egy interfésszel rendelkezı berendezések esetén a kettı ugyanazt jelenti. 3
Ez az elméleti címteret 292 = 79228162514264337593543950336 szorosára növeli!
22/92
Amíg IPv4 esetében rendszerint egy interfész egy címmel rendelkezett (bár volt lehetıség több cím hozzárendelésére is), addig IPv6-ban általános a több cím használata, sıt normális esetben egy interfész több – különbözı célú – címmel rendelkezik. A csomag továbbítása alapján az IPv6-os címeket három csoportba sorolhatjuk: • egyedi cím (unicast cím) • bárki cím (anycast cím) • csoport cím (multicast cím) A unicast és az anycast cím értelmezésbeli megkülönböztetést jelent, míg a multicast cím szintaktikusan is megkülönböztethetı. Unicast cím
Ez a típus hasonlít leginkább a hagyományos IPv4-es címekre. Az unicast címre küldött csomagok arra az egyetlen interfészre fognak megérkezni, amelyhez ez a cím van hozzárendelve. Az unicast cím az értelmezési tartományán belül (lokális, globális) egyértelmően meghatároz egy interfészt, és azon keresztül a egy hozzá tartozó eszközt. Anycast cím
Az anycast cím újdonság, az IPv4-ben hasonló fogalom nincsen. Anycast címeket interfészek csoportjához rendelhetünk. Ezeknek az interfészeknek nem feltétlenül kell ugyanazon a gépen, sıt ugyanazon a hálózatban lenniük. Az ilyen címre küldött forgalmat legalább egy interfésznek meg kell kapnia abból a csoporttól, amely ezzel a címmel rendelkezik. Az útválasztáskor általában a legközelebbi interfészre irányítjuk ezeket a csomagokat, ilyen módon például redundáns kapcsolat építhetı ki. Az anycast és a unicast címek közötti megkülönböztetés a hálózat (fıleg az útválasztás) konfigurációjából ered. Multicast cím
Az IPv4 a broadcast címet ismerte, amely alkalmas volt egy hálózaton belüli összes állomás megszólítására. Az IPv6 generalizálta ezt és bevezette a multicast címet. A multicast esetében az erre a címre irányuló forgalom minden, ezzel a címmel
23/92
rendelkezı interfészhez továbbítva lesz. A broadcast nem jelent külön címzést, hanem a multicast speciális esete. A multicast cím egyben külön formátummal is rendelkezik. Cím formátumok
A címek – az elıbbiektıl eltérı – csoportosítása a formátum alapján történik. A formátum a cím felhasználási célját jellemzi. A cím azonosítója
A 128 bites cím elsı néhány bitje adja a formátum prefixet (format prefix)4, azaz a teljes címteret felosztjuk különbözı cím formátumokra. Ez azonban nem méretbeli felosztás, mint az IPv4 címzési osztályai, hanem felhasználás szerinti felosztás. Általánosságban tekintve a következı megkülönböztetéseket tudjuk tenni az IPv6-os címek típusában: Bináris prefix 000…00 000…01 11111111 1111111010 1111111011 Minden más
IPv6 cím Típus ::/128 Nem specifikált ::1/128 Saját (loopback) FF00::/8 Multicast FE00::/10 Link-local FEC0::/10 Site-local Globális unicast és anycast címek
1. táblázat: Cím típusok Ezen belül további felosztást lehet tenni, a táblázat bemutatja a jelenleg definiált formátum prefixeket [RFC2373]. Formátum Prefix
0000 0000 0000 0000 0000 0000 0001 001 010 4
0000 0001 001 010 011 01
Cím Foglalt Nem használt NSAP kompatibilitási IPX kompatibilitási5 Nem használt Nem használt Nem használt Aggregálható globális unicast Nem használt
A formátum prefix nem keverendı össze a hálózati címet jelentı prefixszel! A félreértések elkerülése végett az RFC-2373-at felváltó, jelenleg tervezet státusú szöveg elhagyta a formátum prefix terminológiát és a bináris prefixet használja. 5 A tervezet szerint ez a címtartomány „Jelenleg nem használt” minısítéső lesz.
24/92
Formátum Prefix
011 100 101 110 1110 1111 1111 1111 1111 1111 1111 1111
0 10 110 1110 0 1110 10 1110 11 1111
Cím Nem használt Nem használt Nem használt Nem használt Nem használt Nem használt Nem használt Nem használt Nem használt Link-Local unicast Site-Local unicast Multicast
2. táblázat: formátum prefixek Unicast formátumok
A legegyszerőbb cím a minden belsı struktúrát mellızı, 128 bites cím: 128 bit cím
Ebben az esetben az állomásnak nincs tudomása a cím felépítésrıl. Ilyen címek csak a legegyszerőbb esetekben fordulnak elı. Egy kicsit több információt hordoz a hálózati prefixet is tartalmazó cím: n bit prefix
128-n bit interfész azonosító
Ez cím tartalmaz egy hálózat azonosítót, amely valamilyen, a hálózati hierarchiára jellemzı módon van kialakítva, és egy, az ezen a hálózaton belül elhelyezkedı interfész azonosítóját. Ez a cím formátum nagyon hasonlít az általános IPv4 címekre, amelyek szintén egy hálózati és egy hoszt részbıl állnak. Azokkal ellentétben azonban a hálózati prefix is lehet strukturált és a hoszt (interfész) azonosító létrehozása teljesen más módon történik Az interfész azonosító
Az interfész azonosítónak az adott hálózati szegmensen – amelyre az adott prefix érvényes – egyedinek kell lennie. A 000 kezdető címek kivételével minden unicast címben az interfész azonosító 64 bites és az EUI-64 formátumot követi:
25/92
xxx
maradék 61 bit prefix
64 bit interfész azonosító
Az EUI-64 formátum valamilyen interfész jellemzıbıl (pl. 48 bites MAC cím) alakul ki [EUI64]. Ugyan ez a felosztás azonnal felére csökkenti a rendelkezésre álló unicast címtartományt, mégis több jelentıs elınnyel jár: • Az Interfész azonosító mindig fix mérető, ez megkönnyíti a konfigurálást és az útválasztást többek között • Az EUI-64 formátum alkalmazása egyszerősíti az automatikus konfigurálást és az autonóm mőködést Az EUI-64 formátumnak megfelelıen interfész azonosító is lehet globálisan egyedi, ez késıbbi fejlesztésékre ad lehetıséget. Aggregálható globális unicast cím
A globális unicast címek a következı felépítést követik: globális útválasztási prefix
alhálózat
64 bit interfész azonosító
A globális prefix valamilyen, rendszerint hierarchikus felépítéső azonosító, amely globálisan egyedi és meghatározza az adott szervezetnek allokált hálózat címét. Az alhálózati rész, amely szintén lehet hierarchikus felépítéső, már a szervezeten belüli további tagolást tesz lehetıvé. Azaz az adott szervezetnek 64+alhálózat bitnyi saját címtartománya van [RFC2374]. A globális unicast címek speciális változata az aggregálható globális unicast cím (Aggregatable Global Unicast Address – AGUA). Ez a formátum szolgált tulajdonképpen a hierarchikusan felépített, különbözı szintő szolgáltatókból és felhasználókból álló hálózat mőködtetésére. Az általános felépítés is a hierarchiát tükrözi:
001
26/92
TLA ID 13 bit
res 8 bit
NLA ID 24 bit
SLA ID 16 bit
64-n bit interfész azonosító
A cím a 001 azonosítóval (formátum prefix) kezdıdik, tehát a teljes lehetséges IPv6 címtér 1/8-át jelenti. Ezt követi a 13 bites TLA ID (Top Level Aggregate ID – legfelsı szintő aggregáció azonosító), a 8 bites tartalék, a 24 bites NLA ID (Next Level Aggregate ID – következı szintő aggregáció azonosító). Az ezekbıl álló, a publikus topológia részét képezı tartományt tovább osztja az adott szervezeti egységre jellemzı SLA ID (Site Level Aggregate ID – helyszíni aggregáció azonosító) és a 64 bites interfész azonosító. A gyakorlatban a TLA-k a legfelsı szintő gerinchálózati szolgáltatókhoz tartoznak. Mérete célzatosan korlátozott, azért, hogy a gerinchálózati útválasztók tábláinak méretét szükségtelenül ne növekedjen. Szükség esetén a tartalékból növelhetı a mérete vagy újabb formátum prefixek vezethetık be. Az NLA a következı szintő szolgáltatók tartománya, amely a szolgáltató kívánsága szerint tovább bontható, tehát a 24 biten belül több hierarchia is kialakítható:
001
TLA ID 13 bit
res 8 bit
1. N L A ID
2. NL A ID
3. N L A ID
SLA ID 16 bit
64-n bit interfész azonosító
Hasonlóan az SLA rész, amely tulajdonképpen a végfelhasználói hálózatot jellemzi szintén bontható további alhálózatokra. Az aggregálható globális unicast címek két nagy elınnyel rendelkeznek: • felépítésük követi a hálózat topológiáját, amely az útválasztás teljesítményében nagy nyereséggel jár • a hierarchikus felépítés miatt szolgáltató váltás esetén a címnek csak a hierarchiában feljebb elhelyezkedı része változik, tehát saját hálózatunk átszámozását egyszerő kivitelezni. Kompatibilitási címek
Az IPv6 címtartományból több rész is kompatibilitási célokra van fenntartva. A 00000000 kezdető fenntartott tartományban van az IPv4 kompatíbilis IPv6 cím, illetve az IPv6-ba ágyazott IPv4 cím.
27/92
Az IPv4 kompatibilis cím az tunneling során szerepel a végpontok címzésére: 96 bit 0
32 bit IPv4 cím
Az IPv6-ba beágyazott IPv4 cím az áttérési mechanizmusokban játszik szerepet. 80 bit 0
16 bit 1
32 bit IPv4 cím
Más hálózati protokollokkal kapcsolatban is definiáltak kompatibilitási címeket. Az NSAP kompatíbilis címeket az RFC1888 írja le, az IPX kompatíbilis címek használata még nincs definiálva és valószínőleg nem is lesz, mivel a címzési architektúráról készülı új RFC már nem tartalmazza. Lokális címek
IPv4-es eszköz csak akkor képes IP kommunikációra, ha kézi, vagy automatikus úton IP címet rendelünk interfészéhez. Általában ez az a cím, amelyen keresztül a globális kommunikáció megvalósul. Gyakran szükség lehet azonban, hogy az adott eszköz autonóm módon is legyen képes legalább lokális kommunikációra. Ezt a célt szolgálják az IPv6 lokális címek. Két típusuk van, amelyek csak a hatókörben különböznek: • Link-local címek: csak azon a szegmensen belüli kommunikációra szolgálnak, amelyen az eszköz van, és csak ezen a szegmensen belül egyediek. Ezek a címek nem routolhatóak szegmensen kívülre. 1111111010
54 bit 0
64 bit interfész azonosító
• Site-local címek: egy szervezeti egységen belüli kommunikációra szolgálnak, ezen belül egyediek. Ha a belsı hálózat több szegmensbıl áll, akkor ezen alhálózatok között routolható, de a szervezeti egységen kívül nem. Ez a címtípus már nem használatos.
1111111011
28/92
38 bit 0
16 bit alhálózat azonosító
64 bit interfész azonosító
A link-local cím kiemelt jelentıségő az IPv6 mőködése szempontjából. Minden IPv6 interfésznek rendelkeznie kell ilyen címmel, amelyet az eszköz rendszerint autonóm módon állít elı. Mivel a link-local cím birtokában már szegmensen belül képes az kommunikációra, ezért például az automatikus konfiguráció további lépései már történhetnek tisztán IPv6 felett. Ennek jelentısége abban áll, hogy így alkalmazható minden IPv6 szolgáltatás, így a titkosítás és az autentikáció ebben az esetben is. Multicast címek
Az IPv4 multicast utólag lett a rendszerbe illesztve és tulajdonképpen máig opcionális elem. Ezzel szemben az IPv6-nak a multicast integráns része, sıt több fontos funkció, mint például az automatikus konfiguráció a multicast használatán alapul. Az multicast címzéssel kifinomultan lehet több címet elérni. A cím tartalmaz utalást a címzés típusára és hatókörére:
1111111
4 bit flag
4 bit hatókö r
112 bit multicast csoport azonosító
A multicast címben a flag jelzi a típust. Jelenleg két érték van definiálva, a 0 jelenti az ismert (well-known) címeket, az 1-es pedig a szabadon definiálhatóakat. Az ismert címek elıre definiáltak és a hatókörtıl függıen vagy bizonyos esetekben attól függetlenül címzik meg az adott címeket vagy szolgáltatásokat [RFC2375]. Így például a FF02:0:0:0:0:0:0:B cím jelenti az adott szegmensen belüli mobilágenseket, vagy a FF05:0:0:0:0:0:0:2
cím a szervezeti egységen belüli
útválasztókat jelzi. A szabadon értelmezhetı címek esetén a csoport azonosítónak tetszıleges értelmet adhatunk. A hatókör lehet egy eszköz (node-local:1), egy szegmens (link-local:2), egy szervezeti egység (site-local: 5), egy szervezet (organizational: 8) vagy globális (global: 14). Speciális multicast cím a kérelmezett multicast (Solicited Node Multicast), amely FF02:0:0:0:0:1:FFXX:XXXX formátumú cím, amely utolsó 24 bitje az interfész unicast címébıl áll. Minden interfésznek fel kell vennie ezt a címet. Elınye abban áll,
29/92
hogy ha egy interfész több különbözı aggregációkhoz tartozó címekkel rendelkezik, akkor is ugyanaz lesz a kérelmezett multicast címe, tehát ezzel is címezhetı, az aggregáció ismerete nélkül is. Speciális címek
A csupa nulla értékő cím, a ::/128 a nem specifikált címet jelöli. A 127 bitnyi nullát és egy egyest tartalmazó ::1/128 cím pedig a loopback cím, amely mindig a saját állomást jelenti, az IPv4 127.0.0.1 címmel analóg módon. Címek jelölés módja
Az IPv6-os címeket hexadecimális számok csoportjaiként jelölik. Kettısponttal elválasztott,
8
darab
16
bites
(négyjegyő)
csoportból
áll.
Pl.:
3ffe:2f00:0000:0000:0200:c0ff:fec6:068b. Egy csoportban a magasabb helyiértékő nullák elhagyhatók. IPv6 címekben gyakori a sok nulla van egymás mellett. Ha egymás melletti csoportokban csak és kizárólag nullák fordulnak elı, azok elhagyhatók, és helyettük kettı kettıspont írható. Például: 3ffe:2f00::200:c0ff:fec6:68b. A hálózati prefix hossza a cím után jelölhetı egy per ('/') jel után: 3ffe:2f00::200:c0ff:fec6:68b/64. Ha csak a hálózati címet szeretnénk ábrázolni, akkor a fentihez hasonló módon tehetjük meg, az interfész részt elhagyva belıle: 3ffe:2f00::/24. Vigyázni kell, hogy az esetleg elhagyott nullák és a prefix hossza ne okozzon félreértést: 3ffe:10::/24 estében a 24 bites prefix a 3ffe:00::/24, a
10
cím maradék
részéhez tartozik. A beágyazott és a kompatíbilis IPv4-es címeket vegyes írásmódban használhatjuk, ahol az IPv4-es címet a hagyományos pontozott decimális formában jelöljük. Például: ::ffff:152.66.243.50. Látható, hogy az IPv6 címek formátuma és hossza jóval bonyolultabb az emberi kezelés szempontjából, tehát az IPv6 elsısorban a DNS-re támaszkodik a mindennapi használat során.
30/92
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 [RFC2462]. 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). Konfigurációs lépések
Bekapcsolás után elsı lépés a Link-local cím kialakítása. Ez minden interfészre megtörténik. A cím rendszerint valamilyen interfészre jellemzı értékbıl (pl. MAC cím) alakul ki, így a szegmensen belüli egyedisége biztosított, de ennek ellenére a cím véglegesítése elıtt egyediségét ellenırizni kell. Ez a szomszédfelmésési protokoll segítségével történik (Duplicate Address Detection). Ha a cím valóban egyedi, akkor ezen címet használva az eszköz elkezdi figyelni az útválasztók hirdetését, illetve a megfelelı multicast címen keresztül kérelmezi ıket konfigurációs információért. A további lépések ez alapján történnek. Állapotmentes konfiguráció
Ha az útválasztó hirdetése állapotmentes konfigurációt ír elı, akkor a hirdetésben megtalálható a szegmensre alkalmazandó prefix, és más paraméterek (pl. MTU). Az eszköz a meghirdetett prefixbıl és az EUI-64 interfész azonosítóból elıállítja a globális címet és egyediségét ellenırzi. A címek egyediségét egyébként nem csak
31/92
ekkor, de bármely olyan alkalommal meg kell tenni, ha egy interfész új címet kap. Ezzel elkerülhetı az egyik leggyakoribb és a hálózat más részére is kiható konfigurációs hiba, a címütközés. A mőködés során az eszköz folyamatosan figyeli a konfigurációs hirdetéseket, a változások detektálása miatt. Az állapotmentes konfigurációs képes azon minimális konfigurációs adatok felvételére, amely az eszközt alkalmassá teszi globális kommunikációra, azonban a konfiguráció kényszerítésére, vagy további hálózati paraméterek átadására nem alkalmas. Állapottartó konfiguráció
Ha nincsen útválasztó hirdetés, vagy az az állapottartó konfigurációra utasít, akkor valamilyen más metódust kell alkalmazni a konfigurációs adatok felvételére. Egyik ilyen eszköz lehet a DHCPv6, amely tulajdonképpen az IPv4-ben ismert DHCP IPv6os megfelelıje. [RFC3315] Segítségével kézben tartható az össze paraméter és további adatok (pl.: name szerver, stb.) is átadható. Automatikus rekonfiguráció
Az autokonfiguráció nem csak az elsı hálózatra csatlakozáskor lényeges, hanem a folyamatos mőködés közben is. Segítségével a hálózat átszámozása könnyen megoldható. Minden IPv6 cím három állapotban lehet6: • preferált: kapcsolatok létesítésekor a cím használható, • elavult (deprecated): új kapcsolat létesítésekor már nem használható, de bejövı kapcsolatok még fogadhatók vele, • érvénytelen: a cím kommunikációra nem használható. A cím érvényességéhez és preferáltságához élettartam tartozik, amelyet a konfigurációs hirdetés tartalmaz, és mindkettı lehet végtelen is. 6
Vlójában több állapot van, de a rekonfiguráció szempotjából a többi nem jelentıs.
32/92
Ezek alapján az átszámozás a következı módon hajtható végre: 1. A régi címet véges érvényességgel és véges, az elıbbinél rövidebb preferált élettartalmával kezdjük hirdetni. Ennek hatására a hálózaton lévı eszközök beállítják ezt az idıtartamot maguknak. 2. Mielıtt a régi cím preferáltsága lejárna, az új címet is elkezdjük hirdetni. 3. Mint lejár a régi cím preferáltsága, az új kapcsolatok már csak az új címmel jönnek létre, a kívülrıl érkezı kapcsolatokat a régi címre még lehet fogadni, a fennálló kapcsolatokban nem történik változás. 4. A régi cím érvényessége lejár, innentıl már csak az új cím él. Megfelelıen megválasztott élettartamokkal gyakorlatilag fennakadás nélkül végre lehet hajtani az átszámozást. Természetesen egy teljes átszámozás nem csak az IP címek váltását jelenti, de a címváltás automatizálása nagyban megkönnyíti a feladat végrehajtását. 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 [RFC2401][RFC4301] • Az autentikációt megvalósító AH rendszer [RFC2402][RFC4302] • A titkosítást megvalósító ESP rendszer [RFC2406][RFC4303] • A kulcs-menedzsment rendszer • A kriptográfiai algoritmusok
33/92
Az IPSec keretrendszer
Az IPSec keretrendszer teremti meg az egyes komponensek közti kapcsolatot. Központi eleme az SA (Security Association – biztonsági hozzárendelés), illetve az SA-kból álló adatbázis. Az SA teremti meg a kapcsolatot az egyes hálózati kapcsolatok és a hozzájuk tartozó biztonsági jellemzı között. Egy SA a következıket tartalmazza: a kapcsolat cél címe, a biztonsági paraméterek leírója (SPI – Security Parameter Index) és a használt protokollt (AH vagy ESP). Ebbıl következik, hogy egy SA egy kapcsolat egyik irányára vonatkozik csak és vagy csak az ESP-re vagy csak az AH-ra. Tehát egy kétirányú, mindkét irányba titkosítással és autentikációval ellátott kapcsolatra négy SA-t kell alkalmazni. Ennek a látszólag bonyolult megoldásnak az elınye, hogy a kapcsolatok irányára más-más biztonsági jellemzıket adhatunk meg, pl. egy DNS kérést nem kell védeni, a választ viszont autentikációval lehet ellátni. Az SPI és a forrás cím segítségével határozza meg a címzett az alkalmazandó SA-t, az SPI ugyanis minden IPSec csomagban továbbításra kerül. Az SA tartalmazza többek között az alkalmazandó kriptográfiai algoritmusokat, a kulcsokat, ezek élettartamát és hasonló paramétereket. A kapcsolatokra vonatkozó SA-kat a Security Policy Database (biztonsági politika adatbázis) határozza meg, amely segítségével rugalmasan konfigurálhatók az elvárások. AH
Az AH célja a csomag hitelesítése. Ennek során megfelelı kriptográfiai algoritmusokkal (pl. MD5, SHA-1) ellenırzı összeget számol a küldı a csomagra, amelyet a vevı ellenıriz. A visszajátszás elleni támadások ellen a csomagok sorszámozása véd. Az AH csomag az IPv6 fejléc-láncolási mechanizmusán keresztül beékelıdik az IP fejléc és a csomag adatrésze köze.
34/92
ESP
Az ESP a csomagok titkosítására szolgál, de bizonyos algoritmusok mellett az autentikációt is elvégzi. Az ESP az AH-hoz hasonló módon a fejlécek láncolását használja azonban nem ellenırzı összeget számol, hanem titkosítja a csomag adat részét vagy a teljes csomagot. Attól függıen, hogy csak az adatrészt, vagy az egész csomagot titkosítjuk beszélhetünk transport vagy tunnel módú ESP-rıl. Transport mód esetén csak az adat rész titkosított, tehát az eredeti IP fejléc megmarad titkosítatlanul. Ez két állomás közvetlen kommunikációja során alkalmazható fıleg. A tunnel mód elrejti a teljes eredeti csomagot, tehát a forgalomelemzéses támadásoktól is véd. Alkalmazása fıleg hálózatok közötti kapcsolatkor elınyös, amikor minkét hálózat peremén van egy-egy security-gateway, amely a teljes forgalmat ESP-be csomagolja, illetve bontja ki. Természetesen mivel az eredeti csomag titkosított, ezért új IP fejléccel és esetleges opcionális fejlécekkel kell újra ellátni. Nagyon elınyösen alkalmazható VPN (virtuális privát hálózat) kialakításához. Kulcs menedzsment
A jól mőködı biztonsági keretrendszer alapvetı eleme a kulcskezelı rendszer. Az IPSec alapvetıen két módszert ismer, a manuális és az automatizált kulcs cserét. A manuális esetben kézzel kell a kommunikáló feleknél a kulcsokat és a paramétereket beállítani, míg automatizált esetben valamely automatizált eljárást lehet használni. Az automatizált kulcskezelési eljárások közé tartozik a PKI infrastruktúra és a DNS felhasználása a kulcsok osztására. 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 35/92
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. 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. Nyers teljesítmény
Az IPv6-ban alkalmazott cím méret megnöveli az IP fejléc méretét. Ez önmagában – fıleg kis csomagméret esetén – teljesítménycsökkentést okoz. Mérhetıen kb. 1.5%-kal kisebb az IPv6 nyers, lokális hálózaton, két állomás között mérhetı teljesítménye. Ugyanakkor a nagy távolságú teljesítmény a következıkben részletezett okok miatt lényeges különbségeket mutathat az IPv6 javára. A protokoll mag megvalósítása egyszerőbb mint az IPv4 esetében, tehát kevesebb erıforrást igényel hardver és szoftver szinten. Ennek beágyazott eszközök esetében van jelentısége. A címzés és a teljesítmény
Az IPv6 címzési architektúra, és ezen belül különösen a Globálisan Aggregálható Unicast címek elısegítik a teljesítmény növelését, különösen a hálózati hierarchia magasabb szintjén. A TLA-k korlátozott száma a legfelsı szinten csökkenti az útválasztókra nehezedı terhelést, mivel egy gerinc útválasztóban így 8000 körülire lehet redukálni a bejegyzések számát. IPv4 esetében ez jelenleg 50000-70000.
36/92
Fejlécek kezelése
Az IPv6 fejléce fix mérető, és csak a legfontosabb információk találhatóak meg benne. Az IPv4 változó mérető fejlécéhez képest, az opcionális adatok nem a fejlécben, hanem külön opció fejlécekben kerülnek elhelyezésre. A ábra az IPv6 fejlécet mutatja. Verzió 4bit Forgalmi osztály 8 bit
Flow címke 20 bit Következı fejléc 8 bit
Adat hossz 16 bit
Hop limit 8 bit
Forrás cím 128 bit
Cél cím 128 bit
Az egyes mezık jelentése: • Verzió: protokoll verzió, értéke IPv6 esetében 6 • Forgalmi osztály: a forgalom osztályozására használható, DiffServ QoS megoldásokhoz • Flow címke: kapcsolat azonosítására használható, IntServ QoS megoldásokhoz • Adat hossz: a csomag fejléc utáni hossza (opció fejléceket is beleértve) bájtokban • Következı fejléc: az IP fejlécet követı fejléc típusa. Jelölheti az opciós fejlécek láncolását, vagy az adat értelmezését. • Hop limit: a csomag élettartamát korlátozó mezı. Minden csomóponton való áthaladáskor egyel csökken, ha értéke nulla, a csomagot el kell dobni. Az IPv4 fejléccel összehasonlítva az IPv6 fejléc szerkezete jóval egyszerőbb. A nem minden esetben használt opciókat külön fejlécek beillesztésével lehet jelölni. Kétféle opcionális fejléc fordulhat elı:
37/92
• végpontokra érvényes fejléc. Ezeket csak a küldı/fogadó oldalon kell feldolgozni • menet közben is feldolgozandó (hop-by-hop) fejléc. Ezt minden közbensı állomásnak fel kell dolgozni. A fejlécek az IP fejléc után vannak láncolva, a megelızı fejléc „következı fejléc” mezıjét használva. A sorrend kötött, mégpedig olyan módon, hogy a menet közben feldolgozandó fejlécek a végpont fejlécek elıtt vannak. Azaz az közbensı csomópontoknak csak addig kell feldolgozni az opciókat, ameddig el nem érnek egy rájuk már nem vonatkozó fejlécre. Ez, kombinálva az IP fejléc kötött hosszával, egyszerősíti a menet közbeni feldolgozást, u.i. az útválasztónak nem kell végigvizsgálnia a teljes csomagot. Az IP fejlécbıl kimaradt a IPv4-ben meglévı ellenırzı összeg. Ennek indoka az, hogy a jelenlegi hálózati technológiák olyan kis hiba aránnyal dolgoznak, hogy nem érdemes az IP csomagokat külön ellenırzı összeggel védeni, fıleg, hogy felsıbb protokoll rétegek ezt úgyis megteszik. Ha a csomag védelmére IP szinten mégis szükség van, akkor erre a célra az IPSec AH használható. Csomagok tördelése
A csomagok kezelésében fontos újítás, hogy a csomagok tördelése és összerakása (fragmenting/assembling) csak a végpontokon történik meg. Az IPv4 közbensı csomópontok számára is engedélyezte a tördelést, ha a következı szakaszon átvihetı maximális csomagméret kisebb volt az aktuális csomagnál. Ez nagy terhet rótt a útválasztókra. Az IPv6 ezzel szemben az MTU (Maximum Transfer Unit) discovery mechanizmus segítségével (vagy az ICMP hibajelzések alapján) felfedezi az adott útvonalra érvényes MTU-t, és már a küldı végpont ezt használja. [RFC1981]
38/92
IPv6 mobilitás Az 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. [MOBIL6] 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. Különbségek az IPv4-hez képest
• Az IPv6 mobilitás alap IPv6 mechanizmusokra épül, mint például az autokonfiguráció. Ezek minden implementációban léteznek, a mobil mőködést támogató környezet kialakítása nem feltételez különleges megoldásokat. • A honos ágens nélküli direkt kommunikáció az IPv4 megoldásban csak opcionális, az IPv6-ban kötelezı. • A Home Address opció megengedi ingress filteringet alkalmazó hálózatok használatát. Erre IPv4 mobilitásban nincs lehetıség. Ezzel együtt a mobil eszköz multicast csomagokat is tud küldeni. • Az IPSec miatt a mobilitás biztonsága eleve adott, különleges megoldások nélkül. • A Proxy Neighbor Discovery használata függetlenné teszi a mobilitást a hálózati technológiától. Az IPv4 Proxy ARP ebbıl a szempontból technológia függı. •
Az IPv6 mobilitás vezérlı információi opcionális fejlécként vannak megvalósítva, az IPv4 UDP-vel szemben. Ennek teljesítmény és üzembiztonság növelı hatása van, valamint tisztább megvalósítást eredményez.
• A dinamikus honi ágens felfedezés hatékonyabb mint az IPv4 directed broadcast.
39/92
• A mozgás során kétirányú megerısítések vannak. Ez elınyös olyan környezetben, ahol a forgalom két irányának különbözı jellemzıi vannak (például vezeték nélküli rendszerek) • Általában az átirányított forgalom a Routing Header opcionális fejléc segítségével küldhetı tovább. IPv4 minden esetben beágyazást (encapsulation)használ. Ezért az IPv6 mobilitás képes helyesen kezelni az ICMPv6 üzeneteket. Ugyanakkor az IPv6 mobilitás sem ad megoldást két lényeges kérdésre. A nem folyamatos kapcsolattal rendelkezı (pl. rádiós) hálózatok kezelésére, azaz a mobil mőködés továbbra is feltételezi, hogy állandó kapcsolat van a mobil eszköz és a kommunikáló felek között. Hasonlóan nem tisztázottak még a távoli hálózatba való bekapcsolódás autentikációs és autorizációs kérdések. IPv6 kérdések
Az IPv6-tal kapcsolatban természetesen vannak tisztázatlan kérdések: • Bizonyos komponensek még korántsem annyira kiforrottak, mint IPv4-ben. Ilyen például a DNS vagy a DHCP. A DNS néhány implementációban (Pl. Windows XP) még függ az IPv4-tıl, de várhatóan hamarosan megjelennek a megfelelı implementációk, mivel a megoldásokat már kidolgozták. A DNS elengedhetetlen része az IPv6 használható mőködtetésének, ugyanis a nagymérető IPv6 címek közvetlen adminisztrálása kézi munkával gyakorlatilag lehetetlen. A DHCPv6 igen sok funkcióra képes, de használható implementáció csak a közelmúltban jelentek meg. Igaz, az eddig felhasználási körülmények között nem is nagyon van rá szükség,
jelenleg
az
állapotmentes
autokonfiguráció
megfelelı.
Valódi
mőködésben azonban elengedhetetlen pl. a DHCP és a DNS együttmőködése. • Bár évek óta vannak viszonylag nagymérető teszt hálózatok, az teljesítményre még nincsen elegendı mérési adat. A legtöbb hálózat továbbra is konfigurált tunnelek segítségével mőködik, amelyek nem teszik lehetıvé a natív IPv6 routing és egyéb funkciók kipróbálását. • Az hálózatmenedzsment kidolgozása még nem éri el az IPv4 szintjét. Az IPv6 MIB-ek már ki vannak dolgozva, de a gyakorlati próbákon még nem nagyon estek át az eszközök.
40/92
• Az áttérési módszerek gyakorlati használhatósága még nincs átfogóan kipróbálva. Valójában csak a dual-stack, a konfigurált tunnel és a 6to4 módszer van széleskörő használatban. Igaz, hogy mivel szinte az összes implementáció dual stack, ezért a tunneling megoldások általában kielégítı megoldást adnak a jelen helyzetben. Vátható, hogy az IPv4 címek hiánya elıtérbe helyezi a többi módszert is. • Kérdéses az igazi hajtóerı az áttérés mögött. Az USA, mint technológiai vezetı szereppel bíró ország nem szenved IP cím hiányban olyan mértékben, amely sürgıssé tenné az áttérést. Ugyanakkor más jellemzık (menedzselhetıség, biztonság stb.) a címtartománynál is lényegesebb elınyökké válhatnak. Ráadásul a Microsoft és a Google, mint meghatározó technológiai cégek erıteljesen szorgalmazzák az IPv6 bevezetését.
41/92
Az IPv4 és IPv6 által támogatott alkalmazások Az IPv6 nem kíván gyökeresen új protokoll lenni az alkalmazások szempontjából. Valójában az IPv6 csak a hálózati réteget cseréli le, tehát már TCP szinten sem kellene az alkalmazásoknak különbséget látnia. Hagyományos alkalmazások
Általánosságban elmondható, hogy funkcionalitásban az IPv6 kielégíti az IPv4-gyel szemben támasztott elvárásokat, azaz nincsen elvi akadály annak, hogy jelenlegi IPv4 alkalmazások mindkét, vagy az új protokoll feletti mőködésre felkészíthetıek legyenek. A „normál”, tehát nem valamely speciális IPv6 funkcióra támaszkodó alkalmazás esetében programozás szempontjából gyakorlatilag nincsen különbség. A korábbiaktól eltérıen az IPv6 programozói felülete (API) is szabványosított, mind az alapvetı, mint a fejlett szolgáltatásokra nézve [RFC2553][RFC2292]. Ez a szabvány természetesen nem különbözik gyökeresen a de-facto szabványként kezelt socket programozói felülettıl. A kellı figyelemmel megírt IPv4 alkalmazások gyakorlatilag minimális módosítással, szinte egy egyszerő újrafordítással IPv6 képessé tehetık. A kellı figyelem ebben a környezetben azt jelenti, hogy az adott program nem épít az IPv4 címek 32 bites hosszára, hanem a megfelelı, a rendszer által definiált adattípusokat használja. Probléma elsısorban abban az esetben jelentkezik, ha a program pl. integer adattípusként kezeli az IPv4 címeket. Az IPv6 programozás során a közvetlen IPv6 címek kezelése nem praktikus, az alkalmazás ha csak lehet, hosztnevekkel dolgozzon, és a név – IP cím váltást bízza a megfelelı könyvtári hívásokra. Fontosabb alkalmazások IPv6 képessége
Több jelentıs projekt is foglakozik a meglévı alkalmazások IPv6 portjának elkészítésével, valamint a legtöbb, az Internet szempontjából jelentıs program (pl.: sendmail, bind, stb.) már támogatja az IPv6-ot.
42/92
Kimagasló a Kame projekt ezirányú tevékenysége, az általuk IPv6 képessé tett alkalmazások száma több száz és lefedik a legtöbb mindennapos hálózati alkalmazást. A legtöbb alkalmazás a szabad forrású eszközök közül kerül ki, és fıleg a Unix jelegő rendszereken alkalmazhatóak. Új alkalmazások
Az IPv6 bevezetése során kérdéses, mely olyan alkalmazás van, amely igényli az IPv6 által nyújtott szolgáltatásokat. Az IPv6 gyakorlatilag a következı területeken nyújt az alkalmazások számára hasznosítható újdonságot: • Címzés – a kiterjesztett címtartomány és a különbözı címzési típusok segítséget nyújtanak például az intranetek, a VPN-ek, vagy a mobil alkalmazásoknak. • Biztonság – az IPSec lehetıvé teszi a hálózati szintő biztonságot és hitelesítést, így minden alkalmazás igénybe veheti ezt a szoláltatást. • QoS – Az IPv6 QoS támogatása lehetıvé teszi akár az IntServ, akár a DiffServ QoS megoldások bevezetését. • Autokonfiguráció
–
a
kiterjedt
autokonfigurációs
mechanizmusok
a
hálózatmenedzsment széles területén használhatóak A címzés fı hajtóerı volt az IPv6 mögött a protokoll kidolgozásának kezdetén. Akkor a címek elfogyását 2000-2002 körülre jósolták. A közben bevezetett technológiák, mint pl. a NAT elterjedése a vállalati hálózatokban gyakorlatilag megszüntette a címek drámai fogyását. Ilyen módon a címtér mérete jelenleg koránt sem akkora hajtóerı, mint öt évvel ezelıtt volt. Felmerülhet a kérdés, hogy szükség van-e egyátalán a nagyobb címtartományra. A válasz mindenképpen igen, ugyanis a NAT ellenére is fogyóban vannak a címek, de elfogyásuk legalább 5 évet kitolódott. Azonban a NAT nem mindenhol alkalmazható. Egyrészt nem transzparens, tehát rendszerint a NAT mögött lévı hálózatot nehéz kívülrıl elérni (ennek vannak ugyanakkor elınyei a biztonság szempontjából), másrészt pl. mobil IP-vel nem tud együtt mőködni.
43/92
Ugyanakkor a NAT kiváltható IPv6-tal, ha a belsı hálózat IPv6-ot használ és valamilyen transzlációs megoldással kommunikál a külsı hálózattal. A belsı IPv6 hálózat biztonsági és menedzselhetıségi szempontból is elınyösebb lehet. Kapcsolódik a címzési architektúrához a 3. generációs mobil rendszerek, amelyben az IPv6 központi szerepet játszik mind a jelzésrendszer, mind az adatátvitel terén. Az UMTS rendszerek késése azonban jelentısen csökkentheti ezt a hajtóerıt is. Az IPSec létezik IPv4-re is. A jelenleg még megoldatlan problémák, amelyek fıleg a kulcs menedzsmentet és a skálázhatóságot érintik az okozzák, hogy az IPSec szinte kizáróan a VPN, illetve egyéb pont-pont kapcsolatok esetében használatos. Az IPv6 IPSec funkcionálisan nem ad jelentısen többet, mint az IPv4 megoldás, de nagy különbség, hogy az IPSec az IPv6-nak kötelezı része. A QoS támogatás elvben hasznos, gyakorlatban azonban felvet problémákat. Napjainkban tapasztalható, hogy a hálózati technológiák fejlıdésével a QoS által is megoldható kérdéseket inkább elodázzák, egyszerően nagyobb teljesítményőre cserélve az infrastruktúrát. Amennyiben tömeges igény mutatkozna QoS IP szintő megoldására, az IPv6 egyértelmő elınyben lenne. Eredetileg csak kisegítı funkciónak szánták, de jelentıs elınye az IPv6-nak az autokonfiguráció. Ez nem csak az egyes csomópontok automatikus cím és paraméter beállítását jelenti, de a benne foglalt mechanizmusok jelentısen javítják a rendszer robosztusságát. Az IPv4-ben tipikusan megjelenı IP cím ütközés az IPv6-bat teljesen kiküszöbölhetı, illetve hatása csak lokális, nem terjed tovább a hibásan konfigurált (amelyet IPv6 alatt egyébként véletlenül nem lehet megtenni) csomópontnál. Amennyiben megoldódik a címek automatikus kezelése, tehát pl. a DHCP-Dinamikus DNS valóban mőködıképes megvalósítása, és egyéb menedzsment funkciók elkészítése, akkor az IPv6 jelentıs elınyt tud felmutatni. Ez valószínőleg a közeljövıben megvalósul, mert elvi kérdések gyakorlatilag nincsenek, de megbízható megvalósítás még várat magára. Ennek fıleg vállalati hálózatokban van kiemelkedı szerepe, ahol az üzemeltetési költségek nagyban csökkenthetık a manuális munka kiváltásával.
44/92
Összességben megállapítható, hogy az IPv6 több területen is kézzelfogható elınyöket tud felmutatni, azonban jelen körülmények között nem mindegyik elıny elégít ki olyan igényt, amely megoldása abszolút fontosságú. Mindezeket megvizsgálva kérdéses, hogy létezik-e olyan „killer-application”, amely csak IPv6 alatt valósítható meg hatékonyan. Kétségkívül a sok címet, vagy hatékony multicastingot igénylı alkalmazások lehetnek ebben a körben. A többi területen sokkal inkább vagy funkciók kihasználásáról (QoS, IPSec) beszélhetünk, mint kifejezetten IPv6-ra készített alkalmazásokról, vagy egyszerően a funkció megvalósításáról, pl. menedzsment. Bár jelentıs számú eredetileg IPv4-re készített program képes már IPv6-on mőködni, és nincsen elvi akadálya annak, hogy bármely IPv4 funkciót megvalósítsunk IPv6 alatt, nem valószínő, hogy az IPv6 bevezetését egy specifikus alkalmazás, vagy alkalmazás csoport fogja kikényszeríteni. Sokkal inkább várható, hogy az eredeti és a fejlesztés közben felismert igények, mint pl. a címek sokasága, vagy az egyszerő üzemeltetés lesz az, amely a graduális bevezetést fogja elısegíteni. Kétségkívül fennáll a tyúk-tojás probléma, ugyanis a széleskörő bevezetésig a gyártók nincsenek rákényszerítve az IPv6 termékek készítésére, viszont jelenleg a bevezetésre a legnagyobb esélyt az adja, ha az implementációk léteznek, és a felhasználók „csak úgy” felismerik az elınyöket. A 2001. évében viszonylag sok gyártó jelentett be, vagy jelentetett meg hivatalos IPv6 eszközöket, így technikai akadálya nincsen a bevezetésnek, de amíg a desktopon nincs jelen az IPv6, addig tömeges elterjedés nem lesz. Ebbıl a szempontból nagyon lényeges a Microsoft Windows XP után megjelent operációs rendszerei, a Windows Vista illetve a Windows Server 2008, amelyek már teljesen hivatalosan támogatják az IPv6-ot. Ugyancsak jelentısek a különbözı szabad illetve nyílt forrású rendszerek, mint a Linux, a FreeBSD, vagy a Solaris 10 mivel ezek szintén kitőnı IPv6 implementációkkal rendelkeznek.
45/92
Ennek ellenére még mindig várat magára nagy alkalmazás készítık (pl. irodai vagy üzleti alkalmazások) bejelentése az IPv6 támogatásáról.
46/92
A nemzetközi szabványosítás helyzete Az IPv6 bevezetése nem különbözik más Internet szabványok készítésétıl, azaz a szokványos draft→RFC→javasolt szabvány→draft szabvány→szabvány folyamatot járja végig. Az IPv6-tal foglalkozó szabványosító szervezetek
Az IPv6, mint minden más Internet technológia fejlesztését az IETF (Internet Engineering Task Force) irányítja. Több munkacsoport is foglalkozik az IPv6 kérdésekkel, a központi szerepet az IPv6 munkacsoport (korábban IPNGWG – IP Next Gereration Working Group) viszi. A másik jelentıs csoport az Ngtrans (Next Generation Transition), amely az áttérés kérdéseivel foglakozik. Az IPv6 – illetve akkor még IPng (IP Next Generation) – bevezetésére az IETF IPng Area Directors csoport tett javaslatot, 1994-ben a torontói IETF ülésen. Az IESG (Internet Engineering Steering Group) 1994 novemberében hagyta jóvá a javaslatot, amely a javasolt szabvány (proposed standard) státuszt kapta. A központi IPv6 protokollok 1998 augusztusában váltak draft szabvánnyá. Az IPv6 szabványok
A jelentısebb IPv6 funkciók szabványosítási helyzetét mutatja be a következı táblázat. Az öt központi funkció (IPv6, ICMPv6, ND, autokonf, MTU) már draft státuszú, a legtöbb más funkció javasolt szabvány. Jelenleg az áttérési módszerek közül kevés van szabványosítva. RFC 1881 1886 1981 2292 4291 2374 2375 2450 2452 2454 2460 2461
47/92
Megnevezés IPv6 cím allokáció DNS kiterjesztése IPv6-ra path MTU discovery Fejlett socket interfész IPv6 alkalmazásokhoz IPv6 címzési architektúra IPv6 Aggregálható Unicast címzés IPv6 multicast címek TLA és NLA allokációs szabályok IPv6 TCP MIB IPv6 UDP MIB IPv6 specifikáció Szomszédfelmérési (ND) protokoll
Szabvány javasolt/info javasolt draft javasolt/info javasolt javasolt javasolt/info javasolt/info javasolt javasolt draft draft
2462 2463 2464 2465 2466 2467 2470 2472 2473 2492 2553 2675 2740 2894 2928 3056
Állapotmentes autokonfiguráció ICMPv6 IPv6 Ethernet felett IPv6 MIB IPv6 ICMP MIB IPv6 FDDI felett IPv6 TokenRing felett IPv6 PPP felett általános IPv6 tunneling IPv6 over ATM Alap socket interfész IPv6 alkalmazásokhoz IPv6 jumbogram IPv6 OSPF router átszámozás Kezdeti subTLA allokáció 6to4
draft draft javasolt javasolt javasolt javasolt javasolt javasolt javasolt javasolt javasolt/info javasolt javasolt javasolt javasolt/info javasolt
A szabványok szempontjából fontos kérdés, hogy a már létezı korábbi szabványokat és elıírásokat mennyiben érinti az IPv6 bevezetése [IPV6SURVEY] részletesen taglalja az egyes IETF szabványok IPv6 „kompatibilitását”. Megállapítja, hogy több olyan szabvány van, amely nem felel meg az IPv6-nak, rendszerint azért, mert explicit módon kezel IPv4 címeket. Egyes esetekben ez nem jelent gyakorlati problémát, más esetekben egyébként is lesz új szabvány (pl. több routing protokoll).
48/92
A bevezetéshez szükséges hazai szabványosítás Technológiai kérdések
Nyilvánvaló, hogy amint az Ipv4 esetében, úgy az IPv6-nál sincsen sem lehetıség, sem praktikus érv a nemzetközitıl eltérı technikai, technológiai szabványok kialakításában. Az IPv6 esetében a fejlesztık különös figyelmet fordítottak arra, hogy lehetıség szerint
minél
szélesebb
körben
egyértelmő
specifikációk
legyenek.
Ennek
eredményeként az eddigi gyakorlattól is eltértek. Ez megnyilvánul például abban, hogy az IPv6 programozói felületét is specifikálták, annak ellenére, hogy az IETF és elıdei korábban ódzkodtak az API szabványosítástól. Az alapvetı IPv6 funkciókban nem várható módosulás, így bevezetésük várhatóan nem jár kockázattal. Jelentıs a fejlıdés az áttérési módszerek tekintetében, de ezek közül csak néhány van olyan állapotban, hogy éles alkalmazásban is használható, itt azonban változás nem, legfeljebb kiterjesztés valószínő. Adminisztratív kérdések
A hazai szabványosítási kérdések elsısorban az üzemeltetés és az adminisztratív feladatok körül vetıdhetnek fel. Az elsı és legfontosabb kérdés a címtartományok osztása. Ezen felül fontos az áttérési módszerek alkalmazása és a biztonsági megfontolások. Címtartomány kérdése
Az IPv6 címek rendelkezésre álló mennyisége felveti a különbözı címosztási stratégiák kidolgozásának kérdését. Nagyon lényeges feladat annak megakadályozása, hogy egy esetlegesen elhibázott induló stratégia a késıbbiekben problémát okozzon, ahogy ez az IPv4 esetében történt. Az egyik lehetséges megoldási mód az idıleges címek osztása. A jelenlegi koncepció szerint az IPv6 címek nem képezik tulajdonát annak, aki megkapta az adott tartományt, lehetıvé téve ezzel azt, hogy adott esetben a kiosztás megváltoztatható legyen. Az idıleges osztásnál fenn kell tartani azt a kikötést, hogy bizonyos idı (pl. 10
49/92
év) után a kiosztást felül kell vizsgálni, és szükség esetén, a tartományok szőkítése nélkül újra osztást kell elvégezni. A jelenlegi IPv6 címzési architektúra a globálisan aggregálható címekre épít, amelyek minimálisan három szintő hierarchiát tételeznek fel. Ezek közül a legfelsı hierarchia szintnek a mérete erısen korlátozott, és a nemzetközi gerinc szolgáltatók számára van fenntartva. A további osztás inkább politikai és nem mőszaki kérdés, lévén el kell dönteni, hogy a hierarchiába ki van „alul” és ki van „felül”. Áttérési módszerek
Hasonlóan ki kell dolgozni az áttérési módszerek bevezetését és üzemeltetését (pl. ki és hogyan felügyeli a tunnelekt, transzlátorokat, milyen beállításokat kell tenni a hálózat integritását veszélyeztetı támadások ellen, stb.) Az áttérési módszerek alkalmazása párhuzamos rendszerek (külön IPv4 és IPv6 hálózat) vagy az egyik protokoll szempontjából nem a valóságot tükrözı megoldások (pl. IPv6 tunneling) megoldásával járhat. Ennek megfelelıen kellıképen meg kell határozni, hogy az IPv6 milyen következményekkel
van
a
meglévı
infrastruktúrára,
illetve
azon
milyen
változtatásokat kell eszközölni. Célszerő, ha az egyes IPv6-ot alkalmazó szervezetek egyezı címosztási, áttérési stratégiákat alkalmaznak, mert ez nagyban megkönnyíti az sikeres együttmőködést.
50/92
A gyártók termékei IPv6 megvalósítások
Az IPv6 megvalósításokat két nagy csoportra lehet osztani. Hoszt jellegő implementációk közé tartoznak azok amelyek elsısorban nem útválasztásra, hanem IPv6 alkalmazások, szolgáltatások futtatására vannak felkészítve. Természetesen ez nem zárja ki annak a lehetıségét, hogy útválasztóként is alkalmazni lehessen ıket. A router jellegő megvalósítások fı célja az útválasztás hatékony megvalósítása. Mivel az erre a célra szolgáló eszközök erısen specializáltak, ezért célszerő külön vizsgálni ıket a hoszt implementációktól. Az itt felsorolt implementációk közül a Microsoft, Inria, FreeBSD, Linux, Kame, Compaq, Sun, IBM, Cisco, Nortel (Bay) a Tipster6 [TIPSTER6] projekt és korábbi projektek kapcsán szerzett gyakorlati tapasztalatok alapján kerülnek ismertetésre, a többi implementáció az irodalom alapján van vázolva. Ennek megfelelıen a rendelkezésre álló informcáiók is különbözıek. Hoszt jellegő termékek
Hoszt IPv6 termékeket szinte minden nagy gyártó készített. Az implementációk szolgáltatásai, használhatósági foka meglehetısen különbözı. Alapvetıen az IPv6 protokoll központi részeit mind megvalósítja, és általában ennek mőködése is helyes. Nagy különbségek tapasztalhatóak viszont a kiegészítı szolgáltatások, az esetleg az implementációhoz adott alkalmazások valamint a dokumentáltság, használhatóság terén. A gyakorlati alkalmazhatóság szempontjából fontos kérés, hogy mely implementációk hivatalosak, és melyek kísérleti jellegőek. Rendszerint az elızıket az adott rendszerrel együtt szállítják, míg az utóbbiak külön telepíthetı csomag részét képezik. Néhány esetben elıfordul, hogy nem az eszköz vagy operációs rendszer eredeti gyártótójától származik az IPv6 csomag, hanem más gyártótól. A legelterjedtebb, illetve legnagyobb jelentıséggel bíró implementációkat tekintik át a következı ismertetések.
51/92
Microsoft
A Microsoft, mint a legjelentısebb desktop operációs rendszer gyártó három IPv6 megvalósítással rendelkezik: [MSRIP6][MSTP6] • Microsoft Research IPv6 csomag • Microsoft IPv6 Technology Preview for Windows 2000 • Microsoft Windows XP, Server 2003 • Microsoft Windows Vista, Server 2008 Ezek kizárólag a Windows NT operációs rendszer család különbözı tagjaihoz használhatóak. A Microsoft nem készített és minden valószínőség szerint nem is fog készíteni a Windows 95, 98 vagy ME számára IPv6 csomagot. Microsoft Research IPv6 csomag
A legelsı Microsoft IPv6 csomag az Microsoft Research által készített MSRIPv6 volt. A csomag kifejezetten kísérleti jellegő volt, hiszen nem is „a” Microsoft, hanem annak kísérleti fejlesztı részlege készítette. Az MSRIPv6 letölthetı a Microsoft Research honlapjáról. Érdekessége, hogy nem csak a bináris csomag, de a forráskód is letölthetı. Funkcionalitásban a következıket tartalmazza: • Alapvetı IPv6 protokoll, illetve a rá épülı TCP réteg • Állapotmentes autokonfiguráció • Környezetfelmérı protokoll (Neighbor Dicovery) • ICMPv6 • Automatikus és konfigurált tunnelek • 6to4 áttérési eszköz • Statikus útválasztás • IPSec AH és ESP A protokoll megvalósításán kívül néhány alapvetı segédprogram (ping6, racert6, IPSec GUI konfigurátor) és alkalmazás (ftp6) is része csomagnak.
52/92
Különlegessége, hogy a wininet.dll fájl lecserélésével (amelyet kézzel kell megtenni) az Internet Explorer képes IPv6 felett is mőködni, tehát ilyen módon tulajdonképpen a csomagnak része még egy IPv6 böngészı is. Egyébként az alkalmazások száma minimális, de létezik hivatalos IPv6 SDK, így a fejlesztıknek lehetıségük van az egyszerő IPv6 fejlesztésre. Microsoft IPv6 Technology Preview for Windows 2000
Ez a csomag kifejezetten a Windows 2000-hez készült, csak Service Pack 1 esetén hajlandó települni, bár a telepítı konfigurációjának átírásával késıbbi rendszerekre is telepíthetı, igaz, mőködése így nem garantált. Telepítés, majd Service Pack 1-rıl Service Pack 2-re történı frissítéssel viszont problémamentesen mőködik. Telepítése Microsoft Windows XP
A Microsoft XP-vel szállítják az IPv6 protokollt, amely Service Pack 1 óta hivatalos, ennek ellenére alaphelyzetben nem települ, csak külön beavatkozással lehet telepíteni. Alapvetıen az MSRIPv6-ra épül, így tulajdonságai is megegyeznek. Microsoft Windows Vista
A Vista teljesen átdolgozott IPv6 támogatással rendelkezik. Alaphelyzetben is be van kapcsolva az IPv6 és gyakorlatilag minden rendszerkomponens támogatja. A Vista és a Server 2008 kitőnı IPv6 támogatással rendelkezik.
Kame / FreeBSD
A Kame nem csak egy implementáció, de egy teljes projekt az IPv6 minél gyorsabb és szélesebb körő bevezetésére. [KAME] A Kame projekt 1998 áprilisában indult és egy kiterjesztés után a jelenlegi állás szerint 2002 márciusában ér véget. Célja, hogy robosztus IPv6 kódot állítsanak elı, a BSD hálózati kódra alapozva. A fı fejlesztıi platform a különbözı BSD (Free, Net, Open, BSDI) operációs rendszerek. Szinte bizonyosan megállapítható, hogy a Kame IPv6 implementáció a legkiterjedtebb és a legmegbízhatóbb a hoszt implementációk közül. Ezt vizsgálatok is alátámasztják.
53/92
A Kame projekt alapítói a Fujitsu Limited, a Hitachi, Ltd., az IIJ Research Laboratory, az NEC Corporation, a Toshiba Corporation és a Yokogawa Electric Corporation. Az eredményeket saját fejlesztésükben is felhasználják, így pl. a Hitachi IPv6 eszközei az itt kifejlesztett kódon alapulnak. A jelenlegi állapot fıbb tulajdonságai: • IPv6 alap protokoll (RFC460) • A unicast és multicast címzési architektúra. (RFC2373, RFC2374, RFC2375) • ICMPv6 (RFC2463) • MTU felismerés (RFC1981) • Állapotnélküli autokonfiguráció (RFC2462) • Szomszéd felismerése (RFC2461) • IPv6 jumbogramm (RFC2675), korlátozott támogatás, mivel a loopback interfész kivételével nincs olyan interfész, amely ezt a csomagméretet támogatná. • RIPng router szoftverek által (route6d, hroute6d, bgpd) (RFC2080) • BGP4+ (bgpd) (RFC2283, RFC2545) • IPv6 router alert opció (RFC2711) • Név lekérdezés ICMPv6-al (ICMPNAME) • Protokoll Független Multicasting sőrő és ritka módban (RFC2362) • Multicast Listener discovery protokoll (RFC2710) • IPv6 MIB-ek (RFC2465)(RFC2466) • Konfigurált tunnel • FAITH transzlátor (A típusú TRT transzlátor). • 6to4 stf tunnellel (6TO4) • DNS IPv6 támogatásához (RFC1886) • DNS resolver mőködı IPv6 transzporton, multicast DNS resolver • alapvetı IPv6 felhasználói programozási interfész (RFC2553) • kiterjesztett IPv6 programozói interfész támogatása (RFC2292bis) • IPv6 Ethernet (RFC2464), Arcnet (RFC2497), FDDI (RFC2467) ATM (RFC2492) és pont-pont kapcsolat (PPP) (RFC2472) felett • Kísérleti DHCPv6 54/92
• Az FTP (RFC2428, RFC1639) • IPSec + IKE támogatás (RFC1825 - RFC1829, RFC2401-RFC2411) • IPv6 csomagszőrés és firewall • Multihoming • Alkalmazások: igen jelentıs számú (több száz) IPv6 alkalmazás, szinte minden témakörben.Tartalmazza a fı kategóriákat (apache, mozilla, sendmail, X11, stb.) és sok apróbb alkalmazás. Tervezet további fejlesztések: • Router renumbering • DNS szerver felderítés • IPSec fejlesztés: policy, hardver támogatás • Multicast routing • Teljesítmény mérés és bechmarking • RSVP, Diffserv • További áttérési eszközök
Inria
A francia fejlesztéső Inria implementáció volt az egyik elsı „teljes” UNIX IPv6 csomag. [INRIA] A BSD hálózati kódra épült, ezért az ezt alkalmazó rendszerekre lehetett könnyen adaptálni. Alapvetıen FreeBSD-re és NetBSD-re fejlesztették, de ez adta az IBM AIX implementációjának alapját is. A kernel szintő IPv6 megvalósítás abból a szempontból volt érdekes, hogy csak az IP szinten volt különválasztva, ugyanaz a TCP réteg tartozott az IPv4-hez és az IPv6-hoz is. Ez hatékonyság és kód méret szempontjából elınyös, de a fejlesztés során bizonyos bonyolultságot jelent. A protokoll támogatásán kívül gyakorlatilag az összes, az alaprendszerhez tartozó segédprogram és néhány alapvetı alkalmazás (pl. X11) IPv6-os változata is része volt az Inria csomagnak.
55/92
Ennek az implementációnak a fejlesztésével már leálltak, és az általa támogatott rendszerek ma a Kame csomagot használják. Így az Inria IPv6 implementáció használata már nem ajánlott és nem is lehetséges. Linux
A 2.2.x kernel verziótól kezdve rendelkezik a Linux gyakorlatban is használható IPv6 támogatással. [LINUX] A támogatott szolgáltatások köre függ az adott disztribúciótól és verziótól, meglehetısen nagy a szórás a különbözı csomagok között és egységes disztribúció
hiányában
nem
is
mindig
problémamentes
az
egyes
verziók
„összeházasítása”. Fıbb jellemzık: • Alapvetı IPv6 protokollok • Környezetfelmérési Protokoll (Neighbor Discovery) • ICMPv6 • Állapotmentes autokonfiguráció • Tunneling • IPSec Egyéb más protokollok (pl. ftp, smtp vagy útválaszás) a különbözı alkalmazások által támogatott, és általában része a csomagnak. Az alkalmazások IPv6 támogatottsága is változó,
de
általánosságban
más
Unix
(fıleg
BSD)
IPv6
alkalmazások
problémamentesen lefordíthatóak Linux alá. Sun
A Sun Solaris rendszerében a 8-as verziótól kezdve hivatalosan támogatja az IPv6-ot. Korábbi verziókhoz csak kísérleti implementáció létezett. Az IPv6 támogatás telepítéskor
opcionális
komponens,
azonban
[SUN][SOLARIS] Fıbb jellemzık: • IPv6 alap protokoll RFC 2460 szerint • RFC2373 szerinti címzési architektúra • ICMPv6 RFC2463 szerint 56/92
része
a
telepítı
csomagnak.
• Környezetfelmérési Protokoll (Neighbor Discovery) RFC2461 szerint • RFC 2462 szerinti állapotmentes autokonfiguráció • MTU discovery RFC 1981 szerint • Automatikus és konfigurált tunnelek • IPSec külön letölthetı • DNS támogatás (AAAA rekordok) • Alkalmazások: telnet, sendmail, finger, tftp, rlogin, rsh, traceroute, netstat A Sun meglehetısen aktív az IPv6 fejlesztésben, ezért további IPv6 szolgáltatások és alkamazások megjelenése várható a Solarisban. A nyílt forrású Solaris 10 rendszer teljes mértékben támogatja az IPv6-ot, és már telepítéskor felajánlja a használatát. HP
A HP-UX 11.0 változatához van lehetıség kísérleti IPv6 csomag letöltésére. A csomag viszonylag teljes, sok alkalmazás (sendmail, ftp, telnet) IPv6 változatát is tartalmazza az alapvetı IPv6 protokoll családon felül. [HPUX] FreeBSD (NetBSD, OpenBSD)
A FreeBSD-hez két IPv6 csomag létezett, az Inria és a Kame. Az Inria fejlesztése leállt, a Kame viszont nagy iramban fejlıdik, illetve egyesült az Inria bizonyos részeivel.. A FreeBSD a 4.0 verziótól kezdve az alaprendszer részeként támogatja az IPv6-ot,
amely
implementáció
[FREEBSD][OPENBSD][NETBSD].
A
az
Kame
6-os
rendszer
csomagra óta
már
alapul. telepítéskor
bekapcsolható az IPv6. A FreeBSD fejlesztıi idırıl-idıre átveszik a Kame stabil részeit, így ha a legfrissebb IPv6-os fejlesztéseket kívánjuk használni, akkor a Kame csomagot kell letölteni és telepíteni. A FreeBSD IPv6 támogatása teljeskörő, az alaprendszer az IPv4 mellett az IPv6-ot is tartalmazza, így nem kell külön telepíteni, csak az interfészekre engedélyezni használatát. Ezt a rendszer már telepítéskor, a hálózati paraméterek beállításakor felajánlja.
57/92
A BSD/Kame implementáció tekinthetı messze az egyik legjobb IPv6 hoszt implementációnak, a következı fıbb szolgáltatásokat támogatja: • IPv6 alap protokoll (RFC460) • A unicast és multicast címzési architektúra. (RFC2373, RFC2374, RFC2375) • ICMPv6 (RFC2463) • MTU felismerés (RFC1981) • Állapotnélküli autokonfiguráció (RFC2462) • Szomszéd felismerése (RFC2461) • IPv6 jumbogramm (RFC2675), korlátozott támogatás, mivel a loopback interfész kivételével nincs olyan interfész, amely ezt a csomagméretet támogatná. • RIPng router szoftverek által (route6d, hroute6d, bgpd) (RFC2080) • BGP4+ (bgpd) (RFC2283, RFC2545) • IPv6 router alert opció (RFC2711) • Név lekérdezés ICMPv6-al (ICMPNAME) • Protokoll Független Multicasting sőrő és ritka módban (RFC2362) • Multicast Listener discovery protokoll (RFC2710) • IPv6 MIB-ek (RFC2465)(RFC2466) • Konfigurált tunnel • FAITH transzlátor (A típusú TRT transzlátor). • 6to4 stf tunnellel (6TO4) • DNS IPv6 támogatásához (RFC1886) • DNS resolver mőködı IPv6 transzporton • alapvetı IPv6 felhasználói programozási interfész (RFC2553) • kiterjesztett IPv6 programozói interfész támogatása (RFC2292bis) • IPv6 Ethernet (RFC2464), Arcnet (RFC2497), FDDI (RFC2467) ATM (RFC2492) és pont-pont kapcsolat (PPP) (RFC2472) felett • Kísérleti DHCPv6 • Az FTP (RFC2428, RFC1639) • IPSec támogatás (RFC1825 - RFC1829, RFC2401-RFC2411)
58/92
Apple
Korábbi MacOS-re a Mentat készített IPv6 implementációt. Az Apple fejlesztıi készletet készíitett IPv6-hoz a MacOS X-alá, azonban IPv6 implementáció még nincs. A MacOS Darwin alrétege elvileg támogathatja, de amíg a felsı szintek (GUI) nem rendelkezik IPv6-tal, addig az Apple nem fogja hivatalosan támogatni. IBM
Az IBM AIX a 4.2 verziótól kezdve támogatja az IPv6-ot az alaprendszer részeként. Az IBM implementációja az INRIA kódra alapul. A kernel szintő protokoll megvalósításon túl szinte minden jelentıs hálózati segédprogram is tartalmazza az IPv6 ámogatást. Megjelenésekor kimagasló volt az AIX IPv6 kezelhetıség szempontjából, egyrészt mivel nem kellett semmilyen további telepítést végezni használatához, másrészt pedig az IPv6 konfigurációja integrálva volt az AIX rendszermenedzsment alkalmazásába, a SMIT-be. Fıbb jellemzık: • Alap IPv6 protokollok • ICMPv6 • Szomszédfelderítés • Állapotmentes autokonfiguráció • IPSec • Konfigurált és automatikus tunnelek • Hálózati alkalmazások és segédprogramok IPv6 támogatással Router jellegő termékek Cisco
Útválasztók közül mindenképpen a Cisco implementáció a legkiforrottabb és a legszéleskörőbb. Már viszonylag korán, 1997-ben elérhetı volt tesztelésre a kísérleti verzió, igaz a legtöbb gyártóhoz képest viszonylag bonyolult módon, titoktartási nyilatkozat aláírásával lehetett hozzájutni.
59/92
Jelenleg már „hivatalos” változat is létezik, a 12.2(1)T IOS verzió óta az IPv6 hivatalosan is része a Cisco routerek operációs rendszerének. [CISCO] A Cisco a támogatást három fázisra bontja, az eredeti bejelentés szerint az elsı fázis 2000 ıszén, a második 2001 közepén, a harmadik 2001 után következik be. A tapasztalat azt mutatja, hogy a valós állapot kb. 6-9 hónapos késést mutat. IPv6 támogatás jelenleg az IP+ for IPv6, Service Provider és Enterprise IOS verziókban érhetı el, a következı platformokon: Cisco 800, 1400, 1600, 1700, 2500, 2600, 3600, 4x00, AS5x00, 7200, 7500 sorozat. A Cisco 10000 sorozat csak késıbb lett támogatott, az 12000-es sorozat csak teszt szinten támogatott, a 2. fázisban lett hivatalos IPv6 támogatás ehhez az eszközhöz. Az Cisco IPv6 implementáció fı tulajdonságai, fázisokra bontva: 1. fázis: • IPv6 alap protokoll RFC 2460 szerint • RFC2373 szerinti címzési architektúra • ICMPv6 RFC2463 szerint • Környezetfelmérési Protokoll (Neighbor Discovery) RFC2461 szerint • RFC 2462 szerinti állapotmentes autokonfiguráció • MTU discoveryRFC 1981 szerint • RIPv6 routing protokoll RFC2080 szerint • BGP4+ RFC2283 és RFC2545 szerint • Automatikus és konfigurált tunnelek • 6to4 áttérési módszer • ACL támogatás IPv6-hoz • DNS támogatás (AAAA rekordok) • 10, 100, 1000 Mb/s Ethernet támogatás RFC2464 szerint • FDDI támogatás RFC2467 szerint • ATM PVC és LAN emulation támogatás • Cisco HDLC támogatás • Részleges PPP és dial-up támogatás 60/92
• segéprogramok (telnet, ping, traceroute) 2. fázis: • RFC2711 Aouter Alert opció • Integrated IS-ISv6 • 6over4 tunnel • Extendec ACL IPv6 támogatás 3. fázis: • OSPFv6 RFC2740 szerint • EIGRPv6 • RFC2509 szrinti fejléc tömörítés • Dymanic Packet Transport Ezek közül jelenleg az 1. fázis szolgáltatásai érhetık el, tapasztalat szerint mőködésük megbízható. Ezt támasztja alá a tény, hogy a 6bone több éve nagyrészt Cisco termékekre alapozva mőködik. Konfigurálás szempontjából az IPv6 teljes mértékben illeszkedik a megszokott IOS mechanizmusokba, mind az alap hálózati protokollok, mind a routing protokollok szempontjából (ez korábbi teszt verzióknál nem mindenhol volt így). A következı egyszerő példa a wombat.ik.bme.hu router konfigurációjából származik, egy 6to4 tunnel és egy Fast Ethernet interfész konfigurációját mutatja: interface Tunnel0 no ip address no ip redirects ipv6 enable ipv6 unnumbered FastEthernet0/0 tunnel source FastEthernet0/0 tunnel mode ipv6ip 6to4 ! interface FastEthernet0/0 ip address 152.66.243.49 255.255.255.0 duplex auto speed auto ipv6 enable ipv6 address 3FFE:2F00:10::1:3E/126 ipv6 address 3FFE:2F00:10:2::/64 eui-64 ipv6 address 2002:9842:F3F9:1::/64 eui-64 ipv6 nd ra-interval 600 ipv6 nd ra-lifetime 3600 ipv6 nd prefix-advertisement 3FFE:2F00:10:2::/64 2592000 604800 onlink autoconfig
61/92
A következı példa az interfész IPv6 állapotát mutatja: dingo#show ipv6 interface fastEthernet 0/0 FastEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::230:85FF:FE65:9960 Global unicast address(es): 3FFE:2F00:10::1:3E, subnet is 3FFE:2F00:10::1:3E/126 3FFE:2F00:10:2:230:85FF:FE65:9960, subnet is 3FFE:2F00:10:2::/64 2002:9842:F3F9:1:230:85FF:FE65:9960, subnet is 2002:9842:F3F9:1::/64 Joined group address(es): FF02::1 FF02::2 FF02::1:FF65:9960 FF02::1:FF01:3E MTU is 1500 bytes ICMP error messages limited to one every 500 milliseconds ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 600 seconds ND router advertisements live for 3600 seconds Hosts use stateless autoconfig for addresses.
Hitachi
A Hitachi Internetworking ága igen aktív az IPv6 fejlesztésében. 2001. február óta a GR2000 gigabit-routre terméke hivatalos IPv6 támogatással rendelkezik. A Hitachi szoftver a Kame IPv6 kódon alapul és a gyártó ígérete szerint folyamatosan követi a szabványok fejlıdését. [HITACHI] Fıbb jellemzık: • LAN interfészek: Ethernet, Fast Ethernet, Gigabit Ethernet • WAN interfészek: OC-48 sebességig • Alap IPv6 protokoll • ICMPv6 • Környezetfelmérési Protokoll (Neighbor Discovery) • Állapotmentes autokonfiguráció • Részleges DNS támogatás (AAAA rekordok, de csak IPv4 felett) • Csomagszőrés • DiffServ IPv6 QoS • Konfigurált tunnelek • IPv6 MIB-ek (RFC2452, RFC2454, RFC2465, RFC2466)
62/92
• RIPng • BGP4+ • OSPFv3 • segédprogramok (telnet, traceroute, ping, ftp, rlogin) Juniper
A Juniper Networks 2001 októberében jelentette meg a JUNOS 5.1-es verzióját, amely minden routerén támogatja az IPv6-ot. [JUNIPER] Fıbb tulajdonságai: • Alap IPv6 protokollok, hardveres gyorsítással • ICMPv6 • Szomszéfelmérés • Állapotmentes autokonfiguráció • RIPng • BGP • IS-IS • Konfigurált tunnelek • MPLS Mrt
A Multi Threaded Routing Toolkit több platformon (Linux, FreeBSD, Solris és Windows NT) ad RIPng és BGP4+ támogatást. Mőködéséhez szükség van az alaprendszer IPv6 támogatására, mivel az Mrt csak a routng protokollokat valósítja meg. [MRTD] A rendszer forrásban hozzáférhetı. Zebra
A Zebra szoftver Linux, FreeBSD, NetBSD és OpenBSD alatt nyújt RIPng és BGP4+ támogatást. A rendszer forrásban hozzáférhetı.
63/92
Összehasonlítások
Megállapítható, hogy a hoszt implementációk jelenleg már mind állnak olyan fejlettségi szinten, hogy az alap IPv6 protokollokat támogatják. Azaz, szinte minden implementáció képes legalább olyan szinten mőködni, mint IPv4-gyel. A fejlett szolgáltatások körében sokkal nagyobb a különbség, és még nagyobb az alkamazások körében. A következı táblázat a hoszt implementációk összehasonlítása a támogatott szolgáltatások, a rendelkezésre álló alkamazások és a használhatóság (dokumentáltság, konfigurálhatóság, telepítés) alapján. Az értékelés 1-5-ig, 5 a legjobb. Hoszt
Szolgáltatások Alkalmazások Használhatóság
Kame
5
5
5
Linux
5
5
4
Sun
5
4
4
HP
3
3
4
FreeBSD
5
5
5
Vista
5
4
4
IBM AIX
4
3
5
A router implementációk összehasonlítása lényegesen bonyolultabb, mivel a támogatott szolgáltatások mellett a megbízható mőködés is elsırendő szempont. Mindezeket figyelembe véve teljeskörő szolgáltatói használatra jelenleg csak a Cisco és a Juniper implementáció alkalmas. Bár több gyártó is megjelent sok szolgáltatással bíró implementációval, egyik sem volt olyan mérető kvázi-éles tesztnek alá vetve, mint a Cisco, amely többek között a 6bone gerinc nagyrészének infrastruktúráját adta. Ugyanakkor várható, hogy más router gyártók is igen hamar felzárkóznak.
64/92
A külföldi szolgáltatók migrációs stratégiái Helyzetkép
Ahogy várható volt, az IPv6, mint szolgáltatás elıször a kutatási/akadémiai szférában jelent meg, a kommerciális szolgáltatók egyelıre óvatosak a kérdés tekintetében. Az IPv6 bevezetésében és szolgáltatás nyújtásában több elkülönülı fázis lehet felismerni: • szolgáltató nélküli mőködés – tipikus példa volt erre a 6bone, amely elsıször IPv4 tunnelek felett kötötte össze a kísérletben részt vevı feleket. A részvétel önkéntes és viszonylag kis befektetést igényelt. A partnerek önkéntes alapon nyújtanak egymásnak tunnel, esetleg natív IPv6 szolgáltatást. A címtartomány kezdetben egy „lapos” teszt címtartomány volt, majd 3 éve áttért a 6bone a globálisan aggregálható címek használatára, ahol a 6bone kapott egy TLA-t, amelyet tovább oszthat. Így lehetıség nyílt a valós környezet szimulálására, létrejöttek a 6bone gerinc csomópontok (Magyarországon a BME-FSZ csomópont). A gerinc mőködésnek vannak bizonyos mőszaki (pl. BGP4+ használata) és adminisztratív (a 6bone közössége nem emel kifogást, illetve tunneleket ad) feltételei. A gerinc csomópontok ezek után gyakorlatilag szabadon szolgáltathatnak tovább. A valós IPv6 címek osztásának megkezdése óta van átjárás a 6bone és az IPv6 Internet között, tehát a 6bone-hoz kapcsolat hálózat általában képes más IPv6 helyek elérésére is és viszont. • Egyes szolgáltatók, fıleg az akadémiai és kutatói hálózatok szolgáltatói rendelkeznek IPv6 címtartománnyal és szolgáltatnak IPv6-ot. A szolgáltatás egyik esetben sem nevezhetı véglegesnek, inkább kísérleti jellegő. Gyakori, hogy a szolgáltatás kutatási projekt keretében valósul meg. hazánkban ilyen volt a 6net és a camp6 projekt. • Kereskedelmi szolgáltatók egyes országokban (pl. Japán, Franciaország) megkezdték az IPv6 szolgáltatást. A lépések igen óvatosak, ennek oka a még kiforratlan infrastruktúra és a nem teljesen tisztázott adminisztratív környezet. A router és egyéb eszközök szoftverei még hivatalosan nem alkalmasak éles
65/92
üzemre,
tehát
kevés
szolgáltató
meri
megkockáztatni,
hogy
IPv4
infrastruktúráját használja egyben IPv6-ra is. A címek osztás még nem teljesen tisztázott, a RIPE által kezdetben osztott címek igénylıinek pl. vállalniuk kellett, hogy egy éven belül valóban szolgáltatnak is. Ez a vállalás sem mindig tartható be üzleti körülmények között, hiszen egyelıre kétséges/hiányzik a fizetıképes igény az IPv6-ra. A kísérletezık szinte minden igényét kielégíti a 6bone, a nagyközönség pedig sem technikailag sem igény szinten nem felkészült. Jelenleg jóval 100 felett van a kiosztott „production” subTLA-k száma. Ezek között jelentıs számú a japán és a koreai, valamint az európai. Meglepıen kevés a USA-ban igényelt TLA-k száma, ez az ottani IPv4 címek bıségével is magyarázható. Magyarországon jelenleg a HUNGARNET rendelkezik éles IPv6 tartománnyal, a 2001:0738::/35 tartomány 2001 július 17.-én lett számára allokálva. A kezdeti allokációs fázisban /35 mérető címeket osztottak, ez több szempontból (pl. DNS) kényelmetlen, ezért várható ennek a gyakorlatnak a megváltoztatása. Jelenleg több mint 10 exchange point létezik a szolgáltatók közötti IPv6 forgalom kicserélésére. Néhány példa
A Dante kísérleti IPv6 hozzáférési pontokat biztosít hálózatában. [DANTE] A France Telecom a Nokiával karöltve dolgozik az IPv6 migrációs stratégián [FRTLC]. A kanadai Viagénie ingyenes IPv6 hozzáférést biztosít tunnel szerveren keresztül. 2000 októberében a Uecomm ausztrál szolgáltató megkezdte az IPv6 szolgáltatást, nagyrészt Ericsson eszközökre alapozva. A japán NTT 2001. álpilis 27.-tıl natív és tunnelezett IPv6 szolgáltatást nyújt kereskedelmi alapon. A Verino Inc.-del együtt megkezdték az elsı kereskedelmi IPv6 gerinc üzemeltetését. A felhasználóknak /48 mérető címtartományokat adnak. A natív
66/92
hozzáférés 64kbps-tól 100Mbps-ig terjed, 95 000 – 32 300 000 jen havi díjért. [NTTV6] 2000 augusztusban a hong kongi HKNet megkezdte az IPv6 szolgáltatások nyújtását. [HKNET] A 6ren kezdeményezésben részt vevı szervezetek (CAIRN, CERNET, DANTE, ESNet, NTT, Sprint, Wide, MCI) IPv6 szolgáltatást nyújtanak oktatási és kutatási hálózatokban. [6REN] A Stealth Communications IPv6 tunnelen keresztül nyújt IPv6 szolgáltatást. [STEALTH] Az MCI Worldcom a vBNS+ szolgáltatás keretében IPv6 kapcsolatot is ad, addicionális költségek nélkül. [VBNS]
Cím allokáció
Az
éles
szolgáltatás
nyújtásának
elıfeltétele
a
megfelelı
cím
allokációs
mechanizmusok kialakítása. Legfelsı szinten az IANA (Internet Assigned Numbers Authority) birtokolja az IPv6 címteret és az osztás jogát delegálja regionális registry-k és szolgáltatók felé. Az IANA három szervezetnek delegálta a subTLA regisztrációt: az APNIC, az ARIN és a RIPE-NCC. Európában a RIPE által kiadott „Provisional IPv6 Assignment and Allocation Policy Document” (Ripe-196) dokumentum szabályozza az IPv6 címek igénylését és osztását. [RIPE] A dokumentum elıírja a címek hierarchikus és hatékony osztását. A címek /48 hosszúságban jelképezik a publikus topológiát, tehát figyelembe véve az EUI-64 címzési módot, minden felhasználónak (site) 16 bit áll rendelkezésére a belsı, lokális topológia kialakítására. Az induló cimosztás során a cím további részét a következı módon osztják:
67/92
001
TLA 13 bit
subTLA 13 bit
res 6 bit
NLA 13bit
SLA ID 16 bit
64-n bit interfész azonosító
Az elsı allokációs körben a TLA 13 bitjét (subTLA) használják osztásra, azaz egy /35 mérető tartományt adnak. Ha ez a tartomány betelt, akkor van lehetıség további TLAk illetve a tartalék 6 bit felhasználására. A kezdeti fázisban (bootstrap phase) az a kérelmezı juthat IPv6 címhez, amely legalább 3 más autonóm rendszerrel van peering kapcsolatban, meggyızıen bemutatja, hogy egy éven belül IPv6 szolgáltatást nyújt és vagy vannak alsóbb szintő kapcsolatai, amelyeknek IPv6 címet tud osztani, vagy bemutatja, hogy IPv6 gyakorlattal rendelkezik, amely legalább 6 hónapos 6bone kapcsolatot jelent, amelybıl legalább 3 hónap pTLA mőködés volt. Az induló fázis az elsı 100 igény kielégítéséig tart, amely megtörténte után már csak az a kérelmezı juthat IPv6 címhez, akinek legalább három másik olyan szervezettel van peeringje, amelyek rendelkeznek IPv6 címtartománnyal és a szervezetnek vagy van már IPv6 címe felsıbb szintő szolgáltatótól vagy meggyızıen bizonyítja, hogy egy éven belül IPv6 szolgáltatást indít. Mivel az induló fázis befejezıdött, ezért a második szabályozás van életben. Várható, hogy ebben a szabályozásban változások lesznek. A TLA-val rendelkezı szervezetek a 13 bites NLA-t használhatják a címek további osztására, tehát /48 hosszúságú címeket oszthatnak. Ha egy NLA registry felhasználta tartományának 80%-át, akkor igényelhet további tartományt a TLA registry-tıl. Az NLA tovább osztható a 16 bites SLA tartományban. ISP-k esetében a dial-up vonalakat egy SLA blokkból kell kiszolgálni, mivel ezek a vonalak az ISP infrastruktúrájának részeként számítanak.
68/92
A migrációs lépések és környezet Az áttérés fázisai
Az IPv6 bevezetését a következı fázisokra lehet bontani: • Kezdeti szakasz: IPv6 hálózatok (szigetek) a túlnyomó részt IPv4 világban, a gerinchálózati IPv6 támogatás csekély. • Bevezetés folyamata: Közel azonos mennyiségő IPv4 és IPv6 hálózat, a gerinchálózatok nagyrészt IPv6 támogatással rendelkeznek. • Bevezetés vége: IPv4 hálózatok a túlnyomórészt IPv6 világban • Bevezetés megtörténte: elszórt IPv4 eszközök a teljesen IPv6 világban. Ennek során különbözı feladatokat kell az áttérési eszközöknek megoldani: • Biztosítani az IPv6 szigetek összekötését IPv4 felett • Biztosítani az IPv6 hálózatokban elhelyezkedı IPv4 eszközök kommunikációját • Biztosítani az IPv4 hálózatokban elhelyezkedı IPv6 eszközök kommunikációját • Biztosítani az IPv4 szigetek összekötését IPv6 felett • Biztosítani a csak IPv4/IPv6 eszközök kommunikációját csak IPv6/IPv4 eszközökkel Az áttérés során várhatóan több elıre nem látható kérdés fel fog merülni. A jelenlegi technológiák fıleg az áttérés elsı fázisát támogatják, a késıbbi fázisokra vannak kidolgozott, de gyakorlatban ki nem próbált megoldások. [RFC2893] Az áttérési eszközök két nagy csoportra oszthatók, az egyik az IPv4/IPv6-ot egyszerre támogató platformokon használható dual-stack és tunneling megoldások, a másik pedig a két protokoll közötti transzlációt végzı megoldások. A mai gyakorlatban (pl. 6bone) túlnyomó részt az elsı megoldások vannak használatban, így ezek tekinthetıek már kipróbált megoldásnak. Áttérési eszközök Dual-stack implementációk
A legegyszerőbb módja annak, hogy egy eszköz IPv4-en és IPv6-on is képes legyen mőködni, a dual-stack (kettıs protokoll készlet) megoldás. Az IPv4 és az IPv6
69/92
különálló protokollként szerepel az eszközben, így egymástól függetlenül képesek mőködni. A kapcsolat kialakítása attól függıen történik IPv4 vagy IPv6 felett, hogy milyen címet ad meg az alkalmazás, vagy milyen címet illetve milyen sorrendben ad vissza a DNS. A dual stack elınyei az egyszerő megvalósítás, a rugalmas és minden környezetben mőködıképes megvalósítás és az egyszerő üzemeltetés és az, hogy a kommunikáció továbbra is végpont-végpont jellegő marad és direkt módon történik. [DSTM] Hátránya,
hogy
a
teljeskörő
kommunikációhoz
tulajdonképpen
kétszeres
adminisztráció tartozik, hiszen nem csak IPv4 de IPv6 címmel is el kell látni az eszközöket. Ennek megfelelıen skálázhatósága rossz, hiszen nem oldja meg az IPv4 címek szőkösségét, illetve minden ebbıl következı problémát, mint például a nem hatékony útválasztást. Szintén hátrány, hogy teljes mértékben meg kell tartani a párhuzamos IPv4-IPv6 infrastruktúrát. Mindezen elınyöktıl és hátrányoktól függetlenül szinte minden jelenlegi hoszt megvalósítás dual stack, hiszen mindkét protokollt támogatja. Csak IPv6 protokoll megvalósításának egyébként is legfeljebb korlátozott kapacitású (pl. embedded) rendszerek esetén vagy az áttérés késıi szakaszában van értelme. AIIH
Abban az esetben, ha már a kommunikáció nagyobb része IPv6 felett zajlik, akkor a dual stack megoldásnak egy módosított formáját lehet alkalmazni. Ha egy szervezet rendelkezik valamennyi IPv4 címmel, akkor ezeket a címeket idılegesen hozzárendelheti az IPv4 felett kommunikálni próbáló eszközökhöz. Ez természetesen feltételezi, hogy egy idıben legfeljebb annyi eszköz kíván IPv4 kapcsolatot létesíteni, hogy az igény ebbıl a cím-készletbıl kielégíthetı. Az alapvetıen IPv6 mőködéső eszköz, ha IPv4 felett kíván kommunikálni, akkor az AIIH szerverhez fordul, amely idıleges IPv4 címmel látja el. Az AIIH szerver tulajdonképpen egy módosított DHCP szerver, az AIIH igényeinek megfelelı mőködéssel. Mivel az IPv4 kommunikáció befejezte nem detektálható egyértelmően, ezért a címek újrafelhasználására valamely idızítés lejárta után van lehetıség, ha egyébként a kapcsolat már bezárult. 70/92
Az AIIH megtartja a dual-stack megoldás elınyeit, és kibıvíti a viszonylagos skálázhatósággal, hiszen nem kell annyi IPv4 cím, ahány IPv6. Ugyanakkor több hátránnyal is rendelkezik. A mőködés az AIIH/DHCP szerver köré szervezıdik, amely növeli a rendszer komplexitását és hibalehetıségeit, valamint többlet forgalmat generál. A szerver által osztható IPv4 címek elfogyása lehetetlenné teszi a további IPv4 kommunikációt, amíg fel nem szabadul cím. A címek felszabadulása csak idızítık alkalmazásával lehetséges, tehát egy kapcsolat lezárulása nem jelenti a cím azonnali újrafelhasználhatóságát. Az AIIH a DSTM részévé vált. Bump-in-the-stack (BIS)
A BIS a dual-stack és a transzlációs megoldások ötvözése. Mőködése egy IPv4-IPv6 konverteren alapul, amely azonban nem különálló eszközként van megvalósítva, hanem az adott eszközben az alkalmazás illetve a TCP-IPv4 réteg és a hálózati interfész meghajtója közé ékelıdik be. Jelentısége fıleg olyan örökölt IPv4 alkalmazások esetében van, amelyeket nincs mód IPv6-ra módosítani. Az alkalmazás továbbra is IPv4-et „beszél”, azonban mielıtt a csomagok a hálózatra jutnának, a fordító IPv6-tá konvertálja ıket. A címek feloldásánál módosítani kell a DNS resolvert, ugyanis a régi alkalmazás csak IPv4 címek lekérdezésére és fogadására van értelemszerően felkészítve. Az alkalmazás IPv4 kérését IPv6 cím lekérdezésre kell konvertálni és ezzel egyidıben egy olyan privát IPv4 címet kell visszaadnia, amihez a BIS eltárolja a címfeloldás során kapott IPv6 címet. Innentıl kezdve az alkalmazás használja ezt az IPv4 címet, miközben a BIS az egyébként kapott IPv6 címre konvertál és viszont. Az BIS elınye, hogy tetszıleges alkalmazás IPv6 kompatibilissé tehetı, akkor is, ha forrásban nem áll rendelkezésre. Skálázhatósága jó, mivel IPv4 címekre nincs szükség, illetve csak az adott csomópontok belül kell (privát) címeket osztani, amelyek a hálózaton nem jelennek meg. A BIS lehetıvé teszi csak IPv4 csomópont IPv6 csomóponttal való kommunikációját.
71/92
Hátránya, hogy bizonyos esetben nem alkalmazható, pl. ha olyan protokollt használó alkalmazást használunk, amely IPv4 címeket használ közvetlenül (pl. FTP). Ugyancsak problémás funkcionalitásban különbözı szolgáltatások (pl. ICMP – ICMPv6) használata. Bump In the Api (BIA)
A BIA hasonló megoldást kínál, mint a BIS, azonban a az IPv4-IPv6 konverzió nem az eszköz IP stackjébe van beékelve, hanem a alkalmazás és az operációs rendszer közé. A BIA az alkalmazás felé a hagyományos IPv4 programozói felületet nyújtja, az operációs rendszer felé pedig az IPv6 felületet. Elınye, hogy gyakran megoldható az alkalmazás újrafordítás nélkül, pusztán a dinamikus könyvtár kicserélésével. Lehetıséget ad továbbá alkalmazások szelektív áttérésére. Hátránya a nem mindig egyszerő kivitelezhetıség és a nem azonos funkcionalitás kérdése. Tunneling
A tunneling (alagút) megoldások során az IPv6 csomagokat IPv4 csomagokba becsomagolva továbbítjuk. [RFC2473] A tunnel egyik végpontján az elküldendı IPv6 csomagot egy IPv4 csomag adatrészébe helyezik, és tisztán IPv4 felett a hálózat eljuttatja a másik végpontra, hasonlóan a VPN-ek kialakításához. A fogadó oldal „kicsomagolja”, tehát az IPv4 csomagból kiveszi az IPv6 csomagot, majd ezek után már mint IPv6 csomag dolgozza fel. IPv4 fejléc IPv6 fejléc
IPv6 fejléc
adat
adat tunneling
IPv4 csomag adat része
3. ábra: Tunneling alapelve 72/92
A tunnel az IPv6 szempontjából egy pont-pont kapcsolatnak felel meg. A tunnelt megvalósító hálózat mőködhet tisztán IPv4 felett, hiszen minden IPv6 forgalom IPv4 forgalomba van csomagolva. A tunnelnek különbözı jellemzıi, mint pl. MTU vannak. A tunnelezés tipikus felhasználása IPv6 hálózatok összeköttetése, ennek megfelelıen használata az áttérés elsı fázisában jelentıs. Lehetıség van egyes csomópontok közötti kapcsolatra is. A tunnelek kialakítása, paraméterezése, címzése alapján különbözı tunelling mechanizmusok léteznek. A tunneling megvalósítása általában egyszerő, és IPv6 szempontjából transzparens. Skálázhatósága jó, de a végpontoknak rendszerint globális IPv4 címre van szükségük. Értelemszerően a végpontoknak dual-stack megoldással kell rendelkezniük. Problémát jelenthet az a tény, hogy az IPv6 hálózatnak nincs tudomása a tunnelezésre használt IPv4 hálózatról, így az útválasztási feladatok vagy QoS jellemzık nem tarthatók, vagy nem adnak értelmes eredményt. Gondok jelentkezhetnek a biztonsággal is, mivel a kicsomagolás során biztosítani kell, hogy a beágyazott csomag érvényes forrás és cél címekkel rendelkezzen. Ellenkezı esetben pl. hamis címmel rendelkezı csomagokat lehetne a tunnelen keresztül a hálózatba injektálni. A forgalom csomagolása többletterhelést jelent. A tunneling nem
teszi lehetıvé csak
IPv4 és
csak IPv6 csomópontok
kommunikációját. Ugyancsak problémás nem fix IPv4 címek kezelése, a legtöbb tunnel megoldás csak fix IPv4 címekkel mőködik, tehát pl. NAT mögötti Intranet esetében nem mőködik. Kivétel ez alól a „Shpiworm” megoldás. Automatikus tunneling
Az automatikus tunneling segítségével IPv6 alkalmazások kommunikálhatnak IPv4 hálózat felett. A kommunikáció annyiban nem transzparens, hogy a kapcsolat során nem „igazi” IPv6 címet, hanem speciális, IPv4 kompatibilis IPv6 címet kell használni. A címben az ellenállomás IPv4 címe szerepel, és mindkét végpontnak kell rendelkeznie kompatíbilis címmel.
73/92
A küldés során az erre a címre küldött csomag automatikusan IPv4-be csomagolódik, és IPv4 felett kerül el a célállomásra. A fogadó kiveszi az IPv6 csomagot és azt dolgozza fel tovább. Elınye, hogy a meglevı IPv4 infrastruktúrát egyszerően lehet IPv6-ra átállítani, a kompatibilis címek használatával. Ennek kísérleti IPv6 üzem esetén van jelentısége. Ha minden jól mőködik, akkor egy további átszámozással végleg át lehet térni IPv6-ra. Akkor is használható, ha a végpontok kivételével más (még a közvetlen környezet sem) nem támogatja az IPv6-ot. Hátránya, hogy gyakorlatilag csak hoszt-hoszt kapcsolatra alkalmas és teljes IPv4 hálózatot igényel. A címzése az IPv4 címeken alapul, tehát skálázhatósága rossz, bár meglévı hálózatban könnyen bevezethetı. Bizonyos IPv6 szolgáltatások, mint pl. a multicast, nehezen használható. Ugyancsak elveszhet bizonyos (pl. QoS) információ. Konfigurált tunneling
Az automatikus tunnellel ellentétben a konfigurált tunnel tipikusan IPv6 hálózatok összekötetésére szolgál, viszont a végpontoknak nem kell IPv4 kompatíbilis címmel rendelkezniük, csak IPv4 címmel. Jelentısége az áttérés elsı fázisában nagy, hiszen fıleg ekkor kell izolált IPv6 hálózatokat összekötni. A tunneleket a rendszeradminisztrátor hozza létre, ebbıl ered a „konfigurált” elnevezés. A konfigurált tunnel esetében a végpontokon meg kell határozni a másik oldal IPv4 címét és az útválasztási táblába fel kell venni az ellenoldali IPv6 címet vagy prefixet. A alagutak kialakítása manuális munkát igényel, de az egyszer felkonfigurált tunnel további beavatkozás nélkül mőködik. Elınye az egyszerő és transzparens kialakítás. Hátránya a manuális kialakítás és az, hogy az IPv4 feletti átvitel miatt bizonyos szolgáltatások (pl. multicast, QoS) nem teljesértéküek. A tunneling során használt csomagolás többletterhelést okoz az átvivı hálózaton.
74/92
Fontos megjegyezni, hogy ez idáig a konfigurált tunneling az egyetlen igazán nagy mértékben kipróbált áttérési mechanizmus, a 6bone évek óta nagyrészt tunnelek segítségével mőködik. Tunnel broker
A tunnel broker tulajdonképpen nem önálló áttérési mechanizmus, hanem a konfigurált tunnelek során szükséges manuális beavatkozást küszöböli ki. A tunnel broker feladata tunnel létrehozási kérések lekezelése. Ennek során azonosítja a tunnelt kérı felhasználót (pl. jelszó), majd ezek után a megfelelı paraméterekkel létrehozza, módosítja vagy törli a tunnelt. A tunnel broker elınye a manuálisan konfigurált tunnelehez képest az egyszerő és automatizált használat. Dinamikus tunneling
A dinamikus tunneling (DTI) során IPv4-es csomagokat helyezünk IPv6-os csomagokba. Ennek megfelelıen az áttérés késıi fázisában használható, amikor már nincsen mindenhol IPv4 infrastruktúra. Ha DTI-vel ellátott dual stack útválasztó van két IPv4 hálózat szélén, akkor az IPv4 forgalom képes átjutni a közbensı IPv6 hálózaton. A DTI tulajdonképpen az AIIH „fordítottja”. Elınye, hogy egyszerő és nincsen szükség párhuzamos IPv4 - IPv6 infrastruktúrára. DSTM A Dual Stack Transitional Method (DSTM) gyakorlatilag az AIIH és a DTI ötvözete. Teredo – IPv6 over UDP over NAT
A „hagyományos” tunnel módszerek nem mőködnek NAT mögötti hálózatokon, a globális IPv4 cím hiánya miatt. A Shipworm (fúrókagyló – „átfúrja” a NAT-ot) abban az esetben alkalmazandó, ha NAT mögött lévı IPv4 csomópontok szeretnének az Interneten lévı IPv6 csomópontokkal kommunikálni és nincsen más, egyszerőbb módszer (pl. 6to4). A Shipworm UDP felett viszi át az IPv6 csomagokat, a külsı Shipworm szerverhez, illetve
relay-hez.
Külön
csomagokkal
biztosítja
a
NAT
által
alkalmazott
címtranszformáció megállapítását, illetve a transzformáció folyamatos fenntartását. 75/92
A Shipworm megoldás jelenleg fejlesztés alatt áll. 6to4
A tunnel menedzsment nehézségeinek elkerülésére a tunnel broker mellett másik módszer a 6to4. [RFC3056] A 6to4 speciális IPv6 címet használ a tunnel végpontok hirdetésére. A 2002::/16 globálisan aggregálható prefix van erre a célra fenntartva.
001
0x0002
6to4 IPv4 cím
13 bit
32 bit
SLA ID 16 bit
64-n bit interfész azonosító
Formálisan a 6to4 címek a globálisan aggregálható címek körébe tartoznak, azonban a TLA-NLA rész egy IPv4 címet, a 6to4 router címét tartalmazza. Mivel ez a router lehet egy komplexebb hálózat kapcsolódási pontja is, ezért az SLA rész megmarad és lehetıvé teszi ugyanazt a felosztást, mint az „igazi” IPv6 címek esetében, sıt az intézmény belsı címzési struktúrája teljesen megegyezhet a normál IPv6 felosztással, hiszen a 6to4 cím formálisan felfogható úgy, mint egy másik szolgáltató által adott címtartomány (prefix). Kommunikáció kezdeményezése során a 6to4 router észleli, hogy a célzott cím 6to4, és ekkor egy idıleges tunnelt épít ki a címben megadott IPv4 címhez, és a további kommunikáció ezen keresztül folyik. A forgalmat a tunnel esetében a hagyományos IPv4 infrastruktúra továbbítja. A végpont a kapott csomagokat kibontja az IPv4 csomagból és belsı hálózatában már IPv6 csomagként továbbítja. Amennyiben az egyik végpont normál IPv6 címmel is rendelkezik a 6to4 mellett, akkor sincsen különösebb tennivaló, hiszen pl. a DNS visszaadja minkét címet és ekkor a 6to4 címmel lehet csak kapcsolatot felvenni. Célszerő, ha az alkalmazás vagy a resolver tudja, hogy van-e vagy nincs IPv6 kapcsolat a 6to4 mellett, mert ettıl függıen elıször az egyik vagy a másik címet kell használni. Ha nincs IPv6, akkor úgyis a 6to4 címmel lehet csak felvenni a kapcsolatot, de ha van, akkor nem célszerő ha az alkalmazás 6to4 címmel kezdeményezi a kapcsolatot, ugyanis az ekkor is létrejön, de a tunnelezés miatt többlet terhelést okoz. A direkt kommunikáció csak akkor nem mőködik, ha az egyik fél csak IPv6 a másik pedig csak 6to4 címmel rendelkezik, azaz nincs IPv4 kapcsolat a kettı között. Ekkor 76/92
szükség van egy minkét kapcsolattal rendelkezı 6to3 relay-re, amely a tunnelinget elvégzi. Ebben az esetben a relay hirdeti a 6to4 prefixet, míg a normál IPv6 kapcsolat szőri. A 6to4 elınye az egyszerő implementáció és az automatikus mőködés. Együtt tud mőködni más áttérési módszerekkel is, mivel formálisan hagyományos IPv6 címeket használ. Nem keveri útválasztás szempontjából a IPv4 és az IPv6 hálózatokat, tehát egyiknek sem nınek az útválasztási táblázatai, de vigyázni kell, hogy 6to4 prefixek ne kerüljenek hirdetésre az IPv6 hálózatban. Viszonylag jól skálázható, mert hálózatonként csak egy globális IPv4 címre van szükség. Hátrányai közé tartoznak a tunnelezés által okozott általános hátrányok. 6over4
A
6over4
tulajdonképpen
tunnelezés
explicit
tunnellek
nélkül,
hosztok
összekapcsolására egy intézményen belül. A 6over4 az IPv4-et, tulajdonképpen mint adatkapcsolati réteget tekinti, és ezen továbbítja az IPv6 forgalmat. Lényege abban áll, hogy egy intézményi (site) hatáskörő multicast címet definiál, amelyeket a 6over4 leképez IPv4 címekre és az IPv6 e felett, mint hordozó rétegen mőködik. Elınye az egyszerő, automatizált mőködés. Hátrányai közé tartoznak a tunnelezés által okozott általános hátrányok. Transzlátorok
A csak IPv4 és csak IPv6 hosztok közötti kapcsolatot csak transzláció útján lehet megoldani. Ennek során a két protokolt egymásba át kell alakítani. Az IPv4-IPv6 címeket le kell képezni egymásba, valamint további transzformációkra is szükség lehet. A transzlátor megoldások elınye az egyszerő alkalmazhatóság, ha nem túl komplex a kezelendı hálózat (pl. egy belsı IPv6 hálózatot kell a globális IPv4 Internethez kötni). A transzlációs megoldások jelentıs hátrányokkal rendelkeznek ezért mindenképpen csak átmeneti megoldásra alkalmasak. Jelentıs gond, hogy sérül a végpont-végpont jelleg a kommunikációban, ez IPSec vagy QoS esetében probléma. Ezen okból biztonsági problémákat is felvet a transzlátorok alkalmazza. A transzlátor szők 77/92
keresztmetszet lehet egy hálózatban, hasonlóan a tőzfalakhoz, hiszen a teljes forgalmat fel kell dolgoznia. A címek transzlációja további gondot jelent olyan alkalmazások és protokollok esetében, amelyben az eredeti cím is szerepel. Jellemzı példa erre az ftp. A kommunikáló hoszt és a környezet típusa szerint négy különbözı transzlátort különböztethetünk meg. Az elsı két transzlátortípus az áttérés korai szakaszában, vagyis a túlnyomórészt IPv4 Internet, míg a második két transzlátor a késıi, tehát az IPv6 Internet környezetében teszi lehetıvé a csak a másik protokollal rendelkezı csomópont kommunikációját. A további felosztás a szerint történik, hogy melyik protokolt beszélı csomópont kezdeményezi a kapcsolatot. 1. Az A típusú transzlátor a csak IPv6 csomópont, IPv4 Interneten keresztüli kommunikációját biztosítja IPv4 csomópontokkal. Ennek során az IPv4 címteret kell az IPv6 címtérbe leképezni, amely viszonylag egyszerő és egyértelmő. Erre a célra külön kompatibilitási IPv6 tartományt lehet allokálni. 2. A B típusú transzlátor az A típus „ellenkezı irányú” megfelelıje, tehát az IPv4 Interneten elhelyezkedı IPv4 csomópontok IPv6 csomópontokkal történı kommunikációját hozza létre. Ez a megoldás jóval bonyolultabb, mint az A típus, hiszen itt az IPv6 címteret kell leképezni IPv4-re, amely egyértelmően nem tehetı meg, tehát valamilyen dinamikus megoldáshoz kell folyamodni, amely további problémákat vet fel (pl. DNS caching). 3. A C típusú transzlátor feladata egy IPv4 csomópont kommunikációjának biztosítása az IPv6 Interneten lévı IPv6 állomásokkal. Ennek megoldása sem egyértelmő, mivel itt is az IPv6 címteret kell IPv4-re leképezni, de könnyebbséget jelent, hogy ebben az esetben már privát IPv4 címek is használhatóak. A dinamikus megoldás hasonló problémákat vet fel, mint a B típus esetében. 4. A D típusú transzlátor az IPv6 Inteneten lévı IPv6 csomópontok IPv4 eszközzel történı kommunikációját teszi lehetıvé. A megoldás hasonlóan
78/92
egyszerő, mint az A esetben, hiszen az IPv4 címteret egyszerően le lehet képezni IPv6-ra. ALG (Appliation Level Gateway)
Az alkalmazásszintő gateway tulajdonképpen nem más mint a pl. tőzfalakból ismert alkalmazás proxy. Ebben az esetben olyan proxyra van szükség, amely IPv4-et és IPv6-ot is tud. Mivel a transzláció alkalmas szinten történik, ezért ebben az esetben a szők keresztmetszet kivételével nem lépnek fel a más transzlátorok esetében gyakori problémák. Hátránya azonban, hogy minden alkalmazásra külön el kell készíteni, amely nem mindig praktikus. Korlátozott igények esetében (pl. belsı hálózaton csak http, smtp forgalom), gyakorlatilag tökéletes megoldást jelenthet, és mivel hasonló eszközök más okból már most is alkalmazásban vannak, ezért az áttérés zökkenımentes lehet. Socks
A hagyományos Socks protokollnak megvalósították az IPv6 változatát, amely gyakorlatilag alkalmazási szintő gatewayként mőködve képes kapcsolatot teremteni IPv6 és IPv4 csomópontok között. TRT (Transport Relay Translator)
A TRT IPv6 csomópontok által IPv4 állomások (szerverek) felé kezdeményezett kapcsolat létrehozására alkalmas. A TRT az IPv6 csomagokat IPv4-re alakítja. Az IPv4 cím leképezését IPv6-ra a DNS speciális kezelésével oldja meg, pl. DNS proxy-n keresztül. Az IPv6 csomópont a DNS lekérdezésre olyan IPv6 címet kap vissza, amely speciális IPv6 címet ad vissza, amely tartalmazza az IPv4 címet. A TRT az ezzel a prefixszel rendelkezı csomagokat alakítja IPv4-re. A TRT elınye, hogy a kapcsolat kezdeményezıje számára transzparens. Legnagyobb hátránya a skálázhatóság hiánya a nem állapotmentes transzláció miatt. A TRT A és D típusú transzlátor.
79/92
NAT (Network Address Transzlation)
A NAT régóta ismert IPv4 hálózatokban, ahol privát IPv4 címek transzlációját végzi globális címekre. IPv6 esetében hasonló módon használható, és hátrányai is megegyeznek az IPv4 NAT-éval. NAT-PT (NAT – Protocol Trasnaltor)
A NAT-PT a NAT továbbfejlesztése. A NAT-PT dinamikusan allokál IPv4 címeket minden kapcsolatot kezdeményezı IPv6 címhez, és a viaszirányú forgalomban ezeket cseréli IPv6 címekre. IPv4 címek szőkössége esetében nem csak címek, de portok alapján is transzáll (NAPT-PT, Network Address Port Transzlator – Protocol Translator). Tulajdonképpen a NAPT-PT felel meg az IPv4 Intranetek Internetre kötésekor esetében alkalmazott NAT-nak, ennek megfelelı alkalmazhatósága is. A NAT-PT elınye, hogy nem igényel annyi IPv4 címet, amennyi IPv6 csomópont található a belsı hálózatban, azonban ha kifogy a rendelkezésre álló IPv4 címekbıl, akkor további kapcsolat nem lehetséges. A NAT-PT A illetve D típusú transzlációs feladatokra alkalmas. Fejléc konverzió
Igen egyszerő transzlációs mechanizmus a fejléc konverzió (Header Converter), amely az IPv6 fejlécet cseréli IPv4-re és viszont. Elınye az egyszerő implementáció és gyors mőködés. Egyszerősége több problémát is felvet, leglényegesebb a csomagméretekbıl adódó tördelési gondok, mivel IPv6 nem tördeli a csomagokat menet közben, ugyanakkor a konvertált csomag mérte bizonyos esetben ezt szükségessé tenné. A fejléc konverter A és D típusú transzlációra alkalmas. SIIT (Stateless IP/ICMP Translator)
Az állapotmentes IP/ICMP transzlátor célja, hogy – ellentétben több más transzlációs megoldástól – állapot tartása nélkül transzláljon IPv4 és IPv4 között. Az állapotmentes megoldásnak skálázhatósági és menedzselhetıségi elınyei vannak. Az SIIT elsısorban olyan hálózat határán alkalmazható, ahol a belsı áttérés már teljesen megtörtént, és a külsı IPv4 világgal kíván kapcsolatot tartani.
80/92
Az SIIT az IPv4 translated IPv6 címet (::ffff:0:a.b.c.d) használja. Összegzés
Változatos áttérési megoldások vannak kifejlesztve, ezek közül azonban sokra még nincs implementáció és még kevesebb van a gyakorlatban is kipróbálva. A jelenlegi környezet olyan, hogy van elegendı IPv4 cím, tehát a hálózati üzemeltetıjének van lehetısége legalább annyi IPv4 cím igénylésére, amely pl. a tunnelinget lehetıvé teszi. A legtöbb hálózat még ennél is kedvezıbb helyzetben van, a tiszta dual-stack megoldást is tudják használni. A transzlációs áttérési módszerek széleskörő elterjedése nem is várható addig, amíg tisztán IPv6 csomópontok vagy hálózatok nem tömegesen meg nem jelennek, illetve a szabad IPv4 címek el nem fogyank. Addig a tunneling illetve a dual-stack kényelmes és egyszerő megoldást jelent. Várható továbbá, hogy az egyes módszerek egyre finomodnak, hiszen a legtöbb áttérési módszer az utóbbi két-három évben került kidolgozásra, és a legtöbb még nincsen véglegesítve.
81/92
Az IPv6 az e-közigazgatásban Az eddigiek alapján kijelenthetı, hogy az IPv6 protokoll kellıen érett arra, hogy a korábbi megoldásokkal párhuzamosan, vagy azokat leváltva üzemeltessük. A külföldi és a hazai tapasztalatok alapján is valószínősíthetı, hogy már rövid távon is megjelennek az IPv6-on elérhetı szolgáltatások. Legjobb példa erre a Google bejelentése, mi alapján 2008 májusától kezdve a Google keresı szolgáltatása elérhetı IPv6 felett [GOOGLE6]. Ebbıl következik, hogy megjelent az igény az IPv6 felett elérhetı szolgáltatásokra, illetve megjelennek azok a felhasználók, akik elsısorban (vagy kizárólag) Ipv6 eléréssel rendelkeznek. Ennek folyománya, hogy e-közigazgatási alkalmazásoknak már közép távon elérhetınek kell lenniük IPv6 felett is. Másik oldalról felmerül a kérdés, hogy mennyivel javítja az e-kormányzati alkalmazások mőködését az IPv6? Jelent-e az IPv6 minıségi változást? A választ több irányból közelíthetjük meg. Egyrészt az IPv6 alacsony-szintő (a felhasználó számára közvetlenül nem érzékelhetı) protokoll, ezért valójában az alkalmazások mőködése alapvetıen független tıle. Vagyis az elérhetıségen kívül (amely fontos tényezı) más befolyással nincs rá. Másrészrıl azonban az IPv6 nyújt olyan elınyöket (fıleg a skálázhatóság és az üzemeltetés területén), amely önmagában is – elsısorban az üzemeltetı és a szolgáltató – számára elınyt jelent. A már létezı IPv6 kompatibilis alkalmazások tapasztalatai alapján kijelenthetı, hogy ez minimális többletmunkát igényel, ugyanakkor egy már létezı alkalmazás késıbbi „IPv6-ositása” sokkal nehezebb feladat. Összegzésként ezek alapjánkimondható, hogy az e-közigazgatási fejlesztési projektek tervezése és fejlesztése során figyelembe kell venni az IPv6-ot, és célszerő – EU és USA példák alapján – elıírni hogy új fejlesztés csak IPv6 kompatibilis lehet.
82/92
Összefoglalás Az IPv4 és az IPv6 protokoll összahasonlítása alapján megállapítható, hogy az IPv6 több területen is jelentıs elınnyel rendelkezik az IPv4-gyel szemben. Ezek az elınyök a jelenlegi környezetben ugyanakkor nem „kényszerítı erejőek”, azaz nincsen olyan hajtóerı, amely rövid távon igényelné az áttérést. Ennek ellenére középtávon (2-5 év) számíthatunk az IPv6 használatára éles üzemben. Ennek feltétele, hogy létezzenek megfelelı implementációk, legyenek alkalmazások és az áttérés zökkenımentes legyen. Az implementációk már gyakorlatilag most is léteznek, minden jelentıs gyártónak van IPv6 megvalósítása. Várható, hogy egy éven belül ezek a termékek hivatalosan is alkalmasak lesznek éles üzemre és megfelelı támogatással fognak rendelkezni. Az alkalmazások áttérése folyamatban van, szinte minden alapvetı hálózati alakalmazásnak létezik IPv6 változata, több hivatalosan is támogatja az IPv6-ot. Amennyiben IPv4 alkalmazást kell IPv6 feletti müködésre képessé tenni, ez a legtöbb esetben egyszerő feladat, tehát igény esetén várható, hogy ezek a változatok gyorsan elkészülnek. Az áttérés teljes folyamata még nehezen tekinthetı át, hiszen akár több évtizedes munka is lehet. Az elsı fázis megvalósításához szükséges eszközök rendelkezésre állnak, és megkezdıdött a további lépésekre a felkészülés. A kutatói-akadémiai szféra szolgáltatói már több éve foglalkoznak kisérleti IPv6 szolgáltatásokkal, és az utóbbi évben több kereskedelmi szolgáltató is megkezdte IPv6 szolgáltatását, igaz, egyelıre fıleg tapasztalatszerzési és kísérleti célokból. A külföldi trendek figyelembevételével az e-közigazgatási fejlesztési projektek tervezése és fejlesztése során alkalmazni kell venni az IPv6-ot, és az elıremutató technológiai megoldások elérése érdekében célszerő elıírni hogy új fejlesztés csak IPv6 kompatibilis lehet.
83/92
Rövidítések jegyzéke AH Authentication Header AIIH Assignment of IPv4 addresses to IPv6 Hosts ALG Application Level gateway API Application Progamming Interface ARP Address Resolution Protocol BGP Border Gateway Protocol BIA Bump In the API BIS Bump In the Stack DHCP Dynamic Host Configuration Protocol DNS Domain Name System / Domain Name Service DSTM Dual Stack Transition Method ESP Encapsulating Security Payload FTP File Transfer Protocol HTTP HyperText Transfer Protocol ICMP Internet Control Message Protocol IESC Internet Engineering Steering Commitee IETF Internet Engineering Task Force IKE Internet Key Exchange IPng Internet Protocol Next Generation IPv4 Internet Protocol Version 4 IPv6 Internet Protocol Version 6 MIB Management Information Base MPLS Multi Protocol Label Switching MTU Maximum Transfer Unit NAT Network Address Translation NAT-PT Network Address Translator – Protocol Translator ND Neighbor Discovery NLA Next Level Aggregate PPP Point to Point Protocol QoS Quality of Service RFC Request For Comments SA Security Association SIIT Stateless IP/ICMP Translator SLA Site Level Aggregate SMTP Simple Mail Transfer Protocol SPI Security Parameter Index TCP Transmission Control Protocol TCP/IP Transmission Control Protocol / Internet Protocol TLA Top Level Aggregate TRT Transport Relay Translator UDP User Datagram Protocol VPN Virtual Private Network
84/92
Hivatkozások7 [6BONE]
http://www.6bone.net/
[6REN]
http://www.6ren.net/
[6WIND]
6wind, http://www.6wind.com/
[BULL]
Bull SA is supporting AIX 4.3.2 and now AIX 4.3.3, that contains an IPv6 host/router implementation based on DYADE(GIE INRIA-Bull). http://playground.sun.com/pub/ipng/html/ipng-implementations.html#BULL
[CISCO]
Cisco IPv6 oldal, http://www.cisco.com/ipv6/
[COMPAQ]
Network Administration Guide for Tru64 Unix V5.1 http://tru64unix.compaq.com/faqs/publications/base_doc/DOCUMENTATION/V51_HT ML/ARH9CBTE/TITLE.HTM
[DANTE]
Dante, http://www.dante.net
[DEBIAN]
Debian and IPv6 http://people.debian.org/~csmall/ipv6/
[DHCPV6]
J. Bound, C. Perkins, „Dynamic Host Configuration Protocol for IPv6”, draft-ietf-dhcdhcpv6-21.txt . http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-21.txt
[EAK]
Tru64 UNIX IPv6 Early Adopters Kit (EAK) Information, http://www4.ipv6.zk3x.dec.com/v50_kit_information.html
[EUI64]
GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER http://standards.ieee.org/regauth/oui/tutorials/EUI64.html , local
[FERSCH]
Niels Ferguson, Bruce Schneier: A http://www.counterpane.com/ipsec.html
[FREEBSD]
FreeBSD Homepage, http://www.freebsd.org/ , http://freebsd.ik.bme.hu/
[FREENET]
Freenet6, http://www.freenet6.net/
[FRTLC]
Nokia and France Telecom R&D To Cooperate On Global IPv6 Network Evolution, 2001. nov. 28. , http://biz.yahoo.com/bw/011128/282007_1.html
[GOGGLE6]
Hivatalos Google blog: http://googleblog.blogspot.com/2008/05/looking-towardsipv6.html
[HITACHI]
Hitachi Internetworking, http://www.internetworking.hitachi.com/
[HKNET]
http://www.hknet.com/eng/aboutus/pr/pr010831.html
[INRIA]
INRIA Rocquencourt is building a full (4.4BSD) UNIX implementation based on NetBSD 1.3.2 and FreeBSD 2.2.7 ftp://ftp.inria.fr/network/ipv6/
[IPV6SURVEY ]
Philip J. Nesser: Survey of IPv4 Addresses in Currently Deployed IETF Standards, 2001 augusztus. work in progress in draft-ietf-ngtrans-ipv4survey-01.txt, http://www.ietf.org/internet-drafts/ draft-ietf-ngtrans-ipv4survey-01.txt
[IRALLOC]
Regional IRs, „Provisional IPv6 assignment and allocation policy document (Draft 6; 27
7
Cryptographic
Evaluation
(EUI-64), of
IPSec,
A hiperhivatkozások a tanulmány készítésekori állapotot tükrözik. Fıleg a „draft” dokumentációk esetében verziószámuk változhat, eltőnhetnek, vagy elılléphetnek RFC-vé.
85/92
Május 1999)”, ipv6policy-draft-090699.txt . [ISCHC]
Internet Systems Consortium: ISC http://www.isc.org/index.pl?/ops/ds/host-count-history.php
[JUNIANN]
Juniper Networks Delivers Industry’s First Production-Ready IPv6 Solution, 2001. nov. 28. , http://biz.yahoo.com/bw/011128/282238_1.html
[JUNIPER]
Juniper Networks, http://www.juniper.net/
[JUNIPER]
Juniper Networks, http://www.juniper.net/
[KAME]
Kame Project http://www.kame.net/
[LINUX]
Linux IPv6 http://www.bieringer.de/linux/IPv6/
[LIPR]
Linux IPv6 RPM project http://ebs.jindai.net/
[MIGRATE]
Mark A, Miller, P.E.: Implementing IPv6. Migrating to the Next Generation Internet Protocols. (1998 M&T Books)
[MOBIL6]
David B. Johnson, Charles Perkins: Mobility Support in IPv6; 2000. április 27. ftp://ftp.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-12.txt
[MRTD]
MRT honlap, http://www.mrtd.net/
[MSRIP6]
Microsoft Research IPv6 http://research.microsoft.com/msripv6/
[MSTP6]
Microsoft IPv6 Technology Preview for http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp
[NETBSD]
NetBSD Homepage, http://www.netbsd.org/
[NEWBIE]
„newbie” DNS server implementation http://www.sfc.wide.ad.jp/~doi/softs/index.html
[NODEINFO]
Matt Crawford, „”IPv6 Node Information Queries”,” internet draft 2001 július, http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-08.txt
[NORTEL]
Nortel IPv6 oldal, http://www.nortelnetworks.com/corporate/technology/ipv6/index.html
[NTTV6]
http://www.nttamerica.com/news/2001/010426.html
[NWS98]
Mohácsi János, Szigeti Szabolcs, Máray Tamás, „IPv6 implementációk vizsgálata”, Cikk a Networkshop98 konferenciára, 1998, IPv6 Implementációk, Kibıvitett változat, amely már a Windows NT-t is vizsgálja és teljesebb vizsgálatot végez, IPv6 Implementációk tesztelése (WinNT szintén) Cikk az Infopen 1998 szeptemberi számában.
[OPENBSD]
OpenBSD Homepage, http://www.openbsd.org/ , http://openbsd.ik.bme.hu/
[RADVD]
RADVD Introduction http://www.mcs-cityline.net/~lf/radvd/INTRO.html
[RFC0791]
Postel, J., „Internet Protocol”, RFC 791, http://www.ietf.org/rfc/rfc791.txt
[RFC1034]
P. Mockapetris, „Domain names - concepts and facilities”, RFC 1034, November 1987.http://www.ietf.org/rfc/rfc1034.txt
[RFC1035]
P. Mockapetris, „Domain names - implementation and specification”, RFC 1035, November 1987. http://www.ietf.org/rfc/rfc1035.txt
[RFC1546]
C. Partridge, T. Mendez, and W. Milliken, „”Host Anycasting Service”” in RFC1546, November 1993. ftp://ftp.isi.edu/in-notes/rfc1546.txt
86/92
by
Domain
Survey,
Windows
Yusuke
2000
DOI,
,
[RFC1631]
Kjeld B. and P. Francis, „The IP Network Address Translator (NAT)”, RFC 1631, Május 1994. , http://www.ietf.org/rfc/rfc1631.txt
[RFC1639]
D. Piscitello., „FTP Operation Over Big Address Records (FOOBAR).”, RFC 1639, Június 1994., http://www.ietf.org/rfc/rfc1639.txt
[RFC1886]
S. Thomson and C. Huitema, „DNS Extensions to support IP version 6”, RFC 1886, December 1995. http://www.ietf.org/rfc/rfc1886.txt
[RFC1887]
Y. Rekhter, T. Li, An Architecture for IPv6 Unicast Address Allocation , RFC 1887, December 1995. http://www.ietf.org/rfc/rfc2921.txt
[RFC1888]
J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd, OSI NSAPs and IPv6 , RFC1888 , Augusztus 1996, http://www.ietf.org/rfc/rfc1888.txt
[RFC1918]
Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. de Groot and E. Lear, „Address Allocation for Private Internets”, RFC 1918, Február 1996., http://www.ietf.org/rfc/rfc1918.txt
[RFC1918]
Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., Lear, E., „Address Allocation for Private Internets”, RFC 1918, http://www.ietf.org/rfc/rfc1918.txt
[RFC1928]
M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and L. Jones, „SOCKS Protocol Version 5”, RFC 1928, Március 1996. http://www.ietf.org/rfc/rfc1928.txt
[RFC1933]
R. Gilligan and E. Nordmark, „Transition Mechanisms for IPv6 Hosts and Routers”, RFC 1933, Április 1996. leváltotta az RFC2893. http://www.ietf.org/rfc/rfc1933.txt
[RFC1981]
J. McCann, S. Deering & J. Mogul., „Path MTU Discovery for IP version 6.”, RFC 1981, Augusztus 1996., http://www.ietf.org/rfc/rfc1981.txt
[RFC2002]
Charles Perkins, (ed.): RFC2002: http://www.ietf.org/rfc/rfc2002.txt
[RFC2045]
Freed, N., Borenstein, N., „Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2045, November 1996., http://www.ietf.org/rfc/rfc2045.txt
[RFC2046]
Freed, N., Borenstein, N., „Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, RFC 2046, November 1996., http://www.ietf.org/rfc/rfc2046.txt
[RFC2080]
G. Malkin, R. Minnear, „RIPng http://www.ietf.org/rfc/rfc2080.txt
[RFC2081]
G. Malkin, „RIPng Protocol Applicability Statement”, RFC 2081, Január 1997. http://www.ietf.org/rfc/rfc2081.txt
[RFC2085]
M. Oehler, R. Glenn: RFC2085: HMAC-MD5 IP Authentication with Replay Prevention; 1997. február http://www.ietf.org/rfc/rfc2085.txt
[RFC2136]
Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound, „Dynamic Updates in the Domain Name System (DNS UPDATE)”, RFC 2136, Április 1997., http://www.ietf.org/rfc/rfc2136.txt
[RFC2137]
Eastlake, D., „Secure Domain Name System Dynamic Update”, RFC 2137, Április 1997., http://www.ietf.org/rfc/rfc2137.txt
[RFC2147]
D. Borman, „TCP and UDP over IPv6 Jumbograms”, RFC 2147, Május 1997, http://www.ietf.org/rfc/rfc2147.txt
[RFC2185]
R. Callon, D. Haskin, „Routing Aspects of IPv6 Transition”, RFC 2185, Szeptember
87/92
IP
for
Mobility
IPv6”,
Support;
RFC
2080,
1996.
Január
október
1997.
1997. http://www.ietf.org/rfc/rfc2185.txt [RFC2230]
R. Atkinson: RFC2230: Key Exchange Delegation Record for the DNS; 1997. november http://www.ietf.org/rfc/rfc2230.txt
[RFC2260]
T. Bates and Y. Rekhter, „Scalable Support for Multi-homed Multi-provider Connectivity” , RFC2260 , Január 1998. , ftp://ftp.isi.edu/in-notes/rfc2260.txt .
[RFC2267]
P. Ferguson and D. Senie, „Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing” , RFC2267 ,Január 1998,. ftp://ftp.isi.edu/in-notes/rfc2267.txt .
[RFC2283]
T. Bates, R. Chandra, D.Katz, Y. Rekhter, „Multiprotocol Extensions for BGP-4”, RFC 2283, Február 1998. http://www.ietf.org/rfc/rfc2283.txt
[RFC2292]
W. Stevens, M. Thomas, Advanced Sockets API for IPv6 RFC 2292, , Február 1998, http://www.ietf.org/rfc/rfc2292.txt
[RFC2292bis]
W. Richard Stevens, Matt Thomas, Erik Nordmark , „Advanced Sockets API for IPv6”, work in progress in draft-ietf-ipngwg-rfc2292bis-02.txt, updates RFC 2292, http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-03.txt
[RFC2362]
D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei., „Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification.”, RFC2362, Június 1998, http://www.ietf.org/rfc/rfc2362.txt
[RFC2373]
R. Hinden, S. Deering, „IP Version 6 Addressing Architecture”, RFC 2373, Július 1998.http://www.ietf.org/rfc/rfc2373.txt
[RFC2374]
R. Hinden, M. O’Dell, S. Deering, „An IPv6 Aggregatable Global Unicast Address Format”, RFC 2374, Július 1998. http://www.ietf.org/rfc/rfc2374.txt
[RFC2375]
R. Hinden, S. Deering, „IPv6 Multicast Address Assignments”, RFC 2375, Július 1998, http://www.ietf.org/rfc/rfc2375.txt
[RFC2386]
E. Crawley, R. Nair, B. Rajagopalan, H. Sandick: RFC2386: A Framework for QoSbased Routing in the Internet.1998. augusztus http://www.ietf.org/rfc/rfc2386.txt
[RFC2401]
S. Kent, R. Atkinson: RFC2401: Security Architecture for the Internet Protocol; 1998. november http://www.ietf.org/rfc/rfc2401.txt
[RFC2402]
S. Kent, R. Atkinson: RFC2402: IP Authentication Header; 1998. november http://www.ietf.org/rfc/rfc2402.txt
[RFC2405]
C. Madson, N. Doraswamy: RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV; 1998. november http://www.ietf.org/rfc/rfc2405.txt
[RFC2406]
S. Kent, R. Atkinson: RFC2406: IP Encapsulating Security Payload (ESP); 1998. november http://www.ietf.org/rfc/rfc2406.txt
[RFC2407]
D. Piper: RFC2407: The Internet IP Security Domain of Interpretation of ISAKMP; 1998. november http://www.ietf.org/rfc/rfc2407.txt
[RFC2408]
D. Maughan, M. Schertler, M. Schneider, J. Turner: RFC2408: Internet Security Association and Key Management Protocol (ISAKMP); 1998. november http://www.ietf.org/rfc/rfc2408.txt
[RFC2409]
D. Harkins, D. Carrel: RFC2409: The Internet Key Exchange (IKE); 1998. november http://www.ietf.org/rfc/rfc2409.txt
[RFC2411]
R. Thayer, N. Doraswamy, R. Glenn: RFC2411: IP Security Document Roadmap; 1998. november http://www.ietf.org/rfc/rfc2411.txt
88/92
[RFC2428]
M. Allman, S. Ostermann, C. Metz., „FTP Extensions for IPv6 and NATs.”, RFC 2428, Szeptember 1998., http://www.ietf.org/rfc/rfc2428.txt
[RFC2450]
R. Hinden, Proposed TLA and NLA Assignment Rules , RFC 2450 , December 1998. http://www.ietf.org/rfc/rfc2450.txt
[RFC2452]
M. Daniele, IPv6 Management Information Base for the Transmission Control Protocol , RFC2452 , December 1998, http://www.ietf.org/rfc/rfc2452.txt
[RFC2454]
M. Daniele, IPv6 Management Information Base for the User Datagram Protocol , RFC2454 , December 1998., http://www.ietf.org/rfc/rfc2454.txt
[RFC2460]
Deering, S., and R. Hinden, „Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, December 1998, http://www.ietf.org/rfc/rfc2460.txt
[RFC2461]
T. Narten, E. Nordmark W. Simpson: RFC2461: Neighbor Discovery for IP Version 6; 1998. december http://www.ietf.org/rfc/rfc2461.txt
[RFC2462]
Thomson, S., and T. Narten, „IPv6 Stateless Address Autoconfiguration”, RFC 2462, Dec 1998, http://www.ietf.org/rfc/rfc2462.txt
[RFC2463]
A. Conta, S. Deering., „Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.”, RFC 2463, December 1998, http://www.ietf.org/rfc/rfc2463.txt
[RFC2464]
M. Crawford., „Transmission of IPv6 Packets over Ethernet Networks.”, RFC 2464, December 1998., http://www.ietf.org/rfc/rfc2464.txt
[RFC2465]
D. Haskin, S. Onishi., „Management Information Base for IP Version 6: Textual Conventions and General Group.”, RFC 2465, December 1998., http://www.ietf.org/rfc/rfc2465.txt
[RFC2466]
D. Haskin, S. Onishi., „Management Information Base for IP Version 6: ICMPv6 Group.”, RFC 2466, December 1998., http://www.ietf.org/rfc/rfc2466.txt
[RFC2467]
M. Crawford., „Transmission of IPv6 Packets over FDDI Networks.”, RFC 2467, December 1998., http://www.ietf.org/rfc/rfc2467.txt
[RFC2470]
M. Crawford, T. Narten, S. Thomas, A Method for the Tranmission of IPv6 Packets over Token Ring Networks , RFC2470 , December 1998. http://www.ietf.org/rfc/rfc2470.txt
[RFC2471]
R. Hinden, R. Fink, J. Postel, IPv6 Testing Address Allocation , RFC2471 , December 1998.http://www.ietf.org/rfc/rfc2471.txt
[RFC2472]
D. Haskin, E. Allen., „IP Version 6 over PPP.”, RFC 2472, December 1998., http://www.ietf.org/rfc/rfc2472.txt
[RFC2473]
A. Conta, S. Deering, Generic Packet Tunneling in IPv6 Specification , RFC2473 , December 1998. http://www.ietf.org/rfc/rfc2473.txt
[RFC2474]
K. Nichols, S. Blake, F. Baker, D. Black: RFC2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers; 1998. december http://www.ietf.org/rfc/rfc2474.txt
[RFC2475]
S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss: RFC2475: An Architecture for Differentiated Services; 1998 december http://www.ietf.org/rfc/rfc2475.txt
[RFC2492]
G. Armitage, P. Schulter, M. Jork., „IPv6 over ATM Networks.”, RFC 2492, Január 1999., http://www.ietf.org/rfc/rfc2492.txt
89/92
[RFC2497]
I. Souvatzis., „Transmission of IPv6 Packets over ARCnet Networks.”, RFC 2497, Január 1999., http://www.ietf.org/rfc/rfc2497.txt
[RFC2504]
Guttman, E., Leong, L., Malkin, G., „Users’ Security Handbook”, RFC 2504, Február 1999., http://www.ietf.org/rfc/rfc2504.txt
[RFC2507]
M. Degermark, B. Nordgren, S. Pink, IP Header Compression , RFC2507 , Február 1999., http://www.ietf.org/rfc/rfc2507.txt
[RFC2522]
P. Karn, W. Simpson: RFC2522: Photuris: Session-Key Management Protocol; 1999. március http://www.ietf.org/rfc/rfc2522.txt
[RFC2526]
D. Johnson, S. Deering, Reserved IPv6 Subnet Anycast Addresses , RFC2526 , Március 1999., http://www.ietf.org/rfc/rfc2526.txt
[RFC2529]
B. Carpenter, C. Jung, „Transmission of IPv6 over IPv4 Domains without Explicit Tunnels”, RFC2529, Március 1999. http://www.ietf.org/rfc/rfc2529.txt
[RFC2529]
Carpenter, B., and Jung., C. „Transmission of IPv6 over IPv4 Domains without Explicit Tunnels (6over4)”, RFC 2529. ,Március 1999, ftp://ftp.isi.edu/in-notes/rfc2553.txt
[RFC2535]
D. Eastlake: RFC2535: Domain Name System Security Extensions; 1999. március http://www.ietf.org/rfc/rfc2535.txt
[RFC2538]
D. Eastlake, O. Gudmundsson: RFC 2538: Storing Certificates in the Domain Name System (DNS); 1999. március http://www.ietf.org/rfc/rfc2538.txt
[RFC2545]
P. Marques, F. Dupont, „Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing”, RFC2545, Március 1999. http://www.ietf.org/rfc/rfc2545.txt
[RFC2546]
A. Durand, B. Buclin, „6Bone Routing Practice”, RFC 2546, Március 1999. http://www.ietf.org/rfc/rfc2546.txt
[RFC2546]
A. Durand and B. Buclin, „6Bone Routing Practice” , RFC2546, Március 1999, ftp://ftp.isi.edu/in-notes/rfc2546.txt .
[RFC2553]
R. Gilligan, S. Thomson, J. Bound, W. Stevens, „Basic Socket Interface Extensions for IPv6”, RFC 2553, Március 1999, http://www.ietf.org/rfc/rfc2553.txt
[RFC2571]
Wijnen, B., Harrington, D., Presuhn, R., „An Architecture for Decribing SNMP Management Frameworks”, RFC 2571, Április 1999., http://www.ietf.org/rfc/rfc2571.txt
[RFC2574]
Blumenthal, U., Wijnen, B., „User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)”, RFC 2574, Április 1999., http://www.ietf.org/rfc/rfc2574.txt
[RFC2575]
Wijnen, B., Presuhn, R., McCloghrie, K., „View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)”, RFC 2575, Április 1999., http://www.ietf.org/rfc/rfc2575.txt
[RFC2577]
M. Allman and S. Ostermann, „FTP Security Considerations” in RFC2577, Május 1999. ftp://ftp.isi.edu/in-notes/rfc2577.txt
[RFC2673]
Matt Crawford, „Binary Labels in the Domain Name System”, RFC 2673, Augusztus 1999. http://www.ietf.org/rfc/rfc2673.txt
[RFC2675]
D. Borman, S. Deering, R. Hinden., „IPv6 Jumbograms.”, RFC 2675, Augusztus 1999.http://www.ietf.org/rfc/rfc2675.txt
[RFC2676]
G. Apostolopoulos, D. Williams, S. Kamat, R. Guerin, A. Orda, T. Przygienda: RFC2676: QoS Routing Mechanism and OSPF Extensions; 1999. augusztus
90/92
http://www.ietf.org/rfc/rfc2676.txt [RFC2710]
S. Deering, W. Fenner, B. Haberman., „Multicast Listener Discovery (MLD) for IPv6.”, RFC 2710, Október 1999. http://www.ietf.org/rfc/rfc2710.txt
[RFC2711]
C. Partridge, A. Jackson., „IPv6 Router Alert Option.”, RFC 2711, Október 1999. http://www.ietf.org/rfc/rfc2711.txt
[RFC2732]
R. Hinden, B. Carpenter, L. Masinter, Format for Literal IPv6 Addresses in URL’s , RFC 2732 , December 1999., http://www.ietf.org/rfc/rfc2732.txt
[RFC2740]
R. Coltun, D. Ferguson, J. Moy, „OSPF for IPv6”, RFC 2740, December 1999. http://www.ietf.org/rfc/rfc2740.txt
[RFC2765]
E. Nordmark, „Stateless IP/ICMP Translator (SIIT)”, RFC 2765, Februar 2000. http://www.ietf.org/rfc/rfc2765.txt
[RFC2766]
G. Tsirtsis, P. Srisuresh, „Network Address Translation - Protocol Translation (NATPT)”, RFC 2766, Február 2000. http://www.ietf.org/rfc/rfc2766.txt
[RFC2767]
K. Tsuchiya, H. Higuchi, Y. Atarashi, „Dual Stack Hosts using the Bump-in-the-Stack technique”, RFC 2767, Február 2000. http://www.ietf.org/rfc/rfc2767.txt
[RFC2772]
R. Rockell, R. Fink, „6Bone Backbone Routing Guidelines” RFC 2772, Február 2000. http://www.ietf.org/rfc/rfc2772.txt
[RFC2874]
M. Crawford, C. Huitema. „DNS Extensions to Support IPv6 Address Aggregation and Renumbering.” , Július 2000., RFC2874, http://www.ietf.org/rfc/rfc2874.txt
[RFC2893]
R. Gilligan and E. Nordmark, „Transition Mechanisms for IPv6 Hosts and Routers”, RFC 2893, Augusztus 2000. http://www.ietf.org/rfc/rfc2893.txt
[RFC2894]
M. Crawford, „Router Renumbering for IPv6”, RFC 2894, Augusztus 2000, http://www.ietf.org/rfc/rfc2894.txt
[RFC2921]
B. Fink, „6BONE pTLA and pNLA Formats (pTLA)”, RFC 2921, Szeptember 2000, http://www.ietf.org/rfc/rfc2921.txt
[RFC2928]
R. Hinden, S. Deering, R. Fink,T. Hain, „Initial IPv6 Sub-TLA ID Assignments”, RFC 2928, Szeptember 2000, http://www.ietf.org/rfc/rfc2928.txt
[RFC3056]
B. Carpenter, K Moore, „Connection of IPv6 Domains via IPv4” (6to4), 2001. február. http://www.ietf.org/rfc/rfc3056.txt
[RFC3315]
R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. „Dynamic Host Configuration Protocol for IPv6 (DHCPv6)..”, RFC 3315, Július 2003., http://www.ietf.org/rfc/rfc3315.txt
[RFC3513]
R. Hinden, S. Deering. „Internet Protocol Version 6 (IPv6) Addressing Architecture..”, RFC 3513, Április 2003., http://www.ietf.org/rfc/rfc3513.txt
[RFC4291]
R. Hinden, S. Deering. „IP Version 6 Addressing Architecture..”, RFC 4291, Február 2006., http://www.ietf.org/rfc/rfc4291.txt
[RFC4301]
S. Kent, K. Seo. „Security Architecture for the Internet Protocol.”, RFC 4301, December 2005., http://www.ietf.org/rfc/rfc4301.txt
[RFC4302]
S. Kent. „IP Authentication http://www.ietf.org/rfc/rfc4302.txt
[RFC4303]
S. Kent. „IP Encapsulating Security Payload (ESP).”, RFC 4303, Július 2003., http://www.ietf.org/rfc/rfc4303.txt
91/92
Header.”,
RFC
4302,
December
2005.,
[RH]
RedHat Distribution ftp://rawhide.redhat.com/
[RIPE]
RIPE-NCC, http://www.ripe.net/
[RPM]
IPv6 applications in RPM http://ftp.fi.muni.cz/pub/linux/ipv6-rpm/?N=A
[SCOPADDR]
S. Deering, B. Haberman, and B. Zill, „IP Version 6 Scoped Address Architecture,” , internet draft 2001 november, http://www.ietf.org/internet-drafts/draft-ietf-ipngwgscoping-arch-03.txt
[SOLARIS]
Solaris 8 - Internet Protocol Version 6 www.sun.com/software/solaris/ipv6/faqs.html
[SOLSCR]
Solaris 8 Ipv6 Socket Scrubber for C/C++ www.sun.com/software/solaris/ipv6
[STALLINGS]
William Stallings: IP Security, http://www.cisco.com/warp/public/759/ipj_3-1/ipj_31_ip.html
[STEALTH]
http://www.stealth.net/ipv6.html
[SUN]
Solaris Software White Papers: IPv6 www.sun.com/software/white-papers/wp-ipv6
[SUSE]
SuSe Distribution http://www.suse.com/
[TERENA98]
János Mohácsi, Szabolcs Szigeti, Tamás Máray, „Testing IPv6 implementations” TERENA networking conference, 1998, Drezda, Testing IPv6 implementations
[TIPSTER6]
IKTA-0009/2000, IPv6 szolgáltatások vizsgálata projekt. http://tipster6.ik.bme.hu/
[TOTD]
„totd” DNS proxy server from University of http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html
[TRU64DEP]
Compaq’s hint deploying IPv6 in Your Network, http://tru64unix.compaq.com/faqs/publications/best_practices/BP_IPV6/TITLE.HTM
[TRU64PRG]
Network Programmers’ Guide for Tru64 UNIX V5.1 http://tru64unix.compaq.com/faqs/publications/base_doc/DOCUMENTATION/V51_HT ML/ARH9UCTE/TITLE.HTM
[TUNNELBRO KER]
A. Durand, P. Fasano, I. Guardini, D. Lento, „IPv6 Tunnel Broker”, draft-ietf-ngtransbroker-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-broker-06.txt, local
[USAGI]
USAGI Project works to deliver the production quality IPv6 protocol stack for the Linux system. http://www.linux-ipv6.org/
[USENIXNT]
Implementing IPv6 for Windows NT, at the 2nd USENIX Windows NT Symposium in Seattle. http://www.research.microsoft.com/msripv6/usenixnt/intro.htm
[VBNS]
http://www.vbns.net/index.html
[WIDE]
The v6 working group, WIDE Project has been working on several independent IPv6/IPsec stacks including the KAME stack, some dedicated routers, etc. For more information please visit WIDE IPv6 stacks page.
[XIAOLI]
Xipeng Xiao, Lionel M. Ni.: Internet QoS: A Big Picture. IEEE Network March/April 1999. PP.:8-08., http://www.cse.msu.edu/~xiaoxipe/
92/92
and
the
Future
of
Tromso
the
Internet
(Norway).
,
