Názor k článku Tak jsme na suchu! od Santiago - > Další ztěžující věc jsou různá rozhraní (z...

> Další ztěžující věc jsou různá rozhraní (z hlediska adres), které jsou navěšené na jedno (třebas místní linky při autokonfiguraci). 1 rozhraní tak nakonec může komunikovat s větším množstvím měnících se adres (rostou nároky na pamět, ARP tabulky, ...).

Nejsem si jist, ze rozumim co mas na mysli, ale pokud tim myslis proste vic IP prefixu na jednom sitovem rozhrani, tak to je featura, ktera puvodne v IPv4 nebyla, ale je natolik potrebna, ze ji dneska (pro IPv4) stejne umeji skoro vsichni, ale proto, ze puvodne nebyla ve standardu, tak mohou byt potize s kompatibilitou (napr. v OSPFv2, kde rozumne chovani pri vice IP na rozhrani snad nikdo nedefinuje). Proto je vcelku rozumne, ze pri navrhu IPv6 to tam rovnou dali.

> Fragmentování ? To jsem ještě nikdy neřešil, pakety s fragmentem zásadně zahazuju. .. Takže opět něco, co se vyřešilo samo historicky tím, že HW překonal nutnost cokoliv fragmentovat.

Problem s fragmenty v IPv4 neni ani v tom, ze bys je musel spojovat (to stejne dela koncovy stroj), ale ze je musis po ceste rozdelovat, kdyz je predavas na linku s mensim MTU.

Ono to je trochu jinak - prave proto, ze v IPv4 je fragmentace docela dost rozbita, tak se lide moc neodvazuji pouzivat jine (vetsi) MTU nez 1500, i kdyz pro moderni hardware a rychlosti by to bylo vhodnejsi.

Problem s fragmenty v IPv4 neni ani v tom, ze bys je musel spojovat (to stejne dela koncovy stroj), ale ze je musis po ceste rozdelovat, kdyz je predavas na linku s mensim MTU. Jak je to s pruchodnosti fragmentu Internetem nevim, nicmene problem byva spis na opacne strane - router predavajici pakety, ktere maji zakazanou fragmentaci po ceste (typicky TCP), vygeneruje ICMP zpravu, kterou nekde sezere pitome nastaveny firewall.

> Nepřítomnost součtu, že něco zjednodušuje ? Přepočítat kontrolni součet neni problém a to, že ho odebrali, je dle mého názoru, taky chybou. Ne všude pakety jedou po ETH, ne každý protokol, kterým se tuneluje je málochybový.

Kontrolni soucet samozrejme neodbrali, pouze z nej vyjmuli TTL, takze ho neni treba pregenerovat pri kazdem forwardovani paketu.

> Potom fine věci, jako že do stejné skupiny patří 2 rozhraní, jedno WAN a druhé LAN. To všechno zesložiťuje logiku "routování" paketů. Je sice krásné, že zákazníkovi přidělí operátor 1 subnetu a on pro WAN použije rovnou tu subnetu stejně jako pro LAN, nicméně... Proč ?

To, zda mezi LAN a WAN se routuje (a pouzivaji odlisne prefixy) nebo bridguje/proxy­arpuje (a pouzije se stejny), preci vubec nesouvisi s IPv6 - obe varianty se pouzivaji jak na IPv4 tak na IPv6 (nicmene bridging jako optional). A fakt nevim, ze by nejaky IPv6 RFC specifikoval, ze to IPv6 implementace musi umet. Odkaz?

Logika routovani/for­wardovani je vicemene stejna - vyberu best-matching routu a pouziji interface a next-hop, ktery ta routa specifikuje.