Рекомендации по компоновке адресного пространства IPv6

91

Я доволен распределением адресного пространства IPv4. Под этим я подразумеваю: предоставляя услуги для планирования или организации для сети, я хорошо понимаю, как планировать использование пространства IP-адресов. (или, по крайней мере, я так думаю . :)

Существуют ли рекомендации или практические примеры для схемы адресного пространства IPv6?

Крейг Константин
источник

Ответы:

73

Макет, который мы используем для нашего развертывания:

  • / 48 за клиента
  • / 56 на сайт клиента (как подсеть другого / 48)
  • / 126 для всех двухточечных ссылок в ядре, все эти подсети / 48 используются для всех базовых ссылок

Эти размеры в основном взяты из рекомендаций RIPE здесь .

Дэвид Ротера
источник
4
Хотя это только сводится к сайту. Как насчет внутренних ЛВС, этажей, зданий, служб, голосовой ЛВС, соглашения о кодировании VLAN в сетевой адрес и т. Д.?
1
Затем я бы использовал / 64 для каждой VLAN / этажа / здания (или, тем не менее, ваше распределение работает).
Дэвид Ротера
Есть ли у ARIN (для меня RIR) какие-либо рекомендации / рекомендации?
Крейг Константин
Я полагаю, у вас есть какие-то средства для отслеживания злоупотреблений со стороны спамеров, которым нравится прожигать назначенные им IP-адреса?
frogstarr78
3
Зрелый.net/lir-services/training/material/… довольно хорошо читает (спасибо Марко Хогевонингу за то, что указал мне на это).
Андрей Y
26

Старая рекомендация заключалась в том, чтобы везде использовать / 64 даже на P2P-ссылках и назначать / 48 для сайта.

Использование больших пустых подсетей в двухточечных каналах связи может привести к ряду потенциальных проблем безопасности (см. RFC6164 ), поэтому в настоящее время рекомендуется использовать / 127 для каналов P2P и / 128 для обратных вызовов .

Не обязательно давать маленькому клиенту / 48, хотя у вас было бы много адресов, если вы захотите это сделать.

Интерфейсы, с которыми сталкиваются клиенты, должны быть / 64, если вы хотите использовать SLAAC. Если вы не собираетесь использовать его, вы можете использовать другую маску.

Вот несколько хороших ссылок:

BRKRST-2301 от ciscolive365.com (создать бесплатную учетную запись) http://www.cisco.com/web/strategy/docs/gov/IPv6_WP.pdf
http://tools.ietf.org/html/rfc5375.html
http: //tools.ietf.org/html/rfc6177

Некоторые люди берут свои текущие назначения v4 и преобразуют второй и третий октет в гекс и используют его для v6. Есть много разных способов сделать это, поэтому вы должны выбрать то, что чувствует себя лучше.

Даниэль Диб
источник
5
Я утверждаю, что любая схема адресации IPv6, основанная на существующей схеме адресации IPv4, должна подвергаться дополнительной проверке. Это возможность вырваться из оков прошлого, а не рутинная работа по их точному воспроизведению.
neirbowj
2
Насколько я понимаю, самая маленькая подсеть, которую желательно создать (за исключением P2P-ссылок) - это / 64. Если я домашний клиент и хочу иметь несколько подсетей в локальной сети без использования NAT6, я хочу больше, чем / 64. Как человек, который заинтересован в том, чтобы у меня дома был IPv6, и как человек, который знает, сколько существует квадриллионов / 64-х, я хочу по крайней мере / 60.
Луки нет имени
22

С IPv6 вам больше не нужно беспокоиться о выделении места для определенного количества хостов. Все подсети (кроме ссылок P2P) должны быть назначены как / 64, что дает вам смешное количество адресов хоста. Это позволяет вам сосредоточиться на других темах, таких как хорошее сетевое оформление и дизайн. (А / 48 даст вам 65 536/64 сетей)

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

  • 2001: 0DB8: 1: 1 :: / 64 -> 10.1.1.0 / 24
  • 2001: 0DB8: 1: 2 :: / 64 -> 10.1.2.0 / 24
  • ...
  • 2001: 0DB8: 1: 254 :: / 64 -> 10.1.254.0 / 24

