Network Working Group C. Perkins Request for Comments: 2004 IBM Category: Standards Track October 1996
Minimal Encapsulation within IP
Минимальная инкапсуляция в IP
Статус документа
В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.
Аннотация
Этот документ задаёт метод для инкапсуляции (передачи в поле данных – payload) дейтаграммы IP в другую дейтаграмму IP с меньшими издержками, чем при «традиционной» инкапсуляции IP, где добавляется второй заголовок IP к каждой инкапсулируемой дейтаграмме. Инкапсуляция предлагается как средство изменения обычной маршрутизации IP для дейтаграмм путём их доставки промежуточному получателю, который иначе не был бы выбран по полю адреса получателя IP (сетевая часть) в исходном заголовке IP. Инкапсуляция может применяться для различных целей, таких как доставка дейтаграмм мобильному узлу с использованием Mobile IP.
1. Введение
Документ задаёт метод, с помощью которого дайтаграмма IP может инкапсулироваться (передаваться как данные) в дейтаграмму IP с меньшими издержками, нежели при «традиционной» инкапсуляции IP [4], где к каждой инкапсулируемой дейтаграмме добавляется второй заголовок IP. Инкапсуляция предлагается как средство изменения обычной маршрутизации IP для дейтаграмм путём их доставки промежуточному получателю, который иначе не был бы выбран по полю адреса получателя IP (сетевая часть) в исходном заголовке IP. Процесс инкапсуляции и декапсуляции дейтаграмм часто называют туннелированием, а инкапсулятор и декапсулятор – конечными точками туннеля. Инкапсулятор считается входом в туннель, декапсулятор – выходом из туннеля.
2. Мотивация
Рабочая группа Mobile IP определила применение инкапсуляции как способ доставки пакета из «домашней сети» мобильного узла агенту, который может локально доставлять дейтаграммы традиционным способом мобильному узлу, находящемуся «вне дома» [5]. Применение инкапсуляции может указываться всякий раз, когда источник (или промежуточный маршрутизатор) дейтаграммы IP должен влиять на маршрут доставки дейтаграммы конечному получателю. Другие возможные применения инкапсуляции включают групповую передачу, льготные цены (preferential billing), выбор маршрутов с определёнными атрибутами безопасности и маршрутизацию по общим правилам.
В [4] обсуждаются преимущества инкапсуляции по сравнению с использованием опции IP loose source routing (мягкое задание маршрута источником). Использование заголовков IP для инкапсуляции дейтаграмм IP требует ненужного дублирования нескольких полей из внутреннего заголовка IP и можно сократить эти издержки, задав новый механизм инкапсуляции без такого дублирования. Очерченная здесь схема создана рабочей группой Mobile IP (в более ранних Internet Draft) и аналогичная заданной в [2].
3. Минимальная инкапсуляция
Определяется минимальный заголовок пересылки для дейтаграмм, которые не были фрагментированы перед инкапсуляцией. Использование этого метода инкапсуляции не является обязательным. Минимальную инкапсуляцию недопустимо применять, если исходная дейтаграмма уже фрагментирована, поскольку в минимальном заголовке пересылки нет места для хранения сведений о фрагментации. Для использования минимальной инкапсуляции дейтаграммы IP в неё вставляется показанный ниже минимальный заголовок пересылки.
+---------------------------+ +---------------------------+
| | | |
| Заголовок IP | | Измененный заголовок IP |
| | | |
+---------------------------+ ====> +---------------------------+
| | |Минимал. заголов. пересылки|
| | +---------------------------+
| Данные IP | | |
| | | |
| | | Данные IP |
+---------------------------+ | |
| |
+---------------------------+
Заголовок IP исходной дейтаграммы изменяется и после него вставляется минимальный заголовок пересылки, за которым следуют данные IP (payload) из исходной дейтаграммы (например, транспортный заголовок и данные). В дейтаграмму не добавляется другой заголовок IP.
В инкапсулирующей дейтаграмме исходный заголовок IP [6] изменяется, как показано ниже.
-
В поле Protocol указывается значение 55 (протокол минимальной инкапсуляции).
-
Поле Destination Address заменяется IP-адресом выходной точки туннеля.
-
Если инкапсулятор не является исходным источником дейтаграммы, поле Source Address заменяется IP-адресом инкапсулятора.
-
Значение поля Total Length увеличивается на размер добавленного в дейтаграмму заголовка минимальной инкапсуляции. Это увеличение составляет 12 или 8 октетов в зависимости от значения бита S (наличие исходного адреса источника) в заголовке пересылки.
-
Поле Header Checksum рассчитывается заново [6] или обновляется с учётом описанных изменений в заголовке IP.
Отметим, что в отличие от инкапсуляции IP-in-IP [4], поле TTL в заголовке IP не меняется при этой инкапсуляции. Если инкапсулятор пересылает дейтаграмму, он декрементирует TTL в результате обычной пересылки IP. Поскольку исходное значение TTL остаётся в заголовке IP после инкапсуляции, узлы пересылки в туннели будут видимыми, например, для traceroute.
Формат заголовка минимальной инкапсуляции показан ниже.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol |S| reserved | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Original Source Address (при наличии) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol
S (флаг присутствия исходного адреса источника)
0
Исходный адрес не присутствует и размер минимального заголовка туннелирования составляет 8 октетов.1
Исходный адрес присутствует и размер минимального заголовка туннелирования составляет 12 октетов.reserved
Устанавливается в 0 при передаче, игнорируется при получении.Header Checksum
16-битовое дополнение до 1 суммы дополнений до 1 всех 16-битовых слов минимального заголовка пересылки. До расчёта контрольной суммы это поле принимается равным 0. Заголовок IP и данные (payload) после заголовка не учитываются в контрольной сумме.Original Destination Address
Копируется из поля Destination Address в исходном заголовке IP.Original Source Address
При установленном флаге S копируется из поля Source Address в исходном заголовке IP, иначе не присутствует.Придекапсуляции дейтаграммы поля из минимального заголовка пересылки служат для восстановления заголовка IP, а сам заголовок пересылки удаляется из дейтаграммы. Значение поля Total Length в заголовке IP уменьшается на размер заголовка пересылки, а поле Header Checksum в заголовке IP рассчитывается заново [6] или обновляется с учётом внесённых при декапсуляции изменений.
Инкапсулято может использовать имеющиеся механизмы IP, подходящие для доставки инкапсулированного содержимого в выходную точку туннеля. В частности, разрешено использовать опции IP или фрагментацию (если в заголовке IP не установлен флаг Don’t Fragment). Ограничения на фрагментацию нужны для того, чтобы узлы, применяющие Path MTU Discovery [3], могли получить нужную информацию.
4. Отказы маршрутизации
Использование любого метода инкапсуляции для целей маршрутизации повышает восприимчивость к маршрутным петлям. Для снижения опасности маршрутизаторам следует соблюдать процедуры, указанные в [4].
5. Сообщения ICMP из туннеля
Сообщения ICMP обрабатываются в соответствии с [4], включая поддержку «мягкого» (soft state) состояния туннеля.
6. Вопросы безопасности
Вопросы безопасности не рассматриваются в этом документе, но в целом они аналогичны рассмотренным в [4].
7. Благодарности
Большая часть текста раздела 3 заимствована из предварительной версии Mobile IP draft [1]. Спасибо David Johnson за повышение согласованности и множество других улучшений этого документа.
Литература
[1] Perkins, C., Editor, “IPv4 Mobility Support”, Work in Progress1, May 1995.
[2] David B. Johnson. Scalable and Robust Internetwork Routing for Mobile Hosts. In Proceedings of the 14th International Conference on Distributed Computing Systems, pages 2–11, June 1994.
[3] Mogul, J., and S. Deering, “Path MTU Discovery”, RFC 1191, November 1990.
[4] Perkins, C., “IP Encapsulation within IP”, RFC 2003, October 1996.
[5] Perkins, C., Editor, “IP Mobility Support”, RFC 2002, October 1996.
[6] Postel, J., Editor, “Internet Protocol”, STD 5, RFC 791, September 1981.
Адрес автора
Вопросы, связанные с этим документом, можно направлять автору
Charles Perkins Room H3-D34 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Work: +1-914-784-7350 Fax: +1-914-784-6205 EMail: perk@watson.ibm.comС рабочей группой можно связаться через её руководителя
Jim Solomon Motorola, Inc. 1301 E. Algonquin Rd. Schaumburg, IL 60196 Work: +1-847-576-2753 EMail: solomon@comm.mot.comПеревод на русский язык
Николай Малых