1    Úvod

2    Teoretické výhody

3    Meranie rýchlosti odozvy

4    Záver

5    Použitá literatura a WWW odkazy

---

Úvod
E-learning možno v súčasnosti charakterizovať ako modernú, najrýchlejšie sa rozvíjajúcu formu vzdelávania. Jeho rozmach je dôsledkom splnenia základnej požiadavky na dostupnosť Internetu pre širokú verejnosť, zvýšením výkonu a znížením cien hardvéru i sprístupnením potrebného softvéru.
V súčasnosti je oblasť e-vzdelávania jednou z hlavných tém, ktorými zaoberá alebo v strednodobom horizonte plánuje zaoberať prevažná väčšina univerzít, pretože počet záujemcov o vysokoškolské štúdium neustále narastá a často predstavuje pre univerzity neúmernú priestorovú, a pre vyučujúcich neúmernú časovú záťaž.
Ako všetky inštitúcie venujúce sa oblasti vzdelávania, aj Univerzita Konštantína Filozofa v Nitre (UKF) sa v tejto oblasti snaží o nájdenie vhodného pomeru medzi prezenčnou a dištančno-elektronickou formou. Na základe niekoľkoročných skúseností sa ukazuje, že hlavným problémom nie je výber vhodného prostredia LMS, ale skôr nedostatočná príprava vyučujúcich na manažovanie výučby pomocou e-kurzov v kombinovanej a dištančnej forme a nedostatočná motivácia pre ich vytváranie a po vytvorení ďalšie prevádzkovanie (aktualizovanie, využívanie pri manažovaní štúdia a pod.).
Na fakultách UKF existuje viacero inštalácií viacerých LMS, no pre samotnú podporu výučby predmetov zahrnutých v študijných programoch sa postupne presadilo prostredie LMS Moodle, ktoré ako open-source umožňuje flexibilne reagovať na požiadavky vyučujúcich, správcov i programátorov.
Využívanie e-learningových kurzov vo výučbe je bohužiaľ takmer výlučne doménou Fakulty prírodných vied UKF. Okrem špičkových kurzov, ktoré získali niekoľko ocenení na rôznych súťažiach, sa vo často možnosti LMS využívajú v prvom rade na sprístupňovanie učebných materiálov študentom. Obsah kurzov veľmi často tvoria statické dokumenty sprostredkúvajúce obsah predmetu edukantom, niekedy v kombinácii s prostriedkami on- i off-linovej komunikácie. Použitie ostatných aktivít a systematické využívanie LMS na manažovanie štúdia, sú stále nedostatočné.

Centrálny portál
Vzhľadom na neefektívnosť správy viacerých portálov, centralizáciu informačných systémov a centralizáciu správy používateľov prebehlo na začiatku školského roka 2007/2008 zlúčenie existujúcich LMS systémov do celouniverzitného portálu, pre ktorý bola vytvorená doména http://edu.ukf.sk.

