Роберт Ричардсон

Mobile IP обещает сквозное непрерывное соединение через сетии среды. Но кому он может понадобиться на практике?

Если вы и пользовались IP, находясь в пути, то, скорее всего, это был вовсе и не Mobile IP. Я так уверен в этом, потому что Mobile IP принадлежит к числу тех документов IETF, которые, как вино в бочках, 'настаиваются' долгие годы. Этот же конкретный RFC дозревает на Web-сервере IETF вот уже три года. Однако интерес к стандарту нарастает, и производители стали включать технологию в свои продукты. Сейчас, как представляется, самое время подробнее познакомиться со стандартом, областью его применения, причинами внезапного пробуждения интереса к нему со стороны производителей и его значением для мобильных пользователей.

Но вначале давайте определимся с тем, что мы будем понимать под словом 'мобильный'.

Когда командированный поселяется в гостинице и использует модем своего портативного компьютера для звонка провайдеру Internet, такой пользователь не является мобильным. Да, он со своим ноутбуком может скитаться по миру как призрак Элвиса, но его соединение с Internet постоянно прерывается. Каждый раз, когда соединение восстанавливается (по крайней мере в типичной конфигурации), клиент получает новый, временный IP-адрес с помощью DHCP. Для такого рода использования лучше всего подходит определение 'кочевой'.

Чтобы быть действительно мобильным, узел должен иметь согласованный адрес, которым путешественник может пользоваться везде, где бы он ни оказался. Кроме того, текущий сеанс не должен прерываться, если ноутбук перемещается из сети одного провайдера в сеть другого провайдера Internet. Смена одной подсети на другую должна быть прозрачна не только в верхней части сетевого стека, но также и с точки зрения нижележащей среды передачи: если пользователь отсоединяется от сети Ethernet, а ноутбук имеет адаптер CDPD, то ноутбук - если он действительно мобильный - должен переключиться на беспроводной доступ и завершить доставку страницы Web, элементы которой были еще не полностью скопированы, когда пользователь вытащил вилку RJ-45 из гнезда.

Конечно, для большинства задач, для которых люди сегодня используют портативные компьютеры, подобные возможности выглядят как стрельба из пушки по воробьям. Как говорит Марк Денни, менеджер по продуктам IP в подразделении Internetwork Operation System (IOS) компании Cisco Systems, 'администраторы ИТ могут сколько угодно мечтать о том, как это было бы круто, если бы ноутбук не требовалось перезагружать при его подключении к локальной сети конференц-зала, но одного этого недостаточно для экономического обоснования целесообразности применения технологии'.

Кроме того, когда требуется всего лишь проверить почту, вряд ли кто-нибудь будет активно недоволен возможностями обычного кочующего пользователя, особенно если он поселится в приличном отеле. Какое вам дело до того, что при соединении с провайдером Internet по запросу DHCP ноутбук каждый раз получает иной IP-адрес, покуда вы можете получить свою почту?

В результате распространение Mobile IP идет чрезвычайно медленными темпами, так как DHCP оказывается вполне достаточно для многих временных приложений. Между тем эта технология вполне может пользоваться спросом как в вышеописанной ситуации с 'перетыканием вилок', в особенности в корпоративной территориальной сети. Применение Mobile IP в такой среде, где имеется множество подсетей и пользователям приходится часто переходить из одной в другую, вполне оправданно. Сказанное, однако, не означает, что стандарт не будет применяться для переключения между сетями провайдеров Internet.

Денни также указывает, что в другой важной области, при беспроводном использовании, стимулов для решения тех задач, на которые Mobile IP рассчитан, имеется гораздо больше.

БАЗОВЫЙ MOBILE IP

Общая схема Mobile IP чрезвычайно проста: пользователь может взять сетевой узел с определенным IP-адресом, отсоединить его от текущей подсети, перенести в другое место, подключить к другой подсети и продолжать работать, не меняя своего первоначального IP-адреса.

