Implementace protokolu DNS a možnosti monitorování v koncové síti s protokolem IP verze 6

Článek se zabývá implementací protokolu IPv6 v koncových sítí. V předchozím článku byly popsány doporučení pro přidělování IPv6 adresního prostoru a typy automatických konfigurací. Tento článek poskytuje teoretický úvod do služby DNS a seznamuje s volně dostupnými dohledovými systémy pro monitorování sítí IPv6.

DNS Implementation and Monitoring of Network Elements and Data Traffic on the IPv6 LAN Network - Abstract

This article is the second of a series of articles dealing with the IPv6 implementation on the LAN networks. There were described the recommendations for assigned address space of IPv6 and individual types of auto-configuration of computers in the first article. The second article describes the theoretical introduction to DNS and introduces the freely available supervision systems to monitor IPv6 network.

Keywords: IPv6; auto-configuration; DNS; Dibbler; BIND9; NetFlow; Nagios; NfSen

---

DNS v prostředí IP verze 6

Domain Name System (DNS) je nedílnou součástí dnešních sítí a v sítích s podporou IPv6 tomu nebude jinak. Jedná se o hierarchický systém doménových jmen, který je realizován DNS servery a DNS protokolem a poskytuje především mechanismy pro používání symbolických jmen počítačů místo dlouhých a pro běžného uživatele těžko zapamatovatelných IP adres. Součástí DNS jsou jak pravidla pro tvorbu doménových jmen a domén samotných, tak i mechanismy pro vzájemný převod doménových jmen a IP adres. Obecné základy protokolu DNS jsou definovány v RFC 1035.

Současná implementace DNS v prostředí IPv6 řeší dva problémy [1-3]:

• Ukládání adres IPv6 do DNS [3].
• Komunikaci mezi DNS serverem a klientem prostřednictvím IPv6 – komunikace je otázkou implementace DNS serverů a tedy jejich správců.

Tyto problémy jsou do značné míry nezávislé. Klient může klidně s DNS serverem komunikovat prostřednictvím protokolu IPv4 a vyměňovat si informace o IPv6 a naopak.

Podpora DNS v prostředí IPv6 byla složitá a urazila dlouhou cestu, než se stabilizovala. Během této cesty vznikla celá řada RFC dokumentů, které se zabývají koexistencí obou protokolů:

• RFC 3901 se zabývá rekurzivními servery umístěnými v koncových sítích, které řeší dotazy místních klientů.
• RFC 4074 popisuje možné chybové stavy DNS serverů v případě, že obdrží dotaz na záznam typu AAAA.
• RFC 4472 komplexně popisuje problematiku soužití protokolů IPv6 a DNS. Zabývá se především otázkami typu: „Jaké IPv6 adresy by se měli či neměli zapisovat do DNS?“ a „Jaký protokol by se měl použít v případě, že počítač má k dispozici oba protokoly?“. Odpovědi na obě otázky jsou stručně popsány dále v textu.

Adresy IP verze 6 a DNS

Systém ukládání IPv6 adresy do DNS je stejný jako v případě IPv4, kdy klient pro komunikaci s DNS serverem používá následující typy dotazů:

• Dopředné dotazy
• Reverzní dotazy

Dopředné dotazy

Pro dopředný dotaz byl zaveden nový typ záznamu AAAA, jehož název je odvozen z délky IPv6 adresy. Ta je v porovnání s IPv4 adresou čtyřnásobná.

Má-li počítač fel.cvut.cz adresu 2001:718:8DE:128:3201:A1FF:FE67:12, potom bude v zónovém souboru pro doménu cvut.cz obsažen záznam:

fel

IN

AAAA

2001:718:8DE:128:3201:A1FF:FE67:12

Definice domény cvut.cz, ve které se nachází jeden autoritativní server a jeden počítač, může vypadat následovně:

¨

$ORIGIN cvut.cz
@	IN	SOA server.cvut.cz. root.server.cvut.cz. (
		2012040400	;serial
		28800	;refresh
		14400	;retry
		3600000	;expire
		86400	;default_ttl
		)
;DNS servery
	IN	NS	server
