Protokoly IP a ICMP verze 6

Autor: L. Čepa, J. Hájek <cepaluka(at)fel.cvut.cz?cc=hajekj3(at)feld.cvut.cz>, Pracoviště: České vysoké učení technické v Praze, FEL, Téma: Aplikace, sítě a služby, Vydáno dne: 12. 11. 2009

Článek popisuje základy síťového protokolu IP verze 6 (IPv6) a podpůrného protokolu ICMP verze 6 (ICMPv6). Je prvním ze seriálu článků, které popisují návrh směrování v síti IP verze 6.


Protocols IP and ICMP Version 6 - Abstract

The article describes briefly the basics of Internet Protocol version 6 (IPv6) and Internet Control Message Protocol version 6 (ICMPv6). It is the first article of series describing a project of routing in IP network version 6.

Keywords: IPv6; datagram; ICMPv6; addresses


Úvod

Krátící se adresní prostor Internetového protokolu IP verze 4 byl důvodem pro vznik „IP nové generace“. Do roku 1996 bylo vydáno několik RFC dokumentů definujících IP verzi 6 (IPv6). I přes tenčící se adresní prostor je IPv4 protokol v roce 2009, díky postupným úpravám, stále hlavním Internetovým protokolem. Avšak s rostoucí popularitou služeb, které vyžadují přímou komunikaci (IP telefonie, videokonference, ICQ a další) a se zamýšleným rozvojem bezdrátové sítě WiMAX jako mobilní sítě 4G, která počítá s mobilitou IPv6, by se IPv6 [2] mohla dočkat většího rozšíření. V současnosti větší poskytovatelé Internetu ISP (Internet Service Provider) pozvolna přechází na IPv6 na páteřních spojích.
Pro návrh směrování v IPv6 je třeba se seznámit s teoretickými základy protokolu IPv6, IPv6 adresami a protokolem ICMPv6. Je nutné se seznámit se směrovacími protokoly pro IPv6, s jejichž pomocí se navrhne směrovací politika dané sítě.

Vlastnosti IP verze 6

Hlavní změnou IPv6 je daleko větší adresní prostor než má IPv4. Ten vychází z délky adresy 128 bitů, což je čtyřnásobek IPv4. K dispozici je tedy 3,4x1038 (2128) adres. IPv6 disponuje třemi typy adres, a to individuální (unicast), skupinovou (multicast) a výběrovou (anycast). Má jednotné adresní schéma, jak pro Internet, tak i pro vnitřní sítě. Má hierarchické směrování v souladu s hierarchickou adresací a podporuje služby se zajištěnou kvalitou služby QoS. IPv6 byla navržena pro zvýšenou bezpečnost, ve které je zahrnuto šifrování, autentizace a sledování cesty k odesílateli. Umožňuje automatickou konfiguraci a optimalizaci pro rychlostní směrování. V dnešní době je asi největší výhodou oproti IPv4 podpora mobility pro přenosné počítače.
IPv6 je rozšířením IPv4. Většina přenosových a aplikačních vrstev protokolů vyžaduje malé nebo žádné změny pro funkčnost s IPv6. Výjimkou jsou části aplikací, které pracují se síťovými adresami. Největší změnu prodělal formát datagramu.

Formát datagramu

Základem specifikace IPv6 je formát datagramu [1], [2], [3], který se skládá ze základního záhlaví, viz obr. 1, za nímž následují přenášená data. Délka informačního pole může být maximálně 65 535 B. Oproti IPv4 neobsahuje nepovinné informace, kontrolní součet a záhlaví má konstantní velikost. Celková velikost základního záhlaví je dvojnásobně větší oproti záhlaví IPv4. Z 20 B vzrostla na 40 B a z toho 32 B zabírají adresy.

IPaICPM_01

Obr. 1 Základní záhlaví datagramu IPv6

Zřetězení záhlaví

U IPv6 jsou ostatní nepovinné a rozšiřující informace přesunuty do samostatných rozšiřujících záhlaví [1], [2], [3]. Tato záhlaví se mohou umísťovat za základním záhlavím. Každé rozšiřující záhlaví je samostatným blokem a k  propojení jednotlivých záhlaví slouží položka Další záhlaví. Tímto způsobem lze zřetězit libovolný počet záhlaví. Různé situace zřetězení záhlaví jsou zobrazeny na obr. 2. Při zřetězení více rozšiřujících záhlaví je důležité jejich pořadí, které je pevně stanoveno, viz tab. 1. Cílem je, aby zajímavé informace pro uzly (směrovače) byly vpředu a rozšiřující záhlaví, určené až pro koncové uživatele, poslední.