На концептуальном уровне понимание Mobile IP не вызывает трудностей. С практической же точки зрения его реализация выглядит невозможной, особенно с учетом того, как работает маршрутизация IP. При доставке адресату пакет передается от одного маршрутизатора к следующему, причем каждый маршрутизатор просматривает сетевой префикс IP-адреса для определения того, куда пакет следует направить далее. Информация о том, какие пакеты для каких сетей должны быть направлены по каким соединениям, хранится в таблице маршрутизатора - здесь-то и кроется проблема. Таблицы маршрутизаторов становятся столь велики по размерам, что старому оборудованию не хватает памяти, чтобы справляться со стоящими перед ним задачами.

Проблема с таблицами маршрутизаторов показывает, что Mobile IP нельзя реализовать просто посредством добавления определенных записей для каждого мобильного узла и их модификации на лету. При перемещении узла (в чем весь смысл Mobile IP!) записи необходимо будет изменить не только на маршрутизаторах вдоль пути, по которому пакеты проходили до того, но и на маршрутизаторах вдоль пути, по которому они будет проходить теперь.

В мире маршрутизации на основании сетевого префикса при передаче пакета маршрутизатору, непосредственно отвечающему за соответствующую подсеть, пакет не только не будет передаваться дальше, но и будет доставляться только в данную локальную сеть. Вместе с тем если целевой узел перемещается в подсеть с иным префиксом, то доставленный в 'подсеть приписки' пакет не попадет по назначению, т. е. перемещенный узел, располагающийся теперь в другой подсети, никогда не получит предназначенного ему пакета. Именно этот разрыв в связи и призван ликвидировать Mobile IP.

Предлагаемый подход очень прост. Агент в 'подсети приписки' перехватывает предназначенные отсутствующему мобильному узлу пакеты и переадресует их агенту-получателю в подсети, где мобильный узел находится в данный момент. Агент-получатель выгружает переадресованные пакеты и передает их мобильному узлу, а тот воспринимает их так же, как если бы они были доставлены по старому IP-адресу (см. Рисунок 1).

