RFC 2784 Generic Routing Encapsulation (GRE)

Please enter banners and links.

image_print
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. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Or