Slaac rdnss что это

Slaac rdnss что это

PSP5 полностью поддерживает IPv6! На странице View Connection Status отображаются адрес, шлюз, DNS-серверы, рядом с соответствующими настройками IPv4. Отмечается, что работает поддержка SLAAC, RA RDNSS Option и DHCPv6 – и stateful и stateless.

Опубликовано 30.08.2021

Архив 2016г., статистика

/из архивов Фейсбука/

Фейсбук сообщает, что более половины пользователей, заходящих к ним из четырёх самых больших мобильных сетей США, используют IPv6.

И это было всего через четыре года после «глобального» запуска IPv6.

Опубликовано 18.08.2021

IPv6 экзамен

Желающие могут получить и почитать свежий RIPE IPv6 Exam Study Guide. Формат — PDF, язык — английский, 16 страниц.

Опубликовано 11.08.2020

Более 33% !

Доля запросов к Гуглу, приходящих по IPv6, превысила 33%. (Источник)

Опубликовано 05.08.2020

Девятая годовщина Всемирного дня IPv6

Всемирный день IPv6 (2011) — с девятой годовщиной!

Опубликовано 17.07.2020

Apple призывает к переходу на IPv6

На прошлой неделе на конференции WWDC 2020 Apple поделилась некоторыми внутренними статистическими данными в надежде убедить разработчиков приложений принять новые веб-технологии и протоколы, такие как IPv6, HTTP / 2, TLS 1.3 и Multipatch TCP. Источник: ZDNet

Опубликовано 01.07.2020

Самый маленький роутер с IPv6

Опубликовано 30.06.2020

DNS-серверы с IPv6 от Гугла

me@my: dig dns.google AAAA

dns.google. 900 IN AAAA 2001:4860:4860::8888 dns.google. 900 IN AAAA 2001:4860:4860::8844

Не так уж сложно и запомнить. 🙂

Опубликовано 09.06.2020

Чат на тему IPv6

Появился онлайн-чат по тематике IPv6. Работает и по IPv6, англоязычный.

Опубликовано 22.02.2019

Футбол и IPv6

При трансляции полуфинала последнего чемпионата мира по футболу (Бельгия-Франция) 22% процента трафика от Akamai шло по IPv6, пиковая загрузка доходила до 3 Тбит/c.

Опубликовано 27.08.2018

Снова про планирование подсетей

Вышел очередной черновик документа с рекомендациями по планированию адресного пространства IPv6 для «интернета вещей»: IoT Ipv6 address plan.

Все желающие могут принять участие в обсуждении, которое ведется в списке рассылки ipv6-wg.

Опубликовано 16.05.2018

Google + IPv6 в Москве

А в московском офисе Google в гостевой wifi-сети работает IPv6! Это — второе место в столице, про которое мы знаем, где можно получить доступ в Интернет по IPv6.

Скорость достаточно приличная, соединение также держится стабильно. Мой телефон даже сумел обновиться.

IPv6 (Русский)

Состояние перевода: На этой странице представлен перевод статьи IPv6. Дата последней синхронизации: 12 октября 2023. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

В Arch Linux протокол IPv6 включён по умолчанию.

Статья Linux IPv6 HOWTO, хоть и давно не обновлялась, содержит подробную информацию об IPv6, от основ до более сложных тем. Если вы слабо знакомы с данным протоколом, то стоит сначала прочесть её.

Обнаружение соседей

Пинг по адресу многоадресной рассылки ff02::1 заставит все хосты в локальной сети ответить. При этом нужно указать сетевой интерфейс:

$ ping ff02::1%eth0

После этого список «соседей» по локальной сети можно вывести командой

$ ip -6 neigh

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

Если добавить опцию -I ваш-глобальный-ipv6 в пинг-запрос, хосты локальной сети (link-local) ответят с использованием глобальных адресов (link-global). В этом случае сетевой интерфейс можно не указывать:

$ ping -I 2001:4f8:fff6::21 ff02::1

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

#!/usr/bin/bash declare -a l_ifs readarray l_ifs < <(/sbin/ip -6 -j address | jq -r '.[] | .ifname ') for l_if in $; do echo $l_if declare -a l_addrs readarray l_addrs < <(/sbin/ip -6 -j address show dev "$l_if" | \ jq -r '.[0].addr_info[].local') for l_addr in $; do echo $l_addr ping -c 4 -6 -I "$l_addr" ff02::1%"$l_if" done done

Автоконфигурация узла (SLAAC)

Простейший способ получения IPv6-адреса в уже настроенной сети — автоконфигурация узла (SLAAC, Stateless address autoconfiguration). При этом адрес автоматически вычисляется на основании объявленного маршрутизатором префикса сети. Никакие дальнейшие настройки или использование специализированного ПО вроде DHCP-клиента не требуются.

Клиент

Если вы используете netctl, то нужно только добавить одну строку в файл настроек вашей проводной или беспроводной сети.

IP6=stateless

Если вы используете NetworkManager, то он автоматически включит использование IPv6-адресов, если таковые объявлены в сети.

Нужно также заметить, что для нормальной работы автоконфигурации должны быть разрешены пакеты ICMP для IPv6. Поэтому необходимо добавить разрешения для пакетов ipv6-icmp в настройки межсетевого экрана. Если вы используете брандмауэр на основе iptables, то добавьте следующее правило:

-A INPUT -p ipv6-icmp -j ACCEPT

Если вы используете другой интерфейс межсетевого экрана (ufw, shorewall и т.д.), то инструкции по разрешению пакетов ipv6-icmp нужно искать в его документации.

Если вы выбрали сетевой менеджер, который не поддерживает разрешение DNS с бесконтекстным (stateless) IPv6 (например, netctl), то для этих целей можно воспользоваться демоном rdnssd(8) из пакета ndisc6 .

Шлюз

Чтобы соответствующим образом работать с адресами IPv6 клиентских устройств вашей сети, нужно настроить демон объявлений (advertisement daemon). Для этой задачи используется radvd . Его настройка довольно проста. Добавьте следующие строки в файл /etc/radvd.conf , заменив LAN на название вашего сетевого интерфейса:

interface LAN < AdvSendAdvert on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; prefix ::/64 < AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; >; >;

Такая настройка скажет клиентам выбрать адреса из объявленного блока /64 . Обратите внимание, что эта настройка объявляет все доступные префиксы, привязанные к сетевому интерфейсу. Если вы хотите указать конкретные префиксы, то замените ::/64 на необходимый, например, 2001:DB8::/64 . Блок настроек prefix можно повторять для добавления нескольких префиксов.

Чтобы объявить DNS-сервера клиентам вашей локальной сети, можно использовать предлагаемую протоколом обнаружения соседей функциональность RDNSS. Например, добавьте следующие строки к файлу /etc/radvd.conf , чтобы объявить DNSv6-сервер Google:

RDNSS 2001:4860:4860::8888 2001:4860:4860::8844 < >;

Шлюз должен также разрешать трафик ipv6-icmp во всех основных цепочках межсетевого экрана. Для Simple stateful firewall/iptables добавьте правила:

-A INPUT -p ipv6-icmp -j ACCEPT -A OUTPUT -p ipv6-icmp -j ACCEPT -A FORWARD -p ipv6-icmp -j ACCEPT

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

Privacy Extensions

Когда устройство-клиент получает адрес посредством SLAAC, его IPv6-адрес вычисляется на основании префикса сети и MAC-адреса сетевого интерфейса. Это может иметь определённые последствия с точки зрения приватности, поскольку MAC-адрес компьютера теперь можно узнать по IPv6-адресу. Для решения этой проблемы был разработан стандарт IPv6 Privacy Extensions (RFC 4941). В соответствии с ним ядро видоизменяет исходный адрес, генерируя вместо него временный. Такой подход используется, когда необходимо скрыть настоящий адрес при подключении к удалённому серверу.

Чтобы включить Privacy Extensions, добавьте следующие параметры sysctl:

/etc/sysctl.d/40-ipv6.conf

# Enable IPv6 Privacy Extensions net.ipv6.conf.all.use_tempaddr = 2 net.ipv6.conf.default.use_tempaddr = 2 net.ipv6.conf.nic.use_tempaddr = 2

Здесь nic — имя сетевого интерфейса. В статье Настройка сети#Обнаружение сетевых интерфейсов описано, как узнать имена сетевых интерфейсов на вашей машине. Параметры all.use_tempaddr и default.use_tempaddr не будут применены к сетевым интерфейсам, которые уже определены в системе на момент выполнения файла настроек sysctl.

После перезагрузки Privacy Extensions будут включены.

dhcpcd

Стандартная конфигурация dhcpcd содержит опцию slaac private (RFC 7217), которая включает назначение стабильных приватных адресов вместо вычисления оных на основе аппаратных параметров. Дополнительная настройка не требуется, если, конечно, вы не хотите изменять адрес IPv6 чаще, чем в начале каждого нового подключения к сети. Если задать опцию slaac hwaddr , то будут назначаться постоянные адреса.

NetworkManager

