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)
Статус документа
В этом документе содержится спецификация проекта стандартного протокола, предложенного сообществу 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
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
Перевод на русский язык
Николай Малых
12. Полное заявление авторских прав
Copyright (C) The Internet Society (2000). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.
Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
1В оригинале ошибочно указан параграф 5.3 (см. http://www.rfc-editor.org/errata_search.php?eid=1706). Прим. перев.
3В соответствии с RFC 3232 документ заменен базами данных http://www.iana.org/numbers/. Прим. перев.
4Этот документ признан устаревшим и заменен RFC 4306, который, в свою очередь, заменен RFC 5996. Прим. перев.
