RFC 2784 Generic Routing Encapsulation (GRE)

Network Working Group                                   D. Farinacci
Request for Comments: 2784                                     T. Li
Category: Standards Track                           Procket Networks
                                                            S. Hanks
                                                Enron Communications
                                                            D. Meyer
                                                       Cisco Systems
                                                           P. Traina
                                                    Juniper Networks
                                                          March 2000

 

Базовая инкапсуляция маршрутных данных (GRE)

Generic Routing Encapsulation (GRE)

PDF

Статус документа

В этом документе содержится спецификация проекта стандартного протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2000). All Rights Reserved.

Тезисы

В этом документе дана спецификация протокола для инкапсуляции произвольного протокола сетевого уровня в любой другой протокол сетевого уровня.

1. Введение

В настоящее время существует множество протоколов [RFC 1234, RFC 1226] инкапсуляции одного протокола в другой. Для инкапсуляции IP в IP, требуемой политикой, предложены специальные протоколы [RFC 1241, RFC 1479]. В этом документе описан протокол, который очень похож на упомянутые выше протоколы, но является более обобщенным. Для повышения уровня общности многие нюансы протоколов игнорируются. В результате предлагаемый протокол меньше подходит для ситуаций, когда требуется конкретная инкапсуляция протокола X в протокол Y (X over Y). Предлагаемый протокол является попыткой создания простого механизма общего назначения, который переведет проблему инкапсуляции из текущего состояния O(n2) в более управляемое состояние. Документ не решает вопрос определения необходимости инкапсуляции. Документ подтверждает наличие, но не решает проблемы взаимной инкапсуляции [RFC 1326].

В общем случае система имеет пакет, который требуется инкапсулировать и доставить адресату. Будем называть этот пакет вложенным (payload packet). Вложенный пакет инкапсулируется в пакет GRE. Полученный пакет GRE может инкапсулироваться в тот или иной протокол и пересылается. Этот внешний протокол будем называть протоколом доставки. Алгоритмы обработки пакета обсуждаются ниже.

Кроме того, данная спецификация описывает пересечение реализаций GRE, предлагаемых разными производителями.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

2. Структура инкапсулированных пакетов

Структура инкапсулированного с использованием GRE пакета показана на рисунке.

---------------------------------
|                               |
|      Заголовок доставки       |
|                               |
---------------------------------
|                               |
|        Заголовок GRE          |
|                               |
---------------------------------
|                               |
|        Вложенный пакет        |
|                               |
---------------------------------


В этой спецификации рассматривается, прежде всего, структура заголовка GRE, а также обсуждается ряд вопросов, связанных с передачей инкапсулированных пакетов IPv4.

2.1. Заголовок GRE

Заголовок пакета GRE показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|       Reserved0       | Ver |         Protocol Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Checksum (необязательно)    |    Reserved1 (необязательно)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


2.2. Checksum Present (бит 0)

Если флаг Checksum Present (контрольная сумма присутствует) установлен, поля Checksum и Reserved1 присутствуют в заголовке и поле Checksum содержит корректную информацию. Отметим, что совместимые реализации должны принимать и обрабатывать это поле.

2.3. Reserved0 (биты 1-12)

Получатель должен отбрасывать пакеты, в которых биты 1-5 отличны от нуля, если этот получатель не реализует RFC 1701. Биты 6-12 зарезервированы — они должны устанавливаться в 0 при передаче и игнорироваться на приеме.

2.3.1. Version Number (биты 13-15)

Поле номера версии должно иметь нулевое значение.

2.4. Protocol Type (2 октета)

Поле Protocol Type указывает тип протокола для вложенного пакета. Типы протоколов определены в [RFC1700], как ETHER TYPES и в документе [ETYPES]. Реализации, получившей пакет со значением поля Protocol Type, не указанным в [RFC1700] или [ETYPES], следует отбрасывать такой пакет.

2.5. Checksum (2 октета)

Поле Checksum содержит контрольную сумму IP (дополнение до единицы) для всех 16-битовых слов заголовка GRE и вложенного пакета. При расчете контрольной суммы значение данного поля принимается нулевым. Это поле присутствует только при установленном флаге Checksum Present.

2.6. Reserved1 (2 октета)

Поле Reserved1 зарезервировано и при его наличии должно содержать нулевое значение. Поле Reserved1 присутствует только при наличии поля контрольной суммы (т. е., при установленном флаге Checksum Present).

3. IPv4 в качестве вложенных пакетов

Когда протокол IPv4 передается во вложенных пакетах GRE, поле Protocol должно иметь значение 0x800.

3.1. Пересылка декапсулированных пакетов IPv4

Когда конечная точка туннеля декапсулирует пакет GRE, в который вложен пакет IPv4, адрес получателя из заголовка пакета IPv4 должен использоваться для дальнейшей пересылки пакета, а значение TTL в заголовке вложенного пакета должно быть декрементировано. Следует с осторожностью пересылать пакет, поскольку в случае указания в качестве получателя пакета адреса инкапсулятора (т. е., другой стороны туннеля) может возникнуть петля. В таких случаях пакеты должны отбрасываться.

4. IPv4 в качестве протокола доставки

Протокол IPv4 с типом 47 [RFC1700] используется при инкапсуляции пакетов GRE в IPv4. Требования к доставке пакетов через сети IPv4 приведены в документе [RFC1122].

5. Взаимодействие с реализациями RFC 1701

В RFC 1701 поле, обозначенное здесь Reserved0, содержит множество битовых флагов, которые данная спецификация отвергает. В частности, флаги Routing Present, Key Present, Sequence Number Present и Strict Source Route были отменены вместе с полем Recursion Control. В результате заголовок GRE никогда не будет включать полей Key, Sequence Number и Routing, определенных в RFC 1701.

Однако реализации RFC 1701 используются на практике. Ниже описано взаимодействие с такими реализациями.

5.1. Получатель RFC 1701

Реализации, соответствующие данному документу, будет передавать пакеты с нулевым значением поля Reserved0. Соответствующий RFC 1701 получатель будет интерпретировать это, как сброшенные (0) флаги Routing Present, Key Present, Sequence Number Present, Strict Source Route и не будет ждать присутствия определенных в RFC 1701 полей Key, Sequence Number и Routing.

5.2. Отправитель RFC 1701

Отправитель RFC 1701 может устанавливать флаги Routing Present, Key Present, Sequence Number Present и Strict Source Route и передавать в таких случаях определенные в RFC 1701 поля Key, Sequence Number или Routing в заголовке GRE. Как сказано в параграфе 2.31, пакеты с ненулевыми битами 1-5 должны отбрасываться, если получатель не реализует RFC 1701.

6. Вопросы безопасности

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

7. Взаимодействие с IANA

В этом разделе рассматривается выделение для GRE дополнительных значений Version Number и Protocol Type.

7.1. Номера версии GRE

Этот документ задает GRE версии 0. GRE версии 1 используется протоколом PPTP [RFC2637]. Дополнительные номера версий GRE выделяются с согласия IETF, как описано в RFC 2434 [RFC2434].

7.2. Типы протокола

GRE использует значения ETHER TYPE в качестве типа протокола. Новые значения ETHER TYPE выделяются Xerox Systems Institute2 [RFC1700].

8. Благодарности

Документ основан на идеях авторов RFC 1701 и RFC 1702. Hitoshi Asaeda, Scott Bradner, Randy Bush, Brian Carpenter, Bill Fenner, Andy Malis, Thomas Narten, Dave Thaler, Tim Gleeson и др. внесли конструктивные и значимые предложения.

9. Приложение известные проблемы

