|
UP:
4.4.7 Прокси-ARP |
|
UP:
4.4.7 Прокси-ARP |
4.4.7.1 Протокол локализации соседних узлов для IPv6 (ND)
Семенов Ю.А. (ГНЦ ИТЭФ)
Протокол ND (Neighbor Discovery - RFC-4861) IPv6 функционально представляет собой комбинацию нескольких протоколов IPv4: [RDISC] (ICMP Router Discovery) и версии переадресации ICMP [ICMPv4]. В IPv4 не существует единого согласованного механизма детектирования достижимости соседнего узла, хотя в документе "Hosts Requirements" [HR-CL] специфицируются некоторые алгоритмы детектирования недоступности GW.
Машины используют протокол ND для выявления доступных маршрутизаторов, которые могут для них переадресовывать пакеты. Кроме того, узлы используют этот протокол, чтобы активно отслеживать доступность соседних узлов и изменения их МАС-адресов. Когда маршрутизатор или канал, ведущий к нему, отказывает, машина активно ищет альтернативу.
Данный протокол решает несколько проблем, относящихся к взаимодействию узлов, подключенных к общему каналу. Он определяет механизмы решения следующих проблем:
В протоколе ND определены пять разных типов ICMP-пакетов: два сообщения запроса и анонсирования маршрутизатора, два сообщения запроса и анонсирования соседа и сообщение переадресации. Соседями в ND-протоколе считаются узлы, подключенные к общему каналу непосредственно. ICMP-cообщения нужны для:
Для каналов, работающих с мультикастингом, каждый маршрутизатор периодически рассылает пакеты анонсирования маршрутизатора, уведомляя о его доступности. Машина получает анонсирования от всех маршрутизаторов и создает список доступных маршрутизаторов. Маршрутизаторы генерируют анонсирования достаточно часто, чтобы машины узнавали об их присутствии в течение нескольких минут, но этого недостаточно, чтобы своевременно детектировать отказ маршрутизатора. Такие отказы детектируются с привлечением специального алгоритма.
Анонсирование маршрутизатора содержит список префиксов, используемых для детектирования доступности канала и/или конфигурации адреса; флаги, ассоциированные с префиксами, специфицируют предполагаемые применения конкретного префикса. Машины используют анонсированные префиксы канала для формирования и поддержания списка, который используется при принятии решения, когда адрес назначения доступен непосредственно или находится за маршрутизатором. Заметим, что когда место назначения не покрывается ни одним из анонсированных префиксов, маршрутизатор может послать уведомление о переадресации отправителю, сообщая, что адрес назначения доступен непосредственно.
Анонсирования маршрутизатора (и флаги префиксов) позволяют маршрутизаторам информировать машины, как осуществлять адресную конфигурацию. Например, маршрутизаторы могут специфицировать, должны ли машины использовать DHCPv6 и/или автономную адресную конфигурацию.
Сообщения анонсирования маршрутизатора содержат также параметры Интернет, такие как предел шагов маршрута, который машина должна использовать для исходящих пакетов, и, опционно параметров канала, таких как MTU. Это облегчает задачу выбора критических параметров, которые могут быть установлены в маршрутизаторах и проложить пути для всех подключенных машин.
Узлы завершают выявление адреса путем мультикастного запроса соседа, который требует от узла-мишени прислать свой МАС-адрес. Сообщения запроса соседа используют мультикастинг, чтобы обратиться к узлу-мишени. Мишень присылает свой МАС-адрес в уникастном сообщении анонсирования соседа. Одной пары пакетов запроса-отклика достаточно инициатору и адресату для выяснения МАС-адресов друг друга; инициатор помещает свой МАС-адрес в запрос соседа.
Сообщения запроса соседа может также использоваться для детектирования дублирования МАС-адресов в сегменте. Использование сообщений запроса соседа для детектирования дублей адресов специфицировано в [ADDRCONF].
Детектирование недоступности соседа фиксирует отказ соседа или канала, ведущего к нему. Такой механизм требует позитивного подтверждения того, что пакеты, посланные соседу, действительно достигают адресата и обрабатываются корректно его IP-уровнем. Детектирование недоступности соседа использует подтверждение от двух источников. Когда возможно, протоколы верхнего уровня обеспечивают положительное подтверждение того, что соединение функционирует, то-есть, ранее присланная информация была доставлена корректно (напр., недавно полученные подтверждения). Когда положительное подтверждение не приходит, узел посылает уникастные сообщения запроса соседа, которое запрашивает анонсирование соседа в качестве подтверждения доступности следующего узла. Чтобы уменьшить ненужный трафик посылаются только контрольные сообщения соседям, которым узел активно посылает пакеты.
Кроме определения адресов процедура выявления соседа разрешает следующие ситуации:
Протокол выявления соседей IPv6 соответствует комбинации протоколов ARP, ICMP Router Discovery [RDISC], и ICMP-переадресация. В IPv4 не существует согласованных механизмов детектирования недоступности соседа, хотя документ Hosts Requirements [HR-CL] специфицирует некоторые возможные алгоритмы детектирования выхода из строя шлюза.
Протокол выявления соседа предлагает много преимуществ по сравнению с набором протоколов IPv4:
Механизм выявления соседей поддерживает каналы с различными свойствами:
| точка-точка | Выявление соседа работает с такими каналами, как с мультикастными. (Мультикастинг может быть для каналов точка-точка реализован тривиально, а интерфейсам могут быть присвоены локальные МАС-адреса). |
| мультикаст | выявление соседа реализуется через каналы, допускающие мультикастинг. |
| нешироковещательный множественный доступ (NBMA) | Переадресация, Детектирование недостижимости соседа и определение следующего шага должны реализовываться согласно RFC-4861. Выявление адреса, и механизм доставки запроса маршрутизатора и анонсирования для каналов в RFC-4861 не специфицированы . Заметим, что машины поддерживают ручную конфигурацию списка доступных маршрутизаторов, машины могут динамически воспринимать МАС-адреса своих соседей из сообщений переадресации. |
| совместно используемая среда | Сообщение переадресации моделируются в соответствии с сообщениями XRedirect в [SH-MEDIA], для того чтобы упростить использование протокола в совместно используемых каналах. |
| переменное MTU | Выявление соседей позволяет маршрутизатору специфицировать MTU канала, который используют все узлы. Все узлы должны использовать общее значение MTU (или Maximum Receive Unit), для того чтобы мультикастинг работал правильно. В противном случае при мультикастинге отправитель, который не знает, какие узлы получат пакет, не может определить минимальный размер пакета, который все получатели могут обработать. |
| асимметричная доступность | Выявление соседей детектирует отсутствие симметричной достижимости; узел исключает пути до соседа, которые не обеспечивают симметричную коннективность. |
Сообщения выявления соседа нужны для разных задач. Несколько функций реализованы чтобы позволить машинам выяснить принадлежность адреса или соответствия адресов МАС- и IP-уровней.
Машина посылает сообщение запроса маршрутизатора, для того чтобы заставить маршрутизаторы сгенерировать немедленно сообщение анонсирования. Ниже на рис.1 представлен формат такого сообщения.
Рис.1. Формат сообщения запроса маршрутизатора
IP-поля (IP-заголовок пакета):
| Адрес отправителя | IP-адрес, приписанный отправляющему интерфейсу, или неспецифицированный адрес, если адрес отправляющему интерфейсу не присвоен. |
| Адрес получателя | Обычно мультикаст адрес, соответствующий всем маршрутизаторам |
| Макс. число шагов | 255 |
Поля ICMP:
Тип=133
Код=0
Допустимые опции
МАС-адрес отправителя. МАС-адрес отправителя, если известен, не должен включаться, если адрес отправителя является не специфицированным. В противном случае, он должен быть включен на канальных уровнях, которые имеют адреса.
Маршрутизаторы периодически посылают сообщения анонсирования маршрутизатора, или откликаются на запросы маршрутизатора. На рис. 2 представлен формат сообщения анонсирования маршрутизатора.
Рис.2. Формат сообщения анонсирования маршрутизатора
IP-поля (IP-заголовок пакета):
| Адрес отправителя | Должен быть локальным МАС-адресом, присвоенным интерфейсу, который посылает сообщение. |
| Адрес получателя | Обычно адрес отправителя вызывающего запрос маршрутизатора или мультикаст-адрес, соответствующий всем маршрутизаторам. |
| Макс. число шагов | 255 |
Поля ICMP:
Тип=134
Код=0
Cur Hop Limit
8-битовое целое без знака. Значение по умолчанию, которое следует поместить в поле числа шагов IP-заголовка для исходящих пакетов. Значение нуль означает неспецифицированное значение (данным маршрутизатором).
M-бит флаг "Управляемая адресная конфигурация". Если равен 1, он указывает, что адреса доступны через DHCPv6 (Dynamic Host Configuration Protocol) [DHCPv6].
O-бит флаг "Другая конфигурация". Если =1, указывает, что существует другая информация о конфигурации, доступная через DHCPv6. Примерами такой информации являются данные, сопряженные с DNS или информация о других серверах в пределах сети.
Время жизни маршрутизатора
16-битовое целое без знака. Время жизни ассоциировано с маршрутизатором по умолчанию, измеряется в секундах. Поле может содержать значения до 65535, а получатели должны обрабатывать любые значения, по умолчанию максимальное значение равно 9000 секунд. Время жизни равное нулю указывает, что маршрутизатор не является маршрутизатором по умолчанию и на должен присутствовать в соответствующем списке. Время жизни маршрутизатора относится только к его применимости в качестве маршрутизатора по умолчанию; это не относится к информации, которая содержится в других полях сообщения или опций. Опции, которым нужны временные пределы для содержащейся информации, содержат свои поля времени жизни.
Время достижимости - 32-битовое целое без знака. Время в миллисекундах, в течение которого сосед считается доступным после получения подтверждения доступности. Используется алгоритмом детектирования недоступности соседа. Значение нуль означает, что данный маршрутизатор это время не специфицировал.
Таймер повторной передачи - 32-битовое целое число без знака. Время в миллисекундах между повторно пересылаемыми сообщениями запросов соседа, используется алгоритмами определения адресов и детектирования недоступности соседа. Значение нуль означает, что оно не специфицировано данным маршрутизатором.
Допустимые опции
МАС-адрес (канальный адрес) отправителя. МАС-адрес интерфейса, через который было передано анонсирование маршрутизатора. Используется канальными уровнями, работающими с адресами. Маршрутизатор может игнорировать эту опцию, для того чтобы разрешить балансировку нагрузки между несколькими МАС-адресами.
MTU. MTU следует посылать для каналов, которые имеют переменное значение MTU.
Данные префиксов. Эти опции специфицируют префиксы, которые соответствуют каналу и/или используются для автоматической конфигурации. Маршрутизатор должен включить все свои префиксы канала кроме локального префикса, так чтобы многопортовые машины имели полную информацию об объектах, подключенных к каналу. Если полная информация отсутствует, машина с несколькими интерфейсами не сможет правильно выбрать выходной интерфейс при посылке данных соседу.
Узлы посылают запросы соседа чтобы получить МАС-адрес целевого узла и в свою очередь предоставить ему свой МАС-адрес. При запросе соседа используется мультикастинг, когда узлу нужно выяснить адрес, и уникастные запросы при проверке доступности соседа. На рис. 3 представлен формат запроса соседа.
Рис.3. Формат сообщения запроса соседа
IP поля (IP-заголовок пакета)
Адрес отправителя. Либо адрес, приписанный интерфейсу, откуда пришло это сообщение, либо
(если происходит детектирование дубликатов адресов [ADDRCONF]) - неспецифицированный адрес).
Адрес места назначения. Либо мультикаст-адрес, соответствующий месту назначения, либо непосредственно адрес мишени.
Предельное число шагов
Поля ICMP:
Тип=135
Код=0
Адрес мишени. IP-адрес мишени запроса. Он не должен быть мультикастным.
Возможные опции
МАС-адрес отправителя. МАС-адрес отправителя не должен включаться, когда IP-адрес является неспецифицированным. В противном случае, для канальных уровней, которые имеют адреса, эта опция должна быть включена в мультикаст- и в уникаст-запросы.
Узел посылает анонсирование соседа в ответ на запрос соседа и посылает незапрошенное анонсирование соседа, для того чтобы быстро сделать новые данные доступными. На рис. 4 отображен формат сообщения анонсирования соседа.
Рис.4. Формат сообщения анонсирования соседа
IP поля (IP-заголовок пакета)
Адрес отправителя. Адрес присвоенный интерфейсу, через который послано сообщение анонсирования.
Адрес места назначения. Для запрошенных анонсирований адрес отправителя запроса или, если адресат запроса неспецифицирован, мультикаст-адрес всех узлов.
Предельное число шагов =255
Поля ICMP:
Тип=136
Код=0
R - флаг маршрутизатора. Если R=1, отправителем является маршрутизатор. R-бит используется при детектировании недостижимости соседа, чтобы детектировать маршрутизатор, который заменяет машину.
S - флаг запроса. Когда S=1, это означает, что анонсирование было послано в ответ на запрос соседа со стороны адреса места назначения. S-бит используется в качестве подтверждения недоступности соседа. Бит не следует устанавливать в мультикастных уведомлениях или в случае неспровоцированного уникастного анонсирования.
O - флаг перезаписи. Когда О=1, это означает, что анонсирование должно быть переписано существующей записью в кэше, а кэшированный МАС-адрес обновлен. Когда О=0, анонсирование не обновляет кэшированный МАС-адрес, хотя существующая запись кэша соседа может быть обновлена, если там не было МАС-адреса. Бит не следует устанавливать в запросах анонсирования для эникаст-адресов и в прокси-анонсированиях. О=1 во всех других запрашиваемых и незапрашиваемых анонсированиях.
Адрес мишени. Для запрошенных анонсирований, поле адреса мишени в сообщении запроса соседа, которое вызвало это анонсирование. Для неспровоцированных анонсирований это объект, чей МАС-адрес изменился. Адрес мишени не может быть мульткастным.
Возможные опции
МАС-адрес мишени. МАС-адрес мишени, то-есть отправителя анонсирования. Эта опция должна быть включена на канальных уровнях, которые имеют адреса при реагировании на мульткастинг-запросы. При реагировании на уникаст запросы соседа данную опцию также следует включать.
Опция должна включаться в мультикаст-запросы, чтобы исключить бесконечные запросы соседа, когда узел-партнер не имеет записи в кэше, чтобы прислать сообщение анонсирования соседа. При реагировании на уникастные запросы опция может быть исключена, так как отправитель запроса имеет правильный МАС-адрес; в противном случае он не сможет послать уникастный запрос. Однако включение МАС-адреса в этом случае добавляет некоторую избыточность и исключает потенциальный конфликт, когда отправитель уничтожает кэшированный МАС-адрес, прежде чем он получит отклик на предыдущий запрос.
Маршрутизаторы посылают пакеты переадресации, чтобы проинформировать машину о лучшем варианте следующего шага в пути до цели. Машины могут быть перенаправлены на соответствующий маршрутизатор, но могут быть уведомлены также, что следующим шагом будет сосед. В последнем случае ICMP-адрес мишени делается равным ICMP-адресу места назначения. Формат сообщения переадресации показан на рис. 5.
Рис.5. Формат сообщения переадресации
IP поля:
Адрес отправителя. Должен быть равен МАС-адресу, присвоенному интерфейсу, откуда послано сообщение.
Адрес места назначения. Адрес отправителя пакета, который запустил процесс переадресации.
Предельное число шагов =255
Поля ICMP:
Тип=137
Код=0
Адрес мишени. IP-адрес, который является лучшим следующим шагом для адреса достижения ICMP. Когда мишень является оконечным пунктом маршрута, то-есть местом достижения является сосед, поле адрес мишени должно содержать то же значение, что и адрес места назначения ICMP. В противном случае мишень является наилучшим следующим шагом маршрутизатора, а адрес мишени должен быть локальным МАС-адресом маршрутизатора, так что машина может однозначно идентифицировать маршрутизатор.
Адрес места назначения. IP-адрес места назначения, который переадресуется на мишень.
Возможные опции
МАС-адрес мишени. Он должен быть включен (если известен). Заметим, что в NBMA-каналах машины могут полагаться на наличие опции МАС-адреса мишени в сообщениях переадресации, как на средство определения МАС-адресов соседей. В таких случаях, опция должна быть включена в сообщения переадресации. NBMA - Non-Broadcast Multiple Access.
Заголовок переадресации. IP-пакет, который запустил процесс переадресации должен соответствовать требованиям MTU, специфицированным в документах IPv6.
Сообщения выявления соседа включают в себя нуль или более опций, некоторые из которых могут появляться в сообщении несколько раз. Формат опции представлен на рис. 6. Опции следует дополнять заполнителем, чтобы гарантировать их завершение на 64-битовой границе. Все опции имеют следующий формат:
Рис.6. Формат опций
Тип - 8-битовый идентификатор типа опции. В RFC-4861 определены следующие опции:
| Название опции | Тип |
| МАС-адрес отправителя | 1 |
| МАС-адрес мишени | 2 |
| Информация префикса | 3 |
| Заголовок переадресации | 4 |
| MTU | 5 |
Длина. 8-битовое целое без знака. Длина опции (включая поля тип и длина) в единицах 8 октетов. Значение 0 является недопустимым. Узлы должны игнорировать ND-пакет, который содержит опцию с длиной нуль.
Рис.7. МАС-адрес отправителя/мишени
Тип
1 для МАС-адреса отправителя
2 для МАС-адреса мишени
Длина. Длина опции, включая поля типа и длины в единицах по 8 октетов. Например, длина для адресов IEEE 802 равна 1 [IPv6-ETHER].
МАС-адрес Канальный адрес переменной длины.
Содержимое и формат этого поля (включая порядок байтов и бит) специфицировано в [IPv6-ETHER].
Опция МАС-адреса отправителя содержит адрес отправителя пакета. Он используется в паетах запроса соседа и запроса маршрутизатора.
Опция МАС-адреса мишени содержит этот адрес и используется в пакетах анонсирования соседа и переадресации.
Эти опции должны игнорироваться для других сообщений выявления соседа.
Рис.8. Префиксные данные
Тип 3
Длина 4
Длина префикса 8-битовое целое без знака. Число действительных лидирующих бит в префиксе. Значение лежит в пределах от 0 до 128. Поле длины префикса предоставляет необходимые данные о состоянии канала (в сочетании с L-флагом в опции данных префикса). Она помогает также при автоматической адресной конфигурации, как это специфицировано в [ADDRCONF], для которого может быть больше ограничений на длину префикса.
L
1-битовый флаг (on-link). Когда L=1, это указывает, что этот префикс можно использовать для конфигурации в канале. Когда L=0, анонсирование не делает никаких заявлений относительно on или off свойств префикса. Другими словами, если L=0, машина не должна делать вывода, что адрес, полученный из префикса является off-link. То-есть, она не должна обновлять предыдущую индикацию того, что адрес подключен.
on-link - адрес, который приписан интерфейсу, связанному с текущим каналом. Узел рассматривает адрес как on-link, если:
A
1-битовый флаг автономной адресной конфигурации. Когда A=1, префикс можно использовать для адресной автоконфигурации, как это специфицировано в [ADDRCONF].
Корректное время жизни
32-битовое целое без знака. Протяженность времени в секундах (относительно момента посылки пакета), в течение которого префикс считается корректным для целей определения подключенности. Значение с единицами во всех битах (0xffffffff) обозначает бесконечность. Значение корректного времени жизни (Valid Lifetime) используется также при [ADDRCONF].
Предпочтительное время жизни
32-битовое целое без знака. Протяженность времени в секундах (относительно момента посылки пакета), когда
адреса, полученные из префикса при адресной конфигурации остаются предпочтительными
[ADDRCONF]. Значение с единицами во всех битах (0xffffffff) обозначает бесконечность. Смотри [ADDRCONF].
Префикс
IP-адрес или префикс IP-адреса. Поле длины префикса содержит число корректных лидирующих бит в префиксе. Биты в префиксе после длины префикса зарезервированы и должны содержать нули в случае отправителя и игнорироваться получателем. Маршрутизатор не должен посылать опцию префикса для локального канала, а машина должна игнорировать такую опцию префикса.
Опция информации префикса предоставляет машине префиксы канала для автоматической адресной конфигурации. Опция префиксных данных появляется в пакетах анонсирования маршрутизатора и должна игнорироваться во всех прочих сообщениях.
Рис.9. Заголовок переадресации
Тип=4
Длина
Длина опции в 8-октетных блоках.
IP-заголовок + данные
Исходный пакет, укороченный с целью гарантии того, что размер переадресуемого сообщения не превышает минимальное MTU, необходимое в соответствии с регламентациями IPv6.
Опция заголовка переадресации используется в сообщениях переадресации и содержит все части переадресуемого пакета. Эта опция должна игнорироваться для других сообщений выявления соседа.
Рис.10. Формат MTU
Тип =5
Длина=1
MTU 32-битовое целое число без знака. Рекомендуемое значение MTU для канала.
Опция MTU используется в сообщениях анонсирования маршрутизаторов, чтобы гарантировать, что все узлы в канале используют одно и тоже значение MTU в тех случаях, когда MTU канала не известно.
Эта опция должна игнорироваться для всех прочих сообщение выявления соседа.
В конфигурациях, в которых используются различные геторогенные технологии, максимально поддерживаемое MTU для разных сегментов может отличаться. Если бриджи не генерируют ICMP-сообщение Packet Too Big, обменивающиеся данными узлы будут не способны использовать Path MTU для динамического определения MTU на основе характеристик канала до соседа. В таких случаях, маршрутизаторы могут быть сконфигурированы для использования опции MTU, чтобы специфицировать максимальное значение MTU, которое поддерживается всеми сегментами.
Ниже описана модель возможной структуры организации данных, которую машины (и в определенном смысле маршрутизаторы) будут поддерживать, взаимодействуя с соседними узлами. Описанная организация предлагает объяснение того, как должен работать протокол выявления соседа.
Машинам будет нужно поддерживать следующие блоки данных для каждого интерфейса:
Кэш соседа
Набор записей о конкретных соседях, к которым был адресован трафик в последнее время. Записи привязаны к
уникастному IP-адресу соседа и содержат такую информацию как МАС-адрес, флаг, указывающий,
является ли сосед маршрутизатором или обычной машиной, указатель на любые пакеты, ожидающие выявления адреса и т.д.. Запись кэша соседа содержит также информацию, используемую алгоритмом детектировании недоступности соседа, включая состояние доступности, число запросов, оставленные без отклика, и время следующей проверки недоступности.
Кэш места назначения
- Набор записей о местах назначений, куда посылался трафик последнее время. Кэш места назначения содержит данные о доступности (on-link - off-link) и уровень апосредованности по отношению к кэшу соседа.
Кэш места назначения устанавливает соответствие между IP-адресом места назначения и IP-адресом следующего шага. Этот кэш обновляется данными, полученными из сообщений переадресации.
Список префиксов
- Список префиксов, который определяет набор адресов, находящихся в состоянии on-link. Записи списка префиксов создаются на основе данных, полученных из анонсирований маршрутизатора. Каждая запись имеет значение таймера пригодности (извлеченное из анонсирования), которое используется для удаления устаревших префиксов. Специальное значение таймера "бесконечность" специфицирует то, что префикс остается применимым навсегда, если это значение не будет переписано новым значением из последующего анонсирования.
Префикс локального канала рассматривается в списке префикса, как имеющий значение таймера пригодности равного бесконечности. Приходящие анонсирования маршрутизатора не должны модифицировать значение таймера префикса локального канала.
Список маршрутизаторов по умолчанию
Список маршрутизаторов, куда могут быть посланы пакеты. Записи списка маршрутизаторов указывают на записи кэша соседа; алгоритм выбора маршрутизатора по умолчанию отдает предпочтение маршрутизаторам, о достижимости которых известно. Каждая запись также ассоциируется с таймером недействительности, его значение берется из анонсирований маршрутизатора и служит для удаления записей, которые более не анонсируются.
Заметим, что эти концептуальные структуры данных могут быть реализованы разными средствами. Одной из возможных реализаций является использование одной специальной маршрутной таблицы для всех выше упомянутых информационных структур.
Заметим также, что другие протоколы (напр., Мобильный IPv6) могут добавить некоторые новые структуры данных.
Кэш соседа содержит информацию, с которой работает алгоритм детектирования недоступности соседа. Ключевыми являются данные о состоянии доступности соседа. Здесь возможны пять значений состояния:
Незавершенный (INCOMPLETE)
Процесс разрешение адреса идет, а МАС-адрес соседа пока не определен. Грубо говоря, он достижим (REACHABLE), сосед был еще недавно достижим (в пределах десятков секунд).
Достижим (REACHABLE)
Сосед достижим, во всяком случае он был таковым несколько десятков секунд тому назад.
Устаревший (STALE) Сосед не считается более достижимым, но до тех пор пока трафик посылается, не следует пытаться изменить атрибут его доступности.
Задержка (DELAY)
Сосед уже не считается достижимым и трафик в последнее время посылается соседу. Прежде чем зондировать соседа немедленно, следует сделать выдержку, чтобы дать возможность разобраться в ситуации протоколам верхнего уровня.
Зондирование (PROBE)
Сосед не считается доступным и осуществляется уникастный запрос соседа.
При посылке пакета узел использует для определения IP-адреса следующего шага комбинацию из кэша места назначения, списка префиксов и списка маршрутизаторов по умолчанию. Если IP-адрес следующего шага известен, производится обращение к кэшу соседа за канальным адресом соседа.
Определение следующего шага для заданного уникастного места назначения осуществляется следующим образом. Отправитель выбирает самый длинный префикс из списка префиксов, чтобы определить, находится ли место назначения пакета on- или off-link. Если место назначения соответствует on-link, адрес следующего шага совпадает с адресом назначения пакета. В противном случае отправитель выбирает маршрутизатор из списка маршрутизаторов по умолчанию.
Из соображений эффективности определение следующего шага не выполняется для каждого посылаемого пакета. Вместо этого, результаты вычисления следующего шага сохраняются в кэше места назначения (в котором также содержатся обновления, полученные из сообщений переадресации). Когда узел-отправитель имеет пакет, подлежащий отправке, он первым делом просматривает кэш места назначения. Если там нет записей для данного места назначения, для формирования записи в кэше места назначения запускается процедура определения следующего шага.
Раз IP-адрес следующего шага известен, отправитель просматривает кэш соседа для получения его МАС-адреса. Если записи нет, отправитель создает ее, устанавливает ее состояние как INCOMPLETE, инициирует выявление адреса, и затем ставит в очередь информационный пакет, ожидая завершения выявления адреса. Для интерфейсов, работающих с мультикастингом, выявление адреса сопряжено с посылкой сообщения запроса соседа (Neighbor Solicitation) и с ожиданием анонсирования соседа (Neighbor Advertisement). Когда приходит анонсирование соседа, МАС-адрес записывается в кэш соседа, а ожидающий в очереди пакет отсылается.
Для мультикастных пакетов следующим шагом всегда является (multicast) адрес места назначения, который рассматривается как on-link. Процедуру определения МАС-адреса, соответствующего данному IP мультикаст адресу можно найти в [IPv6-ETHER]).
Каждый раз, когда производится доступ к кэшу соседа при передаче уникастного пакета, отправитель проверяет согласно алгоритму детектирования недоступности соседа соответствующую информацию о доступности. Этот тест может вызвать посылку отправителем уникастного запроса соседа, с целью проверки доступности соседа.
Определение следующего шага делается первый раз, когда трафик посылается по направлению места назначения. Поскольку последующий обмен с этим адресатом будет продолжаться, кэш места назначения будет продолжать использоваться. Если в какой-то момент обмен прервется, как это определено в алгоритме детектирования недостижимости соседа, определение следующего шага придется выполнить еще раз. Например, трафик с отказавшего маршрутизатора следует переключить на работающий. Аналогично может перемаршрутизировать трафик для мобильного узла.
Заметим, что когда узел повторно выполняет определение следующего шага, необязательно удалять всю запись кэша места назначения. В действительности, бывает полезно сохранить такую кэшированную информацию как PMTU (Path MTU) и значения RTT-таймера.
Концептуальные структуры данных, описанная выше, используют различные механизмы для удаления потенциально устаревших или неиспользуемых данных. С точки зрения корректности необязательно периодически чистить записи кэшей места назначения и соседа. Хотя устаревшая информация может потенциально оставаться в кэше бесконечно долго, алгоритм детектирования недостижимости соседа гарантирует, что устаревшая информация быстро удаляется, если она используется.
Чтобы ограничить объем памяти, необходимый для кэшей места назначения и соседа, узлу может быть нужно удалять старые записи. Однако, нужно проявлять осторожность, чтобы гарантировать наличие достаточной памяти для нормальной работы системы. Маленький кэш может привести к большому числу сообщений выявления соседа, если записи удаляются и воссоздаются снова. Любая политика, базирующаяся на недавно используемых записях, фиксирует записи, которые использовались какое-то время (напр., десять минут или более) может быть адекватной для схемы удаления неиспользуемых записей.
Узел должен оставлять запись в списке маршрутизаторов по умолчанию и в списке префиксов пока не истечет их время жизни. Однако узел может удалять устаревшие записи заранее, если осталось мало памяти. Если не все маршрутизаторы занесены в список маршрутизаторов, узел должен оставить, по крайней мере, две записи в списке маршрутизаторов по умолчанию (лучше даже больше), для того чтобы поддерживать надежную коннективность для мест назначения off-link.
При удалении записи из списка префиксов необязательно вычищать записи из кэшей мест назначений и соседа. Детектирование недостижимости соседа эффективно удалит любые записи в кэшах, которые стали некорректными. При удалении записи из списка маршрутизаторов по умолчанию, однако, любые записи в кэше места назначения, которые предполагают проход через маршрутизатор, должны снова выполнить процедуру определения следующего шага, чтобы выбрать новый маршрутизатор.
Выявление префикса представляет собой процесс, с помощью которого машины узнают диапазон IP-адресов, которые подключены к каналу и доступны непосредственно. Маршрутизаторы посылают анонсирования маршрутизатора, которые уведомляют, хочет ли он выполнять функцию маршрутизатора по умолчанию. Анонсирования маршрутизатора содержат также опции префиксной информации, где перечисляются префиксы, идентифицирующие IP-адреса подключенные к каналу.
Адресная автоконфигурация должна также получить префиксы субсети в качестве части конфигурируемых адресов. Хотя префиксы используемые для адресной автоконфигурации логически отличаются от адресов, используемых для определения подключенности, информация автоконфигурации связана с сообщениями выявления маршрутизатора, чтобы уменьшить сетевой трафик. В действительности те же самые префиксы могут анонсироваться для определения подключенности к каналу и автоконфигурации с помощью спецификации соответствующих флагов в опциях префикса данных. Подробности обработки данных при автоконфигурации смотри в [ADDRCONF].
Машины должны игнорировать любые сообщения запроса маршрутизатора.
Маршрутизатор должен игнорировать любые запросы маршрутизатора, которые не удовлетворяют всем ниже перечисленным требованиям:
Содержимое поля Зарезервировано и любых нераспознанных опций следует игнорировать.
Содержимое любых опций, которые не специфицированы для использования в сообщениях запроса маршрутизатора, должны игнорироваться, а пакеты обрабатываться обычным порядком. Единственная опция, которая может использоваться в данном контексте - это опция МАС-адреса отправителя.
Запрос, который прошел тестирование, считается корректным запросом ("valid solicitation").
Узел должен игнорировать любые сообщения анонсирования маршрутизатора, которые не удовлетворяют всем перечисленным ниже условиям:
Содержимое любых определенных опций, которые не специфицированы для использования с сообщениями анонсирования маршрутизатора, должны игнорироваться. Единственная опция, которая может использоваться в данном контексте - это опции МАС-адреса отправителя, префиксной информации и MTU.
Анонсирование, которое прошло тесты валидности, считается корректным анонсированием ("valid advertisement").
Маршрутизатор должен позволять конфигурирование концептуальных переменных. Значения по умолчанию специфицируются для упрощения конфигурации в общих случаях.
Для каждого интерфейса:
IsRouter
Флаг, указывающий, разрешена ли маршрутизация для данного интерфейса. Разрешение маршрутизации для интерфейса означает, что маршрутизатор может переадресовывать пакеты направленные к или из данного интерфейса.
По умолчанию: FALSE
AdvSendAdvertisements
Флаг, указывающий, посылает ли маршрутизатор периодически анонсирования маршрутизатора и реагирует kb на запросы маршрутизатора.
По умолчанию: FALSE
Заметим, что AdvSendAdvertisements должны равняться FALSE по умолчанию, так что узел не начнет случайно работать как маршрутизатор, если только он не сконфигурирован для посылки анонсирования маршрутизатора.
MaxRtrAdvInterval
Максимальное время между неспровоцированными мультикастными анонсированиями маршрутизатора в секундах. Это время не должно быть менее 4 секунд и не более 1800 секунд.
По умолчанию: 600 секунд
MinRtrAdvInterval
Минимальное время допустимое между посылками несправоцированных мультикастных анонсирований маршрутизатора в секундах. Это время не должно быть меньше 3 секунд и не больше чем .75 * MaxRtrAdvInterval.
По умолчанию: 0.33 * MaxRtrAdvInterval. Если MaxRtrAdvInterval >= 9 секунд; в противном случае, значение по умолчанию равно MaxRtrAdvInterval.
AdvManagedFlag
Значение TRUE/FALSE помещается в поле флага "Managed address configuration" (управляемая адресная конфигурация) анонсирования маршрутизатора. Смотри [ADDRCONF].
По умолчанию: FALSE
AdvOtherConfigFlag
Значение TRUE/FALSE в поле флага "Other configuration" (другая конфигурация) в анонсировании маршрутизатора. Смотри [ADDRCONF].
По умолчанию: FALSE
AdvLinkMTU Значение, которое следует поместить в опции MTU, посылаемые маршрутизатором. Значение нуль указывает, что никаких опций MTU не посылается.
По умолчанию: 0
AdvReachableTime
Значение, которое должно быть в поле Reachable Time (достижимое время) в сообщениях анонсирования маршрутизатора, посылаемых маршрутизатором. Значение нуль означает, что данное значение не специфицировано данным маршрутизатором. Должно быть больше 3,600,000 миллисекунд (1 час).
По умолчанию: 0
AdvRetransTimerbr> Значение, которое помещается в поле Retrans Timer (таймер ретрансмиссий) в сообщениях анонсирования маршрутизатора. Значение нуль указывает на то, что значение маршрутизатором не специфицировано.
По умолчанию: 0
AdvCurHopLimit
Значение по умолчанию должно быть уложено в поле Cur Hop Limit сообщения анонсирования маршрутизатора, посланного самим маршрутизатором. Значение должно быть установлено равным текущему значению размера Интернет. Значение нуль означает, что величина маршрутизатором не специфицирована.
По умолчанию: Значение специфицируется в документе "Assigned Numbers" [ASSIGNED].
AdvDefaultLifetime
Значение, которое должно быть записано в поле Router Lifetime (время жизни маршрутизатора) анонсирования маршрутизатора, измеряется в секундах. Должно быть либо нулем, или лежать между MaxRtrAdvInterval и 9000 секундами. Значение нуль указывает, что маршрутизатор не должен использоваться по умолчанию. Эти ограничения могут быть изменены при последующем развитии технологии. Например, в каналах точка-точка партнеры могут иметь достаточно информации о числе и состоянии устройств на другом конце канала, так что анонсирования могут выполняться реже.
По умолчанию: 3 * MaxRtrAdvInterval
AdvPrefixList
Список префиксов, которые должны помещаться в опции префиксной информации сообщений анонсирования маршрутизатора.
По умолчанию: все префиксы, которые анонсирует маршрутизатор с помощью протоколов маршрутизации, как on-link для интерфейса, через который осуществляется анонсирование. Префиксы локального канала в этот список не включаются.
Каждому префиксу соответствует:
AdvValidLifetime
Значение в секундах присваивается Valid Lifetime (доступное время жизни) опции префиксной информации. Значение с единицами во всех разрядах (0xffffffff) соответствует бесконечности. Реализации могут позволить специфицировать AdvValidLifetime двумя путями:
По умолчанию: 2592000 секунд (30 дней), фиксировано (т.e., остается неизменным при последовательных анонсированиях).
AdvOnLinkFlag
Значение присваивается флагу on-link ("L-бит") поля опции префиксной информации.
По умолчанию: TRUE
Адресная конфигурация [ADDRCONF] определяет дополнительную информацию, ассоциированную с каждым из префиксов:
AdvPreferredLifetime
Значение в секундах, которое помещается в Preferred Lifetime (предпочтительное время жизни) опции префиксной информации.
Значение с единицами во всех разрядах (0xffffffff) соответствует бесконечности. Смотри [ADDRCONF]. Реализация может позволить специфицировать AdvPreferredLifetime двумя путями:
По умолчанию: 604800 секунд (7 дней), фиксировано (т.e., остается той же самой при последующих анонсированиях). Эта величина не должна быть больше чем AdvValidLifetime.
AdvAutonomousFlag
Значение помещается в поле Autonomous Flag (флаг автономности) опции префиксной информации . Смотри [ADDRCONF].
По умолчанию: TRUE
Выше названные переменные содержат информацию, которая помещается в исходящие сообщения анонсирования маршрутизатора. Машины используют полученную информацию, чтобы инициализировать набор аналогичных переменных, которые управляют их внешним поведением. Некоторые из этих переменных машин (напр., CurHopLimit, RetransTimer и ReachableTime) применимы ко всем узлам, включая маршрутизаторы. На практике эти переменные не могут реально работать для маршрутизаторов, так как их содержимое может быть извлечено из описанных выше переменных. Однако поведение внешних маршрутизаторов должно быть таким же, как и в случае машин с точки зрения этих переменных.
Термин "анонсирующий интерфейс" относится к любому функционирующему и активированному интерфейсу, который имеет, по крайней мере, один уникастный адрес, и чей флаг AdvSendAdvertisements = TRUE. Маршрутизатор не должен посылать анонсирование маршрутизатора через интерфейсы, которые не являются анонсирующими.
Интерфейс может стать анонсирующим в моменты, отличные от запуска системы. Например:
Маршрутизатор должен подключиться к мульткастинг-адресу всех маршрутизаторов для анансирующего интерфейса. Маршрутизаторы откликаются на запросы маршрутизатора, посланные на адрес всех маршрутизаторов.
Маршрутизатор посылает периодически и по запросам анонсирования маршрутизатора через анонсирующие интерфейсы. В исходящие анонсирования маршрутизатора заносятся следующие значения в соответствии с форматом сообщений анонсирования маршрутизатора:
Маршрутизатор может захотеть послать анонсирование маршрутизатора без объявления себя в качестве маршрутизатора по умолчанию Например, маршрутизатор может анонсировать префиксы для адресной автоконфигурации, не желая переадресовывать пакеты. Такие маршрутизаторы заносят в поле Router Lifetime значение нуль.
Маршрутизатор может решить не включать некоторые или все опции при посылке неспровоцированного анонсирования маршрутизатора. Например, если времена жизни префиксов много больше, чем AdvDefaultLifetime, включение их в некоторые анонсирования может оказаться достаточным. Однако при реагировании на запросы маршрутизаторов или в случае первого несправоцированного анонсирования маршрутизатор должен включить все опции, так что вся информация (напр., префиксы) оказываются быстро распространена при инициализации системы.
Если включение всех опций приводит к тому, что размер анонсирования превысит MTU канала, может быть послано несколько анонсирований, каждое из которых содержит часть опций.
Несправоцированные анонсирования маршрутизатора не являются строго периодическими: интервал между последовательными передачами рэндомизируется, чтобы уменьшить вероятность синхронизации анонсирований разных маршрутизаторов на одном и том же канале [SYNC]. Каждый анонсирующий интерфейс имеет свой собственный таймер. Всякий раз когда интерфейсом посылается мультикастное анонсирование, таймер сбрасывается на значение, которое имеет равномерное распределение вероятности и лежит между сконфигурированным MinRtrAdvInterval и MaxRtrAdvInterval; истечение времени таймера вызывает очередной цикл анонсирования.
Для первых нескольких анонсирований (вплоть до MAX_INITIAL_RTR_ADVERTISEMENTS), посылаемых интерфейсом, когда он становится анонсирующим, если случайно выбранный интервал больше чем MAX_INITIAL_RTR_ADVERT_INTERVAL, таймер должен быть установлен на время MAX_INITIAL_RTR_ADVERT_INTERVAL. Использование меньших интервалов для начальных анонсирований увеличивает вероятность того, что маршрутизатор будет обнаружен, когда он окажется доступным.
Информация, содержащаяся в анонсировании маршрутизатора может быть изменена с помощью действий административного управления. Например, может быть изменено время жизни префиксов, могут быть добавлены новые префиксы, маршрутизатор может перестать быть маршрутизатором (т.e., маршрутизатор становится простой машиной) и т.д.. В таких случаях, маршрутизатор может передать до MAX_INITIAL_RTR_ADVERTISEMENTS неспровоцированных анонсирований.
Интерфейс может прекратить быть анонсирующим, за счет управляющих процедур, таких как:
В таком случае, маршрутизатор должен передать одно или более (но не более MAX_FINAL_RTR_ADVERTISEMENTS) финальных мультикастных анонсирований маршрутизатора с полем времени жизни нуль. Кроме того, машина должна гарантировать, что последующие сообщения анонсирования соседа содержат флаг маршрутизатора равный нулю.
Заметим, что система управления может блокировать возможности маршрутизатора переадресовывать пакеты, при этом интерфейс может остаться анонсирующим. В таком случае, последующие анонсирования маршрутизатора должны установить поле времени жизни маршрутизатора равным нулю.
Машина должна игнорировать любые сообщения запроса маршрутизатора.
В дополнение к периодической рассылке неспровоцированных анонсирований, маршрутизатор посылает анонсирования в ответ на запросы. Маршрутизатор может использовать уникастные отклики непосредственно машине, пославшей запрос, но обычным вариантом является мультикастинг-отклик по адресу, соответствующему всем узлам. В последнем случае, таймер интерфейса устанавливался на новое псевдослучайное значение временного интервала, как если бы только что было послано неспровоцированное анонсирование.
Во всех случаях анонсирования маршрутизатора, посланное в ответ на запрос маршрутизатора, должно быть задержано на псевдослучайное время в интервале от нуля до MAX_RA_DELAY_TIME секунд. Если послано одно анонсирование в ответ на несколько запросов, задержка отсчитывается от момента первого запроса. Кроме того, последующие анонсирования маршрутизатора, посланные по мультикаст-адресу всех узлов, должны быть ограничены по частоте и не посылаться чаще одного анонсирования каждые MIN_DELAY_BETWEEN_RAS секунд.
Маршрутизатор может обрабатывать запрос маршрутизатора следующим образом:
Заметим, что маршрутизатору разрешено посылать мультикастные анонсирования более часто, чем это задано конфигурационной переменной MinRtrAdvInterval, если более частые анонсирования связаны с запросами маршрутизатора. Во всех вариантах, однако, неспровоцированные мультикастинг анонсирования не должны следовать чаще, чем это определено MinRtrAdvInterval.
Запрос маршрутизатора, в котором адрес отправителя является неспецифицированным не должен модифицировать кэш соседа маршрутизатора. Запросы с корректным адресом отправителя модифицируют кэш соседа следующим образом. Если маршрутизатор уже имеет кэш соседа для отправителя запроса, запрос содержит опцию МАС-адреса отправителя, а полученный МАС-адрес отличается от значения в кэше, тогда МАС-адрес в соответствующем кэше соседа должен быть обновлен, а состояние доступности устанавливается устаревшим (STALE). Если нет записей в кэше соседа для отправителя запроса, маршрутизатор создает такую запись, инсталлирует МАС-адрес и устанавливает состояние его достижимости устаревшим. Если в кэше соседа нет записи и в запросе отсутствует опция МАС-адреса отправителя, маршрутизатор может реагировать мультикастным или уникастным анонсированием маршрутизатора. Доступна или нет опция МАС-адреса отправителя, если запись кэша соседа для отправителя запроса существует (или создана), флаг записи IsRouter должен быть установлен равным FALSE.
Маршрутизаторы должны инспектировать корректность анонсирований маршрутизатора, посланных другими маршрутизаторами и верифицировать информацию анонсируемую маршрутизаторами. Детектируемые несогласованности указывают на то, что один или более маршрутизаторов сконфигурированы не верно, что следует фиксировать в журналах системы. Минимальный набор данных, подлежащих проверке, включает в себя:
Заметим, что анонсирование разными маршрутизаторами разных наборов префиксов не является ошибкой. Кроме того некоторые маршрутизаторы могут оставлять некоторые поля не специфицированными, т.e., со значениями нуль, в то время как другие маршрутизаторы могут специфицировать те же самые поля. Протоколировать следует ошибки, приводящие к конфликтным ситуациям, вынуждающим машины переключаться с одного значения на другое после получения каждого анонсирования.
Локальные адреса канала должны изменяться крайне редко. Узлы, получая сообщения выявления соседа, используют адрес отправителя для его идентификации. Если несколько пакетов от одного и того же маршрутизатора содержат разные адреса отправителя, узлы будут считать, что они пришли от разных маршрутизаторов, что может вызвать нежелательные последствия. Например, узел будет игнорировать сообщения переадресации, так как считает, что они пришли не от маршрутизатора следующего шага. Таким образом, адрес отправителя, используемый анонсированием маршрутизатора, посланным определенным маршрутизатором, должен быть идентичным с адресом мишени в сообщении переадресации.
Использование локального адреса канала для однозначной идентификации маршрутизаторов в канале имеет то преимущество, что адрес маршрутизатора известен и не должен изменяться при перенумерации сайта.
Если маршрутизатор меняет МАС-адрес одного из интерфейсов, он должен проинформировать машины об этом изменении. Маршрутизатор должен послать мультикастно несколько анонсирований со старого МАС-адреса со значением поля времени жизни маршрутизатора равным нулю, а после этого послать несколько мультикастных анонсирований с нового МАС-адреса. Все будет выглядеть как будто один интерфейс прекратил анонсирования, а другой их начал с другого адреса.
Машина поддерживает определенные переменные, связанные с выявлением соседей.
Эти переменные имеют значения по умолчанию, которые модифицируются информацией, полученной из сообщений анонсирования маршрутизатора. Значения по умолчанию используются, когда нет маршрутизатора или когда полученные анонсирования имеют соответствующие неспецифицированные значения.
Для каждого интерфейса:
LinkMTU
MTU канала.
По умолчанию: Значения определены в соответствующем документе, который описывает то, как работает IPv6 поверх соответствующего уровня (напр., [IPv6-ETHER]).
CurHopLimit
Значение по умолчанию для предельного числа шагов, используемого при посылке IP-пакетов.
По умолчанию: Значение специфицировано в "Assigned Numbers" [ASSIGNED], и влияет на уровне реализации конкретной программы.
BaseReachableTime
Базовое значение используется для вычисления псевдослучайной величины ReachableTime.
По умолчанию: REACHABLE_TIME миллисекунд.
ReachableTime
Время, которое сосед считается достижимым после получения подтверждения доступности.
Эта величина должна быть равномерно распределена между MIN_RANDOM_FACTOR и MAX_RANDOM_FACTOR. Новое случайное значение нужно вычислять, когда изменяется BaseReachableTime (в результате анонсирований маршрутизатора) или, по крайней мере, каждые несколько часов, если не приходят анонсирования.
RetransTimer
Время между ретрансмиссиями сообщений запросов соседа, при выявлении адреса или при проверке доступности соседа.
По умолчанию: RETRANS_TIMER миллисекунд
Когда имеется несколько маршрутизаторов, информация, анонсируемая коллективно всеми маршрутизаторами может быть супернабором данных, содержащихся в одном анонсировании маршрутизатора. Более того, информация может быть получена с помощью других динамических средств типа DHCPv6. Машины воспринимают всю полученную информацию; получение анонсирования маршрутизатора не должно дикредитировать данные полученные в процессе предыдущих анонсирований или из другого источника. Однако, когда приходит информации для определенного параметра (напр., MTU канала) или опции (напр., время жизни определенного префикса) и она отличается от полученной ранее, данные, полученные позднее, имеют более высокий приоритет.
Поле Router Advertisement (анонсирования маршрутизатора) (напр., Cur Hop Limit, Reachable Time, и Retrans Timer) может содержать значения, помеченные как неспецифицированные. В таком случае, параметр должен игнорироваться и машина должна продолжить использование прежнего значения. В частности машина не должна интерпретировать неспецифицированное значение, как указание возврата к величине по умолчанию, которое использовалось до получения первого анонсирования маршрутизатора. Это правило препятствует машине изменение внутренней переменной, когда один маршрутизатор анонсирует конкретное значение, а остальные маршрутизаторы анонсируют неспецифицированное значение переменной.
При получении корректного анонсирования маршрутизатора машина извлекает адрес отправителя из пакета и выполняет следующее:
Чтобы ограничить память, необходимую для списка маршрутизаторов по умолчанию, машина может запоминать не все адреса маршрутизаторов, полученные из анонсирований. Однако, машина должна сохранить, по крайней мере, два адреса маршрутизаторов, а если возможно, то больше. Когда канал до места назначения вышел из строя, выбирается маршрутизатора по умолчанию. Таким образом, чем больше маршрутизаторов в списке, тем больше вероятность, что альтернативный маршрутизатор будет найден быстро (напр., не дожидаясь прихода следующего анонсирования).
Если полученное значение Cur Hop Limit не равно нулю, машина должна установить переменную CurHopLimit равной полученному значению.
Если полученное значение Reachable Time не равно нулю, машина должна установить свою переменную BaseReachableTime равной полученной величине. Если новое значение отличается от предыдущего, машина должна заново вычислить новое псевдослучайное значение ReachableTime. ReachableTime вычисляется для равномерно распределенной вероятности между моментами MIN_RANDOM_FACTOR и MAX_RANDOM_FACTOR. Использование случайной компоненты исключает синхронизацию сообщений детектирования недоступности соседа.
В большинстве случаев, анонсированная величина Reachable Time будет идентичной для последовательных анонсирований маршрутизатора, и значение BaseReachableTime для машины также редки изменяется. В таких случаях, реализация должна гарантировать, что новое случайное значение вычисляется заново, по крайней мере, раз в несколько часов.
Переменная RetransTimer должна копироваться из поля Retrans Timer, если полученная величина не равна нулю.
После извлечения информации из фиксированной части сообщения анонсирования маршрутизатора производится сканирование этого сообщения для выявления корректных опций. Если анонсирование содержит опцию МАС-адреса отправителя, этот адрес должен быть записан в кэш соседа для маршрутизатора (если необходимо, запись создается), а флаг IsRouter в записи кэша соседа должен стать равным TRUE. Если МАС-адрес отправителя не включен, но соответствующая запись в кэше соседа имеется, то флаг IsRouter должен быть установлен равным TRUE. Флаг IsRouter используется детектированием недоступности соседа, чтобы определить, когда маршрутизатор превращается в обычную машину (т.e., более не способен переадресовывать пакеты). Если создана запись кэша соседа для маршрутизатора, его состояние доступности считается устаревшим. Если запись кэша уже существует и в нее внесен новый МАС-адрес, состояние доступности также должно быть установлено устаревшим.
Если присутствует опция MTU, машины должны скопировать значения опции в LinkMTU, причем это значение должно быть больше или равно минимальному MTU канала [IPv6] и не превышать значения LinkMTU, специфицированному в соответствующей регламентации на канал (напр., [IPv6-ETHER]).
Опции префиксной информации, которые имею флаг "on-link" (L)=1, указывают на то, что префикс идентифицирует диапазон адресов, которые следует рассматривать как on-link. Заметим, однако, что опция префиксной информации с флагом on-link=0 не передает никакой информации, связанной с состоянием канала, и не должна интерпретироваться в смысле, что переданные префиксом адреса находятся в состоянии off-link. Единственным способом аннулировать предшествующую индикацию on-link является анонсирование префикса с L-битом=1 и Lifetime=0. По умолчанию при посылке пакета по адресу, для которого нет информации о статусе канала, следует переадресовать пакет маршрутизатору по умолчанию. Получение опции префиксной информации с флагом "on-link" (L) =0 процедуру не меняет.
Для каждой опции префиксной информации с установленным флагом, машина делает следующее:
Адресная автоконфигурация [ADDRCONF] может в некоторых обстоятельствах использовать большие времена жизни префикса или игнорировать его полностью, для того чтобы предотвратить некоторую DoS-атаку. Однако, так как воздействие такой атаки, имеющей целью префиксный список on-link не является катастрофичной (машины будут посылать пакеты маршрутизатору по умолчанию и получать переадресации, и не будут послать пакеты соседу), протокол выявления соседа не навязывает такую проверку значений времен жизни префиксов. Аналогично, [ADDRCONF] может налагать определенные ограничения на длину префикса для целей адресной конфигурации. Следовательно, префикс может быть отвергнут реализацией [ADDRCONF] машины.
Всякий раз, когда происходит таймаут для записи префиксного списка, соответствующая запись удаляется. Но при этом ни одна из записей кэша места назначения не обновляется.
Всякий раз когда время жизни записи в список маршрутизаторов по умолчанию истекает, такая запись удаляется. При удалении маршрутизатора из списка маршрутизаторов по умолчанию узел должен обновить кэш места назначения таким образом, чтобы все записи, использующие маршрутизатор, выполнили вновь процедуру определения следующего шага, а не продолжали слать трафик тому же (удаленному) маршрутизатору.
Алгоритм выбора маршрутизатора зависит от того, что известно о доступности этого маршрутизатора. Алгоритм выбора маршрутизатора по умолчанию осуществляется при определении следующего шага, когда нет записи в кэше места назначения для отключенного адреса или когда коммуникация через имеющийся маршрутизатор невозможна. В нормальных условиях, когда маршрутизатор будет выбран впервые, трафик посылается адресату. В дальнейшем трафик будет следовать через этот же маршрутизатор, как это указано в кэше места назначения. Любые изменения в этом кэше реализуются посредством сообщений переадресации.
Политика выбора маршрутизаторов из списка маршрутизаторов по умолчанию заключается в следующем:
Сканирование списка маршрутизаторов в этом случае гарантирует, что все доступные маршрутизаторы будут протестированы с помощью алгоритма детектирования достижимости. Запрос маршрутизатора по умолчанию совмещается с посылкой пакета маршрутизатору, что попутно проверяет его доступность.
Когда интерфейс активируется, машина может быть вынуждена прождать до следующего несправоцированного анонсирования маршрутизатора, чтобы локализовать маршрутизатор по умолчанию и познакомиться с префиксами. Чтобы получить анонсирование маршрутизатора быстро, машине следует послать до MAX_RTR_SOLICITATIONS сообщений запроса маршрутизатора, с периодом по крайней мере RTR_SOLICITATION_INTERVAL секунд. Запросы маршрутизатора могут быть посланы после следующих событий:
Машина посылает запросы маршрутизатора по мультикастному адресу всех маршрутизаторов. IP-адрес отправителя устанавливается равным одному из уникастных адресов интерфейса или неспецифицированному адреса. Опция МАС-адреса отправителя должна соответствовать МАС-адресу машины, если IP-адрес не является неспецифицированным.
Прежде чем машина посылает исходный запрос, она должна выждать случайный период времени между 0 и MAX_RTR_SOLICITATION_DELAY. Это способствует облегчению перегрузки, когда стартуют многие машины в одно и то же время, такое может случиться после восстановления системы при отказе питания. Если машина уже реализовала случайную задержку после активации интерфейса (напр., в случае детектирования дупликации адресов [ADDRCONF]), введение новой задержки перед посылкой первого сообщения запроса маршрутизатора будет излишним.
В некоторых случаях, случайная задержка может быть, если нужно, исключена. Например, мобильный узел, использующий [MIPv6], перемещаясь к новому каналу будет нуждаться в выявлении такого перемещения как можно быстрее, чтобы минимизировать потери пакетов из-за изменения топологии связей. Запросы маршрутизатора предоставляют удобный инструмент для детектирования перемещений в мобильном IPv6, так как они позволяют мобильным узлам получать информацию канального уровня, которая свидетельствует о таком перемещении, мобильный агент может послать запрос маршрутизатора немедленно, без псевдослучайных задержек. Заметим, что некорректное использование этого механизма может привести к шторму запросов маршрутизатора. Одновременное перемещение большого числа мобильных узлов, которые используют этот механизм, может привести к большому числу запросов, посылаемых одновременно.
Раз компьютер посылает запрос маршрутизатора и получает корректное анонсирование маршрутизатора с ненулевым временем жизни, компьютер должен прекратить рассылку дополнительных запросов интерфейсом, пока не произойдет одно из названных выше событий. Более того, машина должна послать, по крайней мере, один запрос в случае, когда анонсирование получено до отправки запроса. Отклики на запрошенные анонсирования могут содержать больше информации, чем неспровоцированные анонсирования.
Если машина посылает MAX_RTR_SOLICITATIONS запросов, и не получает анонсирований маршрутизатора, прождав MAX_RTR_SOLICITATION_DELAY секунд после посылки последнего запроса, машина считает, что не существует маршрутизатора, подключенного к каналу, пригодного для [ADDRCONF]. Однако машина продолжает получать и обрабатывать сообщения анонсирования маршрутизатора в случае появления маршрутизатора, подключенного к каналу.
Сообщения запросов соседа и анонсирования используются также для детектирования адресных дубликатов, как это специфицировано в [ADDRCONF]. В частности Детектирование адресных дубликатов посылает сообщения запроса соседа с неспецифицированным адресом отправителя, получателем является его собственный исследуемый адрес. Такое сообщение вынуждает узел, уже использующий адрес, реагировать мультикастным анонсированием соседа, указывающим на то, что адрес занят.
Узел должен отбрасывать любые полученные сообщения запроса соседа, которые не удовлетворяют следующим условиям:
Содержимое поля Зарезервировано и любой нераспознанной опции должно игнорироваться.
Содержимое любых опций, которые не специфицированы? как используемые в сообщениях запросов соседа должны игнорироваться, а пакеты обрабатываться обычным порядком. Единственная опция, которая может появиться, это опция канального адреса отправителя.
Запрос соседа, который прошел валидацию, называется "valid solicitation" (корректный запрос).
Узел должен игнорировать любые полученные сообщения анонсирования соседа, которые не проходят следующие тесты:
Содержимое поля Зарезервировано, и любых нераспознанных опций, должны игнорироваться.
Содержимое любых определенных опций, которые не специфицированы, как используемые сообщениями анонсирования соседа, должны игнорироваться, а пакеты обрабатываться обычным порядком. Единственная опция, которая может появится, это опция МАС-адреса отправителя.
Анонсирование соседа, которое прошло валидацию, называется "valid advertisement" (корректное анонсирование).
Выявление адресов представляет собой процесс, посредством которого узел определяет канальный адрес соседа по его IP-адресу (аналог ARP в IPv4). Процедура осуществляется только для адресов, которые подключены к каналу и для которых отправитель не знает МАС-адреса. Выявление адреса никогда не выполняется для мультикастных адресов.
Имеется возможность того, что машина получит запрос анонсирования маршрутизатора или сообщение переадресации без МАС-адреса в опции. Эти сообщения не должны создавать или обновлять записи кэша. Если запись кэша соседа отсутствует для отправителя такого сообщения, выявление адреса будет нужно перед тем как можно будет начать уникастные обмены с таким адресом. Это особенно важно для уникастных откликов на запросы, где нужен дополнительный обмен пакетами для доставки анонсирования.
Когда активируется интерфейс, способный к мультикаст-обмену, узел должен подключиться к мульткаст-адресу всех узлов данного интерфейса, а также к мультикаст-адресу запрашиваемого узла. соответствующего каждому из IP-адресов, приписанных интерфейсу.
Набор адресов, приписанных интерфейсу может меняться со временем. Новые адреса могут быть добавлены, а старые адреса могут быть удалены [ADDRCONF]. В таких случаях узел должен корректировать список мультикаст-адресов с учетом появления новых или удаления старых адресов. Включение адресов производится с использованием процедуры Multicast Listener Discovery, такой как в протоколах [MLD] или [MLDv2]. Заметим, что несколько уникастных адресов могут соответствовать одному мультикастному адресу; узел запроса не должен покидать мультикастную группу до тех пор пока все приписанные участники не покинут эту группу.
Когда узлу нужно послать уникастный пакет соседу, но он не знает его МАС-адрес, он реализует процедуру выявления адреса. Для интерфейсов, способных работать с мультикастом, производится формирование записи в кэше соседа в режиме INCOMPLETE и посылается сообщение запроса соседа, адресованное соседу.
Если адрес отправителя пакета, требующего запроса, является тем же, что присвоен выходному интерфейсу, то такой адрес должен быть помещен в поле IP-адреса отправителя исходящего запроса. В противном случае, следует использовать один из адресов, присвоенных интерфейсу. Использование адресов отправителя пакета, где возможно, гарантирует, что получатель запроса соседа инсталлирует его IP-адрес в кэш соседа, который весьма вероятно будет использован в последующих обменах.
Если запрос послан по мультикастинг адресу, отправитель должен включить свой МАС-адрес (если он его имеет) в качестве опции МАС-адреса отправителя. В противном случае, отправитель должен включить свой МАС-адрес в качестве опции МАС-адреса отправителя. Необходимо включение МАС-адреса отправителя в мультикастные запросы, чтобы выдать адрес мишени, которому можно послать анонсирование соседа. При уникастном запросе реализация может опустить опцию МАС-адреса отправителя. Здесь предполагается что, если отправитель имеет МАС-адрес партнера в своем кэше, высока вероятность того, что партнер будет также иметь запись в своем кэше для отправителя. Следовательно, его не нужно посылать.
Ожидая завершения выявления адреса, отправитель должен поддерживать небольшую очередь пакетов, ждущих выявления адреса. Очередь должна содержать один пакет или более. Однако число пакетов в очереди для каждого соседа должно быть ограничено. Когда очередь переполняется, вновь прибывший пакет должен заместить старейший. Когда адрес выяснен, узел начинает отправлять пакеты, ждущие в очередях.
Ожидая отклика, отправитель должен повторно передавать сообщения запроса соседа примерно каждые RetransTimer миллисекунд, даже в отсутствие дополнительного трафика к соседу. Повторная передача должна быть ограничена по частоте для каждого из соседей одним запросом каждые RetransTimer миллисекунд.
Если не получено анонсирования соседа после MAX_MULTICAST_SOLICIT запросов, выявление адреса не состоялось. Отправитель должен прислать ICMP-отклик "адресат не достижим" с кодом 3 для каждого пакета, ждущего выявления адреса в очереди.
Корректный запрос соседа (Neighbor Solicitation), который не отвечает следующим требованиям должен немедленно удаляться:
Если адрес назначения является тестовым, обработка запроса соседа должна выполняться согласно [ADDRCONF]. В противном случае реализуется следующее. Если адрес отправителя не является неспецифицированным и на канальных уровнях имеются адреса, запрос включает в себя опцию МАС-адреса отправителя, получатель должен сформировать или обновить запись кэша соседа для IP-адреса отправителя запроса. Если записи не существует, узел должен создать новую и установить состояние доступности адреса равным STALE (устарел). Если запись существует, а кэшированный МАС-адрес отличается от МАС-адреса, содержащегося в полученной опции, кэшированный адрес заменяется полученным, а состояние доступности записи объявляется устаревшим (STALE).
Если запись в кэше соседа создана, флаг IsRouter устанавливается равным FALSE. Это будет сделано, даже если запрос соседа послан маршрутизатором, из-за того что сообщения запроса соседа не содержат указания, является ли отправитель маршрутизатором. В случае когда отправитель является маршрутизатором, последующее сообщения анонсирования соседа или анонсирования маршрутизатора установят правильное значение IsRouter. Если запись кэша соседа уже существует, ее флаг IsRouter не должен модифицироваться.
Если адрес отправителя является неспецифицированным, узел не должен создавать или модифицировать запись кэша соседа.
После любых обновлений кэша соседа узел посылает отклик анонсирования соседа.
Узел посылает анонсирование соседа в ответ на корректный запрос соседа, направленный на один из адресов узла. Адрес места назначения анонсирования копируется из Target-адреса запроса. Если IP-адрес назначения запроса не является мультикастным, опция МАС-адреса места назначения может быть опущена; кэшированное значение для соседнего узла должно уже быть текущим, для того чтобы запрос дошел. Если IP-адрес назначения запроса является мультикастным, опция МАС-адреса мишени должна быть включена в анонсирование. Боле того, если узел является маршрутизатором, он должен установить флаг маршрутизатора равным единице; в противном случае, от должен обнулить этот флаг.
Если адрес мишени является эникастным или уникастным, для которого узел предоставляет прокси услуги, или не подключена опция МАС-адреса мишени, флаг перезаписи должен быть сброшен в нуль. В противном случае, флаг перезаписи должен быть сделан равным 1. Правильная установка флага перезаписи гарантирует то, что узлы предоставят преимущество непроксированным анонсированиям, даже в случае получения его после прокси анонсирования, а также гарантирует то, что первое анонсирование для эникастного адреса "победит".
Если отправитель запроса имеет неспецифицированный адрес, узел должен установить флаг запроса =0 и разослать анонсирование по мультикастному адресу всех узлов. В противном случае, узел должен установить флаг запроса =1 и уникастно послать анонсирование по адресу отправителя запроса.
Если адрес мишени является эникастным, отправитель должен задержать отправку отклика на псевдослучайное время между 0 и MAX_ANYCAST_DELAY_TIME секунд.
Так как уникастные запросы соседа не требуют включения МАС-адреса отправителя, существует возможность того, что узел, посылающий запрошенное анонсирование соседа, не имеет соответствующего МАС-адреса своего соседа в своем кэше. В такой ситуации узел должен будет использовать выявление соседа, чтобы определить МАС-адрес своего соседа (т.e., послать мультикастный запрос соседа).
Когда получено корректное анонсирование соседа (по запросу или несправоцированно), проводится поиск записи мишени в кэше соседа. Если записи нет, анонсирование игнорируется. Нет необходимости создания записи, если такая запись отсутствует, так как получатель не имел каких-либо обменов с мишенью.
Раз подходящая запись в кэше соседа найдена, дальнейшие действия зависят от состояния записи кэша соседа, флагов в анонсировании и МАС-адреса.
Если запись кэша соседа-мишени в момент получения анонсирования находится в состоянии INCOMPLETE, могут произойти две вещи. Если канальный уровень имеет адреса, а опция МАС-адреса мишени не включена, принимающий узел должен игнорировать полученное анонсирование. В противном случае принимающий узел выполняет следующие операции:
Заметим, что флаг перезаписи игнорируется, если запись находится в состоянии INCOMPLETE.
Если запись мишени кэша соседа находится при получении анонсирования в любом состоянии кроме INCOMPLETE, предпринимаются следующие действия:
Флаг запроса анонсирования устанавливается =1, только если анонсирование является откликом на запрос соседа.
Так как запросы детектирования доступности соседа посылаются по кэшированному МАС-адресу, получение запрошенного анонсирования индицирует, что прямой проход работает. Получение незапрошенного анонсирования, однако, может указывать, что сосед имеет срочное уведомление (напр., изменился МАС-адрес). Если срочная информация указывает на изменение параметров, которые узел использует, узел должен проверить доступность пути, когда он посылает следующий пакет. Не существует необходимости обновления состояния незапрошенных анонсирований, которые не изменяют содержимое кэша.
Приведенные правила гарантируют то, что кэш обновляется, либо когда анонсирование соседа имеет приоритет (т.e., установлен флаг перезаписи), либо когда анонсирование соседа относится к тому же канальному адресу, что и записанный в данный момент в кэше. Если ни одно из этих утверждений не верны, анонсирование побуждает последующую процедуру детектирования недоступности соседа (если она пока не запущена) путем изменения состояния записи в кэше.
В некоторых случаях, узел может определить, что его канальный адрес изменился (напр., горячая замена интерфейсной карты) и может пожелать быстро проинформировать своих соседей о новом канальном адресе. В таких случаях узел может послать до MAX_NEIGHBOR_ADVERTISEMENT незапрошенных сообщений анонсирований соседа, мультикастно адресованных всем узлам. Эти анонсирования должны быть разделены, по крайней мере, RetransTimer секундами.
Поле Target-адрес в запрошенном анонсировании устанавливается равным IP-адресу интерфейса, а в опцию канального адреса мишени заносится новый канальный адрес. Флаг запроса должен быть равен нулю, для того чтобы избежать сбоев алгоритма детектирования недоступности соседа. Если узел является маршрутизатором, он должен установить флаг маршрутизатора =1; в противном случае, он должен устанавливать его =0. Флаг перезаписи может быть установлен равным нулю или единице. В любом случае, соседние узлы немедленно изменяют состояние своих записей кэша соседа для адреса мишени на STALE, вынуждая их верифицировать доступность прохода. Если флаг перезаписи =1, соседние узлы инсталлируют новый канальный адрес в свои кэши. В противном случае, они игнорируют новый канальный адрес, пробуя вместо этого кэшированный адрес.
Узел, который имеет несколько IP-адресов, приписанных к интерфейсу, могут мультикастно посылать анонсирования соседа для каждого из этих адресов. В каждом случае узел должен вводить небольшую задержку между отправками анонсирований, чтобы уменьшить вероятность потери анонсирований из-за перегрузки.
Прокси могут рассылать анонсирования соседа мультикастным способом, когда их канальные адреса изменяются или когда они сконфигурированы предоставлять прокси услуги для этого адреса. Если имеется несколько узлов, предоставляющих прокси услуги для одного и того же набора адресов, прокси должны предоставить механизм, который бы предотвращал появление нескольких прокси для какого-либо адреса при мультикастных анонсированиях, для того чтобы уменьшить риск чрезмерного потока мультикастинга. Пример узла, который реализует прокси анонсирования в качестве домашнего агента, описан в [MIPv6].
Узел, имеющий эникастный адрес может осуществлять мультикастную рассылку анонсирований соседа, когда канальный адрес узла изменился.
Заметим, что из-за незапрашиваемых анонсирований соседа обновления кэшей в узлах может осуществляться ненадежно (анонсирования могут быть получены не всеми узлами). Алгоритм детектирования недоступности соседе гарантирует, что весе узлы получат достижимый канальный адрес, хотя задержка может быть несколько больше.
С точки зрения выявления соседа эникастные адреса используются практически также как уникастные. Так как эникастные адреса синтаксически не отличимы от уникастных, узлы при выполнении выявления адресов или детектировании недоступности соседа оперируют с эникастными адресами также как с уникастными.
Узлы, которые имеют эникастные адреса, приписанные к интерфейсу, рассматривают их как уникастные лишь с двумя исключениями. Во-первых, анонсирование соседа, посланное в ответ на запрос соседа должно быть задержано на случайное время между 0 и MAX_ANYCAST_DELAY_TIME, чтобы уменьшить вероятность перегрузки сети. Во-вторых, флаг переписи в анонсированиях соседа следует установить =0, так что, когда приходит несколько анонсирований, используется первое пришедшее, а не последнее.
Так как с уникастными адресами детектирование достижимости соседа гарантирует, что узел быстро детектирует момент, когда связь с эникастным адресом исчезает.
При некоторых обстоятельствах, маршрутизатор может быть прокси для одного или более других узлов, то есть, посредством анонсирований соседа он указывает, что готов принимать пакеты, не адресованные непосредственно ему. Например, маршрутизатор может принимать пакеты для мобильного узла, который отключился от канала. Механизмы, используемые прокси являются аналогичными тем, которые используются для эникаст-адресов.
Прокси должен подключить мультикаст-адреса узлов, которые соответствуют IP-адресам, приписанным узлу, для которого он выполняет функции прокси. Это должно выполняться с помощью протокола выявления мультикастных слушателей, такого как [MLD] или [MLDv2].
Все сообщения запросов анонсирования соседа прокси должны иметь флаг перезаписи =0. Это гарантирует, что если сам узел подключен к каналу, его анонсирования соседа (с флагом перезаписи =1) будут иметь преимущество над любыми другими анонсированиями, полученными от прокси. Прокси может послать незапрошенное анонсирование с флагом перезаписи =1, но делая так, прокси может спровоцировать перезапись верной записи, созданной самим узлом.
Наконец, посылая прокси анонсирование в ответ на запрос соседа, отправитель должен задержать свой отклик на случайное время в интервале от 0 до MAX_ANYCAST_DELAY_TIME секунд, чтобы избежать коллизий из-за большого числа откликов, посланных несколькими прокси. Однако в некоторых случаях (напр., мобильный IPv6), где присутствует только один прокси, такая задержка не нужна.
Коммуникации до или через соседа могут не реализоваться в любой момент по многим причинам, включая отказы оборудования, горячая замена карты интерфейса и т.д. Если отказал адресат, восстановление невозможно и коммуникации прерываются. С другой стороны, если виноват проход, восстановление вполне возможно. Таким образом, узел активно отслеживает состояние доступности для соседей, которым он посылает пакеты.
Детектирование доступности соседа используется для всех проходов между машинами и соседними узлами, включая связи ЭВМ-ЭВМ, машина-маршрутизатор и маршрутизатор-машина. Детектирование доступности соседа может также использоваться между маршрутизаторами, но это не требуется, если имеется эквивалентный механизм, например, в рамках действующего протокола маршрутизации.
Когда проход до соседа оказывается недоступен, процедура восстановления зависит от того, как используется сосед. Если сосед является конечной точкой маршрута, может быть, например, снова выполнена процедура выявление адреса. Если соседом является маршрутизатор, можно попробовать переключиться на другой маршрутизатор. Восстановление связности сводится к выявлению нового следующего шага. Детектирование доступности соседа сигнализирует о необходимости поиска следующего шага путем стирания соответствующей записи в кэше соседа.
Детектирование доступности соседа выполняется только для соседей, которым посылаются уникастные пакеты; этого не делается для мультикастных адресов.
Сосед считается доступным, если узел недавно получил подтверждение того, что пакет, посланный соседу, был получен на IP-уровне. Положительное подтверждение может быть получено двумя способами: подсказки со стороны протоколов высокого уровня, которые указывают, что соединение осуществляет обменную функцию ("forward progress") или в результате получения сообщения анонсирования соседа, которое является откликом на сообщение запроса соседа.
Соединение осуществляет "forward progress", если пакеты, полученные от удаленного партнера, могут прибывать, если последние пакеты, посланные этому партнеру действительно к нему пришли. В TCP, например, получение (нового) подтверждения указывает, что ранее посланные данные достигли партнера. Аналогично, прибытие новых (не-дубликатов) данных указывает, что предыдущие подтверждения были доставлены удаленному партнеру. Если пакеты приходят партнеру, они должны также пройти через узел следующего шага отправителя; таким образом, "forward progress" является подтверждением того, что ближайший сосед достижим. Для объектов, непосредственно не подключенных к каналу, forward progress означает, что маршрутизатор первого шага доступен. Если возможно, эта информация верхнего уровня должна использоваться.
В некоторых случаях (напр., протоколы, базирующиеся на UDP и маршрутизаторы, переадресующие пакеты машинам), такая информация о доступности не всегда может быть получена от протоколов верхнего уровня. Когда нет других данных, узел посылает сообщения запроса соседа, чтобы проверить работоспособность канала.
Приход запрошенного анонсирования соседа служит подтверждением доступности, так как анонсирования с флагом запроса =1 посылаются только в ответ на запрос соседа.
Получение других сообщений выявления соседа, таких как анонсирования маршрутизатора и соседа с флагом запроса =0, не должны рассматриваться как подтверждение доступности. Получение незапрошенных сообщений подтверждает связность только одного направления от отправителя до узла-получателя. Напротив, детектирование доступности соседа требует, чтобы узел отслеживал прямой путь до соседа со своей точки зрения, а не с точки зрения соседа. Заметим, что получение запрошенного анонсирования указывает, что путь работает в обоих направлениях. Запрос должен достичь соседа, побуждая его генерировать анонсирование. Аналогично, получение анонсирования указывает, что путь от отправителя до получателя также в рабочем состоянии. Однако, последний факт известен только получателю, отправитель анонсирования не имеет прямого указания того, что анонсирование дошло до адресата. С точки зрения детектирования доступности соседа, только работоспособность прямого пути имеет смысл.
Запись кэша соседа может быть в одном из пяти состояний:
| INCOMPLETE | Выполнено выявление адреса для записи. Запрос соседа был послан по мультикастинг-адресу мишени, но соответствующее анонсирование соседа пока не получено. |
| REACHABLE | Получено позитивное подтверждение в пределах последних ReachableTime миллисекунд того, что прямой проход до соседа функционирует нормально. В состоянии REACHABLE никаких дополнительных действий при посылке пакетов не предпринимается. |
| STALE | Более ReachableTime миллисекунд прошло с момента получения последнего положительного подтверждения корректной работы прохода. В состоянии stale, никаких действий до посылки пакета не предпринимается. |
| Переход в состояние STALE происходит после прихода незапрошенного сообщения выявления соседа, которое обновляет кэшированный канальный адрес. Получение такого сообщения не подтверждает доступности, а переход в состояние STALE гарантирует то, что доступность будет быстро проверена, если запись действительно используется. Однако, доступность в действительности не проверяется, пока запись реально не используется. | |
| DELAY | Более чем ReachableTime миллисекунд прошло с момента получения последнего позитивного подтверждения того, что прямой проход функционировал корректно, и пакет был послан в пределах последних DELAY_FIRST_PROBE_TIME секунд. Если подтверждения доступности не получено в пределах DELAY_FIRST_PROBE_TIME секунд перехода в состояние DELAY, посылается запрос соседа, а состояние переходит в PROBE. |
| Состояние DELAY является оптимизацией, которая дает протоколам верхнего уровня дополнительное время для проверки подтверждение доступности в тех случаях, когда прошло ReachableTime миллисекунд с момента последнего подтверждения из-за недостаточного трафика в последнее время. Без этой оптимизации, открытие TCP-соединения после падения трафика инициирует тестирование несмотря на то, что последующее трех шаговый обмен обеспечит быструю проверку доступности практически немедленно. | |
| PROBE | Подтверждение доступности проверяется путем посылки запросов соседа каждые RetransTimer миллисекунд, пока не будет получено подтверждение доступности. |
Детектирование доступности соседа работает в параллель с отправкой пакетов соседу. В то время как производится проверка доступности соседа, узел продолжает посылать пакеты соседу, используя кэшированный канальный адрес. Если трафика до соседа нет, тестовые пакеты не посылаются.
Когда узлу нужно выполнить выявление адреса для соседа, это создает запись в состоянии INCOMPLETE и инициирует процедуру выявления адреса. Если выявление адреса терпит неудачу, запись должна быть удалена, так что последующий трафик к этому соседу реализует процедуру определения следующего шага. Эта процедура может гарантировать то, что будет опробован альтернативный маршрутизатор по умолчанию.
Когда получено подтверждение доступности (либо посредством подсказки от протокола высокого уровня, либо за счет запрошенного анонсирования соседа), состояние записи изменяется на REACHABLE. Единственным исключением является то, подсказка верхнего уровня не дает эффекта для записи, находящиеся в состоянии INCOMPLETE (напр., для случая, когда нет кэшированного адреса канального уровня).
Когда ReachableTime миллисекунд прошли с момента получения последнего подтверждения доступности соседа, состояние записи кэша соседа изменяется с REACHABLE на STALE.
Когда узел впервые посылает пакет соседу, чья запись находится в состоянии STALE, отправитель изменяет состояние записи на DELAY и устанавливает таймер на время DELAY_FIRST_PROBE_TIME секунд. Если запись находится все еще в состоянии DELAY, когда происходит таймаут, состояние записи изменяется на PROBE. Если получено подтверждение доступности, состояние записи становится REACHABLE.
При входе в состояние PROBE, узел посылает уникастное сообщение запроса соседа, используя кэшированный канальный адрес. Пребывая в состоянии PROBE, узел повторно передает сообщения запроса соседа каждые RetransTimer миллисекунд, пока не будет получено подтверждение доступности. Зондирование продолжается даже если не посылается соседу никаких дополнительных пакетов. Если отклика не получается в течение RetransTimer миллисекунд после посылки MAX_UNICAST_SOLICIT запросов, повторные посылки прекращаются, а запись удаляется. Последующий трафик к этому соседу воссоздаст запись и снова выполнит выявление адреса.
Заметим, что все запросы соседа ограничены по частоте для каждого из соседей. Узел не должен посылать запросы соседа чаще, чем раз за RetransTimer миллисекунд.
Запись кэша соседа переходит в состояние STALE, при создании, как результат получения пакетов, отличных от запрошенных анонсирований соседа (т.e., запрос маршрутизатора (Router Solicitations), анонсирование маршрутизатора (Router Advertisements), переадресации и запрос соседа (Neighbor Solicitations)). Эти пакеты содержат канальный адрес либо отправителя или в случае переадресации, цели переадресации. Однако, получение этих канальных адресов не подтверждает доступности узла по прямому пути. Перевод вновь созданной записи кэша соседа, для которой известен канальный адрес, в состояние STALE дает гарантию того, что отказ канала будет детектирован быстро. Кроме того, кэшированный канальный адрес должен быть модифицирован из-за получения одного из вышеупомянутых сообщений, состояние записи устанавливается в STALE, чтобы обеспечить верификацию зондированием того, что проход до нового адреса работает.
Чтобы правильно детектировать случаи, когда маршрутизатор переключается в режим обычной машины (напр., если его возможность IP-переадресации заблокирована администратором), узел должен сравнить поле флага маршрутизатора во всех сообщениях анонсирования соседа с флагом IsRouter, записанным в кэше соседа. Когда узел детектирует, что сосед превратился из маршрутизатора в обычную машину, узел должен удалить этот маршрутизатор из списка маршрутизаторов по умолчанию и обновить кэш места назначения. Заметим, что маршрутизатор может отсутствовать в списке маршрутизаторов по умолчанию, хотя кэш места назначения использует его (напр., машина была переадресована на него). В таких случаях для всех записей кэша места назначения, на которые ссылался бывший маршрутизатор, необходимо снова выполнить определение следующего шага, прежде чем использовать запись кэша снова.
В некоторых случаях, специфическая канальная информация может указывать, что проход до соседа разрушился. В таких случаях канальная информация может использоваться для удаления записей из кэша соседа, прежде чем это сделает процедура детектирования недоступности соседа. Однако канальная информация не должна использоваться для подтверждения доступности соседа. Такая информация не дает подтверждения связности точка-точка для IP-уровня.
Сообщения переадресации посылаются маршрутизаторами, чтобы перенаправить машину на лучший маршрутизатор первого шага для выбранного места назначения или проинформировать машину о том, что место назначения фактически является ее соседом (т.e., on-link). Это осуществляется путем установления адреса мишени ICMP равным месту назначения.
Маршрутизатор должен быть способен определить локальный канальный адрес для каждого соседнего маршрутизатора, чтобы гарантировать, что адрес мишени в сообщении переадресации идентифицирует соседний маршрутизатор по его канальному адресу. Для статической маршрутизации, это требование предполагает, что адрес маршрутизатора следующего шага специфицирован посредством его канального адреса. Для динамической маршрутизации это требование предполагает, что все протоколы маршрутизации IPv6 должны как-то обмениваться канальными адресами ближайших маршрутизаторов.
Машина должна игнорировать любые сообщения переадресации, которые не удовлетворяют всем ниже перечисленным требованиям:
Содержимое поля "Зарезервировано" и любых нераспознанных опций должно игнорироваться.
Содержимое любых опций, которые не специфицированы для использования с сообщениями переадресации, должны игнорироваться, а пакеты обрабатываться обычным порядком. Единственной опцией, которая может появляться, является опция канального адреса мишени и опция заголовка переадресации.
Машина не должна рассматривать переадресацию некорректной из-за того, что адрес мишени переадресации не перекрывается одним из канальных префиксов.
Переадресация, которая прошла проверки валидности, называется корректной переадресацией ("valid redirect").
Маршрутизатор может посылать сообщение перенаправления, чтобы ограничить трафик, он всякий раз переадресует пакет, который не адресован непосредственно ему (т.e., пакет, который не маршрутизируется отправителем через маршрутизатор), в котором:
Пакет переадресации содержит:
Маршрутизатор должен ограничить частоту посылки сообщений переадресации, для того чтобы ограничить полосу и цену обработки сообщений переадресации, когда отправитель не реагирует корректно на переадресации, или когда отправитель решает игнорировать не вполне корректные сообщения переадресации.
Маршрутизатор не должен обновлять свои маршрутные таблицы на основе сообщений переадресации.
Машина, получающая корректное сообщение переадресации, должна обновить свой кэш мест назначения так, чтобы последующий трафик попадал по специфицированному адресу. Если не существует записи для данного места назначения, такая запись должна быть создана.
Если перенаправление содержит опцию канального адреса адресата, машина либо создает, либо обновляет запись кэша соседа для адресата. В обоих случаях кэшированный канальный адрес копируется из опции канального адреса адресата. Если запись кэша соседа для данного адресата создана, ее состояние доступности должно быть установлено равным STALE. Если запись кэша уже существует и туда записан другой канальный адрес, ее состояние доступности устанавливается равным STALE. Если канальный адрес тот же самый, что и записан в кэше, запись остается неизмененной.
Если адреса мишени и назначения совпадают, машина должна рассматривать мишень как on-link (подключен к локальному каналу). Если адрес мишени не совпадает с адресом места назначения машина должна для мишени установить флаг IsRouter = TRUE. Если адреса мишени и назначения совпадают, невозможно надежно определить, соответствует ли адрес мишени маршрутизатору. Следовательно, во вновь созданных записях кэша соседа флаг IsRouter устанавливается FALSE, в то время как существующие записи кэша свои флаги не меняют. Если мишенью является маршрутизатор, последующее анонсирование соседа или маршрутизатора обновят флаг IsRouter соответствующим образом.
Сообщения переадресации применяются ко всем потокам, которые направлены даному адресату. Так что при получении переадаресации для какого-то места назначения все записи кэша места назначения для данного адреса должны быть обновлены для использования специфицированного следующего шага, вне зависимости от содержимого поля метки потока (Flow Label), которая встречается в опции заголовка переадресации.
Компьютер не должен посылать сообщений переадресации.
Опции определяют механизм для кодирования полей переменной длины, которые могут встретиться несколько раз в пакете или информации, которая не может появляться во всех пакетах. Опции могут также использоваться для расширения функциональности будущих версий протокола ND.
Для того чтобы гарантировать, что будущие расширения будут сосуществовать с современными реализациями, все узлы должны игнорировать любые опции, которые они не могут распознать в полученных ND-пакетах, и продолжать обрабатывать пакет.
Современный набор опций определен таким образом, чтобы получатель мог обработать несколько опций в одном пакете независимо друг от друга. Для того чтобы гарантировать такое условие, будущие опции должны следовать простому правилу:
Опция не должна зависеть от присутствия или отсутствия любых других опций. Семантика опции должна зависеть только от информации в фиксированной части ND-пакета и информации, содержащейся в самой опции.
Следование вышеприведенному правилу дает следующие преимущества:
Опции в пакетах выявления соседа могут располагаться в любом порядке. Получатели должны быть готовы обрабатывать их вне зависимости от их порядка. В одном сообщении могут присутствовать несколько идентичных опций (напр., опций префиксной информации).
Если число опций в анонсирование маршрутизатора вызывает превышение размера пакета за пределы MTU канала, маршрутизатор может послать несколько отдельных анонсирований, каждое из которых содержит субнабор опций.
Количество данных, включенных в опцию заголовка переадресации должно быть ограничено так, чтобы весь пакет переадресации не превысил минимального MTU, необходимого для поддержки IPv6.
Размеры всех опций кратны 8 октетам, что гарантирует выравнивание без заполнителей. Поля в опциях (также как поля в ND-пакетах) определены так, чтобы обеспечить выравнивание на естественных границах (напр., 16-битовое поле выравнивается кратно 16-бит) за исключением 128-битовых IP-адресов/префиксов, которые выравниваются по 64-битовым границам. Поле канального адреса интерпретируется как октетная строка; оно выравнивается по 8-битовой границе.
Размер ND-пакета, включая IP-заголовок, ограничен MTU канала. При добавлении опций к ND-пакету узел не должен превышать MTU канала.
Константы маршрутизатора:
MAX_INITIAL_RTR_ADVERT_INTERVAL 16 секунд
MAX_INITIAL_RTR_ADVERTISEMENTS 3 передачи
MAX_FINAL_RTR_ADVERTISEMENTS 3 передачи
MIN_DELAY_BETWEEN_RAS 3 секунды
MAX_RA_DELAY_TIME .5 секунды
Константы компьютера:
MAX_RTR_SOLICITATION_DELAY 1 секунда
RTR_SOLICITATION_INTERVAL 4 секунд
MAX_RTR_SOLICITATIONS 3 передачи
Константы узла:
MAX_MULTICAST_SOLICIT 3 передачи
MAX_UNICAST_SOLICIT 3 передачи
MAX_ANYCAST_DELAY_TIME 1 секунда
MAX_NEIGHBOR_ADVERTISEMENT 3 передачи
REACHABLE_TIME 30,000 миллисекунд
RETRANS_TIMER 1,000 миллисекунд
DELAY_FIRST_PROBE_TIME 5 секунд
MIN_RANDOM_FACTOR .5
MAX_RANDOM_FACTOR 1.5
Протокол уменьшает угрозы в отсутствии аутентификации за счет игнорирования ND-пакетов, полученных от off-link (внешних) отправителей. Поле Hop Limit всех полученных пакетов проверяется на наличие кода 255, максимальное легальное значение. Так как маршрутизаторы декрементируют Hop Limit (число шагов) всех пакетов, полученные пакеты, содержащие Hop Limit = 255, пришли от соседа.
Криптографические механизмы безопасности для выявления соседа определены в [SEND]. В качестве альтернативы для IP-уровня аутентификации может использоваться IPsec (см. [IPv6-SA]). Использование IKE (Internet Key Exchange) не подходит для создания безопасных динамических ассоциаций или для запросов соседа, как это описано в [ICMPIKE].
В некоторых случаях может быть приемлемым статически сконфигурированные ассоциации безопасности с привлечением для обеспечения безопасности сообщений выявления соседей, либо [IPv6-AUTH], либо [IPv6-ESP]. Однако, важно заметить, что статически сконфигурированные ассоциации безопасности не масштабируемы (особенно когда рассматриваются мультикастные каналы) и ограничены для использования в малых сетях с известными машинами. В любом случае, если используются [IPv6-AUTH] или [IPv6-ESP], ND-пакеты должны верифицироваться с целью аутентификации. Пакеты, которые не прошли аутентификацию, должны отбрасываться.
Протокол выявления соседей (Neighbor Discovery) совместно адресной автоконфигурацией IPv6 [ADDRCONF] предоставляют механизм перенумерации -- могут вводиться новые префиксы и адреса, а старые могут удаляться.
Надежность этих механизмов базируется на всех узлах в канале, получающих сообщения анонсирования маршрутизатора своевременно. Однако машина может быть выключена или быть недостижимой в течение длительного времени (т.e., машина отключается от питания после завершения проекта). В таком случае можно сохранить надежную перенумерацию, но существуют ограничения на время сохранения анонсирования префиксов.
Рассмотрим следующий пример, в котором префикс в начале анонсировался с временем жизни 2 месяца, но 1-го августа решили, префикс следует удалить из-за перенумерации 1-го сентября. Это может быть сделано с помощью уменьшения анонсируемого времени жизни префикса 1-го августа до 1 недели, с последующим сокращением времени жизни и установлением его равным 0 1-го сентября. Проблема в том, что если один или более узлов отключаются от канала раньше 1-го сентября, они могут все еще думать, что префикс корректен, как это было анонсировано ранее (время жизни префикса = 2 месяцам). Таким образом, если узел был отключен от канала 31-го июля, он считает префикс правильным вплоть до 30-го сентября. Если это узел снова будет подключен к каналу до 30-го сентября, он будет использовать старый префикс. Единственный способ заставить узел перестать использовать префикс, анонсированный ранее с большим временем жизни, прислать ему анонсирование, которое изменит время жизни префикса. Решение в этом случае просто: анонсировать этот префикс с временем жизни нуль с 1-го сентября по 1-е октября.
Вообще, для того чтобы сделать систему устойчивой в отношении отключения узлов от канала, важно отслеживать в дальнейшем, можно ли рассматривать префикс корректным для любого узла, подключенного к каналу. Для того чтобы решить эту проблему, нужно анонсировать этот префикс с нулевым временем жизни до конца прошлого времени пригодности.
Приведенный выше пример имеет важное последствие для использования бесконечных времен жизни. Если префикс анонсирован с бесконечным временем жизни и пезднее этот префикс нужно перенумеровать, нежелательно продолжать вечно анонсировать префикс с нулевым временем жизни. Таким образом, либо нужно избегать бесконечных времен жизни, либо нужно ограничить время в течение которого узел остается отключенным от канала, прежде чем он будет к нему подключен снова. Однако, неясно, как сетевой администратор может ограничить время отключения машины от канала.
Сетевые администраторы должны стремиться максимально ограничить время жизни префиксов (т.e., не больше чем несколько недель). Может показаться, что использование протяженных времен жизней способствует надежности, в действительности, машина будет неспособна обмениваться данными в отсутствии нормально функционирующих маршрутизаторов. Такие маршрутизаторы будут посылать анонсирования маршрутизатора, которые содержат нужный и текущий префиксы. Машина, подключенная к сети, которая не имеет функционирующих маршрутизаторов вероятно должна иметь больше серьезных проблем, чем просто отсутствие верного префикса и адреса.
В данном документе продолжают использоваться следующие типа ICMPv6-сообщений, введенные в RFC 2461:
| Имя сообщения | Тип ICMPv6 |
| Запрос маршрутизатора (Router Solicitation) | 133 |
| Анонсирование маршрутизатора (Router Advertisement) | 134 |
| Запрос соседа (Neighbor Solicitation) | 135 |
| Анонсирование соседа (Neighbor Advertisement) | 136 |
| Преадресация | 137 |
В этом документе используются следующие типы опций выявление соседа, введенные в RFC 2461
| Имя опции | Тип |
| Канальный адрес отправителя (Source Link-Layer Address) | 1 |
| Канальный адрес мишени (Target Link-Layer Address) | 2 |
| Префиксная информация (Prefix Information) | 3 |
| Заголовок переадресации (Redirected Header) | 4 |
| MTU | 5 |
При выявлении адресов и детектировании доступности соседа реализуется следующая модель конечных состояний:
| Состояние | Событие | Действие | Новое состояние |
| - | Послать пакет | Создать запись. Послать мультикаст NS. Запустить таймер повторной передачи | INCOMPLETE |
| INCOMPLETE | Перезапустить Retransmit-таймер Число повторных передач <N | Перезапуск NS. Запуск Retransmit-таймера | INCOMPLETE |
| INCOMPLETE | Перезапустить Retransmit-таймер. Число повторных передач ≥N | Анулировать запись Послать сигнал ошибки-ICMP | - |
| INCOMPLETE | NA, Запрос=0 перезапись=любое | Запись МАС-адреса Послать пакеты из очереди | STALE |
| INCOMPLETE | NA, Запрос=1 перезапись=любое | Запись МАС-адреса Послать пакеты из очереди | REACHABLE |
| INCOMPLETE | NA, Запрос=любое перезапись=любое Никакого МАС-адреса | Обновить содержимое флага IsRouter | не меняется |
| - | NS, RS, Переадресация Никакого МАС-адреса | - | - |
| !INCOMPLETE | NA, Запрос=1 Перезапись=0 МАС-адрес из кэша | - | REACHABLE |
| !INCOMPLETE | NA, Запрос=любое перезапись=любое Никакого МАС-адреса | Обновить содержимое флага IsRouter | не меняется |
| [DHCPv6] | Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. |
| [RDISC] | Deering, S., Ed., "ICMP Router Discovery Messages", RFC-1256, September 1991. |
| [ADDRCONF] | Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. |
| [HR-CL] | Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. |
| [LD-SHRE] | Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005. |
| [IPv6-NBMA] | Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999. |
| [SH-MEDIA] | Braden, B., Postel, J., and Y. Rekhter, "Internet Architecture Extensions for Shared Media", RFC 1620, May 1994. |
| [DHCPv6] | Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. |
| [IPv6-ETHER] | Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998 |
| [IPv6-SA] | Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. |
| [IPv6-AUTH] | Kent, S., "IP Authentication Header", RFC 4302, December 2005. |
| [IPv6-ESP] | Kent, S., "IP Encapsulating Security Payload (ESP)", RFC4303, December 2005. |
| [ASSIGNED] | Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. |
| [SYNC] | S. Floyd, V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z. |
| [MIPv6] | Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. |
| [MLD] | Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. |
| [MLDv2] | Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. |
| [SEND] | Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. |
| [ICMPIKE] | Arkko, J., "Effects of ICMPv6 on IKE", Work in Progress, March 2003. |
UP:
4.4.7 Прокси-ARP |
