Jak funguje IPv6

Datagram má v IPv6 obvyklý základní tvar: začíná hlavičkami, za kterými pak následují nesená data. V porovnání s IPv4 však došlo v hlavičkách ke koncepční změně. Dříve byla jejich délka proměnlivá a jednotliví účastníci komunikace mohli připojovat další nepovinné volby podle potřeby. Hlavička obsahovala kontrolní součet, který bylo třeba znovu vypočítat na každém směrovači, jímž datagram prošel (protože se změnila přinejmenším položka TTL).

IPv6 naproti tomu standardní hlavičku minimalizovalo a omezilo její prvky jen na ty nejnutnější. Tato základní hlavička má konstantní velikost. Veškeré doplňující, nepovinné či příležitostně užívané údaje byly přesunuty do rozšiřujících hlaviček, které v datagramu mohou a nemusí být přítomny.

Tvar základní hlavičky vidíte na obrázku Přestože se adresy odesilatele a příjemce prodloužily čtyřikrát, celková délka základní hlavičky datagramu vzrostla ve srovnání s IPv4 jen dvojnásobně (z 20 B na 40 B, z toho 32 B zabírají adresy). Minimalismus je patrný na první pohled.

Položka Verze (Version) je obvyklým zahájením IP datagramu, která identifikuje verzi protokolu. Zde obsahuje hodnotu 6.

Za ní následuje osmibitová Třída provozu (Traffic class), která vyjadřuje prioritu datagramu či jeho zařazení do určité přepravní třídy. Cílem je, aby tato položka umožnila IP poskytovat služby se zaručenou kvalitou. V praxi ale tak daleko nejsme a v nejbližší době ani nebudeme. IP, a to ani ve verzi 6, neumí zaručit dopravní parametry, jako jsou přenosová rychlost, zpoždění či jeho rozptyl. Dovede však poskytovat tak zvané diferencované služby (differentiated services, diffserv). Jejich prostřednictvím mohou mít datagramy různé priority a odlišné způsoby zacházení, které vedou k jejich přednostnímu zpracování či naopak odkládání až po ostatních. Právě diferencované služby využívají pro přenos svých informací položku Třída provozu. Ve vlastní definici IPv6 není nijak blíže upřesněna, pouze se zde požaduje, aby implicitní hodnotou byla nula.

Dalších 20 bitů je věnováno Značce toku (Flow label). Koncepce toku je novinkou v IPv6 a stále ještě se trochu tápe, k čemu a jak ji využívat. V zásadě by jako tok měl být označován proud datagramů se společnými vlastnostmi (odesilatel, adresát, požadavky na vlastnosti spojení). Prostřednictvím identifikátoru (značky) a dvojice adres směrovač rychle rozpozná, že datagram je součástí určitého toku, což mu usnadní rozhodování o jeho dalším osudu (bude s ním naloženo stejně, jako s předchozími členy téhož toku). Jak již bylo řečeno, jedná se stále o experimentální půdu a pokusy o konkrétní využití teprve vznikají.

Délka dat (Payload length) nese údaj o délce datagramu. Přesně řečeno počet bajtů následujících za standardní hlavičkou. Z toho plyne, že základní hlavička se do této délky nepočítá, zatímco případné rozšiřující hlavičky ano. Jelikož je položka dvoubajtová, je maximální délkou 64 KB. Pomocí rozšiřující hlavičky Jumbo obsah popsané dále lze teoreticky vytvářet ještě delší datagramy, reálně je ale nikdo nikdy neviděl.

Další hlavička (Next header) obsahuje identifikaci, jaká hlavička či jaký druh dat následuje za standardní hlavičkou.

Maximální počet skoků (Hop limit) je náhradníkem dřívější životnosti datagramu (TTL). Průchod datagramu jedním směrovačem je považován za jeden skok. Odesilatel v této položce uvede, kolik takových skoků smí datagram maximálně absolvovat. Každý směrovač po cestě pak sníží hodnotu o jedničku. Dojde-li tím k vynulování položky, datagram bude zlikvidován a odesilateli se pošle ICMP zpráva o vypršení maximálního počtu skoků. Smyslem omezení je ochrana proti cyklům při směrování (zacyklený datagram nebude v síti strašit do nekonečna).

Závěrečnými dvěma položkami je dvojice IPv6 adres: Zdrojová adresa (Source address) a Cílová adresa (Destination address). Vzhledem k délce adresy v IPv6 zabírají tyto dvě položky 80 % rozsahu celé hlavičky.

Při srovnání s IPv4 je nejnápadnější absence tří informací: rozšiřujících voleb, kontrolního součtu a fragmentace. Rozšiřující volby byly nahrazeny obecnějším principem zřetězení doplňkových hlaviček. Obdobně údaje související s fragmentací byly přesunuty do těchto rozšiřujících hlaviček.

