iPv6 (англ. Internet Protocol version 6) — новая версия протокола IP, призванная решить проблемы, с которыми столкнулась предыдущая версия (IPv4) при её использовании в Интернете, за счёт использования длины адреса 128 бит вместо 32. В настоящее время протокол IPv6 уже используется в нескольких сотнях сетей по всему миру (более 1600 сетей на март 2009), но пока ещё не получил столь широкого распространения в Интернете, как IPv4. В России практически не используется. Протокол был разработан IETF.
По прогнозам, после того, как адресное пространство в IPv4 закончится (предположительно 2011—2012 г.), два стека протоколов — IPv6 и IPv4 будут использоваться параллельно (англ. dual stack), с постепенным увеличением доли трафика IPv6 по сравнению с IPv4. Такая ситуация станет возможной из-за наличия огромного количества устройств, в том числе устаревших, не поддерживающих IPv6 и требующих специального преобразования для работы с устройствами, использующими только IPv6.
Пропагандисты IPv6 утверждают, что новый протокол обеспечивает 5·1028 адресов на каждого жителя Земли. Это не так — столь огромное адресное пространство сделано ради иерархичности адресов (это упрощает маршрутизацию) и большая его часть в принципе не будет задействована. Тем не менее, увеличенное пространство адресов сделает NAT необязательным.
Из IPv6 убраны вещи, усложняющие работу маршрутизаторов:
Маршрутизаторы больше не разбивают пакет на части (возможно разбиение пакета с передающей стороны). Соответственно оптимальный MTUпридётся искать через Path MTU discovery. Для лучшей работы протоколов, требовательных к потерям, минимальный MTU поднят до 1280 байтов. Информация о разбиении пакетов вынесена из основного заголовка в расширенные;
Исчезла контрольная сумма. С учётом того, что канальные (Ethernet) и транспортные (TCP) протоколы тоже проверяют корректность пакета, контрольная сумма на уровне IP воспринимается как излишняя. Тем более каждый роутер уменьшает hop limit на единицу, что в IPv4 приводило к пересчёту суммы.
Несмотря на огромный размер адреса IPv6, благодаря этим улучшениям заголовок пакета удлинился всего лишь вдвое: с 20 до 40 байт.
Улучшения IPv6 по сравнению с IPv4:
На сверхскоростных сетях возможна поддержка огромных пакетов (джамбограмм) — до 4 гигабайт;
Time to Live переименовано в Hop limit;
Появились метки потоков и классы трафика;
Появилось многоадресное вещание;
Протокол IPSec из желательного превратился в обязательный.
Введение в протоколе IPv6 поля «Метка потока» позволяет значительно упростить процедуру маршрутизации однородного потока пакетов. Поток — это последовательность пакетов, посылаемых отправителем определённому адресату. При этом предполагается, что все пакеты данного потока должны быть подвергнуты определённой обработке. Характер данной обработки задаётся дополнительными заголовками.
Допускается существование нескольких потоков между отправителем и получателем. Метка потока присваивается узлом-отправителем путём генерации псевдослучайного 20-битного числа. Все пакеты одного потока должны иметь одинаковые заголовки, обрабатываемые маршрутизатором.
При получении первого пакета с меткой потока маршрутизатор анализирует дополнительные заголовки, выполняет предписанные этими заголовками функции и запоминает результаты обработки (адрес следующего узла, опции заголовка переходов, перемещение адресов в заголовке маршрутизации и т. д.) в локальномкэше. Ключом для такой записи является комбинация адреса источника и метки потока. Последующие пакеты с той же комбинацией адреса источника и метки потока обрабатываются с учётом информации кэша без детального анализа всех полей заголовка.
Время жизни записи в кэше составляет не более 6 секунд, даже если пакеты этого потока продолжают поступать. При обнулении записи в кэше и получении следующего пакета потока, пакет обрабатывается в обычном режиме и для него происходит новое формирование записи в кэше. Следует отметить, что указанное время жизни потока может быть явно определено узлом отправителем с помощью протокола управления или опций заголовка переходов, и может превышать 6 секунд.
Обеспечение безопасности в протоколе IPv6 осуществляется с использованием протокола IPSec, поддержка которого является обязательной для данной версии протокола.
Приоритезация пакетов обеспечивается маршрутизаторами на основе первых шести бит поля Traffic Class. Первые три бита определяют класс трафика, оставшиеся биты определяют приоритет удаления. Чем больше значение приоритета, тем выше приоритет пакета.
Разработчики IPv6 рекомендуют использовать для определённых категорий приложений, следующие коды класса трафика:
Класс трафика |
Назначение |
---|---|
0 |
Нехарактеризованный трафик |
1 |
Заполняющий трафик (сетевые новости) |
2 |
Несущественный информационный трафик (электронная почта) |
3 |
Резерв |
4 |
|
5 |
Резерв |
6 |
Интерактивный трафик (Telnet, X-terminal, SSH) |
7 |
Управляющий трафик (Маршрутная информация, SNMP) |
Существуют различные типы адресов IPv6: одноадресные (Unicast), групповые (Anycast) и многоадресные (Multicast).
Адреса типа Unicast хорошо всем известны. Пакет, посланный на такой адрес, достигает в точности интерфейса, который этому адресу соответствует.
Адреса типа Anycast синтаксически неотличимы от адресов Unicast, но они адресуют группу интерфейсов. Пакет, направленный такому адресу, попадёт в ближайший (согласно метрике маршрутизатора) интерфейс. Адреса Anycast могут использоваться только маршрутизаторами.
Адреса типа Multicast идентифицируют группу интерфейсов. Пакет, посланный на такой адрес, достигнет всех интерфейсов, привязанных к группе многоадресного вещания.
Широковещательные адреса IPv4 (обычно xxx.xxx.xxx.255) выражаются адресами многоадресного вещания IPv6.
Отступ в байтах |
|
0 |
1 |
2 |
3 |
||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Отступ в битах |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
0 |
0 |
Version |
Traffic Class |
Flow Label |
|||||||||||||||||||||||||||||
4 |
32 |
Payload Length |
Next Header |
Hop Limit |
|||||||||||||||||||||||||||||
8 |
64 |
Source Address |
|||||||||||||||||||||||||||||||
C |
96 |
||||||||||||||||||||||||||||||||
10 |
128 |
||||||||||||||||||||||||||||||||
14 |
160 |
||||||||||||||||||||||||||||||||
18 |
192 |
Destination Address |
|||||||||||||||||||||||||||||||
1C |
224 |
||||||||||||||||||||||||||||||||
20 |
256 |
||||||||||||||||||||||||||||||||
24 |
288 |
Описание полей:
Version: версия протокола; для IPv6 это значение равно 6 (значение в битах — 0110).
Traffic class: приоритет пакета (8 бит). Это поле состоит из двух значений. Старшие 6 бит используются DSCP для классификации пакетов.[1][2]Оставшиеся два бита используются ECN для контроля перегрузки.[3]
Flow label: метка потока (см. метки потоков).
Payload length: в отличие от поля Total length в протоколе IPv4 данное поле не включает заголовок пакета (16 бит). Максимальный размер, определённый размером поля, — 64 Кбайта. При большем размере может использоваться Jumbo payload[4].
Next header: задаёт тип расширенного заголовка (англ. IPv6 extension), который идёт следующим. В последнем расширенном заголовке поле Next headerзадаёт тип транспортного протокола (TCP, UDP и т. д.)
Hop limit: аналог поля time to live в IPv4 (8 бит).
Source Address и Destination Address: адрес отправителя и получателя соответственно; по 128 бит.
Заголовок |
Тип |
Размер |
Описание |
RFC |
---|---|---|---|---|
Hop-By-Hop Options |
0 |
- |
Содержит указания для всех устройств на пути следования пакета. |
|
Routing |
43 |
- |
Позволяет отправителю определять список узлов, которые пакет должен пройти. |
|
Fragment |
44 |
64 бита |
Заголовок содержит информацию по фрагментации пакета. |
|
Authentication Header (AH) |
51 |
- |
см. IPsec |
|
Encapsulating Security Payload (ESP) |
50 |
- |
см. IPsec |
|
Destination Options |
60 |
- |
Опции, который должны обрабатываться только получателем. |
|
No Next Header |
59 |
0 |
Определяет отсутствие следующего заголовка. Данные, следующие за этим заголовком должны игнорироваться и передаваться без изменений (в случае форвардинга). |
В случае если используется несколько заголовков расширений, RFC 1883 рекомендует следующий порядок их следования:
IPv6 заголовок
Hop-by-Hop Options
Destination Options
Routing
Fragment
Authentication
Encapsulating Security Payload
Destination Options
заголовок более высокого уровня (например TCP)
Адреса IPv6 отображаются как восемь групп по четыре шестнадцатеричные цифры, разделённые двоеточием. Пример адреса:
2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d
Если одна или более групп подряд равны 0000, то они могут быть опущены и заменены на двойное двоеточие (::). Например, 2001:0db8:0000:0000:0000:0000:ae21:ad12 может быть сокращён до 2001:db8::ae21:ad12, или 0000:0000:0000:0000:0000:0000:ae21:ad12 может быть сокращён до ::ae21:ad12. Сокращению не могут быть подвергнуты 2 разделённые нулевые группы из-за возникновения неоднозначности.
При использовании IPv6-адреса в URL необходимо заключать адрес в квадратные скобки:
http://[2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d]/
Если необходимо указать порт, то он пишется после скобок:
http://[2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d]:8080/
IPv6 адрес |
Длина префикса (биты) |
Описание |
Заметки |
---|---|---|---|
:: |
128 |
— |
см. 0.0.0.0 в IPv4 |
::1 |
128 |
loopback адрес |
см. 127.0.0.1 в IPv4 |
::xx.xx.xx.xx |
96 |
встроенный IPv4 |
Нижние 32 бита это адрес IPv4. Также называется IPv4 совместимым IPv6 адресом. Устарел и больше не используется. |
::ffff:xx.xx.xx.xx |
96 |
Адрес IPv6, отображенный на IPv4 |
Нижние 32 бита это адрес IPv4. Для хостов, не поддерживающих IPv6. |
2001:db8:: |
32 |
Документирование |
Зарезервирован для примеров в документации в rfc3849 |
fe80:: — febf:: |
10 |
Аналог 169.254.0.0/16 в IPv4 |
|
fec0:: — feff:: |
10 |
site-local |
Помечен как устаревший в rfc3879 |
fc00:: |
7 |
Unique Local Unicast |
Пришёл на смену Site-Local rfc4193 |
ffxx:: |
8 |
|
|
001 (основание 2) |
3 |
global unicast |
Все global unicast адреса присваиваются из этого пула. Первые три бита 001. |
IPsec (сокращение от IP Security) — набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение подлинности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет.
RFC 2401 (Security Architecture for the Internet Protocol) — Архитектура защиты для протокола IP.
RFC 2402 (IP Authentication header) — Аутентификационный заголовок IP.
RFC 2403 (The Use of HMAC-MD5-96 within ESP and AH) — Использование алгоритма хэширования MD-5 для создания аутентификационного заголовка.
RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and AH) — Использование алгоритма хэширования SHA-1 для создания аутентификационного заголовка.
RFC 2405 (The ESP DES-CBC Cipher Algorithm With Explicit IV) — Использование алгоритма шифрования DES.
RFC 2406 (IP Encapsulating Security Payload (ESP)) — Шифрование данных.
RFC 2407 (The Internet IP Security Domain of Interpretation for ISAKMP) — Область применения протокола управления ключами.
RFC 2408 (Internet Security Association and Key Management Protocol (ISAKMP)) — Управление ключами и аутентификаторами защищенных соединений.
RFC 2409 (The Internet Key Exchange (IKE)) — Обмен ключами.
RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) — Нулевой алгоритм шифрования и его использование.
RFC 2411 (IP Security Document Roadmap) — Дальнейшее развитие стандарта.
RFC 2412 (The OAKLEY Key Determination Protocol) — Проверка аутентичности ключа.
IPsec является неотъемлемой частью IPv6 — интернет-протокола следующего поколения, и необязательным расширением существующей версии интернет-протокола IPv4. Первоначально протоколы IPsec были определены в RFC с номерами от 1825 до 1827, принятых в 1995 году. В 1998 году были приняты новые редакции стандартов (RFC с 2401 по 2412), несовместимые с RFC 1825—1827. В 2005 году была принята третья редакция, незначительно отличающаяся от предыдущей.
Протоколы IPsec работают на сетевом уровне (уровень 3 модели OSI). Другие широко распространённые защищённые протоколы сети Интернет, такие как SSLи TLS, работают на транспортном уровне (уровни OSI 4 — 7). Это делает IPsec более гибким, поскольку IPsec может использоваться для защиты любых протоколов базирующихся на TCP и UDP. В то же время увеличивается его сложность из-за невозможности использовать протокол TCP (уровень OSI 4) для обеспечения надёжной передачи данных.
IPsec-протоколы можно разделить на два класса: протоколы отвечающие за защиту потока передаваемых пакетов и протоколы обмена криптографическими ключами. На настоящий момент определён только один протокол обмена криптографическими ключами — IKE (Internet Key Exchange) — и два протокола, обеспечивающих защиту передаваемого потока: ESP (Encapsulating Security Payload — инкапсуляция зашифрованных данных) обеспечивает целостность и конфиденциальность передаваемых данных, в то время как AH (Authentication Header — аутентифицирующий заголовок) гарантирует только целостность потока (передаваемые данные не шифруются).
Протокол IPSec включает криптографические методы, удовлетворяющие потребности управления ключами на сетевом уровне безопасности. Протокол управления ключами Ассоциации безопасности Интернет (Internet Security Association Key Management Protocol — ISAKMP) создает рамочную структуру для управления ключами в сети Интернет и предоставляет конкретную протокольную поддержку для согласования атрибутов безопасности. Само по себе это не создает ключей сессии, однако эта процедура может использоваться с разными протоколами, создающими такие ключи (например, с Oakley), и в результате мы получаем полное решение для управления ключами в Интернет. Протокол определения ключей Oakley Key Determination Protocol пользуется гибридным методом Диффи-Хеллмана, чтобы создать ключи сессии Интернет для центральных компьютеров и маршрутизаторов. Протокол Oakley решает важную задачу обеспечения полной безопасности эстафетной передачи данных. Он основан на криптографических методах, прошедших серьезное испытание практикой. Полная защита эстафетной передачи означает, что если хотя бы один ключ раскрыт, раскрыты будут только те данные, которые зашифрованы этим ключом. Что же касается данных, зашифрованных последующими ключами, они останутся в полной безопасности. Протоколы ISAKMP и Oakley были совмещены в рамках гибридного протокола IKE — Internet Key Exchange. Протокол IKE, включающий ISAKMP и Oakley, использует рамочную структуру ISAKMP для поддержки подмножества режимов обмена ключами Oakley. Новый протокол обмена ключами обеспечивает (в виде опции) полную защиту эстафетной передачи данных, полную защиту ассоциаций, согласования атрибутов, а также поддерживает методы аутентификации, допускающие отказ от авторства и не допускающие такого отказа. Этот протокол может, к примеру, использоваться для создания виртуальных частных сетей (VPN) и для того, чтобы предоставить пользователям, находящимся в удаленных точках (и пользующимся динамически распределяемыми адресами IP), доступ к защищенной сети.
Протоколы защиты передаваемого потока могут работать в двух режимах — в транспортном режиме и в режиме туннелирования. При работе в транспортном режиме IPsec работает только с информацией транспортного уровня, в режиме туннелирования — с целыми IP-пакетами.
IPsec-трафик может маршрутизироваться по тем же правилам, что и остальные IP-протоколы, но, так как маршрутизатор не всегда может извлечь информацию, характерную для протоколов транспортного уровня, то прохождение IPsec через NAT-шлюзы невозможно. Для решения этой проблемы IETF определила способ инкапсуляции ESP в UDP, получивший название NAT-T (NAT traversal).
IPsec можно рассматривать как границу между внутренней (защищённой) и внешней (незащищённой) сетью. Эта граница может быть реализована как на отдельном хосте, так и на шлюзе, защищающем локальную сеть. Заголовок любого пакета, проходящего через границу, анализируется на соответствие политикам безопасности, то есть критериям, заданным администратором. Пакет может быть либо передан дальше без изменений, либо уничтожен, либо обработан с помощью протоколов защиты данных. Для защиты данных создаются так называемые SA (Security Associations) — безопасные соединения, представляющие собой виртуальные однонаправленные каналы для передачи данных. Для двунаправленной связи требуется два SA.
Параметры политик безопасности и безопасных соединений хранятся в двух таблицах: базе данных политик безопасности (SPD — Security Policy Database) и базе данных безопасных соединений (SAD — Security Association Database). Записи в SPD определяют в каких случаях нужно включать шифрование или контроль целостности, в то время как в SAD хранятся криптографические ключи, которые будут использованы для шифрования или подписи передаваемых данных. Если согласно SPD передаваемый пакет должен быть зашифрован, но в SAD нет соответствующего SA, реализация IPsec по протоколу IKE согласовывает с другой стороной создание нового SA и его параметры.
RFC 4301 дополнительно определяет третью таблицу — базу данных для авторизации узлов (PAD, Peer Authorization Database), предназначенную для хранения сведений об узлах, которым разрешено создавать SA с данным узлом и о допустимых параметрах этих SA.
Существует два режима работы IPsec: транспортный режим и туннельный режим.
В транспортном режиме шифруется (или подписывается) только информативная часть IP-пакета. Маршрутизация не затрагивается, так как заголовок IP пакета не изменяется (не шифруется). Транспортный режим как правило используется для установления соединения между хостами. Он может также использоваться между шлюзами, для защиты туннелей, организованных каким-нибудь другим способом (IP tunnel, GRE и др.).
В туннельном режиме IP-пакет шифруется целиком. Для того, чтобы его можно было передать по сети, он помещается в другой IP-пакет. По существу, это защищённый IP-туннель. Туннельный режим может использоваться для подключения удалённых компьютеров к виртуальной частной сети или для организации безопасной передачи данных через открытые каналы связи (например, Интернет) между шлюзами для объединения разных частей виртуальной частной сети.
Режимы IPsec не являются взаимоисключающими. На одном и том же узле некоторые SA могут использовать транспортный режим, а другие — туннельный