Опубликован: 30.07.2013 | Доступ: свободный | Студентов: 1862 / 145 | Длительность: 24:05:00
Лекция 5:

IPv6 в стеке протоколов

< Лекция 4 || Лекция 5: 123456 || Лекция 6 >
PPP

Пример канального протокола, поддержка IPv6 в котором неизбежно требует дополнительной работы, — это PPP. Чтобы обеспечить высокий уровень услуг, PPP готовит канал к работе каждого сетевого протокола, например, согласуя адреса на его концах. Это задание PPP делегирует дочернему протоколу семейства NCP. Уже существующий NCP для IP, IPCP [RFC 1332], может работать только с адресами длиной 32 бита, так что он не годится для IPv6. Посему для IPv6 необходим свой собственный NCP — IPV6CP [RFC 5072].

Прежде всего, назначим IPv6 и его NCP уникальные номера из реестра параметров PPP7 http://www.iana.org/assignments/ppp-numbers , чтобы кадры PPP с ними можно было однозначно демультиплексировать. У IPv6 это 0x0057, а номер его NCP по традиции на 0x8000 больше, то есть 0x8057. Теперь мы можем инкапсулировать оба протокола в PPP, и пора подумать над функциями IPv6CP.

Какое задание, специфичное именно для IPv6, мы можем поставить перед IPV6CP? По нашей задумке (см. §2.7), сетевому интерфейсу IPv6 в высшей степени полезно иметь какой-то эквивалент адреса EUI 64, чтобы на его основе можно было создать условно уникальный идентификатор интерфейса. Хорошо, когда у интерфейса есть настоящий, глобально уникальный EUI 64. Канальный адрес MAC 48 — тоже неплохой вариант, потому что его можно превратить в EUI 64 по общепринятому рецепту, который мы обсудили в §2.7. Но как быть с PPP, где явных канальных адресов вообще нет? Ведь каналу PPP вполне достаточно неявной адресации: всякий кадр PPP, переданный в канал, будет принят узлом на другом конце канала, и только им. Вот пусть это и будет работой IPV6CP: согласовать два уникальных идентификатора на концах канала PPP. Так как в конечном итоге нам нужны идентификаторы интерфейса в формате "модифицированный EUI 64", то пусть IPV6CP согласует непосредственно их, а не промежуточные EUI 64 или MAC 48.

Каким требованиям должны удовлетворять эти идентификаторы [§4.1 RFC 5072]?

  • Идентификаторы интерфейсов на концах канала обязаны быть разными. В то же время, глобальная уникальность им совершенно не требуется. Ведь уникальность составленных из них адресов IPv6 обеспечит префикс подсети, назначенный каналу.

    Зона уникальности полученных адресов IPv6 будет зависеть от области действия префикса подсети: из глобального префикса мы получим глобально уникальные адреса, из внутрисайтового префикса — адреса, уникальные в пределах данного сайта, а из внутриканального префикса — внутриканальные адреса для данного канала PPP.

  • Желательно, чтобы идентификаторы были постоянными и не менялись, к примеру, при перезагрузке узлов. Каждый узел вправе использовать все доступные ему источники уникальности, чтобы построить такой идентификатор. В первую очередь, на эту роль претендуют аппаратные адреса EUI 64 и MAC 48 других сетевых интерфейсов узла. Если таковых нет, то следующий кандидат — это серийные номера основных компонентов узла. Наконец, как крайнее средство, идентификатор все же может быть случайным.
  • Составляя идентификатор, узел обязан соблюдать формат "модифицированный EUI 64" (см. §2.7). В частности, бит U/L нужно установить в единицу тогда, и только тогда, когда идентификатор создан на основе настоящего глобального адреса EUI 64 или MAC 48, назначенного именно этому узлу. Само преобразование EUI 64 и MAC 48 в "модифицированный EUI 64" мы уже подробно обсудили там же, в §2.7.

Само согласование идентификаторов представляет собой простой и доступный пример работы механизма опций PPP. В данном случае достаточно сообщений Conf Req, Conf Rej, Conf Nak и Conf Ack (см. Табл. 4.1), а код соответствующей опции IPV6CP — 1 [§4 RFC 5072].

