IPv6
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Reklama

IPv6IPv6

 

IPv6

Google       23. 12. 2006       12 192×
Reklama
Reklama
Logo 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 × 1038 (neboli 1632)!

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í.

Hlavička IPv6 datagramu
8 bitů 8 bitů 8 bitů 8 bitů
Verze IP Třída dat
(Traffic class)
Identifikace toku dat
(Flow label)
Délka dat
(Payload length)
Další hlavička
(Next header)
Počet hopů
(Hop limit)
Adresa odesílatele
(Source IP address)
128 bitů
Adresa příjemce
(Destination IP address)
128 bitů
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

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ě.

Struktura IPv6 adresy
16 bitů 16 bitů 16 bitů 16 bitů 64 bitů
veřejná část místní část
2001
(prefix RIR)
SubTLA
(poskytovatel)
NLA
(zákazník)
SLA
(podsíť)
rozhraní
(EUI-64)

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.

Zdroj: http://ipv6.cz/

×Odeslání článku na tvůj Kindle

Zadej svůj Kindle e-mail a my ti pošleme článek na tvůj Kindle.
Musíš mít povolený příjem obsahu do svého Kindle z naší e-mailové adresy kindle@programujte.com.

E-mailová adresa (např. novak@kindle.com):

TIP: Pokud chceš dostávat naše články každé ráno do svého Kindle, koukni do sekce Články do Kindle.

Hlasování bylo ukončeno    
0 hlasů
Google
(fotka) Martin ŽákAutor je korektorem e-zinu, dělá v (X)HTML, CSS, PHP a X(S)LT a zajímá se o HW.
Web    

Nové články

Obrázek ke článku Hackerský kongres přiveze v září do Prahy špičky světové kryptoanarchie

Hackerský kongres přiveze v září do Prahy špičky světové kryptoanarchie

Hackerský kongres HCPP16 pořádá od 30. září do 2. října nezisková organizace Paralelní Polis již potřetí, a to ve stejnojmenném bitcoinovém prostoru v pražských Holešovicích. Letos přiveze na třídenní konferenci přes 40 většinou zahraničních speakerů – lídrů z oblastí technologií, decentralizované ekonomiky, politických umění a aktivismu. Náměty jejich přednášek budou také hacking, kryptoměny, věda, svoboda nebo kryptoanarchie.

Reklama
Reklama
Obrázek ke článku ICT PRO školení zaměřené nejenom na ICT

ICT PRO školení zaměřené nejenom na ICT

Dovolte, abychom se představili. Jsme zaměstnanci společnosti ICT Pro, profesionálové v oblasti poskytování komplexních ICT služeb. Neboli služeb spojených s informačními a komunikačními technologiemi, které dnes - ve 21. století - tvoří  nedílnou součást běžného provozu všech moderních firem.

loadingtransparent (function() { var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true; po.src = 'https://apis.google.com/js/plusone.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s); })();
Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032016 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý