IPv6

Jak už jsem v úvodu naznačil, IPv6 (někdy se označuje jako IP nové generace – IP Next Generation; IPng) má řešit některé nedostatky. Tím hlavním je nedostatek adres. Zpočátku se sice zdálo, že rámec adres je dostatečně bohatý, s rozvojem Internetu se však nároky zvyšovaly a zjistilo se, že až tak vysokým počtem nedisponuje. Časem se objevilo řešení – schovat celou síť za jeden počítač. V praxi to vypadá tak, že v jedné síti je třeba deset počítačů, každý má privátní IP. Jako jejich brána slouží NAT, který jako jediný musí mít veřejnou adresu. Tímto systémem se dají adresy šetřit, nicméně k některým činnostem (např. provoz veřejného serveru) je veřejná adresa potřeba.

Jiným krátkodobým řešením je systém CIDR. Ten umožňuje pohybovat se mezi pevnými prefixy IPv4 adresy. Sice se s těmito berličkami dá nějaký ten pátek vydržet, ale není to ideální.

Další vadou je podpora mobilních zařízení. Ta se totiž velice těžce schovávají za NAT. Přenosná zařízení bohužel většinou vyžadují přímé spojení. Proto by nový protokolo měl přinést širokou škálu adres, ideálně by se nikdy nemělo stát, že už by nebyla volná ani jedna. Můj názor však je, že s dalším vývojem Internetu požadavky zase stoupnou.

Z ostatních novinek bych jmenoval ještě automatickou konfiguraci, podporu zajištění úrovně služeb (QoS), fragmentaci paketů a podporu bezpečnosti na úrovni protokolu. Samozřejmě se počítá s jednoduchým přechodem ze stávajícího protoklu na nový.

Historie

Specifikace RFC 760 protokolu IPv4 byla vydána v lednu 1980. V září následujícího roku však byla nahrazena RFC 761. IPv6 byl specifikován RFC 1883 v prosinci 1995. Rozdíl tedy činí patnáct let. V Internetu je to ohromná doba, proto tolik změn.

Úvodní verze IPv6 popsaná v RFC 1883 je však již zastaralá, protože aktuální verze je specifikována RFC 2460. Tato verze byla přijata IETF v roce 1994. Změn moc nebylo, za zmínku stojí snad jen drobná změna v záhlaví datagramu, kde se čtyři bity převedly z pole značka toku do pole třída dat (viz níže). Ostatní změny jsou minoritní. V článku budu popisovat RFC 2460

V roce 1998 byla vydána druhá generace definic (RFC 2460). V současnosti se revidují významné dokumenty a dokončují se některé chybějící.

Existoval samozřejmě také protokol ve verzi 5, ale nebyl určen k širšímu použití. Byl to experimentální streamingový protokol určený k přenosu hlasu, videa a audia.

Zápis adres

Metoda zápisu je jiná než u IPv4. Adresy se zapisují čísly v šestnáctkové soustavě. Většina adres má osm skupin po čtyřech číslicích oddělených dvojtečkami pro větší přehlednost.

Adresa tedy může vypadat třeba takto (je to mimochodem adresa serveru OpenBSD.cz):

3ffe:80ee:038f:0000:0000:0000:0000:0002

Zápis se dá i zjednodušit. Pokud adresa obsahuje v jedné skupině čtyři nuly, může se vynechat. Pokud je takových skupin za sebou více, nahrazují se stejným způsobem, avšak za podmínky, že zápis bude jednoznačný. Také třeba zápis 0001 se dá nahradit zápisem 1 (vynechávají se nuly). Proto následující zápisy jsou shodné.

ca01:0000:0000:0000:0000:0000:0000:010d

ca01:0:0:0:0:0:0:10d

ca01::10d

Tyto zápisy ale shodné nebudou, jelikož zjednodušení prvního zápisu není jednoznačné.

2001:0000:0000:0000:0000:31af:0000:58fa

2001::31af::58fa