Поиграйте с некоторыми калькуляторами IPv6, чтобы разобраться со всем этим. Вот один пример: GestioIP Online IPv4 / v6 Калькулятор

Для меня это было труднее всего - не беспокойтесь о выделении места для хостов! Планируйте свою сеть - сосредоточьтесь на расположении границ уровня 3, предлагаемых услугах, физическом расположении устройств и т. Д. Вероятно, пройдут годы, прежде чем вы будете иметь чистую сеть IPv6, но вы начнете закладывать основы для хорошего проектирования сети. в настоящее время.

Питер
источник
19

Немного точности к предыдущим ответам, основанным на тренинге RIPE IPv6, который я провел год назад. По сути, их рекомендация - сосредоточиться на агрегации, а не на сохранении адресного пространства .

То есть: не беспокойтесь, чтобы зарезервировать большое количество IP-адресов для точки присутствия, даже если у вас здесь только небольшое количество подсетей (пока). Но вам следует объединить каждую подсеть, «живущую» в POP, с таким же большим префиксом.

Их главная проблема, поскольку теперь у нас есть очень большое количество IP-адресов, заключается в том, что если все объявят небольшие префиксы с высокой степенью детализации, размер таблицы маршрутизации DFZ может взорваться.

Вот учебный материал, использованный в презентации. Особенно первый PDF-файл "Учебное упражнение" дает пример плана адресации.

Бенджамин А.
источник
12

Сам использую следующую раскладку (датацентр pov)

Колокейшн-клиенты: один / 48.

Выделенные серверы: один / 64 на сервер по умолчанию.

P2P-ссылки (bgp linknets и т. Д.): / 126

Что касается перехода IPv4 -> IPv6 к среде с двумя стеками для размещенных vlans, я сопоставляю подсеть ipv4 с подсетью ipv6, которая достаточно велика, чтобы содержать / 64 для каждого отдельного адреса ipv4.

Например:

Vlan, содержащий один / 24 ipv4 (256 ip), я сопоставляю это с / 56 Ipv6 (256 уникальных / 64 подсетей)

Vlan, содержащий один / 23 ipv4 (512 ip), я сопоставляю это с / 55 ipv6 (512 уникальных / 64 подсетей)

S.Ideler
источник
11

SURFnet написал хорошее руководство по сетевому плану IPv6, которое может быть полезным

Теун Винк
источник
Эта ссылка сейчас мертва; это тоже довольно поверхностный ответ. Возможно, вы могли бы включить некоторые основные моменты из первоисточника?
Райан Фоули
Я заменил ссылку на размещенную в RIPE (которая спонсировала перевод). Достаточно сложно дать достойное резюме документа, поскольку в нем рассматривается множество различных сценариев, но в основном он соответствует тому, что упоминалось здесь другими. Это хороший документ, который поможет вам принять решение о том, как выбирать адреса.
Теун Винк
Вопрос спрашивает о существовании лучших практик в целом, без какого-либо конкретного расследования. Этот ответ лаконично удовлетворяет этот вопрос. Upvoted.
StockB
Как просмотреть этот ответ на Android? Какое приложение работает с файлом?
Ferrybig
4

Это немного пугает, когда вы видите огромное доступное адресное пространство, но на практике это не сложно.

Допустим, вам выделено / 48. Это дает вам 65K / 64s для игры, каждый из которых способен удерживать довольно много адресов. Также ошибка округления в 65 КБ дает вам немного других / <64 для других целей.

Лично я вызываю / 64 подсети из / 48 для VLAN. Я установил адрес маршрутизатора как :: 1 для каждой VLAN. Я использую :: xxxx для DNS (где xxxx - повторяющаяся цифра) и аналогичные для некоторых других служб. Это легче запомнить.

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

