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

Идентификатор интерфейса и 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 48^{2 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html} . Они очень просты — см. Табл. 3.

То есть между 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 (добавочные байты подчеркнуты).

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

Однако сегодня из документов IEEE однозначно следует, что MAC-48 — это устаревший термин для подмножества EUI- 48^{3 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.

Отлично, теперь вернемся к нашим текущим делам и внимательнее посмотрим на свойства гипотетического адреса 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.

Рис. 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 48EUI-64:

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

   ;
2. EUI 64IPv6:

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

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

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

• Из 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, и в зоне данного канала возникнет конфликт адресов.

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