RFC 2290 Mobile-IPv4 Configuration Option for PPP IPCP

Network Working Group                                     J. Solomon
Request for Comments: 2290                                  Motorola
Updates: 2002                                               S. Glass
Category: Standards Track                               FTP Software
                                                       February 1998

Конфигурационная опция Mobile-IPv4 для PPP IPCP

Mobile-IPv4 Configuration Option for PPP IPCP

PDF

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

Данный документ содержит спецификацию стандартного протокола Internet, предложенного сообществу Internet, и является приглашением к дискуссии в целях развития этого протокола. Сведения о текущем состоянии стандартизации протокола вы найдете в документе «Internet Official Protocol Standards» (STD 1). Документ можно распространять без ограничений.

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

Copyright (C) The Internet Society (1998). All Rights Reserved.

Тезисы

Mobile IP [RFC 2002] определяет независимые от среды процедуры, с помощью которых мобильный узел (Mobile Node) может поддерживать имеющиеся соединения транспортного и прикладных уровней, независимо от точки подключения к сети Internet и без необходимости смены адреса IP. Протокол PPP [RFC 1661] обеспечивает стандартный метод транспортировки пакетов разных протоколов через канал «точка-точка». В настоящее время внешние агенты Mobile IP Foreign Agent, которые поддерживают соединения Mobile Node через PPP, могут делать это лишь после присвоения мобильным узлам уникальных адресов, что сводит на нет основное преимущество использования внешних агентов. Данный документ решает эту проблему за счет определения опции Mobile-IPv4 Configuration Option для протокола IPCP1 [RFC 1332]. При использовании этой опции два партнера могут согласовать поддержку Mobile IP на этапе IPCP протокола PPP. Предполагается знакомство читателя с протоколами Mobile IP [RFC 2002], IPCP [RFC 1332] и PPP [RFC 1661].

Оглавление

Исключено в версии HTML

1. Введение

Mobile IP [RFC 2002] определяет протоколы и процедуры, с помощью которых пакеты могут маршрутизироваться мобильному узлу независимо от его текущей точки подключения к Internet и без замены его IP-адреса. Mobile IP разработан для работы во всех типах сред с любыми протоколами канального уровня. Однако взаимодействие между Mobile IP и PPP в настоящее время специфицировано не полностью и зачастую приводит к недопустимому использованию Mobile IP при подключении мобильных узлов к Internet по протоколу PPP.

Данный документ определяет корректное взаимодействие между мобильным узлом [RFC 2002] и точкой, через которую этот узел подключается к Internet по протоколу PPP. Это требует определения новой опции для IPCP [RFC 1332], названной Mobile-IPv4 Configuration Option (описана в данном документе). Мобильный узел и его партнер используют эту опцию для согласования корректного применения Mobile IP через канал PPP.

Опция Mobile-IPv4, определенная в данном документе, предназначена для совместного использования с опцией IP-Address [RFC 1332].

1.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119.

1.2. Терминология

В этом документе используются термины, определенные в [RFC 2002]:

Mobile Node — мобильный узел

Хост или маршрутизатор, который меняет свою точку подключения с одного канала на другой. Мобильный узел может менять свое положение без смены адреса IP; он может продолжать коммуникации с другими узлами Internet, используя свой (постоянный) домашний адрес IP, из любого места при доступности там услуг канального уровня.

Home Agent — домашний агент

Маршрутизатор, имеющий по крайней мере один интерфейс к домашнему каналу мобильного узла. Домашний агент перехватывает пакеты, адресованные на домашний адрес мобильного узла и туннелирует их на реальный адрес (care-of address) мобильного узла, когда тот подключен к чужому каналу. Мобильный узел сообщает домашнему агенту свой реальный адрес с использованием протокола аутентифицированной регистрации, определенного для Mobile IP.

Foreign Agent — внешний агент

Маршрутизатор, имеющий хотя бы один интерфейс к (текущему) чужому каналу мобильного узла. Когда мобильный узел использует адрес care-of внешнего агента, этот агент детуннелирует и доставляет пакеты для мобильного узла, туннелированые домашним агентом этого узла. Внешний агент может также служить маршрутизатором по умолчанию для пакетов от зарегистрированного мобильного узля.

Peer — партнер

PPP-партнер мобильного узла. Этот партнер может поддерживать функциональность домашнего агента, внешнего агента, выполнять функции обоих или не делать ни того, ни другого.

1.3. Проблема

В Mobile IP пакеты, направленные на домашний адрес мобильного узла, маршрутизируются сначала его домашнему агенту — маршрутизатору на домашнем канале мобильного узла, который перехватывает эти пакеты. Домашний агент туннелирует перехваченные пакеты на реальный (care-of) адрес мобильного узла, где пакеты извлекаются из туннеля и доставляются мобильному узлу. Существует два типа адресов care-of:

Co-located Care-of Address — совмещенный адрес

Адрес, выделенный временно самому мобильному узлу. В этом случае мобильный узел является выходной точкой туннеля и сам декапсулирует пакеты, помещенные в туннель его домашним агентом. Co-located Care-of Address может использоваться в каждый момент только для одного мобильного узла.

Foreign Agent Care-of Address — адрес внешнего агента

Адрес внешнего агента, имеющего хотя бы один интерфейс к каналу, через который в настоящее время подключен мобильный узел. В этом случае внешний агент декапсулирует пакеты, помещенные в туннель домашним агентом мобильного узла и доставляет их тому через канал, служащий для подключения этого узла. Foreign Agent Care-of Address может использоваться для одновременного подключения множества мобильных узлов.

В Приложении B документа Mobile IP [RFC 2002] в настоящее время относительно PPP указано лишь:

