Do dnes mě zaráží, jakou podporu i v odborné, a zejm české odborné, veřejnosti IPv6 má. Výsledek na mě stále působí předražený akademický nesmysl, který navrhl nějaký student na brigádě. Bohužel, v praxi nevítězí dobrá technická řešení, ale něco jiného... jestli se teda dá říct, že IPv6 nějak po těch 30 letech vítězí...
Píšu to z pozice autora IPv6 parseru pro 100G sítě. IPv6 hlavička je přesně to, co nechcete... Jinak ani tcpdump dodnes neumí poměrně základní IPv6 filtering (např zde: https://github.com/the-tcpdump-group/libpcap/issues/600#issuecomment-4537523426), o extension hlavičkách nemluvě.
Jediné dva skutečné přínosy, které jsem u IPv6 zaznamenal, jsou odstranění L3 checksumu a delší adresa. To šlo ale udělat fakt jinak. No a pak, že můžou existovat IPv6 dny a konference, kde se o tom dá tlachat...
"Do dnes mě zaráží, jakou podporu i v odborné, a zejm české odborné, veřejnosti IPv6 má."
Já osobně nedostatkem IPv4 adres netrpím, ale chápu že existuje a je třeba ho nějak řešit. Pokud lepší řešení než IPv6 v současné době není, nezbývá než to akceptovat a podporovat. Pod kritérium "lepší" zahrnuji i to, aby bylo celosvětově prosaditelné.
Býval jsem nadšenější pro všechno nové, ale zjistil jsem že často si od nových věcí slibujeme příliš a pak jsme zbytečně zklamaní. Jestliže IPv6 nějak řeší nedostatek adres, ok, ale čekat od toho že bude Internet internetovější, to ne. Například mít jakékoliv zařízení přístupné komukoliv odkudkoliv není tak snadné a také to není vždy prospěšné.
Vy se divite. Ja proklinam ipv4.
Staci se mi podivat na nektere konfigurace proxy v dmz. Misto toho, aby to melo jednu verejnou IP a tedy jednu sit, ktera muze komunikovat s internimi servery (interni IP), musim mit 2 IP adresy (verejna + interni) a tedy 2 site, nasobek firewall pravidel vcetne reseni NAT komplikaci a tak dale.
Ano, jsou tam dost velké pasti. Konkrétně extension hlavičky ve výsledku znamenají, že je problém skutečně bezpečně implementovat RA Guard na L2 prvcích. Ví se to přes 10 let a reálně je to stále problém:
http://6lab.cz/rogue-router-advertisement-attack/
https://www.root.cz/clanky/bezpecne-ipv6-vicehlavy-utocnik/
Nebo třeba IPv6 radius accounting na WiFi sítích - je skoro jedno jak drahé řešení pořídíte, protože málo kdo to provozuje, takže jsou tyto věci často polofunkční nebo kolidují s některými dalšími funkcemi...
Nejde o iOS 15, jde o schopnost L2 prvků filtrovat rogue RA přes RA guard nebo ACL. Extenzivním využitím/zneužitím řetězení hlaviček a fragmentace lze dosáhnout toho, že z prvního fragmentu nelze odvodit protokol. Řeším to aktuálně na HPE Aruba CX 6100. Přestože datasheet uvádí, že umí RA guard, tak v SW tato funkce není. Přestože je na to na HPE webu skoro 4 roky ticket, tak to v datasheetu dodnes neopravili... Jde to technicky řešit přes ACL, ale tam není jednoduchá možnost, jak blokovat 1st fragment ze kterého nelze určit protokol. Alternativně to může být řešeno na endpointech tak, že budou fragmentované RA zprávy zahazovat, viz RFC 6980. Jde na to spoléhat? Nenašel jsem aktuální přehled, jak na tom všechny obvyklé OS jsou. Prakticky to otestovat není úplně easy.
WiFi řeším na HPE Aruba IAP 505. Jeden bug s IPv6 třeba je rozbití RA, pokud je aktivní client-isolation -- blokuje to solicited RA, klient pak dostane IPv6 až s nejbližším periodickým RA, což je obvykle v řádu minut. Radius accounting mi zatím atribut s IPv6 adresou neposílá vůbec, přestože ve web/cli jsou v client listu vidět. To ještě řeším, ale není tam žádný parametr co by to zjevně ovlivňoval. Jestli to bude někdy spolehlivě posílat všechny privacy-extensions adresy od každého klienta, to jsem hodně zvědavý. Bez toho je problém mít spolehlivý traffic log. Řeknete si dobře - budeme schopni to dohledat podle MAC adresy, kterou máme v Radius Auth ... ale, narazíte na to, že v netflow/ipfix datech MAC adresy nemáte - zdravíme do FortiNetu ... takže i dnes je snaha o full nasazení IPv6 v mid-enterprise prostředí pořád past vedle pasti.