В то время как для DHCPv4, по-видимому, существует только один вариант указания (S)NTP-серверов, а именно 42, DHCPv6, похоже, предлагает два отдельных варианта:
OPTION_SNTP_SERVERS(31) использует тот же формат конфигурации, что и DHCPv4, где указан список IP-адресовOPTION_NTP_SERVER(56) позволяет указать 3 различных подопции: IP-адрес, многоадресный IP-адрес или полное доменное имя.
В соответствии сRFC5908где OPTION_NTP_SERVERуказано:
Эта опция служит контейнером для информации о местоположении сервера, относящейся к одному серверу NTP или серверу Simple Network Time Protocol (SNTP). Эта опция может появляться несколько раз в сообщении DHCPv6. Каждый экземпляр этой опции должен рассматриваться клиентом NTP или SNTP как сервер для включения в его конфигурацию.
Это означает, что с OPTION_NTP_SERVERеще большим объемом информации о сетевом сервере времени может быть предоставлено по сравнению с OPTION_SNTP_SERVERS. Так почему же OPTION_SNTP_SERVERSсуществует рядом с ним?
решение1
После повторной проверки RFC 5908 в нем указано:раздел 7что RFC 4075 устарел ( ) и вместо него следует использовать OPTION_SNTP_SERVERSRFC 5908 ( ).OPTION_NTP_SERVER
Что касается причин, послуживших основанием для принятия решения, то предоставляется следующая информация:
[...] этот подход [RFC 4075] не подходит для всех развертываний NTP. Это не расширяемый механизм и вносит некоторую семантическую путаницу с помощью использования аббревиатуры "SNTP". Кроме того, подходпредоставление только адресов IPv6 для указания местоположения сервера не соответствует требованиям NTPкоторые также используют FQDN (полное доменное имя).
Подводя итог, можно сказать, что дополнительные подопции предоставляют больше различных способов указания местоположения сервера S(NTP), а старые OPTION_SNTP_SERVERSприводили к путанице относительно того, можно ли их также использовать для NTP.
Устаревание приводит к расхождению в способе указания серверов NTP для DHCPv4 и DHCPv6. В то время как DHCPv6 представил новый подход на основе подопций, DHCPv4 по-прежнему позволяет указывать только список IP-адресов, аналогичный RFC 4075 ( OPTION_SNTP_SERVERS).
решение2
Добро пожаловать в сообщество.
СогласноRFC4330 (Простой сетевой протокол времени (SNTP) версии 4 для IPv4, IPv6 и OSI)Страница 1
Простой сетевой протокол времени версии 4 (SNTPv4) ... является подмножеством сетевого протокола времени (NTP) ...
и
...может использоваться, когда максимальная производительность полной реализации NTP на основе RFC 1305 не нужна и не оправдана.
Это сопоставимая ситуация с TFTP и FTP. Использование более простых протоколов упрощает настройки, снижает накладные расходы и т. д. Отказ OPTION_SNTP_SERVERSот DHCPv6 будет означать, что решения, использующие IPv6, потребуют полной реализации NTP.
решение3
Это означает, что с OPTION_NTP_SERVER может быть предоставлено даже больше информации о сетевом сервере времени по сравнению с OPTION_SNTP_SERVERS. Так почему же OPTION_SNTP_SERVERS существует рядом с ним?
Опция SNTP_SERVERSбыл добавлен первым.Он не перестает существовать при добавлении новых опций — в лучшем случае он помечается как «устаревший», но реализации, которые поддерживали его раньше, скорее всего, продолжат его поддерживать.
OPTION_NTP_SERVER появился толькопять лет спустя, с целью расширения старой опции SNTP-only и примечания об ее устаревании:
- RFC 4075 Устаревание
«Вариант конфигурации простого сетевого протокола времени (SNTP) для DHCPv6» [RFC4075] обеспечивает некоторую степень автоматической конфигурации сервера времени для IPv6, поскольку он определяет, как передавать адреса сервера SNTP [RFC4330] через DHCPv6. Однако этот подход не подходит для всех развертываний NTP. Он не является расширяемым механизмом и вносит некоторую семантическую путаницу из-за использования аббревиатуры «SNTP». Кроме того, подход, при котором для указания местоположения сервера предлагаются только адреса IPv6, не соответствует требованиям NTP, которые также используют полное доменное имя (FQDN). По всем вышеупомянутым причинам этот документ делает [RFC4075] устаревшим.