Протокол PPP [RFC 1661] и его IPCP [RFC 1332] согласуют использование IP-адресов.

Мобильному узлу следует сначала попытаться указать свой домашний адрес чтобы при подключении мобильного узла к его домашней сети немаршрутизируемый канал работал корректно. Если домашний адрес не воспринимается партнером и мобильному узлу динамически выделяется временный адрес IP, а сам узел способен поддерживать совмещенный адрес (co-located care-of address), мобильный узел может зарегистрировать этот адрес в качестве co-located care-of address. Когда партнер указывает свой адрес IP, этот адрес недопустимо трактовать, как адрес внешнего агента или IP-адрес домашнего агента.

Анализ этого текста показывает отсутствие возможности использования мобильным узлом адреса внешнего агента (foreign agent care-of address) без предварительного присвоения уникального адреса IP даже при поддержке партнером функций внешнего агента. Это послужило причиной организации процесса согласования IPCP:

  1. Мобильный узел подключается к партнеру по протоколу PPP и предлагает свой домашний адрес в запросе IPCP Configure-Request, содержащем опцию IP-Address. В этом сценарии предполагается, что мобильный узел подключен к некому чужому (foreign) каналу.

  2. Партнер не имеет возможности узнать был ли получен запрос Configure-Request от: (a) мобильного узла, предложившего свой домашний адрес, или (b) обычного узла, предложившего некий топологически немаршрутизируемый адрес. В таком случае партнер должен (консервативно) отправить подтверждение Configure-Nak для опции IP-Address, содержащее топологически приемлемый адрес для использования узлом на другой стороне канала PPP.

  3. Мобильный узел, в свою очередь, не имеет возможности узнать получено ли подтверждение Configure-Nak от партнера по причине того, что тот является консервативным внешним агентом или просто совсем не поддерживает Mobile IP. Следовательно, мобильный узел должен (консервативно) предположить, что партнер не поддерживает Mobile IP и продолжить согласование IP-адреса в IPCP, после чего может использовать выделенный адрес в качестве совмещенного (co-located care-of address).

Здесь мы можем видеть, что даже в том случае, когда партнер мобильного узла является внешним агентом и передает анонс Agent Advertisement мобильному узлу после перехода IPCP в состояние Opened, мобильный узел будет получать на этапе 3 согласованный маршрутизируемый адрес, который уже используется в качестве совмещенного (co-located care-of address). Это препятствует использованию адреса внешнего агента (foreign agent care-of address), который предназначен для совместного использования множеством мобильных узлов и исключения необходимости использования уникального адреса для каждого мобильного узла.

1.4. Требования

Целью этого документа является спецификация поведения обеих сторон канала PPP, когда хотя бы один из партнеров PPP поддерживает Mobile IP. Организация опции и протокола, определенных в данном документе основаны на следующих требованиях:

  1. Описанные опция и протокол должны обеспечивать совместимость с традиционными (обычными) узлами и их потенциальными партнерами, которые не поддерживают ни эту опцию, ни иную функциональность Mobile IP.

  2. Опция и протокол должны приспосабливаться к разным сценариям (как минимум, к описанным в примерах параграфа 2.6).

  3. Опция и протокол не должны дублировать какие-либо функции уже имеющиеся в других опциях IPCP (в частности, опции IP-Address).

  4. Мобильному недопустимо присваивать уникальный адрес без абсолютной необходимости. В частности, такие адреса не присваиваются мобильным узлам, подключающимся по каналу PPP к своей домашней сети, а также к внешним агентам (используя адрес этого агента).

2. Конфигурационная опция Mobile-IPv4

В этом разделе определена конфигурационная опция Mobile-IPv4 и приведены примеры ее использования.

2.1. Формат опции

Конфигурационная опция Mobile-IPv4 для IPCP имеет вид:

    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     |         Mobile Node's ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         ...  Home Address         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

4 (Mobile-IPv4)

Length

6 (размер всего расширения в байтах)

Mobile Node’s Home Address

В Configure-Request домашний IP-адрес мобильного узла, передающего эту опцию, а в остальных случаях (не измененный) домашний IP-адрес мобильного узла, который передан в Configure-Ack или Configure-Reject. Подтверждение Configure-Nak для данной опции не определено и его передача недопустима для реализаций, соответствующих данной спецификации. Недопустимо нулевое значение этого поля.

Значение по умолчанию

По умолчанию в конфигурационной опции Mobile-IPv4 передается домашний адрес мобильного узла.

При описании работы конфигурационной опции Mobile-IPv4 (а также опции IP-Address) используются следующие обозначения:

Типы сообщений PPP:

Request = Configure-Request

Reject = Configure-Reject

Ack = Configure-Ack

Nak = Configure-Nak

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

MIPv4 = Mobile-IPv4

IP = IP-Address

Адреса IP:

a.b.c.d = некий адрес IP, отличный от 0

w.x.y.z = некий адрес IP, отличный от 0 и a.b.c.d

home = домашний IP-адрес мобильного узла

coa = IP-адрес Care-Of

0 = IPадрес, состоящий из нулей (0.0.0.0)

2.2. Обзор

Конфигурационная опция Mobile-IPv4 предназначена для использования совместно с опцией IP-Address. Для удобства разработчиков подробное описание в параграфе 2.5 включает все возможные комбинации этих двух опций, которые могут быть переданы партнером PPP в процессе IPCP. Каждая комбинация сопровождается описание интерпретации опций получателем, а также указанием рекомендуемых действий.

2.3. Требования верхних уровней для узлов, не являющихся мобильными

