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

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 для такого адреса или делегированного префикса, сервер ДОЛЖЕН устанавливать значения T1 и T2 для допустимого времени жизни для опции IA, если только сервер не включает в себя другие адреса или делегированные префиксы, которые сервер может расшириться для IA. Установка T1 и T2 в значения, равные допустимому времени жизни, информирует клиента о том, что аренда, связанная с указанным IA, не будет расширена, поэтому нет смысла пытаться. Кроме того, он избегает генерации ненужного трафика, поскольку оставшееся время жизни приближается к 0.

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

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

Если сервер обнаруживает, что какой-либо из делегированных префиксов в IA не подходит для ссылки, к которой подключен клиент, сервер возвращает делегированный префикс клиенту со временем жизни 0.

Для каждого IA, для которого сервер не может найти запись клиента, сервер имеет следующие варианты, в зависимости от политики сервера и информации о конфигурации:

  • Если сервер настроен на создание новых привязок в результате обработки Обновлять сообщения, сервер СЛЕДУЕТ создавать привязку и возвращать IA с назначенными адресами или делегированными префиксами со временем жизни и, если применимо, T1 / T2 раз и другую информацию, запрашиваемую клиент. Если клиент включил опцию IA Prefix в опции IA_PD (см. Раздел 21.21) с нулевым значением в поле «Префикс IPv6» и ненулевым значением в поле «префикс длины», сервер МОЖЕТ использовать « prefix-length «в качестве подсказки для длины префиксов, которые должны быть назначены (см. [RFC8168] для более подробной информации о подсказках длины префикса).
  • Если сервер настроен на создание новых привязок в результате обработки возобновления сообщений, но сервер не назначает какие-либо аренды IA, сервер возвращает параметр IA, содержащий параметр кода состояния (см. Раздел 21.13), с статусом NoAddrsAvail или NoPrefixAvail кода и сообщения о статусе для пользователя.
  • Если сервер не поддерживает создание новых привязок для клиента, отправляющего сообщение Renew, или если это поведение отключено в соответствии с политикой или информацией о конфигурации сервера, сервер возвращает параметр IA, содержащий параметр состояния кода, с кодом состояния NoBinding и сообщение статуса для пользователя.

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

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

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

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

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

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

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

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

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

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

Если сервер не может найти клиентскую запись для IA, сервер проверяет, содержит ли IA адреса (для IA_NAs и IA_TAs) или делегированные префиксы (для IA_PD). Сервер проверяет, подходят ли адреса и делегированные префиксы для ссылки, к которой подключен интерфейс клиента, в соответствии с информацией о явной конфигурации сервера. Для любого адреса, который не подходит для ссылки, к которой подключен интерфейс клиента, сервер МОЖЕТ включать опцию IA Address со временем жизни 0. Для любого делегированного префикса, который не подходит для ссылки, к которой подключен интерфейс клиента, сервер МОЖЕТ включать опцию префикса IA ​​со временем жизни 0. Ответ с временем жизни 0 представляет собой явное уведомление клиенту о том, что конкретные адреса и делегированные префиксы больше не действительны и НЕ ДОЛЖНЫ использоваться клиентом. Если сервер не хочет включать какие-либо IA, содержащие параметры IA Address или IA Prefix со временем жизни 0, и сервер не включает никаких других IA с договорами аренды и / или статуса, сервер не отправляет ответное сообщение. В этой ситуации сервер отбрасывает сообщение Rebind.

В противном случае для каждого ИА, для которого сервер не может найти запись клиента, сервер имеет следующие варианты, в зависимости от политики сервера и информации о конфигурации:

  • Если сервер настроен на создание новых привязок в результате обработки сообщений Rebind (см. Также примечание ниже о опции Rapid Commit (раздел 21.14)), сервер СЛЕДУЕТ создавать привязку и возвращать IA с выделенными арендами со сроками жизни и, если применимо, значения T1 / T2 и другую информацию, запрошенную клиентом. Сервер НЕ ДОЛЖЕН возвращать какие-либо адреса или делегированные префиксы в IA, которые сервер не назначает клиенту.
  • Если сервер настроен на создание новых привязок в результате обработки переадресованных сообщений, но сервер не назначает какие-либо аренды IA, сервер возвращает параметр IA, содержащий параметр кода состояния (см. Раздел 21.13), с статусом NoAddrsAvail или NoPrefixAvail кода и сообщения о статусе для пользователя.
  • Если сервер не поддерживает создание новых привязок для клиента, отправляющего сообщение Rebind, или если это поведение отключено в соответствии с политикой или конфигурационной информацией сервера, сервер возвращает параметр IA, содержащий код состояния, с кодом состояния NoBinding и сообщение статуса для пользователя.

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

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

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

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

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

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

18.3.6 Получение сообщений с информацией-запросом (Receipt of Information-request Messages)

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

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

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

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

Сервер включает в себя параметры, содержащие информацию о конфигурации, которая должна быть возвращена клиенту, как описано в разделе 18.3. Сервер МОЖЕТ включать дополнительные параметры, которые не запрашивались клиентом в сообщении «Информация-запрос».

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

18.3.7 Получение сообщений о выпуске (Receipt of Release Messages)

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

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

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

После того как все операции были обработаны, сервер генерирует сообщение «Ответ» и включает в себя параметр «Код состояния» (см. Раздел 21.13) со значением «Успех», «Идентификатор сервера» (см. Раздел 21.3) с идентификатором сервера и опцией «Идентификатор клиента» (см. см. раздел 21.2) с DUID клиента. Для каждого IA в сообщении Release, для которого сервер не имеет обязательной информации, сервер добавляет опцию IA с использованием IAID из сообщения Release и включает в себя параметр кода состояния со значением NoBinding в опции IA. Никакие другие варианты не включены в вариант IA.

Сервер может выбрать сохранение записи о назначенных лизингах и ИА после того, как срок жизни в лизинге истек, чтобы позволить серверу переназначить ранее назначенные лизинг клиенту.

18.3.8 Получение сообщений о снижении (Receipt of Decline Messages)

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

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

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

После того, как все адреса обработаны, сервер генерирует сообщение «Ответ», установив поле «Тип сообщения» для ОТКЛЮЧЕНИЯ и копирования идентификатора транзакции из сообщения «Отклонить» в поле «идентификатор транзакции». Клиент включает в себя параметр «Код состояния» (см. Раздел 21.13) со значением «Успех», «Идентификатор сервера» (см. Раздел 21.3) с DUID сервера и опцией «Идентификатор клиента» (см. Раздел 21.2) с DUID клиента. Для каждого IA в сообщении Decline, для которого сервер не имеет обязательной информации, сервер добавляет опцию IA с использованием IAID из сообщения Decline и включает в себя параметр кода состояния со значением NoBinding в опции IA. Никакие другие варианты не включены в вариант IA.

18.3.9 Создание рекламных сообщений (Creation of Advertise Messages)

Сервер устанавливает поле «msg-type» в ADVERTISE и копирует содержимое поля «идентификатор транзакции» из сообщения «Сопровождение», полученного от клиента, в сообщение «Реклама». Сервер включает в себя идентификатор сервера в параметре «Идентификатор сервера» (см. Раздел 21.3) и копирует параметр «Идентификатор клиента» (см. Раздел 21.2) из сообщения «Запросить» в сообщение «Реклама».

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

Сервер включает в себя параметр Reconfigure Accept (см. Раздел 21.20), если сервер хочет указать, что он поддерживает механизм Reconfigure. Эта информация может использоваться клиентом во время процесса выбора сервера.

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

Сервер ДОЛЖЕН включать параметры IA в сообщении «Реклама», содержащем любые адреса и / или делегированные префиксы, которые будут назначены IA, содержащиеся в сообщении «Запросить» от клиента. Если клиент включил адреса в параметры адреса IA (см. Раздел 21.6) в сообщении «Сопровождение», сервер МОЖЕТ использовать эти адреса в качестве подсказок о адресах, которые клиент хотел бы получить. Если клиент включил опции префикса IA (см. Раздел 21.22), сервер МОЖЕТ использовать префикс, содержащийся в поле «IPv6-префикс» и / или длину префикса, содержащуюся в поле «префикс длины», в качестве подсказок о префиксах клиент хотел бы получить. Если сервер не собирается назначать адрес или делегированный префикс, полученный в качестве подсказки в сообщении «Запросить», сервер НЕ ДОЛЖЕН включать этот адрес или делегированный префикс в сообщение «Реклама».

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

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

18.3.10 Передача сообщений о рекламе и ответах (Transmission of Advertise and Reply Messages)

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

Если исходное сообщение было получено в сообщении Relay-forward, сервер создает сообщение Relay-reply с сообщением «Ответ» в полезной нагрузке параметра Relay Message (см. Раздел 21.10). Если в сообщениях с пересылкой включен параметр Interface-Id (см. Раздел 21.18), сервер копирует эту опцию в сообщение Relay-reply. Сервер перенаправляет сообщение ретрансляции непосредственно ретранслятору, используя адрес в поле адреса источника из IP-дейтаграммы, в которой было получено сообщение с переадресацией. Более подробную информацию о построении сообщений ретрансляции см. В разделе 19.3.

18.3.11 Создание и передача реконфигурированных сообщений (Creation and Transmission of Reconfigure Messages)

Сервер устанавливает поле «msg-type» в RECONFIGURE и устанавливает для поля «идентификатор транзакции» значение 0. Сервер включает в себя параметр «Идентификатор сервера» (см. Раздел 21.3), содержащий его параметр DUID и Client Identifier (см. Раздел 21.2), содержащий DUID клиента в сообщении Reconfigure.

Из-за риска атак типа «отказ в обслуживании» (DoS) против DHCP-клиентов использование механизма безопасности задается в «Переконфигурировать сообщения». Сервер ДОЛЖЕН использовать проверку подлинности DHCP в сообщении Reconfigure (см. Раздел 20.4).

Сервер ДОЛЖЕН включать опцию Reconfigure Message (см. Раздел 21.19), чтобы выбрать, отвечает ли клиент сообщением Renew, сообщением Rebind или сообщением с запросом информации.

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

Сервер отправляет каждое сообщение Reconfigure одному клиенту DHCP, используя одноадресный адрес IPv6 достаточной области, принадлежащей клиенту DHCP. Если на сервере нет адреса, на который он может отправить сообщение переконфигурации непосредственно клиенту, сервер использует сообщение ответа ретранслятора (как описано в разделе 19.3), чтобы отправить сообщение Reconfigure ретранслятору, который будет передавать сообщение для клиента. Сервер может получить адрес клиента (и соответствующий агент ретрансляции, если требуется) через информацию, которую сервер имеет о клиентах, которые были в контакте с сервером (см. Раздел 18.3), или через какой-либо внешний агент.

Чтобы перенастроить несколько клиентов, сервер отправляет отдельное сообщение каждому клиенту. Сервер может инициировать реконфигурирование нескольких клиентов одновременно; например, сервер может отправлять сообщение Reconfigure дополнительным клиентам, в то время как обмен сообщениями реконфигурации еще продолжается.

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

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

Значения по умолчанию и начальные значения для REC_TIMEOUT и REC_MAX_RC описаны в разделе 7.6.

18.4 Прием одноадресных сообщений (Reception of Unicast Messages)

Если в подразделах раздела 18.3, в которых обсуждается получение конкретных сообщений, не указано иное, сервер не должен принимать одноадресный трафик, если он явно не настроен для этого. Например, одноадресная передача не разрешена для сообщений «Запросить», «Подтвердить» и «Отменить» (см. Разделы 18.3.1, 18.3.3 и 18.3.5 соответственно), даже если настроена опция «Одноранговая сеть» (см. Раздел 21.12). Для сообщений «Запросить», «Обновить», «Информация-запрос», «Отпустить» и «Отклонить» разрешено только в том случае, если настроен параметр «Унифицированный сервер».

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

