Адресация IPv6

4. Верифицировать подпись с помощью общедоступного ключа.

Расширение DNS для поддержки IP-версии 6 (DNS Extensions to Support IP Version 6. S. Thomson. RFC-1886)

Двухстековая стратегия удобна для перехода от одной технологии к другой, но такая схема обладает уязвимостями обоих протоколов (IPv4 и IPv6), плюс новые уязвимости, связанные с непреднамеренными взаимодействиями между ними. В случае двухстекового варианта машина может поддерживать как IPv4, так и IPv6. Смотри RFC-4554 (Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks). Каждый стек отвественен за конфигурирование своих адресов. Двухстековая схема требует больших сетевых ресурсов.

Документ RFC 4852 (IPv6 Enterprise Network Analysis - IP Layer 3 Focus), содержит хорошие советы относительно работы с двухстековыми системами. RFC 4942 (IPv6 Transition/Coexistence Security Considerations), содержит важные специфические детали совместного использования протоколов:

· Организации должны использовать согласованные политики безопасности как для IPv4, так и для IPv6 (включая firewalls фильтры пакетов).

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

· Так как работают оба протокола, может происходить непредусмотренное туннелирование между машинами. В результате может нарушаться политика безопасности.

· Организации должны обновлять IDS и IPS-системы, firewalls, мониторинг, журналирование и аудит, чтобы обеспечить безопасность IPv6 на уровне IPv4. Если туннелированным пакетам разрешено входить в сеть, firewall или системы IDS/IPS должны обеспечивать глубокий просмотр этих пакетов .

· При переходе на IPv6 параметры системы безопасности могут деградировать.

18.2 Иерархическая адресация для целей сегментации безопасности

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

IPv6 отличается от IPv4 не только идентификацией машины, но и регионального провайдера на основе глобальной иерархии, задаваемой RIR (Regional Internet Registry). Сетевой префикс адреса идентифицирует RIR и адрес ISP. IPv6 допускает использование 16 бит субсети (/48) для SLA (Site-Level Aggregation Identifier). Организации могут использовать эти 16 бит для построения иерархии сайта. Предлагаемые методы построения субсетей включают в себя:

· Последовательная нумерация субсетей

· VLAN номер

· Номер AS

· Номер субсети IPv4

· Физическое положение (здание, город, страна и т.д.)

