RFC 2675 IPv6 Jumbograms

Network Working Group                                          D. Borman
Request for Comments: 2675                      Berkeley Software Design
Obsoletes: 2147                                               S. Deering
Category: Standards Track                                          Cisco
                                                               R. Hinden
                                                                   Nokia
                                                             August 1999

IPv6 Jumbograms

Джамбограммы IPv6

PDF

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

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

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

Аннотация

Джамбограммой (jumbogram) называют пакет IPv6, в котором размер содержимого (payload) превышает 65 535 октетов. Этот документ описывает опцию IPv6 Jumbo Payload, обеспечивающую возможность указать столь большой размер содержимого. Документ также описывает изменения, которые нужно внести в TCP и UDP для применения джамбограмм.

Джамбограммы связаны только с узлами IPv6, которые могут быть подключены к каналам с MTU более 65 575 октетов, и их не требуется поддерживать и понимать узлам IPv6, которые не могут быть подключены к каналам с такими MTU.

1. Введение

      jumbo (jum'bO),

          n., pl. -bos, adj.
          -n.
          1. a person, animal, or thing very large of its kind.
          -adj.
          2. very large: the jumbo box of cereal.

          [1800-10; orig. uncert.; popularized as the name of a large
           elephant purchased and exhibited by P.T. Barnum in 1882]

                                              -- www.infoplease.com

Заголовок IPv6 [IPv6] имеет 16-битовое поле Payload Length, позволяющее указать размер содержимого до 65 535 октетов. Этот документ задаёт поэтапную (hop-by-hop) опцию IPv6, называемую Jumbo Payload, которая включает 32-битовое поле размера, позволяющее передавать пакеты IPv6 с размером содержимого от 65 536 до 4 294 967 295 октетов. Пакеты с таким размером содержимого называют джамбограммами.

Опция Jumbo Payload относится лишь к узлам IPv6, которые могут быть подключены к каналам с MTU более 65 575 октетов (65 535 + 40, где 40 — размер заголовка IPv6). Опцию Jumbo Payload не требуется реализовать или понимать на узлах IPv6, которые не поддерживают подключение к каналам с MTU больше 65 575.

На каналах с настраиваемым MTU, недопустимо устанавливать MTU больше 65 575 октетов, если на канале имеются узлы, не поддерживающие опцию Jumbo Payload, и нет гарантии, что пакеты с опцией Jumbo Payload не будут передаваться таким узлам.

Заголовок UDP [UDP] имеет 16-битовое поле Length, препятствующее использованию дейтаграмм. В заголовке TCP [TCP] нет поля Length, однако опция TCP MSS и поле TCP Urgent имеют размер 16 битов. Этот документ задаёт простые улучшения для TCP и UDP, позволяющие использовать джамбограммы. Реализация TCP или UDP на узле IPv6, поддерживающем опцию Jumbo Payload, должна включать описанные здесь улучшения.

Примечание. 16-битовые контрольные суммы UDP и TCP становятся менее эффективными по мере роста числа учитываемых в них данных. Разработчики приложений могут учитывать это обстоятельство.

1.1 История документа

Этот документ объединяет и обновляет материалы, опубликованные ранее в двух отдельных документах.

Спецификация опции Jumbo ранее была представлена как часть спецификации IPv6 в RFC 1883, которые был заменён RFC 2460, где опция Jumbo Payload отсутствовала.
Спецификация усовершенствований TCP и UDP для поддержки джамбограмм была ранее задана в RFC 2147, отмененном данным документом.

2. Формат опции Jumbo Payload

Опция Jumbo Payload передаётся в заголовке IPv6 Hop-by-Hop Options, следующем сразу после заголовка IPv6. Для этой опции требуется выравнивание 4n + 2 (см. [IPv6], параграф 4.2). Формат опции показан на рисунке.

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |  Option Type  |  Opt Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Jumbo Payload Length                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Type

8-битовое значение C2 (шестнадцатеричное).

Opt Data Len

8-битовое значение 4.

Jumbo Payload Length

32-битовое целое число без знака, указывающее размер пакета IPv6 в октетах без учёта заголовка IPv6, но с включением заголовка Hop-by-Hop Options и всех прочих заголовков расширения. Должно быть больше 65 535.

3. Использование опции Jumbo Payload

Поле Payload Length в заголовке IPv6 должно иметь значение 0 в каждом пакете с опцией Jumbo Payload.

Если узел, понимаюший опцию Jumbo Payload, получает пакет IPv6 с Payload Length = 0 и Next Header = 0 (указывает заголовок Hop-by-Hop Options), для которого кадрирование канального уровня указывает наличие октетов после заголовка IPv6, узел должен обработать заголовок Hop-by-Hop Options для определения фактического размера содержимого (payload) из опции Jumbo Payload.

Опцию Jumbo Payload недопустимо использовать в пакетах с заголовком Fragment.

Протокол вышележащего уровня, использующий поле IPv6 Payload Length для расчёта значения поля размера пакета вышележащего уровня в псевдозаголовке контрольной суммы, описанном в параграфе 8.1 [IPv6], должен вместо этого применять в расчёте значение поля Jumbo Payload Length для пакетов с опцией Jumbo Payload.

Узлы, понимающие опцию Jumbo Payload, должны обнаруживать ряд возможных ошибок формата и, если пакет не отправлен по групповому адресу, указывать эти ошибки, передавая отправителю пакета сообщение ICMP Parameter Problem [ICMPv6]. Ниже указаны ошибки и значения полей Code и Pointer в сообщении Parameter Problem.

     Ошибка: IPv6 Payload Length = 0 и
             IPv6 Next Header = Hop-by-Hop Options, 
             но опции Jumbo Payload нет.

             Code: 0
             Pointer: старший октет поля IPv6 Payload Length.

     Ошибка: IPv6 Payload Length != 0, 
             но имеется опция Jumbo Payload.

             Code: 0
             Pointer: поле Option Type в опции Jumbo Payload.

     Ошибка: Jumbo Payload присутствует, но 
             Jumbo Payload Length < 65 536.

             Code: 0
             Pointer: старший октет поля Jumbo Payload Length.

     Ошибка: Jumbo Payload присутствует
             вместе с заголовком Fragment.

             Code: 0
             Pointer: старший октет заголовка Fragment.

От узла, не понимающего опцию Jumbo Payload, ожидаются указанные ниже отклики на приём джамбограммы.

     Ошибка: IPv6 Payload Length = 0 и
             IPv6 Next Header = Hop-by-Hop Options

             Code: 0
             Pointer: старший октет поля IPv6 Payload Length.

     Ошибка: IPv6 Payload Length != 0 и
             присутствует опция Jumbo Payload.

             Code: 2
             Pointer: поле Option Type опции Jumbo Payload.

4. Джамбограммы UDP

16-битовое поле Length в заголовке UDP ограничивает общий размер пакета UDP (заголовко UDP и данные) значением 65 535 октетов. Этот документ задаёт изменение UDP для ослабления этого ограничения. Пакеты UDP размером больше 65 535 октетов можно передавать с UDP Length = 0, разрешая получателю определить фактический размер пакета UDP из Jumbo Payload Length¹. Отметим, что ранее значение UDP Length = 0 считалость недействительным, поскольку размер пакета UDP учитывает заголовок UDP и должен быть не меньше 8.

Конкретные требования для отправки джамбограмм UDP приведены ниже.

Значение Length = 0 в заголовке пакета UDP устанавливается тогда и только тогда, когда суммарный размер заголовка и данных UDP превышает 65 535 октетов.

Пакет IPv6 с таким большим пакетом UDP будет обязательно включать опцию Jumbo Payload в заголовке Hop-by-Hop Options и поле Jumbo Payload Length в этой опции должно указывать сумму фактического размера заголовка и данных UDP и размера всех заголовков расширения IPv6 между заголовками IPv6 и UDP.

При расчёте контрольной суммы UDP для псевдозаголовка [IPv6] (параграф 8.1) используется фактический размер заголовка и данных UDP, а не 0.

Конкретные требования для приема джамбограмм UDP приведены ниже.

При получении пакета UDP фактический размер заголовка и данных UDP определяется из поля IPv6 Jumbo Payload Length вычитанием размера всех заголовков расширения между заголовками IPv6 и UDP тогда и только тогда, когда указано Length = 0 в заголовке UDP.

При получении пакета с UDP Length = 0, но без опции (пакет IPv6 не является джамбограммой) для указанного выше расчёта используется поле Payload Length в заголовке IPv6 вместо поля Jumbo Payload Length.

Для проверки полученной контрольной суммы UDP в псевдозаголовке используется рассчитанный размер заголовка и данных UDP, а не 0.

5. Джамбограммы TCP

Поскольку в заголовке TCP нет поля размера, величина отдельного пакета TCP не ограничивается. Однако значение MSS, согласуемое при организации соединения, ограничивает максимальный размер передаваемого пакета TCP, а поле Urgent Pointer не позволяет указать данные сверх 65 535 байтов.

5.1 TCP MSS

При определении значения MSS для передачи устанавливается MSS = 65 535, если MTU непосредственно подключённого интерфейса за вычетом 60 [IPv6] (параграф 8.3) составляет не меньше 65 535.

При получении MSS = 65 535 оно трактуется как бесконечность и фактическое значение MSS определяется вычитанием 60 из значения, полученного с помощтю Path MTU Discovery [MTU-DISC] для пути к партнёру TCP.

5.2 TCP Urgent Pointer

Проблему Urgent Pointer можно решить добавлением опции TCP Urgent Pointer Option. Однако одновременное использование приложениями джамбограмм и Urgent Pointer, поэтому достаточно будет менее жёсткого изменения, подобного MSS.

Когда пакет TCP передаётся с Urgent Pointer (установлен бит URG), сначала рассчитывается смещение от Sequence Number до Urgent Pointer. Если смещение меньше 65 535, оно указывается в поле Urgent и продолжается обычная обработка TCP. Если смещение больше 65 535 и не меньше размера данных TCP, в поле Urgent Pointer указывается значение 65 535 и продолжается обычная обработка TCP. В противном случае пакет TCP требуется разделить на два. Первый пакет будет содержать данные вплоть (но не включая) до значения Urgent Pointer, а в поле Urgent устанавливается значение 65 535 для индикации выхода Urgent Pointer за пределы этого пакета. Вторая часть пакета может передаваться с обычной установкой поля Urgent.

Примечание. Первая часть пакета не обязательно включает все данные до Urgent Pointer и может быть короче, заканчиваясь в интервале 65 534 байта от Urgent Pointer, чтобы смещение Urgent Pointer во второй части было меньше 65 535 байтов.

Для входной обработки TCP при получении пакета TCP с флагом URG и полем Urgent = 65 535, значение Urgent Pointer рассчитывается с использованием смещения, равного размеру данных TCP, а не смещению в поле Urgent.

Следует также отметить возможность использования больших окон TCP с помощью опции TCP Window Scale [TCP-EXT], несмотря на 16-битовый размер обычного окна TCP.

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

Опция Jumbo Payload и джамбограммы TCP/UDP не создают новых проблем безопасности.

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

David A. Borman

Berkeley Software Design, Inc.

4719 Weston Hills Drive

Eagan, MN 55123

USA

Phone: +1 612 405 8194

EMail: dab@bsdi.com

Stephen E. Deering

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134-1706

USA

Phone: +1 408 527 8213

EMail: deering@cisco.com

Robert M. Hinden

Nokia

313 Fairchild Drive

Mountain View, CA 94043

USA

Phone: +1 650 625 2004

EMail: hinden@iprg.nokia.com

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

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

nmalykh@protokols.ru

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

[ICMPv6] Conta, A. and S. Deering, «ICMP for the Internet Protocol Version 6 (IPv6)», RFC 2463 ², December 1998.

[IPv6] Deering, S. and R. Hinden, «Internet Protocol Version 6 (IPv6) Specification», RFC 2460 ³, December 1998.

[MTU-DISC] McCann, J., Deering, S. and J. Mogul, «Path MTU Discovery for IP Version 6», RFC 1981 ⁴, August 1986.

[TCP] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[TCP-EXT] Jacobson, V., Braden, R. and D. Borman, «TCP Extensions for High Performance», RFC 1323, May 1992.

[UDP] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.

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

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1В оригинале ошибочно указано IPv6 payload length, см. https://www.rfc-editor.org/errata/eid2175. Прим. перев.

2Заменён RFC 4443. Прим. перев.

3Заменён RFC 8200. Прим. перев.

4Заменён RFC 8201. Прим. перев.