Если у вас есть несколько сайтов, разбейте / 48 на меньшие биты, но больше / 64 - этого достаточно, чтобы покрыть все возможные ситуации. Это позволит вам несколько агрегировать таблицы маршрутизации.

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

Теперь, если ваши настройки больше - скажем, многонациональный и мультисайтовый, тогда я предлагаю вам исследовать PI, а затем разбить его по стране / сайту / VLAN или стране / местности / сайту / зданию / VLAN или чему-то еще. Вы по-прежнему получаете множество адресов в / 48 для всех, кроме самой крупной установки.

user162383
источник
2

Самая большая проблема, вероятно , чтобы определить , где ваши узкие места будут, с точкой зрения агрегации маршрутов. Основные параметры, вероятно, будут следующими: каждая подсеть должна быть / 64 (определяется IPv6), а у вас есть / 60, / 56 или / 48 для игры.

Как уже говорили другие, / 48 дает вам 64 КБ подсетей, но все равно легко загнать себя в угол, если вы просто назначите их случайным образом. Допустим, у вас есть 1000 магазинов, и с каждого из них последовательно выведите a / 64. Затем вы обнаружите, что 43-му хранилищу нужна вторая подсеть - это значит, либо перенумеровать эту сеть, либо предоставить хранилищу две отдельные подсети, которые не могут быть агрегированы.

Кстати, в мире IPv4 вы также получаете подсети 64 КБ, если используете сеть 10.xxx и подключаете ее к / 24s. Некоторые из практик, которые вы используете в этом сценарии, могут хорошо перевести.

Одна компания, в которой я работаю, использует 10.xxx для примерно 150 филиалов (по 100-500 компьютеров в каждом месте). Второй байт - это номер ветви, и они используют / 22 вместо / 24 для своих подсетей. Таким образом, каждый филиал может иметь до 64 подсетей, что хорошо для них.

Кевин Кин
источник
Да, лучшая практика заключается в том, что каждый сайт получает / 56 или более короткую маску. Кроме того, рекомендуется, чтобы при назначении предметов ниббалы не разделялись (каждая назначенная длина маски должна делиться на 4). Операторы не будут рекламировать префикс длиннее / 48, поэтому, если отдельные сайты должны рекламироваться отдельно, каждый из них нуждается в / 48.
Рон Мопин
Такая передовая практика (как и большинство передовых), как правило, является хорошей идеей, но не всегда подходит. Например, если вы Starbucks или McDonalds, вам может не хватить / 56 для всех ваших магазинов. Вот почему на самом деле такие организации, как военные разных стран и даже сеть книжных магазинов, хотели / 29 или даже более короткие префиксы.
Кевин Кин
1
Моя компания получила гораздо меньшую длину маски. Вы можете легко получить гораздо меньшую длину маски, чтобы назначить / 56 (или более короткую) для каждого сайта. Все, что я говорю, это то, что если вы хотите рекламировать префикс в Интернете, вам нужна маска / 48 или более короткая маска. Получить / 32 или / 24, это не сложно, если у вас есть необходимость.
Рон Мопин
1

Рекомендации по компоновке адресного пространства IPv6

Я доволен распределением адресного пространства IPv4. Под этим я подразумеваю: предоставляя услуги для планирования или организации для сети, я хорошо понимаю, как планировать использование пространства IP-адресов. (или, по крайней мере, я так думаю. :)

Существуют ли рекомендации или практические примеры для схемы адресного пространства IPv6 ?

Супер короткий ответ: Начиная с / 56, попытайтесь спроецировать то, что будет использоваться в ближайшие несколько лет, и отрегулируйте соответственно вверх или вниз. Люди, запрашивающие один адрес, должны иметь несколько выделенных для будущего расширения, важно избежать фрагментации распределения, более того, чем небольшое перераспределение.


Более длинный ответ:

Инженерная рабочая группа по Интернету (IETF) - Лучшие современные практики :

  • В RFC 6177 и BCP 157 - «Назначение адресов IPv6 конечным сайтам» поясняется, что рекомендация «один размер для всех» / 48 недостаточно детализирована для широкого диапазона конечных сайтов и больше не рекомендуется в качестве единого значения по умолчанию.

    1. Введение. Существует ряд факторов, которые учитывают политику назначения адресов. Например, чтобы обеспечить долгосрочную работоспособность и масштабируемость инфраструктуры публичной маршрутизации, важно, чтобы адрес хорошо агрегировал [ ROUTE-SCALING ]. Аналогично, выделение чрезмерного количества адресного пространства может привести к преждевременному истощению адресного пространства. Этот документ посвящен (более узкому) вопросу о том, каков подходящий размер назначения адресов IPv6 для конечных сайтов. То есть, когда конечные сайты запрашивают адресное пространство IPv6 у интернет-провайдеров, каков соответствующий размер назначения.

    ...

    Этот документ посвящен (более узкому) вопросу о том, каков подходящий размер назначения адресов IPv6 для конечных сайтов. То есть, когда конечные сайты запрашивают адресное пространство IPv6 у интернет-провайдеров, каков соответствующий размер назначения.

    ...

    Этот документ не дает официальной рекомендации о том, каким должен быть точный размер задания. Точный выбор размера адресного пространства для назначения конечных сайтов является проблемой для оперативного сообщества. Роль IETF в этом случае ограничивается предоставлением рекомендаций по архитектурным и эксплуатационным аспектам IPv6. Этот документ предоставляет вклад в эти обсуждения.

    ...

    2. Назначения / 48 конечным сайтам - оглядываясь на некоторые первоначальные мотивы, лежащие в основе рекомендации / 48 [RFC3177], было три основных проблемы. Первым мотивом было обеспечение того, чтобы конечные сайты могли легко получить достаточное адресное пространство без необходимости «перепрыгивать» через это. Например, если кто-то считает, что ему нужно больше места, то на каком-то уровне достаточно просто спросить.

    В качестве сравнения, в IPv4 типичным домашним пользователям предоставляется один публичный IP-адрес (хотя даже это не всегда гарантировано), но получить более одного адреса часто сложно или даже невозможно - если только человек не хочет платить (значительно) увеличение платы за то, что часто считается услугой более высокого уровня. (Следует отметить, что увеличение платы за интернет-провайдера для получения небольшого количества дополнительных адресов обычно не может быть оправдано реальной стоимостью за адрес, взимаемой RIR, но дополнительные адреса часто доступны только для конечных пользователей как часть другого типа или " услуги более высокого уровня, за которую взимается дополнительная плата. Дело в том, что дополнительные расходы связаны не со структурами оплаты RIR, а с выбором бизнеса, который делают интернет-провайдеры.)

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

    ...

    Изменение политики (например, как указано выше) окажет значительное влияние на прогнозы потребления адресов и ожидаемый срок службы IPv6. Например, изменение назначения по умолчанию с / 48 на / 56 (для подавляющего большинства конечных сайтов, например, домашних сайтов) приведет к экономии до 8 бит, что приведет к уменьшению «общего прогнозируемого потребления адреса» на (до к) 8 бит или два порядка. (Точная сумма экономии зависит от относительного количества домашних пользователей по сравнению с количеством более крупных сайтов.)

    ...

    3. Другие соображения RFC 3177 - ... Учитывая большой объем адресного пространства в IPv6, есть достаточно места, чтобы предоставить конечным сайтам достаточно места, чтобы соответствовать разумным прогнозам роста на многолетние временные рамки. Таким образом, по-прежнему крайне желательно предоставить конечным сайтам достаточно места (как для первоначального, так и для последующих назначений) на несколько лет. К счастью, эта цель может быть достигнута несколькими способами и не требует, чтобы все конечные сайты получали одинаковое назначение размера по умолчанию. "

  • RFC 7608 и BCP 198 - «Рекомендации по длине префикса IPv6 для пересылки»

    Аннотация - длина префикса IPv6, как и в IPv4, является параметром, который передается и используется в процессах маршрутизации и пересылки IPv6 в соответствии с архитектурой бесклассовой междоменной маршрутизации (CIDR). Длина префикса IPv6 может быть любым числом от нуля до 128, хотя в подсетях, использующих автоконфигурацию адресов без сохранения состояния (SLAAC) для распределения адресов, обычно используется префикс / 64. Аппаратные и программные реализации маршрутизации и переадресации должны поэтому не устанавливать никаких правил для длины префикса, но должны реализовывать самое длинное совпадение в первую очередь для префиксов любой допустимой длины.

  • RFC 7934 и BCP 204 - «Рекомендации по доступности адресов хостов» рекомендует сетям предоставлять конечным хостам общего назначения несколько глобальных адресов IPv6 при их подключении, а также описывает преимущества и варианты для этого.

    Введение - «В отличие от IPv4, сети IPv6 не вынуждены из-за проблем с нехваткой адресов предоставлять только один адрес на хост ... Кроме того, предоставление нескольких адресов имеет много преимуществ, включая функциональность и простоту приложений, конфиденциальность и гибкость для размещения будущих приложений. Еще одним существенным преимуществом является возможность предоставления доступа в Интернет без использования трансляции сетевых адресов (NAT). Предоставление только одного адреса IPv6 на узел сводит на нет эти преимущества.

    2. Общая модель развертывания IPv6 - IPv6 предназначен для поддержки нескольких адресов, включая несколько глобальных адресов, для каждого интерфейса (см. Раздел 2.1 [RFC4291] и раздел 5.9.4 [RFC6434] ). Сегодня многие хосты IPv6 общего назначения настраиваются с тремя или более адресами на интерфейс: локальный адрес канала, стабильный адрес (например, с использованием 64-битных расширенных уникальных идентификаторов (EUI-64) или непрозрачных идентификаторов интерфейса [ RFC7217 ]) один или несколько адресов конфиденциальности [ RFC4941 ] и, возможно, один или несколько временных или невременных адресов, полученных с использованием протокола динамической конфигурации хоста для IPv6 (DHCPv6) [ RFC3315 ].

    В большинстве сетей общего назначения IPv6 хосты могут настраивать дополнительные адреса IPv6 из префиксов ссылок без явных запросов к сети. Такие сети включают в себя все сети 3GPP ( [RFC6459], раздел 5.2 ), в дополнение к сетям Ethernet и Wi-Fi, использующим автоматическую настройку адреса без сохранения состояния (SLAAC) [ RFC4862 ]. ".

  • RFC 4862 - «Автоконфигурация адреса без учета IPv6» объясняет:

    3. Цели дизайна

     

    • Автоконфигурация без сохранения состояния разработана с учетом следующих целей: o Ручная настройка отдельных машин перед их подключением к сети не требуется. ... Автоконфигурация адреса предполагает, что каждый интерфейс может предоставить уникальный идентификатор для этого интерфейса (т. Е. «Идентификатор интерфейса»). ...

    • Небольшие сайты, состоящие из набора компьютеров, подключенных к одной ссылке, не должны требовать наличия сервера DHCPv6 или маршрутизатора в качестве предварительного условия для связи. Связь «включай и работай» достигается за счет использования локальных адресов. Адреса локальной связи имеют хорошо известный префикс, который идентифицирует (одну) общую ссылку, к которой присоединяется набор узлов. Хост формирует локальный адрес канала, добавляя идентификатор интерфейса к префиксу локального канала.

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

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

Вопросы безопасности :

  • OPSEC - « Вопросы эксплуатационной безопасности для сетей IPv6 - draft-ietf-opsec-v6-12 »:

    1. Общие соображения безопасности

     

             2.1. Адресация архитектуры

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

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

                    Общий вопрос заключается в том, должны ли компании использовать PI vs PA space RFC7381 ], но с точки зрения безопасности разница невелика . Однако следует помнить об одном аспекте: кто имеет административное право владения адресным пространством и кто несет техническую ответственность, если / когда существует необходимость в применении ограничений на маршрутизируемость пространства из-за злоумышленной преступной деятельности. Использование пространства PA подвергает организацию перенумерации всей сети, включая политики безопасности (на основе ACL), систему аудита, ... короче, сложную задачу, которая может привести к некоторому риску безопасности, если будет выполнена для большой сети и без автоматизации; следовательно, для большой сети, пространство PI должно быть предпочтительным.

