Konfigurace adres při implementaci IP verze 6 v koncových sítích

Tento článek je prvním ze seriálu článků, které se zabývají implementací protokolu IPv6 v koncových sítí. Budou zde popsány základní kroky nutné pro správnou implementaci IPv6, včetně nasazení nezbytných služeb, jako jsou DNS, automatická konfigurace koncových stanic a monitorovacích systémů.

Configure Addresses for the Implementation of IP Version 6 on the LAN Network - Abstract

This article is the first of a series of articles dealing with the IPv6 implementation on the LAN networks. There will be described the basic steps that are necessary for proper IPv6 implementation, including the deployment of necessary services such as DNS and auto-configuration of computers, and monitoring systems.

Keywords: IPv6; auto-configuration; DNS; IP adress

---

Úvod

V současné době je Internet nejrozšířenější prostředí pro komunikaci, přenos dat a provoz interaktivních aplikací a mnoha služeb charakterizujících dnešní dobu. Současný Internet je založen na Internetovém protokolu verze 4 (IPv4), jehož adresní rozsah byl v rámci organizace IANA (Internet Assigned Numbers Authority) vyčerpán již v dubnu 2011. Poslední volné adresní rozsahy IPv4 jsou k dispozici na úrovni organizací RIR (Regional Internet Registers) a Národních poskytovatelů internetových služeb. Na tenčící se adresní prostor IPv4 reagovala standardizační organizace IETF (Internet Engineering Task Force), která již v roce 1996 standardizovala nový Internetový protokol. Ten byl označen jako IPv6. Protokol IPv6 v mnoha ohledech řeší nedostatky IPv4, avšak využívá mnoho pomocných mechanismů, z nichž některé jsou stále ve fázi vývoje. Z tohoto důvodu je stále nejrozšířenějším Internetovým protokolem protokol IPv4 a IPv6 se rozvíjí jen pomalu. V současné době větší poskytovatelé Internetu ISP (Internet Service Provider) pozvolna nasazují protokol IPv6 na páteřních spojích a rovněž i provozovatelé internetových služeb začínají implementovat IPv6 do svých služeb. Tento vývoj v blízké době přinese i požadavky na implementaci protokolu IPv6 do koncových sítí ve větší míře než doposud.
Z tohoto důvodu je nutné vytvořit obecnou metodiku, která se zabývá základními požadavky na implementaci protokolu IPv6 do koncových sítí. Tento článek se zabývá adresací a možnými pravidly a doporučeními pro přidělování IPv6 adres. Dále poskytuje stručný teoretický úvod do služeb automatická konfigurace.

Protokol IPv6

Základy protokolu IPv6 jsou popsány v [1] nebo [2], kde lze nalézt formát datagramu, používané adresy a mechanismy nezbytné pro správnou funkci IPv6. Používané směrovací protokoly v rámci sítě IPv6 a stručný úvod do směrování naleznete v [2] a [3]. Konkrétní příklad návrhu směrování v síti IPv6 naleznete v [4].

Adresní prostor a adresování v rámci koncové sítě

Adresní prostor IPv6 byl rozdělen do několika skupin a každá skupina sdružuje adresy se společnou charakteristikou [1], [5]. Adresy lze k jednotlivým typům přiřadit na základě prefixu, viz tab. 1.

Prefix	Význam
::/128	nedefinovaná adresa
::1/128	smyčka (loopback)
FC00::/7	unikátní individuální lokální
FE80::/10	individuální lokální linkové
FF00::/8	skupinové adresy
ostatní	individuální globální

Tab. 1 Základní rozdělení adres

Nejdůležitějším typem adres jsou globální individuální adresy, které jsou celosvětově jednoznačné a identifikují svého uživatele v rámci celého Internetu. Struktura globální individuální adresy [1], [6] je uvedena na obr. 1. Tyto adresy jsou v současné době přidělovány pouze z prefixu 2000::/3. Ostatní prefixy jsou rezervovány pro budoucí použití. Posledním typem adres jsou tzv. výběrové adresy (anycast) [1]. Jedná se o novinku oproti IPv4 a označují skupinu síťových zařízení, avšak data se doručí pouze jednomu zařízení, a to tomu, které je neblíže. Výběrové adresy nemají přiřazené žádné speciální rozmezí a přidělují se ze stejného prostoru, jako adresy individuální.