Jistě uznáte, že zápis je poměrně složitý a ne každý uživatel jej pochopí. Ani se s tím nepočítá, ostatně pro běžné uživatele je tu DNS :-).

Adresování

Délka adresy je oproti stávajícím čtyřnásobná (přešlo se tedy z 32bitových na 128bitové). To znamená, že celkový počet adres je 3,4 × 10³⁸ (neboli 16³²)!

Existují tři skupiny adres. Dělí se podle toho, čemu je adresa přiřazena:

Unicast

Adresa je přiřazena jednomu síťovému rozhraní

Anycast

Adresa je přiřazena několika síťovým rozhraním a paket je doručen na kterékoliv z nich (většinou na to nejbližší). Využití vidím u velkých serverů, kde uživatel odešle požadavek s obecnou adresou a některý server jej zpracuje. Anycastové adresy jsou přidělovány z prostoru unicastových adres.

Multicast

Adresa je přiřazena skupině zařízení a paket je dopraven na všechna tato zařízení. Příliš se to nepoužívá, problémem je neexistence routovacích protokolů, které by směrování takových paketů umožnily, a možnost zahlcení sítě v případě, že by došlo k cyklu.

Oproti současným adresám tedy zmizely broadcast adresy, jejichž úkol přebraly obecnější multicast adresy. Jednotlivé druhy adres se od sebe rozlišují pomocí prefixů. Doposud nebylo definováno mnoho těchto prefixů, časem snad přibudou další:

::/128

Nespecifikovaná adresa, nahrazuje 0.0.0.0

::1/128

Loopback adresa, nahrazuje 127.0.0.1

2000::/3

Globální unicastové adresy

ff00::/8

Multicastové adresy

fc00::/7

Unikátní unicastové adresy

fe80::/10

Lokální unicastové linkové adresy

fec0::/10

Lokální unicastové místní adresy

1111 1110 10

Lokální unicastové adresy na jednom segmentu (nahrazují 192.168.xxx.xxx)

1111 1110 11

Lokákní unicastové adresy v jedné organizaci (nahrazují 10.xxx.xxx.xxx a 172.16.0.0 – 172.32.255.255)

::xxxx:xxxx

IPv4 adresa při tunelování IPv4 přes IPv6

::ffff:xxxx:xxxx

IPv4 adresa pro počítače nepodporující IPv6

Číslo za lomítkem vyjadřuje délku prefixu (počítáno zleva).

Adresy můžeme dělit také z hlediska dosahu:

Linkové (link-local scope)

Platí jen na konkrétním drátě nebo v jednom virtuálním tunelu. V případě ethernetu se odvozuje z HW adresy síťové karty. Tuto adresu máme definovanou.

Místní (site-local scope)

Platí v rámci určité sítě, např. v rámci jedné organizace, školy… Jde tedy o adresy, které si můžeme vymyslet.

Globální (global scope)

V případě, kdy chceme komunikovat i vně své sítě, se místní adresy nehodí. Třeba veřejnému serveru bychom měli zřídit i globální adresu (oficiálně Aggregatable Global Unicast Address). Tuto adresu si samozřejmě nevymyslíme.

Formát datagramu

Filozoficky je pohled na stavbu datagramu zcela nový. Ze záhlaví datagramu byl vyňat kontrolní součet a některá málo využívaná pole byla přesunuta ze základní hlavičky do nepovinných dalších hlaviček. Základní hlavička teď tedy obsahuje pouze nejnutnější položky. V IPv4 tomu bylo jinak, hlavička měla nepovinné části, takže její délka byla proměnlivá.

Záhlaví IPv6 datagramu má 40 B. Může se to zdát hodně, ale 32 B náleží jen adresám odesílatele a příjemce. Po záhlaví následují rozšíření.

Verze IP

Toto pole obsahuje hodnotu 6, protože se jedná o protokol ve verzi 6.

Třída dat (někdy také třída provozu)

