V6NET.RU

+ НАЧАЛО - НАЧАЛО

+ РАЗДАЧА АДРЕСОВ - РАЗДАЧА АДРЕСОВ

+ СБОР СТАТИСТИКИ - СБОР СТАТИСТИКИ

+ ДЕТАЛИ - ДЕТАЛИ

+ СПРАВОЧНАЯ - СПРАВОЧНАЯ

RFC (первоисточники)

Ниже перечислены основные первоисточники по IPv6.

Документ Тэг О чем RFC2460 IPv6 Описание протокола, 1998г. RFC3513 IPv6 Устройство адреса (в оригинале — Addressing Architecture) RFC4443 IPv6 Описание протокола, в том числе ND RFC3315 DHCPv6 Описание протокола DHCP при работе с IPv6 RFC4649 DHCPv6 Описание протокола DHCP relay при работе с IPv6 RFC3769 DHCPv6 Делегирование префиксов от провайдерского роутера клиентскому в DHCPv6 RFC4192 v4—>v6 Рекомендации по замене адресов для провайдеров RFC5887 v4—>v6 То же самое, более свежий документ RFC3849 Документирование Рекомендации по использованию IPv6-адресов в документации и в примерах RFC2462 IPv6 SLAAC Автоматическое назначение IPv6-адресов хостам (интерфейсам) без DHCP-сервера RFC5006 IPv6 SLAAC Автоматическое назначение клиенту ip-адреса DNS-сервера без использования DHCP RFC3330 IPv4 адреса для специальных целей Для использования в примерах выделен блок 192.0.2.0.24 RFC2606 Доменные имена (tld-зоны) для специальых целей Вот список TLD-имен для специальных целей, для использования в качестве примеров: .test .example .invalid .localhost example.com example.net example.org RFC5398 Номера AS для специальных целей В качествве примеров в документации рекомендуется использовать номера AS: 64496-64511 (16-битные) и 65536-65551 (32-битные) RFC6105, февраль 2011.

RA guard

(конспект)

В общем L2-домене какой-нибудь хост умышленно (или неумышленно) может генерировать RA. Для борьбы с этим свитч должен уметь извлекать из RA-пакета:

L2-адрес источника пакета адрес (номер) порта, на котором получен пакет IP-адрес источника пакета Анонсируемые в пакете префиксы На основании этих данных можно блокировать RA-пакет, или пропускать его. У портов с разрешенными RA также рекомендуется задавать приоритет для этих пакетов. Коммутатор должен быть сконфигурирован соответствующим образом.

Рекомендовано к внедрению.

RFC 6177, март 2011 (замена RFC 3177) Назначение адресов конечным пользователям

(конспект)

При выбора размера подсети для конечного пользователя нужно учитывать несколько факторов: — чтобы ему хватило адресов надолго — чтобы адреса выдавались одним блоком (упрощает маршрутизацию)

С другой стороны, чем больше выдаешь клиенту — тем быстрее они закончатся у тебя..

В RFC 3177 рекомендовалось выдавать /48 конечному пользователю. Сейчас это значение рекомендуется уменьшить до /56.

Также: — не рекомендуется выдавать /128 — ранее рекомендовалось выдавать только фиксированные значения /48, /64 и /128 (аналог «классовой» маршрутизации), теперь эта рекомендация отменена — отменена рекомендация выдавать всем конечным пользователям только по /48

— подтверждается рекомендация выдавать конечным пользователям достаточное количество адресов, с учетом развития на несколько лет вперед, не прибегая IPv6-to-IPv6 NAT

В документе отсутствуют официальные (строгие) рекомендации о размере выделяемого блока адресов

Ранее рекомендовалось выдавать только /48 по следующим причинам: — это достаточно много, чтобы не думать о запросе новых адресов в течение нескольких лет — будет достаточно просто сменить схему адресации при переходе пользователя к другому провайдеру, а также это упростит работу с реверсными записями в DNS — также упростится поддержка сложных, многосайтовых сетевых структур, хотя сторонников делегирования /48 критикуют за разбазаривание адресов.