Zdaleka ne každý paket je totiž fragmentován a lze očekávat, že v IPv6 bude fragmentace ještě vzácnější než v současnosti. IPv6 totiž požaduje, aby infrastruktura pro jeho přenos dovedla přenášet pakety minimálně o délce 1280 B (MTU). Vzhledem k tomu, že drtivá většina koncových zařízení je dnes připojena prostřednictvím různých variant Ethernetu nebo Wi-Fi s MTU alespoň 1500 B, lze očekávat, že tato hodnota se usídlí téměř všude a fragmentace prakticky zmizí ze světa.

Kontrolní součet zmizel bez náhrady. Tuto službu typicky vykonává nižší vrstva síťové architektury (např. zmiňovaný Ethernet) a pokud došlo ke zkomolení při přenosu, datagram rovnou zahodí. Na úrovni IP by se jen duplikovala úspěšná kontrola. Vzhledem k tomu, že hlavička se mění v každém směrovači (klesá dosah datagramu), znamenalo by to zbytečné zpomalování.

Porovnání hlaviček IPv4 a IPv6 názorně představuje obrázek 2. V IPv4 datagramu jsou tmavě šedé položky, které byly (zpravidla v poněkud pozměněné podobě) převzaty do IPv6. Stejná čísla označují položky, které si navzájem odpovídají.

IP verze 6 používá odlišný způsob reprezentace rozšiřujících hlaviček než jeho předchůdce. Každá hlavička je nyní samostatným blokem a k jejich vzájemnému propojení slouží položka Další hlavička (Next header). Kód v ní obsažený identifikuje, jakého typu je hlavička, která následuje za tou stávající. Každá rozšiřující hlavička začíná položkou Další hlavička. Prostřednictvím těchto hodnot lze za sebe zřetězit hlaviček, co hrdlo ráčí.

Poslední z nich obsahuje v položce Další hlavička typ dat, která datagram nese. Zastupuje tak zároveň dřívější položku Protokol. Nejvýznamnější hodnoty shrnuje tabulka. První skupina v ní obsahuje hlavičky, jejichž implementace je podle RFC 8200 povinná. Ve druhé skupině jsou hlavičky nepovinné, následují kódy přiřazené přenášeným protokolům. Aktuální a kompletní seznam hodnot pro typy přenášených dat najdete na adrese: http://www.iana.org/assignments/protocol-numbers

Pokud tedy datagram neobsahuje žádné rozšiřující hlavičky, bude přímo jeho základní IPv6 hlavička obsahovat jako Další hlavičku identifikátor typu nesených dat. Tuto situaci ilustruje obrázek a). Na obrázcíh b) a c) můžete sledovat, jak se změní obsah položek Další hlavička, když datagramu přidáme rozšiřující hlavičky Směrování a Fragmentace.

Hlavními devizami koncepce hlaviček v IPv6 je pružnost a úspornost. Součástí datagramu jsou jen ty průvodní informace, které skutečně potřebuje. Rubem mince je, že zpracování kompletních hlaviček může ve složitějších případech představovat průchod relativně dlouhým řetězcem. Pokud by se mělo odehrávat v každém směrovači na cestě mezi odesilatelem a příjemcem, mohlo by to vést k nezanedbatelné degradaci výkonu.

Tento problém řeší IPv6 velmi jednoduše – doporučuje pro rozšiřující hlavičky následující pořadí:

Jeho cílem je, aby se informace zajímavé pro uzly, kterými datagram prochází, ocitly vpředu a hlavičky určené až pro koncového příjemce následovaly teprve za nimi. Pro průchozí směrovač jsou potenciálně zajímavé jen Volby pro všechny, které se smí vyskytnout jen bezprostředně za základní hlavičkou. Ničeho jiného si nemusí všímat. Jakmile vidí v Další hlavičce jiný kód než 0 (Volby pro všechny), ví, že může s analýzou datagramu skončit.

Ostatní rozšiřující hlavičky jsou zajímavé jen pro adresáta datagramu – ať už průběžného (pocházejícího z hlavičky Směrování ) či koncového. Průběžného adresáta zajímají jen první tři (volby pro všechny, volby pro cíl a směrování), zatímco koncového se týkají všechny.

Každá z rozšiřujících hlaviček by se měla objevit nanejvýš jednou. Výjimkou jsou volby pro cíl, které se mohou vyskytnout dvakrát – jednou před Směrováním a podruhé před Mobilitou.

RFC 8200 důrazně doporučuje dodržovat výše uvedená omezení, zároveň ale požaduje, aby byl adresát schopen se vyrovnat s libovolným pořadím hlaviček i jejich případným opakováním. Výjimkou z této benevolence jsou Volby pro všechny – pokud jsou přítomny, musí být hned na začátku řetězce.

Druhým striktním omezením je, že dojde-li k fragmentaci datagramu, musí být všechny rozšířující hlavičky obsaženy v prvním fragmentu. Velmi dlouhé řetězce hlaviček komplikovaly situaci firewallům a objevily se i snahy o jejich zneužití. Podrobnější zdůvodnění najdete v RFC 7112: Implications of Oversized IPv6 Header Chains.

