Опубликован: 30.07.2013 | Уровень: для всех | Доступ: платный
Лекция 3:

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

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

Идентификатор интерфейса и EUI 64

Фиксируя длину идентификатора интерфейса, мы подразумевали, что теперь это поле сможет вместить в себя канальный адрес в формате EUI 64. Это было бы в высшей степени удобно, ведь адреса EUI 64 призваны быть глобально уникальными — по крайней мере, пока они получены у IEEE. Например, чтобы автоматически назначить интерфейсу уникальный внутриканальный адрес1 Разумеется, ему достаточно уникальности в пределах канала. , в первом приближении будет достаточно соединить префикс FE80::/64. и адрес EUI 64 этого интерфейса. Например, интерфейс с адресом EUI 64 00-11-22-33-44-55-66-77 получил бы, по такой предварительной схеме, внутриканальный адрес FE80::11:2233:4455:6677.

Однако не все канальные адреса — EUI 64. Как быть, если канальный адрес интерфейса отвечает другому стандарту? Это тоже не беда, так как вполне можно сформулировать правило отображения таких адресов в EUI 64. Пока в исходном адресе меньше 64 битов, это отображение может быть инъективным; то есть разные исходные адреса могут быть отображены в разные адреса EUI 64. Простейший и наиболее удобный для нас вид такого отображения — это инкапсуляция исходного адреса в EUI 64. К примеру, ее правила уже заданы для адресов EUI 48 и MAC 482 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html . Они очень просты — см. Табл. 3.

Таблица 2.1. Отображение EUI-48 и MAC-48 в EUI-64
Тип адреса Исходный вид Отображение в EUI 64
EUI 48 xx-yy-zz-ww-vv-tt xx-yy-zz-FF-FE-ww-vv-tt
MAC 48 xx-yy-zz-ww-vv-tt xx-yy-zz-FF-FF-ww-vv-tt

То есть между OUI и добавочным идентификатором возникают еще два байта с определенными значениями: FF-FE в случае EUI-48 и FF-FF в случае MAC 48. Например, из EUI-48 02-35-AB-00-64-C1 получится такой EUI 64: 02-35-AB-FF-FE-00-64-C1 (добавочные байты подчеркнуты).

По этой причине IEEE не разрешает производителям оборудования расходовать добавочные идентификаторы EUI-64, которые начинаются с FF-FE и FF-FF.

Постойте, а в чем состоит разница между EUI-48 и MAC-48? Пока мы не запутались в этом вопросе, давайте изучим его современную интерпретацию, потому что она нам сейчас же понадобится. Оба типа адресов находятся в ведении IEEE. По первоначальной задумке, MAC 48 служили канальными адресами IEEE 802, а EUI 48 — идентификаторами в прочих технологиях. Вначале IEEE даже допускал, что пространства этих адресов могут быть разными, несмотря на одинаковый формат.

Циник заметил бы, что IEEE хотел продать одни и те же байты дважды.

Однако сегодня из документов IEEE однозначно следует, что MAC-48 — это устаревший термин для подмножества EUI- 483 Guidelines for use of the 24-bit Organizationally Unique Identifiers (OUI). IEEE. http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html . Так что мы вправе говорить "EUI-48", подразумевая "MAC-48 и Все-все-все". Кроме того, нам можно забыть о правиле преобразования MAC-48 в EUI-64 и пользоваться только правилом для EUI-48.

Придирчивый читатель может заметить, что адрес и идентификатор — не одно и то же. Тем не менее, идентификатор может быть адресом при соблюдении дополнительных условий. Например, в классической технологии Ethernet идентификатор может быть адресом благодаря тому, что изначально Ethernet был широковещательной средой. В этих условиях адрес мог не обладать свойствами локатора; ему не нужно было отвечать на вопрос: "Где находится данный узел?" Эта особенность не могла не наложить отпечаток на последующее развитие коммутируемого Ethernet: именно из-за нее коммутаторам Ethernet приходится динамически изучать расположение станций на своих портах.

Отлично, теперь вернемся к нашим текущим делам и внимательнее посмотрим на свойства гипотетического адреса IPv6, автоматически полученного соединением префикса подсети и идентификатора EUI-64. Благодаря уникальности EUI-64, мы надеемся, что полученный адрес IPv6 окажется уникальным; но как мы сможем гарантировать, что на другом узле тот же самый адрес не будет назначен вручную?

Поясним наше опасение примером. Допустим, что к одному каналу подключены два узла IPv6, А и Б. Их интерфейсам требуются внутриканальные адреса. Узел А получает внутриканальный адрес от нас, а узел Б пытается выбрать его автоматически, располагая адресом EUI-64 на своем интерфейсе. Мы решили назначить узлу А адрес FE80::11:2233:4455:6677. Как нам удостовериться, что узел Б не выберет тот же самый адрес? Заранее убедиться, что его EUI-64 не равен 00-11-22-33-44-55-66-77? Очевидно, что такая "автоматика" недорого стоит, потому что мы обеспечиваем ее работу вручную. Представьте, что таких узлов не два, а тысяча, и 999 из них выбирают адрес автоматически, на основе EUI-64. Неужели нам придется обойти все 999 узлов, чтобы правильно выбрать тысячный адрес?

Чтобы разрешить это затруднение, нам надо вспомнить, что мы знаем об адресе MAC 48, он же EUI 48. Такой адрес обладает определенной структурой, и, к нашему счастью, она сохранилась в EUI 64 без изменений, с точностью до длины поля "добавочный идентификатор", как это показано на рис. 2.5.

Формат OUI и соответствие между разными типами EUI

Рис. 2.5. Формат OUI и соответствие между разными типами EUI

Сейчас основной интерес для нас представляет бит U/L, он же u, который отличает адреса, выданные глобально (полученные из рук IEEE), от адресов, назначенных локально (по усмотрению администратора сети). Второй бит, который нам придется учитывать в дальнейшем, — бит I/G, он же g, — отличает групповые адреса от индивидуальных. Преобразование из EUI 48 в EUI 64 сохраняет эти биты. Благодаря биту U/L мы можем избежать конфликтов хотя бы с EUI-64, назначенными производителем аппаратуры. Например, в EUI-64 00-11-22-33-44-55-66-77 этот бит сброшен, а значит, это глобальный идентификатор, и нам следует избегать его. И наоборот, EUI-64 02-11-22-33-44-55-66-77 — локальный, так что мы можем выбрать его в качестве идентификатора интерфейса, не опасаясь конфликта с адресом какой-нибудь сетевой карты.

Обобщим эту мысль: идентификатор интерфейса в адресе IPv6 должен основываться на идентификаторе EUI-64 и наследовать его формат. Однако если мы перенесем этот формат без изменений, то окажется, что мы больше не вправе назначать интерфейсам простые, короткие номера: 2001:DB8::1, 2001:DB8::2 и т.д. Ведь если мы рассмотрим, к примеру, число 1 с позиций EUI-64, то это окажется 00-00-00-00-00-00-00-01 — глобально выданный идентификатор, и мы нарушим наше собственное правило. Иначе говоря, нам придется всегда устанавливать битU/L в идентификаторах интерфейсов, которые мы выдумываем сами, например, 2001:DB8::1 нам придется заменить на 2001:DB8:0:0:200:0:0:1.

Как нам избежать этого неудобства? Возможный выход здесь — это задать взаимно однозначное отображение между настоящим EUI-64 и идентификатором интерфейса IPv6. Ведь нас никто не заставляет точно копировать формат EUI-64 — нам достаточно сохранить содержащуюся в нем информацию. Правило этого отображения очевидно: инвертировать бит U/L, с тем чтобы удобные короткие идентификаторы 1, 2, 3… стали доступны для локального назначения. В результате мы получаем так называемый модифицированный формат EUI-64 (modified EUI 64 format), который отличается от EUI 64 только интерпретацией значений бита U/L: теперь 0 означает "локальный", а 1 — "глобальный" [§2.5.1 и Приложение A RFC 4291].

Окончательное требование таково: идентификатор интерфейса в адресе IPv6 обязан отвечать модифицированному формату EUI-64. Это правило распространяется на все индивидуальные адреса IPv6 кроме блока ::/3, зарезервированного для особых целей [§2.5.1 RFС 4291].

Чтобы по этому правилу "изготовить" из EUI-64 адрес IPv6, надо сначала инвертировать бит U/L, а затем добавить перед полученной цепочкой битов (то есть в старших разрядах) данный префикс подсети.

Тогда аналогичный рецепт для EUI 48 (MAC 48) может быть комбинацией двух уже известных нам шагов: сначала от EUI 48 к EUI 64, а затем от EUI 64 к IPv6:

  1. EUI 48\toEUI-64:

    а)вставить между третьим и четвертым байтами EUI 48 (то есть между OUI и добавочным идентификатором) последовательность двух байтов FF-FE

    ;
  2. EUI 64\toIPv6:

    а)инвертировать бит U/L;

    б)присоединить спереди префикс подсети.

Любителям истории будет небезынтересно узнать, что в те времена, когда разработчики IPv6 впервые сформулировали правила для работы с модифицированным форматом EUI 64, MAC 48 и EUI 48 считались разными сущностями. Тогда разработчики IPv6 допустили ошибку в прочтении документов IEEE и перепутали алгоритмы преобразования MAC 48 и EUI 48 в EUI 64: говоря о MAC 48, они привели алгоритм для EUI 48, который и вошел в реализации IPv6. (См. замечание в конце Приложения A RFC 4291.) Впоследствии были разговоры о том, не исправить ли эту [ошибку4 См. обсуждение "RFC 3513 EUI-48/MAC-48 confusion" в списке рассылки IETF IPng: http://www.atm.tut.fi/list-archive/ipng/msg10039.html ],5 См. обсуждение "why 0xFFFE is used in the modified EUI-64 format" в списке рассылки IETF IPv6: http://www.ietf.org/mail-archive/web/ipv6/current/msg06035.html но оказалось проще оставить все как есть. И, наконец, сегодня EUI-48 и MAC 48 слились воедино, и все неожиданно встало на свои места, а старая ошибка превратилась в мудрый выбор.

Вот несколько примеров прямого преобразования:

  • Из EUI 64 00-11-22-33-44-55-66-77 и префикса 2001:DB8::/64 получается адрес IPv6 2001:DB8::211:2233:4455:6677.
  • Из EUI 48 (или MAC 48) 10-20-30-40-50-60 и внутриканального префикса (FE80::/64) получается внутриканальный адрес IPv6 FE80::1220:30FF:FE40:5060.

Возможен и обратный анализ:

  • Адрес IPv6 2001:DB8::D00F — назначен локально, так как бит U/L в идентификаторе интерфейса сброшен.
  • Адрес IPv6 2001:DB8::200:FF:FE00:D00F — получен из глобального EUI 48 00-00-00-00-D0-0F.
  • Адрес IPv6 2001:DB8::200:0:0:D00F — получен из глобального EUI 64 00-00-00-00-00-00-D0-0F.

Хотя большая часть локальных идентификаторов интерфейса (U/L = 0) доступна администраторам и пользователям для их собственных нужд, среди них есть несколько зарезервированных [RFC 5453]. Объяснить, откуда они возникают, мы сможем позже. В частности, зарезервировано нулевое значение, 0000:0000:0000:0000.

В завершение раздела зададим себе такой вопрос: достаточно ли сформулированных нами правил, чтобы автоматически гарантировать уникальность адреса IPv6? Для ответа на него рассмотрим вот какой сценарий. Представим себе, что к одному каналу подключены два интерфейса, А и Б, причем интерфейсу А заранее назначен локальный EUI-64 02-00-00-00-00-00-00-01 — это вполне законно. Далее администратор сети назначает интерфейсу Б внутриканальный адрес IPv6 FE80::1. Он тоже имеет на это полное право, потому что такой адрес отвечает нашим требованиям. И наконец узел, управляющий интерфейсом А, автоматически назначает своему интерфейсу внутриканальный адрес IPv6 на основе уже доступного EUI 64. Как нетрудно видеть, это окажется то же самый адрес FE80::1, и в зоне данного канала возникнет конфликт адресов.

Корень проблемы здесь состоит в том, что локально назначенные идентификаторы интерфейсов IPv6 неявно занимают ячейки в подмножестве локальных идентификаторов EUI-64.

Вот мы и обнаружили как минимум один проблемный случай — применение локальных EUI-64. Это значит, что автоматическое назначение адресов IPv6 останется ненадежным, пока мы целенаправленно не поработаем над механизмом предотвращения конфликтов. Тем не менее, структура идентификатора интерфейса на основе EUI-64 сыграет роль хорошего фундамента для наших последующих разработок — в этом мы убедимся в §5.4.

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

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

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

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

 

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

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

Александр Худышкин
Александр Худышкин
Россия
Константин Второв
Константин Второв
Россия, Бокситогорск, ЛГОУ им. А.С.Пушкина, 2003