Network Working Group P. Calhoun
Request for Comments: 2794 Sun Microsystems Laboratories
Updates: 2290 C. Perkins
Category: Standards Track Nokia Research Center
March 2000
Расширение Mobile IP Network Access Identifier для протокола IPv4
Mobile IP Network Access Identifier Extension for IPv4
Статус документа
Данный документ содержит спецификацию стандартного протокола Internet, предложенного сообществу Internet, и является приглашением к дискуссии в целях развития этого протокола. Сведения о текущем состоянии стандартизации протокола вы найдете в документе Internet Official Protocol Standards (STD 1). Документ можно распространять без ограничений.
Авторские права
Copyright (C) The Internet Society (2000). Все права защищены.
Аннотация
Серверы AAA сегодня широко используются в Internet для аутентификации и проверки полномочий (авторизации) пользователей, подключающихся к сети по коммутируемым линиям. Очевидно, что такие же серверы могут применяться для мобильных узлов, использующих Mobile IP, когда такие узлы пытаются подключиться к чужим доменам с серверами AAA. Современные серверы AAA идентифицируют клиентов с применением идентификаторов доступа в сеть (NAI1). В этом документе для мобильных узлов определяется способ идентификации себя путем включения NAI в запрос Mobile IP Registration. Этот документ также является обновлением RFC 2290, в котором приводится спецификация конфигурационной опции Mobile-IPv4 для IPCP, позволяя использовать нулевое значение поля Home Address для мобильного узла (Mobile Node).
1. Введение
Серверы AAA сегодня широко используются в Internet для аутентификации и проверки полномочий (авторизации) пользователей, подключающихся к сети по коммутируемым линиям. Очевидно, что такие же серверы могут применяться для мобильных узлов, использующих Mobile IP, когда такие узлы пытаются подключиться к чужим доменам с серверами AAA. Современные серверы AAA идентифицируют клиентов с применением идентификаторов доступа в сеть (NAI) [1]. Данный документ содержит спецификацию расширения Mobile Node NAI для сообщений Mobile IP Registration Request [7], передаваемых мобильным узлом.
Поскольку для идентификации мобильного узла обычно используется идентификатор NAI, для такой идентификации не всегда требуется домашний адрес мобильного узла. Это делает возможной аутентификацию и авторизацию мобильного узла даже при отсутствии у него домашнего адреса. В сообщении Registration Request, содержащем расширение Mobile Node NAI, поле Home Address может иметь значение 0, для запроса на выделение такого адреса.
В RFC 2290 [8] была определена опция Mobile-IPv4 Configuration в IPCP для обеспечения корректного взаимодействия между мобильным узлом и партнером, через которого этот узел подключается к сети по протоколу PPP. В соответствии с этой спецификацией поле домашнего адреса (Home Address) мобильного узла в этой опции должно быть отлично от 0. Однако в контексте этого документа, который позволяет идентифицировать мобильный узел по значению NAI и получать адрес после фазы PPP при организации соединения, значение поля Home Address может быть нулевым при сохранении всех остальных требований RFC 2290. Интерпретация различных сценариев из RFC 2290 приведена в разделе 4.
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [3].
2. Расширение NAI для мобильного узла
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | MN-NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 1: Расширение Mobile Node NAI
Расширение Mobile Node NAI, показанное на рисунке 1, содержит имя пользователя в формате, определенном в [1]. Когда это расширение присутствет в запросе на регистрацию (Registration Request), поле Home Address может иметь нулевое значение. Расширение Mobile Node NAI должно включаться в Registration Request до расширений Mobile-Home Authentication и Mobile-Foreign Authentication, если те присутствуют.
Type
131 (может быть пропущено) [7]
Length
Размер поля MN-NAI в байтах.
MN-NAI
Строка в формате NAI, определенном в [1].
3. Взаимодействие с внешними агентами
Если поле Home Address в регистрационном запросе имеет нулевое значение, внешний агент (foreign agent) должен использовать взамен этого адреса идентификатор NAI в своих записях об ожидающих обработки запросах на регистрацию вместе с полем Identification, как обычно. Если внешний агент не может управлять записями о запросах на регистрацию таким способом, он должен возвращать сообщение Registration Reply со значением Code, показывающим NONZERO_HOMEADDR_REQD (см. раздел 5).
Если мобильный узел включает расширение Mobile Node NAI в свой запрос на регистрацию, отклик Registration Reply от домашнего агента должен включать расширение Mobile Node NAI. Если это не так, внешнему агенту следует передать мобильному узлу Registration Reply с Code = MISSING_NAI (см. раздел 5). Отклик Registration Reply должен включать отличные от нуля значения полей адреса Home Agent и домашнего адреса (Home Address) мобильного узла. Если это не так, внешнему агенту следует передавать мобильному узлу Registration Reply с Code = MISSING_HOME_AGENT или MISSING_HOMEADDR, соответственно (см. раздел 5).
4. Взаимодействие с Mobile-IPv4 Configuration Option для IPCP
В Mobile-IPv4 Configuration Option для IPCP [8] поле Home Address мобильного узла может иметь нулевое значение. В этом параграфе указано действие, которое должно быть выполнено в тех случаях, когда мобильный узел использует расширение Mobile Node NAI в регистрационном запросе Mobile IP Registration Request. Независимо от наличия в IP Address Configuration Option отличного от нуля адреса IP мобильный узел будет пытаться получить домашний адрес из отклика Mobile IP Registration Reply.
Если в IP Address Configuration Option для IPCP вместо адреса IP задано нулевое значение, предполагается, что партнер PPP выделит адрес для мобильного узла. С другой стороны, если опция IP Address Configuration для IPCP включает отличный от 0 адрес IP, предполагается, что партнер PPP выделил этот адрес мобильному узлу в качестве совмещенного (co-located care-of address).
Наконец, если опция IP Address Configuration Option отсутствует в IPCP Configure-Request, не предполагается выделения совмещенного адреса в IPCP. Мобильный узел будет получать такой адрес на более поздней фазе настройки конфигурации или использовать адрес внешнего агента (FA-located care-of address).
5. Коды ошибок
В каждой строке приведенной ниже таблицы указано имя и значение поля Code [7], возвращаемого в Registration Reply, и параграф данного документа, в котором описан код ошибки.
|
Имя ошибки |
Значение |
Раздел документа |
|
NONZERO_HOMEADDR_REQD |
96 |
3 |
|
MISSING_NAI |
97 |
3 |
|
MISSING_HOME_AGENT |
98 |
3 |
|
MISSING_HOMEADDR |
99 |
3 |
6. Согласование с IANA
Расширение Mobile Node NAI, определенное в разделе 2, является регистрационным расширением Mobile IP, определенного в RFC 2002 [7] и дополненного в RFC 2356 [6]. Агентству IANA следует выделить для него значение 131.
Значения Code, приведенные в разделе 5, являются кодами ошибок, определенными в RFC 2002 и дополненными в RFC 2344 [5] and RFC 2356 [6]. Они соответствуют кодам ошибок, связываемых условно с отказом на внешнем агенте (значения из диапазона 64-127). Агентству IANA следует выделить значения, приведенные в разделе 5.
7. Вопросы безопасности
Регистрационные сообщения Mobile IP аутентифицируются и аутентификация проверяется получателем. Это позволяет не запрещать передачу NAI через сеть в открытом виде и проблем безопасности от этого не предполагается.
8. Использование с IPv6
Supporting NAI-based registrations for Mobile IPv6 [4] is outside the scope of this document. This section contains some ideas how Stateless Address Autoconfiguration [9] and DHCPv6 [2] might be extended to support NAI-based Mobile IPv6 registrations.
Для мобильных узлов IPv6 не развернуто общепринятных механизмов, с помощью которых мобильный узел может представить самого себя по типу используемых в IPv4. Тем не менее мобильные узлы IPv6 могут пожелать указать домен, в котором его свидетельства (credentials) могут быть проверены, путем использования NAI точно так же, как данная спецификация предлагает для IPv4. Однако в случае IPv6 нет внешнего агента, управляющего подключениями мобильного узла и проверяющего представленные им свидетельства. Для идентификации HDAF (см. Приложение A) в предположении связи с мобильным узлом NAI будет пересылаться локальной системе AAA локальным агентом, вовлеченным в настройку адреса мобильного узла.
Этим агентом может быть маршрутизатор, передающий анонсы Router Advertisement [9], или сервер DHCPv6. В первом случае маршрутизатор будет сигнализировать о своей возможности обрабатывать NAI, путем добавления некой (еще не определенной) опции к Router Advertisement. Во втором случае для управляемых каналов мобильный узел может включить еще не определенное расширение NAI в свое сообщение DHCP Solicitation. Такое расширение NAI и соответствующая аутентификация будут также требоваться для последующего запроса DHCP Request, передаваемого мобильным узлом серверу DHCP, выбранному на основе полученных анонсов DHCP Advertisement. После получения адреса в чужой сети мобильный узел сможет использовать обычный протокол MIPv6 [4].
9. Благодарности
Авторы благодарят Gabriel Montenegro и Vipul Gupta за полезное обсуждение. Спасибо Basaravaj Patil и Pete McCann за текст, описывающий действия при нулевом домашнем адресе и желании мобильного узла использовать конфигурационную опцию Mobile-IPv4 для IPCP, определенную в RFC 2290.
Литература
[1] Aboba, B. and M. Beadles, “The Network Access Identifier”, RFC 2486, January 1999.
[2] Bound, J. and C. Perkins, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, Work in Progress2.
[3] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[4] Johnson, D. and C. Perkins “Mobility Support in IPv6”, Work in Progress3.
[5] Montenegro, G., “Reverse Tunneling for Mobile IP”, RFC 2344, May 1998.
[6] Montenegro, G. and V. Gupta, “Sun’s SKIP Firewall Traversal for Mobile IP”, RFC 2356, June 1998.
[7] Perkins, C., “IP Mobility Support”, RFC 2002, October 1996.
[8] Solomon, J. and S. Glass, “Mobile-IPv4 Configuration Option for PPP IPCP”, RFC 2290, February 1998.
[9] Thomson, S. and T. Narten, “IPv6 Stateless Address Autoconfiguration”, RFC 2462, December 1998.
Приложение A. Функция HDAF
В этом приложении вводится новая функция HDAF4, которая может динамически присваивать мобильному узлу домашний адрес (Home Address).
+------+ | | +---+ HA-1 | +------+ +------+ +------+ | | | | | | | | | | +------+ | MN |-------| FA |-------| HDAF +---+ ... | | | | | | | +------+ +------+ +------+ +------+ | | | +---+ HA-n | | | +------+
Рисунок 2: Функция HDAF
На рисунке 2 показана домашняя функция HDAF, которая получает сообщения от внешних агентов (FA) и выделяет Home Address из своего домашнего домена (Home Domain). HDAF не выполняет обработки запросов Registration Request от мобильных узлов, а просто пересылает такие запросы домашнему агенту (HA) в сети, который может обработать запрос.
При получении запроса Registration Request от мобильного узла (MN) агент FA извлекает NAI и определяет имя домена, связанного с ним. Далее FA находит HDAF, которая обслуживает запросы для домена мобильного узла. Протокол обнаружения выходит за рамки данной спецификации. В приведенном примере FA может передать задачу поиска HDAF локальному серверу AAA. Этот сервер может также помогать FA в процессе верификации свидетельств мобильного узла с использованием протокола, который данная спецификация не задает.
Адреса
Контактировать с рабочей группой можно через ее руководителей:
Basavaraj Patil
Nokia Corporation
6000 Connection Drive
M/S M8-540
Irving, TX 75039
USA
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com
Phil Roberts
Motorola
1501 West Shure Drive
Arlington Heights, IL 60004
USA
Phone: +1 847-632-3148
EMail: QA3445@email.mot.com
Вопросы, относящиеся к данному документу, следует направлять:
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
Fax: +1 650 625-2502
EMail: charliep@iprg.nokia.com
Pat R. Calhoun
Sun Microsystems Laboratories
15 Network Circle
Menlo Park, California 94025
USA
Phone: +1 650-786-7733
Fax: +1 650-786-6445
EMail: pcalhoun@eng.sun.com
Перевод на русский язык
Николай Малых
Полное заявление авторских прав
Copyright (C) The Internet Society (2000). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.
Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
1Network Access Identifier.
2Работа завершена и опубликована в RFC 3315. Прим. перев.
3Работа завершена и опубликована в RFC 3775. Прим. перев.
4Home Domain Allocation Function — функция выделения адреса в домашнем домене.
