Možnosti tunnel brokeru pro připojení IPv6 sítí přes veřejný IPv4

Možnosti tunnel brokeru pro připojení IPv6 sítí přes veřejný IPv4 Bc. David Vašíček Bc Tarek Batiha

Abstrakt: Tento dokument popisuje připojení připojení k IPv6 veřejnému internetu přes stávající IPv4 sít pomocí technologie tunnel broker. Otestovány byly tunnel brokery firem Hurricane, Freenet6, Teredo a Sixxis. Klíčová slova: Tunnel Broker, Gogo6, IPv4, Ipv6 1 Úvod.................................................................................................................................................2 2 Teoretický rozbor..............................................................................................................................2 2.1 IPv4............................................................................................................................................2 2.2 IPv6............................................................................................................................................3 2.3 Tunnel Broker............................................................................................................................3 3 Tunnel Broker...................................................................................................................................3 3.1 Huricane Electric.......................................................................................................................3 3.1.1 Protocol 41.........................................................................................................................5 3.2 Sixxs..........................................................................................................................................6 3.2.1 AYIYA................................................................................................................................6 3.3 Freenet / Gogo6.........................................................................................................................7 3.3.1 TSP.....................................................................................................................................7 3.3.2 gogoCLIENT.....................................................................................................................7 3.4 Teredo........................................................................................................................................9 4 Použitá literatura a citace..................................................................................................................9 4.1 Otestování připojení k IPv6.......................................................................................................9 4.1.1 Test-IPv6..........................................................................................................................10 4.1.2 IPv6-Test..........................................................................................................................10 4.1.3 Test serveru kame.............................................................................................................10 4.1.4 Test na stránkách Google.................................................................................................10 4.2 Statistika pingů pomoci programu RRDtool...........................................................................10 4.3 Test rychlosti připojení na stránkách IPv6-Test.com...............................................................12 5 Závěr...............................................................................................................................................15 6 Použitá literatura.............................................................................................................................15

prosinec 2014

1/16

1

Úvod

Tento projekt je semestrálním projektem do předmětu Technologie počítačových sítí vyučovaného na fakultě elektrotechniky a informatiky na Vysoké škole báňské - Technické univerzitě v Ostravě v druhém ročníku zimního semestru navazujícího magisterského studia. Tento projekt se zabývá vytvářením tunel brokerů pro připojení IPv6 sítí přes veřejný IPv4 Internet. První kapitola s názvem Teoretický rozbor se zabývá otázkou co vlastně IPv4 a IPv6 je a také proč je potřeba tunnel brokery vytvářet. V druhé kapitole tunnel broker se dozvíme, co vlastně tunnel broker je a jaké tunnel brokery může běžný uživatel využít. V této kapitole budou popsány pouze takové tunnely brokery, které budou odzkoušeny, a ke každému takovému tunelu bude popsáno, jak vlastně funguje, popřípadě, jak takový tunel vytvořit. Největší zájem by mněl být projeven u tunnel brokeru od společnosti Huricane Electric. Další část tohoto projektu byla věnována testování připojení IPv6, jak ověřen že IPv6 funguje a také jaké přínosy tunnel broker na IPv6 má. V první části této kapitoly se budeme věnovat webům, které ověřují a testují IPv6 připojení a ověří její funkčnost. Další část tohoto bodu se bude věnovat statistice pingů pomoci OpenSource nástroje RRDtool, který vykresli grafy pingů pro jednotlivé servery, které jsou ukázány v dané kapitole. Poslední části této kapitoly je testování internetového připojení a to za pomocí testu, který je uveden v první části této kapitoly. Tento test nám také ukáže srovnání internetového připojení mezi IPv4 a Ipv6.Pokud budou tyto jednotlivé testy přínosem, se dozvíme již v poslední kapitole s názvem Závěr. Jak již bylo zmíněno v předchozím odstavci, poslední kapitolou je kapitola závěr. Táto kapitola shrnuje veškeré výsledky z jednotlivých kapitol a také vysvětluje, jak a proč jsme k daným výsledkům došli. Tato kapitola také vysvětluje, proč jsme v některých části tohoto projektu neuspěli a co byla jejich přesná, či prav děpodobná příčina.

2

Teoretický rozbor

Táto kapitola se věnuje teorii, která čtenáře přibližuje k pochopení dané problematiky a vysvětluje problematiku daného semestrálního projektu.

2.1

IPv4

IPv4 je čtvrtá verze datově orientovaného internetového protokolu, který je využíván v sítích s přepo jováním paketů. Tento protokol je popsána IETF v RFC 791 (září 1981), které nahradilo RFC 760 (leden 1980) a je standardizována jako MIL-STD-1777 Ministerstvem obrany USA IPv4 adresa se skládá z celkem 4 oktetů, kde každý oktet je v rozsahu od 0 do 255, tudíž 8 bitů. Jednot livé oktety jsou následně odděleny desetinou tečkou tzv. quad-dotted formát. Tímto jsme dospěli k závěru, že adresa v IPv4 obsahuje celkově 32 bitů. Tímto ovšem máme omezený adresní prostor, který nám teoreticky umožňuje 232 adres. To je přesně 4 294 967 296 možných adres, ale prakticky je to však mnohem méně, protože adresy jsou sdružovány kvůli snadnějšímu směrování do podsítí. Příklad adresy IPv4 je zobrazený na obrázku 1.