;adresy počítačů
server	IN	AAAA	2001:718:8DE:128:12:67FF:FE1A:3201
fel	IN	AAAA	2001:718:8DE:128:3201:A1FF:FE67:12

V okamžiku, kdy síť používá více prefixů, mají počítače typicky více adres. Potom každá adresa musí mít i odpovídající záznam AAAA v DNS serveru.

Reverzní dotazy

Reverzní dotaz slouží k získání doménového jména ke známé IPv6 adrese. Stejně jako v případě IPv4 se používají záznamy PTR. Reverzní dotaz je tvořen obráceným pořadím šestnáctkových číslic z IPv6 adresy k jejímuž konci se připojí doména ip6.arpa. IPv6 adresa musí být kompletní. Tedy, musí obsahovat všechny nuly. Reverzní dotaz pro výše uvedenou adresu 2001:718:8de:128:3201:A1FF:FE67:12 má tvar:

2.1.0.0.7.6.E.F.F.F.1.A.1.0.2.3.8.2.1.0.E.D.8.0.8.1.7.0.1.0.0.2.ip6.arpa

Díky obrácenému pořadí číslic se prefix dostává na konec, což umožňuje realizovat distribuovanou správu reverzních domén.

Má-li síť ČVUT prefix 2001:718:8DE::/48, dostane do správy reverzní doménu E.D.8.0.8.1.7.0.1.0.0.2.ip6.arpa. Pro počítač fel.cvut.cz, bude potom v zónovém souboru pro reverzní doménu záznam:

2.1.0.0.7.6.E.F.F.F.1.A.1.0.2.3.8.2.1.0

PTR

fel.cvut.cz.

Definice reverzní domény, která odpovídá výše uvedené doméně cvut.cz, může vypadat následovně:

$ORIGIN E.D.8.0.8.1.7.0.1.0.0.2.ip6.arpa.
@	IN	SOA server.cvut.cz. root.server.cvut.cz. (
		2012040400	;serial
		28800	;refresh
		14400	;retry
		3600000	;expire
		86400	;default_ttl
		)
;DNS servery
	IN	NS	server
;reverzní záznamy
1.0.2.3.A.1.E.F.F.F.7.6.2.1.0.0.8.2.1.0				PTR	server.cvut.cz.
2.1.0.0.7.6.E.F.F.F.1.A.1.0.2.3.8.2.1.0				PTR	fel.cvut.cz.

Obsah domén

Každé rozhraní počítače může mít více IPv6 adres s různým dosahem i životností. Z tohoto důvodu vyvstala otázka: „Jaké IPv6 adresy ukládat do DNS?“ Na tuto otázku reaguje RFC 3596, které doporučuje vytvářet DNS záznamy pro následující adresy:

• Všechny globální individuální adresy s dlouhodobou platností.
• Všechny přechodové adresy s dlouhodobou platností (6to4, ISATAP).

RFC 3596 nedoporučuje vytvářet DNS záznamy pro:

• Lokální linkové adresy.
• Náhodně generované krátkodobé adresy, které se používají pro zachování soukromí.

Pro ostatní IPv6 adresy, zejména ty, které jsou přiděleny bezestavovou či stavovou konfigurací, neexistuje univerzální doporučení. Tyto adresy mají většinou krátkodobou platnost, proto jejich zapsání by vyžadovalo nasazení dynamické aktualizace DNS.

Další otázka vyvstává v okamžiku, kdy počítač komunikuje prostřednictvím obou protokolů: "Jaký typ adresy má počítač použít?" Nabízejí se dva základní přístupy:

• Stejné doménové jméno pro oba typy adres.
• Odlišná doménová jména pro jednotlivé typy adres.

Stejné doménové jméno

Má-li počítač fel.cvut.cz IPv4 adresu 192.168.121.57 a IPv6 adresu 2001:718:8DE:128:3201:A1FF:FE67:12, bude v zónovém souboru pro doménu cvut.cz obsažen záznam:

fel	IN	A	192.168.121.57
	IN	AAAA	2001:718:8DE:128:3201:A1FF:FE67:12

