08.07.2011

RFC5887 Renumbering Still Needs Work
(снова про замену адресов, конспект)

1. Введение.
Иногда замена адресов неизбежна. Вот такие ситуации:

  • замена провайдера или подключение к еще одному провайдеру
  • сам провайдер меняет свои адреса
  • обьединение двух сетей в одну или разделение сети на две или более
  • переход на IPv6

У IP-адреса нет такого встроенного параметра, как «время жизни». Даже, если адрес выдается DHCP-сервером на ограниченное время, или он берется из DNS-записи с установленным TTL, эта информация недоступна программам-приложениям после передачи адреса приложениям на верхние уровни модели OSI. По этой причине поведение приложений при замене адресов непредсказуемо.

2. Существующие хост-ориентированные механизмы замены адресов.
2.1. DHCP
Возможности по замене адресов при использовании DHCP-сервера практически одинаковы и для IPv4 и для IPv6. В принципе, при использовании DHCP, для замены адресов достаточно внести изменения в конфигурационные файлы DHCP сервера, а по истечению времени аренды все произойдет автоматически.
2.2. IPv6 SLAAC
Базируется на RA-пакетах от роутера. Для RA задается два таймера: предпочитаемый (preferred) и действительный (valid). Роутеров может быть несколько, и каждый может анонсировать несколько префиксов. По истечению первого таймера адрес не может использоваться для установления новых сессий, а по истечению второго хост должен прекратить использование адреса. Эти таймеры могут использоваться как индикаторы для хоста, что адрес будет изменен. После получения нового адреса он будет использоваться для новых сессий, параллельно со старым в незавершенных сессиях.
2.3. IPv6 ND Router/Prefix Advertisements
RA не только сообщает о наличии роутера, но и сообщает об известных ему префиксах на линке. Также в RA есть флаг, сообщающий о необходимости использования DHCP-сервера хостом (в этом случае хост не будет проводить автоконфигурирование). В сетях, где есть более одного роутера, а адреса назначаются через DHCP, желательно иметь возможность динамически получать адрес предпочитаемого роутера, но в настоящее время это не реализовано. В IPv6 DHCP нет информации о роутерах-шлюзах.
2.4. РРР
Предусмотрен механизм замены адреса при обновлении состояния линка.
2.5. Внесение изменений в DNS
Можно обновлять файлы зон вручную (даже заранее), а после их перезагрузки обновления начнут распространяться. Или можно использовать динамический DNS.
2.6. Dynamic Service Discovery
SLP — Service Location Protocol — может применяться для обнаружения сервисов, например сетевых печатающих устройств.
Multicast DNS (mDNS) и DNS Service Discovery уже широко используются в BSD, Linux, Mac OS X, UNIX, и Windows. Использование SRV-записей [RFC3958] может стать важным инструментом в уменьшении зависимости от сконфигурированного адреса.

3. Существующие механизмы для роутеров.
3.1. Замена адресов у роутеров.
Можно использовать DHCP, хотя он ориентирован на клиентов. Можно использовать делегирование префикса RFC4192.

4. Существующие многоадресные механизмы для IPv6.
IPv6 был разработан для поддержки нескольких адресов на одном интерфейсе и нескольких префиксов в сегменте [RFC4192], это позволяет добавлять новые префиксы к старым и проводить шаговую замену адресации.
Поскольку хосты в пределах одной подсети могут использовать для связи link-local адреса, то это делает их нечувствительными к замене глобальных адресов при обмене пакетами внутри сайта.

5. Проблемы с заменой адресов.
Делятся на две категории:

  • проблемы с хостом при замене адресов
  • проблемы с прикладными программами при замене адресов