Obrázek 1 IPv4 adresa Rok od roku se počet jednotlivých adres snižoval z důvodu nárůstu jejich spotřeby a to zejména díky novým moderním technologiím, jako jsou notebooky, mobilní telefony, ale především rychle rostoucí nárůst počtu uživatelů internetu, než dne 3.2.2011 došlo k jejich úplnému vyčerpání. To se stalo na konferenci v Miami, kde bylo rozděleno posledních 5 bloků adres. Tato událost se stala z nejvýznamnější události historie Internetu. Internetoví provideři mohou sice ještě nějakou dobu žít z vlastních zásob, ale jednou stejně budou muset vyřešit tento problém s vyčerpáním. Hrozba vyčerpání byla motivací pro řešení tohoto problému, než na konec byla vytvořena IPv6, která na bízí k dispozici mnohem více adres. prosinec 2014

2/16

2.2

IPv6

IPv6 je internetový protokol verze 6, který nahrazuje dosluhující protokol IPv4. IPv6 přináší zejména masivní rozšíření adresního prostoru a také zdokonalení schopnosti vysokorychlostního přenosu dat. IPv6 používá 128-bitovou adresu, která se skládá z celkem dvou částí: (pod)síťový prefix (64 bitů) a část hosta (64 bitů). Ty mohou být vytvářeny automaticky, na základě MAC adresy nebo manuálně přiřazovány. Adresa IPv6 je reprezentována jako osm skupin po čtyřech hexadecimálních číslic od sebe odděleny dvojtečkou a takový příklad adresy můžeme vidět na obrázku 2.

Obrázek 2 IPv6 adresa Díky 128 bitové adresy můžeme vytvořit 2128 adres, což je přesně 340 282 366 920 938 463 463 374 607 431 768 211 456 možných adres. Oproti 32 bitové adrese IPv4 je to opravdu obrovský nárůst, díky kterému odpadá otázka potencionálního vyčerpání adresního prostoru. Díky tomuto masivního nárůstu adres také odpadá potřeba překladu síťových adres a jiných postupů porušujících přirozenost internetových přenosů, jako komunikace mezi dvěma koncovými body. IPv6 protokol není navržen tak, aby byl interoperabilní s protokolem IPv4, neboli IPv6 není schopen vzájemně spolupracovat, poskytovat si služby a dosáhnout vzájemné součinnosti s IPv4. Je to způsobeno od lišnosti hlaviček jednotlivých protokolů a to komplikuje přechod na IPv6. Proto bylo nutné navrhnou IPv6 přechodové mechanismy, které umožňují usnadnění přechodu mezi těmito dvěma protokoly.

2.3

Tunnel Broker

Tunel broker je služba, která uživateli připojenému k IPv4 síti umožňuje připojení k IPv6 síti, pokud jeho poskytovatel internetu IPv6 připojení nepodporuje. Doporučení, jak by měl byt Tunnel Boker vypadat po technické stránce je popsáno v dokumentu RFC:3053. Není to přesný popis parametrů, ale pouze doporučení jak by měla tato služba vypadat a jaké by měla obsahovat prvky. Funkce je znázorněna na obrázku 3.

Obrázek 3 Tunnel Broker

3

Tunnel Broker

Tunnel Broker je služba, která uživateli poskytuje síťový tunel na IPv6 přes IPv4. V této kapitole si popíšeme některé tyto služby, u kterých si můžou uživatelé požádat o vytvoření tunelu. U každé služby si popíšeme, jak daný tunel funguje, které protokoly používá a jak si tunel vyžádat. V tomto projektu jsme otestovali jen pár tunelů, ze kterých si následně vybereme jeden a v samostatné kapitole se mu budeme podrobněji věnovat.

3.1

Huricane Electric

Huricane Electric je největší poskytovatel IPV6 internetu na světě a také globální poskytovatel internetu IPv4, jehož sídlo je ve Fremontu, v Kalifornii. Huricane Electric nabízí IPv6 Tunnel Broker přes 6in4 pře chodové mechanismy, který si uživatel může vytvořit zdarma na stránkách společnosti. prosinec 2014

3/16

