IPv6 основы
Совсем недавно была озвучена новость о том, что Ip адреса версии 4 заканчиваются и причем стремительно, и естественно встает вопрос о том, что же делать? С учетом того, что те у кого все хорошо в любом случае столкнутся с необходимостью перехода. Простым смертным тоже стоит начать беспокоиться и быть в курсе всего, и я тоже решил начать, и начать изучение с основ протокола ipv6 (стоит отметить что познания в ipv4 очень пригодятся).
Анатомия IPv6 адресов
Способы записи IPv6 адресов. В пример IPv6 адрес
2001:0470:1f09:01c7:0000:0000:0000:0001
Его можно использовать и в таком виде, однако в подавляющем большинстве случаев данную запись можно существенно упростить. Для начала удаляем нули в начале каждого 16ти битного блока, получая
2001:470:1f09:1c7:0:0:0:1
далее если имеется длинная последовательность из нулей (только если нули занимают весь 16ти битный блок), заменяем её на ::, получая
2001:470:1f09:1c7::1
Существует ещё смешанная шестнадцатирично-десятичная нотация, удобная в dual-stack IPv4/IPv6 средах: так например, адрес
2001:470:1f09:1c7::192.168.0.100
будет автоматически преобразован в
2001:470:1f09:1c7::c0a8:64
В web’e IPv6 адрес зачастую заключается в квадратные скобки, дабы быть легко отделяемым от номера порта, например так:
http://[2001:470:1f09:1c7::100]:80
Маски подсетей
Маски теперь задаются только /prefix’ами (CIDR / VLSM), классовой адресации и стандартной dotted нотации в IPv6 нет.
Типы адресов и их префиксы
Об IPv6 адресации подробно рассказано в RFC4291. Самые распространённые общепринятые IPv6 адреса, их назначения и префиксы.
- ::/128 — Unspecified — Не должен принадлежать ни одному ноду в сети;
::1/128 — Loopback — обратная петля (127.0.0.1 в IPv4);
FE80::/10 — Link-Local — адреса уникальные на линке. Своеобразная замена 169.254/16. Создание IPv6 link-local адреса из префикса fe80:: и MAC адреса сетевой карты, как и многое другое описано в презентации от Microsoft и в документе Introduction to IP Version 6, также процедура создания Модифицированного EUI-64 идентификатора на пальцах разъяснена в Приложении А RFC4291) ;
FEC0::/10 — Site-Local — устарели судя по RFC3879;
FC00::/7 — Unique Site-Local — Пришли на замену Site-Local в RFC4193. Глобально уникальные (с большой вероятностью уникальные), не роутящиеся в интернет адреса. Однако могут роутиться внутри site’a и между site’ами.
::0000/96 — IPv4-Compatible IPv6 Address — устарели.
::FFFF/96 -IPv4-Compatible IPv6 Address — их назначение описано в RFC4038. Прочтение этого RFC будет полезно программистам которые собираются писать Dual-Stack приложения.
Всё остальное это:
Global Unicast — глобальные адреса, уникальные во всем интернете. Пока, в прочем судя по етому документу, доступно только глобальное пространство пространство 2000::/3.
Виды трафика
- Unicast — Старый добрый юникаст;
Multicast (FF00::/8) — Мультикаст теперь необходимое расширение, а не опциональное как в IPv4. IGMPv2 был заменён на MLD (Multicast Listener Discovery). А процедура получения глобального мультикаст префикса стала тривиальной (процедура получения глобального мультикаст префикса для IPv4 описана в RFC2908) — теперь при получении /64 префикса контора автоматически получает 4.2 миллиарда глобальных мультикаст групп. Процедура подробно описано в RFC3306, а также дополнена внедрением адреса RP прямо в IPv6 адрес в RFC3956;
Anycast — используется только роутерами. Указывает на ближайшего получателя. Обычно «близость» характеризуется метрикой протокола динамической маршрутизации;
Broadcast в IPv6 не существует как класс.
Scope / Zone ID / Zone index
В IPv6 появилось такое понятие как Scope, он же Zone ID терминологии Microsoft. Так как у каждого интерфейса есть свой link-local адрес и он
- не обязательно уникален никак
- не отражает интерфейс которому он принадлежит.
Для того, чтобы явно привязать link-local адреса к интерфейсам, было введено понятие Scope.
В документации сказано, что используется он только для link-local и имеет суффикс %ИндексИнтерфейса в Windows (fe80::2b0:d0ff:fee9:4143%3) или %ИмяИнтерфейса в *BSD/Linux (fe80::2b0:d0ff:fee9:4143%em0).
Заголовок IPv6 пакета
Значительные изменения в формате заголовка пакета
- Фиксированный размер заголовка;
Отсутствует CRC заголовка, соответственно, его не надо проверять, а также пересчитывать для каждого пакета при изменении TTL. Так как crc больше нет, то вся ответственность за целостность информации должна лежать на протоколе более высокого уровня, так например у UDP пакетов наличие checksum теперь обязательно и UDP/IPv6 пакеты с CRC 0000 будут просто отбрасываться роутером;
Сам TTL теперь именуется Hop Limit (скорее всего потому, что раньше одним из условий у роутера было уменьшать TTL на один каждую секунду прибывания пакета в очереди, поэтому и TIME-to-live). Кстати, странно, что он до сих пор 8 бит, ибо лет через 20 думаю от меня до среднестатистического японца может быть и 500 роутеров;
Роутеры теперь не занимаются фрагментацией пакетов. Хосты должны сами проводить Path MTU discovery и разбивать пакеты.
Метки потоков, служат, как я понимаю, для разгрузки роутеров и более точной приоритезации трафика;
Встроенный IPSec
Extension Headers
Заголовок пакета теперь фиксированной длинны и заметно упрощённый, однако благодаря Extension Header’ам обеспечивается гибкость большая нежели у IPv4 Options. Подробно структура IPv6 пакета описана в RFC2460, тут я опишу лишь самое основное.
Итак, каждый пакет содержит 8ми битное поле называемое Next Header, в нём содержится идентификатор заголовка идущего сразу за заголовком пакета. Это не обязательно заголовок более высокого уровня (TCP/UDP), так например, следующим заголовком может быть заголовок протокола IPX или ещё один заголовок IPv6. Extension Headers могут идти (а могут и не идти =) ) сразу после заголовка IPv6 (между заголовком и payload’ом IPv6 пакета) и включают в себя дополнительную информацию сетевого уровня. На данный момент имеются следующие типы Extension Header’ов:
- Hop-by-Hop Options. В документации сказано, что любой роутер на пути следования пакета должен просматривать только IPv6 заголовок, все остальные заголовки предназначены эксклюзивно для получателя пакета. Однако Hop-By-Hop заголовок является исключением — его просматривают все роутеры и если он есть, то должен идти сразу за IPv6 заголовком.
Routing — RFC5095 отменяет Type 0 Routing Headers, которые содержат в своём определении DoS уязвимость (ещё серьёзнее нежели source routing в IPv4). Подробнее security в IPv6 обсуждается в RFC4942.
Fragment — Заголовок ферментированного пакета. Как я уже упоминал, роутеры больше не занимаются фрагментацией, так что отправитель сам должен позаботится об оптимальном размере пакета, иначе получит Packet too big от одного из роутеров на пути. Кстати, MTU для работы IPv6 не должен быть менее 1280.
Destination Options — Опции предназначеные только получателю.
Так же в имеются заголовки IPSec шифрования
- Authentication — RFC4302
Encapsulating Security Payload — RFC4303
ICMPv6
Новый переработанный ICMP — ICMPv6. Тут практически всё осталось как было. Подробнее об изменениях можно прочитать в RFC4443.
NDP
NDP (Neighbor Discovery Protocol) заменил протокол ARP. Одна из новых «фитч» NDP — Neigbour Reachability Detection, позволяющая определить доступность хоста одним из двух методов:
- С помощью протокола более высокого уровня
С помощью unicast solicitation, на который хост должен ответить Neighbor Advertisement сообщением.
Gratuitous Gratuitous ARP’ы уступили своё место Duplicable Address Detection.
Автоконфигурация
Кроме statefull (DHCPv6) в IPv6 имеется также stateless автоконфигурация, последняя позволяет хостам автоматически получать IPv6 адреса в сети без DHCP сервера.
- Могут использоваться одновременно оба вида автоконфигурации, например stateless для получения IPv6 адреса и statefull (DHCPv6) для получения DNS-адресов и др. доп. параметров, которые нельзя передать с помощью stateless протокола;
Роутеры могут получать конфигурацию только посредством statefull-протокола;
Все интерфейсы имеют как минимум один адрес — link-local, автоопределение которого возможно без наличия роутера вообще;
stateless определение адреса возможно только при наличии роутера рассылающего RA;
statefull определение возможно только при наличии в сети DHCP сервера.
Возможны следующие состояния адреса на протяжении его жизненного цикла:
- Tentative — Адрес ещё проверяется на уникальность;
Valid — Траффик на этот адрес будет получатся нодом, делится на 2 подсостояния:
Prefered state — Основное состояние, неограниченное использование адреса;
Deprecated state — Адрес ещё можно использовать для старых соединений, но нельзя создавать новые соединения;
Invalid — Адрес нельзя использовать для получения/отправки пакетов.
DNS
Этому моменту в документации по IPv6 уделено достаточно мало внимания, однако судя по количеству RFC на эту тему, изменения колоссальны.
Для полноценной поддержки IPv6 в DNS систему было введено множество изменений (RFC3152, RFC3226, RFC3363) и всё равно остаётся некоторое количество нерешённых проблем (RFC4472) основная из которых, по моему, — это наличие двух стандартов A6 и AAAA записей, плюсы и минусы каждого из них описаны в RFC3364. Если вкратце, то A6 предоставляет большую гибкость и меньшую зависимость зоны от префикса, а AAAA являются лишь частным случаем A6 с длинной префикса 0.
Для минимальной поддержки IPv6 требуется только одна AAAA запись. Также может потребоваться наличие PTR записи. Кстати, обратные DNS записи для IPv6 выглядят ужасающе. Так, например, обратка для адреса 4321:0:1:2:3:4:567:89ab будет выглядеть как b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.ARPA.
(для генерации обраток рекомендую юзать всё туже sipcalc с ключом -r)
Jumbograms
В IPv4 размер пакетов ограничен 64 килобайтами полезной нагрузки. В IPv6 появилась возможность обходить это ограничение за счет использования так называемых джамбограмм, которые позволяют использовать пакеты размером до 4 гигабайт.