Этот документ задает поведение развернутых реализаций GRE и не пытается решить перечисленные ниже вопросы.

  • Взаимодействие с Path MTU Discovery (PMTU) [RFC1191].

    Существующие реализации GRE при использовании IPv4 в качестве протокола доставки не поддерживают определение Path MTU и не устанавливают флаг запрета фрагментирования (DF) в заголовке доставки. Это может приводить к фрагментированию больших пакетов в туннеле и сборке на выходе (независимо от использования PMTU для вложенного пакета). Если точка входа в туннель использовала определение Path MTU, она должна будет также транслировать сообщения ICMP unreachable (в частности, fragmentation needed and DF set) исходным отправителям пакетов, что не требуется данной спецификацией. Отказ от корректной трансляции данных Path MTU исходному отправителю может приводить к тому, что этот отправитель установит флаг DF, пакет будет отброшен в туннеле, а отправитель не узнает об этом и будет повторять передачу с использованием того же PMTU, что станет причиной отбрасывания и этих пакетов.

  • IPv6 в качестве протокола доставки и вложенного протокола.

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

  • Взаимодействие с ICMP.

  • Взаимодействие с архитектурой дифференцированного обслуживания (DiffServ).

  • Множественная и циклическая инкапсуляция.

10. Литература

[ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers1

[RFC1122] Braden, R., «Requirements for Internet hosts — communication layers», STD 3, RFC 1122, October 1989.

[RFC1191] Mogul, J. and S. Deering, «Path MTU Discovery», RFC 1191, November 1990.

[RFC1226] Kantor, B., «Internet Protocol Encapsulation of AX.25 Frames», RFC 1226, May 1991.

[RFC1234] Provan, D., «Tunneling IPX Traffic through IP Networks», RFC 1234, June 1991.

[RFC1241] Woodburn, R. and D. Mills, «Scheme for an Internet Encapsulation Protocol: Version 1», RFC 1241, July 1991.

[RFC1326] Tsuchiya, P., «Mutual Encapsulation Considered Dangerous», RFC 1326, May 1992.

[RFC1479] Steenstrup, M., «Inter-Domain Policy Routing Protocol Specification: Version 1», RFC 1479, July 1993.

[RFC1700] Reynolds, J. and J. Postel, «Assigned Numbers», STD 2, RFC 17003, October 1994.

[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, «Generic Routing Encapsulation», RFC 1701, October 1994.

[RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, «Generic Routing Encapsulation over IPv4 networks», RFC 1702, October 1994.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March, 1997.

[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 24084, November 1998.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October, 1998.

[RFC2637] Hamzeh, K., et al., «Point-to-Point Tunneling Protocol (PPTP)», RFC 2637, July, 1999.

11. Адреса авторов

Dino Farinacci

Procket Networks

3850 No. First St., Ste. C

San Jose, CA 95134

EMail: dino@procket.com

Tony Li

Procket Networks

3850 No. First St., Ste. C

San Jose, CA 95134

Phone: +1 408 954 7903

Fax: +1 408 987 6166

EMail: tony1@home.net

Stan Hanks

Enron Communications

EMail: stan_hanks@enron.net

David Meyer

Cisco Systems, Inc.

170 Tasman Drive

San Jose, CA, 95134

EMail: dmm@cisco.com

Paul Traina

Juniper Networks

EMail: pst@juniper.net

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

12. Полное заявление авторских прав

Copyright (C) The Internet Society (2000). All Rights Reserved.

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.

1В оригинале ошибочно указан параграф 5.3 (см. http://www.rfc-editor.org/errata_search.php?eid=1706). Прим. перев.

2В настоящее время реестр поддерживается IEEE и доступен по ссылке. Прим. перев.

3В соответствии с RFC 3232 документ заменен базами данных http://www.iana.org/numbers/. Прим. перев.

4Этот документ признан устаревшим и заменен RFC 4306, который, в свою очередь, заменен RFC 5996. Прим. перев.

 

 




RFC 2794 Mobile IP Network Access Identifier Extension for IPv4

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

PDF

Статус документа

Данный документ содержит спецификацию стандартного протокола 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

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

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 — функция выделения адреса в домашнем домене.