RFC 8415 | Протокол динамической конфигурации хоста для IPv6 (DHCPv6)

Резюме

В этом документе описывается протокол конфигурации динамического хоста для IPv6 (DHCPv6): расширяемый механизм для настройки узлов с параметрами сетевой конфигурации, IP-адресами и префиксами.

Скачать оригинальный документ на английском языке RFC 8415 PDF


Параметры могут предоставляться без учета состояния или в сочетании с назначением состояния одного или нескольких адресов IPv6 и/или префиксов IPv6. DHCPv6 может работать как вместо, так и в дополнении к бесструктурным адресам авто-конфигурации (SLAAC).

Этот документ обновляет текст из RFC 3315 (исходная спецификация DHCPv6) и включает в себя делегирование префикса (RFC 3633), без учета состояния DHCPv6 (RFC 3736), возможность указать верхнюю границу времени ожидания клиента перед обновлением информации (RFC 4242 ), механизм дросселирования клиентов DHCPv6, когда служба DHCPv6 недоступна (RFC 7083) и обработка агента ретрансляции неизвестными сообщениями (RFC 7283).

Кроме того, в этом документе разъясняются взаимодействия между моделями работы (RFC 7550). Таким образом, этот документ сделал устаревшими RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283 и RFC 7550.

Оглавление

1. Введение
1.1 Связь с предыдущими стандартами DHCPv6
1.2 Связь с DHCPv4
2. Требования
3. Происхождение
4. Терминология
4.1 Терминология IPv6
4.2 Терминология DHCP
5. Клиентские и серверные обмены
5.1 Клиентские / серверные обмены с участием двух сообщений
5.2 Клиентские / серверные обмены с участием четырех сообщений
5.3 Серверные / клиентские обмены
6. Операционные модели
6.1 Неутверждённый (Безстоящий) DHCP
6.2 DHCP для назначения несрочного адреса
6.3 DHCP для префиксной передачи
6.4 DHCP для клиентских пограничных маршрутизаторов
6.5 DHCP для временных адресов
6.6 Несколько адресов и префиксов
7. Константы DHCP
7.1 Адреса мультивещания
7.2 Порты UDP
7.3 Типы сообщений DHCP
7.4 Коды опций DHCP
7.5 Коды состояния
7.6 Параметры передачи и повторной передачи
7.7 Представление значений времени и «бесконечности» в качестве значения времени
8. Форматы сообщений клиента / сервера
9. Форматы сообщений ретранслятора / сервера
9.1 Сообщение о пересылке
9.2 Сообщение с ретрансляцией
10. Представление и использование доменных имен
11. Уникальный идентификатор DHCP (DUID)
11.1 Содержимое DUID
11.2 DUID, основанный на канале Link Plus Layer (DUID-LLT)
11.3 DUID, назначенный поставщиком на основе корпоративного номера (DUID-EN)
11.4 DUID на основе адреса Link-Layer (DUID-LL)
11.5 DUID на основе универсального уникального идентификатора (DUID-UUID)
12. Идентификационная ассоциация
12.1 Ассоциации удостоверений для назначения адресов
12.2 Ассоциации удостоверений для префиксной передачи
13. Назначение IA
13.1 Выбор адресов для присвоения IA_NA
13.2 Назначение временных адресов
13.3 Назначение префиксов для IA_PD
14. Передача сообщений клиентом
14.1 Ограничение скорости
14.2 Поведение клиента, когда T1 и / или T2 равны 0
15. Надежность обменов сообщениями, инициированными клиентом
16. Проверка сообщений
16.1 Использование идентификаторов транзакций
16.2 Сообщение «Запросить впервые» (Solicit Message)
16.3 Сообщение «Рекламировать» (Advertise Message)
16.4 Сообщение «Запросить» (Request Message)
16.5 Сообщение «Подтвердить» (Confirm Message)
16.6 Сообщение «Обновить» (Renew Message)
16.7 Сообщение «Пересвязать» (Rebind Message)
16.8 Сообщение «Отклонить» (Decline Message)
16.9 Сообщение «Выпустить» (Release Message)
16.10 Сообщение «Ответить» (Reply Message)
16.11 Сообщение «Переконфигурировать» (Reconfigure Message)
16.12 Сообщение «Запрос информации» (Information-request Message)
16.13 Сообщение о пересылке «Пересылать» (Relay-forward Message)
16.14 Сообщение с ретрансляцией «Ретранслировать» (Relay-reply Message)
17. Исходный адрес и выбор интерфейса клиента
17.1 Исходный адрес и выбор интерфейса для назначения адреса
17.2 Исходный адрес и выбор интерфейса для делегирования префикса
18. Обмен конфигурациями DHCP
18.1 Единый обмен для нескольких вариантов IA
18.2 Поведение клиента
18.2.1 Создание и передача сообщений первичных запросов
18.2.2 Создание и передача сообщений запроса
18.2.3 Создание и передача подтверждающих сообщений
18.2.4 Создание и передача сообщений обновления
18.2.5 Создание и передача сообщений пересвязывания
18.2.6 Создание и передача сообщений информационных запросов
18.2.7 Создание и передача сообщений о выпуске
18.2.8 Создание и передача сообщений об отказе
18.2.9 Получение рекламных сообщений
18.2.10 Получение сообщений ответа
18.2.10.1 Ответ на запрос (с быстрой фиксацией), запрос, обновление или пересвязывание
18.2.10.2 Ответ для выпуска и отклонения
18.2.10.3 Ответ для подтверждения
18.2.10.4 Ответ для запроса информации
18.2.11 Получение реконфигурированных сообщений
18.2.12 Обновление информации о конфигурации
18.3 Поведение сервера
18.3.1 Получение сообщений о первичном запросе (поиске)
18.3.2 Получение сообщений о запросе
18.3.3 Получение подтверждающих сообщений
18.3.4 Получение обновлений
18.3.5 Получение сообщений пересвязи
18.3.6 Получение сообщений с инфо-запросом
18.3.7 Получение сообщений о выпуске
18.3.8 Получение сообщений об отклонении
18.3.9 Создание рекламных сообщений
18.3.10 Передача сообщений о рекламе и ответах
18.3.11 Создание и передача сообщений реконфигурации
18.4 Прием одноадресных сообщений
19. Поведение агента передачи
19.1 Ретрансляция сообщения клиента или ретрансляционного сообщения
19.1.1 Передача сообщения от клиента
19.1.2 Передача сообщения от ретрансляционного агента
19.1.3 Поведение агента ретрансляции с префиксом делегирования
19.2 Ретрансляция сообщения с ретрансляцией
19.3 Построение ретрансляционных сообщений
19.4 Взаимодействие между агентами передачи и серверами
20. Аутентификация DHCP сообщений 
20.1 Безопасность сообщений, отправленных между серверами и агентами ретрансляции
20.2 Сводка проверки подлинности DHCP
20.3 Обнаружение воспроизведения
20.4 Протокол аутентификации ключа реконфигурации (RKAP)
20.4.1 Использование опции проверки подлинности в RKAP
20.4.2 Серверные соображения для RKAP
20.4.3 Клиентские соображения для RKAP
21. Параметры DHCP
21.1 Формат параметров DHCP
21.2 Параметр Идентификатора клиента
21.3 Параметр Идентификатора сервера
21.4 Параметр Идентификационной ассоциации для несрочных адресов
21.5 Параметр Идентификационной ассоциации для временного адреса
21.6 Параметр IA Address
21.7 Параметр Запроса
21.8 Параметр Предпочтения
21.9 Параметр Истекшее время
21.10 Параметр Ретрансляционного сообщения
21.11 Параметр Аутентификации
21.12 Параметр одно-адресной передачи сервера
21.13 Параметр кода состояния
21.14 Параметр быстрой фиксации
21.15 Параметр пользовательского класса
21.16 Параметр класса поставщика
21.17 Параметр Специфической для поставщика информации
21.18 Параметр интерфейса-идентификатора
21.19 Параметр сообщения Реконфигурации
21.20 Параметр приема Реконфигурации
21.21 Параметр Идентификационной ассоциации для делегирования префикса
21.22 Параметр префикса IA
21.23 Параметр времени обновления информации
21.24 Параметр SOL_MAX_RT
21.25 Параметр INF_MAX_RT
22. Вопросы безопасности
23. Вопросы конфиденциальности
24. Вопросы IANA
25. Обобщенные механизмы
26. Рекомендации
26.1 Нормативные ссылки
26.2 Информационные ссылки
Приложение A
Приложение B
Приложение C
Признательность
Авторы и адреса

Статус этой заметки

Это документ курса стандартов Интернета.

Этот документ является продуктом Целевой группы Internet Engineering Task Force (IETF). Он представляет собой консенсус сообщества IETF. Он получил публичный обзор и был одобрен для публикации Руководящей группой Internet Engineering Steering Group (IESG). Дополнительная информация о стандартах Интернета приведена в разделе 2 RFC 7841.

Информацию о текущем состоянии этого документа, о любых ошибках и способах предоставления обратной связи по нему можно получить по адресу https://www.rfc-editor.org/info/rfc8415.

Уведомление об авторских правах

Copyright (c) 2018 IETF Trust и лица, идентифицированные как авторы документа. Все права защищены.