IPaICPM_02

Obr. 2 Zřetězení záhlaví datagramu

Pořadí záhlaví
1.základní záhlaví IPv6
2.volby pro všechny (hop-by-hop options)
3.volby pro cíl (destination options) - pro první cílovou adresu
4.směrování (routing)
5.fragmentace (fragment)
6.autentizace (authentication)
7.šifrování obsahu (encapsulating security payload)
8.volby pro cíl - pro konečného příjemce datagramu
9.mobilita (mobility)

Tab. 1 Pořadí záhlaví

Volby

Jsou zavedeny dvě záhlaví Volby pro všechny prvky v cestě a Volby pro cíl. Obě mají stejný tvar, viz obr. 3, kde položka volby obsahuje vlastní volby [1], [2], [3], viz tab. 2. Volby Pad1 a PadN slouží ke vkládání „vaty“ (volného místa) pro lepší zarovnání ostatních prvků.

Volby pro všechnyVolby pro cíl
Pad1Pad1
PadNPadN
Upozornění směrovačeDomací adresa
Rychlý start
Jumbo obsah

Tab. 2 Volby pro všechny prvky v cestě a Volby pro cíl

IPaICPM_03

Obr. 3 Rozšiřující záhlaví voleb

Skutečnou volbou je volba Upozornění směrovače (Router alert) [1], [2], [3]. Jedná se o volbu pro všechny a upozorňuje směrovač po cestě, že paket nese zajímavá data. Pokud datagramy neobsahují Upozornění směrovače a nejsou určeny jemu, má právo obsah takových datagramů ignorovat.
Volba Rychlý start [2] má za cíl zvýšit propustnost transportních protokolů, především TCP. Stroj, který zahajuje komunikaci, přidá do žádosti o navázání TCP spojení rozšiřující záhlaví volby, v němž vyznačí požadovanou přenosovou rychlost. Jedná se o volbu pro všechny, a proto všechny směrovače na cestě se jí budou zabývat. Pokud by se nějakému směrovači nelíbila požadovaná přenosová rychlost, sníží její hodnotu na akceptovatelnou úroveň. Při příchodu k danému cíli tedy záhlaví obsahuje přenosovou rychlost akceptovatelnou pro všechny směrovače na cestě mezi odesilatelem a příjemcem. Tato rychlost se během komunikace aktualizuje.
Volba Jumbo obsah [2], [3] umožňuje vytvářet datagramy o délce 65 535 B až 4 294 967 295 B. Patří mezi volby pro všechny a proto se jí budou zabývat všechny směrovače po cestě.
Volba Domácí adresa byla zavedena v souvislosti s podporou mobility [2], [3].

Směrování

IPv6 ponechává volný prostor pro zavedení různých typů směrování. Pro jejich rozlišení slouží položka typ směrování, viz obr. 4. Prozatím byly přesně definovány typy 0 a 2. Existují i dva volné typy 253 a 254 [3], [4].

Směrování typu 0

Záhlaví Směrování, viz obr. 4, umožňuje datagramu předepsat určité body, kterými musí v daném pořadí projít anebo slouží jako záznam, kterými již prošel. Průchozí body nemusí následovat bezprostředně za sebou. Může být mezi nimi i více směrovačů. Pokud má datagram projít určitými směrovači po cestě k cíli, musí se jako první cílová adresa v záhlaví Směrování uvést adresa prvního směrovače na cestě. A poté následují postupně všechny adresy směrovačů. V položce zbývá segmentů je zapsán celkový počet těchto směrovačů a zároveň i odděluje prošlé adresy od ještě nenavštívených adres. Hodnota nula udává, že datagram dorazil do svého cíle určení [1], [2], [3]. Na obr. 5 je znázorněn princip směrování a změny adres v záhlaví datagramu.

IPaICPM_04

Obr. 4 Formát rozšiřujícího záhlaví Směrování typu 0

IPaICPM_05

Obr. 5 Princip směrování a změny adres v záhlaví datagramu

Tento typ směrování má své výhody i nevýhody. Jednou z výhod je možnost určit přesnou cestu datagramu a tím ověřit funkčnost tohoto spojení. Tedy směrování typu 0 bylo zavedeno pro testování dosažitelnosti mezi libovolnými adresami [3] [4]. K výhodám a zároveň i k nevýhodám se řadí možnost průchodu přes NAT. Neveřejná adresa se uvede jako koncový cíl a veřejná adresa směrovače provádějící překlad adres NAT se uvede jako mezilehlá. Obdobným způsobem lze proniknout i přes firewall. Hlavní nevýhodou tohoto směrování je možnost zahlcení přenosových tras. V datagramu lze zřetězit libovolný počet rozšiřujících záhlaví Směrování a tím zajistit, že se daný datagram bude v síti pohybovat velmi dlouho. Toto může vést k vytvoření datových toků s obrovským objemem. Tento problém se řeší tím [5], že cílový uzel IPv6, který obdržel datagram s nenulovým počtem zbývajících segmentů, je povinen tento datagram zahodit a informovat odesilatele, že je chybný. Pokud je počet zbývajících segmentů nulový, uzel IPv6 je povinen tento datagram ignorovat. Zároveň se doporučuje datagramy s tímto typem záhlaví Směrování filtrovat na aktivních prvcích sítí.

Směrování typu 2

Tento typ směrování byl speciálně definován pro mobilitu [3], [4]. Jde o zjednodušenou verzi typu 0. Mobilní uzel má dvě adresy. Pevnou adresu a dočasnou adresu, která se mění podle sítě, ve které se mobilní uzel nachází. Pomocí směrovacího záhlaví typu 2 se stanoví, že koncová adresa je pevná adresa mobilního uzlu. Ale datagram je nejdříve doručen na dočasnou adresu, kde je postupem podobným směrování typu 0 nahrazena cílová adresa hodnotou ze směrovacího záhlaví a vyšším komunikačním vrstvám se datagram předává, jako by byl doručen na trvalou adresu. Směrování typu 2 omezuje počet zřetězení směrovacích záhlaví pouze na jedinou adresu (domácí adresu mobilního uzlu, kterému je datagram určen), což omezuje její zneužitelnost, která je možná u směrování typu 0.

Fragmentace

Každá technologie pro přenos datagramů má svoji maximální velikost paketů, které dokáže přenést. Tuto velikost udává MTU (Maximum Transmission Unit). Fragmentace umožňuje přenášet datagramy větší, než je tato MTU. Pokud je datagram větší, než MTU přenosové cesty, odesilatel jej rozloží na dostatečně malé pakety, které se přenesou sítí. A příjemce na druhé straně z těchto paketů poskládá původní datagram.
U IPv4 mohl datagram fragmentovat kterýkoliv směrovač na cestě. U IPv6 může fragmentovat pouze odesilatel. To znamená, že pokud je kdekoliv na cestě úsek s menší MTU, než je MTU úseku předcházejícího směrovače, směrovač datagram zahodí a informuje o tom odesilatele ICMP zprávou. U IPv4 je fragmentace součástí základního záhlaví, kdežto u IPv6 se používá rozšiřující záhlaví Fragmentace [1], [2], [3], viz obr. 6. Navíc je snahou u IPv6, aby k fragmentaci vůbec nedocházelo.

IPaICPM_06

Obr. 6 Formát rozšiřujícího záhlaví Fragmentace

Vzhledem k fragmentaci se datagram dělí na dvě části:

Velikost datagramu

Velikost odesílaných datagramů úzce souvisí s fragmentací. Každý datagram navíc zatěžuje síť. V ideálním případě by měl být datagram co největší, čímž by snižoval zatížení sítě, ale zároveň i dostatečně malý, aby nikde po cestě nepřekročil MTU. Jinak by docházelo k fragmentaci. K dosažení těchto cílů slouží algoritmus objevování cesty MTU [1], [3], [6].

Toky

Toky jsou novým prvkem v IPv6 [1], [3], [7]. Definice toku je následující: „Tok je proud datagramů, které spolu nějak souvisí.“ Jde například o TCP spojení mezi WWW klientem a serverem nebo o IP telefonní hovory (transportní spojení), ale vždy tomu tak nemusí být. Cílem toku je usnadnit a zrychlit směrování datagramů na směrovačích. V datagramech je obsažena informace k rozpoznání jednotlivých toků a instrukce pro zacházení s nimi. Datagram je přiřazen do určitého toku na základě IP adresy odesilatele, cílové IP adresy a značky toku. Všechny tři prvky dohromady tvoří jednoznačný identifikátor toku. Značku toku přidělí odesilatel a během cesty se nesmí měnit. Související datagramy směřující ke stejnému cíli by měly být opatřeny stejnou značkou. Odesílatel musí vést záznamy o přidělených značkách, aby nedošlo k použití jedné značky pro toky směřující k rozdílným cílům. Hodnota značky je libovolná a měla by se přidělovat náhodně. Jedinou zakázanou hodnotou je nula, která signalizuje, že datagram nepatří k žádnému toku. Podpora toků není povinná. V případě, že směrovač toky nepodporuje, musí je ignorovat a nezasahovat do nich.

Adresy IP verze 6

Existují tři druhy adres [1], [8]:

Oproti IPv4 se u IPv6 nevyskytují všesměrové (broadcast) adresy. Jejich funkčnost přebírají adresy skupinové. Adresy IPv6 jsou přidělovány obdobně jako u IPv4 síťovým rozhraním, nikoliv síťovým zařízením. IPv6 povoluje rozhraním více libovolných adres různých druhů. IPv6 adresa je dlouhá 128 bitů a standardní zápis tvoří osm skupin po čtyřech číslicích šestnáctkové soustavy, které vyjadřují hodnoty 16 bitů dlouhých částí adresy. Tyto části se navzájem oddělují dvojtečkami. Příklad IPv6 adresy:

A91C:0000:0000:28F6:1984:0000:0000:1224

Důležitou vlastností adres IPv6 je možnost jejich zkrácení. Místo 0000 lze psát jednu nulu. V každé čtveřici se mohou vynechat počáteční nuly a několik nulových skupin za sebou lze nahradit zápisem „::“ (dvě dvojtečky). Konstrukci „::“ lze v každé adrese použít jen jednou, jinak by nebylo možné jednoznačně určit její původní podobu. Koncové nuly ve čtveřicích vynechat nelze. Po použití těchto pravidel lze adresu uvedenou výše zapsat třeba jako:

A91C::28F6:1984:0:0:1224

Prefix

Prefixy se začaly používat v IPv4 pod názvem Classless Interdomain Routing (CIDR) a vyjadřují příslušnost k určité síti nebo podsíti. Všechna rozhraní v rámci jedné sítě mají stejný prefix (začátek adresy). Zápis prefixu je následující:

IPv6_adresa/délka_prefixu, kde délka_prefixu určuje, kolik bitů od začátku adresy je považováno za prefix.

Příklad 60 bitů dlouhého prefixu:

A91C:0:0:1234::/60

Adresní prostor

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

prefixvýznam
::/128nedefinovaná adresa
::1/128smyčka (loopback)
fc00::/7unikátní individuální lokální
fe80::/10individuální lokální linkové
ff00::/8skupinové adresy
ostatníindividuální globální

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

Globální individuální adresy

Jedná se o nejdůležitější typ adres, které identifikují svého uživatele v celém Internetu. Jsou celosvětově jednoznačné a lze je poznat podle prefixu 001 (zapsáno binárně). Formát globální individuální adresy [1], [9] je uveden na obr. 7 a příklad adresy je na obr. 9.

IPaICPM_07

Obr. 7 Formát globální individuální adresy

Identifikátor rozhraní - modifikované EUI-64

IPv6 adresy, které vyžadují identifikátor rozhraní, jej odvozují ze standardu IEEE EUI-64 [3]. Tento standard definuje podobu identifikátoru rozhraní o délce 64 bitů. Jestliže má rozhraní již přidělený EUI-64 identifikátor, tak se do IPv6 adresy převezme s menší úpravou. Předposlední bit v nejvyšším bajtu identifikátoru je příznakem globality a podle modifikované EUI-64 má hodnotu 1. Ve standardu EUI-64 je tomu naopak. Hodnota 0 představuje příznak celosvětově jednoznačné adresy a hodnota 1 adresu lokální. Na obr. 8 je znázorněno vytvoření IPv6 identifikátoru rozhraní z celosvětové adresy MAC (Media Access Control). Mezi třetí a čtvrtý bajt MAC adresy se vloží 16 bitů s hodnotou fffe a dojde k obrácení příznaku globality podle modifikované EUI-64.

IPaICPM_08

Obr. 8 Vytvoření EUI-64 z MAC adresy

IPaICPM_09

Obr. 9 Globální individuální adresa

Lokální adresy

Původní lokální místní adresy byly zakázány a nahrazeny konceptem unikátních lokálních adres s prefixem fc00::/7 [1], [9] Dle doporučení RFC 4193 mají tyto adresy vysokou pravděpodobnost jedinečnosti, což je dáno identifikátorem o délce 40 bitů vygenerovaným pseudonáhodným algoritmem. Tento typ adres není v globálním Internetu směrován a adresy nejsou žádným způsobem centrálně registrovány či koordinovány.

Skupinové adresy

Skupinové adresy [1], [10] identifikují soubor síťových rozhraní, které jsou příjemci zprávy. Typickým příkladem použití je distribuce obrazového a zvukového signálu v reálném čase (videokonference, rozhlasové či televizní vysílání). Tyto adresy začínají hodnotou ff (11111111 binárně), viz obr. 10.

IPaICPM_10

Obr. 10 Skupinová adresa

V případě skupinových adres je důležitý dosah adres [1], [3], který udává, jak daleko mohou být členové skupiny od sebe. Jedná se o čtyřbitovou položku, která umožňuje definovat až 16 možností dosahu. Skupinová adresa se nesmí vyskytnout na místě odesilatele datagramu a nesmí být obsažena ani v jeho rozšiřujícím směrovacím záhlaví. A kromě toho nelze přidělovat adresy ff0x:0:0:0:0:0:0:0, které jsou rezervovány. Typů skupinových adres je celá řada a patří mezi ně skupinové adresy vycházející z individuálních adres [11], skupinové adresy pro SSM (Source Specific Multicast) [11], skupinové adresy obsahující RP (Rendezvous Point) [12] a skupinové adresy vycházející z rozhraní [13].
Některým skupinovým adresám je přiřazen speciální význam. Jedná se o adresy pro všechny uzly v rámci jednoho rozhraní ff01::1, nebo v rámci fyzické sítě ff02::1. Právě tyto adresy nahrazují všesměrové adresy (broadcast). Dalším typem jsou adresy pro všechny směrovače v rámci jednoho rozhraní ff01::2, fyzické sítě ff02::2, nebo místa ff05::2. Poslední typem jsou adresy vyzývaného uzlu. Tyto adresy mají jednotný tvar ff02:0:0:0:0:1:ffxx:xxxx, kde poslední trojice bajtů se převezme z hledané adresy. Adresy vyzývaného uzlu se používají při objevování sousedů [1], [3], což je obdoba ARP (Address Resolution Protocol) protokolu u IPv4.

Výběrové adresy

Výběrové adresy [1], [14] jsou ze stejného adresního prostoru jako individuální adresy. Proto pokud se rozhraní přiděluje výběrová adresa, je nezbytné v konfiguraci oznámit, že se jedná o výběrovou adresu. Všechna rozhraní, která mají nakonfigurovanou výběrovou adresu, lze zařadit do tzv. obalové sítě (skupiny sítí), v níž jsou obsažena. Tuto síť lze charakterizovat například prefixem P. Pokud všichni členové výběrové skupiny patří do stejné podsítě, tak P prefix bude prefixem této podsítě. Uvnitř této podsítě se musí šířit kompletní informace o výběrové skupině a každému členu musí být přidělena samostatná směrovací položka, která je distribuována všem směrovačům v této podsíti s prefixem P. Mimo tuto podsíť není třeba výběrovou adresu rozlišovat a může být zahrnuta do agregovaného bloku adres. Důvod vzniku a možné využití výběrových adres:

Výběrové adresy lze směrovat obvyklými způsoby. Potom počítač, který se zapojil do výběrové skupiny, ohlásí tuto událost některému směrovači v síti a ten se postará o distribuci této informace. V nejhorším případě mohou být příslušníci výběrové skupiny rozptýleni tak, že společný prefix má nulovou nebo zanedbatelnou délku. V tomto případě by se výběrová adresa přidala do globální směrovací informace, což by vedlo k nárůstu velikosti směrovacích tabulek páteřních směrovačů. Z tohoto důvodu jsou globální výběrové adresy zakázány nebo silně omezeny.

Výběr adresy IPv6

Rozhraní IPv6 se přiděluje několik adres. Proto je definována minimální množina adres, ke které se musí každý uzel hlásit [1]. S tímto vznikl problém, kterou adresu IPv6 použít pro danou komunikaci. K tomuto účelu je definovaný algoritmus pro volbu adres [15]. Má dvě sady pravidel. První se vztahuje na volbu zdrojové adresy a druhá se vztahuje na volbu cílové adresy [3], [16].

Multihoming

Multihoming řeší problém s připojením k Internetu i v případě, že dojde k výpadku spojení s provozovatelem připojení ISP [3], [17], [18]. Jde tedy o zákaznickou síť, která je připojena k několika ISP, a při výpadku spojení s primárním ISP, dojde k přesměrování provozu na sekundárního ISP. Multihoming využívají především poskytovatelé služeb, jejichž výpadek by byl kritický a znamenal by ztrátu, ať už finanční nebo poškození jména.

Protokol ICMP verze 6

Protokol ICMP (Internet Control Message Protocol) je součástí sady protokolů Internetu. Používá se pro ohlašování chybových stavů, testování dosažitelnosti a pro výměnu některých provozních informací. Implementace tohoto protokolu je povinná v každém zařízení, které podporuje IP. Verze pro IPv6 je definována v [19], kde jsou specifikovány pouze základy, jako je formát paketu a základní druhy zpráv. Ostatní zprávy ICMPv6 jsou definovány v různých dokumentech RFC. Zprávu ICMPv6, viz obr.11, nese datagram IPv6. Za tělem zprávy následuje část datagramu, která vyvolala odeslání zprávy ICMP.

IPaICPM_11

Obr. 11 Formát zprávy ICMPv6

Zprávy ICMP jsou děleny na chybové a informační. Současná verze ICMP definuje čtyři chybové zprávy:

Mezi informační zprávy patří echo a odpověď na echo [19], které využívá program ping. Další informační zprávy jsou dotaz a odpověď [20], které umožňují získat základní informace o uzlech (jméno uzlu, adresu IPv4 nebo IPv6) a slouží spíše pro správu sítě. Ostatní informační zprávy jsou definovány v různých dokumentech RFC. Jedná se například o zprávy členství ve skupinách [21], výzva, ohlášení směrovače či souseda, přesměrování a objevování sousedů [22] a zprávy týkající se mobility [23], [24].
ICMPv6 má oproti ICMPv4 implementovány bezpečnostní mechanismy [3]. U IPv4 mohlo dojít k zneužití zpráv ICMP a tím k omezení funkčnosti sítě. Ve zkratce, cílové zařízení se zahltilo mnoha zprávami ICMP a ostatní provoz neměl šanci projít. Bezpečnostní mechanismy využívají následující implementace:

Novinkou ICMPv6 je rozšíření [3], které umožňuje do těla zprávy vložit další informace a pozměňuje některé existující zprávy, jako jsou nedosažitelnost či vypršení životnosti. Rozšíření se přidá za konec těla zprávy ICMPv6 do nevyužité čtyřbajtové položky, viz obr. 12.

IPaICPM_12

Obr. 12 Rozšíření zprávy ICMPv6

Závěr

Problematika protokolu IP verze 6 je rozsáhlá, proto jsou zde popsány pouze základní vlastnosti, skladba adres a zprávy protokolu ICMP verze 6. Další navazující článek se bude zabývat směrováním a vlastnostmi směrovacích protokolů, a to především OSPFv3 a BGP4+. Dále budou popsány atributy směrovacího protokolu BGP4+, pomocí kterých se stanovuje směrovací politika autonomních oblastí.

Tento příspěvek vznikl v souvislosti s řešením výzkumného záměru MSM6840770038.

Literatura

[1] ČEPA, L. Návrh směrován v IP síti verze 6. (Diplomová práce) Praha: ČVUT, 2009. 110 s.
[2] DEERING, S. - HIDEN, R. Internet Protocol, Version 6 (IPv6) Specification [online]. c1998, [cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc2460.txt.
[3] SATRAPA, P. IPv6. CZ.NIC, z. s. p. o., 2008. 357 s. ISBN 978-80-904248-0-7.
[4] FENNER, B. Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers [online]. c2006, [cit. 2009-04-23]. Dostupné z: http://tools.ietf.org/html/rfc4727.
[5] ABLEY, J. - SAVOLA, P. - NEVILLE-NEIL, G. Deprecation of Type 0 Routing Headers in IPv6 [online]. c2007, [cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc5095.txt.
[6] McCANN, J. - DEERING, S. - MOGUL, J. Path MTU Discovery for IP version 6 [online]. c1996, [cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc1981.txt.
[7] RAJAHALME, J. - CONTA, A. - CARPENTER, B. - DEERING, S. IPv6 Flow Label Specification [online]. c2004, [cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc3697.txt.
[8] DEERING, S. - HIDEN, R. IP Version 6 Addressing Architecture [online]. c2006, [cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc4291.txt.
[9] DEERING, S. - HIDEN, R. - NORDMARK, E. IPv6 Global Unicast Address Format [online]. c2003, [cit. 2009-04-23]. Dostupné z: http://tools.ietf.org/html/rfc3587.
[10] DEERING, S. - HIDEN, R. IPv6 Multicast Address Assignments [online]. c1998,[cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc2375.txt.
[11] HABERMAN, B. - THALER, D. Unicast-Prefix-based IPv6 Multicast Addresses [online]. c2002, [cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc3306.txt.
[12] SAVOLA, P. - HABERMAN, B. Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address [online]. c2004, [cit. 2009-04-23]. Dostupné z: http://tools.ietf.org/html/rfc3956.
[13] PARK, J-S. - SHIN, M-K. - KIM, H-J. A Method for Generating Link-Scoped IPv6 Multicast Addresses [online]. c2006, [cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc4489.txt.
[14] ABLEY, J. - LINDQVIST, K. Operation of Anycast Services [online]. c2006, [cit. 2009-04-23]. Dostupné z: http://tools.ietf.org/html/rfc4786.
[15] DRAVES, R. Default Address Selection for Internet Protocol version 6 (IPv6) [online]. c2003, [cit. 2009-04-23]. Dostupné z: http://tools.ietf.org/html/rfc3484.
[16] MATSUMOTO, A. - FUJISAKI, T. - HIROMI, R. - KANAYAMA, K. Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules [online]. c2008, [cit. 2009-04-23]. Dostupné z: http://tools.ietf.org/html/rfc5220.
[17] ABLEY, J. - BLACK, B. - GILL, V. Goals for IPv6 Site-Multihoming Architecture [online]. c2003, [cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc3582.txt.
[18] HUSTON, G. Architectural Approaches to Multi-homing for IPv6 [online]. c2005, [cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc4177.txt.
[19] CONTA, A. - DEERING, S. - GUPTA, M. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [online]. c2006,[cit. 2009-04-23]. Dostupné z: http://tools.ietf.org/html/rfc4443.
[20] CRAWFORD, M. - HABERMAN, B. IPv6 Node Information Queries [online]. c2006, [cit. 2009-04-23]. Dostupné z: http://www.rfc-editor.org/rfc/rfc4620.txt.
[21] CRAWFORD, M. Transmission of IPv6 Packets over Ethernet Networks [online]. c1998, [cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc2464.txt.
[22] NARTEN, T. - NORDMARK, E. - SIMPSON, W. - SOLIMAN, H. Neighbor Discovery for IP version 6 (IPv6) [online]. c2007, [cit. 2009-04-23]. Dostupné z: http://www.rfc-editor.org/rfc/rfc4861.txt.
[23] JOHNSON, D. - PERKINS, C. - ARKKO, J. Mobility Support in IPv6 [online]. c2004, [cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc3775.txt.
[24] ARKKO, J. - DEVARAPALLI, V. - DUPONT, F. Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents [online]. c2004,[cit. 2009-04-23]. Dostupné z: http://www.ietf.org/rfc/rfc3776.txt.