Protokol IPv6 a jeho praktické využití

Transkript

1 Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií Protokol IPv6 a jeho praktické využití Diplomová práce Autor: Bc. Ondřej Hotský Informační technologie a management Vedoucí práce: Ing. Vladimír Beneš Nové Strašecí duben, 2013

2 Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Novém Strašecí dne Bc. Ondřej Hotský

3 Tímto bych chtěl poděkovat mému vedoucímu diplomové práce Ing. Vladimíru Benešovi za odborné vedení při vypracování této diplomové práce a za cenné rady. Dále bych chtěl poděkovat své rodině za podporu, kterou mi poskytovala po celou dobu studia.

4 Anotace Tato diplomová práce Protokol IPv6 a jeho praktické využití se zabývá popisem charakteristiky, adresace, datagramu a statické konfigurace protokolu IPv6. Část této práce popisuje současnou situaci protokolu IPv6 na trhu a uvádí jednotlivé důvody relativně pomalého zavádění tohoto protokolu. Samostatnou kapitolu pak tvoří popis přípravy a realizace implementace protokolu IPv6 do konkrétního síťového prostředí firmy, kterou autor v dané firmě realizoval. Klíčová slova Protokol IPv6, adresace, datagram, konfigurace, implementace Annotation The aim of this thesis IPv6 protocol and its practical use is to describe characteristics, addressing, datagram and static configuration of protocol IPv6. Part of this thesis describes actual situation of protocol IPv6 on the market and presents various reasons for the relatively slow implementation of this protocol. Separate chapter presents the description of the preparation and implementation of protocol IPv6 in specific network environment of the company, which were realized in this company by the author of this thesis. Key words: Protocol IPv6, Addressing, Datagram, Configuration, Implementation

5 Obsah Úvod... 8 Zvolené metody zpracování Charakteristika protokolu IPv Protokol IP Co je protokol IPv Vznik protokolu IPv ICMPv Objevování sousedů Automatická konfigurace Stavová konfigurace Bezstavová konfigurace DNS a IPv Přechodové mechanismy Hodnocení situace na trhu Adresace protokolu IPv Adresy IPv Adresní prostor IPv Tvar a zápis IPv6 adresy Příklad zápisu IPv6 adresy Prefix adresy IPv Dosah adres Rozdělení IPv6 adres Globální individuální adresy Lokální adresy IPv6 adresy obsahující IPv4 adresy Skupinové adresy... 44

6 2.6.5 Výběrové adresy Speciální adresy Povinné adresy uzlu Výběr adres Datagram protokolu IPv Úvod do datagramu IPv Položky základní hlavičky datagramu Verze Třída provozu Značka toku Délka dat Další hlavička Maximální počet skoků Zdrojová a Cílová adresa Další hlavičky datagramu Pořadí hlaviček Volby Směrování Fragmentace Jumbogram Konfigurace protokolu IPv Microsoft Windows XP Windows Vista, Windows 7 a Windows Linux Implementace protokolu IPv6 do konkrétního síťového prostředí Popis síťového prostředí... 84

7 5.2 Potřeba protokolu IPv Přípravná fáze Prozkoumání kompatibility Volba strategie přechodu Volba zabezpečení Příprava adresního plánu Způsob zavedení na základě zvolené strategie Odhad finanční náročnosti Implementační fáze Konfigurace virtuálního serveru Konfigurace směrovače Konfigurace přepínače Konfigurace bezdrátového přístupového bodu Konfigurace ostatních síťových zařízení v kanceláři Závěrečné zhodnocení Seznam použité literatury Seznam obrázků Seznam zkratek Přílohy

8 Úvod Dnešní doba je charakteristická velkým rozvoj em informačních technologií, informačních systémů a zařízení, jejichž základní vlastností je schopnost vzájemně komunikovat a interagovat. Aby tato komunikace a interakce byla účinná, je nutné, aby existovalo vhodné síťové prostředí, které takovéto akce umožňuje. V rámci tohoto síťového prostředí je pak nutné, aby pro zajištění dobré a efektivní komunikace byla tato síťová zařízení dobře dosažitelná prostřednictvím určité síťové adresy. V současnosti tuto adresaci zajišťuje dlouhodobě využívaný protokol IPv 4. Hlavní nevýhodou tohoto protokolu je však již současným potřebám nedostačující adresní prostor. Tento a mnoho dalších problémů se snaží řešit nástupce protokolu IPv4, tedy protokol IPv6. Cílem této práce je tedy právě prezentace protokolu IPv6, která zahrnuje charakteristiku tohoto protokolu, popis adresace, popis možností konfigurace ve vyjmenovaných prostředích a zhodnocení situace tohoto protokolu na trhu. Kromě prezentace protokolu IPv6 si tato práce také klade za cíl popis a realizaci implementace protokolu IPv6 do konkrétního síťového prostředí firmy, která bude skutečně v dané firmě vykonána. 8

9 Zvolené metody zpracování Tato práce byla zpracována v podstatě pomocí standardních metod zpracování. Zpracování, resp. zkoumání dané problematiky probíhalo nastudováním příslušných literárních zdrojů a následným popsáním této problematiky. Za stěžejní byly především považovány knižní zdroje a poznatky z nich získané byly doplňovány a kontrolovány pomocí jednotlivých webových zdrojů, především pak pomocí příslušných dokumentů RFC. Při zpracování části této práce, která se zabývá implementací protokolu IPv6 do konkrétního sí ťového prostředí, pak byly především využity autorovy znalosti a zkušenosti s přípravou a realizací zavedení protokolu IPv6 do daného síťového prostředí. 9

10 1 Charakteristika protokolu IPv6 1.1 Protokol IP Dříve než budou v této práci zmiňovány jednotlivé verze protokolu IP (Internet Protocol), je nutné zmínit alespoň obecně, k čemu vlastně takový protokol IP slouží. Toto shrnutí bude velice stručné, protože tato práce předpokládá, že je čtenář obeznámen se základy síťové komunikace. Jedná se o jeden ze základních protokolů použitých při komunikaci v počítačových sítích. Je natolik používaný, že lze vyslovit předpoklad, že každý uživatel sítě Internet se s ním již setkal, byť toto setkání nemuselo být vědomé. Tento komunikační protokol se nachází na úrovni třetí, tedy na síťové vrstvě referenčního modelu ISO/OSI. Dále ho lze zařadit do rodiny protokolů TCP/IP (Transmission Control Protocol/Internet Protocol ). Jako takový zodpovídá za doručování a směrování paketů ( datagramů) od zdroje např. uživatelského počítače až k počítači cílovému, kterým může být např. server hostující nějaký webový obsah, napříč sítěmi IP. Předpokladem této komunikace je přidělení alespoň lokální unikátní IP adresy každému z účastníků této komunikace. Data mezi účastníky této komunikace jsou přenášena pomocí tzv. paketů, resp. datagramů, které tvoří základní jednotku komunikace tohoto protokolu a jejich směrování probíhá prostřednictvím zdrojových a cílových IP adres. Samotné doručování datagramů pracuje na principu nejlepšího úsilí (Best Effort), kdy se všechny aktivní síťové prvky, které se zabývají směrováním na dané trase, snaží posunout datagram blíže k cílovému síťovému zařízení dle svých nejlepších možností. Tento princip ovšem neposkytuje v podstatě žádné absolutní záruky doručení. Samotný datagram se k cíli nemusí vůbec dostat, nebo může do cíle dorazit hned několikrát a s časovým zpožděním. Záruky doručení jsou implementovány až v protokolech vyšší vrstvy architektury sítě. 10

11 1.2 Co je protokol IPv6 IPv6 (Internet Protocol Version 6) je označení jednoho a prozatím jediného z možných kandidátů na nástupce protokolu IPv4 ( Internet Protocol Version 4), který je využíván pro komunikaci v prostředí sítě Internet. Protokol IPv6 byl již od počátku koncipován jako náhrada za v současnosti používaný protokol IPv4. Jako takový přináší především opravdu velké rozšíření adresního prostoru (jeden z hlavních důvodů jeho vzniku), což znamená, že v podstatě každé síťové zařízení může mít svoji unikátní IPv6 adresu, která je jednoznačně identifikovatel ná v rámci celosvětové sítě Internet. Dále reaguje na vzrůstající přenosové rychlosti a moderní komunikační technologie, kterým protokol IPv4 již ne zcela vyhovuje. Při návrhu protokolu IPv6 byly stanoveny dle [41] následující cíle: Dostatečně bohatý adresní prostor pokud možno by již nikdy neměla nastat nouze o adresy. Podpora služeb se zaručenou kvalitou. Design odpovídající vysokorychlostním sítím. Bezpečnostní mechanismy přímo v IP. Podpora mobilních zařízení. Automatický konfigurace. Kooperace s IPv4 a co nejhladší přechod ze stávajícího protokolu na nový. Kromě velkého množství kladů přináší protokol IPv6 i své problémy, nejvýznamnějším z nich je, že není zpětně kompatibilní s protokolem IPv4. V důsledku toho má uživatel síťového zařízení, které podporuje pouze protokol IPv6, velice omezený výběr zdrojů a služeb, které může využívat [41]. Tato situace se však s postupným nasazováním protokolu IPv6 zlepšuje. 11

12 1.3 Vznik protokolu IPv6 Nepřímo lze považovat za počátek cesty protokolu IPv6 rok 1992, kdy konsorcium IETF (Internet Engineering Task Force) podalo prostřednictvím dokumentu RFC 1550: IP: Next Generation (IPng) White Paper Solicitation [9] výzvu pro zpracování návrhu IPng (The IP: next generation). Následovalo ustanovení pracovních skupin, které měly za úkol definovat a vytvořit IPng. Motorem pro vznik nového internetového protokolu byl v té době rychle se tenčící adresní prostor protokolu IPv4. V roce 1995 dochází k vydání sady RFC (Request for Comments), která definuje základy nového internetového protokolu. Od tohoto okamžiku se již nehovoří o IPng, ale již o protokolu IPv6. V rámci dané sady RFC je zásadní především RFC 1883: Internet Protocol, Version 6 (IPv6) Specification [13]. Následující vývoj a rozšíření protokolu IPv6 však neprobíhalo tak rychle, jak bylo původně předpokládáno. Jedním z důvodů zpomalení rozvoje protokolu IPv6 bylo zavedení směrování na základě síťové masky a překladu síťových adres, neboli technologie NAT ( Network Address Translation) u protokolu IPv4. Pomocí těchto technologií došlo k dočasnému potlačení nedostatku adres v rámci adresního prostoru protokolu IPv4. Nicméně vývoj protokolu IPv6 neustal a v následujících letech došlo k vydání různých revizí a přidávání dalších prvků proto kolu IPv6 a především se začala dostávat podpora protokolu IPv6 do řady používaných operačních systémů a síťových zařízení. 1.4 ICMPv6 Novinku v protokolu IPv6 také představuje přepracovaná verze protokolu ICMP (Internet Control Message Protocol), tedy ICMPv6 (Internet Control Message Protocol Version 6), která je definovaná v rámci RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [10]. Protože mnoho mechanismů v rámci protokolu IPv6 staví na protokolu ICMPv6, musí všechna zařízení, která podporují protokol IPv6, podporovat také protokol ICMPv6. Což také 12

13 značí to, že úloha protokolu ICMPv6 je v protokolu IPv6 mnohem větší, než tomu bylo ve vztahu protokolu IPv4 a protokolu ICMP. Protokol ICMPv6 je v rámci IPv6 používán zejména pro výměnu provozních informací, testování dosažitelnosti a pro hlášení jednotlivých chybových stavů. Protokol ICMPv6 je dále využíván systémem objevování sousedů a podporou skupinových adres. Zprávy protokolu ICMPv6 jsou distribuovány pomocí datagramu protokolu IPv6. V rámci protokolu ICMPv6 existují dvě skupiny zpráv. První skupinu tvoří chybové zprávy a druhou informační zprávy. Chybové zprávy obsahují čtyři druhy chybových zpráv: Nedosažitelnost, Nadměrný datagram, Vypršení životnosti datagramu a Chybný datagram. Chybová zpráva Nedosažitelnost informuje o situaci, kdy byl směrovači doručen datagram, jehož cílová adresa je nedosažitelná. Chybová zpráva Nadměrný datagram informuje odesílatele datagramu o tom, že se v přenosové cestě vyskytuje úsek, jehož hodnota MTU je nižší, než je velikost datagramu. Chybovou zprávu Vypršení životnosti datagramu zasílá směrovač, pokud pro daný datagram vypršela doba jeho životnosti. Daná zpráva se může objevit i v případě, kdy směrovač neobdržel všechny fragmentované části datagramu. Chybová zpráva Chybný datagram informuje o situaci, kdy příjemce obdržel datagram s takovými parametry, kterým nerozumí. Mezi informační zprávy lze zařadit zprávy Echo a Odpověď na echo, což jsou klasické zprávy využívané pomocí rozšířeného a známého programu ping. Dále pak se jedná o zprávy Dotaz a Odpověď na dotaz, prostřednictvím kterých lze získat základn í informace o síťovém zařízení a jako takové slouží především pro účely správy sítě. Další typy ICMPv6 zpráv je možné nalézt v rámci jednotlivých mechanismů, které využívá protokol IPv6. Do protokolu ICMPv6 byly zabudovány i některé bezpečností prvky, jejichž účelem je omezení zneužití ICMPv6 zpráv. Tyto bezpečností prvky definují např. minimální časovou prodlevu, která se musí vyskytovat mezi jednotlivými zprávami, nebo přidání šifrovacího mechanismu do jednotlivých zpráv protokolu ICMPv6. 13

14 1.5 Objevování sousedů V rámci protokolu IPv6 je definován nový systém pro objevování sousedů ND (Neighbor Discovery), který pro svou činnost využívá především výše zmíněných zpráv protokolu ICMPv6 a skupinových adres. Obdobu tohoto systému představuje u protokolu IPv4 pr otokol ARP (Address Resolution Protocol), pomocí něhož je možné zjistit MAC (Media Access Control) adresu některého ze sousedících síťových zařízení za použití adresy IP daného síťového zařízení. Systém objevování sousedů je definovaný v rámci RFC 4861: Neighbor Discovery for IP Version 6 (IPv6) [30] a daný systém dle [2] slouží k následujícím účelům: Zjišťování linkových adres uzlů ve stejné lokální síti. Rychlé aktualizace neplatných položek a zjišťování 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ů. Detekce duplicity adres. Systém objevování sousedů využívá ke své činnosti pěti druhů ICMP zpráv protokolu ICMPv6. Jedná se o tyto druhy zpráv: Výzva sousedovi (Neighbor Solicitation), Ohlášení souseda (Neighbor Advertisement), Výzva směrovači (Router Solicitation), Ohlášení směrovače (Router Advertisement) a Přesměrování (Redirect). Pokud se jedná o hledání linkové adresy, systém objevování sousedů využívá pro tyto potřeby skupinové adresy ff02:0:0:0:0:1:ff00::/104. Pokud tedy určité síťové zařízení hledá linkovou adresu určité adresy IPv6, použije posledních dvacet čtyři bitů z dané IPv6 adresy a ty připojí za výše specifikovaný prefix, tak je získána konkrétní skupinová adresa. Na tuto skupinovou adresu následně odešle dané síťové zařízení ICMP zprávu typu Výzva sousedovi. Za předpokladu, že je síťové zařízení, které patří do dané 14

15 skupiny aktivní a danou zprávu přijme, odp oví na ní ICMP zprávou Ohlášení souseda. Daná zpráva pak obsahuje informace o příslušné linkové adrese. V rámci tohoto systému by si měla síťová zařízení vytvářet a udržovat aktuální databázi svých sousedů, neboli jejich cache. Pokud dojde u některého síťového zařízení ke změně údajů týkajících se linkové adresy, může toto zařízení, aniž by předtím bylo tázáno, vyslat ICMP zprávu Ohlášení souseda, aby na tuto skutečnost upozornilo ostatní síťová zařízení a to prostřednictvím skupinové adresy pro všechny uzly ff02::1. Aktualizace cache sousedů proběhne pouze u těch sousedních síťových zařízení, která mají danou IPv6 adresu uloženou v rámci dané cache, ostatní síťová zařízení danou zprávu ignorují. V rámci systému objevování sousedů funguje systém, který se neustále snaží ověřovat dostupnost sousedů, se kterými dané síťové zařízení komunikuje. Daný systém existuje také z důvodu, že se cache sousedů nedá považovat za stoprocentně spolehlivý mechanismus. K určení dosažitelnosti souseda jsou definovány dva principy. První princip využívá informací od vyšší síťové vrstvy o tom, že úspěšně probíhá komunikace s daným sousedem a tím pádem je jasné, že je daný soused dostupný. Druhý princip ověřuje dostupnost sousedů za pomoci vlastních prostředků a to tak, že aktivně zasílá výzvy daným sousedům a pokud na ně daní sousedé odpovědí, je jasné, že jsou dostupní. V rámci tohoto systému je definováno pět stavů, ve kterých se sousedé daného síťového zařízení mohou v rámci cache sousedů nacházet. Jedná se o stavy: Nekompletní (Incomplete), Dosažitelný (Reachable), Prošlý (Stale), Odložený (Delay) a Testovaný (Probe). Stav Nekompletní dává najevo, že daná linková adresa není známa, ale že již byla odeslána patřičná výzva sousedovi, na kterou však so used doposud neodpověděl. Pokud nedorazí žádná odpověď, je daný záznam vymazán. Stav Dosažitelný signalizuje, že je známa příslušná linková adresa a daný soused je dosažitelný. Stav Prošlý signalizuje, že vypršel časový limit dostupnosti daného souseda. Stav Odložený signalizuje, že je daný záznam prošlý a že se aktuálně čeká na potvrzení dostupnosti daného souseda. Stav Testovaný signalizuje čekání na odpověď na zprávu Výzva sousedovi. Za 15

16 předpokladu, že daná odpověď dorazí, je stav změněn na Dosažitelný, pokud odpověď nedorazí, je daný záznam vymazán. 1.6 Automatická konfigurace Automatická konfigurace představuje jednu z dalších novinek, které byly uvedeny v rámci protokolu IPv6 a která staví na principu plug and play. Obecně lze tedy říci, že pokud připojíme síťové zařízení, kterým může být v našem případě např. osobní počítač, do sítě, počítač se sám postará o zjištění parametrů sítě, které jsou potřebné pro komunikaci s okolními sítě a sám si vygeneruje příslušnou IPv6 adresu. Automatická konfigurace se v rámci protokolu IPv6 vyskytuje ve dvou typech Stavová konfigurace Prvním typem je Stavová konfigurace, která je v podstatě následníkem protokolu DHCP (Dynamic Host Configuration Protocol), který je hojně používán v rámci sítí protokolu IPv4. V rámci protokolu IPv6 byl protokol DHCP přepracován a označuje se jako DHCPv6 (Dynamic Host Configuration Protocol for IPv6), jeho definici lze nalézt v rámci RFC 3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [8]. I když se jedná o novou verzi protokolu DHCP, je princip jakým obě verze těchto protokolů pracují v podstatě totožný. Základem tohoto principu je síťové zařízení, na kterém je spuštěn server dané verze protokolu DHCP, který se stará o přidělování parametrů konfigurace sítě jednotlivým klientským síťovým zařízením. Pokud tedy chce dané klientské zařízení znát příslušné konfigurační parametry platící pro danou síť, odešle do tét o sítě požadavek, na nějž mu odpoví DHCP server zaslání m příslušných konfiguračních parametrů. DHCPv6 může pracovat ve dvou režimech konfigurace, tedy ve stavovém režimu (Stateful Mode) a v bezstavovém režimu (Stateless Mode). V rámci stavového režimu DHCP server může přidělovat svým klientům všechny konfigurační parametry pro jejich fungování v rámci dané sítě, tedy kromě příslušné IPv6 adresy, prefixu sítě a výchozí brány, také např. 16

17 adresy DNS (Domain Name System) serverů a NTP (Network Time Protocol) serverů. V rámci bezstavového režimu je kombinováno použití DHCPv6 a Bezstavové konfigurace. Pomocí Bezstavové konfigurace získají síťoví klienti konfigurační parametry typu IPv6 adresy, prefixu sítě a výchozí brány. Zbylé konfigurační parametry, které není schopná dodat síťovým klientům Bezstavová konfigurace, jsou zprostředkovány klientům prostřednictvím DHCPv6. Tato dodatečná konfigurace je prováděna prostřednictvím k tomu vyhrazené položky O (Other Stateful Configuration) v rámci zprávy Ohlášení směrovače. Pokud síťový klient zaregistruje tuto položku v rámci dané zprávy, odešle svůj požadavek na doplňující konfigurační parametry příslušnému DHCPv6 serveru Bezstavová konfigurace Druhým typem automatické konfigurace je tzv. Bezstavová konfigurace, neboli SLAAC (Stateless Address Autoconfiguration). Bezstavová konfigurace je prezentována jako součást systému objevování sousedů. Tento způsob automatické konfigurace již představuje skutečnou novinku, kterou přináší protokol IPv6. Bezstavová konfigurace se zaměřuje na fakt, že každá síť (např. lokální síť) má svůj hlavní směrovač. Hlavní směrovač ze své pozice zná všechny konfigurační parametry, které jsou potřebné pro komunikaci s ostatními sítěmi. Tyto konfigurační parametry jsou pomocí daného směrovače rozesílány v náhodných časových intervalech v rámci sítí, ke kterým je připojen a do kterých je odesílání těchto informací povoleno. Pro veškerou komunikaci je v rámci Bezstavové konfigurace protokolu IPv6 využit protokol ICMPv6. K odesílání těchto konfiguračních parametrů používá směrovač v rámci Bezstavové konfigurace tzv. Ohlášení směrovače, neboli RA ( Router Advertisement) Klientskému zařízení tak stačí v podstatě pouze naslouchat, aby zjistilo konfigurační parametry dané sítě. Jedná se především o konfigurační parametry typu síťový prefix a výchozí brána. Identifikátor rozhraní v rámci adresy IPv6 si je klient schopen odvodit sám, např. pomocí EUI-64 (64-bit Extended Unique Identifier), nebo pomocí Privacy Extensions. Pro 17

18 zajištění větší dynamičnosti tohoto typu autokonfigurace může klientské zařízení vyslat do dané sítě požadavek, kterým žádá o zaslání příslušných konfiguračních parametrů. Požadavek je odeslán prostřednictvím výzvy směrovači, neboli. RS (Router Solicitation). Použitím Bezstavové konfigurace odpadá nutnost konfigurace a údržby DHCP serveru, jako je tomu u Stavové konfigurace. Pro aktivaci Bezstavové konfigurace pro danou síť, která přísluší k určitému směrovači, v podstatě postačuje mít nastavený globální pr efix na daném rozhraní a zapnutou podporu Bezstavové konfigurace. Nevýhodou Bezstavové konfigurace je, že její základní definice neobsahuje v rámci směrovačem rozesílaných konfiguračních parametrů informace o DNS serverech, které mají být použity. V podstatě se nabízí dvě možnosti, jak tento problém vyřešit. První možností je využít rozšířenou verzi Bezstavové konfigurace, která byla popsána v rámci RFC 6106: IPv6 Router Advertisement Options for DNS Configuration [25]. Nevýhodou tohoto řešení je, že musí být dané změny implementovány jak na straně směrovače, tak na straně klientských síťových za řízení a tak toto řešení nemusí být podporováno v rámci všech síťových zařízení. Druhou možností je zabezpečit celý proces předávání konfiguračních parametrů jiným způsobem, než je Bezstavová konfigurace, tedy využitím např. Stavové konfigurace, tedy protokolu DHCPv DNS a IPv6 Systém DNS, který především zajišťuje překlad doménových jmen na příslušné IP adresy, hrál již velice důležitou úlohu v rámci v současnosti masivně používaného protokolu IPv4. V rámci protokolu IPv6 se jeho důležitost ještě zvyšuje. Příčinou je především větší délka adres IPv6. Delší adresy IPv6 jsou špatně zapamatovatelné a hůře se s nimi pracuje. Z toho důvodu je vždy lepší, pokud je možné manipulovat s doménovým jménem, které reprezentuje danou IPv6 adresu a je ve většině případů snadno, nebo alespoň lépe zapamatovatelné oproti dané IPv6 adrese. 18

19 Aby bylo možné plnohodnotně používat protokol IPv6 v rámci systému DNS, musel být tento systém modifikován. V rámci daných potřebných úprav se jednalo v podstatě o dvě oddělené problematiky. První problematiku tvořila nutnost přidat do systému DNS podporu záznamů pro IPv6 adresy. Druhou problematikou bylo naopak zprovoznění komunikace, a to především dotazování do systému DNS prostřednictvím protokolu IPv6. Řešení první problematiky je popsáno v rámci RFC 3596: DNS Extensions to Support IP Version 6 [40]. Jedná se především o přidání nových typů DNS záznamů podporujících adresy IPv6. Pro tzv. dopředné dotazy, které slouží k překladu doménových jmen na příslušné IP adresy, byl v rámci podpory IPv6 přidán další typ záznamu, konkrétně se jed ná o záznam AAAA, který odpovídá záznamu A pro IPv4 adresy. Celý zápis záznamu je v podstatě standardní, na prvním místě stoj í příslušné doménové jméno, za ním následuje specifikace typu záznamu, tedy hodnota AAAA, za kterou se již nalézá zápis samotné IPv6 adresy. Pro tzv. zpětné (reverzní) dotazy, které slouží k nalezení příslušného doménového jména k určité IP adrese, je použit stejný typ záznamu pro adresu protokolu IPv6 stejně jako pro adresu IPv4. Jedná se o záznam PTR. Zápis takového záznamu pro adresu IPv6 pak vypadá tak, že na prvním místě stojí IPv6 adresa v upraveném tvaru, za ní následuje specifikace typu zázn amu, tedy hodnota PTR, za kterou již následuje konkrétní doménové jméno. Upravený tvar IPv6 adresy pro příslušný záznam je získán tak, že dojde k obrácení pořadí šestnáctkových číslic dané IPv6 adresy. Zároveň jsou vypuštěny všechny dvojtečky a libovolné dvě sousedící šestnáctkové číslice musí být odděleny pomocí tečky. Zápis je poněkud ztížen tím, že lze provést převrácení pouze u IPv6 adresy, která je zapsána v plném, tedy v nezkráceném tvaru. Komunikace se systémem DNS byla vyřešena tak, že se lze jak prostřednictvím protokolu IPv4, tak prostřednictvím protokolu IPv6 dotazovat DNS serveru na záznamy všeho druhu. Je tedy možné se prostřednictvím protokolu IPv4 dotázat DNS serveru na záznam typu AAAA, který se týká IPv6 adresy a naopak. 19

20 1.8 Přechodové mechanismy V rámci protokolu IPv6 bylo vytvořeno velké množství přechodových mechanismů, které mají v současnosti usnadnit či umožnit použití tohoto protokolu. Důvodem existence těchto mechanismů je také fakt, že na protokol IPv6 není možné přejít skokově. V současné době je prozatím nutné používat zároveň obě dostupné verze protokolu IP. Obecně je možné tyto mechanismy klasifikovat v rámci tří skupin. Dvojí zásobník (Dual Stack), tunelování a translátory. V rámci dvojího zásobníku fungují oba protokoly na daném síťovém zařízení současně. V rámci tunelování se pomocí tunelů, které používají protokol IPv4, propojují sítě používající protokol IPv6. Translátory slouží k zajištění a překladu komunikace mezi protokolem IPv4 a protokolem IPv6 a naopak. Podrobněji jsou tyto mechanismy zmiňovány v následujících kapitolách této práce. 1.9 Hodnocení situace na trhu Protokol IPv6 je zajímavá náhrada v současnosti používaného protokolu IPv4, zároveň je protokol IPv6 vnímám především jako budoucnost pro síť Internet. Současná situace však neodpovídá tomu, jaké byly předpoklady rozšíření protokolu IPv6. Dokument RFC 5211 : An Internet Transition Plan [11] vydaný v roce 2008 definuje tři fáze zavádění protokolu IPv6. Jedná se konkrétně o tyto fáze: přípravná fáze, pře chodová fáze a po přechodová fáze. V rámci jednotlivých fází je definováno v jakém stavu se v dané fázi má nalézat nasazení protokolu IPv6 z pohledu poskytovatele internetového připojení. Přípravná fáze, která mimo jiné měla být dle daného RFC skončena v prosinci roku 2009, dle [32] specifikuje: Poskytovatelé by měli začít poskytovat IPv6 konektivitu zákazníkům, buď pomocí přechodového mechanismu, ne bo nativně. Organizace by měly mít IPv6 konektivitu pro své veřejné služby. 20

21 Organizace mohou poskytovat IPv6 konektivitu svým interním uživatelům. Přechodová, tedy druhá fáze, která se měla uskutečnit v rozmezí od ledna 2010 do prosince 2011, dle [32] specifikuje: Poskytovatelé musí nabízet internetové služby na bázi IPv6 svým zákazníkům. IPv6 služby by měly být nativní, ale mohou být poskytovány přes IPv6 přechodový mechanismus, pokud to je nezbytné. Organizace musí provozovat IPv6 služby svým interním uživatelům a poskytovat interní podpůrné služby ( např. DNS, DHCP). Internetová konektivita na bázi IPv6 může být realizována nativním IPv6 připojením, nebo může být realizována přes IPv6 přechodový mechanismus. Po přechodová, tedy třetí a poslední fáze, která má probíhat od ledna 2012 do současnosti, dle [32] specifikuje: Poskytovatelé musí nabízet internetové služby na bázi IPv6 svým zákazníkům. IPv6 služby by měly být nativní. Organizace musí mít IPv6 konektivitu pro své veřejné servery. Tyto servery musí být vnímány jako produkční. Organizace by měly poskytovat IPv6 konektivitu pro své interní uživatele včetně podpůrných služeb jako DNS, DHCP. Poskytovatelé mohou nabízet IPv4 konektivitu. Organizace mohou používat IPv4 konektivitu. Pokud nyní porovnáme v jakém stavu se protokol IPv6 nachází u jednotlivých poskytovatelů internetového připojení, zjistíme, že většina poskytovatelů se nachází zhruba v okolí první fáze. V následujících fázích se ojediněle vyskytují spíše menší subjekty, jako jsou např. občanská sdružení, zajišťující pro své členy internetové připojení, případně menší lokální poskytovatelé internetového připojení a akademická sféra. Je to dáno také tím, že u větších a velkých poskytovatelů internetového připojení představuje zavedení tohoto protokolu nesrovnatelně větší procento práce a nákladů. O něco lépe v zavádění protokolu IPv6 jsou na tom firmy, které 21

22 poskytují služby na svých serverech v rámci sítě Internet. Základní orientaci v tom, jací poskytovatelé internetového připojení, a nejen oni, v rámci ČR nabízejí připojení prostřednictvím protokolu IPv6, je možné nalézt na doméně ipv6portal.cz [42], která v rámci dané problematiky nabízí databázi jednotlivých subjektů. Jednotlivé subjekty jsou v rámci dané databáze rozděleny do čtyř kategorií, kterými jsou ISP ( Internet Service Provider), Serverhousing, Webhosting a ISP velkoobchod. Pokud projdeme dané kategorie a vyloučíme kategorii ISP velkoobchod, zjistíme, že nejlepších výsledků v podpoře protokolu IPv6 dosahuje kategorie Serverhousing, což je v podstatě logické. V kategorie ISP, což jsou poskytovatelé internetového připojení, se nacházejí především různá občanská sdružení a menší a střední firmy. Nevýhodou této databáze je však neaktuálnost některých záznamů, které snižují její vypovídací schopnost. Obraz situace na trhu je možné demonstrovat na firmě UPC Česká republika, s.r.o. (dále jen UPC), která představuje možný reprezentativní vzorek velké firmy poskytující internetové připojení v rámci ČR, a na její odpovědi [31] na otázku, zda podporuje její síť protokol IPv6. Firma UPC si velice dobře uvědomuje naléhavost situace, která se t ýká nedostatku adres protokolu IPv4, proto také uvádí, že na zavedení protokolu IPv6 začala pracovat před několika lety, tedy v době, kdy začalo být zřejmé, že je počet IPv4 adres nedostačující. Daná firma také hovoří o tom, že vynaložené náklady na zavedení protokolu IPv6 nebudou velké. Je tedy obtížné si představit, v jakých řádech korun se dané náklady budou pohybovat. Firma ovšem ospravedlňuje svá tvrzení faktem, že všechen hardware, software a vybavení sítě, které dlouhodobě nakupuje, již má zabudovanou podporu protokolu IPv6. Firma si zvolila takový způsob zavedení protokolu IPv6, který bude podporovat jak adresy protokolu IPv6, tak adresy protokolu IPv4. Bude se tedy nejspíše jednat o tzv. duální implementaci (Dual Stack), kdy je současně dostupná jak konektivita prostřednictvím protokolu IPv6, tak prostřednictvím protokolu IPv4. Firma spatřuje výhodu tohoto způsobu zavedení především v tom, že dnes i v budoucnu budou podporována všechna zařízení. Firma ovšem také 22

23 dodává, že se v současné době bezprostředně nepotýká s nedostatkem adres v rámci protokolu IPv4. Daná firma tedy svým klientům prozatím konektivitu prostřednictví protokolu IPv6 nenabízí, ale říká, že pokud by to bylo nezbytně nutné, dokáže ji svým klientům nabídnout. V současnosti není z pohledu poskytovatele internetového připojení problém provozovat síť na zařízeních, která plně podporují protokol IPv6, dostat přidělený určitý blok IPv6 adres, upravit software, který používá, aby podporoval práci s protokolem IPv6, a danou konektivitu prostřednictvím poslední míle dopravit ke svým klientům. Zavedení protokolu IPv6 je tedy spíše problém z finančního hlediska než z hlediska dostupnosti jednotlivých prvků. Vyvstává tedy otázka, proč je protokol IPv6 tak pomalu zaváděn, a jeho rozšířenost nenaplňuje představy jeho tvůrců a propagátorů. Možných odpovědí samozřejmě existuje celá řada. Záleží, pod jakým úhlem pohledu je na danou problematiku nahlíženo. Jeden z možných důvodů, proč je zavádění protokolu IPv6 tak pomalé a zdlouhavé, je označován jako selhání trhu. Jde o to, že trh reaguje na protokol IPv6 velice pomalu a vláčně. Podpora protokolu IPv6 se stala spíše jakousi nálepkou, která má svědčit o kvalitě daného produktu, či služby. Tato problematika ohledně protokolu IPv6 tvoří pomyslný uzavřený kruh. Je to dáno tím, že velice malé procento služeb v rámci sítě Internet je dostupné prostřednictvím protokolu IPv6, protože existuje relativně malé množství uživatelů, kteří jsou schopni tyto služby prostřednictvím protokolu IPv6 využít. Na druhou stranu není velký tlak na rozšíření protokolu IPv6 mezi uživatele, protože je přes něj přístupné relativně malé procento služeb v rámci sítě Internet. Protokol IPv4, který je v současnosti využíván, navíc představuje pro subjekty, které ho provozují jakousi záru ku jistoty a kvality. Jeho provozování nepředstavuje žádné dodatečné náklady a zvýšenou pracnost oproti protokolu IPv6. Navíc zisky, které z používání protokolu IPv4 plynou, jsou k dispozici okamžitě, kdežto zavádění protokolu IPv6 představuje pro mnohé subjekty spíše rizikovou investici, jejíž návratnost se může nacházet až v delším časovém horizontu. Pokud se podíváme na nasazení protokolu IPv6 z pohledu obyčejných uživatelů, zjistíme, že jeho nasazení pro ně nepřináší nic nového, kromě možnosti 23

24 přímo se připojovat ke svým zařízením z jiných lokalit (za předpokladu, že je v rámci těchto lokalit přístup do sítě Internet prostřednictvím protokolu IPv6). Tato možnost však nepředstavuje také žádnou novinku, za předpokladu, že daní uživatelé vlastní veřejnou ad resu protokolu IPv4, nebo používají nějakou techniku pro průchod technologií NAT. Zavedení protokolu IPv6 u koncových uživatelů většinou také pro tyto uživatele znamená další náklady. Jedná se o náklady, které jsou spojené s pořízením nových zařízení podporujících protokol IPv6, samozřejmě za předpokladu, že ho stará zařízení nepodporují. Náklady jsou tak většinou spojené především s výměnou domácích směrovačů (neplatí, pokud jsou zapůjčeny poskytovatelem internetového připojení v rámci dané služby), které slouží jako hraniční bod sítě uživatele a sítě poskytovatele internetového připojení, a to i za předpokladu, že se jedná o nasazení protokolu IPv6 typu Dual Stack, který již byl zmíněn v předchozím textu. Pokud ovšem aktivní síťové prvky, které zajišťují výměnu dat mezi sítí uživatele a sítí poskytovatele internetového připojení, fungují v režimu síťového mostu (Bridge), lze s velkou pravděpodobností říci, že nevyvstává akutní nutnost pořizovat tato zařízení nová (za předpokladu, že je dostačující jejich správa pouze pomocí protokolu IPv4). To také prodlužuje životnost různých domácích bezdrátových přístupových bodů ( pokud fungují v režimu Bridge). Nasazení protokolu IPv6 typu Dual Stack, také oddaluje nutnost pořízení nových síťových zařízení, která nepodpo rují protokol IPv6 (a podporu nelze zajistit dodatečnou úpravou zařízení, např. přehráním firmwaru). Jedná se např. o zařízení typu síťová tiskárna. Je ovšem nutné počítat s tím, že daná zařízení budou přístupná pouze pomocí protokolu IPv4. Při stávající rychlosti nasazování protokolu IPv6 lze předpokládat, že spíše daná síťová zařízení dříve zastarají a budou pořízena nová již s podporou protokolu IPv6, než bude dokončen úplný přechod na tento protokol. Při nasazení protokolu IPv6 typu Dual Stack získává však uživatel jednu výhodu. Tou je jistá forma záložní konektivity, která funguje tak, že pokud není požadovaný cíl dostupný prostřednictví m protokolu IPv6, pokusí se ho v rámci možností dané síťové zařízení kontaktovat prostřednictvím protokolu IPv4. Pokud se jedná o osobní počítače a jim 24

25 podobná zařízení, která pracují s novějšími operačními systémy, je velice pravděpodobné, že v sobě mají již podporu protokolu IPv6 zabudovanou. Kromě toho, že pro obyčejné uživatele protokol IPv6 nepřináší v podstatě nic nového, a jeho zavedení pravděpodobně představuje pro tyto uživatele určité náklady, mohou nastat ještě další situace, které mohou způsobit zpomalení zavádění protokolu IPv6. Tento případ vychází z modelové situace, kdy je zavedení protokolu IPv6 u uživatele např. v režimu Dual Stack spojeno s občasnými výpadky, které jsou způsobeny např. odlaďováním části sítě, která slouží k distribuci protokolu IPv6. Tyto výpadky spolu s jistou prodlevou při přepínání mezi IPv6 a IPv4 konektivitou mohou způsobovat uživateli zhoršený požitek ze služeb poskytovaných v rámci sítě Internet a mohou vést k tomu, že daný uživatel nakonec zakáže na svém počítači podporu protokolu IPv6. Tím se zmenší ve statistikách jednotlivých služeb množství přístupů přes protokol IPv6. Lze také počítat s tím, že o daném zjištění a odstranění svého problému poreferuje svým známým, kteří také tak učiní a celý efekt je ještě znásoben a může vést k ještě menší poptávce po IPv6. K zavádění protokolu IPv6 musí tedy poskytovatelé internetu u svých zákazníků přistupovat obezřetně a plánovitě, protože každá negativní zkušenost, kterou uživatelé podstoupí, se mnohonásobně odrazí v jejich spokojenosti a poptávce. Zavádění protokolu IPv6 by v současnosti mohl pomoci jeden z důvodů, proč byl navržen. Jedná se o jeh o obrovský adresní prostor. Pokud vezmeme v potaz, že v současnosti dochází k masivnímu úbytku volných veřejných IPv4 adres a někde již byla zásoba vyčerpána úplně, stává se z těchto adres svým způsobem vzácnější statek. To zvyšuje pomyslnou cenu těchto adres a poptávku po nich. V důsledku by to mohlo vést k velkému obchodování s volnými IPv4 adresami, nebo alespoň k tlaku, aby bylo takové obchodování umožněno. Pořízení IPv4 adres by tedy bylo dražší a vedlo by k prodražování provozu sítě např. poskytovatelům připojení k internetu. Právě zvyšující se finanční náklady na provoz sítě by mohly dané firmy tlačit k přechodu na protokol IPv6, protože je jeho adresní prostor obrovský a přidělení těchto adres by v porovnání s nastíněnou situací nestálo v podstatě nic. Navíc nedostatek 25

