Toky v IPv6

Nyní vyšlo RFC 3697, které záležitosti kolem toků upřesňuje.

Značka toku, která slouží k jeho identifikaci, má v IPv6 hlavičce vyhrazen prostor o velikosti 20 bitů. Přiznám se, že když jsem v definici IPv6 datagramu (RFC 2460) četl, že toky jsou stále experimentální a budou definovány později, byl jsem krajně skeptický. Text vzbuzoval silný dojem, že se autoři sice shodli na myšlence „toky by mohly být užitečné“, ale nemají příliš přesnou představu o jejich reálné implementaci. Něco podobného jsme zažili už u IPv4, jehož položka Type Of Service (TOS) nebyla pořádně definována dodnes.

Mou skepsi podporovalo i několikaleté mlčení, kdy kýžená definice mechanismů pro práci s toky stále nepřicházela a ani se nezdálo, že by nějak intenzívně vznikala. Nyní je vše jinak. V březnu vyšlo RFC 3697 - IPv6 Flow Label Specification. Přestože stále ponechává některé otázky otevřené, přináší do oblasti toků znatelný pokrok.

Základní rozhodnutí je, že o zařazení do toku rozhoduje odesílatel. Výlučně na něm záleží, kterým datagramům přiřadí jaké značky toků a podle toho stanoví jejich příslušnost k tokům. Během přepravy pak musí být značka toku zachována a hodnota stanovená odesílatelem musí nezměněna doputovat až k příjemci.

Toky jsou rozlišovány podle trojice údajů: IP adresa odesílatele, IP adresa příjemce a značka toku. Shodují-li se všechny tři, patří datagramy ke stejnému toku. Podstatné je, že všechny tři údaje pocházejí z IP hlavičky, není třeba brát v potaz informace z vyšších vrstev (např. ve světě IPv4 je snaha vytvářet toky podle pětice zahrnující IP adresy odesilatele a příjemce, transportní protokol a jeho porty; poslední dva údaje však pocházejí z hlavičky transportního protokolu).

RFC 3697 doporučuje, aby odesílatel zařadil do nového toku každé transportní spojení a proud aplikačních dat, pro něž zatím neexistuje vhodný tok. Měl by to dělat i v případě, že sám žádné speciální zpracování podle toků nepodporuje. Vhodným značkováním ale umožní, aby jím vytvořené datagramy tokově zpracovávali další účastníci komunikace. Pokud se rozhodne datagram nezařadit do žádného toku, musí jeho značce toku přidělit nulovou hodnotu.

Dokument nenařizuje žádný specifický způsob, jak značky toků přiřazovat. Pouze obecně mluví o tom, že odesílatel by měl mít pro jejich přiřazování určitou konzistentní metodu - například sekvenčně nebo pseudonáhodně. Příjemce ale nesmí žádnou takovou metodu na straně odesílatele předpokládat a cokoli odvozovat z výpočtů založených na značkách toků. Na straně odesílatele musí mít nadřazené vrstvy (transportní a aplikační) možnost poručit si značku toku pro svůj provoz. Síťová vrstva by pro tento účel měla poskytnout odpovídající API, včetně přístupových práv pro jeho použití.

Tok je omezen i časově. Pokud po dobu 120 s nepřijde žádný jeho datagram, je považován za ukončený. Jestliže datagram se stejnou trojicí >odesilatel, příjemce, značka toku< dorazí později, bude již považován za příslušníka jiného toku.

Aby bylo možné s toky efektivně pracovat, musí o nich účastníci komunikace udržovat jisté stavové informace. Mechanismy pro jejich vytvoření a správu jsou však podle osvědčeného schématu ponechány k definici pozdějšímu dokumentu. RFC 3697 pro ně stanoví jen nejzákladnější požadavky (stavové informace musí být možné vymazat a mechanismus se musí dokázat vzpamatovat z nesplnitelného požadavku).

Značná pozornost je v dokumentu věnována otázkám bezpečnosti, řeší se především otázky možného zcizení provozu změnou značky toku. Tato problematika a její dopady se dost podobají falšování IP adres, ovšem s určitými rozdíly: značka toku není chráněna mechanismy IPsec, falšování samotné značky toku může být zajímavé pro nehodnou aplikaci na koncovém stroji, která díky tomu uchvátí cizí provoz.

Koncepce toků představuje další pokus o nalezení Svatého grálu všech síťařů - škálovatelného vysokorychlostního způsobu dopravy datagramů s definovanými vlastnostmi. Zatím jsou toky příliš syrové na to, abychom mohli předvídat jejich budoucnost. Nicméně vše nasvědčuje, že to s nimi IETF myslí vážně.