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 infrastruktú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 infrastruktúrá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 (kísé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ásá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űjtő 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ódszernek 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 kívá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 (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 (RFC1661)

• The PPP Internet Protocol Control Protocol (IPCP) (RFC1332)

• PPP Internet Protocol Control Protocol Extensions for Name Server Addresses (RFC1877)

• Remote Authentication Dial In User Service (RADIUS) (RFC2865)

• RADIUS Accounting (RFC2866)

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

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:

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 (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 infrastruktúrá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: Nemzeti Hírközlési Hatóság) kötelezte a természetes monopóliumot birtokló koncessziós szolgáltatókat hogy a DSL infrastruktúrá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 (T-COM, Invitel, Monortel, Hungarotel, Emitel), illetve vannak az Internet szolgáltatók (T-Online, Pantel, GTS-Datanet, Interware, Enternet, 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) (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.

Az L2TP protokoll alkalmazása együtt jár strukturált felhasználónevek alkalmazásával (pl. 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.

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.

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 kedvéért a legelterjedtebb nyílt forráskódú 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, illetve 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.

• 

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.

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álisan 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 hozzá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 RFC4241 írja le. Mielőtt ezt a modellt bemutatnánk, tekintsük át, hogy az IPv4 hozzáférési modellben megismert eszköztárból milyen módszer, protokoll alkalmazására van lehetőség és milyen mélységben.

Az IPv4 hozzáférési modell Ethernet transzportra, illetve PPPoE/PPP és Radius protokollok alkalmazására épült. Az Ethernet transzport továbbra is PPPoE/PPP csomagokat továbbít, így ebben változást nem jelent az IPv6 technológia. A PPP protokoll támogatja az IPv6 forgalom átvitelét, mivel a PPP fejléc "Protocol" mezőjéhez szabványosítottak olyan értéket, mely az IPv6 csomagokat jelöli. (0x0057). Ezek után az egyetlen terület, amit meg kell vizsgálnunk, hogy a PPP, illetve Radius protokoll, illetve a definiált paraméterek mennyiben támogatják az IPv6 paraméterek delegálását.

Az IPv4 hozzáférési modell bemutatásakor láttuk, hogy a hálózati paraméterek delegálását a megfelelő PPP opciók, illetve Radius attribútumok rendelkezésre állása és implementálása teszi lehetővé. IPv6 esetén ezeket a paramétereket az RFC2472 (IP Version 6 over PPP), illetve az RFC3162 (RADIUS and IPv6) ajánlás rögzíti. Átolvasva ezeket az ajánlásokat azt láthatjuk, hogy a rendelkezésre álló lehetőségek választéka még szűkebb, mint az IPv4 protokoll esetén, a következő ábra szerint:

Mint láthatjuk, gyakorlatilag egyetlen használható IPv6CP opció áll rendelkezésre, ez pedig az Interface-Token opció. Ennek alkalmazásával a PPP vonal két végén kommunikáló eszköz képes kicserélni egymással a Link Local címtartományban értelmezett Interface ID paraméterét, így a Link Local címek segítségével a két eszköz képes IPv6 alapú kommunikációra. Ezen túlmenően más paraméter nincs definiálva, az IPv6CP keretén belül nem delegálható sem nyilvános IPv6 prefix, sem a DNS kiszolgáló IPv6 címe. A PPP szabványkört az IETF PPP Working Group kezeli és fejleszti tovább. A Working Group keretén belül több próbálkozás volt új IPv6CP opciók definiálására, de eredmény nélkül. A PPP Working Group hivatalos álláspontja szerint hálózati jellemzők delegálása céljából a DHCPv6 protokoll már részletesen kidolgozásra került és nincs szükség másik, párhuzamos protokollra hasonló célból.

A határozott álláspontnak megfelelően az IPv6 hozzáférési modell a DHCPv6 alkalmazásával fejlődött tovább. Ennek a fejlődési iránynak a következményeként mind a felhasználói végberendezésekben / alkalmazásokban, mind az IPv6-képes BSR routerekben implementálni kellett a PPPoE protokoll-réteg mellett a megfelelő oldali DHCPv6 funkciókat. A BSR routerekben egy korlátozott funkcionalitású DHCPv6 kiszolgáló került implementálásra, mely helyi konfiguráció vagy központi, alapvetően Radius protokollon keresztül kapott paramétereket delegál DHCPv6 segítségével.

A DHCPv6 szabványkör releváns ajánlásai:

• RFC 3315 (Dynamic Host Configuration Protocol for IPv6)

• RFC 3633 (IPv6 Prefix Options for Dynamic Host Configuration Protocol version 6)

• RFC 3646 (DNS Configuration options for Dynamic Host Configuration Protocol for IPv6)

A végberendezésekben / alkalmazásokban a PPPoE kliens mellett DHCPv6 kliens is megjelent, mely nem a helyi Ethernet médián, hanem a PPP kapcsolat keretében felépült hálózati szegmensen keresi a DHCPv6 kiszolgálót.

A DHCPv6 protokoll keretében széleskörű paraméter-lista került szabványosításra, de a Radius protokoll IPv6 paraméter támogatása sajnos messze elmarad ettől, gyakorlatilag az IPv4 változathoz hasonlóan itt is a szükséges műszaki minimumon marad. A használható DHCPv6 opciókat és a Radius attribútumokat a következő ábra mutatja be.

A táblázatból láthatóan az IPv6 végberendezés számára kissé szélesebb körű a hálózati paraméterek delegálási lehetősége, az IPv4 hozzáférési modellnél megismerteken túl megadhatjuk a DNS domain neve(ke)t, illetve Cisco eszközök alkalmazása esetén a SIP kiszolgáló címeket és domain neve(ke)t.

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

A "Dual Stack" hozzáférési modellt az NTT japán szolgáltató szakemberei fogalmazták meg, és mint korábban említettük, RFC dokumentumként közzé is tették. A "Dual Stack" megközelítés az alábbi alap feltételekre épül:

• A felhasználó végberendezése (CPE) és a szolgáltató BRAS routere között egyetlen PPP kapcsolat épül fel
• A PPP kapcsolaton mind IPv4, mind IPv6 kommunikáció támogatott, külön-külön és párhuzamosan egyaránt
• Az IPv6 paraméter egyeztetés az IPv6CP fázis után a Link Local címek felhasználásával DHCPv6 keretében folytatódik
• A CPE először az RFC3633 ajánlásnak megfelelően DHCPv6 protokoll alkalmazásával delegált, nyilvános IPv6 prefixet kér a BSR routertől. Amennyiben a CPE router típusú eszköz, egy vagy több helyi Ethernet interfésszel a helyi LAN felé, akkor a gyakorlat szerint egy /48-as IPv6 prefixet kap, amit /64 IPv6 prefixek formájában tovább oszt a helyi Ethernet interfészei felé. A router CPE a WAN interfészén továbbra is Link Local címeket használ, default gateway-ként is a BSR Link Local IPv6 címe kerül regisztrálásra. Amennyiben a CPE egy PC-n futó PPPoE kliens, akkor rendszerint /64 nyilvános IPv6 prefixet kap.
• A CPE ugyanebben a DHCPv6 kérésben kérdezi a DNS kiszolgálók IPv6 címeit az RFC3646 szerint.

Amennyiben a PPP vonalon egyidőben mind az IPv4, mind az IPv6 szolgáltatás engedélyezett, akkor elsőként rendszerint az IPCP szerinti IPv4 paraméter egyeztetés történik meg, és azt követi az IPv6CP, illetve DHCPv6 szerinti IPv6 paraméter-egyeztetés, amint azt a következő ábra szemlélteti:

IPv6 hozzáférési tesztek

Laboratóriumi teszt hálózat

Az elméletben tárgyalt hozzáférési modellek vizsgálata és verifikálása érdekében Siemens a saját teszt laborjában egy minta hálózatot állított össze. A minta hálózat kialakítása lehetővé teszi mind egyszintű, mint kétszintű DSL szolgáltatás modellezését. A mintahálózat a magyarországi szolgáltatóknál üzemelő két vezető BSR gyártó, a Juniper Networks és a Cisco Systems eszközeivel épült fel. Az alábbi ábra a mintahálózat fizikai kialakítását és az alkalmazott VLAN-okat mutatja be.

Mint az ábrából látható, a hálózatban gyártóként két-két BSR eszköz szerepel, az egyik LAC szerepben, a másik LNS szerepben. A BSR routerek egymással és a Radius kiszolgálóval egy IPv4 hálózaton kommunikálnak (VLAN 3501), az egyszerűség kedvéért RIP routing protokoll felhasználásával.

Az egyes LAC routerekből mindkét LNS router felé egy-egy L2TP tunnel került felépítésre ezen az IPv4 szegmensen. A LAC routerek közvetlen PPPoE interfészei a VLAN 3502 (Juniper LAC), illetve VLAN 3504 (Cisco LAC) interfészek. Ezekről az Ethernet szegmensekről a kétszintű DSL hálózati modellnek megfelelő DSL hozzáférés létesíthető, mely a használt felhasználónév függvényében vagy a Juniper LNS routeren végződik ( xy@ipv6_jnpr ) vagy a Cisco LNS routeren ( xy@ipv6_csco )

Mindkét LNS router rendelkezik közvetlen PPPoE interfésszel az egyszintű DSL hálózati modell alapján történő vizsgálathoz (VLAN 3500 a Juniper LNS-en, VLAN 3503 a Cisco LNS-en).

A mintahálózat IPv4 architektúráját a következő ábra szemlélteti:

A mintahálózat IPv6 topológiája egyszerűbb képet mutat. A két LAC router csupán PPP csomagok továbbítását végzi, ezért IPv6 konfigurációval nem rendelkeznek, logikailag az IPv6 hálózatnak nem részei. Kizárólag a két LNS routerben van engedélyezve az IPv6 hálózati réteg. Az IPv6 routerek egymással OSPFv3 routing protokoll alkalmazásával kommunikálnak, amit azt az alábbi ábra is mutatja:

A teszthálózatban alkalmazott eszközök:

• Juniper BSR routerek
  • LAC: ERX-710 (JUNOSe 7-1-1)
  • LNS: ERX-310 (JUNOSe 7-1-1)
• Cisco BSR routerek
  • LAC: c3640 (IOS C3640-TELCO-M 12.3(11)T2)
  • LNS: c7200 (IOS C7200-IS-M 12.3(14)T7)
• Dual-stack Sun Solaris 9 kiszolgáló
  • IPv6-képes DNS kiszolgáló
  • Freeradius Radius kiszolgáló (v1.1.2)

Alább mellékeljük a mintahálózatban használt Juniper, illetve Cisco routerek konfigurációinak releváns részleteit.

Juniper_LAC_cfg.txt Juniper_LNS_cfg.txt Cisco_LAC_cfg.txt Cisco_LNS_cfg.txt

A Radius kiszolgáló adatbázisában a két gyártó BSR routereihez a gyártó-specifikus bővítéseket eltérő szintaktikával kell tárolni. Illusztrációképpen bemutatunk két előfizetői Radius konfigurációs bejegyzést, az elsőt a Windows XP PPPoE kliens, a második a router CPE rekordja. Mindkét bejegyzést két változatban kellett elkészíteni, attól függően, hogy Juniper vagy Cisco LNS routeren történik a kapcsolat végződtetése.

users_ipv6_cfg.txt

Megjegyezzük, hogy a Freeradius 1.1.2 verziója nem implementálja korrekten a szabványos "ipv6prefix" adattípust, ezért a Freeradius telepítése után a "/usr/local/share/freeradius/dictionary.rfc3162" fájlban a "Framed-IPv6-Prefix" attribútum típusát "ipv6prefix" típusról "octet" típusra kell átírni. Ennek megfelelően került megadásra a Radius előfizetői adatok között az IPv6 prefix.

Tesztelt végberendezések, kliens alkalmazások

Dual-stack kliensként két műszaki megoldást vizsgáltunk a tesztek során: dual-stack PPPoE kliens alkalmazás Windows XP környezetben (Siemens Tango Manager), illetve Layer 3 (router) funkciójú CPE, egy WAN Ethernet és egy LAN Ethernet interfésszel (Juniper Netscreen-5GT, illetve Cisco 871W).

A Siemens Tango Manager egy PPPoE kliens alkalmazás Windows XP operációs rendszerre. Párhuzamosan maximálisan 8 db PPPoE kapcsolat felépítését támogatja, ebből egy db lehet Dual-stack IPv4/IPv6 kapcsolat, a többi jelenleg csak IPv4 kapcsolat lehet. Az egyetlen Dual-stack kapcsolat kötelezően mind az IPv4, mind az IPv6 hálózati réteget felépíti. A Tango Manager, mint PC-n futó alkalmazás, a kapott nyilvános IPv6 prefixet a PPPoE logikai interfészhez rendeli hozzá.

A Tango Manager grafikus interfészen keresztül konfigurálható. A Dual-stack üzemmód engedélyezésére szolgáló párbeszéd-ablak a következő ábrán látható:

Bejelentkezés után a Tango képernyőjén a kapcsolat állapota és a fontosabb hálózati paraméterek áttekinthetőek:

Az IPv6 paraméterek egy külön ablakban részletesen megtekinthetők:

A Tango Manager bejelentkezési, illetve kijelentkezési státusz üzeneteit mutatja a következő két mező.

09/18/2006 12:23:08 -  Opening port...
09/18/2006 12:23:08 -  Port opened.
09/18/2006 12:23:08 -  Connecting
09/18/2006 12:23:08 -  Connected.
09/18/2006 12:23:08 -  All devices connected.
09/18/2006 12:23:08 -  Authenticating
09/18/2006 12:23:08 -  Authentication Notify
09/18/2006 12:23:08 -  Authentication projection.
09/18/2006 12:23:08 -  Authentication Notify
09/18/2006 12:23:08 -  Projected.
09/18/2006 12:23:08 -  Authentication Notify
09/18/2006 12:23:08 -  Successful Authentication.
09/18/2006 12:23:10 -  IPv6: PPPv6 negotiation successful
09/18/2006 12:23:12 -  IPv6: Acquiring DHCPv6 information, please wait...
09/18/2006 12:23:18 -  IPv6: Added DNS server address 2001:738:10:101:a00:20ff:fea0:1360
09/18/2006 12:23:20 -  IPv6: Added Global-scope address 2001:738:10:103:5449:52ff:fe41:4400
09/18/2006 12:23:22 -  IPv6: Added Anycast address 2001:738:10:103::
09/18/2006 12:23:24 -  IPv6: Added route to fe80::90:1a00:241:7103
09/18/2006 12:23:24 -  IPv6: Successfully acquired DHCPv6 information

09/18/2006 12:27:39 -  IPv6: Releasing DHCPv6 information, please wait...
09/18/2006 12:27:39 -  IPv6: Request Release of prefix from server
09/18/2006 12:27:44 -  IPv6: Removed Global-scope address 2001:738:10:103:5449:52ff:fe41:4400
09/18/2006 12:27:46 -  IPv6: Removed Anycast address 2001:738:10:103::
09/18/2006 12:27:48 -  IPv6: Removed route to fe80::90:1a00:241:7103
09/18/2006 12:27:50 -  IPv6: Removed DNS server address 2001:738:10:101:a00:20ff:fea0:1360
09/18/2006 12:27:50 -  IPv6: Successfully released DHCPv6 information
09/18/2006 12:27:50 -  Disconnected 

A Juniper Netscreen-5GT egy kisméretű router típusú CPE, beépített tűzfal funkciókkal, melynek a WAN Ethernet interfészén konfigurálható Dual-stack hozzáférés. A Netscreen-5GT támogatja natív IPv6 hálózati réteg felépítését (azaz nem kötelező IPv4 réteggel is rendelkezni). A Netscreen-5GT a kapott nyilvános IPv6 prefixet a helyi hálózati LAN interfészhez rendeli hozzá, a WAN Ethernet interfész Link Local címekkel kommunikál a BSR routerrel.

A Netscreen-5GT CPE konfigurációja mellékelve: Netscreen-5GT_cfg.txt

A Cisco 871W eszköz elterjedten alkalmazott, kisméretű, router típusú CPE, melynek uplink interfészén Dual-stack hozzáférés konfigurálható. Alapértelmezésben a kapott nyilvános IPv6 prefixet a Cisco 871 is a helyi hálózati LAN interfészhez rendeli hozzá, a WAN Ethernet interfész Link Local címekkel kommunikál a BSR routerrel.

A Cisco 871 CPE konfigurációja mellékelve: Cisco-871_cfg.txt

Speciális Cisco implementáció segítségével a Cisco 871 két nyilvános prefixet is kérhet, egyiket a WAN Ethernet interfész, a másikat a helyi hálózati LAN interfész számára. Ez az üzemmód akkor alkalmazható, ha a PPPoE kapcsolat végződtetését Cisco gyártmányú BSR végzi.

Két nyilvános IPv6 prefix delegálása az alábbi folyamat szerint történik:

1. A Cisco CPE mint PPPoE kliens felépíti a PPPoE kapcsolatot, pl. a kleno@ipv6_csco felhasználónév alkalmazásával.

2. A kapcsolat-felépítés hatására a Cisco BSR router a Radius hitelesítés keretében megkapja az adott felhasználónévhez rendelt nyilvános IPv6 prefixet, melyet ICMPv6 Router Advertisement keretében hirdet a CPE felé. A Cisco CPE az "ipv6 address autoconfig" konfigurációs parancs hatására a hirdetett IPv6 prefixet elfogadja és a WAN Ethernet interfészhez rendeli hozzá.

3. A Cisco CPE DHCPv6 protokollon keresztül újabb nyilvános IPv6 prefixet, DNS kiszolgáló címet és domain nevet kér. Ennek hatására a fogadó Cisco BSR újabb Radius hitelesítés kérést küld, az eredeti felhasználónévből automatikusan generált fiktív felhasználónév alkalmazásával (a példánkban a generált felhasználónév a kleno@ipv6_csco-dhcpv6 lesz). Ezen generált felhasználónévhez tartoznia kell a Radius adatbázisban egy érvényes bejegyzésnek, mely bejegyzés tartalmaz egy nyilvános IPv6 prefixet. Ezt a második IPv6 prefixet a Cisco BSR a DHCPv6 válaszban továbbítja a CPE felé, mely a helyi hálózati interfészhez rendeli hozzá.

Enek a megvalósításnak a segítségével nem csak a helyi hálózati LAN, hanem a WAN összeköttetés is nyilvános címekkel rendelkezik, amely felügyelt CPE esetén könnyebbé teheti a hálózatfelügyeletet és üzemeltetést.

Eredmények

Az IPv6 DSL hozzáférési tesztek a laborban egyértelműen pozitív eredménnyel zárultak: a dual-stack kliensek változatlan konfiguráció beállítások mellett minden esetben sikeresen tudtak csatlakozni a mintahálózat IPv6 szegmenséhez és sikeresen tudtak kommunikálni ezen szegmensen található IPv6-képes számítógépekkel. A sikeres hozzáférést nem befolyásolta, hogy a kliensek egyszintű hálózati modell mellett Cisco vagy Juniper BSR routerhez csatlakoztak, kétszintű hálózati modell mellett Juniper vagy Cisco LAC routeren keresztül Juniper vagy Cisco LNS routeren végződött a kapcsolat. Minden lehetséges variációt kipróbálva minden hozzáférés sikeresen felépült. Ezzel egyúttal igazoltuk a Cisco - Juniper együttműködési képességet az L2TP protokoll alkalmazásánál.

Igazoltuk azt is, hogy a LAC routereknek nem szükséges IPv6 képességekkel rendelkezniük, a mintahálózati Juniper és Cisco LAC routerekben az IPv6 hálózati réteg és routing protokoll nem volt konfigurálva. Ezen az igazolt tapasztalaton alapulva az IPv6 alapú hozzáférés intézményi IPv6 hálózatokhoz kétszintű hálózati modell esetén gyakorlatilag független a DSL szolgáltató infrastruktúrájától, ilyen IPv6 alapú távoli hozzáférés elvileg a DSL szolgáltató közreműködése nélkül is kialakítható.

Ez azonban csak az elmélet, mert a gyakorlati tesztek a T-COM DSL hozzáférési hálózatán mást igazoltak. A T-COM halózatában LAC-ként müködő Cisco 10000 sorozatú hozzáférés koncentrátorok megváltoztatják a csomagokat olyan módon, hogy nem lehetséges IPv6 csomagok átvitele jelenleg a Magyar Telekom DSL hozzáférési hálózatán.