19. Поведение агента передачи

Агент ретрансляции ДОЛЖЕН быть настроен на использование списка адресов получателей, которые включают одноадресные адреса. Список адресов назначения МОЖЕТ включать многоадресный адрес All_DHCP_Servers или другие адреса, выбранные сетевым администратором. Если агент ретрансляции не был явно настроен, он ДОЛЖЕН использовать многоадресный адрес All_DHCP_Servers как значение по умолчанию.

Если агент ретрансляции передает сообщения на многоадресный адрес All_DHCP_Servers или другие многоадресные адреса, он устанавливает для поля Hop Limit значение 8.

Если агент ретранслятора получает сообщение, отличное от Relay-forward и Relay-reply, и агент ретранслятора не распознает его тип сообщения, он ДОЛЖЕН переслать сообщение, как описано в разделе 19.1.1.

19.1 Ретрансляция сообщения клиента или ретрансляционного сообщения

Агент ретрансляции передает как сообщения от клиентов, так и ретрансляционные сообщения от других релейных агентов. Когда агент-ретранслятор принимает сообщение «Реле-пересылка», распознанный тип сообщения, для которого он не предназначен для цели, или непризнанный тип сообщения [RFC7283], он создает новое сообщение Relay-forward. Агент ретрансляции копирует исходный адрес из заголовка IP-дейтаграммы, в котором сообщение было принято в поле однорангового адреса сообщения Relay-forward. Агент ретрансляции копирует принятое сообщение DHCP (за исключением любых заголовков IP или UDP) в сообщение Relay Message (см. Раздел 21.10) в новом сообщении. Агент ретрансляции добавляет к сообщению Relay-forward любые другие параметры, которые он настроен для включения.

[RFC6221] определяет легкий агент ретрансляции DHCPv6 (LDRA), который позволяет вводить информацию агента ретрансляции узлом доступа, который выполняет функцию мостового соединения на уровне канала (т. Е. Не-маршрутизацию).

19.1.1 Передача сообщения от клиента

Если агент ретрансляции принял сообщение, которое будет передано от клиента, агент ретрансляции размещает одноадресный адрес с глобальным охватом (то есть GUA или ULA) из префикса, назначенного на ссылку, на которой клиенту следует назначить аренду в адрес ссылки поле. Если такой адрес недоступен, агент ретрансляции может установить поле link-address на локальный адрес связи из интерфейса, на котором было получено исходное сообщение. Это не рекомендуется, так как может потребоваться дополнительная информация в конфигурации сервера. См. Раздел 3.2 [RFC7969] для подробного обсуждения.

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

Значение параметра hop-count в сообщении Relay-forward установлено равным 0.

Если агент ретрансляции не может использовать адрес в поле адрес-адрес, чтобы идентифицировать интерфейс, через который будет передаваться ответ клиенту, агент ретранслятора ДОЛЖЕН включать параметр интерфейса-идентификатора (см. Раздел 21.18) в сообщении Relay-forward , Сервер будет включать опцию Interface-Id в сообщении Relay-reply. Агент ретрансляции устанавливает поле link-address, как описано ранее в этом подразделе, независимо от того, включает ли агент ретранслятора параметр Interface-Id в сообщении Relay-forward.

19.1.2 Передача сообщения от ретрансляционного агента

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

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

Если адрес источника из заголовка дейтаграммы IP принятого сообщения является одноадресным адресом с глобальной областью (то есть GUA или ULA), агент ретранслятора устанавливает поле link-address в 0; в противном случае агент ретрансляции устанавливает поле link-address для одноадресного адреса с глобальной областью (то есть GUA или ULA), назначенного интерфейсу, на котором было получено сообщение, или включает в себя параметр Interface-Id (см. раздел 21.18) для идентификации интерфейса на которое было получено сообщение.

19.1.3 Поведение агента ретрансляции с префиксом делегирования

Агент ретрансляции пересылает сообщения, содержащие параметры делегирования префикса, таким же образом, как и ретранслировать адреса (т. Е. В разделах 19.1.1 и 19.1.2).

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

19.2 Ретрансляция сообщения с ретрансляцией

Агент ретрансляции обрабатывает любые параметры, включенные в сообщение Relay-reply, в дополнение к опции Relay Message (см. Раздел 21.10).

Агент ретрансляции извлекает сообщение из опции Relay Message и передает его на адрес, содержащийся в поле однорангового адреса сообщения Relay-reply. Агент ретрансляции НЕ ДОЛЖЕН изменять сообщение.

Если сообщение Relay-reply содержит параметр Interface-Id (см. Раздел 21.18), агент ретранслятора передает сообщение от сервера клиенту по ссылке, идентифицированной опцией Interface-Id. В противном случае, если поле link-address не установлено в 0, агент ретрансляции передает сообщение по ссылке, идентифицированной по полю link-address.

Если агент-ретранслятор получает сообщение-ретранслятор-ответ, он ДОЛЖЕН обрабатывать сообщение, как определено выше, независимо от типа сообщения, инкапсулированного в опции Relay Message.

19.3 Построение ретрансляционных сообщений

Сервер использует сообщение Relay-reply для (1) возврата ответа клиенту, если исходное сообщение от клиента было ретранслировано на сервер в сообщении Relay-forward или (2) отправить сообщение Reconfigure клиенту, если сервер не имеет адреса, который он может использовать для отправки сообщения непосредственно клиенту.

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

Например, если клиент C отправил сообщение, которое было ретрансляровано агентом ретрансляции A для ретрансляции агента B, а затем на сервер, сервер отправит следующее ретрансляционное сообщение ретранслятору агента B:

Рисунок 10 - Пример ответа на ретранслятор
Рисунок 10 — Пример ответа на ретранслятор

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

19.4 Взаимодействие между агентами передачи и серверами

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

В некоторых случаях реле могут добавлять один или несколько параметров. Эти параметры можно добавить по нескольким причинам:

  • Во-первых, реле могут предоставить дополнительную информацию о клиенте. Этот источник информации обычно более доверяет администратору сервера, поскольку он исходит от сетевой инфраструктуры, а не от клиента и не может быть легко подделан. Эти параметры могут использоваться сервером для определения его политики распределения.
  • Во-вторых, реле может нуждаться в некоторой информации для отправки ответа клиенту. Ожидается, что агенты ретрансляции будут иметь апатрид (не сохранять состояние после обработки пакета). Агент ретранслятора может включать в себя параметр Interface-Id (см. Раздел 21.18), который будет отражен в ответе. Он может включать в себя другие параметры и попросить сервер повторить один или несколько параметров в ответ. Эти параметры затем могут использоваться агентом ретрансляции для отправки ответа клиенту или для других нужд. Клиент никогда не увидит эти параметры. Подробнее см. В [RFC4994].
  • В-третьих, иногда реле является лучшим устройством для предоставления значений для определенных параметров. Реле может вставить опцию в пересылку пакета на сервер и попросить сервер передать эту опцию клиенту. Клиент получит этот вариант. Следует отметить, что сервер является высшим авторитетом здесь, и — в зависимости от его конфигурации — он может или не может отправить эту опцию клиенту. Подробнее см. В [RFC6422].

По разным причинам серверам может потребоваться сохранить информацию о реестре после завершения обработки пакета. Один из них — механизм подачи наличных денег, который может запрашивать все адреса и / или префиксы, которые были назначены через определенное реле. Второй — для механизма переконфигурации. Сервер может выбрать не отправлять сообщение Reconfigure непосредственно клиенту, а скорее отправлять его через реле. Это конкретное поведение считается деталью реализации и выходит за рамки этого документа.

20. Аутентификация сообщений DHCP

В этом документе представлены два механизма безопасности для аутентификации сообщений DHCP: (1) проверка подлинности (и шифрования) сообщений, отправляемых между серверами и ретрансляционными агентами с использованием IPsec, и (2) защита от неправильной конфигурации клиента, вызванная сообщением Reconfigure, отправленным вредоносным DHCP-сервер.

Протокол отложенной аутентификации, определенный в [RFC3315], был устарел этим документом (см. Раздел 25).

20.1 Безопасность сообщений, отправленных между серверами и агентами ретрансляции

Агенты ретрансляции и серверы, которые обмениваются сообщениями, могут использовать IPsec, как описано в [RFC8213].

20.2 Резюме проверки подлинности DHCP

Аутентификация DHCP-сообщений выполняется с использованием опции «Аутентификация» (см. Раздел 21.11). Информация аутентификации, переносимая в опции «Аутентификация», может использоваться для надежной идентификации источника сообщения DHCP и подтверждения того, что содержимое сообщения DHCP не было изменено.

Параметр «Аутентификация» предоставляет структуру для нескольких протоколов проверки подлинности. Один такой протокол, RKAP, определен в разделе 20.4. Другие протоколы, определенные в будущем, будут указаны в отдельных документах.

Любое сообщение DHCP НЕ ДОЛЖНО включать более одного параметра проверки подлинности.

Поле протокола в опции «Аутентификация» определяет конкретный протокол, используемый для генерации информации об аутентификации, переносимой в опции. Поле алгоритма идентифицирует конкретный алгоритм в протоколе аутентификации; например, поле алгоритма указывает хэш-алгоритм, используемый для генерации кода аутентификации сообщения (MAC) в опции «Аутентификация». Поле RDM указывает тип обнаружения повтора, используемый в поле обнаружения повтора.

20.3 Обнаружение воспроизведения

Поле RDM параметра «Аутентификация» (см. Раздел 21.11) определяет тип обнаружения воспроизведения, используемый в поле обнаружения повтора.

Если поле RDM содержит 0x00, поле обнаружения воспроизведения ДОЛЖНО быть установлено на значение строго монотонно увеличивающегося 64-битного беззнакового целого числа (по модулю 2 ^ 64). Использование этого метода может уменьшить опасность повторных атак. Этот метод ДОЛЖЕН поддерживаться всеми протоколами параметров аутентификации. Одним из вариантов может быть использование 64-битного формата временной метки NTP [RFC5905]).

Клиент, который получает сообщение с полем RDM, установленным в 0x00, ДОЛЖЕН сравнить свое поле обнаружения повтора с предыдущим значением, отправленным этим же сервером (на основе параметра Идентификатор сервера, см. Раздел 21.3) и принимать только сообщение, если полученное значение равно больше и записывать это как новое значение. Если это первый раз, когда клиент обрабатывает параметр проверки подлинности, отправленный сервером, клиент ДОЛЖЕН записать значение обнаружения повтора и пропустить проверку обнаружения повтора.

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

20.4 Протокол аутентификации ключа реконфигурации (RKAP)

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

Как ключ перенастройки, отправленный с сервера клиенту, так и HMAC в последующих сообщениях переконфигурации переносятся в качестве информации аутентификации в параметр «Аутентификация» (см. Раздел 21.11). Формат информации аутентификации определяется в следующем разделе.

RKAP используется (инициируется сервером) только в том случае, если клиент и сервер договорились использовать сообщения переконфигурации.

20.4.1 Использование опции проверки подлинности в RKAP

Следующие поля задаются в опции «Аутентификация» (см. Раздел 21.11) для RKAP:

protocol 3
algorithm 1
RDM 0

Формат информации аутентификации для RKAP:

Рисунок 11 - Информация об аутентификации RKAP
Рисунок 11 — Информация об аутентификации RKAP

Type. Тип данных в поле «Значение», которое отображается в этой опции:

  • Переконфигурируйте значение ключа (используется в ответном сообщении).
  • HMAC-MD5 дайджест сообщения (используется в сообщении переконфигурации).

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

Value. Данные, определенные полем «Тип». 16-октетное поле.

20.4.2 Проблемы с сервером для RKAP

Сервер выбирает ключ переконфигурации для клиента во время обмена сообщениями / ответами, запроса / ответа или обмена информацией / запроса / ответа. Сервер записывает ключ перенастройки и передает этот ключ клиенту в опции «Аутентификация» (см. Раздел 21.11) в ответном сообщении.

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

Чтобы обеспечить аутентификацию для сообщения Reconfigure, сервер выбирает значение обнаружения повтора в соответствии с RDM, выбранным сервером, и вычисляет HMAC-MD5 сообщения Reconfigure с помощью ключа перенастройки для клиента. Сервер вычисляет HMAC-MD5 по всему сообщению DHCP Reconfigure, включая параметр «Аутентификация»; поле HMAC-MD5 в опции «Аутентификация» установлено для 0 для вычисления HMAC-MD5. Сервер включает HMAC-MD5 в поле информации аутентификации в опции «Аутентификация», включенной в сообщение «Переконфигурировать», отправленное клиенту.

20.4.3 Клиентские соображения для RKAP

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

Чтобы выполнить аутентификацию сообщения Reconfigure, клиент вычисляет HMAC-MD5 по сообщению Reconfigure с нулями, замененными для поля HMAC-MD5, используя ключ перенастройки, полученный от сервера. Если этот вычисленный HMAC-MD5 соответствует значению в опции «Аутентификация», клиент принимает сообщение «Переконфигурировать».

21. Параметры DHCP

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

В этом документе описываются параметры DHCP, определенные как часть базовой спецификации DHCP. Другие варианты могут быть определены в будущем в отдельных документах. См. [RFC7227] в отношении рекомендаций относительно определения новых параметров. См. Раздел 24 для получения дополнительной информации о реестре DHCPv6 «Коды опций», поддерживаемые IANA.

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

Параметры, которые могут отображаться только один раз, называются «одноэлементными опциями». Единственными опциями, отличными от singleton, определенными в этом документе, являются IA_NA (см. Раздел 21.4), IA_TA (см. Раздел 21.5), Класс поставщика (см. Раздел 21.16), Информация о конкретном поставщике (см. Раздел 21.17) и IA_PD (см. Раздел 21.21 ) опции. Кроме того, IA-адрес (см. Раздел 21.6) и префикс IA (см. Раздел 21.22) могут отображаться в их соответствующих вариантах IA более одного раза.

21.1 Формат параметров DHCP

Формат DHCP-параметров:

Рисунок 12 - Формат опций
Рисунок 12 — Формат опций

option-code

Целое число без знака, определяющее тип конкретной опции, переносимый в этой опции. 2-октетное поле.

option-len

Целое число без знака, указывающее длину поля данных опции в этой опции в октетах. 2-октетное поле.

option-data

Данные для опции; формат этих данных зависит от определения опции. Поле переменной длины (длина в октетах задается параметром-len).

Параметры DHCP ограничены использованием инкапсуляции. Некоторые параметры обычно применяются к клиенту, некоторые из них относятся к IA, а некоторые относятся к адресам внутри IA. Эти последние два случая обсуждаются в разделах 21.4, 21.5 и 21.6.

21.2 Идентификатор клиента

Параметр Идентификатор клиента используется для переноса DUID (см. Раздел 11), который идентифицирует клиента. Формат идентификатора клиента:

Рисунок 13 - Формат опций идентификатора клиента
Рисунок 13 — Формат опций идентификатора клиента

option-code — OPTION_CLIENTID (1).
option-len — Длина DUID в октетах.
DUID — DUID для клиента.

21.3 Идентификатор сервера

Параметр «Идентификатор сервера» используется для переноса DUID (см. Раздел 11), который идентифицирует сервер. Формат параметра Идентификатор сервера:

Рисунок 14 Формат варианта идентификатора сервера
Рисунок 14 Формат варианта идентификатора сервера

option-code — OPTION_SERVERID (2).
option-len — Длина DUID в октетах.
DUID — DUID для сервера.

21.4 Ассоциация удостоверения личности для несрочных адресов

Опция Identity Association for Non-временные адреса (IA_NA) используется для переноса IA_NA, параметров, связанных с IA_NA, и невременных адресов, связанных с IA_NA.

Адреса, отображаемые в опции IA_NA, не являются временными адресами (см. Раздел 21.5).

Формат опции IA_NA:

Рисунок 15 - Ассоциация идентификаторов для формата временных адресов
Рисунок 15 — Ассоциация идентификаторов для формата временных адресов

option-code — OPTION_IA_NA (3).

option-len — 12 + длина поля IA_NA-options.

IAID — Уникальный идентификатор для этой IA_NA; IAID должен быть уникальным среди идентификаторов для всех IA_NAs этого клиента. Числовое пространство IAID IA_NA отделено от пространства пробелов для других типов опций IA (то есть IA_TA и IA_PD). 4-октетное поле, содержащее целое число без знака.

T1 — Временной интервал, после которого клиент должен связаться с сервером, с которого были получены адреса в IA_NA, чтобы продлить время жизни адресов, назначенных IA_NA; T1 — это продолжительность времени относительно текущего времени, выраженная в единицах секунд. 4-октетное поле, содержащее целое число без знака.

T2 — Временной интервал, после которого клиент должен связаться с любым доступным сервером, чтобы продлить время жизни адресов, назначенных IA_NA; T2 — это продолжительность времени относительно текущего времени, выраженная в единицах секунд. 4-октетное поле, содержащее целое число без знака.

IA_NA-options — Параметры, связанные с этой IA_NA. Поле переменной длины (12 октетов меньше значения в поле опции-len).

Поле IA_NA-options инкапсулирует те параметры, которые относятся к этой IA_NA. Например, все параметры IA Address (см. Раздел 21.6), содержащие адреса, связанные с этой IA_NA, находятся в поле IA_NA-options.

Каждая IA_NA несет один «набор» несрочных адресов; для определения того, сколько адресов назначено, зависит от политики сервера, но обычно от каждого префикса, назначенного на ссылку, к которой привязан клиент, обычно назначается не более одного адреса.

Опция IA_NA может отображаться только в области параметров сообщения DHCP. Сообщение DHCP может содержать несколько опций IA_NA (хотя каждый из них должен иметь уникальный IAID).

Статус любых операций с этой IA_NA указывается в опции кода состояния (см. Раздел 21.13) в поле IA_NA-options.

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

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

В сообщении, отправленном сервером клиенту, клиент ДОЛЖЕН использовать значения в полях T1 и T2 для T1 и T2 раз, если значения в этих полях не равны 0. Значения в полях T1 и T2 — это количество секунд до T1 и T2 и рассчитываются с момента приема сообщения.

В соответствии с разделом 7.7 значение 0xffffffff воспринимается как «бесконечность» и должно использоваться тщательно.

Сервер выбирает значения T1 и T2, чтобы позволить клиенту продлить время жизни любых адресов в IA_NA до истечения срока службы, даже если сервер недоступен в течение некоторого короткого периода времени. Рекомендуемые значения для T1 и T2 равны 0,5 и 0,8 раза кратчайшему предпочтительному времени жизни адресов в IA, которые сервер готов продлить, соответственно. Если «наименьшее» предпочтительное время жизни равно 0xffffffff («бесконечность»), рекомендуемые значения T1 и T2 также равны 0xffffffff. Если время, в которое должны обновляться адреса в IA_NA, должно быть оставлено на усмотрение клиента, сервер устанавливает значения T1 и T2 равными 0. Клиент ДОЛЖЕН следовать правилам, определенным в Разделе 14.2.

Если клиент получает IA_NA с T1 больше, чем T2, а T1 и T2 больше 0, клиент отбрасывает опцию IA_NA и обрабатывает остальную часть сообщения, как если бы сервер не включал недопустимый вариант IA_NA.

21.5 Идентификационная ассоциация для временного адреса

Опция Identity Association for Temporary Addresses (IA_TA) используется для переноса IA_TA, параметров, связанных с IA_TA, и адресов, связанных с IA_TA. Все адреса в этой опции используются клиентом как временные адреса, как определено в [RFC4941]. Формат опции IA_TA:

Рисунок 16 - Формат идентификационной информации для временных форматов адресов
Рисунок 16 — Формат идентификационной информации для временных форматов адресов

option-code — OPTION_IA_TA (4).
option-len — 4 + length of IA_TA-options field.
IAID — Уникальный идентификатор для этого IA_TA; IAID должен быть уникальным среди идентификаторов для всех IA_TA этого клиента. Числовое пространство IAID IA_TA отделено от пространства пробелов для других типов опций IA (то есть IA_NA и IA_PD). 4-октетное поле, содержащее целое число без знака.
IA_TA-options — Параметры, связанные с этим IA_TA. Поле переменной длины (4 октета меньше значения в поле опции-len).

Поле IA_TA-options инкапсулирует те параметры, которые относятся к этой IA_TA. Например, все параметры IA Address (см. Раздел 21.6), содержащие адреса, связанные с этим IA_TA, находятся в поле опций IA_TA.

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

Параметр IA_TA может отображаться только в области параметров сообщения DHCP. Сообщение DHCP может содержать несколько опций IA_TA (хотя каждый из них должен иметь уникальный IAID).

Статус любых операций с этой IA_TA указывается в опции «Код состояния» (см. Раздел 21.13) в поле «Параметры IA_TA».

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

Параметр IA_TA не включает значения для T1 и T2. Клиент МОЖЕТ просить продлить допустимое время жизни на временных адресах, включив в него параметры в опции IA_TA, отправленные на сообщение Renew или Rebind на сервер. Например, клиент запрашивает расширение на действительное время жизни временного адреса, чтобы позволить приложению продолжать использовать установленное TCP-соединение. Расширение только действительного, но не предпочтительного срока службы означает, что в конечном итоге адрес окажется в устаревшем состоянии. Существующие соединения могут продолжаться, но новые адреса не будут созданы с использованием этого адреса.

Клиент получает новые временные адреса путем отправки опции IA_TA с новым IAID на сервер. Запрос новых временных адресов с сервера является эквивалентом создания новых временных адресов, как описано в [RFC4941]. Сервер будет генерировать новые временные адреса и возвращать их клиенту. Клиент должен запросить новые временные адреса до истечения срока службы на ранее назначенных адресах.

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

21.6 Опция IA Address

Параметр IA Address используется для указания адреса, связанного с IA_NA или IA_TA. Опция IA Address должна быть инкапсулирована в поле IA_NA-options опции IA_NA (см. Раздел 21.4) или в поле опций IA_TA опций IA_TA (см. Раздел 21.5). Поле IAaddr-options инкапсулирует те параметры, которые относятся к этому адресу.

Формат опции IA Address:

Рисунок 17 - Формат опций IA-адресов
Рисунок 17 — Формат опций IA-адресов

option-code — OPTION_IAADDR (5).
option-len — 24 + длина поля IAaddr-options.
IPv6-address — Адрес IPv6. Клиент НЕ ДОЛЖЕН формировать неявный префикс с длиной, отличной от 128 для этого адреса. 16-октетное поле.
preferred-lifetime — Предпочтительное время жизни для адреса в опции, выраженное в секундах. 4-октетное поле, содержащее целое число без знака.
valid-lifetime — Действительное время жизни для адреса в опции, выраженное в секундах. 4-октетное поле, содержащее целое число без знака.
IAaddr-options — Параметры, связанные с этим адресом. Поле переменной длины (24 октета меньше значения в поле опции-len).

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

Клиент НЕ ДОЛЖЕН отправлять опцию IA Address с неуказанным адресом (: :).

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

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

Согласно разделу 7.7, если действительное время жизни адреса равно 0xffffffff, это означает «бесконечность» и его следует использовать осторожно.

В опции IA_NA или IA_TA может отображаться более одного параметра IA Address.