Speciální význam má, pokud položka Další hlavička obsahuje hodnotu 59 (no next header). Ta signalizuje, že se jedná o poslední hlavičku, za kterou již nenásleduje vůbec nic. Takový datagram nenese žádná data. Pokud podle své délky obsahuje ještě nějaká data, musí být ignorována. Je-li datagram přeposílán dále, musí do něj předávající tato data zkopírovat beze změny.

Kromě Voleb pro všechny zpracovává hlavičky až adresát datagramu. Mezilehlá zařízení rozšiřující hlavičky nezpracovávají a nesmí je měnit. Výjimku představují Volby pro všechny, jimiž se naopak zabývá každé zařízení, jímž datagram prochází ^[1].

Při zpracování se hlavičky procházejí v tom pořadí, ve kterém jsou vloženy do datagramu. Zpracovávající stroj nesmí přeskakovat nebo si vybírat některé přednostně. Tím je zajištěna konzistence v případech, kdy by některá hlavička ovlivňovala ty následující.

Koncept zřetězení rozšiřujících hlaviček se výrazně liší od přístupu IPv4. Bylo s ním proto méně zkušeností a v praktickém provozu se projevily různé problémy. Týkají se například příliš přísně nastavených firewallů, které zahazovaly datagramy s neznámými typy rozšiřujících hlaviček a bohužel neznaly zdaleka všechny. Objevily se také útoky postavené na rozšiřujících hlavičkách, které vedly například k odmítnutí některých variant hlavičky Směrování.

IETF se snaží praktické zkušenosti promítat do specifikací a vyjasňovat problematická místa. Zde mám na mysli především RFC 7045: Transmission and Processing of IPv6 Extension Headers, které se zabývá zejména přepravou a zpracováním rozšiřujících hlaviček v mezilehlých strojích – směrovačích, firewallech a dalších zařízeních, která nejsou odesilatelem ani adresátem datagramu.

Obecně pro ně platí, že by složení rozšiřujících hlaviček nemělo ovlivňovat přepravu datagramu ^[2]. Od přepravujících strojů se neočekává, že budou analyzovat celý datagram včetně všech hlaviček. Měly by přezkoumat nezbytné minimum a paket odeslat.

Speciálním případem jsou firewally a další prvky, které naopak datagramy analyzují podrobně, často využívají i informace z protokolu transportní vrstvy, takže musí projít celým řetězcem až k neseným datům. V jejich případě RFC 7045 stanoví následující požadavky:

Firewall samozřejmě může datagram zahodit, pokud vyhodnotí určité jeho rozšiřující hlavičky a hodnoty v nich jako nebezpečné, ale nesmí to v případě standardních hlaviček udělat jen na základě toho, že daný typ nezná.

Pokud se týká hlaviček pro každého, ty by naopak měly být zpracovávány každým zařízením, jímž datagram projde. RFC 7045 ale upozorňuje, že vysokorychlostní směrovače a přepínače to často nedělají a vývojáři by s tím měli počítat.

K usnadnění zpracování rozšiřujících hlaviček přispívá i RFC 6564: A Uniform Format for IPv6 Extension Headers, které požaduje, aby nově definované rozšiřující hlavičky dodržovaly jednotný formát: v prvním bajtu Další hlavička, ve druhém délka této hlavičky v osmicích bajtů (bez úvodní osmice) a za ní následuje vlastní hodnota, jejíž strukturu a položky stanoví konkrétní specifikace. Jednotné zahájení usnadní a zrychlí zpracování a umožní zařízení jednoduše přeskočit hlavičku, která zde není podporována.

Zároveň je RFC 6564 velmi konzervativní ohledně přidávání typů rozšiřujících hlaviček. Jednoznačně dává přednost předávání doplňkových informací pomocí Voleb pro cíl. Vytváření nových typů rozšiřujících hlaviček a nových typů Voleb pro každého připouští jen v případě, kdy potřebné informace nelze předávat jiným způsobem. Jejich návrh to musí doložit. Bez výjimky pak zakazuje vytváření nových typů hlaviček, které by vyžadovaly zpracování všemi průchozími zařízeními.

Zajímavá a dost depresivní jsou měření průchodnosti datagramů s rozšiřujícími hlavičkami, která najdete v RFC 7872: Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World. Výsledky pocházejí z let 2014 a 2015 a vůbec nejsou lichotivé – přítomnost některé z rozšiřujících hlaviček zvýší pravděpodobnost zahození daného datagramu řádově o desítky procent. Například pakety obsahující fragmentační hlavičku nebyly doručeny zhruba ve třetině případů.

Tyto hodnoty jsou alarmující a je třeba se smířit s tím, že pokud odesilatel vloží do datagramu rozšiřující hlavičku, výrazně tím sníží jeho šanci na úspěšné doručení současným Internetem. Autoři RFC 7872 apelují na zlepšení situace, ale výsledkem může být i to, že programátoři se budou snažit posílání těchto hlaviček vyhýbat.

Podívejme se nyní podrobněji na tvar a význam existujících rozšiřujících hlaviček.