Другие ссылки :

ARIN - « Рекомендуемый проект политики ARIN-2015-1: изменение критериев для начальных назначений конечных пользователей IPv6 ».

ARIN - « Проект политики ARIN-2011-3: улучшенное распределение IPv6 для интернет-провайдеров ».

Все политики ARIN .

IANA - Главная страница - Реестры протоколов - Зарезервированные домены, управляемые IANA .

IETF - « Соображения по метрике плотности хоста IPv6 - draft-huston-hd-metric-00.txt ».

Все ППГ IETF . ( Архив ).

Лучшие текущие практики Википедии (в настоящее время не обновляются).

AP NIC - « Лучшие современные практики IPv6 ».

Технический документ Cloudmark: « BCP для краткосрочного развертывания SMTP в сетях IPv6 ».

NSRC.org - « Лаборатория входной и выходной фильтрации - семинар по проектированию и эксплуатации сети кампуса ».

RIPE - « Политика распределения и назначения адресов IPv6 » гласит (среди многих других): «Минимальный размер выделения для адресного пространства IPv6 составляет / 32. (Для LIR)», «Чтобы претендовать на начальное выделение адресного пространства IPv6, У LIR должен быть план для перераспределения другим организациям и / или назначениям конечного сайта в течение двух лет. "," LIR, которые соответствуют начальным критериям распределения, имеют право на получение первоначального распределения от / 32 до / 29 без необходимости предоставить любую дополнительную информацию. ", ...