Статус любых операций с этим адресом IA указывается в опции кода состояния в поле IAaddr-options, как указано в разделе 21.13.

21.7 Опция запроса опциона

Опция «Запрос опциона» используется для идентификации списка опций в сообщении между клиентом и сервером. Формат опции запроса опциона:

Рисунок 18 - Формат опций Request Option
Рисунок 18 — Формат опций Request Option

option-code — OPTION_ORO (6).
option-len — 2 * количество запрошенных опций.
requested-option-code-n — Код опции для параметра, запрошенного клиентом. Каждый код опции представляет собой поле с 2 октетами, содержащее целое число без знака.

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

Опция запроса опции НЕ ДОЛЖНА включать следующие параметры:

Идентификатор клиента (см. Раздел 21.2)
Идентификатор сервера (см. Раздел 21.3)
IA_NA (см. Раздел 21.4)
IA_TA (см. Раздел 21.5)
IA_PD (см. Раздел 21.21)
Адрес IA (см. Раздел 21.6)
Префикс IA (см. Раздел 21.22)
Запрос опциона (этот раздел)
Истекшее время (см. Раздел 21.9)
Предпочтение (см. Раздел 21.8)
Сообщение реле (см. Раздел 21.10)
Аутентификация (см. Раздел 21.11)
Одноадресная передача сервера (см. Раздел 21.12)
Код состояния (см. Раздел 21.13)
Быстрая фиксация (см. Раздел 21.14)
Класс пользователя (см. Раздел 21.15)
Класс поставщика (см. Раздел 21.16)
Идентификатор интерфейса (см. Раздел 21.18)
Переконфигурировать сообщение (см. Раздел 21.19)
Reconfigure Accept (см. Раздел 21.20)

Другие параметры верхнего уровня ДОЛЖНЫ появляться в опции Запрос опциона или они не будут отправляться сервером. Только опции верхнего уровня МОГУТ появиться в опции Запрос опций. Параметры, заключенные в контейнерную опцию, НЕ ДОЛЖНЫ появляться в опции Запрос опциона; см. [RFC7598] для примера параметров контейнера. Тем не менее, опции МОГУТ быть определены, которые определяют исключения для этого ограничения при включении инкапсулированных опций в опции запроса опциона. Например, опция запроса опций МОЖЕТ использоваться для поддержки поддержки функции, даже если эта опция инкапсулирована, как в случае опции Префикс Исключить [RFC6603]. См. Таблицу 4.

21.8 Вариант предпочтения

Параметр «Предпочтение» отправляется сервером клиенту для управления выбором сервера клиентом.

Формат опции «Предпочтения»:

Рисунок 19 - Формат опций предпочтений
Рисунок 19 — Формат опций предпочтений

option-code — OPTION_PREFERENCE (7).
option-len — 1.
pref-value — Значение предпочтения для сервера в этом сообщении. 1-октетное целое без знака.

Сервер МОЖЕТ включать опцию «Предпочтение» в сообщении «Реклама» для управления выбором сервера клиентом. См. Раздел 18.2.9 для получения информации об использовании клиентом опции «Предпочтения» и интерпретации значения данных параметра «Предпочтения».

21.9 Истекшее время

Рисунок 20 - Формат опций с истекшим временем
Рисунок 20 — Формат опций с истекшим временем

option-code — OPTION_ELAPSED_TIME (8).
option-len — 2.
elapsed-time — Количество времени, которое клиент начал с текущей транзакции DHCP. Это время выражается в сотых долях секунды (10 ^ -2 секунды). 2-октетное поле, содержащее целое число без знака.

Клиент должен ДОЛЖЕН включить опцию Истекшее время в сообщениях, чтобы указать, как долго клиент пытается завершить обмен сообщениями DHCP. Истекшее время измеряется с момента, когда клиент отправил первое сообщение в обмене сообщения, а поле прошедшего времени установлено в 0 в первом сообщении в обмене сообщениями. Серверы и ретрансляционные агенты используют значение данных в этой опции в качестве входных данных для политики, которая контролирует реакцию сервера на сообщение клиента. Например, опция «Истекшее время» позволяет вторичному серверу DHCP отвечать на запрос, когда первичный сервер не ответил в разумные сроки. Истекшее значение времени — это 16-битное (2-октетное) целое число без знака. Клиент использует значение 0xffff для представления любых значений прошедшего времени, превышающих наибольшее значение времени, которое может быть представлено в опции Истекшее время.

21.10 Опция ретрансляционного сообщения

Параметр Relay Message передает сообщение DHCP в сообщении Relay-forward или Relay-reply.

Формат опции Relay Message:

Рисунок 21 - Формат опций передачи ретрансляции
Рисунок 21 — Формат опций передачи ретрансляции

option-code — OPTION_RELAY_MSG (9).
option-len — Длина поля DHCP-relay-message.
DHCP-relay-message — В сообщении Relay-forward полученное сообщение передано дословно следующему ретранслятору или серверу; в сообщении Relay-reply, которое должно быть скопировано и передано ретранслятору или клиенту, адрес которого находится в поле однорангового адреса сообщения Relay-reply. Длина в октетах задается параметром-len.

21.11 Опция аутентификации

Параметр «Аутентификация» содержит аутентификационную информацию для аутентификации идентификатора и содержимого сообщений DHCP. Использование параметра «Аутентификация» описано в разделе 20. Протокол отложенной аутентификации, определенный в [RFC3315], был устарел этим документом из-за отсутствия использования (см. Раздел 25). Формат параметра «Аутентификация»:

Рисунок 22 - Формат опций аутентификации
Рисунок 22 — Формат опций аутентификации

option-code — OPTION_AUTH (11).
option-len — 11 + длина поля проверки подлинности.
protocol — Протокол аутентификации, используемый в этой опции аутентификации. 1-октетное целое без знака.

algorithm — Алгоритм, используемый в протоколе аутентификации. 1-октетное целое без знака.
RDM — Метод обнаружения повтора, используемый в этой опции аутентификации. 1-октетное целое без знака.
replay detection — Информация об обнаружении воспроизведения для RDM. 64-разрядное (8-октетное) поле.
authentication information — Информация аутентификации, определяемая протоколом и алгоритмом, используемым в этой опции аутентификации. Поле переменной длины (на 11 октетов меньше значения в поле опции-len).

IANA поддерживает реестр для значений протокола, алгоритма и RDM в <https://www.iana.org/assignments/auth-namespaces>.

21.12 Вариант одноадресной передачи сервера

Сервер отправляет эту опцию клиенту, чтобы указать клиенту, что ему разрешено отправлять одноадресные сообщения на сервер. Формат опции Unicast Server:

Рисунок 23 - Формат одноадресной передачи сервера
Рисунок 23 — Формат одноадресной передачи сервера

option-code — OPTION_UNICAST (12).
option-len — 16.
server-address — 128-битный адрес, на который клиент должен отправлять сообщения, отправленные с помощью одноадресной рассылки.

Сервер указывает в поле server-address адрес, по которому клиент должен отправлять одноадресные сообщения. Когда клиент получает этот параметр, где это допустимо и целесообразно, клиент отправляет сообщения непосредственно на сервер, используя адрес, указанный в поле server-address опции.

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

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

21.13 Вариант кода состояния

Эта опция возвращает индикацию состояния, связанную с сообщением DHCP или параметром, в котором он отображается. Формат параметра «Код состояния»:

Рисунок 24 - Формат опций кода состояния
Рисунок 24 — Формат опций кода состояния

option-code — OPTION_STATUS_CODE (13).
option-len — 2 + поле состояния-сообщения.
status-code — Числовой код для состояния, закодированного в этой опции. 2-октетное поле, содержащее целое число без знака.

status-message — Текстовая строка, кодированная UTF-8 [RFC3629], подходящая для отображения конечному пользователю. НЕ ДОЛЖЕН быть завершен с нулевой отметкой. Поле переменной длины (2 октета меньше значения в поле опции-len).

Параметр «Код состояния» может отображаться в поле «Параметры» сообщения DHCP и / или в поле «Параметры» другой опции. Если параметр «Код состояния» не отображается в сообщении, в котором может отображаться этот параметр, статус сообщения считается «Успешно».

Значения кода состояния, определенные ранее [RFC3315] и [RFC3633]:

Таблица 3 - Определения кода состояния
Таблица 3 — Определения кода состояния

Success

Код 0.

Успех

UnspecFail

Код 1.

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

NoAddrsAvail

Код 2.

У сервера нет адресов, доступных для назначения IA (ов).

NoBinding

Код 3.

Запись клиента (привязка) недоступна.

NotOnLink

Код 4.

Префикс для адреса не подходит для ссылки, к которой прикреплен клиент.

UseMulticast

Код 5.

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

NoPrefixAvail

Код 6.

Сервер не имеет префиксов, доступных для назначения IA_PD (s).

См. Раздел «Коды состояния» в https://www.iana.org/assignments dhcpv6-parameters для текущего списка кодов состояния.

 

21.14 Вариант быстрой фиксации

Параметр Rapid Commit используется для сигнализации использования обмена двумя сообщениями для назначения адреса. Формат опции Rapid Commit:

Рисунок 25 - Формат форматирования форматирования
Рисунок 25 — Формат форматирования форматирования

option-code — OPTION_RAPID_COMMIT (14).
option-len — 0.

Клиент МОЖЕТ включить эту опцию в сообщение «Запросить», если клиент готов выполнить обмен сообщениями «Забыть / Ответить», описанный в разделе 18.2.1.

Сервер ДОЛЖЕН включить этот параметр в ответное сообщение, отправленное в ответ на сообщение «Сопровождение» при завершении обмена сообщениями «Запрашивать / Ответить».

Обсуждение:

Каждый сервер, который отвечает «Ответ на запрос», который включает в себя параметр «Быстрая фиксация», передаст клиенту лизинг в ответном сообщении, но не получит подтверждения о том, что клиент получил сообщение «Ответить». Поэтому, если более одного сервера реагируют на запрос, включающий опцию «Быстрая фиксация», все, кроме одного сервера, будут передавать лизинг, которые фактически не используются клиентом; это может привести к неправильной адресной информации в DNS, если DHCP-серверы будут обновлять DNS [RFC4704], а ответы на запросы аренды (RFC5007) могут включать информацию об аренде, не используемой клиентом.

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

21.15 Вариант пользовательского класса

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

Формат параметра User Class:

Рисунок 26 - Формат опций пользовательского класса
Рисунок 26 — Формат опций пользовательского класса

option-code — OPTION_USER_CLASS (15).
option-len — Длина поля данных пользовательского класса.
user-class-data — Классы пользователей, переносимые клиентом. Длина в октетах задается параметром-len.

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

Область данных параметра User Class ДОЛЖНА содержать один или несколько экземпляров информации пользовательского класса. Каждый экземпляр данных пользовательского класса форматируется следующим образом:

Рисунок 27 - Формат поля данных пользовательского класса
Рисунок 27 — Формат поля данных пользовательского класса

Поле user-class-len имеет длину 2 октета и задает длину непрозрачных данных пользовательского класса в сетевом порядке байтов.

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

21.16 Вариант класса поставщика

Эта опция используется клиентом для идентификации поставщика, который изготовил оборудование, на котором работает клиент. Информация, содержащаяся в области данных этого параметра, содержится в одном или нескольких непрозрачных полях, которые идентифицируют детали конфигурации оборудования. Формат опции Vendor Class:

Рисунок 28 - Вариант опций класса поставщика
Рисунок 28 — Вариант опций класса поставщика

option-code — OPTION_VENDOR_CLASS (16).
option-len — 4 + длина поля данных поставщика-класса.
enterprise-number — Зарегистрированный фирменный номер поставщика, поддерживаемый IANA [IANA-PEN]. 4-октетное поле, содержащее целое число без знака.
vendor-class-data — Аппаратная конфигурация узла, на котором работает клиент. Поле переменной длины (4 октета меньше значения в поле опции-len).

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

