Хороший отчёт о внедрении IPv6 с экономической точки зрения. Какие драйверы, плюсы/минусы несёт внедрение IPv6 для сетей в зависимости от их типа, размера и скорости роста и других факторов. Какие стратегии внедрения IPv6 выбирают операторы сетей.  https://www.internetgovernance.org/wp-content/uploads/IPv6-Migration-Study-final-report.pdf

ISC DHCP переехал на Gitlab, там уже есть BIND9 и Kea. Страничку source.isc.org ещё не поправили. Принимают merge requests, есть зеркало на GitHub, но только как зеркало. Историю багтрекера переносить не стали, но она есть.

В какой-то момент наслоениям приложений тоже понадобилась маршрутизация. Cloudflare пишет про новый стандарт и как они его реализуют. Суть проблемы в том, что запрос из одного CDN может переадресовываться на другой, с другого на третий, а с третьего опять не первый. Первый в свою очередь опять запрашивает второй. Да, протоколов маршрутизации и STP тут нет - не тот уровень, а кольцо получается.

Из положения вышли добавив новый заголовок в запросе, пока это не стандарт. Заголовок Via не подошёл по распространённой причине, его использование закостенело в конкретном применении и он потерял свою универсальность. В итоге пока так, но не факт что это решение не потеряет своей актуальности в ближайшее время и кто-то не изобретёт STP между приложениями или их частями.

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

WPA3 не такой уж безопасный как хотелось, но это пока. Выявление проблем на раннем этапе позволит принять меры до того как всё широко разойдётся. В общем-то одна из проблем, и наверное самая большая, как раз желание обеспечить совместимость вездесущего WPA2 и WPA3.

А как WPA2 ломать перебором, для тех кто даже не знает что такое Wi-Fi пишут, например, на KaliTut.

Qrator про хитрый hijack. Если предположение верно, то прямая экономическая выгода с минимум последствий будет очень привлекательна для многих.

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

При этом технически как раз и строили с расчётом на этот самый дух и честность, т.е. введение административных мер сейчас может привести к жутким перекосам. Бурное обсуждение предложения политики RIPE тому подтверждение. А статья Qrator подтверждение того что такие случаи доказать не просто, не говоря уже о том чтобы найти. Если сюда наложить национальный интерес и возможности влияния, я про Китай, то становится совсем интересно. Никакое осуждение и мораль не работают.

Интернет повзрослел.

​ping.gg простой сервис для мониторинга доступности адреса сайта. Основной способ проверки - ответ на ICMP, но можно и HTTP(S).
Никакой регистрации, никакой обязательной платы (авторы просят пожертвования на хостинг), простое управление. Есть Github и логично поднять свой собственный сервер, чтобы следить за своими узлами из разных частей Интернета не привязываясь к кому-то. Проект очень небольшой и действительно простой.

QoS - всё, по крайней мере в виде управления очередями.
Облака и SD-WAN сделали своё дело. Вопрос стоит сейчас в другом - выбор лучшего места для сервиса, лучшего направления/туннеля по заданным критериям.

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

Помните Call Admission Control в VoIP? Современный QoS, по крайней мере его применение для сетевых приложений именно в этом: распределить нагрузку на все имеющиеся ресурсы, так чтобы это было комфортно всем. Если ресурсов не хватаем - выделяем ещё, облака же. В отличие от "старого" подхода управление нагрузкой на одном ресурсе через планирование очередности. Эдакий переход к истинному параллелизму.

Управление потоками и очередями никуда не исчезнет, так же как и локальные сети в своём классическом исполнении.  По крайней мере пока есть приложения для этого, их меньше, но они есть. Так что совсем не обращать внимание на QoS в таком варианте пока не стоит.

Хайку кодирование IP адресов, работает для v4 и v6 в прямую и обратную сторону, на английском, хотя можно было бы ожидать японский ;)

The agile black ape
basks in the ancient clearing.
Autumn colors crunch.

По ссылке длинный текст с подробными объяснениями, сам генератор где-то в середине. IPv4 хайку звучат красивее на мой вкус. Словарик не такой большой, хочется разнообразия даже для одинаковых частей адресов, но для этого есть Github.

Оценка "загрязнённости" автономной системы. Используя различные источники данных, формируется суммарная оценка. Можно посмотреть на конкретный IP и источник из которого он туда попал. Есть API, код открыт. Чуть больше описания на сайте организации противодействия компьютерным происшествиям Люксембурга.

Сейчас это часть проекта D4 анонсированного в ноябре прошлого года, под эгидой той же CIRCL. Хотят разработать и запустить свободную платформу для сбора, анализа и противодействия DDoS. Уже есть готовые элементы, но собственно результат как сервис пока только BGP Ranking.
Они ещё в самом начале. Можно сравнивать с другими подобными проектами, но чем их больше сейчас тем лучше.

Немного выдрано из контекста, но к главной новости сегодняшнего дня подходит хорошо.

По следам взлома matrix.org. Если вы используете механизм SSH-agent forwarding замените его на ProxyCommand или ProxyJump. Иначе, когда промежуточный узел скомпрометирован, узел назначения тоже может быть скомпрометирован. Это известное поведение, будьте аккуратны.