Jak již bylo zmiňováno, uživatel si může tunel vyžádat na stránkách společnosti Huricane Electric. Než takto ale učiní, musí první provést registraci do jejich systému. Registraci provedete na stránkách https://tunnelbroker.net/register.php, kde řádně vyplní formulář, dle pravdivých informací a potvrdí souhlas o podmínkách užití. Pokud uživatel řádně vyplnil formulář, především vyžádané informace, systém uživatele řádně registruje do své databáze a uživateli zašle na jeho uvedený e-mail zprávu s žádosti o potvrzení a dokončení registrace a také s heslem, kterým se uživatel do systému může přihlásit. Pokud je uživatel přihlášen, může začít vytvářet tunely. Těch může vytvořit celkově pět. To provede tak, že v levé části stránky v kategorii “User Functions“ rozklikne “Create Regular Tunnel“, čímž se mu otevře nové okno, kde si právě tunel může vytvořit. Co uživatel potřebuje, je jeho veřejné adresa, kterou následně zadá do kolonky “ IPv4 Endpoint“. Tu může vidět pod polem, do kterého se adresa zadává, popřípadě může navštívit stránky např. http://www.whatismyip.com/. Po zadání IPv4 veřejné adresy proběhne ověření, zda lze na danou adresu tunel vytvořit, nebo ne. Podmínkou je, aby se Huricane Electric dokázala na uživate lovou adresu pingnout. Pokud tomu tak nebude, Bude uživatele systém informovat zprávou, ve které říká, že adresu nejde pingnout a u poskytovatele si uživatel musí vyžádat povolení ICMP zpráv na adresu 66.220.2.74, aby to firewall nadále neblokoval. Tato zpráva se nejčastěji objevuje, pokud uživatel nemá u po skytovatele svou vlastní veřejnou adresu a v takovém případě bývá jednání se svým poskytovatelem dosti obtížné. Pokud ovšem vytvoření tunelu nic nebrání, tunel může být vytvořen. Tímto můžeme říct, že Huri cane Electric vytvoří tunel na každou adresu, na kterou se dokáže pingnout. V poslední řadě vytváření tohoto tunelu musí uživatel zadat město, ve kterém se nachází server. Poté uživatel může vytvořit tunel stiskem tlačítkem “Create Tunnel“ Pokud uživatel tunel vytvoří, přesměruje systém uživatele na novou stránku, kde jsou v souhrnu informace o jeho právě vytvořeném tunelu. Tyto informace jsou uvedeny v záložce “IPv6 Tunnel“. Pro nás je však nejdůležitější záložka “Example Configuration“, kde si uživatel vybere typ operačního systému, na kterém bude tunel realizovat, na základě čehož mu systém vygeneruje konfiguraci pro nové rozhraní síťové karty, na kterém bude tunel fungovat. Pokud tedy uživatel má vygenerovanou konfiguraci, nezbývá nic jiného, než tuto konfiguraci překopírovat dle návodu, který systém ukáže nad vygenerovanou konfigurací. Buďto uživatel danou konfiguraci překopíruje přímo do terminálu, nebo je potřeba danou konfiguraci překopírovat do konfiguračního souboru, je hož cestu systém ukáže.

Obrázek 4 Konfigurace rozhraní Nyní uživateli nebrání nic, než tunel vyzkoušet. To může provést například příkazem ping IPv6 server, nebo zadat přímo do internetového prohlížeče adresu IPv6 serveru např. ipv6.google.com Pokud IPv6 nebude fungovat, bude chyba na straně poskytovatele. Jak již jsme si řekli, Huricane Electric využívá 6in4 přechodové mechanismy, které používají na propojení mezi jednotlivými sítěmi protokol 41. Ten však ve většině případů není u poskytovatelů povolován a firewall jej nepropustí.

prosinec 2014

4/16

Obrázek 5 Informace o vytvořeném tunelu u společnosti Huricane Electric

Na obrázku 6 je ukázka z již vytvořeného tunelu. V tomto scénáři byl vytvořen tunel na hraniční router poskytovatele, a použita konfigurace jako na Obr 6. Pak byl v programu Wireshark použit filtr proto 41.

Obrázek 6 Ukázka vytvořeného tunelu v programu Wireshark

Jak je vidět, tak nepřichází odpověď na příkaz ping6, v tomto případě www.google.com. Můžeme vidět, že paket obsahuje v hlavičce informace jak o protokolu IPv4 - source, destination, tak IPv6 se stejnými infor macemi. Na obrázku 7 můžeme vidět hlavičku paketu, tak, jak je definována v RFC:3056

Obrázek 7 Hlavička paketu, tak, jak je definována v RFC:3056

3.1.1

Protocol 41

Tunnel broker Hurricane Electric využívá k tunelování protokol 41. Jedná se o IPv4 protokol. Pomocí tohoto protokolu jsou zapouzdřeny pakety s IPv4 a IPv6 hlavičkou na transportní vrstvě. O tomto protokolu je zmínka v RFC:3056 a RFC:2893. V RFC:3056 je zmínka o tom, že protokol 41 nemá problém s NAT nebo firewallem na hraničním routeru. U NAT ale pouze, pokud je zařízení připojeno k nejvnějšnějšímu NAT, tj. je jenom za jedním NAT hopem od globální sítě. Pokud je zařízení za více NAT, tak zařízení musí používat adresy odvozené z 2002: prefixu zkonstruovaného z globálních IPv4 adres z nejvnějšnějšího NATu. Toto chování činilo problémy v tomto projektu. Na obrázku 8 vidíme dekapsulaci z IPV4 packetu do IPv6, jak je popsána v RFC:2893 prosinec 2014

5/16

Obrázek 8 Dekapsulace z IPv4 do IPv6

3.2

Sixxs