Узлам без функциональности мобильных (не поддерживающие Mobile-IP, выполняющие функции домашнего или внешнего агента, а также обе функции сразу) недопустимо включать конфигурационную опцию Mobile-IPv4 в какие-либо сообщения Configure-Request. В соответствии с [RFC 1332] таким узлам следует передавать запросы Configure-Request, содержащие опцию IP-Address, в которой поле IP-Address задает отличный от нуля адрес IP, который ghbcdjty узлом для одного из своих интерфейсов. Если явный адрес IP был присвоен интерфейсу PPP на узле, этот адрес следует использовать в качестве предпочтительного в передаваемых сообщениях.

Узлу недопустимо передавать подтверждения Configure-Nak с опцией Mobile-IPv4. Такое действие в настоящее время «не определено» и может вызывать проблемы совместимости, хотя использование Configure-Nak в конечном итоге явно полезно для Mobile-IPv4. Узлу, который передает Configure-Ack с опцией Mobile-IPv4, следует передавать анонс Agent Advertisement [RFC 2002] сразу же после перехода IPCP в состояние Opened.

2.4. Требования верхних уровней для мобильных узлов

Мобильному узлу следует начинать согласование IPCP с передачи запроса Configure-Request, описанного в параграфе 2.5 (1 или 4). При соответствующих (смягчающих) обстоятельствах мобильный узел может начинать согласование с других элементов, описанных в параграфе 2.5.

Мобильный узел, получивший подтверждение Configure-Ack с опцией Mobile-IPv4, должен получить анонс Agent Advertisement (возможно, в ответ на Agent Solicitation) до передачи запроса Registration Request [RFC 2002], если этот узел подключен к чужому каналу. Это обусловлено тем, что партнером может оказаться внешний агент, который применяет политику, требующую регистрации мобильного узла на данном агенте, если узел использует совмещенный адрес (co-located care-of). Мобильный узел может не ожидать такого анонса при подключении к домашнему каналу. Один из способов детектирования подключения к домашнему каналу описан в п. 7a параграфа 2.5. Другой путь заключается в явном уведомлении от партнера (таком, как получения сообщений в пп. 1b, 2c и 3a параграфа 2.5).

Мобильному узлу, получившему отказ Configure-Reject с опцией Mobile-IPv4, следует вернуться к согласованию IPCP, используя опцию IP-Address [RFC 1332]. Следует начинать такое согласование с Request(IP=home) или Request(IP=0), в зависимости от того, подключен мобильный узел к домашнему или чужому каналу, соответственно. Мобильный узел может определить вариант подключения, проверяя опцию IP-Address в запросе Configure-Request от партнера. Если префикс указанного партнером адреса IP совпадает с префиксом домашнего адреса мобильного узла, узел может считать подключение домашним. В противном случае, когда узел подключен к чужому каналу, ему следует передать Request(IP=0), поскольку у партнера может не оказаться иной возможности выделения адреса кроме IPCP. Данная спецификация меняет это поведение, как описано в [RFC 2002], где мобильному узлу рекомендуется начинать согласование IP-Address с передачи Request(IP=Home) во всех случаях.

Партнеру, не поддерживающему функциональности ни домашнего, ни внешнего агента, следует передать Reject в ответ на любой запрос Request от своего партнера с конфигурационной опцией Mobile-IPv4.

2.5. Подробное описание

Пронумерованные элементы ниже показывают все возможные комбинации конфигурационных опций Mobile-IPv4 и IP-Address, которые мобильный (или обычный) узел может передать своему партнеру. Мобильным узлам следует начинать согласование IPCP с 1 или 4 в зависимости от предпочтения совмещенного адреса (co-located) или адреса внешнего агента (foreign agent care-of), соответственно. Помеченные буквами элементы перечисляют возможные корректные отклики, которые партнер может передать мобильному (или обычному) узлу в обмен на Request.