RIPE - « Понимание диаграмм IP-адресации и CIDR » (также см. Ниже) предлагает следующие полезные диаграммы:

IPv4 и IPv6


Первоначальная архитектура Интернета состояла в основном из больших сетей, соединенных друг с другом напрямую, и не очень походила на иерархический дизайн, используемый сегодня. Было легко дать один огромный адресный блок военным, а другой - Стэнфордскому университету. В этой модели маршрутизаторы должны были запоминать только один IP-адрес для каждой сети и могли достигать миллионов узлов через каждый из этих маршрутов.

  • Все устройства IPv6 имеют уникальный адрес, заданный им по умолчанию, устройства IPv4 используют классную сеть и не имеют уникального адреса из-за исчерпания адресов, имевшего место с 31 января 2011 года по 24 сентября 2015 года.

Вот старая карта всего Интернета в феврале 1982 года по сравнению с сегодняшним Интернетом, StackExchange.com - это крошечная точка в центре правого изображения, нажмите для увеличения.

Интернет 1984 против сегодняшнего дня

RFC 3484 - «Выбор адреса по умолчанию для интернет-протокола версии 6 (IPv6)» был отменен RFC 6724 (сентябрь 2012 г.), новое в обновлении:

«Разделы 2.1.4 , 2.2.2 и 2.2.3 из RFC 5220 описывают проблемы выбора адреса , связанные с Уникальными локальными адресами (ulaş) [RFC4193]. По умолчанию глобальных направлений IPv6 предпочтительнее назначение ULA, так как любой ULA является не обязательно достижимо ".

  • Рекомендация «один размер для всех» / 48 недостаточно детализирована для широкого круга конечных сайтов и более не рекомендуется в качестве единственного значения по умолчанию.

См .: RIPE - « Понимание IP-адресации и диаграмм CIDR »:

«Каждое устройство, подключенное к Интернету, должно иметь свой идентификатор. Адреса Интернет-протокола (IP) - это числовые адреса, используемые для идентификации конкретного устройства, подключенного к Интернету.

На сегодняшний день используются две наиболее распространенные версии IP: Интернет-протокол версии 4 (IPv4) и Интернет-протокол версии 6 (IPv6). И IPv4, и IPv6-адреса поступают из конечных пулов номеров.

  • Для IPv4 этот пул имеет размер 32 бита (2 ^ 32) и содержит 4 294 967 296 адресов IPv4.

  • Адресное пространство IPv6 имеет размер 128 бит (2 ^ 128) и содержит 340 282 366 920 938 463 463 374 607 431 768 211 456 адресов IPv6.

