}w!"#$%&'()+,-./012345<ya

Transkript

1 }w!"#$%&'()+,-./012345<ya Masarykova univerzita Fakulta informatiky Přechod IPv4 <-> IPv6 Bakalářská práce Marek Tlačbaba Brno, 2012

2 Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorských dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při práci používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: doc. RNDr. Eva Hladká, Ph.D. ii

3 Poděkování Na tomto místě bych rád poděkoval především paní docentce Hladké za vstřícnost, cenné rady a připomínky při přípravě této práce. Dále děkuji svým rodičům, kteří mě podporují po celou dobu studia. iii

4 Shrnutí Cílem práce je ukázat základní vlastnosti protokolu IPv6 a možnosti přechodu od nekompatabilního IPv4 protokolu. Nakonec jsou vybrány 3 možnosti tunelování IPv6 paketů skrz IPv4 síť a ty jsou porovnány v těchto vlastnostech: zpoždění, rozptyl zpoždění, ztrátovost paketů a šířka pásma. iv

5 Klíčová slova IPv4, IPv6, přechodové mechanismy, tunelování, SixXS, Freenet6, Teredo. v

6 Obsah 1 Úvod Základní vlastnosti nového protokolu Adresy v IPv Podoba a zápis IPv6 adresy Druhy adres Typy adres IPv Struktura adresy Přidělování adres Domain Name System (DNS) Dopředné dotazy Reverzní dotazy Formát datagramu Tvar datagramu v IPv6 a rozdíly oproti IPv Rozšiřující hlavičky Objevování sousedů Automatická konfigurace Bezstavová konfigurace Stavová konfigurace IPsec Podpora skupinového vysílání MLD verze MLD verze Podpora mobility Metody přechodu Obecné metody přechodu Dvojí zásobník Tunelování Překladače Konkrétní metody přechodu Tunnel broker to over

7 3.2.4 ISATAP Teredo Stateless IP/ICMP Translation (SIIT) NAT-PT NAT Testy vybraných přechodových mechanismů Zřízení a instalace tunelovacích mechanismů Testované charakteristiky Testy Zpoždění paketů v síti Rozptyl zpoždění Ztrátovost paketů Rychlost přenosu Celkové shrnutí testů Závěr A Bezpečné objevování sousedů (SEND) B IPsec B.1 Základní principy použití IPSECu B.2 Authentication Header B.3 Encapsulating Security Payload B.4 Správa bezpečnostních asociací C Měření v denní špičce C.1 Zpoždění paketů v síti C.2 Rozptyl zpoždění C.3 Ztrátovost paketů C.4 Šířka pásma D Seznam důležitých RFC dokumentů

8 Kapitola 1 Úvod Komunikace v současném Internetu je jiná než na začátku a způsoby jeho užití jsou také rozdílné. Větší počet uživatelů k němu připojených zvýšil i objem přenášených dat. S tím se začaly objevovat vyšší požadavky především na rychlost, bezpečnost a kvalitu přenosu. První specifikace základního internetového protokolu IPv4 je popsána již v roce Vznikající potřeby a problémy tak byly následně řešeny pomocí dodatečné implementace potřebných funkcí. V roce 1992 začínalo být jasné, že adresový prostor protokolu IPv4 bude pomalu vyčerpán. Proto již tehdy organizace IETF 1 rozhodla o nutnosti změny internetového protokolu, který kromě rozšíření adresového prostoru sebou přinese i další nové funkce. Například individuální, skupinové a výběrové adresy, automatickou konfiguraci, zvýšení bezpečnosti, podporu mobility a plynulý přechod z IPv4 na IPv6. Poté vznikly pracovní skupiny, které započaly práci na novém protokolu označovaném jako IP next generation, pak přejmenovaném na IPv6. První výsledky se objevily koncem roku 1995, kdy byla vydána sada RFC dokumentů definujících IPv6. Jedná se hlavně o RFC 1883 a jeho příbuzné. V této době se mohlo již začít s implementací nového protokolu, ale začátek byl pomalý. Problém s nedostatkem adres se podařilo oddálit pomocí překladačů adres. Přechod na nový protokol narážel na další velký problém, neexistenci aplikací podporující nový protokol a vysoké náklady na jejich vznik. Psychologický milník nastal 3. února 2011, kdy byly alokovány poslední bloky IPv4 adres v registru IANN 2. Cílem první části práce je popis klíčových vlastností síťového protokolu IPv6 a porovnání s IPv4. Na to navazuje druhá část, která je věnována metodám používaných pro zajištění spolupráce obou protokolů. Celá práce je zakončena testováním vybraných metod přechodu. 1. Internet Engineering Task Force. Je to otevřená mezinárodní komunita sdružující zájemce o vývoj architektury Internetu. 2. Internet Assigned Numbers Authority organizace dohlížející na přidělování IP adres, správu kořenových zón DNS a další náležitosti internetových protokolů. 3

9 Kapitola 2 Základní vlastnosti nového protokolu 2.1 Adresy v IPv6 Rozšíření počtu dostupných adres bylo první motivací k vytvoření nového protokolu. Oproti starému protokolu, kde bylo možné využívat adresy o délce 32 bitů a adresovat asi 4 miliardy zařízení, využívá IPv6 adresy o délce 128 bitů a tudíž dovoluje připojit do sítě asi 3, zařízení. Takové množství adres je považováno dnes za nevyčerpatelné Podoba a zápis IPv6 adresy Adresa se standardně zapisuje jako osm skupin po čtyřech číslicích šestnáctkové soustavy, které jsou odděleny dvojtečkami. Protože se celkem často vyskytuje hodnota nula, existují dvě možnosti pro zkrácení zápisu. Je možné vynechat počáteční nuly v každé čtveřici. Tedy v zápise adresy se může objevit místo 0001 pouze 1. Další možností je vynechat nulové šestnáctibitové skupiny následující za sebou zástupným znakem ::. Tento znak se smí vyskytnout v adrese pouze jednou, aby bylo možné jednoznačně určit původní tvar adresy. Některé přechodové mechanismy potřebují pracovat s adresami ze světa IPv4. Proto vznikly takzvané IPv4 kompatibilní adresy, které byly později nahrazeny IPv4-mapovanými adresami, které se používají nyní. Ty mají počátečních 80 bitů nulových, pak následuje 16 bitů jedničkových a na posledních 32 bitech je zapsána IPv4 adresa. Tu je možné zapisovat jako běžnou IPv4 adresu. Například: ::ffff: Normální tvar Zkrácený tvar 0126:0000:0000:0000:0000:0025::fa56: ::25:fa56:26 Tabulka 2.1: Příklad zkrácení adresy 4