· Функциональный модуль (человеческие ресурсы, операции, финансы и т.д.

Целью формирования адресной иерархии является предоставление организации возможности логически группировать ресурсы и упростить администрирование и решение проблем безопасности.

Оборудование Firewall и IDS, несконфигурированное для распознавания трафика IPv6, может его легко пропускать некоторые виды атак. Хакеры часто используют IPv6, чтобы обойти средства защиты IPv4. Зарегистрированы уже атаки и средств автоконфигурации IPv6. Современные ОС делают доступным IPv6 по-умолчанию, что отрывает дополнительное окно уязвимостей. Чтобы закрыть эти возможности для хакеров следует предпринять следующее:

· Выявлять и блокировать IPv6-оборудование в сетях IPv4.

· Блокировать трафик IPv6 и соответствующе туннели на периметре сети.

· Включить политику использования IPv6 в план безопасности организации.

На первом этапе для обеспечения безопасности можно отказаться от процедур автоконфигурации. Вообще перед началом внедрения IPv6 нужно сформировать последовательность шагов. Одним из пунктов на каждом из этапов должна быть безопасность. Смотри также [2] и [3].

18.3 Туннелирование

На верхнем уровне туннели представляют собой сконфигурированные или автоматические туннели. Сконфигурированные туннели требуют вмешательства системного администратора для задания своих конечных точек. В случае автоматических туннелей узлы определяют конечные точки туннелей сами. Обычно, организация для своей инфраструктуры использует сконфигурированные туннели. Машины используют автоматические туннели для передачи данных назад в IPv4 или для островов IPv6. Сконфигурированные туннели статичны по своей природе, а автоматические туннели являются динамическими. На рис. 4.4.1.1.32B показан общий случай, когда две машины могут работать друг с другом через сеть IPv4.



Рис. 4.4.1.1.32B. Пример сетевого туннелирования IPv6 поверх IPv4

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

Рис. 4.4.1.1.32C. Туннели IPv6 поверх IPv4, прозрачные для инфраструктуры IPv4

Существующая поддержка записи адресов Интернет в DNS (Domain Name System) [1,2] не может быть легко расширена для поддержки IPv6-адресов [3], так как приложение предполагает, что адресный запрос вернет только 32-битовый IPv4-адрес.

Для того чтобы запоминать IPv6-адреса, определены следующие расширения:

· Определен новый тип ресурсной записи, для того чтобы установить соответствие между именами доменов и адресами IPv6.

· Определен новый домен, предназначенный для обработки запросов по новым адресам.

· Существующие запросы, которые выполняют выявление IPv4-адресов, переопределены для получения как IPv4, так и IPv6-адресов.

Изменения выполнены так, чтобы быть совместимыми с имеющимся программным обеспечением. Существующая поддержка IPv4-адресов сохраняется. Переходное состояние сосуществования IPv4 и IPv6-адресов обсуждается в [4]. Проблема транспортировки IPv6 через IPv4 (6over4) рассмотрена в RFC-2529 (Transmission of IPv6 over IPv4 Domains without Explicit Tunnels).



19. Расширение DNS для поддержки IP версии 6

19.1 Определение новой ресурсной записи и домена

Определен новый тип ресурсной записи для хранения IPv6-адреса ЭВМ. Если ЭВМ имеет более одного IPv6-адреса, тогда используется более одной такой ресурсной записи.

Тип ресурсной записи aaaa является специфическим для класса Интернет и служит для записи одного IPv6-адреса. Код типа равен 28 (десятичное).

128-битовый IPv6-адрес записывается в информационной части ресурсной записи АААА, придерживаясь порядка байт, используемого в сети (старший байт первый).

Запрос aaaa для конкретного имени домена в классе Интернет возвращает в качестве отклика все ресурсные записи, соответствующие ресурсной секции АААА. Запрос типа aaaa не выполняет никакой дополнительной обработки этой секции.

Текстовое представление информационной секции ресурсной записи АААА, используемое в файле базы данных имеет формат, описанный в [3], а также в текущем разделе.

Определен специальный домен, который предназначен для установления соответствия между именами и IPv6-адресами. Домен имеет имя ip6.int.

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

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.int.

Проблемы маршрутизации для IPv6 подробно рассмотрены в докладе "Router Security Guidance Activity of the Systems and Network Attack Center (SNAC)" [5], где разобраны могие аспекты безопасности.

19.2 Модификации существующих типов запроса

Все существующие типы запросов, которые выполняют дополнительную обработку секции a, т.е. типы запросов, относящиеся к серверу имен (ns), почтовому серверу (MX) и почтовому ящику (MB), для осуществления обработки как секции типа a, так и типа АААА должны быть переопределены. Эти новые определения означают, что сервер имен, обрабатывая один из указанных запросов, должен добавить в соответствующую секцию запроса какие-то подходящие адреса IPv4 и какие-то адреса IPv6 доступные локально.



20. Протокол управляющих сообщений (ICMPv6) для спецификации IPv6 (RFC-1885)

Протокол IPv6 является новой версией IP. IPv6использует протокол управляющих сообщений (ICMP) так, как это определено для IPv4 [RFC-792], но с некоторым количеством изменений. Протокол подключения к группам (IGMP), специфицированный для IPv4 [RFC-1112] был также пересмотрен и включен в протокол ICMP для IPv6. Результирующий протокол называется ICMPv6, и имеет код следующего заголовка 58.

20.1 ICMPv6 (ICMP для IPv6)

ICMPv6 используется узлами IPv6 для сообщений об ошибках при обработке пакетов, и для выполнения других функций уровня Интернет, таких как диагностика (ICMPv6 "ping") и сообщение об участии в мультикастинг группах. Протокол ICMPv6 является интегрированной частью IPv6 и должен реализовываться каждым узлом, поддерживающим IPv6.

20.2 Общий формат сообщений

Сообщения ICMPv6 образуют два класса: сообщения об ошибках и информационные сообщения. Сообщения об ошибках идентифицируются по нулю в старшем бите полятип. Таким образом, сообщения об ошибках могут иметь код поля тип от 0 до 127; информационные сообщения имеют коды поля тип от 128 до 255.

В данном документе определены форматы для следующих сообщений ICMPv6:

Сообщения об ошибках ICMPv6:

1 destination unreachable (место назначения недоступно)

2 packet too big (пакет слишком велик)

3 time exceeded (время превышено)

4 parameter problem (проблема с параметрами)

Информационные сообщения ICMPv6:

128 echo request (Запрос эхо)

129 echo reply (Эхо-отклик)

130 group membership query (запрос участия в группе)

131 group membership report (отчет об участии в группе)

132 group membership reduction (сокращение числа участников в группе)

Каждое сообщение ICMPv6 начинается с заголовка IPv6, за которым следует нуль или более заголовков расширения IPv6. Заголовок ICMPv6 идентифицируется кодом следующего заголовка 58 в предыдущем заголовке. (Заметим: этот код отличается от значения, принятого для ICMP IPv4.)

Сообщения ICMPv6 имеют следующий общий формат (рис. 4.4.1.1.33):

Рис. 4.4.1.1.33. Общий формат заголовка сообщений ICMPv6

Поле тип указывает на тип сообщения. Его значение определяет формат последующих данных.

Поле код зависит от типа сообщения. Оно используется для создания дополнительного уровня структуризации сообщения. Поле контрольная сумма используется для обнаружения повреждений сообщения ICMPv6 и заголовка IPv6.

Узел отправитель сообщения ICMPv6 должен определить IPv6-адреса отправителя и получателя до вычисления контрольной суммы. Если узел имеет более одного уникастного адреса, то он должен выбрать адрес отправителя следующим образом:

a. Если сообщение является откликом на сообщение, полученное по одному из уникаст адресов, адресом отправителя должен стать именно этот адрес.

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

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

d. В противном случае, должна быть просмотрена таблица маршрутизации узла и выяснено, какой интерфейс должен быть использован для достижения места назначения сообщения. Уникастный адрес этого интерфейса и должен быть выбран в качестве адреса отправителя.

Контрольная сумма является 16-битным дополнением по модулю 1 суммы всего сообщения ICMPv6, начиная с поля тип сообщения ICMPv6, дополненного полями псевдозаголовка IPv6. Код поля следующий заголовок для псевдозаголовка выбирается равным 58. (Заметим: включение псевдозаголовка в контрольную сумму ICMPv6 является изменением по отношению к протоколу IPv4; обоснование причин этого см. в [IPv6]). Перед вычислением контрольной суммы поле контрольная сумма обнуляется.

Таблица 4.4.1.1.3. Сообщения об ошибках ICMPv6 и коды типа

Номер сообщения	Тип сообщения	Поле кода
1	Адресат недостижим	0 = нет маршрута до адресата 1 = Взаимодействие с адресатом административно запрещено 2 = Вне зоны достижимости для отправителя 3 = Адрес недостижим 4 = Порт недостижим 5 = Source address failed ingress/egress policy 6 = Маршрут до места назначения отвергнут
2	Пакет слишком длинен	Устанавливается равным 0 (нулю) отправителем и игнорируется получателем
3	Время истекло	0 = Превышен лимит шагов 1 = Превышено время сборки фрагментов
4	Проблема с параметрами	0 = Обнаружено ошибочное поле заголовка 1 = Обнаружен нераспознанный код следующего заголовка
100 и 101	Частные эксперименты	RFC 4443
127	Зарезервировано для расширения функций сообщений об ошибках ICMPv6	RFC 4443

Таблица 4.4.1.1.4. Информационные сообщенияICMPv6

Номер сообщения	Тип сообщения	Поле кода
128	Эхо запрос	RFC-4443. Используется для команд ping
129	Эхо отклик
130	Запрос мультикаст-слушателя	RFC-2710. Используется для управления мультикаст -группами
131	Отчет мультикаст-слушателя
132	Мультикаст-слушатель оформлен
133	Запрос маршрутизатора	RFC-4861. Используется для обнаружения соседа и автоконфигурации
134	Анонсирование маршрутизатора
135	Запрос соседа (RFC-4861)
136	Анонсирование соседа
137	Переадресация сообщения
200 и 201	Частные эксперименты	RFC-4443
255	Зарезервировано для расширения возможностей информационных сообщений ICMPv6	RFC-4443

Приложения должны следовать следующим правилам при обработке сообщений ICMPv6 (из [RFC-1122]):

a. Если получено сообщение о неизвестной ошибке ICMPv6, оно должно быть передано верхнему уровню.

b. Если получено информационное сообщение ICMPv6 неизвестного типа, оно должно быть выброшено.

c. Каждое ICMPv6 сообщение об ошибке (тип < 128) включает в себя целиком или частично IPv6 пакет, вызвавший ошибку, при условии, что сообщение об ошибке превысит 576 октетов.

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

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

e. Сообщение об ошибке ICMPv6 не должно посылаться в качестве результата получения:

(e.1) сообщения об ошибке ICMPv6, или

(e.2) пакета, направленного по IPv6 мультикаст-адресу (существует два исключения из этого правила: (1) сообщения packet too big - пакет слишком велик) - чтобы позволить скорректировать MTU прохода, и (2) сообщения parameter problem (проблема с параметрами), Код 2, оповещающий о нераспознанной опции), или

