TableOfContents

IPv6 alapú intézményi hálózatok távoli elérése DSL technológia és szolgáltatások felhasználásával

Bevezetés

Napjainkban a legelterjedtebb és egyre kedvezőbb árú nyilvános adatátviteli szolgáltatás a DSL technológiára épülő szélessávú Internet-hozzáférés. A távközlési szolgáltatók által kiépített DSL infrastuktúra azonban nem csak Internet-hozzáférésre, hanem intézményi magánhálózatok szélessávú elérésére is alkalmazhatók. A lehetőséget egyre több nagy intézmény ismeri fel és alakítja át ennek megfelelően saját hálózati infrastukturáját, együttműködésben a távközlési szolgáltatókkal.

A DSL hozzáférés alkalmazásának két változata alakult ki:

• a tömeges ADSL szolgáltatásnak megfelelő műszaki paraméterekkel rendelkező DSL csatlakozásokkal cserélik le a személyes távoli hozzáférés céljára eddig használt ISDN / analóg behívás (dialup) csatlakozásokat
• külön megállapodás alapján, szimmetrikus sávszélességi jellemzőkkel rendelkező DSL csatlakozással váltják ki az egyes távoli telephelyek, kisebb intézmények bekötéséhez használt bérelt vonali összeköttetéseket.

Az NIIF/HUNGARNET hálózat az egyik kiemelt intézményi felhasználója a DSL hozzáférési szolgáltatásoknak. Az NIIF gyakorlatilag az összes DSL szolgáltatóval (T-COM, Invitel, HTTC/Pantel) megállapodott és az igény szerinti paraméterekkel rendelkező DSL hozzáférési szolgáltatásokat jelentős számban alkalmazza IPv4 alapú távoli hálózat-elérésre.

Az NIIF/HUNGARNET hálózat napjainkra teljeskörú IPv6 szolgáltatásokat nyújt. Az egyes tagintézmények (kisérleti jelleggel) IPv6 helyi hálózatokat üzemeltetnek. Az IPv6 technológia terjedése logikusan veti fel azt a kérdést, hogyan lenne lehetséges az IPv4-es alapú DSL elérést IPv6 alapokon alkalmazni. Jelen dokumentum ezt a kérdést mutatja be, az alkalmazható technológiákkal, protokollokkal együtt, bemutatva a még nyitott kérdéseket is.

A könnyebb érthetőség kedvéért először röviden áttekintjük az IPv4-re jelenleg alkalmazott műszaki megoldást, majd ezt referenciaként használva bemutatjuk az IPv6 alapú hozzáférésnél található eltérő megoldásokat.

DSL hálózatok általános rendszertechnikai felépítése

A DSL technológián alapuló szélessávú Internet hozzáférés műszaki kialakítása több eszköz és technológia együttes alkalmazát igényli. Az előfizető lakásában egy DSL CPE berendezés kerül telepítésre, mely a telefon-szolgáltatásra használt rézkábel felhasználásával kapcsolódik a szolgáltató központi telephelyén elhelyezett DSLAM berendezéshez. A DSLAM eszközök egy Layer 2 szintű forgalomgyűjtő hálózaton keresztül kapcsolódnak az IP routerekhez, melyeket a speciális feladatkörük miatt külön eszköz-kategóriába sorolnak és röviden BRAS / BSR eszköznek hívnak.

A DSL CPE felhasználói oldalán Ethernet interfész a szolgáltatás-átadási pont. A DSL vonalon az Ethernet keretek ATM cellákba ágyazva kerülnek továbbításra. Az első generációs DSLAM berendezések ATM alapon működtek, ennek megfelelően a Layer 2 forgalomgyűltő hálózat is ATM technológiára épült. Napjainkban szinte kizárólag Ethernet DSLAM-ok kerülnek telepítésre, amelyekben az ATM technológia már a DSL vonali interfészen végződik, és a beágyazott Ethernet keret az Ethernet technológia szabályai szerint kerül továbbításra. Ez utóbbi esetben a forgalomgyújtő hálózat is Ethernet eszközökre épül. Mivel az Ethernet alapú DSL hálózatok váltak domináns szerepűvé, a továbbiakban ezt tekintjük referencia kialakításnak.