10 2. Základní vlastnosti nového protokolu Druhy adres Adresní schéma IPv6 bylo definováno ve specifikaci RFC Následně ještě byla dvakrát upravena v RFC 2373 a v RFC Byly zde popsány tři druhy adres individuální, skupinové a výběrové adresy. Individuální (unicast) adresy určují jednoznačně právě jedno zařízení. Funkce tedy zůstává nezměněná. Skupinové (multicast) adresy určují skupinu zařízení, kterým má být určitá informace doručena. Tu pak obdrží všichni členové skupiny. Také jsou využívány k nahrazení všesměrového vysílání (broadcast), kdy jsou využity speciální skupiny. Například všechny uzly nebo všechny směrovače na dané lince. Výběrové (anycast) adresy jsou oproti IPv4 nové. Podobně jako skupinové adresy určují skupinu příjemců, ale data jsou doručena pouze jedinému nejbližšímu členu Typy adres IPv6 Adresní prostor IPv6 byl rozdělen na několik typů adres, kdy každý typ určuje adresy se společnou charakteristikou. Prefix Význam ::/128 nedefinovaná adresa ::1/128 lokální smyčka ff00::/8 skupinové adresy fe80::/10 individuální lokální linkové adresy fc00::/7 unikátní individuální lokální ostatní individuální globální Tabulka 2.2: Základní typy IPv6 adres (převzato z [1]) Nejrozšířenější adresy jsou individuální a ty se dělí na několik typů. Individuální globální jsou celosvětově jedinečné adresy, takže jsou směrovatelné celým IPv6 Internetem. Jsou protipólem současných IPv4 adres. Individuální lokální linkové jsou adresy, které mají počátečních 64 bitů pevně daných, za nimi je pak připojen 64bitový identifikátor rozhraní. Mají omezen dosah pouze na jedinou linku. Takové adresy 5

11 2. Základní vlastnosti nového protokolu si umí zařízení generovat samo. Tyto adresy se používají v bezstavové autokonfiguraci, objevování sousedů nebo v situacích, kdy není přítomen směrovač. Unikátní individuální lokální jsou adresy, které slouží pro lokální komunikaci, většinou uvnitř jedné sítě, a jsou celosvětově jednoznačné. Toho se využívá, pokud je síť ve více lokalitách, které jsou spojeny přes některou páteřní síť. Tyto adresy jsou nástupcem individuálních lokálních místních adres, které byly zamítnuty v RFC Struktura adresy IPv6 adresa se obvykle dělí na dvě stejně velké části. Horních 64 bitů reprezentuje adresu sítě, dolních 64 bitů identifikátor rozhraní. Ten nejčastěji vzniká použitím modifikovaného EUI Ve standardním EUI-64 je předposlední bit v prvním bajtu příznakem celosvětové jedinečnosti. Hodnota 1 značí lokální adresu, hodnota 0 globální adresu. Modifikované EUI-64 invertuje hodnotu tohoto bitu. To pak usnadňuje vytváření identifikátoru rozhraní. Nejčastěji vzniká identifikátor rozhraní z celosvětově jednoznačné MAC adresy o délce 48 bitů přidělené výrobcem. Tato transformace je vcelku snadná, protože se vloží mezi třetí a čtvrtý bajt MAC adresy 16 bitů s hodnotou fffe a obrátí se příznak globality. V Tabulce 2.3 je ukázán příklad. MAC adresa Identifikátor rozhraní 00:8C:A0:C2:71:35 28c:a0ff:fec2:7135 Tabulka 2.3: Vznik identifikátoru rozhraní pomocí EUI-64 Kvůli jednoduchosti tohoto principu není problém odvodit adresu a tím může vznikat bezpečnostní problém. Lze tak snadno vyhledat, které zařízení k příslušné službě přistupovalo. Navíc je možné i zjistit, z které konkrétní sítě to bylo. Jako ochrana proti těmto problémům vznikl mechanismus Privacy Extensions, který je definován v RFC Princip spočívá v nahodilém generování hostitelské části IPv6 adresy. Ty se pravidelně obměňují a vznikají nové. Takové adresy se tedy nedají předem určit. 1. Standard zaměřený na přidělování celosvětově jednoznačných identifikátorů pro rozhraní v počítačových sítích. 6

12 2.1.5 Přidělování adres 2. Základní vlastnosti nového protokolu Přidělování adres je velmi podobné jako u IPv4. Centrální autoritou je IANA, která přiděluje velké bloky adres regionálním registrům AFRINIC (Afrika), APNIC (Asie a Pacifik), ARIN (Severní Amerika), LACNIC (Latinská Amerika) a RIPE NCC (Evropa a Blízký východ). Ty následně přidělují menší bloky lokálním registrům, což většinou bývají poskytovatelé Internetu. Až od nich získávají adresy zákazníci.[1] Díky hierarchickému uspořádání je dodržována agregovatelnost. Což znamená, že poskytovatel obdrží určitý prefix, ten pak v podobě delších prefixů rozděluje zákazníkům. Cílem je, aby poskytovatelova síť i se všemi jeho zákazníky byla dostupná jedním záznamem ve směrovacích tabulkách. Konečným důsledkem je zmenšení velikosti směrovacích tabulek. Návrh struktury globálních individuálních adres je popsán v RFC 4291, které ji definuje, jak je uvedeno na v Tabulce 2.4. n bits m bits 128-n-m bits global routing prefix subnet ID interface ID Tabulka 2.4: Struktura globálních adres (převzato z [2]) Global routing prefix je hierarchicky strukturovaná hodnota přiřazena určitému místu, subnet ID je identifikátorem jedné linky v tomto místě a interface ID identifikátor rozhraní [2]. 2.2 Domain Name System (DNS) DNS slouží pro převod doménového jména na IP adresu a naopak. V případě nového protokolu je tento systém ještě významnější, protože IPv6 adresy jsou dlouhé, obtížně se pamatují a zapisují. Posledním dokumentem, který řeší ukládání informací do DNS je RFC Toto řešení vychází z IPv Dopředné dotazy Pro zjišťování adresy k danému jménu se používá nový typ záznamů zvaný AAAA. Jejich název byl odvozen od A záznamů z IPv4. Jejich použití v zónovém souboru je obvyklé takto: jméno AAAA adresa pc AAAA 2001:db8:1c01:1:204:76ff:fe47:8e81. 7

13 2. Základní vlastnosti nového protokolu Reverzní dotazy Zjišťuje jméno ke známé IPv6 adrese. V adrese je nejobecnější část na začátku, ale v doménovém jméně je až na konci. Aby se dala databáze reverzního DNS distribuovat obvyklým způsobem, je třeba adresu v dotazu obrátit. Pro IPv6 adresu se reverzní dotaz vytvoří tak, že se obrátí pořadí šestnáctkových číslic v celé kompletní adrese bez vynechání nul. Každá z nich je pak brána jako poddoména a na konec se připojí ip6.arpa. Pro výše uvedený příklad to vypadá takto: 1.8.e e.f.f.f c.1.8.b.d ip6.arpa Do zónového souboru se pak zapisují pomocí obvyklých PTR záznamů. Pro výše uvedenou adresu by instituce dostala přidělen prefix 2001:db8:1c01::/48 a jemu odpovídající reverzní doménu 1.0.c.1.8.b.d ip6.arpa. V jejím zónovém souboru pak bude uvedeno: 1.8.e e.f.f.f PTR pc.kdesi.cz. [4] 2.3 Formát datagramu Hlavním dokumentem, který ho definuje, je RFC Tvar datagramu v IPv6 a rozdíly oproti IPv4 Datagram začíná hlavičkami a po nich následují nesená data. Na rozdíl od IPv4 zde došlo k zásadní změně ve velikosti základní hlavičky, kde se omezily její prvky jen na ty nejnutnější. I přesto, že se adresy prodloužili čtyřikrát, celková délka základní hlavičky datagramu vzrostla ve srovnání s IPv4 jen dvojnásobně z 20 B na 40 B. Z toho u IPv6 zabírají největší část adresy, a to 32 B [1]. Následující výčet ukazuje nové, stejné nebo změněné položky používající se v hlavičce protokolu IPv6. Verze (Version) tato 4 bitová položka identifikuje verzi protokolu. V případě IPv6 má hodnotu 6 [2]. Toto pole jako jediné zůstalo nezměněné. To proto, aby na jedné lokální lince mohli být provozovány oba protokoly zároveň. Třída provozu (Traffic Class) tato 8 bitová položka vyjadřuje prioritu provozu. To by mělo sloužit k lepšímu poskytování služeb se 8