Рисунок 1. Вместо того чтобы следовать по кратчайшему пути между узлами, адресованные мобильному узлу пакеты вынуждены делать крюк через вводимых Mobile IP агентов переадресации. Отправляемые в ответ с мобильного узла пакеты маршрутизируются напрямую (при

При последующем перемещении узла переадресующий агент будет модифицировать адрес получателя; тем временем прежний получатель должен быть готов переадресовать любые пакеты, находившиеся в пути в момент, когда порядок переадресации был изменен.

КТО ВАШ АГЕНТ?

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

Вся черновая работа по регистрации выполняется не самим клиентом, а двумя его агентами: домашним агентом в подсети приписки мобильного узла (т. е. в сети с соответствующим IP-префиксом узла) и внешним агентом, обеспечивающим маршрутизацию по каналу, на котором мобильный узел находится в настоящее время.

Хотя вся схема выглядит вполне надежно (домашний агент пересылает пакеты внешнему агенту, а тот в свою очередь передает их мобильному узлу), это описание с максимально возможной степенью обобщения оставляет без внимания несколько важнейших вопросов. Прежде всего, это процедура обнаружения агента: как мобильный узел узнает, что он отправился в дорогу? В конце концов, мобильный узел может в течение какого-то времени находится в своей родной сети, и тогда Mobile IP ему просто не нужен.

Узел может определить, где он находится, по крайней мере двумя способами. Во-первых, он может просматривать трафик в поисках пакетов с рекламой внешнего агента. Эти периодически посылаемые в сеть пакеты идентичны объявлениям маршрутизатора по протоколу контрольных сообщений (Internet Control Message Protocol, ICMP), но имеют иной номер типа. Ввиду того, что внешний агент может находиться и в сети приписки узла (для обслуживания визитеров из других подсетей), получение объявления внешнего агента само по себе не означает, что узел находится в дороге. Поэтому мобильный узел просматривает сетевой префикс пакета на предмет его совпадения с префиксом своего собственного IP-адреса. Если префиксы не совпадают, то узел четко знает, что он находится на чужой территории.

Конечно, внешний агент имеется далеко не в каждой чужой сети. В этом случае мобильному узлу придется использовать любые доступные традиционные средства - DHCP или ручную конфигурацию - для получения действительного IP-адреса в локальной сети, после чего данный адрес будет передан им домашнему агенту в качестве транзитного.

Это ставит другой вопрос: как мобильный узел узнает IP-адрес своего домашнего агента? Ответ оказывается тривиален: в большинстве реализаций адрес домашнего агента задается на мобильном клиенте вручную точно так же, как адрес маршрутизаторов DNS на стационарных узлах.

Однако мобильный узел способен определить адрес домашнего агента и динамическим образом. Для этого клиент выделяет сетевой префикс своего адреса и затем отправляет многоадресный запрос о регистрации в домашний сегмент. Запрос может быть принят или отвергнут любым домашним агентом посылкой специального ответного кода. Отказы используются мобильным узлом для определения действительных адресов домашних агентов.

ТУННЕЛИРОВАНИЕ

При получении запроса о переадресации домашний агент проверяет запрос с помощью идентификационного расширения с использованием любого предварительного согласованного между мобильным узлом и домашним агентом алгоритма. (В качестве общего знаменателя все реализации должны обязательно поддерживать протокол идентификации Keyed MD5, описанный в RFC 1321.)

В случае успешной регистрации домашний агент извлекает префикс или транзитный адрес и затем рассылает локальным маршрутизаторам объявления протокола разрешения адреса (Address Resolution Protocol, ARP) о том, что он берет на себя функции посредника, и все пакеты с IP-адресом мобильного агента следует посылать на его собственный MAC-адрес.

При поступлении адресованных мобильному узлу пакетов домашний агент помещает (инкапсулирует) их в свои собственные пакеты IP (см. Рисунок 2).

Рисунок 2. Благодаря использованию туннелирования IP в IP, Mobile IP маршрутизирует переадресуемые пакеты к новому местонахождению пользователя без изменения первоначального адреса пакетов. Несмотря на принципиальную возможность туннелирования отличных от

Внутренний пакет представляет собой первоначальный, неизмененный пакет, а внешний адресован на транзитный адрес и передается с помощью обычных механизмов маршрутизации Internet.

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

ПО ВОЗДУХУ

Несмотря на то что RFC 2002 был опубликован еще в 1996 году, не будет ошибкой утверждение, что технология все еще находится на ранних стадиях своего развития. Cisco, самый известный из производителей сетевого оборудования, взявших Mobile IP на вооружение, выпускает RFC 2002-совместимое оборудование с 1998 года. Но до сих пор большинство реализаций RFC 2002 было нацелено на беспроводные, а отнюдь не на территориальные сети.

Беспроводной мир можно в первом приближении поделить на сети на базе стандарта Ethernet 802.11 и передачу пакетных данных по сотовым сетям. С точки зрения управления ИТ беспроводные сети во многом аналогичны своим проводным предшественникам. Но мир сотовых телефонов, где доминируют компании и организации, более тесно связанные с телефонией, чем с Internet и ее организациями по стандартизации, представляет собой совсем иную статью. Здесь протоколы решают проблемы, о которых обычные администраторы ИТ имеют лишь смутное представление, например, как осуществлять арбитраж между передатчиками ячеек, когда из-за неблагоприятных погодных условий узел сотовой сети (т. е. телефон) вынужден переключаться между соседними сотами, даже если он используется стационарно.

Говоря другими словами, когда дело касается передачи пакетных данных из Internet на перемещающийся мобильный узел, вовсе не обязательно, что этот процесс находится под контролем IETF. Однако при всей кажущейся хаотичности Internet, по сравнению с миром телефонии, процедура принятия RFC выглядит четко организованной и чрезвычайно эффективной. Одна из причин этого состоит в том, что в мире телефонии имеется несколько организаций по стандартизации. К счастью, как правило, эти группы берут на вооружение стандарты IETF, если они оказываются более-менее применимы, как тот же Mobile IP - несмотря даже на то, что решения в области роуминга используются в сотовых системах вот уже многие годы.

Исторически роуминг поддерживался на канальном уровне, так что, после того как данные IP вставлялись в передачу CDPD, на уровне IP о происходящем на уровень ниже перемещении ячеек ничего не было известно. Благодаря этому узел мог сохранять свой IP-адрес, где бы в системе он ни находился.

Но, несмотря на историю и унаследованное оборудование, отказ от принятия решения на канальном уровне имеет по крайней мере несколько преимуществ. Возможно, наиболее сильный аргумент в пользу решения на сеансовом уровне состоит в возможности разрыва соединения через одну среду (скажем, с помощью беспроводной связи) и установления его через другого оператора с использованием иной среды передачи (скажем, соединения 10BaseT в кабинке аэропорта) без прерывания открытых сеансов. При таком подходе ноутбук может выбрать наиболее быстрое или экономичное соединение и переключаться на него по ходу дела так, что приложения даже не узнают об этом.

Кроме того, имеющиеся решения канального уровня не в состоянии предоставить все то, что хотели бы получить сотовые провайдеры. Именно поэтому некоторые из них уже взяли на вооружение Mobile IP для целей роуминга. Интегральная цифровая усовершенствованная сеть (integrated Digital Enhanced Network, iDEN) компании Motorola является на сегодняшний день самой развитой Mobile IP-совместимой системой.

В то же время, заботясь о своем будущем, отрасль сотовой связи намеревается обеспечить межсистемную мобильность, что возможно только при принятии стандартов Internet. Для этой цели в соответствии с планами ITU комплекс технологий глобальных беспроводных сетей следующего поколения под общим названием International Mobile Telecommunications (IMT-2000) будет опираться на Mobile IP и Authentication, Authorization, Accounting (AAA) - предложение по стандарту IETF, с помощью которого системы смогут идентифицировать пользователей и передавать биллинговую информацию об использовании ресурсов по Internet (см. врезку 'Защита и другие злободневные вопросы').

НАЗАД НА СВОЮ ТЕРРИТОРИЮ

Несмотря на то что со сроками пока ничего не ясно, весьма вероятно, что Mobile IP станет использоваться в территориальных сетях в не столь отдаленном будущем. Данная технология уже применяется в имеющихся сотовых продуктах, причем отрасль планирует полномасштабную реализацию стандарта в продуктах следующего поколения. Эти обширные беспроводные инфраструктуры будут создаваться на базе того же маршрутизирующего оборудования, что и корпоративные сети IP. Это означает, что компании станут постепенно оснащать свои сети оборудованием со встроенной поддержкой домашних и внешних агентов. С этого момента для реализации технологии будет требоваться только небольшое расширение установленного стека на сетевом клиенте и желание ей заниматься.

Джон Гаррисон, президент компании Ecutel (http://www.ecutel.com/), одного из первых провайдеров сквозного программного решения на базе Mobile IP (под названием Viatores), полагает, что главным стимулом для его внедрения должны стать приложения немедленного обмена сообщениями. 'В случае любого приложения реального времени главные заботы связаны с персональным IP-адресом, - поясняет он. - При переходе из одной сети в другую люди теряют свой IP-адрес, получая взамен временный адрес. После этого никто не знает, как с ними связаться'. Здесь-то и пригодится Mobile IP.

Но Денни из Cisco считает, что администраторы ИТ пока еще не ощущают потребность в такого рода приложениях. 'Даже более того, они считают, что такие приложения им не нужны, - говорит он. - К тому же они не смогут реализовать сквозные решения, потому что клиентский компонент пока отсутствует'.

Или, как заявил пожелавший остаться неизвестным представитель одного из производителей маршрутизаторов, 'любому производителю приходится невольно задумываться о том, что на этот счет думает Кинг-Конг из Рэдмонда. Mobile IP вряд ли появится на наших корпоративных ноутбуках, если не будет дешевого, широко распространенного сетевого клиента, поддерживающего Mobile IP'.

Что касается сетевых администраторов, то Mobile IP может слегка усложнить их жизнь из-за необходимости устанавливать Mobile IP-совместимые версии сетевого клиентского программного обеспечения на традиционные клиенты. Без сомнения, администратору придется к тому же поломать голову над тем, сколько чужих гостей он готов принять в своей сети.

Вместе с тем он может получить выгоду с точки зрения обслуживания, потому что вызывающие столько забот ноутбуки превратятся в своего рода эквивалент Plug-and-Play в области сетевой адресации: их будет достаточно воткнуть в любой сетевой разъем на вашей системе, и они станут работать. К тому же после широкого распространения в Internet соглашений на базе AAA и Mobile IP он сможет наслаждаться нежданными-негаданными выгодами: подключив ноутбук к модемному разъему в отеле, пользователь сможет делать в сети все, что он делает там обычно (включая сотрудничество в реальном времени). Конечно, сначала ему надо будет зарезервировать номер.

Роберт Ричардсон - постоянный автор Network Magazine. С ним можно связаться через его Web-сервер http://www.smallofficetech.com/, где можно подписаться на его информационный бюллетень Small Office TECH.

Защита и другие злободневные вопросы

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

Если сообщество Internet чему-то и научилось, то это тому, что если какая-либо система позволяет изменить маршрутизацию пакетов удаленным образом, то она неизбежно будет атакована - как посредством атак по типу 'отказ в обслуживании', так и с помощью пиратских сеансов, причем в любом случае цель состоит в перенаправлении пакетов на хосты, контролируемые злоумышленниками.

Наиболее очевидный способ атаки на Mobile IP - это солгать домашнему агенту и дать ему неверный транзитный адрес, откуда пакеты будут пересылаться на узел злоумышленника. Однако Mobile IP предотвращает такие атаки благодаря обязательной аутентификации запросов к домашнему агенту.

Другая проблема в области защиты связана с тем, что мобильные узлы будут находиться в чьей-то чужой сети, когда они оказываются за пределами своей собственной сети. В случаях, когда соединение проходит через сеть коммерческого провайдера услуг, провайдер, естественно, захочет взимать плату за используемые время и ресурсы, а не глядеть, как кто-то крадет эти ресурсы из-за отсутствия надлежащего контроля.

Что именно делать с контролем доступа и биллингом - этот вопрос до сих пор остается в подвешенном состоянии. В настоящее время наиболее очевидным выбором для контроля за пользованием сервисом представляется предложение по стандарту IETF под названием 'Аутентификация, авторизация и учет' (Authentication, Authorization, Accounting, AAA).

Описание AAA выходит за рамки данной статьи, но, вообще говоря, это механизм, с помощью которого провайдер услуг чужой сети может проверить наличие у мобильного пользователя контракта с другим провайдером услуг, как он о том утверждает. AAA позволяет также удостовериться, что чужой провайдер услуг является легальным и поддерживает взаимные отношения с домашним провайдером, а биллинговая информация передается домашнему провайдеру по защищенному каналу. С точки зрения клиента, наиболее очевидным следствием использования AAA станет, вероятно, переход с RADIUS на более эффективный и расширяемый протокол Diameter, стандарт на который пока еще не принят.

Другой вопрос в области защиты возникает при попытке оптимизировать кружной маршрут, по которому пакеты вынуждены следовать в соответствии с принятыми в Mobile IP соглашениями относительно переадресации. Если бы мобильный узел мог попросить домашнего агента сообщить транзитный адрес узлу, с которым он ведет диалог, то это позволило бы значительно сократить путь следования пакетов. Проблема, однако, в том, как другой узел сможет проверить, что полученная им информация о транзитном адресе действительно была передана ему мобильным узлом. Если обмен ключами с домашним агентом не составляет труда для мобильного узла (в предположении, что он соответствующим образом сконфигурирован), то распространение заслуживающих доверия ключей на всю потенциальную вселенную возможных адресатов предполагает наличие обширной и сложной архитектуры управления ключами, каковой пока еще не существует.