Пользователь
18,0
рейтинг
31 октября 2013 в 14:48

Администрирование → Практика IPv6 — домашняя сеть tutorial

Abstract: Рассказ про некоторые возможности IPv6 на примере конфигурации сложной домашней IPv6-сети. Включает в себя описания мультикаста, подробности настройки и отладки router advertisement, stateless DHCP и т.д. Описано для linux-системы. Помимо самой конфигурации мы внимательно обсудим некоторые понятия IPv6 в теоретическом плане, а так же некоторые приёмы при работе с IPv6.

Зачем IPv6?


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

Сейчас с IPv6 можно возиться совершенно безопасно, без каких-либо негативных последствий. Можно мирно разбираться в граблях и особенностях, иметь его неработающим месяцами и nobody cares. Я не планирую в свои старшие годы становиться зашоренным коболистом-консерватором, который всю жизнь писал кобол и больше ничего, и все новинки для него «чушь и ерунда». А вот мой досточтимый воображаемый конкурент, когда IPv6 станет продакт-реальностью, будет либо мне не конкурентом, либо мучительно и в состоянии дистресса разбираться с DAD, RA, temporary dynamic addresses и прочими странными вещами, которым посвящено 30+ RFC. А что IPv6 станет основным протоколом ещё при моей жизни — это очевидно, так как альтернатив нет (даже если бы они были, их внедрение — это количество усилий бОльшее, чем завершение внедрения IPv6, то есть любая альтернатива всегда будет отставать). И что адреса таки заканчиваются видно, по тому, как процесс управления ими перешёл во вторую стадию — стадию вторичного рынка. Когда свободные резервы спекуляций и хомячаяния адресов закончится, начнётся этап суровой консолидации — то есть выкидывание всего неважного с адресов, перенос всех «на один адрес» и т.д. Примерно в это время IPv6 начнёт использоваться для реальной работы.

Впрочем, рассказ не про будущее IPv6, а про практику работы с ним. В Санкт-Петербурге есть такой провайдер — Tierа. И я их домашний пользователь. Это один из немногих провайдеров, или, может быть, единственный в городе, кто предоставляет IPv6 домашним пользователям. Пользователю выделяется один IPv6 адрес (для маршрутизатора или компьютера), плюс /64 сетка для всего остального (то есть в четыре миллиарда раз больше адресов, чем всего IPv4 адресов быть может — и всё это в одни руки). Я попробую не просто описать «как настроить IPv6», но разобрать базовые понятия протокола на практических примерах с теоретическими вставками.

Структура сети:

(Оригиналы картинок: github.com/amarao/dia_schemes)
  • 1, 2, 3 — устройства в локальной сети, работают по WiFi
  • 4 — WiFi-роутер, принужденный к работе в роле access point (bridge), то есть коммутатора между WiFi и LAN
  • 5 — eth3 сетевой интерфейс, который раздаёт интернет в локальной сети
  • 6 — мой домашний компьютер (основной) — desunote.ru, который раздачей интернета и занимается, то есть работает маршрутизатором
  • 7 — eth2, интерфейс подключения к сети Tiera


Я пропущу всю IPv4 часть (ничего интересного — обычный nat) и сконцентрируюсь на IPv6.

Полученные мною настройки от Tiera для IPv6:
  1. Адрес 2a00:11d8:1201:0:962b:18:e716:fb97/128 мне выдан для компьютера/шлюза
  2. Сеть 2a00:11d8:1201:32b0::/64 мне выдана для домашних устройств


У провайдера сеть 2a00:11d8:1201:32b0::/64 маршрутизируется через 2a00:11d8:1201:0:962b:18:e716:fb97 (то есть через мой компьютер). Заметим, это всё, что я получил. Никаких шлюзов и т.д. — тут начинается магия IPv6, и самое интересное. «Оно работает само».

Начнём с простого: настройка 2a00:11d8:1201:0:962b:18:e716:fb97 на eth2 для компьютера. Для удобства чтения все конфиги и имена файлов я оставлю на последнюю секцию.

Мы прописываем ipv6 адрес на интерфейсе eth2… И чудо, он начинает работать. Почему? Каким образом компьютер узнал, куда надо слать пакеты дальше? И почему /128 является валидной сетью для ipv6? Ведь /128 означает сеть размером в 1 ip-адрес и не более. Там не может быть шлюза!

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

# ip address show eth2 (обычно сокращают до ip a s eth2)
eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    (skip)
    inet6 2a00:11d8:1201:0:962b:18:e716:fb97/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::218:e7ff:fe16:fb97/64 scope link 
       valid_lft forever preferred_lft forever


Упс. А почему у нас на интерфейсе два адреса? Мы же прописывали один? Наш адрес называется 'scope global', но есть ещё и 'scope link'…

Часть первая: scope


Тут нас встречает первая особенность IPv6 — в нём определено понятие 'scope' (область видимости) для адреса.
Есть следующие виды scope:
  • global — «обычный» адрес, видимый всему Интернету
  • local или link-local — адрес, видимый только в пределах сетевого сегмента. Ближайшим аналогом этого является configless IPv4 из диапазона 169.254.0.0/16, на который сваливается любая windows, которой сказали автоматически получить адрес, а DHCP-сервера вокруг нет. Эти адреса не могут быть маршрутизируемы (то есть тарфик с них не передаётся дальше своей сети). Подробнее про link-local address (wiki).
  • host, он же interface — видимость в пределах хоста. Примерный аналог — loopback адреса для IPv4 (127.0.0.0/8)
  • admin-local — в живую не видел, но какая-то промеждуточная стадия
  • site-local — видимость в пределах офиса. Аналог серых 192.168.0.0/16, то есть адреса, которые не должны выходить за пределы локальной сети
  • organization-local — адреса, которые не выходят за пределы организации.


В процессе проектирования IPv6 вопрос 'scope' много и тщательно обсуждался, потому что исходное деление IPv4, даже с последующими дополнениями, явно не соответствовало потребностям реальных конфигураций. Например, если у вас объединяются две организации, в каждой из которых используется сеть 10.0.0.0/8, то вас ждёт множество «приятных» сюрпризов. В IPv6 решили с самого начала сделать множество градаций видимости, что позволило бы более комфортно осуществлять дальнейшие манипуляции.

Из всего этого на практике я видел использование только host/interface, link/local и global. В свете /64 и пусть никто не уйдёт обиженным, специально возиться с site-local адресами будет только параноик.

Второй важной особенностью IPv6 является официальное (на всех уровнях спецификаций) признание того, что у интерфейса может быть несколько IP-адресов. Этот вопрос в IPv4 был крайне запутан и часто приводил к ужасным последствиям (например, запрос получали на один интерфейс, а отвечали на него через другой, но с адресом первого интерфейса).

Так как в отличие от IPv4 у IPv6 может быть несколько адресов на интефрейсе, то компьютеру не нужно выбирать «какой адрес взять». Он может брать несколько адресов. В случае IPv4 сваливание на link-local адрес происходило в режиме «последней надежды», то есть по большому таймауту.

А в IPv6 мы можем легко и просто с самого первого момента, как интерфейс поднялся, сделать ему link local (и уже после этого думать о том, какие там global адреса есть).

Более того, в IPv6 есть специальная технология автоматической генерации link-local адреса, которая гарантирует отсутствие дублей. Она использует MAC-адрес компьютера для генерации второй (младшей) половинки адреса. Поскольку MAC-адреса уникальны хотя бы в пределах сегмента (иначе L2 сломан и всё прочее автоматически не работает), то использование MAC-адреса даёт нам 100% уверенность в том, что наш IPv6 адрес уникален.

В нашем случае это inet6 fe80::218:e7ff:fe16:fb97/64 scope link. Обратите внимание на префикс — fe80 — это link-local адреса.

Как он делается?

Принцип довольно простой:

MAC-адрес eth2 — это 00:18:e7:16:fb:97, а локальный адрес ipv6 — F80:000218:e7ff:fe16:fb97. Да-да, именно так, как выделено жирным. Зачем было в середину всобачивать ff:fe — не знаю. Сам алгоритм называется modified EUI-64. Сам этот алгоритм очень мотивирован и полон деталей. С позиции системного администратора — пофигу. Адрес есть и есть. Интересным может быть, наверное, обратный алгоритм — из link-local узнать MAC и не более.

Итак, у нас на интерфейсе два адреса. Мы даже знаем, как появились они оба (один автоматически при подъёме интерфейса, второй прописали мы). Мы даже знаем, как система поняла, что адрес глобальный — он из «global» диапазона.

Но каким образом система узнала про то, кто его шлюз по умолчанию? И как вообще может жить /128?

Часть вторая, промежуточная: мультикасту мультикаст мультикастно мультикастит


Посмотрим на таблицу маршрутизации:

ip -6 route show (обычно сокращают до ip -6 r s, или даже ip -6 r):
2a00:11d8:1201:0:962b:18:e716:fb97 dev eth2  proto kernel  metric 256 
fe80::/64 dev eth2  proto kernel  metric 256 
default via fe80::768e:f8ff:fe93:21f0 dev eth2  proto ra  metric 1024  expires 1779sec


Что мы тут видим? Первое — говорит нам, что наш IPv6 адрес — это адрес нашего интерфейса eth2. Второе говорит, что у нас есть link-local сегмент в eth2. У обоих источник — это kernel.

А вот третье — это интрига. Это шлюз по умолчанию, который говорит, что весь трафик надо отправлять на fe80::768e:f8ff:fe93:21f0 на интерфейсе eth2, и источником информации о нём является некое «ra», а ещё сказано, что оно протухает через 1779 секунд.

Что? Где? Куда? Кто? За что? Почему? Зачем? Кто виноват?

Но перед ответом на эти вопросы нам придётся познакомиться с ещё одной важной вещью — multicast. В IPv4 muticast был этакой технологией «не от мира сего». Есть, но редко используется в строго ограниченных случаях. В IPv6 эта технология — центральная часть всего и вся. IPv6 не сможет работать без мультикаста. И без понимания этого многие вещи в IPv6 будут казаться странными или ломаться в неожиданных местах.

Кратко о типах трафика, возможно кто-то пропустил эту информацию, когда изучал IPv4:

  • unicast — пакет адресуется конкретному получателю. Обычный трафик идёт юникастом.
  • broadcast — пакет адресуется всем, кто его слышит. Например, в IPv4 так рассылается запрос о mac-адресе для данного IP-адреса.
  • multicast — пакет адресуется некоторому множеству узлов, которые слушают специальный multicast-адрес. И если получают сообщение, то реагируют на него.
  • anycast — пакет адресуется на адрес, общий для кучи узлов. Кто к запрашивающему ближе (и готов ответить) — тот и отвечает


Так вот, в IPv6 НЕТ БРОДКАСТОВ. Вообще. Вместо них есть мультикаст. И некоторые из мультикаст-адресов являются ключевыми для работы IPv6.

Вот примеры таких адресов (они все link-local, то есть имеют смысл только в контексте конкретного интерфейса):
  • FF02::1 — все узлы сети. Считайте, старинный бродкаст канального уровня.
  • FF02::2 — все маршрутизаторы сети

Полный список адресов, вместе с нюансами link-local, site-local, etc, можно посмотреть тут: www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

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

ping6 -I eth2 FF02::2
64 bytes from fe80::218:e7ff:fe16:fb97: icmp_seq=1 ttl=64 time=0.039 ms
64 bytes from fe80::768e:f8ff:fe93:21f0: icmp_seq=1 ttl=64 time=0.239 ms (DUP!)
64 bytes from fe80::211:2fff:fe23:5763: icmp_seq=1 ttl=64 time=1.38 ms (DUP!)
64 bytes from fe80::5a6d:8fff:fef5:6235: icmp_seq=1 ttl=64 time=5.68 ms (DUP!)
64 bytes from fe80::cad7:19ff:fed5:25b8: icmp_seq=1 ttl=64 time=7.20 ms (DUP!)
64 bytes from fe80::22aa:4bff:fe1e:9e88: icmp_seq=1 ttl=64 time=8.19 ms (DUP!)
64 bytes from fe80::5a6d:8fff:fe4a:c643: icmp_seq=1 ttl=64 time=8.69 ms (DUP!)
64 bytes from fe80::205:9aff:fe3c:7800: icmp_seq=1 ttl=64 time=11.1 ms (DUP!)
64 bytes from fe80::20c:42ff:fef9:807a: icmp_seq=1 ttl=64 time=16.0 ms (DUP!)


Сколько маршрутизаторов вокруг меня… Первым откликнулся мой компьютер. Это потому, что он тоже роутер. Но вопрос маршрутизации мы рассмотрим чуть позже. Пока что важно, что мы видим все роутеры и только роутеры (а, например, ping6 -I eth2 FF002::1 показывает порядка 60 соседей).

Мультикаст-групп (группой называют все узлы, которые слушают данный мультикаст-адрес) много. Среди них — специальная группа FF02::6A с названием «All-Snoopers». Именно этой группе и рассылаются routing advertisements. Когда мы хотим их получать — мы вступаем в соответствующую группу. Точнее не мы, а наш компьютер.

Часть третья: routing advertisements


В IPv6 придумали такую замечательную вещь — когда маршрутизатор рассылает всем желающим информацию о том, что он маршрутизатор. Рассылает периодически.

В отношении этого вопроса есть целый (всего один, что удивительно) RFC: tools.ietf.org/html/rfc4286, но нас интересует из всего этого простая вещь: маршрутизатор рассылает информацию о том, что он маршрутизатор. И, может быть, чуть-чуть ещё информации о том, что в сети происходит.

Вот откуда наш компьютер узнал маршрут. Некий маршрутизатор сказал ему «я маршрутизатор». И мы ему поверили. Почему мы выбрали именно его среди всех окружающих маршруштизаторов (см ответ на пинг на FF02::2 выше) мы обсудим чуть дальше. Пока что скажем, что этот «настоящий» маршрутизатор правильно себя анонсировал.

Таким образом, происходит следующая вещь:

У нас адрес 2a00:11d8:1201:0:962b:18:e716:fb97/128, и ещё есть link-local. Мы слышим мультикаст от роутера, верим ему, и добавляем в таблицу маршрутизации нужный нам адрес как default. С этого момента мы точно знаем, что адрес в сети. Таким образом, отправка трафика в интернет больше не проблема. Мы генерируем пакет с src=2a00:11d8:1201:0:962b:18:e716:fb97 и отправляем его на шлюз по умолчанию, который в нашем случае — fe80::768e:f8ff:fe93:21f0. Другими словами, мы отправляем трафик не своему «шлюзу» в сети, а совсем другому узлу совсем по другому маршруту. Вполне нормальная вещь как для IPv6, так и для IPv4, правда, для IPv4 это некая супер-крутая конфигурация, а для IPv6 — часть бытовой повседневности.

Но как трафик приходит обратно? Очень просто. Когда маршрутизатор провайдера получает пакет, адресованный 2a00:11d8:1201:0:962b:18:e716:fb97, то у него на одном из интерфейсов написано, что он там 2a00:11d8:1201::/64 via (я не знаю, как там называется интерфейс, но пусть) GE1/44/12. Маршрутизатор спрашивает всех соседей (neighbor discovery) об их адресах, и внезапно видит, что адрес такой-то в сети. Что может быть проще — мак есть, адрес есть, отправляем в интерфейс. Ура, наш компьютер видит трафик. Двусторонняя связь установлена.

Въедливый читатель может спросить несколько вопросов: что значит «написано на интерфейсе»? И что значит «neighbor discovery»?

Вопросы справедливые. Для начала попробуем выяснить, какие узлы у нас есть в сети из подсети 2a00:11d8:1201::/64

Для того, чтобы посмотреть router advertisement на интерфейсе нам поднадобится программа radvdump из пакета radvd. Она позволяет печатать анонсы, проходящие на интерфейсах, в человеческом виде. Заметим, сам пакет radvd нам ещё пригодится (так как его демон — radvd позволяет настроить анонсирование со своих интерфейсах).

Итак, посмотрим, что аносирует нам Tiera:

radvdump eth2 (и подождать прилично, ибо анонсы не очень часто рассылаются)
#
# radvd configuration generated by radvdump 1.9.1
# based on Router Advertisement from fe80::768e:f8ff:fe93:21f0
# received by interface eth2
#
interface eth2
{
	AdvSendAdvert on;
	# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
	AdvManagedFlag on;
	AdvOtherConfigFlag on;
	AdvReachableTime 0;
	AdvRetransTimer 0;
	AdvCurHopLimit 64;
	AdvDefaultLifetime 1800;
	AdvHomeAgentFlag off;
	AdvDefaultPreference medium;
	AdvSourceLLAddress on;
	AdvLinkMTU 9216;

	prefix 2a00:11d8:1201::/64
	{
		AdvValidLifetime 2592000;
		AdvPreferredLifetime 604800;
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr off;
	}; # End of prefix definition

}; # End of interface definition


Из всего этого важным является:
  • Адрес, с которого получен анонс (в нашем случае fe80::768e:f8ff:fe93:21f0) — это и есть адрес шлюза.
  • Указание на сетевой сегмент, в котором можно автоконфигурировать себе адреса
  • Флаг AdvAutonomous on, указывающий, что этот анонс имеет смысл. Если бы флаг был off, то его бы можно было смело игнорировать.


Таким образом всё просто — адрес мы указали, маршрутизатор нам «себя» прислал, ядро маршрут обновило. Вуаля, у нас IPv6 на компьютере заработал.

Белый IPv6-адрес для каждого в домашней сети


Получить IPv6 адрес для компьютера — этого маловато будет. Хочется так, чтобы каждое мобильное устройство сидело не за позорным NAT'ом, а голой задницей с белым адресом в Интернете. Желательно ещё при этом так, чтобы злые NSA/google не могли по хвостику моего адреса (в котором закодирован MAC) отслеживать мои перемещения между разными IPv6-сетями (хотя в условиях установленного play services эта параноидальность выглядит наивной и беззащитной).

Но, в любом случае, у нас задача раздать интернет дальше.

Tiera, выдавая мне ipv6, настроила у себя маршрут: 2a00:11d8:1201:32b0::/64 via 2a00:11d8:1201:0:962b:18:e716:fb97.

Так как fb97 уже является адресом моего компьютера, настройка машрутизации плёвое дело:

sysctl net.ipv6.conf.all.forwarding=1


… и у нас через пол-часика полностью отваливается IPv6 на компьютере? Почему? Кто виноват?

Оказывается, линукс не слушает routing advertisement, если сам является маршрутизатором. Что, в общем случае, правильно, потому что если два маршрутизатора будут объявлять себя маршрутизаторами и слушать маршруты друг друга, то мы быстро получим простейшую петлю из двух зацикленных друг на друга железных болванов.

Однако, в нашем случае мы всё-таки хотим слушать RA. Для этого нам надо включить RA силком.

Это делается так:
sysctl net.ipv6.conf.eth2.accept_ra=2


Заметим, важно, что мы слушаем RA не всюду, а только на одном интерфейсе, с которого ожидаем анонсы.

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

Если мне выдали настройки автоматом, то я так же хочу раздавать их дальше автоматом. Благо, dhcpd отлично справляется с аналогичной задачей для IPv4.

Прелесть IPv6 в том, что мы можем решить эту задачу (раздачу сетевых настроек) без каких-либо специальных сервисов и в так называемом stateless режиме. Главная особенность stateless режима состоит в том, что никто не должен напрягаться и что-то сохранять, помнить и т.д. Проблемы с DHCP в IPv4 чаще всего вызывались тем, что один и тот же адрес выдавали двум разным устройствам. А происходило это из-за того, что злой админ стирал/забывал базу данных уже выданных аренд. А ещё, если железок много и они забывают «отдать аренду», то адреса заканчиваются. Другими словами, stateful — это дополнительные требования и проблемы.

Для решения тривиальной задачи «раздать адреса» в IPv6 придумали stateless режим, который основывается на routing advertisement. Клиентскую часть мы уже видели, теперь осталось реализовать серверную, дабы накормить IPv6 планшетик.

Настройка анонсов маршрутизации (radvd)


Для настройки анонсов используется специальная программа-демон — radvd. С утилитой из её комплекта (radvdump) мы познакомились чуть выше. Прелесть утилиты в том, что она выводит не просто полученные данные, а готовый конфиг radvd для рассылки аналогичных анонсов.

Итак, настраиваем radvd:
interface eth3
{
   AdvSendAdvert on;
   AdvHomeAgentFlag off;
   MinRtrAdvInterval 30;
   MaxRtrAdvInterval 100;
   prefix 2a00:11d8:1201:32b0::/64
   {
      AdvOnLink on;
          AdvAutonomous on;
          AdvRouterAddr on;
   };
};

Главное тут — префикс и указание на AdvAutonomous.

