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

При попытке просто расширить адресное пространство инженеры столкнулись с тем, что придётся значительно изменить формат заголовка IP. Вывод они сделали такой: раз текущим форматом заголовка IPv4 им все-таки придется пожертвовать, то почему бы радикально не переделать протокол IP, чтобы исправить в нем существующие недостатки и добавить новые возможности. Именно поэтому между протоколами IPv4 и IPv6 нет совместимости.

На вопрос «а почему именно v6, а не v5, ведь теперь адрес не состоит из 6 байт?» можно ответить так. Почитайте RFC 1819. Он был принят и в нём указано, что в заголовке пакета должна быть указана версия 5. Версия 5 просто была занята при разработке нового протокола, который, соответственно и получил наименование IPv6 и заветное значение `6` в заголовке пакета.

Забудьте о NAT

NAT (Network Address Translation) - это метод, который позволяет множеству устройств в локальной сети использовать один общедоступный IP-адрес. Однако, с появлением IPv6, NAT становится необязательным. Сколько человеко-часов уходит на то, чтобы «подружить» NAT с некоторыми протоколами, из которых вспомним хотя бы IPsec, FTP и SIP. Если вы общаетесь со своими друзьями и родственниками по видео/аудио через интернет, вы вынуждены использовать промежуточный сервер, как и тысячи и миллионы других клиентов, потому что между вами NAT. Вы не можете пересылать поток напрямую. NAT — это костыль в IPv4, который был призван решить его проблемы. Его использование в IPv6 возможно, и, даже существуют готовые программные решения, но использовать их нет никакой необходимости.

Очень часто можно слышать аргумент, что NAT — это про безопасность. Однако если у вас используется сквозная прозрачность, то вы можете пересылать пакеты через ваш маршрутизатор без изменения их содержимого, а обеспечить тот же самый уровень защиты с помощью брандмауэра, который требует значительно меньше ресурсов. Я даже ощущаю чрезвычайную заботу о моей безопасности от одного крупного провайдера в РФ, да такую, что я не могу использовать протоколы UDP и SCTP, потому что обратные пакеты, как и любые соединения TCP в мою сторону, до меня не доходят. И это никак не решить, потому что, официально, провайдер IPv6 не предоставляет.

Маска сети (префикс) теперь не так важна

Из-за размеров адреса в IPv6 маска сети вырастает до таких же размеров. Чтобы упростить жизнь администраторам сети, вместо маски сети в IPv6 используют длину маски или, по другому, префикс. Маска сети, конечно, более гибкий инструмент и позволяет использовать даже чередование нулей и единиц. Но на практике это встречается крайне редко. Скорее, я даже не могу вспомнить ни одного случая, где бы это использовалось и где нельзя обойтись обычной маской. Идея префикса следующая — нужно просто посчитать количество единиц в маске сети и указать его. С помощью этого числа мы всегда сможем восстановить маску, использовав в левой её части указанное число единиц, а правую часть заполнив нулями. Лично мне было удобней пользоваться этим даже в IPv4 вместо маски, потому что это заметно компактней. Подобный формат для IPv4 поддерживает, например, пакет iproute2 в Linux.

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

Т. е. при длине адреса 128 бит, половина их используется в качестве адреса устройства внутри сети. Использование другого префикса без веской причины добавит вам приключений. Этих 64 бит вполне хватает, чтобы устройствам с любым MAC-адресом обеспечить уникальным канальным адресом, а значит узлы при общении между собой могут выбрать себе безопасно IPv6 адрес на основании своего MAC-адреса.

Таким образом на одну сеть IPv6 выделяется 64 бита и ещё 64 бита остаётся для её идентификации. Изначально предлагалось выделять каждому клиенту по 65536 сетей стандартного размера. Однако часто можно встретить, что выделяется только 256 сетей. Вроде бы расточительство выдавать даже по 256, не говоря уже о 65536! Но если сделать прикидки, то все адреса IPv6, которые начинаются на `2` могут обеспечить каждого жителя земли живущего в 2023 году более чем 2,5 тысячами сетей по 65536 сетей стандартного размера /64 или более 650 тысячами сетей по 256 сетей, такого же, стандартного размера /64. Адресации явно хватает с большим запасом. Но даже если в будущем будет признано, что раздавать по 65536 сетей в одни руки или даже 256 - это расточительство, то алгоритм выделения можно изменить в будущем для адресов, которые не начинаются на `2` и `3`. В запасе ещё `4`, `5` … `d`, `e`.

