VLAN из прошлой части режет один коммутатор на много сетей. Но у него два ограничения, которые в дата-центре становятся стенами. Первое — номеров всего 4094, а облачный провайдер хочет изолированную сеть каждому клиенту, и клиентов у него сотни тысяч. Второе важнее: VLAN — это L2, и она заканчивается там, где начинается роутер. Виртуальная машина, переезжающая с сервера в одной стойке на сервер в другой, хочет сохранить IP-адрес и остаться в «своей» сети, а между стойками — маршрутизаторы. Растягивать L2 через весь дата-центр на VLAN и STP значит получить один огромный домен широковещания с одним деревом STP, и это не работает уже на нескольких сотнях коммутаторов.
VXLAN, Virtual eXtensible LAN, RFC 7348, решает обе задачи одним приёмом из первой части — протокол внутри протокола: кадр Ethernet заворачивается в UDP-датаграмму и едет через любую IP-сеть, как обычный пакет. Для хостов внутри это L2-сегмент, для сети снаружи — UDP-трафик между серверами.
Во второй части коммутатор делил домены коллизий, но не домен широковещания: ARP-запрос, DHCP DISCOVER и Router Advertisement получали все, кто воткнут в коммутатор. Один коммутатор — одна сеть, одна подсеть IP. В офисе с бухгалтерией, гостевым Wi-Fi, телефонами и серверами это означало бы по коммутатору и по кабелю на каждую сеть. VLAN, Virtual LAN, IEEE 802.1Q, решает задачу иначе: один коммутатор и один кабель несут несколько независимых сетей, которые друг друга не видят, как будто это разные коммутаторы. Это самая часто используемая технология сегментации, и, как обычно, нас интересует, что для этого добавили в кадр и что делает с ним коммутатор.
SLAAC из прошлой части даёт хосту адрес, шлюз и DNS без единого сервера, и для дома этого достаточно. Но у безсерверности есть цена: никто не знает, какой адрес у какого устройства, набор параметров ограничен, а роутер абонента должен откуда-то получить свой блок префиксов. Для этого в IPv6 есть DHCPv6, RFC 8415. Название обещает «тот же DHCP», но это другой протокол: у него свой формат, свои идентификаторы клиентов, свои режимы и, главное, он не заменяет Router Advertisement, а дополняет. Без RA из четырнадцатой части DHCPv6-клиент даже не начнёт работать.
Чтобы было с чем сравнивать, держите под рукой DHCPv4.
В четырнадцатой части роутер рассылал Router Advertisement, и в нём был префикс сегмента с флагом auto: «из этого префикса можно собрать себе адрес». Сегодня — о том, как хост это делает. Механизм называется SLAAC, Stateless Address Autoconfiguration, RFC 4862, и слово «stateless» в нём главное: никто не хранит, кому какой адрес выдан. Нет сервера, нет аренд, нет таблицы. Роутер говорит «префикс такой», хост сам придумывает вторую половину адреса, проверяет, что она свободна, и начинает работать. Для домашней сети и для телефонов это основной и часто единственный способ получить адрес IPv6.
Половину механизма мы уже знаем: RA и DAD из прошлой части. Осталось понять, откуда берётся вторая половина адреса и как адреса живут и умирают.
В тринадцатой части мы узнали, что в IPv6 нет широковещания, что на каждом интерфейсе всегда есть link-local адрес и что шлюз по умолчанию хост получает не из настроек, а «из объявления роутера». Всё это держится на одном протоколе — ICMPv6, RFC 4443, который в IPv6 делает работу сразу трёх протоколов из блока про IPv4: ICMP (ошибки и ping), ARP (поиск MAC-адреса соседа) и той части DHCP, которая сообщает хосту о шлюзе. Для последних двух задач внутри ICMPv6 живёт набор сообщений, который называют Neighbor Discovery Protocol, NDP, RFC 4861.
Именно поэтому фраза «запретить ICMP на файрволе», которая в IPv4 ломала только Path MTU Discovery, в IPv6 ломает всё: без ICMPv6 хост не найдёт ни соседа, ни роутер.
В пятой части мы закончили на том, что 4,3 миллиарда адресов IPv4 кончились в 2011 году, а в шестой — на NAT, которым эту нехватку латают. Ответ, задуманный ещё в 1990-х и ставший окончательным, — IPv6, RFC 8200. Это не «IPv4 с длинными адресами»: вместе с адресами переделали заголовок, убрали широковещание, запретили роутерам фрагментировать, встроили автонастройку и выкинули NAT как идею. Блок из четырёх частей начнём с адресов и заголовка; протоколы, которые делают IPv6 живым, — Neighbor Discovery, SLAAC и DHCPv6 — в следующих.
Серия про IPv4 была длинной не зря: почти всё из неё здесь пригодится, а отличия будут видны на контрасте.
Всё, что мы разбирали до сих пор, работало с адресами: 203.0.113.10. Люди адресами не пользуются, они набирают www.example.com. Кто-то должен перевести одно в другое, и это DNS — Domain Name System, RFC 1034 и 1035, 1987 год. DNS — первое, что делает браузер при открытии страницы, первое, что ломается при неправильной настройке сети, и самая большая распределённая база данных в мире: несколько сотен миллионов имён, ни одного центрального сервера, и ответ за десятки миллисекунд из любой точки планеты.
Как в прошлых частях, нас интересует не «DNS превращает имена в адреса», а как именно: кто хранит, кто спрашивает, что едет в пакете.
Во всех предыдущих частях у хоста уже был адрес 192.168.1.10, маска /24, шлюз 192.168.1.1 и адрес DNS-сервера. Откуда? В пятой части мы видели, что всё это можно задать руками, и в серверных сетях так и делают. Но ноутбук, который утром в офисе, днём в кафе, а вечером дома, руками не настроишь: в каждой сети у него должен быть свой адрес из её диапазона и её шлюз. Эту работу делает DHCP — Dynamic Host Configuration Protocol, RFC 2131. Он же причина, по которой домашняя сеть «просто работает»: роутер раздаёт адреса, а вы об этом не думаете.
Задача выглядит парадоксально: чтобы получить адрес, нужно отправить запрос, а отправить IP-пакет без адреса нельзя. Посмотрим, как это обходят.
На этой неделе я включил HTTP/3 на Traefik в своём кластере, и по дороге пришлось заново разложить в голове, чем три живущие одновременно версии HTTP отличаются друг от друга и зачем вообще нужна третья, если вторая появилась десять лет назад. Это та самая раскладка: как устроена каждая версия, какую проблему предыдущей она решает, когда одна быстрее другой, как всё это настраивается в Traefik и на какие грабли я наступил или успел заметить заранее.
Статья самостоятельная, но опирается на две части серии «Сети для самых маленьких»: про UDP и про TCP. Там подробно про соединения, потери и окна; здесь будем на них ссылаться.
В девятой части UDP добавил к IP только порты и ничего больше: пакет либо дошёл, либо нет. Для большинства приложений этого мало. Файл должен прийти целиком, байты — в том порядке, в котором отправлены, и отправитель не должен заваливать получателя и сеть быстрее, чем они справляются. Всё это делает TCP, Transmission Control Protocol, RFC 793 (сейчас — RFC 9293), и делает поверх того же ненадёжного IP, который теряет, дублирует и переставляет пакеты.
Разговор будет долгим, потому что TCP — это не формат, а алгоритм: набор правил, по которым две стороны договариваются, нумеруют байты, подтверждают, повторяют и притормаживают. Пойдём по жизни соединения: заголовок, установление, передача, надёжность, скорость, закрытие — и в конце посмотрим на всё это в одном захвате.