Obr. 1 Struktura globální individuální adresy

Při přidělování globálního směrovacího prefixu záleží na tom, kdo ho komu přiděluje. Základní pravidla jsou naznačena na obr. 2.

Obr. 2 Přidělování globálního směrovacího prefixu

Na základě struktury globální individuální adresy lze přidělit minimální prefix délky 64 bitů (dále již prefix /64). Každá organizace, jako je RIR, LIR (Local Internet Register), lokální ISP, která si zažádá o přidělení adresového prostoru IPv6, dostane globální směrovací prefix. Délka globálního směrovacího prefixu záleží na tom, kdo ho přiděluje. Pokud prefix přiděluje RIR, v rámci Evropy RIPE NCC (Réseaux IP Européens Network Coordination Centre), potom je jeho délka dána poměrem HD-Ratio (1) [6]. V takovém případě je s velkou pravděpodobností přidělen prefix /32 a méně. V případě, že menší ISP žádá LIR o přidělení globálního prefixu, tak se přidělování prefixu řídí většinou interní politikou dané organizace. V takovém případě je přidělen nejčastěji prefix /48 a méně (až /32) nebo více prefixů stejné délky. Vše záleží na interní politice přidělování adres dané organizace.

Pro přidělování adresového prostoru (prefixu) z globálního směrovacího prefixu je vyhrazeno n bitů, kde n se určí ze vztahu (2). Potom maximální počet možných podsítí v rámci přiděleného globálního prefixu je dán vztahem (3).

V okamžiku, kdy organizace dostane globální směrovací prefix, tak se přidělování adresového prostoru dalším zájemcům (jednotlivým uživatelům, koncovým sítím, atd.) řídí interní politikou dané organizace. Politika přidělování adresového prostoru je vždy plně v kompetenci dané organizace, avšak lze charakterizovat body, které mohou sloužit jako doporučení při jeho přidělování [7]:

1. Definovat prefix pro spoje bod-bod ze společného rezervovaného adresového prostoru, který má nejčastěji prefix /64. Tento prefix je nutno volit s ohledem na topologii sítě, tedy podle toho jestli je určen pro více zákazníků nebo jen pro jednoho. Univerzální volbou může být prefix /112, který nabízí až 4096 adres, což je více jak dostatečný počet pro spoj bod-bod i s ohledem na budoucí rozšíření na LAN síť pro propojení více směrovačů.
2. V rámci domácí koncové sítě přidělovat LAN sítím jeden nebo více prefixů /64. Pro běžného uživatele je optimální délka prefixu /62 (tj. blok 4 prefixů /64). V případě, že administrátor disponuje dostatečným množstvím adres, je pro domácí koncovou síť obecně doporučovaný prefix /56. Pro představu, prefix /32 disponuje blokem cca 16,8 miliónů prefixů /56. Avšak prefixy kratší jak /64 přidělovat pouze na základě prokázání potřeby použití více podsítí v dané koncové síti.
3. Firmám přidělovat prefixy /48, /52 nebo /56 podle velikosti a počtu využívaných podsítí. V případě, že administrátor nadřazeného ISP má k dispozici prefix /32, je optimální firmám přidělovat prefix /48. Prefixy /52 a /56 mohou být pro firmy nedostatečné s ohledem na přidělování adresového prostoru dalším podsítím (např. topologicky odděleným oblastem (pobočky), VPNkám, serverovým DMZ (Data Management Zone) zónám, LAN a WLAN sítím pro zaměstnance a hosty, atd.). Typicky odděleným oblastem v rámci jedné firmy je doporučeno přidělovat právě prefixy /56 a zároveň rezervovat další alokační bloky, viz bod 5, pro možné budoucí rozšíření těchto oblastí.
4. Menším ISP přidělovat prefix /48 a méně. Optimálně přidělovat prefix /32, protože při dodržování správné segmentace sítě (viz body 1, 2, 3) by prefix /48 byl nedostatečný.
5. Ponechat si rezervy. Ke každému přidělenému prefixu rezervovat jeden, tři, sedm nebo patnáct stejně velkých číselně následujících prefixů. Například pokud má menší ISP přidělen prefix 2001:AD6:A0::/48, tak prefixy 2001:AD6:A1::/48 až 2001:AD6:A7::/48 rezervovat do budoucnosti, kdyby přidělený rozsah ISP nestačil.
6. V případě geograficky rozlehlé topologie sítě, přidělovat jednotlivé prefixy z adresového prostoru tak, aby byla zajištěna agregace směrování a směrovače tak mohly směrovat celé bloky adres. Tím dojde ke snížení požadavků na výpočetní prostředky směrovače pro směrování. Například prefixy /48 lze seskupit podle geografických oblastí do prefixu /40.