26 volných IPv4 adres může vést k omezení vstupu dalších firem na trh s poskytováním služeb v rámci sítě Internet, ke snížení konkurenceschopnosti menších hráčů a k zvýhodnění velkých hráčů na těchto trzích. Takto vzniklá nerovnováha na tr hu by mohla následně vést k úpravám legislativy, která by daným subjektům přikazovala více se angažovat v zavádění protokolu IPv6. Je také možné, že nastane situace, kdy budou jednotlivé RIR (Regional Internet Registry), tedy Regionální internetové registry prověřovat, zda jsou opravdu všechny u jednotlivých subjektů alokované IPv4 adresy využívány, a nevyužívané adresy daným subjektům odeberou a předají je do speciálního registru organizace IANA (Internet Assigned Numbers Authority), jejímž úkolem je celosvětový dohled nad přidělováním IP adres. Nevýhodou takto odebraných adres však je, že nebudou moci být využity dříve, než zásoba volných IPv4 adres libovolné organizace LIR (Local Internet Registry) klesne pod určitou úroveň. Většina výše zmíněných situací může v případě nečinnosti v zavádění protokolu IPv6 negativně působit na zvýšení nákladů zmíněných subjektů a tím jim poskytovat důvod k postupné přípravě a zavádění protokolu IPv6, která nebude v budoucnu znamenat velké jednorázové finanční náklady při skokovém přechodu celých organizací na protokol IPv6. 26

27 2 Adresace protokolu IPv6 2.1 Adresy IPv6 Jedním z důvodů vzniku protokolu IPv6 je právě velikost adresního prostoru, který tento protokol nabízí. Jedná se také o jednu z klíčových vlastností tohoto protokolu, která je intenzivně propagována v souvislosti s rychle ubývajícím adresním prostorem protokolu IPv4. Při návrhu protokolu IPv6 byly tedy kladeny velké nároky na velikost adresního prostoru a proto byla nakonec stanovena délka adres na sto dvacet osm bitů za použití šestnáctkové soustavy pro zápis adres. Což představuje čtyřnásobnou velikost adresy protokolu IPv6 oproti adrese protokolu IPv4, kde byla délka adresy pouze třicet dva bitů a k zápisu adres sloužila desítková soustava. Stěžejní roli ve specifikaci IP adres protokolu IPv6 hraje dokument RFC 4291: IP Version 6 Addressing Architecture [15]. Tento dokument se zabývá specifikací adresní architektury protokolu IPv6, tedy jakou délku dané adresy mají, jaké typy IP adres existují a dalšími prvky těchto adres. Protokol IPv6 zavádí tři druhy základních IP adres, které se odlišují především způsobem použití a chováním. Prvním druhem jsou adresy Individuální (Unicast Addresses), které slouží k jednoznačné identifikaci jednoho síťového rozhraní. Dalším druhem jsou adresy Skupinové (Multicast Addresses), ty slouží k adresaci určité skupiny síťových zařízení. Pokud jsou některá data odeslána na tuto síťovou adresu, musí být doručena všem síťovým zařízením, která se nachází v dané skupině. Novinkou protokolu IPv6 v porovnání s protokolem IPv4 jsou tzv. adresy Výběrové (Anycast Addresses). Podobně jako u adres Skupinových slouží i adresy tohoto typu k adresaci určité skupiny síťových zařízení. Pokud jsou však data odeslána na tuto adresu, nejsou odeslá na všem síťovým zařízením, která jsou členy dané skupiny, ale pouze jedinému síťovému zařízení a to síťovému zařízení, které je nejblíže v rámci dané skupiny, samozřejmě s ohledem na topologii dané sítě. Toto rozdělení adres 27

28 protokolu IPv6 je velice hrubé a bude dále blíže specifikováno v příslušných podkapitolách. V protokolu IPv4 ještě existují tzv. Všesměrové adresy (Broadcast Addresses). Jejich funkce je však v protokolu IPv6 nahrazena pomocí skupinových adres, tj. skupinovou adresou pro všechny síťová zařízení na lince. Pokud se jedná o množství IPv6 adres, které mohou být v protokolu IPv6 přiděleny jednomu danému síťovému rozhraní, je toto množství v podstatě neomezené. Podstatné je, že v protokolu IPv6 jsou adresy přidělovány konkrétnímu síťovému rozhraní. Síťová rozhraní mají v protokolu IPv6 specifikovány přímo IP adresy, kter é jsou pro daná rozhraní povinné. Tyto adresy se mírně odlišují podle toho, jakou funkci zastává dané síťové zařízení v síťovém prostředí. Pokud by síťové zařízení bylo osobním počítačem obyčejného uživatele, jednalo by se podle [2] o tyto IPv6 adresy: lokální linková adresa pro každé rozhraní, všechny individuální a výběrové adresy (které mu byly přiděleny), lokální smyčka (Loopback), skupinové adresy pro všechny uzly, skupinová adresa pro vyzývaný uzel pro všechny přidělené individuální a výběrové adresy, všechny skupinové adresy (jejichž je členem). 2.2 Adresní prostor IPv6 V rámci této práce je často zmiňováno, že protokol IPv6 nabízí oproti svému předchůdci, kterým je protokol IPv4, obrovský adresní prostor. Toto zvětšení adresního prostoru protokolu IPv6 oproti svému předchůdci je dáno především zvětšením velikosti IPv6 adresy, jejíž délka je čtyřnásobná oproti adrese IPv4. Adresa IPv4 má délku třicet dva bitů, a čtyřikrát delší IPv6 adresa má tedy délku sto dvacet osm bitů. Pokud tedy vezmeme v potaz délku IPv4 adresy v bitech a vypočítáme pomocí mocniny (2 32 ) teoretickou velikost adresního prostoru protokolu IPv4, zjistíme, že protokol IPv4 teoreticky nabízí adres. Pokud aplikujeme stejný výpočet pomocí mocniny (2 128 ) na výpočet teoretické velikosti adresního prostorou protokolu IPv6, dostaneme číslo astronomické velikosti, které je pro člověka obtížně představitelné. Protokol IPv6 tedy 28

29 teoreticky nabízí adres, což představuje v uchopitelnějším zápisu množství 3,4 * adres. Pokud bychom pro lepší představivost přepočítali toto množství adres na počet lidí, žijících na planetě Zemi, připadalo by na každého člověka na Zemi zhruba několik trilionů adres [34]. Jiný způsob vyobrazení obrovského adresního prostoru protokolu IPv6 říká, že pokud by byla každou vteřinu přidělována jedna síť, která má délku prefixu čtyřicet bitů, vystačí nám pak celková zásoba IPv6 adres zhruba na třicet pět tisíc let [34]. Z obou zde uvedených příkladů lze říci, že je velikost adresního prostoru protokolu IPv6 pro současnou, a do velké míry i pro budoucí potřebu, v podstatě neomezená. 2.3 Tvar a zápis IPv6 adresy Jak již bylo zmíněno, IP adresa protokolu IPv6 má délku sto dvaceti osmi bitů, a ke své interpretaci, resp. ke svému zápisu, používá šestnáctkovou soustavu. Samotná adresa je rozčleněna na osm skupin, kde každá skupina má délku šestnácti bitů. Dále je každá skupina vyjádřena prostřednictvím čtyř čísel šestnáctkové soustavy. Jednotlivé skupiny jsou od sebe odděleny prostřednictvím dvojtečky. Vezmeme-li v potaz, že IPv6 adresa obsahuje ve své základní a nezkrácené podobě třicet dva čísel šestnáctkové soustavy, dojdeme k závěru, že práce s tímto formátem IPv6 adresy je poněkud těžkopádná. Z tohoto důvodu byla stanovena pravidla, která určují, jak je možno zkrátit zápis IPv6 adresy v její základní podobě. Tato pravidla budou popsána v následujícím odstavci a týkají se především nakládání s hodnotou nula v zápise adresy. Pokud je jedna skupina IPv6 adresy tvořena samými nulami, je možné tyto čtyři nuly nahradit v zápisu nulou pouze jednou. Zároveň je možné v zápise této adresy vynechat všechny počáteční nuly ve všech skupinách. Samozřejmě je nutné, aby v daných skupinách po vynechání nul zůstaly nějaké hodnoty, za předpokladu, že se nejedná o následující situ aci. Pokud by se v IPv6 adrese vyskytovalo více bezprostředně sousedících skupin, jejichž obsah je tvořen pouze nulami (tzv. nulové skupiny), je možné tyto nulové skupiny zcela nahradit zapsáním dvou dvojteček ( :: ). Toto 29

30 nahrazení je však možné v zápisu IPv6 adresy použít pouze jednou a nesmí být použito k nahrazení pouze jedné nulové skupiny. Nulu, která se nalézá na konci zápisu dané skupiny a zároveň ji předchází v dané skupině jiné hodnoty, nelze ničím nahradit, ani ji ze zápisu vynechat. Tato pravidla tedy umožňují zkrátit zápis IPv6 adresy ze základního tvaru. Neumožňují však, aby adresy po aplikaci zkrácení prostřednictvím těchto pravidel byly na výstupu vždy stejné, byť na vstupu se jedná o stejnou adresu. Právě složitost, možná nejednoznačnost zápisu IPv6 adresy a pro správce a další pracovníky informačních technologií obtížnější manipulace s touto adresou vyústila k vydání dokumentu RFC 5952: A Recommendation for IPv6 Address Text Representation [27], který definuje, jakým způsobem má být v textu, resp. ve výstupu pro uživatele, reprezentována a zapsána IPv6 adresa, tak aby podoba tohoto zápisu byla jednoznačná a vždy stejná (v rámci jedné adresy). Bez takto stanovených pravidel by mohlo v IPv6 adrese docházet k záměnám typickým pro uživatele, jako je např. záměna velkého písmene B za číslo osm apod. Definuje tedy tzv. kanonický zápis (kanonický tvar) adresy IPv6, který slouží právě k textové reprezentaci této adresy pro její uživatele (tedy pro lidi). Tento dokument však přímo stanovuje, že aplikace a systémy, které pracují s adresou IPv6 musí být schopny pracovat se všemi jejími implementacemi, tedy musí být schopny zpracovat jakýkoliv legitimní formát adresy dle na začátku minulé kapitoly uvedeného RFC 4291 [15]. Následující podoba pravidel pro kanonický zápis je čerpána především ze zdroje [2]. První pravidlo pro kanonický zápis IPv6 adres stanovuje, že tzv. šestnáctkové číslice, konkrétně ta jejich část, která je v rámci této adresy vyjádřena písmeny, se zapisuje vždy malými znaky. Toto pravidlo minimalizuje možnost, že dojde k optické záměně některých znaků IPv6 adresy, tedy např. již zmíněného případu s velkým písmenem B a číslicí osm. Další pravidlo stanovuje povinnost vynechat v IPv6 adrese počáteční nuly v rámci dané čtveřice, resp. skupiny. Poslední pravidlo týkající se zkrácení sousedících nulových skupin v IPv6 adrese pomocí dvou dvojteček ( :: ), které již bylo zmíněno v rámci možností zkrácení zápisu IPv6 adresy, je zde rozšířeno dalšími kritérii pro jeho 30

31 použití. Kromě již zmíněné možnosti použít toto zkrácení v rámci IPv6 adresy pouze jednou, je dále stanoveno, že dané zkrácení pomocí dvou dvojteček musí být v rámci dané adresy použito tak, aby toto použití dosahovalo maximální možné efektivnosti. Tedy aby došlo k pohlcení všech nulových skupin, které spolu bezprostředně sousedí a zároveň, aby se jednalo o takové bezprostředně sousedící nulové skupiny, které zabírají v rámci dané adresy nejvíce místa. Pokud by nastal případ, že se v rámci dané IPv6 adresy vyskytuje více spolu bezprostředně sousedících nulových skupin, které jsou však rozděleny jinou nenulovou skupinou na dvě části, které obsahují bezprostředně sousedící nulové skupiny a jsou stejně dlouhé, dojde k použití zkrácení zápisu dané adresy pomocí dvou dvojteček ( :: ) pouze u první bezprostředně sousedící nulové skupiny. U skupiny druhé bude použito pravidlo o vynechání počátečních nul. Nutno podotknout, že není povolen zápis adresy, který by byl zapsán, tímto způsobem ::0:, nebo tímto způsobem :0:: [2]. Na závěr tohoto pravidla je nutné dodat, že jeho použití je možné pouze pokud se jedná o více bezprostředně sousedících nulových skupin a nelze ho tedy použít pouze u jedné nulové skupiny. Ta bude opět přepsána pomocí pravidla o vynechání počátečních nul, tedy daná nulová skupina bude po přepsání obsahovat pouze jednu nulu. Pro přehlednost bude v samostatné podkapitole uveden příklad postupného přepisu reálně použité IPv6 adresy z jejího plného základního zápisu do zápisu kanonického. Pokud bychom chtěli IPv6 adresu v kanonickém nebo v jakémkoliv jiném legitimním zápisu použít přímo, např. ve webovém prohlížeči jako adresu webového serveru ve formátu URL (Uniform Resource Locator), není možné použít stejný typ zápisu, jako tomu je u IP adresy protokolu IPv4. Tedy nelze zapsat IPv6 adresu přímo do adresního řádku prohlížeče, aniž by daná adresa neprošla jistou úpravou. Důvodem je právě způsob zápisu IPv6 adresy, konkrétně se jedná o znak :, který slouží jako oddělovač jednotlivých skupin, na které je IPv6 adresa rozdělena. Právě dvojtečka totiž v URL označuje v kombinaci s IP adresou protokolu IPv4 port, na který má být v rámci dané IP adresy provedeno připojení. Adresa IPv6 musí tedy před tímto způsobem použití projí t úpravou, konkrétně se 31

32 jedná o umístění IPv6 adresy do hranatých závorek [], pak již nejsou dané dvojtečky oddělující skupiny považová ny např. za port a použití je již jinak stejné jako u IP adresy protokolu IPv4. Touto problematikou se hlouběji zabývá dokument RFC 3986: Uniform Resource Identifier (URI): Generic Syntax [6] Příklad zápisu IPv6 adresy Tato podkapitola se zabývá příkladem možného zápisu IPv6 adresy v plném tvaru a zkrácením této adresy do kanonického zápisu. Dále bude uvedena úprava IPv6 adresy v kanonickém zápisu do tvaru, ve kterém je použitelná např. v rámci internetového prohlížeče. Pro daný příklad je použita reálně fungující globální individuální IPv6 adresa 2a02:2b88:0002:0001:0000:0000:167d:0001. Takto zapsaná IPv6 adresa představuje její možný nejdelší zápis. Na první pohled je patrné, že se v rámci této IPv6 adresy vyskytují dvě nulové skupiny, které spolu přímo sousedí a ve třech dalších skupinách jsou počáteční nuly. Zároveň stojí za povšimnutí, že je v zápisu IPv6 adresy již uplatněno pravidlo o malých písmenech v rámci šestnáctkových číslic. Protože po prozkoumání dané IPv6 adresy již víme, že obsahuje dvě přímo sousedící nulové skupiny, můžeme provést jejich minimalizaci pomocí zápisu v podobě dvou dvojteček. Po prvním kroku zkrácení vypadá daná IPv6 adresa následovně 2a02:2b88:0002:0001::167d:0001. V dalším kroku je možné odstranit počáteční nuly ve třech skupinách. Po odstranění počátečních nul v příslušných skupinách vypadá daná IPv6 adresa následovně 2a02:2b88:2:1::167d:1. Tato po doba IPv6 adresy je, co se zkracování týče, finální a není ji možné dále zkrátit. Pokud spočítáme počet znaků v původním zápisu této IPv6 adresy, dojdeme k počtu třiceti devíti znaků (včetně dvojteček). Naopak počet znaků ve finálním zápise dané IPv6 adresy je dvacet jedna (včetně dvojteček). Došlo tedy ke zkrácení původního zápisu IPv6 adresy o osmnáct znaků, což v případě práce s danou adresou již znamená podstatné zjednodušení. 32

33 Pokud bychom chtěli takto zkrácenou IPv6 adresu zadat např. do adresního řádku prohlížeče, musíme ji, jak již bylo dříve zmíněno, vložit do hranatých závorek. Po vložení do hranatých závorek bude tedy celý zápis vypadat následovně [2a02:2b88:2:1::167d:1]. Pokud bychom takto upravenou IPv6 adresu zapsali do adresního řádku např. prohlížeče Firefox, začne se prohlížeč připojovat na webový server na dané IPv6 adrese na standardním portu. Pokud bychom chtěli zvolit port jiný, stačí přidat za výše zmíněný zápis ještě dvojtečku a za ní číselně specifikovat jiný port. Celý zápis by tedy mohl vypadat takto [2a02:2b88:2:1::167d:1]:8080. Samozřejmě by měl být v zápise adresy do adresního řádku uveden ještě protokol, ten však daný prohlížeč automaticky doplňuje jako HT TP (Hypertext Transfer Protocol). Pro názornost je uveden ještě celý zápis včetně protokolu, který vypadá následovně Prefix adresy IPv6 V předchozím textu bylo popsáno, jak IP adresa protokolu IPv6 vypadá, jak ji lze zkrátit a jak má být zapisována tak, aby byla uživatelsky přívětivá, aby manipulace s ní nebyla obtížnější, než být musí. Pokud však má být i síť provozována efektivně, měla by být rozdělena na více částí, které jsou přidělovány např. různým oblastem. Tyto části sítě se nazývají podsítě a tvoří podmnožinu jednoho velkého celku sítě. Jinak řečeno protokol IPv6 má adresní prostor o určité velikosti a ten je rozdělován na určité menší podmnožiny adres (podsítě). K rozlišení, které IPv6 adresy jsou součástí kte rých podsítí, slouží právě v nadpisu této podkapitoly zmíněný prefix. Prefix tedy určuje, jaká část IPv6 adresy je pro všechny adresy v dané síti naprosto shodná, jedná se tedy o tzv. adresu sítě. Pokud si uvědomíme, že strojově reprez entovaná IPv6 adresa je tvořena souborem bitů o určitém počtu, které mohou nabývat rozdílných hodnot, dospějeme k závěru, že prefix určuje počáteční bity dané IPv6 adresy, které jsou pro všechny účastníky dané podsítě stejné. Při pohledu na jednu konkrétní IPv6 adresu však můžeme vidět prefixů celou řadu, záleží o který prefix se v rámci dané IPv6 adresy zajímáme. Může se 33