Obr. 1 E-learningový portál UKF (http://edu.ukf.sk)

Portál, ako taký, je aktuálne (začiatok novembra 2007) postavený na verzii Moodle 1.8.3+. Pracuje na hardvérovej platforme SUN, konkrétne na štvorprocesorovom SUN Fire T2000 (Niagara) založenom na technológii CoolThreads, ktorý vďaka 8 jadrám na procesore dosahuje extrémne vysoký výkon a konektivitu v internetových prostrediach.
Portál komunikuje s univerzitným LDAP, ktorý je napojený na Akademický informačný systém (zdroj študentov) a SAP/SOFIA (zdroj zamestnancov).


Obr. 2. Prepojenie portálu na ďalšie systémy

Vďaka prepojeniu s týmito systémami nie je potrebné registrovať používateľov portálu manuálne, pretože LDAP okrem overovania totožnosti slúži i ako centrálne úložisko a zdroj údajov pre ostatné systémy – obsahuje kompletné údaje o zamestnancoch i študentoch ako aj o ich rolách a právach v informačných systémoch, ktoré LDAP využívajú.
Údaje sú pritom reálne, aktuálne a napokon v prípade ukončenia štúdia/zamestnania je dané konto automaticky zablokované a zrušené.

Správa a štruktúra portálu
Účelom portálu je poskytovať edukačné materiály pre potreby vysokoškolského vzdelávania na UKF a z tohto dôvodu je nutné pokryť nasledovné oblasti:
• správu hardvéru a operačného systému zabezpečuje centrum IKT,
• správu a administráciu LMS zabezpečujú tvorcovia kurzov so skúsenosťami ako s tvorbou samotných kurzov, tak i s administráciou predchádzajúcich implementácií LMS Moodle na UKF (autori príspevku). Výhodou takéhoto riešenia je úzky kontakt administrátorov s tvorbou kurzov a tým i vyvinutá intuícia pri odhadovaní potrieb používateľov – menej skúsených tvorcov e-learningových kurzov. Zároveň toto riešenie disponuje i perspektívou rozvoja portálu – aktívni tvorcovia majú omnoho vyšší záujem napredovať a skúšať nové funkcionality ako pasívni správcovia napr. z radov Centra IKT,


Obr. 3 Organizačná štruktúra a sféry vplyvu na úrovni portálu

• podporu používateľov možno chápať z viacerých pohľadov:
o základná podpora spočívajúca vo vytvorení kurzu ako jednotky LMS systému, jeho zaradenia a pridelenie roly tvorcu kurzu/učiteľa používateľovi. Túto činnosť zabezpečujú na úrovni fakúlt poverení zamestnanci na základe žiadosti používateľa.
o podpora na formálnej úrovni je zabezpečená prostredníctvom vytvárania a nastavovania šablón, ktoré okrem dizajnu poskytujú tvorcovi kurzu i návrh základného štruktúrovania kurzu (preddefinovaný priestor pre sylaby kurzu, diskusné fóra, záverečné hodnotenie a pod.)
o podpora na úrovni komunity spočíva v riešení problémov a v diskusiách o zvolených témach. Diskusie sú moderované administrátormi portálu a ich cieľom je pomôcť používateľom, zistiť ich potreby a vhodne usmerniť ich činnosť – táto aktivita je v súčasnosti v štádiu prípravy (technická realizácia je pripravená),
o podpora na úrovni vzdelávania tvorcov je realizovaná prostredníctvom elektronických materiálov (publikácie, články) a prostredníctvom školení, ktoré doposiaľ boli realizované na úrovni niektorých fakúlt,
o poslednou, no z pohľadu tvorcov určite nie nepodstatnou zložkou je podpora finančná. Táto spočíva vo finančnom ohodnotení tvorcov a detailnejšie sa jej venujeme nižšie,
• správu/evaluáciu obsahu zabezpečuje po formálnej stránke Rada pre e-learning, ktorá je v zložení zástupcov všetkých fakúlt schopná objektívne posúdiť formálnu stránku vytvorených kurzov (napr. rozsah, delenie obsahu na prednášky a cvičenia, dostatočný počet autotestov a pod.). Vzhľadom na to, že obsahovú stránku mnohých kurzov nedokáže posúdiť laik v danej oblasti, je na autorovi, aby svoj kurz nechal validovať vhodným recenzentom.

Motivácia tvorcov kurzov
Ak zabezpečenie dodržania dostatočnej úrovne portálu spočíva v rozdelení elektronických kurzov na skupiny recenzovaných (obsahová i formálna stránka bola posúdená kompetentnými orgánmi ako vyhovujúca) a nerecenzovaných kurzov (predstavujú rozpracované, čiastočne ukončené alebo ukončené a nerecenzované kurzy), možno toto delenie využiť i pri finančnom hodnotení a motivácii tvorcov.
Niektoré univerzity nastúpili v tomto smere na cestu jednorazového príspevku pri vytvorení, resp. odovzdaní či obhájení kurzu, prípadne na symbolické mesačné osobné prilepšenie.
Vzhľadom na niekoľkoročné skúsenosti však do finančného ohodnotenia odporúčame premietnuť aj ďalšie parametre:
• recenzovaný/nerecenzovaný kurz predstavuje významný fakt reprezentujúci komplexnosť kurzu – komplexný kurz musí byť hodnotený vyššie ako kurz neúplný, resp. kurz s nevhodným či neúplným obsahom,
• rozsah textovej časti kurzu (s prihliadnutím na multimediálny a ďalší obsah) – nie každý kurz má rovnaký rozsah – je žiaduce vyššie ohodnotiť kurzy s väčším rozsahom textu, prípadne s využitím multimediálnych údajov,
• počet aktívnych učiteľov kurzu – v prípade viacerých používateľov kurzu je obsah tvorený každým z nich (diskusné fóra, zadávanie úloh, príp. i tvorba obsahu) a náročnosť na jedného tvorcu sa znižuje,
• aktivita učiteľov musí pri hodnotení predstavovať významný aspekt, pretože vytvorením kurzu sa práca na ňom zďaleka nekončí. Tvorca kurzu, ktorý ho nepoužíva, nemá byť prečo odmeňovaný – za svoju aktivitu počas tvorby kurzu bol odmenený v období, keď kurz vytváral. Naopak, učiteľ, ktorý denne zadáva, kontroluje a koordinuje aktivity edukantov musí za túto svoju činnosť veľmi často „nadčas“ dostať primerané ohodnotenie,
• počet prihlásených študentov a aktivita študentov úzko súvisia s aktivitou učiteľov a odzrkadľujú nielen aktivizujúce prvky v kurze, ale aj jeho zaujímavosť a pestrosť,
• inovatívnosť kurzu spočíva v použití nových, netradičných a neštandardných metód zvyšujúcich kvalitu vyučovacieho procesu – a tieto určite nesmú zostať nepovšimnuté...

Záver
Portál nastúpil v školskom roku 2007/08 na začiatok svojej cesty. Veríme, že sa v nasledujúcich rokoch stane dostatočne silným odrazovým mostíkom pre tvorbu nových a obľúbeným miestom pre využívanie existujúcich elektronických kurzov.

Zdroj:
Drlík, Martin - Kapusta, Jozef - Skalka, Ján - Švec, Peter: Implementácia LMS na úrovni univerzity . In: UNINFOS 2007 - Univerzitné informačné systémy : zborník príspevkov z medzinárodnej konferencie. - Bratislava: Ekonóm, 2007. - ISBN 978-80-225-2418-6. - S. 55-59.

1 Možnosti mobility v IPv6 - teória
1.1 Mobilita hostiteľa
Podpora mobility hostiteľa umožňuje IPv6 uzlom presun z jednej IPv6 siete to inej IPv6 siete bez prerušenia prebiehajúcich spojení. Mobilita hostiteľa je zabezpečená protokolom Mobile IPv6 (MIPv6), ktorý je štandardným IETF protokolom vytvoreným pre podporu mobility hostiteľa v IPv6. Aplikáciou MIPv6 sa zaoberajú dva projekty. Prvým je KAME projekt, ktorý sa orientuje na vývoj IPv6/IPSec referenčnej sady pre BSD systémy. Druhým je USAGI projekt, ktorý sa zameriava na vylepšenie IPv6/IPSec sady pre Linux.

1.2 Mobilita siete
Mobilita siete sa objavuje keď celá sieť zmení bod pripojenia s ohľadom na topológiu Internetu. Takéto siete budeme môcť čoskoro nájsť v dopravných prostriedkoch (autá, vlaky) a na ľuďoch ako PAN siete tvorené PDA zariadeniami a mobilnými telefónmi. Mobilná sieť je pripojená k Internetu prostredníctvom jedného alebo viacerých mobilných smerovačov. Uzly, ktoré sú za mobilným smerovačom rozdeľujeme do troch kategórií:

• lokálne fixné uzly (patria do siete, ale nemajú možnosť zmeniť svoj bod pripojenia),
  
• lokálne mobilné uzly (patria do siete a majú možnosť zmeniť svoj bod pripojenia) a
  
• hosťujúce mobilné uzly (nepatria do mobilnej siete a sú schopné zmeniť svoj bod pripojenia).

Ak mobilný smerovač zmení svoj bod pripojenia a pre uzly nie je poskytovaná žiadna podpora mobility, všetky spojenia medzi mobilnými sieťovými uzlami a uzlami umiestnenými v Internete sa prerušia. Riešením tohto problému sa zaoberá pracovná skupina NEMO (NEtwork MObility). Najjednoduchším riešením je vytvorenie obojsmerného tunela medzi domácim agentom a mobilným smerovačom podobne ako je to v MIPv6.
Táto pracovná skupina tiež skúma problémy súvisiace so špecifickou konfiguráciou mobilných sietí ako sú napríklad vnorené mobilné siete (mobilné siete, ktoré sú pripojené do väčšej mobilnej siete, napr. PDA, ktoré sa pripája do mobilnej siete vo vlaku), multihome mobilné siete (mobilné siete s viacerými bodmi pripojenia do Internetu), kompatibilitou s ostatnými IPv6 protokolmi ako napríklad multicast.

1.3 Multihoming
Multihoming je situácia, pri ktorej si uzol môže vybrať medzi viacerými možnosťami ako dosiahnuť spojenie k cieľu. Môže to byť spôsobené tým, že uzol má viacero sieťových rozhraní, z ktorých si môže vybrať alebo pretože sieť ku ktorej je uzol pripojený je k Internetu pripojená cez viacero smerovačov alebo cez smerovač s viacerými rozhraniami. Takáto konfigurácia s pohľadu mobility umožňuje mobilným uzlom zostať permanentne pripojený k Internetu až kým nestratí konektivitu (ako dôsledok pohybu mimo oblasť pokrytia). Okrem zvýšenej možnosti, že spojenie zostane udržané táto konfigurácia umožňuje rozloženie sieťovej prevádzky medzi viaceré pripojenia. IETF sa otázkou multihomingu z pohľadu mobility siete zaoberala, navrhla množstvo riešení avšak žiadne nebolo prijaté a IETF stratila záujem o riešenie tohto problému. Multihoming sa rieši v rámci projektu NEMO.

2 Možnosti mobility v IPv6 – prax
2.1 Komunikácia medzi dopravnými prostriedkami
Jednou z možností mobility v počítačových sieťach je komunikácia medzi dopravnými prostriedkami navzájom (V2V) alebo medzi dopravným prostriedkom a infraštruktúrou (V2I). Komunikácia medzi dopravnými prostriedkami pozostáva z bezdrôtovej komunikácie prostredníctvom infražiarenia alebo rádiových vĺn (VHF alebo mikrovlny). V spojených štátoch je pre tento účel definované DSRC (Dedicated Short Range Communication) pásmo s frekvenciou 5,9 GHz, ktoré poskytuje konektivitu do vzdialenosti 1 km a umožňuje komunikáciu pri rýchlosti do 160 km/h. Protokol, ktorý v tomto pásme prenáša komunikáciu je založený na protokole IEEE 802.11p. V Európskej únii sa zatiaľ na definovaní podobného štandardu pracuje.
DSRC komunikačný systém pozostáva z dvoch častí: jedna časť je umiestnená v dopravnom prostriedku (OBU, On-board Unit), druhá je súčasťou infraštruktúry (RSU, Road-side Unit). RSU vysiela približne 10x za sekundu varovné a bezpečnostné správy a informuje o aplikáciách dostupných na jednotlivých kanáloch. OBU zasa načúva na kontrolnom kanáli, autentifikuje RSU a v prvom rade vykonáva bezpečnostné aplikácie. Následne mení kanál a vykonáva ostatné aplikácie. Bezpečnosť tejto komunikácie je dosiahnutá šifrovaním na linkovej vrstve použitím PKI infraštruktúry. V tabuľke 1 sú uvedené príklady aplikácií, ktoré sa využívajú v komunikácii medzi dopravnými prostriedkami (autami) navzájom a komunikácii áut a infraštruktúry.

V2V aplikácie

• varovanie o prichádzajúcom vozidle záchrannej služby
  
• varovanie o slepom bode
  
• kooperatívne adaptívne riadenie rýchlosti jazdy
  
• kooperatívne varovanie o možnom vzniku kolízie
  
• kooperatívne varovanie o blížení sa k možnej kolízii
  
• núdzové brzdenie
  
• asistent pri vjazde na diaľnicu z pripájajúceho pruhu
  
• varovanie o zmene jazdného pruhu
  
• varovanie po zrážke
  
• načúvanie na informáciu o zrážke
  
• varovanie o stave vozovky
  
• informácie o možnostiach vozovky
  
• zvyšovanie viditeľnosti
  
• varovanie o vodičovi idúcom v protismere

V2I aplikácie

• varovanie o vodičovi, ktorý sa pripája do jazdného pruhu a kvôli slepému bodu nevidí súbežne idúce vozidlo
  
• varovanie o rýchlosti v zákrute
  
• varovanie o prichádzajúcom vozidle záchrannej služby
  
• varovanie o možnej kolízii na diaľnici alebo železnici
  
• varovanie o možnej kolízii na križovatke
  
• informácia o oprave v správny čas
  
• asistent pri odbočovaní doľava
  
• varovanie o nízkom moste
  
• varovanie o plnom parkovisku
  
• informácia o chodcovi prechádzajúcom cez križovatku
  
• varovanie o stave vozovky
  
• SOS služby
  
• asistent pri rozbehu zo STOP značky
  
• varovanie o porušení signálu STOP
  
• varovanie o porušení signálov semafora
  

Princíp DSRC komunikácie si vysvetlíme na technológii varovania o porušení signálov semafora. V tomto prípade sa používa V2I komunikácia a jej úlohou je varovať vodiča, že pri aktuálnej rýchlosti jazdy poruší signál semafora. Semafor v pravidelných intervaloch bezdrôtovo vysiela správy, ktoré obsahujú stav semafora, jeho pozíciu, čas za ktorý sa stav zmení a aký stav nastane. Okrem týchto informácii môže táto správa obsahovať aj informácie o stave vozovky alebo počasia. Ak auto prijme signál od semafora, vypočíta svoju polohu a na rozhodne sa, či túto informáciu poskytne vodičovi alebo nie. Na obrázku 1 je zobrazená situácia, pri ktorej auto prichádza zo západu a semafor pomocou smerových bezdrôtových antén vysiela svoje správy do všetkých smerov.


Obr. 1: Semafor vysiela DSRC signál

Auto prijíma signál od semafora, vyhodnotí svoju vzdialenosť, rýchlosť a zrýchlenie a na základe informuje vodiča či môže bezpečne prejsť križovatkou alebo nie

Varovanie o rýchlosti v zákrute vie poskytnúť aj systém GPS. Avšak ten nezarátava poveternostné podmienky, stav vozovky a pod. Na obrázku 2 je zobrazená situácia, kedy auto prechádza horskou cestou. Prijíma signály od majákov umiestnených pri ceste. Na základe prijatého tvaru a stavu zákruty preráta či je daná rýchlosť vhodná pre vjazd do zákruty alebo nie. Pokiaľ má maják tiež senzory na vozovke, vie poslať prichádzajúcemu autu aj polohu ľadu.


Obr. 2: Varovanie o rýchlosti v zákrute

Ako posledný príklad si uvedieme V2V komunikáciu (Obr. 3). V zníženej viditeľnosti začne auto E prudko brzdiť. DSRC systém v aute začne vysielať varovanie o prudkom brzdení o ostatné autá varujú vodiča o tejto situácii skôr ako to vodič spozoruje. Táto správa je relevantná len pre autá B a C. Podobným spôsobom postupného šírenia informácie sa realizuje aj varovanie o zrážke, prekážke, poľadovici a podobne.


Obr. 3: Varovanie o prudkom brzdení

Záver
Komunikácia medzi autami je len jednou z praktických aplikácii v mobilne IPv6. Dnes používané bezdrôtové technológie síce dokážu prechádzať medzi jednotlivými prístupovými bodmi, avšak len pri malých rýchlostiach. Ako riešenie tohto problému bol definovaný protokol NEMO, ktorý pracuje len v IPv6. Aplikácie popísané v tomto článku nemožno očakávať veľmi skoro. Keď si uvedomíme, že životnosť automobilov je približne 15 rokov, tak aspoň tento čas bude trvať kým tieto technológie budú v autách štandardom. Reálne to však asi nebude skôr ako o 30 rokov (a v našich podmienkach ešte neskôr)

Literatúra

1. FERNANDES, P. – NUNES, U. 2007. Vehicle Communications: A Short Survey. In: MCCSIS 2007. Lisbon : IADIS Press, 2007, s. 134-138, ISBN: 978-972-8924-40-9
   
2. High-Priority Safety Applications: Further Development and Communication Requirements http://www-nrd.nhtsa.dot.gov/pdf/nrd-12/1665CAMP3web/pages/4HiPriorityA.html (10.9.2007)
   
3. Nautilus6 Project Overview - Deployment of the Mobile Internet, http://www.nautilus6.org (10.9.2007)
   
4. The KAME project, http://www.kame.net (10.9.2007)

Zdroj:
Švec, Peter: Podpora mobility v IPv6 a jej praktické využitie.
In: Informatický seminár Katedry informatiky 2007 : Využitie operačných systémov a počítačových sietí v podpore výučby informatických predmetov. - Nitra: UKF, 2007. - ISBN 978-80-8094-167-3. - S. 136-141.

1. INTRODUCTION
IPv6 protocol was firsty defined in 1998. The main reason for developing a new internet protocol was based on lack of address; however this was not the only reason. Unfortunately, many people think of IPv6 only as enormous address space, but there are a lot of other advantages, e.g:
- group addressing – possibility of communication in big groups of users. It is very important for large data transfer such as video stream or videoconference. Datastream is not delivered to every user (unicast) but to the whole group of users (anycast). IPv6 also enables communication with the nearest node (anycast).
- security function – authorizations and authentication function are implemented directly in the protocol and are mandatory.
- auto configuration – automatic configuration of network interfaces based on their physical address
- flow priority – protocol itself recognizes data streams which must be transmitted in real time, and the data must be processed with highest priority.
- mobility – possibility of migration between many networks with the user’s home network address.
New protocol has also simplified header, which speeds up its processing on routers. Increasing of speed is also available because the fragmentation occurs on end stations not on routers. Mobile device support should be the main reason to implement this protocol into practice, which, in reality, is not true. Due to NAT technology, the address space is not exhausted and IPv6 protocol is mainly used only in academic networks. We approached universities in Slovakia to find out whether they use the new IPv6 protocol. The result of this research is described later on this paper. There are three ways how to connect to IPv6. We used some tests to compare these methods of connection into IPv6 network to show the need of IPv6.

2. SURVEY
Protocol IPv4 is keeping its post because of the commercial sphere, so it is up to academic sphere to fight for its expansion. There is GÉANT2 network in Europe which interconnects national academic networks. GÉANT2 natively supports IPv6 protocol. Academic network in Slovakia is SANET (Slovak Academic Network). It also natively supports this protocol. We made a research on 15 Slovak university departments (Centers of ICT or Departments of Computer Science).We asked them whether they use IPv6 protocol and so what extend. We have obtained replies from 9 of these departments.

University of Presov
The support of IPv6 protocol is only on main SANET router. The University does not use this protocol. This university has 19 blocks of IPv4 C class addresses.

University of SS Cyril and Methodius in Trnava
Strictly uses only IPv4. Regarding to RIPE database, this University has only one C class range assigned.

Academy of Arts in Banska Bystrica
This university does not deal with this problem and has one C class range assigned.

The Catholic University in Ruzomberok
Faculty of Education has created VLAN networks, all backbone devices are IPv6 compatible but they do not use it. Regarding to RIPE this University has ten C classes assigned.

Technical University of Kosice
Formerly they had an IPv6 project as an effort of a few students. They routed IPv6 traffic from Cisco lab to the college. Later they requested IPv6 address range, but it was too small and incorrectly designed. Now they do not use IPv6 even though it is supported and configured on SANET router. This university has one B class address range assigned of IPv4, but no IPv6 address range. Most probably they had IPv6 address space when using 6bone.

Comenius University in Bratislava
This University does not use IPv6 protocol and they do not intend to implement it. In the past some departments tested IPv6 in labs, but they did not use it in practice. Comenius University has, as Technical University of Kosice, assigned one B class of IP4 address space.

Matej Bel University in Banska Bystrica
MBU uses only direct IPv4 addressing and all active network devices and end stations are configured for using IPv4 protocol. Technically they support IPv6, but the University does not use it. The MBU has 19 C classes assigned of IPv4, but also has IPv6 address range 2001:4118:0100::/48.

University of Zilina
It has one B class IPv4 address range assigned and also 2001:4118:300::/48 IPv6 address range. IPv6 services are natively accessible via IPv6. They use OSPF routing protocol in their network. Services accessible via IPv6 are DNS: nic.uniza.sk., proxy.uniza.sk. WWW: www.uniza.sk, nic.uniza.sk, EMAIL (pop3, imap): nic.uniza.sk, LDAP: nic.uniza.sk, FTP: nic.uniza.sk and are running on Linux and Windows 2003 servers.

Slovak University of Agriculture in Nitra
This university does not use IPv6 and has not done any research in this field. RIPE has twelve C classes assigned.

Constantine the Philosopher University in Nitra
All end hosts and servers are using direct IPv4 addressing. Nowadays the University has eight C classes of IPv4 addresses assigned. This range is for the University needs too small so the University is trying do get more IPv4 addresses. The rules are too strict and the process is too complicated. Most servers have UNIX operating system so the possibility to use IPv6 is open. The University have no IPv6 address space assigned. Thanks to auto configuration mechanism, all servers have link local IPv6 addresses (FE80::/10). All workstations use Windows XP, so after enabling IPv6 support with command ipv6 install all have link local address and also 6to4 (RFC3056) addresses from 2002::/16 range.

3. POSSIBILITIES OF USING IPV6
Most of out universities does not use IPv6 protocol. The answers for the question why are various. They are mostly saying “Why to change anything that works?”, “If you want to use IPv6, just enable it in your Windows and you will get 6to4 address.”
We are looking for the method how to show people, that the best way for using IPv6 is its native form. There are three ways how to connect into an IPv6 network: using native IPv6 network and have IPv6 address space assigned from RIPE or using 6to4 or 6in4 mechanism.
Both of them encapsulate IPv6 packets into IPv4 ones. The main difference between them is that in 6in4 it is necessary to establish en explicit tunnel between a host and a server. The tunnel is established and the configuration is done by a Tunnel Broker. In 6to4 there is no need to establish the tunnel. IPv6 prefix is derived from IPv4 address of a host.
We tested the speed of using 6in4 and 6to4 addresses against IPv4 addresses. The test of native IPv6 was not done because our university has not assigned IPv6 address space.

3.1 Tunneling via Broker – 6in4
First of all, we must find a Broker. There are many brokers, e.g. Freenet6, Huricane Electric, SixXS, S26, SingNet. We decided to use Hexago which provides connectivity into a Freenet6 network. A tunnel registration is divided into three steps. First, we must fill a registration form www.hexago.com. Second, we need to install a TSP client – a virtual network adapter. Third, we need to run the TSP client. After this is done, we get 2001:5c0:8fff:fffe::44b7 IPv6 address. We made this procedure on two separate hosts and the second one had 2001:5c0:8fff:fffe::44b9 address. After this, we ran a ping test between those two hosts (Figure 1)

C:\Documents and Settings\Petko>ping6 2001:5c0:8fff:fffe::44b9
Pinging 2001:5c0:8fff:fffe::44b9
from 2001:5c0:8fff:fffe::44b7 with 32 bytes of data:
Reply from 2001:5c0:8fff:fffe::44b9: bytes=32 time=340ms
Reply from 2001:5c0:8fff:fffe::44b9: bytes=32 time=372ms
Reply from 2001:5c0:8fff:fffe::44b9: bytes=32 time=315ms
Reply from 2001:5c0:8fff:fffe::44b9: bytes=32 time=340ms
Ping statistics for 2001:5c0:8fff:fffe::44b9:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 315ms, Maximum = 372ms, Average = 341ms

Figure 1. Ping test between to 6in4 hosts

3.2 Automatic tunnel – 6to4
Assigning a 6to4 IPv6 address is very simple. All we have to do is to enable IPv6 support on the interface and have public IPv4 address. After this, the system is configured with IPv6 address from 2002::/16 range. We ran a test on workstation located in Constantine the Philosopher University in Nitra to a DNS server located at University of Zilina. Both universities are connected to SANET and Zilina has native IPv6 support.
First, we made traceroute to count hops in IPv4 network and IPv6 network. The results can be seen in the Figures 2 and 3. When we used 6to4 address, there are twelve hops. The reason for this is that the packets do not stay in the SANET network. First we have to contact relay router with IPv4 anycast address 192.88.99.1 which, in our case, is situated in Portugal.
tracert nic.uniza.sk
Tracing route to nic.uniza.sk [158.193.48.33] over a maximum of 30 hops:
1 <1>Figure 2. Tracing route in IPv4 network

tracert6 nic.uniza.sk
Tracing route to nic.uniza.sk [2001:4118:300:48::33] from 2002:c2a0:d2ce::c2a0:d2ce over a maximum of 30 hops:
1 58 ms 60 ms 58 ms ::192.88.99.1
2 58 ms 62 ms 67 ms ROUTER1.IPv6.GE.Lisboa.fccn.pt [2001:690:800:1::1]
3 78 ms 124 ms 60 ms fccn.rt1.lis.pt.geant2.net [2001:798:24:10aa::1]
4 62 ms 62 ms 58 ms 2001:798:cc:1701:2401::1
5 58 ms 59 ms 59 ms so-7-2-0.rt1.gen.ch.geant2.net [2001:798:cc:1201:1701::1]
6 72 ms 68 ms 68 ms so-7-2-0.rt1.fra.de.geant2.net [2001:798:cc:1201:1401::2]
7 93 ms 74 ms 74 ms so-6-0-0.rt1.pra.cz.geant2.net [2001:798:cc:1301:1401::1]
8 83 ms 79 ms 79 ms cz.sk1.sk.geant.net [2001:798:20cc:1301:2701::2]
9 81 ms 79 ms 79 ms sanet-gw.sk1.sk.geant.net [2001:798:2027:10aa::2]
10 83 ms 82 ms 84 ms ZU-Zilina.sanet2.sk [2001:4118::c5]
11 83 ms 85 ms 96 ms sw-vd-a5.net.utc.sk [2001:4118:300::7708:215]
12 81 ms 81 ms 83 ms nic.uniza.sk [2001:4118:300:48::33]
Trace complete.
Figure 3. Tracing route in IPv6 network

4. CONCLUSION
Although Slovak Academic Network supports native IPv6 and routes IPv6 packets, the usage of this protocol is very low. Only two universities have IPv6 addresses assigned, yet only one on them uses it in practice. The reason most probably lies in no need for IPv6 because most of them have enough IPv4 addresses and do not want to change something that works. Some universities use private IP addresses and NAT technology for end users. NAT decreases end-to-end communication which is one of the basic principles of IP. On the Constantine the Philosopher University we are ready to request IPv6 address space and implement it on all servers and most workstations at the university.
We are looking for applications that will convince users to switch to IPv6. There is a problem with Windows XP as IPv6 is disabled by default in this operating system, but this problem can be solved. Windows Vista is a great support for IPv6 implementation IPv6 is enabled in this operation system by default and preferred.
We also tested the other two ways of connecting to IPv6 network which is via Broker and via IPv4 compatible IPv6 address. The connection via Broker works well only for testing. The problem is that any traffic is done via the tunnel even if there is a shorter path than the one from other side of the tunnel. A problem with 6to4 address is, that the host sometimes does not connect to the nearest relay server. We can enforce it to use a different relay server, but we cannot expect a user to use a command prompt and type commands. We hope to obtain IPv6 address range in a near future.

REFERENCES
Deering, S., Hinden R., 1998, Internet Protocol, Version 6 (IPv6) Specification. RFC 2460
Huitema, C., 1997, IPv6: The New Internet Protocol, (Second edition). Prentice Hall, New Jersey, USA
Miller, P.E., Miller M. A., 2000, Implementing IPv6: Supporting the Next Generation Internet Protocols, Faster City: IDG Books Worldwide
Satrapa, P., 2007, IPv6 v MS Windows Vista. 2007. [online].
Satrapa, P., 2002, IPv6. Vydavateľstvo Neocortex spol. s. r. o., Praha, Czech Republic

SOURCE
Švec, Peter: IPv6 in Slovak Academic Network. In: IADIS Multi Conference on Computer Science and Information Systems 2007. - Lisabon: Universidade de Lisboa, 2007. - ISBN 978-972-8924-40-9. - S. 120-123.

Úvod
Využívanie systém Moodle ako primárneho LMS má už na Katedre informatiky FPV UKF v Nitre niekoľkoročnú tradíciu. V prvých rokoch slúžil hlavne ako úložisko elektronických materiálov pre študentov avšak veľmi rýchlo sa začali vyvíjať e-kurzy, ktoré sú dnes na veľmi dobrej úrovni. Moodle vo svojej základnej inštalácii umožňuje vytvárať študijné materiály vo formáte HTML stránok alebo umiestňovať rôzny offline obsah. Študijný materiál pre online formu musí spĺňať rôzne zásady, čo sa týka množstva textu zobrazeného na jednej obrazovke, počtu kapitol, slov jednej lekcii, atď. Ani štandardné HTML stránky, ani offline dokumenty napríklad v PDF formáte tieto zásady nespĺňajú. Dnes v systéme študuje viac ako 600 študentov a jeho ďalšou úlohou sa stáva manažment výučby. Nejde už len o vytvorenie a zadelenie veľkého počtu študentov do skupín, ale aj o to ako s týmito študentmi efektívne komunikovať, viesť ich prácu, evidovať ich aktivitu a získavať anonymnú spätnú väzbu. Všetky tieto vymenované vlastnosti nie sú štandardnou súčasťou Moodle a ich využívanie nám umožňujú moduly tretích strán

Moduly tretích strán
Moodle je modulárny systém napísaný v skriptovacom jazyku PHP. Použitie tohto jazyka dáva možnosť veľkej skupine programátorov podieľať sa na jeho vývoji a odhaľovaní chýb. Vzhľadom na to, že systém je modulárny, je jednoduché vytvoriť nové časti nazývané moduly a integrovať ich do existujúceho systému bez nutnosti zasahovať do pôvodného celku. Niektoré moduly vytvárajú priamo vývojári samotného systému, iné sú tvorené jednotlivcami alebo skupinami – nadšencami po celkom svete. Tieto sa nazývajú moduly tretích strán. Moduly tretích strán sú publikované na oficiálnych stránkach systému Moodle (moodle.org) v sekcii Modules and Plugins. Ich inštalácia je veľmi jednoduchá. Niektoré sa inštalujú ako bloky, iné ako moduly alebo aktivity.

1.1 Modul Kniha (Book)
Modul Kniha vytvoril Petr Škoda z Českej republiky. Kniha umožňuje veľmi jednoducho vytvárať viacstranové texty podobne ako sme zvyknutí s tlačených kníh. Nie sme nútení vytvárať veľa zdrojov vo formáte HTML stránky, všetky môžeme dať do jedného, čím sa zároveň zvýši prehľadnosť kurzu. Druhou výhodou je odstránenie nutnosti vertikálneho posúvania textu. Online texty by mali byť vytvárané tak, aby sa v žiadnom prípade neposúvalo v horizontálnom smere, a ideálne je ak ani vo vertikálnom. Ak je to nutné tak vo vertikálnom smere maximálne jeden a pol strany. Odstránenie nutnosti posúvať text sa docielilo vytvorením hierarchickej štruktúry kapitol a podkapitol. Modul kniha definuje kvôli jednoduchosti a prehľadnosti len dve úrovne v hierarchii, čo je však v prevažnej väčšine kurzov postačujúce. Medzi jednotlivými stranami knihy sa je možné prepínať tlačidlami ďalšia strana a predchádzajúca strana.
Modul podporuje aj verziu pre tlač. Vytlačiť môžeme buď celú knihu, alebo len definovanú kapitolu. Generovanie verzie pre tlač je efektívnejšie, nakoľko v prípade opravy chyby alebo zmeny textu, nemusíme robiť túto zmenu 2x (pre online a pre offline) text.
Kniha sama o sebe nie je interaktívna, avšak umožňuje vkladať interaktívny obsah ako je flash, Jej využívanie sa nám osvedčilo a momentálne je väčšina našich kurzov vytváraná v tomto nástroji.

Obr. 1 Online kniha a jej verzia pre tlač

1.2 Modul Dochádzka (Attendance)
Vzhľadom k tomu, že Moodle využívame aj ako podporu denného štúdia, pre niektorých vyučujúcich je tento modul veľkou pomocou. Denní študenti majú povinnosť zúčastňovať sa seminárov a cvičení. Pre vyučujúceho to znamená, že by si mal viesť evidenciu ich dochádzky, väčšinou papierovou formou. Navyše, dochádzka evidovaná na papieri má tendenciu sa stratiť. Modul Dochádzka vytvoril učiteľ ruskej Novosibirskej Štátnej Pedagogickej Univerzity, Dmitry Pupinin. Umožňuje evidovať účasť/neúčasť študenta na cvičení alebo seminári. Do dochádzky sa načítava rozdelenie študentov do skupín v rámci daného kurzu. V súčasnej verzii, nie je možné vytvoriť pre rôzne skupiny rôzne termíny. Tento problém riešime vytvorením týždňov v danom semestri, ktoré sú pre všetkých spoločné. Modul dochádzka definuje 4 typy účasti na prezenčnej forme – prítomný, neprítomný, neskorý príchod, ospravedlnený. Každému typu účasti môžeme prideliť bodovú hodnotu a preniesť tak zisk bodov do celkového hodnotenia. Aby sa body z dochádzky prejavili v celkovom hodnotení, je nutné mať medzi aktivitami kurzu aj aktivitu Účasť pre blok.


Obr. 2 Zadávanie dochádzky a prehľadná správa o dochádzke

1.3 Modul Quickmail
Jednou z najdôležitejších činností učiteľa pri dištančnom vzdelávaní je komunikácia s účastníkmi kurzu. Moodle ponúka niekoľko možností takejto komunikácia. Tou najjednoduchšou je odosielanie súkromných správ. Správa sa zobrazí študentovi v "popup" okne hneď ako sa do systému prihlási. Správu môže poslať nielen učiteľ študentovi, ale študent učiteľovi alebo inému študentovi. Pokiaľ by chcel učiteľ osloviť súčasne viac študentov, týmto spôsobom je to neuveriteľne náročné, čiže môžeme povedať, že nemožné. Pokiaľ chce učiteľ hromadne osloviť študentov môže tak urobiť prostredníctvom diskusného fóra. Pokiaľ nechce aby na jeho príspevok reagovali, je možné takúto reakciu zakázať. V prípade použitia diskusného fóra, nie je zaručené, že sa si študent príspevok v ňom prečíta. Diskusné fórum má možnosť vynútiť odoberanie všetkých príspevkom aj elektronickou poštou, čo by tento problém mohlo vyriešiť. Je tu však druhý problém a tým je oslovenie iba časti študentov alebo len niektorých skupín, bez toho aby sa túto informáciu dozvedeli aj iné skupiny (napr. zrušenie konkrétnej hodiny cvičenia). Tieto problémy rieši modul Quickmail, ktorého autorom je tím Michael Penneyho z Humboldtovej Štátnej Univerzity v USA. Modul umožňuje odoslať vybraným študentom alebo skupinám elektronickú poštu priamo na ich email uvedený pri registrácii. Táto metóda je dostatočne efektívna a konkrétna. Možnosť odosielať hromadný email má len učiteľ kurzu. Vo vyšších verziách Moodle existuje možnosť aby aj študenti mohli odosielať hromadný email, avšak takého nastavenie nepovažujeme za šťastné. Okrem možnosti odosielania správ modul archivuje odoslané správy v Histórii správ.


Obr. 3 Písanie hromadného emailu

1.4 Modul dotazník (Feedback)
Jednou so súčastí vzdelávacieho procesu je aj spätná väzba od študentov. Vzhľadom na to, že študent nepovie svoj názor otvorene, z neopodstatneného strachu, že bude za svoj názor potrestaný, musí byť spätná väzba anonymná. Systém Moodle zaznamenáva všetky aktivitu svojich používateľov – od prihlásenia, cez každé kliknutie, každú odpoveď. Pokiaľ by sme netrvali na anonymite môžeme pre spätnú väzbu využiť diskusné fórum, avšak názory v ňom nemusia byť pravdivé. Moodle poskytuje aktivitu Prieskum, kde jednotlivé prieskumy boli vybrané na základe ich praktickej užitočnosti na hodnotenie v online výučbovom prostredí konštruktívnymi pedagógmi. Sú užitočné na identifikáciu určitých trendov, ktoré sa môžu vyskytnúť medzi účastníkmi. Táto aktivita neumožňuje vytvárať prieskum vlastný a nemáme teda možnosť dozvedieť sa názor študentov na prístup vyučujúceho, kvalitu učeného textu či náročnosť testu. Tieto informácie môžeme získať po doinštalovaní modulu Dotazník. V súčasnosti je to voliteľný modul, avšak vo verzii 1.9 by sa mal stať štandardným. V dotazníku si môžeme vytvoriť ľubovoľné množstvo rôznych typov otázok. Tie najzákladnejšie sú výber jednej alebo viacerých odpovedí (single choice, multiple choice), možnosť otvorenej odpovede (long answer, short answer) alebo definovať bodové hodnoty pre odpovede (rated). Príkladom bodových hodnôt je možnosť ohodnotiť známkou od jedna do päť jednotlivé otázky. Po vyplnení dotazníka učiteľ vidí odpovede, ich percentuálny podiel, avšak nevidí kto akú odpoveď zadal. Nemá teda možnosť ani podvedome vyvodzovať dôsledky pre jednotlivých študentov. 
  
Obr. 4 Vytváranie dotazníka a jeho vyhodnotenie

Záver
Používanie modulov tretích strán umožnilo lepšie využívanie LMS Moodle na Katedre informatiky. Pre editovanie a vkladanie obsahu sa stal veľmi obľúbeným modul Kniha. Z ostatných modulov si najviac pochvál vyslúžili moduly Quickmail, ktorý zefektívnil komunikáciu s účastníkmi kurzu a modul Dotazník, ktorý zasa zefektívňuje vyučovací proces. V tomto článku sme popísali len tie najdôležitejšie moduly tretích strán, aj keď ich využívame oveľa viac. Ako príklad spomenieme štatistiku jedinečných prístupov za posledný mesiac na úvodnej stránke nášho Moodle (moodle.studnet.sk).

Literatúra
KAPUSTA, J. - DRLÍK, M.: Možnosti uplatnenia ďalších technológií v e-learningu. In
Technológia vzdelávania. 2004, roč. 12, č. 5, s. 6-8. ISSN 1335-003X.

SKALKA, Ján - DRLÍK, Martin - KAPUSTA, Jozef - ŠVEC, Peter. Podoby elektronického vyučovania v prostredí Moodle. In Divai 2006 : Dištančné vzdelávanie v Aplikovanej informatike : zborník z vedeckého seminára. Nitra : FPV UKF Nitra - edícia Prírodovedec č. 208, 2006, s. 238-244. ISBN 80-8050-975-1.


Zdroj:
Švec, Peter: Využitie modulov tretích strán v LMS Moodle. In: Divai 2007 : Dištančné vzdelávanie v Aplikovanej informatike : zborník z konferencie s medzinárodnou účasťou. - Nitra: UKF, 2007. - ISBN 978-80-8094-123-9. - S. 209-213.

Úvod
Protokol IPv6 bol definovaný v roku 1998. Hlavným dôvodom, prečo sa tento protokol začal vyvíjať, bol rastúci strach z možného nedostatku adries. Bohužiaľ, väčšina ľudí si pod pojmom IPv6 predstaví veľký adresný priestor. Tento protokol má však aj množstvo iných výhod. Spomeňme si niektoré z nich:

• skupinové adresovanie – skupinová komunikácia je dôležitá pri dátových prenosoch, ako sú rádiové a televízne vysielanie alebo videokonferencia. Dátový tok sa nevysiela každému účastníkovi zvlášť (unicast), ale celej skupine účastníkov (multicast). IPv6 zavádza ešte jeden spôsob skupinovej adresácie. Je ňou metóda, pri ktorej odpovedá najbližší účastník (anycast).
  
• bezpečnostné funkcie – priamo v protokole sú definované autorizačné a autentifikačné funkcie. Tieto bezpečnostné funkcie sú povinné.
  
• autokonfigurácia – automatická konfigurácia sieťových nastavení na základe jedinečného 64 bitového EUI sieťového adaptéru.
  
• definovanie priority prenosu – protokol rozlišuje medzi dátovými tokmi, ktoré musia byť prenášané v reálnom čase, a teda ich spracovanie musí byť uprednostnené pred spracovaním komunikácie nižšej priority.
  
• mobilita – umožňuje jednoduchý presun účastníka medzi rôznymi počítačovými sieťami so zachovaním si adresy, ktorú mal vo svojej domácej sieti.

Nový protokol má tiež zjednodušenú hlavičku, čo zvyšuje rýchlosť jeho spracovania na smerovačoch. K ďalšiemu zvyšovaniu rýchlosti prispieva aj to, že fragmentáciu majú na starosti koncové stanice a nie smerovače. Navyše protokol podporuje mobilné zariadenia, ako napríklad mobilné telefóny. Práve podpora mobilných zariadení by mala prispieť k jeho presadeniu, ale aktuálna situácia je iná. Napriek mnohým predpovediam o vyčerpaní adresného priestoru IPv4 sa tento priestor stále nevyčerpal. Stalo sa tak preto, že bol zavedený mechanizmus lokálnych adries spolu s technológiou NAT. Súčasný stav je taký, že je pre organizáciu veľmi ťažké získať ďalšie rozsahy IP adries. Podmienky sú veľmi prísne.

Prieskum
Vzhľadom na to, že protokol IPv4 si svoju pozíciu drží vďaka komerčnej sfére, je zrejmé, že za rozšírenie IPv6 bude musí bojovať sféra akademická. V Európe existuje sieť GÉANT2, ktorá prepája európske akademické siete. GÉANT2 natívne podporuje IPv6 protokol. Rovnako je to aj v prípade nášho SANETu. Spýtali sme sa 15 vybraných univerzitných pracovísk (buď katedier informatiky alebo centier informačných technológií), ako sú na tom s implementáciou IPv6 protokolu. Žiadali sme ich o poskytnutie informácií o IPv6 sieti v rámci ich univerzity. Odpovedalo 9 pracovísk. Zároveň sme v RIPE databázach vyhľadali, koľko IPv4 adries majú univerzity, ktoré odpovedali.

Prešovská univerzita
Podpora IPv6 je zapnutá na centrálnom smerovači SANETu. Podľa RIPE informácií má univerzita pridelených 19 rozsahov triedy C. Pripomeňme si, že jeden rozsah triedy C obsahuje 256 IP adries.

UCM Trnava
Striktne sa používa len IPv4. Podľa RIPE informácií má pridelený jeden C rozsah IPv4 adries.

Akadémia umení v Banskej Bystrici.
Akadémia umení sa nezaoberá problematikou IPv6, má pridelený jeden rozsah triedy C.

Katolícka univerzita v Ružomberku
Pedagogická fakulta má vytvorené účelové VLAN siete. Všetky chrbticové sieťové zariadenia zvládnu aj IPv6. Podľa RIPE má pridelených 10 rozsahov triedy C.

Technická univerzita Košice
Projektu IPv6 sa na internátoch veľmi dávno venovalo zopár jednotlivcov. Smerovali IPv6 z CISCO Labu na internáty. Neskôr internáty požiadali o pridelenie IPv6 adresného priestoru. Pridelený rozsah bol veľmi malý a nevhodne navrhnutý. Momentálne je zo strany SANET smerovača všetko nastavené pre použitie IPv6, avšak brána nie je pre tento protokol z dôvodu nevhodného rozvrhnutia pripravená. Protokol IPv6 sa v konečnom dôsledku v sieti univerzity nevyužíva. Údaje v RIPE databáze ukazujú, že Technická univerzita má pridelenú jednu B triedu adries a nemá pridelený rozsah IPv6. Pravdepodobne sa IPv6 prevádzkoval počas fungovania experimentálnej siete 6bone.

Univerzita Komenského
Na Univerzite Komenského v súčasnosti nie je IPv6 prevádzkované a ani sa v dohľadnej dobe neuvažuje o jeho implementácii. Laboratórne sa výskumom IPv6 niektoré pracoviská zaoberali, ale k praktickému nasadeniu neprišlo. UK má rovnako ako Technická univerzita v Košiciach pridelenú jednu B triedu adries.

UMB Banská Bystrica
Na UMB je použité priame IPv4 adresovanie a všetky aktívne prvky siete a koncové stanice nakonfigurované pre IPv4 ale technicky umožňujúce aj implementáciu IPv6. UMB má pridelených 19 C tried IPv4 a taktiež IPv6 adresný rozsah 2001:4118:0100::/48.

Žilinská univerzita
Žilinská univerzita má pridelený jeden rozsah B triedy a taktiež IPv6 adresný priestor 2001:4118:300::/48. IPv6 služby sú na univerzite dostupné natívne a na smerovanie je použitý protokol OSPF. Služby IPv6 sú nakonfigurované na serveroch s OS linux a windows 2003. Cez IPv6 sú dostupné služby: DNS: nic.uniza.sk., proxy.uniza.sk. WWW: www.uniza.sk, nic.uniza.sk, EMAIL(pop3, imap): nic.uniza.sk, LDAP: nic.uniza.sk, FTP: nic.uniza.sk

SPU Nitra
Slovenská poľnohospodárska univerzita sa výskumom IPv6 nezaoberá ani tento protokol nepoužíva. Univerzita má pridelených 12 C tried IPv4 rozsahu.

UKF Nitra
V počítačovej sieti UKF sa používa priame adresovanie v IPv4 priestore. Momentálne má univerzita pridelených 8 rozsahov C triedy IPv4 adries. Tento rozsah však nestačí, a preto sa univerzita snaží získať ďalšie IPv4 adresy. Ich získanie je však kvôli súčasným pravidlám prideľovania veľmi ťažké. Vzhľadom na to, že až na pár výnimiek používa univerzita unixové servre (prevažne SUN), je vo vnútornej sieti IPv6 podporovaná. Znamená to, že vďaka autokonfigurácii majú všetky tzv. lokálne linkové adresy z rozsahu FE80::/10. Ako pracovné stanice sa používajú počítače s operačným systémom Windows XP. Windows XP má síce podporu protokolu IPv6, ale treba ju zapnúť príkazom ipv6 install. Windows sa potom nakonfiguruje tak, že má lokálnu linkovú adresu ale aj 6to4 adresu (RFC3056), čo je adresný rozsah 2002::/16.

UKF a 6to4
Hlavným cieľom 6to4 je umožniť IPv6 oblastiam vzájomnú a bezproblémovú komunikáciu po IPv4 Internete s minimálnou konfiguráciou. Vyžaduje len, aby mala pripojená sieť k dispozícií aspoň jednu IPv4 adresu. 6to4 vytvára na základe danej IPv4 adresy IPv6 prefix s dĺžkou 48 pre celú sieť. Začína hodnotou 2002::/16, podľa ktorej sa dá rozpoznať, že ide o 6to4 adresu. Ďalších 32 bitov tvorí IPv4 adresa prístupového smerovača. Takto vznikne prefix štandardnej dĺžky, ktorý umožňuje adresovať počítače v sieti obvyklým spôsobom. Jednoducho povedané, pokiaľ daný uzol podporuje IPv6, tak posiela IPv6 datagramy, pokiaľ nie, tak ich tuneluje prostredníctvom IPv4 siete. A nič netreba robiť! Je to ale naozaj tak? Ukážme si príklad príkazu tracert, ktorý nám zobrazí zoznam smerovačov, cez ktoré naša požiadavka prechádza. Vyskúšame tento príkaz na DNS serveri Žilinskej univerzity. Obe univerzity sú pripojené do SANETu, takže by sa dalo predpokladať, že počet smerovačov, cez ktoré treba prejsť bude nízky. Skúsme najskôr klasiku, vykonáme príkaz tracert.

tracert nic.uniza.sk
Tracing route to nic.uniza.sk [158.193.48.33] over a maximum of 30 hops:

1 <1>

Obr. 1: Sledovanie trasy pre IPv4 uzol

A teraz to isté len s IPv6. Vykonáme príkaz tracert6. Všimnime si v IPv6 adrese časť adresy c2a0:d2.ce. Keď toto číslo prevedieme do desiatkového tvaru dostaneme 194.160.210.206 čo je IPv4 adresa.

tracert6 nic.uniza.sk
Tracing route to nic.uniza.sk [2001:4118:300:48::33] from 2002:c2a0:d2ce::c2a0:d2ce over a maximum of 30 hops:
1 58 ms 60 ms 58 ms ::192.88.99.1
2 58 ms 62 ms 67 ms ROUTER1.IPv6.GE.Lisboa.fccn.pt [2001:690:800:1::1]
3 78 ms 124 ms 60 ms fccn.rt1.lis.pt.geant2.net [2001:798:24:10aa::1]
4 62 ms 62 ms 58 ms 2001:798:cc:1701:2401::1
5 58 ms 59 ms 59 ms so-7-2-0.rt1.gen.ch.geant2.net [2001:798:cc:1201:1701::1]
6 72 ms 68 ms 68 ms so-7-2-0.rt1.fra.de.geant2.net [2001:798:cc:1201:1401::2]
7 93 ms 74 ms 74 ms so-6-0-0.rt1.pra.cz.geant2.net [2001:798:cc:1301:1401::1]
8 83 ms 79 ms 79 ms cz.sk1.sk.geant.net [2001:798:20cc:1301:2701::2]
9 81 ms 79 ms 79 ms sanet-gw.sk1.sk.geant.net [2001:798:2027:10aa::2]
10 83 ms 82 ms 84 ms ZU-Zilina.sanet2.sk [2001:4118::c5]
11 83 ms 85 ms 96 ms sw-vd-a5.net.utc.sk [2001:4118:300::7708:215]
12 81 ms 81 ms 83 ms nic.uniza.sk [2001:4118:300:48::33]
Trace complete.
Obr. 2: Sledovanie trasy pre IPv6 uzol

Vidíme, že naša požiadavka prešla celou Európu. Prečo je ale tomu tak? Veď sme na rovnakom SANETe. A SANET natívne podporuje IPv6. Problém je v prvom riadku výpisu. Je to prvý 6to4 uzol, ktorý vybalí z IPv4 IPv6 datagram a smeruje ho späť GÉANT2 siete. Tento výpis nie je celkom kompletný, pretože náš datagram musí ešte prejsť cestu k 192.88.99.1.

tracert 192.88.99.1
Tracing route to 192.88.99.1 over a maximum of 30 hops
1 3 ms 2 ms <1>st timed out.
11 59 ms 57 ms 59 ms 192.88.99.1

Trace complete.
Obr. 3: Sledovanie trasy pre 6to4 uzol

Keď si to spočítame, tak IPv6 požiadavka musela prejsť cez 22 smerovačov, čo je v porovnaní s IPv4 štyrikrát viac. Mohli by sme teda povedať, že na čo nám je IPv6, keď jeho smerovanie je také pomalé. Ale musíme si uvedomiť, že dôvodom spomalenia je práve technológia 6to4. Keby sme používali natívne IPv6 a mali sme pridelený adresný rozsah, tak by bolo smerovanie vďaka vlastnostiam IPv6 rýchlejšie ako súčasné IPv4. Problémom je už len to „keby“.
Za súčasných podmienok, keď funguje NAT, voliteľne aj IPSec len málokto uvažuje nad prechodom na IPv6. Navyše, prinútiť používateľov, aby vo svojom Windows napísali príkaz IPv6 install je asi nemožné. Znamená to, že musí prísť niekto, kto povie, že je čas na to, aby IPv6 používali aj koncoví používatelia. Vyzerá to tak, že to bude Microsoft.

Windows Vista a Longhorn
Nový Windows zrovnoprávnil obidva protokoly. Implicitne bude podpora IPv6 nainštalovaná a aktívna. Pokiaľ DNS dotaz pre dané meno vráti adresy pre IPv4 aj pre IPv6, prednosť budú mať práve IPv6 a na tejto adrese sa klient pokúsi nadviazať spojenie. Až keď neuspeje, vytvorí spojenie s IPv4 adresou. Konfigurácia sieťových rozhraní (stavová aj bezstavová) bude v štandardnom nastavení tiež automatická. Ďalšou novinkou bude možnosť konfigurovať IPv6 cez grafické rozhranie a navyše plná podpora IPSec. Dúfajme teda, že snaha celého sveta presadiť IPv6 bude konečne úspešná.

Záver
Protokol novej generácie má pred sebou ešte dlhú cestu. Našou snahou je mu pomôcť aspoň na akademickej pôde na Slovensku. UKF v Nitre už mala IPv6 implementované, ale to bolo ešte za čias experimentálnej siete 6bone. Momentálne začíname od znova. Krátkym prieskumom sme zistili, že iné univerzity buď ani nerozmýšľajú nad zavedením IPv6, alebo je to len márna snaha zopár snaživcov. Svetlým príkladom je Žilinská univerzita, ktorá má tento protokol implementovaný. Za zmienku tiež stojí ochota ľudí na tomto probléme spolupracovať.


Literatúra

[1] DEERING S., HINDEN R. 1998. Internet Protocol, Version 6 (IPv6) Specification. 1998. RFC 2460
[2] HUITEMA, C. 1997. IPv6: The New Internet Protocol, (Second edition). Prentice Hall, 1997. ISBN 0138505055.
[3] MILLER, P.E., MILLER M. A. 2000. Implementing IPv6: Supporting the Next Generation Internet Protocols, Faster City: IDG Books Worldwide, ISBN: 0764545892
[4] SATRAPA, P. 2007. IPv6 v MS Windows Vista. 2007. [online]. [cit. 2007- 02 - 5]. In Lupa – server o českém Internetu, 2007. Dostupné na internete: .
[5] SATRAPA, P. 2002. IPv6. Praha : Vydavateľstvo Neocortex spol. s. r. o. 237 s. ISBN 80-86330-10-9

Zdroj:
Švec, Peter: Súčasný stav IPv6 na Slovenských univerzitách. In: Sieťové a informačné technológie 2007 - SIT 2007. - Nitra: SPU, 2007. - ISBN 978-80-8069-873-7. - S. 106-111.

1 IP verzie 4
Koncom šesťdesiatych rokov minulého storočia sa v oblasti sieťových technológií začala prejavovať potreba zaviesť komunikačný protokol, ktorý by bol nezávislý na hardvérovej implementácii, centrálnom riadení a rovnocennosti jednotlivých pripojených uzlov. V roku 1969 americká agentúra DARPA vyhlásila projekt na vytvorenie takejto siete. Nová sieť dostala meno ARPANET a stala sa základom budúceho Internetu. K jej vývoju sa pripojilo viacero organizácií. V polovici sedemdesiatych rokov vznikajú základy TCP (Cerf V., Dala Y., Sunshine C., 1974). V roku 1983 bol TCP/IP štandardizovaný a vyhlásený za jediný komunikačný protokol v prostredí ARPANETu. V roku 1990 sieť ARPANET zaniká a vzniká sieť Internet.
Základným komunikačným protokolom siete Internet je protokol IP (Postel J., 1981). V pôvodnom návrhu počíta IP protokol s jedinečnou adresou dlhou štyri bajty. Preto má táto verzia označenie 4. V čase keď sa definoval IP protokol, nikto nepredpokladal obrovský rast siete, vývoj a zlacnenie osobných počítačov a prudký rozvoj telekomunikačných technológií. Rozsah IP adries bol rozdelený do piatich tried, ktoré sa veľmi štedro prideľovali jednotlivým záujemcom o pripojenie k sieti.
Jednotlivé triedy IP adries sú uvedené v tabuľke č. 1.

Tab. 1 Rozdelenie tried IPv4

Trieda Rozsah Počet sietí Počet počítačov v jednej sieti
A 1.0.0.0/8 – 126.0.0.0/8 126 224-2 = 16 777 214
B 128.0.0.1/16 – 191.0.0.0/16 214 = 16 384 216-2 = 65 534
C 192.0.0.1/24 – 223.0.0.0/24 222 = 4 194 304 28-2 = 254 počítačov
D 224.0.0.1 – 239.255.255.255 – –
E 240.0.0.1 – 254.255.255.255 – –

Začiatkom 90-tych rokov si zodpovední uvedomili, že takého delenie je veľmi neefektívne. Príliš veľa spoločnostiam sa pridelil počet adries, ktoré nevyužívali. S rastom žiadostí o pridelenie adries sa objavil problém ich vyčerpania. Začali sa preto hľadať možnosti ako vyriešiť nedostatok adries.
Pokiaľ sa nenašlo riešenie bolo nutné spomaliť rýchlosť akou sa rozdeľovali adresy. Zrušili sa preto triedy a zaviedlo sa teda beztriedne adresovanie. Zároveň sa zaviedli privátne adresy použiteľné len v intranetoch. Ako privátne adresy sa podľa RFC 1597 (Rekhter Y., Moskowitz B., Karrenberg D., de Groot G., 1994) vyčlenili siete 10.0.0.0/8, 172.16.0.0/12 a 192.168.0.0/24. Všetky ostatné adresy označujeme ako verejné. Privátne adresy spolu s mechanizmom NAT (Network Address Translation) vyriešili problém s nedostatkom IP adries na dostatočne dlhý čas. Princíp NAT spočíva v tom, že za pod jedinú verejnú IP adresu môžeme schovať ľubovoľný počet počítačov s privátnymi adresami.
Komplexné riešenie sa objavilo v roku 1994. Vznikol nový protokol, ktorý riešil nie len problém s nedostatočným počtom adries, ale aj mnohé ďalšie problémy. Nový protokol mal vedieť zabezpečiť skupinovú komunikáciu, bezpečnosť, mobilitu, prioritu dátových tokov a automatickú konfiguráciu.
Aj keď bol definovaný nový protokol, jeho masovému uvedeniu do praxe bráni skutočnosť, že technológia NAT je pre väčšinu organizácií dostačujúca. Preto pokiaľ nenarastie záujem o garantované vysokorýchlostné dátové prenosy a bezpečnosť prenosu bude IPv6 stále trocha v úzadí.

2 IP verzie 6
Výsledkom snaženia mnohých odborníkov je protokol verzie 6. Jednou zo základných vlastností nového protokolu je zmena dĺžky IP adresy na 128 bitov (Huitema C., 1997). Takéto rozšírenie nám dáva možnosť použiť 2128 adries, čo je približne 35 triliónov adries. Toto neuveriteľne veľké číslo je dostatočnou rezervou na veľmi dlhý čas.
Protokol IPv6 disponuje mnohými ďalšími vlastnosťami. Ako príklad si vymenujme tie najdôležitejšie:

• skupinové adresovanie – skupinová komunikácia je dôležitá pri dátových prenosoch ako sú rádiové a televízne vysielanie alebo videokonferencia. Dátový tok sa nevysiela každému účastníkovi zvlášť (unicast) ale celej skupine účastníkov (multicast). IPv6 zavádza ešte jeden spôsob skupinovej adresácie. Je ňou metóda, pri ktorej odpovedá najbližší účastník (anycast).
  
• bezpečnostné funkcie – priamo v protokole sú definované autorizačné a autentifikačné funkcie
  
• autokonfigurácia – automatická konfigurácia sieťových nastavení na základe jedinečného 64 bitového EUI sieťového adaptéru.
  
• definovanie priority prenosu – protokol rozlišuje medzi dátovými tokmi, ktoré musia byť prenášané v reálnom čase, a teda ich spracovanie musí byť uprednostnené pred spracovaním komunikácie nižšej priority
  
• mobilita – umožňuje jednoduchý presun účastníka medzi rôznymi počítačovými sieťami so zachovaním si adresy, ktorú mal vo svojej domácej sieti
  

Nový protokol definovaný v RFC 2460 (Deering S., Hinden R., 1998) má zjednodušenú hlavičku, čo prispieva k jeho rýchlejšiemu spracovaniu na smerovačoch. Zmenšenie hlavičky ale neznamená zníženie počtu informácií, ktoré sa prenášajú. Menej dôležité časti sa presunuli do rozširujúcich hlavičiek, ktoré si spracuje to zariadenie, pre ktoré sú určené.
Nová IP adresa má aj nový spôsob zápisu. Tvar adresy je rozdelený na osem 16 bitových častí písaných v šestnástkovej sústave. Jednotlivé čísla sú oddelené dvojbodkou. Syntax umožňuje používať aj skrátený zápis (tab. 2), kde

• sa nemusia písať uvádzacie nuly,
  
• štyri nuly môžu nahradiť jednou nulou a
  
• skupina núl sa môže na nahradiť dvojbodkou.
  

Tab. 2 Formáty zápisu IPv6 adresy

0123:0000:0000:0000:FEDC:BA98:7654:3210
123:0000:0000:0000:FEDC:BA98:7654:3210
123:0:0:0:FEDC:BA98:7654:3210
123::FEDC:BA98:7654:3210

Protokol IPv6 nedelí adresy na triedy, ale definuje prefix, ktorý oddeľuje časť určenú pre označenie siete od časti určenej pre označenie pre jednotlivé pripojené počítače. Prefix sa udáva podobne ako u starých adries za lomkou. Vo všeobecnosti sa IPv6 adresy delia na

• globálne – sú jednoznačné v celom Internete
  
• lokálne – sú jednoznačné v rámci jednej inštitúcie
  
• linkové – sú jednoznačné iba v rámci jednej fyzickej siete
  

Na obr. 1 je zobrazené rozdelenie jednotlivých častí IPv6 adresy. Jednotlivé čísla uvádzajú začiatočný bit poľa. Celková dĺžka poľa je 128 bitov.


Obr. 1 Členenie globálnej adresy

• I je štandardný identifikátor pre globálnu adresu (3 bity), binárne sa rovná 001
  

• TLA (top level aggregation, 13 bitov) je identifikátor agregačnej inštitúcie najvyššej úrovne (globálny poskytovateľ).
  
• NLA (next level aggregation, 32 bitov) je identifikátor agregačnej inštitúcie, ktorá je na ďalšej úrovni v poradí (lokálny poskytovateľ)
  
• NLA a TLA zodpovedajú topológii „verejného“ Internetu, teda siete mimo koncovú pripojenú organizáciu
  
• SLA (site level aggregation, 16 bitov) je agregačný identifikátor pre jednu lokalitu (pre inštitúciu). Rozdelenie v poli SLA zodpovedá topológii miestnej siete.
  
• Zvyšok adresy tvorí 64 bitový identifikátor sieťového rozhrania koncového uzla, ktoré môže byť vytvorené napríklad z EUI-64, ktoré je vytvorené z MAC adresy rozhrania.
  

3 Pripojenie k IPv6 sieti
3.1 Získanie IPv6 adresy
Postup prideľovania IPv6 adresy je nasledujúci:

• Poskytovateľ najvyššej úrovne dostane od registračnej autority pridelený identifikátor (prefix siete), z rozsahu ktorého môže prideľovať identifikátory nižšej úrovne jednotlivým ISP – poskytovateľom služieb Internetu.
  
• ISP potom v rámci svojho identifikátora prideľujú číselne kombinácie pre svojich klientov.
  
• Koncový klienti si pridelený prefix (najčastejšie dĺžky /48) rozdelia podľa svojich potrieb.
  

Prvým krokom pripojenia sa k sieti IPv6 je výber poskytovateľa pripojenia. Natívny spôsob pripojenia sa k sieti nie je technicky jednoduchý, tak sa pripojenie k IPv6 sieti rieši tunelovaním IPv6 protokolu v rámci protokolu IPv4. Princíp tunela je zobrazený na obr. 2.

Obr. 2 Tunelovanie IPv6 protokolu

Aby sme sa pripojili k IPv6 sieti, musíme si nájsť poskytovateľa, ktorý nám umožní vytvoriť si k nemu tunel. Takýto poskytovateľ má pomenovanie IPv6 Tunnel Broker. Takýchto „brokerov“ je veľa. Ako príklad spomenieme Freenet6, Huricane Electric, SixXS, XS26, SingNet. Pre naše potreby sme si vybrali ako brokera kanadskú spoločnosť Hexago, ktorá poskytuje pripojenie k sieti Freenet6.

3.2 Registrácia tunela
Registrácia tunela a teda aj získanie IPv6 adresy spočíva v troch krokoch.

• vyplnenie registračného formulára na adrese http://www.hexago.com
  
• nainštalovanie TSP klienta (TSP klient je potrebný pre vytvorenie virtuálneho adaptéra siete a pre autorizáciu u brokera). Tabuľka 3 uvádza podporované operačné systémy TSP klienta.
  
• spustenie TSP klienta
  

Tab. 3 Podporované operačné systémy pre TSP klienta


3.3 Inštalácia tunela
Pre overenie funkčnosti tunela sme nainštalovali TSP klienta na operačné systémy Windows XP SP2 a FreeBSD 6. Inštalácia na oboch systémoch bola bezproblémová a štandardná. V systéme Windows XP sa vytvorili dva sieťové adaptéry (obr. 3), ktoré umožnia vytvorenie tunela. Po spustení klienta (obr. 4) sa virtuálny adaptér pripojil rýchlosťou 10 Mbps a získal IP adresu 2001:5c0:8fff:fffe::44b7. Druhá strana tunela má IP adresu 2001:5c0:8fff:fffe::44b6 a slúži ako predvolená brána. Treba podotknúť, že systém bežiaci na Windows XP bol pripojený do súkromnej bezdrôtovej siete, a to cez viacnásobný NAT.


Obr. 3 Virtuálny adaptér umožňujúci pripojenie k IPv6 sieti


Obr. 4 TSP klient v aktívnom stave

V systéme FreeBSD sme úpravou konfiguračných súborov TSP klienta požiadali o pridelenie prefixu dĺžky /64 pre druhý sieťový adaptér v systéme. Zo systému sa tak stáva IPv6 router, ktorý bude prideľovať svojim klientom pripojeným na jeho vnútorné rozhranie IPv6 adresy a cez tunelované rozhranie bude smerovať komunikáciu do IPv6 siete. Systém s FreeBSD má pridelenú verejnú IP adresu verzie 4 zo sady pridelenej UKF v Nitre. Je teda priamo pripojený do Internetu.
TSP klient sa spúšťa štartovacím skriptom uloženým v /usr/local/etc/rc.d/freenet6.sh. Po spustení sa klient pripojí k brokerovi, autorizuje sa a pridelí IPv6 adresu virtuálnemu adaptéru (gif0) ako aj vnútornému rozhraniu (fxp0). Pridelené adresy sú uvedené na obr. 5.

fxp0: flags=8843 mtu 1500
options=8
inet6 fe80::20d:60ff:feab:31ee%fxp0 prefixlen 64 scopeid 0x1
inet6 2001:5c0:8dfe::1 prefixlen 64
ether 00:0d:60:ab:31:ee
media: Ethernet autoselect (none)
status: no carrier

gif0: flags=8051 mtu 1280
tunnel inet 194.160.210.164 --> 64.86.88.116
inet6 2001:5c0:8fff:fffe::44b9 --> 2001:5c0:8fff:fffe::44b8 prefixlen 128
inet6 fe80::20d:60ff:feab:31ee%gif0 prefixlen 64 scopeid 0x5
Obr. 5 Konfigurácia sieťových zariadení v systéme FreeBSD

3.4 Overenie funkčnosti tunela
Na overenie funkčnosti tunela sme použili štandardné nástroje oboch operačných systémov. Prvým krokom bolo overenie dostupnosti druhej strany tunela. Na systéme Windows XP aj FreeBSD je to príkaz ping6. Priebeh testu je zobrazený na obr. 6.


C:\Documents and Settings\Petko>ping6 2001:5c0:8fff:fffe::44b6 -t

Pinging 2001:5c0:8fff:fffe::44b6
from 2001:5c0:8fff:fffe::44b7 with 32 bytes of data:

Reply from 2001:5c0:8fff:fffe::44b6: bytes=32 time=232ms
Reply from 2001:5c0:8fff:fffe::44b6: bytes=32 time=211ms
Reply from 2001:5c0:8fff:fffe::44b6: bytes=32 time=209ms
Reply from 2001:5c0:8fff:fffe::44b6: bytes=32 time=354ms
Reply from 2001:5c0:8fff:fffe::44b6: bytes=32 time=386ms
Reply from 2001:5c0:8fff:fffe::44b6: bytes=32 time=311ms

Ping statistics for 2001:5c0:8fff:fffe::44b6:
Packets: Sent = 6, Received = 6, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 209ms, Maximum = 386ms, Average = 283ms

Obr. 6 Testovanie dostupnosti druhej strany tunela

Tunel bol dostupný z obidvoch systémov. Ďalej bolo treba zistiť, či sa tieto dva systémy v sieti vidia, teda či sú navzájom dostupné. Univerzitný firewall blokuje ping žiadosti na počítače vo vnútornej sieti. Keďže celá naša komunikácia prebieha vo vytvorenom tuneli, táto skutočnosť by nám nemala vadiť. Priebeh testu zobrazuje obr. 7.


C:\Documents and Settings\Petko>ping6 2001:5c0:8fff:fffe::44b9

Pinging 2001:5c0:8fff:fffe::44b9
from 2001:5c0:8fff:fffe::44b7 with 32 bytes of data:

Reply from 2001:5c0:8fff:fffe::44b9: bytes=32 time=340ms
Reply from 2001:5c0:8fff:fffe::44b9: bytes=32 time=372ms
Reply from 2001:5c0:8fff:fffe::44b9: bytes=32 time=315ms
Reply from 2001:5c0:8fff:fffe::44b9: bytes=32 time=340ms

Ping statistics for 2001:5c0:8fff:fffe::44b9:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 315ms, Maximum = 372ms, Average = 341ms
Obr. 7 Testovanie prechodu ping žiadosti IPv4 firewallom

Týmito príkazmi sme si overili, že komunikácia v rámci siete nášho brokera je bezproblémová. Našim cieľom ale nie je komunikovať iba v rámci jednej siete, ale v rámci viacerých sietí. Preto sme sa rozhodli preskúmať cesty k cieľu, ktorý je pripojený v inej IPv6 sieti ako je náš broker. Vybrali sme si brazílsky segment 6bone siete. Cestu sme preskúmali príkazom tracert6. Výsledok testu zobrazuje obr. 8.


C:\Documents and Settings\Petko>tracert6 www.6bone.rnp.br

Tracing route to virgo.6bone.rnp.br [3ffe:2b00:1:101:204:acff:fee6:50b1]
from 2001:5c0:8fff:fffe::44b7 over a maximum of 30 hops:

1 * 129 ms 285 ms 2001:5c0:8fff:fffe::44b6
2 283 ms 190 ms 259 ms 2001:5c0:0:5::114
3 393 ms * 417 ms if-5-0-1.6bb1.MTT-Montreal.ipv6.teleglobe.net
[2001:5a0:300::5]
4 323 ms * 296 ms gin-ad1-6bb1.ipv6.teleglobe.net [2001:5a0:200
::1]
5 267 ms 386 ms 347 ms eth10-0-0.xr1.ams1.gblx.net [2001:7f8:1::a500
:3549:1]
6 491 ms * 448 ms 2001:12f0:1:2011::1
7 548 ms * 570 ms 2001:12f0:1:2011::1
8 471 ms 555 ms * 2001:450:1:1::26
9 568 ms 695 ms 637 ms 2001:12f0:1:2011::2
10 578 ms 629 ms 626 ms 2001:12f0:0:fe::e1
11 695 ms 689 ms * 3ffe:2b00:500:2::1
12 719 ms 850 ms 675 ms 3ffe:2b00:1:101:204:acff:fee6:50b1

Trace complete.

Obr. 8 Testovanie trasy do inej IPv6 siete

3.5 Služby servera
Na FreeBSD sme sa rozhodli spustiť IPv6 služby. Ako prvú službu, ktorú bude server poskytovať je služba siete www. Systém FreeBSD má snáď najlepšie implementované IPv6 služby so všetkých unixových systémov. Ako webový server sme nainštalovali Apache vo verzii 1.3. Výsledok je zobrazený na obr. 9. Stránku sme prezerali v prehliadači Opera 8.51 volaním http://[2001:5c0:8fff:fffe::44b9]


Obr. 9 Webový server Apache dostupný cez sieť IPv6
S inicializáciou TSP klienta sa na serveri spustil démon rtadvd, ktorý umožňuje automatickú konfiguráciu klientov pripojených na vnútorné rozhranie fxp0. Týmto krokom sme pripojili celú učebňu k sieti IPv6.

4 Záver
Podarilo sa nám pripojiť sa k sieti IPv6 prostredníctvom voľne dostupného brokera a spojazdniť na jednom z počítačov služby internetového servera. Naším ďalším cieľom bude požiadať správcu adresného priestoru o pridelenie určitého rozsahu adries, ktoré budú použité pre jednotlivé koncové uzly. Ďalším cieľom bude spustenie väčšieho počtu internetových služieb, napríklad elektronickej pošty, systému DNS, webového servera, FTP servera a ďalších. Najväčším cieľom bude vytvoriť natívne, nie tunelované pripojenie do IPv6 siete.

5 Literatúra
Cerf V., Dala Y., Sunshine C. 1974. Specification of Internet Transmission Control Program. 1974. RFC 675
Deering S., Hinden R. 1998. Internet Protocol, Version 6 (IPv6) Specification. 1998. RFC 2460
Huitema, C. 1997. IPv6: The New Internet Protocol, (Second edition). Prentice Hall, 1997. ISBN 0138505055.
Miller, P.E., Miller M. A. 2000. Implementing IPv6: Supporting the Next Generation Internet Protocols, Faster City: IDG Books Worldwide, ISBN: 0764545892
Postel J. 1981. Internet Protocol. 1981. RFC 791
Rekhter Y., Moskowitz B., Karrenberg D., de Groot G., 1994. Address Allocation for Private Internets. 1994. RFC 1597

Zdroj:
Švec, Peter: Ako integrovať IPv6 do laboratórnej siete.
In: VII. vedecká konferencia doktorandov a mladých vedeckých pracovníkov. - Nitra: UKF, 2006. - ISBN 80-8050-960-3. - S. 747-754.