Adatátviteli szempontból a DSL hálózat transzparens Ethernet átvitelt biztosít a CPE felhasználói interfészétől a BSR router interfészéig. IP szolgáltatásra ez az Ethernet átvitel műszakilag alkalmas lehetne IP/Ethernet adatábrázolás mellett, a helyi hálózatokban alkalmazott módszernem megfelelően. Nyilvános szolgáltatói környezetben ez a kialakítás alapvető szolgáltatási, üzemeltetési követelményeknek nem felel meg:

• az előfizető nem azonosítható
• az előfizető nem hitelesíthető
• nincs egyértelmű, kialakult módszer az előfizető szolgáltatás-igénybevételének és forgalmának mérésére

Kézenfekvő módon a nyilvános Internet szolgáltatók minél inkább a bevált módszereket kivánták alkalmazni a DSL hálózatok esetén is, ezért került definiálásra és implementálásra a PPP over Ethernet protokoll ([http://www.ietf.org/rfc/rfc2516.txt RFC2516]). A PPPoE protokoll segítségével az Internet szolgáltatók a DSL környezetben gyakorlatilag minimális igazításokkal újra fel tudták használni azt a PPP / Radius alapú előfizető-kezelő keretrendszert, amelyet a behívásos (dialup) Internet-hozzáférés szolgáltatás számára már kiépítettek:

• előfizető azonosítása és hitelesítése PPP authentikációval, ahol az előfizetői adatok központi RADIUS adatbázisból kerülnek lekérdezése
• előfizető számára hálózati paraméterek delegálása (akár személyre szabottan) a RADIUS adatbázison keresztül
• előfizető számlázása a RADIUS accounting ajánlások szerint, rögzítve a belépés/kilépés időpontját és a forgalmazott adatmennyiséget

A legfontosabb releváns ajánlások:

• The Point-to-Point Protocol ([http://www.ietf.org/rfc/rfc1661.txt RFC1661])

• The PPP Internet Protocol Control Protocol (IPCP) ([http://www.ietf.org/rfc/rfc1332.txt RFC1332])

• PPP Internet Protocol Control Protocol Extensions for Name Server Addresses ([http://www.ietf.org/rfc/rfc1877.txt RFC1877])

• Remote Authentication Dial In User Service (RADIUS) ([http://www.ietf.org/rfc/rfc2865.txt RFC2865])

• RADIUS Accounting ([http://www.ietf.org/rfc/rfc2866.txt RFC2866])

A DSL hálózat rendszertechnikáját a következő ábra szemlélteti:

attachment:IPv6_DSL_1.jpg

Az ábrán jól látható, hogy PPPoE/PPP, illetve IP kommunikáció csak az előfizetői végberendezés és a BSR router között történik, a DSL és az aggregációs hálózat csupán egyszerű Ethernet transzport szerepet tölt be.

Amikor az előfizető megosztási céllal Internet routert üzemeltet a lakásában, akkor a rendszertechnikai kép kis mértékben módosul, az alábbi ábra szerint:

attachment:IPv6_DSL_2.jpg

Mint látható, ebben az esetben az Internet router lesz az "előfizető", a PPPoE kapcsolatot ő építi fel. Az Internet router helyi oldalán a tényleges végfelhasználói berendezések előre konfigurált IP címmel rendelkeznek, vagy DHCP protokoll segítségével kapják az Internet routertől. A helyi IP címek rendszerint privát IP címek ([http://www.ietf.org/rfc/rfc1918.txt RFC1918]), melyet az Internet router címfordítással rendel hozzá a kapott publikus IP címhez.

Ennek a változatnak nagy előnye, hogy olyan végberendezés is Internet-kapcsolattal rendelkezhet, mely PPPoE kliens szoftver komponenst nem tartalmaz.

A kezdeti időkben ugyanaz a szolgáltató üzemeltette a DSL infrastrukturát és biztosította az Internet szolgáltatást. A behívásos Internet szolgáltatás terén kialakult piaci verseny fenntartása érdekében a szabályzó hatóság (mai nevén: [http://www.nhh.hu Nemzeti Hírközlési Hatóság]) kötelezte a természetes monopóliumot birtokló koncessziós szolgáltatókat hogy a DSL infrastrukturájukat nyissák meg viszonteladók számára. Ez a jelenleg is fennálló helyzet: vannak DSL szolgáltatók, akik lényegében a helyi koncessziós társaságok ([http://www.t-com.hu T-COM], [http://www.invitel.hu Invitel], [http://www.monortel.hu Monortel], [http://www.hungarotel.hu Hungarotel], [http://www.emitel.hu Emitel]), illetve vannak az Internet szolgáltatók ([http://www.t-online.hu T-Online], [http://www.pantel.hu Pantel], [http://www.gtsdatanet.hu GTS-Datanet], [http://www.interware.hu Interware], [http://www.enternet.hu Enternet], [http://www.externet.hu Externet] stb). Az előfizetők az Internet szolgáltatóval szerződik, aki szolgáltatásként bérli a DSL szolgáltatótól a DSL csatlakozást.

A kétszintű Internet szolgáltatást műszaki szempontból a Layer Two Tunneling Protocol (L2TP) ([http://www.ietf.org/rfc/rfc2661.txt RFC2661]) teszi lehetővé, mely különböző Layer 2 protokollok IP hálózaton keresztüli átvitelét valósítja meg. Konkrétan a mi esetünkben az előfizető PPP csomagjait a DSL szolgáltató routere (LAC) egy közbenső IP hálózat felhasználásával L2TP tunnellekben továbbítja az Internet szolgáltató routere (LNS) felé.

A kétszintű DSL hálózat vázlatát a következő ábra mutatja be.

attachment:IPv6_DSL_3.jpg

Az L2TP protokoll alkalmazása együtt jár strukturált felhasználónevek alkalmazásával (pl. [mailto:Gipsz_J@niif.hu Gipsz_J@hungarnet.hu] ), ennek segítségével az adott DSL szolgáltató LAC routere a realm / domain név alapján (példánkban a @ határoló karakter utáni "hungarnet.hu" karaktersorozat) dinamikusan tudja az adott felhasználó forgalmát a megfelelő Internet szolgáltató (NIIF) felé irányítani.

A kétszintű hálózati architektúra jelentős üzleti, szolgáltatási és üzemeltetési előnyőket kínál mind a felhasználók, mind a szolgáltatók számára:

• A felhasználó szabadon választhat Internet szolgáltatót, nincs korlátozva a területileg illetékes DSL szolgáltatóhoz
• A DSL szolgáltató DSL lefedettsége a partner Internet szolgáltatók ügyfélkörének bővülésével automatikusan növekszik
• A DSL szolgáltató nem kezel /adminisztrál érzékeny üzleti információkat (felhasználó-nevek, jelszavak), minden bizalmas információ az előfizetővel közvetlen szerződésben álló Internet szolgáltató kezelésében marad. Egyetlen paraméterben kell megegyezniük az együttműködő szolgáltatóknak: az adott Internet szolgáltatóhoz tartozó realm / domain névben.
• Az Internet szolgáltató nincs földrajzi elhelyezkedéshez kötve, szolgáltatási területe a partner DSL szolgáltatók lefedettségének felel meg
• Az előfizető bejelentkezéskor az Internet szolgáltató által megszabott hálózati jellemzőket (IP cím, DNS szerver cím) kapja meg, mely paraméterek műszakilag teljesen függetlenek a DSL szolgáltató hálózatának jellemzőitől.

Az NIIF / HUNGARNET hálózat jelenlegi DSL kapcsolatai is a bemutatott kétszintű architektúrának megfelelően üzemelnek, ahol az NIIF egy "Internet szolgáltató" szerepkörében egy központi LNS routert üzemeltet, mely fogadja / végződteti az együttműködő DSL szolgáltatóktól érkező felhasználói forgalmat.

A hozzáférési modell építőelemei

A hozzáférési modell fogalmán azt a szolgáltatói környezetben kialakított rendszertechnikai megoldást értjük, mely teljes körűen leírja azokat folyamatokat és funkciókat, melyek egy nyilvános hálózati hozzáférés szolgáltatás igénybevételéhez szükségesek. A hozzáférési modell nyilvános szolgáltatói környezetben értelmezett és ennek megfelelően nem csak az adat-továbbítás műszaki megvalósítását jelenti, hanem kiegészül azon rész-funkciókkal, amelyek a fizetős, tömeges szolgáltatás üzemeltetéséhez szükségesek:

• Bejelentkezés, előfizető azonosítás és hitelesítés
• Hálózati paraméterek központi készletből történő dinamikus delegálása, illletve hálózati erőforrások paramétereinek átadása
• Kijelentkezés, a használt hálózati paraméterek felszabadítása
• Szolgáltatás igénybevételének naplózása, számlázáshoz szükséges műszaki statisztikák gyűjtése

Jelen dokumentumban elsősorban a hálózati paraméterek delegálásának kérdéskörét járjuk körbe.

A szélessávú szolgáltatások hozzáférési modellje a behívásos Internet szolgáltatás üzemeltetése során kialakult megoldást ülteti át DSL/Ethernet környezetre, ennek megfelelően a hozzáférési modell két legfontosabb építőeleme a PPP protokoll és a Radius protokoll.

A PPP protokoll

A PPP protokoll pont-pont összeköttetésen (pl. soros vonal, telefon kapcsolat) történő kommunikáció céljából fejlesztették ki. A DSL hálózatban ezt a pont-pont összeköttetés az előfizetői végberendezés (pl, PC) és a szolgáltató BSR routere közötti PPPoE csatorna. Az első generációs DSL hálózatban az Ethernet technológia csak mint adatábrázolási formátum volt jelen, az adatok továbbítása egy pont-pont jellegű ATM PVC-n keresztül történt az előfizető DSL modemjétől a szolgáltató BSR routeréig. A jelenleg domináns Ethernet alapú DSL hálózatokban az Ethernet nem csak adat-formátum, hanem transzport technológia is, mely alapvetően multipont-multipont jellegű, mégis a PPPoE protokoll segítségével pont-pont összeköttetések jönnek létre és továbbítják az előfizető forgalmát.

Amint a korábbi ábrán is láthattuk, a felhasználó forgalma PPP protokollba ágyazva kerül továbbításra a szolgáltató BSR routeréig. A PPP protokollnak nagy előnye, hogy kezdettől fogva multiprotokoll jellegű továbbításra tervezték, azaz ugyanazon a pont-pont linken párhuzamosan több Layer 3 protokoll (IP, IPX, Appletalk stb) forgalmát képes továbbítani.

A PPP protokoll multiprotokoll jelleget két jellemző teszi lehetővé:

• A PPP keret fejlécében egy adott mező ("Protocol") azonosítja a beágyazott Layer 3 protokoll típusát, így az egyes Layer 3 adatfolyamok elválaszthatóak
• A PPP bejelentkezési folyamatban minden egyes Layer 3 protokollhoz tartozik egy Network Control Protocol fázis, ahol a felek meg tudnak egyezni az adott Layer 3 protokollhoz tartozó hálózati paraméterekben

A következő ábra a PPP bejelentkezési folyamatát mutatja be.

attachment:IPv6_DSL_4.jpg

A PPP multiprotokoll jellegét a később bemutatott un. "Dual Stack" hozzáférési modell használja ki, mely ugyanazon a linken párhuzamosan IPv4 ésIPv6 kommunikációt valósít meg.

A Radius protokoll

A nyilvános hálózati hozzáférés szolgáltatás infrastruktúrájában a szolgáltató BSR routere végzi az előfizető csatlakoztatását. Annak érdekében, hogy az előfizető bejelentkezéséről a BSR műszaki döntést hozhasson, rendelkeznie kell egy sor előfizetői adatta. (előfizetői név, jelszó, jogosultságok). Ezeket a paramétereket természetesen lehet az adott BSR routerben helyi konfigurációban tárolni, de az előfizetők (és a BSR routerek) számának növekedésével a helyi felhasználói adatbázisok folyamatos és szinkronizált karbantartása egyre nagyobb üzemeltetői terhelést jelentene. Ennek a problémának a megoldására került kifejlesztésre a "Remote Authentication Dial In User Service" (Radius) protokoll.

A Radius szabvány koncepciójában a BSR routerek nem tartalmaznak semmilyen előfizetői adatbázist, csak egy központi kiszolgáló címét, melyet az előfizető bejelentkezésekor igénybe tudnak venni azonosításra és hitelesítésre. A kapott döntés alapján a BSR csak műszaki végrehajtó szerepet tölt be.

A Radius koncepció hálózati modelljét a következő ábra szemlélteti.

attachment:IPv6_DSL_5.jpg

A Radius szabványkör önmagában egy kommunikációs protokollt és az ehhez tartozó paraméterek ábrázolását írja le. A gyakorlati Radius kiszolgáló implementációk természetesen ennél jóval gazdagabb szolgáltatás-készlettel rendelkeznek. A legfontosabb ilyen szolgáltatás az előfizetői adatok és számlázási információk tárolása. Minden vezető Radius kiszolgáló implementáció támogatja ezen adatok szöveges állományban történő tárolását (mint legegyszerűbb megoldást), de ez az "adatbázis" az előfizető-szám növekedésével egyre lassúbb adat-hozzáférést biztosít. Szolgáltatói minőségű Radius kiszolgáló alkalmazások rendelkeznek megfelelő illesztéssel a professzionális adatbázis-kezelő rendszerek felé. (Csak a példa kevéért a legelterjedtebb nyílt forráskódú [http://www.freeradius.org FreeRadius] alkalmazás az alábbi adatbázis-kezelő rendszereket támogatja: LDAP, MySQL, MSSQL, PostgreSQL, Oracle.)

A gyakorlati alkalmazásban a szolgáltatók jelentős része külön kezeli a ritkán változó, elsősorban olvasásra használt előfizetői adatbázist (LDAP) illetve a gyakran változó, írást és olvasást egyaránt igénylő számlázási adatbázist (SQL). A külső adatbázis illesztés támogatja ezen adatbázis-kezelő alkalmazások külön gépen történő üzemeltetését is, mely jelentősen növeli a Radius kiszolgáló skálázhatóságát.

IPv4 DSL hozzáférési modell

IPv4 alapú DSL hozzáférés esetén elsőként PPPoE kapcsolat épül föl az előfizető és a DSL szolgáltató BSR routere között . Az üzemelő PPPoE kapcsolat felett PPP kommunikáció kezdődik, ahol egyszintű hálózat esetén a DSL szolgáltató BSR routere az előfizető partnere, míg kétszintű DSL hálózat esetén pedig az Internet szolgáltató BSR routere (LNS). (A PPP folyamat szempontjából a két eset nem különbözik egymástól.)

A felhasználó bejelentkezési folyamata két párhuzamos kommunikáció összjátékának eredményeképpen fejeződhet be sikeresen. A két kommunikáció az előfizető - BSR router közötti PPP, illletve a BSR router és a központi előfizetői adatbázis között Radius protokoll segítségével történik. Az egyes tipikus üzenetváltások sorrendjét, illetve egymásra épülését a következő ábra szemlélteti.

• attachment:IPv6_DSL_7.jpg

A PPP előfizető-azonosítási fázisában a BSR router a felhasználó azonosítására és hitelesítésére a központi Radius kiszolgálóhoz fordul. A felhasználói adatok (pl. név, kapott jelszó) mellett a BSR router további bejelentkezési paramétereket küld a központi Radius kiszolgálónak (pl. fogadó BSR router, melyik interfészen érkezett a bejelentkezés). A szolgáltató ezen bejelentkezési adatok felhasználásával kifinomult szabályrendszert alkothat a felhasználó bejelentkezésének elfogadására vagy visszautasítására (pl. korlátozhatja az előfizető mobilitását, feltételként véve a bejelentkezési BSR routert és annak interfészét).

A Radius kiszolgáló a kapott bejelentkezési paraméterek és az ő központi adatbázisa alapján dönt a bejelentkezés elfogadásáról. Negatív válasz esetén a Radius kiszolgáló rendszerint mellékeli a visszautasítás okára utaló paramétert (pl. ismeretlen előfizető, hibás jelszó). A bejelentkezés elfogadása esetén az engedélyező válasz is rendelkezik "mellékletekkel": a Radius kiszolgáló átadja a BSR routernek azokat az IPv4 paramétereket, mely a központi adatbázisa alapján az adott előfizetőhöz tartoznak (pl. IP cím, DNS kiszolgáló címe). Ezeket az adatokat a BSR router átmenetileg tárolja, míg a PPP előfizetői azonosítás fázis sikeresen lezárul és megkezdődik az IPv4 hálózati réteg protokoll egyeztetés (IPCP). A sikeres IPCP egyeztetés után az előfizető bejelentkezése megtörtént, mely eseményről a BSR router Radius számlázási rekord küldésével értesíti a központi Radius kiszolgálót (természetesen amennyiben a Radius számlázás be van kapcsolva).

Miután az előfizetői bejelentkezés és paraméter-egyeztetés folyamatát megismertük, az egyetlen nyitva maradt kérdés, hogy e folyamat során milyen paramétereket lehet központi adatbázisból az előfizető számára delegálni. A megismert hozzáférési modell alapján egy adott jellemzőt két helyen kell definiálni: a Radius paraméterek között, illetve a PPP paraméterek között. A két protokoll paramétereinek egymáshoz rendelését a BSR router végzi el.

Sajnos a jelenleg érvényes nyilvános szabványok és ajánlások alapján nagyon kevés azon jellemzők száma, melyet központilag lehetne delegálni az előfizető számára. A szabványok szerint IPv4 paraméterek listáját a következő táblázat foglalja össze.

attachment:IPv6_DSL_6.jpg

A táblázat alapján látható, hogy gyakorlatilag az IP cím és a DNS kiszolgáló(k) címe(i) azok a paraméterek, melyet a PPP kliens megkaphat. Ez az Internet szolgáltatáshoz a szükséges minimum. Microsoft Windows alapú intézményi hálózatok távoli eléréséhez opcionálisam a PPP kliens megkaphatja az NBNS (Wins) kiszolgáló(k) címét is.

IPv6 DSL hozzáférési modell

Az IPv6 alapú nyilvános szélessávú szolgáltatások elsődleges terepe a távol-keleti országok, elsősorban Japán. A nyilvános IPv4 címtartomány szűkössége az IPv6 technológia alkalmazására és elterjesztésére késztette mind az állami hatóságokat, mind a szolgáltatókat és mind a gyártókat. Nem véletlen, hogy az IPv6 DSL hosszáférési modell első nyilvános ajánlása is japán szakemberek eredménye: a japán NTT szolgáltató által kiválasztott és implementált un. "Dual Stack" hozzáférési modellt az [http://www.ietf.org/rfc/rfc4241.txt RFC4241] írja le.

"Dual Stack" hozzáférési modell

attachment:IPv6_DSL_11_12.jpg

attachment:IPv6_DSL_9.jpg

attachment:IPv6_DSL_10.jpg

IPv6 hozzáférési tesztek, eredmények

Laboratóriumi teszt hálózat

attachment:IPv6_DSL_13.jpg

attachment:IPv6_DSL_14.jpg

attachment:IPv6_DSL_15.jpg

Tesztelt végberendezések, kliens alkalmazások

Összegzés