Protože tunnel broker Hurricane Electric nebylo možné díky používání protokolu otestovat, bylo nutné se poohlédnou po jiných alternativách. Jak ideální kandidát se zdál tunnel broker Sixxs. Jednak proto, že je na mnohých fórech doporučován jako alternativa pro uživatele, kteří mají problémy s nepropustností protokolu 41 přes NAT. Toto je dáno tím, že Sixxs je možné provozovat jak s protokolem 41, tak je možné provozovat tento tunnel broker s tunelovacím protokolem AYIYA. Další dobrou zprávou pro uživatele, jejichž ISP nepodporuje IPv6 je, že je možné si prohlížet weby běžící pouze na IPv6. Tato služba se jmenuje Website Gateway/Proxy. Toto je umožněno použitím přidáním k jakékoliv IPv6 adrese textový řetězec “.sixxs“. Tj. například www.ipv6web.com.sixxs. Nevýhoda tohoto řešení je, že funguje pouze pro nešifrována spojení. Což je užitečnější, tuto funkci lze aplikovat i opačně, tj. z IPv6 sítě se připojit na IPv4 web servery např. http://www.ipv6.org.ipv4.sixxs.org, ale opět se stejným omezením ohledně šifrování, tedy pouze HTTP/1.1 a port 80. Toto omezení je pochopitelné, protože by asi bylo třeba použití SSL proxy, což by celý proces šifrování učinilo zbytečným. Jak se ale ukázalo, tunnel broker má velice zajímavé podmínky použití. Protože pro vytvoření tunelu, nebo instalace klienta aiccu je nutné být registrován na webových stránkách www.sixxs.net. Bohužel ani jednomu z autorů tohoto projektu nebyla registrace akceptována a to z důvodu neuvedení pravdivých infor mací, přestože bylo uvedeno vše pravdivě, včetně tel. čísla. Toto je velice zajímavé hlavně proto, že se, alespoň podle webu žádosti o registraci akceptují manuálně, tj. asi autory znají lépe, než oni sami.

3.2.1

AYIYA

Anything In Anything (AYIYA) je tunelovací protokol, který je nezávislý na transportním protokolu. Řeší to problémy protokolu 41, které má s NAT.

Obrázek 9 Protokol AIYA Jak je vidět na obrázku 9, tak protokol AIYA vyžaduje na zařízení klienta. Přímo v repositářích distribuce debian a jeho derivátů se nachází balík aiccu, který je právě klientem tunnel brokeru Sixxs. Protokol pak využívá TCP, UDP nebo SCTP. prosinec 2014 6/16

3.3

Freenet / Gogo6

Protože nebylo dosaženo připojení ani pomoci tunnel brokeru Hurricane Electric ani pomocí brokeru Sixxs, byl otestován další tunnel broker, Freenet6 Tunnel Broker. Tento tunnel broker pracuje na protokolu TSP a proto by neměl být problém s NATem. Další výhodou tohoto řešení připojení do IPv6 sítě je, že funguje v anonymním módu, takže odpadají problémy s instalací, potažmo registrací a je možné jej použít jako dočasné řešení prakticky out of the box. Přestože má tato služba v názvu free, tak to není úplně přesné označení. Po registraci má uživatel možnost stažení klienta, a to buďto pro Windows, nebo Linux ve formě zdrojových kódů. V tomto momentě, kdy má uživatel nainstalovaného klienta, může IPv6 internet využívat naplno. Omezení v tomto případě je to, že se jedná o anonymní připojení, takže se může stát, že se například v průběhu dne změní IP adresa. Za další si uživatel nemůže zažádat o rozsah adres, například k připojení své menší sítě k IPv6, protože v IPv6 rozsahu technologie jako NAT není, a v blízké budoucnosti nebude potřeba. Nyní se dostáváme ke slovu free, protože za jednorázový poplatek 10 USD je možné tuto službu využívat naplno. Pro účely tohoto projektu se autoři rozhodli neinvestovat své dlouhodobě šetřené úspory do technologie, která je podle příslušného RFC jen dočasným řešením, než ISP přejdou na IPv6, která existuje docela dlouho. Po bezplatné registraci uživatel získá přístup do sítě gogo6, což je podle webu gogo6.com komunita s více než 100 000 členy, sdružující se okolo technologie IPv6. Na Ubuntu, potažmo Debianu a jeho derivátech se dá gogoc klient stáhnout a nainstalovat plně funkční řešení pouze příkazem sudo apt-get install gogoc. V tomto momentu by měl být stroj plně schopen komunikace s IPv6 sítí, ale můžou nastat jakékoliv problémy, ať už s konfigurací, nebo s přetížeností konkrétního serveru.

3.3.1

TSP

Tunnel Setup Protocol je síťový protokol k nastavení parametrů IP tunelu mezi klientem a tunnel broker serverem. Tento protokol je definován v RFC:5572

Obrázek 10 TSP protokol aplikovaný v tunnel broker modelu

Na obrázku 10 vidíme TSP protokol aplikovaný v tunnel broker modelu. TSP session se skládá ze zá kladní výměny XML dat a to za použití protokolu UDP a nebo TCP. Proto NAT není překážkou pro tento protokol.

3.3.2

gogoCLIENT

V tomto protokolu byly otestován Freenet Tunnel Broker pouze v anonymním módu a to z důvodu uvedený dríve v této kapitole, pro zopakování hlavně kvůli jednorázovému poplatku nutnému k plnému využití služby. prosinec 2014 7/16