В каждом случае указана интерпретация и выбор предлагаемых действий. Предполагается, что выбранная форма представления является более точной и понятной по сравнению с «прозаической формой».

  1. Request(IP=0,MIPv4=home) означает: «Я предпочитаю совмещенный адрес адресу внешнего агента.» Партнер должен ответить одним из следующих вариантов:

    1. Nak(IP=coa) означает: «Используйте coa в качестве вашего совмещенного адреса.» Далее 2.

    2. Nak(IP=home) означает: «Вы дома и совмещенный адрес не нужен.» Далее 3.

    3. Reject(IP=0) означает: «Невозможно выделить совмещенный адрес, но вы можете воспользоваться адресом внешнего агента.» Далее 4.

    4. Reject(MIPv4=home) означает: «Не поддерживается опция Mobile-IPv4.» Если партнер передал также Request(IP=address) и префикс выделенного им адреса совпадает с префиксом домашнего адреса мобильного узла, переход к 6 с a.b.c.d=home, в остальных случаях переход к 5.

    5. Reject(IP=0,MIPv4=home) означает: «Используйте принятый по умолчанию.» Далее 7.

      => Ack(IP=0, …), Nak(MIPv4=any, …) недопустимо передавать.

  2. Request(IP=coa,MIPv4=home) означает: «Я хочу использовать coa в качестве совмещенного адреса.» Партнер должен ответить одним из следующих вариантов:

    1. Ack(IP=coa,MIPv4=home) означает: «Хорошо, используйте coa в качестве совмещенного адреса и дождитесь анонса.» Opened.

    2. Nak(IP=alternate-coa) означает: «Нет, возьмите в качестве совмещенного адреса alternate-coa.» Далее 2.

    3. Nak(IP=home) означает: «Вы дома и нет нужды применять совмещенный адрес.» Далее 3.

    4. Reject(IP=coa) означает: «coa не является подходящим в качестве совмещенного адреса на этом канале и я не могу выделить другой подходящий адрес (или не буду согласовывать опцию IP-Address) – вы можете использовать меня в качестве внешнего агента.» Далее 4.

    5. Reject(MIPv4=home) означает: «Я не поддерживаю опцию Mobile-IPv4.» Если партнер передает также Request(IP=address) и префикс партнерского адреса совпадает с префиксом домашнего адреса мобильного узла, переход к 6 с a.b.c.d=home, в остальных случаях переход к 5.

    6. Reject(IP=coa,MIPv4=home) означает: «Используйте принятое по умолчанию.» Далее 7.

      => Nak(MIPv4=any, …) недопустимо передавать.

  3. Request(IP=home,MIPv4=home) означает: «Я полагаю, что нахожусь дома, но, если я ошибаюсь, предпочел бы совмещенный адрес адресу внешнего агента.» Партнер должен ответить одним из следующих вариантов:

    1. Ack(IP=home,MIPv4=home) означает: «Да, вы дома.» Opened.

    2. Nak(IP=coa) означает: «Вы не дома, используйте coa в качестве совмещенного адреса.» Далее 2.

    3. Reject(IP=home) означает: «Вы не дома и я не могу выделить совмещенный адрес (или не могу согласовать опцию IP-Address) — вы можете использовать меня в качестве внешнего адреса.» Далее 4.

    4. Reject(MIPv4=home) означает: «Я не поддерживаю опцию Mobile-IPv4.» Если партнер передает также Request(IP=address) и префикс партнерского адреса совпадает с префиксом домашнего адреса мобильного узла, переход к 6 с a.b.c.d=home, в остальных случаях переход к 5.

    5. Reject(IP=home,MIPv4=home) означает: «Используйте принятое по умолчанию.» Далее 7.

      => Nak(MIPv4=any, …) недопустимо передавать.

  4. Request(MIPv4=home) означает: «Я хочу использовать Mobile IP на этом канале, но не хочу пользоваться совмещенным адресом.» Партнер должен ответить одним из следующих вариантов:

    1. Ack(MIPv4=home) означает: «Хорошо, ждите анонса для выяснения вашего местоположения.» Opened.

    2. Reject(MIPv4=home) означает: «Я не поддерживаю опцию Mobile-IPv4.» Если партнер передает также Request(IP=address) и префикс партнерского адреса совпадает с префиксом домашнего адреса мобильного узла, переход к 6 с a.b.c.d=home, в остальных случаях переход к 5.

      => Nak(MIPv4=any, …) недопустимо передавать.

  5. Request(IP=0) означает: «Пожалуйста выделите адрес/совмещенный адрес.» Партнер должен ответить одним из следующих вариантов:

    1. Nak(IP=a.b.c.d) означает: «Используйте a.b.c.d в качестве своего адреса/совмещенного адреса.» Далее 6.

    2. Reject(IP=0) означает: «Я не могу выделить адрес (для использования мобильным узлом в качестве совмещенного) или не поддерживается опция IP-Address.» Далее 7.

      => Ack(IP=0) недопустимо передавать. Исторически это означает; «Я совсем не знаю вашего адреса.» Opened. Реализации недопустимо использовать 0 в качестве своего адреса IP после получения Ack(IP=0), но можно использовать некий отличный от 0 адрес интерфейса для пакетов, передаваемых через интерфейс PPP.

  6. Request(IP=a.b.c.d) означает: «Я хочу использовать a.b.c.d в качестве адреса/домашнего адреса,совмещенного адреса.» Партнер должен ответить одним из следующих вариантов:

    1. Ack(IP=a.b.c.d) означает: «Хорошо, a.b.c.d будет вашим адресом/домашним адресом/совмещенным адресом.» Opened.

    2. Nak(IP=w.x.y.z) означает: «Нет, используйте w.x.y.z в качестве адреса/домашнего адреса,совмещенного адреса.» Далее 6.

    3. Reject(IP=a.b.c.d) означает: «a.b.c.d не подходит для использования, но я не могу дать вам подходящего адреса.» или «Я не поддерживаю опцию IP-Address.» Далее 7.

  7. Request() означает: «Я хочу использовать принятый по умолчанию адрес.» Партнер должен ответить одним из следующих вариантов:

    1. Ack() означает: «Хорошо, используйте его.» Opened.

      В этом случае мобильный узел будет использовать «принятые по умолчанию» значения опции IP-Address (адрес не задан с помощью IPCP) и Mobile-IPv4 (домашний IP-адрес мобильного узла). Мобильному узлу следует предать Agent Solicitation, чтобы увидеть присутствуют ли на текущем канале2 какие-либо агенты. Если агент имеется и мобильный узел получает анонс Agent Advertisement, мобильный узел использует свои алгоритмы детектирования перемещений и регистрируется соответствующим образом.

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

      В противном случае мобильный узел может предпринять попытку получения топологически маршрутизируемого адреса любым из поддерживаемых способов (например, DHCP, настройка вручную и т.п.) для использования этого адреса в качестве совмещенного. Если мобильный узел получит такой адрес, ему следует зарегистрировать адрес у своего домашнего агента.

      => Nak(IP=0) недопустимо передавать. Далее 6.

      => Nak() недопустимо передавать.

      => Reject() недопустимо передавать.

2.6. Примеры

Этот параграф иллюстрирует применение протокольных опций, определенных выше. В приведенных примерах одной строкой показаны запрос Configure-Request, который передает мобильный узел, а также полученный от партнера отклик. Буквы и цифры слева от каждой пары «запрос-отклик» соответствуют нумерации параграфа 2.5.

A. Мобильный узел предпочитает совмещенный адрес, партнер является внешним агентом, способным дать такой адрес:

(1)(a) Request(IP=0,MIPv4=Home) / Nak(IP=coa)

(2)(a) Request(IP=coa,MIPv4=Home) / Ack(IP=coa,MIPv4=Home)

  • Мобильный узел ждет приема анонса Agent Advertisement.

  • Если (в Advertisement установлен бит R), то

    мобильный узел регистрирует использование совмещенного адреса через внешнего агента;

    иначе

    мобильный узел регистрирует использование совмещенного адреса напрямую с домашним агентом.

B. Мобильный узел предпочитает совмещенный адрес, но партнером является внешний агент, который не может выделить такого адреса (например, не имеет блока адресов для распрределения):

(1)(c) Request(IP=0,MIPv4=Home) / Reject(IP=0)

(4)(a) Request(MIPv4=Home) / Ack(MIPv4=Home)

  • IPCP завершается.

  • Мобильный узел ждет анонса Agent Advertisement.

  • Мобильный узел регистрирует использование адреса внешнего агента на своем домашнем агенте.

C. Мобильный узел предпочитает совмещенный адрес, а партнер определил, что домашний адрес мобильного узла такой, как при подключении того к своему домашнему каналу:

(1)(b) Request(IP=0,MIPv4=Home) / Nak(IP=Home)

(3)(a) Request(IP=Home,MIPv4=Home) / Ack(IP=Home,MIPv4=Home)

  • IPCP завершается.

  • Мобильный узел отменяет свою регистрацию с домашним агентом.

D. Мобильный узел предпочитает адрес внешнего агента и партнер является внешним агентом, которого устраивает такой вариант:

(4)(a) Request(MIPv4=Home) / Ack(MIPv4=Home)

  • IPCP завершается.

  • Мобильный узел ждет анонса Agent Advertisement.

  • Мобильный узел регистрирует использование адреса внешнего агента или отменяет домашнюю регистрацию в зависимости от значений в анонсе Agent Advertisement.

E. Мобильный узел предпочитает совмещенный адрес, а партнер не поддерживает опцию Mobile-IPv4. Однако партнер может выделить динамический адрес:

(1)(d) Request(IP=0,MIPv4=Home) / Reject(MIPv4=Home)

(5)(a) Request(IP=0) / Nak(IP=a.b.c.d)

(6)(a) Request(IP=a.b.c.d) / Ack(IP=a.b.c.d)

— IPCP завершается.

— Мобильный узел регистрирует a.b.c.d в качестве совмещенного адреса на своем домашнем агенте.

F. Мобильный узел предпочитает совмещенный адрес, а партнер не поддерживает опцию Mobile-IPv4 и не может выделить динамического адреса.

(1)(e) Request(IP=0,MIPv4=Home) / Reject(IP=0,MIPv4=Home)

(7)(a) Request() / Ack()

— IPCP завершается.

— Мобильный узел передает запрос Agent Solicitation и/или пытается получить совмещенный адрес иным способом без IPCP (например, через DHCP или ручную настройку).

3. Дополнительные требования

3.1. Другие опции IPCP

Мобильным узлам недопустимо включать отмененную опцию IP-Addresses в любые запросы Configure-Request с опцией Mobile-IPv4 или/и IP-Address.

И напротив, мобильный узел может включать опцию IP-Compression-Protocol и любые другие опции, не включающие согласования адресов IP.

Если мобильный узел и внешний или домашний агент согласовали в IPCP использование сжатия заголовков Van Jacobson [RFC 1144], мобильному узлу недопустимо устанавливать бит V в своих запросах Mobile IP Registration Request [RFC 2002]. Если партнер PPP уже использует сжатие заголовков VJ, мобильным узлам не нужно запрашивать компрессию и запрос этой опции может приводить к путанице.

3.2. Детектирование перемещений

Мобильный узел, подключающийся по протоколу PPP, должен корректно реализовать IPCP, поскольку перемещение мобильного узла может приводить к смене его партнера PPP. В частности, мобильные узлы должны быть в любой момент готовы к повторному согласованию IPCP, включая новое согласование конфигурационных опций IP-Address и Mobile-IPv4, описанных в этом документе. Как сказано в [RFC 1661], мобильный узел в состоянии Opened должен повторять согласование IPCP при получении от партнера запроса IPCP Configure-Request.

Отметим также, что некоторые беспроводные сети могут использовать механизмы передачи обслуживания (handoff) и кэширования (proxying), которые позволяют не разрывать соединение PPP, но будут требовать от мобильного узла регистрации на новом внешнем агенте. Следовательно, мобильный узел, подключенный к агенту по протоколу PPP, должен поддерживать алгоритмы детектирования перемещений (см. параграф 2.4.2 в [RFC 2002]) и регистрироваться при детектировании смены подключения.

В частности, мобильный узел, которому не удалось получить от своего текущего внешнего агента анонс Agent Advertisement в течение времени жизни Lifetime, должен предположить потерю контакта с этим агентом (см. параграф 2.4.2.1 в [RFC 2002]). Если в течение этого же времени мобильный узел получил анонс Agent Advertisements от другого внешнего агента, ему следует незамедлительно зарегистрироваться на этом агенте, не дожидаясь тайм-аута для текущего агента.

Точно так же мобильный узел, реализующий детектирование перемещений на основе расширения Prefix-Length, должен сравнивать префикс любых анонсирующих агентов с префиксом текущего внешнего агента (см. параграф 2.4.2.2 в [RFC 2002]). Если такой мобильный узел получает Agent Advertisement от внешнего агента с префиксом, отличающимся от префикса текущего агента, он должен зарегистрироваться на новом внешнем агенте.

Мобильный узел может трактовать организацию соединения PPP как достаточное основание для выполнения новой регистрации Mobile IP. В разделе 2 определены обстоятельства, при которых мобильные узлы должны дождаться анонса Agent Advertisement перед регистрацией. В соответствии с этим внешним и домашним агентам следует передавать анонсы Agent Advertisement через канал PPP сразу же после того, как IPCP для соединения перейдет в состояние Opened.

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

