♦ 224.0.0.5 — все OSPF-маршрутизаторы локальной сети;
♦ 224.0.0.251 — все DNS-серверы локальной сети.
В других случаях члены группы могут располагаться в разных сетях. Тогда протокол маршрутизации необходим. Но для начала маршрутизаторы, передающие многоадресные сообщения, должны знать, какие хосты являются членами группы. Процесс может попросить свой хост присоединиться к какой-либо группе или покинуть группу. Каждый хост следит за тем, членами каких групп являются его процессы в текущий момент. Когда последний процесс хоста покидает группу, хост больше не является членом этой группы. Примерно раз в минуту каждый многоадресный маршрутизатор совершает аппаратную (то есть на уровне передачи данных) многоадресную рассылку хостам на своей локальной сети (по адресу 224.0.0.1) с просьбой сообщить о группах, к которым в данный момент принадлежат их процессы. Многоадресные маршрутизаторы не обязательно должны находиться там же, где обычные маршрутизаторы. Каждый хост посылает обратно ответы для всех интересующих его адресов класса D. Эти пакеты запросов и ответов используются протоколом IGMP (Internet Group Management Protocol — протокол управления группами в Интернете). Он описан в RFC 3376.
Для построения связующего дерева, позволяющего получить пути от отправителей до всех членов группы, используются различные протоколы многоадресной маршрутизации. О соответствующих алгоритмах мы уже говорили в разделе 5.2.8. Внутри автономной системы чаще всего используется протокольно-независимая многоадресная рассылка (PIM, Protocol Independent Multicast). Существует несколько вариантов PIM. При PIM в плотном режиме (Dense Mode PIM) создается усеченное дерево, построенное методом продвижения по встречному пути. Такой вариант подходит в ситуациях, когда члены группы находятся во всех частях сети — например, при распространении файлов на множественные серверы. При PIM в разреженном режиме (Sparse Mode PIM) создаются связующие деревья, похожие на деревья с основанием в ядре. Такой вариант может использоваться, к примеру, когда поставщик контента транслирует ТВ-сигнал абонентам своей IP-сети. Вариант этой схемы под названием Source-Specific Multicast PIM работает лучше в ситуациях с одним источником. Наконец, если члены группы находятся в нескольких АС, для создания многоадресных маршрутов необходимо использовать специальные расширения BGP или туннелирование.
5.6.9. Мобильный IP
Многие пользователи Интернета обладают портативными компьютерами и заинтересованы в возможности оставаться в подключенном к сети состоянии, даже находясь в пути. К сожалению, система адресации IP такова, что реализовать это оказывается гораздо сложнее, чем кажется (вскоре мы поговорим об этом подробнее). Когда потребность в мобильных хостах значительно возросла, проблемная группа проектирования Интернета (IETF, Internet Engineering Task Force) создала рабочую группу для поиска решения проблемы. Созданная рабочая группа быстро сформулировала набор целей, которых хотелось бы достичь, независимо от способа решения. Основными целями были признаны следующие.
1. Каждый мобильный хост должен иметь возможность использовать свой домашний IP-адрес где угодно.
2. Изменения программного обеспечения фиксированных хостов недопустимы.
3. Изменения программного обеспечения и таблиц маршрутизаторов недопустимы.
4. Большая часть пакетов, направляемых мобильным хостам, должны доставляться напрямую.
5. Не должно быть никаких дополнительных расходов, когда мобильный хост находится дома.
Рабочая группа выработала решение, описанное в разделе 5.2.10. Суть его, напомним, заключалась в том, что везде, где требуется предоставить возможность перемещения в пространстве, следует создать внутреннего агента (home agent). Когда мобильный хост прибывает на новое место, он получает новый IP-адрес (также называемый адресом для передачи). После этого мобильный хост сообщает внутреннему агенту о своем местоположении с помощью адреса для передачи. Если в момент прибытия пакета, предназначенного этому хосту, в домашнюю сеть хост находится в другом месте, внешний агент туннелирует этот пакет на хост, используя адрес для передачи. Мобильный хост может посылать ответные пакеты, но при этом адресом отправителя будет домашний адрес. Это решение удовлетворяет всем перечисленным выше требованиям за исключением рециркулирующих пакетов мобильных хостов.
Чтобы получить адрес для передачи в новой сети, мобильный хост может использовать DHCP. Или же, если IP-адресов не хватает, этот хост может отправлять и получать пакеты через внешнего агента, у которого уже есть IP-адрес в этой сети. Чтобы найти внешнего агента, хост использует тот же ICMP-механизм, что и при поиске внутреннего агента. После того как хост получил IP-адрес или нашел внешнего агента, он может по сети сообщить внутреннему агенту о своем текущем местоположении.
Внутренний агент должен перехватывать пакеты, предназначенные для мобильного хоста, только при отсутствии этого хоста в домашней сети. Сделать это можно с помощью ARP. Чтобы отправить пакет на IP-хост по сети Ethernet, маршрутизатор должен знать Ethernet-адрес хоста. Обычно маршрутизатор отправляет ARP-сообщение, в котором спрашивает что-то вроде «какой Ethernet-адрес у 160.80.40.20?» Если мобильный хост находится в домашней сети, он отвечает на запрос, содержащий его IP-адрес, сообщением со своим Ethernet-адресом. Если он находится в другом месте, на этот запрос отвечает внутренний агент, сообщая свой Ethernet-адрес. В результате маршрутизатор отправляет пакеты для 160.80.40.20 домашнему агенту. Как вы, возможно, помните, это называется ARP-прокси.
Чтобы быстро обновлять таблицы отображения адресов при перемещении хоста туда и обратно, используется другой метод, называемый добровольным ARP-сообщением (gratuitous ARP). Суть в том, что мобильный хост или внутренний агент отправляет самому себе ARP-запрос для мобильного IP-адреса, который заставляет маршрутизатор заменить в своей таблице запись о хосте.
При туннелировании пакета от внутреннего агента к мобильному хосту к пакету добавляется IP-заголовок с адресом для передачи. Когда пакет пребывает на этот адрес, внешний IP-заголовок удаляется.
Как и в случае со многими интернет-протоколами, дьявол кроется в деталях, и особенно в тех мелочах, которые касаются совместимости с другими протоколами. Здесь есть две сложности. Во-первых, NAT-блоку необходим доступ к TCP-и UDP-заголовкам, расположенным после IP-заголовка. Изначальный вариант туннелирования для мобильных IP не использовал эти заголовки и поэтому не работал с NAT-блоками. Позже было принято решение изменить способ добавления заголовков, включив UDP-заголовок.
Вторая сложность состоит в том, что некоторые провайдеры проверяют, соответствует ли IP-адрес источника тому расположению, где, по мнению протокола маршрутизации, источник должен находиться. Этот процесс называется фильтрацией на входе (ingress filtering) и является мерой безопасности, позволяющей отвергать трафик, поступивший с сомнительного адреса, так как он может представлять угрозу. Однако если мобильный хост находится не в домашней сети, его пакеты будут приходить с IP-адреса другой сети и поэтому, скорее всего, будут отвергнуты. Чтобы обойти эту проблему, мобильный хост может туннелировать пакеты внутреннему агенту с помощью адреса для передачи. Пакеты, отправленные отсюда, не будут казаться подозрительными. Минус такой схемы в том, что такой путь является далеко не прямым.
Еще одним вопросом является безопасность. Когда внутренний агент получает просьбу пересылать все пакеты, приходящие на имя Натальи, на некий IP-адрес, он не должен подчиняться, пока не убедится, что источником этого запроса является Наталья, а не кто-то пытающийся выдать себя за Наталью. Для этого применяются протоколы криптографической аутентификации, которые будут рассматриваться в главе 8.