Модель распределения адресов

В настоящее время IANA выделяет адресные блоки региональным реестрам. Реестры, в свою очередь, присваивают адресные блоки поставщикам услуг. Поставщик услуг обязан раздавать адреса своим клиентам.

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

Политика, зависящая от провайдера

На рисунке графически показано, как действует эта начальная политика. Эта модель назначения обычно называется назначением поставщика (PA) или зависимым от поставщика (PD) назначением. Длина префикса, показанная на рисунке, является рекомендацией. Реестры и поставщики услуг могут назначать блоки, используя процессы и процедуры, которые они установили для своих регионов и клиентов. Это объясняется в RFC 6177.

RFC 6177 - «Назначение адресов IPv6 конечным сайтам».

В качестве примера политики IANA присвоила ARIN 2600: 0000 :: / 12 для назначения. Это выравнивается с верхним слоем модели. Впоследствии ARIN назначил блок 2600 :: / 29 для Sprint, 2600: 300 :: / 24 для AT & T Mobility, 2600: 7000 :: / 24 для Hurricane Electric и т. Д.

Эти назначения блоков не соответствуют первоначальной модели, определенной в RFC 3177. Поставщики услуг впоследствии назначают блоки своим клиентам на основе потребностей своих клиентов. Интернет-провайдер (ISP) может назначать своим клиентам широкий диапазон адресов.

Например, клиенту интернет-провайдера крупного предприятия может потребоваться назначение / 40, в то время как бытовому клиенту потребуется только назначение / 60.

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

В RFC 5375 - «Вопросы присвоения одноадресного IPv6-адреса» изложены некоторые проблемы, которые также необходимо учитывать при составлении плана адресации.

Сначала вы должны решить, хотите ли вы независимые от поставщика блоки адресов или приемлема ли назначенная поставщиком адресация?

Если у клиента есть PI-адреса, назначение останется действительным, если будут выполнены критерии для исходного назначения.

Клиентам с адресами PA рекомендуется получить новое назначение адресного пространства от другого LIR и вернуть адресное пространство PA, которое было назначено их исходным LIR. В этом

Более того, обращение к ссылкам IANA и IETF, указанным выше, - лучший способ оставаться в курсе лучших практик.

обкрадывать
источник
0

Лучший способ разделения ipv6 - это подсети / 64. потому что / 64 адрес может быть легко сопоставлен с IPV4 вручную

Винод Редди
источник
1
Как деление этого на / 64 делает это проще, чем, например, деление на / 48. Можете ли вы уточнить, как бы вы сделали это отображение?
Теун Винк
1
И почему мы должны заботиться о «легко сопоставляемом с IPV4»?
Майкл Хэмптон
0

Основные отличия между v4 и v6

  1. не должно быть необходимости в микроуправлении. Адресное пространство относительно много.
  2. Ожидается, что все подсети будут / 64
  3. NAT сильно не рекомендуется. Для крупных предприятий это не проблема, они просто получают пространство PI или даже регистрируются как LIR и рекламируют свое пространство через BGP. Однако для малого бизнеса это оставляет трудный выбор, они подают заявку на PI space и покупают более дорогие интернет-соединения, которые позволят им использовать его? Используют ли они частные адреса и распределенные публичные адреса провайдера параллельно и надеются, что ни один из выделенных адресов провайдера не окажется в файлах долгосрочной конфигурации? они игнорируют IETF и запускают NAT в любом случае?
  4. Шестнадцатеричное обозначение делает клочья границы убедительными для адресации уровней.

Кроме того, он не должен сильно отличаться от v4, определите, какие подсети вам нужны, выясните, в какие логические группы они попадают и сколько места для будущего расширения вы хотите на каждом уровне, и начните составлять план.

Питер Грин
источник