RFC 1332 The PPP Internet Protocol Control Protocol (IPCP)

Network Working Group                                    G. McGregor
Request for Comments: 1332                                     Merit
Obsoletes: RFC 1172                                         May 1992

Протокол IPCP

The PPP Internet Protocol Control Protocol (IPCP)

PDF

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

Данный RFC задает проект стандартного протокола IAB для сообщества Internet и служит приглашением к дискуссии и развитию протокола. Состояние стандартизации протокола можно найти в документе IAB Official Protocol Standards. Документ может распространяться без ограничений.

Аннотация

Протокол PPP¹ [1] обеспечивает стандартный метод инкапсуляции данных протокола сетевого уровня (Network Layer) для соединений «точка-точка». PPP также определяет расширяемый протокол управления каналом LCP² и предлагает семейство протоколов управления сетью (NCP³) для организации и настройки разных протоколов сетевого уровня.

Данный документ определяет NCP для организации и настройки IP [2] через PPP, а также метод согласования и применения компрессии заголовков TCP/IP [3] Van Jacobson для протокола PPP.

Данный RFC является результатом работы группы Point-to-Point Protocol по эгидой IETF⁴.

1. Введение

PPP состоит из трех основных компонент:

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

2. Протокол управления каналом (LCP) для организации, настройки и проверки соединений канального уровня.

3. Семейство протоколов управления (NCP) для организации и настройки разных протоколов сетевого уровня.

Для организации связи через канал «точка-точка» каждая из сторон соединения PPP должна сначала передать пакеты LCP для настройки и проверки канала данных. После организации канала и согласования дополнительных возможностей в соответствии с потребностями LCP протокол PPP должен передать пакеты NCP для выбора и настройки одного или множества протоколов сетевого уровня. После настройки выбранных протоколов сетевого уровня через канал могут передаваться дейтаграммы этого протокола.

Канал будет сохранять коммуникационные настройки до тех пор, пока явные пакеты LCP или NCP не закроют соединение или пока не произойдет некое внешнее событие (например, тайм-аут или действия администратора).

2. Протокол NCP для IP

Протокол IPCP⁵ отвечает за настройку конфигурации и отключение модулей протокола IP на обеих сторонах соединения «точка-точка». IPCP использует такой же механизм обмена пакетами, какой применяется в LCP. Обмен пакетами IPCP становится возможным только после перехода протокола PPP в фазу Network-Layer Protocol. Полученные до этого пакеты IPCP следует отбрасывать без уведомления.

Протокол IPCP имеет некоторые отличия от протокола LCP [1]:

Поле Protocol в кадрах канального уровня

В точности один пакет IPCP инкапсулируется в поле Information кадров канального уровня PPP, где поле Protocol содержит шестнадцатеричное значение 8021 (IP Control Protocol).

Поле Code

Используются коды от 1 до 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack и Code-Reject). Остальные коды следует трактовать, как нераспознанные и возвращать в Code-Reject.

Тайм-ауты

Обмен пакетами IPCP не может происходить, пока PPP не достигнет фазы Network-Layer Protocol. Реализациям следует быть готовыми к ожиданию завершения Authentication и Link Quality Determination, не фиксируя тайм-аут ожидания Configure-Ack или иного отклика. Реализация предлагается фиксировать тайм-аут только после вмешательства пользователя или по истечении заданного в конфигурации времени.

Типы конфигурационных опций

IPCP имеет свой набор конфигурационных опций, которые определены ниже.

2.1. Передача дейтаграмм IP

До того, как начнется передача каких-либо пакетов IP, протокол PPP должен достигнуть фазы Network-Layer Protocol, а протокол IPCP – состояния Opened.

В точности один пакет IPCP инкапсулируется в поле Information кадров канального уровня PPP, где поле Protocol содержит шестнадцатеричное значение 0021 (Internet Protocol).

