Патчкорд

IPv6 сканировать сложно, но можно. Один из способов это стать публичным общедоступным сервисом, например, опубликоваться в NTP пуле и собирать адреса всех кто обращается, а потом уже их сканировать. Поиск и исследование таких серверов выполняется в этой публикации, в конце даже советуют как быть. Отметим только что NTP не единственный механизм, любой публичный сервис таит в себе такую опасность.

Помимо проверок достоверности путей и принадлежности префиксов в BGP, о чём мы много говорим и для чего мы уже много сделали, есть и другие способы как эффективно завалить BGP глобально, от которых у нас нет никакой защиты, ни сейчас, ни в ближайшем будущем, ни возможно вообще в рамках технических решений. Об этом в блоге RIPE Labs или целиком в обширной публикации с примерами.

Можно ли используя простые пинги определить к какой подсети IPv4 принадлежит адрес? Можно, основываясь на специфических реализациях у разных производителей. А также, используя не совсем простые пинги всё ещё работающего, как оказалось, ICMP type 17/18 Address Mask.

Juniper рассказывает, что если использовать Active Lease Query (RFC 7724 и RFC 7653) вместе EVPN VPWS на их BNG, то можно не переавторизовывать по DHCP пользователей IPoE. Но всё остальное в их тесте на 64000 абонентов, по 32K IPoE и PPPoE не так идеально. Маршрутизация сходится минуту, PPPoE за три, CGNAT заводится на новых адресах, что приводит к разрывам сессий. В целом, это очень быстро, заметно, но быстро при такой аварии для провайдера. Стоило ли биться именно за DCHP, наверное да, чтобы в два раза снизить лавинообразную нагрузку на сервер авторизации, которому только PPPoE придётся заниматься, и не бояться, что абоненты зависнут без интернета ожидая завершения жизни выданных им по DHCP адресов и не будут в ручную перезагружать свои устройства.

Если ещё есть сисадмины, кто-то выжил - с праздником вас, я с вами.

В Cloudflare продолжают бороться за чистоту Интернета, на этот раз в поле зрения BGP ORIGIN, который многие перезаписывают как им хочется, а не так как написано в RFC.

Ещё одна статья про то что стоит перейти на IPv6, ровно такая же как и все остальные, хотя автор пытается донести это по другому, пересказывая и делясь впечатлениями от увиденного выступления на конференции CHI-NOG 13. IPv4 когда нибудь кончатся совсем, но это не точно, хотя у кого-то уже кончились, но они нашли другой выход. Дуалстек это переходный момент, неизвестно насколько, но об этом не стоит забывать. Кажется что IPv6 быстрее, но имеет всё ещё очевидные технические проблемы, например, со множественным подключением к разным провайдерам без BGP. Как бы то ни было IPv6 уже здесь, для тех кто хочет, а остальные догонят, когда нибудь. Про ipv6.army мы уже упоминали, работает до сих пор не очень.

Трассировка трафика внутри Linux для конкретного процесса. Показывает сколько времени занимают syscall, прерывания, планировщик и собственно передача трафика. Внутри eBPF, снаружи Go.

А Китай решил подписать все свои префиксы, что собственно почти и сделал.

Juniper показывает и рассказывает про механизмы безопасности BGP: ROV, роли и ASPA. Для ASPA ещё нет публичной реализации Junos, как нет и номера RFC, но можно оценить на картинках.

Вы можете держать собственный сервер с ресурсами RPKI, а не пользоваться тем что предоставляет RIR. Обзор таких серверов, на которых меньше 1300 записей ROA, некоторые рассмотрены чуть более внимательно.

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

Обширная статья про то, что надо настроить в Arista 7280SR3K для использования в качестве пограничного Интернет маршрутизатора и вторая статья, почему надо сделать именно так.

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

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

Если апдейты BGP по BMP загнать в базу данных, то, конечно, искать ответы на вопрос: "Что было три недели назад?" - станет проще. Автор показывает решение для MongoDB, ещё будут нужны Kafka и GoBMP, но только показывает, попробовать можно обратившись к нему с запросом.

Дополнение к RFC 8950 для конечных хостов, чтобы отправлять трафик IPv4 напрямую маршрутизатору IPv6, получая его MAC адрес из таблицы соседств IPv6, без использования ARP. Для этого предлагается использовать специальный адрес 192.0.0.11 в качестве шлюза по умолчанию на хосте, который подскажет сетевому стеку как надо поступить. Всё это в очень ранней стадии, ещё даже до утверждения проекта как такового, поэтому всех заинтересованных зовут пообсуждать на IETF 126 проходящей прямо сейчас.

в соседнем чатике поделились прошлогодней статейкой про IPv6, любопытная https://www.indata.org.ru/stradaniya-po-ipv6-ili-30-let-ipv6/ казалось бы, есть технология - берите и используйте, но увы, люди склонны находить "любимчиков" даже в протоколах :) и ооооооооооочень не любят что-то менять, понимаю... видел неоднократно инфраструктуры на IPv4, где уже количество хостов и машин явно превышало изначально запланированное и где идёт борьба за каждую /24, где стараются экономить буквально на всём, начиная от p2p адресов, до подсетей на сервера и даже переиспользуют текущие подсети в изолированных друг от друга сегментах это всё конечно не есть хорошо, и очевидно в тот или иной момент времени может приводить к разным последствиям, изолированные сегменты внезапно должны быть смешаны по какому-то невероятному стечению обстоятельств и вот вы уже ставите на границе NAT, или запланированные /26 на сегмент, внезапно начинают мигрировать в K8s и там получается расход сильно выше, ну и многое другое. в общем, это я всё к чему, если у вас небольшая сетевая инфра, ну не знаю, пара офисов, несколько стоек в машзале, то конечно не нужен вам никакой IPv6, или допустим уже эксплуатируете одну и ту же сеть 15 лет, она устоявшаяся, не растёт как грибы и оставшегося запаса адресов вам достаточно, то не надо ничего ломать ради какого-то непонятного профита, оставляйте всё как есть, без шуток но, если вы строите гринфилд и у вас изначально планируется несколько машзалов или ЦОДов и расход адресов на этапе стройки уже видится как десятки, а то и сотни тысяч префиксов, то кажется стоит сразу думать про IPv6, хотя бы просто посчитайте и сравните, может и не подойдёт он вам, но вы будете точно понимать, а не просто делать как привыкли ну и вот в качестве примера наш underlay, весь на IPv6 и в GRT нет IPv4 вообще

xxx#sh ip route
...
IP Route Table for VRF "default"
C            127.0.0.0/8 is directly connected 

Gateway of last resort is not set
xxx#

так что, не бойтесь вы этих протоколов, они оба, что IPv4, что IPv6 всего лишь инструменты в наших с вами руках P.S. а ещё относительно недавно был зафиксирован случай, когда использование IPv6 по всему миру превысило 50% - https://habr.com/ru/news/1024624/

Via - ещё один traceroute/mtr. Написан на Go, всё красиво раскрашено, есть ICMP/TCP/UDP, показ номеров AS, обнаружение ECMP. Если задумаете попробовать написать что-то сетевое, вы знаете с чего начать.

Лёгкое я бы сказал расслабляющее чтение про OSPF, насколько это вообще возможно. Упомянуты процессы установки соединения, некоторые LSA и вычисление стоимости с поправкой на reference bandwidth. Ещё зачем-то бесклассовая маршрутизация, кто помнит тот помнит.