NetworkManager использует IPv6 Privacy Extensions в соответствии с настройкой ipv6.ip6-privacy в файле NetworkManager.conf(5) или в профиле соединения. Если параметр не задан ни глобально, ни для соединения, NetworkManager будет использовать /proc/sys/net/ipv6/conf/default/use_tempaddr .

Чтобы включить IPv6 Privacy Extensions явно, добавьте следующие строки в файл NetworkManager.conf(5) :

/etc/NetworkManager/conf.d/ip6-privacy.conf

[connection] ipv6.ip6-privacy=2

Примените настройки и переподключитесь ко всем активным соединениям.

Чтобы включить IPv6 Privacy Extensions для отдельных соединений под управлением NetworkManager, отредактируйте соответствующий нужному соединения файл в каталоге /etc/NetworkManager/system-connections/ , добавив к разделу [ipv6] пару ключ-значение ip6-privacy=2 :

/etc/NetworkManager/system-connections/соединение.nmconnection

. [ipv6] method=auto ip6-privacy=2 .

Перезагрузите соединение и подключитесь к нему снова.

Примечание: Может показаться, что временный адрес IPv6, созданный при включении Privacy Extensions, никогда не обновляется (он не переходит в статус deprecated после истечения времени жизни valid_lft ). На самом деле это не совсем так: через больший промежуток времени адрес всё же изменится.

systemd-networkd

systemd-networkd не включает IPv6 Privacy Extensions по умолчанию. Для включения добавьте параметр IPv6PrivacyExtensions=yes в секции [Network] в файле .network соответствующего соединения. Также можно включить глобально для всех соединений с помощью файла в каталоге /etc/systemd/networkd.conf.d/ , например:

/etc/systemd/networkd.conf.d/ipv6-privacy-extensions.conf

[Network] IPv6PrivacyExtensions=yes

systemd-networkd не учитывает sysctl-параметр net.ipv6.conf.nicN.use_tempaddr , если оцпия IPv6PrivacyExtensions не установлена в значение kernel .

Тем не менее, учитываются некоторые другие опции[1]:

Название	Описание
net.ipv6.conf.nicN.temp_prefered_lft	Предпочтительное время жизни временного адреса в секундах. (В названии допущена грамматическая ошибка, но так и должно быть.)
net.ipv6.conf.nicN.temp_valid_lft	Максимальное время жизни временного адреса в секундах.

ConnMan

Добавьте следующую строку в файл службы:

/var/lib/connman/название_службы/settings

IPv6.privacy=preferred

Постоянный приватный адрес

Другой полезной возможностью являются описанные в RFC 7217 постоянные приватные IP-адреса (stable private addresses). Эта технология позволяет назначать интерфейсам постоянные адреса, для вычисления которых вместо MAC-адреса устройства используется специально сгенерированный ключ.

Чтобы заставить ядро сгенерировать ключ (например, для интерфейса wlan0 ), необходимо задать параметр ядра:

# sysctl net.ipv6.conf.wlan0.addr_gen_mode=3

Выключив/включив интерфейс и выполнив ip addr show dev wlan0 вы увидите флаг stable-privacy рядом с каждым адресом IPv6. Ядро должно было создать 128-битный ключ для генерирования адресов этого интерфейса. Чтобы увидеть сам ключ, выполните команду sysctl net.ipv6.conf.wlan0.stable_secret . Чтобы ключ сохранялся после перезагрузок и был постоянным, нужно добавить в файл /etc/sysctl.d/40-ipv6.conf следующие строки:

# Enable IPv6 stable privacy mode net.ipv6.conf.wlan0.stable_secret = ключ net.ipv6.conf.wlan0.addr_gen_mode = 2

Примечание: Если адрес IPv6 получен от dhcpcd, то флага stable-privacy у него не будет.

NetworkManager

Описанные выше настройки не работают для NetworkManager, но он использует постоянные приватные адреса по умолчанию [2],[3].

Статический адрес

Иногда использование статического адреса может быть применено в качестве одной из мер обеспечения безопасности. Например, если ваш локальный маршрутизатор использует обнаружение соседей (Neighbor Discovery) или radvd (RFC 2461), вашему интерфейсу будет автоматически присвоен адрес, который содержит часть MAC-адреса сетевого интерфейса (используя SLAAC). Это может быть не слишком хорошо для безопасности, так как позволяет без труда отслеживать систему, даже если часть IPv6-адреса сменилась.

Чтобы присвоить статический IP-адрес при помощи netctl, используйте шаблон профиля /etc/netctl/examples/ethernet-static . Следующие строки особенно важны:

. # For IPv6 static address configuration IP6=static Address6=('1234:5678:9abc:def::1/64' '1234:3456::123/96') Routes6=('abcd::1234') Gateway6='1234:0:123::abcd'

Примечание: Если вы подключены к сети, в которой есть только IPv6, то необходимо определить соответствующий DNS-сервер. Например:

DNS=('6666:6666::1' '6666:6666::2')

Если ваш провайдер не предоставляет DNS для IPv6 и вы не хотите настраивать свой сервер, то можно выбрать его по рекомендациям в статье Разрешение доменных имён.

IPv6 и PPPoE

Стандартный инструмент для PPPoE, pppd(8) , позволяет использовать IPv6 в PPPoE, если это поддерживается вашим провайдером и модемом. Добавьте одну строку в файл /etc/ppp/options :

+ipv6

Если вы используете netctl для PPPoE, тогда вместо этого добавьте следующую строку в файл настроек netctl:

PPPoEIP6=yes

Делегирование префикса (DHCPv6-PD)

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

Делегирование префикса (prefix delegation) — широко распространённая технология развёртывания IPv6, используемая многими интернет-провайдерами. Представляет собой метод назначения сетевого префикса пользователю (например, локальной сети). Маршрутизатор может быть настроен на привязку разных сетевых префиксов к различным подсетям. Провайдер выдаёт префикс с помощью DHCPv6 (обычно это префикс /56 или /64 ), а dhcp-клиент назначает префикс локальной сети. В случае простого шлюза с двумя интерфейсами клиент обычно получает адрес через WAN-интерфейс (или псевдоинтерфейс вроде ppp) и на его основании присваивает IPv6-префикс интерфейсу, обращённому к локальной сети.

Клиент DHCPv6 принимает входящие соединения на UDP-порт 546. Чтобы настроить доступ к этому порту в межсетевом экране nftables, в файле /etc/nftables.conf добавьте следующее правило в цепочку input:

table inet filter < chain input < udp dport dhcpv6-client accept . >. >

dhcpcd

dhcpcd помимо поддержки dhcp для IPv4 также предлагает полноценную реализацию протокола DHCPv6 (включая DHCPv6-PD). Если вы используете dhcpcd , отредактируйте файл /etc/dhcpcd.conf . Скорее всего, вы уже используете dhcpcd для IPv4, поэтому просто обновите существующую конфигурацию.

duid noipv6rs waitip 6 # Uncomment this line if you are running dhcpcd for IPv6 only. #ipv6only # use the interface connected to WAN interface WAN ipv6rs iaid 1 # use the interface connected to your LAN ia_pd 1 LAN #ia_pd 1/::/64 LAN/0/64

Эта конфигурация запросит префикс на WAN-интерфейсе ( WAN ) и делегирует его внутреннему интерфейсу ( LAN ). Если вдруг с диапазоном /64 возникнут проблемы, то нужно использовать вторую инструкцию ia_pd , которая в примере выше закомментирована. Кроме того, приведённая конфигурация также отключит вызовы маршрутизатора (router solicitation) для всех интерфейсов, кроме WAN.

Совет: См. также dhcpcd(8) и dhcpcd.conf(5) .

WIDE-DHCPv6

WIDE-DHCPv6 — свободная реализация протокола DHCP для IPv6 (DHCPv6), первоначально разработанная проектом KAME. Установите его с пакетом wide-dhcpv6 AUR .

Если вы используете wide-dhcpv6, отредактируйте файл /etc/wide-dhcpv6/dhcp6c.conf , заменив WAN и LAN названиями соответствующих интерфейсов:

# use the interface connected to your WAN interface WAN < send ia-pd 0; >; id-assoc pd 0 < # use the interface connected to your LAN prefix-interface LAN < sla-id 1; sla-len 8; >; >;

Примечание: Параметр sla-len нужно назначить таким образом, чтобы выполнялась формула (WAN-prefix) + (sla-len) = 64 . В нашем случае для сети с префиксом /56 формула примет вид 56+8=64. Для префикса /64 sla-len будет равен 0 .

Клиент wide-dhcpv6 можно запустить/включить с помощью systemd-юнита dhcp6c@интерфейс.service , где интерфейс — название интерфейса в файле настроек, то есть, например, для интерфейса «WAN» используйте dhcp6c@WAN.service .

Совет: См. также dhcp6c(8) и dhcp6c.conf(5) .

systemd-networkd

