Vlákno názorů k článku IPv6 Mýty a skutečnost, díl V. - Zjednodušené hlavičky od ondra.novacisko.cz - Vzhledem k tomu, že IP protokol tu existuje...

Vzhledem k tomu, že IP protokol tu existuje proto, aby bylo možné doručit balíček dat z jednoho konce zeměkoule na druhý mi přijde hlavičky a pravidla těhle datagramů jako hodně složitá. Chápu, že se má myslet na všechny eventuality, protože sítě, kterými paket prochází mohou být různé, ale podle mě toho řeší až moc.

Zajímavé je také to, že zatímco dynamicky dlouhou adresu IPv6 jasánci v zásadě odmítají, protože je náročné pro směrovač ji zpracovat (přestože by stačilo, aby z dynamicky dlouhé adresy vyzvedli jen stále stejně dlouhý prefix, který je zajímá, už jim nevadí dynamická délka hlavičky, byť se to maskuje jako rozšířená hlavička.

Ono jde spíše o to, že typicky se směrovač (bez firewallingu) podívá do na next-header a pokud tam neuvidí nic, co by bylo určeno pro směrovače (a tyto hlavičky jsou nejdříve - hop-by-hop resp. routing), tak další hlavičky nemusí řešit. Řešit je samozřejmě bude firewall.

Možná tu funkčnost chtělo v textu lépe vysvětlit, aby to pochopili i laici.

No jo, jenze dneska i ten nejblbejsi router umi aspon ACL, kde je mozne zadavat TCP/UDP porty. Pokud tohle neumi vyresit v hardware tak je to docela problem.

Ano, protokol 4. vrstvy mohl být uveden v hlavičce, zřejmě tam není proto, aby byla zarovnána na 32 bajtů a délka byla co nejmenší.

Je třeba si z pohledu firewallingu a zpracování hlaviček HW uvědomit, v kterém roce návrh IPv6 vznikl. Na rozdíl od dalších věcí nemůžete do struktury základní IPv6 hlavičky sáhnout a výrazně ji měnit.

Leda by se předefinovala část "Flow label" na tento význam, ale i tak nastává problém, že je to snadno falšovatelné, leda by povinně cíl detekoval podvod a takové datagramy rovnou zahazoval.

Zkusme si to tedy rozebrat, co se stane v jednotlivých situacích:
1. směrovač bez ACL se podívá na typ
a) ID známého protokolu - většina datagramů, řeší standardně
b) hop-by-hop/routing - musí řešit vázaným seznamem, čili ukazatel na další pozici, pár jasně daných hlaviček, musí řešit pouze je. Předpokládám, že bude řešitelné v FPGA.

2. Hraniční směrovač/firewall s ACL:
a) ID známého protokolu - většina datagramů, řeší standardně
b) jiný případ - musí projít celý vázaný seznam, dereference ukazatelů + nějaký IF pro známé/neznámé protokoly. O tom, co udělat s neznámými je psáno v článku.

3. SOHO router - nebude stejně ACL/paketové filtry řešit v HW, u datagramů s "next headers" musí projít vázaný seznam. Mimo to, pokud bude firewall stavový, tak bude potřeba hledat v tabulce spojení a to bude v závislosti na implementaci často ještě náročnější operace, než prostý průchod vázaným seznamem.

Datagramy se špatným pořadím hlaviček by měly být zahazovány rovnou. Mám navíc obavy, že na některých FW bude v budoucnu v pravidlech definováno něco jako "Zahoď, má-li více než X rozšiřujících hlaviček".

Vy jste se učil u jednoho německého pána, co tvrdil, že stokrát opakovaná lež se stává pravdou?

Lháři tady byli dřív, stydím se :-)

holt tomu akorát nerozumíte, akorát to nemusíte tak okatě prezentovat. Už vás známe :-)

Jenze routery na paterich tohle vubec resit nebudou, ty vemou paket a poslou ho dal - tam kde je pidizatez si muzu dovolit lecjakou zhuverilost, protoze CPU to nejak rozdejcha, ale tam kde mi tecou Gbity dat si tohle dovolit nemuzu.