Vzhledem k tomu, že jsem byl v závěru zmíněn, musím reagovat :)
Podle mého názoru je chování systému na IPv6-only síti mnohem lepší − prostě to nefunguje a je to potřeba opravit. Uživatelé nezahrnují technickou podporu nejasnými stížnostmi jako že „Youtube videa se načítají pomalu“, nebo „Firefox funguje, ale Thunderbird ne“ a technik řešící problém jej velice rychle najde, protože projde jedinou možnou cestu od uživatele.
V dual-stack světě je například i pro zkušeného administrátora velký problém odlišit příznaky problémů s MTU od problému s nefunkčností jednoho protokolu a troubleshooting je tak mnohem komplikovanější.
Otázka zní jinak: o kolika chybách v IPv6 víme (máme prověřenou neexistenci dalších zkušenostmi z provozu) a kolik je z nich "vyřešených" nějakou "best current practice", tak aby koncový uživatel nemusel měnit svoje* zařízení?
Můj pocit totiž je ten, že chyby IPv6 se musí často řešit jinými postupy než (principielně ty samé) chyby IPv4, a ti kdo na ty chyby upozorňují tak zatím vesměs nedávají odkazy na nějaké BCP, které by to řešilo.
Hezký den,
ano, máte pravdu. Chyby se musí řešit jinými postupy, než principiálně stejné chyby u IPv4. Co se týče chybějícího odkazování na BCP, tak to je to dané tím, že BCP pro IPv6 zatím neexistují. Resp. neexistují oficiální BCP, které by reprezentovaly nějaký konsensus. Tedy není se moc na co odkazovat.
M.
Hezký den,
vámi navrhované řešení podle mě není moc vhodné, jelikož vaše řešení spíše nahrává útočníkovi. Tím, že by se odstranily nejstarší záznamy se totiž odstraní i validní záznamy z NC. Útočník, pokud generuje stále nové a nové pakety, je pak de facto schopen zaplnit celou NC vlastními záznami a odstranit všechny validní, které tam byly.
M.
Ta myšlenka má něco do sebe. Při zaplnění cache začít procházet záznamy a pokud nepřijde odpověď na ping, tak bez milosti zahodit záznam, jinak prodloužit na maximum... Jednak se uvomní neaktuální záznamy, druhak tam při přetečení zůstane zdravý jádro. Sice to nemusí být všelék, ale moc by to pokazit nemělo.
Ano i ne. Útočník na ping může odpovídat naprosto stejně jako validní zařízení. On v principu tento problém nemá moc řešení a musí se dohledat ono "škodící" zařízení a odpojit ho, nebo ho nějak jinak opravit (často tyto útoky provádí různý malware). Občas zařízení nicméně používají strategii - když je cache plná, zařízení ji kompletně celou smaže a pokračuje se s prázdnou cache od začátku. Ale záleží na implementaci - typicky tyto optimalizace moc implementované nejsou.
Tohle řešení ale tu cache zase velmi rychle zaplní platnými daty, když útok skončí (on totiž útočník může úplně stejně zahltit síť třeba broadcast pingem a o žádnou cache se starat nemusí). Což mi přijde jako mnohem lepší řešení, než když cache zůstane zaplněná nesmyslnými záznamy útočníka.