Настройте внешний (wan) и внутренний (lan) интерфейсы. Это включит DHCPv6-PD для интерфейса с запущенным DHCPv6-клиентом. Делегированные префиксы предоставляются посредством IPv6 Router Advertisement во внутренней (локальной) сети.

/etc/systemd/network/wan.network

[Network] # Укажите 'yes' вместо 'ipv6' для одновременной работы и ipv4, и ipv6. DHCP=ipv6

/etc/systemd/network/lan.network

[Network] IPv6SendRA=yes DHCPv6PrefixDelegation=yes

Совет: Смотрите также systemd.network(5) § EXAMPLES .

Другие клиенты

dhclient также может запрашивать сетевой префикс, но для присваивания этого префикса или его части нужно использовать специальный скрипт. Пример программы: https://github.com/jaymzh/v6-gw-scripts/blob/master/dhclient-ipv6.

NAT64

NAT64 — это механизм перехода на IPv6, при котором хосты, поддерживающие только IPv6, могут взаимодействовать с хостами IPv4 с помощью NAT.

Ядро Linux не поддерживает NAT64 нативно, но есть пакеты, добавляющие поддержку NAT64.

• Jool — SIIT и NAT64 для Linux

• TAYGA — Демон NAT64 (не поддерживается)

Отключение IPv4

Отключение IPv4 в systemd-networkd

Пример конфигурации только IPv6-интерфейса в systemd-networkd (однако это по сути только отключает DHCPv4, но не весь протокол IPv4 целиком).

/etc/systemd/network/lan.network

[Match] Name=eno0 [Link] RequiredForOnline=routable [Network] # Enable IPv6 only DHCP=ipv6 # Enable SLAAC IPv6AcceptRA=true

Отключение IPv6

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

Отключение функциональности

Параметр ядра ipv6.disable=1 отключает весь стек IPv6, что в большинстве случаев помогает добиться желаемого результата.

Другой параметр, ipv6.disable_ipv6=1 , оставит стек IPv6 работающим, но адреса IPv6 не будут присваиваться сетевым интерфейсам.

Также вы можете отключить присвоение адреса IPv6 всем или определённым сетевым интерфейсам, добавив следующие параметры sysctl в файл /etc/sysctl.d/40-ipv6.conf :

# Disable IPv6 net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.nic0.disable_ipv6 = 1 . net.ipv6.conf.nicN.disable_ipv6 = 1

Перезапустите юнит systemd-sysctl.service , чтобы изменения вступили в силу.

Совет: Если стек IPv6 не отключен, то для проверки изменений можно также отключить IPv6 на сетевых интерфейсах на лету. Выполнение команды # sysctl -w net.ipv6.conf.all.disable_ipv6=1 отбрасывает назначенные IPv6-адреса и маршруты, а позже это можно отменить.

Примечание: Обратите также внимание, что при таком способе отключения IPv6 необходимо закомментировать все IPv6-хосты в файле /etc/hosts . В противном случае могут происходить ошибки подключения, если при определении адреса произошло разрешение имени хоста на недоступный IPv6-адрес.

Другие программы

Отключение IPv6 в ядре не избавит от попыток программ использовать IPv6. В большинстве случаев это не приводит к проблемам, однако, если они всё-таки появляются, вам остаётся лишь искать в man-страницах или на просторах сети способ отключить эту функциональность.

dhcpcd

Например, dhcpcd будет продолжать пытаться запрашивать настройки сети у маршрутизаторов IPv6 (т.н. Router solicitation). Чтобы отключить это, добавьте следующие строки в файл /etc/dhcpcd.conf :

noipv6rs noipv6

NetworkManager

Чтобы отключить IPv6 в NetworkManager, вызовите контекстное меню значка статуса сети и выберите Параметры соединений > Ethernet > Название соединения > Изменить выбранное соединение > Параметры IPv6 > Метод > Игнорировать. Затем нажмите Сохранить.

Это также можно сделать с помощью команды:

# nmcli connection modify НазваниеСоединения ipv6.method "disabled"

После этого нужно перезапустить соединение:

# nmcli connection up НазваниеСоединения 

Чтобы убедиться, что настройки применились, используйте команду ip address show и проверьте, что запись inet6 не отображается. Также можно проверить, что /proc/sys/net/ipv6/conf/интерфейс/disable_ipv6 имеет значение 1.

ntpd

Чтобы определить, как systemd должен запускать службу ntpd, необходимо внести изменения в файл ntpd.service .

Создайте drop-in файл, который будет запускать другую команду вместо стандартной. Флаг -4 отключает использование IPv6 демоном ntp.

[Service] ExecStart= ExecStart=/usr/bin/ntpd -4 -g -u ntp:ntp

