IPv6 — вы делаете это неправильно



    Вокруг IPv6 много заблуждений и мифов. Часто хостинг-провайдеры неправильно понимают, как его использовать и размышляют устаревшими подходами из мира IPv4. Например, имея октиллионы IPv6-адресов, хостер продает адреса клиентам поштучно вместо того, чтобы выделять полноценную сеть /64, как следует из рекомендаций.

    Бывает, что хостеры назначают разным клиентам IPv6-адреса внутри одной сети /64. При этом крупные сервисы, вроде Google, воспринимают все адреса внутри диапазона /64 как одного клиента. В результате клиенты могут страдать из-за действий соседа по диапазону.

    Доступность IPv6-адресов позволяет назначать внутренним ресурсам, например, контейнерам или VPN-клиентам полноценные внешние адреса. Для этого хостер должен выдать клиенту отдельную маршрутизируемую сеть. К сожалению, почти никто не умеет это делать.

    В статье мы разберем основные ошибки использования IPv6 провайдерами.

    Завязка сюжета: RFC 3177


    В 2001 году в рекомендациях по распределению адресов было рекомендовано (простите за тавтологию, это важно) выделять:

    • /48 в общем случае
    • /64 если за ним одна и только одна подсеть
    • /128 если одно и только одно устройство

    Одиозный документ RFC 2119, в котором регламентируется применение различных уровней обязательности для выполнения указаний определяет «рекомендуется» следующим образом:
    Слова «Должны» или «Рекомендуется» означают, что могут существовать обоснованные причины в определенных обстоятельствах не поступать указанным образом, однако выбор другой линии поведения должен быть взвешенным решением, принятым с полным пониманием последствий.
    Возможно, полного понимания последствий на тот момент ни у кого не было, возможно «определённые обстоятельства» так и не были определены, но, так или иначе, рекомендациям все следовали.

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

    Осознание проблемы: RFC 6177


    Новая политика назначения адресов явно говорит, что /48 — всего лишь пожелание, а не требование. Никаких указаний на конкретные цифры не даётся, однако указывается, что /64 или короче работает в нормальных условиях.

    Основная логика при рекомендации размера выдачи блока /48 конечному потребителю преследовала три цели.

    Во-первых, назначенное пространство адресов должно быть достаточным для целей потребителя и легко расширяемым, без приседаний со штангой. Да, именно так и написано, только в английском варианте — jump through hoops. Одна из важных причин перехода на IPv6 — это изменение существующего размера назначения от «один адрес» до «множество подсетей».

    Во-вторых, смена провайдера должна была проходить с минимумом проблем. Если при переезде в новое адресное пространство можно сохранить старую схему адресов подсетей, то это избавит от большого количества работы

    В-третьих, выделение блока /48 должно было покрывать увеличение в потребностях адресного пространства развивающегося потребителя.

    Хотя все эти условия выполнялись, стало очевидным что рекомендация /48, мягко говоря, избыточна.

    Закрепление /64 как единицы выдачи


    Помимо порядка распределения были и другие моменты. Оказалось, что многие особенности IPv6 не работают, если префикс сети не /64. А именно не работают:

    • Neighbor Discovery (ND)
    • Secure Neighborship Discovery (SEND)
    • некоторые части Mobile IPv6
    • Site Multihoming by IPv6 Intermediation
    • много разных мелочей

    Дополнительным фактором стало то, что многие проектируемые технологии опирались именно на такой префикс сети.

    Не только угроза сломать новообретенный стандарт стала причиной написания новых рекомендаций. Весьма популярными также были два мнения сомнительной обоснованности.
    Первое — многие устройства реализуют IPv6-маршрутизацию программно, с костылями и велосипедами, а потому не готовы к полному переходу на неё. Возможное увеличение задержки за счёт этого может увеличиться в разы, если не на порядок. Дефолтное определение подсети /64 должно было сильно уменьшить эти задержки.

    Второе — переход на новый стандарт всегда является болью для техподдержки и системных администраторов. Единый префикс/64 должен был уменьшить эту боль до приемлемого значения.

    Положение дел на фронтах


    Как уже происходило ранее в далёком 2001, рекомендацию /64 многие крупные игроки интернета воспринимают как стандарт. С одной стороны это хорошо, с другой не очень.

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

    Зачастую провайдеры не заморачиваются такими вещами, как изучение общепринятых практик. Адреса могут выдаваться по любому принципу, да хоть бы даже по гороскопу.

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

    В случае если несколько человек из этого блока начнут искать котиков одновременно, Google может решить, что это ботнет шлёт запросы для поискового скама или каких-то иных не очень хороших дел. С его точки зрения это всё один пользователь. Закономерный итог — всё усложняющаяся капча.

    Это, как вы понимаете, самый безобидный вариант ответа на гипотетический скам.
    Обратная ситуация — выдача одному пользователю адресов из разных блоков. Если пользователи этих блоков попадут в чей-то блэклист, то и адреса честного пользователя попадут вместе с ними. Особо интересный сюжет: часть ваших адресов забанила одна рекламная сеть, часть забанила другая.

    Помимо этого, возможны и другие неприятные неожиданности. Например вы получили в своё пользование блок /64, но это динамический блок, как динамический адрес — сегодня 2001:DA8:1D01:FA13::/64, завтра 2001:DA8:1D01:FС15::/64. Новые приключения каждый день!
    Есть немалый шанс встретить разнообразные комбинации этих проблем и другие причудливо изогнутые грабли в довесок.

    Выдаем IPv6 со своего сервера


    Если у нас есть квинтиллионы IP-адресов, то почему бы не выдавать реальные IP-адреса, например, VPN-клиентам так, чтобы они ходили в интернет без NAT и могли принимать входящие подключения из мира. Звучит прекрасно, но на практике сделать это не так просто. Для этого потребуется отдельная IPv6 сеть, маршрутизируемая через IP-адрес, назначенный на интерфейс сервера.

    Допустим, на сервер назначен адрес 2a01:baba::c0fee:dead/64, тогда для VPN-клиентов потребуется отдельная сеть вроде 2a01:baba:fafa:0f0f::/64, маршрутизируемая через адрес 2a01:baba::c0fee:dead/64.

    К сожалению, крайне мало хостинг-провайдеров имеют инструменты чтобы выдавать клиентам такие сети, из-за чего приходится использовать костыли вроде ND Proxy.

    Заключение


    Читать рекомендации IETF не самое интересное занятие, однако крайне полезное. Заполнять им долгие зимние вечера явно не стоит, но и пренебрегать чтением важных для вас разделов также нежелательно.

    Выбирая себе провайдера, убедитесь, что он разделяет эту точку зрения.

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



    Подписывайтесь на нашего разработчика в Instagram


    Хостинг-технологии
    Хостинг серверов для разработки

    Комментарии 20

      +8
      Например, имея октиллионы IPv6-адресов, хостер продает адреса клиентам поштучно вместо того, чтобы выделять полноценную сеть /64, как следует из рекомендаций.
      И это касается в том числе и вашей компании, предоставляющей хоть и до сотни, но всё равно /128.
        0
        Предоставляют поштучно, а потом начинаются проблемы как сами же писали в разделе «Положение дел на фронтах».
        +9
        «Да, мы предоставляем возможность использовать IPv6. Стоимость услуги — 1 руб. в месяц за 1 IPv6 адрес.»
        Самоирония — признак сильных.
          +2
          При этом у большинства других хостеров IPv6 идут бесплатно.
          0
          Надо было настаивать на выдаче /48, как аналог одного IPv4. Этих сетей ведь десятки триллионов, даже если давать их каждому мобильнику и VDS, в ближайшие 100 лет они бы не кончились. Жалобы были от тех, кто на халяву взял /32 не думая и вдруг оказалось, что для операторских целей этого крайне мало.
          IPv6 создан вовсе не для того, чтобы антиспаму жилось легче, я бы даже сказал, что у них противоположные цели. Google вероятно будет относится ко всей /64, как к одному адресу, всем авторизованным доступ, всем анонимам капчу. Конечно они могут навсегда запоминать анонима ввёдшего капчу и не совершавшего злодеяний, но зачем, если можно мягко навязать гуглоаккаунт?
          Динамические адреса были первой реакцией на дефицит адресов, для IPv6 оно не нужно. Если биллинг по другому не умеет, лечите биллинг.
          Если выдавать каждой VDS по /48, то не будет никаких проблем с настройкой маршрутизации контейнеров и небольших VPN.
            0
            Сам сижу на провайдере, который на один виртуальный сервер выдаёт /64 как один IPv6-адрес за тот же рубль в месяц, и этого в принципе хватает (не пробовал пока только PTR-записи для таких подсетей в DNS прописывать). А так не очень понимаю, зачем маленькой подсети нужно /48, если в сегменте в принципе не будет столько устройств на L2 (да и даже в /64 не будет)? Крах любого протокола начинается с расточительства.
              0
              Например одну /64 можно отдать Docker, одну для назначения адресов различным сервисам, ещё несколько для создания VPN для синхронизации данных и бэкапов, целую пачку админу из страны через чур контролирующей интернет. А так же его тестовым виртуальным машинам и сетевым стендам.
              IPv6 создан для расточительности, неважно нужны ли Вам сети прямо сейчас, если они Вам вдруг понадобиться, админам не придётся перекраивать сеть и плодить 100500 маршрутов к одной точке.
                0
                Уж не знаю, насколько он создан для расточительности… в своё время говорили, что и 640 КБайт ОЗУ всем хватит. И наверняка то же самое говорили про IPv4. И что, начинать всё заново? Если тому же Docker отдать не /64, а /96, будет так плохо?
                  0
                  Даже если население земли вырастет до 100 млрд. и каждый получит по десятку /48, всё ещё останется запас. Так же память роутера закончится раньше, чем адреса в /64. IPv4 был создан в расчёте на институты и военных США, никто не рассчитывал на его повсеместное распространение. Как только интернет стал разростаться, так сразу был придуман IPv6. С IPv6 такое может случиться только если мы начнем расселение по другим планетам и изобретём передачу данных быстрее скорости света. И только тогда придется всё переделывать.
                  Docker может либо с индивидуальной /64, либо NDP-proxy с сетью /64, по другому никак.
                    +1
                    Даже если население земли вырастет до 100 млрд. и каждый получит по десятку /48, всё ещё останется запас

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

                      0
                      В одной /64 18,5 квинтиллионов адресов, неужели одному пользователю не хватит на каждую вещь в доме?
                        0

                        Одному обычному пользователю хватит.
                        Вопрос все же не в нем, а в куче всякого добра, которое будет потреблять адреса помимо конечных пользователей интернета, подключающихся через провайдера. И если каждый холодильник хапнет себе /64 (без участия пользователя и не из его доли, полученной от провайдера), то будет весело.
                        Представьте себе сеть холодильников, связанных через какой-нибудь хитрый VPN с некоторой глобальной инфраструктурой поддержки с уникальным /64 на каждый холодильник, включая давно помершие и утилизированные. А еще есть куча оборудования, напрямую с конечным пользователем никак не связанного: диагностические системы на каждом промежуточном узле любой сети от канализации до систем связи, различные автономные системы в промышленности, различные транспортные средства и т.д., и т.п.


                        Те же IPv4, кстати, тоже в основном не у конечных пользователей осели. Многое осело в инфраструктуру передачи данных. Многое хапнули и не отдают крупные организации (пес его знает, как они их там утилизируют).

                          0
                          Оно так не умеет. Только роутер может запросить подсеть у провайдера и даёт он сколько хочет, а не сколько попросили. Уж не говоря о том, что домашние роутеры обычно не умеют делегировать подсеть. Так, что если последовательно подключите несколько роутеров, сами они адреса не настроят. Это конечно недоработка.
            +2
            LIR обычно получают /32, в лучшем случае /29 (больше придётся очень постараться с обоснованиями), так что в итоге получаем совсем не триллионы /48, а вполне исчерпаемые 64K-512K адресов в пределах LIR.

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

            Для тех кто хочет строить свои внутренние сетки, можно давать /56 — это аж 256 /64, более чем достаточно даже для крупных клиентов, и только там где реально необходимо — можно уже и /48 давать.

            Если вы компания-пользователь (т.е. не провайдер) со своим DC (реальным или виртуальным) и кучей локалок — то /56 это достаточно много, а если учесть что ISP может раздать минимум 16M /56 — то и тут особых проблем нет.

            То что пространство IPv6 огромно вовсе не значит что его нужно бездумно раздавать, не задумываясь о последствиях, особенно если учесть что всё идёт к тому что чуть ли не каждая блоха будет подключена к интернету.

              0
              Как бы люди себе IPv4 очень давно уже выбивали исключительно по обоснованиям, ничего нового тут нет. Если у Вас более 200 тысяч клиентов, то так ли сложно обосновать получение сети крупнее /29? Просто пишешь сколько клиентов, сколько ещё может быть, умножаем на потери агрегации и говорим, что хотим всем дать по /48, как они же и рекомендуют.
              Каждому виртуальному серверу нужно по /64 минимум. Иначе в случае спама одного из товарищей по серверу в бан улетят все и хорошо если не вся /48. Hetzer вообще с ума сошли, предлагают дробить /64, много где такие сети не работают. Так они кстати и провоцируют перепродажу адресов поштучно. Возможно они делают это специально, чтобы убрать ресселеров.
              Вы исходите из минимально возможной потребности, тогда как IPv6 создавался для удобства администрирования.
              Каждой блохе можно дать адрес из одной /64, они могут хоть целыми тучами мигрировать между сетями. А сетки нужно считать от конечных пользователей, то есть контрактов с ISP. Поскольку население земли не бесконечно, то и контрактов будет относительно мало.
                0
                Если у Вас более 200 тысяч клиентов, то так ли сложно обосновать получение сети крупнее /29?

                Думаю да, по крайней мере в RIPE — потому что они считают использование по /56 блокам, а если учесть что в /29 аж 134 миллиона (!) таких блоков — удачи с доказательствами.

                Даже /48 будет > 500K — если у вас 200 тыс. клиентов, хватит каждому по два раза.

                Каждому виртуальному серверу нужно по /64 минимум. Иначе в случае спама одного из товарищей по серверу в бан улетят все и хорошо если не вся /48.

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

                Да даже если давать свой /64 на отдельный сервер (примерный эквивалент одного IPv4) — чем это неудобно (в большинстве случаев)? С блокировками проблем нет (в одном /64 только один сервер), в пределах сервера IP немеряно. Подчеркну — речь про клиентский сервер, будь то DS/VPS/VDS, а не про сервер хостера где крутится много клиентов.

                Если нужна подсетка — как я уже говорил выше, клиенту даётся /56 и он может построить 256 сетей/хостов /64 — это покрывает, вероятно, потребности 99.9% всех клиентов — обычных клиентов, а не тех кто покупает дешёвые DS и потом сам притворяется хостером (именно в этом случае возникают проблемы со спамерами в одной /64).

                Hetzer вообще с ума сошли, предлагают дробить /64, много где такие сети не работают.

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

                Возможно они делают это специально, чтобы убрать ресселеров

                Вы не путайте реселлеров с обычными клиентами — первые это те кто перепродаёт сервера самого Hetzner (в т.ч. виртуальные), и они (разумеется) получают один /64 на один сервер (любой). Если вы устраиваете свой хостинг на своём сервере — вы уже не реселлер, вы просто клиент.

                Хотите быть хозяином и самостоятельно распределять свой тяжко заработанный /29-/32 — запрашивайте AS, поднимайте BGP и хоститесь у кого-то типа MyLoc, или любом другом датацентре где дают возможность приходить со своими сетками, в крайнем случае найдите хостера которые дают /48-/56, благо их достаточно (хотя и дороже).

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

                Распределение любого потенциально конечного ресурса должно быть обосновано, иначе получим то что получили с IPv4 — когда раздавали /24, /16 и даже /8 тоже исходили из «удобства администрирования», кто ж знал что каждая кофеварка свой IP захочет.

                Вообще насколько я могу судить по дискуссиям на тему IPv6 — проблемы с распределением реально возникают только у тех кто лепит свой хостинг на базе чужих ДЦ (обычно дешёвых), те кто покупает хостинг для обычных задач у владельцев ДЦ вообще проблем не испытывают.
                  0
                  Думаю да, по крайней мере в RIPE — потому что они считают использование по /56 блокам
                  Мда, ARIN говорит, что давать по /48 пользователю это обычное дело. Да и RIPE так же считал некоторое время назад. А сейчас выходит, что обладателю белого IPv4-адреса, достанется больше IPv6-сетей(за счёт 6to4), чем нативно… И he.net всем даёт /48 вообще бесплатно. По моему это абсурд.
                  чем это неудобно (в большинстве случаев)?
                  В большинстве случаев вполне удобно, а в остальных будут требоваться костыли, может даже NAT. Хотя контейнеризация вроде уже стала нормой, а следовательно им нужны адреса, которые придётся настраивать ручками или через NDP-proxy.
                  даже /8 тоже исходили из «удобства администрирования»
                  Ну им сейчас определённо очень удобно администрировать и у каждого принтера по белому адресу.
              0
              Не нашел понятного руководства по настройке NAT64 на Windows 10. Может кто-то встречал или может статью написать?

              У меня достаточно типовой setup домашней лабы:
              — статический IPv4 от провайдера
              — физический комп в DMZ, так как мой router IPv4 only
              — на компе поднят туннель 6in4 (v6v4tunnel) до туннельного брокера, получена /48
              — на компе прописаны /64 и серый 192.168.1.XXX
              — лаба на Hyper-V на internal виртуальном коммутаторе

              Виртуалки в лабе IPv6 only, на каждой /64.
              Хотелось бы, чтобы хост выпускал их в IPv4 сеть.
                0
                Есть же хороший курс, да еще и бесплатный www.networkeducation.ru/video/track/ipv6
                p.s. читал по диагонали.
                  0
                  IPv6 уже успел устареть, не отвечая современным реалиям, т.к. стандарты по этому протоколу были выпущены еще аж в 1996г. (начал разрабатываться с 1992г.) Да и тут на Хабре было неск. статей по поводу провала IPv6, его недостатков и т.д. А еще более старый IPv4 пока справляется, и дефицит адресов не так ощущается при использовании частных (серых) адресов, несмотря на то что вроде как в конце прошлого года был выдан последний блок адресов подсети /22 (1024 адресов); и пока что IPv4 является рабочей лошадкой Интернет.

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

                  Самое читаемое