IPv6 zavádí dvě hlavičky obsahující volby: Volby pro všechny (hop-by-hop options, Další hlavička před nimi má hodnotu 0) a Volby pro cíl (destination options, předcházející Další hlavička má hodnotu 60).

Obě hlavičky mají společný tvar, který najdete na obrázku 4.

Význam položky Další hlavička jsem již vysvětlil. Délka dat obsahuje délku hlavičky v osmicích bajtů. Do délky se nepočítá prvních 8 bajtů, takže pokud má hodnotu 1, znamená to, že celá hlavička s volbami měří 16 B.

Položka Volby (Options) pak obsahuje vlastní volby. Ty mohou být zavedeny jako součást jednotlivých konkrétních mechanismů. Například v rámci podpory mobilních počítačů se objevila volba Domácí adresa.

Přehled doposud definovaných voleb najdete v tabulkách 2 a 3.

Samotná definice IPv6 obsahuje jen dvě: Pad1 a PadN. Slouží ke vkládání „vaty“ – volného místa, které má sloužit k lepšímu zarovnání ostatních prvků s přihlédnutím k hranicím čtyřbajtových slov. Jedná se o vycpávky, které nenesou žádnou aktivní informaci.

Pad1 vynechává 1 bajt. Tvar této volby je triviální: jedná se o jeden bajt s hodnotou 0, která identifikuje typ volby a zároveň říká, že to je vše.

PadN umožňuje vynechat dva a více bajtů. První bajt opět určuje typ volby a má hodnotu 1. Za ním následuje jeden bajt obsahující délku volby, do níž se první dva bajty nepočítají. Následují data uvedené délky, jejichž hodnoty jsou nulové. Chcete-li tedy vynechat celkem 6 bajtů, bude mít Délka dat hodnotu 4 a za ní budou následovat čtyři nulové bajty „dat“.

Všechny volby musí dodržovat jednotný tvar. Odpovídá tomu, který jste viděli u volby PadN. První bajt identifikuje, o jakou volbu se jedná. Za ním pak následuje Délka dat (do níž se nepočítají první dva bajty) a po ní data. Jejich strukturu musí definovat dokument, který zavede danou volbu.

V rámci Typu volby byl pevně předepsán význam nejvyšších tří bitů. První dva určují, co se stane s datagramem, pokud zpracovávající uzel dotyčnou volbu nezná. Za nimi následuje bit, který indikuje, zda se volba může měnit během průchodu sítí. Konkrétní hodnoty najdete v obrázku 2.5

Jednou z „opravdových“ voleb pro všechny je tak zvané Upozornění směrovače (router alert) definované v RFC 2711. Má za cíl upozornit každý směrovač po cestě, že tento paket nese data, která by jej mohla zajímat.

Volba najde uplatnění například v rezervačním protokolu RSVP, který posílá řídicí pakety pro alokaci kapacit po cestě. Tyto pakety jsou určeny všem směrovačům. Právě Upozornění směrovače může napovědět, že paket nese zajímavou informaci. Bez něj by směrovač musel prohlížet všechny datagramy a zkoumat, jakému protokolu vyšší vrstvy patří. Když by narazil na paket RSVP, zabýval by se jím podrobněji. V opačném případě by jej poslal dále po cestě k cíli.

Díky Upozornění směrovače lze rychle odlišit datagramy potenciálně zajímavé od těch, které se mají prostě předávat dál. Formát volby najdete na obrázku 6.

Obsahuje vlastně jedinou položku, která slouží k identifikaci protokolu, jehož data nese. Dosud definované hodnoty shrnuje tabulka 4.

Aby tato volba přinášela nějaký efekt, musí odpovídající protokol nařizovat její použití. Směrovač má právo ignorovat obsah všech datagramů, které nejsou adresovány jemu a neobsahují Upozornění směrovače. Chce-li určitý protokol získat jeho pozornost, musí k datagramu přihodit tuto volbu.

Upozornění směrovače s sebou nese i určitá bezpečnostní rizika. Jejich rozbor, ale zejména doporučení pro operátory sítí, jak s datagramy nesoucími tuto volbu zacházet, najdete v RFC 6398: IP Router Alert Considerations and Usage.

V RFC 8250: IPv6 Performance and Diagnostic Metrics (PDM) Destination Option byla zavedena volba pro příjemce označovaná zkratkou PDM, která je určena pro měření zpoždění a spolehlivosti přenosů. Obsahuje pořadová čísla paketů a časové rozdíly mezi odeslanými a přijatými pakety.

Standardně je datagram směrován podle své cílové adresy. Hlavička Směrování (Routing) umožňuje do tohoto procesu zasáhnout a předepsat jeden či několik bodů (IPv6 adres), jimiž musí datagram projít před doručením adresátovi. Motivace pro takové chování jsou různé, jak zanedlouho uvidíte.