Этот документ не добавляет известных угроз безопасности сверх тех, которые существуют для любого узла Internet, подключенного по протоколу PPP или реализующего Mobile IP. В частности, сервис-провайдерам следует использовать строгую криптографическую аутентификацию (например, CHAP [RFC 1994]) для предотвращения кражи услуг. Пользователям, озабоченным конфиденциальностью, следует применять шифрование для каналов PPP [RFC 1968], шифрование на уровне IP [RFC 1827] или прикладном уровне в зависимости от индивидуальных требований. Аутентификация Mobile IP [RFC 2002] обеспечивает защиту от тривиальных атак на службы (denial-of-service), которые могли быть направлены на мобильные узлы или домашних агентов.

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

[RFC 2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC 1144] Jacobson, V., «Compressing TCP/IP Headers for Low-Speed Serial Links», RFC 1144, January 1990.

[RFC 1332] McGregor, G., «The PPP Internet Protocol Control Protocol (IPCP),» RFC 1332, May 1992.

[RFC 1661] Simpson, W., Editor, «The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links», STD 51, RFC 1661, July 1994.

[RFC 1827] Atkinson, R., «IP Encapsulating Security Payload (ESP)», RFC 18273, August 1995.

[RFC 1994] Simpson, W., «PPP Challenge Handshake Authentication Protocol (CHAP)», RFC 1994, August 1996.

[RFC 1968] Meyer, G., «The PPP Encryption Control Protocol (ECP)», RFC 1968, June 1996.

[RFC 2002] Perkins, C., Editor, «IP Mobility Support», RFC 20024, October 1996.

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

Разработка этого протокола и опции были инициированы давним предложением B. Patel и C. Perkins (в том момент сотрудниками IBM), которое осталось в качестве чернового документа (draft) с истекшим сроком. Часть текста William Simpson была дословно скопирована из [RFC 1661] для обеспечения согласованности терминологии и спецификации. Это же относится к некоторым определениям Charlie Perkins и другим фрагментам из [RFC 2002].

Tim Wilson и Chris Stanaway (Motorola) снесли существенный вклад в разработку спецификации протокола и конфигурационной опции. Особо следует отметить Vernon Schryver (SGI), Craig Fox (Cisco), Karl Fox (Ascend) и John Bray (FTP) за их предложения, комментарии и терпение.

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

Jim Solomon

Motorola, Inc.

1301 E. Algonquin Rd. — Rm 2240

Schaumburg, IL 60196

Phone: +1-847-576-2753

Fax: +1-847-576-3240

EMail: solomon@comm.mot.com

Steven Glass

FTP Software, Inc.

2 High Street

North Andover, MA 01845

Phone: +1-508-685-4000

Fax: +1-508-684-6105

EMail: glass@ftp.com

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

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

nmalykh@gmail.com

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

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1Internet Protocol Control Protocol.

2Текущий «канал» может быть и разделяемой средой, если PPP-партнером мобильного узла является мост.

3Документ признан устаревшим и заменен RFC 2406, который, в свою очередь, заменен на RFC 4303 и RFC 4305. Прим. перев.

4Документ признан устаревшим и заменен RFC 3220. Прим. перев.




RFC 2283 Multiprotocol Extensions for BGP-4

Network Working Group                                       T. Bates
Request for Comments: 2283                             Cisco Systems
Category: Standards Track                                 R. Chandra
                                                       Cisco Systems
                                                             D. Katz
                                                    Juniper Networks
                                                          Y. Rekhter
                                                       Cisco Systems
                                                       February 1998

Многопротокольные расширения для BGP-4

Multiprotocol Extensions for BGP-41

PDF

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

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться без ограничений.

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

Copyright (C) The Internet Society (1998). All Rights Reserved.

2. Тезисы

В настоящее время протокол BGP-4 [BGP-4] подходит только для передачи маршрутной информации протокола IPv4 [IPv4]. В этом документе определяется расширение протокола BGP-4, позволяющее передавать информацию для различных протоколов сетевого уровня (например, IPv6, IPX и т. п.). Расширение обеспечивает обратную совместимость — маршрутизаторы, поддерживающие это расширение, смогут нормально работать с маршрутизаторами, которые его не поддерживают.

3. Обзор

Только три компоненты информации, передаваемой с помощью BGP-4, непосредственно связаны с IPv4: (a) атрибут NEXT_HOP (указывается адресом IPv4), (b) AGGREGATOR (содержит адрес IPv4) и (c) NLRI (выражается префиксом адреса IPv4). В этом документе предполагается, что любой узел BGP (включая те, которые поддерживают описанное здесь расширение) имеет адрес IPv4 (который будет вместе с другими параметрами использоваться в атрибуте AGGREGATOR). Следовательно, для того, чтобы BGP-4 поддерживал маршрутизацию для множества протоколов сетевого уровня, в BGP-4 требуется добавить только два элемента: (a) возможность связывания того или иного протокола сетевого уровня с информацией о следующем интервале (next hop) и (b) возможность связывания протокола сетевого уровня с NLRI. Для идентификации протоколов сетевого уровня данный документ использует значение Address Family (семейство адресов), указанное в [RFC1700].

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

Для обеспечения совместимости с предыдущими спецификациями и упрощения перехода к поддержке многопротокольного расширения в BGP-4 в данном документе используются два новых атрибута — MP_REACH_NLRI2 и MP_UNREACH_NLRI3. Первый атрибут (MP_REACH_NLRI) используется для передачи набора доступных адресов с информацией о следующем интервале, который будет использоваться для пересылки по этим адресам. Второй атрибут (MP_UNREACH_NLRI) служит для передачи наборов недоступных адресатов. Оба эти атрибута являются необязательными и непереходными. Таким образом, узел BGP, не поддерживающий многопротокольное расширение, просто будет игнорировать содержащуюся в этих атрибутах информацию и не станет передавать ее другим узлам BGP.

