Enhanced IP
Как оказалось, не все мои знакомые инженеры могут дать ответ на простой вопрос: что это такое — 192.0.0.1.10.0.0.1. Нет, это не ссылка на ветку MIB протокола SNMP (были и такие версии). Сегодня мы поговорим об Enhanced IP (далее EnIP).
Если трезво смотреть на мир, то транспортная сеть состоит из кучи «костылей», чего только стоят такие технологии как nat (во всех его видах) или virtual links в ospf. Прочитав драфт rfc, посвященный EnIP, я понял, что это очередной костыль. Но честно говоря идея мне понравилась. Ну, начнем.
Не буду говорить как тяжело сейчас живется и как мало у нас IPv4 адресов (это все и так уже слышали), а перейду непосредственно к технологии.
Итак, что же такое EnIP. На первый взгляд разработчики взяли два IPv4 адреса и склеили их в один, получив при этом 64 битый адрес вида 192.0.0.1.10.0.0.1. Казалось бы адресное пространство увеличилось более чем в 4 миллиарда: с 2^32 до 2^64, теперь провайдерам не надо переходить на IPv6, IANA может снова раздавать адреса пачками направо и на лево. Но давайте разберемся на сколько реально увеличится адресное пространство. Для этого приведу пару фраз из rfc:
Because it is IPv4, it maximizes backward compatibility while increasing address space by a factor of 17.9 million.
This could allow the reassignment of small segments of unused address blocks in /8 networks to registries with chronic shortages of IP addresses
У нас есть три распределенных блока адресов, который можно перераспределить, не потеряв обратную совместимость между IPv4 и EnIP– это приватные диапазоны 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16. Делаем не сложные подсчеты (2^32×2^24)+(2^32×2^20)+(2^32+2^16) и убеждаемся, что количество маршрутизируемых в интернете адресов увеличится в 17,9 миллионов раз. Конечно, стоит упомянуть, что помимо префикса из приватного адресного пространства 10.0.0.0/8,172.16.0.0/12 и 192.168.0.0/16, необходимо иметь (или получить) хотя бы один глобально маршрутизируемый префикс, иначе ничего не заработает.
Примечание: есть еще префикс 224.0.0.0/4, но он до сих пор не распределен, а в драфте RFC говорится о перераспределении. Может быть когда драфт данного rfc обретет статус официального документа, что то поменяется, но я очень в этом сомневаюсь.
Итак, подведем маленький итог. Что же на самом деле сделали разработчики. Они взяли адреса приватных диапазонов и предложили приделать их ко всем глобально маршрутизируемым префиксам, тем самым увеличив количество доступных для маршрутизации в интернете (так сказать белых) адресов.
Но тогда возникает здравая мысль-как без модернизации стандартного IPv4 заголовка реализовать идею разработчиков, ведь под адреса в IPv4 заголовке выделено 64 бита (32 на source IP и 32 на destination IP): 
Если мы изменим заголовок — то получим не IPv4, а что то новое и неизвестное. В такой ситуации проще сразу перейти на IPv6. Но разработчики нашли выход, который помимо того, что не требует внесения изменения в IP заголовок, еще и не требует больших вложений со стороны провайдеров (необходимо лишь произвести апгрейд софта).
Надеюсь, что все знают, что заголовок IPv4 может быть дополнен несколькими полями опций. В EnIP к 20 байтам основного заголовка добавляется поле опций, длинной 12 байт, таким образом получаем такой заголовок длинной 32 байта: 
Как указано на рисунке поле опций включает два поля под адреса, называемые Extended Source Address и Extended Destination Address. Думаю вы уже поняли основную идею — хоть адрес и представлен в виде одного 64-битного адреса, на самом деле таковым не является и размещается в заголовке в двух полях — поле адреса в заголовке и поле расширенного адреса в опциях. Перейдем непосредственно к механизму работы данной технологии.
Для наглядности будем использовать следующую топологию: 
Условно можно разделить сеть на две зоны: одна зона, где для маршрутизации используется префикс из приватного диапазона 10.0.0.0/8 (от EIP1 до N1, от N2 до EIP2) и зона, где используется глобальный уникальный префикс (от N1 до N2).
Теперь разберем, как будут меняться значения полей в IP заголовке при передаче от узла к узлу.
Узел EIP1 получает от DNS сервера адрес узла EIP2 вида 65.127.221.2.10.3.3.2. (о нюансах работы DNS в данной технологии мы поговорим ниже). Далее узел EIP1 разбивает полученный адрес на два адреса: адрес сайта (site address) 65.127.221.2 (он должен быть глобально маршрутизируемым) и адрес хоста (host address) 10.3.3.2. Составляя пакет, узел EIP1 помешает адрес сайта (65.127.221.2) в поле адреса назначения в заголовке, адрес хоста (10.3.3.2) в поле расширенного адреса назначения в опциях, а так же свой адрес в поле адреса источника в заголовке (10.1.1.2), как показано на иллюстрации ниже: 
Как видно из иллюстрации, extended source address (расширенный адрес источника пакета) не задан. Дело в том, что EIP1 не знает данного адреса (подобно технологии NAT — узел не знает своего глобального уникального адреса), поэтому и подставляет вместо адреса все единицы (255.255.255.255), как это регламентирует RFC:
The Enhanced Source Address in the EnIP header is set to all ones since an EnIP source address is not currently present
Стоит так же обратить внимание на поля флагов ESP и EDP в поле опций. Поднятый флаг в ESP говорит о наличии Enhanced Source Address, а EDP — о наличии Extended Destination Address.
В представленном выше заголовке в поле опций отсутствует расширенный адрес исходящего узла, поэтому флаг ESP выставлен в 0.
Далее пакет с указанным выше заголовком попадает к узлу N1. N1 производит анализ полей заголовка и опций, переносит адрес хоста 10.1.1.2 из заголовка в опции, а вместо Source Address в заголовок вписывает свой глобально маршрутизируемый IPv4 адрес, так же меняет значения флага ESP на 1, так как теперь заданы оба расширенных адреса; пересчитывает контрольную сумму и отправляет пакет в соответствующий интерфейс (поля, которые изменяются выделены зеленым цветом): 
Почему нам необходимо поменять исходящий адрес? Дело в том, что согласно rfc, если в открытом интернете маршрутизатор получит пакет с приватным исходящим адресом или приватным адресом назначения, он должен отбросить этот пакет. То есть имя приватный адрес, пакет просто не будет отправлен в глобальную сеть. Мы этого не хотим, поэтому маршрутизатор меняет приватный адрес на глобально маршрутизируемый
Теперь пакет имеет в заголовке глобально маршрутизируемый адрес назначения и источника в заголовке, что позволит ему беспрепятственно передаваться в интернете, а в опциях сохранена информация о конечных адресах хостов.
Приняв пакет, узел N2 тоже производит анализ заголовка. Так как узел N2 видит, что пакет предназначен ему, он начинает анализировать опции, перемещает адрес хоста (10.3.3.2) из опций в поле адрес назначения заголовка, а поле расширенного адреса в опциях обнуляет (так как теперь в этом поле нет смысла). Так как в заголовок были внесены изменения, N2 должен произвести пересчет контрольной суммы заголовка, а так как в поле extended destination address теперь нет адреса, то N2 также должен сбросить значение флага EDP.
Узел EIP2, приняв пакет, видит что данный пакет получен с адреса 65.127.221.1.10.1.1.2 (адрес сайта 65.127.221.1, адрес узла 10.1.1.2. Зная этот адрес, EIP2 может отправить ответное сообщение узлу EIP1.
Теперь перейдем к еще одному важному звену технологии EnIP — DNS сервер. Для работы описанной технологии необходим DNS сервер, умеющий работать с AAAA записями. По сути нам нужен IPv6 DNS-сервер.
Хост EIP1 делает запрос на определение IP адреса, какого то сайта, к примеру mysite.ru. Данный процесс проиллюстрирован ниже: 
DNS сервер находит в свое базе данных запрошенный адрес сайта mysite.ru и предоставляет информацию в виде… IPv6 адреса. Зачем нам IPv6 префикс? Для начала надо вспомнить, какие адреса IPv6 зарезервированы. Все вспоминать не будем, нам нужен префикс 2001:0101::, который был зарезервирован для экспериментального применения.
Теперь вернемся к полученной от DNS сервера информации. В ответ на наш запрос, мы получили вот такой IPv6 префикс: 2001:0101:417F: DD02:0A03:0302::0. Но зачем он нам? Ответить на этот вопрос мы сможем, если переведем полученный префикс из шестнадцатеричной системы в десятичную: 
Оказывается 417F: DD02:0A03:0302 после перевода из шестнадцатеричной системы в десятичную отображаются как 65.127.221.2.10.3.3.2. Выбраны именно эти группы префикса, так как первые две группы это зарезервированный префикс 2001:0101::, а группы 7 и 8 всегда равны нулям.
Узел EIP1 проделывает показанную выше операцию и получает необходимый для передачи сообщения адрес.
На этом думаю можно закончить с кратким обзором технологии. Если остались вопросы задавайте, попробую на них ответить.
Информация взята из RFC по ссылке в начале статьи. Иллюстрации взяты из презентации по ссылке .