Pokud bude chtít tedy host komunikovat s počítačem fel.cvut.cz, tak mu DNS server pošle obě adresy. Volbu vhodné adresy potom host provede na základě typu připojení. V okamžiku, kdy host má k dispozici oba typy protokolů, bude mít IPv6 protokol přednost, protože současné operační systémy upřednostňují IPv6.

Problém může nastat v okamžiku, kdy mezi hosty neexistuje nativní IPv6 konektivita. Pokud se tedy hostu nepodaří navázat spojení prostřednictvím adresy IPv6, automaticky přejde k adrese IPv4 a pokusí se spojit přes ni. Má to však jeden háček. Síťová vrstva neumožňuje ověřit dostupnost protější strany. To tedy znamená, že host přejde na adresu IPv4 až v okamžiku, kdy vyprší různé časovače protokolu TCP na transportní vrstvě, což může trvat i desítky vteřin.

Odlišná doménová jména

V případě odlišných doménových jmen bývá zvykem uvést pod-doménu (často nazvanou ip6 nebo ipv6), ve které jsou zařazeny IPv6 adresy daného počítače. Z doménového jména lze tedy přímo odvodit použití komunikačního protokolu.

V tomto případě by měl zónový soubor pro počítač fel.cvut.cz obsahovat následující záznam:

fel	IN	A	192.168.121.57
fel.ip6	IN	AAAA	2001:718:8DE:128:3201:A1FF:FE67:12

V současné době tento přístup využívá například společnost Google, kde doménové jméno google.com je dostupné přes IPv4 protokol a ipv6.google.com přes IPv6 protokol.

S velkou pravděpodobností se však jedná pouze o dočasnou variantu, protože vede k menšímu využívání protokolu IPv6.

Současné problémy s implementací DNS serverů v prostředí IP verze 6

Různé implementace DNS serverů trpí různými chybami a to hlavně při překládání doménových jmen na IPv6 adresy. Nevhodné chování softwaru je blíže specifikováno v RFC 4074.

Pravděpodobně nejrozšířenější problém nastává v okamžiku použití cache serverů (servery s vyrovnávací pamětí). Problém popíšeme na následujícím příkladu, kdy host pošle lokálnímu cache serveru dotaz na překlad doménového jména na A i AAAA záznam a lokální cache server nemá příslušné záznamy v paměti. V tomto případě se lokální cache server dotáže autoritativního DNS serveru na oba záznamy. Ten má uložený platný A záznam, ale prázdný AAAA záznam a oba záznamy pošle lokálnímu cache serveru. Lokální cache server si oba záznamy uloží do své cache paměti a předá je hostovi. Při budoucím dotazu na stejné doménové jméno se již lokální cache server nedotazuje autoritativního DNS serveru a informace poskytne z cache paměti (tedy pouze A záznam). Což znamená, že se host o případné změně AAAA záznamu nedozví.

Dohledové systémy pro monitorování sítí

Monitorování síťové infrastruktury umožňuje, mimo jiné, sledovat stav síťových prvků, sledovat kvalitu poskytovaných služeb, udržovat síť v provozu s minimálními výpadky, optimalizaci sítě, plánovat rozvoj sítě, detekovat a předcházet případným útokům.

Rozdíl mezi dohledem nad sítí s protokolem IPv4, nebo s protokolem IPv6 není příliš velký. Parametry, které je v síti potřeba sledovat, jsou stejné a tak při volbě dohledového systému obvykle jde jen o to, jestli ten, či onen dohledový nástroj podporuje protokol IPv6, popř. do jaké míry. Existuje celá řada kvalitních komerčních nástrojů, které umožňují monitorovat většinu služeb pro oba typy protokolů. Avšak cílem této práce je zvolit volně dostupný dohledový nástroj, který má slušnou podporou jak IPv4, tak i IPv6 protokolu.

Obecně lze dohledové nástroje rozdělit do dvou skupin:

• Nástroje monitorující stav síťových prvků.
• Nástroje monitorující síťový provoz.

Nástroje monitorující stav síťových prvků