Pole třída dat se skládá v nové verzi z osmi bitů. Má vyjadřovat prioritu datagramu nebo jeho zařazení do určité přepravní třídy. Cílem je umožnění služby QoS. Význam hodnot se sice dá vyhledat, (najdete rozdělení hodnot od 0 po 15), ale podle oficiálního zdroje nebyl definován význam. Očekává se, že se určí experimenty z oblasti diferencovaných služeb. V současné době se požaduje uvádět jako implicitní hodnotu nulu (nula má vyjadřovat nespecifikovaná data).

Identifikace toku dat (značka toku)

Značce toku náleží 20 bitů. Koncepce toku je naprosto originální myšlenkou, která však ještě nebyla přesně definovaná. Jako tok by se měl označovat proud datagramů, které mají stejné vlastnosti (odesílatel, příjemce). Hodí se to například při posílání velikých souborů, kdy se zpracuje první datagram a směrovač si zapamatuje výsledek. U dalšího datagramu si pak prohlédne paměť a pokud tam najde údaje pro daný tok, neřeší úlohu směrování. Paměť směrovače se maže každých 6 vteřin, aby nedocházelo ke kolizím – server se restartuje a náhodou dostane stejnou identifikaci pro zcela jiný tok. 6 vteřin proto, že je nemožné (aspoň se s tím nepočítá) restartovat systém za tak krátkou dobu.

Značka toku se ale dá využít i jiným způsobem. Směrovač nemusí odesílat datagramy postupně, ale může je vybírat tak, aby zajistil dohodnutou šířku pásma. Samozřejmě tady neplatí šestivteřinový limit.

U IPv4 existovalo pole Typ služby (Type of Service, ToS), ale nikdy se přesně nedefinovalo.

Délka dat

Informaci o velikosti datagramu bez základního záhlaví podává tato položka. Standardně může datagram dosahovat velikosti až 65 535 bajtů (toto pole má totiž dva bajty), ovšem volbou „ohromný datagram“ v další položce záhlaví říkáme směrovači, že posíláme ještě větší datový objem.

Další hlavička

Obsahuje identifikaci, jaká hlavička nebo druh dat následuje za základní hlavičkou. V IPv4 se toto pole označovalo jako Protokol. U IPv6 to mohou být tyto typy:

Rozšiřující hlavičky

Číslo	Značka	Protokol	Reference
0	HOPOPT	IPv6 Hop-by-Hop Option Informace pro směrovače	RFC 1883
43	IPv6-Route	Routing Header for IPv6 Směrovací informace	Deering
44	IPv6-Frag	Fragment Header for IPv6 Záhlaví fragmentu	Deering
50	ESP	Encap Security Payload Bezpečnostní hlavička	RFC 2406
51	AH	Authentication Header Autentizační hlavička	RFC 2402
59	IPv6-NoNxt	No Next Header for IPv6 Žádná další hlavička nenásleduje	RFC 1883
60	IPv6-Opts	Destination Options for IPv6 Jiná volba	RFC 1883
62	CFTP	CFTP Hlavička pro komunikaci s mobilními zařízeními	CFTP, HCF2
4	IP	IP in IP (encapsulation) Protokol IP	RFC 2003
6	TCP	Transmission Control Protocol Protokol TCP	RFC 793
8	EGP	Exterior Gateway Protocol Protokol EGP	RFC 888, DLM1
17	UDP	User Datagram Protocol Protokol UDP	RFC 768, JBP
45	IDRP	Inter-Domain Routing Protocol Protokol IDRP (někdy jen IRP)	Sue Hares
46	RSVP	Reservation Protocol Protokol RSVP (někdy RRP)	Braden
58	IPv6-ICMP	ICMP for IPv6 Protokol ICMP	RFC 1883

Počet hopů

Vlastně identická položka s TTL (Time To Live) z IPv4. Využití:

1. Zahazování zatoulaných datagramů – při průchodu směrovačem se toto pole sníží o jedničku a při dosažení nuly se datagram zahodí a bude o tom uvědoměn odesílatel.
2. Zjištění nejkratší cesty – adresnému oběžníku se odešle datagram s maximálním počtem hopů 1. Pokud nedojde odezva, odešle se datagram s dvojkou atd.

V IPv4 se toto pole označovalo jako Protokol.

Další hlavičky

Pole další hlavičky může odkazovat přímo na TCP (nebo i UDP) segment nebo na jiný protokol, ale může taky ukazovat na další rozšiřující hlavičky. V takovém případě má i odkazovaná hlavička pole Další hlavičky, hlavičky se tudíž řetězí. Řetěz ovšem obsahuje – narozdíl od IPv4 – jen ty hlavičky, které jsou nezbytné.

Za polem další hlavička je ještě délka hlavičky, která specifikuje délku této hlavičky. Toto není u základního záhlaví (má vždy délku 40 bajtů) a u záhlaví fragmentu (má vždy 8 bajtů).

Informace pro směrovače (Volby pro všechny)

Hlavička informace pro směrovače musí následovat přímo za IPv6 hlavičkou. Obsahuje informace, které musí zkoumat každý router, kterým paket projde. Informace je složena tří polí: typ (1 B), délka (1 B) a vlastní sdělení.

Pole typ má 1 bajt, to je 8 bitů:

aabccccc

Bity aa říkají, co se má stát, pokud směrovač volbu nezná. Mohou nabýt čtyři hodnoty:

00

Pokud se volba nerozpozná, bude ignorována a směrovač bude pokračovat ve zpracování datagramu.

01

Pokud se volba nerozpozná, datagram bude zahozen.

10

Pokud se volba nerozpozná, datagram bude zahozen a směrovač uvědomí odesilatele pomocí protokolu ICMP.

11

Pokud se volba nerozpozná, datagram bude zahozen a směrovač uvědomí odesilatele pomocí protokolu ICMP, pokud nebude datagram adresován adresnému oběžníku (unicast).

Bit b směrovači říká, jestli může volbu změnit:

0

Volba nesmí být změněna.

1

Volba se smí změnit.

Bity ccccc tvoří „zbytek“ pole. Slouží k jednoznačné identifikaci možnosti, i když se ve specifikacích uvádí, že k identifikaci slouží i tři předchozí bity.

Přehled některých voleb

Typ desít- kově	Typ šestnáct- kově	Bity aa	Bit b	Bity ccccc	Název	Reference
0	0	00	0	00000	Pad1 (Výplň dlouhá 1 b)	RFC 1883
1	1	00	0	00001	PadN (Výplň dlouhá n bajtů)	RFC 1883
194	C2	11	0	00010	Jumbo Payload (Rozsáhlý – „ohromný“ – datagram)	Jumbogram
195	C3	11	0	00011	Nepřiřazeno	—
4	4	00	0	00100	Tunnel Encapsulation Limit	Tunnel
5	5	00	0	00101	Router Alert	RFC 2711
201	C9	11	0	01001	Home Address	RFC 3775
138	8A	10	0	01010	Endpoint Identification	Charles Lynn

Pole délka udává délku volby. Nepleťte si to s polem Délka hlavičky, to je totiž bezpodmínečně součástí každé další hlavičky, toto pole délka je však věcí hlavičky 0, tj. Informace pro směrovače.

Pokud bude délka volby kratší než 4 bajty, budou použity výplně. 4 bajty umožňují za použití volby ohromný datagram posílat datagramy o velikosti až 4 GB, namísto 64 kB, které nabízí základní záhlaví. V takovém případě se délka v základním záhlaví přehlíží (nastaví se na nulu) a používá se délka uvedená v této volbě.

Pokud je voleb více, nepoužije se více hlaviček, vše se naskládá do jedné.

Struktura hlavičky Informace pro směrovače

Směrovací informace (Směrování)

Struktura adres

Pozastavme se nad unicast adresami, ty totiž adresují jednotlivé počítače.