Запускаем демона, берём ближайший ноутбук (обычная бытовая убунта с обычным бытовым network-manager'ом), рррраз, и получаем…
ip a show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 10:0b:a9:bd:26:a8 brd ff:ff:ff:ff:ff:ff
    inet 10.13.77.167/24 brd 10.13.77.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 2a00:11d8:1201:32b0:69b9:8925:13d9:a879/64 scope global temporary dynamic 
       valid_lft 86339sec preferred_lft 14339sec
    inet6 2a00:11d8:1201:32b0:120b:a9ff:febd:26a8/64 scope global dynamic 
       valid_lft 86339sec preferred_lft 14339sec
    inet6 fe80::120b:a9ff:febd:26a8/64 scope link 
       valid_lft forever preferred_lft forever

Откуда у нас столько ipv6 мы поговорим в следующем разделе, а пока что отметим, что адреса сконфигурировались автоматически. И маршруты у нас такие:

ip -6 r
2a00:11d8:1201:32b0::/64 dev wlan0  proto kernel  metric 256  expires 86215sec
fe80::/64 dev wlan0  proto kernel  metric 256 
default via fe80::5ed9:98ff:fef5:68bf dev wlan0  proto ra  metric 1024  expires 115sec

Надеюсь, читатель уже вполне понимает, что происходит. Однако… Чего-то не хватает. У нас нет dns-resolver'а. Точнее есть, но выданный dhcpd по IPv4. А у нас пятиминутка любви к IPv6, так то ресолвер нам тоже нужен IPv6.

Тяжело расчехляя aptitude ставим dhcpv6 и прописываем опции nameserver Как бы не так!

К счастью, IPv6 очень долго продумывался и совершенствовался. Так что мы можем решить проблему без участия DHCP-сервера. Для этого нам надо добавить к анонсу маршрута ещё указание на адреса DNS-серверов.

RDNSS в RA


Описывается вся эта примудрость в RFC 6106. По сути — у нас есть возможность указать адрес рекурсивного DNS-сервера (то есть «обычного ресолвера») в анонсе, распространяемом маршрутизатором.

По большому счёту это всё, что мы хотим от DHCP, так что DHCP там тут не нужен. Компьютеры сами делают себе адреса непротиворечивым образом (то есть для исключения коллизий), знают адреса DNS-серверов. Интернетом можно пользоваться.

Для этого мы дописываем в конфиг radvd соответствующую опцию:

   RDNSS 2001:4860:4860::8888 2001:4860:4860::8844
   {
   };

(полный конфиг — см. в конце статьи).

Пробуем подключиться снова — и, ура, всё работает.

ping6 google.com
PING google.com(lb-in-x66.1e100.net) 56 data bytes
64 bytes from lb-in-x66.1e100.net: icmp_seq=1 ttl=54 time=25.3 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 25.312/25.312/25.312/0.000 ms


google.com выбран был не случайно. Сервисы гугля (в немалой степени youtube) — это едва ли не основной источник IPv6 трафика в настоящий момент. Второй источник — торренты, где можно увидеть аж 5-10% пиров в IPv6 варианте.

На этом рассказ можно было закончить, если бы не ещё одна важная деталь — что за третий IPv6-адрес на интерфейсе ноутбука? И что это за temporary dynamic?

Privacy extension


Как я уже упомянул выше, автоматическое конфигурирование IPv6-адреса на основе MAC-адреса сетевого адаптера хорошо всем, кроме того, что создаёт практически идеальное средство для отслеживания пользователей в сети. Вы можете брать любые браузеры и операционные системы, использовать любых провайдеров (использующих IPv6, так что это всё пишется с прицелом на будущее) — но у вас будет один и тот же MAC-адрес, и любой гугуль, NSA или просто спамер смогут вас отслеживать по младшим битам вашего IPv6 адреса. Старшие будут меняться в зависимости от провайдера, а младшие сохраняться как есть.

Для решения этой проблемы были придуманы специальные расширения для IPv6, называющиеся privacy extensions (RFC 4941). Как любое RFC, его чтение — это обычно признак отчаяния, так что по сути этот стандарт описывает как с помощью шаманства и md5 генерировать случайные автоконфигурируемые адреса.

Как это работает?

Хост, в нашем случае обычная убунта на обычном ноутбуке, генерирует штатным образом IPv6 адрес из анонса маршрутизатора. После этого она придумывает себе другой адрес, проверяет, что этот адрес не является зарезервированным (например, нам так повезло, и md5 хеш сгенерировал нам все нули — вместо того, чтобы трубить об этом на всех углах, этот изумительный md5 хеш будет выкинут и вместо него будет взят следующий), и, главное, проверяет, что такого адреса в сети нет. Для этого используется штатный механизм DAD (см ниже). Если всё ок, то на интерфейс назначается новосгенерированный случайный адрес, и именно он используется для общения с узлами Интернета. Хотя наш ноутбук с тем же успехом ответит на пинг и по основному адресу.

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

Duplicate Address Detection


Последняя практически важная фича IPv6 — это DAD. Во времена IPv4 на вопрос «а что делать, если адрес, назначаемый на хост, уже кем-то используется в сети» отвечали «а вы не используйте адреса повторно и всё будет хорошо».

На самом деле все вендоры реализовывали свою версию защиты от повторяющегося адреса, но работало это плохо. В частности, линукс пишет о конфликте IPv4 адресов в dmesg, Windows — в syslog… Event… Короче, забыл. В собственную версию журнала и показывает жёлтенко-тревожненький попапик в трее, мол, бида-бида. Однако, это не мешает использовать дублирующийся адрес, если он назначен статикой, и приводит к головоломным проблемам в районе ARP и времени его протухания (выглядит это так: с одного компьютера по сети по заданному адресу отвечает сервер, а с другого, по тому же адресу, допустим, залётный ноутбук, и они ролями периодически меняются).

Многие DHCP-сервера (циски, например), даже имели специальную опцию «проверять пингом» перед выдачей адреса.

Но всё это были доморощенные костыли для подпирания «а вы не нажимайте, больно и не будет».

В IPv6 проблему решили куда более изящно. При назначении IPv6 адреса запускается прописаный в RFC алгоритм (то есть выполняемый всеми, а не только premium grade enterprise ready cost saving proprietary solution за -цать тысяч). Этот алгоритм называется Optimistic DAD (RFC 4429), и его суть сводится к простому: кто первый встал, того и тапки. Включая прилагающийся IPv6 адрес.

Сам DAD работает отлично, но у него есть мааааленькая подлость, с которой я как-то столкнулся. Если (дополнительный) адрес на интерфейс вешать простым ip -6 address add, то ip отработает раньше, чем закончится DAD. Так что если этот адрес используется дальше в скрипте или конфигах автостартующих демонов, то демоны могут отвалиться по причине «нет такого адреса» — линукс не экспортирует в список доступных для приложений те адреса, про которые нет уверенности, что их можно использовать.

Конфиги


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

/etc/network/interfaces:

auto lo eth2 eth3
iface lo inet loopback

allow-hotplug eth2 eth3

iface eth2 inet static
	address 95.161.2.76
	netmask 255.255.255.0
	gateway 95.161.2.1
	dns-nameservers 127.0.0.1  #У меня локальный ресолвер на базе bind'а

iface eth2 inet6 static
	address 2a00:11d8:1201:0:962b:18:e716:fb97/128
	dns-nameservers ::1

iface eth3 inet static
	address 10.13.77.1
	netmask 255.255.255.0

iface eth3 inet6 static
	address 2a00:11d8:1201:32b0::1/64

/etc/sysctl.d/ra2.conf
net.ipv6.conf.eth2.accept_ra=2

/etc/sysctl.d/ip_forwarding.conf
net.ipv4.conf.all.forwarding = 1
net.ipv6.conf.all.forwarding = 1

/etc/radvd.conf
interface eth3
{
   AdvSendAdvert on;
   AdvHomeAgentFlag off;
   MinRtrAdvInterval 30;
   MaxRtrAdvInterval 100;
   prefix 2a00:11d8:1201:32b0::/64
   {
	  AdvOnLink on;
          AdvAutonomous on;
          AdvRouterAddr on;
   };
   RDNSS 2001:4860:4860::8888 2001:4860:4860::8844
   {
   };
};

/etc/dhcp/dhcpd.conf
ddns-update-style none;

option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;

default-lease-time 600;
max-lease-time 7200;

log-facility local7;

subnet 10.13.77.0 netmask 255.255.255.0 {
	range 10.13.77.160 10.13.77.199;
	option routers 10.13.77.1;
	option domain-name-servers 10.13.77.1;
}

Используется ли IPv6?


У меня обычный домашний компьютер. Чуть-чуть raid, LVM XFS, BTRFS, LUCKS, свой почтовый и веб-сервера, dns-сервер и т.д. Я подключен к обычному домашнему провайдеру с IPv6.

Вот статистика использования интернета за четыре дня. Собиралась она простым способом:
iptables -t filter -A INPUT
ip6tables -t filter -A INPUT
(смотреть счётчики - iptables -L -v, и ip6tables -L -v)


И вот какая она получилась:

  • 4.5% (2.7 Гб) IPv6
  • 95.5% (59 Гб) — представители прочих, устаревающих, версий IP

Таким образом, IPv6 занимает второе место по распространённости в Интернете (если Майкрософту с виндофонами так желтить можно, почему мне нельзя?).

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

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

О поддержке в оборудовании


Десктопные линуксы, понятно, IPv6 поддерживают и используют.
Андроиды (4+) тоже умеют и используют. Пока что найдена только одна забавная бага, это неответ на пинги по IPv6 (но ответ по IPv4) в deep sleep режимах.
Насколько я знаю, IOS'ы IPv6 поддерживают и используют.
Георгий Шуклин @amarao
карма
268,0
рейтинг 18,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (125)

  • 0
    При назначении IPv6 адреса запускается прописаный в RFC (скипнуто).

    Кто там запускается?
    • 0
      Поправил, спасибо.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    В Санкт-Петербурге есть такой провайдер — Tierа.

    Только на В.О. что-то их не видно, или я плохо смотрю?
    • 0
      Я в центре живу. А вообще, они много где.
  • 0
    «Оно работает само» — это не объяснение для инженера, и магии тут никакой нет.
    nashvill просил передать:
    адрес вы получили не просто так, а все же при dhcpv6 запросе, где был запрошен и адрес, и блок
    и в ответе получили помимо друх адресов еще и адреса DNSv6 серверов:
    ну а в момент когда свалился ответ как раз настроилась маршрутизация выданного ему блока на его роутер на стороне тиеры

    Как-то так ;)
    • +2
      У меня нет dhcpv6-клиента. Возможно, подразумевалась другая схема использования, в этом случае я хочу услышать как это «должно было быть» от Тиеровцев.

      Я пока что обхожусь слушанием RA + статическим IP на маршрутизирующем интерфейсе, плюс своим radvd на домашнем интерфейсе.
      • +4
        Ваш случай, признаюсь, наиболее непопулярный и наименее удобный для меня, как оператора. С вашей стороны получилось все в целом просто и ненавязчиво, с моей же стороны мне пришлось нарисовать пачку костылей чтобы системы контроля конфигов маршрутизаторов не трогали статический IPv6 раут выданного вам блока на ваш роутер ибо все остальное работает действительно автоматически, как у вас :)

        Я давно вынашиваю идею либо выступить с лекцией по опыту внедрению IPv6 на одной из распространенных российский телеком пьянок, и/или написать статью на хабре, чтобы показать как все это выглядит со стороны оператора и какие реальные масштабные проблемы создают неудачное исполнение IPv6 на абонентских роутерах.
        • +2
          Ох, извините. Я честно пытался найти документацию, но большинство всего сводилось к «зайди в настройки веб-морды рутера и клинки туда-то».

          А как должно было выглядеть правильное решение? Допустим, некий умный маршрутизатор и сетка за ним. Как должен выглядеть идеальный конфиг?
          • +3
            Правильное решение это dhcpv6 клиент с вашей стороны.
            В нем все просто — говорим, чтобы запрашивал блок. Дальше по связке он сам рисует конфиг для radvd на основе полученных адресов.
            При этом со стороны оператора это выглядит как dhcpv6 request с DHCPv6 DUID по которому в конечном счете мы и авторизуем абонента, наш маршрутизатор релеет ваш запрос на наш dhcpv6 сервер, сервер отвечает релею, релей (маршрутизатор) создает динамический IPv6 route, выданного абоненту блока, на IPv6 адрес (причем это будет как раз fe80 адрес) и направляет ответ уже роутеру абонента.
            Это идеальная схема, которая работает у нас для 99% абонентов так или иначе захотевших IPv6.

            Что касается конфига — тут все сильно индивидуально для каждого вендора абонентского роутера. Начиная с того, что у кого-то это isc-dhcp, а у кого-то wide-dhcp.
            • +1
              Таким образом, правильная схема выглядит так:

              у меня на компьютере маршрутизаторе link-local и запущен dhcpv6-client с указанным duid, который, я вроде бы отправлял, и, надеюсь, не посеял (не, не посеял, так и лежит в /var/lib/dhcpv6/dhcp6s_duid). В ответ мне присылают /64 сегмент, который маршрутизируется через link-local адрес автономного маршрутизатора.

              При этом в момент выдачи ваш роутер запоминает «duid -> ipv6 сегмент ->link-local того, через кого маршрутизировать»? А ipv6-сегмент всё время один и тот же, или от разу к разу различается?

              А дальше я с этой сеткой делаю уже что хочу, но уже целиком в своей сети? (То есть «наружу» вообще нет никакого link-local).

              Последний вопрос: текущая прибитая гвоздями схема и старая схема вместе жить могут? (читать: могу начинать экспериментировать в dhcpv6/duid без поломки существующей схемы?).
              • +3
                Роутер DUID не запоминает, я склонен считать, что он вообще не знает что это такое :)
                DUID нужен только вашему dhcpv6 клиенту чтобы как-то идентифицироваться и нашему dhcpv6 серверу чтобы вас идентифицировать. Наш dhcpv6 сервер по вашему DUID понимает про кого именно идет речь и отправляет dhcpv6 reply в сторону нашего маршрутизатора. Наш маршрутизатор ловит ответ смотрит что там решили выдать абоненту и создает динамический раут, после чего отправляет ответ уже вашему dhcpv6 клиенту.

                Так как на нашем dhcpv6 сервере четко указан выданный вам блок, то он будет всегда одним и тем же.
                Полученную /64 сетку вы мучаете как вам угодно, но лишь в пределах вашего роутера, на который мы ее смаршрутизировали.

                Прибитая гвоздями схема лишь от части будет работать с попытками поднять динамическую маршрутизацию, однако если реальный Ipv6 адрес с внешнего интерфейса вашего роутера принудительно не убирать, то ничего не сломается.
                • +1
                  Ясно, спасибо. Попробую в ближайшие дни переделать.
        • 0
          Валера, давай про в6 на ближайшем биринге? А то с Ёбургом я в пролёте как обычно… ДР у жены как раз на те числа.
          • 0
            На биринге читают доклады?))
            • 0
              А как же!
              В узком кругу специалистов широкого профиля, только на утро никто ничего не помнит :)
              • +1
                Ну так-то да…
    • +2
      О, а он на хабре. Кастую сюда, в комменты.

      nashvill, зажгись прийди.
  • 0
    Пользователю выделяется один IPv6 адрес (для маршрутизатора или компьютера), плюс /64 сетка для всего остального

    Хм, а неплохая практика. Есть провайдеры, которые выдают только одну /64, и больше ничего. И для того, чтобы ее смаршрутизировать, приходится делать либо IPv6-бридж (пропускать протокол 41 сразу провайдеру), либо костылять другими способами.
    Но, в то же время, блин, почему не две /64? Или одну /60? RIPE советует, вообще, пользователям /56 давать.

    Ну и, amarao, отличная статья! У меня был IPv6 настроен дома с 2010, наверное. Я вижу в нем одни только плюсы, даже через туннели.
    • 0
      Из всего этого на практике я видел использование только host/interface, link/local и global. В свете /64 и пусть никто не уйдёт обиженным, специально возиться с site-local адресами будет только параноик.

      Не совсем. Иногда site-local бывают очень кстати. Например, вам нужно маршрутизировать какой-то трафик, но вы не хотите выдавать маршрутизатору IP из global-диапазона, а link-local использовать либо не получается, либо нежелательно.
      • +4
        Вот еще что.
        Скажем, есть у вас 2 компьютера с поддержкой IPv6, скажем, один без монитора и с ssh-сервером, а второй — ноутбук. Нужно вам подключиться к первому компьютеру. Он получает IPv4 по DHCP, а IPv6 «не настроен». На ноутбуке вам влом поднимать DHCP-сервер.
        Берете и пингуете ff02::1, как описано в статье. Получаем DUP от какого-то адреса. Ну а дальше просто:
        ssh fe80::…%eth0

        Нам необходимо указать интерфейс, т.к. это link-local адрес. Указание интерфейса через знак процента работает почти везде.
    • +1
      А зачем вам две /64?

      Скорее всего, на самом деле устроено так: дают один адрес A из /64 (а может быть из /126), в которой так же находится и машрутизатор провайдера, а на этот адрес маршрутизируют другую /64-сеть N, на манер ip route add N/64 via A. Предполагается, что на одной стороне маршрутизатора (который в сторону провайдера) будет настроен адрес A, а как там пользователь загрузит N/64 — настроит ли на компах, нарежет ли — это его дело.
      • +3
        В идеальной схеме отдельно выдаваемый адрес роутеру вообще не нужен и является откровенно лишним. Со стороны провайдера так или иначе блок должен маршрутизироваться на fe80 адрес роутера.
        Частные случаи, когда мы выдаем отдельный адрес роутеру, связаны с абонентскими роутерами, которые не в состоянии отправлять исходящие в мир запросы с адреса, назначенного внутреннему интерфейсу (т.е. с адреса выданного блока).
        • 0
          Согласен полностью, link-local достаточно.
    • 0
      RIPE советует, вообще, пользователям /56 давать.

      Это все, безусловно, замечательно, однако основной идеей RIPE при выдаче такого блока было, что этот /56 будет поделен на внушительную пачку /64, каждая из которых будет жить своей жизнью из серии, одна /64 это своя сетка, вторая гостевая, третья еще как-нить, например, техническая и так далее; зачем под это отдали так много — лично я не понимаю.
      По факту я вижу то, что абонентские роутеры едва ли в состоянии справиться с единичной /64 и меня терзают смутные сомнения, что им не поплохеет, если они получат вместо ожидаемых /64 вдруг /56.
      • 0
        Почему вы так думаете? От чего им поплохеет? Какая вообще роутеру с двумя дырками разница, какого размера сети там и там? Он только и делает, что перекладывает из правого порта в левый и наоборот :)
        • 0
          Ой ли…
          Не поверите, но большинство абонентских роутеров вообще ни разу не ожидает увидеть в качестве полученного PD что-то отличное от /64. А причина очень проста — они едва ли научились вообще с IPv6 работать и в сорцах в большинстве случаев чуть ли не константами прописаны размерности сетей равные 64. Надо отдать должное, IPv6, как и годами раньше, это, увы, до сих пор всего лишь игрушка, а не стабильно работающий «инструмент».
          • 0
            Так в них же во всех линукс крутится, причём сейчас это уже 2.6-ветка, по идее, ipv6 должен быть нормальный
  • +2
    Скажите, кто следит, сейчас адреса IPv6 выдают также бесконтрольно целыми пачками (а, дескать, всё равно их дохрена) или же учли ошибку четвёртой версии и на каждый выдаваемый адрес заставляют писать объяснительную, для чего он будет использоваться?
    • 0
      By comparison, this amounts to approximately 4.8×1028 addresses for each of the seven billion people alive in 2011.
      5.4.1. Assignment address space size
      • +1
        Ну а через несколько столетий адресов внезапно не хватит при подключении очередной галактики к вселенскому интернету. И снова начнётся канитель с переходом на какой-нибудь IPv8.
        Не лучше ли проявить немного дальновидности и предусмотреть это уже сейчас?
        • 0
          Сейчас основной префикс который IANA режет RIRам, это 2000::/3, но 3000::/4 в резвре. Поэтому если текущая план выдачи вдруг провалиться, можно заново раздавать из резерва.
    • +2
      Адреса выдают контрольно и выдаёт из (в Европе) RIPE NCC. Основной задачей для IPv6 является агрегация, а не консолидация.

      Примерные правила выделения: /64 на домашнего пользователя. /48 на организацию или PI, /32 стандартная аллокация для LIR'а, но при исчерпании может быть выделено более одной /32.

      Если вы это переведёте из логарифмической формы в обычную, то увидите, что LIR'у выдают для дальнейшей раздачи (из /32 кусочками по /48) всего навсего по 65 тысяч сетей. А каждая /32 — это 1/4миллиарда от адресного пространства интернета (я не считаю спецдиапазоны сейчас).

      Основной идеей сейчас идёт такое построение сетей, чтобы каждому самостоятельному объекту (организации, филиалу и т.д.) соответствовала одна-единственная сетка какого-то размера, а не обширная пачка маленьких сетей. Это и называется агрегация.

      В IPv4 же действует принцип консолидации — то есть «лучше побольше мелких сетей, зато меньшее количество неиспользуемых адресов» — и это сильно осложняет жизнь.
      • +2
        Надо еще заметить, что RIPE выдает /32 не подряд, а с приличными «пробелами» позволяя позже лишь по запросу оператора именно расширить выданный блок аж до /29. Причем в последних письмах они делают упор, что сделают это с удовольствием, без лишней переписки, по первому же запросу оператора/LIRа.
        • +1
          Ого, эту часть я прослушал. В этом случае тренд точно на максимальную агрегацию.
          • +1
            В целом, нынче IPv6 FullView это чуть меньше 15К префиксов (против 477К в ipv4). По моим наблюдениям, рост крайне слабый.
            Надо отдать должное, что варианты когда один и тот же оператор анонсирует более одного v6 префикса сейчас практически не наблюдаются, что позволяет держать рост таблицы минимальным.
  • +3
    Опасносте, в interfaces комментарии могут быть только в начале строки!

    Кстати, в версии 0.7.45 появилось экспериментальное решение для DAD, потестируйте, пожалуйста
    • 0
      И «allow-hotplug eth2 eth3» в принципе лишнее, auto тремя строками выше определено.

      (таки конфиги читают, они обычно интереснее чем текст же)
      • 0
        auto — это «поднимать интерфейс при старте», а allow-hotplug — это переконфигурировать интерфейс при linkup/down или появлении интерфейса.

        auto без hotplug — отключили/подключили — нет сети.
        hotplug без auto — загрузились, сети нет, воткнули/вынули кабель, сеть появилась.
        • +1
          auto без hotplug — отключили/подключили — нет сети.


          Не совсем так — при наличии auto сеть отключаться c точки зрения ifup/ifdown при пропадании линка просто
          не будет
          node:~# grep allow /etc/network/interfaces
          node:~# grep auto /etc/network/interfaces | grep eth
          auto eth0
          node:~# ip link | grep eth0
          2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> blah blah
          # eth0 plug off:
          node:~# dmesg | tail -1
          [166457.930384] e1000e: eth0 NIC Link is Down
          node:~# ip link | grep eth0
          2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> blah blah #note NO-CARRIER
          node:~# ifconfig | grep eth0
          eth0 Link encap:Ethernet HWaddr 00:0b:ad:c0:ff:ee # note interface is still up
          # rj45 plug back
          node:~# dmesg| tail -2
          [166565.256986] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
          [166565.257110] e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO
          node^ ~# ping c1 www.ru #success


          Отключили — нет сети, подключили — опять есть.
          • +1
            Поправка, речь не про патч. Я вспомнил, в чём там дело было — появление/исчезновение интерфейса (то есть vif-plug/unplug в моём случае). Физический аналог — втыкание/вынимание usb-сетевухи.
          • 0
            Вы неправы.
            • 0
              Да, я уже понял, что поспешил. Смутило «переконфигурировать интерфейс при linkup/down».
        • 0
          hotplug — не про кабель, а про сетевуху. При появлении интерфейса (в любом состоянии) udev запускает ifup, а при удалении (например, по rmmod) — запускает ifdown.
    • 0
      Коммент в конфиге писался только в статье, да.

      А что за решение для DAD? Не видел, не читал.
      • 0
        Ну почитайте. Скрипт, который дожидается его окончания, ну или трубит тревогу.
  • 0
    возможно я задам тупой вопрос =)
    а если твой провайдер выдаёт IPv6, но нет никакого желания городить дома самодельный маршрутизатор, есть ли сейчас доступная возможность взять для данной цели какую-нибудь недорогую консьюмерскую железку? скажем так, обычный вайфай-роутер, который помимо всего прочего может работать с IPv6. или таких ещё нет?
    • 0
      Многие железки поддерживают ipv6 passthrough, поэтому даже ничего настраивать не придется.
    • +1
      Есть конечно, довольно много. Работает и на родных прошивках, и на всяких WRT. Уже как с год на моём Asus RT-N56U функционирует шестёрка через брокера. Домашние Android, iOS, MacOS, Win7 и даже NAS от Synology (!) вкушают блага цивилизации.
  • +5
    Идеальная статья. Вспомнился старый и уютный хабр. Эх.

    А вообще, не могли бы вы обьяснить что происходит дальше?
    Вот у меня есть конечный адрес, я трафик передал на машрутизатор(термин шлюз корректен?), а дальше?
    Получается в локальной сети он однозначно определяет адрес источника по мак адресу ethernet frame, или там есть отдельное поле «настоящий источник» и «локальный источник»?
    И получается что для обратной связи все машрутизаторы хранят таблицы сессий?

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

    И еще раз спасибо за статью, мне очень понравился ваш стиль изложения, я получил ощущаемое(а не только произностимое: в стиле пишу LOL, а сижу с каменным лицом) удовольствие. Заумь RFC переведена по сути, для конкретной аудитории на простой язык.
  • +1
    В разделе про «белый адрес для каждого»:

    Так как fb97 уже является адресом моего компьютера, настройка машрутизации плёвое дело:
    sysctl net.ipv4.conf.all.forwarding=1


    Неужели маршрутизация для ipv6 также висит на переменной ipv4? Или тут опечатка?
    • +1
      Опечатка, конечно. Должно быть net.ipv6.conf.all.forwarding
    • +5
      Ах, уели. Сейчас поправлю.
  • +3
    Не, ну как вот объяснить, что провайдер в Питере даёт ipv6 домашним пользователям правильнее, чем Hetzner в германии для серверов?
    • 0
      Насколько я помню, ещё и скорость не режется по IPv6 у Tiera, то есть теоретически можно и гигабит дома выжать )
  • 0
    RIPE советует, вообще, пользователям /56 давать

    думаю когда нибудь так и может случиться,
    просто сейчас ещё не отпускает страх «а вдруг закончатся» — обычная инерция мышления. Хотя может им так удобнее.
    • 0
      Нет, правда, одно дело, когда «640 Кб хватит каждому», и другое — "/64 хватит каждому". Несопоставимые масштабы.
  • +1
    Отличная статья, спасибо.
    По поводу маршрутизаторов — а как определяется, какой именно нужно использовать?
    Ну т.е. делаем мультикаст, получаем список — а дальше? И что помешает в таком случае легко и свободно провернуть MitM, прикинувшись маршрутизатором?
    • 0
      Увы ничего не мешает и такие ситуации встречаются относительно часто. Бороться можно лишь в случае когда на доступе стоит коммутатор умеющий фильтровать неугодные (заведомо нелегитимные) RA.
      • +1
        Ну так и сейчас уважающие себя провайдеры разрешают DHCP offer приходить только из определённого порта. Я могу поднять DHCP-сервер в сторону провайдера, но никому он не ответит.
        • +1
          Потому что заблочить входящие с абонентского порта IPv4 пакеты с source портом 67 всяко проще, чем разбирать IPv6 RA в поисках что ж там абонентский роутер решил наанонсить «в мир», да еще и мультикастом в придачу.
          • 0
            Чем отличается блокирование входящего с порта клиента ICMPv6 type 134 от блокирования входящего с порта клиента UDP source port 67?

            • 0
              По-моему вы вполне сами себе на вопрос и ответили, разве нет?
              Если нет, то в случае IPv4 это банальный extended ACL, а во втором это уже залезание внутрь пакета, что умеют далеко не все коммутаторы.
              • 0
                Видно, туплю под вечер, но не очень понимаю, чем заглядывание в то, что следом за заголовком ip(v4/v6)-пакета, отличается. Тем, что ipv6-пакет сложнее, может содержать всякие hop-by-hop?
                • +1
                  Тем, что большинство коммутаторов умеют делать ACL только на L4 уровне. То, что о чем мы с вами говорим, уже совсем не L4.

                  В терминологии DLink это, вроде как, PCL — packet content layer.
  • 0
    Нужно ещё помнить, что если взялся настраивать IPv6, то настраивай до конца. Я в своё время баловался с настройками, пробовал запустить 6to4, но по какой-то причине бросил. IPv6 в локалке успешно работал. Но однажды наткнулся на непонятные проблемы с сетью. Как оказалось, раз компьютер видит, что имеет IPv6 адрес, то пытается иногда (когда есть AAAA запись) подключиться по IPv6. Естественно, обламывается.
    • 0
      Я у себя на Giga включал туннель 6to4 попробовать. Пока не вырубил на нём выдачу локального адреса ipv6 XP пыталось соединиться с ipv6 сайтами при помощи него и обламывалось.
  • 0
    Я как раз на днях настроил 6to4 дома. Поднял приоритет маршрута, и теперь некоторые сайты не открываются :) Думаю, придется отключать взад, если не разберусь.
    А ещё несколько лет назад, когда роутером-с-NAT у меня стоял компьютер с FreeBSD, там ядро уходило в kernel panic, если включить rtadvd. Происходило это не сразу, и я так не смог узнать, где именно там что падало.
  • 0
    А как поступить если, скажем, я не хочу, чтобы мой адрес маршрутизировался в интернете?

    В ipv4 были немаршрутизируемые сети типа 10.0.0.0/8, а в ipv6 сказано что для этой цели есть site-local адреса, но rfc 3879 от 2004 года говорит, что они deprecated, и при этом не говорит прямо что с этим делать.
    • –2
      Если ваш адрес не маршрутизируется в интернете, то у вас не будет и доступа к интернету, поэтому на такой вопрос ответ: не подключаться к интернету вообще :)
      А вообще, вместо site-local нужно использовать тот блок адресов, который вам выдал провайдер.
    • +2
      Вики говорит:
      Unique-Local

      RFC 4193, соответствуют внутренним IP адресам, которыми в версии IPv4 являлись 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16. Начинаются с цифр FC00 и FD00.
    • +5
      1. Сети 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16 — маршрутизируемые. Они «неанонсируемые», т.е. ни одна AS не должна анонсировать эти адреса. Поэтому они и не участвуют в глобальной маршрутизации (впрочем, ради этого следствия и запретили их анонсы). Однако, если пакет с таким адресом попадёт на маршрутизатор (и не будет заблокирован всякими пакетными фильтрами), он будет маршрутизирован как положено по обычным правилам маршрутизации. На этом последнем факте базируются все разветвлённые VPN-ы, «домовые сети» и «городские локалки» провайдеров.

      Это так называемые private-адреса.

      В IPv4 есть действительно немаршрутизируемые адреса, так называемые link-local адреса — 169.254.0.0/16. Вот такой пакет при попадании на маршрутизатор никуда дальше передан не должен быть никогда, то есть он не будет маршрутизироваться.

      site-local адресов в ipv4 нет.

      2. В ipv6 есть link-local адреса — fe80::/64. Абсолютно так же, как в случае с ipv4, такой пакет маршрутизатор не маршрутизирует никогда.

      ipv6 site-local адреса были, но сплыли.

      Но есть и private-сети — fc00::/7 — ipv6 unique local addresses (RFC4193) — они, так же как и private-сети ipv4 не должны анонсироваться вовне AS (4.1. в этом RFC:… the default BGP configuration must filter out any Local IPv6 address prefixes, both incoming and outgoing...). Однако, они маршрутизируются по общим правилам. В общем, они совершенно похожи на 10.0.0.0/8 и прочие из ipv4. В отличие от ipv6, однако, здесь нет стандарта на ipv6 NAT (или я устарел?) и поэтому у вас будут проблемы, если вы захотите «выпустить их в интернет» (хотя, например, linux начиная с 3.8 поддерживает ipv6 nat, ни разу не пробовал).

      (я полагаю, от site-local потому и отказались, что при наличии ula они не нужны)
      • 0
        Спасибо за полный ответ. Похоже, Unique Local адреса — это то, что нужно.
  • 0
    Если уж на чужом языке, то грамотно — nobody careS. Хотя чаще говорят «Who cares?».
  • +3
    Чего-то не хватает, чтобы можно было сказать «получилось красиво».
    Prefix Delegation — это такая магия, которая позволяет получать от провайдера первую половину адреса внутренней (домашней) сети, а вторую половину назначать самостоятельно. Т.е. в терминах IOS (копипаста из доки):
    ipv6 dhcp client pd prefix-from-provider
    
    !--- The DHCP client prefix delegation is 
    !--- given the name prefix-from-provider.
    
    interface FastEthernet0/0
    no ip address
    duplex auto
    speed auto
    ipv6 address prefix-from-provider ::1:0:0:0:1/64
    
    !--- The first 48 bits are imported from the delegated
    !--- prefix (2001:db8:1200) and the ::/64 is the client
    !--- identifier that gives the interface Fa0/1 the
    !--- global IPv6 address 2001:DB8:1200:1::1/64.

    Никакой статики никогда и нигде! Только PD + EUI-64 (тоже можно)!
    Для решения тривиальной задачи «раздать адреса» в IPv6 придумали stateless режим, который основывается на routing advertisement.

    Stateless DHCP — это тот же DHCP, хотя покороче. Данные из RA могут учитываться, а могут и не учитываться. Тут разные системы ведут себя по-разному.
    В IPv4 muticast был этакой технологией «не от мира сего». Есть, но редко используется в строго ограниченных случаях.

    Сразу видно серверного админа :)
    • +1
      Stateless DHCP — это тот же DHCP, хотя покороче. Данные из RA могут учитываться, а могут и не учитываться. Тут разные системы ведут себя по-разному.

      По хорошему, они должны себя вести ровно так как установлены биты/флаги в RA сообщениях.
      А именно managed-config-flag и other-config-flag.
      Один отвечает за то, что адрес таки нужно получать не из prefix announcement, иными слова не stateless, а statefull, а другой, что еще пачку параметров можно/нужно получить по dhcp6, будь то DNS сервера, как пример.
      • 0
        В пакетах ICMPv6 типа RA присутствует и DNS-сервер тоже. Так что в IPv6-сетях DHCP не особо и нужен.
        • 0
          Поделитесь секретом, кто (и на основании чего) принимает решение о выдаче абоненту блока 2002:b00e:d4f2:1::/64, как это описано в вашем случае.
          • 0
            Это 6to4 блок привязанный к внешнему Ipv4.

            • 0
              Мы с вами друг друга пока не поняли.
              Кто принял решение выдать именно этот блок, кто сгенерировал именно такой пакет, дамп которого вы показали?
              • 0
                Не я показал конечно но судя по тому что в качестве DNS используется адрес начинающийся с fe80 т.е. link-local этот пакет отправил роутер в локальной сети.
                • +3
                  Не я показал конечно

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

                  Основная идея в том, что операторский маршрутизатор при всем желании не должен являться DNS сервером, это, как минимум не его задача. То, что видно в дампе пакета существует только в связке абонентский роутер -> абонентский компьютер. В связке абонентский роутер -> операторский роутер такая схема не взлетит.

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

                  P.S. Я, похоже, догадываюсь в чем возникает общее противоречие между моими постами и постами других участников обсуждения — все рассматривают IPv6 со стороны абонента, я же, напротив, со стороны оператора.
                  • 0
                    А что-то мешает вписать в то поле маршрутизируемый адрес? И пусть DNS сервер стоит где угодно.
                    • +1
                      Никто, это всецело на совести тех, кто пишет софт для абонентских роутеров.
                      • 0
                        Что мешает операторскому роутеру отправить аналогичный пакет с адресом операторского DNS сервера?
                        • +1
                          Как ни банально, но он не умеет так делать.

                          Надо понимать, что оператору УДОБНО, когда абонент получает все по DHCPv6.

                          P.S. И не надо рассказывать, что оператор должен делать так как удобно абоненту — это утопия, такого нет, не было и не будет.

                          P.S.2 Схема с DHCPv6 работает практически идеально, зачем выдумывать разные странные схемы для достижения ТОГО же результата?
                          • 0
                            Router Advertisement с префиксами и прочей лабудой лучше хотя бы тем, что он stateless. Достаточно посылать пакеты время от времени да отвечать на Router Solicitation. Никакой хитрой логики не нужно, хранить аренды адресов тоже не нужно.
              • 0
                Это мой домашний роутер. Если точнее, ASUS RT-N16 с дефолтной прошивкой (пусть и обновленной до последней версии). Купил недавно, так что пока не буду торопиться с выводами, хороший или плохой этот роутер :)
                Прошивка там на основе линукса, крутится демон radvd версии 1.9.3.
                • +1
                  Нормальный роутер, IPv6 на нем работает вполне достойно.
        • 0
          В пакетах ICMPv6 типа RA присутствует и DNS-сервер тоже.

          Многие имплементации роутеров/клиентов не умеют раздавать/принимать DNS сервера в RA. RFC буквально на днях вышел.
      • 0
        По хорошему, они должны себя вести ровно так как установлены биты/флаги в RA сообщениях.

        Не совсем. Никто там ничего не обязан.
        • 0
          Так кто ж против, получил себе «левый» ipv6 адрес из shared блока типа temporarily ipv6 address в винде — сиди в локалке, в мир с него не пустим. Учитывая, что он при каждом чихе меняется на новый, возникает слишком много головной боли ради всяких сормов и прочих любителей поприсылать запросы, их постоянно фиксировать и сохранять.

          Вы поймите одну простую истину — я исхожу не из того, как это описано в RFC и продумано умными и не очень людьми, а из наших, в частности Российских, реалий, как бы это ни было грустно.
          • 0
            Вы, вероятно, промахнулись комментарием при ответе?
            • 0
              Да нет, не промахнулся.
              То, что они не обязаны, вовсе не означает, что такая схема взлетит в реальной сети.
              И, кстати говоря, в реальной сети взлетает ровно так как выставлены флаги.

              P.S. Выше я описал, что будет если игнорировать флаги.
              • 0
                в реальной сети взлетает ровно так как выставлены флаги.

                Нет. Читал я один материал — поведение WinXP, Win7, Linux и MacOS в плане принимания во внимание значений флагов радикально отличается. Вроде семерка вела себя лучше всех (ближе к RFC). Макось вроде полностью игнорировала их значения.

                Причем тут «получил себе «левый» ipv6 адрес из shared блока типа temporarily ipv6 address в винде» и «Российских, реалий» вообще не понял, просьба расшифровать мысль.
                • +1
                  Рассматриваем ситуацию, когда абонентский компьютер подключен напрямую к сети оператора без абонентского роутера.
                  Если есть абонентский роутер, то все выше и нижеописанное не имеет ровно никакого значения.
                  Так вот, если абонентский компьютер игнорирует флаги обозначающие, что настройки нужно получать по DHCPv6, то он получит свой адрес по SLAAC из prefix-advertisement блока оператора, при этом винда при включенном (by default) temporarily ipv6 address получит еще один (второй) ipv6 адрес и все соединения будет выполнять от его «имени».

                  Так вот, мы получим абонента, выходящего в сеть интернет каждый раз с нового в6 адреса. Мы будем вынуждены каждый раз запоминать с какого адреса он вышел (т.е. идентифицировать его с полученным временным в6 адресом) чтобы в случае получения запроса от органов «какой абонент выходил в сеть Интернет такого-то числа с такого-то в6 адреса» мы могли ответить не «а пес его знает», а выдать конкретный ответ.
                  • +2
                    Я, кстати, нашел ту табличку.
                    Скрытый текст


                    Вариант m=1 o=1 вроде на всех ОС означает получение адресации и настроек по DHCP, но вот с остальными комбинациями полный бардак.
                    Мы будем вынуждены каждый раз запоминать с какого адреса он вышел

                    На месте нищеброда-провайдера я бы оставил фильтрацию по макам на порту, и просто писал бы в лог всё связанное с RA на первом хопе. Не стопроцентная панацея, от спуферов, которым не интересен обратный трафик, не защитит.
                    • 0
                      Не табличка, а сплошная жуть. Было бы полезно еще указывать в ней последний примененный патч к ОС, ибо там тоже встречаются изменения.

                      Что касается провайдера-нищеброда, то писать в логи все связанное с RA не столь простая задача, как это выглядит если эту фразу написать на хабре, увы. Вы думаете на доступе у всех, тем более нищебродов-провайдеров, стоят коммутаторы которые знают что такое IPv6? Так вы глубочайшим образом заблуждаетесь.
                      Если речь идет о фиксировании всех IPv6 соседей на ближайшем IPv6 роутере оператора, то да, технически возможно, но это геморрой. Проще отказать абоненту в такой шалости, не выпустив его в «мир».
                      • 0
                        Вы думаете на доступе у всех, тем более нищебродов-провайдеров, стоят коммутаторы которые знают что такое IPv6?

                        Я жк сказал — «на первом хопе». Под хопами обычно понимают роутеры.
                        Задачей свитча будет пропускать пакеты только с правильным smac. Вдаваться в подробности L3 не надо.
                        то да, технически возможно, но это геморрой.

                        Больший, чем протоколировать базу аренд DHCP?
                        Парсер этих данных пишется минут за 5, включая перекуры.
                        • 0
                          Никто не говорит, что проблема в парсинге данных. Вопрос ведь в том, 1) сколько времени хранить и, что логично и немаловажно, 2) где хранить.
                          • 0
                            1) Сколько велено постановлениями и законами. Я не знаю.
                            2) Там же, где и гораздо больший по объему аккаунтинг в виде *flow. Насколько я помню, без него или чего-то подобного провайдеру никак нельзя.
    • +2
      Спасибо, почитаю (в этом и прелесть раннего освоения, что можно сколько угодно тупить, не знать и т.д. — и всем пофигу).

      Насчёт мультикаста и серверных админов — каким бы админ не был, но нужно признать, что большАя часть IPv4 работала без использования мультикаста. В IPv6 без мультикаста пакет до шлюза не дойдёт.
      • 0
        В IPv6 без мультикаста пакет до шлюза не дойдёт.

        Оспорю: можно статически прописать маршруты и соседей (ip neigh add ..) и дойдёт. Проверял, когда из-за глюков драйвера wl broadcom у меня на буке не работали те самые мультикасты — но ipv6 на буке «руками» завести было можно, хотя и неудобно.

        А сейчас там b43, он без таких глюков
      • +1
        Если смотреть на вещи реалистично: единственный случай, когда возможны проблемы с L2 мультикастом (напомню — это та штука, которую по дефолту даже настраивать не требуется, она либо сходу работает нормально, требуя подкручивания лишь из соображений безопасности, либо тоже работает, но как броадкаст, если свитчи — говно) — это L2 каналы поверх провайдеров.

        Ну и да, как подметили выше — IPv4 технически может жить без броадкастов со статическими arp записями, а IPv6 без мультикаста с аналогичными извращениями.

        И еще один момент. Сейчас нельзя игнорировать существование IPv6 даже в v4-only среде. Один вражеский ra способен обойти все ориентированные на IPv4 защиты на коммутаторах и натворить бед. Как минимум — необходимо отключить на всех хостах IPv6.
        • 0
          И еще один момент. Сейчас нельзя игнорировать существование IPv6 даже в v4-only среде. Один вражеский ra способен обойти все ориентированные на IPv4 защиты на коммутаторах и натворить бед. Как минимум — необходимо отключить на всех хостах IPv6.Б


          Был случай, коллега настраивал какой-то конторе интернет. Ну, проработало неделю, и на некоторых компах работать перестало. Кинулись — что, где. А главное, смотреть ездили люди, которые не в курсе, что бывает ipv6 и так далее. Ну реально, некоторые адреса не работают. В общем, спустя пару дней разобрались.

          Выяснилось, что на половине компов там XP, на другой — семёрка. Какой-то чудный человек для чего-то вставил в семёрку 3g-модем и настроил раздачу инета, а потом модем выдрал. Не знаю, зачем и как он настроил ipv6, видимо, teredo или что-то в этом духе. Почему она продолжала раздавать ra без модема — я не знаю, но продолжала. Все семёрки понимали это как «о, ipv6 роутер, айда через него» и ничерта на них не работало.

          Самое обидное, что в конторе нашлись «яндексовские специалисты», которые думают что что-то понимают, и крайне сложно оказалось объяснить им причину проблемы (в том числе что это не была недоработка и не была «закладка», а были слишком большие права у пользователя того компа и слишком шаловливые руки, и что застраховаться от этого они не смогут, не имея админа и достаточно интеллектуального оборудования).
  • 0
    эх, загорелся идей, решил узнать, кто в москве из провайдеров дает ipv6:
    version6.ru/isp
    что-то совсем беда
    • 0
      Попробуйте 6to4
      • 0
        спасибо, интересно. правда провайдер у меня настолько суров, что я сижу за натом и для начала надо статический адрес арендовать
        • +1
          Попробуйте вариант с туннелем до he, статический паблик при таком раскладе не нужен.
          • 0
            спасибо, буду пробовать. но, как я понимаю, это все костыли все таки
            • +1
              Отнюдь, ряд ОПЕРАТОРОВ (надо понимать, что речь про далекие регионы необъятной), аплинки которых не готовы к поднятию IPv6 BGP сессий, поступают именно так.
              • 0
                это интересно. вообще изначально у меня цель было попрактиваться в настройке и получить опыт примерно, как у топик стартера. попробовать все это дело на каком-нибудь микротике/пс хоум роутере поднять и раздать на домашние устройства
                с туннелями это вообще осуществимо или можно сразу забить?
                • 0
                  Ну я с тоннелем 6to4 и роутером Keenetic Giga поднял.
                • 0
                  Я не пробовал и более того не уверен, что схема с HE сработает с home роутером/микротиком.
                  Мне повезло больше — я пнул аплинков и они мне выдали IPv6 BGP связность в реальные сроки.
                  В остальном, повторюсь, на туннелях живут операторы, которым интересен IPv6. Уж не знаю насколько они довольны явно более высоким задержкам, но при отсутствии альтернатив…
                  • 0
                    Я как-то наоборот смотрю на bgp.he.net — все аплинки у нас всё давно умеют, равно как и те провайдеры, что дают интернет детямнаселению. Вон, воронежский филиал Ростелекома ещё в 2008 году впервые попробовал, когда он ещё не был филиалом Ростелекома, ни Центртелекома, а был сам себе ВоронежСвязьИнформ :)

                    На мой вопрос тогда «а когда вы нам выдадите ipv6», они сказали: «когда циско напишут поддержку». И на этом всё.
                • 0
                  Поднимал и на pc и на микротике, все реализуемо и не сложно (stateless, то что описывает автор статьи). Проблемы возникли с попыткой поднять stateful конфигурацию (т.е. dhcpv6) по микротиковским мануалам, вообщем так и не взлетело. Надо снова попробовать, вроде на микротик уже 6ая версия ОС вышла.
          • 0
            Оно за натом не работает.
  • +1
    Огромное спасибо за статью. Ваши статьи аналогично ализаровским вычисляемы, не глядя на автора. Но в отличие от ализаровских по качеству написания и полезности.

    Не встречался ли кто с проблемой, что на стоковом андроиде 4.2.2 на самсунге (galaxy tab 3 10.1 рутованный) не получается ipv6 от radvd на роутере? Все получают, в том числе андроид 4.2.2 от cyanogen'а в телефоне, а планшет не получает. Через openvpn получает IPv6-адрес и все работает.
    • –1
      Та же проблема, что и с пингами ipv6. В спящем режиме он не слушает ipv6 вообще, ни пинги, ни RA. Когда просыпается, оп, а старый ra протух.

      Чистой воды глюка самсунга, насколько я знаю.
  • 0
    Говорят, что ipv6 собирается поддерживать IPSEC. Это уже работает?
  • 0
    «С этого момента мы точно знаем, что адрес в сети. „

    в целом, очень основательно получилось. спасибо.
  • 0
    А можно как-нибудь аналогичным образом использовать блок адресов, который выдаётся облачным серверам в selectel? Насколько я понимаю, там нет разделения на адрес роутера и маршрутизируемую через него сеть, а серверу выдаётся сразу /112 блок адресов.
  • 0
    Отличная статья, спасибо, добавил себе в мемориз избранное.

    Мысль вслух: всё же, насколько более сложно читаются адреса IPv6 по сравнению с IPv4. Хотя, это, наверное, скорее, вопрос привычки. Работают же операционисты в банках с номерами счетов, а там ведь тоже своя структура есть :)
  • 0
    Блин, буквально вчера прочитал с интересом эту статью, а сегодня на конференции по IPv6 от MSK-IX выступал Стрельцов Валерий о том, как они внедряли в компании Tiera IPv6 для пользователей. С какими сложностями и тонкостями пришлось столкнуться. Было весьма любопытно.

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