Dnešní nástroje monitorující stav síťových prvků umožňují získat snad každou informaci, na kterou si vzpomenete. Většina těchto nástrojů používá k získávání informací o stavu zařízení protokol SNMP (Simple Network Management Protocol) [4]. Jedná se o velice rozšířený a výrobci často podporovaný protokol hlavně pro jeho univerzálnost. Jeho funkcionalita je založena na principu Manager – Agent.

SNMP Manager obvykle běží na výkonné serverové stanici a jeho funkce spočívá v dotazování se SNMP Agentů na aktuální stav monitorovaných síťových prvků. SNMP Agent, který běží na monitorovaném zařízení, získává tyto informace z tzv. MIB (Management Information Base) databáze. Rozsah informací, které lze získat, závisí právě na MIB databázi a každý síťový prvek, který je subjektem monitorování, musí udržovat minimálně jednu tuto databázi. V případě potřeby, může SNMP Agent informace o stavu síťového prvku poslat i sám.

SNMP protokol lze rovněž použít i pro monitorování síťových prvků v sítích IPv6. Nicméně zásadní fakt, který určuje tuto schopnost, je podpora protokolu IPv6 v MIB databázi jednotlivých zařízení. Je tedy pochopitelně nutné, aby se požadované informace spjaté s novým protokolem nacházely v této databázi, jinak SNMP Agent nebude schopný příslušné informace získat. Aktuálně by měla být podpora protokolu IPv6 v MIB databázích velmi dobrá a to hlavně u předních výrobců síťových prvků, jako jsou např. Cisco, Juniper, Hitachi. Ve výsledku můžeme informace o zařízení spjaté s protokolem IPv6 posílat SNMP Managerovi i přes klasickou IPv4 infrastrukturu (za předpokladu, že zařízení používá technologii dual-stack).

Získané informace SNMP Manager ukládá pro další zpracování a umožňuje jejich zobrazení obvykle pomocí webového rozhraní. K tomu je zapotřebí program, který umožňuje získané informace graficky prezentovat. Existuje mnoho komerčních i nekomerčních programů, po kterých může správce sítě sáhnout. Mezi nejrozšířenější patří Nagios, Cacti, Zabbix, či známé MRTG. V našem příkladu implementace IPv6 v koncové síti jsme si zvolili pro monitorování síťových prvků volně dostupný program Nagios. Ten bude stručně popsán v následující podkapitole.

Nagios

Nagios je aktuálně asi nejpopulárnější monitorovací nástroj síťového prostředí [6]. Jeho redukovaná volně dostupná verze Nagios Core je dostatečná pro nadstandardní monitorování sítí a je produkována s licencí GNU GPL (General Public License). Nagios je primárně určen pro Linux, ale lze ho zprovoznit na většině Unixových systémů. Pro jeho velkou podporu ho volí spousta síťových administrátorů, ba dokonce i celá řada menších a středně velkých ISP. Velkou výhodou tohoto systému je dobrá kompatibilita a stabilita.

Nagios je znám svojí univerzálností. Má frontendovou a backendovou část, kde frontendová část je tvořena přehledným webovým rozhraním, díky kterému lze získané výsledky graficky zobrazit, viz obr. 1. Kdežto backendová část je tvořena řadou utilit, které se starají o chod celého systému. Nagios má modulární strukturu a díky tomu se backendová část skládá hlavně ze skriptů, jejichž spouštění je hlídáno jádrem Nagiosu. Skripty jsou obvykle jednoduché a díky tomu lze pomocí Nagiosu sledovat téměř veškerou aktivitu v síti, od stavu toneru v tiskárně po vytížení rozhraní směrovače. Skripty jsou obvykle psané v jazycích jako je Perl, Bash, či Ruby.

