Преимущества и недостатки IPv6 (Sergey Matveev’s homepage)

Next: Преимущества и недостатки FreeBSD, Previous: Мультимедиа форматы, Up: Articles

Преимущества и недостатки IPv6 ¶

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

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

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

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

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

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

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

Что же даёт IPv6, какие плюсы имеет:

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

Некоторые well-known multicast адреса позволяют легко узнать какие компьютеры вообще есть в сети (broadcast домене Ethernet-а), моментально в ad-hoc режиме их найдя и имея возможность сразу же подключиться:

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

Killer-feature: SLAAC. Автоматическое конфигурирование адресов, буквально plug-and-play, буквально без каких-либо клиентов и серверов с базами данных для хранения состояний. Просто подключая кабель, ОС делает одну приёмо-передачу ICMPv6 пакетов, после чего является полноценным участником глобальной полностью работающей (со всеми настроенными адресами маршрутизаторов, MTU, DNS) IPv6 сети. На маршрутизаторе, с каким-нибудь rtadvd, или вообще не требуется конфигурационных файлов, или не сложнее чем одна строчка на интерфейс. Например:
```
igb0:addr="2001:dead:beef::":mtu=1320:rdnss="2001:dead:beef::1":
```
Anycast адреса штатно поддерживаются и обрабатываются NDP протоколом, прозрачно с ними работая из коробки.
IPv6 заголовок существенно проще обрабатывать: нет контрольных сумм, фиксированной длины фиксированные поля, в противовес IPv4 с варьируемой длиной заголовка и пересчётом контрольной суммы на каждом hop-е. Плюс в два раза меньше полей чем в IPv4. Это эффективно и просто!
Flow label в IPv6 заголовке позволяет иметь состояние сессий/соединений не по (src, dst, proto, portSrc, portDst), для которого нужно распарсить и заголовок сетевого и транспортного уровней, а по (src, dst, flowLabel) которые находятся в фиксированных местах одного IPv6 заголовка. А если IP пакет фрагментирован, да так, что заголовок транспортного уровня разбит, то это задача уже не тривиальная. Flow label может быть очень эффективным!
Multicast рассылки NDP протокола не грузят большие сети и не прерывают работу хостов, как это делает broadcast, используемый IPv4, как минимум, для ARP и DHCP. Это эффективно!
Работа NDP, DHCPv6 протоколов поверх ICMPv6, поверх сетевого уровня, максимально старается разделять всё что касается сетевого и канального уровней. В идеале, NDP/ICMPv6 не нужно знать про то, поверх чего оно работает: Ethernet ли, PPP или ещё какой канал. В отличии от IPv4 мира с его ARP и DHCP, например при работе не на Ethernet, а на PPP, необходимо было встраивать в сам PPP поддержку/эмуляцию этих протоколов. В IPv6 все подобные протоколы просто работают поверх link-local адресов. Кроме того, это позволяет ещё и применять IPsec политики к ним! Это очень удобно и продуманно!
NDP NUD (neighbour unreachability detection) позволяет быстро определять двустороннюю (не)доступность хоста, быстро переключаясь на использование другого next hop-а или маршрутизатора, если хост перестал отвечать. Это, по сути, автоматический heartbeat хоста, в противовес просто большим timeout-ам в IPv4. Это просто и эффективно!
NDP RA (router advertisement) и NDP redirect пакеты сразу же содержат адреса канального уровня, а не только сетевые, не требуя совершать дополнительные round-trip-ы для NDP address resolution, как это было в IPv4 мире. Это продуманно и эффективно!

Отдельно хочется упомянуть отлично продуманный Mobile IPv6. Имея всего-лишь относительно простого демона (home agent) в домашней сети и демона на мобильном хосте (mobile agent), можно иметь полностью работающий мобильный IPv6, когда, обращаясь по домашнему адресу, всегда можно достучаться до мобильного. В отличии от Mobile IPv4, без каких-либо дополнительных требований к сети где находится мобильный агент. IP пакеты при этом просто будут эффективно (всего-лишь добавляя расширенный IPv6 заголовок) проксироваться с домашнего агента на мобильный. Кроме того, если сторонний инициатор соединения тоже поддерживает MIPv6, то он прозрачно договорится с домашним и мобильным агентами о том, что трафик он будет слать напрямую мобильному хосту, без проксирования через домашний, обеспечивая максимальную возможную эффективность (с учётом одного расширенного IPv6 заголовка) передачи. А благодаря быстрому NDP NUD, смена мобильной сети будет приводить к минимальным временным задержкам из-за обновления адреса мобильного хоста. И всё это с минимальными добавлениями в ICMPv6/NDP протоколы, введением простого расширенного IPv6 заголовка и Mobility Header.