Názory k článku Omezte broadcastový šum protokolu ARP na síti s veřejnými adresami

S negativni cache pro IPv6 neighbor discovery to tak jednoduche nebude. Aneb i tech potencialnich 2^64 zaznamu v pameti neco sezere. A samozrejme na toto samozrejme existuji i cilene utoky. Zrovna tady je jednodussi to resit jinak nez u IPv4, tu negativni informaci v cache proste nemit a adresu, ktera neodpovida co nejrychleji zapomenout - nez kvuli "par" usetrenym paketum do wifiny nechat padnou router na nedostatek pameti :-) Soucasne se vetsinou omezuje pocet soubeznych nezodpovezenych dotazu (nebo pamet pro ne vyhrazena).

U IPv6 dává naopak smysl jen pozitivní cache. Speciálně v prostředích jako je Wi-Fi není vůbec potřeba multicastové zprávy NDP šířit. Přístupový bod má přehled o všech klientech a kdykoli si kterýkoli klient nastaví novou IPv6 adresu, musí provést detekci duplicitních adres, tím se o každé adrese dozví i přístupový bod.

Každý přístupový bod má tedy přesný seznam všech IPv6 adres všech klientů, které jsou jeho prostřednictvím dostupné a může klidně odbavovat příslušné zprávy protokolu NDP sám.

Některá Wi-Fi řešení to tak dělají. Pozná se to například tak, že mají arbitrární limit počtu IPv6 adres na klienta (třeba 8 - to je ostatně jedna z motivací za skoroRFC PD per device), nebo že v takové síti nefungují adresy které v rozporu s protokolem detekcí duplicit neprošly.

Ja reagoval na to hledani ipv6 ekvivalentu k arpd. Ano, je to zbytecne ho vubec hledat :-) A neni divu, ze takovou blbost se nikdo implementovat nesnazi.

Jinak samozrejme to dozvidani se o klientovi skrze DAD ma taky sve limity - tu informaci tam nebudes chtit drzet vecne, ostatne i neighbor cache nekdy expiruje. A samozrejme jsou legitimni stavy, kdy klient toho jinak moc ven neposle a proste jen prijima data - aneb to parovani muze zmizet. A opet to muze byt vektor utoku - klient, co si prilis casto meni adresu ti opet muze opet vycerpat zdroje (kterych na typickem hardware pro AP nebyva na rozdavani). Ten limit co zminujes je mj. obranou proti tomuto (samozrejme umysl je jedna vec, prakticka implementace a jeji nedomysleni vec druha) - aneb zrovna ty "konferencni" (potazmo verejne site vubec) site muzou byt mj. lakadlem pro ruzne zaskodniky.

Máš pravdu. To dozvídání o nové adrese pomocí DAD je jen pro prvotní zjištění, že se v síti objevila nová adresa. Jakmile AP tuhle informaci má, může použít normální NDP pro periodické zjišťování, zda daná adresa stále žije. Protože ale AP už zná, který klient danou adresu má mít, není vůbec nutné posílat tyhle výzvy multicastem.

To zpomalení wifi se dá taky omezit zvýšením rychlosti na které se ty broadcasty vysílají. Na místě hustě pokrytém APečkama nemá smysl to mít na minimu.

Taky je možné nastavit AP tak, aby ty broadcasty neposílal jako jeden broadcast minimální rychlosti, ale jako unicast pro každého připojeného klienta zvlášť tou rychlostí co se používá pro bežný provoz. Mám pocit, že OpenWrt to dělá ve výchozím nastavení. Pokud je ale těch klientů hodně, tak se to nevyplatí.

cell_density v openwrt je vychozi 0, urcite je tam oproti defaultum jeste prostor pro posun smerem k vyssimu rate :-) Jediny je defaultne vyply jsou legacy_rates.

Je to přesně tak. Taky mám dojem, že OpenWRT má někde v kódu pro bridge patch, který překládá multicastový provoz do unicastového (jen na vrstvě ethernetu, IP zůstává stejné). Kontrola na Turrisu Omnia ukázala, že patch tam skutečně je a funkce je zapnutá pro všechna Wi-Fi rozhraní:

root@omnia:~# cat /sys/devices/virtual/net/br-lan/brif/wlan*/multicast_to_unicast
1
1
1
1

Vzhledem k tomu, že broadcasty jsou skutečně obvykle pomalejší až tisíckrát, dává překládání multicastu do unicastu smysl v podstatě při jakémkoli realistickém množství klientů.

Tam je ale podminkou fungovani signalizace pres MLD - klient musi rict, ze o danou multicastovou skupinu ma opravdu zajem (i ti to tam pisou). Az pak se ten prevod na bridge vrstve dela. Ten usecase je primarne trosku jiny - cili to na klasicky streaming s plnotucnym multicastem, ktery posilas jen tem klientum, co ho fakt chteji...

Dela se jeste jeden multicast to unicast preklad - na mac80211 vrstve, to je jina feature s jinou motivaci a v podstate vse s ethertype ip/ipv6/arp ma prepsanou cilovou mac na unicastovou... aby to nebylo jednoduchy :-)

Zrovna koukám na moje nové Omada AP a tam je vyloženě možnost zapnout "ARP-to-Unicast Conversion"

Nebylo by lepší neexistující adresy zaříznout už na firewallu? Tedy přesněji: default zaříznout vše a explicitně povolit existující adresy (statické + generovat pravidla při přidělení adresy DHCP serverem).

Takze budeme do kazdeho pravidla vypisovat stovky, klidne i tisice a vyssi rady adres?

To by teoreticky šlo, ale jedná se o hrozně komplikované řešení. Něco takového dělají myslím snad jen captive portály.

Kdyby se do toho už někdo pustil, může rovnou pro každou přidělenou IP adresu nastavit statickou MAC adresu do tabulky sousedů. Takže pak není potřeba ARP broadcasty vysílat vůbec.

Něco na ten způsob mě napadlo. Pokud vím, že v síti chci provozovat jen hosty s adresami přidělenými DHCP, proč to a) nefiltrovat podle seznamu adres přidělených DHCP, a b) podle MAC které si DHCP o adresu řekly?
1) mám seznam zařízení, o kterém vím že tam jsou všichni s kým realisticky můžu chtít komunikovat, a 2) už seznam MAC adres mám, takže broadcasty nemusím vlastně vysílat vůbec.
I pokud by došlo k vypršení adresy bez obnovy, tak není důvod se dotazovat, protože v tu chvíli už ji protějšek stejně nemá co používat a tedy se s ním nechci bavit.

Tak jsou borci, co sli jeste o chlup dal (kde inspiraci byla starsi myslenka)... v podstate tady nediskutujeme nic, co by nenapadlo uz nekoho jineho :-)