Почему ARIN (и т. Д.) Выделяет такие большие блоки адресов IPv6?

Основная причина в том, что автоконфигурация адреса без сохранения состояния согласно RFC4862 для правильной работы требуется сеть / 64. Добавьте к этому предположение о том, что при установке вам потребуется более одной подсети, и сложность маршрутизации произвольных кратных / 64, и автоматическая тенденция, по-видимому, заключается в назначении / 56 или, если ленивый, / 48.

Как ни странно, я уже вижу первые признаки экономии в Великобритании. У меня был v6 в моем домашнем офисе уже пару лет, но недавно сменил провайдера. Старый дал мне / 56 автоматически; новый дал мне / 64, но когда я упомянул, что я использую подсети, с радостью обновил меня до / 56 бесплатно.

Я предполагаю, что базовое распределение стабилизируется на уровне / 64, как только v6 станет обычным явлением, и любой, у кого есть хоть сколько-нибудь приличная причина, получит / 56.

Я предполагаю, что маршрутизация меньших блоков создает проблемы для маршрутизации BGP - чем больше меньших блоков, тем больше маршрутизации должны переносить ВСЕ маршрутизаторы, которые не имеют маршрута по умолчанию.

Кроме того, хотя движущей силой IPV6 является увеличенное адресное пространство, IPv6 имеет много преимущества через IPv4. (Более эффективная маршрутизация, упрощенная конфигурация сети, больше не требуется NAT - если вы называете это преимуществом, лучшая безопасность - IPSec встроен в него)

У меня сложилось впечатление (и не более того, хотя я нахожусь на периферии сообщества интернет-провайдеров), что нет смысла анализировать адреса IPv4, поскольку это только отсрочит неизбежное - рано или поздно Интернету понадобится IPv6. Нет смысла продлевать агонию, растягивая IPv4 дальше, чем он должен быть. Те, кому нужно инвестировать в модернизацию инфраструктуры, в любом случае столкнутся с одними и теми же стенами - они могут ударить их прямо сейчас.

Я чувствую, что в целом на этот вопрос было дано достаточно ответов (240 триллионов /48 ассигнований, что означает, что каждый человек на Земле может получить 30 000 /48 распределения, и нас все равно не будет). Но отмечу, что 2011 г. RFC 6177 изменили рекомендацию для интернет-провайдеров и RIR с "предоставлять сайтам клиентов минимум /48"чтобы" предоставить сайтам клиентов нечто меньшее, чем /64, наверное /56, но будьте осторожны "

Процитируем RFC:

Хотя рекомендация / 48 действительно упрощает управление адресным пространством для конечных сайтов, она также широко критиковалась как расточительная.

Я бы с этим не согласился. Опять же, есть 240 триллионов /48 распределения. Человеческое вымирание приведет к тому, что мы убегаем. /48s предлагают больше адресного пространства, чем нужно большинству сайтов, но это не очень расточительно. Он продолжается:

В то же время может возникнуть соблазн дать домашним сайтам единый /64, поскольку это уже значительно больше адресного пространства по сравнению с сегодняшней практикой IPv4. Однако это исключает ожидания того, что даже домашние сайты будут расширяться для поддержки нескольких подсетей в будущем. Следовательно, настоятельно предполагается, что даже домашним сайтам по умолчанию будет предоставлено пространство для нескольких подсетей. Следовательно, этот документ по-прежнему рекомендует предоставлять домашним сайтам значительно больше, чем один /64, но не рекомендует давать каждому домашнему сайту /48 либо.

....

Ключевым принципом управления адресами является то, что конечные узлы всегда могут получить разумный объем адресного пространства для их фактического и запланированного использования и в течение временных диапазонов, указанных в годах, а не в месяцах. На практике это означает как минимум один / 64, а в большинстве случаев значительно больше. Следует избегать одной конкретной ситуации, когда конечный сайт вынужден использовать преобразование сетевых адресов IPv6 в IPv6. или другие обременительные методы сохранения адреса, потому что он не может получить достаточное адресное пространство.

RFC также рекомендует разбивать выделение только на четные полубайты, поэтому /60, /56, /52, /48и т. д. A /60 предоставляет конечным пользователям до 16 подсетей, что нормально, но гораздо меньше 255 подсетей, которые позволяет использовать частный адрес 192.168.0.0/16 на IPv4. Нетрудно представить домашнего пользователя, которому требуется более 16 подсетей. Большинство этого не сделает, но это нетрудно представить.

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

Я видел, как некоторые интернет-провайдеры наконец приступили к развертыванию IPv6 для домашних пользователей, но они предоставляют только /64 и они не предоставляют статических префиксов. Это означает, что домашние пользователи не могут использовать более 1 подсети на IPv6, и это огорчает. Довольно часто дома имеют 1 подсеть для большинства устройств и 1 подсеть для гостевого Wi-Fi. Я бы порекомендовал создать другую подсеть для устройств умного дома IoT, поскольку у этих устройств, похоже, так много ошибок прошивки, что вы вряд ли хотите, чтобы они имели доступ к Интернету, но, конечно, не лишайте их доступа к вашей локальной сети. Имея только / 64, домашний пользователь должен будет либо: выбрать, какая подсеть поддерживает IPv6, и использовать IPv4 + NAT для других подсетей. или использовать IPv6 - IPv6 NAT.

Я чувствую себя /128 разумно для одного сервера в некоторых случаях, а /64 в других. Но /64 никогда не является разумным для сайта, и хотя RFC6177 дает ISP больше свободы действий, мы, вероятно, могли бы придерживаться принципа «всегда давать как минимум / 48 сайтам конечных пользователей» из 2001-х годов RFC 3177 без вреда.