Здесь сначала очищается значение ExecStart , а затем устанавливается новая команда.

GnuPG

Отключите IPv6 в настройках dirmngr:

~/.gnupg/dirmngr.conf

disable-ipv6

После этого перезапустите пользовательскую службу dirmngr.service .

sshd

Добавьте следующие строки в файл sshd_config , чтобы убедиться, что sshd использует IPv4-адрес:

/etc/ssh/sshd_config

AddressFamily inet

После этого перезапустите службу sshd.service .

systemd-timesyncd

Иногда systemd-timesyncd пытается отправлять запросы IPv6-серверу времени, даже если IPv6 отключён. Это может привести к тому, что системные часы не будут обновляться, а в журнале появятся сообщения об ошибках следующего вида:

systemd-timesyncd[336]: Failed to set up connection socket: Address family not supported by protocol

Если посмотреть статус юнита systemd-timesyncd в пункте Status будет виден IPv6-адрес целевого сервера:

Status: "Connecting to time server [2001:19f0:8001:afd:5400:1ff:fe9d:cba]:123 (2.pool.ntp.org)"

Как видно из FS#59806, по протоколу IPv6 работают «2.»-сервера ntp.org. Чтобы запретить подключение к ним, удалите в файле /etc/systemd/timesyncd.conf записи 2.arch.pool.ntp.org и 2.pool.ntp.org из параметров NTP and FallbackNTP соответственно.

systemd-networkd

networkd позволяет отключить IPv6 для отдельного интерфейса. Когда в разделе [Network] сетевого юнита указан параметр LinkLocalAddressing=ipv4 или LinkLocalAddressing=no , networkd не будет настраивать IPv6 на соответствующих сетевых интерфейсах.

Однако нужно отметить, что даже при использовании указанных выше опций networkd всё ещё будет ожидать получения «объявлений маршрутизатора» (router advertisements, RA), если IPv6 не был отключён глобально для всей системы. Если трафик IPv6 не будет доходить до интерфейса (например, из-за настроек sysctl или ip6tables), то интерфейс останется в состоянии настройки и потенциально может стать причиной превышения времени ожидания (timeout) для служб, требующих полной настройки сети. Чтобы этого избежать, добавьте опцию IPv6AcceptRA=no в раздел [Network] .

Использование IPv4 вместо IPv6

The factual accuracy of this article or section is disputed.

