Как работает multihoming с ipv6?

Каковы различия между множественной адресацией в IPv4 и IPv6?

Может ли предприятие запросить независимое от провайдера адресное пространство IPv6 из своего RIR / LIR, которое может быть объявлено нескольким вышестоящим провайдерам через BGP, как в IPv4?

Являются ли правила запроса независимого от поставщика распределения IPv6 одинаковыми для всех RIR?

Вы действительно можете запросить независимое от поставщика назначение (PI) в местном RIR через LIR. Маршрутизация блока адресного пространства IPv6 выполняется с помощью BGP так же, как и блок адресного пространства IPv4. Блок только немного больше :-)

Для IPv4 обычно, что блок, меньший чем / 24 (то есть префикс / 25 или более длинный), не будет обычно маршрутизироваться ISP. В IPv6 общим пределом в наши дни является / 48.

Каждый RIR имеет свою собственную политику, поэтому вам придется взглянуть на RIR в вашем собственном регионе, чтобы узнать подробности. Если вы оказались в регионе обслуживания RIPE NCC, я могу ответить на любые ваши вопросы.

Похоже, что это тот подход, к которому стремятся многие компании, но цель дизайна IPv6 состояла в том, чтобы не дать компаниям, кроме компаний однорангового размера (например, Google), получить независимые от поставщика блоки для уменьшения размера таблицы глобальной маршрутизации. ,

Хосты IPv6 должны иметь возможность обрабатывать несколько адресов для каждого интерфейса, и было задумано, чтобы множественная адресация работала, чтобы каждый выходной маршрутизатор предприятия объявлял блок (как правило, / 48 или / 56) доступным через свою восходящую линию связи, а также для маршрутизаторов. внутри предприятия добавить глобальный префикс (обычно читаемый через DHCPv6) к независимому от префикса номеру подсети. Перенос хостов, получающих свою информацию из рекламных объявлений маршрутизатора, может осуществляться постепенно и без вмешательства администратора.

К сожалению, в реальном развертывании эта модель была затруднена принятием AAAAзаписи DNS (в которой хранится только буквальный IP-адрес) поверх A6записи, что позволило указать компоненты адреса (например, 48-разрядную префиксную часть в масштабе предприятия и 80-разрядную часть). часть хоста), которая может управляться и обновляться независимо; а также благодаря ненадежной поддержке адресов на основе префиксов в ранних версиях программного обеспечения маршрутизатора, и кажется маловероятным, что многоадресная модель получит какую-либо поддержку по сравнению с моделью PI + BGP. Ранние RFC рекомендовали не назначать блоки PI нетранзитным организациям, но, по крайней мере, по RFC6177 эта рекомендация, похоже, была отозвана.

Первоначальная идея сторонников IPv6 заключалась в том, что организации будут использовать несколько блоков адресов параллельно, чтобы обеспечить возможность множественной адресации.

Однако на практике это проблематично по нескольким причинам.

1. В такой конфигурации, когда конечный хост выбирает исходный IP-адрес, он, по сути, принимает решения о маршрутизации, но конечные хосты плохо расположены для принятия решений о маршрутизации.
2. Добавление или удаление префиксов IP часто затруднено, поскольку IP-адреса хранятся во многих местах. Были предложены расширения для DNS, чтобы помочь с этим, но они добавили сложность и хрупкость в систему DNS и были в конечном итоге отброшены как «исторические».
3. Это действительно не обрабатывает случай, когда подключение к одному провайдеру неожиданно обрывается.
4. Маршрутизаторы должны будут принимать решения о маршрутизации на основе исходного IP-адреса. Некоторые маршрутизаторы могут делать это, но это расширенная функция, а не обычная маршрутизация.

В конце концов кажется, что у власти есть возможность понять, что организации не собираются мириться с этим дерьмом, и, если они хотят, чтобы IPv6 был принят, они должны были предложить пространство IPv6 PI на тех же условиях, что и пространство IPv4 PI.

Точные политики немного различаются между RIR, но, как правило, если вы можете продемонстрировать намерение использовать несколько домов, вы сможете получить блок пространства PI без особых проблем.

Будет интересно посмотреть, как это закончится в долгосрочной перспективе. Поскольку IPv6 NAT сильно не рекомендуется, я могу увидеть взрыв в размере таблицы маршрутизации, поскольку предприятия среднего размера переходят от natted v4 к независимому от поставщика IPv6.