1) неправильно указал исходные параметры для Req и Resp ipv6, но это не существенно (у ipv4 такие же правила). Да и всё равно, ведь меняю направление на "Любое" для ping IPv6 (на самом деле было "Исходящее"(для Req) "Входящее"(для Resp)).
Всё же остаётся вопрос: На сколько это нужно/важно/безопасно для работы Ipv6 в целом?
2) входящие запросы теста Ping ipv4 на https://ipv6-test.com/pingtest/ резались роутером. При чём баллы, на https://ipv6-test.com, этот факт не учитывают. (Создавал, одно разрешающей правило для ISMP в роутере на время тестирования, и всё. Правила ping ipv4 dr.web не менял! А ведь они по умолчанию такие же: "Исходящее"(для Req) "Входящее"(для Resp) но ping test v4 стал проходить и без их изменения!)
3) тест ping ipv6 на https://ipv6-test.com/pingtest/заработал без всякого вмешательства в правила роутера (Правда роутер сам поднимает тоннель до провайдера IPv6).
Оказалось достаточно поменять значение направления "ICMPv6 : Ping other (Req)" и "ICMPv6 : Ping other (Resp)" с исходящее/входящее, на любое.
4) Осталось победить SpiDer Gate. если он включён, то тесты https://ipv6-test.com/ и https://test-ipv6.com/ жалуются, что ipv6 поддерживается браузером, но им не используется! Видимо из-за задержек, вызванных работой SpiDer Gate, выбирается более быстрый протокол (ipv4).
5) Интересно, почему такая разница в логике работы правил dr.web для ping ipv4 и ping ipv6 при подключении ПК через роутер?
Нужно бы проверить логику работы ping ipv4 dr.web при прямом подключении ПК к проводу провайдера, но у меня L2TP и мне лень.