IPv6 адресов много, очень много, поэтому некоторые виды техник исследований IPv6 которые доступны в IPv4, например, перебор становятся недоступны (на текущем этапе). Но тут на передний план выходят настоящие математики, которые знают теорию вероятности и статистику, и то что для админа много здесь всего лишь цифра.

Поэтому адреса были собраны, препарированы и сформированы в отчёте на сайте http://entropy-ip.com. Адреса обезличены в старшей части - все префиксы 2001:db8::/32. По факту в простом отчёте префикс всегда 2001:db8:0000::/40 и 14 октет всегда 0, возможно это издержки набора данных (тем более что некоторые границы видно и в других местах). Но так как в полный отчёт я погрузился не до конца не могу по этому поводу ничего сказать. Его можно читать, если вы давно не видели формул придётся кое-что вспомнить. Там сильно разжёвано по существу, но некоторые отсылки придётся вспоминать или пропускать

Простой отчёт не содержит никаких уравнений и читается легче:

1. Сначала посчитали энтропию (чем больше число, тем больший разброс значений в этом месте IPv6 адреса) - это синяя линия на первом графике. Так как статья академическая то сравнили ещё со значением ACR из другой академической статьи (на него можно внимания не обращать).

2. На основе значений энтропии выделили несколько сегментов в IPv6 адресе, по тому как сильно отличаются они друг от друга. В этих сегментах (один или несколько октетов), посчитали статистику появления того или иного значения. Если задан диапазон значений (зелёный курсив со звёздочкой), то из него уже исключены все ранее приведённые значения. Например, вероятность что в 16 октете будет число 3 - 9,5%, а что будет какое либо другое число кроме 3,5,4,8 - 67,52%

3. Дальше построили Байесову сеть - зависимость появления какого либо числа в каком-то месте, от того какое число стоит в другом месте. И сделали интерактивную табличку, в которой можно выбрать число и увидеть как изменится вероятность (отличается цветом) появление других чисел в адресе. Такие же таблички приведены на первой странице http://entropy-ip.com для разных наборов данных (ссылки Dataset).

В самом конце были сгенерированы адреса, которые с большой вероятностью могут встретится в сети и быть активными. Попадание при используемом методе 40% и вот это уже очень много - перебирать ничего не нужно даже если активна всего половина адресов из предполагаемых то это в бесконечное количество раз лучше чем проверить даже 2^64.
Конечно остаётся вопрос получения исходных данных по которым можно проводить анализ. Но это не такой сложный вопрос, особенно если иметь определённую цель. Тем более что инструментарий доступен на GitHub Akamai, а метод расписан от и до.

​Вчера робот Ubuntu который следит за зеркалами напомнил нам, что мы забыли синхронизировать новый релиз 18.10. Релизы у нас синхронизируются раз в сутки, позже чем выкатываются на основном зеркале. Это не противоречит правилам, но в этот раз робот заметил и напомнил.

Новый релиз не вызвал бурного роста запросов на скачивание, как это было с 18.04, вероятно потому что не LTS. Подобная информация один из тех аспектов которые открываются перед администраторами публичных зеркал, волей не волей. И такой чувствительной информации достаточно много. Остаётся обладать большой ответственностью или большим доверием чтобы продолжать поддерживать и пользоваться публичными ресурсами.

Но тут сама Canonical выложила подобный отчёт на основе данных которые она может собирать начиная с версии 18.04. Его русский вариант в переводе Василия Алексеенко. Россия в лидерах по количеству пользователей Ubuntu, не зря значит мы держим наше зеркало ;)

Cisco привела список своих решений в отношении которых проводится проверка по поводу libssh уязвимости. И их там много, включая например IOS XR Software. Того чего нет в списке - 100% не может быть затронуто. Секция "Уязвимые" пустая, пока.

Самостоятельно проверить можно с помощью LibSSH Scaner - качается с GitHub.

Новый Knot 2.7 теперь может в географии разбираться с помощью модуля GeoIP. Примерно вот так:

www.example.com:
 - geo: "CZ;Prague"
   A: 192.0.2.0
   TXT: "Prague"
 - geo: "CZ;Brno"
   A: 192.0.2.1
   TXT: "Brno"
 - geo: "CZ;*"
   A: 192.0.2.2
   TXT: "Czechia"

Поддержка EDNS присутствует.

ASCII картинки заголовков протоколов форматированные в стиле RFC. Есть уже готовые заголовки, а можно конструировать самим какие захочется. Парочка опций командной строки для корректировки вывода. Написано не Python.

Очередной мощный пост от Vincent Bernat, весьма подробно рассказывающий о механизме BGP LLGR с примерами на актуальных платформах. Рекомендуется к прочтению, впрочем как и весь блог на постоянной основе, там всегда много интересного. https://vincent.bernat.ch/en/blog/2018-bgp-llgr

MSK-IX и DE-CIX собираются установить прямой пиринг. Неплохо, неплохо. Вот будет-ли общий пиринговый вилан... посмотрим.

Очень хорошая и простая (во всех смыслах), но от этого ещё более хорошая, статья про основы балансировки сегодня на Habr. От DNS до BGP, от Apache и Nginx прокси до кода на стороне клиента. Всё что нужно знать для практического понимания балансировки, совсем без углубления в детали и с отличной подачей.

Этот же вопрос куда детальней на большом Highload или от Yandex (везде видео).

Вот такой Juniper. Большой.
Но какая бы ни была железка тестовое окружение везде одинаково, и провисающие патчи - норма :)

Кто-то ещё пользуется ifconfig в Linux который как минимум лет 10 не актуален. Два путеводителя по миру администрирования Linux сети от Bert Hubert и Martin A. Brown.
Второй значительно подробнее, но оба хороши. Жаль что не встретились мне в то время, хотя конечно тогда я был другим увлечён. С другой стороны RHEL (Centos) 6 ещё в строю, а там ядро 2.6.

У меня иногда (а это уже часто, раньше такого не было) спрашивают сколько стоят IPv4 адреса. Вот тут цены c марта этого года. Цена за один адрес - купить навсегда, не аренда. Это аукционная стоимость, т.е. она несколько завышена по сравнению с прямыми договорённостями, но картину отражает.
Но эта цена когда адреса есть, а они ещё есть, цена когда их не будет или устремится в космос или к 0 (из-за IPv6). Вот где рискованные инвестиции.

Всё, Google включил DNS over TLS на 8.8.8.8. kdig это dig в версии Knot DNS, пакет называется knot-dnsutils, надо последних версий. Ещё в Android Pie можно переключить настройки DNS в приватный режим. Или по простому сделать telnet на 853 порт и получить бинарный ответ, убедившись что нужный порт на DNS сервере открыт.
Вклинится и подменить запрос/ответ уже невозможно. Я думаю остальные подтянуться быстро, главное чтобы клиенты ещё подтянулись. С Andoid понятно всё, кто его делает, но осталось ещё много помимо него.

Ко вчерашней новости про DoT статья на хабр нашего подписчика, как настроить на MacOS. Но в общем универсальный подход: делаем обычный (без TLS) локальный резолвер, а уже  он сам использует DoT.

​Значки для сетевых диаграмм, есть для Visio и svg. Автор пишет что делал в современном стиле, а ни как из 80-х.

Новая карта всего Интернета не стену за 2018 год. Всего 250 долларов. Но можно посмотреть онлайн https://global-internet-map-2018.telegeography.com - ёмкость, цены, ведущие провайдеры, абоненты, прогнозы.

​Проект для обкатки IPv6 DNS экосистемы.  Можно подключиться в качестве одного из root серверов или использовать эти серверы для повседневной работы. Соответствующие инструкции есть на сайте.
Для истинных энтузиастов, которых, судя по статистике совсем немного.

Вот ещё крутая презентация с RIPE77  про атаку на VXLAN. И видео.

Так как протокол сам по себе не поддерживает встроенные механизмы безопасности, т.е. отдаёт это на транспортный уровень (и это касается очень многих протоколов и, вообще, это unixway) то становится возможным делать очень интересные вещи, по сути внутри L2 сети, но из Интернета. Потому что транспортный уровень у нас стек TCP/IP и вот всё что возможно с ним сделать, в первую очередь спуфинг, можно сделать и внутри VXLAN (L2).
Итого для параноиков, сначала защищаем весь трафик внутри VXLAN от L2 до L7, а потом делаем то же для сети по которой VXLAN бежит - VXLAN in TLS over IP.

​HTTP/2 используется уже достаточно широко, а вот Server Push не очень. Механизм Server Push позволяет отправить данные до того момента как их запросит клиент, например, отправить файл CSS или графику в момент запроса index.html обходясь без самого момента запроса конкретного ресурса, экономя время.
Но вопрос экономит ли это на самом деле время и что надо сделать чтобы экономить - увеличить скорость загрузки страницы. Большая статья по этому поводу c исследованиями в лабораторной среде и на живом Интернете. И ситуация 50 на 50, всё очень сильно зависит от ресурса, его структуры и выбранного содержимого которое отправляется в Push. Например, Wikipedia удаётся значительно увеличить время загрузки страницы, а CNN наоборот при использовании Push его снижает.
Иными словами просто так включить не получится, придётся экспериментировать или думать. Но инструмент есть, осталось научиться его использовать.

Peter Welcher про дизайн сети, в основном в рамках подхода Cisco ACI. Несколько принципов и объяснение позиции. Самые дискуссионные:  не маршрутизируйте на серверах, виланы полезны - но там написано почему такой дизайн имеет место быть. Будьте проще.
Про документирование очень хорошо написано. Специалисту (инженеру) часто свойственно зарываться в детали, итогом получается что общая картина (если не поддерживать адекватный уровень документирования) теряется, что в итоге приводит к умножению деталей и усложнению всей структуры. А если вы не можете понятно описать дизайн сети, то вероятно он не такой хороший.

Сходите ещё на Design Zone Cisco, где много документов описывающих как надо проектировать сети: диаграммы и парадигмы на разные случаи. Ссылки или на документы или на другие статьи на Cisco.com.