4. MP_REACH_NLRI (тип 14)

Этот необязательный и непереходный атрибут может использоваться с несколькими целями:

  1. анонсирование партнеру возможного маршрута;

  2. обеспечение маршрутизатору возможности анонсирования адреса сетевого уровня маршрутизатора, который следует использовать как следующий интервал (next hop) на пути к адресату, указанному в поле NLRI4 атрибута MP_NLRI;

  3. обеспечение данному маршрутизатору возможности сообщать о всех или некоторых SNPA5, существующих в локальной системе.

+---------------------------------------------------------+
| Address Family Identifier (2 октета)                    |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 октет)          |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 октет)            |
+---------------------------------------------------------+
| Network Address of Next Hop (перемен.)                  |
+---------------------------------------------------------+
| Number of SNPAs (1 октет)                               |
+---------------------------------------------------------+
| Length of first SNPA (1 октет)                          |
+---------------------------------------------------------+
| First SNPA (variable)                                   |
+---------------------------------------------------------+
| Length of second SNPA (1 октет)                         |
+---------------------------------------------------------+
| Second SNPA (перемен.)                                  |
+---------------------------------------------------------+
| ...                                                     |
+---------------------------------------------------------+
| Length of Last SNPA (1 октет)                           |
+---------------------------------------------------------+
| Last SNPA (перемен.)                                    |
+---------------------------------------------------------+
| Network Layer Reachability Information (перемен.)       |
+---------------------------------------------------------+

Атрибут содержит один или множество триплетов <Address Family Information, Next Hop Information, Network Layer Reachability Information>. Формат представления атрибута показан на рисунке. Назначение полей описано ниже.

Address Family Identifier – идентификатор семейства адресов

Это поле служит для идентификации протокола сетевого уровня, связанного с указанным далее сеетвым адресом. Определенные в настоящий момент значения указаны в документе RFC 17006 (раздел Address Family Numbers).

Subsequent Address Family Identifier – дополнительный идентификатор семейства адресов

Это поле содержит дополнительную информацию о типе NLRI в данном атрибуте.

Length of Next Hop Network Address – размер адреса следующего интервала

1-октетное поле, указывающее размер сетевого адреса следующего интервала (поле Network Address of Next Hop) в октетах.

Network Address of Next Hop – сетевой адрес для следующего интервала

Поле переменной длины, содержащее адрес сетевого уровня для следующего маршрутизатора на пути к получателю.

Number of SNPAs – число точек подключения подсетей

1-октетное поле, содержащее количество различных SNPA, перечисленных в последующих полях. Нулевое значение этого поля говорит об отсутствии SNPA в данном атрибуте.

Length of Nth SNPA — размер n-го SNPA

1-октетное поле, указывающее размер поля Nth SNPA of Next Hop в полуоктетах.

Nth SNPA of Next Hop – n-я SPNA следующего маршрутизатора

Поле переменной длины, содержащее SNPA маршрутизатора, чей сетевой адрес содержится в поле Network Address of Next Hop. Размер поля составляет целое число октетов, равное округленному до большего значению половины размера SNPA, выраженного в полуоктетах; если SNPA включает нечетное количество полуоктетов, значение этого поля дополняется нулевым полуоктетом после значения размера.

Network Layer Reachability Information – информация о доступности на сетевом уровне (NLRI).

Поле переменной длины, содержащее список NLRI для возможных маршрутов, которые будут анонсироваться этим атрибутом. Если поле Subsequent Address Family Identifier содержит одно из значений, определенных в данном документе, каждое значение NLRI кодируется в соответствии с параграфом 6. Представление NLRI данного документа.

Информация о следующем интервале, передаваемая в атрибуте пути MP_REACH_NLRI, определяет адрес сетевого уровня граничного маршрутизатора, который следует использовать в качестве следующего этапа пересылки адресатам, указанным в атрибуте MP_NLRI сообщения UPDATE. При анонсировании атрибута MP_REACH_NLRI внешнему партнеру маршрутизатор может использовать адрес одного из своих интерфейсов в качестве указывающей следующий интервал компоненты атрибута, полученного от внешнего партнера, для которого анонсируемый маршрут имеет общую подсеть с адресом next hop. Это называют «следующим интервалом из первых рук» (first party next hop). Узел BGP может анонсировать внешнему партнеру интерфейс любого внутреннего партнерского маршрутизатора в компоненте next hop, полученной от внешнего партнера, для которого анонсируемый маршрут имеет общую подсеть с адресом next hop. Это называется «следующим интервалом из третьих рук» (third party next hop). Узел BGP может анонсировать любой внешний партнерский маршрутизатор в компоненте next hop, указывающей, что адрес сетевого уровня этого граничного маршрутизатора, который получен от внешнего партнера, и внешний партнер, для которого будет анонсироваться маршрут, имеет общую подсеть с адресом next hop. Это другой вариант «следующего интервала из третьих рук».

Обычно информация о следующем интервале выбирается так, чтобы использовался кратчайший из доступных путей. Узел BGP должен обеспечивать поддержку запрета анонсов информации из третьих рук для обслуживания сред с несовершенными мостами или по соображениям политики.

Для узла BGP недопустимо анонсирование адреса партнера этому же партнеру в качестве следующего интервала для маршрутов, который начинается с данного узла. Для узла BGP недопустимо создание маршрутов с указанием самого себя в качестве следующего интервала.

