Názory k článku IPv6 Mýty a skutečnost, díl V. - Zjednodušené hlavičky

Už několikrát vás tu upozornovali,kdo je autorem IPv6 specifikace a vy tu stále opakujete ty své mantry o akademicích a bruselistech.

Nefunkcni ICMP je mor i na IPv4, osobne by mi nijak zvlast nevadilo, aby vzniklo pravidlo, ze stroj ktery neodpovi na ping nebude routovan a bude mu odebrana IP. To by bylo najedou IPcek ;D.

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

To, že lžete není napadání, ale holý fakt, na který vás tady už několikrát upozorňovali. Takže asi tak.

Tak to se běž honem rychle léčit ;-)

A ani bych se nedivil, kdyby byl od jednoho autora...

wokna je lepší nepoužívat, takže odpojte síťovou kartu :-)

Asi bych příliš nezdůrazňoval MLD snooping, protože se jedná o berličku pro nefungující protokoly druhé vrstvy jako MRP, GARP a pod., které málokterý switch implementuje.

V IPv6 je source routing (hlavička RH0) zakázána od roku 2007. V IPv4 zákaz source routingu skončil u draftu - http://tools.ietf.org/html/draft-reitzel-ipv4-source-routing-is-evil-00.

IPv6 je na tom v této velmi úzké oblasti lépe než IPv4 - dle standardu není nutné a ani vhodné source routing implementovat. V IPv4 je potřeba ho stále implementovat (pokud chcete dodržovat standard) a následně pomocí administrativních nástrojů zakazovat. V mnoha implementacích IPv4 je source routing po základní instalaci stále povolen.

> Vzhledem k tomu, že zpráva informující o velkém datagramu je přenášená protokolem ICMPv6, nelze u IPv6 beztrestně blokovat veškerý ICMPv6 provoz na firewallu, jak se tomu mnohdy dělo v případě ICMP(v4).

V tomhle ohledu se IPv4 a IPv6 zas tak moc nelisi - sice IPv4 podporuje fragmentaci uvnitr site, ale take podporuje flag don't fragment, ktere takove chovani zakazuje, a tusim, ze je pouzivani tohoto flagu dnes majoritni a doporucovane chovani. Zahazovani ICMP paketu na IPv4 tedy casto vede k podobnym problemum.

Ovsem bez ICMPv6 si jaksi neskrtnete jeste z par dalsich duvodu, treba proto, ze nebudete ani schopen nalezt sousedni stroj (ekvivalent blokovani protokolu ARP).

No to nevim jestli se vam povede. M$ zamerne dela nektere aplikace tak, aby behaly jen po IPv6, takze casem asi prilis na vyber nebudete mit.

Nevim, MRP/GARP moc s MLD nesouvisi (http://en.wikipedia.org/wiki/Multiple_Registration_Protocol). Prihlasovani do skupin je v kazdem pripade potreba kvuli routeru. Nicmene MLD snooping v sitich, kde neni multicast je asi stejne celkem k nicemu.

Je dobre ze tenhle nesmysl casem z IPv6 zmizel. Zna nekdo vubec nejakou smysluplnou aplikaci, kde je/byl source routing k uzitku?

Právě, že souvisí MRP/GMRP je protokol, který switchi říká, do kterých multicastových skupin se počítač přihlásil na L2. Samozřejmě na L3 se musí přihlásit k odběru multicastových skupin pomocí MLD.

MLD snooping je náhražka za MRP, switch prostě poslouchá zprávy pro router, což by neměl dělat, ale měl by se řídit zprávami MRP. Jenomže to tak nikdo nedělá.

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.

No, není to pozůstatek z doby, kdy celý internet tvořilo pět počítačů a routovací tabulky byly jen v hlavách uživatelů? A pak už to zůstalo kvůli zpětné kompatibilitě.

Jestlize neni mozno tento packet zahazovat, pak je potreba ho zpracovat a nejak mu verit. Jak se resi podvrzeni tohoto paketu?

Jelikoz je mozne podvrhnout adresu odesilatele, takze paket muze vypadat, jako ze prichazi od smerovace na puvodni ceste (tudiz filtering na teto polozce nepomuze), je mozno informovat zdrojovy firewall ze MTU je nejake male cislo. Tim lze ZVENKU site sice ne zahltit jako v pripade hop countu, ale alespon zpomalit efektivni prenos - to vse jednim paketem.

Pri zacileni na vice probihajich prenosu lze tak sit i zahltit, protoze vetsinu surovych dat budou tvorit hlavicky.

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

No kluci já se Vám divim. Já s nikým kdo má nemoderní IPV4 vůbec nekomunikuju.

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.

Já si radši počkám na další verzi. Asi to bude jako u woken: je potřeba jít minimálně přes 1 verzi.

Pokud se do odesílaného paketu vhodně předepíšou mezilehlé adresy, je možné na jedné lince docílit cyklického putování paketu tam i zpět a tímto ji doslova ucpat.

To možná několikanásobně zatížit, ale těžko ucpat. Hop count je jasná stopka.

Dekuji za dalsi dil.

1. Trochu nepřesná je formulace <i>"Stejně jako v IPv4 je hodnota snížena při průchodu každým směrovačem a v případě, že je dosaženo hodnoty 0, je paket zahozen."</i> - na rozdíl od IPv4 je zde vždy snížení o 1, proto také "hop count".
2. Netx Header -> Next Header
3. TCPv2 je uvedeno jako hypotetický příklad, nebo už někde existuje draft? Zatím víceméně stačilo UDP a TCP, byť s určitými problémy, viz následující bod.
4. Postrádám v textu zmínku o hlavičce "Jumbogram", která umožňuje přenášet v 1 IP datagramu potenciálně 4GB dat, ovšem s určitými "obháky" u UDP (délka=0) a TCP (ukazatel urgentních dat, ...)

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

Dovedu si predstavit, ze chcete udrzovat konstatni latenci a nechcete aby se vam menila tim, ze ruzne pakety pujdou ruznou cestou => zjistite si cestu a chcete aby kompletni komunikace probihala po ni.

Samo to sebou nese riziko, ze cesta nebude dostupna.

Já taky ne :-)

a nikdy na neho neprejdu ;-)

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.

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

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.