Таблица 4.1. Сообщения IPV6CP при согласовании идентификатора интерфейса
Сообщение Смысл Допустимые варианты ответа
Запрос
Conf-Req Источник хотел бы присвоить себе (не удаленной стороне!) такой-то идентификатор интерфейса (прилагается к сообщению). Пока что это пробный идентификатор (tentative identifier), потому что источник только испытывает его. Если идентификатор в сообщении нулевой, то источник не может сам справиться с выбором и просит удаленную сторону о помощи. Conf Rej, Conf Nak, Conf Ack
Варианты ответа
Conf-Rej Источник вообще не поддерживает данную опцию. Удаленная сторона должна продолжить согласование сообщением Conf-Req без этой опции или прервать сеанс. Conf-Req
Conf-Nak Источник поддерживает опцию, но не удовлетворен ее значением. Видимо, значение было нулевым, или источник сам хотел назначить себе такой же идентификатор. Поэтому источник предлагает удаленной стороне свой вариант ее, удаленной стороны, идентификатора (прилагается к сообщению). Удаленная сторона должна рассмотреть этот вариант и послать новый Conf-Req. Conf-Req
Conf-Ack Источник отвечает, что согласен с выбором удаленной стороны, поскольку он не нулевой и отличается от пробного идентификатора самого источника. На этом согласование завершено. Нет

Как мы помним, согласование опции PPP проходит независимо в каждом из двух возможных направлений. Поэтому стороны А и Б ведут два, на первый взгляд, независимых диалога IPV6CP. Итогом одного из них будет идентификатор стороны А, а другого — идентификатор стороны Б.

Механизм согласования IPV6CP допускает следующий сценарий: узел Б объявляет нулевой идентификатор, и тогда узел А подбирает идентификатор не только для себя, но и для удаленного узла Б. В этом случае бит U/L в идентификаторе для Б надо сбросить, даже если он получен из глобального EUI 64. Ведь этот EUI 64 принадлежит узлу А, а не узлу Б. (Как исключение, этот бит можно установить в единицу, если узел А имел в запасе еще один глобальный EUI 64, а теперь передает его узлу Б в безраздельное пользование на время данного сеанса PPP [§4.1 RFC 5072].)

Чтобы процесс согласования идентификаторов не зациклился, сформулируем несколько дополнительных правил поведения стороны IPV6CP:

  • не повторяться, то есть не предлагать один и тот же идентификатор дважды в Conf Req или Conf Nak;

    Тем не менее, идентификатор, который уже фигурировал в Conf-Nak, вполне может появиться в ответном Conf-Req. Однако в этом случае идентификатор придет от удаленной стороны, а мы говорим о поведении одной стороны, которую мы по традиции считаем нашей локальной.

  • не капризничать, то есть соглашаться с первым же подходящим идентификатором:

    если идентификатор в принятом нами Conf Req не совпадает с нашим собственным пробным значением, которое мы объявили в исходящем Conf Req, то мы немедленно соглашаемся с ним, отвечая Conf Ack. Так мы соглашаемся с выбором удаленной стороны для нее самой;

    если идентификатор во входящем Conf-Nak не совпадает с тем, что мы сами предложили удаленной стороне в последнем переданном нами Conf Nak, то мы обязаны принять его в качестве нашего пробного значения и выслать об этом Conf Req. Здесь мы соглашаемся с предложением удаленной стороны для нас.

    Обратите внимание, как между встречными диалогами IPV6CP возникает скрытая зависимость. Чтобы правильно ответить на входящее сообщение Conf Req, нам надо помнить наш собственный пробный идентификатор, который мы наверняка сами объявили в исходящем Conf Req. А правильная реакция на входящий Conf Nak возможна только при условии, что мы запомнили значение опции из посланного нами самими Conf Nak.

Эти правила склоняют согласование идентификаторов к одному из двух вероятных путей:

  • или обе стороны с самого начала выбирают себе разные пробные идентификаторы и просто соглашаются друг с другом;
  • или же сначала возникает конфликт пробных идентификаторов, вслед за которым стороны предлагают разные идентификаторы друг другу.

Конечно, конфликт может возникнуть больше одного раза подряд, но вероятность этого события низка. Точнее, она может быть высокой, но только если мы имеем дело с неудачной реализацией протокола. В частности, возможен перманентный конфликт, если стороны выбирают одно и то же пробное значение, а затем используют один и тот же детерминистический алгоритм, чтобы генерировать новые пробные значения для себя и партнера. Но на этом "патологическом" случае мы останавливаться не будем. У любой современной системы есть достаточно источников уникальности или случайности, а в крайнем случае она может запросить идентификатор у удаленной стороны, передав нулевое значение в своем первом сообщении Conf Req.

Поэтому, если обе стороны передают нулевые значения в своих сообщениях Conf Req, согласование надо немедленно прекратить ради устойчивости протокола [§4.1 RFC 5072].

< Лекция 4 || Лекция 5: 123456 || Лекция 6 >
Сергей Субботин
Сергей Субботин

"Теоретически канал с адресацией EUI 64 может соединить порядка 2^63 "

запись вида 2^63  не понятна и отнимает время на попытку ее осмыслить.

ее можно заменить например на записи вида  264  или 1,8 * 1019

 

Павел Афиногенов
Павел Афиногенов

Курс IPv6, в тексте имеются ссылки на параграфы. Разбиения курса на параграфы нет.