34 jednat např. o prefix, který označuje podsíť, ve které je přímo připojeno síťové rozhraní daného síťového zařízení s IPv6 adresou z dané podsítě. Může se však jednat i o prefix, který označuje seznam podsítí, které byly přiděleny danému poskytovateli internetového připojení. Prefixy jsou tvořeny pomocí čísla z desítkové soustavy a zapisují se za IPv6 adresu, od které jsou odděleny pomocí lomítka /. Prefixy mají v podstatě dva způsoby použití. Jedním způsobem je zápis prefixu ke konkrétní IPv6 adrese, který určuje, v jaké podsíti se daná adresa nalézá a s jakým rozsahem adres může daná adresa dále přímo komunikovat, aniž by docházelo např. k směrování. Druhý způsob zápisu slouží především k účelům směrování daných podsítí a na konci dané adresy sítě se pak obvykle objevují v zápisu nulové skupiny, za nimiž následuje lomítkem oddělený zápis prefixu. Hodnota prefixu, resp. jeho délka může nabývat hodnoty do sto dvaceti osmi, přičemž se jedná o přirozená čísla. Čím je tedy hodnota prefixu vyšší, tím větší část IPv6 adresy je pro všechny účastníky dané sítě shodná a tím nižší je počet IPv6 adres případně podsítí, které se v dané podsíti mohou nacházet. Pokud tedy vezmeme v potaz maximální hodnotu prefixu, která je sto dvacet osm, zjistíme, že daná adresa může být shodná v podstatě pouze pro jednoho účastníka sítě. Tento prefix také označuje pouze jednu konkrétní IPv6 adresu. Pokud dále postupujeme od hodnoty sto dvacet osm k nižším hodnotám prefixu, snižuje se počet bitů, které jsou pro adresy v dané podsíti stejné a tak se tedy zvyšuje množství adres, případně podsítí, které se v dané podsíti mohou nacházet. 2.5 Dosah adres Dosah adres (Address Scope) je novinka uvedená v rámci protokolu IPv6. Problematika, kterou řeší dosah adres v rámci protokolu IPv6, byla v protokolu IPv4 řešena pomocí TTL (Time to Live), tedy pomocí životnosti datagramů. Dosah adres v podstatě slouží ke stanovení určité oblasti sítě, v rámci které je daná IPv6 adresa jednoznačná. Dosah adres podrobně specifikuje RFC 4007: IPv6 Scoped Address Architecture [12]. Úrovně jednotlivých dosahů se u jednotlivých druhů adres liší. Nejužším členěním 34

35 dosahu adres disponují adresy individuální a tedy i adresy výběrové, které v podstatě pod individuální adresy spadají. Tyto dva druhy adres disponují pouze dvěma úrovněmi dosahu, tedy úrovní lokální pro danou linku a úrovní globální. Naopak nejširším členěním jednotlivých dosahů disponují adresy skupinové, které zahrnují následující úrovně [2]: Rozhraní (1) adresa nepřekročí jediné rozhraní, použití zejména pro skupinové vysílání do rozhraní pro lokální smyčku. Linka (2) dosah je omezen pouze na jednu fyzickou síť, jedná se např. o síť Ethernet. Správa (4) nejmenší dosah, který musí být konfigurován správcem, obvykle se jedná o podsíť. Místo (5) část sítě, která patří jedné organizaci a nachází se v jedné geografické lokalitě, jedná se např. o zákaznickou síť. Organizace (8) dosah, který pokrývá několik míst jedné organizace, např. pobočky jedné firmy v různých městech. Spolu s dosahem adres jsou v protokolu IPv6 zavedeny zóny. Zóny označují konkrétní část sítě odpovídající danému rozsahu. Důležité ovšem je, že hranice zón neprochází linkami, ale přímo jednotlivými síťovými zařízeními např. počítači. Zóny adres jsou hierarchicky členěny. Z toho vyplývá, že zóny, které označují menší dosahy adres, mohou být včleněny do zón, které označují větší dosahy. Pokud se jedná o zóny, které jsou definovány v rámci stejných dosahů adres, platí u nich pravidlo, že se nemohou překrývat. Tyto zóny jsou od sebe tedy buď zcela oddělené, anebo jsou naopak totožné. Pokud spojíme problematiku zón se směrováním, je velice důležité, aby v rámci směrování byly jednotlivé zóny souvislé. Pokud by tomu tak nebylo, mohlo by to vést k tomu, že by datagramy během své cesty opustily zónu, ve které se nacházely, a význam jejich adresy by mohl ztratit smysl. Protože jak bylo řečeno, hranice zón prochází jednotlivými síťovými zařízeními, v našem případě např. počítači, je důležité, aby byly zóny 35

36 v rámci jednotlivých počítačů rozlišovány. Za tímto účelem byl zaveden prvek zvaný Identifikátor zón, který toto rozlišování umožňuje. Důležité je, že jsou jednotlivé identifikátory zón v rámci daných síťových zařízení přidělovány vnitřně a nedochází k vzájemnému sdílení s ostatními síťovými zařízeními v síti. K odvození dosahu jednotlivých zón slouží jednotlivé adresy. Identifikátor zón se zapisuje tak, že je nejprve uvedena příslušná adresa, za kterou následuje procentem oddělená zóna, která je reprezentována reálným číslem. Pokud za danou adres ou není zóna přímo uvedena, použije se standardně zóna, která je reprezentována číslem nula. 2.6 Rozdělení IPv6 adres Protokol IPv6 dělí IPv6 adresy svého adresního prostoru do několika skupin. Tyto skupiny dále určují, jaké vlastnosti budou mít dané IPv6 adresy a jaká bude jejich funkce, tedy o jaký typ IPv6 adres se bude jednat. Příslušnost k určité skupině IPv6 adres, resp. k typu IPv6 adres, je v některých případech stanovena použitím právě pomocí v předcházející podkapitole popsaného prefixu. Protože adresní prostor, který protokol IPv6 nabízí, daleko přesahuje aktuální potřeby, není v současnosti ještě většina prefixů přiřazena. Jedná se především o prefixy, které jsou podmnožinou adresníh o prostoru globálních individuálních IPv6 adres. Pokud vezmeme v potaz fakt, k jakému účelů mají IPv6 adresy primárně sloužit, musíme nutně dojít k závěru, že většinu adresního prostoru zabírají právě globální individuální adresy, které umožňují přiřadit síťovému zařízení celosvětově unikátní IPv6 adresu. V současné době je pro globální individuální adresy využíván především prefix 2000::/3. Tento prefix označuje všechny IPv6 adresy, které začínají již zmíněným číslem dva, nebo číslem tři. Konkrétně se jedná o IPv6 adresy v rozsahu 2000:: - 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. Následují skupinové adresy, jejichž základní charakteristika byla popsána v úvodu této kapitoly. Skupinovou adresu lze identifikovat pomocí prvních dvou čísel šestnáctkové soustavy dané IPv6 adresy, konkrétně dané adresy začínají čísly ff šestnáctkové soustavy. Prefix skupinových adres 36

37 je zapsán jako ff00::/8. Jedná se tedy o IPv6 adresy v rozsahu ff00:: - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. Výběrové adresy, tedy adresy poslední ze základní trojice v úvodu zmíněných adres, nemají na rozdíl od dvou výše zmíněných typů adres přidělen žádný speciální rozsah IPv6 adres, protože jsou přidělovány z rozsahu individuálních IPv6 adres Globální individuální adresy Globální individuální adresy (Global Unicast Addresses) jsou adresy protokolu IPv6, které jsou pro veřejnost, ale i pro uživatele protokolu IPv6, nejvíce na očích. Jedná se totiž o IPv6 adresy, které jsou v podstatě obdobou veřejných IP adres v protokolu IPv4. Právě rozdíl mezi velikostí docházejícího adresního prostoru veřejných adres v protokolu IPv4 a velikostí mnohonásobně většího adresního prostoru globálních individuálních adres v protokolu IPv6 slouží k propagaci protokolu IPv6 a tímto způsobem se globální individuální adresy protokolu IPv6 dostávají do povědomí širší veřejnosti. Finálně je tedy možné označit tyto globá lní individuální adresy za jednu z klíčových vlastností protokolu IPv6. Globální individuální adresy slouží k identifikaci jejich vlastníka, resp. jednoho síťového rozhraní, ke kterému je daná IPv6 adresa přiřazena v rámci celé sítě Internet na bázi protokolu IPv6 a v rámci této sítě jsou také unikátní, což právě označuje jejich globálnost. Jejich popis je možné nalézt v dokumentu RFC 3587: IPv6 Global Unicast Address Format [23]. IPv6 adresy tohoto typu jsou agregovatelné, z čehož vyplývá, že je u nich možné využít principu agregace např. pro směrování, kde agregace značně snižuje zatížení směrovačů. Tato jejich vlastnost vyplývá ze způsobu, kterým jsou prefixy těchto IPv6 adres přidělovány jednotlivým subjektům. Globální individuální adresa je v protokolu IPv6 rozdělena na tři části. Konkrétně na globální směrovací prefix ( Global Routing Prefix), identifikátor podsítě (Subnet ID) a identifikátor rozhraní (Interface ID). Globální směrovací prefix dle [2] slouží k identifikaci koncové sítě a je dané sítí přidělen lokálním internetovým registrem např. 37

38 poskytovatelem internetu. Standardně používaná délka tohoto prefixu je čtyřicet osm bitů (resp. čtyřicet pět bitů a tři bity dlouhá pevná hodnota zapsaná 001 v binární podobě, která uvozuje globální směrovací prefix ). Ovšem je možné se setkat s prefixy větší délky např. s prefixy s délkou šedesát čtyři bitů, jejichž použití se vyskytuje zejména v sítích menšího typu. Za globálním směrovacím prefixem se nalézá identifikátor podsítě, který umožňuje odlišit jednotlivé podsítě v určité síti. Protože, jak již bylo řečeno, se identifikátor podsítě nalézá za globálním směrovacím prefixem, je délka identifikátoru podsítě do jisté míry závislá na délce globálního směrovacího prefixu. Je to dáno tím, že součet délky globálního směrovacího prefixu a délky identifikátoru podsítě musí tvořit ve standardních situacích délku šedesáti čtyř bitů. Pokud tedy vezmeme globální směrovací prefix o standardní délce čtyřiceti osmi bitů a aplikujeme výše zmíněnou podmínku, musí mít identifikátor sítě délku šestnácti bitů, aby bylo dosaženo požadované celkové délky šedesáti čtyř bitů. Pokud by ovšem nastala situace, že by byl použit globální směrovací prefix o délce šedesáti čtyř bitů, pak by již nezbývalo žádné místo na identifikátor podsítě a daná síť by nebyla členěna na jednotlivé podsítě, protože délka identifikátoru rozhraní je šedesát čtyři bitů. Nejčastěji se však v praxi vyskytuje identifikátor podsítě, který má délku šestnáct bitů. Poslední součástí globální individuální adresy je identifikátor rozhraní, jehož délka, jak již bylo výše popsáno, zabírá celou polovinu délky adresy IPv6, tedy šedesát čtyři bitů. Slouží k tomu, aby bylo možné rozlišit jednotlivá síťová zařízení, která jsou umístěna v rámci stejné podsítě. Co se týče identifikátoru rozhraní, je ho možné určit více způsoby. Jeden ze způsobů určení identifikátoru rozhraní je pomocí modifikovaného EUI-64, který je popsán níže. Modifikované EUI-64, které je používáno jako jedna z možností pro určení identifikátoru rozhraní, vzniká odvozením z ethernetové MAC adresy daného síťové rozhraní. Nejprve se tedy vezme daná MAC adresa síťového zařízení, která má délku čtyřiceti osmi bitů. Identifikátor rozhraní má však délku šedesáti čtyř bitů, je tedy nutné provést úpravu dané MAC 38

39 adresy, aby délka odpovídala délce identifikátoru rozhraní. Úprava MAC adresy je provedena tak, že se mezi třetí a čtvrtý bajt MAC adre sy vloží dva bajty, tedy šestnáct bitů o hodnotě fffe. Nyní máme řetězec o požadované délce šedesáti čtyř bitů, ovšem ještě je nutné invertovat sedmý bit od začátku adresy, tedy obrátit příznak globality, abychom dostali modifikovaný EUI-64. Tímto postupem je možné z jakékoliv MAC adresy vytvořit platný a unikátní identifikátor rozhraní. Nevýhodou tohoto postupu však může být globální unikátnost MAC adresy spo jené s daným síťovým zařízením. Pokud je modifikované EUI -64 využíváno pro určení identifikátoru rozhraní na více místech, v rámci kterých se jedno síťové zařízení připojuje, pak je možné pomocí takto určeného identifikátoru rozhraní jednoznačně identifikovat síťové zařízení v rámci daných sítí a tím tedy i získat možnost zjistit, v rámci jakých sítí se dané síťové zařízení pohybuje. Protože tento princip generování identifikátoru rozhraní má své odpůrce, byl později navržen další možný způsob určení identifikátoru rozhraní (Privacy Extensions), který znemožňuje dlouhodobější sledování síťového zařízení. V rámci tohoto způsobu se v podstatě jedná o náhodně generovaný identifikáto r rozhraní s podmínkou, že dané náhodně generované identifikátory rozhraní budou mít pouze omezenou platnost. Doba platnosti nemusí být stejná a může se jednat např. o rozmezí v rámci hodin a dnů. Po vypršení platnosti takto vygenerovaného identifikátoru rozhraní je opět vygenerová n náhodně nový identifikátor rozhraní a celý tento proces je neustále opakován v daných intervalech platnosti. Tento princip umožňuje v podstatě generovat navenek náhodný identifikátor rozhraní, avšak znesnadňuje komunikaci, která směřuje k danému síťovému zařízení. Proto byl později tento princip rozšíř en pomocí modifikovaného EUI-64 a ve výsledku jsou tedy v tomto principu použity dva identifikátory rozhraní. První identifikátor rozhraní je náhodně generován a je upřednostňován v rámci všech odchozích komunikací síťového zařízení do dané sítě. Naproti tomu je druhý identifikátor rozhraní generován pomocí modifikovaného EUI-64 a slouží především pro použití v rámci systému DNS, aby případně usnadnil příchozí komunikaci na dané síťové rozhraní. Pro zachování anonymity se v systému DNS vyskytuje 39

40 pouze ten identifikátor rozhraní, pro jehož určení byl využit modifikovaný EUI-64. Pro vysvětlení možností určení identifikátoru rozhraní byly popsány pouze dva způsoby jak tento identifikátor určovat. V rámci protokolu IPv6 však ještě existují další nepopsané způsoby, kterými lze určit identifikátor rozhraní Lokální adresy Lokální adresy existují v podstatě i v protokolu IPv4. Tyto adresy zde byly vytvořeny tak, že došlo k odtržení určitých rozsahů veřejných IPv4 adres a bylo řečeno, že tyto rozsahy IPv4 adres budou sloužit pouze jako lokální adresy. V rámci protokolu IPv4 je použití lokálních adres vyhrazeno pouze pro privátní sítě. Tyto adresy tedy nesmí být směrovány v rámci celosvětové sítě Internet a zárove ň se jedná o adresy, které nejsou celosvětově unikátní, protože mohou být opakovaně použity v rámci mnoha privátních sítí. V dnešní době je tento typ adres hojně používán např. pro připojení zařízení k síti Internet v rámci privátní sítě, kde je samotný přístup do internetu zajištěn pomocí jedné či několika veřejných IPv4 adres a pomocí technologie překladu síťových adres, neboli technologie NAT (Network Address Translation). Pokud dojde do jisté míry k zobecnění principu překladu síťových adres, lze říci, že umožňuje překlad IPv4 adres z privátních sítí na veřejnou IPv4 adresu, která je následně použita pro komunikaci v rámci sítě Internet. Tento princip je v současnosti využíván ve velké míře a v podstatě oddálil nutnost řešení problému s nedostatkem veřejných IPv4 adres. Ovšem tento princip je spíše jednosměrný a neumožňuje přímé připojení ze sítě Internet na zařízení s privátní IPv4 adresou (bez použití pokročilejších síťových technik ). Protokol IPv6 zavádí více druhů lokálních adres, které mají své specifické vlastnosti a především se odlišují účelem, za kterým jsou používány. Ve většině případů je možno je nějakým způsobem připodobnit právě k lokálním adresám z protokolu IPv4, což umožňuje jejich lepší pochopení. Mezi tyto adresy v rámci protokolu IPv6 patří adresy lokální 40

41 linkové, lokální místní a unikátní lokální. Tyto adresy budou popsány v následujícím textu. Lokální linkové adresy (Link Local Addresses) slouží v protokolu IPv6, jak už jejich název napovídá, jako lokální IPv6 adresy rozhraní, které budou pro dané rozhraní k dispozici vždy, bez ohledu na to, zda je dané síťové zařízení připojeno k síti Internet či nikoliv. Tyto adresy se vyskytují vždy v rámci určité linky a slouží pro komunikaci s ostatními síťovými zařízeními, která se na této lince také vyskytují. Ve své podstatě se tedy jedná o takovou skupinu síťových zařízení, která jsou spolu schopna komunikovat na linkové úrovni. Může se tedy jednat např. o síťová zařízení, která jsou v rámci sítě LAN (Local Area Network) připojena do jednoho síťového přepínače (Network Switch). Tyto adresy tedy umožňují zabezpečit komunikaci mezi síťovými zařízeními, kter á se nacházejí na stejné lince, aniž by bylo nutno cokoliv konfigurovat. Nevýhodou však je, že tyto adresy nejsou evidovány v žádném systému DNS, a proto je nutné pro komunikaci používat přímý zápis těchto adres namísto jmenného. Tyto adresy jsou mimo jiné také využívány pro konfig uraci IPv6 adres systémem DHCP pro přenos jednotlivých zpráv mezi klientem DHCP a DHCP serverem. Lokální linkové adresy není možné směrovat. Jedním z důvodů je, že dosah těchto adres je omezen pouze na jednu linku a za směrovačem se již nachází linka jiná. Na začátku těchto adres stojí pevně definovaný prefix fe80::/10 o délce deseti bitů. Zbylý prostor o délce padesáti čtyř bitů mezi začátkem následujícího šedesáti čtyř bitového identifikátoru rozhraní a tímto prefixem je vyplněn nulami, resp. je nulový. Samotný identifikátor rozhraní je tvořen za pomoci modifikovaného EUI-64, tedy za pomocí úpravy MAC adresy, která byla popsána v předchozím textu. Tato adresa je tedy generována automaticky daným síťovým zařízením, což zabezpečuje její maximální dostupnost pro dané síťové zařízení, ale zároveň dochází také k ověření, zda je pro danou linku, ve které se nachází, skutečně unikátní. V některých situacích je možné nalézt linkovou lokální adresu doplněnou o dodatečný identifikátor rozhraní, který určuje, ke které lince se daná linková lokální adresa váže. Tento identifikátor se v zápisu odděluje od lokální linkové IPv6 adresy pomocí znaku procenta % a je 41

42 zapsán číslem, může se jednat např. o číslo dva. Tyto identifikátory jsou v rámci každého síťového zařízení přidělovány samostatně a nedochází tedy k jejich synchronizaci s okolními síťovými zařízeními. Dalším typem lokálních adres v protokolu IPv6 jsou unikátní lokální adresy, neboli ULA (Unique Local Address). Někdy jsou tyto adresy také v českém jazyce nazývány jako unikátní privátní adresy. Definici tohoto typu adres je možné nalézt v dokumentu RFC 4193: Unique Local IPv6 Unicast Addresses [21]. Jedná se o IPv6 adresy, které jsou celosvětově jedinečné a jsou určeny pro komunikaci na lokální (privátní) úrovni. Jako jedna z možných výhod těchto adres se uvádí jejich nezávislost na poskytovateli internetových služeb. Tyto adresy jsou dobře identifikovatelné dle jejich prefixu, který je pro všechny tyto adresy stejný, jedná se o prefix fc00::/7. Ve struktuře tohoto typu adresy se za daným sedm bitů dlouhým prefixem nalézá jednobitová položka L, která určuje, jakým způsobem je daný prefix přiřazen. Pokud je prefix přiřazen lokálně, nabývá tato položka hodnoty jedna. Význam druhé možné hodnoty, tedy hodnoty nula, není prozatím přesně definován a je určen pro budoucí použití. Z toho tedy vyplývá, že jsou všechny adresy tohoto typu v současnosti přidělovány lokálně, a proto tedy položka L nabývá hodnoty jedna. Tím pádem všechny tyto adresy začínají prefixem fd00::/8. [2] Za položkou L následuje čtyřicet bitů dlouhý globální identifikátor (Global ID), pomocí kterého je zabezpečováno vytvoření globálně unikátního prefixu. Ve své podstatě se jedná o zvláštním postupem vygenerované náhodné číslo, které dle výše zmíněného RFC nemá být snadno předvídatelné. Současně je v daném RFC zmíněn jeden z možných postupů, který pro vygenerování tohoto náhodného čísla používá aktuální čas, adresu a SHA-1. Díky délce globálního identifikátoru, společně se zmíněným postupem, je pravděpodobnost, že bude náhodně zvolen stejný globální identifikátor, opravdu velice malá. Pokud spojíme všechny doposud popsané části tohoto typu IPv6 adresy, tedy prefix, položku L a globální identifikátor, dostaneme prefix klasické délky čtyřiceti osmi bitů. Za tímto čtyřiceti osmi bitovým prefixem dále následuje identifikátor podsítě (Subnet ID) a identifikátor rozhraní (Interface ID) o délce šedesáti 42