Этот документ подлежит BCP 78 и правовым положениям IETF Trust, относящимся к документам IETF (https://trustee.ietf.org/license-info), действующим на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, поскольку они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя упрощенный текст лицензии BSD, как описано в разделе 4.e Доверенных правовых положений, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

Этот документ может содержать материалы из документов IETF или IETF Contributions, опубликованные или опубликованные до 10 ноября 2008 года. Лицо (лица), контролирующие авторское право в некоторых из этих материалов, возможно, не предоставило IETF Trust право разрешать модификации такого материала вне процесса стандартов IETF.

Без получения адекватной лицензии от лица (лиц), контролирующего авторское право в таких материалах, этот документ не может быть изменен за пределами Процесса стандартов IETF, и его производные работы не могут создаваться вне процесса стандартов IETF, за исключением того, чтобы отформатировать его для публикации в качестве RFC или для перевода на другие языки, кроме английского.

1. Введение

В этом документе описывается DHCP для протокола IPv6 (DHCPv6), клиент-серверный протокол, который обеспечивает управляемую конфигурацию устройств. Базовая операция DHCPv6 обеспечивает конфигурацию для клиентов, подключенных к тому же каналу связи, что и сервер. Функциональность агента ретрансляции также определена для обеспечения связи между клиентами и серверами, которые не находятся на одном и том же канале связи.

DHCPv6 может предоставить устройство с адресами, назначенными сервером DHCPv6 и другой информацией о конфигурации; эти данные переносятся в опциях. DHCPv6 можно расширить с помощью определения новых параметров для переноса информации о конфигурации, не указанной в этом документе.

DHCPv6 также обеспечивает механизм автоматического делегирования префиксов IPv6 с использованием DHCPv6, как первоначально указано в [RFC3633]. Благодаря этому механизму делегирующий маршрутизатор может делегировать префиксы запрашивающим маршрутизаторам. Использование этого механизма указано как часть [RFC7084] и [TR-187].

DHCP также может использоваться только для предоставления других параметров конфигурации (то есть без адресов или префиксов). Это означает, что сервер не должен отслеживать состояние; таким образом, этот режим называется «Без состояния DHCPv6» (Stateless DHCPv6). Механизмы, необходимые для поддержки неактивных DHCPv6, намного меньше механизмов, необходимых для поддержки состояния DHCPv6. [RFC3736] был написан для документирования только тех частей DHCPv6, которые необходимы для поддержки операции без сохранения по протоколу DHCPv6.

Остальная часть этого введения суммирует связь с предыдущими стандартами DHCPv6 (см. Раздел 1.1) и разъясняет позицию относительно DHCPv4 (см. Раздел 1.2). Раздел 5 описывает механизмы обмена сообщениями, чтобы проиллюстрировать работу DHCP, а не предоставлять исчерпывающий список всех возможных взаимодействий, а в разделе 6 представлен общий обзор общих операционных моделей. Раздел 18 подробно описывает работу клиента и сервера.

1.1 Связь с предыдущими стандартами DHCPv6

Первоначальная спецификация DHCPv6 была определена в [RFC3315], и за эти годы был опубликован ряд последующих документов:

  • [RFC3633] («Параметры префикса IPv6 для протокола динамической конфигурации хоста (DHCP) версии 6»)
  • [RFC3736] («Служба протокола динамической конфигурации динамического хоста (DHCP) для IPv6»)
  • [RFC4242] («Опция обновления информации для протокола динамической конфигурации хоста для IPv6 (DHCPv6)»)
  • [RFC7083] («Изменение значений по умолчанию для SOL_MAX_RT и INF_MAX_RT»)
  • [RFC7283] («Обработка неизвестных сообщений DHCPv6»)
  • [RFC7550] («Проблемы и рекомендации с несколькими параметрами DHCPv6 с несколькими состояниями»)

Этот документ содержит унифицированное, исправленное и очищенное определение DHCPv6, которое также охватывает все применимые ошибки, поданные против более старых RFC (см. Список в Приложении A). Таким образом, он убирает RFC, перечисленные в предыдущем абзаце. Кроме того, существует небольшое количество механизмов, которые устарели; см. раздел 25 и приложение А.

1.2 Связь с DHCPv4

Операционные модели и соответствующая информация конфигурации для DHCPv4 [RFC2131] [RFC2132] и DHCPv6 достаточно различны, что интеграция между этими двумя службами не включена в этот документ. [RFC3315] предположил, что будущей работой может быть расширение DHCPv6 для переноса адресов IPv4 и информации о конфигурации. Однако нынешнее согласие IETF заключается в том, что DHCPv4 следует использовать вместо DHCPv6 при передаче информации конфигурации IPv4 узлам. В сетях с поддержкой IPv6 [RFC7341] описывается механизм транспорта для переноса сообщений DHCPv4 с использованием протокола DHCPv6 для динамического предоставления адресов IPv4 и информации о конфигурации.

Слияние настроек DHCPv4 и DHCPv6 выходит за рамки этого документа. [RFC4477] обсуждает некоторые проблемы и возможные стратегии совместной работы сервисов DHCPv4 и DHCPv6. Хотя [RFC4477] немного устарел, он дает хороший обзор проблем.

2. Требования

Ключевыми словами «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «NOT RECOMMENDED», «MAY», и «OPTIONAL»

(«ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «СЛЕДУЕТ», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО)в этом документе должны интерпретироваться, как описано в BCP 14 [RFC2119] [RFC8174], когда и только тогда, когда они отображаются во всех столицах, как показано здесь.

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

3. Происхождение

[RFC8200] («Протокол Интернета, версия 6 (IPv6)») обеспечивает базовую архитектуру и дизайн IPv6. В дополнение к [RFC8200], связанная работа в IPv6, которую лучший исполнитель должен изучить, включает:

  • [RFC4291] («Архитектура адресации IP версии 6»)
  • [RFC4862] («Автоконфигурация адресов без аутентификации IPv6»)
  • [RFC4861] («Соседнее обнаружение для IP-версии 6 (IPv6)»)

Эти спецификации позволяют DHCP использовать работу IPv6 для обеспечения надежной автоконфигурации с учетом состояния.

[RFC4291] определяет область адресов, которая может использоваться в реализации IPv6, а также предоставляет различные рекомендации по архитектуре архитектуры для сетевых дизайнеров адресного пространства IPv6. Два преимущества IPv6 заключаются в том, что требуется поддержка многоадресной рассылки, а узлы могут создавать локальные ссылки во время инициализации. Доступность этих функций означает, что клиент может использовать свой локальный адрес связи и известный многоадресный адрес для обнаружения и связи с серверами DHCP или ретрансляционными агентами по своей ссылке.

[RFC4862] указывает процедуры, с помощью которых узел может автоконфигурировать адреса на основе объявлений Router [RFC4861] и использовать допустимый срок службы для поддержки перенумерации адресов в Интернете. Совместимость с автоконфигурацией адресов без состояния — это требование к дизайну DHCP.

IPv6 Neighbor Discovery [RFC4861] — протокол обнаружения узлов в IPv6, который заменяет и улучшает функции ARP [RFC826]. Чтобы понять автоконфигурацию адреса IPv6 и безструктурного адреса, настоятельно рекомендуется, чтобы разработчики поняли IPv6 Neighbor Discovery.

4. Терминология

В этом разделе определяется терминология, специфичная для IPv6 и DHCP, используемых в этом документе.

4.1 Терминология IPv6

Терминология IPv6 из [RFC8200], [RFC4291] и [RFC4862], относящихся к этой спецификации, приведена ниже.

address

Идентификатор уровня IP для интерфейса или набора интерфейсов.

GUA

Глобальный адрес одноадресной рассылки (см. [RFC4291]).

host

Любой узел, который не является маршрутизатором.

IP

Протокол Интернета версии 6 (IPv6). Термины «IPv4» и «IPv6» используются только в тех контекстах, где необходимо избегать двусмысленности.

interface

Вложение узла в ссылку.

link

Средство связи или среда, по которой узлы могут взаимодействовать на уровне канала связи, то есть на уровне ниже IP. Примерами являются Ethernet (простой или мостовой); Линии PPP и PPP через Ethernet (PPPoE); и туннели (или более высокие) интернет-уровня (например, туннели по IPv4 или самому IPv6).

link-layer identifier

Идентификатор уровня канала связи для интерфейса — например, IEEE 802 для сетевых интерфейсов Ethernet или Token Ring.

link-local address

Адрес IPv6 с областью только для ссылок, обозначенной префиксом (fe80 :: / 10), который может использоваться для доступа к соседним узлам, прикрепленным к той же самой ссылке. Каждый интерфейс IPv6, на котором DHCPv6 может быть полезным, имеет локальный адрес ссылки.

multicast address

Идентификатор для набора интерфейсов (обычно принадлежащих разным узлам). Пакет, отправленный на многоадресный адрес, доставляется на все интерфейсы, идентифицированные этим адресом.

neighbor

Узел, прикрепленный к той же ссылке.

node

Устройство, реализующее IP.

packet

IP-заголовок плюс полезная нагрузка.

prefix

Исходные биты адреса или набор IP-адресов, которые имеют одни и те же начальные биты.

prefix length

Количество бит в префиксе.

router

Узел, который пересылает IP-пакеты, явно не адресован сам себе.

ULA

Уникальный локальный адрес (см. [RFC4193]).

unicast address

Идентификатор для одного интерфейса. Пакет, отправленный на одноадресный адрес, доставляется в интерфейс, указанный этим адресом.

4.2 Терминология DHCP

Терминологию, специфичную для DHCP, можно найти ниже.

appropriate to the link

Адрес «соответствует ссылке», когда адрес соответствует значению DHCP-сервера топологии сети, назначению префикса и политикам назначения адресов.

binding

Связывание (или привязка клиента) представляет собой группу записей данных сервера, содержащих информацию, которую сервер имеет о адресах или делегированных префиксах в Ассоциации удостоверений (IA) или информации конфигурации, явно назначенной клиенту. Информация о конфигурации, которая была возвращена клиенту с помощью политики, такой как информация, возвращаемая всем клиентам по одной и той же ссылке, не требует привязки. Связывание, содержащее информацию об IA, индексируется кортежем <DUID, IA-type, IAID> (где тип IA — тип аренды в IA — например, временный). Связывание, содержащее информацию о конфигурации для клиента, индексируется с помощью <DUID>. Ниже приведены определения DUID, IA и IAID.

configuration parameter

Элемент информации конфигурации, установленный на сервере и переданный клиенту с использованием DHCP. Такие параметры могут использоваться для переноса информации, которая будет использоваться узлом для настройки его сетевой подсистемы и, например, включения связи по линии связи или межсетевой сети.

container option

Опция, которая инкапсулирует другие параметры (например, параметр IA_NA (см. Раздел 21.4), может содержать параметры адреса IA (см. Раздел 21.6)).

delegating router

Маршрутизатор, который действует как DHCP-сервер и отвечает на запросы делегированных префиксов. В этом документе в основном используется термин «сервер DHCP» или «сервер» при обсуждении функциональности делегирования маршрутизатора делегирования префикса (см. Раздел 1).

DHCP

Протокол динамической конфигурации хоста для IPv6. Термины «DHCPv4» и «DHCPv6» используются только в контекстах, где необходимо избегать двусмысленности.

DHCP client

Также упоминается как «клиент». Узел, который инициирует запросы по ссылке для получения параметров конфигурации с одного или нескольких серверов DHCP. Узел может выступать в роли запрашивающего маршрутизатора (см. Ниже), если он поддерживает делегирование префикса.

DHCP domain

Набор ссылок, управляемых DHCP и управляемых одним административным объектом.

DHCP relay agent

Также упоминается как «агент ретрансляции». Узел, который выступает в качестве посредника для доставки сообщений DHCP между клиентами и серверами. В некоторых конфигурациях между клиентами и серверами может быть более одного агента ретрансляции, поэтому агент ретрансляции может отправлять DHCP-сообщения другому ретранслятору.

DHCP server

Также упоминается как «сервер». Узел, который отвечает на запросы клиентов. Он может быть или не быть на той же ссылке, что и клиент (ы). В зависимости от его возможностей, если он поддерживает делегирование префикса, он также может использовать функциональные возможности делегирующего маршрутизатора.

DUID

Уникальный идентификатор DHCP для участника DHCP. Каждый клиент и сервер DHCP имеет ровно один DUID. Подробные сведения о способах создания DUID см. В Разделе 11.

encapsulated option

Параметр DHCP, который обычно содержится только в другом варианте. Например, параметр IA Address содержится в параметрах IA_NA или IA_TA (см. Раздел 21.5). Более подробное определение см. В разделе 9 [RFC7227].

IA

Identity Association (Идентификационная ассоциация): коллекция договоров аренды, назначенных клиенту. Каждый IA имеет ассоциированный IAID (см. Ниже). Клиент может иметь более одного назначенного ему IA — например, по одному для каждого из своих интерфейсов. Каждый ИА имеет один тип аренды; например, ассоциация идентификации для временных адресов (IA_TA) содержит временные адреса, а ассоциация идентификации для делегирования префикса (IA_PD) содержит делегированные префиксы. Во всем этом документе «IA» используется для обозначения ассоциации идентификации, не определяя тип аренды в IA. На момент написания этого документа было определено три типа IA: IA_NA, IA_TA и IA_PD. Новые типы IA могут быть определены в будущем.

IA option(s)

На момент написания этого документа, один или несколько вариантов IA_NA, IA_TA и / или IA_PD. Новые типы IA могут быть определены в будущем.

IAID

Identity Association Identifier (Идентификатор Идентификационной ассоциации): идентификатор для IA, выбранный клиентом. Каждый IA имеет IAID, который выбран как уникальный среди IAID для IA определенного типа, принадлежащих этому клиенту.

IA_NA

Ассоциация идентификации для несрочных адресов: IA, которая несет назначенные адреса, которые не являются временными адресами (см. «IA_TA»). Подробнее о параметре IA_NA см. В разделе 21.4.

IA_PD

Ассоциация идентификации для префиксного делегирования: IA, который несет делегированные префиксы. Подробнее о опции IA_PD см. В разделе 21.21.

IA_TA

Ассоциация идентификации временных адресов: IA, которая содержит временные адреса (см. [RFC4941]). Подробнее о параметре IA_TA см. В разделе 21.5.

lease

Контракт, по которому сервер предоставляет использование адреса или делегированного префикса клиенту в течение определенного периода времени.

message

Единица данных, переносимая как полезная нагрузка дейтаграммы UDP, обменивается между серверами DHCP, агентами ретрансляции и клиентами.

Reconfigure key

Ключ, предоставляемый клиенту сервером. Используется для обеспечения безопасности для переконфигурации сообщений (см. Раздел 7.3 для списка доступных типов сообщений).

relaying

Агент ретрансляции DHCP передает DHCP-сообщения между участниками DHCP.

requesting router

Маршрутизатор, который действует как клиент DHCP и запрашивает префикс (ы), который должен быть назначен. В этом документе в основном используется термин «клиент DHCP» или «клиент» при обсуждении функциональности «запрашивающего маршрутизатора» делегирования префикса (см. Раздел 1).

retransmission

Еще одна попытка отправить одно и то же сообщение DHCP клиентом или сервером в результате не получения действительного ответа на ранее отправленные сообщения. Повторно переданное сообщение обычно изменяется до отправки, как того требуют спецификации DHCP. В частности, клиент обновляет значение параметра «Истекшее время» в повторно переданном сообщении.

RKAP

Протокол аутентификации ключа реконфигурации (см. Раздел 20.4).

singleton option

Опция, которая разрешается появляться только один раз в качестве опции верхнего уровня или на любом уровне инкапсуляции. Большинство вариантов — одиночные.

T1

Временной интервал, после которого ожидается, что клиент свяжется с сервером, который выполнял задание, продлить (продлить) время жизни назначенных адресов (с использованием опций IA_NA) и / или префиксов делегированных (через опции (IA_PD)), чтобы клиент. T1 выражается как абсолютное значение в сообщениях (в секундах), передается в контейнерах IA (в настоящее время опции IA_NA и IA_PD) и интерпретируется как временной интервал с момента приема пакета. Значение, хранящееся в поле T1 в вариантах IA, называется значением T1. Фактическое время истечения таймера называется временем T1.

T2

Временной интервал, после которого клиент, как ожидается, свяжется с любым доступным сервером, чтобы продлить (повторить) время жизни назначенных адресов (через опции (IA_NA)) и / или префиксы, делегированные (через опции IA_PD) клиенту. T2 выражается как абсолютное значение в сообщениях (в секундах), передается в контейнерах IA (в настоящее время опции IA_NA и IA_PD) и интерпретируется как временной интервал с момента приема пакета. Значение, сохраненное в поле T2 в опциях IA, называется значением T2. Фактическое время истечения таймера называется временем T2.

top-level option

Опция, переданная в сообщении DHCP напрямую, т. Е. Не инкапсулированная никаким другим вариантом, как описано в разделе 9 документа [RFC7227].

transaction ID

Недостаточное значение, используемое для сопоставления ответов с ответами, инициированными либо клиентом, либо сервером.

5. Клиентские и серверные обмены

Клиенты и серверы обмениваются сообщениями DHCP с использованием UDP (см. [RFC768] и BCP 145 [RFC8085]). Клиент использует локальный адрес или адреса связи, определенные с помощью других механизмов для передачи и приема сообщений DHCP.

Клиент DHCP отправляет большинство сообщений с использованием зарезервированного целевого адреса многоадресной передачи с привязкой к ссылкам, чтобы клиент не мог быть настроен с адресом или адресами DHCP-серверов.

Чтобы клиент DHCP мог отправить сообщение на сервер DHCP, который не подключен к той же ссылке, агент ретрансляции DHCP на ссылке клиента будет ретранслировать сообщения между клиентом и сервером. Работа ретрансляционного агента прозрачна для клиента. Обсуждение обменов сообщениями в оставшейся части этого раздела опускает описание ретрансляции сообщений ретрансляционными агентами.

Как только клиент определил адрес сервера, он может при некоторых обстоятельствах отправлять сообщения непосредственно на сервер с помощью одноадресной рассылки.

5.1 Клиентские / серверные обмены с участием двух сообщений

Если клиенту DHCP не требуется, чтобы DHCP-сервер назначал ему IP-адреса или делегированные префиксы, клиент может получить другую информацию о конфигурации, такую как список доступных DNS-серверов [RFC3646] или NTP-серверов [RFC5908], через одно сообщение и обмен ответами с сервером DHCP. Для получения другой информации о конфигурации клиент сначала отправляет сообщение «Информация-запрос» на многоадресный адрес All_DHCP_Relay_Agents_and_Servers. Серверы отвечают на сообщение «Ответ», содержащее другую конфигурационную информацию для клиента.

Клиент может также запрашивать у сервера ускорение назначения адреса и / или префикса делегирования, используя обмен двух сообщений вместо обычного обмена четырьмя сообщениями, как описано в следующем разделе. Ускоренное присвоение может быть запрошено клиентом, а серверы могут или не могут выполнить запрос (подробнее см. Разделы 18.3.1 и 21.14 и почему серверы не могут выполнить этот запрос). Клиенты могут запросить эту ускоренную услугу в тех средах, где, вероятно, есть только один сервер, доступный по ссылке, и не ожидается, что второй сервер станет доступным или когда процесс настройки как можно быстрее станет приоритетом.

Чтобы запросить ускоренный обмен двумя сообщениями, клиент отправляет сообщение «Запросить» на адрес многоадресной рассылки All_DHCP_Relay_Agents_and_Servers, запрашивая назначение адресов и / или делегированных префиксов и другую информацию о конфигурации. Это сообщение содержит указание (опция Rapid Commit, см. Раздел 21.14), что клиент готов принять немедленное ответное сообщение с сервера. Сервер, который желает передать назначение адресов и / или делегированных префиксов клиенту, немедленно отвечает сообщением «Ответ». Конфигурационная информация, а также адреса и / или делегированные префиксы в ответном сообщении затем сразу доступны для использования клиентом.

Каждый адрес или делегированный префикс, назначенный клиенту, связывает предпочтительные и действительные сроки жизни, указанные сервером. Чтобы запросить продление срока службы, назначенного на адрес или делегированный префикс, клиент отправляет на сервер сообщение «Обновление» Renew. Сервер отправляет клиенту ответное сообщение с новыми сроками службы, позволяя клиенту продолжать использовать адрес или делегированный префикс без перерыва. Если сервер не может продлить срок службы адреса или делегированного префикса, он указывает это, возвращая адрес или делегированный префикс с временем жизни 0. В то же время сервер может назначать другие адреса или делегированные префиксы.

См. Раздел 18 для описания дополнительных обменов двумя сообщениями между клиентом и сервером.

5.2 Клиентские / серверные обмены с участием четырех сообщений

Чтобы запросить назначение одного или нескольких адресов и / или делегированных префиксов, клиент сначала находит DHCP-сервер, а затем запрашивает назначение адресов и / или делегированных префиксов и другой информации о конфигурации с сервера. Клиент отправляет сообщение «Запросить» на многоадресный адрес All_DHCP_Relay_Agents_and_Servers для поиска доступных серверов DHCP. Любой сервер, который может отвечать требованиям клиента, отвечает сообщением «Реклама». Затем клиент выбирает один из серверов и отправляет на сервер сообщение с запросом на подтверждение назначения адресов и / или делегированных префиксов и другой информации о конфигурации. Сервер отвечает сообщением «Ответ», которое содержит подтвержденные адреса, делегированные префиксы и конфигурацию.

Как описано в предыдущем разделе, клиент может запросить расширение сроков службы, назначенных для адресов или делегированных префиксов (это обмен двумя сообщениями).

5.3 Серверные / клиентские обмены

Сервер, ранее связанный с клиентом и согласованный с клиентом для прослушивания переконфигурированных сообщений, может отправить клиенту сообщение «Переконфигурировать», чтобы инициировать клиенту обновление своей конфигурации, отправив сообщение «Запрос информации» Information-request, «Обновить» Renew или «Пересоздать» Rebind. Затем клиент выполняет обмен двумя сообщениями, как описано выше. Это можно использоваться для ускорения изменений конфигурации для клиента, например, для нумерации сети (см. [RFC6879]).

6. Операционные модели

В этом разделе описываются некоторые из наиболее распространенных операционных моделей DHCP. Описанные модели не являются взаимоисключающими и иногда используются вместе. Например, устройство может запускаться в режиме состояния для получения адреса, а в более позднее время, когда приложение запускается, запрашивать дополнительные параметры, используя режим без состояния (stateless mode).

В этом документе предполагается, что серверы DHCP и клиент, взаимодействующие с серверами через определенный интерфейс, относятся к одному континуальному домену.

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

6.1 Неутверждённый (Безстоящий) DHCP

Неутверждённый (Stateless) DHCP [RFC3736] используется, когда DHCP не используется для получения аренды, но узел (клиент DHCP) желает один или несколько параметров DHCP «другой конфигурации», например список рекурсивных DNS-серверов или DNS списки поиска домена [RFC3646 ]. Неутверждённый DHCP может использоваться, когда узел сначала загружается или в любое время программное обеспечение на узле требует некоторой отсутствующей или устаревшей информации о конфигурации, доступной через DHCP.

Это самая простая и из большинства операций для DHCP и она требует, чтобы клиент (и сервер) поддерживал только два сообщения — «Запрос информации и ответ». Обратите внимание, что DHCP-серверы и ретрансляционные агенты обычно также должны поддерживать сообщения Relay-forward и Relay-reply для работы, когда клиенты и серверы не находятся на одной и той же ссылке.

6.2 DHCP для назначения несрочного адреса

Эта модель работы была оригинальной мотивацией для DHCP. Она подходит для ситуаций, когда автономная автоконфигурация одного из адресов является недостаточной или нецелесообразной, например, из-за сетевой политики, дополнительных требований, таких как динамические обновления для DNS или для клиент-специфичных требований.

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

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

Как правило, клиенты запрашивают другие параметры конфигурации, такие как адреса DNS-сервера имен и списки поиска домена, при запросе адресов.

Клиенты также могут запрашивать более одного адреса или набора адресов (см. Разделы 6.6 и 12).

6.3 DHCP для префиксной передачи

Механизм делегирования префикса, первоначально описанный в [RFC3633], является другим режимом работы с состоянием и первоначально предназначен для простого делегирования префиксов от делегирующего маршрутизатора (DHCP-сервера) на запросы маршрутизаторов (DHCP-клиентов). Он подходит для ситуаций, когда делегирующий маршрутизатор (1) не знает о топологии сетей, к которым подключен запрашивающий маршрутизатор, и (2) не требует другой информации, кроме идентификатора запрашивающего маршрутизатора, для выбора префикса для делегирования. Этот механизм подходит для использования провайдером для делегирования префикса подписчику, где делегированный префикс, возможно, будет подсетен и назначен для ссылок в сети абонента. [RFC7084] и [RFC7368] описывают такое использование в деталях.

Конструкция этого механизма делегирования префикса соответствует требованиям для делегирования префикса в [RFC3769].

Хотя [RFC3633] предполагает, что клиент DHCP является маршрутизатором (отсюда и использование «запрашивающего маршрутизатора») и что DHCP-сервер является маршрутизатором (отсюда и использование «делегирующего маршрутизатора»), делегирование префикса DHCP не требует, чтобы клиентские IP-пакеты, не адресованные себе и, следовательно, не требуют, чтобы клиент (или сервер) был маршрутизатором, как определено в [RFC8200]. Кроме того, во многих случаях (например, при подключении или хостинге виртуальных машин) хосты уже пересылают IP-пакеты и, таким образом, работают как маршрутизаторы, как определено в [RFC8200]. Поэтому этот документ в основном заменяет «запрашивающий маршрутизатор» «клиентом» и «делегирующим маршрутизатором» на «сервер».

Модель операции для делегирования префикса следующая. Сервер снабжен префиксами, которые должны быть делегированы клиентам. Клиент запрашивает префикс (ы) с сервера, как описано в разделе 18. Сервер выбирает префикс (ы) для делегирования и отвечает с префиксом (именами) клиенту. Затем клиент отвечает за делегированные префикс (ы). Например, клиент может назначить подсеть из делегированного префикса на один из своих интерфейсов и начать отправлять рекламные объявления Router для префикса по этой ссылке.

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

На рисунке 1 показана сетевая архитектура, в которой можно использовать делегирование префикса.

Рисунок 1 - Сеть делегирования префиксов
Рисунок 1 — Сеть делегирования префиксов

В этом примере сервер (делегирующий маршрутизатор) настроен с набором префиксов, которые будут использоваться для назначения клиентам в момент первого подключения каждого клиента к службе интернет-провайдера. Процесс делегирования префикса начинается, когда клиент (запрашивающий маршрутизатор) запрашивает информацию о конфигурации через DHCP. Сообщения DHCP от клиента принимаются сервером в устройстве агрегации. Когда сервер получает запрос, он выбирает доступный префикс или префиксы для делегирования клиенту. Затем сервер возвращает префикс или префиксы клиенту.

Клиентские подсети делегирует префиксы и назначают более длинные префиксы для ссылок в сети абонента. В типичном сценарии, основанном на сети, показанной на рисунке 1, клиентские подсети это один делегированный префикс / 48 префикс в / 64 префиксах и назначает один / 64 префикс для каждой из ссылок в сети абонента.

Параметры делегирования префикса могут использоваться в сочетании с другими параметрами DHCP, переносящими другую информацию о конфигурации клиенту.

Клиент, в свою очередь, может предоставлять службу DHCP узлам, подключенным к внутренней сети. Например, клиент может получить адреса DNS и NTP-серверов с сервера ISP, а затем передать эту информацию о конфигурации на абонентские хосты через DHCP-сервер в клиенте (запрашивающий маршрутизатор).

Если клиент использует делегированный префикс для настройки адресов на интерфейсах на себе или других узлах позади него, предпочтительный и действительный срок службы этих адресов ДОЛЖЕН быть не более, чем оставшиеся предпочтительные и действительные сроки жизни, соответственно, для делегированного префикса в любое время. В частности, если делегированный префикс или префикс, полученный из него, объявляется для автоконфигурации автономного адреса [RFC4862], объявленные предпочтительные и действительные сроки жизни НЕ ДОЛЖНЫ превышать соответствующие оставшиеся времена жизни делегированного префикса.

6.4 DHCP для клиентских пограничных маршрутизаторов

Требования DHCP и сетевая архитектура для клиентских пограничных маршрутизаторов описаны в [RFC7084]. Эта модель операции объединяет назначение адреса (см. Раздел 6.2) и делегирование префикса (см. Раздел 6.3). В целом, эта модель предполагает, что один набор транзакций между клиентом и сервером будет назначать или расширять несрочные адреса клиента и делегированные префиксы.

6.5 DHCP для временных адресов

Временные адреса были изначально введены, чтобы избежать проблем с конфиденциальностью при автоконфигурации безстоящих адресов, которые основывались на 64 битах адреса в EUI-64 (см. [RFC4941]. Они были добавлены в DHCP для предоставления дополнительной поддержки при использовании назначения адреса состояния.

Временное назначение адреса работает в основном как не временное назначение адреса (см. Раздел 6.2); однако эти адреса, как правило, предназначены для использования в течение короткого периода времени и не продлевают срок их службы, хотя они могут быть в случае необходимости.

6.6 Несколько адресов и префиксов

DHCP позволяет клиенту получать несколько адресов. Во время типичной операции клиент отправляет один экземпляр опции IA_NA, и сервер назначает не более одного адреса из каждого префикса, назначенного на ссылку, к которой прикреплен клиент. В частности, сервер может быть настроен для обслуживания адресов из нескольких префиксов для данной ссылки. Это полезно в случаях, когда происходит событие перенумерации сети. В типичном развертывании сервер предоставит один адрес для каждого варианта IA_NA (см. Раздел 21.4).

Клиент может явно запросить несколько адресов, отправив несколько опций IA_NA (и / или IA_TA, см. Раздел 21.5). Клиент может отправлять несколько параметров IA_NA (и / или IA_TA) в своих первоначальных передачах. В качестве альтернативы, он может отправить дополнительное сообщение с дополнительными опциями IA_NA (и / или IA_TA) (или включить их в сообщение Renew).

Тот же принцип применяется и к префиксному делегированию. В принципе, DHCP позволяет клиенту запрашивать новые префиксы для делегирования путем отправки дополнительных опций IA_PD (см. Раздел 21.21). Однако типичный оператор обычно предпочитает делегировать один, более большой префикс. В большинстве развертываний рекомендуется, чтобы клиент запрашивал более высокий префикс в своих первоначальных передачах, а не позже запрашивал дополнительные префиксы.

Точное поведение сервера (предоставление дополнительных адресов и префиксов или нет) зависит от политики сервера и выходит за рамки этого документа.

Для получения дополнительной информации о том, как сервер различает экземпляры вариантов IA, см. Раздел 12.

7. Константы DHCP

В этом разделе описываются различные программные и сетевые константы, используемые DHCP.

7.1 Адреса мультивещания

DHCP использует следующие многовещательные адреса:

All_DHCP_Relay_Agents_and_Servers (ff02 :: 1: 2) Многоадресный адрес с привязкой к области ссылок, используемый клиентом для связи с соседними (то есть, по-линии) ретрансляционными агентами и серверами. Все серверы и ретрансляционные агенты являются членами этой многоадресной группы.

All_DHCP_Servers (ff05 :: 1: 3) Многоадресный адрес узла, используемый агент ретранслятора для связи с серверами, либо потому, что агент ретрансляции хочет отправлять сообщения всем серверам, либо потому, что он не знает одноадресные адреса серверов. Обратите внимание, что для того, чтобы агент-ретранслятор использовал этот адрес, он должен иметь адрес достаточной области, доступный для серверов. Все серверы на сайте являются членами этой многоадресной группы на интерфейсах, которые находятся на этом сайте.

7.2 Порты UDP

Клиенты прослушивают сообщения DHCP на UDP-порту 546. Серверы и ретрансляторы прослушивают сообщения DHCP на UDP-порту 547.

7.3 Типы сообщений DHCP

DHCP определяет следующие типы сообщений. Форматы этих сообщений приведены в разделах 8 и 9. Дополнительные типы сообщений были определены и могут быть определены в будущем; см. <https://www.iana.org/assignments/dhcpv6-parameters>. Числовая кодировка для каждого типа сообщения показана в круглых скобках.

  • SOLICIT (1)
  • ADVERTISE (2)
  • REQUEST (3)
  • CONFIRM (4)
  • RENEW (5)
  • REBIND (6)
  • REPLY (7)
  • RELEASE (8)
  • DECLINE (9)
  • RECONFIGURE (10)
  • INFORMATION-REQUEST (11)
  • RELAY-FORW (12)
  • RELAY-REPL (13)

SOLICIT (1)

Клиент отправляет сообщение «Запросить» для поиска серверов.

ADVERTISE (2)

Сервер отправляет сообщение «Реклама», чтобы указать, что он доступен для службы DHCP, в ответ на сообщение «Запросить», полученное от клиента.

REQUEST (3)

Клиент отправляет сообщение «Запрос» для запроса параметров конфигурации, включая адреса и / или делегированные префиксы, с определенного сервера.

CONFIRM (4)

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

RENEW (5)

Клиент отправляет сообщение «Возобновить» (Renew) на сервер, который изначально предоставил лизинг и параметры конфигурации клиента, чтобы продлить срок службы лизингов, назначенных клиенту, и обновить другие параметры конфигурации.

REBIND (6)

Клиент отправляет сообщение «Переcвязать» (Rebind) любому доступному серверу для продления срока службы в аренде, назначенной клиенту, и для обновления других параметров конфигурации; это сообщение отправляется после того, как клиент не получил ответа на сообщение «Возобновить» Renew.

REPLY (7)

Сервер отправляет ответное сообщение, содержащее назначенные лизинг и параметры конфигурации, в ответ на сообщение «Запрашивать, запрос, обновлять или переадресовывать», полученное от клиента. Сервер отправляет ответное сообщение, содержащее параметры конфигурации, в ответ на сообщение «Информация-запрос». Сервер отправляет ответное сообщение в ответ на сообщение подтверждения, подтверждающее или отрицающее, что адреса, назначенные клиенту, соответствуют ссылке, к которой подключен клиент. Сервер отправляет ответное сообщение, чтобы подтвердить получение сообщения Release или Decline.

RELEASE (8)

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

DECLINE (9)

Клиент отправляет сообщение «Отклонить» серверу, чтобы указать, что клиент определил, что один или несколько адресов, назначенных сервером, уже используются по ссылке, к которой подключен клиент.

RECONFIGURE (10)

Сервер отправляет клиенту сообщение «Переконфигурировать», чтобы сообщить клиенту, что у сервера есть новые или обновленные параметры конфигурации, и что клиент должен инициировать транзакцию Renew / Reply, Rebind / Reply или Information-request / Reply с сервером в порядке для получения обновленной информации.

INFORMATION-REQUEST (11)

Клиент отправляет на сервер сообщение «Информация-запрос» для запроса параметров конфигурации без назначения клиенту каких-либо договоров аренды.

RELAY-FORW (12)

Агент ретрансляции отправляет сообщение Relay-forward для передачи сообщений серверам либо напрямую, либо через другой ретранслятор. Полученное сообщение — либо сообщение клиента, либо сообщение Relay-forward от другого ретранслятора — инкапсулируется в опции в сообщении Relay-forward.

RELAY-REPL (13)

Сервер отправляет сообщение Relay-reply агенту ретрансляции, содержащему сообщение, которое агент ретранслятора передает клиенту. Сообщение ретрансляции может быть ретранслировано другими ретрансляционными агентами для доставки ретранслятору адресата.

Сервер инкапсулирует сообщение клиента в качестве опции в сообщение Relay-reply, которое ретранслятор извлекает и передает клиенту.

7.4 Коды опций DHCP

DHCP широко использует опции в сообщениях; некоторые из них определены позже, в разделе 21. Дополнительные параметры определены в других документах или могут быть определены в будущем (см. [RFC7227] для руководства по новым определениям опций).

7.5 Коды состояния

DHCP использует коды состояния для сообщения об успешности или сбое операций, запрошенных в сообщениях от клиентов и серверов, и для предоставления дополнительной информации о конкретной причине отказа сообщения. Конкретные коды состояния определены в разделе 21.13.

Если параметр «Код состояния» (см. Раздел 21.13) не отображается в сообщении, в котором может отображаться опция, статус сообщения считается успешным.

7.6 Параметры передачи и повторной передачи

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

Таблица 1 - Параметры передачи и повторной передачи
Таблица 1 — Параметры передачи и повторной передачи
  • SOL_MAX_DELAY (1 секунда по-умолчанию) — Максимальная задержка первого запроса
  • SOL_TIMEOUT (1 секунда по-умолчанию) — Исходный тайм-аут первого запроса
  • SOL_MAX_RT (3600 секунд по-умолчанию) — Максимальное значение таймаута ожидания первого запроса
  • REQ_TIMEOUT (1 секунда по-умолчанию) — Исходный таймаут запроса
  • REQ_MAX_RT (30 секунд) — Максимальное время ожидания запроса
  • REQ_MAX_RC (10) — Максимальное количество повторной попытки запроса
  • CNF_MAX_DELAY (1 секунда) — Максимальная задержка первого подтверждения
  • CNF_TIMEOUT (1 секунда) — Начальный период ожидания подтверждения
  • CNF_MAX_RT (4 секунды) — Максимальное время ожидания подтверждения
  • CNF_MAX_RD (10 секунд) — Максимальная продолжительность подтверждения
  • REN_TIMEOUT (10 секунд) — Исходное время ожидания обновления
  • REN_MAX_RT (600 секунд) — Максимальное возобновление значения времени ожидания
  • REB_TIMEOUT (10 секунд) — Исходный тайм-аут пересвязывания
  • REB_MAX_RT (600 секунд) — Максимальное значение тайм-аута пересвязывания
  • INF_MAX_DELAY (1 секунда) — Максимальная задержка первого запроса информации
  • INF_TIMEOUT (1 секунда) — Исходный тайм-аут запроса информации
  • INF_MAX_RT (3600 секунд) — Максимальное значение времени ожидания запроса информации
  • REL_TIMEOUT (1 секунда) —  Тайм-аут исходного Высвобожнения
  • REL_MAX_RC (4) — Максимальные повторные попытки Высвобожнения
  • DEC_TIMEOUT (1 секунда) — Исходный тайм-аут завершения
  • DEC_MAX_RC (4) — Максимальное значение повторных попыток Завершения
  • REC_TIMEOUT (2 секунды) — Тайм-аут исходной Переконфигурации
  • REC_MAX_RC (8) — Максимальные попытки Переконфигурации
  • HOP_COUNT_LIMIT (8) — Максимальное количество переходов в сообщении Relay-forward
  • IRT_DEFAULT (86400 секунд (24 часа)) — Время обновления информации по умолчанию
  • IRT_MINIMUM (600 секунд) — Минимальное время обновления информации
  • MAX_WAIT_TIME (60 секунд) — Максимальное время ожидания ответа

7.7 Представление значений времени и «бесконечности» в качестве значения времени

Все временные значения для времен жизни, T1 и T2 представляют собой неподписанные 32-битные целые числа и выражаются в единицах секунд. Значение 0xffffffff воспринимается как «бесконечность» при использовании как время жизни (как в [RFC4861]) или значение для T1 или T2.

Установка допустимого времени жизни адреса или делегированного префикса на 0xffffffff («бесконечность») означает постоянное присвоение адреса или делегирование клиенту и должно использоваться только в случаях, когда требуются постоянные назначения.

Следует соблюдать осторожность при настройке T1 или T2 на 0xffffffff («бесконечность»). Клиент никогда не будет пытаться продлить время жизни любых адресов в IA с T1, установленным в 0xffffffff. Клиент никогда не будет пытаться использовать сообщение Rebind для поиска другого сервера для продления срока службы любых адресов в IA с T2, установленным в 0xffffffff.

8. Форматы сообщений клиента / сервера

Все сообщения DHCP, отправляемые между клиентами и серверами, имеют одинаковый заголовок с фиксированным форматом и область с переменным форматом для параметров.

Все значения в заголовке сообщения и в параметрах находятся в сетевом порядке байтов.

Опции хранятся поочередно в поле «параметры», без дополнительных параметров. Параметры выровнены по байт, но не выровнены каким-либо другим способом (например, на 2-байтных или 4-байтных границах).

Следующая диаграмма иллюстрирует формат сообщений DHCP, отправляемых между клиентами и серверами:

Рисунок 2 - Формат сообщений клиента или сервера
Рисунок 2 — Формат сообщений клиента или сервера

msg-type

Определяет тип сообщения DHCP; доступные типы сообщений перечислены в разделе 7.3. 1-октетное поле.

transaction-id

Идентификатор транзакции для обмена этим сообщением. 3-октетное поле.

options

Параметры, указанные в этом сообщении; параметры описаны в разделе 21. Поле переменной длины (на 4 октета меньше размера сообщения).

9. Форматы сообщений ретранслятора / сервера

Релейные агенты обмениваются сообщениями с другими релейными агентами и серверами для передачи сообщений между клиентами и серверами, которые не подключены к одной и той же ссылке.

Все значения в заголовке сообщения и в параметрах находятся в сетевом порядке байтов.

Опции хранятся поочередно в поле «параметры», без дополнительных параметров. Параметры выровнены по байт, но не выровнены каким-либо другим способом (например, на 2-байтных или 4-байтных границах).

Существует два сообщения ретранслятора (Relay-forward и Relay-ответ), которые имеют следующий формат:

Рисунок 3 - Формат сообщения агента ретрансляции или сервера
Рисунок 3 — Формат сообщения агента ретрансляции или сервера

В следующих разделах описывается использование заголовка сообщения агента реле.

9.1 Сообщение о пересылке

Следующая таблица определяет использование полей сообщения в сообщении Relay-forward.

msg-type

RELAY-FORW (12). 1-октетное поле.

hop-count

Количество релейных агентов, которые уже передали это сообщение.

1-октетное поле.

link-address

Адрес, который может использоваться сервером для идентификации ссылки, на которой расположен клиент. Обычно это одноадресный адрес с глобальным охватом (т. Е. GUA или ULA), но см. Обсуждение в разделе 19.1.1.

16-октетное поле.

peer-address

Адрес клиента или агента ретрансляции, из которого было получено сообщение, подлежащее передаче.

16-октетное поле.

options

ДОЛЖЕН включить параметр Relay Message (см. Раздел 21.10); МОЖЕТ включать другие параметры, такие как параметр Interface-Id (см. Раздел 21.18), добавленный агентом ретрансляции. Поле переменной длины (на 34 октета меньше размера сообщения).

См. Раздел 13.1 для объяснения того, как используется поле link-address.

9.2 Сообщение с ретрансляцией

В следующей таблице указано использование полей сообщений в сообщении Relay-reply.

msg-type

RELAY-REPL (13).

1-октетное поле.

hop-count

Скопировано из сообщения Relay-forward.

1-октетное поле.

link-address

Скопировано из сообщения Relay-forward.

16-октетное поле.

peer-address

Скопировано из сообщения Relay-forward.

16-октетное поле.

options

ДОЛЖЕН включить параметр Relay Message (см. Раздел 21.10); МОЖЕТ включать другие параметры, такие как опция Interface-Id (см. Раздел 21.18). Поле переменной длины (на 34 октета меньше размера сообщения).

10. Представление и использование доменных имен

Таким образом, чтобы имена доменов могли кодироваться равномерно, имя домена или список доменных имен кодируются с использованием метода, описанного в разделе 3.1 [RFC1035]. Доменное имя или список доменных имен в DHCP НЕ ДОЛЖНО храниться в сжатой форме, как описано в разделе 4.1.4 [RFC1035].

11. Уникальный идентификатор DHCP (DUID)

Каждый клиент и сервер DHCP имеет DUID. DHCP-серверы используют DUID для идентификации клиентов для выбора параметров конфигурации и объединения IA с клиентами. DHCP-клиенты используют DUID для идентификации сервера в сообщениях, где необходимо идентифицировать сервер. См. Разделы 21.2 и 21.3 для получения подробной информации о представлении DUID в сообщении DHCP.

Клиенты и серверы ДОЛЖНЫ относиться к DUID как непрозрачные значения и ДОЛЖНЫ только сравнивать DUID для равенства.

Клиенты и серверы НЕ ДОЛЖНЫ каким-либо иным образом интерпретировать DUID. Клиенты и серверы НЕ ДОЛЖНЫ ограничивать DUID для типов, определенных в этом документе, поскольку в будущем могут быть определены дополнительные типы DUID. Следует отметить, что попытка проанализировать DUID для получения адреса канала связи клиента ненадежна, так как нет гарантии, что клиент все еще использует тот же адрес уровня канала, что и при создании его DUID. Кроме того, такая попытка будет становиться все более ненадежной, поскольку все больше клиентов принимают меры по обеспечению конфиденциальности, такие как те, которые определены в [RFC7844]. Если эта возможность требуется, рекомендуется использовать опцию Client Link-Layer Address вместо [RFC6939].

DUID переносится в опции, поскольку он может быть переменной по длине и потому, что он не требуется во всех сообщениях DHCP. DUID разработан, чтобы быть уникальным для всех DHCP-клиентов и серверов и стабилен для любого конкретного клиента или сервера. То есть, DUID, используемый клиентом или сервером, НЕ ДОЛЖЕН меняться со временем, если это вообще возможно; например, DUID устройства не должен изменяться в результате изменения сетевого оборудования устройства или изменений в виртуальных интерфейсах (например, логических интерфейсах PPP (через Ethernet), которые могут появляться и выполняться в маршрутизаторах оборудования для помещений для клиентов). Клиент может изменить свой DUID, как указано в [RFC7844].

Мотивация наличия более чем одного типа DUID заключается в том, что DUID должен быть глобально уникальным и также должен быть легко сгенерирован. Тип глобального уникального идентификатора, который легко сгенерирован для любого устройства, может сильно различаться. Кроме того, некоторые устройства не могут содержать постоянное хранилище. Сохранение сгенерированного DUID в таком устройстве невозможно, поэтому схема DUID должна размещать такие устройства.

11.1 Содержимое DUID

DUID состоит из кода 2-октетного типа, представленного в сетевом порядке байтов, за которым следует переменное количество октетов, которые составляют фактический идентификатор. Длина DUID (не включая код типа) не менее 1 октета и не более 128 октетов. В настоящее время определены следующие типы:

  1. Адрес уровня ссылки плюс время
  2. Уникальный идентификатор, присвоенный поставщиком, на основе номера предприятия
  3. Адрес уровня ссылки
  4. Универсальный уникальный идентификатор (UUID) [RFC6355]

Ниже приведены форматы для поля переменной DUID для первых трех указанных типов. Четвертый тип, DUID-UUID [RFC6355], может использоваться в ситуациях, когда UUID хранится в настройках прошивки устройства.

Этот тип DUID состоит из поля 2-октетного типа, содержащего значение 1, 2-октетного аппаратного типа и 4 октета, содержащих значение времени, за которым следует адрес канального уровня любого сетевого интерфейса, который подключен к DHCP в момент создания DUID. Значение времени — это время создания DUID, представленное в секундах с полуночи (UTC), 1 января 2000 года, по модулю 2 ^ 32. Тип оборудования ДОЛЖЕН быть допустимым аппаратным типом, назначенным IANA; см. [IANA-HARDWARE-TYPES]. Время и тип оборудования сохраняются в сетевом порядке. Для типов аппаратного обеспечения Ethernet адрес канального уровня сохраняется в канонической форме, как описано в [RFC2464].

Следующая диаграмма иллюстрирует формат DUID-LLT:

Рисунок 4 - Формат DUID-LLT
Рисунок 4 — Формат DUID-LLT

Выбор сетевого интерфейса может быть полностью произвольным, если этот интерфейс предоставляет глобально уникальный адрес уровня канала для типа ссылки; тот же DUID-LLT ДОЛЖЕН использоваться при настройке всех сетевых интерфейсов, подключенных к устройству, независимо от того, какой адрес интерфейса канала использовался для создания DUID-LLT.

Клиенты и серверы, использующие этот тип DUID, ДОЛЖНЫ хранить DUID-LLT в стабильном хранилище и ДОЛЖНЫ продолжать использовать этот DUID-LLT, даже если сетевой интерфейс, используемый для генерации DUID-LLT, удаляется. Клиенты и серверы, у которых нет стабильного хранилища, НЕ ДОЛЖНЫ использовать этот тип DUID.

Клиенты и серверы, использующие этот DUID, ДОЛЖНЫ пытаться настроить время до создания DUID, если это возможно, и ДОЛЖНЫ использовать какой-то источник времени (например, часы реального времени) при генерации DUID, даже если это источник времени не может быть настроен до генерации DUID. Использование источника времени делает маловероятным создание двух идентичных DUID-LLT, если сетевой интерфейс удаляется с клиента, а другой клиент использует тот же сетевой интерфейс для создания DUID-LLT. Столкновение между двумя DUID-LLT очень маловероятно, даже если часы не были настроены до генерации DUID.

Этот метод генерации DUID рекомендуется для всех универсальных вычислительных устройств, таких как настольные компьютеры и портативные компьютеры, а также для таких устройств, как принтеры, маршрутизаторы и т. Д., Которые содержат некоторую форму перезаписываемого энергонезависимого хранилища.

Возможно, что этот алгоритм для генерации DUID может привести к столкновению идентификатора клиента. Клиент DHCP, который генерирует DUID-LLT с использованием этого механизма, ДОЛЖЕН предоставить административный интерфейс, который заменяет существующий DUID новым DUID-LLT.

11.3 DUID, назначенный поставщиком на основе корпоративного номера (DUID-EN)

Поставщик назначает эту форму DUID устройству. Этот DUID состоит из зарегистрированного Частного Enterprise Number 4-октетного вендора, который поддерживается IANA [IANA-PEN], за которым следует уникальный идентификатор, назначенный поставщиком. Следующая диаграмма суммирует структуру DUID-EN:

Рисунок 5 - Формат DUID-EN
Рисунок 5 — Формат DUID-EN

Источник идентификатора остается до поставщика, определяющего его, но каждая часть идентификатора каждого DUID-EN ДОЛЖНА быть уникальной для устройства, которое его использует, и ДОЛЖНА быть назначено устройству не позднее, чем при первом использовании и сохранении в некотором виде энергонезависимого хранилища. Обычно это означает назначение во время производственного процесса в случае физических устройств или, в случае виртуальных машин, когда изображение создается или загружается в первый раз. Сгенерированный DUID СЛЕДУЕТ записываться в неэкранируемом хранилище. Номер предприятия — это зарегистрированный номер частного предпринимателя, который поддерживается IANA [IANA-PEN]. Номер предприятия хранится как 32-битное число без знака.

Пример DUID этого типа может выглядеть так:

Рисунок 6 - Пример DUID-EN
Рисунок 6 — Пример DUID-EN

Этот пример включает 2-октетный тип 2 и Enterprise Number (9), за которым следуют 8 октетов данных идентификатора (0x0CC084D303000912).

Этот тип DUID состоит из 2 октетов, содержащих тип DUID 3 и 2-октетный код аппаратного типа сети, а затем адрес канального уровня любого сетевого интерфейса, который постоянно подключен к клиентскому или серверному устройству. Например, узел, который имеет сетевой интерфейс, реализованный в чипе, который вряд ли будет удален и использован в другом месте, может использовать DUID-LL. Тип оборудования ДОЛЖЕН быть допустимым аппаратным типом, назначенным IANA; см. [IANA-HARDWARE-TYPES]. Тип оборудования хранится в сетевом порядке байтов. Адрес канального уровня хранится в канонической форме, как описано в [RFC2464]. Следующая диаграмма иллюстрирует формат DUID-LL:

Рисунок 7 - Формат DUID-LL
Рисунок 7 — Формат DUID-LL

Выбор сетевого интерфейса может быть совершенно произвольным, если этот интерфейс предоставляет уникальный адрес уровня канала и постоянно подключен к устройству, на котором генерируется DUID-LL. Тот же DUID-LL ДОЛЖЕН использоваться при настройке всех сетевых интерфейсов, подключенных к устройству, независимо от того, какой адрес интерфейса канала использовался для создания DUID.

DUID-LL рекомендуется для устройств с постоянно подключенным сетевым интерфейсом с адресом канала связи и не иметь энергонезависимого, доступного для записи стабильного хранилища. DUID-LL НЕ ДОЛЖЕН использоваться клиентами или серверами DHCP, которые не могут определить, постоянно ли подключен сетевой интерфейс к устройству, на котором работает клиент DHCP.

11.5 DUID на основе универсального уникального идентификатора (DUID-UUID)

Этот тип DUID состоит из 16 октетов, содержащих 128-битный UUID. [RFC6355] подробно, когда использовать этот тип и как выбрать соответствующий источник UUID.

Рисунок 8 - Формат DUID-UUID
Рисунок 8 — Формат DUID-UUID

12. Идентификационная ассоциация

Что такое Identity Association?

Ассоциация идентификации (IA) — это конструкция, через которую сервер и клиент могут идентифицировать, группировать и управлять набором связанных адресов IPv6 или делегированных префиксов. Каждый IA состоит из IAID и связанной с ним информации конфигурации.

IAID однозначно идентифицирует IA и ДОЛЖЕН быть выбран как уникальный среди IAID для этого типа IA на клиенте (например, IA_NA с IAID 0 и IA_PD с IAID 0 считаются уникальными). IAID выбирается клиентом. Для любого конкретного использования IA клиентом IAID для этого IA ДОЛЖЕН быть последовательным через перезагрузки клиента DHCP. Клиент может поддерживать согласованность либо путем хранения IAID в энергонезависимой памяти, либо с использованием алгоритма, который будет последовательно создавать тот же IAID, если конфигурация клиента не изменилась. Клиент не может поддерживать согласованность IAID, если он не имеет энергонезависимого хранилища и изменения конфигурации оборудования клиента. Если клиент использует только один IAID, он может использовать известное значение, например, ноль.

Если клиент хочет получить явно новый адрес или префикс и обесценить существующий, клиент отправляет сообщение Release на сервер для IA с использованием оригинального IAID. Затем клиент создает новый IAID, который будет использоваться в будущих сообщениях для получения аренды для нового IA.

12.1 Ассоциации удостоверений для назначения адресов

Клиент должен связывать по меньшей мере один отдельный IA с каждым из своих сетевых интерфейсов, для которого он должен запрашивать назначение адресов IPv6 с сервера DHCP. Клиент использует IA, назначенные для интерфейса, для получения информации о конфигурации с сервера для этого интерфейса. Каждый такой IA должен быть связан только с одним интерфейсом.

Конфигурационная информация в опции IA_NA состоит из одного или нескольких адресов IPv6 вместе с значениями T1 и T2 для IA. См. Раздел 21.4 для получения подробной информации о представлении IA_NA в сообщении DHCP.

Конфигурационная информация в опции IA_TA состоит из одного или нескольких адресов IPv6. Подробные сведения о представлении IA_TA в сообщении DHCP см. В разделе 21.5.

Каждый адрес в IA имеет предпочтительное время жизни и действительное время жизни, как определено в [RFC4862]. Время жизни передается от DHCP-сервера клиенту в опции IA Address (см. Раздел 21.6). Время жизни относится к использованию адресов; см. раздел 5.5.4 в [RFC4862].

12.2 Ассоциации удостоверений для префиксной передачи

IA_PD отличается от IA для назначения адреса тем, что ему не нужно связываться с одним интерфейсом. Один IA_PD может быть связан с клиентом, с набором интерфейсов или с одним интерфейсом. Клиент, настроенный на запрос делегированных префиксов, должен создать хотя бы один отдельный IA_PD. Он может связывать отдельный IA_PD с каждым из его нижестоящих сетевых интерфейсов и использовать этот IA_PD для получения префикса для этого интерфейса с сервера.

Конфигурационная информация в опции IA_PD состоит из одного или больше префиксов вместе с значениями T1 и T2 для IA_PD. Увидеть Раздел 21.21 для получения подробной информации о представлении IA_PD в сообщение DHCP.

Каждый делегированный префикс в IA имеет предпочтительное время жизни и действительное время жизни, как определено в [RFC4862]. Время жизни передается с сервера DHCP клиенту в опции префикса IA (см. Раздел 21.22). Время жизни применяется к использованию делегированных префиксов; см. раздел 5.5.4 в [RFC4862].

13. Назначение IA

13.1 Выбор адресов для присвоения IA_NA

Сервер выбирает адреса, которые должны быть назначены IA_NA в соответствии с политиками назначения адресов, определенными администратором сервера, и конкретной информацией, которую сервер определяет о клиенте из некоторой комбинации следующих источников:

Ссылка, к которой прикреплен клиент

Сервер определяет ссылку следующим образом:

  • Если сервер получает сообщение непосредственно от клиента, а исходный адрес в дейтаграмме IP, в которой было получено сообщение, является локальным адресом связи, то клиент находится на той же ссылке, с которой интерфейс, по которому было получено сообщение, прилагается.
  • Если сервер получает сообщение от агента ретрансляционного ретранслятора, то клиент находится на той же ссылке, что и тот, к которому прикреплен интерфейс, идентифицированный полем адресного адреса в сообщении от агента ретрансляции. Согласно [RFC6221], сервер ДОЛЖЕН игнорировать любое поле адрес-адрес, значение которого равно нулю. Адрес ссылки в этом случае может исходить из любого из сообщений, связанных с ретрансляцией, инкапсулированных в принятом ретрансляционном пересылке, и в целом наиболее инкапсулированный (ближайший Relay-forward к клиенту) имеет самое полезное значение.
  • Если сервер получает сообщение непосредственно от клиента, а исходный адрес в дейтаграмме IP, в которой было получено сообщение, не является локальным адресом связи, то клиент находится по ссылке, идентифицированной исходным адресом в дейтаграмме IP (примечание что эта ситуация может возникнуть только в том случае, если сервер разрешил использование одноадресной доставки сообщений клиентом, и клиент отправил сообщение, для которого разрешена одноадресная доставка).

DUID, поставляемый клиентом.

Другая информация в параметрах, предоставляемых клиентом, например, Параметры адреса IA (см. Раздел 21.6), которые включают запросы клиента для определенных адресов.

Другая информация в параметрах, предоставляемых ретранслятором.

По умолчанию реализации DHCP-сервера НЕ ДОЛЖНЫ генерировать предсказуемые адреса (см. Раздел 4.7 из [RFC7721]). Разработчикам сервера рекомендуется просмотреть [RFC4941], [RFC7824] и [RFC7707] относительно возможных соображений, как создавать адреса.

Сервер НЕ ДОЛЖЕН присваивать адрес, который иначе зарезервирован для какой-либо другой цели. Например, сервер НЕ ДОЛЖЕН назначать адреса, которые используют зарезервированный идентификатор интерфейса IPv6 [RFC5453] [RFC7136] [IANA-RESERVED-IID].

См. [RFC7969] для более подробного обсуждения того, как серверы определяют местоположение клиента в сети.

13.2 Назначение временных адресов

Клиент может запросить назначение временных адресов (см. [RFC4941] для определения временных адресов). Обработка DHCP для назначения адреса не отличается для временных адресов.

Клиенты запрашивают временные адреса, а серверы назначают их. Временные адреса переносятся в опции IA_TA (см. Раздел 21.5). Каждая опция IA_TA обычно содержит по крайней мере один временный адрес для каждого из префиксов на ссылке, к которой прикреплен клиент.

Время жизни назначенного временного адреса устанавливается в параметре IA Address (см. Раздел 21.6), инкапсулированном в опции IA_TA. РЕКОМЕНДУЕТСЯ установить короткий срок службы, как правило, короче TEMP_VALID_LIFETIME и TEMP_PREFERRED_LIFETIME (см. Раздел 5 [RFC4941]).

Реализация сервера DHCP МОЖЕТ генерировать временные адреса, ссылаясь на алгоритм, определенный в разделе 3.2.1 [RFC4941], с дополнительным условием, что любой новый адрес не совпадает с любым назначенным адресом.

Сервер МОЖЕТ обновлять DNS для временного адреса, как описано в разделе 4 документа [RFC4941].

На клиентах по умолчанию временные адреса предпочтительны для выбора адреса источника в соответствии с правилом 7 раздела 5 [RFC6724]. Однако эту политику можно переопределить.

Одним из наиболее важных свойств временного адреса является затруднение привязки адреса к различным действиям с течением времени. Таким образом, для клиента не рекомендуется обновлять временные адреса, хотя DHCP предоставляет такую возможность (см. Раздел 21.5).

13.3 Назначение префиксов для IA_PD

Механизм, посредством которого сервер выбирает префикс (ы) для делегирования, не указан в этом документе. Примеры способов, которыми сервер может выбрать префикс (ы) для клиента, включают статическое назначение на основе подписки на ISP, динамическое назначение из пула доступных префиксов и выбор на основе внешнего органа, такого как сервер RADIUS, с использованием Framed -IPv6-Prefix, как описано в [RFC3162].

14. Передача сообщений клиентом

Если иное не указано в этом документе или документе, который описывает, как IPv6 переносится на определенный тип ссылки (для типов ссылок, которые не поддерживают многоадресную рассылку), клиент отправляет DHCP-сообщения на многоадресный адрес All_DHCP_Relay_Agents_and_Servers.

DHCP-серверы НЕ ДОЛЖНЫ проверять, является ли используемый адрес уровня 2 многоадресным или нет, если адрес 3-го уровня был правильным.

Клиент использует многоадресную рассылку для доступа ко всем серверам или отдельному серверу. Отдельный сервер указывается указанием DUID сервера в опции «Идентификатор сервера» (см. Раздел 21.3) в сообщении клиента. (Все серверы получат это сообщение, но ответит только указанный сервер.) Все серверы отображаются, если эта опция не указана.

Клиент может отправлять сообщения непосредственно на сервер с помощью одноадресной рассылки, как описано в разделе 21.12.

14.1 Ограничение скорости

Чтобы избежать длительных пакетов сообщений, которые могут быть вызваны возможными логическими циклами, клиент DHCP ДОЛЖЕН ограничить скорость сообщений DHCP, которые он передает или повторно передает. Одним из примеров является то, что клиент получает адрес или делегированный префикс, но ему не нравится ответ, поэтому он возвращается к процедуре поиска, обнаруживает тот же (единственный) сервер, запрашивает адрес или делегированный префикс и получает тот же адрес или делегирован префикс, как и раньше (поскольку сервер имеет ранее запрошенную аренду, назначенную этому клиенту). Этот цикл может повторяться бесконечно, если не существует механизма quit / stop. Поэтому клиент не должен слишком часто запускать передачи.

Рекомендуемым методом реализации функции ограничения скорости является токен-ковш token bucket (см. Приложение A к [RFC3290]), ограничивая среднюю скорость передачи на определенное число за определенный промежуток времени. Этот метод ограничения разрыва также гарантирует, что долгосрочная скорость передачи не будет превышена.

Ограничение скорости передачи СЛЕДУЕТ настраивать. Возможным значением по умолчанию может быть 20 пакетов за 20 секунд.
Для устройства, имеющего несколько интерфейсов, предел ДОЛЖЕН быть применен для каждого интерфейса.
Ограничение скорости пересылаемых сообщений DHCP и сообщений на стороне сервера выходит за рамки этой спецификации.

14.2 Поведение клиента, когда T1 и / или T2 равны 0

В некоторых случаях значения T1 и / или T2 могут быть установлены равными 0. В настоящее время существует три таких случая:

  • клиент получил опцию IA_NA (см. раздел 21.4) с нулевым значением
  • клиент получил опцию IA_PD (см. раздел 21.21) с нулевым значением
  • клиент получил опцию IA_TA (см. раздел 21.5) (который не содержит полей T1 и T2, и эти аренды обычно не обновляются)

Это свидетельствует о том, что время обновления и повторной обработки остается на усмотрение клиента. Однако они не являются полностью дискреционными.

Когда значения T1 и / или T2 установлены в 0, клиент ДОЛЖЕН выбрать время, чтобы избежать пакетных штормов. В частности, он НЕ ДОЛЖЕН передавать немедленно. Если клиент получил несколько вариантов IA, ему следует выбрать время продления и / или повторной передачи, чтобы все варианты IA обрабатывались в одном обмене, если это возможно. Клиент ДОЛЖЕН выбирать время продления и повторного выполнения, чтобы не нарушать ограничения ограничения скорости, как определено в разделе 14.1.

15. Надежность обменов сообщениями, инициированными клиентом

DHCP-клиенты несут ответственность за надежную доставку сообщений в обмене сообщениями, инициируемыми клиентом, описанные в разделе 18. Если клиент DHCP не может получить ожидаемый ответ от сервера, клиент должен повторно передать его сообщение в соответствии с стратегией повторной передачи, описанной в этом разделе.

Обратите внимание, что процедура, описанная в этом разделе, слегка изменена при использовании с сообщением «Запросить впервые» (Solicit). Модифицированная процедура описана в разделе 18.2.1.

Клиент начинает обмен сообщениями, передавая сообщение серверу. Обмен сообщениями прекращается, когда либо (1) клиент успешно получает соответствующий ответ или ответы от сервера или серверов, либо (2) считается, что обмен сообщениями потерпел неудачу в соответствии с механизмом повторной передачи, описанным ниже.

Клиент ДОЛЖЕН обновлять значение «прошедшее время» в опции «Истекшее время» (см. Раздел 21.9) в повторном сообщении. В некоторых случаях клиенту также может потребоваться изменить значения в опциях IA Address (см. Раздел 21.6) или опции префикса IA (см. Раздел 21.22), если до повторной передачи истекает срок действия для любой из клиентских лизингов. Таким образом, всякий раз, когда этот документ ссылается на «повторную передачу» сообщения клиента, он ссылается как на изменение исходного сообщения, так и на отправку этого нового экземпляра сообщения на сервер.

Поведение повторной передачи клиента контролируется и описывается следующими переменными:

  • RT (Retransmission timeout) — Тайм-аут повторной передачи
  • IRT (Initial retransmission time) — Начальное время повторной передачи
  • MRC (Maximum retransmission count) — Максимальное количество повторной передачи
  • MRT (Maximum retransmission time) — Максимальное время повторной передачи
  • MRD (Maximum retransmission duration) — Максимальная продолжительность повторной передачи
  • RAND (Randomization factor) — Фактор рандомизации

Конкретные значения для каждого из этих параметров, относящихся к различным сообщениям, приведены в подразделах раздела 18.2, используя значения, определенные в таблице 1 раздела 7.6. Алгоритм RAND является общим для всех передач сообщений.

При каждой передаче или повторной передаче сообщения клиент устанавливает RT в соответствии с приведенными ниже правилами. Если RT истекает до завершения обмена сообщениями, клиент повторно передает RT и повторно передает сообщение.

Каждый из вычислений нового RT включает в себя фактор рандомизации (RAND), который является случайным числом, выбранным с равномерным распределением между -0.1 и +0.1. Фактор рандомизации включен для сведения к минимуму синхронизации сообщений, передаваемых DHCP-клиентами.

Алгоритм выбора случайного числа не должен быть криптографически звуковым. Алгоритм СЛЕДУЕТ производить различную последовательность случайных чисел из каждого вызова DHCP-клиента.

RT для первой передачи сообщений основано на IRT:

RT = IRT + RAND*IRT

RT для каждой последующей передачи сообщений основано на предыдущем значении RT:

RT = 2*RTprev + RAND*RTprev

MRT указывает верхнюю границу значения RT (без учета рандомизации, добавленной с помощью RAND). Если MRT имеет значение 0, верхний предел для значения RT отсутствует. Иначе:

Если (RT > MRT)
RT = MRT + RAND*MRT

MRC определяет верхнюю границу количества раз, когда клиент может повторно передать сообщение. Если MRC не равен нулю, обмен сообщениями прерывается после того, как клиент передал сообщение MRC раз.

MRD определяет верхнюю границу времени, в течение которого клиент может повторно передать сообщение. Если MRD не равен нулю, обмен сообщениями прерывается по истечении времени MRD, поскольку клиент первым передал сообщение.

Если оба MRC и MRD не равны нулю, обмен сообщениями не выполняется, если выполняется одно из условий, указанных в предыдущих двух абзацах.

Если оба MRC и MRD равны нулю, клиент продолжает передавать сообщение до получения ответа.

Ожидается, что клиент не будет прослушивать ответ в течение всего периода RT и может отключить возможности прослушивания после ожидания, по крайней мере, короче RT и MAX_WAIT_TIME из-за экономии энергопотребления или по другим причинам. Конечно, клиент ДОЛЖЕН прослушать Reconfigure, если он договорился о его использовании с сервером.

16. Проверка сообщений

В этом разделе описывается, какие параметры действительны в отношении типов сообщений, и объясняет, что делать, когда клиент или сервер получает сообщение, которое содержит известные параметры, которые недействительны для этого сообщения. Например, в сообщении «Информация-запрос» Information-request не разрешается указывать параметр IA.

Клиенты и серверы МОГУТ выбрать либо (1) извлечь информацию из такого сообщения, если информация используется получателю, либо (2) полностью игнорировать такое сообщение и просто отбросить его.

Если сервер получает сообщение, которое он считает недействительным, он МОЖЕТ отправить сообщение «Ответить» (или «Рекламировать сообщение», если необходимо) с параметром «Идентификатор сервера» (см. Раздел 21.3), параметр «Идентификатор клиента» (см. Раздел 21.2) (если один из них был включен в сообщении) и параметр «Код состояния» (см. раздел 21.13) со статусом UnspecFail.

Клиенты, агенты ретрансляции и серверы НЕ ДОЛЖНЫ удалять сообщения, содержащие неизвестные параметры (или экземпляры опций поставщика с неизвестными значениями корпоративного номера). Их следует игнорировать, как если бы их не было. Это важно для будущих расширений DHCP.

Сервер ДОЛЖЕН отбрасывать любые запросы на получение, подтверждение, перевязку или информацию-запрос, которые он получает, с адресом назначения одноадресной передачи уровня 3.

Клиент или сервер ДОЛЖНЫ отбрасывать любые принятые сообщения DHCP с неизвестным типом сообщения.

16.1 Использование идентификаторов транзакций

Поле «transaction-id» содержит значение, используемое клиентами и серверами для синхронизации ответов сервера на клиентские сообщения. Клиенту СЛЕДУЕТ генерировать случайное число, которое не может быть легко угадано или предсказано для использования в качестве идентификатора транзакции для каждого нового отправленного им сообщения. Обратите внимание: если клиент генерирует легко предсказуемые идентификаторы транзакций, он может стать более уязвимым для определенных видов атак от нарушителей вне пути. Клиент ДОЛЖЕН оставить идентификатор транзакции неизменным при повторных передачах сообщения.

16.2  Сообщение «Запросить впервые» — Solicit Message

Клиенты ДОЛЖНЫ отбрасывать любые полученные «Запрошенные впервые» сообщения.

Серверы ДОЛЖНЫ отбрасывать любые «Запрошенные впервые» сообщения, которые не включают параметр Идентификатор клиента или которые включают параметр Идентификатор сервера.

Клиенты ДОЛЖНЫ отменить любое принятое «Рекламное» сообщение, которое отвечает любым из следующих условий:

  • сообщение не включает параметр Идентификатор сервера (см. раздел 21.3)
  • сообщение не включает параметр идентификатора клиента (см. раздел 21.2)
  • содержимое параметра идентификатора клиента не соответствует DUID клиента
  • значение поля «идентификатор транзакции» не соответствует значению, которое клиент использовал в сообщении «Сопровождение»

Серверы и ретрансляторы должны удалять любые принятые «Рекламные» сообщения.

16.4 Сообщение «Запрос» — Request

Клиенты ДОЛЖНЫ отказаться от любых полученных сообщений.

Серверы ДОЛЖНЫ отменить любое полученное сообщение запроса, которое отвечает любым из следующих условий:

  • сообщение не включает параметр «Идентификатор сервера» (см. раздел 21.3)
  • содержимое параметра «Идентификатор сервера» не соответствует DUID сервера
  • сообщение не включает параметр идентификатора клиента (см. раздел 21.2)

16.5 Сообщение «Подтвердить» — Confirm

Клиенты ДОЛЖНЫ отменить все принятые подтверждения.

Серверы ДОЛЖНЫ отбрасывать любые принятые сообщения подтверждения, которые не включают параметр идентификатора клиента (см. Раздел 21.2) или которые включают параметр идентификатора сервера (см. Раздел 21.3).

16.6 Сообщение «Обновить» — Renew

Клиенты ДОЛЖНЫ удалять любые полученные обновления.

Серверы ДОЛЖНЫ отменить любое полученное сообщение Renew, которое отвечает любым из следующих условий:

  • сообщение не включает параметр Идентификатор сервера (см. раздел 21.3)
  • содержимое параметра «Идентификатор сервера» не совпадает с идентификатором сервера
  • сообщение не включает параметр идентификатора клиента (см. раздел 21.2)

16.7 Сообщение «Пересвязать» — Rebind

Клиенты ДОЛЖНЫ удалять любые принятые сообщения перезаписи.

Серверы ДОЛЖНЫ отбрасывать любые принятые сообщения «Rebind», которые не включают параметр «Идентификатор клиента» (см. Раздел 21.2), или которые включают параметр «Идентификатор сервера» (см. Раздел 21.3).

16.8 Сообщение об отклонении — Decline

Клиенты ДОЛЖНЫ удалять любые принятые сообщения о снижении.

Серверы ДОЛЖНЫ отменить любое полученное сообщение о снижении, которое отвечает любым из следующих условий:

  • сообщение не включает параметр Идентификатор сервера (см. раздел 21.3)
  • содержимое параметра «Идентификатор сервера» не совпадает с идентификатором сервера
  • сообщение не включает параметр идентификатора клиента (см. раздел 21.2)

16.9 Сообщение о выпуске — Release

Клиенты ДОЛЖНЫ отказаться от любых полученных сообщений о выпуске.

Серверы ДОЛЖНЫ отменить любое полученное сообщение о выпуске, которое отвечает любым из следующих условий:

  • сообщение не включает параметр Идентификатор сервера (см. раздел 21.3)
  • содержимое параметра «Идентификатор сервера» не совпадает с идентификатором сервера
  • сообщение не включает параметр идентификатора клиента (см. раздел 21.2)

16.10 Сообщение «Ответ» — Reply

Клиенты ДОЛЖНЫ отменить любое полученное ответное сообщение, которое отвечает любым из следующих условий:

  • сообщение не включает параметр Идентификатор сервера (см. раздел 21.3)
  • поле «идентификатор транзакции» в сообщении не соответствует значению, используемому в исходном сообщении

Если клиент включил опцию «Идентификатор клиента» (см. Раздел 21.2) в исходное сообщение, ответное сообщение должно включать параметр идентификатора клиента, а содержимое параметра идентификатора клиента ДОЛЖНО соответствовать DUID клиента. Если клиент не включил параметр «Идентификатор клиента» в исходное сообщение, сообщение «Ответить» НЕ ДОЛЖНО включать параметр «Идентификатор клиента».

Серверы и ретрансляционные агенты ДОЛЖНЫ отбрасывать любые полученные ответные сообщения.

16.11 Сообщение «Переконфигурировать» — Reconfigure

Серверы и ретрансляционные агенты ДОЛЖНЫ отменить все принятые сообщения переконфигурации.

Клиенты ДОЛЖНЫ отказаться от любого сообщения переконфигурации, которое отвечает любым из следующих условий:

  • сообщение не было одноадресным для клиента
  • сообщение не включает параметр Идентификатор сервера (см. раздел 21.3)
  • сообщение не включает параметр идентификатора клиента (см. раздел 21.2), который содержит идентификатор клиента
  • сообщение не включает параметр «Переопределить сообщение» (см. раздел 21.19)
  • параметр msg-type Reconfigure Message не является допустимым значением
  • сообщение не включает аутентификацию (например, RKAP, см. раздел 20.4) или не проверяет проверку подлинности

16.12 Сообщение с запросом информации — Information-request

Клиенты ДОЛЖНЫ отбрасывать любые полученные информационные сообщения.

Серверы ДОЛЖНЫ удалять любое полученное сообщение «Информация-запрос», которое отвечает любым из следующих условий:

  • сообщение содержит параметр «Идентификатор сервера» (см. раздел 21.3), а DUID в опции не соответствует DUID сервера
  • сообщение включает опцию IA

16.13 Сообщение о пересылке — Relay-forward

Клиенты ДОЛЖНЫ отбрасывать любые принятые сообщения пересылки.

16.14 Сообщение с ретрансляцией — Relay-reply

Клиенты и серверы ДОЛЖНЫ удалять любые принятые сообщения ретрансляции.

17. Исходный адрес и выбор интерфейса клиента

Поведение клиента относительно выбора интерфейса отличается в зависимости от цели конфигурации.

17.1 Исходный адрес и выбор интерфейса для назначения адреса

Когда клиент отправляет сообщение DHCP на многоадресный адрес All_DHCP_Relay_Agents_and_Servers, он ДОЛЖЕН отправлять сообщение через интерфейс, для которого запрашивается информация о конфигурации (включая адреса). Тем не менее, клиент МОЖЕТ отправить сообщение через другой интерфейс, если интерфейс, для которого запрашивается конфигурация, является логическим интерфейсом без привязки прямой ссылки или клиент уверен, что к одной и той же ссылке подключены два интерфейса.

Когда клиент отправляет DHCP-сообщение непосредственно на сервер с помощью одноадресной передачи (после получения опции «Unicast Server» (см. Раздел 21.12) с этого сервера) адрес источника в заголовке датаграммы IPv6 ДОЛЖЕН быть адресом, назначенным интерфейсу, для которого клиент заинтересован в получении конфигурации и подходит для использования сервером в ответ на клиент.

17.2 Исходный адрес и выбор интерфейса для делегирования префикса

Делегированные префиксы не связаны с определенным интерфейсом так же, как адреса для назначения адреса, как указано в разделе 17.1 выше.

Когда клиент отправляет сообщение DHCP для делегирования префикса, он ДОЛЖЕН быть отправлен на интерфейс, связанный с маршрутизатором восходящего потока (как правило, подключенный к сети интернет-провайдера); см. [RFC7084]. Интерфейс восходящего потока обычно определяется конфигурацией. Это правило применяется даже в том случае, когда для каждого нисходящего интерфейса используется отдельный IA_PD.

Когда клиент отправляет сообщение DHCP непосредственно на сервер, используя одноадресную рассылку (после получения от него сервера Unicast (см. Раздел 21.12), адрес источника ДОЛЖЕН быть адресом, который находится из интерфейса выше по потоку, и который подходит для использования сервер в ответе на клиента.

18. Обмен конфигурациями DHCP

Клиент инициирует обмен сообщениями с сервером или серверами для получения или обновления интересующей информации о конфигурации. У клиента есть много причин для начала обмена конфигурацией. Некоторые из наиболее распространенных:

  1. как часть процесса конфигурирования / загрузки операционной системы,
  2. при запросе сделать это с помощью прикладного уровня (через API, специфичный для операционной системы)
  3. когда объявление маршрутизатора указывает, что DHCPv6 доступен для конфигурации адреса (см. раздел 4.2 [RFC4861]),
  4. как требуется для продления срока службы адресов (адресов) и / или делегированных префикс (ых), с использованием сообщений «Обновить и переадресовать», или
  5. после получения сообщения переконфигурации, когда этого требует сервер.

Клиент отвечает за создание IA и запрос на то, чтобы сервер назначил адреса и / или делегированные префиксы IA. Клиент сначала создает IA и присваивает им IAID. Затем клиент передает сообщение «Сопровождение», содержащее параметры IA, описывающие IA. Клиент НЕ ДОЛЖЕН использовать ни один из адресов или делегированных префиксов, для которых он пытается получить привязки, отправив сообщение «Запросить». В частности, если клиент имел некоторые действительные привязки и решил запустить процесс обнаружения сервера для получения тех же привязок с другого сервера, клиент ДОЛЖЕН прекратить использование адресов и делегированных префиксов для привязок, которые он получил от предыдущего сервера (см. раздел 18.2.7 для более подробной информации о том, что означает «остановить использование» в этом контексте) и что он теперь пытается получить с нового сервера.

Клиент DHCP, которому не требуется назначать DHCP-сервер для IP-адресов или делегированных префиксов, может получить информацию о конфигурации, такую как список доступных DNS-серверов [RFC3646] или NTP-серверов [RFC5908], посредством одного сообщения и обмена ответами с помощью DHCP-сервер. Чтобы получить информацию о конфигурации, клиент сначала отправляет сообщение «Запрос информации» (см. Раздел 18.2.6) на адрес многоадресной рассылки All_DHCP_Relay_Agents_and_Servers. Серверы отвечают на сообщение «Ответ», содержащее информацию о конфигурации для клиента (см. Раздел 18.3.6).

Чтобы запросить назначение одного или нескольких адресов или делегированных префиксов, клиент сначала находит DHCP-сервер, а затем запрашивает назначение адресов / префиксов и другой информации о конфигурации с сервера. Клиент делает это, отправив сообщение «Запросить» (см. Раздел 18.2.1) на адрес многоадресной рассылки All_DHCP_Relay_Agents_and_Servers и собирая рекламные сообщения с серверов, которые отвечают на сообщение клиента; клиент затем выбирает сервер, из которого он хочет получить информацию о конфигурации. Этот процесс называется открытием сервера. Когда клиент выбрал сервер, он отправляет сообщение «Запрос» на этот сервер, как описано в разделе 18.2.2.

Клиент, желающий выполнить обмен сообщениями «Запрашивать / Ответить», описанный в разделе 18.2.1, включает опцию «Быстрая фиксация» (см. Раздел 21.14) в сообщении «Запросить».

Серверы, которые могут назначать адреса или делегированные префиксы IA, отвечают клиенту с сообщением «Реклама» или «Ответ», если клиент включил опцию «Быстрая фиксация», и сервер настроен на ее принятие.

Если сервер отвечает сообщением «Реклама», клиент инициирует обмен конфигурацией, как описано в разделе 18.2.2.

Сервер может инициировать обмен сообщениями с клиентом, отправив сообщение Reconfigure, чтобы заставить клиента отправить сообщение Renew, Rebind или Information-request, чтобы обновить информацию о своей конфигурации, как только сообщение Reconfigure будет получено клиентом.

На рисунке 9 показана временная диаграмма сообщений, обмен которыми осуществляется между клиентом и двумя серверами, для типичного жизненного цикла одного или нескольких договоров аренды. Это начинается с обмена сообщениями «Запрашивать / рекламировать / запрос / ответ» с четырьмя сообщениями для получения аренды (ов), за которым следует обмен сообщениями «Повторить / Ответить» с двумя сообщениями, чтобы продлить срок службы аренды (ов), а затем заканчивается двумя -message Release / Reply exchange, чтобы прекратить использование клиентом договора аренды.

Рисунок 9 - Временная диаграмма сообщений, обмен которыми осуществляется между клиентом и двумя серверами для типичного жизненного цикла одной или нескольких лизинговых операций
Рисунок 9 — Временная диаграмма сообщений, обмен которыми осуществляется между клиентом и двумя серверами для типичного жизненного цикла одной или нескольких лизинговых операций

18.1 Единый обмен для нескольких вариантов IA

В этом документе предполагается, что клиент ДОЛЖЕН использовать одну транзакцию для всех параметров IA, необходимых для интерфейса; это упрощает реализацию клиента и уменьшает потенциальное количество необходимых транзакций (для фона по этому выбору дизайна см. раздел 4 в [RFC7550]). Чтобы облегчить использование клиентом одной транзакции для всех параметров IA, серверы ДОЛЖНЫ возвращать те же значения T1 / T2 для всех параметров IA в ответе (см. Разделы 18.3.2, 18.3.4 и 18.3.5), чтобы клиент будет генерировать единую транзакцию при обновлении или восстановлении ее аренды. Однако, поскольку некоторые серверы могут еще не соответствовать этому требованию, клиент ДОЛЖЕН быть подготовлен к выбору соответствующих T1 / T2 раз, как описано в Разделе 18.2.4.

18.2 Поведение клиента

Клиент использует сообщение «Запросить» для обнаружения DHCP-серверов, настроенных для назначения аренды или возврата других параметров конфигурации на ссылку, к которой прикреплен клиент.

Клиент использует сообщения Request, Renew, Rebind, Release и Decline в течение обычного жизненного цикла адресов и делегированных префиксов.

Когда клиент обнаруживает, что он, возможно, переместился на новую ссылку, он использует Confirm, если он имеет только адреса и Rebind, если он делегировал префиксы (и адреса). Он использует информационные сообщения, когда ему нужна информация о конфигурации, но нет адресов и префиксов.

Когда клиент запрашивает несколько типов опций IA или несколько экземпляров одних и тех же типов IA в запросе, запросе, обновлении или повторной привязке, возможно, что доступный сервер (ы) может быть настроен только для предоставления подмножества из них. Когда это возможно, клиент ДОЛЖЕН использовать наилучшую конфигурацию и продолжать запрашивать дополнительные IA в последующих сообщениях. Это позволяет клиенту поддерживать один сеанс и конечный автомат. На практике, особенно в случае обработки запросов IA_NA и IA_PD [RFC7084], эта ситуация должна быть редкой или результатом временной оперативной ошибки. Таким образом, более вероятно, что клиент получит всю конфигурацию, если он продолжит в каждом последующем обмене конфигурацией запросить всю информацию о конфигурации, которую он запрограммировал, чтобы попытаться получить, включая любые параметры конфигурации состояния, для которых не было возвращено никаких результатов в предыдущем обмен сообщениями.

После получения сообщения Reconfigure с сервера клиент отвечает сообщением Renew, Rebind или Information-request, как указано параметром Reconfigure Message (см. Раздел 21.19). Клиент ДОЛЖЕН быть подозрительным к сообщению Reconfigure (они могут быть поддельными), и он НЕ ДОЛЖЕН отказаться от каких-либо ресурсов, которые он мог бы уже получить. Клиент ДОЛЖЕН обрабатывать сообщение Reconfigure, как если бы таймер T1 истек. Клиент ожидает, что сервер отправит IA и / или другую информацию о конфигурации клиенту в ответном сообщении.

Если у клиента есть исходный адрес достаточной области, который может использоваться сервером в качестве обратного адреса, и клиент получил параметр «Унифицированный сервер» (см. Раздел 21.12) с сервера, клиент ДОЛЖЕН одноадресной передачи любого запроса, обновления, и Отклонить сообщения на сервер.

Использование одноадресной рассылки может избежать задержек из-за ретрансляции сообщений агентами ретрансляции, а также избежать накладных расходов на серверах из-за доставки клиентских сообщений на несколько серверов. Однако, требуя, чтобы клиент ретранслировал все сообщения DHCP через ретрансляционный агент, можно включить опции агента ретрансляции во все сообщения, отправленные клиентом. Сервер должен включить использование одноадресной рассылки только тогда, когда параметры ретранслятора не будут использоваться.

18.2.1 Создание и передача запрашиваемых сообщений (Solicit)

Клиент устанавливает поле «msg-type» в SOLICIT. Клиент генерирует идентификатор транзакции и вставляет это значение в поле «идентификатор транзакции».

Клиент должен ДОЛЖЕН включить параметр идентификатора клиента (см. Раздел 21.2), чтобы идентифицировать себя на сервере. Клиент включает опции IA для любых IA, которым он хочет, чтобы сервер назначил аренду.

Клиент ДОЛЖЕН включать опцию «Истекшее время» (см. Раздел 21.9), чтобы указать, как долго клиент пытается завершить текущий обмен сообщениями DHCP.

Клиент использует параметры IA_NA (см. Раздел 21.4), чтобы запросить назначение не временных адресов, опций IA_TA (см. Раздел 21.5), чтобы запросить назначение временных адресов и параметры IA_PD (см. Раздел 21.21), чтобы запросить делегирование префикса. Параметры IA_NA, IA_TA или IA_PD, или комбинация всех, могут быть включены в сообщения DHCP. Кроме того, могут быть включены несколько экземпляров любого типа опций IA.

Клиент МОЖЕТ включать адреса в опциях IA Address (см. Раздел 21.6), инкапсулированные в опции IA_NA и IA_TA, в качестве подсказок для сервера о адресах, для которых клиент имеет предпочтение.

Клиент МОЖЕТ включать значения в опциях префикса IA (см. Раздел 21.22), инкапсулированные в опции IA_PD, в качестве подсказок для делегированного префикса и / или длины префикса, для которых предпочтение отдается клиенту. См. Раздел 18.2.4 для более подробных советов.

Клиент ДОЛЖЕН включать опцию «Запрос опциона» (ORO) (см. Раздел 21.7), чтобы запросить опцию SOL_MAX_RT (см. Раздел 21.24) и любые другие параметры, которые клиент заинтересован в получении. Клиент МОЖЕТ дополнительно включать экземпляры тех опций, которые указаны в опции запроса опциона, со значениями данных в качестве подсказок для сервера о значениях параметров, которые клиент хотел бы вернуть.

Клиент включает опцию Reconfigure Accept (см. Раздел 21.20), если клиент готов принять переконфигурирование сообщений с сервера.

Клиент НЕ ДОЛЖЕН включать какие-либо другие параметры в сообщение «Запросить», за исключением случаев, когда это разрешено в определении отдельных параметров.

Первое запрашиваемое сообщение от клиента на интерфейсе ДОЛЖНО задерживаться на случайное время между 0 и SOL_MAX_DELAY. Эта случайная задержка помогает десинхронизировать клиентов, которые одновременно запускают сеанс DHCP, например, после восстановления после сбоя питания или после отключения маршрутизатора, увидев, что DHCP доступен в рекламных сообщениях маршрутизатора (см. Раздел 4.2 [RFC4861]).

Клиент передает сообщение в соответствии с разделом 15, используя следующие параметры:

IRT SOL_TIMEOUT
MRT SOL_MAX_RT
MRC 0
MRD 0

Клиент, который хочет использовать обмен сообщениями с двумя сообщениями Rapid Commit, включает опцию «Быстрая фиксация» (см. Раздел 21.14) в сообщении «Запросить впервые». Клиент может получать несколько разных ответов с разных серверов. Клиент будет отмечать любые допустимые рекламные сообщения, которые он получает. Клиент будет отбрасывать любые ответные сообщения, которые не содержат параметр «Быстрая фиксация».

После получения действительного ответа с опцией Rapid Commit клиент обрабатывает сообщение, как описано в разделе 18.2.10.

В конце первого периода RT, если не получено подходящих сообщений ответа, но у клиента есть допустимые рекламные сообщения, клиент обрабатывает рекламу, как описано в разделе 18.2.9.

Если клиент впоследствии получает действительное сообщение «Ответ», которое включает опцию «Быстрая фиксация», он выполняет одно из следующих действий:

  • обрабатывает ответное сообщение, как описано в разделе 18.2.10, и отбрасывает любые ответные сообщения, полученные в ответ на сообщение «Запрос»
  • обрабатывает любые ответные сообщения, полученные в ответ на сообщение «Запрос», и отбрасывает ответное сообщение, которое включает опцию «Быстрая фиксация»

Если клиент ожидает сообщения «Реклама», механизм, описанный в Разделе 15, изменяется следующим образом для использования при передаче Запрошенных сообщений. Обмен сообщениями не прекращается с момента получения Рекламы до истечения первого RT. Скорее, клиент собирает действительные рекламные сообщения до истечения первого RT. Кроме того, первая RT ДОЛЖНА быть выбрана строго больше IRT, выбирая RAND строго больше 0.

Клиент ДОЛЖЕН собирать действительные рекламные сообщения в течение первых секунд RT, если только он не получает действительное рекламное сообщение с преференциальным значением 255. Значение предпочтения переносится в опции «Предпочтение» (см. Раздел 21.8). Любая действительная реклама, которая не включает опцию «Предпочтение», считается значением предпочтения 0. Если клиент получает действительное объявление «Реклама», которое включает опцию «Предпочтение» с значением предпочтения 255, клиент немедленно начинает обмен сообщениями с клиентом (как описано в разделе 18.2.2), отправив сообщение «Запрос» на сервер, с которого было получено сообщение «Реклама». Если клиент получает действительное объявление «Реклама», которое не включает опцию «Предпочтение» с значением предпочтения 255, клиент продолжает ждать, пока не истечет первый RT. Если первый RT истекает, и клиент получил правильное объявление, клиент ДОЛЖЕН продолжить обмен сообщениями, инициированным клиентом, отправив сообщение «Запрос».

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

Клиент DHCP СЛЕДУЕТ выбирать значения MRC и MRD 0. Если клиент DHCP настроен либо MRC, либо MRD, установленным на значение, отличное от 0, он ДОЛЖЕН прекратить попытки настроить интерфейс, если обмен сообщениями не выполняется. После того, как клиент DHCP перестает пытаться настроить интерфейс, он ДОЛЖЕН перезапустить процесс реконфигурации после некоторого внешнего события, такого как ввод пользователя, перезапуск системы или когда клиент подключен к новой ссылке.

18.2.2 Создание и передача сообщений запроса (Request)

Клиент использует сообщение «Запрос» для заполнения аренды IA и получения другой информации о конфигурации. Клиент включает одну или несколько опций IA в сообщении «Запрос». Затем сервер возвращает лизинг и другую информацию об ИА клиенту в вариантах IA в ответном сообщении.

Клиент устанавливает поле «msg-type» в «ЗАПРОСИТЬ». Клиент генерирует идентификатор транзакции и вставляет это значение в поле «идентификатор транзакции».

Клиент ДОЛЖЕН включать идентификатор целевого сервера в опции «Идентификатор сервера» (см. Раздел 21.3).

Клиент должен ДОЛЖЕН включить параметр идентификатора клиента (см. Раздел 21.2), чтобы идентифицировать себя на сервере. Клиент добавляет любые другие подходящие опции, включая один или несколько вариантов IA.

Клиент ДОЛЖЕН включать опцию «Истекшее время» (см. Раздел 21.9), чтобы указать, как долго клиент пытается завершить текущий обмен сообщениями DHCP.

Клиент ДОЛЖЕН включать опцию «Запрос опциона» (см. Раздел 21.7), чтобы запросить опцию SOL_MAX_RT (см. Раздел 21.24) и любые другие параметры, которые клиент заинтересован в получении. Клиент МОЖЕТ дополнительно включать экземпляры тех опций, которые указаны в опции запроса опциона, со значениями данных в качестве подсказок для сервера о значениях параметров, которые клиент хотел бы вернуть.

Клиент включает опцию Reconfigure Accept (см. Раздел 21.20), если клиент готов принять переконфигурирование сообщений с сервера.

Клиент передает сообщение в соответствии с разделом 15, используя следующие параметры:

IRT REQ_TIMEOUT
MRT REQ_MAX_RT
MRC REQ_MAX_RC
MRD 0

Если обмен сообщениями не выполняется, клиент принимает действие на основе локальной политики клиента. Примеры действий, которые может предпринять клиент, включают следующее:

  • Выберите другой сервер из списка серверов, известных клиенту, например серверов, на которые ответил сообщение «Реклама».
  • Инициировать процесс обнаружения сервера, описанный в Разделе 18
  • Завершите процесс конфигурации и сбой отчета.

18.2.3 Создание и передача подтверждающих (Confirm) сообщений

Клиент использует сообщение подтверждения, когда он имеет только адреса (без делегированных префиксов), назначенные DHCP-сервером, чтобы определить, все ли он подключен к той же ссылке, когда клиент обнаруживает изменение сетевой информации, как описано в разделе 18.2.12.

Клиент устанавливает поле «msg-type» в CONFIRM. Клиент генерирует идентификатор транзакции и вставляет это значение в поле «идентификатор транзакции».

Клиент должен ДОЛЖЕН включить параметр идентификатора клиента (см. Раздел 21.2), чтобы идентифицировать себя на сервере.

Клиент ДОЛЖЕН включать опцию «Истекшее время» (см. Раздел 21.9), чтобы указать, как долго клиент пытается завершить текущий обмен сообщениями DHCP.

Клиент включает опции IA для всех IA, назначенных интерфейсу, для которого отправляется сообщение подтверждения. Варианты IA включают все адреса, которые клиент в настоящее время связывает с этими IA. Клиент СЛЕДУЕТ устанавливать поля T1 и T2 в любых параметрах IA_NA (см. Раздел 21.4), а также поля предпочтительного срока службы и срока действия в параметрах IA Address (см. Раздел 21.6) на 0, так как сервер будет игнорировать эти поля.

Первое сообщение подтверждения от клиента на интерфейсе ДОЛЖНО быть отложено на случайное время между 0 и CNF_MAX_DELAY. Клиент передает сообщение в соответствии с разделом 15, используя следующие параметры:

IRT CNF_TIMEOUT
MRT CNF_MAX_RT
MRC 0
MRD CNF_MAX_RD

Если клиент не получает ответов до того, как процесс передачи сообщения завершается, как описано в разделе 15, клиент ДОЛЖЕН продолжать использовать любую аренду, используя последние известные времена жизни для этих договоров аренды, и ДОЛЖЕН продолжать использовать любые другие ранее полученные параметры конфигурации.

18.2.4 Создание и передача обновленных сообщений (Renew)

Чтобы расширить предпочтительные и действительные сроки жизни для аренды, назначенной IA, и получить новые адреса или делегированные префиксы для IA, клиент отправляет сообщение Renew на сервер, с которого были получены арендные договоры; сообщение Renew включает варианты IA для IA, срок действия которых должен быть расширен. Клиент включает опции IA Address (см. Раздел 21.6) в IA_NA (см. Раздел 21.4) и IA_TA (см. Раздел 21.5) параметры для адресов, назначенных IA. Клиент включает опции префикса IA (см. Раздел 21.22) в вариантах IA_PD (см. Раздел 21.21) для делегированных префиксов, назначенных IA.

Сервер контролирует время, с которым клиент должен связаться с сервером, чтобы продлить срок службы назначенных лизинга через значения T1 и T2, назначенные IA. Однако, поскольку клиенту ДОЛЖНО возобновлять / переподчинять все IA с сервера одновременно, клиент ДОЛЖЕН выбирать T1 и T2 раз из всех параметров IA, которые гарантируют, что клиент инициирует передачу сообщений Renew / Rebind не позднее, чем на T1 / T2, связанное с любым связыванием клиента (самый ранний T1 / T2).

В момент времени T1 клиент инициирует обмен сообщениями Renew / Reply, чтобы продлить срок службы на любой аренде в IA.

Клиент ДОЛЖЕН также инициировать обмен сообщениями Renew / Reply до времени T1, если локальный адрес ссылки клиента, используемый в предыдущих взаимодействиях с сервером, более недействителен и готов получать сообщения Reconfigure.

Если T1 или T2 были установлены на 0 сервером (для IA_NA или IA_PD), либо нет T1 или T2 раз (для IA_TA) в предыдущем ответе, клиент может по своему усмотрению отправить обновление или перевязку сообщение, соответственно. Клиент ДОЛЖЕН следовать правилам, определенным в Разделе 14.2.

Клиент устанавливает поле «msg-type» в RENEW. Клиент генерирует идентификатор транзакции и вставляет это значение в поле «идентификатор транзакции».

Клиент ДОЛЖЕН включать параметр «Идентификатор сервера» (см. Раздел 21.3) в сообщении «Обновление», идентифицируя сервер, с которым недавно был передан клиент.

Клиент должен ДОЛЖЕН включить параметр идентификатора клиента (см. Раздел 21.2), чтобы идентифицировать себя на сервере. Клиент добавляет любые подходящие опции, включая один или несколько вариантов IA.

Клиент ДОЛЖЕН включать опцию «Истекшее время» (см. Раздел 21.9), чтобы указать, как долго клиент пытается завершить текущий обмен сообщениями DHCP.

Для IA, которым были назначены лизинга, клиент включает соответствующую опцию IA, содержащую опцию IA Address для каждого адреса, назначенного для IA и префикса IA для каждого префикса, назначенного IA. Клиент НЕ ДОЛЖЕН включать адреса и префиксы в любую опцию IA, которую клиент не получал с сервера или который больше не действителен (срок действия которого равен 0).

Клиент МОЖЕТ включать опцию IA для каждой привязки, которую он желает, но не смог получить. В этом случае, если клиент включает в себя параметр IA_PD для запроса делегирования префикса, клиент МОЖЕТ включать опцию префикса IA, инкапсулированную в опции IA_PD, с полем «IPv6-prefix», установленным в 0 и поле «префикс длины» до нужной длины префикса, который должен быть делегирован. Сервер МОЖЕТ использовать это значение в качестве подсказки для длины префикса. Клиент НЕ ДОЛЖЕН включать опцию префикса IA с полем «IPv6-prefix», установленным в 0, если он не дает подсказки для длины префикса.

Клиент включает опцию «Запрос опциона» (см. Раздел 21.7), чтобы запросить опцию SOL_MAX_RT (см. Раздел 21.24) и любые другие параметры, которые клиент заинтересован в получении. Клиент МОЖЕТ включать опции с значениями данных в качестве подсказок для сервера о значениях параметров, которые клиент хотел бы вернуть.

Клиент передает сообщение в соответствии с разделом 15, используя следующие параметры:

IRT REN_TIMEOUT
MRT REN_MAX_RT
MRC 0
MRD Remaining time until earliest T2

Обмен сообщениями прекращается, когда достигается самое раннее время T2. Пока клиент отвечает на Reconfigure, клиент игнорирует и отбрасывает любые дополнительные сообщения Reconfigure, которые он может получить.

Обмен сообщениями прекращается, когда достигается самое раннее время T2, после чего клиент начинает обмен сообщениями Rebind (см. Раздел 18.2.5).

18.2.5 Создание и передача сообщений перезаписи (Rebind)

В момент времени T2 (который будет достигнут только в том случае, если сервер, на который было отправлено сообщение Renew, начиная со времени T1, не ответил), клиент инициирует обмен сообщениями Rebind / Reply с любым доступным сервером.

Rebind также используется для проверки делегированных привязок префикса, но с различными параметрами повторной передачи, как описано в разделе 18.2.3.

Клиент создает сообщение Rebind, как описано в разделе 18.2.4, со следующими отличиями:

  • Клиент устанавливает поле «msg-type» в REBIND.
  • Клиент не включает параметр «Идентификатор сервера» (см. Раздел 21.3) в сообщении «REBIND».

Клиент передает сообщение в соответствии с разделом 15, используя следующие параметры:

IRT REB_TIMEOUT
MRT REB_MAX_RT
MRC 0
MRD Remaining time until valid lifetimes of all leases in all IAs have expired

Если все лизинга для IA истекли, клиент может выбрать включить этот IA в последующие сообщения Rebind, чтобы указать, что клиент заинтересован в назначении аренды этому IA.

Обмен сообщениями прекращается, когда истек срок действия всех лизинговых платежей по всем IA, и в это время клиент использует сообщение «Запросить» для поиска нового DHCP-сервера и отправляет запрос на истекшие IA на новый сервер. Если завершенный обмен Rebind был инициирован в результате приема сообщения Reconfigure, клиент игнорирует и отбрасывает сообщение Reconfigure.

18.2.6 Создание и передача сообщений с информацией-запросами (Information-request)

Клиент использует сообщение «Информация-запрос» для получения информации о конфигурации без присвоения им адресов и / или делегированных префиксов.

Клиент устанавливает поле «msg-type» в «ИНФОРМАЦИОННО-ЗАПРОС». Клиент генерирует идентификатор транзакции и вставляет это значение в поле «идентификатор транзакции».

Клиент ДОЛЖЕН включать в себя параметр идентификатора клиента (см. Раздел 21.2), чтобы идентифицировать себя на сервере (однако, см. Раздел 4.3.1 из [RFC7844] по причинам, по которым клиент может не захотеть включить эту опцию). Если клиент не включает параметр «Идентификатор клиента», сервер не сможет возвращать клиенту какие-либо клиентские параметры, или сервер может отказаться от ответа на сообщение вообще.

Клиент ДОЛЖЕН включать опцию «Истекшее время» (см. Раздел 21.9), чтобы указать, как долго клиент пытается завершить текущий обмен сообщениями DHCP.

Клиент ДОЛЖЕН включать опцию «Запрос опциона» (см. Раздел 21.7), чтобы запросить опцию INF_MAX_RT (см. Раздел 21.25), параметр «Время обновления информации» (см. Раздел 21.23) и любые другие параметры, которые клиент заинтересован в получении. Клиент МОЖЕТ включать опции с значениями данных в качестве подсказок для сервера о значениях параметров, которые клиент хотел бы вернуть.

При ответе на переконфигурирование клиент включает в себя параметр Идентификатор сервера (см. Раздел 21.3) с идентификатором из сообщения Reconfigure, на которое отвечает клиент.

Первое сообщение «Информация-запрос» от клиента на интерфейсе ДОЛЖНО быть отложено на случайное время между 0 и INF_MAX_DELAY. Клиент передает сообщение в соответствии с разделом 15, используя следующие параметры:

IRT INF_TIMEOUT
MRT INF_MAX_RT
MRC 0
MRD 0

18.2.7 Создание и передача сообщений о выпуске (Release)

Чтобы освободить одну или несколько договоров аренды, клиент отправляет сообщение Release на сервер.

Клиент устанавливает поле «msg-type» в RELEASE. Клиент генерирует идентификатор транзакции и помещает это значение в поле «transaction-id».

Клиент помещает идентификатор сервера, который выделил аренду (ы) в опции «Идентификатор сервера» (см. Раздел 21.3).

Клиент должен ДОЛЖЕН включить параметр идентификатора клиента (см. Раздел 21.2), чтобы идентифицировать себя на сервере.

Клиент ДОЛЖЕН включать опцию «Истекшее время» (см. Раздел 21.9), чтобы указать, как долго клиент пытается завершить текущий обмен сообщениями DHCP.

Клиент включает в себя опции, содержащие IA для аренды, которые он выпускает в поле «options». Договор аренды должен быть включен в ИА. Любые аренды для IA, которые клиент хочет продолжать использовать, НЕ ДОЛЖНЫ быть добавлены в IA.

Клиент ДОЛЖЕН прекратить использование всех выпущенных лизинга до того, как клиент начнет процесс обмена сообщениями Release. Для адреса это означает, что адрес ДОЛЖЕН быть удален из интерфейса. Для делегированного префикса это означает, что префикс ДОЛЖЕН быть рекламирован с предпочтительным временем жизни и действительным временем жизни 0 в рекламном сообщении маршрутизатора, как описано в части (e) раздела 5.5.3 [RFC4862]; также см. требование L-13 в разделе 4.3 документа [RFC7084].

Клиент НЕ ДОЛЖЕН использовать ни один из адресов, которые он освобождает в качестве исходного адреса в сообщении о выпуске или в любом последующем переданном сообщении.

Поскольку сообщения Release могут быть потеряны, клиент должен повторно передать Release, если ответ не получен. Тем не менее, есть сценарии, когда клиент может не пожелать дождаться нормального тайм-аута повторной передачи до отказа (например, при отключении питания). Реализации СЛЕДУЕТ повторно передавать один или несколько раз, но МОЖНО отказаться от процедуры повторной передачи раньше.

Клиент передает сообщение в соответствии с разделом 15, используя следующие параметры:

IRT REL_TIMEOUT
MRT 0
MRC REL_MAX_RC
MRD 0

Если лизинг освобождается, но ответ с сервера DHCP теряется, клиент будет повторно передавать сообщение о выпуске, и сервер может ответить с ответом, указывающим статус NoBinding. Следовательно, клиент не обрабатывает сообщение «Сообщение» со статусом «Нет привязки» в обмене сообщения «Отмена», как если бы он указывал на ошибку.

Обратите внимание, что если клиент не может освободить аренду, каждая аренда, назначенная IA, будет возвращена сервером, когда истечет срок действия этого срока аренды.

18.2.8 Создание и передача сообщений об отказе (Decline)

Если клиент обнаруживает, что один или несколько адресов, назначенных ему сервером, уже используются другим узлом, клиент отправляет на сервер сообщение «Отклонить», чтобы сообщить ему, что адрес является подозрительным.

Сообщение «Отклонение» не используется при делегировании префикса; таким образом, клиент НЕ ДОЛЖЕН включать опции IA_PD (см. раздел 21.21) в сообщении «Снижение».

Клиент устанавливает поле «msg-type» в DECLINE. Клиент генерирует идентификатор транзакции и помещает это значение в поле «transaction-id».

Клиент помещает идентификатор сервера, который выделяет адреса (ы) в опции «Идентификатор сервера» (см. Раздел 21.3).

Клиент должен ДОЛЖЕН включить параметр идентификатора клиента (см. Раздел 21.2), чтобы идентифицировать себя на сервере.

Клиент ДОЛЖЕН включать опцию «Истекшее время» (см. Раздел 21.9), чтобы указать, как долго клиент пытается завершить текущий обмен сообщениями DHCP.

Клиент включает в себя параметры, содержащие IA для адресов, которые он отклоняет в поле «Параметры». Адреса, которые необходимо отклонить, ДОЛЖНЫ быть включены в IA. Любые адреса для IA, которые клиент хочет продолжить использовать, не должны добавляться в IA.

Клиент НЕ ДОЛЖЕН использовать любой из адресов, которые он отклоняет как исходный адрес в сообщении «Снижение» или в любом последующем переданном сообщении.

Клиент передает сообщение в соответствии с разделом 15, используя следующие параметры:

IRT DEC_TIMEOUT
MRT 0
MRC DEC_MAX_RC
MRD 0

Если адреса отклоняются, а ответ с сервера DHCP теряется, клиент будет повторно передавать сообщение о снижении, и сервер может ответить с ответом, указывающим статус NoBinding. Поэтому клиент не обрабатывает сообщение «Сообщение» со статусом «Нет привязки» в обмене сообщения «Снижение», как если бы он указывал на ошибку.

Клиент НЕ ДОЛЖЕН отправлять сообщение о выпуске для других привязок, которые он мог получить только потому, что он отправил сообщение «Отклонить». Клиент ДОЛЖЕН сохранять неконфликтные привязки. Клиент ДОЛЖЕН относиться к неспособности получить привязку (из-за конфликта) как эквивалент того, что не получил привязку, насколько он ведет себя при отправке сообщений Renew и Rebind.

18.2.9 Получение рекламных сообщений

После получения одного или нескольких допустимых рекламных сообщений клиент выбирает одно или несколько рекламных сообщений на основе следующих критериев.

  • Те, кто рекламирует сообщения с наивысшим значением предпочтений сервера, ДОЛЖНЫ быть предпочтительнее всех других рекламных сообщений. Клиент МОЖЕТ выбрать менее предпочтительный сервер, если на этом сервере есть лучший набор объявленных параметров, например доступный набор IA, а также набор других параметров конфигурации, рекламируемых.
  • В группе объявлений «Реклама» с тем же значением предпочтений сервера клиент МОЖЕТ выбирать те серверы, чьи рекламные сообщения рекламируют информацию, представляющую интерес для клиента.

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

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

Если клиенту необходимо выбрать альтернативный сервер в случае, если выбранный сервер не отвечает, клиент выбирает следующий сервер в соответствии с указанными выше критериями.

Клиент ДОЛЖЕН обрабатывать любой параметр SOL_MAX_RT (см. Раздел 21.24) и INF_MAX_RT (см. Раздел 21.25), присутствующий в сообщении «Реклама», даже если сообщение содержит параметр «Код состояния» (см. Раздел 21.13), указывающий на сбой, и сообщение «Реклама» будет отбрасывается клиентом. Клиент ДОЛЖЕН только обновлять свои значения SOL_MAX_RT и INF_MAX_RT, если все принятые рекламные сообщения, содержащие соответствующую опцию, указали одно и то же значение; в противном случае он должен использовать значение по умолчанию (см. раздел 7.6).

Клиент ДОЛЖЕН игнорировать любое рекламное сообщение, которое не содержит адресов (параметры IA Address (см. Раздел 21.6), инкапсулированные в опции IA_NA (см. Раздел 21.4) или параметры IA_TA (см. Раздел 21.5)), и не делегированные префиксы (варианты префикса IA (см. Раздел 21.22 ), инкапсулированные в опции IA_PD (см. раздел 21.21)), за исключением того, что клиент:

  • ДОЛЖЕН обрабатывать включенную опцию SOL_MAX_RT
  • ДОЛЖЕН обрабатывать включенную опцию INF_MAX_RT

Клиент может записывать в журнал активности или отображать пользователю любые связанные с ним сообщения (состояния) состояния.

Клиент, игнорирующий сообщение «Реклама», НЕ ДОЛЖЕН перезапускать таймер повторной передачи запроса.

18.2.10 Получение сообщений ответа

После получения действительного ответного сообщения в ответ на опцию «Запрашивать с быстрой компиляцией» (см. Раздел 21.14), запрос, подтверждение, обновление, пересказка или сообщение с запросом информации, клиент извлекает код состояния верхнего уровня (см. Раздел 21.13), если они имеются.

Клиент ДОЛЖЕН обрабатывать любую опцию SOL_MAX_RT (см. Раздел 21.24) и INF_MAX_RT (см. Раздел 21.25), присутствующую в ответном сообщении, даже если сообщение содержит параметр «Код состояния», указывающий на сбой.

Если клиент получает ответное сообщение с кодом состояния UnspecFail, сервер указывает, что он не смог обработать сообщение клиента из-за неопределенного отказа. Если клиент повторно передает исходное сообщение на тот же сервер, чтобы повторить требуемую операцию, клиент ДОЛЖЕН ограничить скорость, с которой он повторно передает сообщение, и ограничивать продолжительность времени, в течение которого он повторно передает сообщение (см. Раздел 14.1).

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

В противном случае (код состояния или другой код состояния) клиент обрабатывает ответ, как описано ниже, на основе исходного сообщения, для которого был получен ответ.

Клиент может выбрать сообщение любого кода состояния или сообщения из параметра «Код состояния» в ответном сообщении.

Когда клиент получил опцию конфигурации в более раннем ответе, а затем отправляет запрос Renew, Rebind или Information-request, а запрошенная опция отсутствует в ответе, клиент ДОЛЖЕН прекратить использование ранее полученной информации о конфигурации. Другими словами, клиент должен вести себя так, как будто он никогда не получал эту конфигурацию и не возвращался в соответствующее состояние по умолчанию. Если нет жизнеспособного способа прекратить использование полученной информации о конфигурации, значения, полученные / настроенные из опции, могут сохраняться, если нет других источников для этих данных, и они не имеют внешнего воздействия. Например, клиент, который ранее получил параметр FQDN клиента (см. [RFC4704]) и использовал его для настройки своего имени хоста, может продолжить его использование, если нет разумного способа, чтобы узел удалял свое имя хоста и не имел внешнего влияние. В качестве встречного примера клиент, который ранее получил адрес сервера NTP с сервера DHCP и больше не получает его, ДОЛЖЕН прекратить использование настроенного адреса сервера NTP. Клиент ДОЛЖЕН быть открыт для других источников одной и той же информации о конфигурации. Это поведение не относится к каким-либо параметрам IA, так как их обработка подробно описана в следующем разделе.

Когда клиент получает запрошенную опцию, которая имеет обновленное значение из того, что было ранее получено, клиенту ДОЛЖНО использовать это обновленное значение как можно скорее для информации о его конфигурации.

18.2.10.1 Ответ на запрос (с быстрой фиксацией), запрос, обновление или переделка — Reply for Solicit (with Rapid Commit), Request, Renew, or
Rebind

Если клиент получает статус NotOnLink с сервера в ответ на опцию «Запрашивать» (с опцией «Быстрая фиксация», см. Раздел 21.14) или «Запрос», клиент может либо переиздать сообщение без указания адресов, либо перезапустить процесс обнаружения DHCP-сервера (см. Раздел 18).

Если ответ был получен в ответ на сообщение «Запрашивать» (с опцией быстрой компиляции), «Запросить, обновить или переадресовать», клиент обновит информацию, которую он записал об IA, из параметров IA, содержащихся в сообщении «Ответ»:

  • Рассчитайте T1 и T2 раз (на основе значений T1 и T2, отправленных в пакете и времени приема пакета), если это необходимо для типа IA.
  • Добавить любые новые лизинга в опции IA в IA, записанные клиентом.
  • Обновлять сроки жизни для любой аренды в варианте IA, который клиент уже записал в IA.
  • Отмените любые лизинга из IA, записанные клиентом, которые имеют действительное время жизни 0 в опции IA Address или IA Prefix.
  • Не оставляйте без изменений любую информацию об аренде, которую клиент записал в IA, но которые не были включены в IA с сервера.

Если клиент может работать с адресами и / или префиксами, полученными с сервера:

  • Клиент использует адреса, делегированные префиксы и другую информацию от любых ИА, которые не содержат код состояния, с кодом состояния NoAddrsAvail или NoPrefixAvail. Клиент МОЖЕТ включать IA, для которых он получил код статуса NoAddrsAvail или NoPrefixAvail, без адресов или префиксов, в последующих сообщениях Renew and Rebind, отправленных на сервер, для повторного получения адресов или префиксов для этих IA.
  • Клиент ДОЛЖЕН выполнять обнаружение повторяющихся адресов в соответствии с разделом 5.4 [RFC4862], в котором перечислены некоторые исключения, по каждому из полученных адресов в любых ИА, на которых он не выполнял обнаружение двойного адреса при обработке любого из предыдущих сообщений ответа от сервер. Клиент выполняет обнаружение дубликатов адресов перед использованием полученных адресов для любого трафика. Если обнаружен какой-либо из адресов в ссылке, клиент отправляет сообщение «Отклонить» серверу для этих адресов, как описано в Разделе 18.2.8.
  • Для каждого назначенного адреса, который не имеет связанной информации о достижении (см. Определение «on-link» в разделе 2.1 [RFC4861]), чтобы избежать проблем, описанных в [RFC4943], клиент НЕ ДОЛЖЕН предполагать, что любой адреса доступны по ссылке в результате приема IA_NA или IA_TA. Адреса, полученные из IA_NA или IA_TA, НЕ ДОЛЖНЫ использоваться для формирования неявного префикса с длиной, отличной от 128.
  • Для каждого делегированного префикса клиент назначает подсеть каждой из ссылок, к которым присоединены связанные интерфейсы. — Когда клиент подсети делегирует префикс, он должен назначить дополнительные биты для префикса для генерации уникальных более длинных префиксов. Например, если клиент на рисунке 1 был делегирован 2001: db8: 0 :: / 48, он может генерировать 2001: db8: 0: 1 :: / 64 и 2001: db8: 0: 2 :: / 64 для назначения две линии в абонентской сети. Если клиент был делегирован 2001: db8: 0 :: / 48 и 2001: db8: 5 :: / 48, он может назначить 2001: db8: 0: 1 :: / 64 и 2001: db8: 5: 1 :: / 64 к одной из ссылок и 2001: db8: 0: 2 :: / 64 и 2001: db8: 5: 2 :: / 64 для назначения другой ссылке. — Если клиент использует делегированный префикс для настройки адресов на интерфейсах на себе или других узлах позади него, предпочтительный и действительный срок службы этих адресов ДОЛЖЕН быть не более, чем оставшиеся предпочтительные и действительные сроки жизни, соответственно, для делегированного префикса в любое время. В частности, если делегированный префикс или префикс, полученный из него, объявляется для автоконфигурации автономного адреса [RFC4862], объявленные предпочтительные и действительные сроки жизни НЕ ДОЛЖНЫ превышать соответствующие оставшиеся времена жизни делегированного префикса.

Управление конкретной информацией о конфигурации подробно описано в определении каждого параметра в Разделе 21.

Если сообщение «Ответ» содержит какие-либо IA, но клиент не находит непригодных для использования адресов и / или делегированных префиксов в любом из этих IA, клиент может либо попробовать другой сервер (возможно, перезапустить процесс обнаружения DHCP-сервера), либо использовать сообщение «Информация-запрос» для получения другая информация о конфигурации.

Когда клиент получает ответное сообщение в ответ на сообщение Renew или Rebind, клиент:

  • Отправляет запрос на сервер, который ответил, если какой-либо из IA в ответном сообщении содержит код состояния NoBinding. Клиент помещает опции IA в это сообщение для всех IA. Клиент продолжает использовать другие привязки, для которых сервер не возвратил ошибку.
  • Отправляет Renew / Rebind, если какой-либо из IA не находится в сообщении «Ответ», но поскольку это, вероятно, указывает на то, что сервер, который ответил, не поддерживает этот тип IA, отправка немедленно вряд ли приведет к другому результату. Поэтому клиент ДОЛЖЕН ограничить скорость передачи данных (см. Раздел 14.1) и МОЖЕТ просто ждать обычного времени повторной передачи (как будто сообщение ответа не было получено). Клиент продолжает использовать другие привязки, для которых сервер действительно возвращал информацию.
  • В противном случае принимает информацию в IA.

Всякий раз, когда клиент перезапускает процесс обнаружения DHCP-сервера или выбирает альтернативный сервер, как описано в разделе 18.2.9, клиент ДОЛЖЕН прекратить использовать все адреса и делегированные префиксы, для которых у него есть привязки, и попытаться получить все необходимые лизинга с нового сервера. Это облегчает клиенту использование одного конечного автомата для всех привязок.

18.2.10.2 Ответ для выпуска и снижения — Reply for Release and Decline

Когда клиент получает действительное ответное сообщение в ответ на сообщение о выпуске, клиент считает, что событие Release завершено независимо от параметра «Код состояния» (см. Раздел 21.13), возвращенного сервером.

Когда клиент получает действительное ответное сообщение в ответ на сообщение «Отклонение», клиент считает, что событие «Отклонение» завершено независимо от параметров (-ов) кода состояния, возвращаемых сервером.

18.2.10.3 Ответить для подтверждения — Reply for Confirm

Если клиент получает любые ответные сообщения, которые указывают статус успеха (явный или неявный), клиент может использовать адреса в IA и игнорировать любые сообщения, которые указывают статус NotOnLink. Когда клиент получает одно или несколько сообщений «Ответ» с статусом NotOnLink в ответ на сообщение «Подтверждение», клиент выполняет обнаружение DHCP-сервера, как описано в Разделе 18.

18.2.10.4 Ответ для запроса информации — Reply for Information-request

Обратитесь к разделу 21.23 за информацией о том, как клиент должен обрабатывать параметр «Время обновления информации» (независимо от того, присутствует или нет в ответе).

18.2.11 Получение реконфигурированных сообщений

Клиент получает переконфигурированные сообщения, отправленные на UDP-порт 546 на интерфейсы, для которых он получил информацию о конфигурации через DHCP. Эти сообщения могут быть отправлены в любое время. Поскольку результаты события реконфигурации могут влиять на программы на уровне приложений, клиенту СЛЕДУЕТ регистрировать эти события и МОЖЕТ уведомлять эти программы об изменении через интерфейс, специфичный для реализации.

После получения действительного сообщения Reconfigure клиент отвечает сообщением Renew, сообщением Rebind или сообщением «Информация-запрос», как указано параметром Reconfigure Message (см. Раздел 21.19). Клиент игнорирует поле «идентификатор транзакции» в полученном сообщении переконфигурации. Пока транзакция выполняется, клиент отбрасывает любые сообщения Reconfigure, которые он получает.

Сообщение Reconfigure действует как триггер, который сигнализирует клиенту о завершении успешного обмена сообщениями. После того, как клиент получил Reconfigure, клиент продолжит обмен сообщениями (при необходимости повторно передавая сообщение Renew, Rebind или Information-request); клиент ДОЛЖЕН игнорировать любые дополнительные сообщения переконфигурации, пока обмен не будет завершен.

Дублированные сообщения будут игнорироваться, поскольку клиент начнет обмен после получения первой переконфигурации. Повторно переданные сообщения будут либо (1) инициировать обмен (если первая переконфигурация не была получена клиентом), либо (2) игнорируются. Сервер МОЖЕТ прекратить повторную передачу реконфигурации сообщений клиенту, как только сервер получит сообщение от Renew, Rebind или Information-request от клиента.

Возможно, дубликат или повторная передача Reconfigure будет достаточно задержана (и доставлена не по порядку), чтобы она прибыла на клиента после того, как обмен (инициированный оригинальной Reconfigure) был завершен. В этом случае клиент инициирует избыточный обмен. Вероятность задержки и доставки вне заказа достаточно мала, чтобы ее можно было игнорировать. Следствием избыточного обмена является неэффективность, а не некорректная работа.

18.2.12 Обновление информации о конфигурации

Всякий раз, когда клиент мог перейти на новую ссылку, префиксы / адреса, назначенные интерфейсам по этой ссылке, могут быть не более подходящими для ссылки, к которой прикреплен клиент. Примеры случаев, когда клиент мог перейти на новую ссылку, включают следующее:

  • Клиент перезагружается (и имеет стабильное хранилище и постоянное состояние DHCP)
  • Клиент повторно подключается к ссылке, на которой он получил аренду
  • Клиент возвращается из спящего режима
  • Клиент меняет точки доступа (например, при использовании технологии Wi-Fi)

Когда клиент обнаруживает, что он, возможно, переместился на новую ссылку и получил адреса и не делегированные префиксы с сервера, клиент СЛЕДУЕТ начать обмен сообщениями Подтверждение / Ответ. Клиент включает в себя любые IA, назначенные интерфейсу, который, возможно, переместился на новую ссылку вместе с адресами, связанными с этими IA, в сообщении подтверждения. На любых серверах-ответчиках указывается, подходят ли эти адреса для ссылки, к которой прикреплен клиент, со статусом в ответном сообщении, который он возвращает клиенту.

Если у клиента есть действительные делегированные префиксы, полученные с сервера DHCP, клиент ДОЛЖЕН инициировать обмен сообщениями Rebind / Reply, как описано в разделе 18.2.5, за исключением того, что параметры повторной передачи должны быть установлены как для сообщения подтверждения (см. Раздел 18.2.3). Клиент включает IA_NAs, IA_TA и IA_PD, а также связанные с ними аренды в своем сообщении Rebind.

Если клиент получил только сетевую информацию, используя обмен сообщениями «Информация-запрос / Ответ», клиент ДОЛЖЕН инициировать обмен сообщениями «Информация-запрос / Ответ», как описано в Разделе 18.2.6.

Если это не связано с одним из вышеупомянутых условий, клиенту СЛЕДУЕТ инициировать обмен обновления / ответа (как если бы время T1 истекло), как описано в разделе 18.2.4, или обмен информацией-запросом / ответом, как описано в разделе 18.2. 6, если клиент обнаруживает существенное изменение в отношении префиксов, доступных в ссылке (при добавлении новых префиксов или устаревших префиксов), поскольку это может указывать на изменение конфигурации. Тем не менее, клиент ДОЛЖЕН ограничить количество таких попыток, чтобы избежать наводнения сервера запросами при возникновении проблем с каналами (например, только одно из них не чаще, чем каждые 30 секунд).

18.3 Поведение сервера

Для этого обсуждения предполагается, что сервер сконфигурирован с учетом специфики реализации с конфигурациями, представляющими интерес для клиентов.

Сервер отправляет сообщение «Реклама» в ответ на каждое действительное запрашиваемое сообщение, которое он получает, чтобы сообщить о доступности сервера клиенту.

В большинстве случаев сервер отправляет ответ в ответ на запросы, подтверждающие, обновляя, отменяя, отклоняя, освобождая и запрашивая информацию, отправляемые клиентом. Сервер также отправит ответ в ответ на опцию «Запрашивать с быстрой компиляцией» (см. Раздел 21.14), когда сервер настроен на ответ с совершенными лизинговыми заданиями.

Эти сообщения «Реклама и ответ» ДОЛЖНЫ всегда содержать параметр «Идентификатор сервера» (см. Раздел 21.3), содержащий параметр DUID сервера и идентификатор клиента (см. Раздел 21.2) из сообщения клиента, если он присутствует.

В большинстве ответных сообщений сервер содержит параметры, содержащие информацию о конфигурации для клиента. Сервер должен знать рекомендации по размерам пакетов и использованию фрагментации, как описано в разделе 5 [RFC8200]. Если клиент включил опцию «Запрос опциона» (см. Раздел 21.7) в своем сообщении, сервер содержит параметры в ответном сообщении, содержащем параметры конфигурации для всех параметров, указанных в опции «Запрос опциона», которые сервер настроен для возврата к клиенту , Сервер МОЖЕТ возвращать дополнительные параметры клиенту, если он настроен для этого.

Любое сообщение, отправленное с клиента, может поступать на сервер, инкапсулированный в одно или несколько сообщений с пересылкой. Сервер ДОЛЖЕН использовать полученное сообщение для построения надлежащего сообщения ретрансляции, чтобы разрешить передачу ответа на полученное сообщение через те же ретрансляторы (в обратном порядке) в качестве исходного сообщения клиента; см. раздел 19.3 для более подробной информации. Серверу также может потребоваться записать эту информацию с каждым клиентом, если потребуется отправить сообщение переконфигурации позднее, если только сервер не настроен с адресами, которые могут использоваться для отправки сообщений переконфигурации непосредственно клиенту (см. Раздел 18.3.11). Обратите внимание, что серверы, поддерживающие leasequery [RFC5007], также должны записывать эту информацию.

Отправляя сообщения Reconfigure, сервер МОЖЕТ начать обмен конфигурацией, чтобы заставить DHCP-клиенты получать новые адреса, префиксы и другую информацию о конфигурации. Например, администратор может использовать обмен конфигурации, инициированный сервером, когда ссылки в домене DHCP должны быть перенумерованы или когда другие параметры конфигурации обновляются, возможно, потому что серверы перемещены, добавлены или удалены.

Когда клиент получает сообщение Reconfigure с сервера, клиент инициирует отправку сообщения Renew, Rebind или Information-request, как указано в параметре msg в опции Reconfigure Message (см. Раздел 21.19). Сервер отправляет IA и / или другую информацию о конфигурации клиенту в ответном сообщении. Сервер МОЖЕТ включать опции, содержащие IA и новые значения для других параметров конфигурации в сообщении «Ответ», даже если эти IA и параметры не были запрошены в сообщении клиента.

18.3.1 Получение сообщений о поиске (Solicit)

См. Раздел 18.4 для получения подробной информации об обработке запросов на получение сообщений, полученных через одноадресную рассылку. Одноадресная передача сообщений «Запросить» не допускается, независимо от того, настроена ли опция «Одноранговая сеть» (см. Раздел 21.12) или нет.

Сервер определяет информацию о клиенте и его местоположении, как описано в разделе 13, и проверяет его административную политику относительно ответа на клиент. Если серверу не разрешено отвечать клиенту, сервер отбрасывает сообщение «Запросить впервые». Например, если административная политика для сервера заключается в том, что он может отвечать только клиенту, который согласен принять сообщение Reconfigure, если клиент не включает параметр Reconfigure Accept (см. Раздел 21.20) в сообщении «Запросить впервые», сервер отбрасывает сообщение «Запросить впервые».

Если (1) серверу разрешено отвечать на клиента, (2) клиент не включил опцию «Быстрая фиксация» (см. Раздел 21.14) в сообщении «Запросить» или (3) сервер не настроен на ответ с совершенным присвоения лизинга и других ресурсов, сервер отправляет клиенту рекламное сообщение, как описано в разделе 18.3.9.

Если клиент включил опцию «Быстрая фиксация» в сообщении «Запросить», и сервер был настроен для ответа на зафиксированные назначения аренды и других ресурсов, сервер отвечает на сообщение «Запрашивать с ответом». Сервер создает ответное сообщение, как будто оно получило сообщение «Запрос», как описано в разделе 18.3.2. Сервер передает ответное сообщение, как описано в разделе 18.3.10. Сервер ДОЛЖЕН зафиксировать назначение любых адресов и делегированных префиксов или другой информации о конфигурации перед отправкой ответного сообщения клиенту. В этом случае сервер включает параметр «Быстрая фиксация» в сообщении «Ответ», чтобы указать, что ответ отвечает на сообщение «Запросить».

Обсуждение:

  • При использовании обмена сообщениями «Запрашивать / Ответить» сервер выполняет назначение любых договоров аренды перед отправкой сообщения «Ответ». Клиент может предположить, что ему было присвоено арендное соглашение в ответном сообщении, и ему не нужно отправлять сообщение запроса для этих договоров аренды.
  • Как правило, серверы, настроенные на использование обмена сообщениями «Запрашивать / Ответить», будут развернуты так, чтобы только один сервер отвечал на сообщение «Запросить». Если отвечает более одного сервера, клиент будет использовать лизинг только с одного из серверов, тогда как лизинг с других серверов будет передан клиенту, но не будет использоваться клиентом.

18.3.2 Получение сообщений о запросе (Receipt of Request Messages)

См. Раздел 18.4 для получения подробной информации об обработке сообщений Запроса, полученных через одноадресную рассылку.

Когда сервер получает действительное сообщение «Запрос», сервер создает привязки для этого клиента в соответствии с информацией о политике и конфигурации сервера и записывает идентификационные данные и другую информацию, запрашиваемую клиентом.

Сервер создает сообщение «Ответ», устанавливая поле «msg-type» для ОТКЛЮЧЕНИЯ и копирования идентификатора транзакции из сообщения «Запрос» в поле «идентификатор транзакции».

Сервер ДОЛЖЕН включить в ответное сообщение параметр «Идентификатор сервера» (см. Раздел 21.3), содержащий идентификатор сервера и идентификатор клиента (см. Раздел 21.2) из сообщения «Запрос».

Сервер проверяет все IA в сообщении от клиента.

Для каждого варианта IA_NA (см. Раздел 21.4) и опции IA_TA (см. Раздел 21.5) в сообщении «Запрос» сервер проверяет, подходят ли префиксы включенных адресов для ссылки, к которой подключен клиент. Если какой-либо из префиксов входящих адресов не подходит для ссылки, к которой подключен клиент, сервер ДОЛЖЕН вернуть IA клиенту с параметром кода состояния (см. Раздел 21.13) со значением NotOnLink. Если сервер не отправляет код статуса NotOnLink, но он не может назначить какие-либо IP-адреса IA, сервер ДОЛЖЕН вернуть параметр IA в ответном сообщении без адресов в IA и код состояния, содержащий код состояния NoAddrsAvail в IA.

Для любого варианта IA_PD (см. Раздел 21.21) в сообщении «Запрос», которому сервер не может назначить какие-либо делегированные префиксы, сервер ДОЛЖЕН вернуть параметр IA_PD в ответном сообщении без префиксов в IA_PD и с кодом состояния, содержащим код состояния NoPrefixAvail в IA_PD.

Сервер МОЖЕТ назначать разные адреса и / или делегированные префиксы IA, чем те, которые включены в IA сообщения запроса клиента.

Для всех IA, которым сервер может назначать адреса или делегированные префиксы, сервер включает IA с адресами (для IA_NAs и IA_TAs), префиксы (для IA_PD) и другие параметры конфигурации и записывает IA как новую привязку клиента. Сервер НЕ ДОЛЖЕН включать любые адреса или делегированные префиксы в IA, которые сервер не назначает клиенту.

Времена T1 / T2, установленные в каждой применимой опции IA для ответа, ДОЛЖНЫ быть одинаковыми значениями для всех IA. Сервер ДОЛЖЕН определять время T1 / T2 во всех привязках соответствующего клиента в ответе. Это облегчает клиенту возможность одновременно обновлять все привязки.

Сервер ДОЛЖЕН включать параметр Reconfigure Accept (см. Раздел 21.20), если политика сервера включает механизм реконфигурации, и клиент поддерживает его. В настоящее время отправка этой опции в ответ технически избыточна, так как использование механизма реконфигурации требует аутентификации; в настоящее время единственным определяемым механизмом является RKAP (см. раздел 20.4), а наличие сигналов переконфигурированных ключей поддерживает прием сообщений Reconfigure. Однако в будущем могут быть установлены более надежные механизмы безопасности, которые не позволят RKAP больше не использоваться.

Сервер включает в себя другие параметры, содержащие информацию о конфигурации, которая должна быть возвращена клиенту, как описано в разделе 18.3.

Если сервер обнаруживает, что клиент включил IA в сообщение «Запрос», для которого сервер уже имеет привязку, которая связывает IA с клиентом, сервер отправляет ответное сообщение с существующими привязками, возможно, с обновленными сроками службы. Сервер может обновлять привязки в соответствии с его локальными политиками, но сервер СЛЕДУЕТ генерировать ответ еще раз, а не просто повторно передавать ранее отправленную информацию, даже если значение поля «идентификатор транзакции» соответствует предыдущей передаче. Сервер НЕ ДОЛЖЕН кэшировать свои ответы.

Обсуждение:

  • Кэшированные ответы плохи, потому что необходимо обновить сроки жизни (либо уменьшить таймеры на количество времени, прошедшее с момента первоначальной передачи, либо сохранить значения жизненного цикла и обновить информацию об аренде в базе данных сервера). Кроме того, если сообщение использует любую защиту (например, метод обнаружения повтора (RDM), как описано в разделе 20.3), его значение должно быть обновлено. Кроме того, любые дайджесты должны быть обновлены. Учитывая все вышеперечисленное, ответы кэширования намного сложнее, чем просто отправка того же буфера, что и раньше, и легко пропустить некоторые из этих шагов.

18.3.3 Получение подтверждающих сообщений (Receipt of Confirm Messages)

См. Раздел 18.4 для получения подробной информации об обработке сообщений подтверждения, полученных через одноадресную рассылку. Одноадресная передача сообщений подтверждения не допускается, независимо от того, настроена ли опция Server Unicast (см. Раздел 21.12) или нет.

Когда сервер получает сообщение подтверждения, сервер определяет, подходят ли адреса в сообщении подтверждения для ссылки, к которой прикреплен клиент. Если все адреса в сообщении «Подтвердить» проходят этот тест, сервер возвращает статус «Успех». Если какой-либо из адресов не проходит этот тест, сервер возвращает статус NotOnLink. Если сервер не может выполнить этот тест (например, сервер не имеет информации о префиксах на ссылке, к которой подключен клиент) или не было адресов в любом из IA, отправленных клиентом, сервер НЕ ДОЛЖЕН отправьте ответ клиенту.

Сервер игнорирует поля T1 и T2 в параметрах IA, а также поля Preferred-lifetime и valid-lifetime в параметрах IA Address (см. Раздел 21.6).

Сервер создает сообщение «Ответ», устанавливая поле «msg-type» для ОТВЕТА и копирования идентификатора транзакции из сообщения «Подтверждение» в поле «идентификатор транзакции».

Сервер ДОЛЖЕН включить в ответное сообщение параметр «Идентификатор сервера» (см. Раздел 21.3), содержащий идентификатор сервера и идентификатор клиента (см. Раздел 21.2) из сообщения «Подтверждение». Сервер включает в себя код состояния (см. Раздел 21.13), указывающий статус сообщения подтверждения.

18.3.4 Получение обновлений (Receipt of Renew Messages)

См. Раздел 18.4 для получения подробной информации об обработке обновления сообщений, полученных через одноадресную рассылку.

Для каждого IA в сообщении Renew от клиента сервер находит привязку клиента и проверяет, соответствует ли информация в IA клиенту информации, хранящейся для этого клиента.

Если сервер находит запись клиента для IA, сервер отправляет IA обратно клиенту с новыми сроками службы и, если применимо, T1 / T2 раз. Если сервер не может продлить срок службы адреса или делегированного префикса в IA, сервер МОЖЕТ не включать параметр IA Address (см. Раздел 21.6) для этого адреса или префикса IA (см. Раздел 21.22) для этого делегированного префикс. Если сервер предпочитает включать опцию IA Address или IA Prefix для такого адреса или делегированного префик