}w !"#$%&'()+,-./012345
Masarykova univerzita Fakulta informatiky
Přechod IPv4 <-> IPv6 Bakalářská práce
Marek Tlačbaba
Brno, 2012
Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorských dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při práci používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Vedoucí práce: doc. RNDr. Eva Hladká, Ph.D. ii
Poděkování Na tomto místě bych rád poděkoval především paní docentce Hladké za vstřícnost, cenné rady a připomínky při přípravě této práce. Dále děkuji svým rodičům, kteří mě podporují po celou dobu studia.
iii
Shrnutí Cílem práce je ukázat základní vlastnosti protokolu IPv6 a možnosti přechodu od nekompatabilního IPv4 protokolu. Nakonec jsou vybrány 3 možnosti tunelování IPv6 paketů skrz IPv4 síť a ty jsou porovnány v těchto vlastnostech: zpoždění, rozptyl zpoždění, ztrátovost paketů a šířka pásma.
iv
Klíčová slova IPv4, IPv6, přechodové mechanismy, tunelování, SixXS, Freenet6, Teredo.
v
Obsah 1 2
3
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Základní vlastnosti nového protokolu . . . . . . . . . 2.1 Adresy v IPv6 . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Podoba a zápis IPv6 adresy . . . . . . . . . . 2.1.2 Druhy adres . . . . . . . . . . . . . . . . . . . 2.1.3 Typy adres IPv6 . . . . . . . . . . . . . . . . 2.1.4 Struktura adresy . . . . . . . . . . . . . . . . 2.1.5 Přidělování adres . . . . . . . . . . . . . . . . 2.2 Domain Name System (DNS) . . . . . . . . . . . . . 2.2.1 Dopředné dotazy . . . . . . . . . . . . . . . . 2.2.2 Reverzní dotazy . . . . . . . . . . . . . . . . 2.3 Formát datagramu . . . . . . . . . . . . . . . . . . . 2.3.1 Tvar datagramu v IPv6 a rozdíly oproti IPv4 2.3.2 Rozšiřující hlavičky . . . . . . . . . . . . . . . 2.4 Objevování sousedů . . . . . . . . . . . . . . . . . . . 2.5 Automatická konfigurace . . . . . . . . . . . . . . . . 2.5.1 Bezstavová konfigurace . . . . . . . . . . . . . 2.5.2 Stavová konfigurace . . . . . . . . . . . . . . 2.6 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Podpora skupinového vysílání . . . . . . . . . . . . . 2.7.1 MLD verze 1 . . . . . . . . . . . . . . . . . . 2.7.2 MLD verze 2 . . . . . . . . . . . . . . . . . . 2.8 Podpora mobility . . . . . . . . . . . . . . . . . . . . Metody přechodu . . . . . . . . . . . . . . . . . . . . . 3.1 Obecné metody přechodu . . . . . . . . . . . . . . . 3.1.1 Dvojí zásobník . . . . . . . . . . . . . . . . . 3.1.2 Tunelování . . . . . . . . . . . . . . . . . . . 3.1.3 Překladače . . . . . . . . . . . . . . . . . . . 3.2 Konkrétní metody přechodu . . . . . . . . . . . . . . 3.2.1 Tunnel broker . . . . . . . . . . . . . . . . . . 3.2.2 6to4 . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 6over4 . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 4 4 4 5 5 6 7 7 7 8 8 8 10 11 13 13 14 15 15 16 17 17 19 19 19 19 20 20 20 22 22 1
4
5 A B
C
D
3.2.4 ISATAP . . . . . . . . . . . . . . . . . 3.2.5 Teredo . . . . . . . . . . . . . . . . . . 3.2.6 Stateless IP/ICMP Translation (SIIT) 3.2.7 NAT-PT . . . . . . . . . . . . . . . . . 3.2.8 NAT64 . . . . . . . . . . . . . . . . . Testy vybraných přechodových mechanismů 4.1 Zřízení a instalace tunelovacích mechanismů . 4.2 Testované charakteristiky . . . . . . . . . . . 4.3 Testy . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Zpoždění paketů v síti . . . . . . . . . 4.3.2 Rozptyl zpoždění . . . . . . . . . . . . 4.3.3 Ztrátovost paketů . . . . . . . . . . . 4.3.4 Rychlost přenosu . . . . . . . . . . . . 4.3.5 Celkové shrnutí testů . . . . . . . . . . Závěr . . . . . . . . . . . . . . . . . . . . . . . . . Bezpečné objevování sousedů (SEND) . . . . IPsec . . . . . . . . . . . . . . . . . . . . . . . . . B.1 Základní principy použití IPSECu . . . . . . B.2 Authentication Header . . . . . . . . . . . . . B.3 Encapsulating Security Payload . . . . . . . . B.4 Správa bezpečnostních asociací . . . . . . . . Měření v denní špičce . . . . . . . . . . . . . . C.1 Zpoždění paketů v síti . . . . . . . . . . . . . C.2 Rozptyl zpoždění . . . . . . . . . . . . . . . . C.3 Ztrátovost paketů . . . . . . . . . . . . . . . . C.4 Šířka pásma . . . . . . . . . . . . . . . . . . . Seznam důležitých RFC dokumentů . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
23 23 25 25 25 27 28 28 29 29 30 32 33 33 35 38 39 39 39 40 40 41 41 42 43 44 45
2
Kapitola 1
Úvod Komunikace v současném Internetu je jiná než na začátku a způsoby jeho užití jsou také rozdílné. Větší počet uživatelů k němu připojených zvýšil i objem přenášených dat. S tím se začaly objevovat vyšší požadavky především na rychlost, bezpečnost a kvalitu přenosu. První specifikace základního internetového protokolu IPv4 je popsána již v roce 1980. Vznikající potřeby a problémy tak byly následně řešeny pomocí dodatečné implementace potřebných funkcí. V roce 1992 začínalo být jasné, že adresový prostor protokolu IPv4 bude pomalu vyčerpán. Proto již tehdy organizace IETF1 rozhodla o nutnosti změny internetového protokolu, který kromě rozšíření adresového prostoru sebou přinese i další nové funkce. Například individuální, skupinové a výběrové adresy, automatickou konfiguraci, zvýšení bezpečnosti, podporu mobility a plynulý přechod z IPv4 na IPv6. Poté vznikly pracovní skupiny, které započaly práci na novém protokolu označovaném jako IP next generation, pak přejmenovaném na IPv6. První výsledky se objevily koncem roku 1995, kdy byla vydána sada RFC dokumentů definujících IPv6. Jedná se hlavně o RFC 1883 a jeho příbuzné. V této době se mohlo již začít s implementací nového protokolu, ale začátek byl pomalý. Problém s nedostatkem adres se podařilo oddálit pomocí překladačů adres. Přechod na nový protokol narážel na další velký problém, neexistenci aplikací podporující nový protokol a vysoké náklady na jejich vznik. Psychologický milník nastal 3. února 2011, kdy byly alokovány poslední bloky IPv4 adres v registru IANN2 . Cílem první části práce je popis klíčových vlastností síťového protokolu IPv6 a porovnání s IPv4. Na to navazuje druhá část, která je věnována metodám používaných pro zajištění spolupráce obou protokolů. Celá práce je zakončena testováním vybraných metod přechodu.
1. Internet Engineering Task Force. Je to otevřená mezinárodní komunita sdružující zájemce o vývoj architektury Internetu. 2. Internet Assigned Numbers Authority – organizace dohlížející na přidělování IP adres, správu kořenových zón DNS a další náležitosti internetových protokolů.
3
Kapitola 2
Základní vlastnosti nového protokolu 2.1
Adresy v IPv6
Rozšíření počtu dostupných adres bylo první motivací k vytvoření nového protokolu. Oproti starému protokolu, kde bylo možné využívat adresy o délce 32 bitů a adresovat asi 4 miliardy zařízení, využívá IPv6 adresy o délce 128 bitů a tudíž dovoluje připojit do sítě asi 3, 4 × 1038 zařízení. Takové množství adres je považováno dnes za nevyčerpatelné.
2.1.1 Podoba a zápis IPv6 adresy Adresa se standardně zapisuje jako osm skupin po čtyřech číslicích šestnáctkové soustavy, které jsou odděleny dvojtečkami. Protože se celkem často vyskytuje hodnota nula, existují dvě možnosti pro zkrácení zápisu. Je možné vynechat počáteční nuly v každé čtveřici. Tedy v zápise adresy se může objevit místo „0001“ pouze „1“. Další možností je vynechat nulové šestnáctibitové skupiny následující za sebou zástupným znakem „::“. Tento znak se smí vyskytnout v adrese pouze jednou, aby bylo možné jednoznačně určit původní tvar adresy. Některé přechodové mechanismy potřebují pracovat s adresami ze světa IPv4. Proto vznikly takzvané IPv4 kompatibilní adresy, které byly později nahrazeny IPv4-mapovanými adresami, které se používají nyní. Ty mají počátečních 80 bitů nulových, pak následuje 16 bitů jedničkových a na posledních 32 bitech je zapsána IPv4 adresa. Tu je možné zapisovat jako běžnou IPv4 adresu. Například: „::ffff:147.233.49.89“.
Normální tvar Zkrácený tvar
0126:0000:0000:0000:0000:0025::fa56:0026 126::25:fa56:26 Tabulka 2.1: Příklad zkrácení adresy 4
2. Základní vlastnosti nového protokolu 2.1.2 Druhy adres Adresní schéma IPv6 bylo definováno ve specifikaci RFC 1884. Následně ještě byla dvakrát upravena v RFC 2373 a v RFC 3513. Byly zde popsány tři druhy adres – individuální, skupinové a výběrové adresy. ∙
Individuální (unicast) adresy určují jednoznačně právě jedno zařízení. Funkce tedy zůstává nezměněná.
∙
Skupinové (multicast) adresy určují skupinu zařízení, kterým má být určitá informace doručena. Tu pak obdrží všichni členové skupiny. Také jsou využívány k nahrazení všesměrového vysílání (broadcast), kdy jsou využity speciální skupiny. Například všechny uzly nebo všechny směrovače na dané lince.
∙
Výběrové (anycast) adresy jsou oproti IPv4 nové. Podobně jako skupinové adresy určují skupinu příjemců, ale data jsou doručena pouze jedinému nejbližšímu členu.
2.1.3 Typy adres IPv6 Adresní prostor IPv6 byl rozdělen na několik typů adres, kdy každý typ určuje adresy se společnou charakteristikou. Prefix ::/128 ::1/128 ff00::/8 fe80::/10 fc00::/7 ostatní
Význam nedefinovaná adresa lokální smyčka skupinové adresy individuální lokální linkové adresy unikátní individuální lokální individuální globální
Tabulka 2.2: Základní typy IPv6 adres (převzato z [1]) Nejrozšířenější adresy jsou individuální a ty se dělí na několik typů. ∙
Individuální globální – jsou celosvětově jedinečné adresy, takže jsou směrovatelné celým IPv6 Internetem. Jsou protipólem současných IPv4 adres.
∙
Individuální lokální linkové – jsou adresy, které mají počátečních 64 bitů pevně daných, za nimi je pak připojen 64bitový identifikátor rozhraní. Mají omezen dosah pouze na jedinou linku. Takové adresy 5
2. Základní vlastnosti nového protokolu si umí zařízení generovat samo. Tyto adresy se používají v bezstavové autokonfiguraci, objevování sousedů nebo v situacích, kdy není přítomen směrovač. ∙
Unikátní individuální lokální – jsou adresy, které slouží pro lokální komunikaci, většinou uvnitř jedné sítě, a jsou celosvětově jednoznačné. Toho se využívá, pokud je síť ve více lokalitách, které jsou spojeny přes některou páteřní síť. Tyto adresy jsou nástupcem individuálních lokálních místních adres, které byly zamítnuty v RFC 3879.
2.1.4 Struktura adresy IPv6 adresa se obvykle dělí na dvě stejně velké části. Horních 64 bitů reprezentuje adresu sítě, dolních 64 bitů identifikátor rozhraní. Ten nejčastěji vzniká použitím modifikovaného EUI-641 . Ve standardním EUI-64 je předposlední bit v prvním bajtu příznakem celosvětové jedinečnosti. Hodnota 1 značí lokální adresu, hodnota 0 globální adresu. Modifikované EUI-64 invertuje hodnotu tohoto bitu. To pak usnadňuje vytváření identifikátoru rozhraní. Nejčastěji vzniká identifikátor rozhraní z celosvětově jednoznačné MAC adresy o délce 48 bitů přidělené výrobcem. Tato transformace je vcelku snadná, protože se vloží mezi třetí a čtvrtý bajt MAC adresy 16 bitů s hodnotou fffe a obrátí se příznak globality. V Tabulce 2.3 je ukázán příklad. MAC adresa Identifikátor rozhraní
00:8C:A0:C2:71:35 28c:a0ff:fec2:7135
Tabulka 2.3: Vznik identifikátoru rozhraní pomocí EUI-64 Kvůli jednoduchosti tohoto principu není problém odvodit adresu a tím může vznikat bezpečnostní problém. Lze tak snadno vyhledat, které zařízení k příslušné službě přistupovalo. Navíc je možné i zjistit, z které konkrétní sítě to bylo. Jako ochrana proti těmto problémům vznikl mechanismus Privacy Extensions, který je definován v RFC 4941. Princip spočívá v nahodilém generování hostitelské části IPv6 adresy. Ty se pravidelně obměňují a vznikají nové. Takové adresy se tedy nedají předem určit. 1. Standard zaměřený na přidělování celosvětově jednoznačných identifikátorů pro rozhraní v počítačových sítích.
6
2. Základní vlastnosti nového protokolu 2.1.5 Přidělování adres Přidělování adres je velmi podobné jako u IPv4. Centrální autoritou je IANA, která přiděluje velké bloky adres regionálním registrům – AFRINIC (Afrika), APNIC (Asie a Pacifik), ARIN (Severní Amerika), LACNIC (Latinská Amerika) a RIPE NCC (Evropa a Blízký východ). Ty následně přidělují menší bloky lokálním registrům, což většinou bývají poskytovatelé Internetu. Až od nich získávají adresy zákazníci.[1] Díky hierarchickému uspořádání je dodržována agregovatelnost. Což znamená, že poskytovatel obdrží určitý prefix, ten pak v podobě delších prefixů rozděluje zákazníkům. Cílem je, aby poskytovatelova síť i se všemi jeho zákazníky byla dostupná jedním záznamem ve směrovacích tabulkách. Konečným důsledkem je zmenšení velikosti směrovacích tabulek. Návrh struktury globálních individuálních adres je popsán v RFC 4291, které ji definuje, jak je uvedeno na v Tabulce 2.4. n bits global routing prefix
m bits subnet ID
128-n-m bits interface ID
Tabulka 2.4: Struktura globálních adres (převzato z [2]) Global routing prefix je hierarchicky strukturovaná hodnota přiřazena určitému místu, subnet ID je identifikátorem jedné linky v tomto místě a interface ID identifikátor rozhraní [2].
2.2
Domain Name System (DNS)
DNS slouží pro převod doménového jména na IP adresu a naopak. V případě nového protokolu je tento systém ještě významnější, protože IPv6 adresy jsou dlouhé, obtížně se pamatují a zapisují. Posledním dokumentem, který řeší ukládání informací do DNS je RFC 3596. Toto řešení vychází z IPv4.
2.2.1 Dopředné dotazy Pro zjišťování adresy k danému jménu se používá nový typ záznamů zvaný AAAA. Jejich název byl odvozen od A záznamů z IPv4. Jejich použití v zónovém souboru je obvyklé takto: jméno AAAA adresa – pc AAAA 2001:db8:1c01:1:204:76ff:fe47:8e81. 7
2. Základní vlastnosti nového protokolu 2.2.2 Reverzní dotazy Zjišťuje jméno ke známé IPv6 adrese. V adrese je nejobecnější část na začátku, ale v doménovém jméně je až na konci. Aby se dala databáze reverzního DNS distribuovat obvyklým způsobem, je třeba adresu v dotazu obrátit. Pro IPv6 adresu se reverzní dotaz vytvoří tak, že se obrátí pořadí šestnáctkových číslic v celé kompletní adrese bez vynechání nul. Každá z nich je pak brána jako poddoména a na konec se připojí ip6.arpa. Pro výše uvedený příklad to vypadá takto: 1.8.e.8.7.4.e.f.f.f.6.7.4.0.2.0.1.0.0.0.1.0.c.1.8.b.d.0.1.0.0. 2.ip6.arpa Do zónového souboru se pak zapisují pomocí obvyklých PTR záznamů. Pro výše uvedenou adresu by instituce dostala přidělen prefix 2001:db8:1c01::/48 a jemu odpovídající reverzní doménu 1.0.c.1.8.b.d.0.1.0.0.2.ip6.arpa. V jejím zónovém souboru pak bude uvedeno: 1.8.e.8.7.4.e.f.f.f.6.7.4.0.2.0.1.0.0.0 PTR pc.kdesi.cz. [4]
2.3
Formát datagramu
Hlavním dokumentem, který ho definuje, je RFC 2460. 2.3.1 Tvar datagramu v IPv6 a rozdíly oproti IPv4 Datagram začíná hlavičkami a po nich následují nesená data. Na rozdíl od IPv4 zde došlo k zásadní změně ve velikosti základní hlavičky, kde se omezily její prvky jen na ty nejnutnější. I přesto, že se adresy prodloužili čtyřikrát, celková délka základní hlavičky datagramu vzrostla ve srovnání s IPv4 jen dvojnásobně z 20 B na 40 B. Z toho u IPv6 zabírají největší část adresy, a to 32 B [1]. Následující výčet ukazuje nové, stejné nebo změněné položky používající se v hlavičce protokolu IPv6. ∙
Verze (Version) – tato 4 bitová položka identifikuje verzi protokolu. V případě IPv6 má hodnotu 6 [2]. Toto pole jako jediné zůstalo nezměněné. To proto, aby na jedné lokální lince mohli být provozovány oba protokoly zároveň.
∙
Třída provozu (Traffic Class) – tato 8 bitová položka vyjadřuje prioritu provozu. To by mělo sloužit k lepšímu poskytování služeb se 8
2. Základní vlastnosti nového protokolu
Obrázek 2.1: Porovnání IPv4 a IPv6 hlavičky datagramu (převzato z [5]) zaručenou kvalitou. Zatím však v praxi neumí zajistit takové parametry, jako jsou například přenosová rychlost, zpoždění či rozptyl. Z definice se zatím požaduje, aby implicitní hodnota všech bitů byla nastavena na 0 [2]. Podobnou úlohu ve starém protokolu zastává pole Typ služby (Type of Service). ∙
Značka toku (Flow Label) – je jedno z nových polí v IPv6 , zatím není přesně definováno a má velikost 20 bitů. Odesílatel by měl označovat jako tok pakety se společnými vlastnostmi. S těmi by pak mělo být během směrování zacházeno stejně. Ty pakety, které nepatří k žádnému toku, by měly mít nastavenou tuto položku na 0. [2], [1]
∙
Délka dat (Payload Length) – šestnáctibitové číslo značící délku dat přenášených za základní hlavičkou, které se mezi tyto data nepočítá. Rozšiřující hlavičky už mezi ně ale počítány jsou [2]. Ve starém protokolu se používalo pole Délka datagramu (Datagram Length), které na rozdíl od nové verze nese délku dat včetně záhlaví.
∙
Další hlavička (Next Header) – osmibitová položka označující to, co následuje za záhlavím. Může označovat buď typ rozšiřující hlavičky, 9
2. Základní vlastnosti nového protokolu Typ záhlaví Volby pro všechny (Hop-by-hop Options) Směrování (Routing) Fragmentace (Fragment) Autentizace (Autentication) Volby pro cíl (Destination Options Šifrování obsahu (Encapsulating Security Payload) Poslední hlavička (No Next Header) Typ nesených dat – příklady TCP UDP ICMP
Hodnota 0 43 44 51 60 50 59 6 17 58
Tabulka 2.5: Vybrané hodnoty pole další hlavička (převzato z [3]) nebo druh dat [2]. Tato položka nahrazuje ze starého protokolu položku Protokol (Protocol), který udává druh dat a také částečně položku Volby (Options). ∙
Maximální počet skoků (Hop Limit) – osmibitová položka, jejíž hodnota je snižována pokaždé o 1, když směrovač pošle paket dál sítí. Po dosažení 0 je paket zahozen. Slouží jako ochrana proti zacyklení při směrování [2]. Stejnou úlohu plní ve starém protokolu pole Životnost (Time to Live).
∙
Zdrojová adresa (Source Address) – 128-bitová adresa odesílatele. Zde se změnila pouze velikost oproti starému protokolu. To samé platí samozřejmě i pro cílovou adresu.
∙
Cílová adresa (Destination Address) – 128-bitová adresa odesílatele.
2.3.2 Rozšiřující hlavičky Právě zde dochází k největší změně ve formátu hlaviček. Položka Další hlavička obecně odkazuje na typ následující hlavičky. Již to není omezeno pouze na protokol vyšší vrstvy, ale může obsahovat další rozšiřující volby. Každá hlavička je samostatným blokem a ty jsou vzájemně propojeny pomocí pole Další hlavička. Vlastnímu obsahu tedy může předcházet řada volitelných hlaviček, které jsou zřetězeny do lineárního seznamu a měly by dodržovat určené pořadí. Jednotlivé hlavičky jsou identifikovány podle hodnoty v poli Další hlavička. 10
2. Základní vlastnosti nového protokolu Hlavní výhodou této koncepce je pružnost a úspornost. Přenášejí se pouze potřebné informace. Na druhou stranu zde existuje možná nevýhoda, že zpracování může představovat průchod dlouhým řetězcem. [1] Tento problém se řeší pomocí předepsaného pořadí rozšiřujících hlaviček v RFC 2460. Zde je jejich pořadí a krátká charakteristika. 1.
Základní hlavička IPv6 (IPv6 header).
2.
Volby pro všechny (Hop-by-hop Options) – jsou volby určené pro všechny směrovače po cestě.
3.
Volby pro cíl (Destination Options) – volby určené pro cílovou adresu a pro případné další uvedené v hlavičce Směrování.
4.
Směrování (Routing) – nabízí možnost přidat do směrování jednu či několik IPv6 adres, jimiž musí datagram projít před doručením.
5.
Fragmentace (Fragment) – umožňuje pouze odesílajícímu zařízení odesílat větší data, než dovoluje maximální přenosová velikost pakety (MTU). Obsahuje identifikaci původního paketu neděleného paketu, pořadí fragmentu a označení, zda je koncový paket.
6.
Autentizace (Authentication) – obsahuje kontrolní informace, zda nebyla porušena integrita.
7.
Šifrování obsahu (Encapsulating Security Palyload) – obsahuje parametry týkající se šifrování a dešifrování dat.
8.
Volby pro cíl (Destination Options) – volby pouze pro konečného příjemce.
Každá z hlaviček by měla být v paketu pouze jednou s výjimkou hlavičky Volby pro cíl, která se může vyskytnout dvakrát. Mezilehlé směrovače čtou pouze Volby pro všechny. Výjimku tvoří ty pakety, které mají rozšiřující hlavičku Směrování. Tam pak průběžný cílový uzel zajímají ještě hlavičky Volby pro cíl a Směrování. Ostatní hlavičky jsou určeny pouze pro koncový cílový uzel.
2.4
Objevování sousedů
V IPv4 se ke zjištění linkové adresy partnera využívá protokol Address Resolution Protocol (ARP). Ten pomocí všesměrového vysílání rozešle dotaz 11
2. Základní vlastnosti nového protokolu obsahující hledanou IP adresu a údaje o sobě, IP a MAC adresu. Hledaný uzel mu odpoví zprávou, kde je jeho IP a MAC adresa. U IPv6 vytvořili obecnější nástroj řešící tento problém. Ten je definován v RFC 4861 a řeší i tyto oblasti: ∙
zjišťování linkových adres uzlů v lokální síti,
∙
aktualizaci neplatných položek a změn v linkových adresách,
∙
hledání směrovačů,
∙
přesměrování,
∙
zjišťování prefixů, parametrů sítě a dalších údajů pro automatickou konfiguraci adresy,
∙
ověřování dosažitelnosti sousedů,
∙
detekci duplicitních adres.
K činnosti využívá 5 základních ICMP zpráv: výzva směrovači, ohlášení směrovače, výzva sousedovi, ohlášení souseda a přesměrování. Hledání linkových adres se podobá klasickému ARP. Změnila se adresa používaná k zasílání dotazů. Tvoří ji prefix ff02:0:0:0:0:1:ff00::/104. Zbývajících 24 bitů je tvořeno posledními 24 bity z hledané IP adresy. Takovéto adrese se říká adresa pro vyzývaný uzel. Aby to mohlo fungovat, musí se každé zařízení při inicializaci IP přihlásit do všech odpovídajících skupin. Většinou v každé takové skupině bude zařízení samo, takže při zjišťování adresy nebudou obtěžovány ostatní uzly. Zjištění linkové adresy tedy probíhá následovně. Z cílové adresy vytvoří skupinovou adresu. Na ni pošle Výzvu sousedovi. Ten na ni reaguje Ohlášením souseda. Pak se již jen aktualizuje cache paměť sousedů, ve které jsou uloženy jejich linkové adresy. Pomocí těchto zpráv se testuje i dosažitelnost souseda. Pokud dorazí ohlášení, je vše v pořádku. Pokud ne, výzva se několikrát opakuje. Když ani poté nedorazí ohlášení souseda, tak bude adresa vymazána z cache paměti sousedů. Inverzní objevování sousedů řeší situaci, kdy zařízení zná linkovou adresu a potřebuje zjistit jeho IP adresu. Stroj tedy odešle prostřednictvím ICMP Výzvu. Posílá ji na skupinovou adresu pro všechny, ale na linkové vrstvě ji adresuje pouze adresou cílového stroje. Vyzvaný pak reaguje Ohlášením, které obsahuje linkovou adresu a také seznam IPv6 adres pro odpovídající rozhraní. Jako reakce na bezpečnostní problémy vznikl mechanismus SEND, který je popsán v příloze A. 12
2. Základní vlastnosti nového protokolu
2.5
Automatická konfigurace
Ve světě je stále větší pozornost věnována tomu, aby se většina zařízení uměla nakonfigurovat sama. Nejinak je tomu i u počítače zapojovaného do sítě. K tomu byly navrženy dvě možnosti: bezstavová a stavová konfigurace. 2.5.1 Bezstavová konfigurace Zde se využívá dostatečně veliký adresový prostor IPv6 k tomu, aby nemusely být adresy přidělovány, ale každé koncové zařízení si může svoji adresu nakonfigurovat samostatně. Tento mechanismus je prvně popsán v RFC 2462, později v RFC 4862. Uzel nejdříve vytvoří svou lokální linkovou adresu. Ta se tvoří tak, že k prefixu lokálních linkových adres fe80::/10 se připojí identifikátor rozhraní. Pak pomocí detekce duplicitních adres ověří, že adresa je jedinečná. Uzel rozešle výzvu sousedovi s právě vygenerovanou IPv6 adresou, pokud nepřijde žádná odpověď, tak je adresa jedinečná. K dalšímu pokračování je již potřeba mít znalosti o svém okolí. Ty získá z ohlášení směrovače, které je generováno automaticky nebo si ho může uzel sám vyžádat. Z něho se hlavně dozví prefix podsítě a informaci o tom, jak dlouho může daný směrovač využívat jako implicitní. Z těchto informací si již je zařízení schopno samostatně vytvořit platnou IPv6 adresu. Ale ještě z nich nemůže poznat adresu DNS serveru. To se řeší dvěma způsoby, ale jenom jeden je dosud implementovaný. Funkční variantou je kombinace bezstavové automatické konfigurace s bezstavovým DHCPv6, které doplňuje zbývající chybějící adresy místních DNS serverů a případně přípony doménových jmen k prohledávání. Druhou možností je využití nových voleb v ohlášení směrovače. Ty jsou definovány v RFC 6106. ∙
RDNSS (Recursive DNS Server) – ohlašuje se v ní IPv6 adresy místních rekurzivních serverů. Může obsahovat i více adres, u kterých je ještě oznamovaná jejich životnost. Ohlášení může obsahovat několik voleb RDNSS.
∙
DNSSL (DNS Search List) – obsahuje seznam přípon, které má klient zkusit připojit na konec doménového jména, pokud se nedaří najít odpověď. Tato informace není nezbytná, ale je také součástí DHCP a proto je přidána i zde.
Z těchto informací si budou klienti udržovat dva seznamy – adresy místních rekurzivních serverů a prohledávané přípony doménových jmen. Podle 13
2. Základní vlastnosti nového protokolu příchozích ohlášení směrovačů se budou oba seznamy aktualizovat. Může nastat situace, kdy se klient dozví různé informace z ohlášení směrovače a jiné z DHCPv6. Pak se doporučuje, aby si klient ponechal nějaké údaje z každého zdroje. Pak by pořadí informací mělo dodržovat následující priority: DHCPv6, ohlášení směrovače chráněné pomocí SEND a nechráněné ohlašení směrovače. 2.5.2 Stavová konfigurace Ta je známa už z IPv4. Zde se používá nový protokol DHCPv6, který je definován v RFC 3315. Počítač rozešle na obecnou adresu paket s dotazem na komunikační parametry. Server mu v odpovědi sdělí potřebné informace – IP adresu, prefix podsítě, implicitní záznam do směrovací tabulky, adresu DNS serveru a další informace podle potřeby. Podílejí se na ní 3 kategorie zařízení. ∙
Klient – chce získat informace.
∙
Server – poskytuje informace.
∙
Zprostředkovatel – zprostředkovává styk mezi nimi, pokud neleží na stejné lince. Někdy bývají pod pojmem Agent zařazeny Server a Zprostředkovatel.
V DHCP je velmi důležitá otázka identifikace zařízení. Ve staré verzi se používá ethernetová adresa. V DHCPv6 se zavádí pojem DHCP Unique Identifier (DUID). Je to jednoznačný identifikátor každého zařízení fungující v DHCP procesu – klient i server. Druhým pojmem sloužícím k identifikaci je Identity Association (IA). Ten počítač přiřazuje každému svému rozhraní. Nejdříve si klient vytvoří IA pro svá rozhraní a opatří je jednoznačnými identifikátory. Pak na adresu všech DHCP agentů (ff02::1:2) pošle zprávu výzva (Solicit), ve které je obsažen DUID, všechny IA a jeho vytvořená lokální linková adresa. Pokud klient a server sídlí na stejné lince, pak server odpoví přímo na jeho linkovou adresu zprávou ohlášení serveru (Advertise), kde jsou uvedeny preference a parametry, které by přidělil jednotlivým IA. Klient si ze všech přijatých oznámení vytvoří seznam DHCP serverů. Pak si podle hodnoty preference vybere ten nejvýhodnější a tomu pošle zprávu žádost (Request), kde je uveden DUID serveru. To je proto, že je zpráva odesílána stále na obecnou adresu serverů. Příslušný server pak zašle zprávu odpověď (Reply) obsahující IPv6 adresy a další parametry. Klient si pak pomocí mechanismu 14
2. Základní vlastnosti nového protokolu pro detekci duplicitních adres zkontroluje jedinečnost adres. Pokud nejsou jedinečné, pak je odmítne pomocí zprávy odmítnutí (Decline). Pokud se klient a server nenachází na stejné lince, zprávy jsou stejné jen s tím rozdílem, že agent zprávy přicházející od klienta balí do zpráv předání (Relay), které pak odesílá serverům ve svém seznamu. Server pak zabalí své odpovědi do zpráv zprostředkování (Relay) a posílá je na adresu agenta. Ten je pak vybalí a normálně zašle klientovi. Takto přidělené adresy mají ovšem omezenou životnost. Po uplynutí musí klient žádat o její prodloužení server, který ji přidělil. Když server neodpovídá, požádá jiný dostupný server. Naopak pokud se klient odpojuje ze sítě, měl by o tom informovat zprávou uvolnění (Release). DHCP také řeší situaci návratu klienta do sítě, například po restartu počítače. Potom si musí klient ověřit, zda jeho stávající údaje jsou správné. To učiní pomocí zprávy potvrzení (Confirm), kterou pošle na skupinovou adresu všech DHCP serverů. V ní sděluje aktuální parametry svých IA. Příslušný server reaguje kladnou nebo zápornou odpovědí. [1] Komunikaci většinou zahajuje klient, ale i server má možnost si vynutit na klientech, aby se přizpůsobili nové situaci při změně síťových parametrů. K tomu slouží zpráva rekonfigurace (Reconfigure).
2.6
IPsec
Bezpečnost na síťové vrstvě řeší sada mechanismů souhrnně se nazývající IPsec. Existuje jak pro IPv4, tak samozřejmě i pro IPv6, kde již musí být povinně implementován. Nabízí autentizaci a šifrování pomocí dvou rozšiřujících záhlaví. Prvním z nich je hlavička Authentication Header (AH), která má za úkol zajistit integritu dat, autentizaci a ochranu proti opakování pro celý IPv6 paket. Druhým je hlavička Encapsulating Security Payload (ESP), která zajišťuje integritu dat, autentizaci, utajení a ochranu proti opakování pro data, která jsou zabalena v ESP. Jak je vidět, tak ESP nabízí stejné služby jako AH, proto se postupně projevuje odklon od hlavičky AH. Před začátkem komunikace je třeba vyjednat bezpečnostní asociaci, kde se zařízení domluví na všem potřebném. Ke správě bezpečnostních asociací je využíván Internet Key Exchange version 2 (IKE2). Více v příloze B.
2.7
Podpora skupinového vysílání
Skupinové vysílání je šíření dat od jednoho zdroje k více cílům. Obecně musí řešit dva základní problémy. Jak nejlépe doručit stejná data více příjemcům tak, aby byly efektivně využívány linky. Zároveň se ale snaží zajistit, aby 15
2. Základní vlastnosti nového protokolu Adresa IPv6 ff02::1 ff02::2
Popis všechny uzly ve stejném segmentu sítě všechny směrovače ve stejném segmentu sítě
Tabulka 2.6: Vybrané skupinové adresy (převzato z [1]) ostatní uzly nebyly obtěžovány nevyžádanými daty. Základní informací pro směrovače je, které skupiny má vysílat do daného prostředí. Ke zjišťování příjemců v IPv6 slouží Multicast Listener Discovery (MLD), jehož definice je v RFC 3810. Ten je nástupcem Internet Group Managment Protocol, který se využíval pro stejné účely v IPv4. MLD je podprotokolem ICMPv6, jsou tedy využívány zprávy typu ICMP. Typy zpráv se liší podle verze protokolu. Pro skupinové vysílání jsou vyhrazeny adresy s prvními osmi bity jedničkovými. V IPv6 již není broadcast, ale používají se různé skupiny. Nejdůležitější z nich jsou uvedeny v následující tabulce. 2.7.1 MLD verze 1 Tato verze se nestará o odesílatele. Vychází z toho, zda pro danou skupinu existuje nějaký příjemce. Proto si musí směrovač udržovat seznam aktivních skupinových adres, ze kterého pak vytváří distribuční stromy pro jednotlivé skupiny. Používá tři typy zpráv. Zpráva obsahuje Typ, Kód, Kontrolní součet, Maximální zpoždění, Skupinovou adresu. ∙
Ohlášení členství ve skupině (Typ 131) – posílá ji počítač na adresu skupiny, do které chce vstoupit. Směrovače si pak přidají u příslušného rozhraní tuto skupinovou adresu do seznamu vysílaných.
∙
Vystoupení ze skupiny (Typ 132) – posílá ji počítač na adresu ff02::2, když chce ukončit členství ve skupině.
∙
Výzva (Typ 130) – posílá ji směrovač na adresu skupiny, aby zjistil, zda ještě existuje nějaký posluchač dané skupiny. Ze skupiny odpoví vždy maximálně jeden stroj. Tato zpráva se také ještě využívá k obecným dotazům, kdy je ve skupinové adrese uvedena nula a zpráva je odeslána na ff02::1. Tím směrovač zjišťuje, které všechny skupiny zde mají své posluchače. Tento dotaz posílá vždy směrovač s nejnižší IP adresou, ale odpověď dostávají všechny směrovače na lince. 16
2. Základní vlastnosti nového protokolu 2.7.2 MLD verze 2 Tato možnost navíc umí filtrovat vysílací zdroje. Dovoluje vybírat konkrétní zdroj nebo naopak některé blokovat. K definování zdrojů, které chceme přijímat, slouží příkaz INCLUDE. Naopak seznam zdrojů, od kterých přijímat data nechceme, definujeme pomocí příkazu EXCLUDE. Tyto pravidla mezi sebou můžeme kombinovat pomocí logických operací (sjednocení, průnik a doplněk). Na straně příjemce je jedna událost typu 143 Hlášení, které je zasíláno všem MLDv2 směrovačům na lince na adresu (ff02::16). Každá takováto zpráva se skládá z více Záznamů, které nesou informace o skupinové adrese, zdrojích skupinového vysílání a typu záznamu. Dotaz od směrovače umožňuje navíc připojit seznam zdrojů a zjišťuje tak nejen seznam posluchače daných skupin, ale také posluchače daných zdrojů. Tato zpráva je posílána všem na adresu ff02::1, nebo na příslušnou skupinovou adresu. Na rozdíl od MLDv1 zde musí odpovědět každý příjemce, protože v odpovědi je seznam všech skupin a zdrojů, které poslouchá. Tato odpověď je posílána všem směrovačům na lince.
2.8
Podpora mobility
Podpora mobilních zařízení v IPv6 je definována nejprve v RFC 3775, později pak v RFC 6275. Je to jedna z významných předností nového protokolu. Základní myšlenka vychází z faktu, že každý uzel má svojí domácí síť a tedy i svoji domácí adresu. Tuto adresu má zaregistrovanou v DNS a na ni ho může zájemce kontaktovat. Pokud se ale uzel nachází zrovna na cestách, tedy mění svojí IP adresu, zastupuje jej v jeho domácí síti tzv. domácí agent. Tím většinou bývá jeden ze směrovačů v jeho domácí síti. Toho mobilní uzel kontaktuje a zaregistruje se u něj. To znamená, že mu pošle svou aktuální dočasnou adresu a požádá o zastupování. Tím je vytvořena vazba mezi jeho domácí a dočasnou adresou. Od toho okamžiku se domácí agent vydává za mobilní uzel a přebírá datagramy určené pro mobilní uzel a následně mu je posílá na jeho aktuální dočasnou adresu. Všechny tyto datagramy šifruje pomocí IPsecu, kde využívá hlavičku ESP. Tedy zájemce (označováný jako korespondent) posílá data domácímu agentu, od něj pak putují mobilnímu uzlu. Jeho odpovědi jsou přeposílána přes domácího agenta zpět ke korespondentovi. Celý tento způsob komunikace je značně neefektivní a proto zde existuje snaha spojení optimalizovat. Komunikace je zahájena mobilním uzlem v okamžiku příchodu prvního datagramu. Jejím cílem je oznámit korespondentovi aktuální dočasnou ad17
2. Základní vlastnosti nového protokolu resu. K tomu slouží aktualizace vazby, ale nejdříve musí prokázat svému partnerovi, že je skutečně ten, za kterého se vydává. Jakmile je aktualizace vazby úspěšně dokončena, přidává korespondent do datagramů rozšiřující hlavičku Směrování. Finální adresou zůstává domácí adresa mobilního uzlu, ale datagramy jsou posílány přes dočasnou aktuální adresu. Tím probíhá komunikace mezi stroji přímo. Průběh aktualizace vazby je na Obrázku 2.4.
Obrázek 2.2: Aktualizace vazby u korespondenta (převzato z [7]) Jak je výše zmíněno, korespondent přidává rozšiřující hlavičku Směrování. Mobilní uzel zase přidává volbu Domácí adresa do hlavičky Volby pro příjemce, ve které posílá svou domácí adresu. Mobilní uzel může svou adresu měnit, pak musí změnu nahlásit svému domácímu agentovi. Také ale musí tuto změnu ohlásit všem partnerům, se kterými v poslední době komunikoval. Ty najde v seznamu aktualizací a těm pošle aktualizaci s novou adresou. Speciálním případem změny adresy je návrat do domovské sítě. Mobilní uzel posílá zprávu Aktualizace vazby, která má ale nulovou životnost. To znamená výmaz ze seznamu vazeb. Tuto informaci posílá také domácímu agentovi, aby zrušil registraci. Nakonec ještě musí rozeslat několik ohlášení souseda.
18
Kapitola 3
Metody přechodu Nový protokol IPv6 přináší spoustu změn a nových vlastností, které jej činí nekompatibilním se starší verzí IPv4. Jako reakce na tyto problémy vznikly zároveň také různé mechanismy přechodu, které umožňují dočasnou funkčnost obou protokolů vedle sebe. Zpočátku tyto mechanismy mají sloužit k připojení menších sítí, či jednotlivců používajících IPv6 do celosvětové sítě. Se zvyšujícím se podílem IPv6 by měly sloužit k připojení IPv4 ostrůvků. Nakonec by měl nový protokol úplně nahradit ten starý a tyto mechanismy se přirozeně přestanou používat. Obecně se dělí na tři skupiny: dvojí zásobník (Dual Stack), tunelování (Tunneling) a překladače (Translators).
3.1
Obecné metody přechodu
3.1.1 Dvojí zásobník Dvojí zásobník je integrační metoda, ve které musí dané zařízení podporovat oba dva protokoly a mít tedy jak IPv4, tak i IPv6 adresu. K jejich získání se používají obvyklé způsoby, tedy u IPv4 ruční konfigurace nebo DHCP, pro IPv6 je možná ruční nebo automatická konfigurace. Také DNS klient se musí vyznat jak v A záznamech pro IPv4, tak v AAAA záznamech pro IPv6. Který zásobník se použije, rozhodne uzel na základě cílové adresy paketu. Přitom by měl preferovat IPv6, bude-li to možné. 3.1.2 Tunelování Tunelování je obecně zabalení jednoho protokolu do druhého. Mechanismus je ukázán na Obrázku 3.1. Tím je umožněno přenášet data přes síť, která daný protokol nepodporuje. Na jedné straně tunelu je tedy IPv6 paket zapouzdřen do IPv4 paketu, kterému se nastaví hodnota 41 v položce Protokol. Pak je poslán na IPv4 adresu směrovače na druhém konci tunelu. Ten z něj vybalí původní IPv6 paket, který se během průchodu tunelem nemění. Což má za následek, že celý průchod je počítán pouze za jeden skok a přijímající směrovač tedy zmenší položku Max skoků v IPv6 hlavičce pouze o jedničku. 19
3. Metody přechodu Využívány jsou dva základní režimy tunelování: manuální (nastavovány správcem) a automatické (navazují se samočinně). Manuální tunel se musí na dotyčném zařízení pomocí příkazů nadefinovat. Přesně se mu nastaví druhý konec, kam má směřovat. Tyto tunely se používají většinou k trvalému propojení sítí nebo ke vzdálenému zapojení počítače do sítě. Používají se například u Tunnel Brokeru či TSP. Z principu automatických tunelů vychází metody přechodu 6to4, ISATAP nebo Teredo.
Obrázek 3.1: Mechanismus tunelování (převzato z [1])
3.1.3 Překladače Předcházející přístupy potřebují ke svému fungování síť, ve které je integrována i nativní IPv6. V reálném světě mohou nastat i takové případy, kdy zařízení podporující pouze IPv6 potřebuje komunikovat se zařízením podporujícím pouze IPv4. V takovýchto případech se použijí překladače. Tedy adresy jsou překládány z jedné na druhou. Tím je tedy způsobeno, že zařízení nekomunikují přímo mezi sebou, ale přes třetí zařízení, kterým je překladač. Proto může docházet ke ztrátě některých výhod nového protokolu. Mezi překládací metody přechodu patří SIIT, NAT-PT, NAT64, TRT, BIS a SOCKS64.
3.2
Konkrétní metody přechodu
3.2.1 Tunnel broker Využívá manuálně konfigurované tunely. Jejím základem je síť serverů, zvaných Tunnel Brokers, které spravují žádosti na zřízení tunelů od jednotlivých 20
3. Metody přechodu klientů. Má sloužit hlavně k připojení izolovaných IPv6 uzlů, kterým jejich ISP neposkytuje zatím nativní IPv6 připojení. Tento model je založen na několika funkčních elementech. ∙
Tunnel Broker – je to místo, kde se uživatel může zaregistrovat a aktivovat tunel. Tedy spravuje vytváření, modifikaci a mazání tunelů podle požadavků klienta.
∙
Tunnel Server – je to směrovač s dvojím zásobníkem. Je připojen jak k IPv4 a IPv6 Internetu. Podle informací z Tunnel Brokeru vytváří, modifikuje nebo ruší svůj konec tunelu.
∙
DNS Systém – mapuje IPv6 adresy na doménová jména. Každý uživatel dostane přiděleno doménové jméno, na které bude namapována jeho IPv6 adresa. [7]
Klient musí na začátku odeslat žádost o registraci k Tunnel Brokerovi. Vždy musí obsahovat jméno, email a heslo. Broker klientovi přiřadí blok adres, DNS záznam a vrátí tyto informace zpět. Potom klient odešle žádost o aktivaci tunelu svému Tunnel Brokerovi. Ten tak získá IPv4 adresu a určí Tunnel Server, který bude pro daného klienta sloužit jako vzdálený konce tunelu. Tunnel server sestaví svůj konec tunelu a do IPv6 směrovací tabulky se přidá záznam, že adresa klienta je přístupná přes nově vytvořený tunel. Tunnel Broker odešle informace o vytvořeném tunelu klientovi. Klient si pak nakonfiguruje svou část tunelu. Tato konfigurace je poměrně složitá a vyžaduje poměrně kvalifikovaného uživatele. Proto jsou snahy vytvářet nástroje pro vyjednání tunelu s Tunnel Brokerem. Jedním z nich je i Tunnel Setup Protocol (TSP). Je to v podstatě signalizační protokol, který slouží k vytvoření tunelu mezi dvěma koncovými body. K výměně informací slouží XML soubory, které jsou přenášeny přes TCP nebo UDP protokol. TSP je iniciována z klientského uzlu směrem k Tunnel Brokerovi a skládá se ze tří fází. První fáze je autentizační, kdy Tunnel Broker/Server oznamuje klientovi dostupnost a škálu nabízených služeb a klient se autentizuje. Pak přichází příkazová fáze, kdy klient žádá o tunel nebo aktualizuje tunel stávající. Nakonec přichází fáze odpovědi, kdy klient dostane od Brokera/Serveru odpověď, podle níž tunel buď přijme, nebo odmítne. [8] TSP umožňuje vyjednávat oběma koncům o parametrech, jako jsou třeba prefix, DNS nebo směrování. Dá se také s výhodou použít pro mobilní uzly. 21
3. Metody přechodu 3.2.2 6to4 Cílem této metody automatického tunelování je poskytnout možnost komunikace koncovým IPv6 sítím prostřednictvím IPv4 s minimální konfigurací. Zde není nutné explicitně konfigurovat tunel, ale stačí nakonfigurovat 6to4 směrovač. Metoda by měla pomoci hlavně v prvotních fázích přechodů, po získání nativního připojení by se měla stát zbytečnou a přestat se používat. [9] Základním požadavkem je alespoň jedna veřejná IPv4 adresa. Tu má přiřazenou 6to4 směrovač, který je připojen jak k IPv4 Internetu, tak ke koncové IPv6 síti. Jím procházejí veškerá data přepravovaná 6to4. Nejčastěji tímto směrovačem bývá přístupový směrovač, ale není to podmínkou. Na základě IPv4 adresy se vytvoří IPv6 prefix délky 48 bitů pro celou síť. Prefix 6to4 začíná hodnotou 2002::/16, dalších 32 bitů tvoří veřejná IPv4 adresa daného směrovače. Tím vzniká prefix obvyklé délky. Směrovač pak do vnitřní sítě ohlašuje pouze, že přes něj vede cesta k síti 2002::/16. Datagramy jsou následně adresované do jiné 6to4 sítě jsou k doručení předány jemu. Ten je převezme a automaticky je tuneluje. Takto nakonfigurovaný uzel ale nemůže přímo komunikovat. Proto na Internetu existují zprostředkovatelé (relay routers). Pro nativní IPv6 síť ohlašuje, že je přes něj dosažitelná síť s prefixem 2002::/16. Podle původní specifikace bylo možné najít vhodného zprostředkovatele podle externího směrovacího protokolu, což ale má velkou režii a není proto vhodné pro menší sítě. Nové řešení bylo definováno v RFC 3068, kde byla zavedena fixní výběrová adresa pro zprostředkovatele (192.88.99.1 resp. 2002:c058:6301::). Hlavní předností je tedy minimální náročnost. Má malou celkovou režii a pro jeho používání je potřeba nastavit pouze 6to4 směrovač. Nadále je již datagram tunelován automaticky, ale tunel není založen trvale.
3.2.3 6over4 Na rozdíl od přechodového mechanismu 6to4, který řeší připojení koncových IPv6 sítí, se 6over4 zaměřuje na jednotlivé počítače připojené pouze do sítě IPv4. Mechanismus je definován v RFC 2529. Zde musí dotyčné počítače podporovat oba protokoly, protože IPv6 datagramy se tunelují samy. Každý takový stroj má svou IPv4 adresu a jeho IPv6 adresa vzniká připojením identifikátoru rozhraní k prefixu podsítě. Identifikátor rozhraní se skládá z prvních čtyř bajtů nulových a pak následuje jeho IPv4 adresa. Pro svou činnost využívá mechanismy běžné v IPv6. Proto je nutné zajistit, aby fungovalo skupinové adresování, které je nutné 22
3. Metody přechodu například pro objevování sousedů či při automatické konfiguraci. 6over4 definuje postup, jak se tyto adresy mapují na IPv4 skupiny. Vezme se posledních 16 bitů a před ně se předřadí 239.192. Protože podpora skupinového vysílání není běžně podporovaná v IPv4 sítích, je tento požadavek považován za hlavní nevýhodu tohoto přístupu. 3.2.4 ISATAP Mechanismus je definován v RFC 5214. Snaží se řešit podobný problém jako 6over4, ale zároveň nebýt závislý na podpoře skupinového vysílání v IPv4. Jelikož se zde nepoužívá skupinové vysílání, není možné použít protokol objevování sousedů. Aby stanice nalezly směrovač, pomocí kterého mohou provést autokonfiguraci, řeší ISATAP tento problém pomocí seznamu potencionálních směrovačů (potential router list, PRL). Uzel posílá výzvu směrovači na adresy uvedené v tomto seznamu. Odpovědi jsou také posílány pouze tomu, kdo se dotazoval. Z těchto ohlášení již může uzel provést proces autokonfigurace. Naplnění seznamu se nejčastěji řeší pomocí DNS, kterého se klient dotazuje na A záznam pro jméno isatap. V adrese tvoří prvních 64 bitů ISATAP prefix, který se získá procesem autokonfigurace pomocí směrovače z PRL. Dalších 32 bitů je ISATAP identifikátor, který má hodnotu 0000:5EFE. Posledních 32 bitů je původní IPv4 adresa vyjádřená v hexadecimálním tvaru. Omezením protokolu je nemožnost využívat skupinové vysílání. 3.2.5 Teredo Původně se tento návrh jmenoval shipworm, anglický název pro sášeň lodní. Takto označované programy ale mají v počítačovém světě špatnou pověst. Proto se autoři rozhodli změnit jméno na Teredo, což je latinský název pro sášeň lodní. Cílem bylo vytvořit mechanismus, který by překonal překážku v podobě NATu, s kterou si většina ostatních tunelovacích mechanismů neví rady. Teredo tento problém překonává, ale za cenu značné režie, proto je vhodné ho použít až tehdy, kdy ostatní mechanismy selhaly. Vznikla tedy specifikace RFC 4380. K použití tohoto principu není třeba žádného speciálního hardwaru, ale je tvořeno softwarovým programem běžícím pod operačním systémem. Využívá se zde Teredo klient a Teredo server. Teredo klient je za NATem v síti IPv4 a žádá o přidělení IPv6 adresy. Zatímco Teredo server má veřejnou IPv4 adresu a přiděluje Teredo klientům IPv6 adresu. 23
3. Metody přechodu Vychází z myšlenky zahájení komunikace zevnitř NATované sítě. Proto se utvoří odpovídající vazba na NATu. Teredo se dokáže vypořádat s trychtýřovitým NATem, který klientovi přidělí určitou adresu a port již propouští všechny pakety. Také překoná omezený NAT a klientovi přidělí adresu a port. Avšak propuštěny jsou jen ty datagramy, které přicházejí z adresy a portu, na něž již klient v minulosti něco poslal. Překážkou, se kterou si ani Teredo neumí poradit, je symetricky NAT, který navíc pro data odesílaná k různým cílům přiděluje klientovi jiné adresy a porty. Teredo adresa se skládá z Teredo prefixu (2001::/32). Za ním je IPv4 adresa Teredo serveru, který adresu přidělil. Dalších 16 bitů jsou příznaky. Nově přidaný příznak C (Cone) rozlišuje trychtýřovitý NAT od jiného. Pak následuje 16 bitů značících UDP port (mapování klienta). Posledních 32 bitů patří IPv4 adrese venkovního směrovače s NATem. Teredo klient získává IPv6 adresu tak, že posílá výzvu směrovači s NATem zabalenou do UDP paketu a odešle ji prostřednictvím IPv4 na adresu Teredo serveru. Ten po přijmutí paketu vytvoří adresu pro klienta a zašle ji na adresu a port klienta. Komunikace s ostatními IPv6 adresami se pak dělí na dvě skupiny podle adresáta. Buď je jím další Teredo klient nebo klient s nativní podporou IPv6. V prvním případě si klienti vyměňují data přímo. Nejlepší případ je, když je v cílové adrese nastaven příznak C. To znamená, že je adresát za trychtýřovitým NATem, který přijímá data odkudkoli. Pokud je příznak C nulový, musí poslat odesílatel dvě prázdné zprávy. První zpráva se pošle přímo adresátovi, aby se nastavil místní NAT pro příjem odpovědi. Druhá zpráva je poslaná na adresu Teredo serveru, který ji pouze předá na cílovou adresu a port. Cílový stroj se tímto dozví, že s ním chce někdo komunikovat a odpoví na tuto zprávu. V této fázi již komunikace probíhá přímo. V druhém případě probíhá komunikace s uzlem, který je přímo připojen do IPv6 sítě. Proto je zde zprostředkovatel, který předává datagramy z IPv6 prostředí do Teredo světa a naopak. Ten šíří do sítě, že je přes něj dostupný Teredo prefix 2001::/32. Klient musí najít vhodného zprostředkovatele. Odešle proto ICMPv6 zprávu echo request (požadavek na odpověď). Tu zabalí do UDP a pošle na Teredo serveru, který ji odešle na odpovídající adresu. Odpověď je odeslaná zprostředkovateli. Ten ji podle příznaku v cílové adrese odešle přímo, nebo přes Teredo server. Tím se klient dozví adresu zprostředkovatele a odešle mu paket na otevření svého NATu. Teredo klient si z praktického důvodu udržuje seznam svých komunikačních partnerů. Tento návrh vyžaduje značnou režii pro svoje fungování. Pokud je to možné, je lepší použít jinou metodu.
24
3. Metody přechodu 3.2.6 Stateless IP/ICMP Translation (SIIT) Nejstarší z překladových mechanismů. Definuje přesná pravidla pro překlad jednotlivých hlaviček, což je jeho hlavní přínos. Používá bezstavový přístup, tedy si neuchovává žádné informace o procházejících spojeních. Ale překladová pravidla mají svá omezení, která znemožňují používat rozšiřující hlavičky ze strany IPv6. SIIT nebývá v praxi nasazován samostatně, ale jeho definice pro překlad datagramů využívají další mechanismy. [10] 3.2.7 NAT-PT Network Address Translation – Protocol Translation (NAT-PT) používá právě překladová pravidla podle SIIT a k nim doplňuje mapování a překlad adres. K jednomu IPv6 prefixu mapuje IPv4 adresy přidáním na konec. Směrování v IPv6 musí zajistit, aby se datagramy směřující na daný prefix, doručily stroji implementujícímu NAT-PT. Opačné mapování se provádí na jednu či několik svých IPv4 adres a princip je obdobný jako u běžného NATu. Když IPv6 stroj odesílá datagram do IPv4 sítě, vytvoří se záznam pro IPv6 adresu a port v mapovacích tabulkách překladače a adresu přeloží do IPv4. Když přijde odpověď na příslušnou adresu a port, podle mapovací tabulky ji přeloží do IPv6. Tímto způsobem je umožněno pouze jednostranné navazování spojení z koncové sítě směrem ven. Pro oboustranné navazování je nutný zásah do DNS. Dorazí-li zvenčí dotaz na záznam typu A adresovaný některému ze zdejších DNS serverů, NAT-PT jej změní na záznam typu AAAA. Když dorazí odpověď, zařadí IPv6 adresu v ní obsaženou do své mapovací tabulky a vytvoří mapovaní. Odpověď pak přeloží do IPv4, záznam v ní změní na typ A a vloží do něj svou adresu z vytvořeného záznamu v mapovací tabulce. [11] Praktické nasazení tohoto protokolu přineslo řadu problému kvůli jeho zásahům do DNS záznamu. Proto byl v roce 2007 odmítnut v RFC 4966. 3.2.8 NAT64 NAT64 je nástupcem překládacího mechanismu NAT-PT. Jeho specifikace vyšla až po čtyřech letech od zavrhnutí staršího mechanismu v RFC 6146. Cílem je připojit koncovou IPv6 síť k IPv4 Internetu se všemi jeho službami. Nepřekládá jenom adresy, ale celé datagramy mezi oběma protokoly. Překlad probíhá podle pravidel uvedených v RFC 6145. Pro zásahy do DNS záznamů je používán algoritmus DNS64, který je obsažen v RFC 6147. Překlad IPv4 adresy na IPv6 je jednoduchý. K určenému prefixu, ob25
3. Metody přechodu vykle délky 96 bitů, se připojí IPv4 adresa. Pokud dorazí datagram s takto vytvořenou adresou, tak se pouze vyzvedne cílová IPv4 adresa, na kterou se dál přepošle. Takový prefix je označován jako Prefix64::/n a pro příslušné IPv6 adresy se používá pojem Ipv4-převedené (Ipv4-converted). [12] Překlad opačným směrem už tak snadný není. Používá se zde překladová tabulka, která se podobá tabulkám současných NATů. NAT64 překládá místní IPv6 adresy na svou IPv4 adresu a vhodný port. Když následně dorazí z IPv6 sítě datagram, jehož cílová adresa je Ipv4-převedená, vyhledá NAT64 v mapovací tabulce položku pro odesílatele a podle ní vloží do datagramu IPv4 adresu a číslo portu. Pokud položka v tabulce není, tak se vytvoří. Mapovací tabulka pracuje dynamicky. Pokud záznamy nejsou delší dobu používány, tak jsou z tabulky vymazány. NAT64 si musí pro každý protokol uchovávat dvě tabulky. Jednu pro mapování adres a druhou s aktivními relacemi. Je zde také počítáno se statickými položkami, které tam může vložit správce zařízení. Nakonec musí stroj v IPv6 síti získat IPv4-převedenou adresu. K tomu slouží mechanismus DNS64. Ten dostane klientovu žádost o záznam AAAA. Nejprve jej předá dál, a pokud dostane kladnou odpověď, přepošle ji zpět. Pokud ale vznikne chyba, zkusí DNS64 poptat ještě záznamy A. Odpověď pak změní na AAAA tak, že k adresám přidá Prefix64::/n. Spolupracující NAT64 a DNS64 musí pochopitelně používat stejný prefix. Dále musí být zajištěno, aby IPv6 datagramy směřující na IPv4-převedené adresy, procházely NAT64 zařízením. NAT64 je trochu omezený oproti NAT-PT. Umožňuje volně zahájit komunikaci jen ze strany IPv6 a podporuje pouze protokoly UDP, TCP a ICMP. Ostatní protokoly jsou zahozeny. Jeho přínos bude asi nejvíce na úrovni poskytovatele, kdy pomocí něj bude možno zprostředkovat svým zákazníkům IPv4 Internet.
26
Kapitola 4
Testy vybraných přechodových mechanismů Při rozhodování, které mechanismy budu testovat, jsem vybíral mezi překladačem NAT64 a tunelovacími mechanismy. Zprvu mě zaujal NAT64, jehož specifikace vyšla teprve v dubnu 2011. I přesto již bylo možné najít dvě jeho implementace s otevřeným zdrojovým kódem – TAYGA1 a Ecdysis2 . Po problémech při instalaci a jejich konfiguraci, jsem se nakonec rozhodl pro testování tunelovacích mechanismů, které jsou využitelné pro běžné uživatele, pokud jim jejich poskytovatel neumožňuje přímé připojení do IPv6 sítě. Při výběrů konkrétních mechanismů jsem se rozhodoval podle dostupnosti zakončení tunelu v České republice, nebo alespoň v Evropě. Jako další podmínku jsem zvolil možnost tunely vytvářet i ze sítě, která se nachází za NATem, což není vůbec výjimečná situace v našich podmínkách. Podle těchto kritérií jsem vybral Teredo jako zástupce automatických tunelů. Z řad manuálních to jsou tunely od poskytovatelů SixXS a Freenet6. Instalace a testování tunelovacích mechanismů probíhalo na notebooku (Intel(R) Core(TM)2 Duo 2.0 GHz, 3 GB, PCI-E Gigabit Ethernet 1Gbit/s ) s operačním systém Ubuntu 10.10 – 2.6.35-22 (dále jen notebook), který byl připojen do veřejné internetové sítě připojením od společnosti UPC Fiber Power 10. Toto připojení je pouze přes Ipv4 protokol. Download je 10 Mb/s a upload je 1 Mb/s. Jako druhý stroj byl využit PC (Intel(R) Pentium(R) 4 CPU 2.0 GHz, 1 GB, PRO/100 VE (CNR) Ethernet Controller) s operačním systém Ubuntu 10.10 – 2.6.35-22 (dále jen počítač), který byl umístěn v Sitole3 s připojením do akademické sítě s nesrovnatelně vyšší rychlostí a s nativním připojení jak do IPv4 tak i do IPv6 sítě. Tento stroj byl použit jako server, vůči kterému byly prováděny testy.
1. 2. 3. na
Dostupné na
Dostupné na
Výzkumná laboratoř na Fakultě informatiky, Masarykovy university, specializující se pokročilé síťové protokoly a aplikace.
27
4. Testy vybraných přechodových mechanismů
4.1
Zřízení a instalace tunelovacích mechanismů
Zřízení Teredo spojení je velmi jednoduché i na linuxu. Zde stačí nainstalovat program jménem Miredo. Je dostupný ve standadních repozitářích. To po spuštění vytvoří nové rozhraní jménem teredo a tunel je připraven k použití. Já jsem ve své instalaci ještě změnil v konfiguračním souboru miredo.conf teredo server na teredo.nic.cz. Tento server poskytuje společnost CZ:NIC a je umístěn v Praze. Tím už je Teredo funkční a nakonfigurováno pro prostředí v České republice. Vytvoření tunelu od společnosti Freenet6 v anonymním režimu je snadné jako u Tereda. Stačí si nainstalovat klienta Gogoc. Ten již stačí jen spustit a anonymní tunel je vytvořen. Ale pro své testy jsem zvolil autentizovanou verzi, kdy je nutné se zaregistrovat na webu . Po té je nutno aktualizovat konfigurační soubor na autentizovaný režim. Za to dostanete pevnou IPv6 adresu. Nevýhodou zde je umístění nejblížšího serveru v Amsterdamu, takže to není úplně vhodné pro využívání zdrojů v České republice. Posledním zástupcem je tunel od společnosti SixXS. Zde už je povinná registrace na webu <sixxs.net>. Ta se musí vyplnit poctivě, protože je schvalována ručně. Po úspěšném schválení žádosti je přiděleno uživatelské jméno a heslo. Následně je potřeba se přihlásit do systému přes webové rozhraní a zažádat o vytvoření tunelu za přidělované virtuální kredity. To je také schvalováno ručně. Následuje instalace klienta AICCU, kde se během instalace zadají přihlašovací údaje. Ty se mohou samozřejmě zadat a měnit v konfiguračním souboru aiccu.conf. Poté je již tunel vytvořen automaticky startem programu jako v předchozích případech.
4.2
Testované charakteristiky
Jako testované veličiny jsem zvolil zpoždění paketu v síti, rozptyl zpoždění, propustnost sítě a ztrátovost paketů. Zpoždění paketu je doba, po kterou byl byl jeden paket přenášen přes testovanou síť. To může být měřeno jako jednosměrné nebo obousměrné. Jednosměrné je čas, který uplyne od odeslaní jednoho paketu do přijetí na druhém stroji. Na jeho měření je nutnost mít oba stroje časově synchronizované. Naproti tomu oboustranné zpoždění v sobě zahrnuje cestu k přijímači, zpracování na straně přijímače a cestu zpět k odesílateli. Rozptyl zpoždění je rozdíl zpoždění po sobě následujících paketů stejného spojení. Jedná se o kolísání zpoždění přenášených paketů. Ten je velice důležitý pro řadu aplikací určených pro přenosy zvuku, obrazu nebo také 28
4. Testy vybraných přechodových mechanismů například pro distribuované výpočty. Propustnost je maximální přenosová rychlost, které je možné dosáhnout na dané lince. Tedy kolik bitů za sekundu je možné na dané lince přenést. Ztrátovost paketů se většinou vyjadřuje jako procento paketů, které nedorazí od odesílatele k příjemci v určitém časovém období.
4.3
Testy
Testy byly prováděny na veřejné síti, protože jinak by nebylo možné otestovat parametry spojení různých poskytovatelů. To samozřejmě nese riziko ovlivnění různými anomáliemi na síti, které není možné předvídat. Proto byly testy prováděny v nejmenším vytížení sítě, přibližně od 2 do 5 hodin ráno. Také byly prováděny opakovaně v různé dny. Postupně jsem vyzkoušel testy dělat po dobu 1, 5 a 10 minut. U testů někdy vznikalo ovlivnění na začátku testu vysokými nebo naopak nízkými naměřenými hodnotami. Proto jsem vyřadil možnost dělat testy v délce jedné minuty a zvolil jsem délku testu 5 minut, kde pak již tyto hodnoty nebyly znát a výsledky 5 minutových a 10 minutových testů již tím nebyly ovlivněny a byly stejné. Poté jsem ze všech dosažených výsledků spočítal medián nebo průměr a ty následně použil jako výsledné hodnoty k porovnání. Pro zajímavost jsem testy provedl také v denní špičce a výsledné grafy pro porovnání jsou v příloze C. K testování byly využity nástroje pro měření parametrů sítí Ping a Iperf. Ping je jednoduchý nástroj sloužící především k dotazování na dostupnost určité IP adresy na síti. Zasílá ICMP pakety určité velikosti a v určitých intervalech na zadanou IP adresu. Hostitelské zařízení je po obdržení pošle zpět jako odpověď. Z těchto odpovědí pak zjišťuje oboustranné zpoždění, počet špatných nebo nedoručitelných paketů. Iperf je nástroj pro testování sítě, který pro měření využívá TCP a UDP toky dat. Pracuje jako aplikace klient-server a je tedy nutné ho nainstalovat na obou koncích měřené trasy. Klient odesílá proud TCP nebo UDP paketů na server, ten jej zpracovává, vyhodnocuje a výsledky zasílá zpět na klienta. Data jsou přenášena z klientské operační paměti do paměti serveru. 4.3.1 Zpoždění paketů v síti Pro test zpoždění jsem zvolil nástroj Ping. Měření zpoždění pomocí tohoto nástroje může být nepřesné, protože využívá pakety protokolu ICMP a ty mají jinou prioritu průchodu sítí než pakety protokolů UDP nebo TCP. V mém testu není účelem zjistit přesnou velikost zpoždění, ale porovnat zpoždění tunelovacích mechanismů mezi sebou. Proto jsem se nástroj Ping 29
4. Testy vybraných přechodových mechanismů rozhodl využít. Dotazoval jsem se v intervalu 1 sekundy z notebooku na dostupnost počítače. Test byl prováděn po dobu 5 minut a byl zopakován čtyřikrát. Ve výsledku jsem tedy měl k dispozici celkem 1200 naměřených hodnot pro každý tunel. Z těchto hodnot jsem spočítal jejich medián a ten použil jako hlavní parametr pro jejich srovnání na zpoždění. Pro další srovnání ještě uvádím i maximální a minimální hodnoty dosažených při testování. 140
130
121
120
v ms
100
87,7
80
64,5
71,2
64,7
63,5 60,7
60 40 20
28
20,5 18,6
25,5
0 Ipv4
Freenet6 Medián
Sixxs Min
Teredo
Max
Obrázek 4.1: Graf oboustranného zpoždění Z obrázku 4.1 je vidět, že jednoznačně nejlepší výsledek má tunel od společnosti SixXS. Ten má jen o málo vyšší zpoždění než připojení pomocí IPv4. Bude to nejspíše způsobeno fyzickým umístěním tunel-serveru v Praze. O desítky sekund hůře dopadl tunel Teredo, který také má svůj tunel-server umístěn v Praze, ale zpoždění bylo asi 3-násobné. To může svědčit o náročnějším a delším zpracování paketu. Nejhůře dopadl tunel u společnosti Freenet6, kde je tento výsledek zřejmě ovlivněn umístěním tunel-serveru v nizozemském Amsterdamu. 4.3.2 Rozptyl zpoždění Pro měření rozptylu zpoždění jsem využil nástroj Iperf. V testu jsem použil nespolehlivý protokol UDP, který nevyžaduje potvrzení správného přijetí vysílaných paketů. Měřil jsem odchozí i příchozí spojení. Byly použity pakety o velikosti 64 bytů a 1470 bytů, které byly odesílány v maximální udávané šířce pásma. Tedy u odchozího spojení to bylo 1000 kbits/sec a u příchozího 10000 kbits/sec. Celkem byly provedeny 4 testy v různé dny po dobu trvání 5 minut, kdy hodnota byla brána v 5 vteřinových intervalech. K dispozici 30
4. Testy vybraných přechodových mechanismů tedy bylo celkem 240 hodnot. Z těch byl spočítán medián a ten je brán jako hodnota ke srovnání. 2,5 1,94
čas v ms
2
1,72
1,63
1,5 1
0,76
0,5 0,1
0,12
0,13
0,12
0 Odchozí Ipv4
Příchozí Freenet6
Sixxs
Teredo
Obrázek 4.2: Rozptyl paketů o velikosti 64 bytů Na obrázku 4.2 je ukázána situace s pakety o velikosti 64 bytů. Situace je u příchozího spojení velice vyrovnaná mezi srovnávanými mechanismy. U odchozího připojení pak rozdíly také nejsou nikterak veliké. Nejhorší výsledek zde má Freenet6 a nejlepší Teredo. Zde je potřeba zmínit, že při odesílání velkého počtu malých paketů, byly zaznamenány problémy se spojením u mechanismů Freenet6 a Teredo. Spojení u Freenet6 bylo během vykonávání těchto pětiminutových testů přerušeno 2 krát a test musel být v těchto dvou případech opakován. U Tereda dokonce přerušení nastalo ve všech 4 případech a opakován musel být dokonce několikrát, než se ho podařilo úspěšně dokončit. U Tereda byl navíc problém s doručováním paketů mimo pořadí, kdy tak sice bylo doručeno pouze 0,04 % ze všech paketů v každém 5 minutovém testu, tedy zhruba 2352 z celkových 5882315 přenášených paketů v jednom testu. Ale ostatní dva tunely s tím téměř problémy neměli, doručeny mimo pořadí byly 1–2 pakety v celém testu. Kladem tunelu SixXS je tedy spojení bez výpadku. Jinak jsou výsledky celkem srovnatelné. Na obrázku 4.3 je situace s pakety o velikosti 1470 bytů. U příchozího spojení je situace stále vyrovnaná, i když zde má nejhorší výsledek SixXS a nejlepší Freenet6, ale rozdíly nejsou velké. Situace je jiná u odchozího spojení, kdy opět nejhorší výsledek má SixXS, nejlépe pak dopadl Freenet6 a o něco horší bylo Teredo. Problémy s padáním spojení u Freenet6 ustaly úplně, ale u Tereda během provádění testů spojení jednou spadlo a doručování paketů mimo pořadí se snížilo na 0,01 %. Celkově se s méně pakety o větší velikosti tunely vyrovnaly lépe, ale pořád se vyskytly výpadky spojení u Tereda. 31
4. Testy vybraných přechodových mechanismů 3,5 3
2,98
2,89
čas v ms
2,5 2
1,88
1,66
1,5 1 0,5
0,14
0,18
0,27
0,21
0 Odchozí Ipv4
Příchozí Freenet6
Sixxs
Teredo
Obrázek 4.3: Rozptyl paketů o velikosti 1470 bytů 4.3.3 Ztrátovost paketů Pro měření ztrátovosti paketů byl využit stejný test jako v předchozím případě. Využil jsem tedy opět nástroj Iperf s proudem UDP paketů o velikosti 64 bytů a 1470 bytů, které byly odesílány v maximální šířce pásma. Tedy u odchozího spojení to bylo 1000 kbits/sec a u příchozího 10000 kbits/sec. 70
65,9
64
60
55,6
52,1
53,9
58
50
v%
40
38
34,1
30 20 10 0 Odchozí Ipv4
Příchozí Freenet6
Sixxs
Teredo
Obrázek 4.4: Ztrátovost paketů o velikosti 64 bytů Zde jsem však namísto mediánu zvolil průměr ztracených paketů. Je to z toho důvodu, že u Tereda byly několikrát naměřeny shlukové ztráty ve velikosti až 25 % v oněch měřených 5 vteřinových intervalech při použití paketů o velikosti 1470 bytů. Kdybych použil medián, tak by výsledek pro 32
4. Testy vybraných přechodových mechanismů Teredo byla 0% ztráta, a to by nebylo vypovídající. Z obrázku 4.4 vyplývá, že nejhůře dopadl tunel SiXS, pak Teredo a Freenet6. Výsledky byly podobné jak u odchozího tak i příchozího spojení. Ale jak jsem zmínil již u předchozího testu, spojení SixXS jako jediné se během testování nepřerušilo, kdežto u ostatních dvou nastaly výpadky. 30 24,6
25
v%
20 15
11,8
10 4,3
5 0
0
0,6
0
0
Odchozí Ipv4
3,8
Příchozí Freenet6
Sixxs
Teredo
Obrázek 4.5: Ztrátovost paketů o velikosti 1470 bytů Z obrázku 4.5 je vidět, že situace s pakety o velikosti 1470 bytů je podobná. Nejhůře opět vychází SixXS, jak u příchozího, tak hlavně u odchozího, kde jako jediné dokonce zaznamenává ztrátu. Zde bylo přerušeno spojení pouze jednou a to u testu Tereda. 4.3.4 Rychlost přenosu Pro měření tohoto parametru jsem využil nástroj Iperf a proud TCP paketů. Byly opět provedeny 4 testy po 5 minutách, kdy hodnota byla brána v 5 vteřinových intervalech. Opět tedy bylo k dispozici 240 hodnot, ze kterých byl spočítán medián a pomocí něho bylo uděláno srovnání. Z obrázku 4.6 je vidět, že u příchozího a odchozího spojení se rozdíly příliš neliší. Nejlépe je na tom Freenet6, pak Teredo a nejhůře SixXS. 4.3.5 Celkové shrnutí testů Z testů lze těžko jednoznačně určit nejlepší a nejhorší výsledek. Nejmenší zpoždění je u spojení pomocí tunelu SixXS. Ale v následujícím testu na roztpyl zpoždění má nejhorší výsledky, ale jako jediné nemělo výpadky při zprácování paketů o velikosti 64 bytů, kde nejčastěji vypadávalo spojení pomocí Tereda. V testu na ztrátovost paketů dopadlo opět nejhůře 33
4. Testy vybraných přechodových mechanismů 12000
v Kbits/sec
10000
10512
10066
9568
10040
8000 6000 4000 2000
1049
1049
996
1022
0 Příchozí Ipv4
Odchozí Freenet6
Sixxs
Teredo
Obrázek 4.6: Rychlost přenosů při využití protokolu TCP spojení pomocí tunelu SixXS. Ale i zde musíme zohlednit výpadky konkurentů a navíc u spojení pomocí Tereda vznikaly větší shluky ztracených paketů. V posledním testu byli výsledky jasné a skončily v pořadí Freenet6, Teredo a SixXS. Pokud tedy zohledníme i výpadky spojení a možnost mít pevnou IPv6 adresu, nejlepší variantou zde bude asi spojení pomocí SixXS, i když konkurence v podobě Freenet6 je velká. Kdyby měl zakončení tunelu v České republice, asi by to pak byla nejlepší volba. Teredo se spíše hodí na první zkoušky s IPv6 protokolem a to i proto, že zde není možnost mít trvale přidělenou IPv6 adresu.
34
Kapitola 5
Závěr Nový protokol IPv6 neřeší jenom problém s nedostatkem IPv4 adres, ale po dlouhém vývoji vznikl protokol značně odlišný od předchozí verze. Přínáší sebou řadu vylepšení s důrazem na jednoduchost, rychlost, bezpečnost a mobilitu. K posouzení těchto vlastností v praxi musí nejdříve dojít k větší implementaci. Ale situace není v nasazení zatím optimální, i když už se pomalu začíná zlepšovat. Vznikají služby pro IPv6 a možnosti připojení k IPv6 síti jsou již také k dispozici. Zatím je získat přímé připojení jednodušší hlavně pro velké zákazníky. Ale i pro menší podniky a pro domácnosti již zde existují použitelné mechanismy pro přístup k IPv6 službám, když poskytovatel Internetu stále toto spojení nenabízí. Pro menší podniky se zde nabízejí možnosti připojit svou IPv6 síť třeba za využití překladacích mechanismů nebo pomocí automatických tunelů. Pro domácnosti a jednotlivce, kteří chtějí vyzkoušet IPv6 Internet a začít ho seriózně používat, je asi nejjednodušší možnost využít manuálních tunelů. Při své práci jsem se vyzkoušel, že některé možnosti, jak si zařídit IPv6 tunel skrz IPv4 síť, nejsou příliš složité. Takže se tyto možnosti nabízejí i méně zdatným uživatelům PC. Sice z testů, které jsem provedl, je vidět určité zhoršení měřených parametrů oproti připojení pomocí IPv4. Ale zase tato zhoršení nejsou taková, aby se tunelování nedalo využít při běžné práci s Internetem. Takže podle mne již není důvod oddalovat seznamování se IPv6, i když stále poskytovatel Internetu toto spojení nenabízí.
35
Literatura [1] SATRAPA, P. IPv6 - Internetový protokol verze 6. Praha : CZ.NIC, 2008. [2] HINDEN, R.; DEERING, S. IP Version 6 Addressing Architecture [online]. 2006-02, [cit. 2011-10-21]. Dostupné z . [3] IANA Assigned Internet Protocol Numbers [online]. 2011-11-01, [cit. 2011-11-15]. Dostupné z . [4] IPV6.CZ DNS [online]. 2008-11-01, [cit. 2011-10-21]. Dostupné z . [5] PODERMAŃSKI, T.; GRÉGR, M. IPv6 Mýty a skutečnosti, dil V. Zjednodušené hlavičky [online]. 2011-03-10, [cit. 2011-10-23]. Dostupné z . [6] SATRAPA, P. SEND chrání objevování sousedů pro IPv6 [online]. 200606-17, [cit. 2011-10-25]. Dostupné z . [7] KOLEKTIV AUTORŮ IPv6 Tunnel Broker [online]. Leden 2011, [cit. 2011-11-30]. Dostupné z . [8] BLANCHET, M.; PARENT, F. IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) [online]. 2010-02, [cit. 2011-10-21]. Dostupné z . [9] CARPENTER, B.; MOORE, K. Connection of IPv6 Domains via IPv4 Clouds [online]. 2001-02, [cit. 2011-10-21]. Dostupné z . [10] IPV6.CZ SIIT [online]. 2008-11-02, [cit. 2011-10-21]. Dostupné z . 36
5. Závěr [11] IPV6.CZ NAT-PT [online]. 2008-11-02, [cit. 2011-10-21]. Dostupné z . [12] SATRAPA, P. Vyšla definice [cit. 2011-10-25]. Dostupné z vysla-definice-nat64/>.
NAT64 [online]. 2011-05-05,
37
Příloha A
Bezpečné objevování sousedů (SEND) Mechanismus objevování sousedů samozřejmě může cílem různých druhů útoků. Jako reakce na tyto problémy již zmíněný SEND, jež je definován v RFC 3971. Má poskytnout dostatečnou úroveň zabezpečení při výměně zpráva a zároveň se snaží minimalizovat nároky na zúčastněné. Přidává několik nových voleb a popisuje chování jednotlivých účastníků. [1] Využívá asymetrickou kryptografii a digitální podpisy. Ale i zde vzniká problém, jak spolehlivě zjistit veřejný klíč. SEND v tomto směru nabízí dvě možnosti. Kryptograficky generované adresy (CGA), kdy se adresa rozhraní odvodí z veřejného klíče dotyčného počítače. Veřejný klíč se spojí s několika dalšími položkami, poté se hodnota zpracuje hashovací funkcí a část výsledku se použije jako identifikátor rozhraní. Cílem je zabránit falšování ohlášení sousedů. K ohlášení souseda se připojí datová struktura s veřejným klíčem. To umožňuje ověřit, že adresa stroje je skutečně odvozena z veřejného klíče. Vše je pak podepsáno soukromým klíčem. Výhodou tohoto přístupu je, že nejsou potřeba žádné informace navíc. Volby CGA a RSA podpis jsou připojeny přímo ve vlastní zprávě. Na druhou stranu toto není možné aplikovat na libovolné adresy, ale pouze na adresy vytvořené podle principu CGA. Takže nelze ochránit adresy vzniklé podle EUI-64 nebo Privacy Extension. Ztrátě soukromí je možné zabránit, když si počítač vytvoří více dvojic klíčů, které díky vstupu náhodné veličiny do výpočtu CGA nejsou viditelně svázány. [6] Druhou možností zabraňující nekorektnímu ohlašování směrovačů jsou certifikáty pro směrovače. Lokální autorita udělí směrovači certifikát. K ověření certifikátů potřebuje dotyčný stroj veřejný klíč dané autority. Je zde připuštěno budování certifikačních cest. SEND kvůli velikosti certifikátů a jejich dlouhodobější platnosti definuje dva nové typy zpráv, jimiž může každý stroj požádat o certifikační cestu a přijmout odpověď. [6] Zatím však mechanismus SEND má jen velmi malou podporu na straně směrovačů a spíše jen experimentální implementace na straně klientů. Proto zatím lze o SENDu mluvit pouze jako o potencionálním prostředku pro sítě nové generace. 38
Příloha B
IPsec B.1
Základní principy použití IPSECu
Bezpečností hlavičky můžeme využívat ve dvou režimech. V transportním režimu se vloží přímo mezi rozšiřující hlavičky daného paketu a následné je paket odeslán. V tunelujícím režimu se celý původní paket zabalí jako data do nového paketu, který obsahuje nové hlavičky včetně těch bezpečnostních. Datagramy takto nemusí být chráněny po celé cestě, ale je možno takto chránit třeba všechny pakety směřující z jedné sítě (z jednoho směrovače) do druhé sítě (k druhému směrovači). Pak tyto směrovače nazýváme bezpečnostní brány. Jak je již zmíněno výše, důležitá je také bezpečnostní asociace (Security Association, SA). Je to jakési virtuální spojení dvou počítačů za účelem bezpečně přenést data potřebné k zajištění vlastního přenosu. Jsou to například: použitý bezpečnostní protokol (AH nebo ESP) a jeho režim šifrovací algoritmus a klíče pro toto spojení, ochranné prvky proti opakování. Jelikož se jedná o jednosměrné spojení, je potřeba pro každý směr jedna SA. Všechno řídí takzvaná databáze bezpečnostní politiky. Je to soubor pravidel, podle kterých se posuzuje každý příchozí a odchozí paket. Ten se buď zahodí, normálně zpracovat nebo podrobit paket IPsec.
B.2
Authentication Header
Úkolem této hlavičky je ověřit, zda posílaný paket je skutečně odeslaný počítačem, jehož adresa je uvedena v hlavičce a že po cestě nebyl nijak změněn. Nepovinně také může zajišťovat ochranu proti opakování. Odesílatel vloží do záhlaví paketu hlavičku AH, vyplní jeho položky a vypočte autentizační data. Příjemce pak také provede výpočet autentizačních d2373at a porovná, zda je výsledek shodný, který je uveden v záhlaví AH. Pokud se shoduje, je odesílatel autentizován, pokud ne, tak je paket bez upozornění odesílatele zahozen. Když je navíc využívána ochrana proti opakování, je navíc kontrolováno i pořadové číslo paketu. [1] 39
B. IPsec
B.3
Encapsulating Security Payload
ESP je komplexnější a nabízí zajištění autenticity, kontrolu původnosti dat, ochranu proti opakování a navíc ještě šifrování obsahu paketu. V transportním režimu má ESP hlavička jednu zvláštnost, protože obaluje skoro celý datagram do sebe. Před ní jsou jen hlavičky určené pro každého po cestě, směrování a fragmentaci. V tunelovacím režimu jednoduše obalí datagram novým, jehož poslední hlavičkou je ESP. Odeslání datagramu probíhá následovně: odesílatel určí pozici, do které vloží záhlaví ESP, v případě potřeby doplní datagram vycpávkou a zašifruje. Dál vygeneruje pořadové číslo, v případě autentizace a kontroly integrity vypočítá kontrolní hodnotu a uloží ji do položky autentizační data v záhlaví ESP. Příjemce pak vyhledá odpovídající bezpečnostní asociaci, zkontroluje pořadové číslo a vypočte autentizační data. Pokud něco z toho selže, je paket zahozen. V případě úspěchu příjemce dešifruje paket, odstraní ESP hlavičku a paket dál zpracuje. [1]
B.4
Správa bezpečnostních asociací
K tomu účelu se využívá již výše zmíněný IKEv21 . Strany se nejdříve musí dohodnout na kryptografických algoritmech, jejich parametrech a používaných klíčích. Pro výměnu těchto informací si IKEv2 nejdříve vytvoří svou bezpečnostní asociaci, nazývaná IKE_SA, podle které je další komunikace šifrována. Komunikace probíhá ve výměnách. Ve specifikaci jsou definovány čtyři výměny, dvě pro zahájení, jedna ke správě a jedna pro výměnu informací. Každá výměna obsahuje návrh parametrů a odpověď s výběrem optimálních pro druhou stranu. Pro vytvoření sdíleného tajemství se využívá Diffie-Hellmanův algoritmus2 . Na zahájení komunikace se provádí dvě výměny. První se označuje IKE_SA_INIT, kde se ustaví bezpečnostní asociace IKE_SA. V ní se obě strany domluví na parametrech této asociace a také si vymění hodnoty pro Diffie-Hellmanův algoritmus. Po výpočtu sdíleného tajemství další komunikace probíhá chráněná IKE_SA. Druhá výměna se značí IKE_AUTH, která slouží k ověření totožnosti účastníků a k vytvoření první asociace využívané pro výměnu dat. Pro navázání dalších asociací slouží výměna CREATE_CHILD_SA.
1. 2.
Popsán v RFC 4306 Popsán v RFC 2631
40
Příloha C
Měření v denní špičce Tyto měření proběhla podle stejných pravidel jak jsou uvedena v práci, pouze v jinou dobu a to od 2 do 6 hodin odpoledne.
C.1
Zpoždění paketů v síti 140
129
120 100
91,4
88,6
83,6
v ms
80
67,9 56,9
60
48,3
40 20
18,4
25,3
16,7
23,2
25,5
0
Ipv4
Freenet6 Medián
Sixxs Max
Teredo
Min
Obrázek C.1: Graf oboustranného zpoždění
41
C. Měření v denní špičce
C.2
Rozptyl zpoždění 2,5 1,92
2
1,86
čas v ms
1,66 1,5 1
0,77
0,5 0,1
0,14
0,13
0,13
0 Odchozí Ipv4
Příchozí Freenet6
Sixxs
Teredo
Obrázek C.2: Rozptyl paketů o velikosti 64 bytů 4,5
4,23
4
3,47
3,5
čas v ms
3
2,75
2,63
2,5 2 1,5 1 0,5
0,15
0,16
0,25
0,14
0 Odchozí Ipv4
Příchozí Freenet6
Sixxs
Teredo
Obrázek C.3: Rozptyl paketů o velikosti 1470 bytů
42
C. Měření v denní špičce
C.3
Ztrátovost paketů 70
65,8
64
60
54,9
52,3
57,3
53,8
50
v%
40
37,8
34,3
30 20 10 0 Odchozí Ipv4
Příchozí Freenet6
Sixxs
Teredo
Obrázek C.4: Ztrátovost paketů o velikosti 64 bytů 30 25
25
v%
20 15 11 10 3,7
5 0
0
0,6
0
0
Odchozí Ipv4
3,5
Příchozí Freenet6
Sixxs
Teredo
Obrázek C.5: Ztrátovost paketů o velikosti 1470 bytů
43
C. Měření v denní špičce
C.4
Šířka pásma 12000
v Kbits/sec
10000
10512
10066
9607
10053
8000 6000 4000 2000
1049
1049
976
1032
0 Příchozí Ipv4
Odchozí Freenet6
Sixxs
Teredo
Obrázek C.6: Rychlost přenosů při využití protokolu TCP
44
Příloha D
Seznam důležitých RFC dokumentů Všechny RFC dokumenty jsou dostupné na oficiálních webových stránkách organizace IETF . ∙
RFC 1883: Internet Protocol, Version 6 (IPv6) Specification. 1995
∙
RFC 1884: IP Version 6 Addressing Architecture. 1995
∙
RFC 2373: IP Version 6 Addressing Architecture. 1998
∙
RFC 3513: Internet Protocol Version 6 (IPv6) Addressing Architecture. 2003
∙
RFC 3879: Deprecating Site Local Addresses. 2004
∙
RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6. 2007
∙
RFC 4291: IP Version 6 Addressing Architecture. 2006
∙
RFC 3596: DNS Extensions to Support IP Version 6. 2003
∙
RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. 1998
∙
RFC 4861: Neighbor Discovery for IP version 6 (IPv6). 2007
∙
RFC 4862: IPv6 Stateless Address Autoconfiguration. 2007
∙
RFC 6106: IPv6 Router Advertisement Options for DNS Configuration. 2010
∙
RFC 3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6). 2003
∙
RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6. 2004 45
D. Seznam důležitých RFC dokumentů ∙
RFC 6275: Mobility Support in IPv6. 2011
∙
RFC 3068: An Anycast Prefix for 6to4 Relay Routers. 2001
∙
RFC 2529: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. 1999
∙
RFC 5214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). 2008
∙
RFC 4380: Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs). 2006
∙
RFC 4966: Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status. 2007
∙
RFC 6146: Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. 2011
∙
RFC 6145: IP/ICMP Translation Algorithm. 2011
∙
RFC 6147: DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. 2011
∙
RFC 3971: SEcure Neighbor Discovery (SEND). 2005
∙
RFC 4306: Internet Key Exchange (IKEv2) Protocol. 2005
∙
RFC 2631: Diffie-Hellman Key Agreement Method. 1999
46