43 čtyř bitů, který je standardně vytvářen dle mod ifikovaného EUI-64, které bylo popsáno v podkapitole zabývající se globálními individuálními adresami. Jednou z dalších výhod tohoto typu IPv6 adres je možnost jejich směrování v rámci lokálních sítí IPv6 adresy obsahující IPv4 adresy V některých situacích, např. pro zajištění zpětné kompatibility protokolu IPv4, je třeba použít IPv4 adresy, které jsou obsažené v rámci adres IPv6. Může se jednat například o situaci, kdy má webový server předřazen reverzní proxy server a je požadována podpora obou pro tokolů. Takovou situaci je možné řešit tak, že se reverzní proxy na daný webový server připojuje prostřednictvím protokolu IPv6 a zdrojové adresy síťových zařízení používajících protokol IPv4 překládá na adresy IPv6. Často je možné setkat se v rámci různých síťových programů s IPv4 mapovanými adresami. Jedná se tedy o jednu z možností, jak použít IPv4 adresu v rámci adresy IPv6. Zápis takovéto IPv6 adresy pro IPv4 adres může vypadat následovně ::ffff: Mapované IPv4 adresy byly po čase nahrazeny novým formátem, který definuje RFC 6052: IPv6 Addressing of IPv4/IPv6 Translators [5]. Jedná se o tzv. adresy s vloženým IPv4 [2], které vyčleňují část adresního prostoru protokolu IPv6 pro reprezentaci IPv4 adres. Daná část adresního prostoru je specifikována prostřednictvím určitého prefixu a za prefix je uvedena požadovaná IPv4 adresa. Za prefixem stojí ještě přípona, která slouží k rozlišení jednotlivých částí v rámci jedné mapované adresy [2]. V rámci těchto adres se vyskytuje daný prefix ve dvou typech, v jednom případě se jedná o prefix, který je vyčleněn správcem sítě z lokálního adresního prostoru. V druhém případě jde o použití univerzální varianty prefixu pro tento případ a to 64:ff9b::/96. V rámci tohoto prefixu však nelze používat neveřejné IPv4 adresy, pro ty v tomto případě musí být vytvořen prefix vlastní. 43

44 2.6.4 Skupinové adresy Skupinové adresy (Multicast Addresses) představují samostatný typ adres v protokolu IPv6 a slouží především k adresaci určitých skupin síťových zařízení, resp. skupin síťových rozhraní těchto síťových zařízení. Za předpokladu, že jsou na skupinovou adresu odeslána nějaká data, jsou doručena všem síťovým zařízením, která jsou členy dané multicastové skupiny. Lze tedy říci, že jednotlivé skupinové adresy identifikují jednotlivé multicastové skupiny. Se skupinovými adresami se lze setkat především u šíření obrazového a zvukového signálu v reálném čase, může se tedy jednat např. o videokonference. Jsou také velmi používané v rámci nového systému objevování sousedů v rámci protokolu IPv6. Multicast se vyznačuje odlišným chováním oproti unicastu. Jedná se především o způsob, jakým se mají chovat jeho příjemci. U multicastu si musí jeho příjemce předem říci, že chce data v rámci daného multicastu přijímat, na rozdíl od unicastu, kde v podstatě čeká, až mu nějaká data přijdou. To učiní tak, že odešle patřičné oznámení do sítě, že chce přijímat data dané multicastové skupiny a na základě těchto oznámení jsou klientovi doručována příslušná data tak dlouho, dokud o ně bude mít zájem. Jedno síťové rozhraní může být členem více multicastových skupin. V protokolu IPv6 identifikují jednotlivé multicastové skupiny skupinové adresy, které mají vyčleněný speciální rozsah adres ff00::/8. U skupinových adres v protokolu IPv6 platí zásada, že se dané adresy nesmějí nikdy nalézat v pozici odesílatele datagramu. Skupinové adresy jsou definovány v rámci RFC 4291: IP Version 6 Addressing Architecture [15]. První část struktury skupinové adresy tvoří osmi bitová položka, která slouží k identifikaci, že se jedná o skupinovou adresu. Všech osm bitů je nastaveno na hodnotu jedna. Následuje čtyřbitová položka, která pomocí příznaků 0RPT určuje volby dané adresy. První příznak v této čtyřbitové položce je prozatím vždy nulový, protože je ur čen pro použití v budoucnosti. Příznak R (Rendezvous Point) je použit u skupin souvisejících se směrovacím protokolem PIM-SM (Protocol Independent Multicast Sparse 44

45 Mode). Pomocí tohoto příznaku jsou definovány skupinové adresy, ve kterých hraje klíčovou roli shromaždiště RP ( Rendezvous Point). Pokud tento příznak nabývá hodnoty nula, nezahrnuje daná skupinová adresa RP. V případě, že nabývá hodnoty jedna, pak naopak daná skupinová adresa RP zahrnuje, a dva následující příznaky musí pak být nastaveny na hodnotu jedna. Více informací o RP je možné nalézt v rámci dokumentu RFC 3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address [22]. Příznak P (Prefix) je použit u skupinových adres, které jsou odvozeny z individuálních globálních adres. Pokud je hodnota tohoto příznaku jedna, pak daná skupinová adresa vychází ze síťového prefixu a následující příznak musí být nastaven také na hodnotu jedna. V opačném případě, kdy je hodnota příznaku nula, daná sku pinová adresa nevychází ze síťového prefixu. Příznak T (Transient) slouží k určení, zda bylo přidělení adresy skupině trvalé či nikoliv. Trvalé přidělení adresy zajišťuje IANA ( Internet Assigned Numbers Authority). Pokud je adresa přidělena trvale, má příznak T hodnotu nula. Naopak pokud je adresa přidělena dočasně, má příznak T hodnotu jedna. U dočasného přidělení je podstatné, že může být prováděno jednotlivými aplikacemi v podstatě dle potřeby. Ve struktuře skupinové adresy následuje po volbách čtyřb itová položka dosah (Scope), která určuje jaká je maximální povolená vzdálenost mezi členy dané skupiny. Protože je délka dané položky čtyři bity, je definováno šestnáct jednotlivých skupin dosahu. Poslední položkou struktury skupinové adresy je položka s názvem adresa skupiny (Group ID) o délce sto dvanácti bitů, která již slouží k identifikaci dané skupiny. Protože oblast skupinových adres a jejich směrování je velice rozsáhlá, budou v následujícím textu uvedeny pouze jednotlivé typy skupinových adres a příslušná RFC, ve kterých je možné dohledat příslušné informace. Prvním typem skupinových adres jsou skupinové adresy, které vycházejí z globálních individuálních adres, informace o nich poskytuje RFC 3306: Unicast-Prefix-based IPv6 Multicast Addresses [39]. Dalším 45

46 typem jsou skupinové adresy, které vycházejí z rozhraní, informace poskytuje RFC 4489: A Method for Generating Link-Scoped IPv6 Multicast Addresses [26]. Dále skupinové adresy pro SSM (Source Specific Multicast) a v poslední řadě skupinové adresy, které obsahují RP, a které jsou definovány v rámci RFC 3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address [22]. V rámci skupinových adres ještě existují předdefinované skupinové adresy. Některé z těchto adres jsou definovány v rámci RFC Těmito adresami jsou: ff01::1, což je skupinová adresa pro všechny uzly v rámci jednoho rozhraní a ff02:1, což je skupinová adresa pro všechny uzly v rámci dané linky. Dalšími adresami jsou: ff01::2, což je skupinová adresa pro všechny směrovače v rámci jednoho rozhraní, ff02::2, což je skupinová adresa pro všechny směrovače v rámci jedné linky a ff05::2, což je skupinová adresa pro všechny směrovače v rámci jednoho místa. Velké množství dalších skupinových adres je definováno v rámci dokumentu RFC 2375: IPv6 Multicast Address Assignments [16] Výběrové adresy Jak již bylo popsáno na začátku této kapitoly, výběrové adresy (Anycast Addresses) slouží k adresaci určité skupiny síťových zařízení. Nicméně se nejedná o takový princip a skupinu adres, jako je tomu u adres skupinových. Podstatou skupinových adres je snaha doručit daná data všem síťovým zařízením, která jsou členem d ané skupiny. V případě výběrových adres je tomu jinak, protože daná snaha se týká doručení dat, která pochází z více síťových zařízení, na takové místo v síti, které se vzhledem k danému síťovému zařízení nalézá nejblíže, a které je schopno přijmout a zpracovat tato data. Výběrové adresy jsou popsány v rámci dokumentu RFC 4291: IP Version 6 Addressing Architecture [15]. Výběrové adresy nemají vyhrazenou žádnou konkrétní část adresního prostoru IPv6 a jsou vybírány ze stejných částí adresního prostoru jako globální individuální adresy. Z toho vyplývá, že výběrové adresy mohou být promíchány s globálními individuálními adresami a nejsme proto schopni pouze ze samotné IPv6 adresy zjistit, zda se jedná o adresu 46

47 výběrovou, nebo o globální individuální adresu. Pokud tedy chceme nastavit výběrovou adresu na síťovém zařízení, je nutné při konfiguraci této adresy na patřičném síťovém rozhraní také uvést, že se jedná o výběrovou adresu. Za předpokladu, že nemáme přístup k adresnímu plánu dané sítě, je jednou z možností jak zjistit typ dané adresy, právě z konfigurace adresy daného síťového rozhraní. Výběrové adresy je možné směrovat pomocí klasických metod směrování. Výhodou výběrových adres je, že mohou být agregovány v rámci směrování do určitého bloku adres spolu s globálními individuálními adresami. Klasický způsob směrování tvoří však současně i jednu z nevýhod výběrových adres. Pokud se výběrové adresy budou nalézat v rámci určité podsítě, pak je na směrovačích této podsítě nutné nastavit směrovací záznamy pro dané výběrové adresy, které budou ukazovat na nejbližší členy dané výběrové skupiny. Za předpokladu, že se členové výběrové skupiny nenacházejí v rámci jedné podsítě, ale jsou vzdálenější, je nutné přidat výběrovou adresu do globálních směrovacích informací [2]. Pokud vezmeme v úvahu, že každý další záznam, který je přidaný do směrovacích tabulek, zvyšuje požadavky na výkon směrovače a snižuje jeho rychlost, pak může masivnější použití výběrových adres znamenat nárůst velikosti směrovacích tabulek a to především u směrovačů na páteřních sítích. To je také důvod, proč nejspíše v budoucnu nebudou výběrové adresy použity ve velkém měřítku. Jejich použití bude tedy s velkou pravděpodobností největší v rámci menších sítí. Za hlavní potenciál, který nabízejí výběrové adresy, je možné považovat snížení a rozložení zátěže mezi jednotlivá síťová zařízení např. při poskytování některých služeb v rámci sítě Internet. Snížení/rozložení zátěže je dosaženo díky tomu, že jsou požadavky na danou výběrovou adresu koncentrovány na některém z více síťových zařízen í, která disponují touto výběrové adresou a tak je možné rozložit zátěž např. pomocí určitých oblastí, pro které je konkrétní síťové zařízení spádové. Kromě toho lze použitím výběrových adres dosáhnout snížení doby odezvy a to tak, že je díky výběrové adrese zkrácena přenosová cesta např. mezi serverem a klientem. Použití výběrových adres také umožňuje zmenšení počtu adres 47

48 síťových zařízení, která jsou potřebná pro provozování nějaké síťové služby v rámci sítě Internet, protože místo toho, aby jednotlivá zařízení, která zajišťují chod dané služby, měla vlastní adresy, vystupují daná zařízení pod adresou výběrovou. Tato možnost výběrových adres také snižuje nároky, které jsou spojeny se správou většího množství adres síťových zařízení, která poskytují dané síťové služby. Výběrové adresy také umožňují omezit dopady útoků typu DoS ( Denial of Service ) a DDoS (Distributed Denial of Service). Je to dáno tím, že pokud provádí útočníci útok na danou síťovou službu reprezentovanou výběrovou adresou, je jejich útok rozmělněn na více síťových zařízení s danou výběrovou adresou, dle oblastí, do kterých útočnici spadají. Dobrý příklad globálního využití potenciálu výběrových adres představují kořenové DNS servery. Z hlediska rozložení zátěže by kořenových DNS serverů mělo být co nejvíce, avšak z hlediska toho, že adresy kořenových DNS serverů musí znát většina ostatních DNS serverů, by těchto kořenových serverů nemělo být příliš mnoho. V současnosti je těchto kořenových DNS serverů třináct. Použití výběrových adres však umožňuje, aby se za adresami třinácti kořenových DNS serverů nalézaly stovky těchto serverů [34] Speciální adresy V rámci protokolu IPv6 jsou definovány různé síťové adresy, které zastávají specifické funkce. Mezi ně patří např. adresa lokální smyčky (Loopback), což je v podstatě adresa pro localhost a je zapisována v následujícím tvaru ::1/128. Další adresou je nespecifikovaná adresa, někdy označována jako adresa samých nul, která se především používá v rámci různých programů a zapisuje se ::/128. Další příklady těchto adres byly jmenovány v rámci předchozího textu. 2.7 Povinné adresy uzlu V rámci protokolu IPv4 bylo celkem běžné, že se u síťového rozhraní daného síťového zařízení vyskytovala pouze jedna síťová adresa. Naproti tomu v protokolu IPv6 je standardem, aby jedno síťové rozhraní daného 48

49 síťového zařízení mělo více síťových adres. Je to dáno také tím, že jsou v rámci protokol IPv6 určeny specifické síťové adresy, kterými dané síťové zařízení musí disponovat. Množství a typ daných adres záleží především na tom, jakému účelu dané síťové zařízení slouží. Pokud bychom vzali síťové zařízení, kterým může být např. počítač běžného uživatele, pak daný počítač dle [2], může disponovat následujícími typy adres: Lokální linková adresa pro každé rozhraní. Všechny individuální a výběrové adresy, které mu byly přiděleny. Lokální smyčka (Loopback). Skupinové adresy pro všechny uzly. Skupinová adresa pro vyzývaný uzel pro všechny přidělené individuální výběrové adresy. Všechny skupinové adresy, jejichž je členem. Za předpokladu, že bychom za dané síťové zařízení považovali směrovač, musel by se daný směrovač dle [2] hlásit ke stejným typům síťových adres jako v případě počítače, ale ještě navíc k následujícím adresám: Výběrová adresa pro směrovače v podsíti (pro každé rozhraní, kde funguje jako směrovač). Skupinové adresy pro všechny směrovače. 2.8 Výběr adres Protože síťová zařízení v rámci protokolu IPv6 disponují relativně větším počtem adres, vyvstal problém, jaká z daných adres má být použita pro určitou komunikaci, tak aby bylo dosaženo cíle. Jedná se především o výběr cílových adres a následný výběr adres zdrojových. Řešení tohoto problému bylo specifikováno v rámci RFC 3484: Default Address Selection for Internet Protocol version 6 (IPv6) [18], který se zabývá způsobem výběru dané adresy a definuje algoritmus výběru. 49

50 V souvislosti s danou problematikou byl zaveden pojem kandidátských adres. V rámci kandidátských adres jsou specifikováni kandidáti adres, ze kterých se vybírá je dna adresa, která bude následně použita jako cílová adresa pro danou komunikaci. Nutno dodat, že se daná problematika týká především situací, kdy je cílem komunikace nějaké doménové jméno. Při překladu doménového jména může být systémem DNS vráceno více adres, které jsou následně vloženy do seznamu kandidátských adres. Řešení dané problematiky pro cílové adresy však odpadá, pokud je v rámci dané komunikace předem znám cíl, který je přímo definovaný nějakou adresou. Následně proběhne seřazení jednotlivých adres v rámci seznamu kandidátských adres dle předem definovaných pravidel, a to v pořadí od adresy, která je nejvhodnější, až po adresu, která nejméně vyhovuje. Pokud je ukončen výběr nejvhodnější cílové adresy ze seznamu kandidátských adres, celý problém ještě nekončí, k dané zvolené cílové adrese je ještě třeba vybrat nejvhodnější zdrojovou adresu. Seznam kandidátských zdrojových adres je vytvořen z individuálních adres, které jsou přiřazeny rozhraní, které bude použito v rámci dané komunikace. Je tedy možné, že nastane situace, že pro každou cílovou adresou mohou existovat různé seznamy kandidátských zd rojových adres. Daná situace může nastat např. na směrovači, který komunikuje s ostatními síťovými zařízeními, která se nacházejí v rámci různých sítí, k nimž je daný směrovač připojen. Za předpokladu, že je komunikace po výběru cílové a zdrojové adresy nějakým způsobem neúspěšná, je vybrána další adresa ze seznamu kandidátských cílových adres a výběr zdrojové adresy je opakován znovu. Výběr adres může na jednotlivých síťových zařízeních upravovat správce pomocí úpravy tabulky politik (Policy Table) a standardně je k dispozici předdefinovaná tabulka politik. Tato tabulka funguje na podobném principu jako tabulka směrovacích záznamů a skládá se z jednotlivých záznamů, ve kterých je obsažen prefix, priorita a značka. V rámci dané tabulky je vybrán takový záznam, jehož prefix se nejvíce shoduje s prefixem dané adresy. Zároveň je však výběr ještě ovlivněn 50

51 pomocí priority a značky. Priorita slouží k určení výhodnosti dané cílové adresy. Čím vyšší je hodnota priority, tím výhodnější je použít danou adresu. Značka naopak slouží k určení, zda se k sobě vybraný pár adres hodí. Pár adres, který má shodnou značku, je upřednostňován. Konkrétní pravidla, kterými se daný algoritmus řídí pro výběr zdrojové a cílové adresy, jsou vcelku rozsáhlá a složitá, z toho důvodu nebudou v této práci přímo uvedena a je možné je vyhledat v rámci výše uvedeného RFC 3484 [18]. 51