Reason: Это отключит другие настройки по умолчанию. [4] (Discuss in Talk:IPv6#Factual accuracy — Prefer IPv4 over IPv6)

Раскомментируйте следующую строку в файле /etc/gai.conf :

# # For sites which prefer IPv4 connections change the last line to # precedence ::ffff:0:0/96 100

Смотрите также

• IPv6 — документация на kernel.org.
• IPv6 temporary addresses — временные адреса и расширения приватности.
• IPv6 prefixes — о типах префиксов.
• net.ipv6 options — документация параметров ядра.

Retrieved from «https://wiki.archlinux.org/index.php?title=IPv6_(Русский)&oldid=796388»

SLAAC — зачем?

Покая не вникал в суть IPv6, мне казалось что SLAAC — это не протокол, а свойство IPV6, тоесть если на интерфейсе роутера настроен условный адрес 2001:8888:8888:8888::1/64, то в ответ на NDP придет пакет где будет предложена этот префикс и ПК уже сам выберет себе адрес. и тогда это вроде как имеет смысл, не надо плодить дополнительную сущность для раздачи адресов (DHCP).

Но нет. на практике оказалось, что для работы SLAAC нужно запускать отдельного демона (radvd в linux) у которого есть конфиг, в котором нужно указывать префикс для раздачи, тоесть получили вы префикс по dhcpv6-pd, будте добры добавить его в конфиг (скриптами конечно). Тоесть фактически отдельная сущность для раздачи IP адресов остается, причем SLAAC не умеет раздавать ничего кроме IP адресов и битового префикса (есть rfc про раздачу dns, но вроде его мало кто реализовал) и для полноценной работы рядом с ним должен быть запущем DHCPv6 сервер, который будет отдавать все остальные опции.

И из этого возникает вопрос — а зачем нужна новая сущность если и старая неплохо справлялась и всеравно работает совместно с новой?

IPv6 — прекрасный мир, стоящий скорого перехода на него

Практически все статьи, которые я видел на тему «чем хорош IPv6 и почему на него стоит пошустрее переходить», говорят только о просто более широком адресном пространстве. В лучшем случае, упомянут автоматическую конфигурацию адресов и маршрутов (stateless address autoconfiguration (SLAAC)). Это удручает, а ведь IPv6 имеет много ещё других неявных плюшек, являясь очень продуманным стеком протоколов (IPv6 + ICMPv6 + NDP)! Создаётся впечатление, что IPv6 это просто тупо про расширение адресов, а дальше то особо никакого профита. Или же некоторые статьи плачутся о том, что они не видят сиюминутного профита от внедрения/перехода. Простоту и удобство, гибкость и расширенные возможности (из-за одного только избавления от NAT-а) не так то легко измерить, как какие-нибудь задержки и пропускную способность. Решил поэтому собрать моё видение прекрасного мира IPv6 протокола и его плюсы в этой статье.

Не использовать IPv6 для построения чего-то нового, новых сетей — просто не имеет смысла, так как лишаемся массы удобств и возможностей, получая кучу геморроя от лишения этой массы удобств и возможностей. IPv6 поддерживается даже с Windows XP версии. Последний раз я проверял пять лет назад, но уже тогда SLAAC+RDNSS/DNSSL поддерживали и iOS и Android и даже Windows 10 устройства, не говоря о GNU/Linux и BSD системах.

IPv4 не является плохим протоколом. Его проблема только в том, что он никогда не задумывался для создания большой глобальной сети, где почти у каждого человека на Земном шаре будет доступ к ней прямиком из штанов (где лежит смартфон). Он создавался во времена, когда компьютеры были более быстрыми чем сети (странное сравнение?) и с кучей памяти. Сейчас наоборот: сделать 10 Gb канал связи можно тривиально и дома, но из коробки ни одна из массово используемых ОС не сможет эффективно коммутировать или маршрутизировать трафик на такой скорости.

Конечному пользователю сложно представить получаемые преимущества, так как Интернета, по факту, уже давно мало кому дают: преобладающая часть людей всегда сидела за NAT-ом и считает, что изобретение протоколов типа WebSocket, есть нечто штатное, нормальное, логичное и разумное, и ничего кроме TCP, UDP и ICMP у нас особо-то и не ходит поверх IP.

Сетевому инженеру, чисто психологически, сложно будет пересиливать себя в понимании того, что адресов и сетей реально очень много выдаётся и не имеет смысла (и даже будет только вредить удобству и простоте обслуживания) экономить на их использовании. Большая проблема — осознание того, что IP адреса уже не являются дефицитным ресурсом и думать приходится чаще всего в понятиях не единичных адресов, а целых огромных сетей минимум с /64 префиксом.

IPv6 имеет более серьёзные требования (эту часть можно обозвать недостатками):

• Минимальный допустимый MTU канала: 1280 байт.
• Канал должен быть с обнаружением (или даже исправлением) ошибок.
• NDP протокол работает активно поверх multicast адресов, требуя работоспособных multicast рассылок в Ethernet-е.
• PMTUD является обязательным для (эффективной) работы, так как в IPv6 нет фрагментации пакетов на уровне маршрутизаторов.
• ICMPv6 протокол играет очень большую роль для работоспособности IPv6 сетей, как минимум для NDP и PMTUD. Если заблокировать его (как многие админы любят делать в IPv4 сетях), то сеть, скорее всего, перестанет работать.

• У конечного пользователя появляется Интернет, а не удалённый доступ до ряда служб корпораций типа Facebook, ВКонтакте, WhatsApp, YouTube и т.д.! Буквально появляется возможность обмениваться произвольными данными между произвольными компьютерами. Можно использовать, зачастую гораздо более эффективные, peer-to-peer протоколы, разгружая сервера. Количество перерастает в качество: все мы знаем насколько революционен был BitTorrent только для обмена файлами.
• Исчезает NAT (всё ломающий костыль, абсолютное зло): теперь можно использовать гораздо более эффективные протоколы для различных задач. Например, SCTP для удобной гарантированной in-order передачи сообщений параллельных потоков, в противовес TCP, передающему поток байт, да ещё и с head-of-line blocking. Использовать протоколы без ненужной инкапсуляции, с лишним overhead-ом и бесполезной тратой ресурсов, например, на пересчёт контрольных сумм, как это делают с IPsec (или любыми VPN) и SCTP протоколами инкапсулированными в UDP пакетах. Использовать протоколы где не нужно разделение на порты, убирая громоздкие заголовки транспортного уровня. Это эффективно и удобно!
• Работающий IPsec, как правило, требующий доступности хостов. Наконец-то его можно использовать не только для VPN-ов/туннелей, но и для обезопашивания хоть каждой TCP сессии по отдельности: setsockopt может делать per-socket IPsec policy, вкупе с возможностью задания ожидаемых идентификаторов участников IKE соединения (sadb_ident), это с лихвой покрывает все задачи решаемые SSL/TLS-ом! Был бы IPv6 внедрён раньше, то и SSL/TLS, с очень долгой историей небезопасности, в принципе бы не появился. IPsec имеется сразу же из коробки во всех современных ОС и его трафик обрабатывается на ядерном уровне, с централизованным (один IKE/KINK/whatever демон) управлением рукопожатиями. Это очень эффективно, продуманно и удобно!
• Не нужно заниматься выделением отдельных портов для разных демонов запускаемых на одном IP адресе — проще на отдельных IP адресах поднимать несвязанные между с собой демоны, без неудобств с отличающимися от default-ных значений портов. Каждому пользователю всё-равно выдаётся минимум /64 сеть. Это просто и удобно!
• Глобальных префиксов так много выдаётся конечным пользователям и организациям, что просто не имеет смысла использовать site-local адреса сетей (fc::/7), рискуя иметь коллизию с какой-нибудь домашней сетью пользователя, подключающегося по VPN к сети организации (хорошо известная проблема в IPv4 мире, иногда вынуждающая переделывать адресацию домашней сети). Везде надо привыкать к тому, что стоит использовать глобальные префиксы сетей. Это очень удобно!
• На практике, адреса сконфигурированные руками/человеками, зачастую проще запомнить чем 4 несвязанных десятичных числа, особенно если их делать мнемоническими (типа :dead:babe:): 2a02:6b8::2:242 (ya.ru), :face:b00c: в сети Facebook, 2001:4860:4860::8888 публичный DNS Google-а, 2620:0:ccc::2 (OpenDNS). А если что-то длинное автоматически сгенерированно, то человеку это на практике и не нужно запоминать/продиктовывать, так как он хоть мышкой выделит в терминале и вставит куда надо.
• Так как все адреса выдаются иерархическим образом, то таблица маршрутизации на каждом узле/маршрутизаторе маленькая и компактная. Даже за /48, /56 или /64 сети конечных пользователей отвечают маршрутизаторы самих пользователей, которым эти префиксы делегированы. Это очень эффективно, продуманно и удобно!
• Если умные инженеры всё же просчитались и раздача /48, /56 и подобного размера сетей каждому конечному пользователю является чересчур нерациональной и безалаберной идеей, то ничего страшного: штатно адреса для глобальных адресов сейчас раздаются только из 2000::/3 диапазона, то есть всего-лишь из 1/8 части всего возможного адресного пространства. Если это было плохим решением, то у нас ещё есть 7 попыток раздавать адреса по другим политикам. Это продуманно!
• Killer-feature: link-local адреса. Автоматически создаваемые на каждом канале link-local адреса гарантируют наличие работающего сетевого уровня между компьютерами. Не нужно настраивать руками временные IPv4 приватные сети. Для большой организации не нужно тратить время и силы на разрезание на подсети какой-нибудь 10/8 сети, раздавая из неё адреса для маршрутизаторов, следя чтобы не пересеклось ничего. Так как IPv6 позволяет иметь много адресов на одном интерфейсе и один и тот же адрес на разных интерфейсах, то можно какой-нибудь fe80::1 на каждом интерфейсе общения с виртуальными машинами назначить и зашить намертво в образах машин как адрес шлюза. Это невероятно удобно!
• Некоторые well-known multicast адреса позволяют легко узнать какие компьютеры вообще есть в сети (broadcast домене Ethernet-а), моментально в ad-hoc режиме их найдя и имея возможность сразу же подключиться:

# ping6 ff02::1%igb0 PING6(56=40+8+8 bytes) fe80::be5f:f4ff:fedd:2752%igb0 --> ff02::1%igb0 16 bytes from fe80::be5f:f4ff:fedd:2752%igb0, icmp_seq=0 hlim=64 time=0.036 ms 16 bytes from fe80::be5f:f4ff:fedd:98f1%igb0, icmp_seq=0 hlim=64 time=0.239 ms(DUP!) 16 bytes from fe80::be5f:f4ff:fee6:c37e%igb0, icmp_seq=0 hlim=64 time=0.344 ms(DUP!) 16 bytes from fe80::be5f:f4ff:fedd:9c5d%igb0, icmp_seq=0 hlim=64 time=0.479 ms(DUP!) 

igb0:addr="2001:dead:beef::":mtu=1320:rdnss="2001:dead:beef::1": 

Даёшь IPv6 и полноценный Интернет в массы!