Конфигурация маршрутизации через DHCPv6

В настоящее время протокол DHCPv6 не позволяет предоставлять хостам какую-либо информацию, связанную с маршрутизацией. Новое предложение направлено на устранение этого недостатка. Проект draft-ietf-mif-dhcpv6-route-option определяет механизм предоставления информации о маршрутизации по протоколу DHCPv6. В этой статье наша команда постаралась раскрыть основные понятия и объяснить, как использовать программное обеспечение ISC DHCP для доставки такой информации.

Немного истории

Когда было определено семейство протоколов IPv6, было решено, что необходим новый механизм обнаружения маршрутизаторов. Маршрутизаторы посылают сообщения Router Advertisement (RA), содержащие их адреса и список маршрутов, доступных через них. Они могут содержать дополнительную информацию, например, маршруты, доступные непосредственно на линии связи. Этот механизм является важной частью протокола Neighbor Discovery. В настоящее время это единственный разумный способ предоставления хостам информации о маршрутизации. Другие альтернативы обычно избегаются. Ручная настройка каждого узла в сети очень трудоемка, чревата ошибками и занимает много времени, а в случае изменения информации о маршрутизации ее приходится выполнять заново. Последним возможным способом доставки информации о маршрутизации на хосты было бы участие в динамической маршрутизации (например, RIP, OSPF или BGP), но это невыполнимо для хостов и проблематично на нескольких уровнях. Поэтому в настоящее время большинство хостов используют RA для настройки маршрутизации.

Определение проблемы

Подход на основе RA работает, но имеет несколько существенных недостатков:

Интересно: Стандарт нового поколения Wi-Fi 7 будет завершен в начале 2024 года

RA передаются всем хостам многоадресно. Не существует способа дифференцировать эту информацию для каждого хоста. Например, предположим, что одному из отделов корпоративной сети требуется доступ к определенной сети (например, инженерам-программистам необходимо подключиться к лаборатории). Другим примером может быть сеть доступа, в которой обычные пользователи используют один маршрутизатор, а премиум-пользователям разрешено использовать и второй маршрутизатор.
DHCPv6 требует RA для правильной работы. Протокол DHCPv6 назначает адреса, но не предоставляет никакой информации о маршрутах. Представьте себе разделенную сеть, в которой нет ни одного маршрутизатора. Сервер DHCPv6 назначает адреса узлу A и узлу B. Согласно RFC3315, A и B не могут пинговать друг друга, даже если им были назначены адреса с одним и тем же префиксом. У них нет информации о маршрутизации, поэтому они не знают, как связаться друг с другом.
У пользователей, имеющих опыт работы с IPv4 и DHCPv4, когда они начинают переход на IPv6, возникает один очень распространенный вопрос: «Как указать информацию о маршрутизации в DHCPv6?».
В мобильных сетях предполагается, что мобильный узел подключается к новой сети, затем ждет периодически объявляемых RA, после чего начинает DHCPv6, если это необходимо. Он также может запросить отправку RA немедленно, отправив сообщение Router Solicitation (RS), но это не всегда работает из-за ограничений, наложенных на маршрутизаторы в отношении максимального количества RA, отправленных за определенный период времени.

Решение

Чтобы решить эти проблемы, несколько инженеров, участвующих в работе Internet Engineering Task Force (IETF), взялись решить эту проблему. Draft-mif-dhcpv6-route-option определяет гибкий способ предоставления информации о маршрутизации через DHCPv6. Этот проект принят рабочей группой Multiple Interfaces (MIF) и в настоящее время проходит через Workgroup Last Call (WGLC), поэтому ожидается, что он будет одобрен и опубликован в ближайшее время. Предлагаемый подход решает все вышеупомянутые ограничения. В частности, он позволяет настраивать конфигурацию на основе каждого хоста. Он также позволяет настраивать маршрут по умолчанию и доступность локального маршрута на линии. В некотором смысле это делает DHCPv6 полноценным, поскольку для его работы больше не требуются RA.

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

Сервер DHCPv6 может сообщить хостам, что маршрут X/Y доступен через маршрутизатор Z. Время жизни такого маршрута и его метрика могут быть указаны.
Сервер DHCPv6 может сообщить хостам, что маршрут X/Y доступен локально, непосредственно на линии связи. Время жизни такого маршрута и его метрика могут быть указаны.
В сетях с ограниченной пропускной способностью сервер DHCPv6 может сообщить клиентам, что маршрут по умолчанию доступен через маршрутизатор X. Этот более короткий вариант не рекомендуется использовать, если нет значительных ограничений пропускной способности.

Реализация