52 3 Datagram protokolu IPv6 3.1 Úvod do datagramu IPv6 Datagram protokolu IPv6 částečně staví na formátu datagramu, který byl již použit v protokolu IPv4. Pokud uvážíme fakt, že protokol IPv6 má být a považuje se za nástupce dnes masově používaného protokolu IPv4, dojdeme závěru, že muselo dojít k určitým změnám a optimalizacím ve formátu a složení datagramu. Tyto změny, především však změny majoritní, budou popsány v následujícím textu. Formát datagramu a základní informace o jeho částech definuje dokument, který nese označení RFC 2460: Internet Protocol Version 6 (IPv6) Specification [14]. Tento dokument lze také označit a je často označován jako základní stavební prvek celého protokolu IPv6. Zaměřímeli se na samotný datagram v protokolu IPv6, zjistíme, že jeho základní podoba je v podstatě obvyklá. Tedy, že jako první jsou v datagramu hlavičky a za nimi pak následují vlastní data nesená datagramem. Zaměříme-li se však na hlavičky datagramu, objevíme první rozdíly. V protokolu IPv4 měly hlavičky proměnlivou délku a každý další bod, kterým datagram prošel, mohl připojit další volby, které nebyly povinné. V hlavičce datagramu IPv4 byl dále kontrolní součet tzv. header checksum. I když byl tento kontrolní součet vypočítáván pouze ze záhlaví datagramu IPv4 a ne z datagramu celého, tak každá změna v hlavičce datagramu vyvolala potřebu přepočítat kontrolní součet datagramu a změnit jeho hodnotu v hlavičce. Vezmeme-li v úvahu ve většině případů běžné fungování protokolu IPv4, kde při průchodu směrovačem, směrovač změní nějakou položku v záhlaví datagramu protokolu IP např. hodnotu TTL, kterou až na výjimky musí při průchodu změnit. Dostáváme se tedy k faktu, že by každý průchod směrovačem znamenal pro směrovač dodatečnou zátěž ve formě přepočítání kontrolního součtu v hlavičce datagramu protokolu IP. Konkrétně kontrolní součet v hlavičce, tak jak byl použit v protokolu IPv4, je v protokolu IPv6 odstraněn a je změněna i celá koncepce hlavičky 52

53 tak, že je v podstatě v tomto místě nepotřebný. Tento čin je odůvodněn tvrzením, že služba kontrolního součtu je poskytována prostřednictvím nižší vrstvy v síťové architektuře a na úrovni protokolu IPv6 by byl tento úkon opakován znovu a v podstatě redundantně. Což není z hlediska výkonu žádoucí. V protokolu IPv6 je hlavička minimalizována a použití prvků v hlavičce je omezeno pouze na ty prvky, které jsou nutné. Vznikla tak hlavička, která má konstantní počet prvků a je možno ji tedy také označit za hlavičku základní. Podstatným faktem je, že i velikost této základní hlavičky je konstantní. Je tedy patrné, že došlo k maximálnímu zjednodušení struktury základní hlavičky. Všechny ostatní údaje byly přemístěny do rozšiřujících hlaviček, které slouží jako doplnění základní hlavičky o další položky, které však v datagramu na rozdíl od základní hlavičky mohou být přítomny, nebo mohou zcela chybět. Aby byl celý koncept týkající se hlavičky datagramu v protokolu IPv6 škálovatelný, je zaveden systém zřetězení hlaviček. S tím souvisí i odlišný způsob, kterým jsou reprezentovány rozšiřující hlavičky v porovnání s protokolem IPv4. Každá hlavička v tomto systému vytváří samostatný blok. Tyto samostatné bloky jsou propojovány prostřednictvím v protokolu IPv6 nově zavedené položky hlavičky, která se nazývá další hlavička (Next header). Hodnota položky další hlavička, resp. kód v ní obsažený, určuje typ hlavičky, která následuje po hlavičce s tímto kódem. Každá rozšiřující hlavička je uvozena položkou další hlavička. Díky těmto položkám a jejich hodnotám je možno provést zřetězení v podstatě libovolného počtu hlaviček. Tento princip bude podrobněji popsán v příslušné podkapitole. Za povšimnutí stojí také velikosti hlavi ček. Pokud vezmeme hlavičku z datagramu protokolu IPv6 a porovnáme ji s hlavičkou datagramu z protokolu IPv4, zjistíme, že má hlavička protokolu IPv6 pouze dvojnásobnou délku oproti své předchůdkyni. Délka hlavičky datagramu protokolu IPv6 je tedy čtyřicet bajtů, přičemž z těchto čtyřiceti bajtů činí 53

54 třicet dva bajtů pouze adresy příjemce a odesílatele. V protokolu IPv4 měly adresy příjemce a odesílatele délku pouze osmi bajtů. 3.2 Položky základní hlavičky datagramu V této podkapitole budou popsány položky, které obsahuje základní hlavička. Bude osvětlen jejich význam, účel a případné vysvětlení změn oproti hlavičce v protokolu IPv4. Pokud bude v této podkapitole zmíněn pojem datagram, jedná se o IP datagram. Obrázek 3.1: Základní hlavička datagramu protokolu IPv6 Zdroj: [Online] CESNET, z. s. p. o. [Citace: 2. února 2013.] Verze První položkou základní hlavičky datagramu protokolu IPv6 je Verze (Version). Tato položka není žádnou novinkou a je použita ke stejnému účelu i v protokolu IPv4. Slouží k identifikaci verze používaného protokolu IP. V případě protokolu IPv6 je hodnotou obsaženou v této položce číslo šest. V případě protokolu IPv4 je tato hodnota rovna číslu čtyři Třída provozu Následuje položka třída provozu (Traffic Class). Tato položka je v některých českých publikacích také označována jako třída dat [1]. V této práci bude dále pro tuto položku používán název třída provozu, důvodem je větší blízkost originálnímu názvu v anglickém jazyce. Položka třída 54

55 provozu má délku osmi bitů. V některých publikacích je možné narazit i na tvrzení, že tato položka má délku čtyři bity [1]. Toto tvrzení je ovšem pravděpodobně mylné, vzhledem k tomu, že i v RFC 2460: Internet Protocol Version 6 (IPv6) Specification [14] je uvedeno, že se jedná o položku délky osmi bitů. Jejím úkolem je svou hodnotou specifikovat, jakou prioritu má daný datagram, případně do jaké přepravní třídy má být tento datagram zařazen. Účelem je zajištění poskytování služeb se zaručenou kvalitou. Tuto položku využívají především různé síťové body a routery, aby mohly identifikovat a rozlišit provoz dle jednotlivých priorit a přepravních tříd Značka toku Další položku tvoří značka toku (Flow Label). Opět i u této položky je možné najít v některých publikacích odlišné české pojmenování a tím je identifikace toku dat [1]. Tato položka je novinkou v protokolu IPv6 a má délku celkem dvaceti bitů. Značka toku společně s třídou provozu není prozatím přesně definována a je stále v experimentálním stádiu. Tok může být definován jako určitý proud datagramů, který má jisté vlastnosti společné. Může se jednat např. o: adresáta, odesílatele, požadavky na vlastnosti spojení. Pokud je značka toku spojena s adresou odesílatele, je možné toto spojení využít pro jednoznačnou identifikaci jednoho toku dat v síti. Tento princip, který mohou využít např. směrovače ke směrování, umožňuje rychle rozpoznat, kterého toku je daný datagram součástí a provést rozhodnutí dle definovaných pravidel, co s daným datagramem učinit. S jistou pravděpodobností lze říci, že s datagramem, který patří do jednoho určitého identifikovaného datového toku, bude naloženo stejně jako s ostatními datagramy, které patří do téhož datového toku. Klasické směrování probíhá ve většině případů na základě adresy příjemce, použití značky toku tedy umožnuje provádět směrování na základě výše zmíněných vlastností toku, resp. společných vlastností proudu datagramů. Při klasickém směrování jsou dopravovány jednotlivé datagramy od zdroje k cíli samostatně. Tzn., pokud spolu komunikují 55

56 prostřednictvím rozsáhlé sítě dvě zařízení, pak mezi nimi sítí prochází tok datagramů. Směrovače, kterými tento tok datagramů prochází, řeší směrování samostatně pro každý datagram, který jimi projde. Za předpokladu zachování neměnné topologie sítě z tohoto chování vyplývá, že směrovače řeší opakovaně neustále stejný úkol, bez ohledu na množství přenesených datagramů. To zejména při vyšších datových tocích klade vyšší nároky na výkon daných směrovačů. Za předpokladu, že je využito značkování toku a jednotlivé toky jsou odlišeny pomocí značek toku, které toky jednoznačně identifikují, vzniká pro směrovače nová možnost, jak mohou řešit úkol směrování. Opět bereme v úvahu, že zůstává stejná topologie sítě. Směrovače, jimiž prochází tok datagramů, určí příslušnost datagramu k určitému toku dle principů popsaných výše. Nyní směrovačům stačí, aby vyřešily daný úkol (směrování) např., na které síťové rozhraní datagram odeslat, pouze pro první datagram daného toku a do své paměti si uloží vý sledek tohoto rozhodnutí. Následující datagramy, které směrovač zařadí do stejného toku, pak předává do rozhraní, které určil v některém z předchozích rozhodnutí a nemusí řešit samotný úkol směrování. Pokud by některý datagram neodpovídal identifikaci toku, která je uložena v paměti, je opět řešeno směrování, a identifikace spolu s rozhodnutím je uložena do paměti směrovače jako položka. Takto se neustále celý proces opakuje. Pro paměť, ve které si směrovač uchovává daná rozhodnutí, platí pravidlo, že maximální stáří položky je šest sekund. Důvodem pro zavedení maximálního stáří položky je možnost, že odesílatel nějakým způsobem, např. restartem zařízení, ztratí návaznost značek přidělených jednotlivým tokům. Pak je možné, že nastane s ituace, kdy zařízení vygeneruje stejnou již dříve použitou značku toku pro jiný tok. Ovšem i toto opatření obsahuje jednu podmínku. Ta spočívá v tom, že se nepředpokládá, že se dokáže dané zařízení např. zrestartovat během daných šesti sekund. Jiným způsobem využití značek toku je zajištění šířky pásma. U tohoto způsobu využití je však nutná konfigurace směrovačů, kterými tok datagramů prochází a to ve směru od odesílatele k příjemci datagramů. 56

57 Směrovačům se nastaví parametry, dle kterých jsou směrovače schopny identifikovat určený tok datagramů a mohou mu tak zajistit určenou šířku pásma. Datagramy, které přijdou do daného směrovače, se umísťují do fronty, která je klasicky zpracovávaná sekvenčně tzn. metodou FIFO (First In, First Out). V tomto způsobu využití však nemusí být použit klasický sekvenční přístup zpracování příchozích datagramů, a le datagramy, které jsou identifikovány jako součást toku datagramů, u kterého je nastaveno zajištění specifické šířky pásma, mohou být upřednostněny při zpracování fronty (tj. při odesílání daných datagramů z fronty) a to v takové míře, aby bylo dosaženo specifikované šířky pásma. Zároveň je u tohoto způsobu využití vyloučeno použití stanoveného šestisekundového limitu maximální stáří položky, který je specifikován u předchozího výše popsaného způsobu použití. Síťová zařízení, která nepodporují funkcionali tu značky toku, jsou povinna nastavit značku toku na hodnotu nula, pokud jsou zdrojem daného datagramu. Pokud tato zařízení datagram pouze přeposílají, musí ponechat hodnotu značky toku v nezměněné podobě a v případě, že jsou konečnými příjemci datagramu, mají značku toku ignorovat Délka dat Délka dat (Payload Length) je položkou základní hlavičky datagramu, která obsahuje informaci o délce datagramu, tedy specifikuje počet bitů, resp. bajtů, které následují za základní hlavičkou datagramu. Podstatné je, že samotná délka základní hlavičky datagramu se do této položky nezapočítává. Výjimku ovšem tvoří rozšiřující hlavičky, jejichž délka se do délky dat započítává. Samotná délka této položky je šestnáct bitů, resp. dva bajty. Položka je datového typu nezáporného celého čísla (Unsigned Integer). Z toho vyplývá, že maximální hodnotou délky dat je oktetů, resp. bajtů. Tato hodnota je také maximální velikostí paketu, resp. MTU (Max Transmission Unit), tedy maximální přenosovou jednotkou, kte rou je schopna většina protokolů na linkové vrstvě přenést bez fragmentace paketů. 57

58 Pokud by tedy bylo třeba přenést pakety o velikosti větší než je výše zmíněná hodnota, je nutno použít další funkcionalitu protokolu IPv6, která se nazývá Jumbogram, resp. se použije příslušná rozšiřující hlavička datagramu. Podmínkou použití Jumbogramu jsou ovšem komunikační cesty, mající MTU větší než oktetů. Samozřejmě, že tuto podmínku musí splňovat i obě strany, které spolu komunikují prostřednict vím komunikačních cest. Jumbogramy samotnými a vysvětlením jejich použití se bude zabývat samostatná podkapitola Další hlavička Položka Další hlavička (Next Header) specifikuje jaký typ hlavičky, případně jaký typ dat bezprostředně následuje za standardní hlavičkou. Délka této položky je 8 bitů. Při specifikaci jsou použity stejné hodnoty, které používá i protokol IPv4 v položce datagramu se jménem Protokol. Tyto hodnoty jsou specifikovány v dokumentu RFC 1700: Assigned Numbers [36] Maximální počet skoků Položka Maximální počet skoků (Hop Limit) je jinak v českém jazyce nazývána také počet hopů či dosah. Hodnota této položky slouží ke stanovení maximálního počtu skoků, které smí datagram během své cesty sítí vykonat. Položka je tvořena datovým typem nezáporné celé číslo (Unsigned Integer) a má délku osmi bitů. Jeden skok lze definovat jako průchod datagramu jedním směrovačem. Na začátku cesty datagramu, tedy u jeho zdroje, resp. u odesílatele datagramu, je do základní hlavičky datagramu zapsána hodnota položky maximálního počtu skoků. Tuto hodnotu stanovuje odesílatel dle své potřeby. Pokud datagram na své cestě sítí projde směrovačem, směrovač sníží v datagramu hodnotu maximálního počtu skoků o jedna. Pokud hodnota položky maximálního počtu skoků dosáhne nuly, nesmí datagram dále pokračovat a je zahozen. Odesílateli datagramu je zároveň zaslána ICMP zpráva, která ho informuje o tom, že hodnota maximálního počtu 58

59 skoků vypršela. Hlavním účelem této položky je tedy zamezení vzniku možných zacyklení při směrování datagramů. Ovšem maximální počet skoků lze využít také jiným způsobem a to pro určení nejkratší cesty v síti. Prvotním úkolem je nalézt nejbližšího člena určitého multicastu. Postupuje se tak, že je nejprve odeslán datagram, který má nastaven jako svého adresáta určitý multicast, přičemž hodnota položka maximálního počtu skoků je v tomto datagramu nastavena na jedna. Na tento datagram mohou odpovědět pouze t i členové daného multicastu, kteří jsou v bezprostřední blízkosti odesílatele a nejsou umístěni za žádným směrovačem, který by snižoval tuto hodnotu. Je tomu tak, protože po průchodu datagramu směrovačem by došlo ke snížení hodnoty této položky o jedna a hodnota by se tak dostala na úroveň nuly a paket by tak byl zahozen. Pokud na tento datagram s maximálním počtem skoků jedna neodpoví žádný člen daného multicastu, je nutno odeslat datagram, který má zvýšenou hodnotu maximálního počtu skoků o jedna, tedy na hodnotu dva. Pokud se ani nyní nikdo neozve, je hodnota obdobně dále zvyšována, dokud není splněn daný úkol. Tato položka je obdobou položky TTL, tedy doby životnosti datagramu v hlavičce datagramu protokolu IPv Zdrojová a Cílová adresa Zdrojová (Source Address) a Cílová adresa (Destination Address) tvoří dvě položky základní hlavičky. Nicméně tyto položky v podstatě slouží ke stejnému účelu. Jsou nositeli adres protokolu IPv6. Z tohoto důvodu je jejich popis spojen do jedné podkapitoly. Každá z těchto položek má délku sto dvacet osm bitů, což z nich činí v základní hlavičce položky o největší délce. V porovnání a délkou adresy v protokolu IPv4 došlo ke čtyřnásobnému zvětšení. Zdrojová adresa slouží k uložení adresy původce, tedy odesílatele datagramu. Naopak Cílová adresa slouží k uložení adresy adresáta, tedy příjemce datagramu. Funkci této položky může dále upravovat rozšiřující hlavička Směrování. 59

60 3.3 Další hlavičky datagramu Jak již bylo dříve v této kapitole nastíněno, protokol IPv6 má jiný systém struktury hlaviček, než tomu bylo u protokolu IPv4. Jedná se o systém zřetězení hlaviček, který umožňuje velkou škálovatelnost hlavičky, resp. hlaviček datagramu. Tento přístup obecně zahrnuje dva typy hlaviček. Na jedné straně hlavičku základní, která musí být použita a má vždy konstantní počet prvků a konstantní velikost. Na straně druhé zavádí rozšiřující hlavičky, které jak již jejich název napovídá, slouží k rozšíření základní hlavičky a jsou používány pouze v případech, kdy je k tomu důvod. Díky tomu jsou v hlavičkách datagramu obsaženy pouze ty informace, které jsou ve s vé podstatě nezbytné pro splnění zamýšlené funkce. Proto také existuje velké množství typů těchto rozšiřujících hlaviček. Každý typ rozšiřujících hlaviček, případně typ následujících dat je reprezentován číselnou hodnotou. Rozšiřující hlavička také nemůže být použita, aniž by před ní nestála hlavička základní. Zároveň každá z hlaviček tvoří samostatný blok. Tyto bloky jsou propojeny pomocí položky hlaviček, která nese označení Další hlavička. Tato položka uvozuje všechny po základní hlavičce následující rozšiřující hlavičky. Za položkou další hlavička v rozšiřující hlavičce datagramu standardně bývá uvedena položka Délka dat. Tato položka specifikuje délku této rozšiřující hlavičky, resp. o kolik bitů je třeba se při zpracování hlaviček posunout, abych došel k hlavičce následující. Do délky se nepočítá prvních 8 bajtů [2]. Tento mechanizmus je použit např. u Voleb, které jsou popsány v jedné z následujících kapitol. Díky tomuto principu lze teoreticky zřetězit neomezený počet hlaviček, resp. jednu hlavičku základní a neomezený počet hlaviček rozšiřujících. V případě, že jsou použity rozšiřující hlavičky, neobsahuje poslední rozšiřující hlavička v položce Další hlavička typ další rozšiřující hlavičky, ale naopak typ dat, která jsou transportována prostřednictvím datagramu. Zde je patrná jistá podobnost s položkou Protokol hlavičky datagramu protokolu IPv4. 60

61 Opačný případ tvoří datagram, ve kterém se nevyskytují žádné rozšiřující hlavičky. V takovém datagramu je pak obsažena pouze základní hlavička, která ve své položce Další hlavička nese hodnotu reprezentující typ následujících dat. Princip je tedy v podstatě totožný jako v případě poslední rozšiřující hlavičky. Výjimku však může tvořit ještě případ, kdy není v položce Další hlavička v pořadí poslední rozšiřující hlavičky uveden typ následujících dat, ale je zde zapsána číselná hodnota, která představuje typ No Next header (žádná další hlavička). Tento typ vyjadřuje skutečnost, že za poslední rozšiřující hlavičkou nenásleduje již nic, ani žádná data nesená datagramem. Již bylo řečeno, že základní hlavička je v podstatě rozšiřitelná pomocí teoreticky neomezeného počtu rozšiřujících hlaviček. Avšak je nutné dodat, že každá hlavička by se v daném datagramu měla vyskytnout pouze jednou. Toto pravidlo ovšem neplatí pro r ozšiřující hlavičku z kategorie Volby, konkrétně pro rozšiřující hlavičku Volby pro cíl, která bude popsána v následující kapitole. Tato rozšiřující hlavička se v jednom datagramu může použít dvakrát. Konkrétně jednou u Směrování a jednou u Mobility Pořadí hlaviček Možnou negativní stránku tohoto principu představuje fakt, že pokud je zřetězeno velké množství hlaviček, je pro jejich zpracování nutný průchod rozsáhlého řetězce dat. Pokud by zpracování všech těchto hlaviček mělo být vykonáno na každém síťovém prvku např. směrovači, který se nachází mezi odesílatelem a příjemcem, mohlo by dojít k znatelnému snížení výkonu těchto prvků a zároveň ke zvýšení jejich zatížení. Tato možná negativní stránka je řešena pomocí techniky, která předepisuje předem stanovená pořadí určitých skupin rozšiřujících hlaviček, přičemž základní hlavička už z principu musí být umístěna na prvním místě. Tato technika tak řadí hlavičky, které jsou především využívány síťovými prvky, např. již zmíněnými směrovači na cestě sítí od odesílatele k příjemci, na 61

