- •Стеки сетевых протоколов Семиуровневая модель osi
- •Уровни модели osi
- •Инкапсуляция и обработка пакетов
- •Стек протоколов tcp/ip
- •Уровень приложений
- •Транспортный уровень
- •Межсетевой уровень и протокол ip
- •Уровень доступа к среде передачи
- •Протокол ip Функции протокола ip
- •Классовая модель
- •Бесклассовая модель (cidr)
- •Запись адресов в бесклассовой модели
- •Маршрутизация
- •Пример маршрутизации
- •Пример подключения локальной сети организации к Интернет
- •Маршрутизатор или шлюз?
- •Создание статических маршрутов
- •Динамическая маршрутизация
- •Формат заголовка ip-дейтаграммы
- •Фрагментация дейтаграмм
- •Обсуждение фрагментации
- •Опции ip
- •Опции “Loose/Strict Source Routing”
- •Протокол icmp
- •Протокол arp
- •Arp для дейтаграмм, направленных в другую сеть
- •Протокол iPv6 (Internet Protocol Version 6)
- •Введение в iPv6
- •Узлы, маршрутизаторы хосты и интерфейсы
- •Связи, соседи, mtu канала и адреса уровня связи
- •Одноадресные (unicast), групповые (multicast) и адреса рассылки до первого получателя (anycast)
- •Адресация iPv6 Текстовое представление iPv6-адресов
- •Адреса одноадресной рассылки
- •Зарезервированные адреса одноадресной рассылки
- •Глобальные адреса провайдеров
- •Локальные адреса одноадресной рассылки
- •IPv6-адреса с вложенными iPv4-адресами
- •Адреса рассылки до первого получателя
- •Групповые адреса
- •Обнаружение соседа (neighbor discovery)
- •Методы обнаружения маршрутизаторов
- •Обнаружение хоста
- •Формат заголовка iPv6 и механизмы маршрутизации
- •Дополнительный заголовок Hop-by-Hop
- •Заголовок Destination Options
- •Заголовок Маршрутизации (Routing)
- •Заголовок Фрагмента (Fragment)
- •Заголовок Проверка подлинности (Authentication)
- •Механизмы перехода
- •Поддержка двух стеков протоколов
- •Туннелирование iPv6 через iPv4
Заголовок Проверка подлинности (Authentication)
Заголовок Проверка подлинности (Authentication), обеспечивающий проверку источника данных и целостность данных, может быть использован как самостоятельно, так и совместно с заголовком Инкапсуляции с обеспечением безопасности полезной нагрузки (Encapsulating Security Payload, ESP). Однако заголовок Проверка подлинности не обеспечивает шифрование данных, в IPv6 за это отвечает заголовок ESP. Форматы заголовков Проверка подлинности и ESP описаны в RFC 2402 и 2406. Значения «51» и «50» в поле Next Header предыдущего заголовка указывают соответственно на типы заголовков Проверка подлинности и Инкапсуляция с обеспечением безопасности полезной нагрузки *.
Поле Длины нагрузки (Payload Length) длиной 8 битов в заголовке Проверка подлинности определяет размер этого заголовка в 32-битных словах. Поле Резерв (Reserved) длиной 16 битов не используется и должно иметь значение «0». Поле Индекс Параметра Безопасности (Security Parameters Index, SPI) содержит произвольное 32-битное значение. Совместно с адресом узла назначения и протоколом безопасности, при согласовании узлов, это значение однозначно определяет сопоставление безопасности пакета. Поле Номер последовательности (Sequence Number) длинной 32 бита увеличивается на единицу для каждого пакета, значение этого счетчика не может быть уменьшено без отправления и получения узлами нового сопоставления безопасности пакета. Длина данных проверки подлинности может варьироваться, но должна быть кратной 64 битам и, хотя и может содержать любые значения, но по требованиям безопасности эти данные формируются на основе значений Длины полезной нагрузки (Payload Length) и Значение проверки целостности (Integrity Check Value).
Рисунок 9-12 - Формат заголовка Проверка подлинности
Механизмы перехода
Механизмы для перехода с IPv4 на IPv6 хотя и определены в RFC 1933, но продолжают разрабатываться в настоящее время. Основная цель процесса перехода состоит в успешном сосуществовании протоколов двух версий, пока IPv4 будет использоваться, если вообще, когда-либо он будет исключен из употребления. Планы перехода разделены на две основные группы: поддержка двух стеков протоколов и использование IPv6 с помощью IPv4 туннелирования.
Дополнительная информация. Механизмы перехода от IPv4 к IPv6 определены в RFC 1933
Поддержка двух стеков протоколов
Простейший метод обеспечения функциональности IPv6 состоит в разрешении поддержки двух стеков протоколов каждым узлом. Узлы, использующие два стека протоколов, могут взаимодействовать через любой из стеков. При этом такие узлы могут использовать адреса IPv4 и IPv6, соответствующие каждому протоколу. Это даже не является требованием реализации, поскольку два адреса совершенно независимы. Такие узлы также могут выполнять туннелирование IPv6 через IPv4. Поскольку каждый стек полностью функционален, узлы могут конфигурировать свои IPv6-адреса как посредством автоконфигурирования без возможности изменения адреса, так и с помощью DHCP, при этом для IPv4-адресов использовать любой из современных методов конфигурирования.
Туннелирование iPv6 через iPv4
Второй метод реализации IPv6 в окружении IPv4 заключается в туннелировании пакетов IPv6 внутри пакетов IPv4. Эти узлы могут включать свои IPv4 адреса в IPv6-адреса, совместимые с IPv4-адресами, используя предшествующий IPv4 адресу 96-битный префикс «0:0:0:0:0:0». В случае применения этого метода не требуется немедленная замена маршрутизаторов в сети на совместимые с IPv6, но серверы DNS в такой смешанной сети должны поддерживать протоколы обеих версий. Для помощи в достижении этой цели, адресам IPv6 определен новый тип записи DNS «АААА».
Безусловно, поддержка протокола IPv4 будет продолжаться еще несколько лет. Тем не менее, ему недоступна функциональность IP, которую предоставляет IPv6 за счет расширяемости и богатых конфигурационных возможностей. Протокол быстро достигает завершенного состояния. Когда протокол IPv6 будет окончательно развернут, он сможет предоставить примерно 1500 IP-адресов для каждого квадратного ангстрема (10-10м) на планете, отлично обеспечивая любые сетевые потребности, что ранее считалось научной фантастикой.