IPv6 ponechává prostor pro zavedení různých typů směrovacích hlaviček. K jejich rozlišení slouží hodnota položky Typ směrování. Zatím byly definovány dva přesně popsané typy (0 a 2) a dva volné typy (hodnoty 253 a 254) určené pro experimentování se směrovacími mechanismy. Další informace o experimentálních typech najdete v RFC 4727, zde si jimi nebudu zabývat.

Typ 0 je starší, byl zaveden přímo v RFC 2460 jako součást definice jádra IPv6. Umožňuje předepsat datagramu určité body, kterými musí v daném pořadí projít. Zároveň slouží jako záznam, kterými z nich již prošel. Tyto „průchozí body“ nemusí následovat bezprostředně za sebou, mezi každými dvěma může datagram projít libovolným počtem směrovačů. Podobnou rozšiřující volbu nabízí i IPv4.

Funguje to tak, že se jako cílová adresa do datagramu vloží první průchozí bod. Když do něj datagram dorazí, přesune se jeho adresa do hlavičky Směrování jako hotová a cílem se stane další z průchozích bodů – a tak dál až do skutečného cíle.

Tento mechanismus je bohužel zneužitelný k útokům usilujícím o zahlcení přenosových tras. Útočník může nechat přepravovat datagramy sítí sem a tam a když navíc použije několik směrovacích hlaviček napěchovaných po okraj, může se datagram potulovat sítí velmi dlouho. Série takových datagramů dokáže v síti vytvořit datové toky s objemem mnohonásobně převyšujícím kapacitu útočníkova připojení ^[3], navíc i na velmi dlouhé trase.

Důsledkem bylo zrušení směrovací hlavičky typu 0 v RFC 5095: Deprecation of Type 0 Routing Headers in IPv6. Podle něj je cílový IPv6 uzel, který obdržel datagram s hlavičkou Směrování typu 0, povinen ji ignorovat, pokud je konečným cílem celého řetězce. V opačném případě musí datagram zahodit a ohlásit jej odesilateli jako chybný. Kromě toho se zde doporučuje datagramy s tímto typem hlavičky Směrování filtrovat na aktivních prvcích.

Typ 2 byl definován speciálně pro mobilitu. De facto se jedná o silné zjednodušení obecnějšího typu 0 s jedinou adresou. Když je mobilní uzel na cestách, má kromě své původní pevné adresy i adresu dočasnou, jež se mění podle sítě, ve které se právě nachází. Pokud přechází mezi buňkami, může se dočasná adresa během komunikace měnit. Aby nebyla narušena komunikace běžících programů, používá pro ni svou trvalou, tak zvanou domácí adresu.

Jeho partner pomocí směrovací hlavičky typu 2 stanoví, že koncovou adresou je pevná adresa mobilního uzlu, ale má se nejprve dopravit na jeho dočasnou adresu. Čili datagram je dopraven na aktuální dočasnou adresu, tam se nahradí cílová adresa hodnotou ze směrovací hlavičky a vyšším komunikačním vrstvám se data doručí, jako by přišla na trvalou adresu.

Směrovací hlavička typu 2 proto umožňuje uložit jen jedinou adresu (domácí adresu mobilního uzlu, jemuž je datagram určen). To výrazně omezuje její zneužitelnost. Formát této směrovací hlavičky najdete na obrázku 11.16 263 v kapitole o mobilitě, kde se dočtete i podrobnější informace o jejím fungování.

Každá z podřízených technologií, které IPv6 používá pro přepravu svých datagramů, má jistou maximální velikost paketů, které dokáže přenášet. Tato konstanta se označuje zkratkou MTU (Maximum Transmission Unit). Například nejpopulárnější Ethernet má MTU = 1500 B.

Cílem fragmentace je umožnit IPv6 přepravovat datagramy větší, než je MTU používaných technologií. Základní myšlenka je prostá: odesilatel rozloží datagram do několika dostatečně malých částí a příjemce z nich poskládá původní datagram.

Analogickou techniku používá i protokol IPv4, liší se však v několika důležitých detailech. Zatímco v IPv4 může datagram fragmentovat libovolný směrovač po cestě (kdykoli má být odeslán linkou, jejíž MTU je menší než velikost datagramu), v IPv6 fragmentuje výlučně odesilatel. Pokud má některý ze směrovačů odeslat datagram linkou s nedostačujícím MTU, zahodí jej a pošle odesilateli ICMP zprávu „příliš velký paket“, jejíž součástí je i MTU, které tento stav způsobilo. Druhou odlišností je, že zatímco IPv4 má všechny podklady pro fragmentaci zařazeny již do standardní hlavičky, IPv6 pro ni používá hlavičku rozšiřující a spíše se snaží, aby k fragmentaci vůbec nedocházelo.

Rozšiřující hlavička Fragmentace (Fragment) je identifikována kódem 44 v položce Další hlavička svého bezprostředního předchůdce. Její tvar vidíte na obrázku 7

Velikost je konstantní a kromě obvyklé Další hlavičky obsahuje tři informační položky.