Не используйте IPv6 адрес явно

Если ваше устройство не предоставляет другим каких-либо сервисов, то забудьте о том, что ваше устройство вообще имеет IP-адрес. Считайте, что оно просто имеет доступ в сеть. Да, IP адрес или, скорее, адреса у него есть, но забудьте о них совсем на обычных устройствах, к которому другие не должны иметь доступ без разрешения. Даже если вы хотите, например, предоставить доступ по сети в папку в Windows или открыть доступ на сетевой принтер, вам не нужен постоянный IP-адрес, можно использовать сервисы вроде LLMNR или mDNS для обнаружения вашего устройства в сети и пользоваться именами узлов, а не IP адресами. Конечно, для серверов и всего того, что должно быть доступно всем, есть статическая адресацию и DNS.

Почему об IP адресе лучше забыть? Потому что в IPv6 ваше устройство может иметь множество IPv6 адресов одновременно:

1. link-local - ваше устройство автоматически будет иметь этот адрес при включении IPv6 и использовать его в пределах канала;

2. GUA (Global unicast IPv6 address) - глобальный адрес или несколько, т.е. именно тот адрес, который вы можете использовать для связи с любыми узлами в интернете, и, да, вы можете иметь их несколько одновременно;

3. ULA (Unique Local IPv6 Address) - если ваш провайдер не предоставляет вам IPv6 адресацию или префиксы вам выдаются динамически, вы можете использовать специальный тип адресов — локально уникальных.

Кроме этого, ваше устройство может использовать специальные адреса для multicast и anycast вещания. Это отдельная большая тема и я её сейчас не затрагиваю.

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

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

У приложений нет необходимости указывать адрес, который будет использован как исходящий. Это должна делать сама операционная система. Фактически адрес нужен приложениям только в том случае, если они желают передать его удалённой стороне, например, при совершении видеозвонков. Клиенты обмениваются своими адресами через центральный сервер после чего, уже не зависимо от него, осуществляют прямое соединение между собой по тем адресам, которые они указали.

DHCP больше вам не нужен

Совсем забывать про него не нужно. Механизм DHCP в IPv6 всё ещё остался, но теперь это, скорее, опция, а не необходимость. Теперь любой маршрутизатор может анонсировать свою сеть и ваши устройства в сети с помощью механизма SLAAC могут самостоятельно назначить себе адрес. SLAAC (IPv6 Stateless Address Auto-configuration) — это способ получения устройством глобального IPv6-адреса одноадресной рассылки без использования DHCPv6-сервера.

До сих пор в сети можно найти заблуждение, что IPv6 позволяет вычислить тип устройства и его производителя по IPv6 адресу. Да, иногда такое возможно, но только если адрес устройство назначает себе на основе MAC-адреса своего интерфейса. Однако уже давно существуют расширения, которые реализованы в операционных системах и которые призваны скрыть ваш MAC-адрес. Сейчас многие операционные системы назначают себе адрес на основе случайных данных из которых атакующий вас уже ничего не сможет извлечь полезного, кроме, конечно, вашего IP адреса. Просто посмотрите на ваш IPv6 адрес. Если в середине второй части адреса вы видите последовательность `xxFE:FFxx`, то, с большой долей вероятности, адрес назначен на основании MAC адреса. Если это часть глобального адреса (который начинается на цифру `2` или `3`), то стоит проверить настройки вашего устройства и включить механизм безопасности.

ARP больше не используется

ARP (Address Resolution Protocol) - это протокол, который используется в IPv4 для связи между IP-адресами и MAC-адресами устройств в сети. В IPv6 ARP заменен на NDP (Neighbor Discovery Protocol). Чтобы NDP работал нормально, нужно обеспечить нормальную работу ICMPv6. ARP больше не нужен.

Промежуточные узлы не обязаны иметь публичные IP адреса

Любой маршрутизатор в сети IPv6 может иметь только link-local адреса на своих интерфейсах. Этого вполне достаточно чтобы общаться со своими соседями и клиентами. При этом маршрутизатор может получить префикс от вышестоящих узлов, раздавать эту адресацию узлам внутри сети и даже отдельные префиксы другим маршрутизаторам, а также обеспечивать пересылку трафика между узлами локальной сети и интернет, но при этом не использовать ни одного адреса из полученной сети. Иметь в качестве шлюза адрес `fe80::1`, т.е. link-local адрес — это нормально.

