Кратко

  • RFC 3315 позволял клиенту DHCPv6 запросить обмен Solicit–Reply вместо обычного Solicit–Advertise–Request–Reply, однако сервер мог не принимать такое ускорение согласно своей политике и конфигурации.
  • При Rapid Commit сервер закреплял аренду до отправки Reply. Несколько серверов могли закрепить адреса, хотя клиент пользовался арендой только одного; потерянный ответ также разделял состояние сервера и то, что получил клиент.

Четыре сообщения образовывали не просто более длинную версию того же действия. После Solicit клиент получал Advertise от доступных серверов, сравнивал варианты и выбирал сервер сообщением Request. Reply подтверждал назначение уже после выбора. Опубликованный в июле 2003 года RFC 3315 определил DHCP для IPv6 и предусмотрел сокращённый маршрут, но не сделал его обязательным.

Клиент мог поместить в Solicit опцию Rapid Commit нулевой длины, показывая готовность немедленно принять Reply. Это было пожелание, а не команда серверам. Каждый сервер продолжал учитывать административную политику и собственную конфигурацию. Если он не был настроен закреплять ресурсы в таком обмене, то мог проигнорировать опцию, отправить Advertise и оставить клиенту обычный выбор. Сервер, принимавший Rapid Commit, закреплял назначенные ресурсы до передачи Reply.

Порядок и создавал компромисс. Получив корректный Reply с Rapid Commit, клиент мог использовать указанные адрес и параметры, не отправляя Request. Но сервер не получал следующего сообщения, которое подтверждало бы доставку Reply клиенту. RFC 3315 отдельно описывает последствия нескольких ответов на один Solicit: каждый сервер может закрепить адреса, а клиент использует аренду лишь одного из них. Остальные остаются закреплёнными без использования. Если Reply теряется в пути, у сервера может остаться запись о назначении, на основании которого клиент ничего не получил.

Сокращение обмена не убирало неопределённость, а перемещало её. В обычной последовательности Advertise–Request клиент выбирал предложение до окончательного назначения. В Rapid Commit сервер закреплял ресурс раньше, и при независимых ответах нескольких серверов нагрузка на пулы могла возникнуть до того, как стало понятно, какой ответ клиент получил и использовал. Это не доказывает ни столкновения адресов, ни ущерба от каждой лишней аренды. Это описанный протоколом сценарий, который важен для проектирования службы.

RFC 3315 отмечает, что службы с Solicit–Reply обычно устраивают так, чтобы отвечал только один сервер. Среди способов уменьшить число неиспользованных назначений названы также более короткие начальные сроки аренды. Это меры управления, а не гарантия единственного сервера или общей базы состояния. Короткий путь предсказуемее, когда состав ответчиков выбран сознательно.

В 2005 году RFC 4039 добавил Rapid Commit для DHCPv4, указав на сценарии с высокой мобильностью и частой сменой точки подключения. Он также пояснил ценность обычного четырёхсообщенного обмена: предложения резервных серверов остаются предварительными, пока клиент не выбрал одно. Это показывает родство механизмов, а не повсеместное внедрение или измеренный выигрыш во времени запуска. RFC 8415 объединил спецификацию DHCPv6 в 2018 году; в 2026 году его сменил RFC 9915, сохранив возможность клиентского запроса, решение сервера и предупреждение о закреплённых, но неиспользованных адресах.

Поэтому история Rapid Commit — не только об уменьшении задержки. Важно, когда сервер закрепляет ресурс, сколько серверов могут это сделать и какие данные подтверждают обеим сторонам, что клиент действительно получил и использовал назначение. Сэкономленный обмен — это одновременно утраченный этап выбора и подтверждения.

Источники: RFC 3315, RFC 4039, RFC 8415 и RFC 9915.