Популярные ресурсы и их отношение к IPv6, структурировано по разделам.
Если чего-то не хватает, то можно попытаться дополнить или форкнуть.

Разведка доложила ужасную вещь - не все знают, что у винды уже давно есть свой tcpdump и даже приложуха для анализов дампов. Правда последнюю всё же придётся скачать отдельно, но pktmon уже давно идёт из коробки.
https://www.bleepingcomputer.com/news/microsoft/windows-10-quietly-got-a-built-in-network-sniffer-how-to-use/

И совсем уж чОрная магия: у них даже есть тулза для конвертации etl в pcap. Так что хватит там уже страдать по углам.

https://github.com/microsoft/etl2pcapng

Не слежу за новостями мобильной связи, за 5G и даже не пользуюсь интернетом на телефоне. Но вот почему-то порадовался за соседнюю страну, хотя и не могу оценить степень крутости или не крутости.

История заголовка HTTP который не стал стандартом, не совсем стандартом RFC 8674.

Ntop научился сам опрашивать ICMP, Speedtest и HTTP, наверное, чтобы два раза с дивана не вставать и это логично. Функционал ищем в четвёртой версии.

На Habr вывод ss -s разложенный по косточкам, с небольшим погружением в исходный код и удобными диаграммами.

Cloudflare теперь и speedtest сделал - speed.cloudflare.com

Очень хорошее пояснение проблематики DHCPv6 vs. ND/RA SLAAC в списке рассылке IETF с разных позиций, в том числе и административной. Зримо присутствует ещё более сложный вопрос классификации и деления на уровни: что относится к задачам сети, а что уже к прикладным задачам хоста. Вопрос, если и решаемый, то не для всех.

Если основательно подходить к планированию и проектированию сети или работ на сети, то перед тем как что-то сделать надо это попробовать. В тестовом окружении, реальном или виртуальном, может быть даже на рабочем участке сети. Чем больше сеть и чем масштабнее проект тем это сделать сложнее, но и в этом случае можно смоделировать поведение в тех или иных условиях.

Для меня сейчас это звучит нереально и почему-то отсылает в мою студенческую жизнь, когда мы строили поведенческие модели сетей, сами что-то считали и программировали, находили вероятности и риски разных топологий и даже был какой-то специализированный софт для построения моделей сетей передачи данных.

Но разве не в этом и заключается работа сетевого инженера? И такие инструменты, конечно, должны быть, об одном из которых в блоге APNIC - pyNTM, а также упоминаются несколько других коммерческих продуктов. Это не готовое приложение - библиотека/фреймворк в который придётся вникать, но который, возможно, выведет ваш подход к работе на новый уровень. В любом случае, обоснование к закупке где фигурирует строгий математический расчёт выглядит солиднее, хотя это может и не добавить ему шансов на реализацию.

Если у вас есть один машиночитаемый документ, то из него достаточно легко, гораздо легче чем не имея такой документ, можно сделать любой другой. Например, из файлов drawthe.net рабочую топологию для GNS3 с помощью пары страничек кода на Python. И уже не надо себя ограничивать нелюбимым редактором, комбинируй как хочешь, но чуть-чуть программировать надо уметь.

Книга по SDN, во всех его смыслах. Если не всё, то многое в одном месте разложенное по полочкам. Всё ещё в процессе написания, я думаю в постоянном процессе, объёмы небольшие чтобы за вечер осилить.

Хорошие инструменты подходят сетям любого размера: большой экран - Network Weathermap в Cacti, я так понимаю это магистральная сеть на всю страну. На мониторе справа вкладка активных триггеров Zabbix.

​Что такое шик - это когда даже в мелочах не к чему придраться. Забавный и вполне понятный своим происхождением глюк на одном из наших давно, очень давно, непрерывно работающих коммутаторов. Не хочется думать что производители не рассчитывали, что их оборудование будет так долго работать :) тем более работой мы вполне довольны, не восхищены, но и не огорчены.
Из таких мелочей, в основном, и складывается сложность: мелочи в протоколах, мелочи в их реализации, мелочи во взаимодействии с конкретным оборудованием и сотня других причин и мелочей.

P.S. Подсказка для тех кто не любит искать - смотрим количество переданных пакетов и время прошедшее с поднятия интерфейса.

Ещё даже не все настроили DoH на Микротике, а они уже RPKI выкатывают в бете.

​День запуска IPv6, прошло 8 лет. График Google перебрался за 30% и показывает сейчас линейный рост. Где-то на границе 2017-2018 случился перелом, до этого было похоже на параболу. Плюс 5% проникновения в год, до 100% осталось 14 лет, но это не точно.

BGPlay ко вчерашней аварии Telegram. С нашей стороны, да и не только, наблюдалось полная потеря анонсов из AS62041. Хорошо видны моменты, когда упало и когда поднялось.

Geoff Huston про будущее Интернета, будущее технологий. Это ответ на New IP, но совсем не про него. А про то, что вообще можно считать прорывными технологиями и какие из тех современных, что на слуху у всех, мы уже используем широко или только начинаем использовать, и почему они прорывные по его мнению. Бонусом, исторические аналогии, подглядывание в будущее и несколько едких замечаний в сторону бизнеса.

Наверное, все знают или хотя бы наслышаны о страшилках и опасности редистрибьюции BGP full view в OSPF. Статья о том, что конкретно при этом происходит с точки зрения протокола, примеры и рекомендации так не делать.

Случаи бывают разные и разные необходимости, просто следует относиться к этому очень внимательно и не только к этому. Кстати, iBGP в Cisco по умолчанию нельзя проанонсировать в OSPF, но тут, наверное, другой посыл.

Как бы не хотелось построить по настоящему отказоустойчивую и распределённую сеть, почти всегда останутся места более важные чем остальные. Это может быть оборудование, или магистраль, или целый ЦОД. Даже в глобальном масштабе случаются проколы.

Многие, если не большинство мелких и средних провайдеров, в том числе отдельные части у больших провайдеров не имеют горячего резерва 1+1. Хороший вариант если резерв потянет хотя бы 50% от общей нагрузки, чуть хуже, если то из чего можно собрать резерв есть в наличии, или это можно снять с другого менее загруженного участка сети. Частый вариант, нечем менять и тогда замена ищется у друзей или соседей, или собирается кардинально новая схема позволяющая работать хоть как-то.

Эту картину плохо видно в общем, но на вскидку за последние 4-5 лет, в нашем регионе я знаю про несколько подобных аварий, со сроками устранения до нескольких недель, то время чтобы найти и доставить адекватную замену или настроить неадекватную требующую переделку многих внутренних механизмов. И мы сейчас говорим про центральный узел, на периферию часто легче найти замену из ранее используемого оборудования, но уже выведенного из эксплуатации, или быстро купить ввиду меньших требований к функционалу и производительности, да и последствий меньше.

Ещё момент касающийся централизации и почему иметь две точки выхода в Интернет в разных частях, разнесённых географически, для многих совершенно не по силам - это СОРМ и уже многочисленные инициативы и законы по централизованному управлению трафиком, которые в принципе ломают децентрализацию, если в провайдере её имели хоть в каком-то виде.

Я хочу понимать почему так и даже сам иногда верю что это дорого и не оправдано, но это точно не правильно. Пусть у вас ничего не ломается, а если и ломается то всегда было что-то вместо.