Konfigurace zde popsané jsou všechny prováděny v OS Linux, konkrétně Gubuntu 14.04.1 LTS. Konfigurační soubor se nachází v /etc/gogoc/gogoc.conf. Možnosti konfigurace pro anonymní mód jsou omezeny jen na výběr serveru, nezadává se uživatelské jméno ani heslo. Počet serverů není nijak oslnivý, autorům tooto projektu se podařilo nalézt pouze čtyři a podle různých fór jich ani více nebude. Kompletní se znam je pravdě podobně dostupný platícím uživatelům. Nalezené servery jsou anon-amsterdam.freenet6.nl, anon-montreal.freenet6.net, anon-taipei.freenet6.net, anon-sydney.freenet6.net. Anon před názvem serveru znamená, že se jedná o anonymní server. Další nastavi telné parametry jsou keepalive interval, tunel mode, rozhraní na kterém bude pracovat aj. Asi nejzajmavjější je typ host|router, kde se dá nastavit stanice jakou router který má přidělený IPv6/56 rozsah, ale to je funkce jen pro platící uživatele. Po spuštění se vytvoří virtuální tunelovací rozhraní, přes které jde veškerý IPv6 provoz je vidět na obrázku 11.

Obrázek 11 virtuální tunelovací rozhraní Dále se nastaví příslušné cesty pro IPv6 provoz na vytvořeném rozhraní jak je vidět na obrázku 12.

Obrázek 12 Nastavení příslušné cesty pro IPv6 provoz Na obrázku 13 vidíme příchozí SSH spojení z IPv6 sítě. Adresa 2001:5c0:1400:a::b27 je adresa SSH serveru na který se připojuje klient. Adresa 81.171.72.12 je pak adresa tunnel brokeru, na který se připojuje gogoc pomocí protokolu UDP, jak lze vyčíst z obrázku.

Obrázek 13 Příchozí SSH spojení z IPv6 sítě

prosinec 2014

8/16

3.4

Teredo

Protože Freenet6 tunnel broker má pro uživatele v České Republic poměrně vzdálené servery, hledali autoři této práce nějakou další možnost IPv6 tunelování. Samozřejmě bylo hledáno řešení, které nevyužívá protokol 41 a to z důvodů zmíněných v kapitole 3.1.1. Teredo je dalším z automatických tunelovacích mechanismů, které se snaží zprostředkovat IPv6 komu nikaci jednotlivým strojům, které se nacházejí uprostřed IPv4 sítě (podobně jako například ISATAP). Jeho síla spočívá především v tom, že dokáže do značné míry procházet NATy a je proto vhodný například pro domácí sítě, které dnes obvykle bývají za NATem. Platí za to nízkou efektivitou. Teredo používá komplikovaný formát adres, jež obsahují několik informací ze světa IPv4. Začínají konstantním prefixem 2001::/32, za nímž následuje IPv4 adresa Teredo serveru, který adresu přidělil. První polovinu adresy tedy určuje server. Identifikátor rozhraní začíná příznaky o délce 16 bitů. Kromě obvyklých příznaků U a G společných pro všechny identifikátory přidává příznak C (Cone), který je nastaven, pokud se majitel adresy nachází za trychtýřovým NATem. Následuje 16b číslo UDP portu a 32b IPv4 adresa klientova NATu. Teredo. Teredo - IPv6.cz [online]. [cit. 2014-12-12]. Dostupné z: https://www.ipv6.cz/Teredo Stejně jako v případě Freenet Tunnel Brokeru má Teredo klienta v depozitářích Ubuntu, který se jmenuje miredo. IPv6 síť je přístupná hned po instalaci. Možnou výhodou pro české uživatele je, že sdružení CZ.NIC provozuje server na adrese teredo.nic.cz. Bohužel jméno serveru je jediná položka, kterou uživatel může konfigurovat a to v souboru /rtc/miredo/miredo.conf. Podobně jako aplikace gogoc si miredo vytvoří virtuální rozhraní, jak můžeme vidět na obrázku 14.

Obrázek 14 virtuální rozhraní teredo Velká nevýhoda tereda je časá změna adres během spojení. Na obrázku 15 je ukázka připojeného klienta během cca 20 minut. Jak můžeme vypozorovat, tak během této doby byla třikrát změněna ip adresa.

Obrázek 15 Připojení klienta Zajímavá situace nastala, když byl pokus o ping mezi dvěma hosty připojenými přes teredo tunel. Oba dva se dopingli na www.google.com, ale ping mezi sebou se nepodařil, chybová hláška byla network unreachable. Ukazuje to nevhodnost tohoto tunelu i k jednoduchým úkonům.

4

Použitá literatura a citace

4.1

Otestování připojení k IPv6

V této podkapitole se budeme chvíli věnovat, jak připojení IPv6 ověřit. K tomu slouží jak specializované weby, tak i jednodušší amatérské, ale také jednoduché odzkoušení na IPv6 serverech. prosinec 2014 9/16

4.1.1

Test-IPv6

Tento test provádí několik testů na IPv4 a IPv6 připojení, které pak ohodnotí body. V tomto Testu je nej důležitější IPv6 připojení. Pokud jej nemáte, dostáváte automaticky 0/10 bodů. Pokud ovšem IPv6 připojení máte, můžete začít získávat skutečně body z jednotlivých testů, které byly provedeny. Jednotlivé testy jsou: • • • • • • • • • •

