Комментарии 126
При назначении IPv6 адреса запускается прописаный в RFC (скипнуто).
Кто там запускается?
Кто там запускается?
НЛО прилетело и опубликовало эту надпись здесь
Обратиться в службу поддержки?
В Санкт-Петербурге есть такой провайдер — Tierа.
Только на В.О. что-то их не видно, или я плохо смотрю?
«Оно работает само» — это не объяснение для инженера, и магии тут никакой нет.
nashvill просил передать:
адрес вы получили не просто так, а все же при dhcpv6 запросе, где был запрошен и адрес, и блок
и в ответе получили помимо друх адресов еще и адреса DNSv6 серверов:
ну а в момент когда свалился ответ как раз настроилась маршрутизация выданного ему блока на его роутер на стороне тиеры
Как-то так ;)
nashvill просил передать:
адрес вы получили не просто так, а все же при dhcpv6 запросе, где был запрошен и адрес, и блок
и в ответе получили помимо друх адресов еще и адреса DNSv6 серверов:
ну а в момент когда свалился ответ как раз настроилась маршрутизация выданного ему блока на его роутер на стороне тиеры
Как-то так ;)
У меня нет dhcpv6-клиента. Возможно, подразумевалась другая схема использования, в этом случае я хочу услышать как это «должно было быть» от Тиеровцев.
Я пока что обхожусь слушанием RA + статическим IP на маршрутизирующем интерфейсе, плюс своим radvd на домашнем интерфейсе.
Я пока что обхожусь слушанием RA + статическим IP на маршрутизирующем интерфейсе, плюс своим radvd на домашнем интерфейсе.
Ваш случай, признаюсь, наиболее непопулярный и наименее удобный для меня, как оператора. С вашей стороны получилось все в целом просто и ненавязчиво, с моей же стороны мне пришлось нарисовать пачку костылей чтобы системы контроля конфигов маршрутизаторов не трогали статический IPv6 раут выданного вам блока на ваш роутер ибо все остальное работает действительно автоматически, как у вас :)
Я давно вынашиваю идею либо выступить с лекцией по опыту внедрению IPv6 на одной из распространенных российский телеком пьянок, и/или написать статью на хабре, чтобы показать как все это выглядит со стороны оператора и какие реальные масштабные проблемы создают неудачное исполнение IPv6 на абонентских роутерах.
Я давно вынашиваю идею либо выступить с лекцией по опыту внедрению IPv6 на одной из распространенных российский телеком пьянок, и/или написать статью на хабре, чтобы показать как все это выглядит со стороны оператора и какие реальные масштабные проблемы создают неудачное исполнение IPv6 на абонентских роутерах.
Ох, извините. Я честно пытался найти документацию, но большинство всего сводилось к «зайди в настройки веб-морды рутера и клинки туда-то».
А как должно было выглядеть правильное решение? Допустим, некий умный маршрутизатор и сетка за ним. Как должен выглядеть идеальный конфиг?
А как должно было выглядеть правильное решение? Допустим, некий умный маршрутизатор и сетка за ним. Как должен выглядеть идеальный конфиг?
Правильное решение это dhcpv6 клиент с вашей стороны.
В нем все просто — говорим, чтобы запрашивал блок. Дальше по связке он сам рисует конфиг для radvd на основе полученных адресов.
При этом со стороны оператора это выглядит как dhcpv6 request с DHCPv6 DUID по которому в конечном счете мы и авторизуем абонента, наш маршрутизатор релеет ваш запрос на наш dhcpv6 сервер, сервер отвечает релею, релей (маршрутизатор) создает динамический IPv6 route, выданного абоненту блока, на IPv6 адрес (причем это будет как раз fe80 адрес) и направляет ответ уже роутеру абонента.
Это идеальная схема, которая работает у нас для 99% абонентов так или иначе захотевших IPv6.
Что касается конфига — тут все сильно индивидуально для каждого вендора абонентского роутера. Начиная с того, что у кого-то это isc-dhcp, а у кого-то wide-dhcp.
В нем все просто — говорим, чтобы запрашивал блок. Дальше по связке он сам рисует конфиг для radvd на основе полученных адресов.
При этом со стороны оператора это выглядит как dhcpv6 request с DHCPv6 DUID по которому в конечном счете мы и авторизуем абонента, наш маршрутизатор релеет ваш запрос на наш dhcpv6 сервер, сервер отвечает релею, релей (маршрутизатор) создает динамический IPv6 route, выданного абоненту блока, на IPv6 адрес (причем это будет как раз fe80 адрес) и направляет ответ уже роутеру абонента.
Это идеальная схема, которая работает у нас для 99% абонентов так или иначе захотевших IPv6.
Что касается конфига — тут все сильно индивидуально для каждого вендора абонентского роутера. Начиная с того, что у кого-то это isc-dhcp, а у кого-то wide-dhcp.
Таким образом, правильная схема выглядит так:
у меня накомпьютере маршрутизаторе link-local и запущен dhcpv6-client с указанным duid, который, я вроде бы отправлял, и, надеюсь, не посеял (не, не посеял, так и лежит в /var/lib/dhcpv6/dhcp6s_duid). В ответ мне присылают /64 сегмент, который маршрутизируется через link-local адрес автономного маршрутизатора.
При этом в момент выдачи ваш роутер запоминает «duid -> ipv6 сегмент ->link-local того, через кого маршрутизировать»? А ipv6-сегмент всё время один и тот же, или от разу к разу различается?
А дальше я с этой сеткой делаю уже что хочу, но уже целиком в своей сети? (То есть «наружу» вообще нет никакого link-local).
Последний вопрос: текущая прибитая гвоздями схема и старая схема вместе жить могут? (читать: могу начинать экспериментировать в dhcpv6/duid без поломки существующей схемы?).
у меня на
При этом в момент выдачи ваш роутер запоминает «duid -> ipv6 сегмент ->link-local того, через кого маршрутизировать»? А ipv6-сегмент всё время один и тот же, или от разу к разу различается?
А дальше я с этой сеткой делаю уже что хочу, но уже целиком в своей сети? (То есть «наружу» вообще нет никакого link-local).
Последний вопрос: текущая прибитая гвоздями схема и старая схема вместе жить могут? (читать: могу начинать экспериментировать в dhcpv6/duid без поломки существующей схемы?).
Роутер DUID не запоминает, я склонен считать, что он вообще не знает что это такое :)
DUID нужен только вашему dhcpv6 клиенту чтобы как-то идентифицироваться и нашему dhcpv6 серверу чтобы вас идентифицировать. Наш dhcpv6 сервер по вашему DUID понимает про кого именно идет речь и отправляет dhcpv6 reply в сторону нашего маршрутизатора. Наш маршрутизатор ловит ответ смотрит что там решили выдать абоненту и создает динамический раут, после чего отправляет ответ уже вашему dhcpv6 клиенту.
Так как на нашем dhcpv6 сервере четко указан выданный вам блок, то он будет всегда одним и тем же.
Полученную /64 сетку вы мучаете как вам угодно, но лишь в пределах вашего роутера, на который мы ее смаршрутизировали.
Прибитая гвоздями схема лишь от части будет работать с попытками поднять динамическую маршрутизацию, однако если реальный Ipv6 адрес с внешнего интерфейса вашего роутера принудительно не убирать, то ничего не сломается.
DUID нужен только вашему dhcpv6 клиенту чтобы как-то идентифицироваться и нашему dhcpv6 серверу чтобы вас идентифицировать. Наш dhcpv6 сервер по вашему DUID понимает про кого именно идет речь и отправляет dhcpv6 reply в сторону нашего маршрутизатора. Наш маршрутизатор ловит ответ смотрит что там решили выдать абоненту и создает динамический раут, после чего отправляет ответ уже вашему dhcpv6 клиенту.
Так как на нашем dhcpv6 сервере четко указан выданный вам блок, то он будет всегда одним и тем же.
Полученную /64 сетку вы мучаете как вам угодно, но лишь в пределах вашего роутера, на который мы ее смаршрутизировали.
Прибитая гвоздями схема лишь от части будет работать с попытками поднять динамическую маршрутизацию, однако если реальный Ipv6 адрес с внешнего интерфейса вашего роутера принудительно не убирать, то ничего не сломается.
Валера, давай про в6 на ближайшем биринге? А то с Ёбургом я в пролёте как обычно… ДР у жены как раз на те числа.
Пользователю выделяется один IPv6 адрес (для маршрутизатора или компьютера), плюс /64 сетка для всего остального
Хм, а неплохая практика. Есть провайдеры, которые выдают только одну /64, и больше ничего. И для того, чтобы ее смаршрутизировать, приходится делать либо IPv6-бридж (пропускать протокол 41 сразу провайдеру), либо костылять другими способами.
Но, в то же время, блин, почему не две /64? Или одну /60? RIPE советует, вообще, пользователям /56 давать.
Ну и, amarao, отличная статья! У меня был IPv6 настроен дома с 2010, наверное. Я вижу в нем одни только плюсы, даже через туннели.
Из всего этого на практике я видел использование только host/interface, link/local и global. В свете /64 и пусть никто не уйдёт обиженным, специально возиться с site-local адресами будет только параноик.
Не совсем. Иногда site-local бывают очень кстати. Например, вам нужно маршрутизировать какой-то трафик, но вы не хотите выдавать маршрутизатору IP из global-диапазона, а link-local использовать либо не получается, либо нежелательно.
Вот еще что.
Скажем, есть у вас 2 компьютера с поддержкой IPv6, скажем, один без монитора и с ssh-сервером, а второй — ноутбук. Нужно вам подключиться к первому компьютеру. Он получает IPv4 по DHCP, а IPv6 «не настроен». На ноутбуке вам влом поднимать DHCP-сервер.
Берете и пингуете ff02::1, как описано в статье. Получаем DUP от какого-то адреса. Ну а дальше просто:
Нам необходимо указать интерфейс, т.к. это link-local адрес. Указание интерфейса через знак процента работает почти везде.
Скажем, есть у вас 2 компьютера с поддержкой IPv6, скажем, один без монитора и с ssh-сервером, а второй — ноутбук. Нужно вам подключиться к первому компьютеру. Он получает IPv4 по DHCP, а IPv6 «не настроен». На ноутбуке вам влом поднимать DHCP-сервер.
Берете и пингуете ff02::1, как описано в статье. Получаем DUP от какого-то адреса. Ну а дальше просто:
ssh fe80::…%eth0Нам необходимо указать интерфейс, т.к. это link-local адрес. Указание интерфейса через знак процента работает почти везде.
А зачем вам две /64?
Скорее всего, на самом деле устроено так: дают один адрес A из /64 (а может быть из /126), в которой так же находится и машрутизатор провайдера, а на этот адрес маршрутизируют другую /64-сеть N, на манер ip route add N/64 via A. Предполагается, что на одной стороне маршрутизатора (который в сторону провайдера) будет настроен адрес A, а как там пользователь загрузит N/64 — настроит ли на компах, нарежет ли — это его дело.
Скорее всего, на самом деле устроено так: дают один адрес A из /64 (а может быть из /126), в которой так же находится и машрутизатор провайдера, а на этот адрес маршрутизируют другую /64-сеть N, на манер ip route add N/64 via A. Предполагается, что на одной стороне маршрутизатора (который в сторону провайдера) будет настроен адрес A, а как там пользователь загрузит N/64 — настроит ли на компах, нарежет ли — это его дело.
В идеальной схеме отдельно выдаваемый адрес роутеру вообще не нужен и является откровенно лишним. Со стороны провайдера так или иначе блок должен маршрутизироваться на fe80 адрес роутера.
Частные случаи, когда мы выдаем отдельный адрес роутеру, связаны с абонентскими роутерами, которые не в состоянии отправлять исходящие в мир запросы с адреса, назначенного внутреннему интерфейсу (т.е. с адреса выданного блока).
Частные случаи, когда мы выдаем отдельный адрес роутеру, связаны с абонентскими роутерами, которые не в состоянии отправлять исходящие в мир запросы с адреса, назначенного внутреннему интерфейсу (т.е. с адреса выданного блока).
RIPE советует, вообще, пользователям /56 давать.
Это все, безусловно, замечательно, однако основной идеей RIPE при выдаче такого блока было, что этот /56 будет поделен на внушительную пачку /64, каждая из которых будет жить своей жизнью из серии, одна /64 это своя сетка, вторая гостевая, третья еще как-нить, например, техническая и так далее; зачем под это отдали так много — лично я не понимаю.
По факту я вижу то, что абонентские роутеры едва ли в состоянии справиться с единичной /64 и меня терзают смутные сомнения, что им не поплохеет, если они получат вместо ожидаемых /64 вдруг /56.
Почему вы так думаете? От чего им поплохеет? Какая вообще роутеру с двумя дырками разница, какого размера сети там и там? Он только и делает, что перекладывает из правого порта в левый и наоборот :)
Ой ли…
Не поверите, но большинство абонентских роутеров вообще ни разу не ожидает увидеть в качестве полученного PD что-то отличное от /64. А причина очень проста — они едва ли научились вообще с IPv6 работать и в сорцах в большинстве случаев чуть ли не константами прописаны размерности сетей равные 64. Надо отдать должное, IPv6, как и годами раньше, это, увы, до сих пор всего лишь игрушка, а не стабильно работающий «инструмент».
Не поверите, но большинство абонентских роутеров вообще ни разу не ожидает увидеть в качестве полученного PD что-то отличное от /64. А причина очень проста — они едва ли научились вообще с IPv6 работать и в сорцах в большинстве случаев чуть ли не константами прописаны размерности сетей равные 64. Надо отдать должное, IPv6, как и годами раньше, это, увы, до сих пор всего лишь игрушка, а не стабильно работающий «инструмент».
Скажите, кто следит, сейчас адреса IPv6 выдают также бесконтрольно целыми пачками (а, дескать, всё равно их дохрена) или же учли ошибку четвёртой версии и на каждый выдаваемый адрес заставляют писать объяснительную, для чего он будет использоваться?
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
Адреса выдают контрольно и выдаёт из (в Европе) RIPE NCC. Основной задачей для IPv6 является агрегация, а не консолидация.
Примерные правила выделения: /64 на домашнего пользователя. /48 на организацию или PI, /32 стандартная аллокация для LIR'а, но при исчерпании может быть выделено более одной /32.
Если вы это переведёте из логарифмической формы в обычную, то увидите, что LIR'у выдают для дальнейшей раздачи (из /32 кусочками по /48) всего навсего по 65 тысяч сетей. А каждая /32 — это 1/4миллиарда от адресного пространства интернета (я не считаю спецдиапазоны сейчас).
Основной идеей сейчас идёт такое построение сетей, чтобы каждому самостоятельному объекту (организации, филиалу и т.д.) соответствовала одна-единственная сетка какого-то размера, а не обширная пачка маленьких сетей. Это и называется агрегация.
В IPv4 же действует принцип консолидации — то есть «лучше побольше мелких сетей, зато меньшее количество неиспользуемых адресов» — и это сильно осложняет жизнь.
Примерные правила выделения: /64 на домашнего пользователя. /48 на организацию или PI, /32 стандартная аллокация для LIR'а, но при исчерпании может быть выделено более одной /32.
Если вы это переведёте из логарифмической формы в обычную, то увидите, что LIR'у выдают для дальнейшей раздачи (из /32 кусочками по /48) всего навсего по 65 тысяч сетей. А каждая /32 — это 1/4миллиарда от адресного пространства интернета (я не считаю спецдиапазоны сейчас).
Основной идеей сейчас идёт такое построение сетей, чтобы каждому самостоятельному объекту (организации, филиалу и т.д.) соответствовала одна-единственная сетка какого-то размера, а не обширная пачка маленьких сетей. Это и называется агрегация.
В IPv4 же действует принцип консолидации — то есть «лучше побольше мелких сетей, зато меньшее количество неиспользуемых адресов» — и это сильно осложняет жизнь.
Надо еще заметить, что RIPE выдает /32 не подряд, а с приличными «пробелами» позволяя позже лишь по запросу оператора именно расширить выданный блок аж до /29. Причем в последних письмах они делают упор, что сделают это с удовольствием, без лишней переписки, по первому же запросу оператора/LIRа.
Ого, эту часть я прослушал. В этом случае тренд точно на максимальную агрегацию.
В целом, нынче IPv6 FullView это чуть меньше 15К префиксов (против 477К в ipv4). По моим наблюдениям, рост крайне слабый.
Надо отдать должное, что варианты когда один и тот же оператор анонсирует более одного v6 префикса сейчас практически не наблюдаются, что позволяет держать рост таблицы минимальным.
Надо отдать должное, что варианты когда один и тот же оператор анонсирует более одного v6 префикса сейчас практически не наблюдаются, что позволяет держать рост таблицы минимальным.
Опасносте, в
Кстати, в версии 0.7.45 появилось экспериментальное решение для DAD, потестируйте, пожалуйста
interfaces комментарии могут быть только в начале строки!Кстати, в версии 0.7.45 появилось экспериментальное решение для DAD, потестируйте, пожалуйста
НЛО прилетело и опубликовало эту надпись здесь
auto — это «поднимать интерфейс при старте», а allow-hotplug — это переконфигурировать интерфейс при linkup/down или появлении интерфейса.
auto без hotplug — отключили/подключили — нет сети.
hotplug без auto — загрузились, сети нет, воткнули/вынули кабель, сеть появилась.
auto без hotplug — отключили/подключили — нет сети.
hotplug без auto — загрузились, сети нет, воткнули/вынули кабель, сеть появилась.
Коммент в конфиге писался только в статье, да.
А что за решение для DAD? Не видел, не читал.
А что за решение для DAD? Не видел, не читал.
возможно я задам тупой вопрос =)
а если твой провайдер выдаёт IPv6, но нет никакого желания городить дома самодельный маршрутизатор, есть ли сейчас доступная возможность взять для данной цели какую-нибудь недорогую консьюмерскую железку? скажем так, обычный вайфай-роутер, который помимо всего прочего может работать с IPv6. или таких ещё нет?
а если твой провайдер выдаёт IPv6, но нет никакого желания городить дома самодельный маршрутизатор, есть ли сейчас доступная возможность взять для данной цели какую-нибудь недорогую консьюмерскую железку? скажем так, обычный вайфай-роутер, который помимо всего прочего может работать с IPv6. или таких ещё нет?
Многие железки поддерживают ipv6 passthrough, поэтому даже ничего настраивать не придется.
Есть конечно, довольно много. Работает и на родных прошивках, и на всяких WRT. Уже как с год на моём Asus RT-N56U функционирует шестёрка через брокера. Домашние Android, iOS, MacOS, Win7 и даже NAS от Synology (!) вкушают блага цивилизации.
Идеальная статья. Вспомнился старый и уютный хабр. Эх.
А вообще, не могли бы вы обьяснить что происходит дальше?
Вот у меня есть конечный адрес, я трафик передал на машрутизатор(термин шлюз корректен?), а дальше?
Получается в локальной сети он однозначно определяет адрес источника по мак адресу ethernet frame, или там есть отдельное поле «настоящий источник» и «локальный источник»?
И получается что для обратной связи все машрутизаторы хранят таблицы сессий?
Вообщем что бы я не строил догадки, расскажите, что происходит с адресами в пакетах. Небольшая каша в голове.
И еще раз спасибо за статью, мне очень понравился ваш стиль изложения, я получил ощущаемое(а не только произностимое: в стиле пишу LOL, а сижу с каменным лицом) удовольствие. Заумь RFC переведена по сути, для конкретной аудитории на простой язык.
А вообще, не могли бы вы обьяснить что происходит дальше?
Вот у меня есть конечный адрес, я трафик передал на машрутизатор(термин шлюз корректен?), а дальше?
Получается в локальной сети он однозначно определяет адрес источника по мак адресу ethernet frame, или там есть отдельное поле «настоящий источник» и «локальный источник»?
И получается что для обратной связи все машрутизаторы хранят таблицы сессий?
Вообщем что бы я не строил догадки, расскажите, что происходит с адресами в пакетах. Небольшая каша в голове.
И еще раз спасибо за статью, мне очень понравился ваш стиль изложения, я получил ощущаемое(а не только произностимое: в стиле пишу LOL, а сижу с каменным лицом) удовольствие. Заумь RFC переведена по сути, для конкретной аудитории на простой язык.
В разделе про «белый адрес для каждого»:
Неужели маршрутизация для ipv6 также висит на переменной ipv4? Или тут опечатка?
Так как fb97 уже является адресом моего компьютера, настройка машрутизации плёвое дело:
sysctl net.ipv4.conf.all.forwarding=1
Неужели маршрутизация для ipv6 также висит на переменной ipv4? Или тут опечатка?
Не, ну как вот объяснить, что провайдер в Питере даёт ipv6 домашним пользователям правильнее, чем Hetzner в германии для серверов?
RIPE советует, вообще, пользователям /56 давать
думаю когда нибудь так и может случиться,
просто сейчас ещё не отпускает страх «а вдруг закончатся» — обычная инерция мышления. Хотя может им так удобнее.
Отличная статья, спасибо.
По поводу маршрутизаторов — а как определяется, какой именно нужно использовать?
Ну т.е. делаем мультикаст, получаем список — а дальше? И что помешает в таком случае легко и свободно провернуть MitM, прикинувшись маршрутизатором?
По поводу маршрутизаторов — а как определяется, какой именно нужно использовать?
Ну т.е. делаем мультикаст, получаем список — а дальше? И что помешает в таком случае легко и свободно провернуть MitM, прикинувшись маршрутизатором?
Увы ничего не мешает и такие ситуации встречаются относительно часто. Бороться можно лишь в случае когда на доступе стоит коммутатор умеющий фильтровать неугодные (заведомо нелегитимные) RA.
Ну так и сейчас уважающие себя провайдеры разрешают DHCP offer приходить только из определённого порта. Я могу поднять DHCP-сервер в сторону провайдера, но никому он не ответит.
Потому что заблочить входящие с абонентского порта IPv4 пакеты с source портом 67 всяко проще, чем разбирать IPv6 RA в поисках что ж там абонентский роутер решил наанонсить «в мир», да еще и мультикастом в придачу.
Чем отличается блокирование входящего с порта клиента ICMPv6 type 134 от блокирования входящего с порта клиента UDP source port 67?
По-моему вы вполне сами себе на вопрос и ответили, разве нет?
Если нет, то в случае IPv4 это банальный extended ACL, а во втором это уже залезание внутрь пакета, что умеют далеко не все коммутаторы.
Если нет, то в случае IPv4 это банальный extended ACL, а во втором это уже залезание внутрь пакета, что умеют далеко не все коммутаторы.
Нужно ещё помнить, что если взялся настраивать IPv6, то настраивай до конца. Я в своё время баловался с настройками, пробовал запустить 6to4, но по какой-то причине бросил. IPv6 в локалке успешно работал. Но однажды наткнулся на непонятные проблемы с сетью. Как оказалось, раз компьютер видит, что имеет IPv6 адрес, то пытается иногда (когда есть AAAA запись) подключиться по IPv6. Естественно, обламывается.
Я как раз на днях настроил 6to4 дома. Поднял приоритет маршрута, и теперь некоторые сайты не открываются :) Думаю, придется отключать взад, если не разберусь.
А ещё несколько лет назад, когда роутером-с-NAT у меня стоял компьютер с FreeBSD, там ядро уходило в kernel panic, если включить rtadvd. Происходило это не сразу, и я так не смог узнать, где именно там что падало.
А ещё несколько лет назад, когда роутером-с-NAT у меня стоял компьютер с FreeBSD, там ядро уходило в kernel panic, если включить rtadvd. Происходило это не сразу, и я так не смог узнать, где именно там что падало.
А как поступить если, скажем, я не хочу, чтобы мой адрес маршрутизировался в интернете?
В ipv4 были немаршрутизируемые сети типа 10.0.0.0/8, а в ipv6 сказано что для этой цели есть site-local адреса, но rfc 3879 от 2004 года говорит, что они deprecated, и при этом не говорит прямо что с этим делать.
В ipv4 были немаршрутизируемые сети типа 10.0.0.0/8, а в ipv6 сказано что для этой цели есть site-local адреса, но rfc 3879 от 2004 года говорит, что они deprecated, и при этом не говорит прямо что с этим делать.
Если ваш адрес не маршрутизируется в интернете, то у вас не будет и доступа к интернету, поэтому на такой вопрос ответ: не подключаться к интернету вообще :)
А вообще, вместо site-local нужно использовать тот блок адресов, который вам выдал провайдер.
А вообще, вместо site-local нужно использовать тот блок адресов, который вам выдал провайдер.
Вики говорит:
Unique-Local
RFC 4193, соответствуют внутренним IP адресам, которыми в версии IPv4 являлись 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16. Начинаются с цифр FC00 и FD00.
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 они не нужны)
Это так называемые 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 они не нужны)
Если уж на чужом языке, то грамотно — nobody careS. Хотя чаще говорят «Who cares?».
Чего-то не хватает, чтобы можно было сказать «получилось красиво».
Prefix Delegation — это такая магия, которая позволяет получать от провайдера первую половину адреса внутренней (домашней) сети, а вторую половину назначать самостоятельно. Т.е. в терминах IOS (копипаста из доки):
Никакой статики никогда и нигде! Только PD + EUI-64 (тоже можно)!
Stateless DHCP — это тот же DHCP, хотя покороче. Данные из RA могут учитываться, а могут и не учитываться. Тут разные системы ведут себя по-разному.
Сразу видно серверного админа :)
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 был этакой технологией «не от мира сего». Есть, но редко используется в строго ограниченных случаях.
Сразу видно серверного админа :)
Stateless DHCP — это тот же DHCP, хотя покороче. Данные из RA могут учитываться, а могут и не учитываться. Тут разные системы ведут себя по-разному.
По хорошему, они должны себя вести ровно так как установлены биты/флаги в RA сообщениях.
А именно managed-config-flag и other-config-flag.
Один отвечает за то, что адрес таки нужно получать не из prefix announcement, иными слова не stateless, а statefull, а другой, что еще пачку параметров можно/нужно получить по dhcp6, будь то DNS сервера, как пример.
В пакетах ICMPv6 типа RA присутствует и DNS-сервер тоже. Так что в IPv6-сетях DHCP не особо и нужен.
Поделитесь секретом, кто (и на основании чего) принимает решение о выдаче абоненту блока 2002:b00e:d4f2:1::/64, как это описано в вашем случае.
Мы с вами друг друга пока не поняли.
Кто принял решение выдать именно этот блок, кто сгенерировал именно такой пакет, дамп которого вы показали?
Кто принял решение выдать именно этот блок, кто сгенерировал именно такой пакет, дамп которого вы показали?
Не я показал конечно но судя по тому что в качестве DNS используется адрес начинающийся с fe80 т.е. link-local этот пакет отправил роутер в локальной сети.
Не я показал конечно
Пардон, я все еще пытаюсь привыкнуть к возможности писать на хабре, а не только читать :)
Основная идея в том, что операторский маршрутизатор при всем желании не должен являться DNS сервером, это, как минимум не его задача. То, что видно в дампе пакета существует только в связке абонентский роутер -> абонентский компьютер. В связке абонентский роутер -> операторский роутер такая схема не взлетит.
Таким образом, мы возвращаемся к моему, теперь уже дополненному, утверждению, что без DHCPv6 в операторской сети, мы никуда не взлетим.
P.S. Я, похоже, догадываюсь в чем возникает общее противоречие между моими постами и постами других участников обсуждения — все рассматривают IPv6 со стороны абонента, я же, напротив, со стороны оператора.
А что-то мешает вписать в то поле маршрутизируемый адрес? И пусть DNS сервер стоит где угодно.
Никто, это всецело на совести тех, кто пишет софт для абонентских роутеров.
Что мешает операторскому роутеру отправить аналогичный пакет с адресом операторского DNS сервера?
Как ни банально, но он не умеет так делать.
Надо понимать, что оператору УДОБНО, когда абонент получает все по DHCPv6.
P.S. И не надо рассказывать, что оператор должен делать так как удобно абоненту — это утопия, такого нет, не было и не будет.
P.S.2 Схема с DHCPv6 работает практически идеально, зачем выдумывать разные странные схемы для достижения ТОГО же результата?
Надо понимать, что оператору УДОБНО, когда абонент получает все по DHCPv6.
P.S. И не надо рассказывать, что оператор должен делать так как удобно абоненту — это утопия, такого нет, не было и не будет.
P.S.2 Схема с DHCPv6 работает практически идеально, зачем выдумывать разные странные схемы для достижения ТОГО же результата?
Это мой домашний роутер. Если точнее, ASUS RT-N16 с дефолтной прошивкой (пусть и обновленной до последней версии). Купил недавно, так что пока не буду торопиться с выводами, хороший или плохой этот роутер :)
Прошивка там на основе линукса, крутится демон radvd версии 1.9.3.
Прошивка там на основе линукса, крутится демон radvd версии 1.9.3.
В пакетах ICMPv6 типа RA присутствует и DNS-сервер тоже.
Многие имплементации роутеров/клиентов не умеют раздавать/принимать DNS сервера в RA. RFC буквально на днях вышел.
По хорошему, они должны себя вести ровно так как установлены биты/флаги в RA сообщениях.
Не совсем. Никто там ничего не обязан.
Так кто ж против, получил себе «левый» ipv6 адрес из shared блока типа temporarily ipv6 address в винде — сиди в локалке, в мир с него не пустим. Учитывая, что он при каждом чихе меняется на новый, возникает слишком много головной боли ради всяких сормов и прочих любителей поприсылать запросы, их постоянно фиксировать и сохранять.
Вы поймите одну простую истину — я исхожу не из того, как это описано в RFC и продумано умными и не очень людьми, а из наших, в частности Российских, реалий, как бы это ни было грустно.
Вы поймите одну простую истину — я исхожу не из того, как это описано в RFC и продумано умными и не очень людьми, а из наших, в частности Российских, реалий, как бы это ни было грустно.
Вы, вероятно, промахнулись комментарием при ответе?
Да нет, не промахнулся.
То, что они не обязаны, вовсе не означает, что такая схема взлетит в реальной сети.
И, кстати говоря, в реальной сети взлетает ровно так как выставлены флаги.
P.S. Выше я описал, что будет если игнорировать флаги.
То, что они не обязаны, вовсе не означает, что такая схема взлетит в реальной сети.
И, кстати говоря, в реальной сети взлетает ровно так как выставлены флаги.
P.S. Выше я описал, что будет если игнорировать флаги.
в реальной сети взлетает ровно так как выставлены флаги.
Нет. Читал я один материал — поведение WinXP, Win7, Linux и MacOS в плане принимания во внимание значений флагов радикально отличается. Вроде семерка вела себя лучше всех (ближе к RFC). Макось вроде полностью игнорировала их значения.
Причем тут «получил себе «левый» ipv6 адрес из shared блока типа temporarily ipv6 address в винде» и «Российских, реалий» вообще не понял, просьба расшифровать мысль.
Рассматриваем ситуацию, когда абонентский компьютер подключен напрямую к сети оператора без абонентского роутера.
Если есть абонентский роутер, то все выше и нижеописанное не имеет ровно никакого значения.
Так вот, если абонентский компьютер игнорирует флаги обозначающие, что настройки нужно получать по DHCPv6, то он получит свой адрес по SLAAC из prefix-advertisement блока оператора, при этом винда при включенном (by default) temporarily ipv6 address получит еще один (второй) ipv6 адрес и все соединения будет выполнять от его «имени».
Так вот, мы получим абонента, выходящего в сеть интернет каждый раз с нового в6 адреса. Мы будем вынуждены каждый раз запоминать с какого адреса он вышел (т.е. идентифицировать его с полученным временным в6 адресом) чтобы в случае получения запроса от органов «какой абонент выходил в сеть Интернет такого-то числа с такого-то в6 адреса» мы могли ответить не «а пес его знает», а выдать конкретный ответ.
Если есть абонентский роутер, то все выше и нижеописанное не имеет ровно никакого значения.
Так вот, если абонентский компьютер игнорирует флаги обозначающие, что настройки нужно получать по DHCPv6, то он получит свой адрес по SLAAC из prefix-advertisement блока оператора, при этом винда при включенном (by default) temporarily ipv6 address получит еще один (второй) ipv6 адрес и все соединения будет выполнять от его «имени».
Так вот, мы получим абонента, выходящего в сеть интернет каждый раз с нового в6 адреса. Мы будем вынуждены каждый раз запоминать с какого адреса он вышел (т.е. идентифицировать его с полученным временным в6 адресом) чтобы в случае получения запроса от органов «какой абонент выходил в сеть Интернет такого-то числа с такого-то в6 адреса» мы могли ответить не «а пес его знает», а выдать конкретный ответ.
Я, кстати, нашел ту табличку.
Вариант m=1 o=1 вроде на всех ОС означает получение адресации и настроек по DHCP, но вот с остальными комбинациями полный бардак.
На месте нищеброда-провайдера я бы оставил фильтрацию по макам на порту, и просто писал бы в лог всё связанное с RA на первом хопе. Не стопроцентная панацея, от спуферов, которым не интересен обратный трафик, не защитит.
Скрытый текст
Вариант m=1 o=1 вроде на всех ОС означает получение адресации и настроек по DHCP, но вот с остальными комбинациями полный бардак.
Мы будем вынуждены каждый раз запоминать с какого адреса он вышел
На месте нищеброда-провайдера я бы оставил фильтрацию по макам на порту, и просто писал бы в лог всё связанное с RA на первом хопе. Не стопроцентная панацея, от спуферов, которым не интересен обратный трафик, не защитит.
Не табличка, а сплошная жуть. Было бы полезно еще указывать в ней последний примененный патч к ОС, ибо там тоже встречаются изменения.
Что касается провайдера-нищеброда, то писать в логи все связанное с RA не столь простая задача, как это выглядит если эту фразу написать на хабре, увы. Вы думаете на доступе у всех, тем более нищебродов-провайдеров, стоят коммутаторы которые знают что такое IPv6? Так вы глубочайшим образом заблуждаетесь.
Если речь идет о фиксировании всех IPv6 соседей на ближайшем IPv6 роутере оператора, то да, технически возможно, но это геморрой. Проще отказать абоненту в такой шалости, не выпустив его в «мир».
Что касается провайдера-нищеброда, то писать в логи все связанное с RA не столь простая задача, как это выглядит если эту фразу написать на хабре, увы. Вы думаете на доступе у всех, тем более нищебродов-провайдеров, стоят коммутаторы которые знают что такое IPv6? Так вы глубочайшим образом заблуждаетесь.
Если речь идет о фиксировании всех IPv6 соседей на ближайшем IPv6 роутере оператора, то да, технически возможно, но это геморрой. Проще отказать абоненту в такой шалости, не выпустив его в «мир».
Вы думаете на доступе у всех, тем более нищебродов-провайдеров, стоят коммутаторы которые знают что такое IPv6?
Я жк сказал — «на первом хопе». Под хопами обычно понимают роутеры.
Задачей свитча будет пропускать пакеты только с правильным smac. Вдаваться в подробности L3 не надо.
то да, технически возможно, но это геморрой.
Больший, чем протоколировать базу аренд DHCP?
Парсер этих данных пишется минут за 5, включая перекуры.
Спасибо, почитаю (в этом и прелесть раннего освоения, что можно сколько угодно тупить, не знать и т.д. — и всем пофигу).
Насчёт мультикаста и серверных админов — каким бы админ не был, но нужно признать, что большАя часть IPv4 работала без использования мультикаста. В IPv6 без мультикаста пакет до шлюза не дойдёт.
Насчёт мультикаста и серверных админов — каким бы админ не был, но нужно признать, что большАя часть IPv4 работала без использования мультикаста. В IPv6 без мультикаста пакет до шлюза не дойдёт.
В IPv6 без мультикаста пакет до шлюза не дойдёт.
Оспорю: можно статически прописать маршруты и соседей (ip neigh add ..) и дойдёт. Проверял, когда из-за глюков драйвера wl broadcom у меня на буке не работали те самые мультикасты — но ipv6 на буке «руками» завести было можно, хотя и неудобно.
Если смотреть на вещи реалистично: единственный случай, когда возможны проблемы с L2 мультикастом (напомню — это та штука, которую по дефолту даже настраивать не требуется, она либо сходу работает нормально, требуя подкручивания лишь из соображений безопасности, либо тоже работает, но как броадкаст, если свитчи — говно) — это L2 каналы поверх провайдеров.
Ну и да, как подметили выше — IPv4 технически может жить без броадкастов со статическими arp записями, а IPv6 без мультикаста с аналогичными извращениями.
И еще один момент. Сейчас нельзя игнорировать существование IPv6 даже в v4-only среде. Один вражеский ra способен обойти все ориентированные на IPv4 защиты на коммутаторах и натворить бед. Как минимум — необходимо отключить на всех хостах IPv6.
Ну и да, как подметили выше — IPv4 технически может жить без броадкастов со статическими arp записями, а IPv6 без мультикаста с аналогичными извращениями.
И еще один момент. Сейчас нельзя игнорировать существование IPv6 даже в v4-only среде. Один вражеский ra способен обойти все ориентированные на IPv4 защиты на коммутаторах и натворить бед. Как минимум — необходимо отключить на всех хостах IPv6.
И еще один момент. Сейчас нельзя игнорировать существование IPv6 даже в v4-only среде. Один вражеский ra способен обойти все ориентированные на IPv4 защиты на коммутаторах и натворить бед. Как минимум — необходимо отключить на всех хостах IPv6.Б
Был случай, коллега настраивал какой-то конторе интернет. Ну, проработало неделю, и на некоторых компах работать перестало. Кинулись — что, где. А главное, смотреть ездили люди, которые не в курсе, что бывает ipv6 и так далее. Ну реально, некоторые адреса не работают. В общем, спустя пару дней разобрались.
Выяснилось, что на половине компов там XP, на другой — семёрка. Какой-то чудный человек для чего-то вставил в семёрку 3g-модем и настроил раздачу инета, а потом модем выдрал. Не знаю, зачем и как он настроил ipv6, видимо, teredo или что-то в этом духе. Почему она продолжала раздавать ra без модема — я не знаю, но продолжала. Все семёрки понимали это как «о, ipv6 роутер, айда через него» и ничерта на них не работало.
Самое обидное, что в конторе нашлись «яндексовские специалисты», которые думают что что-то понимают, и крайне сложно оказалось объяснить им причину проблемы (в том числе что это не была недоработка и не была «закладка», а были слишком большие права у пользователя того компа и слишком шаловливые руки, и что застраховаться от этого они не смогут, не имея админа и достаточно интеллектуального оборудования).
эх, загорелся идей, решил узнать, кто в москве из провайдеров дает ipv6:
version6.ru/isp
что-то совсем беда
version6.ru/isp
что-то совсем беда
Попробуйте 6to4
спасибо, интересно. правда провайдер у меня настолько суров, что я сижу за натом и для начала надо статический адрес арендовать
Попробуйте вариант с туннелем до he, статический паблик при таком раскладе не нужен.
спасибо, буду пробовать. но, как я понимаю, это все костыли все таки
Отнюдь, ряд ОПЕРАТОРОВ (надо понимать, что речь про далекие регионы необъятной), аплинки которых не готовы к поднятию IPv6 BGP сессий, поступают именно так.
это интересно. вообще изначально у меня цель было попрактиваться в настройке и получить опыт примерно, как у топик стартера. попробовать все это дело на каком-нибудь микротике/пс хоум роутере поднять и раздать на домашние устройства
с туннелями это вообще осуществимо или можно сразу забить?
с туннелями это вообще осуществимо или можно сразу забить?
Ну я с тоннелем 6to4 и роутером Keenetic Giga поднял.
Я не пробовал и более того не уверен, что схема с HE сработает с home роутером/микротиком.
Мне повезло больше — я пнул аплинков и они мне выдали IPv6 BGP связность в реальные сроки.
В остальном, повторюсь, на туннелях живут операторы, которым интересен IPv6. Уж не знаю насколько они довольны явно более высоким задержкам, но при отсутствии альтернатив…
Мне повезло больше — я пнул аплинков и они мне выдали IPv6 BGP связность в реальные сроки.
В остальном, повторюсь, на туннелях живут операторы, которым интересен IPv6. Уж не знаю насколько они довольны явно более высоким задержкам, но при отсутствии альтернатив…
Я как-то наоборот смотрю на bgp.he.net — все аплинки у нас всё давно умеют, равно как и те провайдеры, что дают интернет детямнаселению. Вон, воронежский филиал Ростелекома ещё в 2008 году впервые попробовал, когда он ещё не был филиалом Ростелекома, ни Центртелекома, а был сам себе ВоронежСвязьИнформ :)
На мой вопрос тогда «а когда вы нам выдадите ipv6», они сказали: «когда циско напишут поддержку». И на этом всё.
На мой вопрос тогда «а когда вы нам выдадите ipv6», они сказали: «когда циско напишут поддержку». И на этом всё.
Поднимал и на pc и на микротике, все реализуемо и не сложно (stateless, то что описывает автор статьи). Проблемы возникли с попыткой поднять stateful конфигурацию (т.е. dhcpv6) по микротиковским мануалам, вообщем так и не взлетело. Надо снова попробовать, вроде на микротик уже 6ая версия ОС вышла.
Оно за натом не работает.
Огромное спасибо за статью. Ваши статьи аналогично ализаровским вычисляемы, не глядя на автора. Но в отличие от ализаровских по качеству написания и полезности.
Не встречался ли кто с проблемой, что на стоковом андроиде 4.2.2 на самсунге (galaxy tab 3 10.1 рутованный) не получается ipv6 от radvd на роутере? Все получают, в том числе андроид 4.2.2 от cyanogen'а в телефоне, а планшет не получает. Через openvpn получает IPv6-адрес и все работает.
Не встречался ли кто с проблемой, что на стоковом андроиде 4.2.2 на самсунге (galaxy tab 3 10.1 рутованный) не получается ipv6 от radvd на роутере? Все получают, в том числе андроид 4.2.2 от cyanogen'а в телефоне, а планшет не получает. Через openvpn получает IPv6-адрес и все работает.
Говорят, что ipv6 собирается поддерживать IPSEC. Это уже работает?
«С этого момента мы точно знаем, что адрес в сети. „
в целом, очень основательно получилось. спасибо.
в целом, очень основательно получилось. спасибо.
А можно как-нибудь аналогичным образом использовать блок адресов, который выдаётся облачным серверам в selectel? Насколько я понимаю, там нет разделения на адрес роутера и маршрутизируемую через него сеть, а серверу выдаётся сразу /112 блок адресов.
НЛО прилетело и опубликовало эту надпись здесь
Блин, буквально вчера прочитал с интересом эту статью, а сегодня на конференции по IPv6 от MSK-IX выступал Стрельцов Валерий о том, как они внедряли в компании Tiera IPv6 для пользователей. С какими сложностями и тонкостями пришлось столкнуться. Было весьма любопытно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практика IPv6 — домашняя сеть