(e.3) мультикастинг-пакета канального уровня, (исключения пункта e.2 применимы и здесь), или

(e.4) широковещательного пакета канального уровня, (исключения пункта e.2 применимы и здесь), или

(e.5) пакета, чей адрес отправителя не однозначно определяет какой-то узел, например, не специфицированный адрес IPv6, мультикаст-адрес IPv6 или эникаст-адрес.

(f) Наконец, узел IPv6 должен ограничить частоту посылки сообщений об ошибке, если адресат на них не реагирует. Это ограничит загрузку канала.

Существует много способов ограничения частоты посылки сообщений, например:

(f.1) Таймерный метод. Передача сообщений производится не чаще, чем раз за указанное число T миллисекунд.

(f.2) Метод полосы пропускания. Сообщения об ошибке должны занимать не более определенной доли F полосы пропускания канала.

Ограничивающие параметры (например, T или F в вышеприведенных примерах) должны задаваться узлом со значениями по умолчанию (напр., T = 1 сек, и F = 2%, не 100%!).



20.3 Сообщения об ошибках ICMPv6

Рис. 4.4.1.1.34. Формат сообщения о недостижимости адресата

Поля IPv6:

Адрес места назначения копируется из поля адрес отправителя пакета, вызвавшего ошибку.

Поля ICMPv6:

Тип = 1

Код = 0 - нет маршрута до места назначения

1 - связь с адресатом административно запрещена

2 - не сосед

3 - адрес не достижим

4 - порт не достижим

Не используется. Это поле не используется при всех значениях поля код. Оно должно быть обнулено отправителем и игнорироваться получателем.

Описание

Сообщение адресат не достижим (destination unreachable) должно генерироваться маршрутизатором, или уровнем IPv6 узла-отправителя, в случае, когда пакет не может быть доставлен адресату не по причине перегрузки. (Сообщение ICMPv6 не должно посылаться при потере пакета из-за перегрузки).

Если причиной потери пакета является недостаток места в маршрутной таблице узла, поле код должно принять значение 0 (Заметим, что такая ошибка может произойти только при наличии в таблице маршрута по умолчанию).

Если причиной потери пакета является административный запрет, например, Firewall, поле код принимает значение 1.

Если причиной потери пакета является то, что следующий узел в маршрутной таблице не является соседом данного узла, то поле код принимает значение 2.

Если имеет место какая-то другая причина недоставки пакета, в поле код заносится значение 3.

Узел места назначения может посылать сообщение “адресат не достижим” с кодом 4, когда транспортный протокол пакета (напр., UDP) не имеет получателя, а другого метода, уведомить об этом отправителя нет.

Узел, получивший сообщение ICMPv6 “адресат не достижим” должен уведомить об этом протокол вышележащего уровня.

Рис. 4.4.1.1.35. Сообщение packet too big (пакет слишком велик)

Поля IPv6:

Адрес места назначения копируется из поля адрес отправителя пакета, вызвавшего ошибку.

Поля ICMPv6:

Тип 2

Код 0

mtu mtu следующего шага.

Описание

Сообщение packet too big (пакет слишком велик) должно посылаться маршрутизатором в ответ на получение пакета, который не может быть переадресован, из-за того, что он длиннее, чем MTU выходного канала. Информация в этом сообщении используется в качестве части процесса определения MTU прохода [RFC-1191].

Пришедшее сообщение packet too big должно быть передано протоколу верхнего уровня.

Формат сообщения о превышении времени аналогичен формату сообщения о недостижимости адресата (рис. 4.4.1.1.33).

Поля ICMPv6:

Тип 3

Код 0 - при передаче превышен лимит числа шагов

1 - превышено время восстановления сообщения из фрагментов.

Не используется. Это поле не используется при всех значениях поля код. Оно должно быть обнулено отправителем и игнорироваться получателем.

Описание

Если маршрутизатор получает пакет с предельным значением числа шагов равным нулю (hop limit = 0), или маршрутизатор после декрементации получил нулевое значение поля hop limit, он должен выбросить такой пакет и послать отправителю пакета сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным 0. Это указывает на зацикливание маршрута или на слишком малое значение поля hop limit.

Посылая сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным нулю, маршрутизатор должен рассматривать входной интерфейс, в соответствии с правилом выбора адреса отправителя (d).

Пришедшее сообщение time exceeded должно быть передано протоколу верхнего уровня.



Рис. 4.4.1.1.36. Сообщение о конфликте параметров

Поля ICMPv6:

Тип 4

Код 0 - встретилась ошибка в поле заголовка

1 - встретился неопознанный код поля следующий заголовок

2 - встретилась неопознанная опция IPv6

Указатель. Идентифицирует смещение в октетах в пакете, вызвавшем ошибку.

Указатель отмечает позицию в пакете, если размер пакета ICMPv6 не позволяет поместить его в отклик полностью, а ошибочное поле в сообщение не поместилось.

Описание

Если узел IPv6, обрабатывающий пакет, обнаруживает какую-то проблему с одним из полей заголовка или заголовков расширения, такую, что дальнейшая обработка невозможна, он должен выбросить пакет и послать сообщение ICMPv6 parameter problem (проблема с параметрами) отправителю пакета с указанием типа и позиции ошибки.

Поле указатель идентифицирует октет заголовка исходного пакета, где обнаружена ошибка. Например, сообщение ICMPv6 с полем тип = 4, полем код = 1 и полемуказатель = 40 указывает на то, что заголовок расширения IPv6, следующий за заголовком IPv6 исходного пакета содержит нераспознанный код следующего заголовка.



20.4 Информационные сообщения ICMPv6

Рис. 4.4.1.1.37. Сообщение запрос эхо

Поля IPv6:

Адрес места назначения - любой легальный IPv6-адрес

Поля ICMPv6:

Тип 128

Код 0

Идентификатор. Идентификатор, который помогает друг с другом связать запрос эхо и эхо-отклик. Может равняться нулю.

Номер по порядку

Номер по порядку имеет целью связать друг с другом запрос эхо и эхо-отклик. Может равняться нулю.

Информация. Нуль или более октетов произвольных данных.

Описание

Каждый узел должен реализовать функцию эхо-отклика ICMPv6 при получении запроса эхо. Узлу следует также предоставить пользовательский интерфейс для посылки запросов эхо и получения эхо-откликов для целей диагностики.

Формат сообщения эхо-отклик идентичен формату запроса эхо (рис. 20.5).

Поля IPv6:

Адрес места назначения копируется из поля адрес отправителя пакета запрос эхо.

Поля ICMPv6:

Тип 129

Код 0

Идентификатор. Идентификатор из исходного запроса эхо (echo request).

Номер по порядку. Номер по порядку из исходного запроса эхо.

Информация. Данные из исходного запроса эхо.

Описание

Каждый узел должен иметь встроенную функцию отклика ICMPv6, которая получает запросы эхо и посылает соответствующие эхо-отклики. Узел должен также реализовать интерфейс прикладного уровня для посылки запросов эхо и получения эхо-откликов для диагностических целей.

Адрес отправителя эхо-отклика, посылаемого в ответ на уникастный запрос эхо должен быть тем же самым, что и адрес места назначения в запросе эхо.

Эхо-отклик должен быть послан в ответ на запрос эхо, посланный по мультикастному адресу. Адрес отправителя в отклике должен быть уникастным адресом, принадлежащим интерфейсу, через который был получен мультикастный запрос эхо.

Информация, полученная в ICMPv6 сообщении запроса эхо, должна быть полостью возвращена без модификации в ICMPv6 эхо-отклике, если эхо-отклик не превысит MTU обратного прохода, в противном случае пакет укорачивается.

Оповещение верхнего уровня

Сообщения эхо-отклик должны передаваться пользовательскому интерфейсу ICMPv6, если соответствующий запрос эхо исходит не из IP-уровня.

Сообщение о членстве в группе имеет следующий формат:



Рис. 4.4.1.1.38. Сообщения участия в группе

Поля IPv6:

Адрес места назначения

В сообщении-запросе о членстве в группе запрашивается мультикаст-адрес группы.

В отчете о членстве в группе или в сообщении о сокращении членства в группе сообщается мультикаст-адрес группы.

Поле Hop Limit = 1 (предельное число шагов)

Поля ICMPv6:

Тип 130 - Запрос членства в группе

131 - Отчет о членстве в группе

132 - Сокращение членства в группе

Код 0

Максимальное время отклика

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

Не используется. Отправитель записывает нуль, получатель игнорирует.

Мультикаст-адрес

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

Описание

Сообщения ICMPv6 о членстве в группе используются для передачи информации о членстве в мультикаст-группе от узлов к их ближайшим маршрутизаторам. Подробности их использования можно найти в [RFC-1112].



Литература

[1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD13, RFC 1034, USC/Information Sciences Institute, November 1987.

[2] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

[3] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995.

[4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", Work in Progress.

[ALLOC] [Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast Address Allocation", RFC 1887, cisco Systems, December 1995

[ANYCST] [Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, BBN, November 1993.

[CIDR] [Fuller, V., Li, T., Varadhan, K., and J. Yu, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cisco, Merit, OARnet, June 1992.

[IPV6] [Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon Networks, December 1995.

[IPv6-ADDR] [Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995.

[IPv6-DISC] [Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", Work in Progress

[MULT] [Deering, S., "Host Extensions for IP multicasting", STD 5, RFC 1112, Stanford University, August 1989

[NSAP] [Carpenter, B., Editor, "Mechanisms for OSIN SAPs, CLNP and TP over IPv6", Work in Progress.

[RFC-791] [Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.

[RFC-792] [Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981

[RFC-1112] [Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989.

[RFC-1122] [Braden, R., "Requirements for Internet Hosts -Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989

[RFC-1191] [Mogul, J., and S. Deering, "Path MTU Discovery", RFC1191, DECWRL, Stanford University, November 1990.

[RFC-1661] [Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.

[RFC-1700] [Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

[RFC-1825] [Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, Naval Research Laboratory, August 1995.

[RFC-1826] [Atkinson, R., "IP Authentication Header", RFC 1826, Naval Research Laboratory, August 1995.

[RFC-1827] [Atkinson, R., "IP Encapsulating Security Protocol (ESP)", RFC 1827, Naval Research Laboratory, August 1995

[RFC-1885] [Conta, A., and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, Digital Equipment Corporation, Xerox PARC, December 1995.

[RFC-1884] [Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995

[RFC-1933] [Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan & E. Nordmark. April 1996

[RFC-1970] [Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark & W. Simpson. August 1996.

[RFC-1971] [IPv6 Stateless Address Autoconfiguration. S. Thomson & T. Narten. August 1996.

[RFC-1972] [A Method for the Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. August 1996.

[RFC-2019] [Transmission of IPv6 Packets Over FDDI. M. Crawford. October 1996.

[RFC-2030] [Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. October 1996.

[RFC-2080] [RIPng for IPv6. G. Malkin, R. Minnear. January 1997.

[RFC-2133] [Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. April 1997.

1. Guidelines for the Secure Deployment of IPv6. Recommendations of the National Institute of Standards and Technology. Sheila Frankel, Richard Graveman, John Pearce, Mark Rooks (NIST US; 188 страниц.) Достаточно полное описание самого протокола и совершенно незаменимое руководство по внедрению и конфигурированию сети с поддержкой IPv6.

2. A Profile for IPv6 in the U.S. Government - Version 1.0. Special Publication 500-267 NIST. Recommendations of the National Institute of Standards and Technology. Doug Montgomery, Stephen Nightingale, Sheila Frankel and Mark Carson

3. Malware Tunneling in IPv6. US-CERT. Статья посвящена возможностям использования легальных средств IPv6-туннелирования для вредоносных целей, а также средствам и методам противодействия угрозам.

4. THC-IPV6. Май 2005 г

5. Router Security Configuration Guide Supplement - Security for IPv6 Routers. Router Security Guidance Activity of the Systems and Network Attack Center (SNAC). Neal Ziring, 23 May 2006 Version: 1.0

Размещено на Allbest.ru