Identifikace (Identification) slouží k rozpoznání, které fragmenty patří k sobě. Jedná se o 32bitové celé číslo, které je v rámci dané dvojice odesilatel–příjemce pokud možno jednoznačné. Původně se používalo prosté zvětšování jeho hodnoty, jenže se objevily různé druhy útoků, které zneužívaly předvídatelné identifikátory. Proto řada současných implementací dává přednost pseudonáhodným či kryptografickým metodám. Podrobněji se problematice věnuje RFC 7739: Security Implications of Predictable Fragment Identification Values.

Posun fragmentu (Fragment offset) říká, kam tento fragment patří. Jednotkou jsou osmice bajtů od začátku fragmentovatelné části původního datagramu (viz níže). A konečně příznak M (More fragments) signalizuje, zda je tento fragment poslední (hodnota 0) nebo za ním následuje další (hodnota 1).

Má-li dojít k fragmentaci, vymezí se v původním datagramu tři části:

Datagramy obsahující jednotlivé fragmenty jsou sestaveny následovně:

Příklad celého postupu vidíte na obrázku 9.

Odeslání datagramu o velikosti 1500 B skončilo příchodem ICMP zprávy ohlašující překročení MTU s hodnotou 1280 B. Dojde tedy k rozdělení původního paketu do dvou fragmentů, hodnoty podstatných položek v hlavičkách jsou v obrázku uvedeny.

Vzniklé fragmenty jsou jako samostatné datagramy odeslány adresátovi. Ten je posbírá a z údajů ve fragmentační hlavičce dokáže složit původní datagram: podle Identifikátoru pozná, které fragmenty patří k sobě, pomocí Posunutí určí správné pořadí a v kombinaci s Délkou dat zjistí případné chybějící části a konečně příznak M mu prozradí, zda má k dispozici všechny kousky.

Na základě těchto údajů příjemce poskládá původní datagram do podoby, kterou měl před fragmentací (tím zaniknou hlavičky Fragmentace jednotlivých částí) a ten pak dále zpracovává bez ohledu na to, že mu přišel po kouskách.

Fragmentace bohužel způsobuje řadu potíží a významně snižuje pravděpodobnost úspěšného doručení datagramu. Například firewally běžně zkoumají údaje transportního protokolu TCP nebo UDP, protože propouštějí jen povolené porty. Některé jsou nastaveny tak, že pokud datagram neobsahuje hlavičku transportního protokolu, zahodí jej. Ta je ovšem jen v prvním fragmentu. Popsaným typem firewallu projde vždy jen první fragment, zbývající jsou zahozeny a příjemce si původní datagram nikdy nesloží ^[4].

Další problém způsobuje zahazování ICMP zpráv, které se v Internetu stalo celkem běžným. Odesilatel se díky němu nemusí dozvědět, že paket neprošel a měl by jej rozdělit na menší.

A aby toho nebylo málo, fragmentaci lze zneužít k různým útokům. Řekněme, že v cestě je rozumný firewall, který sice kontroluje hlavičku transportní vrstvy, ale pokud propustí první fragment, povolí i jeho pokračování. Pak lze provozovat různé ošklivé triky, kdy útočník prvnímu fragmentu vloží do transportní hlavičky spořádané údaje, aby jej firewall propustil. Druhý fragment ponese ovšem nulový nebo velmi malý Posun a při skládání přepíše transportní hlavičku svého předchůdce nebo její část. Takto lze změnit porty, příznaky TCP, ledacos.

V reakci na triky s překrýváním fragmentů vzniklo RFC 5722: Handling of Overlapping IPv6 Fragments, které překrývání zakázalo. Odesilatel musí zajistit, že se fragmenty vzájemně nepřekrývají. A na druhé straně pokud příjemce zjistí, že se fragmenty přicházejícího datagramu překrývají, musí jej celý potichu zahodit.

Obecně je nejlepší se fragmentaci pokud možno vyhnout. Tím se dostáváme k velikosti datagramů.

Zvolit optimální velikost datagramů je docela tvrdý oříšek. Každý datagram navíc přináší určitou (byť malou) zátěž – musí mít své hlavičky, směrovače po cestě se musí rozhodovat, kudy jej poslat, a podobně. Ideálem je, aby datagramy byly pokud možno co největší, aby jich bylo co nejméně a snižovala se tak nadbytečná zátěž. Na druhé straně však musí být natolik malé, aby nikde po své cestě nepřekročily MTU a nedocházelo k fragmentaci.

O dosažení tohoto kompromisu se snaží algoritmus nazvaný objevování MTU cesty. Definuje jej RFC 8201: Path MTU Discovery for IP version 6.

Z pohledu teoretika nemá vůbec smysl mluvit o nějakých cestách v souvislosti s protokolem IP. Nabízí službu bez spojení, kdy je každý datagram směrován samostatně a nezávisle na ostatních. To znamená, že každý ze skupiny datagramů tvořících jeden soubor může dorazit k cíli jinou cestou. V praxi se však směrovací tabulky nemění příliš rychle a je vysoce pravděpodobné, že datagramy odeslané v krátkém časovém intervalu ke stejnému cíli budou putovat stejnou trasou. Na tomto pozorování ostatně stojí již letitý program traceroute.

Objevování MTU cesty má za cíl najít maximální velikost paketu, který lze poslat danému cíli. Postupuje jednoduše: nejprve pošle datagram, jehož velikost je rovna MTU rozhraní, kterým datagram odesílá. Celkové MTU jistě nemůže být větší. Pokud datagram úspěšně dojde, máme nalezeno MTU cesty.

Jestliže někde narazí na úsek s menším MTU, směrovač na jeho začátku datagram zahodí a pošle odesilateli ICMP zprávu „příliš velký datagram“. Její součástí je i hodnota MTU dotyčné linky. Odesilatel si příslušně zmenší svůj odhad MTU cesty a zkusí štěstí znovu s datagramem této velikosti. Celý proces se opakuje tak dlouho, dokud se datagramy nedostanou až k cíli.

Informace o MTU cesty bývá využívána například v protokolu TCP, který jí přizpůsobí velikost odesílaných segmentů a snaží se tak předcházet jejich fragmentaci.

Pokud komunikace trvá delší dobu, může dojít ke změně cesty, případně i několikanásobné. Hledání MTU se snaží s touto skutečností vyrovnat. Pokud MTU cesty poklesne, odesilatel na to přijde hned – obdrží ICMP zprávu o příliš velkém datagramu. O případném zvětšení se však touto cestou nedozví. Proto by měl čas od času zopakovat celý algoritmus hledání MTU, aby zjistil, zda aktuální hodnota není vyšší, než se domnívá. V RFC se požaduje, aby interval mezi těmito zkouškami byl minimálně 5 minut, doporučená hodnota je 10 minut.

Ostatně vzhledem k tomu, že MTU na linkách podporujících IPv6 má být alespoň 1280 B a doporučuje se používat 1500 B nebo více, lze očekávat, že MTU cesty bude zpravidla 1500 B a prakticky se nebude měnit. Klient nesmí zmenšit MTU cesty pod 1280 B. Pokud by některá technologie nedokázala přepravovat datagramy této velikosti, musí na úrovni linkové vrstvy zajistit kouskování a skládání paketů tak, aby pro IPv6 nabídla alespoň 1280 B.

Objevování MTU cesty lze používat i pro skupinové adresy. V tomto případě může dostat na jeden datagram celou řadu ICMP zpráv. Bude se chovat podle očekávání – použije nejmenší ohlášenou hodnotu.

Implementace popsaného algoritmu je autory IPv6 důrazně doporučena, není však povinná. Jedná-li se o minimalistickou implementaci IPv6 (např. v ROM přenosného zařízení), může používat hodnotu 1280 B, aniž by se pokoušela zjistit, zda skutečné MTU cesty není vyšší.

Jelikož je délka nesených dat v IPv6 datagramu ukládána do 16bitové položky, je maximální dosažitelnou hodnotou 65 535 bajtů. Jumbogramy poskytují nástroj, jak přepravovat ještě delší pakety. Nesetkaly se ovšem s reálným nasazením, proto byly z poslední verze požadavků na IPv6 uzel (RFC 8504) odstraněny a lze je považovat za opuštěné.

Rozšiřující hlavička Rychlý start (Quickstart) byla přidána experimentálním RFC 4782: Quick-Start for TCP and IP. Jeho cílem je zvýšit propustnost transportních protokolů, především TCP. Stroj zahajující komunikaci přidá do žádosti o navázání TCP spojení tuto hlavičku, v níž vyznačí přenosovou rychlost, jakou by rád používal.

Jedná se o volbu pro všechny, hlavičkou se tedy zabývají všechny směrovače po cestě a pokud některý z nich považuje navrženou přenosovou rychlost za příliš vysokou, sníží hodnotu na akceptovatelnou úroveň. Při příchodu do cílového stroje tedy hlavička obsahuje rychlost přijatelnou pro všechna zařízení na cestě mezi odesilatelem a příjemcem. Během komunikace je pochopitelně tato informace čas od času aktualizována. Vzhledem k tomu, že dotyčný protokol je experimentální a s vlastním IPv6 souvisí jen volně, nebudu mu zde věnovat větší pozornost.

Jedním z nových prvků IPv6 je koncepce toku. Idea je jasná: tok je proud datagramů, které spolu „nějak souvisí“. Často tok odpovídá transportnímu spojení (například TCP spojení mezi WWW klientem a serverem či IP telefonní hovor mohou být dobrými kandidáty pro tok), ale nemusí tomu tak nutně být.

Přestože se termín ve světě IPv4 nepoužívá, analogie toků zde existuje. Obvykle bývají identifikovány pěticí údajů:

Pokud jste někdy konfigurovali firewall, jistě vám tahle pětka je důvěrně známá. Typickým příkladem uplatnění de facto toku je stavový firewall, který povolí otevřít TCP spojení jen v jednom směru. Jakmile se tak stane, uloží si pětici uvedených údajů do paměti a po určitou dobu obousměrně propouští datagramy s příslušnými hodnotami, protože je považuje za součást otevřeného spojení (čili toku).

Problém je, že tři z pěti údajů patří do transportní vrstvy a nemusí být snadno dostupné. Dojde-li k fragmentaci datagramu, jsou transportní údaje obsaženy jen v prvním fragmentu. Při utajení pomocí hlavičky ESP se k nim prvky po cestě nedostanou vůbec, protože jsou zašifrovány a z principu věci je dešifrovat umí jen příjemce. Nebo sice jsou dostupné, ale cesta k nim vede dlouhou sekvencí rozšiřujících hlaviček a zbytečně zpracující zařízení zdržuje.

Proto se objevil koncept toků, který má pomoci identifikovat související datagramy snadno a rychle, jen pomocí údajů ze základní IP hlavičky. Výše zmíněnou pětici má nahradit trojice:

Problematika toků je dosud živá. Původní RFC 2460 ji neřešilo vůbec, odložilo definici na později. První krok na cestě k funkčním tokům učinilo RFC 3697: IPv6 Flow Label Specification, které definovalo pravidla pro zacházení se značkami toků v datagramech. Postupem času se objevila řada návrhů, k čemu všemu a jak by se dala Značka toku ze základní hlavičky využít. Jejich přehled najdete v RFC 6294: Survey of Proposed Use Cases for the IPv6 Flow Label. Obvykle však odporují některým pravidlům zavedeným v RFC 3697.

Na podzim 2011 pak vyšla nová generace dokumentů, které se snaží postrčit definici toků zase o něco dál. Zahrnuje RFC 6436: Rationale for Update to the IPv6 Flow Label Specification shrnující dosavadní zkušenosti a motivaci nové specifikace. Ta je obsažena v RFC 6437: IPv6 Flow Label Specification, jež nahrazuje RFC 3697.

Hodnota značky podle RFC 6437 nemá žádnou strukturu ani význam. Slouží čistě jako identifikátor. Pokud odesilatel nechce své datagramy značkovat, vloží do položky Značka toku nulu, která signalizuje, že paket není zařazen do žádného toku. Nula je jedinou hodnotou, pro niž specifikace zavádí speciální význam.

Přidělení značky toku má na starosti odesilatel datagramu. Svou vlastní značku typicky dostane každý datový tok se stejnou pěticí základních identifikačních údajů, již jsem zmínil výše. Nicméně není to předepsáno pevně, rozhodnutí je na odesilateli.

Specifikace požaduje, aby hodnoty značek byly rovnoměrně rozděleny v celém dostupném prostoru a aby se nedaly předem odhadnout. Důvodem těchto požadavků je snaha o jejich snadnou použitelnost při hašování a omezení bezpečnostních rizik. Jako vhodné generátory značek dokument zmiňuje hašovací funkci nebo generátor pseudonáhodných čísel. Naopak výslovně nedoporučuje sekvenční přiřazování, kdy každá další značka je o jedničku větší než poslední použitá.

Během přepravy sítí se značka nesmí měnit a musí být příjemci doručena se stejnou hodnotou, jakou jí přidělil odesilatel. Z tohoto obecného pravidla ovšem existují dvě výjimky. První je motivována bezpečností: Pokud by některý ze směrujících strojů dospěl k závěru, že se někdo snaží zneužít značky k vytvoření tajného informačního kanálu, smí do nich zasáhnout. Druhou výjimkou je nulová značka. Jestliže se odesilatel rozhodl datagram neznačkovat, může to za něj udělat některý ze směrovačů ^[5]. Jakmile došlo ke vložení nenulové hodnoty, musí už dále zůstat neměnná. Způsob využití při přepravě není pevně definován. Existují v zásadě dvě cesty: může být bezstavový, kdy si přepravující prvky neukládají žádné informace, jež by při doručování značkovaných datagramů využívaly, či stavový, který se právě o takové informace opírá. Návrh dává přednost bezstavové variantě, zatímco o stavové se zmiňuje jen okrajově.

Podpora toků není povinná ^[6]. Průchozí zařízení může brát na tok zřetel, nebo nemusí. V tom případě však musí informace související s tokem ignorovat a nijak do nich nezasahovat. Tím je zajištěno, že nic nepokazí strojům, které jsou za ním a věci rozumějí.

Na novou specifikaci toků navazuje RFC 6438: Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels s příkladem možného využití Značky toku k rozkládání zátěže mezi několik alternativních cest vedoucích ke stejnému cíli. RFC 7098: Using the IPv6 Flow Label for Load Balancing in Server Farms později přišlo s návrhem využít značky toků k distribuci paketů v rámci serverové farmy.

V praxi se zatím lze se značkováním toků setkat jen zcela ojediněle, valná většina datagramů v Internetu nese nulovou značku. Nová generace dokumentů představuje určitý posun vpřed, ale na reálné používání značek si nepochybně ještě dost dlouho počkáme.