Velikost adresního prostoru je mnohonásobně vyšší, což komplikuje směrování. Kapacita routerů totiž není nekonečná (běžně bývá kvůli nesprávné agregaci v páteřních routerech kolem 60 000 záznamů) a adresy se musí vhodně organizovat, aby se sem routovací tabulky vešly a aby bylo zpracování požadavku dostatečně rychlé. To v praxi znamená, že každá ucelená síť (např. jeden provider a všichni jeho zákazníci) má jeden prefix.

U IPv6 adresy tvoří vždy prvních 48 bitů prefix sítě (ten se ještě dále větví na 3 bloky po šestnácti bitech). Dalších 16 bitů identifikuje SLA a konečně posledních 64 bitů identifikuje jednotlivý počítač (rozhraní) v rámci podsítě.

Agregace adres by měla ovlivnit především prefix sítě, tedy veřejnou topologii. V současné době se jako prefix regionálních registrátorů (RIR) užívá 2001::/16. Providerovi pak náleží dalších 16 bitů (SubTLA). Ten má možnost rozdělit své zákazníky v šestnácti následujících bitech (NLA).

Modifikované EUI-64

Jak jste si všichni jistě všimli, polovina adresy je věnována identifikaci rozhraní. Někomu se může zdát, že je to zbytečně moc. Nabízí to ovšem obrovské plus v podobě automatického získání adresy. Jednoduše se vygeneruje za použití ethernetové adresy.

Říká se tomu EUI-64. Spočívá v tom, že se vezme ethernetová 48bitová adresa. Do té se vloží 16 bitů o hodnotě fffe, čímž vznikne 64bitová adresa. Jak prosté :-)

Ale aby to nebylo až tak jednoduché, tak IPv6 využívá modifikovanou verzi tohoto standardu.

To znamená, že tento chaos se ještě obohatí o nastavení sedmého nejvyššího bitu. Ten se změní na 1 v případě globálně jednoznačné adresy, hodnotu 2 dostane, pokud jde o lokálně jednoznačnou adresu. Je to složité, takže si ukážeme příklad:

MAC adresa:

00:04:76:47:8e:81

Upravený formát EUI-64:

0204:76ff:fe47:8e81

Automatická konfigurace

IPv6 si zakládá na tom, že se jednoduše připojíte a o žádná nastavení se nestaráte. Tohoto se dosáhne dvěma možnými postupy: stavovou a bezstavovou konfigurací.

Stavová konfigurace

Žádná převratná novinka, funguje to i dnes. Počítač zašle dotaz a DHCP server mu v odpovědi sdělí všechny potřebné parametry.

Bezstavová konfigurace

Možná se budete divit, ale tato technologie nepřebírá ůdaje ze žádného serveru. Využívá funkci Neighbour Discovery. Každý směrovač v určitých časových úsecích rozesílá po síti „ohlášení“. To sděluje ostatním síťovým prvkům informace o sobě (posílá prefixy adres a informuje, jestli může služit jako implicitní směrovač). Takhle se směrovač hlásí v síti. Stejně tak informace získává (tyto informace mu zasílají ostatní směrovače). Ohlášení si může vyžádat hned po připojení a kdykoliv jindy. Z ohlášení získá data o síti. Ta by mu ale byla ještě k ničemu. Musí totiž sestavit celou svou adresu. Proto přidá ještě 64 bitů, které vychází z ethernetové adresy (viz výše), čímž vlastně vygeneruje svou kompletní adresu. Zároveň si vytváří seznam směrovačů, kterým bude zasílat pakety, které míří ven ze sítě. Je-li jich k dispozici více, bude je směrovač střídat. Časem si směrovací tabulku doladí na základě upozornění, která směrovače odesílají, pokud nebyl použit správný směrovač.

Neighbour Discovery zjišťuje nejen IP adresy, ale i související fyzické adresy. Vlastně nahrazuje ARP.

Celé to zní krásně, ovšem jednu chybu to přece jenom má – počítači se nedostane žádná informace o DNS.