Когда узел BGP анонсирует маршрут своему внутреннему партнеру, ему не следует изменять связанную с этим маршрутом информацию о следующем интервале. При получении узлом BGP маршрута через внутреннее соединение, он может пересылать пакеты по адресу следующего интервала, если содержащийся в атрибуте адрес имеет общую подсеть с локальным и удаленным узлами BGP.

Сообщение UPDATE, содержащее MP_REACH_NLRI, должно включать также атрибуты ORIGIN и AS_PATH (как для EBGP, так и для IBGP). Более того, при обмене IBGP такие сообщения должны также включать атрибут LOCAL_PREF. Если сообщение получено от внешнего партнера, локальной системе следует убедиться, что самое левое значение AS в атрибуте AS_PATH является номером автономной системы, к которой относится передавший сообщение партнер. Если это условие не выполняется, локальной системе следует передать сообщение NOTIFICATION со значениями Error Code = UPDATE Message Error и Error Subcode = Malformed AS_PATH.

5. MP_UNREACH_NLRI (тип 15)

+---------------------------------------------------------+
| Address Family Identifier (2 октета)                    |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 октет)          |
+---------------------------------------------------------+
| Withdrawn Routes (перемен.)                             |
+---------------------------------------------------------+

Этот дополнительный непереходный атрибут может использоваться для отзыва невозможных маршрутов.

Атрибут содержит один или множество триплетов <Address Family Information, Unfeasible Routes Length, Withdrawn Routes>. Формат атрибута показан на рисунке.

Назначение полей атрибута описано ниже.

Address Family Identifier – идентификатор семейства адресов

Это поле служит для идентификации протокола сетевого уровня, связанного с указанным далее сеетвым адресом. Определенные в настоящий момент значения указаны в документе RFC 17007 (раздел Address Family Numbers).

Subsequent Address Family Identifier – дополнительный идентификатор семейства адресов

Это поле содержит дополнительную информацию о типе NLRI в данном атрибуте.

Withdrawn Routes – отзываемые маршруты

Поле переменной длины, содержащее значения NLRI для отзываемых маршрутов. При установке в поле Subsequent Address Family Identifier одного из определенных в данном документе значений, каждое поле NLRI кодируется в соответствии с параграфом 6. Представление NLRI.

Сообщение UPDATE, содержащее MP_UNREACH_NLRI, может не включать других атрибутов пути.

6. Представление NLRI

+---------------------------+
| Length (1 октет)          |
+---------------------------+
| Prefix (перемен.)         |
+---------------------------+

Информация о доступности на сетевом уровне (NLRI) представляется в форме одной или множества пар <length, prefix>, показанных на рисунке справа.

Назначение каждого поля пар описано ниже.

  1. Length — размер

    Поле Length указывает размер адресного префикса в битах. Нулевой размер показывает, что префикс соответствует всем (как указано для данного семейства) адресам (т. е., сам префикс содержит 0 октетов.

  2. Prefix — префикс

    Поле Prefix включает префикс адреса, за которым следуют нулевые биты заполнения для выравнивания поля по границе октета. Отметим, что нулевые биты заполнения не принимаются во внимание.

7. Дополнительный идентификатор семейства адресов

Этот документ определяет следующие значения поля Subsequent Address Family Identifier для атрибутов MP_REACH_NLRI и MP_UNREACH_NLRI:

1 – NLRI используется для unicast-пересылки (по конкретному адресу);

2 – NLRI используется для групповой пересылки;

3 – NLRI используется для индивидуальной и групповой пересылки.

Этот документ резервирует значения 128-255 для разработчиков (vendor-specific applications).

Документ резервирует значение 0.

Идентификаторы SAFI (отличающиеся от зарезервированных выше для разработчиков) выделяются только по согласованию с IETF после одобрения IESG.

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

Это расширение BGP не оказывает влияния на безопасность.

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

Авторы выражают свою признательность членам рабочей группы IDR за просмотр документа и комментарии.

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

[BGP-4] Rekhter, Y., and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 1771, March 1995.

[IPv4] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC1700] Reynolds, J., and J. Postel, «Assigned Numbers,» STD 2, RFC 170010, October 1994. (see also http://www.iana.org/iana/assignments.html)

11. Сведения об авторах

Tony Bates

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134

EMail: tbates@cisco.com

Ravi Chandra

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134

EMail: rchandra@cisco.com

Dave Katz

Juniper Networks, Inc.

3260 Jay St.

Santa Clara, CA 95054

EMail: dkatz@jnx.com

Yakov Rekhter

Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134

EMail: yakov@cisco.com


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

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

nmalykh@gmail.com

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

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1Этот документ утратил силу и заменен RFC 2858. Перевод имеется на сайте http://www.protocols.ru. Прим. перев.

2Multiprotocol Reachable NLRI

3Multiprotocol Unreachable NLRI

4Network Layer Reachability Information – информация о доступности на сетевом уровне.

5Subnetwork Points of Attachment – точка подключения подсети.

6В соответствии с RFC 3232 этот документ утратил силу. Упомянутые здесь значения доступны на сайте http://www.iana.org/assignments/address-family-numbers. Прим. перев.

7В соответствии с RFC 3232 этот документ утратил силу. Упомянутые здесь значения доступны на сайте http://www.iana.org/assignments/address-family-numbers. Прим. перев.

8Этот документ утратил силу и заменен RFC 4271. Перевод имеется на сайте www.protocols.ru. Прим. перев.

9Перевод этого стандарта имеется на сайте www.protocols.ru. Прим. перев.

10В соответствии с RFC 3232 этот документ утратил силу STD 2 и выделенные номера в настоящее время доступны в базе данных по ссылке http://www.iana.org/numbers.html. Указанная в оригинале ссылка на сайт также утратила актуальность. Прим. перев.