Каждый экземпляр данных класса поставщика форматируется следующим образом:

Рисунок 29 - Формат поля данных поставщика-данных
Рисунок 29 — Формат поля данных поставщика-данных

Поле vendor-class-len имеет длину 2 октета и задает длину непрозрачных данных класса-поставщика в сетевом порядке байтов.

Серверы и клиенты НЕ ДОЛЖНЫ включать более одного экземпляра OPTION_VENDOR_CLASS с тем же Enterprise Number. Каждый экземпляр OPTION_VENDOR_CLASS может иметь несколько экземпляров экземпляров поставщика-класса.

21.17 Специфическая для поставщика информация

Эта опция используется клиентами и серверами для обмена информацией о конкретных поставщиках.

Формат опции «Информация о продавце»:

Рисунок 30 - Формат опциональной информации поставщика
Рисунок 30 — Формат опциональной информации поставщика

option-code — OPTION_VENDOR_OPTS (17).
option-len — 4 + длина поля данных поставщика-опции.

enterprise-number — Зарегистрированный фирменный номер поставщика, поддерживаемый IANA [IANA-PEN]. 4-октетное поле, содержащее целое число без знака.
vendor-option-data — Варианты поставщика, интерпретируемые кодом конкретного поставщика на клиентах и серверах. Поле переменной длины (4 октета меньше значения в поле опции-len).

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

Поле данных поставщика-поставщика ДОЛЖНО быть закодировано как последовательность полей кода / длины / значения в формате, идентичном параметрам DHCP (см. Раздел 21.1). Коды вспомогательных опций определяются продавцом, указанным в поле «номер предприятия» и не управляются IANA. Каждый из подпараметров форматируется следующим образом:

Рисунок 31 - Формат опций для конкретного поставщика
Рисунок 31 — Формат опций для конкретного поставщика

sub-opt-code — Код для дополнительной опции. 2-октетное поле.
sub-option-len — Целое число без знака, указывающее длину поля подпараметров-данных в этом подпараллеле в октетах. 2-октетное поле.
sub-option-data — Область данных для вспомогательной опции. Длина в октетах задается с помощью опции sub-option-len.

В сообщении DHCP может отображаться несколько экземпляров параметра Информация о конкретной поставщике. Каждый экземпляр опции интерпретируется в соответствии с кодами опций, определенными поставщиком, идентифицированным по Enterprise Number в этом параметре. Серверы и клиенты НЕ ДОЛЖНЫ отправлять более одного экземпляра опции «Информация о продавце» с тем же Enterprise-номером. Каждый экземпляр опции «Информация о продавце» МОЖЕТ содержать несколько подпараметров.

Клиент, который заинтересован в получении опционной информации о продавце:
— ДОЛЖНО указывать опцию «Информация о продавце» в опции «Запрос опциона».
— МОЖЕТ специфицировать связанную опцию Vendor Class (см. Раздел 21.16).
— МОЖЕТ специфицировать опцию «Информация о продавце» с соответствующими данными.

Серверы возвращают параметры информации, специфичные для поставщика, если они указаны в параметрах запроса опций от клиентов и:
— МОЖНО использовать номера Enterprise в соответствующих параметрах класса поставщика, чтобы ограничить набор Enterprise Numbers в возвращаемых опциях информации о продавце.
— МОЖЕТ возвращать все настроенные параметры информации, относящиеся к поставщику.
— МОЖЕТ использовать другую информацию в пакете или в своей конфигурации, чтобы определить, какой набор номеров Enterprise в параметрах Информация о продавце возвращается.

21.18 Опция интерфейса-идентификатора

Агент ретрансляции МОЖЕТ отправить параметр Interface-Id для идентификации интерфейса, на котором было получено сообщение клиента. Если агент-ретранслятор получает сообщение Relay-reply с опцией Interface-Id, агент ретрансляции передает сообщение клиенту через интерфейс, идентифицированный опцией.

Формат опции Interface-Id:

Рисунок 32 - Формат опций интерфейса-идентификатора
Рисунок 32 — Формат опций интерфейса-идентификатора

option-code — OPTION_INTERFACE_ID (18).
option-len — Длина поля интерфейса-идентификатора.
interface-id — Недостаточное значение произвольной длины, генерируемое агентом ретрансляции для идентификации одного из интерфейсов агента ретранслятора. Длина в октетах задается параметром-len.

Сервер ДОЛЖЕН скопировать параметр Interface-Id из сообщения Relay-forward в сообщение Relay-reply, которое сервер отправляет агенту ретрансляции в ответ на сообщение Relay-forward. Эта опция НЕ ДОЛЖНА появляться в любом сообщении, кроме сообщения «Реле-пересылка» или «Реле-ответ».

Серверы МОГУТ использовать поле интерфейса-идентификатора для политик назначения параметров. Значение идентификатора интерфейса СЛЕДУЕТ считаться непрозрачным значением, причем политики основаны только на точном совпадении; то есть поле идентификатора интерфейса НЕ ДОЛЖНО быть внутренне проанализировано сервером. Значение идентификатора интерфейса для интерфейса СЛЕДУЕТ быть стабильным и оставаться неизменным — например, после перезапуска агента ретрансляции; если значение идентификатора интерфейса изменяется, сервер не сможет надежно использовать его в политиках назначения параметров.

21.19 Переконфигурировать вариант сообщения

Сервер содержит параметр «Переопределить сообщение» в сообщении «Переконфигурировать», чтобы указать клиенту, отвечает ли клиент на сообщение «Обновление», сообщение «Пересылка» или сообщение «Информация-запрос». Формат параметра Reconfigure Message:

Рисунок 33 - Переконфигурировать формат опций сообщений
Рисунок 33 — Переконфигурировать формат опций сообщений

option-code — OPTION_RECONF_MSG (19).
option-len — 1.
msg-type — 5 для сообщения Renew, 6 для сообщения Rebind, 11 для сообщения Information-request. 1-октетное целое без знака.

Опция Reconfigure Message может отображаться только в сообщении Reconfigure.

21.20 Переконфигурировать вариант приема

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

Рисунок 34 - Переконфигурировать формат опций Accept
Рисунок 34 — Переконфигурировать формат опций Accept

option-code — OPTION_RECONF_ACCEPT (20).
option-len — 0.

21.21 Идентификационная ассоциация для опции делегирования префикса

Параметр IA_PD используется для переноса ассоциации идентификации делегирования префикса, параметров, связанных с IA_PD, и связанных с ним префиксов. Формат опции IA_PD:

Рисунок 35 - Ассоциация удостоверений для формата делегирования префикса
Рисунок 35 — Ассоциация удостоверений для формата делегирования префикса

option-code — OPTION_IA_PD (25).

option-len — 12 + длина поля опций IA_PD.

IAID — Уникальный идентификатор для этого IA_PD; IAID должен быть уникальным среди идентификаторов для всех IA_PD этого клиента. Пространство для IAID IA_PD отделено от пространства пробелов для других типов опций IA (то есть IA_NA и IA_TA). 4-октетное поле, содержащее целое число без знака.

T1 — Временной интервал, после которого клиент должен связаться с сервером, с которого были получены префиксы в IA_PD, чтобы продлить время жизни префиксов, делегированных IA_PD; T1 — это продолжительность времени относительно времени приема сообщения, выраженного в единицах секунд. 4-октетное поле, содержащее целое число без знака.

T2 — Временной интервал, после которого клиент должен связаться с любым доступным сервером, чтобы продлить время жизни префиксов, назначенных IA_PD; T2 — это продолжительность времени относительно времени приема сообщения, выраженного в единицах секунд. 4-октетное поле, содержащее целое число без знака.

IA_PD-options — Параметры, связанные с этим IA_PD. Поле переменной длины (12 октетов меньше значения в поле опции-len).

Поле IA_PD-options инкапсулирует те параметры, которые относятся к этому IA_PD. Например, все опции префикса IA (см. Раздел 21.22), содержащие префиксы, связанные с этим IA_PD, находятся в поле IA_PD-options.

Параметр IA_PD может отображаться только в области параметров сообщения DHCP. Сообщение DHCP может содержать несколько параметров IA_PD (хотя каждый из них должен иметь уникальный IAID).

Статус любых операций с этим IA_PD указывается в опции кода состояния (см. Раздел 21.13) в поле IA_PD-options.

Обратите внимание, что IA_PD не имеет явной «продолжительности жизни» или «длины аренды». Когда действительные времена жизни всех префиксов в IA_PD истекли, IA_PD можно считать истечением. Поля T1 и T2 включены для обеспечения явного контроля сервера, когда клиент должен связаться с сервером об определенном IA_PD.

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

В сообщении, отправленном сервером клиенту, клиент ДОЛЖЕН использовать значения в полях T1 и T2 для таймеров T1 и T2, если значения в этих полях не равны 0. Значения в полях T1 и T2 — это количество секунд до T1 и T2.

Сервер выбирает T1 и T2 раз, чтобы позволить клиенту продлить срок службы любых префиксов в IA_PD до истечения срока службы, даже если сервер недоступен в течение некоторого короткого периода времени. Рекомендуемые значения для T1 и T2 равны 0,5 и 0,8 кратчайшего предпочтительного времени жизни префиксов в IA_PD, которые сервер готов продлить, соответственно. Если время, в течение которого префиксы в IA_PD должны быть обновлены, должно быть оставлено на усмотрение клиента, сервер устанавливает T1 и T2 в 0. Клиент ДОЛЖЕН следовать правилам, определенным в Разделе 14.2.

Если клиент получает IA_PD с T1 больше T2, а T1 и T2 больше 0, клиент отбрасывает опцию IA_PD и обрабатывает оставшуюся часть сообщения, как если бы сервер не включал опцию IA_PD.

21.22 Вариант префикса IA

Параметр префикса IA используется для указания префикса, связанного с IA_PD. Опция IA Prefix должна быть инкапсулирована в поле IA_PD-options опции IA_PD (см. Раздел 21.21).

Рисунок 36 - Формат опций IA Prefix
Рисунок 36 — Формат опций IA Prefix

option-code — OPTION_IAPREFIX (26).

option-len — 25 + длина поля IAprefix-options.

preferred-lifetime — Предпочтительное время жизни для префикса в опции, выраженное в секундах. Значение 0xffffffff представляет «бесконечность» (см. Раздел 7.7). 4-октетное поле, содержащее целое число без знака.

valid-lifetime — Действительное время жизни для префикса в опции, выраженное в единицах секунд. Значение 0xffffffff представляет «бесконечность». 4-октетное поле, содержащее целое число без знака.

prefix-length —  Длина этого префикса в битах. 1-октетное целое без знака.

IPv6-prefix — Префикс IPv6. 16-октетное поле.

IAprefix-options — Параметры, связанные с этим префиксом. Поле переменной длины (25 октетов меньше значения в поле опции-len).

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

