Please enter banners and links.
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: [email protected]
Phil Roberts
Motorola
1501 West Shure Drive
Arlington Heights, IL 60004
USA
Phone: +1 847-632-3148
EMail: [email protected]
Вопросы, относящиеся к данному документу, следует направлять:
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: [email protected]
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: [email protected]
Перевод на русский язык
Николай Малых
Полное заявление авторских прав
Copyright (C) The Internet Society (2000). Все права защищены.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
1Network Access Identifier.
2Работа завершена и опубликована в RFC 3315. Прим. перев.
3Работа завершена и опубликована в RFC 3775. Прим. перев.
4Home Domain Allocation Function — функция выделения адреса в домашнем домене.