Test s IPv4 DNS záznamem Test s IPv6 DNS záznamem Test s dual stack DNS záznamem Test s dual stack DNS záznamem a velkým IPv6 paketem Test IPv4 bez DNS Test IPv6 bez DNS Test velkých IPv6 paketů Test zda DNS server vašeho ISP používá IPv6 Find IPv4 Service Provider Find IPv6 Service Provider

tento test můžete nalézt na stránkách http://www.test-ipv6.cz/

4.1.2

IPv6-Test

Tento test se odvážím nazvat asi nejlepším testem ze všech testů na připojení IPv6 se kterými jsem pracoval. Tento test Uživateli nabídne informace o IPv4 konektivitě kde najde informace o stavu připojení, adre se, hosname a ISP, IPv6 konektivitu kde jsou zase uvedeny informace např. o stavu připojení, adrese, typu připojení, ICMP, hosname, ISP. To ale samozřejmě není vše, co tento test umí. Test je schopen nabídnou i informace o DNS a také, jako předchozí test na adrese http://www.test-ipv6.cz/ vás umí test ohodnotit body, které jste v testu získal. V tomto testu je maximální počet budu 20. V poslední řadě jsou zde i testy pingů a testy rychlosti a srovnání IPv4 a IPv6. Tímto se však budeme zabývat v kapitole 4.3. Tento test můžete nalézt na stránkách http://ipv6-test.com/

4.1.3

Test serveru kame

Tento test je velmi jednoduchý. I přes to, že tento test neumí ani z daleko to, co test předchozí, je zde uveden z toho důvodu, že se zdá být docela zábavný. Po spuštění serveru kame se zobrazí webová stránka s obrázkem kreslené želvičky v horní části stránky. Pokud uživatel na danou stránku přišel skrz IPv6 připojení, želvička se začne hýbat a simulovat plavání. Pokud ale uživatel přijde skrz IPv4, obrázek želvičky je statický a želvička nic nedělá. Tento test můžete najít na stránkách http://www.kame.net/

4.1.4

Test na stránkách Google

Jedná se asi o nejjednodušší případ, jak otestovat připojení IPv6. Není na tom nic složitého. Stačí jednoduše do internetového prohlížeče zadat URL adresu www.ipv6.google.com a buď daný server funguje, nebo ne. Pokud jede, máte jistotu, že připojení na IPv6 máte. Tento test můžete najít na stránkách http://www.ipv6.google.com/

4.2

Statistika pingů pomoci programu RRDtool

RRDtool je OpenSource program, který slouží pro sběr, zpracování a vykreslení časově závislých dat. RRDtool je zkratka pro Round Robin Database Tool, z čehož vyplývá, že data uložené v databázi jsou typu Round Robin. K vytvoření takové databáze slouží celkem tři základní kroky. Prvně musí uživatel vytvořit prázdnou databázi pomoci rrdtool create. Do takto vytvořené databáze, může následně uživatel postupně přidávat sbírána data, která provádí funkce rrdtool update a v poslední řadě zbývá postupně vytvářet grafy pro jednotlivá nasbírána data. Tyto grafy se vytvářejí pomocí rrdtool graph. Funkci rrdtool create nebudeme zde věnovat příliš velké pozornosti a to z takového důvodu, že jednotlivé tyto funkce se v mnoha případech od sebe neliší. V našem případě se budeme spíše zabývat funkcí rrdtool update, která je nejdůležitější funkcí těchto tří částí. Jak již bylo zmíněno, jedná se o funkci vkládání dat do databáze. Pro naše testování vkládáme do databáze průměrnou dobu zasílání IP datagramu na námi vybrané servery, které můžete vidět v jednotlivých grafech. Jinak řečeno, jako data používáme průměrnou dobu pingů na tyto jednotlivé servery. Tyto data jsou vkládána do databáze každou minutu. To je prováděno tak, že skript prosinec 2014 10/16

s funkcí rrdtool update je každou minutu spouštěn na pozadí v programu Cron. Poslední částí je funkce rrd tool graph, jejíž hlavním úkolem je na základě vložených dat v databázi vytvořit jednotlivé grafy. Tyto grafy lze různě modifikovat a uživatel si s nimi může dosti vyhrát. Jednotlivé grafy zobrazují statistiku pingů na serverech www.google.com a www.seznam.cz v IPv4 i IPv6 síti. za posledních 5 minut, 15 minut, 30 minut a 60 minut, co byly data do databáze vloženy. Na těchto grafech tvoří osu X čas, ve kterém byl ping proveden, a osu Y dobu průměrné odezvy pingů v ms. V grafech také můžeme vidět číselné údaje jednotlivých pingů pro jednotlivé servery a to především nejmenší dobu odezvy, nejvyšší dobu odezvy, průměrnou dobu odezvy a poslední dobu odezvy, která byla do databáze vložena. Jednotlivé grafy můžeme vidět pod tímto odstavcem, pojmenovány Graf 1 až Graf 4.

Graf 1: Statistika pingu během 5 minut