V rámci koncové sítě lze pro výchozí směrovače, servery, tiskárny atd. doporučit manuální konfiguraci adres a přidělovat adresy ve tvaru prefix_podsítě::X, kde X je až čtyřmístné hexadecimální číslo (např. pro výchozí směrovač sítě s prefixem 2001:AD6:A0:123::/64 volit adresu 2001:AD6:A0:123::1). Při manuální konfiguraci adres je nutné respektovat vyhrazené rozsahy adres, viz tab. 2, a pravidla daná modifikovaným standardem EUI-64 [1]. Volba tohoto tvaru adres je daná snazší administrací těchto uzlů.

RFC4291 Subnet-Router anycast:	0:0:0:0
RFC2526 Reserved Subnet anycast:	FDFF:FFFF:FFFF:FF80 – FDFF:FFFF:FFFF:FFFF
RFC2526 Mobile IPv6 Home Agents anycast:	FDFF:FFFF:FFFF:FFFE
RFC3956 Embedded-RP:	0:0:0:000x (v dolních 4 bitech identifikátoru RP)
RFC5214 ISATAP Addresses:	0000:5EFE:xxxx:xxxx (v dolních 32 bitech IPv4 adresa)
RFC4291 Universal a Group EUI-64:	první oktet bit 1=1 (u) nebo bit 0=1 (g) – host ID začínající x2xx, x3xx, x6xx, x7xx, xAxx, xBxx, xExx, xFxx

Tab. 2 Vyhrazené rozsahy adres [7]

Pro koncové stanice lze naopak doporučit používat automatickou konfiguraci, což rovněž zjednoduší práci administrátora. Typy automatické konfigurace stanic stručně popisuje následující kapitola.

Konfigurace adres

Tato část článku se bude zabývat problematikou konfigurace koncových stanic. Protokol IPv6 nabízí více variant, kterými lze přidělit koncové stanici její IP adresu. Kromě statické konfigurace především nabízí dvě varianty automatické konfigurace:

• Bezestavová konfigurace
• Stavová konfigurace

Bezestavová konfigurace

Bezestavová konfigurace SLAAC (Stateless Address Autoconfiguration) představuje zcela nový způsob automatické konfigurace [1]. Vychází ze skutečnosti, že každá lokální síť má výchozí směrovač nebo server, který zná všechny potřebné parametry pro komunikaci s okolním světem. Tyto parametry potom směrovač nebo server rozesílá do všech sítí, ke kterým je připojen. Klientovi tedy stačí pouze naslouchat či o tyto parametry požádat.

Základním kamenem bezestavové konfigurace je ICMPv6 zpráva Ohlášení směrovače RA (Router Advertisment), obr. 3, pomocí které se v náhodných časových intervalech rozesílají všechny potřebné parametry pro komunikaci s okolním světem. V případě, že koncová stanice neobdrží v určitém intervalu ohlášení směrovače, může o ní zažádat zprávou Výzva směrovači RS (Router Solicitation).

Obr. 3 Formát zprávy Ohlášení směrovače

Pro pochopení bezestavové konfigurace je nezbytné vysvětlit jednotlivé položky zprávy RA:

• Omezení skoků (Cur Hop Limit) – oznamuje uzlům, jakou hodnotu mají vkládat do položky s maximálním počtem skoků (životnost datagramu) do záhlaví IPv6 paketu.
• Příznak M (Managed Address Configuration) – příznak Stavové konfigurace adres oznamuje, že adresy a další komunikační parametry jsou přidělovány protokolem DHCPv6.
• Příznak O (Other Stateful Configuration) – příznak Stavové konfigurace ostatních parametrů oznamuje, že i ostatní parametry jsou přidělovány protokolem DHCPv6, jako je adresa lokálního DNS serveru. Tabulka tab. 4 uvádí význam možných kombinací příznaků M a O.
• Příznak H (Home Agent) – příznak domácího agenta slouží k podpoře mobility a oznamuje, že výchozí směrovač pracuje i jako domácí agent [1].
• Preference (Prf) – umožňuje rozlišit preference výchozích směrovačů a nastavuje se v případě nenulové položky Životnost výchozího směrovače. Existují celkem čtyři úrovně, viz tab. 3.
• Životnost výchozího směrovače (Router Lifetime) – oznamuje časový interval, po který směrovač bude sloužit jako výchozí. Je-li hodnota nulová, směrovač nebude použit jako výchozí.
• Trvání dosažitelnosti (Reachable Time) – oznamuje, jak dlouho má být uzel považován za dosažitelný, poté co byla ověřena jeho momentální dosažitelnost.
• Interval opakování (Retrans Timer) – jedná se o interval mezi dvěma zprávami Výzva sousedovi [1]. Tyto zprávy využívá mechanismus Objevování sousedů ND (Neighbor Discovery) [1].
• Volby – umožňují připojit informace o fyzické adrese, ohlásit MTU linky a především slouží pro vkládání informací o prefixech. Pro každý prefix se vloží jedna volba Informace o prefixu, viz obr. 4.

Preference	Význam
01	vysoká
00	střední
11	nízká
10	rezervováno (nesmí se používat)

Tab. 3 Preference výchozího směrovače

Obr. 4 Formát volby Informace o prefixu

Formát volby Informace o prefixu obsahuje tyto důležité položky:

• Délka prefixu (Prefix Length) – udává délku prefixu v bitech.
• Příznak L (on-Link) – oznamuje, že podle tohoto prefixu lze rozhodovat, zdali je cíl komunikace ve stejné podsíti, či nikoliv.
• Příznak A (Autonomous Address-configuration) – příznak autonomní konfigurace adres oznamuje, že daný prefix lze použít k automatické konfiguraci vlastní adresy. Je-li tento příznak nastaven na hodnotu 0, umožňuje vypnout bezestavovou konfiguraci. Uzel má k dispozici tedy pouze lokální linkovou adresu nebo může k získání adresy použít DHCPv6. V případě, že některé prefixy mají nastaven příznak A i L, může daný uzel použít obě automatické konfigurace pro získání adresy.
• Příznak R (Router Address) – příznak adresy směrovače oznamuje, že položka Prefix obsahuje kompletní globální adresu směrovače. Tento příznak byl zaveden pro potřeby mobility. V případě využití pro automatickou konfiguraci se použije pouze prefix a identifikátor rozhraní se bude ignorovat.
• Doba platnosti (Valid Lifetime) – udává dobu platnosti prefixu.
• Doba preferování (Preferred Lifetime) – udává dobu preferování adresy [1].

Před zahájením vlastní komunikace si každý uzel automaticky vygeneruje pro každé aktivní rozhraní lokální linkovou adresu. Tato adresa vznikne z prefixu FE80::/10 a identifikátoru rozhraní [1]. Následně musí uzel ověřit jednoznačnost této adresy, respektive identifikátoru rozhraní, v rámci lokální linky. K tomu použije mechanismus Detekce duplicitních adres DAD (Duplicate Address Detection), který je založen na mechanismu ND. Princip je jednoduchý. Uzel pošle výzvu sousedovi, kterou hledá všechny sousedy se stejnou lokální linkovou adresou. Pokud jako reakce na tuto zprávu dorazí ohlášení souseda, znamená to, že i jiný uzel v lokální síti má stejný identifikátor rozhraní a automatická konfigurace je následkem toho zastavena. Duplicita adres se testuje i v případě manuální nebo stavové konfigurace adres. V případě negativní odezvy si uzel vygenerovanou lokální linkovou adresu přidělí a bude čekat na ohlášení směrovače.

V okamžiku, kdy uzel přijme ohlášení směrovače, odvodí si z příznaků M a O, zda má pro konfiguraci adresy a ostatních parametrů sítě použít bezestavovou či stavovou konfiguraci, případně, zda má kombinovat obě konfigurace. Možné scénáře kombinace příznaků M a O jsou uvedeny v tab. 4. Význam obou příznaků je uveden výše v textu. Dále jsou pro vysvětlení možných scénářů použity proměnné M-Policy a O-Policy [8]. Proměnná M-Policy může nabývat hodnot:

• Policy 1 – klient by měl použít stavovou konfiguraci (DHCPv6) pro automatickou konfiguraci, včetně konfigurace i ostatních parametrů sítě bez ohledu na příznaky M a O stávajícího nebo příchozího ohlášení směrovače.
• Policy 2 – klient by měl použít stavovou konfiguraci pro automatickou konfiguraci, včetně ostatních parametrů sítě, pouze v případě, kdy je příznak M nastaven na hodnotu 1.
• Policy 3 – klient by neměl pro automatickou konfiguraci použít stavovou konfiguraci, včetně ostatních parametrů sítě bez ohledu na příznaky M a O stávajícího nebo příchozího ohlášení směrovače.

Proměnná O-Policy může nabývat hodnot:

• Policy 1 – klient může použít stavovou konfiguraci pouze pro získání ostatních parametrů sítě bez ohledu na příznaky M a O stávajícího nebo příchozího ohlášení směrovače.
• Policy 2 – klient může použít stavovou konfiguraci pro získání ostatních parametrů sítě pouze v případě, kdy je příznak M nastaven na hodnotu 1.
• Policy 3 – klient by neměl použít stavovou konfiguraci pro získání ostatních parametrů sítě bez ohledu na příznaky M a O stávajícího nebo příchozího ohlášení směrovače.

		Příznak M
		0	1
Příznak O	0	M-Policy: 1     Stavová konfigurace (DHCPv6) M-Policy: 2 nebo 3 & O-Policy: 1     Bezestavová konfigurace (SLAAC)	M-Policy: 1 nebo 2     Stavová konfigurace (DHCPv6) M-Policy: 3 & O-Policy: 1     Bezestavová konfigurace (SLAAC)
	1	M-Policy: 1     Stavová konfigurace (DHCPv6) M-Policy: 2 nebo 3 & O-Policy: 1 nebo 2     Bezestavová konfigurace (SLAAC)	M-Policy: 1 nebo 2     Stavová konfigurace (DHCPv6) M-Policy: 3 & O-Policy: 1 nebo 2     Bezestavová konfigurace (SLAAC)

Tab. 4 Možné kombinace příznaků M a O a jejich význam

Pokud je zvolena bezestavová konfigurace, pak uzel ke každému prefixu, který je obsažen v ohlášení směrovače a nemá nastaven příznak A na hodnotu 0, připojí svůj identifikátor rozhraní a adresu si přidělí. Identifikátor rozhraní určí buď podle modifikovaného EUI-64, nebo náhodně podle RFC 4941 [1]. V případě, že si uzel vygeneroval identifikátor rozhraní podle modifikovaného EUI-64, nemusí již testovat jeho jednoznačnost. Ta byla ověřena během generování lokální linkové adresy. V opačném případě musí dojít k ověření jednoznačnosti adresy.

Takto přiřazená adresa k rozhraní má časové omezení, které je odvozeno z doby platnosti a doby preferování. Adresa je bezprostředně po svém vzniku označena jako preferována (preferred). Uzel ji může bez žádných omezení libovolně používat. Po vypršení doby preferování je adresa označena jako odmítaná (deprecated). To znamená, že je sice adresa platná, ale pro zahájení nové komunikace by se již neměla používat. Uzel by měl zvolit jinou preferovanou adresu. Jakmile vyprší doba platnosti adresy, pak se již nesmí použít pro síťovou komunikaci.

Bezestavová konfigurace rovněž umožňuje odvození směrovacích informací [1], avšak její základní mechanismy nepodporují konfiguraci DNS serverů, což je vzhledem tvaru adres IPv6 obrovská nevýhoda. Tento problém řeší RFC 6106, které doplňuje dvě nové volby pro DNS do ohlášení směrovače [1]. Jedná se však o relativně nový dokument, takže jeho implementace do operačních systémů ještě nějakou chvíli potrvá. Z tohoto důvodu je v případě nasazení bezestavové konfigurace nutné použít i stavovou konfiguraci.

Stavová konfigurace