5.1. Проблемы с хостами
5.1.1. Проблемы сетевого уровня.
Сигнал FORCERENEW описан в DHCP для IPv4 [RFC3203].
Он может использоваться как команда для обнвления данных от сервера. В DHCPv6 есть подобный сигнал — RECONFIGURE, который может быть отправлен каждому хосту для обновления конфигурационных данных. О широком использовании этих сигналов неизвестно.
В случае, если DHCP использует привязку ip-mac, то можно внести изменения в конфигурацию при помощи какого-нибудь скрипта сразу для всех хостов, если привязки нет, то вносятся изменения в общую конфигурацию пулов.
Также можно попасть в ситуацию, когда в одном сетевом сегменте используется SLAAC для одного префикса (или одного интерфейса) а DHCPv6 для другого, что вызывает риск непредсказуемого поведения такого хоста.
Существует ряд устройств, у которых адреса хранятся в ROM или задаются DIP-переключателями. Такие устройства создают проблемы при замене адресов.
5.1.2. Проблемы транспортного уровня.
IP-адрес входит в контрольную сумму tcp/udp заголовка, так что сменить его «налету», то есть во время сесии (flow) не получится.
5.1.3. Проблемы с DNS
Временная установка уменьшенного значения TTL минимизирует негативные последствия при замене адресов. Также следует помнить, что не только в прямые, но и в реверсные зоны тоже нужно вносить изменения. Если организация использует DNS провайдера для поддержки своих зон, то следует своевременно сообщить ему о необходимости внести изменения в файлы зон.
5.1.4. Проблемы прикладного уровня.
Идеальным было бы проанализировать работу всех сетевых приложений. Работоспособность многих зависит от того, как в них хранится IP-адрес. Если он (точнее — FQDN) хранится в конфигурационном файле, то преобразование FQDN-IP делается только один раз при запуске приложения. У некоторых приложений система лицензирования (защиты) может быть «привязана» к IP-адресу.

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

5.3. Другие проблемы.
5.3.1. Проблемы с NAT
При замене адресов все соответствующие записи в таблице трансляции станут недействительными.
5.3.2. Mobile IP.
Особых проблем не отмечено.
5.3.3. Multicast.
В случае с ASM (Any-Source Multicast) проблем быть не должно. В случае Source-Specific Multicast (SSM) при изменении адреса источника будут проблемы — приложения должны узнать новый адрес, и топология должна быть перестроена.
5.3.4. Проблемы с обслуживанием
У многих устройств адреса для управления прописаны статически в конфигурационных файлах, а также эти адреса могут быть «связаны» с адресами других устройств, например VPN-концентраторов (для решения этой проблемы рекомендуется использовать FQDN). Некоторые конфигурационные файлы, в которых используются адреса, легко найти (например, наборы правил файерволов), другие дадут знать о себе сами, когда после внесения изменений у соседей, устройство перестанет работать.
5.3.5. Проблемы с безопасностью.
Во время замены адресов сеть становится чувствительной к их подмене или самовольному использованию, но пока нет доступных средств для предотвращения такой угрозы.
Нужно будет переписать адреса в правилах фильтрации в файерволах, системах обнаружения вторжений и проч. Поскольку необходимо организовать непрерывное функционирование сети, то такие работы следует разделить на два этапа: непосредственно перед заменой адресов и непосредственно после замены адресов. PKI сертификаты «привязаны» к адресу, после замены адресов они перестанут работать.

6. Предлагаемые решения.
6.1. SHIM6.
Предусматривает механизм динамической замены адресов у хоста с несколькими интерфейсами.
6.2. MANET Proposals
Описан механизм, позволяющий мобильным роутерам динамически обнаруживать пограничные маршрутизаторы и доводить эту информацию до хостов.
6.3. Другие предложения IETF.
Расширения DHCP могут сообщать адреса альтернативных роутеров. Другие опции могут информировать клиентов о дополнительных адресах и префиксах, доступных в сети.
6.4. Другие предложения.
Есть предложения включить в IP-адрес время жизни этого адреса.

7. Пробелы, недостатки.
7.1. Хосты.
Приложения не имеют информации о времени жизни (действительности) IP-адреса. Использование FQDN может помочь в решении этой проблемы. Для приложений, работающих с адресами, можно использовать известный файл /etc/hosts.
7.2. Роутеры.
Кое-какие временные меры, которые описаны в [RFC2894] и в [RFC3633], могут быть использованы на практике.
7.3. Работа.
Поскольку замена адресов часто проходит через DNS, то его безопасности придается важное значение. Рекомендуется документировать все шаги.
7.4. Другие пробелы.
Нужен безопасный механизм анонсирования префикса другим сайтам.

8. Безопасность.
8.1. Нет механизма, позволяющего проверить, что один и тот же префикс «принят» всеми узлами в сегменте.
———————————————-

Фактически снова перечислены очевидные вещи..


  *** Via IPv4 ***