62 přední místa. Tedy před hlavičky, které jsou určené především pro konečného příjemce. Pořadí hlaviček může dle [2] vypadat např. takto: 1. Základní hlavička IPv6. 2. Volby pro všechny (Hop-by-hop Options). 3. Volby pro cíl (Destination Options). 4. Směrování (Routing). 5. Fragmentace (Fragment). 6. Autentizace (Authentication). 7. Šifrování obsahu (Encapsulation Security Payload). 8. Volby pro cíl (Destination Options). 9. Mobilita (Mobility) Volby Volby (Options), které jsou typem rozšiřujících hlaviček v protokolu IPv6, bývají také někdy nazývány jako informace pro směrovače. Důvodem je fakt, že v určitých případech se většina směrovačů předávajících datagram, který obsahuje rozšiřující hlavičku typu Volby, musí zabývat touto rozšiřující hlavičkou. Tato skupina rozšiřujících hlaviček obsahuje celkem dva typy hlaviček. Konkrétně se jedná o Volby pro všechny ( Hopby-hop Options) a Volby pro cíl (Destination Options). Pro oba typy těchto hlaviček je stanoven stejný základní tvar hlavičky. Hlavička je tedy složena z položek Další hlavička, Délka dat a Volby. V poslední položce Volby jsou obsaženy samotné volby, které mohou přímo využívat jednotlivé síťové mechanismy. Oba zmíněné typy voleb využívají volby Pad1 a PadN. Tyto volby slouží ke vkládání vaty volného místa, které má sloužit k lepšímu zarovnání ostatních prvků, jedná se tak o vycpávky, které nenesou žádnou aktivní informaci [2]. Pad1 umožňuje vynechat jeden bajt a PadN umožňuje vynechat dva a více bajtů. Do voleb pro všechny dále patří volba Upozornění směrovače ( Router Alert), volba Rychlý start (Quickstart) a volba Jumbo obsah. Volba Upozornění směrovače, jak již název napovídá, slouží k upozornění všech směrovačů v cestě, že daný datagram obsahuje pro směrovače zajímavá 62

63 data. Volba Rychlý start slouží k určení akceptovatelné přenosové rychlosti napříč všemi směrovači v rámci přenosové cesty. Volba Jumbo obsah umožňuje vytvářet datagramy, jejichž délka přesahuje bajtů. Do voleb pro cíle dále patří volba Domácí adresa ( Home Address), která slouží k podpoře mobility v rámci protokolu IPv6 a slouží k předání domácí adresy odesílatele příjemci Směrování Směrování (Routing) tvoří další typ rozšiřující hlavičky protokolu IPv6. Tato hlavička umožňuje odesílateli datagramu specifikovat, kterými síťovými body, resp. kterými síťovými body identifikovanými prostřednictvím adres IPv6, musí daný datagram projít před tím, než bude doručen jeho adresátovi. Protože existuje více typů směrovacích hlaviček, je v každé rozšiřující hlavičce směrování položka Typ směrování, která slouží právě k rozlišení těchto typů směrování. V současné době jsou definovány celkem dva typy směrování, které byly přesně popsány. Jedná se o typy směrování, které zastupuje hodnota nula a dva. Tyto dva typy směrování budou popsány v následujícím textu. Dále byly definovány dva volné typy směrování, které jsou určeny především pro experimentální činnost týkající se směrování. Tyto typy směrování jsou zastoupeny hodnotou dvě stě padesát tři a dvě stě padesát čtyři. Informace o těchto experimentálních typech směrová ní je možné nalézt v dokumentu RFC 4727: Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers [19]. Nutno podotknout, že princip směrovací hlavičky není v rodině protokolů IP úplnou novinkou. V protokolu IPv4 je možno modifikovat hlavičku pomocí volby Source Routing, která má v podstatě stejný, i když v určitých aspektech omezenější účinek a odlišuje se jemnými detaily. Směrování typu nula je z těchto typů směrování nejstarší a bylo specifikováno přímo v definici dokumentu RFC 2460: Internet Protocol, Version 6 (IPv6) Specification [14]. Jedním z důvodů vzniku tohoto typu směrování bylo vytvoření dalších možností, kterými by mohlo být 63

64 směrování testováno. Příkladem může být klasický ping, který umožňuje testovat dosažitelnost mezi odesílatelem a stanoveným síťovým bodem. Neumožňuje však ověřit propojení mezi dvěma libovolnými síťovými body, jako je tomu právě za předpokladu, že je použita směrovací hlavička typu nula, ve které jsou v podstatě předepsány síťové lokace, mezi kt erými se mají datagramy přepravit. Navíc je možné získat toto ověření propojení dvou síťových bodů obousměrně. Hlavička směrování typu nula obsahuje následující položky : Další hlavička (Next Header), Délka dat (Hdr Ext Len), Typ směrování (Routing Type), Zbývá segmentů (Segments Left), seznam adres (Address[1..n]). Položky Další hlavička a Délka dat byly již popsány dříve. Položka Typ slouží k identifikaci použitého typu směrování a obsahuje hodnotu nula pro určení aktuálně popisovaného typu směrování. Položka Zbývá segmentů popisuje počet adres ze seznamu adres, kterými musí daný datagram ještě projít, než dosáhne cíle. Obrázek 3.2: Rozšiřující hlavička směrování typu nula Zdroj: Satrapa, Pavel IPv6 Internetový protokol verze 6. třetí vydání. Praha : CZ.NIC, z. s. p. o., str ISBN Tento typ směrování nejvíce odpovídá popisu směrování, který byl popsán v úvodu této kapitoly, protože tato směrovací hlavička obsahuje seznam adres a počítadlo, které určuje, kolik z odesílatelem 64

65 specifikovaných adres je třeba ještě projít v daném pořadí. V následujícím textu se pojmem síťový bod rozumí např. směrovač. Podstatné je, že seznam adres obsažený v tomto typu směrování nestanovuje, že datagra m musí projít přesně těmito síťovými body, resp. adresami, a žádnými jinými ve stanoveném pořadí. Právě naopak, datagram při své cestě napříč sítí od odesílatele k příjemci může projít libovolným počtem síťových bodů, ale během své cesty musí projít síťovými body, které odpovídají adresám síťových bodů specifikovaných odesílatelem a to v daném pořadí. Jinak řečeno, mezi každými dvěma, odesílatelem datagramu specifikovanými síťovými body, resp. jejich adresami, může datagram projít libovolným počtem jiných síťových bodů. Tento seznam odesílatelem specifikovaných adres zároveň během cesty datagramu napříč sítí slouží i jako seznam síťových bodů, resp. jejich adres, kterými datagram již prošel. Celý princip spočívá v tom, že se během cesty datagramu sítí postupně přesouvají jednotlivé adresy mezi směrovací hlavičkou a položkou Adresa příjemce ve standardní hlavičce datagramu. Použití směrování typu nula však kromě patrných výhod může představovat i jistá bezpečností rizika. Pomocí této hlavičky lze provést útok, jehož výsledkem může být přehlcení určitých síťových linek. Tento útok je založen na uložení velkého počtu adres, kterými má datagram projít, do rozšiřující hlavičky směrování. Pokud je seznam adres rozsáhlý, může to znamenat, že se daný datagram bude pohybovat napříč sítí nemalou dobu. Za předpokladu, že se takovýchto datagramů objeví více, mohou vzniknout datové toky, které mohou přesahovat velikost konektivity útočníka v násobcích. Pavel Satrapa uvádí ve své knize o IPv6, že v praxi byla překročena konektivita útočníka osmdesát osm krát. Kromě tohoto útoku, může směrovací hlavička představovat pro útočníka také možnost, jak obejít firewall. Analýza a projednávání těchto bezpečnostních rizik vyústily v roce 2007 k vydání dokumentu RFC 5095: Deprecation of Type 0 Routing Headers in IPv6 [3], který v podstatě zakazuje použití Směrování typu nula a specifikuje způsoby, jak má být zacházeno s datagramy, které jsou takto směrovány. 65

66 Směrování typu dva představuje v podstatě zjednodušenou verzi Směrování typu nula a je využíváno především pro potřeby mobility, přičemž je u něj použito prakticky stejných mechanismů jako u Směrování typu nula. Tato rozšiřující hlavička, resp. tento typ směrování, byl zaveden v rámci podpory mobility v protokolu IPv6 a je popsán v dokumentu RFC 3775: Mobility Support in IPv6 [4]. Jedním z hlavních rozdílů tohoto směrování, oproti Směrování typu nula, je omezení adres uložených ve směrovací hlavičce pouze na jedinou adresu, kterou je domácí adresa mobilního uzlu. Fakt, že je Směrování typu dva v podstatě odvozeno od Směrování typu nula, potvrzuje i struktura rozšiřující hlavičky Směrování typu dva, která je až na drobné odchylky stejná. Odlišnosti lze odvodit již z popisu Směrování typu dva. V následujícím textu budou zmíněny pouze dané odlišnosti. Položka Délka dat má předdefinovanou hodnotu dva, stejně jako položka Typ směrování. V položce Zbývá segmentů je nastavena hodnota jedna, která určuje, že v daném datagramu lze specifikovat pouze jednu adresu síťového bodu, kterou má daný datagram během své cesty sítí projít. Poslední odlišnost je v položce, která byla u Směrování typu nula popsána jako seznam adres. Zde je této položce přidělen název Domácí adresa (Home address), která namísto seznamu adres obsahuje pouze jednu adresu. Všechny tyto změny mimo jiné snižují i možnosti zneužití tohoto typu směrování v porovnání se Směrováním typu dva. Mobilní uzel používá v podstatě dva druhy adres. Prvním druhem adresy je pevná, resp. trvalá adresa, kterou má mobilní uzel trvale přidělenou v místě svého sídla. Na druhé straně stojí adresa dočasná, kterou má mobilní uzel přidělenou dle sítě, ve které se v daný okamžik nachází. U mobilního uzlu se předpokládá, že nebude umístěn stále na jednom místě, ale bude se pohybovat. Proto je velice pravděpodobné, že se s jeho pohybem bude měnit i jeho dočasná adresa, tak jak bude přecházet mezi jednotlivými sítěmi, nebo jejich částmi. Tyto změny adres by bez použití tohoto typu směrování znamenaly přerušení navázaných komunikací. Pro zachování kontinuity spojení používá mobilní uzel pro odchozí komunikaci svoji pevnou adresu, resp. adresu domácí. Pokud se 66

67 jedná o komunikaci pro mobilní uzel příchozí, nastaví odesílatel pomocí směrovací hlavičky typu dva, že má být daná komunikace nejprve směrována na dočasnou adresu mobilního uzlu, avšak jako cílová adresa je nastavena pevná adresa mobilního uzlu Fragmentace Fragmentace, kterou používá protokol IPv6, nepředstavuje v rodině protokolů IP žádnou novinku a je široce využívána i v protokolu IPv4. Přesto protokol IPv6 přináší ve fragmentaci jisté změny. Jsou jimi např. změna síťových subjektů, které smějí fragmentac i vykonávat, nebo zavedení rozšiřující hlavičky do systému rozšiřujících hlaviček datagramu pod názvem Fragmentace (Fragment), která je popsána v rámci dokumentu RFC 2460: Internet Protocol, Version 6 (IPv6) Specification [14]. Pro přepravu datagramů napříč sítí slouží tzv. přenosové cesty, které jsou složeny z linek a jednotlivých průchozích uzlů. Každá z linek může mít rozdílnou MTU, což je hodnota, která udává, jakou maximální velikost datagramu je linka schopna přenést. Pokud se jedná o MTU celé přenosové cesty, hovoříme o PMTU (Path MTU). Ta představuje maximální velikost datagramu, kterou je schopna celá přenosová cesta přenést. Tuto hodnotu určuje hodnota MTU linky, která je obsažena v přenosové cestě, přičemž její hodnota MTU je ze všech obsažených linek nejmenší. Linku je zde možné definovat jako propojení jednotlivých síťových bodů, resp. síťových uzlů, a to konkrétně na druhé vrstvě při použití referenčního modelu ISO/OSI. Zástupcem této vrstvy může být např. Et hernet, který v dnešní době představuje velice rozšířenou technologii. Obvyklá neboli standardní hodnota MTU u Ethernetu je tisíc pět set bajtů. Rozšiřující hlavička Fragmentace (Fragment Header) obsahuje následující položky: Další hlavička (Next Header), rezerva (Reserved), Posun fragmentu (Fragment Offset), položku Res, příznak M (More Fragments M flag) a poslední položku tvoří Identifikace (Identification). Rozšiřující hlavička Fragmentace je určena pomocí čísla čtyřicet čtyři v položce Další hlavička předcházející hlavičky. Velikost této rozšiřující hlavičky je neměnná. 67

68 Význam první položky Další hlavička této rozšiřující hlavi čky již byl popsán v předchozím textu a v tomto použití se nikterak nemění, proto ho není třeba dále popisovat. Položka Posun Fragmentu má délku třináct bitů a je typu nezáporného celého čísla. Jako jednotku používá oktety, resp. osmice bajtů od začátku fragmentovatelné části původního datagramu, a určuje, kam tento fragment patří [2]. Příznak M určuje, o jaký typ fragmentu se jedná, konkrétně zda jde o fragment poslední, nebo zda je za tímto fragmentem obsažen ještě další fragment. V případě, že se jedná o fragment poslední, je hodnota této položky rovna nule, pokud je za stávajícím fragmentem obsažen ještě fragment další, je hodnota této položky rovna jedné. Položka Identifikace má délku třicet dva bitů a datový typ této položky je celé číslo. Daná položka zajišťuje, aby bylo možno rozeznat, které z fragmentů náleží do stejné skupiny, resp. k sobě. Každému datagramu, který je fragmentován, přidělí jeho odesílatel jeho identifikační hodnotu, kterou zapíše do položky Identifikace. Tato hodnota by měla být jednoznačná ve vztahu odesílatele fragmentovaného datagramu a jeho příjemce. Pokud tedy dojde k odeslání dalšího fragmentovaného datagramu odesílatelem příjemci, je hodnota položky Identifikace tohoto dalšího odeslaného fragmentovaného datagramu vypočítána tak, že dojde k navýšení poslední použité hodnoty této položky o jedna. V případě, že by toto navýšení mělo znamenat překročení daného rozsahu možn ých hodnot této položky, je hodnota položky vynulována a začíná se tedy číslovat opět od čísla nula. Příklad použití položky Identifikace je popsán v následujícím textu této kapitoly. Celý princip fragmentace spočívá v rozdělení datagramu, jehož velikost přesahuje velikost hodnoty MTU linky a to na menší datagramy, které mají takovou velikost, kterou je možno po lince přenést s ohledem na hodnotu MTU použité linky. Jinak řečeno, fragmentace umožňuje protokolu IPv6 přenášet datagramy, jejichž velikost přesah uje MTU použité linky. Pokud tedy chce odesílatel doručit datagram příjemci a velikost datagramu je vyšší než hodnota MTU použité linky, musí odesílatel datagram rozložit na několik menších datagramů dle již výše zmíněného pravidla a t yto menší datagramy následně odeslat příjemci. Příjemce naopak menší datagramy po 68

69 jejich přijetí zkompletuje do původního datagramu. Fragmentace obecně klade dodatečné nároky na síťové body, resp. síťové uzly, a zvyšuje tak míru jejich zatížení. S tímto faktem bylo při návrhu fragmentace v protokolu IPv6 počítáno, a tak může v tomto protokolu provádět fragmentaci datagramu pouze jeho odesílatel. Toto pravidlo sebou nese další nutnou úpravu chování. Pokud odesílatel odešle datagram, který během své cesty sítí k jeho příjemci narazí na linku, která má menší MTU, než je velikost datagramu, je tento datagram zahozen síťovým bodem, resp. síťovým uzlem a síťový uzel, který provedl zahození tohoto datagramu zašle informaci jeho odesílateli prostřednictvím ICMP zprávy Paket příliš velký (Packet too Big). V této ICMP zprávě je zároveň obsažena informace o velikosti dané MTU, kvůli které byla daná akce vyvolána. Právě z důvodu možných rozdílných hodnot MTU linek, které se nacházejí v přenosové cestě, zavádí protokol IPv6 algoritmus objevování MTU přenosové cesty PMTUD (Path MTU Discovery), který je definovaný v RFC 1191: Path MTU Discovery [17]. Cílem tohoto algoritmu je nalézt hodnotu PMTU. Tedy jak velký datagram lze pomocí přenosové cesty dopravit k cíli. Celý postup probíhá v několika krocích. V prvním kroku odesílatel odešle datagram, který má velikost shodující se s velikostí MTU síťového rozhraní, přes které je datagram odesílán. První krok zároveň stanovuje, že MTU přenosové cesty již nemůže být vyšší, než je hodnota MTU daného síťového rozhraní. Druhý krok ověřuje, zda datagram, který má velikost shodnou s MTU rozhraní odesílatele, došel k cíli. Za předpokladu, že se tak stalo, je již známo MTU přenosové cesty, které se tedy v tomto případě rovná MTU síťového rozhraní odesílatele. Pokud odeslaný datagram k cíli nedorazí, resp. pokud odesílatel obdrží ICMP zprávu o překročení velikosti datagramu s informací o hodnotě MTU, která byla v kolizi s velikostí odeslaného datagramu, je odesílatelem upravena velikost MTU přenosové cesty. Následně odesílatel odešle k cíli nový datagram, jehož velikost je patřičně upravena. Pokud tento datagram dorazí k cíli, je známa velikost MTU přenosové cesty. Za předpokladu, že se tak nestane, je celý tento proces opakován do té doby, než je datagram doručen k cíli, tedy než je známa skutečná velikost MTU přenosové cesty. 69

70 Pokud tedy chce odesílatel odeslat datagram, který musí být např. z důvodu nižšího MTU přenosové cesty fragmentován, rozdělí se tento původní (originální) datagram na dvě části. Konkrétně na fragmentovatelnou (Fragmentable Part) a nefragmentovatelnou (Unfragmentable Part) část datagramu. V popředí stojí nefragmentovatelná část datagramu, ve které je obsažena standardní část hlavičky datagramu a za ní dále všechny rozšiřující hlavičky datagramu (pokud jsou obsaženy), až k poslední obsažené rozšiřující hlavičce, kterou je rozšiřující hlavička Směrování. Jedná se tedy o standardní hlavičku a rozšiřující hlavičky datagramu, které musí být za účelem doručení datagramu zpracovány síťovými body, resp. síťovými uzly, v rámci průchodu datagramu sítí. Jinak řečeno, jedná se o všechny hlavičky datagramu, které jsou umístěny před rozšiřující hlavičkou datagramu Fragmentace. Jak již název této části napovídá, není tato část předmětem fragmentace. Důvodem, proč tato část datagramu není předmětem fragmentace, je zabezpečení přístupu síťovým uzlům k potřebným hlavičkám datagramu. Ve fragmentovatelné části datagramu je tedy obsažen zbytek datagramu, který není obsažen v nefragmentovatelné části a pouze tato fragmentovatelná č ást datagramu je fragmentována. Obsahem fragmentovatelné části jsou např. rozšiřující hlavičky datagramu, které jsou zpracovávány pouze příjemcem datagramu, nebo hlavičky vyšších vrstev, případně samotná data. Fragmentovatelná část původního datagramu je dále rozdělena na fragmenty (úseky), které mají velikost v násobcích osmi bajtů, a jejich velikost nepřesahuje velikost danou MTU např. prostřednictvím MTU přenosové cesty. Tímto způsobem jsou vytvořeny z původního datagramu nové datagramy, resp. fragmenty. Hlavičky těchto fragmentů jsou skládány následovně. Nejprve je převzata nefragmentovatelná část původního datagramu a vložena do jednotlivých fragmentů. Podstatné je, že pro jednotlivé fragmenty je nutné tuto část upravit. Pro dané fragmenty je tedy uprav ena velikost v základní hlavičce, protože tato hodnota musí odpovídat skutečné velikosti daného fragmentu. Dále je změněna hodnota Další hlavička poslední rozšiřující hlavičky obsažené v nefragmentovatelné části, tak aby její hodnota byla čtyřicet čtyři. Tato hodnota značí, že další následující rozšiřující hlavičkou je 70

