RFC’s

Ниже перечислены основные первоисточники по 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 критикуют за разбазаривание адресов.

 


  *** Via IPv4 ***  

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.