RFC 2290 Mobile-IPv4 Configuration Option for PPP IPCP

Опубликовано 19.02.1998 автором Nikolai Malykh 
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].

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). Все права защищены.

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

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

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

1Internet Protocol Control Protocol.

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

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

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

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.