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

Форматы адресов IPv6

< Лекция 2 || Лекция 3: 123456 || Лекция 4 >

Расширение возможностей групповой адресации с помощью индивидуальных адресов

В §2.8 мы обнаружили, что даже области действия не защитят от конфликтов, когда независимые пользователи группового вещания IPv6 выбирают себе временно занятые адреса из одной и той же зоны. Так, например, все мы находимся в одной глобальной зоне, и произвольный выбор глобального временно занятого адреса заведомо чреват конфликтом, даже если вероятность его низка. Чтобы пользователи группового вещания IPv6 не работали по принципу "авось пронесет", нужен глобальный арбитр, который бы управлял распределением и оборотом глобальных временно занятых адресов. Но кто возьмет на себя этот труд и связанные с ним расходы? Добровольцев пока нет, и даже не предвидится. В конечном итоге, именно об это препятствие разбились все попытки создать выделенную систему управления временно занятыми групповыми адресами в Internet.

Из таких попыток стоит упомянуть протокол MADCAP (multicast address dynamic client allocation protocol) [RFC 2730], который имеет статус предлагаемого стандарта. Тем не менее, насколько нам известно, распространения он так и не получил [§3.5 RFC 6308].

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

Для работы в Internet нового поколения конечному пользователю нужен, по меньшей мере, глобальный индивидуальный адрес IPv6, но гораздо лучше будет выделить ему целый префикс. Ведь, как мы сказали еще в §2.1, адресов IPv6 достаточно много, чтобы поощрять пользователей к созданию целых сетей вокруг себя. Для распределения индивидуальных префиксов уже создана международная система, включающая в себя IANA, несколько RIR и множество LIR. Одна из ее задач состоит как раз в том, чтобы обеспечить уникальность выдаваемых префиксов и избежать каких-либо конфликтов в подпространстве индивидуальных адресов.

Теперь обратим внимание, что выданный пользователю индивидуальный префикс должен быть не длиннее стандартного префикса подсети IPv6 (64 бита — см. §2.7), так как подсеть дальше не делится. В противном случае пользователь вряд ли сможет найти применение выданному префиксу.

Поэтому каждый пользователь, законным путем получивший глобальный индивидуальный префикс IPv6, может составить заведомо уникальный групповой адрес, взяв за основу идентификатора группы свой префикс, например, поместив его в старшие биты такого идентификатора. Длина идентификатора группы составляет 112 бит, а этого с запасом достаточно, чтобы вместить любой индивидуальный префикс IPv6. Максимальная длина такого префикса — /64, так что пользователю даже остается 48 бит идентификатора группы, которыми он может распоряжаться по своему усмотрению, а это означает 2^48 глобально уникальных групп!

  • во-первых, возможен конфликт между двумя сообществами пользователей, когда одни станут производить временно занятые групповые адреса от своих префиксов, а другие продолжат выбирать их наугад;
  • во-вторых, префиксы могут быть разной длины, и, скажем, 2001:DB8:a1ef::/48 — не одно и то же, что 2001:DB8:a1ef::/64, поскольку длина префикса — его неотъемлемый атрибут. Вдобавок, нам не следует забывать, что система распределения префиксов — многоуровневая, и владелец префикса 2001:DB8:a1ef::/48 вполне может отличаться от владельца 2001:DB8:a1ef::/64, хотя они и находятся на одной вертикали иерархии: последний получил префикс от первого, возможно, через посредников.

К счастью, это проблемы практического характера, и нам вполне по силам их решить. Так, для решения первой проблемы достаточно, чтобы эти два сообщества пользователей оперировали непересекающимися подмножествами адресов. Обеспечить это способен еще один бит в поле флагов группового адреса, обозначаемый P. Пусть значение P по умолчанию, то есть нулевое, означает прежний, анархический способ выделения — или, скорее уж, захвата — временно занятых адресов. Напротив, если в групповом адресе IPv6 P = 1, то перед нами адрес, основанный на уникальном индивидуальном префиксе. Очевидно, что установленный флаг P имеет смысл только при T = 1, так как речь идет только о временно занятых адресах. В противном случае значение флага P должно быть нулевым. Вот мы и справились с первой проблемой.

Вторую проблему тоже решить несложно. В идентификаторе группы остались незанятыми 48 бит, и мы можем "отрезать" от них поле длины префикса, а уж остальные биты достанутся пользователю. Так как префикс может быть длиной от 0 до 64 бит включительно, нам понадобится минимум 7 бит, чтобы представить все возможные значения целым беззнаковым полем. Но ради удобства пользователей и программистов мы расширим это поле до целого байта, то есть 8 бит.

Не востребованные немедленно значения диапазона пригодятся для расширений. Например, особое значение длины префикса 255 означает внутриканальный групповой адрес, основанный на идентификаторе интерфейса [RFC 4489]. Хост может сам создать такой адрес, например, для нужд Zeroconf.

В результате мы получаем изображенный на рис. 2.8 формат группового адреса, основанного на индивидуальном префиксе (unicast-prefix-based multicast address, UBM) [RFC 3306]. Несмотря на сокращение поля доступных бит, пользователь получает в свое распоряжение 32 бита, что тоже весьма неплохо!

Формат адреса UBM

Рис. 2.8. Формат адреса UBM

Откуда взялось поле "резерв" между кодом области и длиной префикса, мы, по правде говоря, не знаем. Возможно, оно выравнивает поле "префикс сети" на границу 32 бит, чтобы такие адреса было удобнее составлять. Как и у всех полей "резерв", его биты обязаны быть нулевыми.

Адреса UBM определены не только в IPv6, но и в IPv4 [RFC 6034].

Например, обладатель глобального префикса 2001:DB8:D0D0::/47 получит в свое нераздельное пользование все групповые адреса общего вида FF3x:002F:2001:DB8:D0D0:0:zzzz:zzzz, где x — любой допустимый код области (см. Табл. 4 на стр. 41), а zzzz:zzzz — произвольный идентификатор группы.

Можно сказать, что вместе с индивидуальным префиксом 2001:DB8:D0D0::/47 его обладатель получил все групповые префиксы FF3x:002F:2001:DB8:D0D0::/96, где x — допустимый код области. Любой технический автор может свободно распоряжаться всеми адресами UBM, основанными на префиксе для документации 2001:DB8::/32 и его дочерних префиксах большей длины [§3.1 RFC 6676].

Благодаря удачному выравниванию все элементы адреса видны невооруженным глазом. В частности, 002F — это длина префикса (47), записанная по основанию 16, а сам префикс находится сразу за полем длины. Интересным свойством адресов UBM будет то, что по значению адреса легко определить, из какой сети он произошел, хотя сама группа может включать в себя интерфейсы из разных сетей по всему миру.

Нам осталось поставить последний штрих в этой схеме, ответив на такой вопрос: как быть, если индивидуальный префикс — не глобальный, а меньшей области? Допустим, к примеру, что он внутрисайтовый. Откуда пользователь взял его? Скорее всего, пользователь принадлежит какой-то организации, или части организации, сеть которой основана на внутрисайтовых адресах и представляет собой зону величины "сайт". В этой организации тоже есть ответственный за распределение адресного пространства, например, администратор сети или отдел технического обеспечения. Именно он и выдал пользователю префикс, уникальный в пределах данного сайта. Поэтому произведенный от такого префикса групповой адрес тоже будет уникальным в пределах сайта. Выходит, что групповые адреса, основанные на неглобальных префиксах, получат право на существование, если мы ограничим их хождение зоной префикса. Для этого нам достаточно ввести такое правило: область группового адреса, основанного на индивидуальном префиксе, должна быть не больше, чем область самого префикса [§4 RFC 3306]. Например, пользователь может создать на основе внутрисайтового индивидуального префикса групповые адреса с областями "интерфейс", "канал", "администратор" и "сайт", а вот "организация" и "вселенная" — не имеет права.

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

Закончив с этим решением, посмотрим на возможные альтернативы ему. Так, в некоторых прикладных задачах достаточно, чтобы групповой трафик исходил из единственного источника. Например, к этому типу относятся задачи вещания, построенного по той же схеме, что радио и телевидение: у так называемого канала вещания (channel) есть ровно один источник и от нуля до бесконечности слушателей. Этот режим заметно отличается от традиционного группового вещания IP, когда любой источник может передавать пакеты данной группе.

При вещании из одного источника идентификатором последнего выступает адрес IP. Если той же группе станет вещать источник с другим адресом, то это будет другой канал вещания. Поэтому идентификатором канала вещания выступает упорядоченная пара (S,G), где S — адрес источника, а G — адрес группы назначения. Например, в этом режиме узел-слушатель проверяет, адресован ли ему данный групповой пакет, не по списку групп G, в которых он состоит на входном интерфейсе, а по списку каналов вещания (S,G) на этом интерфейсе. Поэтому данный режим называют групповое вещание с настройкой источника (source-specific multicast, SSM) [RFC 4607].

По аналогии, традиционный режим, когда вещать группе может любой источник — это групповое вещание из произвольного источника (any-source multicast, ASM) [§2 RFC 3569].

Есть ли у адресации SSM какие-нибудь интересные особенности? В режиме SSM уникальным должен быть канал (S,G). Иными словами, каналы (S_1, G_1 и (S_2, G_2 совпадают, только если   и  . Поэтому, если вещают источники и , где S_1\ne S_2, то все их каналы автоматически будут разными, независимо от выбранного адреса назначения G. А значит, в режиме SSM источнику не надо заботиться об уникальности адреса G! Точнее, разные адреса назначения , и т.д. понадобятся только разным каналам одного и того же источника S.

Возможен и промежуточный режим, когда слушатели принимают групповые пакеты только от заданного множества источников. Его называют групповое вещание с фильтрацией источника (source-filtered multicast, SFM) [§2 RFC 3569]. В простейшем случае этот режим можно реализовать локально, в самих слушателях, как программируемый фильтр пакетов. Однако из соображений эффективности сеть группового вещания тоже участвует в этой фильтрации, чтобы не передавать групповой трафик туда, где его все равно потом отбросят. В частности, IGMPv3 и MLDv2 (§6.4) поддерживают SFM. По своей адресации SFM гораздо ближе к ASM, чем к SSM, так как по-прежнему оперирует группами с уникальным адресом G, тогда как источник S интересен только фильтру.

Единственная наша проблема состоит в том, что до сих пор мы говорили о типах группового вещания как о режимах. Означает ли это, что каждой реализации сетевого стека IPv6 понадобится тумблер ручного управления с положениями "ASM" и "SSM"? Конечно, это было бы очень неудобно и даже глупо. Сетевой стек должен сам отличать на входе групповые пакеты, переданные в режиме ASM, от пакетов, переданных в режиме SSM.9 Такое решение будет в духе архитектурных принципов Internet §3.8 RFC 1958. Тогда и источник сможет выбирать режим для каждой передачи отдельно, по запросу приложения. Пока мы работаем над адресами IPv6, давайте закодируем различие между ASM и SSM в адресе назначения G. Иными словами, адресу G в составе канала SSM нужна отличительная черта, которая выделит его среди обычных групповых адресов ASM.

Можно сказать, что каналы (S,G) в чем-то родственны групповым адресам UBM: и здесь, и там индивидуальный адрес или префикс составляет часть группового адреса. Только у вторых индивидуальный префикс "зашит" непосредственно в групповой адрес назначения, тогда как у первых индивидуальный адрес передается отдельно — по видимому, в поле "источник" заголовка IPv6, над которым нам еще предстоит работать. Поэтому вряд ли кто-то возразит, если мы сделаем адрес назначения SSM частным случаем группового адреса UBM.

Поставив себя на место IANA, мы пожертвуем пустым префиксом нулевой длины ::/0 ради SSM10 Ведь пустой префикс ::/0 находится в безраздельном ведении IANA. . То есть, когда в групповом адресе IPv6 T = 1 и P = 1, а поле "длина префикса" равно нулю, как на рис. 2.9, то перед нами адрес SSM. Нетрудно подсчитать, что все адреса SSM охвачены префиксами FF3x::/96, где x — допустимый код области из Табл. 4 на стр. 41. В каждой области доступно 2^32 адресов, что не так уж и много по современным меркам. Однако особенность адресации SSM такова, что эти адреса полностью доступны каждому источнику SSM, поскольку адрес источника тоже входит в окончательный идентификатор канала вещания.

Формат группового адреса SSM

Рис. 2.9. Формат группового адреса SSM
Как можно заметить, сама идея SSM никак не зависит от особенностей IPv6. Поэтому неудивительно, что механизм SSM определен и для IPv4 [RFC 4607]. Адресам SSM выделен блок 232.0.0.0/8 .11 http://www.iana.org/assignments/ipv6-multicast-addresses/

Последний наш вопрос по SSM традиционно будет насчет областей. В канале (S,G) элементы S и G — это не что иное, как адреса IPv6, и у каждого из них есть определенные область и зона действия. Нужны ли особые правила, связывающие эти области и зоны? На самом деле, нет — достаточно универсального правила, основанного на принципе изоляции зон из §2.4: интерфейс источника S должен находиться в зоне адреса G, а все интерфейсы G — в зоне адреса S.

В завершение раздела отметим, что значение поля "идентификатор группы" у всех адресов с T = 1, включая UBM и SSM, ограничено диапазоном 0x8000 0000–0xFFFF FFFF на уровне политики распределения групповых адресов [§4.3 RFC 3307]. Зачем это было сделано, мы увидим в §4.1.1, когда рассмотрим разрешение групповых адресов IPv6 в адреса MAC.

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

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

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

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

 

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

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