Netnod IX обновляет свою платформу маршрутизации, чтобы соответствовать современным требованиям. Много говорится про RPKI, это тренд и скоро, я думаю, так будет у всех. Для реализации используют связку Arouteserver, Bird, GoBGP и Alice-LG для looking glass. Подробнее можно посмотреть в презентации с DKNOG9 или видео.

Netnod IX большой обменник с суммарным трафиком около 1,5Терабит/c, для сравнения MSK-IX 3,5. Так что опыт и инструменты можно смело перенимать для своих целей, тем более все средства более чем доступны.

Рисуем схему сети в YAML

http://go.drawthe.net

OpenSSH 8.0 - налетай!

Генератор локальных уникальных уникаст IPv6 адресов (ULA). Используется предложенный в RFC4193 способ: время, SHA1 и EUI-64 (MAC, по сути любое произвольное длинное число).
Никто конечно не проверяет что вы используете fc00::/8 или fd00::/8 с неслучайными значениями, на то это и локальный диапазон. Но для себя подстраховаться стоит, мало ли, IPv6 теперь может до скончания веков с нами. Правда реального применения этого диапазона я ещё нигде не видел, как и не видел чтобы его кто-то даже попытался задавать согласно RFC.

DNS over что-то это хорошо, но помимо пользы и свободы он добавляет и проблем вполне легитимным пользователям. Например, админам корпоративной сети которым надо обеспечивать безопасность этой самой сети и пользователей в ней. Локальный DNS с фильтрацией, скажем, фишинговых сайтов вполне распространённое и эффективное решение, поэтому использование сторонних сервисов пробивает брешь там где она не нужна.

Сторонние DNS можно запретить по возможности и для классического UDP 53  это хорошо работает, с ним можно даже и ответы подменять. А вот для DNS over что-то - сложнее. В этом случае будет запрещён и протокол в который вкладывается DNS запрос, например HTTPS.

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

Как всегда любой инструмент можно использовать по разному и его противоположность то же.

Вдогонку уходящему дню. Помните 512К day в 2014? Тогда BGP full view перевалила за 512 000 маршрутов, а настройки по умолчанию на популярных маршрутизаторах Cisco были как раз установлены максимум в 512 000 маршрутов, что привело к проблемам с маршрутизацией, в том числе, у больших провайдеров. Как об этом писала сама Cisco. Тогда упоминалось, что этому было подвержено не очень новое оборудование.

Прошло 5 лет, таблица BGP Full view растёт почти линейно и сегодня перевалила на 768 000 маршрутов, или перевалит в ближайшем времени, некоторые неточности возможны при подсчёте. По этому поводу на zdnet.com написали целую статью опасаясь за то что опять могут повториться проблемы.

Это, в принципе, могло бы быть, так как многие резонно рассудив подвинули границу как раз к 768 000 маршрутов, а не к максимальным возможным в 1 000 000, чтобы оставить немного места для IPv6 на 120 000 маршрутов, сейчас их реально почти 70 000, и что-то для MPLS и мультикаст. Но 5 лет большой срок, чтобы всё ещё оставаться на устаревшем уже в 2014 году оборудовании и, наверное, мы не увидим больше подобного фиаско. Может быть ещё через 5 лет, когда количество маршрутов доберётся до 1 000 000.

Следить за зрелищем :) на любителя, можно тут @bgp_table_bot

Вот тут у немцев похоже получилось построить большую добровольческую Wi-Fi сеть. Больше 1500 узлов на карте с почти 2500 клиентов в Мюнхене и трафика там достаточно. А это только один город из. Выход в Интернет присутствует.
Конечно, не забудем упомянуть ещё связанный с этим проектом мессенджер для p2p сетей. Для простой одноранговой локалки тоже подойдёт.

И ещё про mesh сети и IPv6. В этом случае IPv6 снимает практически все вопросы адресации, мы сразу получаем мало чем ограниченное количество узлов в этой сети. Правда что-то придётся придумать с маршрутизацией в этом плоском пространстве, зато ничего не придётся придумывать для протоколов обмена полезной нагрузкой, всё остаётся в рамках стека IPv6.
Такую сеть конечно придумали и называется она CJDNS. Как это всё работает и настраивается в статье, за которую большое спасибо нашему подписчику. На Github тоже стоит зайти. И обязательно на Habr за последними новостями, где CJDNS превращается в Yggdrasil.

Что отметил для себя. IPv6 дал столько свободы своими 128 битами после десятилетий притеснений, что у многих появилось желание использовать адрес не только как адрес. А почему бы и нет, это целых 16 байт, в былые времена которых хватало очень на много, на целые программы хватало. Поэтому и появляются проекты вроде 6cn.
Единственное что  может случится не так - применение адреса не просто как идентификатора в будущем, возможно, сузит валидное адресное пространство, просто потому что адрес не будет в какой-то алгоритм укладываться. Вот об это стоит подумать разработчикам, а то опять себя в рамки загоним без выхода.

Да, всё именно так. Оригинал картинки с описанием и другими картинками можно найти на сайте производителя.

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

Статья на Habr про это, наверное, вы её уже видели. Там такие же правдивые, но не такие детальные схемы топологии сети провайдера. Можно и другим способом организовывать, но принципиально не сильно большая разница.