ISC предоставляет несколько коммерческих решений с открытым исходным кодом, одним из ярких примеров которых является ISC DHCP. ISC DHCP – это реализация, которая поддерживает как DHCPv4, так и DHCPv6. Она также предлагает способ определения пользовательских опций, которые не поддерживаются напрямую. В следующих разделах объясняется, как настроить существующее программное обеспечение ISC DHCP для предоставления клиентам информации о маршрутизации. Инструкции были протестированы с использованием версии 4.2.3, но этот подход должен работать на всех поддерживаемых в настоящее время версиях семейства 4.*. Обратите внимание, что версии семейства 3.x не поддерживают DHCPv6 и не могут быть использованы для этой цели.

Конфигурация сервера

Следующий файл конфигурации можно использовать для указания серверу предоставлять информацию о маршрутизации клиентам.

Example server configuration for routing parameters
as defined in draft-ietf-mif-dhcpv6-route-option-03
This statement defines an option layout, not the values.
NEXT_HOP option with RTPREFIX option included 
option dhcp6.next-hop-rt-prefix code 242 = { ip6-address, unsigned integer 16, 
   unsigned integer 16, unsigned integer 32, unsigned integer 8, unsigned integer 8, ip6-address };
This statement configures actual values to be sent
RTPREFIX option code = 243, RTPREFIX length = 22 
lifetime = 9000 seconds 
route 2001:db8:2::/64 
metric 1 
option dhcp6.next-hop-rt-prefix 2001:db8:1::1 243 22 9000 64 1 2001:db8:2::;  
Simplified mode (NEXT_HOP only, without RTPREFIX) for 
bandwidth constrained networks. 
Make sure that only simplified or full mode are uncommented, not both.
Uncomment this if you want to send simplified default-route information 
#option dhcp6.next-hop code 242 = ip6-address; 
#option dhcp6.next-hop 2001:db8:1::1;  
Uncomment this if you want to provision information about routes 
available directly on-link.  
RTPREFIX option layout definition 
option dhcp6.rtprefix code 243 = {unsigned integer 32, unsigned integer 8, unsigned integer 8, ip6-address };  
RTPREFIX option values: 2001:db8:1:1234::/64 prefix
with lifetime 3600 available on-link, metric 1
option dhcp6.rtprefix 3600 64 1 2001:db8:1:1234::;  
This is the usual definition of subnet with range allocated
for dynamic assignment. 
subnet6 2001:db8:1:15c::/64 {     
    # Range for clients     
    range6 2001:db8:1:15c::1:0 2001:db8:1:15c::1:ffff;      
    # standard options     
    option dhcp6.name-servers 2001:db8:1::1;     
    option dhcp6.domain-search "example.com"; 
}

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

Интересно: Отслеживание сетевых подключений в Linux с помощью pktstat

Совет: Вы можете заменить 2001:db8:2::/64 на::/0, если хотите настроить маршрут по умолчанию с использованием полной нотации.

Совет: При выполнении этой конфигурации убедитесь, что вы используете флаг командной строки -6 (т. е. запускаете сервер в режиме DHCPv6, а не в стандартном режиме DHCPv4) и что на вашей машине, на которой запущен сервер, назначен адрес IPv6, принадлежащий подсети v6.

Конфигурация клиента

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

Conf file for dhclient6
script "/path/to/your/client-script.sh";
Uncomment this if you want to request only default route
#option dhcp6.option-next-hop code 242 = { ip6-address, encapsulate routing6 };
Use this definition to provision default or any other specific route
with addtional information (metric and lifetime).
NEXT_HOP option with RTPREFIX option included
option dhcp6.next-hop-rtprefix code 242 = { ip6-address,
   unsigned integer 16, unsigned integer 16,
   unsigned integer 32,
   unsigned integer 8, unsigned integer 8, ip6-address };
Simplified mode (NEXT_HOP only, without RTPREFIX)
Uncomment this if you want to send simplified default-route information
Make sure that only simplified or full mode are uncommented, not both.
#option dhcp6.next-hop code 242 = ip6-address ;
RTPREFIX option
option dhcp6.rtprefix code 243 = {unsigned integer 32,
   unsigned integer 8, unsigned integer 8, ip6-address };
This specifies list of options that client will request.
request dhcp6.name-servers, dhcp6.domain-search, dhcp6.rtprefix, dhcp6.next-hop-rtprefix;

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

new_dhcp6_next_hop_rtprefix='2001:db8:1::1 243 22 9000 64 1 2001:db8:2::'
new_dhcp6_rtprefix='3600 64 0 2001:db8:1:1234::'

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

Взаимозаменяемость

Рабочие проекты, которые еще не опубликованы как RFC, обычно не имеют заданных значений опций. В представленных примерах используются значения 242 для кодов опций NEXT_HOP и 243 для RTPREFIX. Как только IETF одобрит этот проект, IANA назначит фактические коды опций, которые почти гарантированно будут отличаться от тех, что используются в этом примере.

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

Представленный подход не является проприетарным и совместим с реализациями DHCP других производителей. Он был протестирован для работы с версией разработки Dibbler, реализации DHCPv6 с открытым исходным кодом.