Graf 2: Statistika pingu během 15 minut

prosinec 2014

11/16

Graf 3: Statistika pingu během 30 minut

Graf 4: Statistika pingu během 60 minut Z grafu můžeme vyčíst, že doba odezvy pingu u IPv6 je mnohem vyšší, než u IPv4. V případě serveru Google.com má IPv6 server cca 1,5x větší dobu odezvy než IPv4, ale u serveru Seznamu.cz je už to cca 5x více. U grafu č. 4, si můžeme také všimnout rekordní doby odezvy u serveru IPv6 Seznam.cz, která je 255,2 ms. V případě IPv6 Google.com to je potom 185,9 ms. Tyto obrovské rozdíly jsou způsobeny tím, že IPv6 server, ke kterému je tunel připojen, je umístěn v Kanadě. K tomu testování byl použit tunel společnosti go go6.com. Pokud provedeme srovnání jednotlivých časů odezvy od jednotlivých serverů, můžeme přijít na odpověď proč je mezi serverem Google.com a serverem Seznam.cz tak značný rozdíl. Server Seznam IPv4 se připojuje rovnou na český server přes svého poskytovatele, kdežto Seznam IPv6 se připojuje na český server skrze server v Kanadě. Tím pádem IP datagram musí urazit výrazně rozdílnou trasu, na které se poté pěti násobek doby odezvy projeví. Co se týče Google.com, Tak mezi IPv4 a IPv6 není tak značný rozdíl a to z toho důvodu, že server Google se nachází téměř v totožné lokalitě jako server v Kanadě, přes který se se vede tunel. Proto mezi IPv4 a IPv6 je rozdíl asi jeden a půl násobek.

4.3

Test rychlosti připojení na stránkách IPv6-Test.com

Co umí tento test jsme si již mohli přečíst v kapitole 4.1.2 . Nyní se ale budeme chvíli věnovat testování rychlosti připojení a rozdílu mezi IPv4 a IPv6. V pravém dolním rohu na stránkách http://ipv6-test.com/ mů prosinec 2014

12/16

žeme najít odstavec s nápisem ”More”, kde můžeme vidět dva typy testů. Speed test a Ping test. V našem případě si vybereme Speed test, kterým následně test rychlosti provedeme. Po kliknutí na daný test rychlosti se objeví nová stránka, kde si uživatele může vybrat několik testovacích serverů, které se nachází v několika částech celého světa. Jedná se o Portsmouth - Velká Británie, Alaska Spojené státy americké, Roubaix - Francie, Lyon - Francie, Zeeland - Nizozemsko, Rumunsko, PR - Brazílie. Pro naše testování jsme si vybrali pár těchto serveru, na kterých jsme následně měřili rychlost připojení a ve kterých zemích tyto servrery leží, bude napsáno u každého grafu, který znázorňuje tuto rychlost připojení. Pokud uživatel žádný server nevybere, bude automaticky měřit na serveru, který je v seznamu v prvním pořadí. Jedná se o server na Alasce, u kterého se píše, že test je umožněn pouze uživatelům Alasky. Proto je nezbytné, aby uživatel vybral jiný server ze seznamu. Následně nezbývá nic jiného než spustit samotný test, Ten se spustí tlačítkem v pravé části stránky s názvem ”Start Speed Test” Po spuštění tohoto testu začne samotné měření IPv4 připojení u vašeho poskytovatele a IPv6 na serveru, který uživatel vybral. Po skončení testu se automaticky vytvoří graf se srovnáním IPv4 a IPv6 rychlosti. Takové grafy můžeme vidět na Grafu 5 až Graf 8, kde každý graf vždy doprovází obrázek umístěny před daným grafem. Jedná se o obrázky 16 – 18.

Obrázek 16 Test internetového připojení se serverem ve Francii

Graf 5: Test internetového připojení se serverem ve Francii

prosinec 2014

13/16

Obrázek 17 Test internetového připojení se serverem v Nizozemí

Graf 6: Test internetového připojení se serverem v Nizozemí

Obrázek 18 Test internetového připojení se serverem ve Velké Británii

prosinec 2014

14/16

Graf 7: Test internetového připojení se serverem ve Velké Británii Z jednotlivých obrázků a grafů, můžeme vidět, jak značně Tunnel broker dokáže ovlivnit i přenosovou rychlost a ne jen dobu odezvy pingu. Tunnel Broker zmenšuje přenosovou rychlost cca na polovinu rychlosti, která byla naměřena přímo u poskytovatele IPv4 internetu. Také můžeme zpozorovat rozdílné přenosové rychlosti pro různé lokality, které jsou uvedeny vždy v levém horním rohu obrázku.

5

Závěr

Tato kapitola se věnuje shrnutí veškerých výsledků jednotlivých kapitol a podkapitol, funkčnosti či nefunkčnosti jednotlivých tunelů, přínosu tohoto semestrální projektu a jiným problémům řešeným v této práci. První kapitola se věnovala teoretickému rozboru, a proto není nijak potřebné tuto kapitolu rekapitulovat a proto můžeme přejít ke kapitole další. Tato další kapitola nese název Tunnel Broker a věnovala se různým tu nelům, které běžný uživatel může využít. Věnovali jsme se zde pouze takovým tunelům, které jsme vlastnoručně odzkoušeli. Jak již bylo dříve zmíněno, největší zájem jsme projevili o tunnel broker od společnosti Huricane Electric, kterému jsme věnovali nejvíce času a který byl pojat formou jakéhosi tutoriálu, jak takovýto tunnel získat. Tento tunel byl testován u pěti různých internetových poskytovatelů a na různých operačních systémech. U prvního Internetového poskytovatele bohužel neprošla firewallem základní ICMP zpráva a proto nebylo možné dále s tímto poskytovatelem pracovat. Proto byli dále už vybírání jen takoví po skytovatelé, u kterých zprávy ICMP přes firewall prošly. Jednalo se asi o půlku z odzkoušených poskytovate lů, jejiž výsledkem bylo právě těchto 5 zmíněných dále testovaných poskytovatelů. U dvou poskytovatelů byl tunel testován pouze na operačním systému Windows 7, u dvou poskytovatelů na systému Windows 7 a Ubuntu 14.04. a u jednoho pouze na Ubuntu 14.04. Bohužel žádný z těchto poskytovatelů internetu nepovoluje skrz firewall protokol 41, proto nebylo možné daný tunel vytvořit Další tunnel broker, který byl testován, byl tunnel broker sixxs. Tento tunel se nám také nepodařilo vytvo řit. Naše práce s tímto serverem zakončila ve chvíli, kdy server odmítl naší žádost o registraci s tím, že jsme neposkytli pravdivé informace v registračním formuláři. Nedokážeme přesně určit proč naše, celkem dvě žádosti byly odmítnuty. Sixxs registrace probíhají manuálně a ne automaticky jak jsme tomu u registraci zvyklí. Navíc také sixxs ve svém registračním formuláři požaduje minimálně 20 slov o tom jak a proč chcete jejich služby využívat, takže se může nejeden člověk u vyplňování registračního formuláře dosti zapotit. Další tunnel broker byl testován tunel od společnosti gogo6, dříve freenet a také od společnosti teredo, tyto dva tunely se nám podařilo zprovoznit na operačním systému Ubuntu 14.02, nikoli však na operačním systému Windows 7. co se týče gogo6, byl tento tunel na Windows 7 vytvářen pomoci gogoCLIENTA, který byl stažen z oficiálních stránek společnosti a následně nainstalován na počítači. Při pokusu o vytvoření tune lu však nastala chyba, která v logu oznamuje, že při konfiguraci rozhraní nastala chyba. Proto jsme tento tu nel používali na operačním systému Ubuntu 14.04, kde jsme dále s tímto tunelem pracovali a testovali. V další kapitole jsme testovali IPv6 připojení pomoci specializovaných webů a také za pomocí jistých programů a testů. Týkalo se to především testu pingů, které jsme prováděli na výše popsaných serverech a internetovém připojení. Výsledky jednotlivých testů, byly popsány na koncích kapitol, proto není potřeba výsledky těchto testů dále zmiňovat. Tento projekt nám přinesl rozšířený pohled na připojení IPv6 síti přes veřejný IPv4 internet. Měli jsme možnost vyzkoušet si jednotlivé tunnel brokery, a to nejen jak tyto tunely vytvářet, ale také jak přesně pracují. Co se týče testování IPv6, měli jsme možnost podívat se, jak hodně se liší IPv6 připojení od IPv4.

6

Použitá literatura [1] [2]

Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-12-19]. Dostupné z: http://cs.wikipedia.org/wiki/IPv4 Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-12-19]. Dostupné z: http://en.wikipedia.org/wiki/IPv4

prosinec 2014

15/16

[3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]

Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-12-19]. Dostupné z: http://cs.wikipedia.org/wiki/IPv6 Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-12-19]. Dostupné z: http://en.wikipedia.org/wiki/IPv6 Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-12-19]. Dostupné z: http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-12-19]. Dostupné z: http://en.wikipedia.org/wiki/Tunnel_broker Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-12-19]. Dostupné z: http://en.wikipedia.org/wiki/Hurricane_Electric Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-12-19]. Dostupné z: http://cs.wikipedia.org/wiki/RRDTool Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-12-19]. Dostupné z: http://en.wikipedia.org/wiki/Anything_In_Anything Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-12-19]. Dostupné z: http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-12-19]. Dostupné z: http://en.wikipedia.org/wiki/Tunnel_Setup_Protocol [online]. [cit. 2014-12-19]. Dostupné z: http://www.gogo6.com/main [online]. [cit. 2014-12-19]. Dostupné z: http://www.gogo6.com/main [online]. [cit. 2014-12-19]. Dostupné z: http://tools.ietf.org/html/rfc5572 [online]. [cit. 2014-12-19]. Dostupné z: http://www.whatismyip.com/ [online]. [cit. 2014-12-19]. Dostupné z: https://www.ietf.org/rfc/rfc2893.txt [online]. [cit. 2014-12-19]. Dostupné z: http://tools.ietf.org/html/rfc3056 [online]. [cit. 2014-12-19]. Dostupné z: https://www.sixxs.net/ [online]. [cit. 2014-12-19]. Dostupné z: https://tunnelbroker.net/

prosinec 2014

16/16