71 Fragmentace. Následně je připojena rozšiřující hlavička Fragmentace. Pro tuto rozšiřující hlavičku je vytvořena nová Identifikace datagramu a tato hodnota je následně přidělena všem fragmentům původního datagramu. Dále je nastavena položka Další hlavička, jejíž hodnota je převzata z poslední Další hlavičky nefragmentovatelné části původního datagramu. Následně je změněna položka Posun fragmentu. Posun každého fragmentu se určí jako počet osmic bajtů, o které je jeho začátek vzdálen od začátku fragmentovatelné části původního datagramu ; jelikož všechny fragmenty (kromě posledního) budou mít stejnou délku x, bude mít první fragment Posun nulový, druhý fragment ponese Posun=x, třetí Posun=2x atd. [2]. Při nastavování příznaku M se postupuje podle toho, zda se jedná o poslední fragment či nikoliv. Pro poslední fragment je tomuto příznaku nast avena hodnota nula a pro ostatní hodnota jedna. Jako poslední je připojen kus fragmentovatelné části původní datagramu, tedy fragment. Po tomto rozdělení původního datagramu, resp. po jeho fragmentaci, jsou vzniklé fragmenty odeslány ve formě samostatných datagramů příjemci původního datagramu. Příjemce těchto fragmentů je postupně přijme a díky hodnotám, které byly nastaveny při fragmentaci v rozšiřující hlavičce Fragmentace těchto fragmentů, je může složit do podoby původního datagramu. Při procesu skládání těchto fragmentů hraje důležitou roli položka Identifikace rozšiřující hlavičky Fragmentace, protože díky ní je příjemce schopen rozpoznat fragmenty, které patří k sobě. Jaké je správné pořadí fragmentů, zjistí příjemce pomocí položky Posun fragmentu. Pokud tuto položku zkombinuje ještě s položkou Délka dat, je schopen určit zda nechybí některé části a případně jaké. Pro zjištění, zda jsou příjemcem přijaty všechny části, mu poslouží příznak M. Díky těmto údajům je tedy příjemce schopen zrekonstruovat původní datagram v podstatě do takové podoby, jakou měl před zahájením fragmentace. Jinak řečeno v zrekonstruovaném datagramu zanikají všechny rozšiřující hlavičky Fragmentace. 71

72 3.3.5 Jumbogram Jumbogram (Jumbogram) je v protokolu IPv6 datagram, který nese data o délce vyšší než bajtů. Je to dáno tím, že maximální hodnota délky dat, které nese datagram, je specifikována v šestnácti bitové položce základní hlavičky Délka dat. Přičemž do šestnácti bitů lze uloži t maximální hodnotu Specifikaci Jumbogramů v protokolu IPv6 popisuje dokument RFC 2675: IPv6 Jumbograms [7]. Jumbogramy se v protokolu IPv6 vytvářejí prostřednictvím Volby pro všechny s názvem Jumbo obsah (Jumbo Payload), kterou se zabývá každý síťový uzel např. směrovač v rámci dané síťové trasy. Tato volba umožňuje odesílateli sestavovat datagramy, které mají velikost v rozmezí bajtů [7]. Aby mělo použití Jumbogramu smysl, je nezbytné, aby odesílatel měl k dispozici přenosovou cestu, jejíž MTU je vyšší než bajtů. Pokud některé síťové prvky v přenosové cestě nemají MTU dostatečně velké, nemusí podporovat Jumbogramy ani nikterak manipulovat s danou volbou. V knize [2] autor popisuje Jumbogramy jako spíše zajímavou teoretickou konstrukci, než prakticky použitelný nástroj. Jako důvod uvádí fakt, že potřebná MTU o takových velikostech, která by je umožňovala využít, se v současném internetu nevyskytují. Pokud jsou Jumbogramy použity, resp. pokud je použita volba Jumbo obsah, dojde k vynulování položky Délka dat. Důvod k tomuto vynulování byl popsán v předchozím odstavci. Následně je do datagramu přidána rozšiřující hlavička, která obsahuje Volby pro všechny, které obsahují Jumbo obsah. Volba Jumbo obsah se skládá celkem ze tří položek. Položka Typ volby (Option Type), má délku osmi bitů a v tomto použití nese konkrétní hodnotu 194. Další položkou je Délka volby (Opt Data Len), která v tomto případě nese hodnotu 4. Délka této položky je opět osm bitů. Poslední položkou je Délka jumbo dat ( Jumbo Payload Length) o délce třicet dva bitů, která využívá datový typ nezáporného celého čísla. Jedná se v podstatě o klíčovou položku celého Jumbogramu, protože umož ňuje uložit údaj o velikosti datagramu, resp. Jumbogramu, která přesahuje hodnotu 72

73 a pohybuje se v rozmezí, které bylo specifikováno v předchozím odstavci. 73

74 4 Konfigurace protokolu IPv6 Následující kapitola se zabývá popisem některých z možností konfigurace protokolu IPv6 v rámci vyjmenovaných operačních systémů, které podporují protokol IPv6. Předmětem popisu bude především statická konfigurace protokolu IPv6 u klientských síťových zařízení. Protože u dynamické konfigurace postačuje mít povolenou podporu protokolu IPv6 a zapnutou automatickou konfiguraci protokolu IPv6, o veškerá nastavení se již postarají patřičné mechanismy (ve většině případů je toto standardní chování), ovšem za předpokladu, že jsou v rámci dané sítě podporovány. Informace o příslušných mechanismech autokonfigurace, je možné nalézt v kapitole 1.7. Co se týče statické konfigurace protokolu IPv6 je v podstatě v rámci všech operačních systémů a zařízení podobná. Dochází k nastavování velice podobných položek konfigurace protokolu IPv6. Ve většině případů se pak od sebe jednotlivé systémy a zařízení odlišují příslušným způsobem, postupy zadávání nastavení protokolu IPv6 a rozsahem jeho podpory. Jednotlivé způsoby konfigurace se od sebe také od lišují tím, jakým způsobem je realizována pro dané síťové zařízení konektivita IPv6. Jedním a nejlepším případem IPv6 konektivity je nativní připojení prostřednictvím protokolu IPv6. Případů, kdy poskytovatel umožňuje nativní připojení pomocí protokolu IPv6, je stále však velice málo. Pokud hovoříme o nativním připojení, je myšlen takový druh připojení, kdy je možné používat přímo globální individuální adresu protokolu IPv6, která patří do rozsahu poskytovatele internetu. Je pak možné přenášet datagramy protokolu IPv6 přímo bez nějakých dalších podpůrných systémů. Další možností, jak mít dostupnou IPv6 konektivitu na daném síťovém zařízení, je prostřednictvím různých druhů tunelů, které tunelují IPv6 konektivitu prostřednictvím konektivity protokolu IPv4. 74

75 4.1 Microsoft Windows XP Operační systém Windows XP od firmy Microsoft je prvním operačním systémem této firmy, který podporoval protokol IPv6. Protokol IPv6 však nebyl v daném operačním systému podporován od počátku, ale jeho podpora byla přidána až v roce 2002 v rámci Service Pack 1. Podstatné však je, že jde o podporu, která není úplná. Jako příklad neúplné podpory je možné uvést dotazy na DNS server, které jsou odesílány pouze prostřednictvím protokolu IPv4 [29]. Dalším důkazem, že daný operační systém nabízí pouze částečnou podporu, je nemožnost statické konfigurace protokolu IPv6 na určitém rozhraní, pomocí grafického uživatelského rozhraní. Pokročilé možnosti konfigurace protokolu IPv6 včetně statické konfigurace jsou tak dostupné pouze prostřednictvím příkazového řádku. Obrázek 4.1: Konfigurace IPv6 ve Windows XP Zdroj: Vlastní úprava Jasně viditelné nepřístupné (zešedlé) tlačítko Vlastnosti na Obrázku 4.1 potvrzuje nemožnost konfigurace protokolu IPv6 prostřednictvím grafického uživatelského rozhraní. V rámci konfigurace v tomto uživatelské rozhraní je tedy možné pouze povolit podporu protok olu IPv6 75

76 a veškerou následující konfiguraci pak převezmou příslušné mechanismy autokonfigurace Windows Vista, Windows 7 a Windows 8 Podpora protokolu IPv6 je v rámci operačních systémů Windows Vista, Windows 7 a Windows 8 v podstatě stejná. Je to dáno tím, že operační systém Windows 7 převzal ve velké míře podporu protokolu IPv6 přímo z Windows Vista. Drobné odlišnosti ve Windows 7 je možné nalézt především v pojmenování určitých položek a v grafickém uživatelském rozhraní [28]. Podpora protokolu IPv6 je však na rozdíl od Windows XP v těchto operačních systémech na vysoké úrovni. Podpora k protokolu IPv6 je v rámci těchto systémů také vyjádřena tak, že je implicitně aktivována. V obou operačních systémech byla navíc zavedena podpora automatického tunelovacího mechanismu Teredo, který zprostředkovává připojení k síti IPv6 na místech, kde je dostupná konektivita pouze prostřednictvím protokolu IPv4. Výhodou této technologie je její dobrá schopnost procházet technologií NAT, avšak díky tomu také není příliš efektivní. Samozřejmostí obou systémů je také podpora bezstavové automatické konfigurace a systému DHCPv6. Statickou konfiguraci protokolu IPv6 prostřednictvím uživatelského rozhraní Windows 7 je možné nalézt pomocí následující cesty: Ovládací panely Síť a Internet Centrum síťových připojení Změnit nastavení adaptéru, zde je třeba vybrat příslušné síťové rozhraní, otevřít ho a stisknout tlačítko Vlastnosti. Poté již stačí z jednotlivých položek připojení vybrat Protokol IP verze 6 (TCP/IPv6) a zvolit opět Vlastnosti. Následně se zobrazí příslušné dialogové okno, které je viditelné na obrázku 4.2, a jehož prostřednictvím je možné měnit jednotlivé konfigurační parametry protokolu IPv6. V rámci Windows Vista je přístup k této konfiguraci velice podobný, pouze se mohou jednotlivé položky cesty mírně odlišovat v příslušných názvech. 76

77 Obrázek 4.2: Konfigurace IPv6 ve Windows 7 Zdroj: Vlastní úprava Na obrázku 4.2 je viditelná situace, kdy byla zrušena volba použití některého z autokonfiguračních mechanismů a byla vybrána volba manuální (statické) konfigurace. V rámci dané konfigurace byla jako pří klad použita globální individuální IPv6 adresa 2a01:490:1d:130:981:5746:2721:4000 s prefixem o délce šedesát čtyři bitů. Jako výchozí brána a jediný DNS server slouží v tomto případě konfigurace IPv6 adresa 2a01:490:1d:130::1. Obrázek 4.3: Podrobnosti konfigurace IPv6 ve Windows 7 Zdroj: Vlastní úprava 77

78 Na obrázku 4.3 je pak možné spatřit nastavenou konfiguraci pro dané síťové rozhraní. Mimo konfiguračních parametrů, které se týkají protokolu IPv6, je zde možné spatřit i konfiguraci protokolu IPv4, která byla nastavena prostřednictvím automatické konfigurace. Za povšimnutí také stojí, že autoři v tomto výpisu konfigurace vypustili položku, která by popisovala prefix adresy IPv6. V souhrnu z dané konfigurace vyplývá, že je nativně k dispozici jak konektivita prostřednictvím protokolu IPv4, tak prostřednictvím protokolu IPv Linux Podpora protokolu IPv6 existuje v jádře Linuxu již od roku 1996, tato podpora byla však až do roku 2005 označována pouze jako experimentální. V současnosti se řadí podpora protokolu IPv6 v jádře Linuxu k nejkvalitnějším podporám tohoto protokolu. Operační systém (dále jen OS) Linux tedy podporuje protokol IPv6 a to na velmi dobré úrovni, avšak aby bylo možné aktivně provozovat tento protokol na tomto OS, je třeba využívat jádro, které je sestaveno s podporou protokolu IPv6. V současnosti se doporučuje používat verzi jádra ze série 2.6 a vyšší. Tento požadavek však dnes splňuje drtivá většina aktivně vyvíjených distribucí OS Linux. Je to dáno tím, že aktivně vyvíjené distribuce používají relativně nová jádra OS Linux. Samozřejmě, že podpora protokolu IPv6 může fungovat i na starších distribucích OS Linux, záleží především na verzi provozovaného jádra. Pokud je tedy provozované jádro dané distribuce sestaveno s podporou protokolu IPv6, ještě to neznamená, že je daný protokol IPv6 možné začít okamžitě konfigurovat. Záleží především na tom, jakým způsobem byla podpora protokolu IPv6 v daném jádře sestavena. Tedy zda byla sestavena formou modulu, nebo zda byla zabudována přímo do jádra. Pokud je zabudována přímo do jádra, není třeba pro zapnutí této podpory s největší pravděpodobností nic dalšího podnikat. Za předpokladu, že byla podpora daného protokolu sestavena jako modul, je třeba pro aktivaci 78

79 podpory IPv6 tento modul zavést ručně, případně upravit konfiguraci zavádění jednotlivých modulů (za předpokladu, že zavádění modulu není nastaveno implicitně). Zavedení příslušného modulu je možné v superuživatelském režimu pomocí příkazu modprobe, za kterým následuje název protokolu, tedy IPv6. Celý příkaz pak vypadá takto modprobe ipv6. Zavedení daného modulu a dalších součástí lze zkontrolovat pomocí příkazu lsmod grep ipv6. Výstupem tohoto příkazu je výpis zavedených modulů jádra, které ve svém názvu obsahují řetězec ipv6. Za předpokladu, že je jádro sestaveno s patřičnou podporou protokolu IPv6 a tato podpora je aktivována, je možné přejít ke konfiguraci protokolu IPv6, resp. jeho síťových parametrů, prostřednictvím některého z nástrojů, které jsou k tomu určené. V rámci linuxových distribucí se nejčastěji objevují dvě skupiny nástrojů, kterými lze konfigurovat jednotlivá síťová rozhraní a nejen je. První skupinu tvoří nástroje ifconfig (většinou součástí balíčku net-tools) a route (většinou součástí balíčku nettools). Druhou skupinu pak tvoří nástroj ip (většinou součástí balíčku iproute, někdy také označovaného jako iproute2 ). Samozřejmě lze ke statické konfiguraci použít některé z mnoha grafických uživatelských rozhraní, ale ty jsou většinou ve své podstatě pouze nadstavbou nad výše zmíněnými nástroji, a proto nebude konfigurace tohoto druhu popsána. Obecně se doporučuje používat novějšího nástroje ip, protože je jeho prostřednictvím možné nastavovat více síťových parametrů a má lepší podporu. Z toho důvodu bude dále pro vysvětlení konfigurace protokolu IPv6 použit daný nástroj ip. Pro konfiguraci ipv6 adresy a jejího prefixu pro dané síťové rozhraní v superuživatelském režimu za pomocí nástroje ip vypadá struktura použitého příkazu následovně: ip -6 addr add adresa/prefix dev rozhraní Parametr -6 označuje, že se jedná o konfiguraci síťových parametrů, které se týkají protokolu IPv6. Parametr addr vyjadřuje, že se jedná o konfiguraci IP adresy, přičemž za ním následuje zápis příslušné 79

80 IPv6 adresy a jejího prefixu. Parametr dev slouží k určení síťového rozhraní, ke kterému bude daná konfigurace přiřazena, a za tímto parametrem následuje zápis názvu daného síťového rozhraní. Při konfiguraci globální individuální adresy by tedy tento příkaz mohl vypadat takto: ip -6 addr add 2a01:490:1d:130:ec2d:2245:2d6:6365/64 dev eth0 Výsledkem vykonání tohoto příkazu je nastavení globální individuální adresy IPv6 2a01:490:1d:130:ec2d:2245:2d6:6365, která má délku prefixu šedesát čtyři k síťovému rozhraní označenému jako eth0. Pokud však chceme komunikovat se síťovými zařízení mi, která se nacházejí mimo hranici dané sítě, kterou vymezuje stanovený prefix, je třeba přidat do směrovací tabulky adresu síťového zařízení ( v tomto případě směrovače), které bude sloužit jako výchozí brána. Opět bude nejprve popsána struktura odpovídajícího příkazu, která vypadá následovně: ip -6 route add default via adresa Parametr -6 zastává stejný význam jako v předchozím příkladu. Parametr route označuje, že se jedná o úpravu konfigurace směrovací tabulky. Následující parametr add vyjadřuje, že se bude jednat o přidání záznamu do směrovací tabulky. Parametr default označu je, že se jedná o typ záznamu, který vyjadřuje výchozí bránu a za tímto již následuje zápis samotné IPv6 adresy směrovače, který slouží jako výchozí brána. V reálném použit může tento příkaz vypadat následovně: ip -6 route add default via 2a01:490:1d:130::1 Po vykonání tohoto příkazu je do směrovací tabulky přidán záznam, který říká, že v rámci protokolu IPv6 má být pro komunikaci s ostatními sítěmi použita výchozí brána, která se nalézá na IPv6 adrese 2a01:490:1d:130::1. 80

81 Obrázek 4.4: Výpis nastavení IPv6 před zahájením konfigurace Zdroj: Vlastní úprava Při aplikaci výše popsaného nastavení, by mělo síťové zařízení, na které je toto nastavení aplikováno, být schopno komunikovat i v rámci sítě Internet (za předpokladu, že je dostupná IPv6 konektivita a komunikaci nic nebrání). Samozřejmě, že by tato komunikace byla funkční pouze za předpokladu znalosti konkrétních IPv6 adres. Pro plnohodnotné připojení je tak nutné ještě nakonfigurovat adresu serveru DNS, který bude sloužit pro překlad doménových jmen. To lze provést prostřednictvím konfiguračního souboru resolv.conf, který se nalézá v adresáři etc. Daný konfigurační soubor je třeba upravit takovým způsobem, aby se na samostatně řádce nalézal zápis ve struktuře: nameserver adresa Za předpokladu, že by se daný DNS server nalézal na IPv6 adrese 2a01:490:1d:130::1, je možné provést danou úpravu konfiguračního souboru resolv.conf následujícím způsobem: echo "nameserver 2a01:490:1d:130::1" > /etc/resolv.conf 81

82 V tomto případě se spíše jedná o demonstrativní možnost úpravy daného konfiguračního souboru. Je to dáno tím, že takto zadaný příkaz vymaže celý obsah souboru a následně do něho přidá daný konfigura ční řádek. Z toho důvodu je lepší pro úpravu daného konfiguračního souboru použít některý z řady textových editorů. Obrázek 4.5: Zadání příslušných příkazů konfigurace IPv6 Zdroj: Vlastní úprava Výše popsanou konfiguraci lze bez dalších konfiguračních kroků označit spíše za dočasnou konfiguraci, která se vynuluje restartem daného zařízení. Aby tato konfigurace byla trvalá, je třeba dané příkazy zapsat do některého z konfiguračních souborů, jejichž obsah je vykonán po spuštění daného OS (příkladem může být soubor rc.local). Lepší a častější variantou konfigurace je však využití některý z předpřipravených konfiguračních souborů, které slouží ke konfiguraci síťových rozhraní, a které mají svůj specifický syntax zápisu konfigurace. Tyto konfigurační soubory a způsob v nich použité syntaxe je však specifický v závislosti na použité distribuci OS Linux. Obecně však většinou platí, že jsou tyto konfigurační soubory zpracovány po spuštění OS pomocí speciálních skriptů, které využívají některých z výše zmíněných nástrojů konfigurace. 82

83 Obrázek 4.6: Výpis nastavení po skončení konfigurace IPv6 Zdroj: Vlastní úprava 83