Obr. 1 Obr. 1 Webové rozhraní monitorovacího nástroje Nagios (zdroj http://www.root.cz)

Nagios sám o sobě funguje jako nástroj, který sleduje změnu stavu. Čeho se jistá změna stavu týká, určuje běžící skript nebo plugin (doplňkový modul jiné aplikace, který rozšiřuje její funkčnost), který danou službu, nebo síťový prvek testuje. Nejjednodušší skripty znají tři stavy: OK, WARNING, CRITICAL. OK znamená, že je objekt funkční, WARNING znamená, že se objekt chová nestandardně a CRITICAL znamená, že objekt není dostupný. Nagios tedy v pravidelných intervalech dle plánovače volá jednotlivé skripty, které mu po svém vykonání vrátí příslušný stav. Hodnota je potom uložena do databáze a zobrazena webovým rozhraním. Je tedy jasné, že objekt, který je monitorován, určuje samotný skript, neboli plugin a ne Nagios. Díky tomu lze Nagios jednoduše rozšiřovat přidáváním různých pluginů, kterých je nepřeberné množství.

Nagios se vyznačuje i slušnou podporou protokolu IPv6. Tím je myšleno, že Nagios umožňuje ukládat do databáze a zobrazovat výsledky pro objekty, které fungují pod protokolem IPv6. Sledování dostupnosti síťového prvku pod novým protokolem se děje jednoduše pomocí zprávy ICMPv6, respektive pomocí programu ping6. Sledování služeb je pochopitelně obtížnější a podpora je trochu slabší. To jestli lze službu s novým protokolem sledovat, ovlivňuje hlavně podpora pluginu, respektive skriptu, nežli podpora Nagiosu. Aktuálně lze již většinu služeb s protokolem IPv6 sledovat a vzhledem k popularitě Nagiosu bude podpora nepochybně dále stoupat.

Nejvýznamější schopnosti Nagiosu jsou:

• Sledování síťových služeb: SMTP, POP3, SSH, DNS, SNMP, ICMP, FTP atd.
• Monitorování zdrojů s podporou většiny OS: vytížení procesoru, využití disků, systémové logy atd.
• Sledování různých zařízení se síťovou konektivitou: alarmy, tiskárny, teplotní čidla atd.

Příslušným pluginem lze Nagios rozšířit o upozorňování administrátora na kritické události. Díky tomu se může administrátor okamžitě dozvědět a výskytu nenadálé události, kterou je nutno ihned řešit. Možnosti informování jsou rozličné. Administrátor může být upozorněn pomocí Mailu, nebo SMS zprávy. Nagios také umožňuje reagovat na kritickou zprávu spuštěním dalších skriptů, které nenadálý stav ošetří.

Nástroje monitorující síťový provoz

Při sledování jednotlivých zařízení, například pomocí výše zmíněného protokolu SNMP, můžeme zjistit aktuální, či historické vytížení jejich rozhraní, nicméně nemůžeme zjistit, z čeho se daný síťový provoz ve skutečnosti skládá. To nám umožní až utility sloužící ke sledování síťového provozu. Monitorování síťového provozu spočívá v analyzování paketů a jejich následném zařazení do jednotlivých síťových toků, kde každý síťový tok je definován jako jednosměrná posloupnost paketů sdílejících následující vlastnosti:

• Zdrojová IP adresa
• Cílová IP Adresa
• Zdrojový TCP, nebo UDP port
• Cílový TCP, nebo UDP port
• IP protokol
• Rozhraní
• IP typ služby (Type of service)

Koncept protokolů monitorujících síťový provoz je založen na principu klient – server. V terminologii pro monitorování síťového provozu se serveru říká kolektor a klientu agent či též exportér. Exportér provádí analyzování paketů a jejich klasifikování do jednotlivých síťových toků. Dále ukládá jejich společné vlastnosti, které v pravidelných intervalech odesílá kolektoru. Kolektor informace často ukládá do databáze, a dále je zpracovává pro grafickou prezentaci.

Exportér může být implementován buď softwarově, nejčastěji na hraničním směrovači či přepínači, nebo jako hardwarová sonda, která je umístěna na klíčové pozici v síti. Softwarová implementace je jednoduší a využívá stávající prvky v síti. Tato varianta je lepší zpravidla pro menší sítě, kde síťový provoz není příliš velký. Nevýhodou je nadbytečné zatěžování směrovačů či přepínačů, které pro tento typ operace nejsou optimalizovány. Naproti tomu hardwarové sondy jsou pro tento typ operace optimalizovány a nezpůsobují přetížení směrovačů či přepínačů, a proto se doporučuje je používat pro střední a větší sítě.

Nejpoužívanější protokoly pro sledování síťového provozu jsou [5]:

• sFlow – Tento protokol je specifický tím, že analyzuje jen N-tý paket. To umožňuje šetřit výpočetní prostředky avšak na úkor získaných výsledků, které jsou nepřesné (obtížněji se získávají informace o začátku a konci toku).
• NetFlow – Jedná se o proprietární protokol společnosti Cisco, který díky své popularitě implementuje i celá řada jiných výrobců. Protokol prošel celou řadou změn a jeho aktuální verze má číslo 9. Ta má kompletní podporu protokolu IPv6 a právě tuto verzi použijeme pro sledování síťového provozu v našem příkladu. Dále v textu budou představeny nejčastěji používané kolektory tohoto protokolu.
• IPFIX - Jedná se o standard, který je definován v RFC 5101. Cílem tohoto protokolu je vytvořit sjednocený standard a omezit tak různá proprietární řešení. Vychází z proprietárního protokolu NetFlow verze 9 a je mu velmi blízký.

NetFlow analyzátory

Volně dostupných programů pro účely analyzování síťových toků je celá řada. Většina z nich ale podporuje jen základní formát NetFlow verze 5. Pokud chce síťový administrátor využít všechny možnosti a monitorovat IPv6 toky, bude muset sáhnout po verzi 9. Kolektorů podporujících poslední verzi protokolu NetFlow je však o poznání méně:

• nTop – Program slouží jako kolektor pro různé protokoly [7], jako jsou NetFlow a sFlow, a využívá knihovnu libpcap, díky čemuž je kompatibilní nejen s Unixovými systémy, ale i se systémy Windows. Podobně jako u většiny ostatních programů mu nechybí frontendová část ve formě webového rozhraní, která umožňuje vizualizaci dat a také konfiguraci programu. Od stejných vývojářů pochází i program nProbe. Jedná se o softwarovou sondu, která slouží jako exportér pro rozličné protokoly, jako jsou NetFlow verze 5 a 9, sFlow a IPFIX.
• NFDUMP Tools – Jedná se o skupinu nástrojů, které dohromady vytvářejí kvalitní kolektor. Ve spojení s programem NfSen, který slouží jako frontendová část, se jedná o velice kvalitní produkt pro sledování síťového provozu. Větší pozornost těmto programům je věnována v následující podkapitole.

Monitorovací nástroje NfDump a NfSen

Jedná se o velmi kvalitní řešení monitorování síťového provozu, které podporuje protokol NetFlow (verze 5, 7, 9) [8, 9]. Díky tomu se vyznačuje plnou podporou protokolu IPv6. Jako většina dalších nástrojů se skládá z frontendové a backendové části.

Backendová část je tvořena následující sadou nástrojů:

• NfCapd – Tato utilita běží v systému jako démon a slouží k zachytávání, čtení a ukládání NetFlow paketů do RRD databáze [5]. Data ukládá do souborů v pravidelných, typicky pětiminutových intervalech. Jeden démon vždy naslouchá na jednom portu. To znamená, že pro více sond je třeba mít stejný počet spuštěných démonů.
• NfDump – Stejnojmenná utilita slouží k získávání dat ze souborů vytvořených pomocí NfCapd. Tento program umožní zobrazit potřebné statistiky pomocí specifických kritérií.
• NfProfile – Umožňuje ukládat specifická filtrovací kritéria do tzv. profilů a filtrovaná data ukládat pro další zpracování.
• NfReplay – Tato utilita umožňuje uložená NetFlow data zasílat jinému NetFlow kolektoru v síti.

Frontendová část systému je tvořena webovým rozhraním NfSen [9], viz obr. 2. To slouží k přehlednému grafickému zobrazování výsledků. Program umožňuje zobrazovat souhrnné výsledky, nebo i specifické toky, které lze filtrovat pomocí různých kritérií. Ve výsledku lze dohledat jednotlivé toky s určitou cílovou a zdrojovou IP adresou, specifickým portem nebo dalšími parametry. Mimo jiné existuje i několik pluginů, které umožní rozšířit možnosti filtrování specifických informací a jejich zobrazení a automatickou detekci proti různým druhům útoků v síti:

• Port tracker – Ve výchozí podobě umí Nfsen vyfiltrovat síťové toky dle jejich cílových portů a zobrazit je pouze ve formě záznamů. Tato nadstavba umožnuje toky se stejným portem zobrazovat graficky, což zpřehlední práci se softwarem.
• Nfsight – Tento plugin nabízí vizualizaci veškerých toků. Toky potom nemusí být zobrazovány ve formě záznamů, ale jsou přehledně zobrazeny v různých grafických mapách.
• Botnet – Plugin, který umožnuje detekci útoků pomocí bot programů (program, který umí plnit příkazy útočníka zadávané z jiného počítače).

Obr. 2 Webové rozhraní monitorovacího nástroje NfSen (zdroj http://nfsen.sourceforge.net)

Závěr

Tento článek si kladl za cíl poskytnout čtenáři teoretický úvod do problematiky DNS v prostředí IPv6 a monitorování stavu síťových prvků a síťového provozu. Další článek se již bude zabývat příkladem praktické implementace IPv6 v koncové experimentální síti. Konkrétně se bude zabývat topologií experimentální sítě, konfigurací bezestavové a stavové konfigurace a DNS serveru.

Tento příspěvek vznikl v souvislosti s řešením projektu Fondu rozvoje sdružení CESNET „Implementace protokolu IPv6 do experimentální a výzkumné sítě katedry Telekomunikační techniky a její metodické zobecnění“ a projektu Studentské grantové soutěže ČVUT v Praze č. SGS10/275/OHK3/3T/13.

Seznam použitých zkratek

DNS	Domain Name System
FTP	File Transfer Protocol
GNU GPL	GNU General Public License
ICMP	Internet Control Message Protocol
IPv4	Internet Protocol Version 4
IPv6	Internet Protocol Version 6
ISATAP	Intra-Site Automatic Tunnel Addressing Protocol
MRTG	Multi Router Traffic Grapher
OS	Operační systém
POP3	Post Office Protocol 3
RFC	Request for Comments
RRD	Round Robin Database
SMTP	Simple Mail Transfer Protocol
SNMP	Simple Network Management Protocol
SSH	Secure Shell
TCP	Transmission Control Protocol
UDP	User Datagram Protocol

Literatura

[1] SATRAPA, P. IPv6: internetový protokol verze 6 [online]. 3., aktualiz. a dopl. vyd. Praha: CZ.NIC, c2011, 407 s. [cit. 2012-05-15]. CZ.NIC. ISBN 978-80-904248-4-5 (BROž.). Dostupné z: http://ii.iinfo.cz/r/kd/internetovy-protokol-ipv6-treti-vydani.pdf
[2] BUSH, R. – DURAND, A. – FINK, B. – GUDMUNDSSON, O. – HAIN, T. Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) [online]. c2002, [cit. 2012-05-24]. Dostupné z: http://www.ietf.org/rfc/rfc3363.txt
[3] THOMSON, S. – HUITEMA, C. – KSINANT, V – SOUISSI, M. DNS Extensions to Support IP Version 6 [online]. c2003, [cit. 2012-05-24]. Dostupné z: http://www.ietf.org/rfc/rfc3596.txt
[4] MAURO, Douglas R a Kevin J SCHMIDT. Essential SNMP. 2nd ed. Beijing: O´Reilly, 2005, 442 s. ISBN 05-960-0840-6
[5] LUCAS, Michael. Network Flow Analysis. San Francisco: No Starch Press, c2010, xiii, 204 p. ISBN 978-1-59327-203-6
[6] BARTH, Wolfgang. Nagios: system and network monitoring. 2nd ed. Munich: Open Source Press, c2008, 719 p. ISBN 15-932-7179-4
[7] ntop [online]. 2012 [cit. 2012-05-24]. Dostupné z: http://www.ntop.org/
[8] NFDUMP [online]. 2011 [cit. 2012-05-24]. Dostupné z: http://nfdump.sourceforge.net/
[9] NfSen [online]. 2011 [cit. 2012-05-24]. Dostupné z: http://nfsen.sourceforge.net/