14 2. Základní vlastnosti nového protokolu Obrázek 2.1: Porovnání IPv4 a IPv6 hlavičky datagramu (převzato z [5]) zaručenou kvalitou. Zatím však v praxi neumí zajistit takové parametry, jako jsou například přenosová rychlost, zpoždění či rozptyl. Z definice se zatím požaduje, aby implicitní hodnota všech bitů byla nastavena na 0 [2]. Podobnou úlohu ve starém protokolu zastává pole Typ služby (Type of Service). Značka toku (Flow Label) je jedno z nových polí v IPv6, zatím není přesně definováno a má velikost 20 bitů. Odesílatel by měl označovat jako tok pakety se společnými vlastnostmi. S těmi by pak mělo být během směrování zacházeno stejně. Ty pakety, které nepatří k žádnému toku, by měly mít nastavenou tuto položku na 0. [2], [1] Délka dat (Payload Length) šestnáctibitové číslo značící délku dat přenášených za základní hlavičkou, které se mezi tyto data nepočítá. Rozšiřující hlavičky už mezi ně ale počítány jsou [2]. Ve starém protokolu se používalo pole Délka datagramu (Datagram Length), které na rozdíl od nové verze nese délku dat včetně záhlaví. Další hlavička (Next Header) osmibitová položka označující to, co následuje za záhlavím. Může označovat buď typ rozšiřující hlavičky, 9

15 2. Základní vlastnosti nového protokolu Typ záhlaví Hodnota Volby pro všechny (Hop-by-hop Options) 0 Směrování (Routing) 43 Fragmentace (Fragment) 44 Autentizace (Autentication) 51 Volby pro cíl (Destination Options 60 Šifrování obsahu (Encapsulating Security Payload) 50 Poslední hlavička (No Next Header) 59 Typ nesených dat příklady TCP 6 UDP 17 ICMP 58 Tabulka 2.5: Vybrané hodnoty pole další hlavička (převzato z [3]) nebo druh dat [2]. Tato položka nahrazuje ze starého protokolu položku Protokol (Protocol), který udává druh dat a také částečně položku Volby (Options). Maximální počet skoků (Hop Limit) osmibitová položka, jejíž hodnota je snižována pokaždé o 1, když směrovač pošle paket dál sítí. Po dosažení 0 je paket zahozen. Slouží jako ochrana proti zacyklení při směrování [2]. Stejnou úlohu plní ve starém protokolu pole Životnost (Time to Live). Zdrojová adresa (Source Address) 128-bitová adresa odesílatele. Zde se změnila pouze velikost oproti starému protokolu. To samé platí samozřejmě i pro cílovou adresu. Cílová adresa (Destination Address) 128-bitová adresa odesílatele Rozšiřující hlavičky Právě zde dochází k největší změně ve formátu hlaviček. Položka Další hlavička obecně odkazuje na typ následující hlavičky. Již to není omezeno pouze na protokol vyšší vrstvy, ale může obsahovat další rozšiřující volby. Každá hlavička je samostatným blokem a ty jsou vzájemně propojeny pomocí pole Další hlavička. Vlastnímu obsahu tedy může předcházet řada volitelných hlaviček, které jsou zřetězeny do lineárního seznamu a měly by dodržovat určené pořadí. Jednotlivé hlavičky jsou identifikovány podle hodnoty v poli Další hlavička. 10

16 2. Základní vlastnosti nového protokolu Hlavní výhodou této koncepce je pružnost a úspornost. Přenášejí se pouze potřebné informace. Na druhou stranu zde existuje možná nevýhoda, že zpracování může představovat průchod dlouhým řetězcem. [1] Tento problém se řeší pomocí předepsaného pořadí rozšiřujících hlaviček v RFC Zde je jejich pořadí a krátká charakteristika. 1. Základní hlavička IPv6 (IPv6 header). 2. Volby pro všechny (Hop-by-hop Options) jsou volby určené pro všechny směrovače po cestě. 3. Volby pro cíl (Destination Options) volby určené pro cílovou adresu a pro případné další uvedené v hlavičce Směrování. 4. Směrování (Routing) nabízí možnost přidat do směrování jednu či několik IPv6 adres, jimiž musí datagram projít před doručením. 5. Fragmentace (Fragment) umožňuje pouze odesílajícímu zařízení odesílat větší data, než dovoluje maximální přenosová velikost pakety (MTU). Obsahuje identifikaci původního paketu neděleného paketu, pořadí fragmentu a označení, zda je koncový paket. 6. Autentizace (Authentication) obsahuje kontrolní informace, zda nebyla porušena integrita. 7. Šifrování obsahu (Encapsulating Security Palyload) obsahuje parametry týkající se šifrování a dešifrování dat. 8. Volby pro cíl (Destination Options) volby pouze pro konečného příjemce. Každá z hlaviček by měla být v paketu pouze jednou s výjimkou hlavičky Volby pro cíl, která se může vyskytnout dvakrát. Mezilehlé směrovače čtou pouze Volby pro všechny. Výjimku tvoří ty pakety, které mají rozšiřující hlavičku Směrování. Tam pak průběžný cílový uzel zajímají ještě hlavičky Volby pro cíl a Směrování. Ostatní hlavičky jsou určeny pouze pro koncový cílový uzel. 2.4 Objevování sousedů V IPv4 se ke zjištění linkové adresy partnera využívá protokol Address Resolution Protocol (ARP). Ten pomocí všesměrového vysílání rozešle dotaz 11

17 2. Základní vlastnosti nového protokolu obsahující hledanou IP adresu a údaje o sobě, IP a MAC adresu. Hledaný uzel mu odpoví zprávou, kde je jeho IP a MAC adresa. U IPv6 vytvořili obecnější nástroj řešící tento problém. Ten je definován v RFC 4861 a řeší i tyto oblasti: zjišťování linkových adres uzlů v lokální síti, aktualizaci neplatných položek a změn v linkových adresách, hledání směrovačů, přesměrování, zjišťování prefixů, parametrů sítě a dalších údajů pro automatickou konfiguraci adresy, ověřování dosažitelnosti sousedů, detekci duplicitních adres. K činnosti využívá 5 základních ICMP zpráv: výzva směrovači, ohlášení směrovače, výzva sousedovi, ohlášení souseda a přesměrování. Hledání linkových adres se podobá klasickému ARP. Změnila se adresa používaná k zasílání dotazů. Tvoří ji prefix ff02:0:0:0:0:1:ff00::/104. Zbývajících 24 bitů je tvořeno posledními 24 bity z hledané IP adresy. Takovéto adrese se říká adresa pro vyzývaný uzel. Aby to mohlo fungovat, musí se každé zařízení při inicializaci IP přihlásit do všech odpovídajících skupin. Většinou v každé takové skupině bude zařízení samo, takže při zjišťování adresy nebudou obtěžovány ostatní uzly. Zjištění linkové adresy tedy probíhá následovně. Z cílové adresy vytvoří skupinovou adresu. Na ni pošle Výzvu sousedovi. Ten na ni reaguje Ohlášením souseda. Pak se již jen aktualizuje cache paměť sousedů, ve které jsou uloženy jejich linkové adresy. Pomocí těchto zpráv se testuje i dosažitelnost souseda. Pokud dorazí ohlášení, je vše v pořádku. Pokud ne, výzva se několikrát opakuje. Když ani poté nedorazí ohlášení souseda, tak bude adresa vymazána z cache paměti sousedů. Inverzní objevování sousedů řeší situaci, kdy zařízení zná linkovou adresu a potřebuje zjistit jeho IP adresu. Stroj tedy odešle prostřednictvím ICMP Výzvu. Posílá ji na skupinovou adresu pro všechny, ale na linkové vrstvě ji adresuje pouze adresou cílového stroje. Vyzvaný pak reaguje Ohlášením, které obsahuje linkovou adresu a také seznam IPv6 adres pro odpovídající rozhraní. Jako reakce na bezpečnostní problémy vznikl mechanismus SEND, který je popsán v příloze A. 12

18 2.5 Automatická konfigurace 2. Základní vlastnosti nového protokolu Ve světě je stále větší pozornost věnována tomu, aby se většina zařízení uměla nakonfigurovat sama. Nejinak je tomu i u počítače zapojovaného do sítě. K tomu byly navrženy dvě možnosti: bezstavová a stavová konfigurace Bezstavová konfigurace Zde se využívá dostatečně veliký adresový prostor IPv6 k tomu, aby nemusely být adresy přidělovány, ale každé koncové zařízení si může svoji adresu nakonfigurovat samostatně. Tento mechanismus je prvně popsán v RFC 2462, později v RFC Uzel nejdříve vytvoří svou lokální linkovou adresu. Ta se tvoří tak, že k prefixu lokálních linkových adres fe80::/10 se připojí identifikátor rozhraní. Pak pomocí detekce duplicitních adres ověří, že adresa je jedinečná. Uzel rozešle výzvu sousedovi s právě vygenerovanou IPv6 adresou, pokud nepřijde žádná odpověď, tak je adresa jedinečná. K dalšímu pokračování je již potřeba mít znalosti o svém okolí. Ty získá z ohlášení směrovače, které je generováno automaticky nebo si ho může uzel sám vyžádat. Z něho se hlavně dozví prefix podsítě a informaci o tom, jak dlouho může daný směrovač využívat jako implicitní. Z těchto informací si již je zařízení schopno samostatně vytvořit platnou IPv6 adresu. Ale ještě z nich nemůže poznat adresu DNS serveru. To se řeší dvěma způsoby, ale jenom jeden je dosud implementovaný. Funkční variantou je kombinace bezstavové automatické konfigurace s bezstavovým DHCPv6, které doplňuje zbývající chybějící adresy místních DNS serverů a případně přípony doménových jmen k prohledávání. Druhou možností je využití nových voleb v ohlášení směrovače. Ty jsou definovány v RFC RDNSS (Recursive DNS Server) ohlašuje se v ní IPv6 adresy místních rekurzivních serverů. Může obsahovat i více adres, u kterých je ještě oznamovaná jejich životnost. Ohlášení může obsahovat několik voleb RDNSS. DNSSL (DNS Search List) obsahuje seznam přípon, které má klient zkusit připojit na konec doménového jména, pokud se nedaří najít odpověď. Tato informace není nezbytná, ale je také součástí DHCP a proto je přidána i zde. Z těchto informací si budou klienti udržovat dva seznamy adresy místních rekurzivních serverů a prohledávané přípony doménových jmen. Podle 13

19 2. Základní vlastnosti nového protokolu příchozích ohlášení směrovačů se budou oba seznamy aktualizovat. Může nastat situace, kdy se klient dozví různé informace z ohlášení směrovače a jiné z DHCPv6. Pak se doporučuje, aby si klient ponechal nějaké údaje z každého zdroje. Pak by pořadí informací mělo dodržovat následující priority: DHCPv6, ohlášení směrovače chráněné pomocí SEND a nechráněné ohlašení směrovače Stavová konfigurace Ta je známa už z IPv4. Zde se používá nový protokol DHCPv6, který je definován v RFC Počítač rozešle na obecnou adresu paket s dotazem na komunikační parametry. Server mu v odpovědi sdělí potřebné informace IP adresu, prefix podsítě, implicitní záznam do směrovací tabulky, adresu DNS serveru a další informace podle potřeby. Podílejí se na ní 3 kategorie zařízení. Klient chce získat informace. Server poskytuje informace. Zprostředkovatel zprostředkovává styk mezi nimi, pokud neleží na stejné lince. Někdy bývají pod pojmem Agent zařazeny Server a Zprostředkovatel. V DHCP je velmi důležitá otázka identifikace zařízení. Ve staré verzi se používá ethernetová adresa. V DHCPv6 se zavádí pojem DHCP Unique Identifier (DUID). Je to jednoznačný identifikátor každého zařízení fungující v DHCP procesu klient i server. Druhým pojmem sloužícím k identifikaci je Identity Association (IA). Ten počítač přiřazuje každému svému rozhraní. Nejdříve si klient vytvoří IA pro svá rozhraní a opatří je jednoznačnými identifikátory. Pak na adresu všech DHCP agentů (ff02::1:2) pošle zprávu výzva (Solicit), ve které je obsažen DUID, všechny IA a jeho vytvořená lokální linková adresa. Pokud klient a server sídlí na stejné lince, pak server odpoví přímo na jeho linkovou adresu zprávou ohlášení serveru (Advertise), kde jsou uvedeny preference a parametry, které by přidělil jednotlivým IA. Klient si ze všech přijatých oznámení vytvoří seznam DHCP serverů. Pak si podle hodnoty preference vybere ten nejvýhodnější a tomu pošle zprávu žádost (Request), kde je uveden DUID serveru. To je proto, že je zpráva odesílána stále na obecnou adresu serverů. Příslušný server pak zašle zprávu odpověď (Reply) obsahující IPv6 adresy a další parametry. Klient si pak pomocí mechanismu 14

20 2. Základní vlastnosti nového protokolu pro detekci duplicitních adres zkontroluje jedinečnost adres. Pokud nejsou jedinečné, pak je odmítne pomocí zprávy odmítnutí (Decline). Pokud se klient a server nenachází na stejné lince, zprávy jsou stejné jen s tím rozdílem, že agent zprávy přicházející od klienta balí do zpráv předání (Relay), které pak odesílá serverům ve svém seznamu. Server pak zabalí své odpovědi do zpráv zprostředkování (Relay) a posílá je na adresu agenta. Ten je pak vybalí a normálně zašle klientovi. Takto přidělené adresy mají ovšem omezenou životnost. Po uplynutí musí klient žádat o její prodloužení server, který ji přidělil. Když server neodpovídá, požádá jiný dostupný server. Naopak pokud se klient odpojuje ze sítě, měl by o tom informovat zprávou uvolnění (Release). DHCP také řeší situaci návratu klienta do sítě, například po restartu počítače. Potom si musí klient ověřit, zda jeho stávající údaje jsou správné. To učiní pomocí zprávy potvrzení (Confirm), kterou pošle na skupinovou adresu všech DHCP serverů. V ní sděluje aktuální parametry svých IA. Příslušný server reaguje kladnou nebo zápornou odpovědí. [1] Komunikaci většinou zahajuje klient, ale i server má možnost si vynutit na klientech, aby se přizpůsobili nové situaci při změně síťových parametrů. K tomu slouží zpráva rekonfigurace (Reconfigure). 2.6 IPsec Bezpečnost na síťové vrstvě řeší sada mechanismů souhrnně se nazývající IPsec. Existuje jak pro IPv4, tak samozřejmě i pro IPv6, kde již musí být povinně implementován. Nabízí autentizaci a šifrování pomocí dvou rozšiřujících záhlaví. Prvním z nich je hlavička Authentication Header (AH), která má za úkol zajistit integritu dat, autentizaci a ochranu proti opakování pro celý IPv6 paket. Druhým je hlavička Encapsulating Security Payload (ESP), která zajišťuje integritu dat, autentizaci, utajení a ochranu proti opakování pro data, která jsou zabalena v ESP. Jak je vidět, tak ESP nabízí stejné služby jako AH, proto se postupně projevuje odklon od hlavičky AH. Před začátkem komunikace je třeba vyjednat bezpečnostní asociaci, kde se zařízení domluví na všem potřebném. Ke správě bezpečnostních asociací je využíván Internet Key Exchange version 2 (IKE2). Více v příloze B. 2.7 Podpora skupinového vysílání Skupinové vysílání je šíření dat od jednoho zdroje k více cílům. Obecně musí řešit dva základní problémy. Jak nejlépe doručit stejná data více příjemcům tak, aby byly efektivně využívány linky. Zároveň se ale snaží zajistit, aby 15

21 2. Základní vlastnosti nového protokolu Adresa IPv6 ff02::1 ff02::2 Popis všechny uzly ve stejném segmentu sítě všechny směrovače ve stejném segmentu sítě Tabulka 2.6: Vybrané skupinové adresy (převzato z [1]) ostatní uzly nebyly obtěžovány nevyžádanými daty. Základní informací pro směrovače je, které skupiny má vysílat do daného prostředí. Ke zjišťování příjemců v IPv6 slouží Multicast Listener Discovery (MLD), jehož definice je v RFC Ten je nástupcem Internet Group Managment Protocol, který se využíval pro stejné účely v IPv4. MLD je podprotokolem ICMPv6, jsou tedy využívány zprávy typu ICMP. Typy zpráv se liší podle verze protokolu. Pro skupinové vysílání jsou vyhrazeny adresy s prvními osmi bity jedničkovými. V IPv6 již není broadcast, ale používají se různé skupiny. Nejdůležitější z nich jsou uvedeny v následující tabulce MLD verze 1 Tato verze se nestará o odesílatele. Vychází z toho, zda pro danou skupinu existuje nějaký příjemce. Proto si musí směrovač udržovat seznam aktivních skupinových adres, ze kterého pak vytváří distribuční stromy pro jednotlivé skupiny. Používá tři typy zpráv. Zpráva obsahuje Typ, Kód, Kontrolní součet, Maximální zpoždění, Skupinovou adresu. Ohlášení členství ve skupině (Typ 131) posílá ji počítač na adresu skupiny, do které chce vstoupit. Směrovače si pak přidají u příslušného rozhraní tuto skupinovou adresu do seznamu vysílaných. Vystoupení ze skupiny (Typ 132) posílá ji počítač na adresu ff02::2, když chce ukončit členství ve skupině. Výzva (Typ 130) posílá ji směrovač na adresu skupiny, aby zjistil, zda ještě existuje nějaký posluchač dané skupiny. Ze skupiny odpoví vždy maximálně jeden stroj. Tato zpráva se také ještě využívá k obecným dotazům, kdy je ve skupinové adrese uvedena nula a zpráva je odeslána na ff02::1. Tím směrovač zjišťuje, které všechny skupiny zde mají své posluchače. Tento dotaz posílá vždy směrovač s nejnižší IP adresou, ale odpověď dostávají všechny směrovače na lince. 16

22 2. Základní vlastnosti nového protokolu MLD verze 2 Tato možnost navíc umí filtrovat vysílací zdroje. Dovoluje vybírat konkrétní zdroj nebo naopak některé blokovat. K definování zdrojů, které chceme přijímat, slouží příkaz INCLUDE. Naopak seznam zdrojů, od kterých přijímat data nechceme, definujeme pomocí příkazu EXCLUDE. Tyto pravidla mezi sebou můžeme kombinovat pomocí logických operací (sjednocení, průnik a doplněk). Na straně příjemce je jedna událost typu 143 Hlášení, které je zasíláno všem MLDv2 směrovačům na lince na adresu (ff02::16). Každá takováto zpráva se skládá z více Záznamů, které nesou informace o skupinové adrese, zdrojích skupinového vysílání a typu záznamu. Dotaz od směrovače umožňuje navíc připojit seznam zdrojů a zjišťuje tak nejen seznam posluchače daných skupin, ale také posluchače daných zdrojů. Tato zpráva je posílána všem na adresu ff02::1, nebo na příslušnou skupinovou adresu. Na rozdíl od MLDv1 zde musí odpovědět každý příjemce, protože v odpovědi je seznam všech skupin a zdrojů, které poslouchá. Tato odpověď je posílána všem směrovačům na lince. 2.8 Podpora mobility Podpora mobilních zařízení v IPv6 je definována nejprve v RFC 3775, později pak v RFC Je to jedna z významných předností nového protokolu. Základní myšlenka vychází z faktu, že každý uzel má svojí domácí síť a tedy i svoji domácí adresu. Tuto adresu má zaregistrovanou v DNS a na ni ho může zájemce kontaktovat. Pokud se ale uzel nachází zrovna na cestách, tedy mění svojí IP adresu, zastupuje jej v jeho domácí síti tzv. domácí agent. Tím většinou bývá jeden ze směrovačů v jeho domácí síti. Toho mobilní uzel kontaktuje a zaregistruje se u něj. To znamená, že mu pošle svou aktuální dočasnou adresu a požádá o zastupování. Tím je vytvořena vazba mezi jeho domácí a dočasnou adresou. Od toho okamžiku se domácí agent vydává za mobilní uzel a přebírá datagramy určené pro mobilní uzel a následně mu je posílá na jeho aktuální dočasnou adresu. Všechny tyto datagramy šifruje pomocí IPsecu, kde využívá hlavičku ESP. Tedy zájemce (označováný jako korespondent) posílá data domácímu agentu, od něj pak putují mobilnímu uzlu. Jeho odpovědi jsou přeposílána přes domácího agenta zpět ke korespondentovi. Celý tento způsob komunikace je značně neefektivní a proto zde existuje snaha spojení optimalizovat. Komunikace je zahájena mobilním uzlem v okamžiku příchodu prvního datagramu. Jejím cílem je oznámit korespondentovi aktuální dočasnou ad- 17

23 2. Základní vlastnosti nového protokolu resu. K tomu slouží aktualizace vazby, ale nejdříve musí prokázat svému partnerovi, že je skutečně ten, za kterého se vydává. Jakmile je aktualizace vazby úspěšně dokončena, přidává korespondent do datagramů rozšiřující hlavičku Směrování. Finální adresou zůstává domácí adresa mobilního uzlu, ale datagramy jsou posílány přes dočasnou aktuální adresu. Tím probíhá komunikace mezi stroji přímo. Průběh aktualizace vazby je na Obrázku 2.4. Obrázek 2.2: Aktualizace vazby u korespondenta (převzato z [7]) Jak je výše zmíněno, korespondent přidává rozšiřující hlavičku Směrování. Mobilní uzel zase přidává volbu Domácí adresa do hlavičky Volby pro příjemce, ve které posílá svou domácí adresu. Mobilní uzel může svou adresu měnit, pak musí změnu nahlásit svému domácímu agentovi. Také ale musí tuto změnu ohlásit všem partnerům, se kterými v poslední době komunikoval. Ty najde v seznamu aktualizací a těm pošle aktualizaci s novou adresou. Speciálním případem změny adresy je návrat do domovské sítě. Mobilní uzel posílá zprávu Aktualizace vazby, která má ale nulovou životnost. To znamená výmaz ze seznamu vazeb. Tuto informaci posílá také domácímu agentovi, aby zrušil registraci. Nakonec ještě musí rozeslat několik ohlášení souseda. 18

24 Kapitola 3 Metody přechodu Nový protokol IPv6 přináší spoustu změn a nových vlastností, které jej činí nekompatibilním se starší verzí IPv4. Jako reakce na tyto problémy vznikly zároveň také různé mechanismy přechodu, které umožňují dočasnou funkčnost obou protokolů vedle sebe. Zpočátku tyto mechanismy mají sloužit k připojení menších sítí, či jednotlivců používajících IPv6 do celosvětové sítě. Se zvyšujícím se podílem IPv6 by měly sloužit k připojení IPv4 ostrůvků. Nakonec by měl nový protokol úplně nahradit ten starý a tyto mechanismy se přirozeně přestanou používat. Obecně se dělí na tři skupiny: dvojí zásobník (Dual Stack), tunelování (Tunneling) a překladače (Translators). 3.1 Obecné metody přechodu Dvojí zásobník Dvojí zásobník je integrační metoda, ve které musí dané zařízení podporovat oba dva protokoly a mít tedy jak IPv4, tak i IPv6 adresu. K jejich získání se používají obvyklé způsoby, tedy u IPv4 ruční konfigurace nebo DHCP, pro IPv6 je možná ruční nebo automatická konfigurace. Také DNS klient se musí vyznat jak v A záznamech pro IPv4, tak v AAAA záznamech pro IPv6. Který zásobník se použije, rozhodne uzel na základě cílové adresy paketu. Přitom by měl preferovat IPv6, bude-li to možné Tunelování Tunelování je obecně zabalení jednoho protokolu do druhého. Mechanismus je ukázán na Obrázku 3.1. Tím je umožněno přenášet data přes síť, která daný protokol nepodporuje. Na jedné straně tunelu je tedy IPv6 paket zapouzdřen do IPv4 paketu, kterému se nastaví hodnota 41 v položce Protokol. Pak je poslán na IPv4 adresu směrovače na druhém konci tunelu. Ten z něj vybalí původní IPv6 paket, který se během průchodu tunelem nemění. Což má za následek, že celý průchod je počítán pouze za jeden skok a přijímající směrovač tedy zmenší položku Max skoků v IPv6 hlavičce pouze o jedničku. 19

25 3. Metody přechodu Využívány jsou dva základní režimy tunelování: manuální (nastavovány správcem) a automatické (navazují se samočinně). Manuální tunel se musí na dotyčném zařízení pomocí příkazů nadefinovat. Přesně se mu nastaví druhý konec, kam má směřovat. Tyto tunely se používají většinou k trvalému propojení sítí nebo ke vzdálenému zapojení počítače do sítě. Používají se například u Tunnel Brokeru či TSP. Z principu automatických tunelů vychází metody přechodu 6to4, ISATAP nebo Teredo. Obrázek 3.1: Mechanismus tunelování (převzato z [1]) Překladače Předcházející přístupy potřebují ke svému fungování síť, ve které je integrována i nativní IPv6. V reálném světě mohou nastat i takové případy, kdy zařízení podporující pouze IPv6 potřebuje komunikovat se zařízením podporujícím pouze IPv4. V takovýchto případech se použijí překladače. Tedy adresy jsou překládány z jedné na druhou. Tím je tedy způsobeno, že zařízení nekomunikují přímo mezi sebou, ale přes třetí zařízení, kterým je překladač. Proto může docházet ke ztrátě některých výhod nového protokolu. Mezi překládací metody přechodu patří SIIT, NAT-PT, NAT64, TRT, BIS a SOCKS Konkrétní metody přechodu Tunnel broker Využívá manuálně konfigurované tunely. Jejím základem je síť serverů, zvaných Tunnel Brokers, které spravují žádosti na zřízení tunelů od jednotlivých 20

26 3. Metody přechodu klientů. Má sloužit hlavně k připojení izolovaných IPv6 uzlů, kterým jejich ISP neposkytuje zatím nativní IPv6 připojení. Tento model je založen na několika funkčních elementech. Tunnel Broker je to místo, kde se uživatel může zaregistrovat a aktivovat tunel. Tedy spravuje vytváření, modifikaci a mazání tunelů podle požadavků klienta. Tunnel Server je to směrovač s dvojím zásobníkem. Je připojen jak k IPv4 a IPv6 Internetu. Podle informací z Tunnel Brokeru vytváří, modifikuje nebo ruší svůj konec tunelu. DNS Systém mapuje IPv6 adresy na doménová jména. Každý uživatel dostane přiděleno doménové jméno, na které bude namapována jeho IPv6 adresa. [7] Klient musí na začátku odeslat žádost o registraci k Tunnel Brokerovi. Vždy musí obsahovat jméno, a heslo. Broker klientovi přiřadí blok adres, DNS záznam a vrátí tyto informace zpět. Potom klient odešle žádost o aktivaci tunelu svému Tunnel Brokerovi. Ten tak získá IPv4 adresu a určí Tunnel Server, který bude pro daného klienta sloužit jako vzdálený konce tunelu. Tunnel server sestaví svůj konec tunelu a do IPv6 směrovací tabulky se přidá záznam, že adresa klienta je přístupná přes nově vytvořený tunel. Tunnel Broker odešle informace o vytvořeném tunelu klientovi. Klient si pak nakonfiguruje svou část tunelu. Tato konfigurace je poměrně složitá a vyžaduje poměrně kvalifikovaného uživatele. Proto jsou snahy vytvářet nástroje pro vyjednání tunelu s Tunnel Brokerem. Jedním z nich je i Tunnel Setup Protocol (TSP). Je to v podstatě signalizační protokol, který slouží k vytvoření tunelu mezi dvěma koncovými body. K výměně informací slouží XML soubory, které jsou přenášeny přes TCP nebo UDP protokol. TSP je iniciována z klientského uzlu směrem k Tunnel Brokerovi a skládá se ze tří fází. První fáze je autentizační, kdy Tunnel Broker/Server oznamuje klientovi dostupnost a škálu nabízených služeb a klient se autentizuje. Pak přichází příkazová fáze, kdy klient žádá o tunel nebo aktualizuje tunel stávající. Nakonec přichází fáze odpovědi, kdy klient dostane od Brokera/Serveru odpověď, podle níž tunel buď přijme, nebo odmítne. [8] TSP umožňuje vyjednávat oběma koncům o parametrech, jako jsou třeba prefix, DNS nebo směrování. Dá se také s výhodou použít pro mobilní uzly. 21

27 3. Metody přechodu to4 Cílem této metody automatického tunelování je poskytnout možnost komunikace koncovým IPv6 sítím prostřednictvím IPv4 s minimální konfigurací. Zde není nutné explicitně konfigurovat tunel, ale stačí nakonfigurovat 6to4 směrovač. Metoda by měla pomoci hlavně v prvotních fázích přechodů, po získání nativního připojení by se měla stát zbytečnou a přestat se používat. [9] Základním požadavkem je alespoň jedna veřejná IPv4 adresa. Tu má přiřazenou 6to4 směrovač, který je připojen jak k IPv4 Internetu, tak ke koncové IPv6 síti. Jím procházejí veškerá data přepravovaná 6to4. Nejčastěji tímto směrovačem bývá přístupový směrovač, ale není to podmínkou. Na základě IPv4 adresy se vytvoří IPv6 prefix délky 48 bitů pro celou síť. Prefix 6to4 začíná hodnotou 2002::/16, dalších 32 bitů tvoří veřejná IPv4 adresa daného směrovače. Tím vzniká prefix obvyklé délky. Směrovač pak do vnitřní sítě ohlašuje pouze, že přes něj vede cesta k síti 2002::/16. Datagramy jsou následně adresované do jiné 6to4 sítě jsou k doručení předány jemu. Ten je převezme a automaticky je tuneluje. Takto nakonfigurovaný uzel ale nemůže přímo komunikovat. Proto na Internetu existují zprostředkovatelé (relay routers). Pro nativní IPv6 síť ohlašuje, že je přes něj dosažitelná síť s prefixem 2002::/16. Podle původní specifikace bylo možné najít vhodného zprostředkovatele podle externího směrovacího protokolu, což ale má velkou režii a není proto vhodné pro menší sítě. Nové řešení bylo definováno v RFC 3068, kde byla zavedena fixní výběrová adresa pro zprostředkovatele ( resp. 2002:c058:6301::). Hlavní předností je tedy minimální náročnost. Má malou celkovou režii a pro jeho používání je potřeba nastavit pouze 6to4 směrovač. Nadále je již datagram tunelován automaticky, ale tunel není založen trvale over4 Na rozdíl od přechodového mechanismu 6to4, který řeší připojení koncových IPv6 sítí, se 6over4 zaměřuje na jednotlivé počítače připojené pouze do sítě IPv4. Mechanismus je definován v RFC Zde musí dotyčné počítače podporovat oba protokoly, protože IPv6 datagramy se tunelují samy. Každý takový stroj má svou IPv4 adresu a jeho IPv6 adresa vzniká připojením identifikátoru rozhraní k prefixu podsítě. Identifikátor rozhraní se skládá z prvních čtyř bajtů nulových a pak následuje jeho IPv4 adresa. Pro svou činnost využívá mechanismy běžné v IPv6. Proto je nutné zajistit, aby fungovalo skupinové adresování, které je nutné 22

28 3. Metody přechodu například pro objevování sousedů či při automatické konfiguraci. 6over4 definuje postup, jak se tyto adresy mapují na IPv4 skupiny. Vezme se posledních 16 bitů a před ně se předřadí Protože podpora skupinového vysílání není běžně podporovaná v IPv4 sítích, je tento požadavek považován za hlavní nevýhodu tohoto přístupu ISATAP Mechanismus je definován v RFC Snaží se řešit podobný problém jako 6over4, ale zároveň nebýt závislý na podpoře skupinového vysílání v IPv4. Jelikož se zde nepoužívá skupinové vysílání, není možné použít protokol objevování sousedů. Aby stanice nalezly směrovač, pomocí kterého mohou provést autokonfiguraci, řeší ISATAP tento problém pomocí seznamu potencionálních směrovačů (potential router list, PRL). Uzel posílá výzvu směrovači na adresy uvedené v tomto seznamu. Odpovědi jsou také posílány pouze tomu, kdo se dotazoval. Z těchto ohlášení již může uzel provést proces autokonfigurace. Naplnění seznamu se nejčastěji řeší pomocí DNS, kterého se klient dotazuje na A záznam pro jméno isatap. V adrese tvoří prvních 64 bitů ISATAP prefix, který se získá procesem autokonfigurace pomocí směrovače z PRL. Dalších 32 bitů je ISATAP identifikátor, který má hodnotu 0000:5EFE. Posledních 32 bitů je původní IPv4 adresa vyjádřená v hexadecimálním tvaru. Omezením protokolu je nemožnost využívat skupinové vysílání Teredo Původně se tento návrh jmenoval shipworm, anglický název pro sášeň lodní. Takto označované programy ale mají v počítačovém světě špatnou pověst. Proto se autoři rozhodli změnit jméno na Teredo, což je latinský název pro sášeň lodní. Cílem bylo vytvořit mechanismus, který by překonal překážku v podobě NATu, s kterou si většina ostatních tunelovacích mechanismů neví rady. Teredo tento problém překonává, ale za cenu značné režie, proto je vhodné ho použít až tehdy, kdy ostatní mechanismy selhaly. Vznikla tedy specifikace RFC K použití tohoto principu není třeba žádného speciálního hardwaru, ale je tvořeno softwarovým programem běžícím pod operačním systémem. Využívá se zde Teredo klient a Teredo server. Teredo klient je za NATem v síti IPv4 a žádá o přidělení IPv6 adresy. Zatímco Teredo server má veřejnou IPv4 adresu a přiděluje Teredo klientům IPv6 adresu. 23

29 3. Metody přechodu Vychází z myšlenky zahájení komunikace zevnitř NATované sítě. Proto se utvoří odpovídající vazba na NATu. Teredo se dokáže vypořádat s trychtýřovitým NATem, který klientovi přidělí určitou adresu a port již propouští všechny pakety. Také překoná omezený NAT a klientovi přidělí adresu a port. Avšak propuštěny jsou jen ty datagramy, které přicházejí z adresy a portu, na něž již klient v minulosti něco poslal. Překážkou, se kterou si ani Teredo neumí poradit, je symetricky NAT, který navíc pro data odesílaná k různým cílům přiděluje klientovi jiné adresy a porty. Teredo adresa se skládá z Teredo prefixu (2001::/32). Za ním je IPv4 adresa Teredo serveru, který adresu přidělil. Dalších 16 bitů jsou příznaky. Nově přidaný příznak C (Cone) rozlišuje trychtýřovitý NAT od jiného. Pak následuje 16 bitů značících UDP port (mapování klienta). Posledních 32 bitů patří IPv4 adrese venkovního směrovače s NATem. Teredo klient získává IPv6 adresu tak, že posílá výzvu směrovači s NA- Tem zabalenou do UDP paketu a odešle ji prostřednictvím IPv4 na adresu Teredo serveru. Ten po přijmutí paketu vytvoří adresu pro klienta a zašle ji na adresu a port klienta. Komunikace s ostatními IPv6 adresami se pak dělí na dvě skupiny podle adresáta. Buď je jím další Teredo klient nebo klient s nativní podporou IPv6. V prvním případě si klienti vyměňují data přímo. Nejlepší případ je, když je v cílové adrese nastaven příznak C. To znamená, že je adresát za trychtýřovitým NATem, který přijímá data odkudkoli. Pokud je příznak C nulový, musí poslat odesílatel dvě prázdné zprávy. První zpráva se pošle přímo adresátovi, aby se nastavil místní NAT pro příjem odpovědi. Druhá zpráva je poslaná na adresu Teredo serveru, který ji pouze předá na cílovou adresu a port. Cílový stroj se tímto dozví, že s ním chce někdo komunikovat a odpoví na tuto zprávu. V této fázi již komunikace probíhá přímo. V druhém případě probíhá komunikace s uzlem, který je přímo připojen do IPv6 sítě. Proto je zde zprostředkovatel, který předává datagramy z IPv6 prostředí do Teredo světa a naopak. Ten šíří do sítě, že je přes něj dostupný Teredo prefix 2001::/32. Klient musí najít vhodného zprostředkovatele. Odešle proto ICMPv6 zprávu echo request (požadavek na odpověď). Tu zabalí do UDP a pošle na Teredo serveru, který ji odešle na odpovídající adresu. Odpověď je odeslaná zprostředkovateli. Ten ji podle příznaku v cílové adrese odešle přímo, nebo přes Teredo server. Tím se klient dozví adresu zprostředkovatele a odešle mu paket na otevření svého NATu. Teredo klient si z praktického důvodu udržuje seznam svých komunikačních partnerů. Tento návrh vyžaduje značnou režii pro svoje fungování. Pokud je to možné, je lepší použít jinou metodu. 24

30 3.2.6 Stateless IP/ICMP Translation (SIIT) 3. Metody přechodu Nejstarší z překladových mechanismů. Definuje přesná pravidla pro překlad jednotlivých hlaviček, což je jeho hlavní přínos. Používá bezstavový přístup, tedy si neuchovává žádné informace o procházejících spojeních. Ale překladová pravidla mají svá omezení, která znemožňují používat rozšiřující hlavičky ze strany IPv6. SIIT nebývá v praxi nasazován samostatně, ale jeho definice pro překlad datagramů využívají další mechanismy. [10] NAT-PT Network Address Translation Protocol Translation (NAT-PT) používá právě překladová pravidla podle SIIT a k nim doplňuje mapování a překlad adres. K jednomu IPv6 prefixu mapuje IPv4 adresy přidáním na konec. Směrování v IPv6 musí zajistit, aby se datagramy směřující na daný prefix, doručily stroji implementujícímu NAT-PT. Opačné mapování se provádí na jednu či několik svých IPv4 adres a princip je obdobný jako u běžného NATu. Když IPv6 stroj odesílá datagram do IPv4 sítě, vytvoří se záznam pro IPv6 adresu a port v mapovacích tabulkách překladače a adresu přeloží do IPv4. Když přijde odpověď na příslušnou adresu a port, podle mapovací tabulky ji přeloží do IPv6. Tímto způsobem je umožněno pouze jednostranné navazování spojení z koncové sítě směrem ven. Pro oboustranné navazování je nutný zásah do DNS. Dorazí-li zvenčí dotaz na záznam typu A adresovaný některému ze zdejších DNS serverů, NAT-PT jej změní na záznam typu AAAA. Když dorazí odpověď, zařadí IPv6 adresu v ní obsaženou do své mapovací tabulky a vytvoří mapovaní. Odpověď pak přeloží do IPv4, záznam v ní změní na typ A a vloží do něj svou adresu z vytvořeného záznamu v mapovací tabulce. [11] Praktické nasazení tohoto protokolu přineslo řadu problému kvůli jeho zásahům do DNS záznamu. Proto byl v roce 2007 odmítnut v RFC NAT64 NAT64 je nástupcem překládacího mechanismu NAT-PT. Jeho specifikace vyšla až po čtyřech letech od zavrhnutí staršího mechanismu v RFC Cílem je připojit koncovou IPv6 síť k IPv4 Internetu se všemi jeho službami. Nepřekládá jenom adresy, ale celé datagramy mezi oběma protokoly. Překlad probíhá podle pravidel uvedených v RFC Pro zásahy do DNS záznamů je používán algoritmus DNS64, který je obsažen v RFC Překlad IPv4 adresy na IPv6 je jednoduchý. K určenému prefixu, ob- 25

31 3. Metody přechodu vykle délky 96 bitů, se připojí IPv4 adresa. Pokud dorazí datagram s takto vytvořenou adresou, tak se pouze vyzvedne cílová IPv4 adresa, na kterou se dál přepošle. Takový prefix je označován jako Prefix64::/n a pro příslušné IPv6 adresy se používá pojem Ipv4-převedené (Ipv4-converted). [12] Překlad opačným směrem už tak snadný není. Používá se zde překladová tabulka, která se podobá tabulkám současných NATů. NAT64 překládá místní IPv6 adresy na svou IPv4 adresu a vhodný port. Když následně dorazí z IPv6 sítě datagram, jehož cílová adresa je Ipv4-převedená, vyhledá NAT64 v mapovací tabulce položku pro odesílatele a podle ní vloží do datagramu IPv4 adresu a číslo portu. Pokud položka v tabulce není, tak se vytvoří. Mapovací tabulka pracuje dynamicky. Pokud záznamy nejsou delší dobu používány, tak jsou z tabulky vymazány. NAT64 si musí pro každý protokol uchovávat dvě tabulky. Jednu pro mapování adres a druhou s aktivními relacemi. Je zde také počítáno se statickými položkami, které tam může vložit správce zařízení. Nakonec musí stroj v IPv6 síti získat IPv4-převedenou adresu. K tomu slouží mechanismus DNS64. Ten dostane klientovu žádost o záznam AAAA. Nejprve jej předá dál, a pokud dostane kladnou odpověď, přepošle ji zpět. Pokud ale vznikne chyba, zkusí DNS64 poptat ještě záznamy A. Odpověď pak změní na AAAA tak, že k adresám přidá Prefix64::/n. Spolupracující NAT64 a DNS64 musí pochopitelně používat stejný prefix. Dále musí být zajištěno, aby IPv6 datagramy směřující na IPv4-převedené adresy, procházely NAT64 zařízením. NAT64 je trochu omezený oproti NAT-PT. Umožňuje volně zahájit komunikaci jen ze strany IPv6 a podporuje pouze protokoly UDP, TCP a ICMP. Ostatní protokoly jsou zahozeny. Jeho přínos bude asi nejvíce na úrovni poskytovatele, kdy pomocí něj bude možno zprostředkovat svým zákazníkům IPv4 Internet. 26