Клиент НЕ ДОЛЖЕН отправлять опцию префикса IA с 0 в поле «префикс длины» (и неопределенное значение (: 🙂 в поле «IPv6-prefix»). Клиент может отправить ненулевое значение в поле «префикс длины» и неопределенное значение (:) в поле «Префикс IPv6», чтобы указать предпочтение размера префикса, который должен быть делегирован. См. [RFC8168] для получения дополнительной информации о подсказках префикса.

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

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

В соответствии с разделом 7.7 значение 0xffffffff для предпочтительного времени жизни или действительного времени жизни принято понимать как «бесконечность» и его следует использовать осторожно.

Параметр префикса IA может отображаться только в опции IA_PD. В одной опции IA_PD может отображаться более одной опции префикса IA.

Статус любых операций с этой опцией префикса IA указывается в опции кода состояния (см. Раздел 21.13) в поле IAprefix-options.

21.23 Опция обновления информации

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

Рисунок 37 - Формат опций обновления информации
Рисунок 37 — Формат опций обновления информации

option-code — OPTION_INFORMATION_REFRESH_TIME (32).
option-len — 4.
information-refresh-time — Продолжительность времени относительно текущего времени, выраженная в единицах секунд. 4-октетное поле, содержащее целое число без знака.

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

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

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

Клиент ДОЛЖЕН использовать время обновления IRT_MINIMUM, если он получает опцию со значением, меньшим IRT_MINIMUM.

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

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

Когда клиент обнаруживает, что время обновления истекло, ему ДОЛЖНО пытаться обновить свои данные конфигурации, отправив Информационный запрос, как указано в Разделе 18.2.6, за исключением того, что клиент ДОЛЖЕН отложить отправку первого Информационного запроса случайным количеством время между 0 и INF_MAX_DELAY.

Клиент МОЖЕТ иметь максимальное значение для времени обновления, где это значение используется всякий раз, когда клиент получает эту опцию со значением, превышающим максимальное значение. Это также означает, что максимальное значение используется, когда принятое значение «бесконечность». Максимальное значение может сделать клиент менее уязвимым для атак на основе поддельных сообщений DHCP. Без максимального значения клиент может быть использован для использования неверной информации в течение, возможно, бесконечного периода времени. Однако могут быть причины для очень длительного времени обновления, поэтому может быть полезно, чтобы это максимальное значение было настраиваемым.

21.24 Опция SOL_MAX_RT

DHCP-сервер отправляет опции SOL_MAX_RT клиенту, чтобы переопределить значение по умолчанию SOL_MAX_RT. Значение SOL_MAX_RT в опции заменяет значение по умолчанию, определенное в Разделе 7.6. Одним из вариантов использования параметра SOL_MAX_RT является установка более высокого значения для SOL_MAX_RT; это уменьшает запрашиваемый трафик от клиента, который не получил ответа на его запросы.

Рисунок 38 - Формат опций SOL_MAX_RT
Рисунок 38 — Формат опций SOL_MAX_RT

option-code — OPTION_SOL_MAX_RT (82).
option-len — 4.
SOL_MAX_RT value — Переопределение значения для SOL_MAX_RT в секундах; ДОЛЖЕН быть в этом диапазоне: 60 <= «значение» <= 86400 (1 день). 4-октетное поле, содержащее целое число без знака.

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

DHCP-сервер МОЖЕТ включить параметр SOL_MAX_RT в любой ответ, который он отправляет клиенту, который включил код опции SOL_MAX_RT в опции Запрос опциона. Параметр SOL_MAX_RT отправляется в качестве параметра верхнего уровня в сообщении клиенту.

Клиент DHCP ДОЛЖЕН игнорировать любые значения параметра SOL_MAX_RT, которые составляют менее 60 или более 86400.

Если клиент DHCP получает сообщение, содержащее параметр SOL_MAX_RT, который имеет действительное значение для SOL_MAX_RT, клиент ДОЛЖЕН установить свой внутренний параметр SOL_MAX_RT в значение, содержащееся в опции SOL_MAX_RT. Это значение SOL_MAX_RT затем используется механизмом повторной передачи, определенным в разделах 15 и 18.2.1.

Цель этого механизма — дать сетевым администраторам возможность избежать чрезмерного трафика DHCP, если все серверы DHCP становятся недоступными. Поэтому ожидается, что это значение сохранится до тех пор, пока это практически возможно.

Обновленное значение SOL_MAX_RT применяется только к сетевому интерфейсу, на котором клиент получил параметр SOL_MAX_RT.

21.25 Опция INF_MAX_RT

DHCP-сервер отправляет опции INF_MAX_RT клиенту для переопределения значения по умолчанию INF_MAX_RT. Значение INF_MAX_RT в опции заменяет значение по умолчанию, определенное в разделе 7.6. Одним из вариантов использования INF_MAX_RT является установка более высокого значения для INF_MAX_RT; это уменьшает трафик информации-запроса от клиента, который не получил ответа на его сообщения с запросом информации.

Формат опции INF_MAX_RT:

Рисунок 39 - Формат опций INF_MAX_RT
Рисунок 39 — Формат опций INF_MAX_RT

option-code — OPTION_INF_MAX_RT (83).
option-len — 4.
INF_MAX_RT value — Значение переопределения для INF_MAX_RT в секундах; ДОЛЖЕН быть в этом диапазоне: 60 <= «значение» <= 86400 (1 день). 4-октетное поле, содержащее целое число без знака.

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

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

Клиент DHCP ДОЛЖЕН игнорировать любые значения параметров INF_MAX_RT, которые составляют менее 60 или более 86400.

Если клиент DHCP получает сообщение, содержащее параметр INF_MAX_RT, который имеет действительное значение для INF_MAX_RT, клиент ДОЛЖЕН установить свой внутренний параметр INF_MAX_RT в значение, содержащееся в опции INF_MAX_RT. Это значение INF_MAX_RT затем используется механизмом повторной передачи, определенным в разделах 15 и 18.2.6.

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

22. Вопросы безопасности

В этом разделе рассматриваются соображения безопасности, которые не связаны с конфиденциальностью. См. Раздел 23 для обсуждения вопросов конфиденциальности.

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

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

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

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

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

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

Клиент DHCP также может подвергаться атаке через получение сообщения Reconfigure с вредоносного сервера, что заставляет клиента получать неверную информацию о конфигурации с этого сервера. Обратите внимание, что хотя клиент отправляет свой ответ (Renew, Rebind или Information-request message) через ретрансляционный агент, и поэтому этот ответ будет приниматься только серверами, на которые ретранслируются сообщения DHCP, вредоносный сервер может отправить сообщение Reconfigure для клиента, после (после соответствующей задержки) сообщение «Ответ», которое будет принято клиентом. Таким образом, вредоносный сервер, который не находится на сетевом пути между клиентом и сервером, все еще может монтировать атаку Reconfigure на клиенте. Использование идентификаторов транзакций, криптографически обоснованных и не может быть легко предсказано, также уменьшит вероятность того, что такая атака будет успешной.

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

RKAP, описанный в Разделе 20.4, обеспечивает защиту от использования сообщения Reconfigure злоумышленным DHCP-сервером для монтирования DoS или атаки «человек-в-середине» на клиенте. Этот протокол может быть взломан злоумышленником, который может перехватить начальное сообщение, в котором DHCP-сервер отправляет клиенту ключ «в обычный текст».

Многие из этих атак на серверах-изгоях могут быть смягчены с помощью механизмов, описанных в [RFC7610] и [RFC7513].

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

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

Сообщения, обменянные между ретрансляционными агентами и серверами, могут использоваться для установки атаки «человек в середине» или DoS. Связь между сервером и ретранслятором и связь между ретрансляционными агентами могут быть аутентифицированы и зашифрованы с использованием IPsec, как описано в [RFC8213].

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

Различные сетевые среды также предлагают уровни безопасности, если они развернуты, как описано ниже:

  • В корпоративных и заводских сетях использование аутентификации на [IEEE-802.1x] может препятствовать подключению неизвестных или ненадежных клиентов к сети. Однако это не обязательно гарантирует, что подключенный клиент будет хорошим DHCP или сетевым игроком.
  • Для проводных сетей, где клиенты обычно подключаются к порту коммутатора, отслеживание трафика многоадресной передачи DHCP (или одноадресной) становится затруднительным, поскольку коммутаторы ограничивают трафик, отправляемый в порт. Многоадресные пакеты DHCP-клиента (с адресом назначения fe02 :: 1: 2) отправляются только на порт коммутатора DHCP-сервера (или ретранслятора) — не все порты. Кроме того, одноадресные ответы сервера (или реле) передаются только на порт целевого клиента — не все порты.
  • В общедоступных сетях (например, в сети Wi-Fi в кафе или в аэропорту) другим пользователям в радиусе радиосвязи можно отслеживать DHCP и другой трафик. Но в этих средах очень мало, если что-то, что может быть извлечено из самого DHCP-трафика (от клиента к серверу или от сервера к клиенту), если соблюдены соображения конфиденциальности, приведенные в разделе 23. Даже для устройств, которые не соответствуют соображениям конфиденциальности, мало что можно узнать, которые не будут доступны из последующих сообщений в любом случае (например, адрес устройства управления доступом к среде (MAC)). Кроме того, поскольку все клиенты обычно получают аналогичные данные конфигурации, плохой актер, который инициирует сам запрос DHCP, может узнать большую часть такой информации. Как упоминалось выше, одна угроза заключается в том, что ключ RKAP для клиента может быть изучен (если отслеживается первичный контроль за покупками / рекламой / запросом / ответом) и инициирует преждевременную реконфигурацию, но это относительно легко предотвратить, запретив прямой клиент -клиентную связь в этих сетях или с использованием [RFC7610] и [RFC7513].

23. Конфиденциальность

Для расширенного обсуждения соображений конфиденциальности для клиента см. [RFC7824]:

  • В частности, в Разделе 3 обсуждаются различные идентификаторы, которые могут быть неправильно использованы для отслеживания клиента.
  • В Разделе 4 обсуждаются существующие механизмы, которые могут повлиять на конфиденциальность клиента.
  • Наконец, в Разделе 5 обсуждаются потенциальные векторы атаки.

Рекомендации по устранению или устранению этих проблем см. В [RFC7844].

Эта спецификация не определяет стратегии распределения для серверов. Ожидается, что разработчики разработают собственный алгоритм для сервера, чтобы выбрать ресурс из имеющегося пула. Несколько возможных стратегий распределения упоминаются в разделе 4.3 документа [RFC7824]. Имейте в виду, что список в [RFC7824] не является исчерпывающим; есть, конечно, другие возможные стратегии. Читателям также рекомендуется читать [RFC7707] — в частности, в разделе 4.1.2, где обсуждаются проблемы с определенными стратегиями распределения.

24. Вопросы IANA

Этот документ не определяет новые пространства имен или определения DHCP.

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

Список назначенных значений, используемых в DHCPv6, доступен по адресу <https://www.iana.org/assignments/dhcpv6-parameters>.

IANA обновила https://www.iana.org/assignments/dhcpv6-parameters, чтобы добавить ссылку на этот документ для определений, ранее созданных [RFC3315], [RFC3633], [RFC4242] и [RFC7083].

IANA добавила два столбца в реестр DHCPv6 «Коды опций» на странице <https://www.iana.org/assignments/dhcpv6-parameters>, чтобы указать, какие параметры разрешены для отображения в опции запроса клиента (см. Раздел 21.7) и какие параметры являются одно-элементными (разрешено появляться только как опция верхнего уровня или инкапсулированной, см. раздел 16 из [RFC7227]). В таблице 4 приведены данные для параметров, назначенных IANA на момент написания этого документа.

Таблица 4 - Обновленные параметры
Таблица 4 — Обновленные параметры

Примечания для таблицы 4:

(1) В столбце «Клиент ORO» параметр «Да» для опции означает, что клиент включает этот код опции в опции «Запрос опциона» (см. Раздел 21.7), если он желает, чтобы информация о конфигурации, а «Нет» означает, что параметр НЕ ДОЛЖЕН быть включен (и серверы СЛЕДУЕТ игнорировать этот код опции, если он появляется в опции запроса опциона клиента).

(2) Для каждого Enterprise Number ДОЛЖЕН быть только один экземпляр.

(3) Подробнее см. [RFC7598].

IANA скорректировала диапазон возможных кодов состояния в таблице «Коды состояния» на https://www.iana.org/assignments/dhcpv6-parameters, заменив 23-255 (как неназначенный) на 23-65535 (коды 16 -битные целые числа без знака).

IANA обновила записи таблицы All_DHCP_Relay_Agents_and_Servers (ff02 :: 1: 2) и All_DHCP_Servers (ff05 :: 1: 3) в «Реестре адресов адресов многоадресной рассылки IPv6» на странице https://www.iana.org/assignments/ipv6- multicast-addresses для ссылки на этот документ вместо [RFC3315].

IANA добавила аннотацию «Устаревшая» в записи «Отложенная аутентификация DHCPv6» в «Подтверждение суффикса аутентификации (значение 8) — значения идентификатора протокола» в <https://www.iana.org/assignments/bootp-dhcp-parameters > и добавила аннотацию «Устаревшая» в записи «Задержка аутентификации» в реестре «Значения пространственных значений протокола» на странице <https://www.iana.org/assignments/auth-namespaces>. IANA также обновила эти страницы для ссылки на этот документ вместо [RFC3315].

IANA добавила ссылку на этот документ для значения RDM 0 в реестр «Значения пространственных значений имени RDM» на странице https://www.iana.org/assignments/auth-namespaces.

IANA обновила «Регистр номеров портов имен служб и транспортных протоколов» по адресу https://www.iana.org/assignments/service-names-port-numbers следующим образом:

546/udp Этот документ
547/udp Этот документ
547/tcp [RFC5460]
647/tcp [RFC8156]

25. Обобщенные механизмы

Эта спецификация в основном является исправленной и очищенной версией исходной спецификации — [RFC3315] — наряду с многочисленными дополнениями от более поздних RFC. Тем не менее, существует небольшое количество механизмов, которые не были широко развернуты, не были указаны или имели другие операционные проблемы. Эти механизмы теперь считаются устаревшими. Устаревшие реализации МОГУТ поддерживать их, но реализации, соответствующие этому документу, НЕ ДОЛЖНЫ полагаться на них.

В настоящее время устаревшие механизмы:

  • Delayed authentication (Отсроченная аутентификация). Этот механизм был уточнен и представлен значительный эксплуатационный ущерб. В результате через 10 лет его принятие в лучшем случае было крайне ограничено.
  • Lifetime hints sent by a client (Пожизненные подсказки, отправленные клиентом). Клиентам было разрешено отправлять значения времени жизни в качестве подсказок. Этот механизм не был широко реализован, и были известны неправильные реализации, которые отправили оставшиеся сроки жизни, а не общее количество ожидаемых жизней. Это, в свою очередь, иногда неправильно понималось серверами как запрос на постоянно уменьшающиеся сроки аренды, что вызвало проблемы, когда значения начали приближаться к нулю. Клиенты теперь ДОЛЖНЫ установить время жизни на 0 в параметрах IA Address и IA Prefix, а серверы ДОЛЖНЫ игнорировать любое запрошенное значение времени жизни.
  • T1/T2 hints sent by a client (T1 / T2 подсказки, отправленные клиентом). У них были проблемы, похожие на те, которые были намечены на всю жизнь. Клиенты теперь ДОЛЖНЫ установить значения T1 / T2 в 0 в вариантах IA_NA и IA_PD, а серверы ДОЛЖНЫ игнорировать любые значения T1 / T2, предоставленные клиентом.

26. Рекомендации

26.1 Нормативные ссылки

[RFC768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, «Neighbor Discovery for IP version 6 (IPv6)», RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, «IPv6 Stateless Address Autoconfiguration», RFC 4862, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.

[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, «Lightweight DHCPv6 Relay Agent», RFC 6221, DOI 10.17487/RFC6221, May 2011,
<https://www.rfc-editor.org/info/rfc6221>.

[RFC6355] Narten, T. and J. Johnson, «Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)», RFC 6355, DOI 10.17487/RFC6355, August 2011,
<https://www.rfc-editor.org/info/rfc6355>.

[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, «Guidelines for Creating New DHCPv6 Options», BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.

[RFC7283] Cui, Y., Sun, Q., and T. Lemon, «Handling Unknown DHCPv6 Messages», RFC 7283, DOI 10.17487/RFC7283, July 2014,
<https://www.rfc-editor.org/info/rfc7283>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, «UDP Usage Guidelines», BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.

[RFC8213] Volz, B. and Y. Pal, «Security of Messages Exchanged between Servers and Relay Agents», RFC 8213, DOI 10.17487/RFC8213, August 2017,
<https://www.rfc-editor.org/info/rfc8213>.

26.2 Информационные ссылки

[IANA-HARDWARE-TYPES]
IANA, «Hardware Types»,
<https://www.iana.org/assignments/arp-parameters>.

[IANA-PEN] IANA, «Private Enterprise Numbers»,
<https://www.iana.org/assignments/enterprise-numbers>.

[IANA-RESERVED-IID]
IANA, «Reserved IPv6 Interface Identifiers»,
<https://www.iana.org/assignments/ipv6-interface-ids>.

[IEEE-802.1x]
IEEE, «IEEE Standard for Local and metropolitan area networks—Port-Based Network Access Control», IEEE 802.1X-2010, DOI 10.1109/IEEESTD.2010.5409813,
<https://ieeexplore.ieee.org/servlet/opac?punumber=5409757>.

[RFC826] Plummer, D., «An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware», STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>.

[RFC2131] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.

[RFC2132] Alexander, S. and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>.

[RFC2464] Crawford, M., «Transmission of IPv6 Packets over Ethernet Networks», RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>.

[RFC3162] Aboba, B., Zorn, G., and D. Mitton, «RADIUS and IPv6», RFC 3162, DOI 10.17487/RFC3162, August 2001,
<https://www.rfc-editor.org/info/rfc3162>.

[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, «An Informal Management Model for Diffserv Routers», RFC 3290, DOI 10.17487/RFC3290, May 2002,
<https://www.rfc-editor.org/info/rfc3290>.

[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 3315, DOI 10.17487/RFC3315,
July 2003, <https://www.rfc-editor.org/info/rfc3315>.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.

[RFC3633] Troan, O. and R. Droms, «IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6», RFC 3633, DOI 10.17487/RFC3633, December 2003,
<https://www.rfc-editor.org/info/rfc3633>.

[RFC3646] Droms, R., Ed., «DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 3646, DOI 10.17487/RFC3646, December 2003,
<https://www.rfc-editor.org/info/rfc3646>.

[RFC3736] Droms, R., «Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6», RFC 3736, DOI 10.17487/RFC3736,
April 2004, <https://www.rfc-editor.org/info/rfc3736>.

[RFC3769] Miyakawa, S. and R. Droms, «Requirements for IPv6 Prefix Delegation», RFC 3769, DOI 10.17487/RFC3769, June 2004,
<https://www.rfc-editor.org/info/rfc3769>.

[RFC4193] Hinden, R. and B. Haberman, «Unique Local IPv6 Unicast Addresses», RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.

[RFC4242] Venaas, S., Chown, T., and B. Volz, «Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 4242, DOI 10.17487/RFC4242,
November 2005, <https://www.rfc-editor.org/info/rfc4242>.

[RFC4477] Chown, T., Venaas, S., and C. Strauf, «Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues», RFC 4477, DOI 10.17487/RFC4477, May 2006,
<https://www.rfc-editor.org/info/rfc4477>.

[RFC4704] Volz, B., «The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option», RFC 4704, DOI 10.17487/RFC4704, October 2006, <https://www.rfc-editor.org/info/rfc4704>.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, «Privacy Extensions for Stateless Address Autoconfiguration in IPv6», RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.

[RFC4943] Roy, S., Durand, A., and J. Paugh, «IPv6 Neighbor Discovery On-Link Assumption Considered Harmful», RFC 4943, DOI 10.17487/RFC4943, September 2007,
<https://www.rfc-editor.org/info/rfc4943>.

[RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, «DHCPv6 Relay Agent Echo Request Option», RFC 4994, DOI 10.17487/RFC4994, September 2007, <https://www.rfc-editor.org/info/rfc4994>.

[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, «DHCPv6 Leasequery», RFC 5007, DOI 10.17487/RFC5007, September 2007, <https://www.rfc-editor.org/info/rfc5007>.

[RFC5453] Krishnan, S., «Reserved IPv6 Interface Identifiers», RFC 5453, DOI 10.17487/RFC5453, February 2009,
<https://www.rfc-editor.org/info/rfc5453>.

[RFC5460] Stapp, M., «DHCPv6 Bulk Leasequery», RFC 5460, DOI 10.17487/RFC5460, February 2009,
<https://www.rfc-editor.org/info/rfc5460>.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

[RFC5908] Gayraud, R. and B. Lourdelet, «Network Time Protocol (NTP) Server Option for DHCPv6», RFC 5908, DOI 10.17487/RFC5908,
June 2010, <https://www.rfc-editor.org/info/rfc5908>.

[RFC6422] Lemon, T. and Q. Wu, «Relay-Supplied DHCP Options», RFC 6422, DOI 10.17487/RFC6422, December 2011, <https://www.rfc-editor.org/info/rfc6422>.

[RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. Troan, «Prefix Exclude Option for DHCPv6-based Prefix Delegation», RFC 6603, DOI 10.17487/RFC6603, May 2012, <https://www.rfc-editor.org/info/rfc6603>.

[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, «Default Address Selection for Internet Protocol Version 6 (IPv6)», RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.

[RFC6879] Jiang, S., Liu, B., and B. Carpenter, «IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods», RFC 6879, DOI 10.17487/RFC6879, February 2013, <https://www.rfc-editor.org/info/rfc6879>.

[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, «Client Link-Layer Address Option in DHCPv6», RFC 6939, DOI 10.17487/RFC6939,
May 2013, <https://www.rfc-editor.org/info/rfc6939>.

[RFC7083] Droms, R., «Modification to Default Values of SOL_MAX_RT and INF_MAX_RT», RFC 7083, DOI 10.17487/RFC7083, November 2013, <https://www.rfc-editor.org/info/rfc7083>.

[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, «Basic Requirements for IPv6 Customer Edge Routers», RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>.

[RFC7136] Carpenter, B. and S. Jiang, «Significance of IPv6 Interface Identifiers», RFC 7136, DOI 10.17487/RFC7136, February 2014, <https://www.rfc-editor.org/info/rfc7136>.

[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, «DHCPv4-over-DHCPv6 (DHCP 4o6) Transport», RFC 7341, DOI 10.17487/RFC7341, August 2014, <https://www.rfc-editor.org/info/rfc7341>.

[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, «IPv6 Home Networking Architecture Principles», RFC 7368, DOI 10.17487/RFC7368, October 2014, <https://www.rfc-editor.org/info/rfc7368>.

[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, «Source Address Validation Improvement (SAVI) Solution for DHCP», RFC 7513, DOI 10.17487/RFC7513, May 2015,
<https://www.rfc-editor.org/info/rfc7513>.

[RFC7550] Troan, O., Volz, B., and M. Siodelski, «Issues and Recommendations with Multiple Stateful DHCPv6 Options», RFC 7550, DOI 10.17487/RFC7550, May 2015, <https://www.rfc-editor.org/info/rfc7550>.

[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, «DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients», RFC 7598, DOI 10.17487/RFC7598, July 2015, <https://www.rfc-editor.org/info/rfc7598>.

[RFC7610] Gont, F., Liu, W., and G. Van de Velde, «DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers», BCP 199, RFC 7610, DOI 10.17487/RFC7610, August 2015, <https://www.rfc-editor.org/info/rfc7610>.

[RFC7707] Gont, F. and T. Chown, «Network Reconnaissance in IPv6 Networks», RFC 7707, DOI 10.17487/RFC7707, March 2016, <https://www.rfc-editor.org/info/rfc7707>.

[RFC7721] Cooper, A., Gont, F., and D. Thaler, «Security and Privacy Considerations for IPv6 Address Generation Mechanisms», RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>.

[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, «Privacy Considerations for DHCPv6», RFC 7824, DOI 10.17487/RFC7824, May 2016, <https://www.rfc-editor.org/info/rfc7824>.

[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, «Anonymity Profiles for DHCP Clients», RFC 7844, DOI 10.17487/RFC7844, May 2016,
https://www.rfc-editor.org/info/rfc7844.

[RFC7969] Lemon, T. and T. Mrugalski, «Customizing DHCP Configuration on the Basis of Network Topology», RFC 7969, DOI 10.17487/RFC7969, October 2016, https://www.rfc-editor.org/info/rfc7969.

[RFC8156] Mrugalski, T. and K. Kinnear, «DHCPv6 Failover Protocol», RFC 8156, DOI 10.17487/RFC8156, June 2017, https://www.rfc-editor.org/info/rfc8156.

[RFC8168] Li, T., Liu, C., and Y. Cui, «DHCPv6 Prefix-Length Hint Issues», RFC 8168, DOI 10.17487/RFC8168, May 2017, https://www.rfc-editor.org/info/rfc8168.

[TR-187] Broadband Forum, «TR-187 — IPv6 for PPP Broadband Access», February 2013, https://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf.

Приложение A — Сводка изменений

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

1. Введение (раздел 1) было реорганизовано и обновлено. В частности, обмен сообщениями клиент / сервер был перемещен в новый (и расширенный) раздел самостоятельно (см. Раздел 5).

2. Были добавлены новые разделы, чтобы обсудить связь с предыдущими документами DHCPv6, а также с DHCPv4.

3. Разделы 2 («Требования») и 3 («Предыстория») имели очень незначительные изменения.

4. Раздел 4 («Терминология») имел незначительные изменения.

5. Раздел 4.2 («Терминология DHCP») был расширен с целью включения определений из RFC 3633, добавления определений T1 / T2, добавления определений, полезных для описания комбинированных операций назначения адресов и операций делегирования префикса, а также для улучшения некоторых существующих определений.

6. Раздел 5 («Клиент / серверные биржи») был добавлен из материала, ранее описанного в Разделе 1 RFC 3315 («Введение и обзор») и был расширен.

7. Раздел 6 («Операционные модели») является новым. Он предоставляет информацию о видах клиентов DHCP и о том, как они работают.

8. Раздел 7 («Константы DHCP») был в основном обновлен, чтобы добавить константы из RFC 4242 и RFC 7083. Обратите внимание, что значение HOP_COUNT_LIMIT по умолчанию было уменьшено с 32 до 8.

9. Разделы 8 («Форматы сообщений клиента / сервера»), 9 («Форматы сообщений ретранслятора / сервера») и 10 («Представление и использование доменных имен») имели только незначительные изменения.

10. Раздел 11 («Уникальный идентификатор DHCP (DUID)») теперь препятствует, а не запрещает серверу анализировать DUID; теперь включает некоторую информацию о DUID-UUID (RFC 6355); и имел другие незначительные изменения.

11. Раздел 12 («Ассоциация удостоверений») был расширен, чтобы лучше объяснить концепцию и также включить делегирование префикса.

12. Раздел 13 («Присвоение IA») включает материал из двух разделов (11 и 12) RFC 3315, а также включает раздел о делегировании префикса.

13. Раздел 14 («Передача сообщений клиентом») был расширен, чтобы включить ограничение ставок клиентами и как клиенты должны обрабатывать значения T1 или T2 0.

14. Раздел 15 («Надежность обменов сообщений, инициированных клиентом») был расширен, чтобы уточнить, что параметр «Истекшее время» должен быть обновлен в повторно переданных сообщениях и что клиенту не требуется прослушивать DHCP-трафик на весь период повторной передачи.

15. Раздел 16 («Проверка сообщений») имеет незначительные изменения.

16. Раздел 17 («Исходный адрес источника и выбор интерфейса») был расширен, чтобы включить делегирование префикса.

17. Раздел 18 («Обмен конфигурациями DHCP») объединяет то, что раньше использовалось в следующих разделах RFC 3315: «Запрос DHCP-сервера» (раздел 17), «Обмен DHCP-сервером Exchange» (раздел 18) и «DHCP Server-Initified Configuration Exchange «(раздел 19). Этот материал был реорганизован и расширен и включает в себя префиксное делегирование RFC 3633 и другие изменения из RFC 4242, RFC 7083 и RFC 7550. Несколько изменений примечания:

  • A. Опция запроса опциона больше не является обязательной для некоторых сообщений (запрос и запрос информации), так как RFC 7083 требует, чтобы клиенты запрашивали параметры SOL_MAX_RT или INF_MAX_RT.
  • B. Сообщение Reconfigure больше не должно содержать IA_NA / IA_PD, ORO или другие параметры, чтобы указать клиенту, что было переконфигурировано. Клиент должен запросить все, что ему нужно, в ответе на Reconfigure.
  • C. Контуры времени жизни и T1 / T2 не должны посылаться клиентом (он должен отправлять значения 0 в этих полях), и любые ненулевые значения должны игнорироваться сервером.
  • D. Уточнено, что сервер может возвращать разные адреса в ответе, чем запрашивается клиентом в сообщении «Запрос». Также уточняется, что сервер не должен включать адреса, которые он не будет назначать.

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

18. Раздел 19 («Поведение агента реле») включает RFC 7283 и имеет незначительные изменения. Добавлен новый раздел «Взаимодействие между агентами реле и серверами» (раздел 19.4).

19. Раздел 20 («Аутентификация сообщений DHCP») включает значительные изменения: материалы IPsec были в основном удалены и заменены ссылкой на RFC 8213, а протокол с задержкой аутентификации устарел (см. Раздел 25). Обратите внимание, что RKAP по-прежнему считается текущим.

20. Раздел 21 («Параметры DHCP») был расширен для включения OPTION_IA_PD и OPTION_IAPREFIX из RFC 3633, опции обновления информации (OPTION_INFORMATION_REFRESH_TIME) из RFC 4242 и опций SOL_MAX_RT и INF_MAX_RT из RFC 7083. Некоторые дополнительные изменения были сделаны для уточнения опция, например, какие параметры не должны быть в опции запроса опциона.

21. Вопросы безопасности (раздел 22) были обновлены для расширения обсуждения угроз безопасности и включают материалы из включенных документов, в первую очередь RFC 3633.

22. Добавлены новые соображения конфиденциальности (раздел 23) для учета вопросов конфиденциальности.

23. Раздел 24 («Соображения IANA») был переписан, чтобы отразить изменения, запрошенные для этого документа, поскольку другие документы уже сделали назначение сообщений, опцию, DUID и присвоение кода статуса, и этот документ не добавляет никаких новых назначений.

24. Раздел 25 («Обобщенные механизмы») представляет собой новый раздел, который документирует механизмы, устаревшие по этой спецификации.

25. Приложения B («Внешний вид вариантов в типах сообщений») и C («Внешний вид опций в параметрах» «Поле параметров DHCP») были обновлены с учетом включенных опций из RFC 3633, RFC 4242 и RFC 7083.

26. Там, где это уместно, были добавлены справочные ссылки, чтобы представить дополнительные справочные материалы и рекомендации на протяжении всего документа (как можно заметить из-за огромного увеличения количества ссылок).

27. Были внесены изменения с целью включения следующих ошибок для RFC 3315: Идентификационные номера 294, 295, 1373, 1815, 2471, 2472, 2509, 2928, 3577, 5450; RFC 3633: Идентификационные номера 248, 2468, 2469, 2470, 3736; и RFC 3736: Идентификатор ошибки 3796. Обратите внимание, что идентификатор ошибки 1880 для RFC 3633 больше не применяется, поскольку серверы (делегирующие маршрутизаторы) игнорируют полученные подсказки T1 / T2 (см. (C) в пункте 17 выше).

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

29. Следует отметить, что этот документ не относится ко всем функциям и спецификациям DHCPv6. Читатели этой спецификации должны посетить https://www.iana.org/assignments/dhcpv6-parameters и https://datatracker.ietf.org/wg/dhc/, чтобы узнать о RFC, которые определяют сообщения DHCPv6, параметры, коды состояния , и больше.

Приложение B — Внешний вид опций в типах сообщений

В следующих таблицах указаны «*» параметры, разрешенные для каждого типа сообщений DHCP.

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

Параметры, разрешенные для каждого типа сообщений DHCP
Параметры, разрешенные для каждого типа сообщений DHCP

ПРИМЕЧАНИЕ. Параметр «Идентификатор сервера» (см. Раздел 21.3) включен только в сообщения «Информация-запрос», которые отправляются в ответ на «Переконфигурировать» (см. Раздел 18.2.6).

Параметры, разрешенные для каждого типа сообщений DHCP - 02
Параметры, разрешенные для каждого типа сообщений DHCP — 02
Параметры, разрешенные для каждого типа сообщений DHCP - 03
Параметры, разрешенные для каждого типа сообщений DHCP — 03

Приложение C — Внешний вид опций в «опциях» Поле параметров DHCP

В следующей таблице указаны «*», где параметры, определенные в этом документе, могут отображаться как параметры верхнего уровня или могут быть инкапсулированы в другие параметры, определенные в этом документе. Другие RFC могут определять дополнительные ситуации, когда опции, определенные в этом документе, инкапсулируются в другие параметры.

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

Параметры верхнего уровня, которые могут быть инкапсулированы в другие параметры
Параметры верхнего уровня, которые могут быть инкапсулированы в другие параметры

Примечания. Параметры, отмеченные звездочкой в столбце «Верхний уровень», отображаются в поле «Параметры» клиентских сообщений (см. Раздел 8). Параметры, отмеченные звездочками в столбцах «RELAY-FORW» и «RELAY-REPL», отображаются в поле «Параметры» сообщений Relay-forward и Relay-reply (см. Раздел 9).

Признательность

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

— RFC 3315 (Ralph Droms, Jim Bound, Bernie Volz, Ted Lemon, Charles Perkins, and Mike Carney)
— RFC 3633 (Ole Troan and Ralph Droms)
— RFC 3736 (Ralph Droms)
— RFC 4242 (Stig Venaas, Tim Chown, and Bernie Volz)
— RFC 7083 (Ralph Droms)
— RFC 7283 (Yong Cui, Qi Sun, and Ted Lemon)
— RFC 7550 (Ole Troan, Bernie Volz, and Marcin Siodelski)

Ряд дополнительных людей внесли свой вклад в выявление проблем с RFC 3315 и RFC 3633 и предложили решения по этим вопросам, отраженные в этом документе (перечислены здесь без особого порядка):

Оле Троан, Роберт Маркс, Лист Йех, Мишель Коттон, Пабло Армандо, Джон Бжозовский, Суреш Кришнан, Хидеши Енокихара, Александру Петреску, Юкио Акисада, Татуя Джинмей, Фред Темплин и Кристиан Хиитема.

Мы также благодарим следующее, а не какое-либо иное признание и не в каком-либо конкретном порядке, за замечания по их обзору:

Джереми Рид, Фрэнсис Дюпон, Лоренцо Колитти, Тяньсян Ли, Ян Фаррер, Йогендра Пал, Ким Киннер, Шон Ратье, Михайла Ньюкомб, Алисса Купер, Эллисон Манкин, Адам Роуч, Кайл Роуз, Элвин Дэвис, Эрик Рескорла, Бен Кэмпбелл, Уоррен Кумари , и Кэтлин Мориарти.

Кроме того, особая благодарность Ральфу Дромсу (Ralph Droms) за то, что он ответил на многие вопросы, связанные с оригинальной работой RFC 3315 и RFC 3633, и за то, что он взял этот документ через процесс IETF.

Авторы и адреса

Авторы RFC 8415
Авторы RFC 8415
Авторы RFC 8415
Авторы RFC 8415