Максимальный размер пакета IP, передаваемого по каналу PPP, совпадает с максимальным размером поля Information в кадрах канального уровня PPP. Более крупные дейтаграммы IP должны фрагментироваться. Если система желает предотвратить фрагментацию и сборку фрагментов, ей следует использовать опцию TCP MSS⁶ [4] и механизм MTU discovery [5].

3. Конфигурационные опции IPCP

Конфигурационные опции IPCP позволяют согласовать желаемые параметры протокола IP. IPCP использует такой же формат Configuration Option, какой определен для LCP [1], но со своим набором опций.

Большинство актуальных значений поля IPCP Option Type указано в действующей редакции документа Assigned Numbers [6]. В настоящее время выделены значения:

1 IP-Addresses

2 IP-Compression-Protocol

3 IP-Address

3.1. IP-Addresses

Использование конфигурационной опции IP-Addresses не рекомендуется. Опыт показал, что достаточно сложно обеспечить схождение при согласовании этой опции для всех ситуаций. В RFC 1172 [7] приведены данные для реализаций, которым нужна совместимость со старыми версиями. Взамен данной опции предложена конфигурационная опция IP-Address и ее применение является предпочтительным.

Эту опцию не следует передавать в запросах Configure-Request при получении запроса Configure-Request с опцией IP-Addresses или IP-Address. Опцию можно передавать при получении отказа Configure-Reject для опции IP-Address или подтверждения Configure-Nak с опцией IP-Addresses, добавленной в конце.

Поддержка этой опции может быть исключена после получения протоколом IPCP статуса Internet Draft Standard.

3.2. IP-Compression-Protocol

Эта конфигурационная опция обеспечивает способ согласования использования конкретного протокола сжатия. По умолчанию компрессия отключена.

Формат опции IP-Compression-Protocol показан ниже. Поля передаются в порядка «слева направо».

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     IP-Compression-Protocol   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+

Type

2

Length

>= 4

IP-Compression-Protocol

Поле IP-Compression-Protocol занимает два октета и указывает желаемый протокол компрессии. Значения для этого поля совпадают со значения поля PPP Data Link Layer Protocol для того же протокола сжатия.

Актуальные значения поля IP-Compression-Protocol указаны в последнем документе Assigned Numbers [6]. В настоящее время определено значение:

Шестнадцатеричное значение	Протокол
002d	Van Jacobson Compressed TCP/IP

Data

Поле Data может содержать дополнительные данные, определяемые конкретным протоколом сжатия.

Параметры, используемые по умолчанию

Протокол сжатия не используется.

3.3. IP-Address

Эта конфигурационная опция обеспечивает способ согласования адреса IP, который будет применяться на локальной стороне канала. Опция позволяет отправителю Configure-Request указать, какую опцию IP-address он желает получить, или запросить у партнера предоставление информации. Партнер может предоставить эту информацию, подтверждая (NAK) опцию или возвращая корректную опцию IP-address.

Если требуется согласование опции IP-address на удаленной стороне и партнер не включил опцию в свой Configure-Request, опцию следует добавить в конце Configure-Nak. Значение IP-address должно быть приемлемо на удаленной стороне или указывать на запрос информации от партнера.

По умолчанию IP-адрес не присваивается.

Формат конфигурационной опции IP-Address показан ниже. Поля опции передаются в порядке «слева направо».

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |           IP-Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           IP-Address (продолжение)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

3

Length

6

IP-Address

4-октетное поле IP-Address указывает желаемый локальный адрес отправителя Configure-Request. Если все октеты имеют нулевые значения, это говорит о запросе информации IP-Address у партнера.

Параметры, используемые по умолчанию

IP-адрес не присваивается.

4. Компрессия заголовков TCP/IP Van Jacobson

Компрессия Van Jacobson для заголовков TCP/IP уменьшает размер заголовков вплоть до 3 байтов. Это может быть существенно для медленных последовательных линий, особенно при интерактивном трафике.

Конфигурационная опция IP-Compression-Protocol служит для индикации возможности приема пакетов со сжатыми заголовками. Если нужно сжатие в обоих направлениях, каждая сторона должна независимо запросить эту опцию.