Диапазон link-local во всех сетях один

Изначально может показаться странным, но link-local адреса во всех сетях используют один диапазон — `fe80::/10`. Более того, узел с несколькими интерфейсами может иметь один и тот же link-local адрес на всех интерфейсах, например, `fe80::1`. И это будет работать! link-local адреса должны быть уникальны только в пределах одного канала, т. е. в пределах той части сети, куда подключен сетевой интерфейс. Всё, что должен знать маршрутизатор, что следующий маршрутизатор доступен через этот интерфейс и имеет такой-то канальный (link-local) адрес. Больше никаких заморочек с выделением /30 сетей для связи соседних маршрутизаторов, как это было для протокола IPv4.

Единственное неудобство такого решения — если вы хотите использовать link-local адрес удалённого устройства, то необходимо кроме этого адреса указывать интерфейс, через который это устройство доступно.

[~]$ ping fe80::1%wlp3s0

PING fe80::1%wlp3s0(fe80::1%wlp3s0) 56 data bytes

64 bytes from fe80::1%wlp3s0: icmp_seq=1 ttl=255 time=3.79 ms

Безопасность сети

Если ранее необходимо было защищать сеть от посторонних DHCP серверов, то теперь необходимо, также, запрещать анонсы маршрутизаторов IPv6 (RA) с посторонних направлений, т. к. с они могут перенаправить клиентский трафик по другому направлению. Как это реализуется в вашем оборудовании можно узнать через поисковые системы с помощью запроса «RA Guard». Cisco, Juniper, Huawei, Eltex и другие предоставляют необходимый функционал в своих устройствах на современных прошивках.

Заключение

Основная проблема внедрения IPv6 в 2023 году — отсутствие заинтересованности у провайдеров. Нет клиентов с IPv6, нет потребности в IPv6 на серверах. Нет IPv6 на серверах, нет потребности у клиентов. Замкнутый круг. По факту же, большинство современных устройств вполне способно полноценно работать в условиях наличия только IPv6 протокола. Наиболее приспособленные к этому мобильные устройства. С персональными компьютерами немного сложнее, например, может потребоваться установка дополнительного софта для приложений, которые хотят по прежнему использовать протокол IPv4 (например, магазин приложений Steam).