Pro potřeby stavové konfigurace byl definován protokol DHCPv6 (Dynamic Host Configuration Protocol for Internet Protocol Version 6) [1]. Jedná se o modifikaci protokolu DHCP, který se široce používá v sítích IPv4. Protokol DHCPv6 se od jeho předchůdce v zásadě příliš neliší:

• Stejně jako jeho předchůdce využívá modelu klient-server.
• Oba protokoly slouží k delegaci konfiguračních parametrů všem žádajícím klientům v síti, především se jedná o přidělení jedné či více IP adres.
• Klient a server musí být umístěny v jedné podsíti, jinak spolu nemohou komunikovat (komunikují pomocí lokálních linkových adres a skupinových adres s dosahem lokální linky). Jestliže umístíme DHCP server do jiné sítě, potom musí být v síti klienta prostředník (DHCP relay), který přeposílá zprávy serveru a naopak.
• Oba protokoly využívají ke komunikaci protokol UDP.

Počáteční komunikace mezi klientem a serverem probíhá ve čtyřech fázích stejně jako v případě jeho předchůdce. Komunikaci zahajuje klient, který pošle zprávu Výzva (solicit) na adresu všech DHCP serverů a agentů (FF02::1:2) s dosahem jedné linky. V případě, že se v rámci linky místo DHCP serveru nachází DHCP prostředník (DHCP relay), budou jím zprávy přeposílány na adresu všech serverů (FF05::1:3) s dosahem jednoho místa [1].

Server odpovídá zprávou Ohlášení serveru (advertise), ve které jsou nabízeny všechny konfigurační parametry. Klient přijme jedno či více ohlášení serveru a vybere pro něj nejvhodnější. Poté nastává třetí část, ve které klient zasílá zprávu žádost (request), ve které žádá o potvrzení konfiguračních parametrů. Cílový server potom konečně odpovídá zprávou odpověď (reply), ve které potvrzuje klientovi, že tyto parametry může použít a nakonfigurovat podle nich své rozhraní.

V současné době je implementace protokolu DHCPv6 dostatečně zvládnuta pouze firmou Cisco Systems, Inc. Ostatní výrobci v implementaci tohoto protokolu zaostávají a jeho podpora není dostatečná nebo zcela chybí. Například fa Mikrotik podporuje DHCPv6 protokol od verze RouterOS 5.9, ale stávající implementace neumožňuje vložit adresu DNS serveru.

DHCPv6 server lze rovněž spustit i na serverech založených na linuxové distribuci nebo Microsoft Windows Server 2008. Jak Windows Server 2008, tak i linuxové distribuce mají k dispozici předinstalované programy, které umožňují zapnutí a nastavení DHCPv6 serveru. Microsoft Windows Server 2008 má k dispozici DHCPv6-capable DHCP server a většina linuxových distribucí dhcp6s. Ostatní produkty Microsoftu vyžadují doinstalování programu, který bude vykonávat funkci DHCPv6 serveru. Existuje celá řada takovýchto programů jak pro Windows, tak pro linuxové distribuce.

Pro naše účely, kdy funkci DHCPv6 serveru bude vykonávat server založený na linuxové distribuci Scientific Linux, jsme zvolily program zvaný Dibbler verze 0.8.0. Tento program bude blíže popsán v dalším článku zabývajícím se praktickou ukázkou implementace IPv6 v koncové síti.

Kombinace obou konfigurací

Z výše uvedených skutečností se v současné době jeví jako nejzajímavější kombinace bezestavové konfigurace a DHCP serveru, kde DHCP server je spuštěn na linuxovém stroji. Tato skutečnost je oznámena uzlu prostřednictvím příznaků M a O v ohlášení směrovače, viz tab. 4. Ten si z delegované prefixu odvodí svoji adresu a ostatní parametry sítě si vyžádá od DHCP serveru. Nejčastější dodatečná informace bude pravděpodobně adresa DNS serveru, bez níž je koncová stanice značně omezena.

Poznámka: Aktuálně je na experimentální úrovni i několik jiných přístupů k problému delegace adresy DNS serveru, díky nimž by se v jednodušších a menších sítích mohlo nasazení DHCP severu úplně vynechat. Jednou z nich je přiřazení DNS serveru do seznamu výběrových adres [1]. Díky tomu by koncové stanice byly předkonfigurovány výběrovou adresou, na které by ve výchozím nastavení DNS server naslouchal. Další variantou je zasílání adresy doménového serveru pomocí ohlášení směrovače. Toto se jeví jako zajímavá varianta a řada výrobců směrovačů (např. Mikrotik) tuto variantu umožňuje. Vzhledem k tomu, že tato možnost byla standardizována teprve nedávno, je její nativní podpora u koncových stanic chabá. To ale lze obejít instalací dodatečné aktualizace (patch), která tento problém řeší. V budoucnu se ale podpora nepochybně zlepší.

Závěr

Podpora protokolu IPv6 se napříč poskytovateli Internetu a provozovateli internetových služeb pozvolna zlepšuje. Tento vývoj v blízké době přinese i požadavky na implementaci protokolu IPv6 do koncových sítí ve větší míře než doposud. Tento fakt vyžaduje osvětu a šíření základních i pokročilých postupů, které jsou nezbytné pro správnou funkčnost IPv6 v koncových sítích. Tento článek poskytl čtenáři stručný teoretický úvod do problematiky adresování a přidělování adres. Dále bude popsána služba DNS a monitorování sítí. Po teoretickém úvodu bude následovat ukázka implementace protokolu IPv6 v koncové síti.

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 č. SGS11/124/OHK3/2T/13.

Seznam použitých zkratek

DAD	Duplicate Address Detection
DHCP	Dynamic Host Configuration Protocol
DHCPv6	Dynamic Host Configuration Protocol for Internet Protocol Version 6
DMZ	Data Management Zone
DNS	Domain Name System
EUI-64	Extended Unique Identifier-64
IANA	Internet Assigned Numbers Authority
IETF	Internet Engineering Task Force
IPv6	Internet Protocol Version 6
ISP	Internet Service Provider
LAN	Local Area Network
LIR	Local Internet Register
MTU	Maximum Transmission Unit
ND	Neighbor Discovery
RA	Router Advertisment
RFC	Request for Comments
RIPE NCC	Réseaux IP Européens Network Coordination Centre
RIR	Regional Internet Registers
RS	Router Solicitation
SLAAC	Stateless Address Autoconfiguration
VPN	Virtual Private Network
WLAN	Wireless Local Area Network

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] ČEPA, L. Protokoly IP a ICMP verze 6. Access server [online]. 2009, roč. 7, č. 2009110004, [cit. 2012-05-15]. Dostupné z: http://access.fel.cvut.cz/view.php?cisloclanku=2009110004. ISSN 1214-9675
[3] ČEPA, L. Směrovaní a směrovací protokoly v IP síti verze 6. Access server [online]. 2010, roč. 8, č. 2010010002, [cit. 2012-05-15]. Dostupné z: http://access.fel.cvut.cz/view.php?nazevclanku=smerovani-a-smerovaci-protokoly-v-ip-siti-verze-6&cisloclanku=2010010002. ISSN 1214-9675
[4] ČEPA, L. Návrh směrování v síti s protokolem IP verze 6. Access server [online]. 2010, roč. 8, č. 2010050003, [cit. 2012-05-15]. Dostupné z: http://access.fel.cvut.cz/view.php?cisloclanku=2010050003. ISSN 1214-9675
[5] DEERING, S. – HIDEN, R. IP Version 6 Addressing Architecture [online]. c2006, [cit. 2012-05-16]. Dostupné z: http://www.ietf.org/rfc/rfc4291.txt
[6] DURAND, A. – HUITEMA, C. The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio [online]. c2001, [cit. 2012-05-17]. Dostupné z: http://www.ietf.org/rfc/rfc3194.txt
[7] LAMPA, P. – HAŽMUK, I. Pravidla přidělování IPv6 adres na VUT [online]. c2009, [cit. 2012-05-16]. Dostupné z: http://www.fit.vutbr.cz/CVT/ipv6/lib/exe/fetch.php?media=intro:pravidlaipv6doc.pdf
[8] PARK, S. – MADANAPALLI, S. – JINMEI, T. Considerations on M and O Flags of IPv6 Router Advertisement draft-ietf-ipv6-ra-mo-flags-00.txt [online]. c2004, [cit. 2012-05-17]. Dostupné z: http://tools.ietf.org/id/draft-ietf-ipv6-ra-mo-flags-00.txt