При передаче пакетов IP значение поля PPP Protocol устанавливается в соответствии с приведенной ниже таблицей.

Шестнадцатеричное значение
21	Type IP. Пакет не относится к TCP, содержит фрагмент или не может быть сжат.
002d	Compressed TCP. Заголовки TCP/IP сжаты.
002f	Uncompressed TCP. Поле IP protocol заменено идентификатором слота.

4.1. Формат конфигурационной опции

Формат конфигурационной опции IP-Compression-Protocol для согласования компрессии Van Jacobson для заголовков TCP/IP показан ниже. Поля опции передаютсяв порядке «слева направо».

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     IP-Compression-Protocol   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Max-Slot-Id  | Comp-Slot-Id  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

2

Length

6

IP-Compression-Protocol

002d (шестнадцатеричное) для сжатых по методу Van Jacobson заголовков TCP/IP.

Max-Slot-Id

Поле Max-Slot-Id размером 1 октет показывает максимальный идентификатор слота. Число реальных слотов на 1 больше, поскольку они нумеруются от 0 до Max-Slot-Id.

Примечание: Могут возникать проблемы с реализациями, поддерживающими единственный слот (Max-Slot-Id = 0), как описано в работе [3]. Например, реализация [3] будет работать только с номерами слотов от 3 до 254.

Comp-Slot-Id

Однооктетное поле Comp-Slot-Id показывает возможность сжатия поля идентификатора слота.

0 Идентификатор слота не может быть сжат. Все сжатые пакеты TCP должны иметь установленный бит C в каждой маске изменений и включать идентификатор слота.

1 Идентификатор слота может быть сжат.

Идентификатор слота не допускается сжимать, если на канальном уровне PPP отсутствует возможность индикации ошибки при получении для модуля декомпрессии. Синхронизация после ошибки зависит от получения пакета с идентификатором слота (см. обсуждение в работе [3]).

Приложение A. Рекомендуемые опции IPCP

Рекомендуется использовать показанные ниже конфигурационные опции:

IP-Compression-Protocol — не менее 4 слотов (обычно, 16).

IP-Address — только для коммутируемых телефонных линий.

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

Вопросы безопасности не рассматриваются в этом документе.

Литература

[1] Simpson, W., “The Point-to-Point Protocol”, RFC 1331⁷, May 1992.

[2] Postel, J., “Internet Protocol”, RFC 791, USC/Information Sciences Institute, September 1981.

[3] Jacobson, V., “Compressing TCP/IP Headers”, RFC 1144, January 1990.

[4] Postel, J., “The TCP Maximum Segment Size Option and Related Topics”, RFC 879, USC/Information Sciences Institute, November 1983.

[5] Mogul, J., and S. Deering, “Path MTU Discovery”, RFC 1191, November 1990.

[6] Reynolds, J., and J. Postel, “Assigned Numbers”, RFC 1060⁸, USC/Information Sciences Institute, March 1990.

[7] Perkins, D., and R. Hobby, “Point-to-Point Protocol (PPP) initial configuration options”, RFC 1172, August 1990.

Благодарности

Часть текста документа заимствована из RFC 1171 и RFC 1172, подготовленных Drew Perkins из Carnegie Mellon University и by Russ Hobby из University of California в Davis.

Информацию для введения опции IP-Compression предоставил Van Jacobson на конференции SIGCOMM ’90.

Bill Simpson помог с форматированием документа.

Адрес руководителя группы

С рабочей группой можно связаться через ее руководителя:

Brian Lloyd

Lloyd & Associates

3420 Sudbury Road

Cameron Park, California 95682

Phone: (916) 676-1147

EMail: brian@ray.lloyd.com

Адрес автора

Связанные с этим документом вопросы следует направлять по адресу:

Glenn McGregor

Merit Network, Inc.

1071 Beal Avenue

Ann Arbor, MI 48109-2103

Phone: (313) 763-1203

EMail: Glenn.McGregor@Merit.edu

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

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

nmalykh@protokols.ru

---