Ознакомьтесь подробнее с IPv6 и вы больше никогда не захотите возвращаться обратно к IPv4.

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


  1. Cayp
    00.00.0000 00:00
    +13

    mandatory meme
    mandatory meme


    1. netch80
      00.00.0000 00:00
      +1

      Плюсанул за картинку, хоть это сейчас и борьба с ветряными мельницами. Увы, никто делать чуть разумнее (без устарелостей IP4, но и без перекосов IP6) уже не будет.


  1. a_anistratenko
    00.00.0000 00:00
    +3

    Актуальная продуманная технология!

    Неделю назад сам перешел, через туннельного брокера He.

    Да, надо преодолеть внутренне сопротивление, консерватизм и вникнуть.


  1. none7
    00.00.0000 00:00
    -1

    Как минимум в IPv6 есть Google, Yandex, Facebook. А гиганты на то и гиганты, что выдают трафика больше других. Я скорее слышал вариант «Все популярные сайты есть в IPv4 и IPv6 им не необходим. Вот когда будут популярные IPv6-only сайты, тогда и приходите». У сайтов вообще нет никаких причин внедрять IPv6, кроме телеметрии. А существование P2P трафика не интересует вообще никого. Если он Вам нужен, купите услугу «белый IP».

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


  1. nickpetrovsky
    00.00.0000 00:00
    +3

    Мой энтузиазм с ipv6 давно угас и перешёл в практические рельсы (я не имею отношения к сетям, терминология может быть некорректна). Объективно он мало что даёт для обывателя кроме некоторых относительно редких случаев. И на практике можно найти компромиссное решение в ipv4. Из того что не было указано в статье, ipv6-only корпоративные сети (MS, Meta etc.) используют именно его по причине недостатка локальных адресов с учётом адресных пространств на контейнеры. То есть у них была практическая проблема и они её решали. Мобильные операторы северной Америки пошли по тому же пути и на самом деле у них ipv6-only с подобием 464xlat, как я понимаю у этого решения тоже была вполне практическая потребность. То есть если вы запустите дома ipv6-only сеть с 464xlat скорее всего разницы на мобильных устройствах вы не заметите вообще.

    Поделюсь своим практическим опытом использования ipv6, тут, в Беларуси, есть закон который обязал всех провайдеров его поддерживать, и они его поддержали, правда большинство за отдельную плату. Из положительных моментов я бы отметил вот что: все которыми я пользовался выдают префикс /56 (некоторые даже статический), очень грамотно и полезно если есть в планах сегментировать сеть на vlan (их получится аж 256 по /64). Какая практическая польза, попробую описать реальные +\- конкретно в моём случае:

    • Выше автор писал о том что якобы это помогает всяким сервисам видео связи, спорное утверждение, так как любой нормальный файрволл настроен на блокировку всех входящих соединений если не разрешено иное, каких-то "лучших практик" для FaceTime или webrtc именно для ipv6 я не нашёл, так что relay сервера избежать это не даёт. (пользы около 0)

    • Якобы отсутствие NAT всё ускорит, возможно речь идёт скорее о клиентском оборудовании. Из заметного иногда связь с некоторыми европейскими датацентрами стала быстрее на 10-12 Мбит (но иногда и наоборот), возможно связано с тем что трафик движется по отличным от ipv4 линиям связи. (+\-)

    • ipv6 дал возможность описать конкретные правила для файрвола с префиксами в известных мне сетях и подключаться с планшета к домашнему ssh и rdp (tcp+udp) без vpn, и не светит порт на весь интернет. Удобно и работает крайне надежно даже на мобильной связи. Гипотетически энергопотребление будет меньше из-за отсутствия дополнительного шифрования. Можно было и не описывать строгие правила, так как затраты на пинг одной /64 подсети исчисляется гигабайтами. Условным плюсом можно считать отсутствие необходимости менять стандартный порт, в некоторых мобильных приложениях это имеет смысл. Однако можно настроить мобильный профиль для IPSec и не знать проблем с доступом к локальным ресурсам :) (+, гибкость в пробросе сервисов в интернет и их "условно" бОльшая безопасность)

    • для того чтобы нормально настроить докер контейнеры в разных комбинациях с сетью в ipv6 придётся использовать vlan и свитч который их поддерживает для отдельного префикса, и как я понял если нет возможности отдавать для докера меньшую подсеть чем /64 все становится в разы сложнее (но вроде как возможно). И весь трафик между сегментами /64 даже в локальной сети будет ходить через маршрутизатор. Так же нет полной ясности как это делать если префикс от оператора только динамический. (-, относительная сложность корректной конфигурации, если выдаваемая подсеть провайдером >= /64 все становится в разы сложнее)

    • наличие глобального ipv6 адреса != доступу к интернету, камеры и устройства iot могут остаться в жесткой изоляции в отдельном vlan, однако есть возможности вынести видеорегистратор в другую локацию не делая дополнительных туннелей, в критический момент можно подключиться к ним напрямую поменяв правила фаервола (+)

    • сложность конфигурации роутера, некоторые провайдеры отдают ipv6 по pppoe и после переподключения соединения в Linux на основе Debian/Ubuntu systemd не выполняется обновление конфигурации dhcpcd и клиенты теряют свои адреса. Это известная проблема, возможно уже исправили.

    • Если у DNS записи есть DNSSEC и нет корректной записи для ipv6, то 464xlat работать не будет или нужно выключать его проверку полностью. (-, редкий случай, как и DNSSEC в целом :) )

    • Между двумя сетями со статическими префиксами можно настроить защищенный туннель без оверхеда. (+, сам не использовал)

    После интеграции ipv6 и интересного времени с его настройкой я пришёл к выводу что он нужен относительно редко и только для специфических потребностей, там раскрываются его сильные стороны. Решение проблем с ним далеко не так очевидны и корректная конфигурация не так проста. Тут скорее желание быть ближе к прогрессу, для энтузиастов я бы рекомендовал сделать дома ipv6-only с 464xlat чтобы даже не иметь dual stack, это возможно будет полезно для разработчиков мобильных приложений ориентированных на страны где ipv6 правило а не исключение.


    1. dartraiden
      00.00.0000 00:00

      любой нормальный файрволл настроен на блокировку всех входящих соединений

      Любая нормальная ОС уведомит пользователя о том, что приложение хочет открыть порт для входящих соединений. В этом плане поведение ничем не отличается от "белого" IPv4. Но, зато не требуется этот самый белый IP покупать, как щедро предложил один из комментаторов выше (чужие деньги тратить я так-то тоже горазд, а вот свои неохота).


      Ещё плюс, что раз нет NAT — то отпадает нужда в UPnP, NAT-PMP, PCP и прочих костылях, которые добавляют уязвимостей. Ну, и ALG туда же.


    1. FSA Автор
      00.00.0000 00:00

      Выше автор писал о том что якобы это помогает всяким сервисам видео связи, спорное утверждение, так как любой нормальный файрволл настроен на блокировку всех входящих соединений если не разрешено иное, каких-то "лучших практик" для FaceTime или webrtc именно для ipv6 я не нашёл, так что relay сервера избежать это не даёт. (пользы около 0)

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

      Якобы отсутствие NAT всё ускорит, возможно речь идёт скорее о клиентском оборудовании. Из заметного иногда связь с некоторыми европейскими датацентрами стала быстрее на 10-12 Мбит (но иногда и наоборот), возможно связано с тем что трафик движется по отличным от ipv4 линиям связи. (+\-)

      В современных условиях NAT теперь есть даже у провайдеров, не говоря уже о клиентских маршрутизаторах, где без NAT никак. Любой NAT - это вмешательство в пакет IP. Его нужно переписывать по правилам, а это требует некоторого времени. Кроме этого, глобальная таблица маршрутизации IPv4 значительно распухла из-за того, что адресное пространство оказалась чрезвычайно сегментировано и маршруты не получается агрегировать. Никаких даже намёков на улучшение точно не предвидится. Есть RFC 1715 и RFC 3194 из которых понятно, что проблемы с этим начинаются значительно раньше, чем адресация исчерпается, а она уже исчерпана!!! Таблицы для IPv6 значительно меньше и при правильном распределении адресов с проблемой, подобно той, что сейчас IPv4 мы не встретимся ещё долго. Меньше таблицы - меньше нагрузки на маршрутизаторы. Увы, но это можно будет ощутить только после отказа от IPv4, потому что сейчас требуется держать в памяти жирные таблицы IPv4 и IPv6. И оба типа трафика требуют своего внимания.

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

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

      наличие глобального ipv6 адреса != доступу к интернету, камеры и устройства iot могут остаться в жесткой изоляции в отдельном vlan, однако есть возможности вынести видеорегистратор в другую локацию не делая дополнительных туннелей, в критический момент можно подключиться к ним напрямую поменяв правила фаервола (+)

      Это скорее вопросы к производителям железа. У них и в IPv4 не всё гладко, а если нужен доступ, то нужны дополнительные железки, чтобы его обезопасить. Меняем шило на мыло. Ничего по факту не меняется.

      сложность конфигурации роутера, некоторые провайдеры отдают ipv6 по pppoe и после переподключения соединения в Linux на основе Debian/Ubuntu systemd не выполняется обновление конфигурации dhcpcd и клиенты теряют свои адреса. Это известная проблема, возможно уже исправили.

      Тут ничего не могу сказать. У меня провайдер выдаёт IPv6. Проблем особо никаких нет, кроме их заботы о моей безопасности и блокировки входящих соединений. Ну и специфический маршрутизатор, который толком ничего с IPv6 не умеет, кроме как раздать одну сеть /64. Будут больше IPv6 использовать, будет и софт допиливаться.

      Если у DNS записи есть DNSSEC и нет корректной записи для ipv6, то 464xlat работать не будет или нужно выключать его проверку полностью. (-, редкий случай, как и DNSSEC в целом :) )

      Да. Есть проблема с DNSSEC. Но, благо, их исчезающе мало, потому что заморочиться DNSSEC, но при этом совсем не смотреть в сторону IPv6 как-то странно. Если сервисы сами используют IPv6, то с такой проблемой точно не столкнёшься. Но, да. Нужно проверять в каждом конкретном случае. Ну и проблема выплывает только если отказываешься от IPv4 у себя в сети, а не используешь дуалстэк.


  1. 13werwolf13
    00.00.0000 00:00
    +1

    Основная проблема внедрения IPv6 в 2023 году — отсутствие заинтересованности у провайдеров

    ну уж нет.. основная проблема ipv6 что в отличии от ipv4 некоторые вещи подняли с системного уровня на прикладной. за такое руки бы оторвать..


  1. shifttstas
    00.00.0000 00:00

    Ну уже аддопшен неплохой в некоторых странах более 50% https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption