BOOTP

Материал из Wiki.

BOOTP (Bootstrap Protocol) — это сетевой протокол, который, как и RARP, обеспечивает определение с помощью специального сервера IP-адреса клиента по его MAC-адресу (например, при загрузке устройства, не имеющего возможности хранить свой собственный IP-адрес), а также позволяет клиентам узнавать другие параметры загрузки (например, имя программы, загружаемой затем с помощью TFTP) и использует UDP вместо протокола канального уровня. Это позволяет использовать маршрутизаторы (bootp relay) для передачи запросов и ответов из одного сегмента локальной сети в другой. Протокол DHCP (Dynamic Host Configuration Protocol) является надстройкой над BOOTP (для совместимости с bootp relay) и позволяет серверу выделять IP-адреса клиентам динамически на ограниченный срок. Порт сервера — UDP/67 (BOOTPS), клиента — UDP/68 (BOOTPC). Клиент делает широковещательный (255.255.255.255 — всем в локальной сети, номера которой я не знаю) запрос bootrequest (один нефрагментированный пакет): обязательно содержит аппаратный MAC-адрес клиента и может содержать предполагаемый IP-адрес клиента, имя сервера и обобщённое имя файла для загрузки. Сервер отвечает пакетом bootreply (обычно unicast, так как MAC- и IP-адреса клиента ему известны): IP-адрес клиента, обобщённое имя файла замещается на полное имя файла исходя из конфигурации сервера, типа и адреса клиента и др. Собственно загрузка файла осуществляется клиентом с помощью протокола TFTP. Клиент должен быть в состоянии ответить на ARP запросы, чтобы мог работать TFTP-сервер.

Формат пакетов (в скобках упомянуты теги /etc/bootptab и /etc/dhcpd.conf):

• тип пакета: bootrequest или bootreply
• тип оборудования (ethernet 10 Mbit = 1, ht, hardware ethernet)
• длина MAC-адреса (6)
• число пройденных прокси, каждый прокси добавляет 1
• номер транзакции (0 или случайное число, позволяет клиенту отличить ответ на свой запрос от чужого)
• число секунд после первого bootrequest (позволяет запасному BOOTP серверу заметить неработоспособность основного)
• требование к серверу отвечать широковещательным пакетом
• IP-адрес клиента, предполагаемый самим клиентом (должен уметь отвечать на запросы ARP) или 0.0.0.0
• IP-адрес клиента, возвращаемый сервером (ip, fixed-address)
• IP-адрес следующего сервера (сюда же будет направлен TFTP запрос, sa, next-server)
• IP-адрес прокси (это не обязательно маршрутизатор!)
• MAC-адрес клиента (ha)
• имя сервера (64 байта)
• имя загрузочного файла (128 байт)
• дополнительная информация (vendor-specific или options, 64 байта для BOOTP, переменная длина для DHCP)

Формат дополнительной информации: первые 4 байта имеют значение 99.130.83.99, что позволяет определить её наличие (может быть использовано другое согласованное значение, определяющее собственный формат этого поля). Далее расположен список элементов (имена и тексты в кодировке NVT ASCII). Каждый элемент имеет однобайтовую этикетку, описывающую его тип. Типы 0 и 255 состоят только из этикетки (0 — заполнитель, 255 — конец данных). Остальные типы элементов вторым байтом имеют длину элемента (в скобках упомянуты теги /etc/bootptab и /etc/dhcpd.conf):

