RFC: 2460
Оригинал: Internet Protocol, Version 6 (IPv6) Specification
Предыдущие версии: RFC 1883
Категория: Проект стандарта
Дата публикации:
Авторы: ,
Перевод: Мельников Дмитрий Анатольевич

RFC 2460, Страница 8 из 31

Третий старший бит, представленный выше, воспринимается как элемент типа дополнительной функции, причем независимый от типа функции. То есть, соответствующая дополнительная функция определяется всеми 8-ью битами поля «Тип дополнительной функции», но только 5 битов младшего порядка определяют конкретный тип этой функции.

Одна и та же номерная ёмкость поля «Тип дополнительной функции» используется одновременно в двух заголовках: «Дополнительные функции: ретрансляция» и «Дополнительные функции: узел-получатель». Однако, описание (назначение) соответствующей дополнительной функции может ограничить её использование только в одном из этих двух заголовков.

Одиночные дополнительные функции могут иметь специфические требования к структуре своего формата в целях гарантированного обеспечения того, что параметры, состоящие из нескольких октетов, в рамках полей «Данные дополнительной функции» совпадут с естественными границами. Требование к структуре формата дополнительной функции заключается в использовании следующего соотношения: «xn+y». Оно означает, что поле «Тип дополнительной функции» должно быть представлено как целое число, состоящее из «х» октетов от начала заголовка и плюс «y» октетов. Например, «2n» означает любой сдвиг на два октета от начала заголовка, а «8n+2» — любой сдвиг на восемь октетов от начала заголовка плюс два октета.

Существуют два типа функции дополнения символами двоичной последовательности, которые используются тогда, когда появляется необходимость дополнения заголовка до длины, кратной 8 октетам. Эти типы дополнения должны в обязательном порядке определяться всеми программными реализациями IPv6-протокола, а именно:

  1. Первый тип дополнения («Pad1»): требования к структуре формата отсутствуют (рис.4).

    +-+-+-+-+-+-+-+-+
    |       0       |
    +-+-+-+-+-+-+-+-+
    Рис.4. Формат первого типа дополнения

    Замечание. Формат такого типа дополнения является специальным случаем, то есть он не имеет полей для указания длины и значения параметра.

    Этот тип функции используется для вставки только одного октета в качестве дополнения последовательности заголовка, описывающей дополнительную функцию. Если же необходимо использовать несколько октетов дополнения последовательности, то тогда целесообразно использовать второй тип функции дополнения «PadN», а не несколько раз первый тип «Pad1».

  2. Второй тип дополнения («PadN»): требования к структуре формата отсутствуют (рис.5).

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -
    |                               |          Длина поля           |
    |               1               |    «Данные дополнительной     | Данные дополнительной функции
    |                               |           функции»            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -
    Рис.5. Формат второго типа дополнения

    Этот тип функции используется для вставки двух или более октетов в качестве дополнения последовательности заголовка, описывающей дополнительную функцию. Для дополнения из «N» октетов, поле «Длина поля «Данные дополнительной функции» будет содержать значение «N-2», а само поле «Данные дополнительной функции» будет состоять из «N-2» нулевых октетов.

Страница 8 из 31

2007 - 2022 © Русские переводы RFC, IETF, ISOC.