1.	маска подсети (sm, subnet-mask)
2.	смещение времени относительно UTC (в секундах)
3.	список IP адресов маршрутизаторов (первый — предпочтительный, gw, routers)
4.	список IP адресов серверов времени (RFC 868)
5.	список IP адресов серверов имён (IEN 116, не DNS!)
6.	список IP адресов DNS серверов
7.	список IP адресов серверов syslog (lg, log-servers)
8.	список IP адресов серверов "Quote of the Day" (RFC 865)
9.	список IP адресов серверов печати (LPR/LPD, RFC 1179)
10.	список IP адресов серверов Imagen Impress
11.	список IP адресов серверов поиска ресурсов (RFC 887)
12.	доменное имя хоста клиента, возможно только локальная часть (hn, host-name)
13.	число блоков в загрузочном файле (по 512 байт, до 64k, bs)
14.	имя файла для coredump
15.	имя домена клиента
16.	IP-адрес swap сервера
17.	путь монтирования диска root
18.	имя файла (берётся затем клиентом с помощью TFTP) с продолжением дополнительной информации
19.	должен ли клиент передавать пакеты с интерфейса на интерфейс, то есть работать маршрутизатором (forwarding)
20.	разрешать ли source routing IP-пакетов
21.	фильтры для source routing
22.	максимальный размер датаграммы для сборки клиентом (не менее 576)
23.	TTL для исходящих от клиента датаграмм
24.	время ожидания для алгоритма автораскрытия MTU (RFC 1191)
25.	таблица значений MTU для алгоритма автораскрытия MTU (RFC 1191)
26.	MTU интерфейса (не менее 68)
27.	все ли прямо подключённые подсети имеют одинаковый MTU
28.	широковещательный IP-адрес локальной подсети
29.	использовать ли ICMP для автораскрытия маски подсети
30.	отвечать ли на ICMP запросы автораскрытия маски подсети
31.	использовать ли механизм поиска маршрутизаторов (RFC 1256)
32.	IP-адрес сервера механизма поиска маршрутизаторов
33.	список статических маршрутов в виде списка пар: сеть (нельзя задавать 0.0.0.0), адрес маршрутизатора (а маска?)
34.	использовать ли "хвосты" в канальных кадрах (RFC 893)
35.	время жизни элементов ARP кеша (секунд)
36.	версия Ethernet: version 2 (RFC 894) или IEEE 802.3 (RFC 1042)
37.	TTL для исходящих от клиента TCP пакетов
38.	TCP keepalive interval
39.	TCP keepalive garbage option
40.	имя домена NIS
41.	список IP-адресов серверов NIS
42.	список IP-адресов серверов NTP
43.	информация в формате изготовителя оборудования
44.	список адресов серверов имён NetBIOS over TCP/IP (RFC 1001, RFC 1002)
45.	список адресов серверов NBDD NetBIOS over TCP/IP (RFC 1001, RFC 1002)
46.	тип узла NetBIOS over TCP/IP (RFC 1001, RFC 1002)
47.	область NetBIOS over TCP/IP (RFC 1001, RFC 1002)
48.	список IP-адресов серверов шрифтов X Window System
49.	список IP-адресов менеджеров дисплея (xdm) X Window System
50.	требуемый клиенту IP адрес (DHCPDISCOVER)
51.	запрашиваемое (DHCPDISCOVER, DHCPREQUEST) или предоставленное (DHCPOFFER) время аренды IP адреса (в секундах относительно момента запроса)
52.	использовать ли поля имени сервера и имени загрузочного файла для передачи дополнительных опций (DHCP)
53.	тип сообщения DHCP (DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPDECLINE, DHCPACK, DHCPNAK, DHCPRELEASE, DHCPINFORM)
54.	идентификатор сервера DHCP (IP-адрес), указывается сервером в DHCPOFFER, чтобы клиент мог различить предложения от различных серверов (возможно также указание в DHCPACK и DHCPNAK); указывается клиентом в DHCPREQUEST, чтобы показать, какое предложение он принял
55.	список кодов опций, значения которых клиент хочет узнать от сервера
56.	текст сообщения об ошибке (DHCPNAK, DHCPDECLINE)
57.	максимальный размер сообщения DHCP, которое клиент готов принять (DHCPDISCOVER, DHCPREQUEST)
58.	T1 - интервал времени (в секундах), через который клиент DHCP должен перейти в режим запроса подтверждения на право владения IP-адресом (RENEWING), по умолчанию - 0.5 от срока аренды
59.	T2 - интервал времени (в секундах), через который клиент DHCP должен перейти в режим получения нового IP-адреса (REBINDING), по умолчанию - 0.875 от срока аренды
60.	используется DHCP клиентом для указания варианта конфигурации (vendor class), сервер возвращает информацию только в формате изготовителя оборудования
61.	уникальный в подсети идентификатор клиента DHCP (например, MAC-адрес или полное доменное имя), в протоколе BOOTP для идентификации клиента использовался его MAC-адрес
64.	имя домена NIS+
65.	список IP-адресов серверов NIS+
66.	имя TFTP сервера, если поле имени сервера использовано под дополнительные опции (DHCP)
67.	имя загрузочного файла, если поле имени загрузочного файла использовано под дополнительные опции (DHCP)
68.	список IP-адресов Mobile IP Home Agent
69.	список IP-адресов серверов SMTP
70.	список IP-адресов серверов POP3
71.	список IP-адресов серверов NNTP
72.	список IP-адресов серверов WWW (HTTP ?)
73.	список IP-адресов серверов finger
74.	список IP-адресов серверов IRC
75.	список IP-адресов серверов StreetTalk
76.	список IP-адресов серверов StreetTalk Directory Assistance
128 – 254	зарезервированы для локального использования (Tномер, option option-номер)

Средств обеспечения безопасности нет, в ответ клиент может получить фальшивый пакет. Поэтому на периферии сети порты UDP/67 и UDP/68 должны быть заблокированы сетевым экраном, а на сервере BOOTP должны быть проделаны дырки в ipchains (привожу формат /etc/sysconfig/ipchains):

-A input -s 0.0.0.0/0.0.0.0 68:68 -d 0.0.0.0/0.0.0.0 67:67 -p udp -j ACCEPT

Аналогичные дырки надо проделать для исходящих пакетов сервера и пакетов, пересылаемых DHCP прокси.

Если в ядре включена фильтрация поддельных IP-адресов (martian address filtering), то её придётся отключить (по крайней мере для адресов 0.0.0.0 и 255.255.255.255).

Экран можно усилить, заменив «универсальные» 0.0.0.0/0.0.0.0 на адреса ваших клиентов/сервера, но учитывайте, что исходящими IP-адресами клиентов могут быть также 0.0.0.0, а входным — 255.255.255.255.

Дополнительно(RFC): BOOTSTRAP PROTOCOL (BOOTP) (RFC 951) Interoperation Between DHCP and BOOTP (RFC 1534) Clarifications and Extensions for BOOTP (RFC 1542) DHCP Options and BOOTP Vendor Extensions (RFC 2132)